服务器集群是怎么做的？

随着单台服务器优势的减弱，相信越来越多的人开始逐渐耳闻“集群”这个概念，很大站长学会香港站群服务器，终于把网站搞上去了，对于热备份服务器系统来说同样有优势，服务器集群技术

两个月前写过一篇文章，HDFS和Yarn经常出现dataNode和NameNode之间, nodeManager与resourceManager之间 连接不良的现象，开始怀疑是service Monitor监控内存失败的问题，于是更换了JDK版本，当时认为问题解决，然而没过多久，假死和连接不良现象又出现了。重新将nameNode日志阈值改成debug，发现依然存在如下异常：
但网上查了一些资料，也有人说这是CDH版HDFS的一个bug。本身并不影响服务。考虑到CDH本身也将该异常认定为debug级别，觉得是有可能的。个人感觉这个问题除了让日志增长比较快，也就这样了。决定先把这个问题放一放。

由于疫情和工作原因，一直没功夫去看这个问题，一气之下把主节点升到16G内存，惊喜发现部署在主节点的DataNode和nodeManager几乎一直是良好状态，而从节点经常出现问题。

比如这个很可怜，除了主节点之外的nodeManager其余都挂了。

所以现在解决问题的思路无非是

1 升级从节点的资源配置，和主节点配置保持一致。
2 通过系统优化和调优解决问题。

本着对技术的探(mei)究(qian)之心，我决定采用第二条方案。

先把服务器上的HDFS nameNode/yarn nodeManager堆栈日志dump下来(因为这两个组件内存占用较大)，看看究竟。发现其中70%的都是不可达对象（也就是图中的灰色部分）。
于是到服务器上去一探究竟。
通过jmap 命令，发现两个现象：

1 新生代内存比较小，并且频繁进行minor gc，几乎每分钟都有。

2 老年代内存一直在增长并且没有释放的迹象。

感觉新生代内存过小可能会导致：

1  频繁的minor gc，很多新生对象没有经过充分gc而进入老年代。（比如新生对象存活时间是五分钟，而频繁的minor gc导致3分钟这个对象就被当成老人放入老年代）

2  频繁的minor gc，可能导致对cpu资源的争夺或其它未知的原因导致nodeManager或者dataNode不良。

而老年代内存回收过慢则导致系统内存一直处于高位。

于是尝试设置两个参数：

-XX:NewRatio=2 -XX:CMSInitiatingOccupancyFraction=45

第一个XX:NewRatio是指扩大新生代内存的比例，降低minor gc的频率，而第二个则是降低触发老年代full gc内存回收的阈值，使得老年代不至于保存大量已不可达的对象。如果但这个值如果设太低，则又会频繁触发full gc和major gc，所以也不敢设置太低，设成45。

通过设置，HDFS的dataNode连接不良的问题得以解决，但yarn的nodeManager还是频繁出现不良。
继续百度+谷歌，发现JDK18有更好的垃圾收集器，G1回收器，感兴趣的同学请移步：

深入理解JVM（5）——GC垃圾回收（3）——8大垃圾收集器

G1回收器比之前用的新生代并行垃圾收集器无论是吞吐量优先(让单位时间内，STW 的时间最短)还是对响应时间优先(尽可能让单次 STW 的时间最短)的处理都比并行垃圾处理器(useParNewGC）优雅不少。

我们可以通过以下参数设置，其中XX:MaxGCPauseMillis为单次最大gc停顿时间。这是一个软目标，G1会尽量保证单次停顿低于该值。

-XX:+UseG1GC -XX:MaxGCPauseMillis=200

设置完之后，集群稳定的一批。跑了一些任务，也没有问题。收工。

最后又是安利追剧时间，今天安利的是精英律师，老干部嘴皮子简直6得不行了，栗娜真的超好看。

1cdh集群版本

5123  CentOS75

2、错误提示

3、集群所有节点都同步了ntp服务器，执行ntptime均返回ok，但任然有三个节点报错。

4、经过一番搜索尝试，问题在于CDH不能及时获取服务器同步性（当我们使用NTP时间同步服务器时）。所以我阐释使用chronyd做时间同步

5、CDH界面验证OK，错误警告消除。

1、Hortonworks Hadoop区别于其他的Hadoop发行版(如Cloudera)的根本就在于，Hortonworks的产品均是百分之百开源。
2、Cloudera有免费版和企业版，企业版只有试用期。
3、apache hadoop则是原生的hadoop。
4、目前在中国流行的是apache hadoop，Cloudera CDH，当然Hortonworks也有用的
5、Apache Ambari是一个基于web的工具，用于配置、管理和监视Apache Hadoop集群，支持Hadoop HDFS,、Hadoop MapReduce、Hive、HCatalog,、HBase、ZooKeeper、Oozie、Pig和Sqoop。Ambari同样还提供了集群状况仪表盘，比如heatmaps和查看MapReduce、Pig、Hive应用程序的能力，以友好的用户界面对它们的性能特性进行诊断。
Ambari你值得拥有
1、通过一步一步的安装向导简化了集群供应。
2、预先配置好关键的运维指标（metrics），可以直接查看Hadoop Core（HDFS和MapReduce）及相关项目（如HBase、Hive和HCatalog）是否健康。
3、支持作业与任务执行的可视化与分析，能够更好地查看依赖和性能。
4、通过一个完整的RESTful API把监控信息暴露出来，集成了现有的运维工具。
5、用户界面非常直观，用户可以轻松有效地查看信息并控制集群。

在hadoop 200之前，在hdfs集群中，NameNode是存在单点故障问题的。每个集群只有一个NameNode，如果该机器或者进程不可用，那么集群将无法使用，直到NameNode重新启动或者在单独的机器启动。在企业中也绝对是HA的。

HDFS:NN SNN(checkpoint) DN

NN节点挂了 就不能提供对外服务
所以需要两个NN active standby,任何时候只有1台 active的NN对外，另外一台是standby 做实时备份，随时准备standby--》active状态，对外提供服务那么外界是无感知

nn1 active hdfs://nn1:9000/ 挂了
nn2 standby hdfs://nn2:9000/

命名空间：挂载着 nn1 nn2 ,读写 *** 作是直接通过命名空间的 *** 作的
hdfs://nameservice1/

思考题 :
以下这三种访问方式有什么不同
hdfs dfs -ls
hdfs dfs -ls /
hdfs dfs -ls hdfs://ip:9000/

第一种访问的当前文件系统的登入用户的家目录，例如： /user/登入的用户/
第二种访问的是当前文件系统的根目录
第三种访问的是指定文件系统的跟目录

HA最少要3台机器

JN:>=3台，2n+1

ZK: 2n+1 投票选举
生产上，如果集群规模<20节点，一般建议配置5台
如果集群规模20~100节点，一般建议配置7/9/11台
如果集群规模>100台，一般建议配置11台
zk 往往会和其他进程部署在同一个机器上，但是如果zk很繁忙（意味着服务器很繁忙），可能导致无法选举，那么建议单独部署zk。
zk 不是越多越好，因为机器越多进行投票选举的时间越长

master--->slave
1DN NM部署在同一个机器上 原因是由于数据本地化。
2大数据生态圈 大部分组件都是主从架构
但是 特别注意: hbase读写流程并不经过master进程。

HA使用active NN, standby NN两个节点解决单点问题。两个NN节点通过JN集群，
共享状态，通过ZKFC选举active，监控状态，自动备援。DN会同时向两个NN节点发送心跳。

active nn：
接收client的rpc请求并处理，同时自己editlog写一份，也向JN的共享存储上的editlog写一份。也同时接收DN的block report，block location updates 和 heartbeat。

standby nn:
同样会接受到从JN的editlog上读取并执行这些log *** 作，使自己的NN的元数据和activenn的元数据是同步的，使用说standby是active nn的一个热备。一旦切换为active状态，就能够立即马上对外提供NN角色的服务。也同时接收DN的block report，block location updates 和 heartbeat。

jn：
用于active nn,standby nn的同步数据，本身由一组的JN节点组成的集群，奇数，3台(CDH)，是支持Paxos协议。保证高可用。

ZKFC：
监控NN的健康状态。向ZK集群定期发送心跳 ，让自己被选举，当自己被ZK选举为主时，zkfc进程通过rpc调用让nn转换为active状态

拓展：
结果双写：spark-->hbase(所有数据)+es(对外 两个月的数据 ttl)
数据同步双写:mysql-->habse 设置A线，B线两种同步方案

RM:
a启动时会通过向ZK的/hadoop-ha目录写一个lock文件，写成功则为active，否则standby。
standby RM会一直监控lock文件的是否存在，如果不存在就会尝试去创建，争取为active rm。
b会接收客户端的任务请求，接收和监控nm的资源的汇报，负责资源的分配与调度，启动和监控 ApplicationMaster（AM）

NM:
节点上的资源的管理，启动container 容器 运行task的计算，上报资源，container情况汇报给RM和任务的处理情况汇报给 ApplicationMaster（AM）

ApplicationMaster（AM）driver : nm机器上的container
单个application(job)的task的管理和调度，并向rm进行资源的申请，
向nm发出 launch container指令，接收NM的task的处理状态信息。

RMstatestore:
aRM的作业信息存储在ZK的/rmstore下，active RM向这个目录写app(作业)信息
b当active rm挂了，另外一个standby rm成功转换为active rm后，会从/rmstore目录读取相应的作业信息，
重新构建作业的内存信息。然后启动内部服务，开始接收NM的心跳，构建集群资源的信息，并接收客户端的提交作业的请求等。

ZKFC:
自动故障转移 只作为RM进程的一个线程 而非独立的守护进程来启动

1zkfc一个是进程，一个是线程
2hdfs ha有独立的数据中间件的集群维护，yarn ha作业调度信息维护在zk里面。
3HDFS中的DataNode 会向两个NameNode同时发送心跳。Yarn中NodeManager只会向activeRM上报资源

---