迁移策略：CDH 集群整体平缓迁移的最佳实践
在大数据时代，Hadoop作为一款开源的分布式计算框架，已经成为了企业处理海量数据的首选技术。而Cloudera Distribution Inc.（CDH）作为一个基于Apache Hadoop的开源软件平台，为企业提供了一套完整的、易于部署和管理的解决方案。然而，随着业务的发展和需求的变化，企业可能需要对CDH集群进行迁移，以满足新的需求。本文将详细介绍CDH集群整体平滑迁移的过程和注意事项，希望给到大家以借鉴的意义。
一、集群环境
系统环境 | 软件环境 | 集群规模 |
CentOS Linux release 7.6.1810 (Core) | CDH 6.3.0 (Parcel) | 100+ |
二、迁移范围
1.ZooKeeper整体
2.Yarn整体
3.Hdfs整体
4.Hive整体
5.Cloudera Manager Server三、迁移步骤
3.1 迁移zookeeper服务
在Hadoop集群中，Zookeeper主要用于保证Hadoop集群的高可用性，在进行Hadoop集群迁移的过程中，通常先迁移Zookeeper。
Zookeeper集群的平缓迁移主要思路是先扩展Zookeeper集群到新节点，然后下线旧节点，整个过程ZK集群可以持续提供服务。这种方式可以保证服务不中断。
1.通过cm的控制台添加新的节点到zookeeper集群中，保持服务停止状态。
2.通过cm控制台停止需要迁移的旧节点上的服务，登录主机上迁移旧节点上的数据到新添加的节点上对应目录下。
3.通过cm控制台删除旧节点，启动上面新添加的新节点。
4.重复上面的操作，可以迁移走集群的两台zookeeper服务节点。
重点说明：zookeeper集群不能一次性完全迁移完，因为集群中有其他的服务依赖zookeeper服务，所以迁移完2台之后，需要重启集群中其他依赖的服务，如果迁移完所有的zookeeper集群之前没有重启服务，会导致依赖的服务没有更新访问zookeeper服务的信息导致服务整体失败。
重点提示：上面在重启hdfs集群的时候，当重启JournalNode节点时，一定等待一半以上的JournalNode和 active状态的 namenode数据完全同步后，再继续重启其他JournalNode，否则会导致 namenode宕机；
5.等待所有的依赖服务平滑重启完成之后，在迁移最后一台zookeeper服务节点，方式同上。
3.2 迁移Yarn服务
首先迁移ResourceManager,具体的方式如下：
1.通过cm控制台先停止备用的ResourceManager节点，删除此节点。
2.通过cm控制台添加新的ResourceManager节点，启动此服务节点。
3.通过cm控制台重启集群中的所有nodemanager节点和JobHistory Server服务节点。（依次滚动重启）
重点说明：然后这里同时需要重启或者替换依赖Yarn的服务了，这里需要重启的是hive和spark，如果不重启这些服务，服务没有异常，但是提交任务会失败；下面是hive执行计算的一个报错；
4.通过cm控制台重启另一个ResourceManager节点，观察新添加的RM节点是否可以正常切换为主节点。
5.通过cm控制台停止另一个待迁移的节点，并删除此节点
6.通过cm控制台添加新的ResourceManager节点，启用此节点。
7.通过cm控制台重启集群中的所有nodemanager节点和JobHistory Server服务节点。（依次滚动重启）
8.通过cm控制台重启另一个ResourceManager节点，观察新添加的ResourceManager节点是否可以正常切换为主节点。
9.通过cm控制台部署客户端配置。
10.上述步骤无异常，yarn主服务迁移完成，其他的nodemanager节点迁移就很方便了，通过cm控制台下线旧的节点，添加并启动新的服务节点即可。
11.最后依赖的服务还需要重启一次，然后通过cm控制台部署最新的客户端配置。
3.3 迁移HIVE服务
hive服务的迁移主要是Hive Metastore Server和HiveServer2，相对来说比较方便。两个服务的迁步骤相同。
1.通过cm控制台添加新的节点，并启动此节点。
2.通过cm控制台停止旧的节点，删除旧的节点。
3.如果要迁移多台，重复上面的操作即可。
重点提示：在迁移最后一台旧的 Hive Metastore Server服务之前，一定要重启或者更新其他依赖的服务的配置。
3.4 迁移HDFS服务
a.首先迁移JournalNode服务
1.通过cm控制台停止源主机的JournalNode服务，然后将编辑目录（参数dfs.journalnode.edits.dir 对应的配置）下的数据打包。
2.通过cm控制台添加目标新主机到为JournalNode服务。
3.登录主机上同步源JournalNode服务主机上打包的数据到目标新主机相同目录下，注意目录（dfs.journalnode.edits.dir）需要手动创建，且要保持目录的权限和源主机下一致。
4.通过cm控制台从JournalNode服务中将源主机剔除掉。
5.通过cm控制台启动新主机上的JournalNode服务。
说明：新加的JournalNode服务在启动后目录（/hadoop/dfs/jn/ShareSdkHadoop）下没有in_use.lock文件，但是服务是正常启动，在任意一个namenode重启后才会产生此文件。
此时查看新启动的JournalNode服务日志的内容最后一条是
“INFO org.apache.hadoop.ipc.Server: IPC Server listener on 8485: starting”6.通过cm控制台先重启namenode备节点。
7.通过cm控制台手动切换namenndoe主备。
重点注意：如果集群的负载很高，可以通过控制集群资源的使用或者是在任务的低峰期切换，否则有很大风险切换失败。
8.通过cm控制台将 namenode 另一台备节点重启。（第7步中，原来主节点已经切换成备节点）。
9.然后重复上面的操作迁移集群中的其他JournalNode服务。
10.完成所有的JournalNode服务之后，逐台重启其他JournalNode来更新集群中所有的JournalNode的配置保持一致。
重点说明：重启JN服务的过程中，不要太过着急，要等主节点namenode和集群中其他存活的JN的N-1）/ 2个保持同步之后再做下一个重启操作，否则会导致namenode主节点挂掉。
b.迁移Namenode服务
1.通过cm控制台停止备节点的namenode和Failover Controller服务。
2.登录到服务主机上打包停止的nn节点的数据目录（dfs.namenode.name.dir）。
3.登录到服务主机上将打包的数据迁移到新的namenode节点下，数据解压到和原来namenode保持相同配置（dfs.namenode.name.dir）的数据目录下，新主机上目录需要手动创建。注意目录的权限要和老节点的一致。
4.通过cm控制台从hdfs集群删除停止的NameNode和Failover Controller服务。
说明：此时cm页面会有如下报错提示，可以先不用管，一会启用新的后会恢复。
5.通过cm控制台添加新的主机为NameNode和Failover Controller服务。
6.通过cm控制台修改新主机hdfs相关的配置，主要配置项如下截图
NameNode Nameservice、Quorum Journal 名称、dfs.ha.automatic-failover.enabled；
7.通过cm控制台重启新的NameNode和Failover Controller服务。
8.通过cm控制台依次滚动重启集群中其他所有依赖服务。
重点说明：这一步是为下一个NameNode节点的迁移做准备，如果不重启集群的相关依赖服务，会导致下一步在切换主的NameNode服务到新主机时，导致其他依赖服务没有更新关于NameNode的配置而无法正常访问hdfs，导致失败。
9.重复上面的步骤迁移另一个namenode服务。
3.5 Cloudera Manager Server 迁移
- 确定要安装 Cloudera Manager 的新主机。
- 在确认的主机上安装和老机器相同版本的cloudera-manager-server。
- 登录主机上复制旧主机上/var/lib/cloudera-scm-server/路径的全部内容到新主机上的相同路径。确保保留权限和所有文件内容。
- 复制旧主机上/opt/cloudera/parcel-repo目录下的*.parcel文件和*.parcel.sha以及manifest.json文件到新主机的相同目录，注意文件的权限保持一致。
- 更新/etc/cloudera-scm-server/db.properties包含数据库名称、数据库实例名称、用户名和密码。
- 更新所有agent的配置为新主机的ip；/etc/cloudera-scm-agent/config.ini，更新服务器主机属性到新主机名。
- 重启所有的主机的agent服务；systemctl restart cloudera-scm-agent。
- 停止旧主机的cloudera-scm-server。
- 启用新主机的cloudera-scm-server。
- 登录CM控制台，页面重启Cloudera Management Service。
至此，整个集群的服务完成了在线平滑迁移，整个过程集群保持可用状态。
