CDH集群机房搬迁这活儿我接过不止一次了。每次听到机房搬迁四个字第一反应不是兴奋而是头皮发麻——尤其是CDH这种动辄几十上百节点的生产集群一次搬迁牵涉到网络、存储、元数据、服务依赖、业务验证方方面面任何一个环节掉链子轻则服务起不来重则数据完整性受损。这篇文章我把这些年踩过的坑、积累的经验整理成一套可落地的搬迁方案从前期评估、策略选型到执行步骤、问题排查尽量讲透给正准备做机房迁移或集群迁移的运维朋友一个完整的参考框架。1. 搬迁前的摸底为什么大多数搬迁事故都出在没想清楚1.1 先盘清楚集群家底再谈搬迁策略很多人一接到机房搬迁任务第一反应就是停机搬机器上电启动服务。这个思路害死人。CDH集群跟普通单机应用完全不同它是由Cloudera Manager统一管理的一套分布式系统节点之间有着复杂的角色依赖和数据冗余关系。如果不对集群家底做一次彻底盘点搬迁过程中任何惊喜都会被无限放大。摸底阶段至少要搞清楚五件事第一件事集群规模和角色分布。打开Cloudera Manager的主机列表页把每个节点的角色梳理清楚哪些节点是NameNode哪些是DataNode哪些跑了HBase RegionServer、Kafka Broker、ZooKeeper、Hive Metastore。这里不用靠记忆直接导出一份Hosts和Roles的清单就可以了。关键是要搞清楚每个节点的硬件配置CPU、内存、磁盘数量和容量因为新机房的机柜承重、电力配额都跟这个挂钩。第二件事元数据和服务配置的现状。CM自身的数据库通常是PostgreSQL或者MySQL里面存着集群的所有配置、运行历史和告警信息要确认备份机制是正常的。HDFS的NameNode元数据目录、JournalNode的edits日志目录、Hive的Metastore库、Kafka的controller配置这些都属于搬错一步就全员陪葬的敏感数据。我建议按服务维度列一张配置清单标注每个服务的配置存储位置和当前版本防止搬迁后配置丢失或版本错乱。第三件事数据量和数据分布。用hdfs fsck或hdfs dfsadmin -report统计出总体块数量、副本分布情况、各目录的数据量大小。如果集群里跑着Kafka还要统计每个Topic的分区数和保留的数据量。这些数字直接决定数据迁移窗口也关系到新机房的存储是否有富余。第四件事业务方的真实需求。搬迁期间业务能不能停能停多久有没有跨机房同步的实时任务这些一定要提前拉上业务负责人开会敲定。我从经验上说业务方往往比你想象的更扛得住停机但前提是你提前把停机窗口说清楚并且给出血和肉的对比是停8小时做完整搬迁还是分两期做滚动迁移、承受至少一个月的新旧环境并存复杂度。第五件事新旧机房的物理条件差异。网络带宽内网是万兆还是千兆、机柜数量、供电能力、空调散热、物理位置。这些看起来不是技术问题但恰恰是搬迁计划能不能落地的底层约束。比如新旧机房之间有专线或者公网链路的话数据级迁移的效率会完全不一样如果只能整机物理搬运那你需要提前规划货梯、搬运路线、机柜标签和上架顺序。1.2 搬迁策略三种选型别只盯着怎么搬盘完家底之后就要定搬迁策略。根据我接触过的案例CDH集群机房搬迁基本可以归纳为三种模式模式一整机物理搬迁。集群节点随着机柜整体搬迁到新机房适用于新旧机房距离近、搬迁窗口短、服务器数量不是特别大的场景。好处是数据不用重新复制元数据和服务角色一一对应搬迁后基本只需要调整网络配置就行。风险在于物理搬运可能损坏硬件而且整个窗口期内集群完全不可用如果搬运过程中硬盘损坏还得靠HDFS的副本机制来恢复。模式二数据级迁移。把集群数据从旧机房迁移到新机房的全新集群上典型的工具是Hadoop自带的DistCp加上Hive的export/import、Kafka的MirrorMaker等。这种模式适合新旧机房距离远、无法物理搬运或者新集群顺便要做版本升级、架构调整的场景。数据级迁移可以做到业务不中断通过双跑或增量同步来缩短最终切换窗口但实施复杂度明显更高而且对网络带宽要求很高。模式三混合迁移。先把计算层和一部分角色迁移过去数据层做异步复制最后在停机窗口内做一次增量拷贝和主备切换。这种方式适合超大规模集群或者业务连续性要求极高的场景。我个人的建议是节点在50台以下、机房距离可控的优先考虑物理搬迁如果跨城搬迁或者新增节点数量较多优先考虑数据级迁移真正的生产大集群混合迁移是唯一选择。选择策略时不要光看搬迁这么简单还要考虑后续半年内集群是不是会扩容、平台是不是要做升级。一次搬迁至少消耗一两周的精力别在搬迁前刚做完决策、搬迁后一个月又因为版本或架构问题再来一次无痛迁移。2. 搬迁方案的核心设计网络、数据和停机窗口是三个变量2.1 网络拓扑重构IP固化还是全量变更机房搬迁遇到的第一道坎大概率不是数据而是网络。CDH集群对主机名和IP十分敏感因为CM会把每个Agent的主机名、IP地址、角色配置都记录在自己的元数据库里。如果搬迁后IP段变了你会面临三个连带问题Agent连不上CM Server、NameNode/DataNode之间互相找不到、Hadoop各组件的配置文件里全是旧IP。所以在搬迁方案里网络规划必须放在最前面。我的做法是分三种情况处理情况一新旧机房网络可以打通且能够保留原有IP。这是最理想的情况。通过VLAN互通、路由策略调整让旧集群的节点搬到新机房后使用的还是原来的IP和主机名。这种情况下CDH集群基本可以无感搬迁只需要处理DNS解析和默认网关的切换。操作上提前在新机房核心交换机上配置好原有网段的VLAN服务器上架后直接接网线不做任何IP改动。情况二IP段可以变化但主机名保持不变。这种情况也比较常见。CDH依赖主机名来识别节点IP变化反而好处理因为只要更新/etc/hosts和/etc/sysconfig/network-scripts/ifcfg-*里的IP配置并保证新IP在CM数据库里能正确记录即可。重点要检查的是各服务配置里是否有写死的旧IP——比如HBase的hbase-site.xml、Kafka的advertised.listeners、HDFS的dfs.namenode.rpc-address。情况三IP和主机名都变。这种情形最麻烦相当于把整个集群改名换姓。需要修改主机名并在CM中重新添加主机或者通过CM的Reconfigure操作对所有角色做一次配置刷新。我明确建议如果条件允许尽量不要IP和主机名同时变否则排查问题的复杂度会直线上升。实操层面的网络检查清单如下新旧机房的内网MTU是否一致很多分布式传输问题是MTU不一致导致的建议统一为9000或1500核心交换机到所有节点的带宽是否满足HDFS块复制和Spark Shuffle的吞吐要求防火墙和安全组策略是否放行了CDH需要的端口段9000/8020、2181、9092、16000等DNS解析记录是否提前更新并保留旧DNS一段时间的缓存2.2 数据迁移路线物理搬运与逻辑复制的边界数据迁移是整个搬迁方案里最花时间、最容易被低估的环节。如果是物理搬运这一节可以跳过但还是要做好上架后硬盘自检和块校验如果是数据级迁移就需要认真规划迁移节奏。我常用的数据迁移策略是全量加增量两段式全量阶段在搬迁窗口前的T-2周视数据量大小可提前更多用DistCp把HDFS上的核心业务数据从旧集群复制到新集群。命令示例hdfs distcp -p -update -delete \ hdfs://old-namenode:8020/user/business \ hdfs://new-namenode:8020/user/business-p保留权限、时间戳等属性-update做增量覆盖-delete删除源端已经不存在的文件。初次全量迁移时如果中途失败可以反复执行同一命令DistCp天然支持断点续传。Hive的数据表如果底层是HDFS文件直接迁HDFS即可但要注意/user/hive/warehouse目录的属主必须是hive用户否则跑Hive SQL时会报权限错误。这里要吃透一个关键原理DistCp并不是把文件复制过去那么简单它会把源端文件的所有block信息拉取下来然后由MapReduce任务并行执行复制。这意味着在DistCp运行期间会占用大量的网络带宽和MapReduce资源。所以跑全量复制的时间点尽量选在业务低峰期并且通过-bandwidth参数做限速避免把业务集群打死。增量阶段在正式切换窗口的T-1天或T-0天再执行一次增量DistCp把业务停写之后新增的数据同步到新集群。Kafka的数据迁移则要复杂一些这里给两条路线如果Topic数据量不大直接在搬迁窗口内停掉旧Kafka把数据目录整体拷贝到新机器上再启动Kafka。这个方案的坑在于Kafka的日志目录和分区副本分配关系不能乱拷贝后需要确保目录属主和路径一致。若数据量大且业务不容许长时间停机就用Kafka MirrorMaker做Topic的准实时同步。MirrorMaker本质上就是一个Kafka消费者加生产者把旧集群的消息消费下来再写到新集群。切流时业务先把生产端切到新集群等消费Lag清掉后再把消费端也切过去。2.3 停机窗口的估算逻辑停机窗口不是拍脑袋定的而是根据两个时间估算出来的一是数据增量同步所需时间二是服务停启和验证所需时间。增量同步时间可以这么估算统计出搬迁前几天每天的数据增量例如HDFS大约新增2TBKafka日增500GB再看新旧机房之间的实际带宽例如1Gbps专线理论上2.5TB的数据需要大约5.6小时。但实际网络不可能打满一般打六折所以增量同步至少要估8~10小时。再加上服务停启和校验我建议整体停机窗口至少在12~24小时以上比较稳妥。如果你给业务方承诺两小时搞定大概率是你对增量数据量不清楚或者对服务启动耗时估计太乐观。服务启停时间的估算也不能瞎拍。以100个节点的CDH集群为例从CM上停止所有服务的干净操作大约需要30~60分钟启动ZooKeeper、HDFS、YARN等核心服务又要30分钟左右再加上后续Hive、HBase、Kafka等服务依次启动整体启动过程可能还要再加40分钟。这些时间都是理想情况一旦启动过程中出现角色起不来的情况时间就不可控了。3. 实操过程CDH集群搬迁的完整落地步骤3.1 搬迁前备份清单与执行细节搬迁前备份是整个方案里最不应该省的一步。我每次做搬迁都会强制自己完成一整轮备份并把备份文件同步到集群外的独立存储上。备份清单至少要包括下面几个层面CM管理层面的备份。CM的数据库通常名为scm或rman里面存储了集群配置、主机分配关系、服务角色状态、告警历史等关键信息。备份方式很简单用PostgreSQL自带的pg_dump或MySQL的mysqldump就行pg_dump -U scm -h localhost scm scm_backup_$(date %F).sqlHDFS元数据备份。NameNode内存中的目录树和文件块映射关系是集群的命脉。通过hdfs dfsadmin -saveNamespace将内存状态落盘到fsimage然后备份dfs.namenode.name.dir目录下的fsimage和edits文件并同步到异地。另外把HDFS Federation如果开启了中每一个NameNode的元数据都备份一遍。Hive Metastore备份。Hive的元数据表结构虽然不会频繁变化但一旦丢失所有表结构、分区信息都要重建。在MySQL里执行mysqldump -u hive -p hive_database hive_metastore_backup_$(date %F).sql各服务配置目录备份。包括但不限于/etc/hadoop/conf、/etc/hbase/conf、/etc/kafka、/etc/zookeeper、/etc/hive/conf以及Cloudera Manager的agent配置文件/etc/cloudera-scm-agent/config.ini。打包成tar后转移到单独存储。做完备份之后还要做一次备份的恢复预演。这个预演不一定要全部恢复但至少要验证备份文件能正常解压、能被数据库工具识别读取。我见过太多人做完备份就以为万事大吉等真正需要恢复时才傻眼——备份文件是0字节。3.2 新机房机器上架与基础环境初始化新机房节点的上架不是直接把服务器插上电就完事了基础环境的初始化步骤建议全部脚本化避免手工操作遗漏。基础环境初始化的核心动作包括设置主机名确保主机名与规划中的一致不要出现两个节点主机名重复的乌龙配置/etc/hosts把所有节点的IP和主机名映射写进去这里要用一个Ansible脚本或Shell循环推送别手动逐台编辑设置磁盘挂载检查新机器的数据盘是否全部识别并按之前的挂载路径做好分区和格式化。CDH对DataNode的数据目录要求是一个物理磁盘最好不要挂两个以上的数据目录否则磁盘IO会成为瓶颈安装基础依赖CDH依赖的JDK版本、Python版本、必要的系统包比如libaio、unzip、ntpdate都要提前装好同步时钟这是一个容易被忽略但足以引发大事故的环节。ZooKeeper、Kerberos如果启用都对时钟偏移有严格要求。建议部署好NTP服务并确认所有节点的时间源一致特别要提一下磁盘格式化的小细节有些新机房的机器是老机器硬盘可能有坏道或者smart信息异常。上架后第一时间跑一次badblocks -sv或者smartctl -t short做磁盘健康检查。这块不用省时间因为一旦数据写进去之后才知道盘有问题那就得靠HDFS副本恢复既费时间又伤性能。3.3 服务启停顺序与CM配置调整搬迁完成后服务的启动顺序要严格遵循依赖关系。我的经验是分四层依次启动第一层ZooKeeper。作为整个集群的协调大脑ZooKeeper必须先起来。等ZooKeeper三个或五个节点全部进入healthy状态后再做下一步。第二层HDFS和YARN。启动HDFS时先起JournalNode再起NameNode最后起DataNode和ZKFC如果启用了HA。通过CM的启动按钮操作时CM会自己处理顺序但如果是手动脚本启停顺序一定要对。NameNode起来后确认Active/Standby状态正常再启动YARN的ResourceManager和NodeManager。第三层Hive、HBase、Kafka等上层服务。这些服务依赖HDFS和ZooKeeper所以必须等前两层完全稳定后再启动。HBase依赖HDFS和ZooKeeper而Kafka需要ZooKeeper来选主。第四层业务调度平台和实时任务。包括Spark、Flink、DolphinScheduler、Airflow等任务调度层以及各类自研的微服务。如果集群启用了Kerberos还要额外注意顺序先启动KDC服务确保每个节点都能正常认证再启动ZooKeeper。Kerberos环节最容易出问题因为KDC的时钟偏差限制是5分钟默认而刚搬迁后的服务器如果NTP同步不准确很容易出现认证失败。还有一点IP变更后CM Agent和Server之间的通信会基于域名解析来建立。如果旧配置里写死了IP在CM页面上就会出现主机失联。此时不要急着重新安装Agent先去检查Agent的config.ini和/etc/hosts是否已经更新再重启cloudera-scm-agent服务。3.4 数据校验与业务联调服务全部启动之后不要急着对外宣布搬迁完成。数据校验这一步做得越细事后被业务找上门的概率就越低。校验分几层来做第一层HDFS层面。用hdfs fsck / -files -blocks -locations检查整个文件系统是否有缺失的块每个文件的副本数是否达到配置要求。这个命令可能比较耗时但值得跑一次因为物理搬迁中硬盘上的数据虽然整体是完整的但也可能有个别副本在搬运中损坏。如果发现有Missing replica就先别放业务进来排查是哪台节点上的副本丢了必要时用hdfs debug recoverLease -path做修复或者设置dfs.replication重新复制。第二层Hive层。抽查几个核心业务库的表执行show partitions和select count(*)确认元数据和实际数据是一致的。这里有一个坑如果Hive表是外部表元数据里记录的是HDFS路径搬迁后路径不变才没有影响如果路径变了必须用alter table修改表位置。第三层实时链路。启动Kafka消费者观察topic的--from-beginning消费是否正常然后往生产端发送测试消息确认消费端能收到。如果是通过MirrorMaker做的迁移还要检查MM的Lag指标是不是归零。第四层业务层面。让业务方先做一轮冒烟挑几条核心链路比如日报表、实时大屏、核心API跑一下。注意业务侧测试建议在专门的测试账号或测试环境下进行不要在正式库里直接写数据避免产生脏数据。数据校验完成后还需要检查CM页面上有没有新的健康告警。重点看HDFS容量使用率、DataNode心跳是否正常、副本数是否异常、YARN队列资源是否合理。确认这些都没问题才能算真正意义上的搬迁完成。4. 常见问题与排查技巧实录4.1 CM Server起不来数据库连接错乱是第一嫌疑有一次搬迁新机房上电后CM Server怎么都起不来日志里报的是数据库连接超时。排查了一圈才发现CM Server配置里指向的数据库IP还是旧机房的但旧机房已切了网络无法访问。这里的教训是如果CM使用的数据库也是集群内的节点之一搬迁前一定要确认CM Server的db.properties是否指向了新的数据库地址。处理方式很简单修改/etc/cloudera-scm-server/db.properties中的数据库主机名然后重启cloudera-scm-server服务。如果使用外部数据库比如独立的MySQL要同步更新/etc/cloudera-scm-server/db.properties和MySQL的授权账号host限制把新节点IP加进远程访问白名单。4.2 主机名/IP变更后的配置残留CDH集群最讨厌的一点是各种配置会缓存在Agent节点上。即使你在CM页面上修改了主机名或者使用新的IP重新添加主机旧配置也可能残留在/etc/hadoop/conf等目录下。常见的情景是服务能启动但YARN的NodeManager连不上ResourceManagerHBase的RegionServer连不上Master报错全是连接超时。解决思路分三步先在CM页面主机菜单里确认所有主机的IP已更新再在每台节点上执行cloudera-manager-agent的reset操作service cloudera-scm-agent stop rm -rf /var/lib/cloudera-scm-agent/* service cloudera-scm-agent start最后到CM的所有服务页面执行一次重新部署客户端配置把最新配置下发到所有节点。注意删除/var/lib/cloudera-scm-agent/*这个操作会清掉Agent本地的缓存和证书之后Agent会向Server重新注册属于正常现象。4.3 HDFS块缺失别慌先定位再修复物理搬迁后跑hdfs fsck报出一堆Missing block是很正常的。原因可能有两种一是某台DataNode在搬运中损坏了某块磁盘导致部分block的所有副本都丢了二是搬过去的新机器磁盘挂载路径变了DataNode启动后找不到原来的数据目录。如果是第一种情况先检查是否有其他副本存活如果一份副本都没有只能看数据本身是否还有备份没有的话就只能认栽。如果是第二种情况处理方式是修改dfs.datanode.data.dir让它指向新挂载的路径然后重启DataNode。重启后DataNode会重新扫描目录并上报块信息原本看起来缺失的块会自动恢复。还有一种场景DataNode能上报块但NameNode在safeMode下不允许副本复制。这时候可以用hdfs dfsadmin -safemode leave退出安全模式让它触发副本复制任务。注意如果只是短暂的块复制不必惊慌若是安全的缺失建议等到副本数恢复后再执行大规模任务。4.4 时钟和Kerberos排查了一整天才找到的元凶搬迁后出现ZooKeeper连接断开或Kerberos认证失败很多时候不是网络问题而是系统时间偏差超过了认证阈值。有一次我们排查一个跨机房同步任务在迁移后无论如何都鉴权失败最终发现是Agent节点重启后NTP没有生效时钟偏差了7分钟刚好超过Kerberos默认的5分钟容错范围。排查方法很简单在所有节点上执行date如果发现节点间时间差异超过10秒就应该立即调整ntpdate -u your.ntp.server service ntpd restart同时检查/etc/ntp.conf里的server配置是否指向了当前机房可用的NTP节点。高可用集群中ZooKeeper对时间偏差也很敏感偏差过大可能导致Leader频繁切换引发连锁故障。把所有节点的时钟对齐之后再重启ZooKeeper和Kerberos相关服务问题通常就能解决。4.5 搬迁后磁盘容量凭空缩小的检查方向这种情况比较隐蔽但遇到过的人会印象深刻搬迁前集群HDFS还剩20%空间搬迁后业务还没跑多久就报磁盘不足。排查到最后往往不是因为数据量真的變大而是新机器的数据盘分区方案和原来不一致——原来每块盘8TB新机器上挂着同样的8TB盘但DataNode只识别了其中一部分分区。检查命令hdfs dfsadmin -report重点看每台DataNode的DFS Used和DFS Remaining是否均衡。如果发现某台节点的容量明显比别人少了一半大概率是dfs.datanode.data.dir配置里的挂载路径有问题或者新增的数据盘没有被正确格式化并挂载。修改配置后重启DataNode容量就会恢复。写在最后的一个建议CDH集群机房搬迁本质不是一场搬运而是一场验证。验证你对集群的了解程度、验证你团队的应急能力、验证你们对业务依赖关系的掌握。我每次搬迁完最大的感触不是终于搞定了而是原来我对这套集群还有这么多盲区。如果你现在正面临搬迁任务我的建议只有一句话把时间往前挪。前期花一周做详细的摸底和方案讨论比现场通宵抢救要划算得多。把本文里的备份清单、启动顺序、校验步骤整理成自己的checklist逐条打勾执行机房里出大问题的概率就会低很多。最后无论方案多完美一定留一个回退窗口。别把旧机房的环境立刻清空至少保留三天给新环境一个充分的观察期。