一、资源查看

公司的测试集群是window Server上用vmvare做的虚拟化节点，由于测试HDP集群的资源分配过少，导致集群的响应速度慢，近期还提示了磁盘告警，故需要从新规划一下HDP的节点以及资源的分配

查看原节点的磁盘情况

使用fdisk -l 命令可以看到，该节点一共100G的磁盘，/dev/sda2为100G的逻辑卷，其中1个逻辑分区50G挂载到根目录/，一个挂载到家目录/home

二、资源分配规划

原分配方案

其中hdp4节点创建后，却没有加入集群中，资源闲置

节点	内存	CPU	硬盘	IP
windowServer实体机	128G	40Core	3T	192.168.10.164
hdp1	8G	4 Core	100G	192.168.10.151
hdp2	8G	4 Core	100G	192.168.10.152
hdp3	8G	4 Core	100G	192.168.10.153
hdp4	8G	4 Core	100G	192.168.10.154

资源分配规划方案

由于预装的hdp集群采用的centos6.4 32位的操作系统，再虚拟化机器中，不能超过8G的内存使用量，所以内存分配暂时只能是使用8G内存，
为了达到资源利用率更高，集群速度更快，将集群横向扩展到9节点，其中6个节点提供Hadoop及相关大数据组件服务，
考虑到发挥kafaka集群的高吞吐、IO，高性能的特性，将其中3个节点隔离开来作为kafka集群单独使用。

节点	内存	CPU	硬盘	IP
windowServer实体机	128G	40Core	3T	192.168.10.164
hdp1	8G	4 Core	200G	192.168.10.151
hdp2	8G	4 Core	200G	192.168.10.152
hdp3	8G	4 Core	200G	192.168.10.153
hdp4	8G	4 Core	200G	192.168.10.154
hdp5	8G	4 Core	200G	192.168.10.155
hdp6	8G	4 Core	200G	192.168.10.156
hdp7	8G	4 Core	200G	192.168.10.157
hdp8	8G	4 Core	200G	192.168.10.158
hdp9	8G	4 Core	200G	192.168.10.159

角色分配预计效果

组件名称	服务名称	节点分布
Hadoop	Active namenode	hdp1
Hadoop	StandBy namenode	hdp2
Yarn	ResourceManager	hdp1
Yarn	NodeManager	hdp1-6
Tez
hdp1-6
Hive	MataStrore	hdp1
HBase	HMaster	Hdp1-2
Hbase	HRegionServer	Hdp1-6
Zookeeper	Zookeeper-Server	Hdp1-3
Kafka	Kafka-Server	Hdp7-9
Hawq	Master	hdp3
	StandBy Master	hdp2
	Segment	hdp1-6
	PXF	hdp1-6

三、磁盘扩容步骤

1. 虚拟机磁盘扩容

2.确认磁盘状况

可以看出/dev/sda 已经变成200G，df磁盘情况并没有变化

3.扩展分区

已经有sda1和sda2了，需要扩展的下一个分区ID为3，输入3

一路空格使用默认配置，将剩余的所有空间都分配给sda3分区

更改分区为逻辑卷

更改过后输入w保存

再次输入fdisk -l可以看到多一个逻辑卷

执行 partprobe或者重启

执行 partprobe命令用于将磁盘分区表变化信息通知内核，并请求操作系统重新加载分区表，可以避免必须重新启动的问题，这里我们reboot一下。

附：PV,VG,LV的关系和操作

扩展vg

扩展lv
可以将此lv全部添加或者部分添加，我们这里全部添加到根目录下 vg_hdp1-lv_root

此时看到df状态还没有变化

动态扩容
使用xfs_growfs可以将xfs文件系统进行online方式的扩展，它会将data block进行调整。

附：动态扩容分区的相关操作

使用df -hT可以看到分区是ext4文件系统

执行命令：

验证扩容之后的空间：根目录已经增大到150G

剩下的将hdp1-3三个节点执行同样的流程扩容即可