（四）大数据集群运维

大数据集群运维

ES常见运维命令

windows和linux常用命令

1：集群扩容均衡

1.1：hdfs均衡

su - hdfs命令。hdfs均衡需要使用管理员不然没有权限

hdfs dfsadmin -setBalancerBandwidth 20971520 
设置均衡的集群间速度：20M,可根据网速适当调整
开始均衡：bash */HDFS/hadoop/sbin/start-balancer.sh -threshold 偏差值
停止均衡：bash */HDFS/hadoop/sbin/stop-balancer.sh
bash start-balancer.sh --help查看具体的命令使用情况
均衡日志查看客户端logs的日志

例如：
bash /opt/client/HDFS/hadoop/sbin/start-balancer.sh -threshold 10
这个命令中-threshold 参数值是 HDFS 达到平衡状态的磁盘使用率偏差值。如果各
节点间磁盘使用率与所有节点磁盘使用率的平均值偏差小于 10%，则 HDFS 集群
已经达到了平衡的状态。
hdfs的目录存储。dn/存储数据。/nm/存储spark程序的运行日志

1.2：kafka均衡

执行 kafka-balancer.sh --run --zookeeper {ZooKeeper 集群业务 IP:zk_port}/kafka --
bootstrap-server {Kafka 集群业务 IP: kafka_port } --throttle {throttle number} --
consumer-config {consumer config file path} --show-details

： 多个 ZooKeeper 集群业务 IP 之间使用“,”隔开。
： “zk_port”为“ZooKeeper 服务配置”中的“clientPort”参数值。
： “kafka_port”为“Kafka 服务配置”中的“sasl.port”参数值。
： “throttle number”为均衡方案执行时的带宽限制，单位:bytes/sec。 
： “consumer config file path”为配置文件“consumer.properties”所在的绝对路径。

例如：
kafka-balancer.sh --run --zookeeper
192.168.0.10:24002,192.168.0.11:24002,192.168.0.12:24002/kafka --bootstrap-server
192.168.0.10:21007, 192.168.0.11:21007, 192.168.0.12:21007 --throttle 10000000 –
consumer-config consumer.properties --show-details

1.3：es均衡

curl -XGET "http://IP:Port/_cat/indices?pretty=true"

2：hadoop集群服务角色汇总

jps命令可以查看各个服务器上启动的角色进程。

2.1：hdfs

Namenode：用于管理文件系统的命名空间、目录结构、元数据信息以及提供备份机制等，
		  主要存储数据块位置的元数据信息，一般是主从架构多个节点。
datanode：存储真正的数据块文件信息。
secondarynamenode：主要是帮助主角色进行元数据文件的合并动作，随时准备在Active NameNode出现异常时接管其服务
zkfc：ZooKeeperFailoverController是hadoop用来监控namenode的状态，定期发送health-check的命令，和namenode是一一对应的。
journalnode：HA集群下，用于同步主备NameNode之间的元数据信息，一般最少3个节点。

2.2：yarn

YARN分层结构的本质是ResourceManager。这个实体控制整个集群并管理应用程序向基础计算资源的分配。ResourceManager将各个资源部分（计算、内存、带宽等）精心安排给基础NodeManager（YARN的每节点代理）。ResourceManager还与Application Master一起分配资源，与NodeManager一起启动和监视它们的基础应用程序。在此上下文中，Application Master承担了以前的TaskTracker的一些角色，ResourceManager 承担了JobTracker的角色。

Application Master管理一个在YARN内运行的应用程序的每个实例。Application Master负责协调来自ResourceManager的资源，并通过NodeManager监视容器的执行和资源使用（CPU、内存等的资源分配）。

NodeManager管理一个YARN集群中的每个节点。NodeManager提供针对集群中每个节点的服务，从监督对一个容器的终生管理到监视资源和跟踪节点健康。MRv1通过插槽管理Map和Reduce任务的执行，而NodeManager管理抽象容器，这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。

Client：YARN Application客户端，用户可以通过客户端向ResourceManager提交任务，查询Application运行状态等。

ResourceManager(RM)：负责集群中所有资源的统一管理和分配。接收来自各个节点（NodeManager）的资源汇报信息，并根据收集的资源按照一定的策略分配给各个应用程序。

NodeManager：(NM)NodeManager（NM）是YARN中每个节点上的代理，管理Hadoop集群中单个计算节点，包括与ResourceManger保持通信，监督Container的生命周期管理，
		监控每个Container的资源使用（内存、CPU等）情况，追踪节点健康状况，管理日志和不同应用程序用到的附属服务（auxiliary service）。

ApplicationMaster(AM)：即图中的App Mstr，负责一个Application生命周期内的所有工作。包括：与RM调度器协商以获取资源；将得到的资源进一步分配给内部任务
  		（资源的二次分配）；与NM通信以启动/停止任务；监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。

Container：Container是YARN中的资源抽象，封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等（目前仅封装内存和CPU），当AM向RM申请资源时，RM为AM返回的
		资源便是用Container表示。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。

2,3：zookeeper

ZooKeeper集群中的节点分为三种角色：Leader、Follower和Observer，其结构和相互关系如图1所示。通常来说，需要在集群中配置奇数个（2N+1）ZooKeeper服务，至少（N+1）个投票才能成功的执行写操作。

Leader：在ZooKeeper集群中只有一个节点作为集群的领导者，由各Follower通过ZooKeeper Atomic Broadcast(ZAB)
			协议选举产生，主要负责接收和协调所有写请求，并把写入的信息同步到Follower和Observer。

Follower：Follower的功能有两个：
	每个Follower都作为Leader的储备，当Leader故障时重新选举Leader，避免单点故障。
 	处理读请求，并配合Leader一起进行写请求处理。
Observer：Observer不参与选举和写请求的投票，只负责处理读请求、并向Leader转发写请求，避免系统处理能力浪费。

Client：ZooKeeper集群的客户端，对ZooKeeper集群进行读写操作。例如HBase可以作为ZooKeeper集群的客户端，
		利用ZooKeeper集群的仲裁功能，控制其HMaster的“Active”和“Standby”状态。

2.4：hive

Hive是建立在Hadoop上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。Hive定义了简单的类SQL查询语言，称为HiveQL，它允许熟悉SQL的用户查询数据。Hive的数据计算依赖于MapReduce、Spark、Tez。
Hive体系结构：

用户接口：用户接口主要有三个：CLI，Client和WebUI。其中最常用的是CLI，CLI启动的时候，会同时启动一个Hive副本。Client是Hive的客户端，用户连接至Hive Server。在启动Client模式的时候，需要指出Hive Server所在节点，并且在该节点启动Hive Server。WebUI是通过浏览器访问Hive。MRS仅支持Client方式访问Hive，使用操作请参考从零开始使用Hive，应用开发请参考Hive应用开发。
元数据存储：Hive将元数据存储在数据库中，如MySQL、Derby。Hive中的元数据包括表的名字，表的列和分区及其属性，表的属性（是否为外部表等），表的数据所在目录等

HiveServer：一个集群内可部署多个HiveServer，负荷分担。对外提供Hive数据库服务，将用户提交的
	HQL语句进行编译，解析成对应的Yarn任务或者HDFS操作，从而完成数据的提取、转换、分析。

MetaStore：一个集群内可部署多个MetaStore，负荷分担。提供Hive的元数据服务，负责Hive表的结构和属性信息读、写、维护和修改。
	提供Thrift接口，供HiveServer、Spark、WebHCat等MetaStore客户端来访问，操作元数据。
WebHCat
	一个集群内可部署多个WebHCat，负荷分担。提供Rest接口，通过Rest执行Hive命令，提交MapReduce任务。

Hive客户端：包括人机交互命令行Beeline、提供给JDBC应用的JDBC驱动、提供给Python应用的Python驱动、提供给Mapreduce的HCatalog相关JAR包。

ZooKeeper集群：ZooKeeper作为临时节点记录各HiveServer实例的IP地址列表，客户端驱动连接Zookeeper获取该列表，并根据路由机制选取对应的HiveServer实例。

Hive表数据存储在HDFS集群中。

MapReduce/Yarn集群：提供分布式计算服务：Hive的大部分数据操作依赖MapReduce，
	HiveServer的主要功能是将HQL语句转换成MapReduce任务，从而完成对海量数据的处理。

2.4：hbase

Master：又叫HMaster，在HA模式下，包含主用Master和备用Master。

主用Master：负责HBase中RegionServer的管理，包括表的增删改查；RegionServer的负载均衡，Region分布调整；
	Region分裂以及分裂后的Region分配；RegionServer失效后的Region迁移等。
备用Master：当主用Master故障时，备用Master将取代主用Master对外提供服务。故障恢复后，原主用Master降为备用。

Client：Client使用HBase的RPC机制与Master、RegionServer进行通信。
	Client与Master进行管理类通信，与RegionServer进行数据操作类通信。

RegionServer：RegionServer负责提供表数据读写等服务，是HBase的数据处理和计算单元。
RegionServer一般与HDFS集群的DataNode部署在一起，实现数据的存储功能。

ZooKeeper集群：ZooKeeper为HBase集群中各进程提供分布式协作服务。
	各RegionServer将自己的信息注册到ZooKeeper中，主用Master据此感知各个RegionServer的健康状态。

HDFS集群：HDFS为HBase提供高可靠的文件存储服务，HBase的数据全部存储在HDFS中。

3：故障解决实战

3.1：hdfs

1：HDFS容量使用达到100%

问题现象
HDFS使用容量100%，磁盘容量只使用85%左右，HDFS服务状态为只读，导致上层服务HBase、Spark等上报服务不可用。

原因分析
当前NodeManager和DataNode共数据盘使用，MRS默认预留15%的数据磁盘空间给非HDFS使用，可通过HDFS参数dfs.datanode.du.reserved.percentage修改百分比来控制具体的磁盘占比。

当HDFS磁盘使用100%之后，可通过降低dfs.datanode.du.reserved.percentage百分比来恢复业务，再进行磁盘扩容。

2：数据写入报java.io.IOException: Too many open files。

问题背景与现象
文件最大打开句柄数设置太小，导致文件句柄不足。写文件到HDFS很慢，或者写文件失败。
执行ulimit -a命令查看有问题节点文件句柄数最多设置是多少，如果很小，建议修改成640000
执行vi /etc/security/limits.d/90-nofile.conf命令编辑这个文件

4：数据分布不均衡

HDFS的DataNode数据分布不均匀，在某节点上磁盘使用率很高，甚至达到100%，其他节点空闲很多。
原因分析
客户端安装在该节点，根据HDFS数据副本机制，第一个副本会存放在本地机器，最终导致节点磁盘被占满，而其他节点空闲很多。

解决办法
针对已有不平衡的数据，执行balance脚本均衡数据。
/opt/client/HDFS/hadoop/sbin/start-balancer.sh -threshold 10

其中“/opt/client”是实际的客户端安装目录。

针对新写入数据，将客户端安装在没有安装DataNode的节点。

5：执行balance失败，/system/balancer.id文件异常

问题详细：

在HDFS客户端启动一个Balance进程，该进程被异常停止后，再次执行Balance操作，操作会失败。
解决方法

方法1：等待硬租期超过1小时后，原有客户端释放租约，再执行第二次Balance操作。

方法2：删除HDFS中的“/system/balancer.id”文件，再执行下次Balance操作。

3.2：yarn

1：Yarn队列资源不足

可能原因

NodeManager节点资源过小。
队列最大资源容量设置过小。
AM最大资源百分比设置过小

解决
1：分别使用命令free -g和cat /proc/cpuinfo，查询节点可用内存和可用CPU
2：确定是否可以增大Yarn NodeManager的资源参数“yarn.nodemanager.resource.memory-mb”“yarn.nodemanager.resource.cpu-vcores”的值，然后重启NodeManager实例。

3.3：zookeeper

3.4：hive

3.4：hbase

1：HBase合并队列超出阈值

可能原因

HBase regionserver数太少。
HBase 单个regionserver上region数过多。
HBase regionserver堆大小较小。
资源不足。
相关参数配置不合理。

解决：适当调大其值或者分析运行日志后再处理。

hbase.hstore.compaction.min”，
“hbase.hstore.compaction.max”，
“hbase.hstore.compactionThreshold”，
“hbase.regionserver.thread.compaction.small”和“hbase.regionserver.thread.compaction.throttle”，

2：HBase节点数据写入延迟/cpu负载高

因为hdfs和hbase服务再同节点，在部署数据入湖程序后数据写入hbase，但是发生了写入延迟，排查集群节点状态发现两台服务器的cpu负载较高达到了90%。
排查过程：
1、集群页面看节点的cpu负载
2、到高负载节点排查进程发现是regionserver进程
3、到hbase集群查看service.log日志发现了一些warn告警：WARN | RpcServer.default.FPBQ.Fifo.handler=101,queue=1,port=21302 | slow scan response (process time:30000) on regionserver:node-group。该告警node就是高负载的node。
3、在hbase集群页面查看该regionserver服务发现，region数量比其他服务器要多100左右达到了650个（内存31G。一般控制小于region数20个/G），同时查看写入请求发现较多。
若是存在大量的compcation线程压缩则是属于正常现象，不用处理等compcation完毕自行恢复。
4、同时排查问题发现有服务一直在以分钟级调度一直读取hbase的数据导致node的负载过高

解决

1：region均衡
2：联系定时调度任务进行调优，降低调度频率
3：集群扩容

4：集群配置优化

4.1：hdfs

GC_OPTS：【说明】JVM用于gc的参数。仅当GC_PROFILE设置为custom时该配置才会生效。需确保GC_OPTS参数设置正确，否则进程启动会失败。默认的话内存只有2G。
HDFS->NameNode
namenode的内存大小和文件块数正相关，可以按照下面比例增加。
10,000,000 “-Xms6G -Xmx6G -XX:NewSize=512M -XX:MaxNewSize=512M”

-Xms10240M -Xmx71680M -XX:NewSize=6144M -XX:MaxNewSize=12288M -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=128M -XX:CMSFullGCsBeforeCompaction=1 -XX:MaxDirectMemorySize=1G -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=80 -XX:+PrintGCDetails -Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFE -Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFE -XX:-OmitStackTraceInFastThrow -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=1M -Djdk.tls.ephemeralDHKeySize=2048

HDFS->DataNode

-Xms6144M -Xmx12288M -XX:NewSize=614M -XX:MaxNewSize=1228M -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=128M -XX:CMSFullGCsBeforeCompaction=1 -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=80 -XX:+PrintGCDetails -Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFE -Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFE -XX:-OmitStackTraceInFastThrow -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=1M -Djdk.tls.ephemeralDHKeySize=2048

dfs.datanode.data.dir：hdfs存储数据的路径。一般会配置多个路径，默认只有一个性能较低。

4.2：yarn

yarn.nodemanager.resource.cpu-vcores：表示该节点上YARN可使用的cpu核数，一般和是节点核数一致
yarn.nodemanager.resource.memory-mb：表示该节点上YARN可使用的物理内存总量，默认为16384，单位M。建议配置成节点物理内存总量的75%-90%。若该节点有其他业务的常驻进程，请降低此参数值给该进程预留足够运行资源
GC_OPTS

JVM使用的gc参数。仅当GC_PROFILE设置为custom时该配置才会生效。需确保
GC_OPT设置正确，否则进程启动会失败。【默认值】-Xms512M -Xmx1G，优化如下
-Xms1024M -Xmx4096M -XX:NewSize=922M -XX:MaxNewSize=1843M -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=128M -XX:CMSFullGCsBeforeCompaction=1 -XX:MaxDirectMemorySize=128M -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingOccupancyFraction=80 -XX:+PrintGCDetails -Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFE -Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFE -XX:-OmitStackTraceInFastThrow -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=1M -Djdk.tls.ephemeralDHKeySize=2048

4.3：zookeeper

4.4：hive

4.5：hbase

1、HBase->RegionServer优化
优化配置说明：->后表示优化后的值

hbase.client.scanner.timeout.period
客户端执行scan的租约超时时间【默认值】60000->300000

hbase.regionserver.maxlogs
RegionServer进程运行过程中，仅有一个HLog文件可以被用来提供写数据服务。当该HLog文件的大小超过某个值时，该文件必须被禁用并归档且必须创建一个新的HLog文件以提供写数据服务。hbase.regionserver.maxlogs被用来设置归档的HLog文件的最大数量。若归档的HLog文件数超过hbase.regionserver.maxlogs的参数值，一些不必要的HLog文件将被系统强制删除。
【默认值】32->64

hbase.hfile.hsync
设置是否启用Hfile耐久性以将数据持久化到磁盘。若将该参数设置为true，则性能将受到影响，原因是每个Hfile写入时都会被hadoop fsync同步到磁盘上。
【默认值】true->false

hbase.hstore.flusher.count：flush线程数
【默认值】2->8

hbase.regionserver.thread.compaction.small
minor。compcation小压缩线程数【默认值】10->15

hbase.regionserver.global.memstore.size
更新被锁定以及强制冲洗发生之前一个RegionServer上支持的所有MemStore的大小。提升内存配置可以提高写入性能。
【默认值】0.4->0.5

hbase.hstore.compaction.min
默认值 3，一个列族下的HFile数量超过该值就会触发Minor Compaction，这个参数默认值小了，一般情况下建议调大到5~10之间，注意相应调整下一个参数

hbase.hstore.compaction.max
默认值 10，一次Minor Compaction最多合并的HFile文件数量，这个参数基本控制着一次压缩即Compaction的耗时。这个参数要比上一个参数hbase.hstore.compaction.min值大，通常是其2~3倍。

hbase.regionserver.handler.count
该设置决定了处理RPC的线程数量，默认值是10，通常可以调大，比如：150，当请求内容很大（上MB，比如大的put、使用缓存的scans）的时候，如果该值设置过大则会占用过多的内存，导致频繁的GC，或者出现OutOfMemory，因此该值不是越大越好。

HBase->HMaster-GC_OPTS一般默认4G够用