同程旅行Hadoop集群跨机房迁移实践

文章目录

1 背景
2 迁移方案
- 2.1 A,增加机房感知策略
- 2.2 B,支持副本策略数据优先写入新机房
3 经验和教训
4 跨集群迁移工具改造
5 总结和未来展望

背景

随着同程旅行业务和数据规模越来越大，原有的机房不足以支撑未来几年的扩容需求，同时老机房的保障优先级也低于新机房。为了不受限于机房的压力，公司决定进行机房迁移。为了尽快完成迁移，需要1个月内完成上百PB数据量的集群迁移，迁移过程不允许停止服务。

目前HADOOP集群主要有多个2.X版本，2019年升级到联邦模式，目前有近20个namespace，80%的业务都与hdfs 相关，资源调度层主要依赖YARN集群，上游支撑数仓建设、算法分析、机器学习等多个业务板块。

迁移方案

目前同程旅行有多套HDFS集群，在新机房搭建多套HDFS集群成本和数据同步都是不小的工作量，所以这个方案刚开始就被PASS，总体迁移方案规划是单集群扩缩容的方式进行迁移。

关于数据迁移有下面2个实现方案：•机房感知策略•副本选择节点策略

A,增加机房感知策略

1、通过修改namenode核心代码，支持存储的多机房感知，增加节点的机房属性。

2、针对指定迁移的租户/目录做任务隔离搭建独立的yarn，迁移过程中充分利用HDFS本地性和减少跨机房产生的网络带宽。

3、按照目录/租户的方式进行迁移，方便控制进度和观察跨机房网络的稳定性

优点：可以细粒度的进行迁移；过程可控。

缺点：修改namenode核心代码，需要有一定时间来测试再上线；迁移周期相对比较久。

B,支持副本策略数据优先写入新机房

通过策略控制新写入的数据写到使用率比较低的DN节点（新机房节点），从生产源头进行数据转移，对于历史的数据可以通过balance指定Iplist和集群迁移的方式来加快迁移

优点：可以不依赖具体的目录/租户来迁移，可以按照机架来迁移。

缺点：新的策略对于磁盘使用过低的datanode还是可能会出现一些热点问题，需要进行改进；balance速度比较慢，满足不了快速迁移需求；会产生大量的带宽压力，高峰期可能会集群造成额外的RPC压力。

最后我们选择方案B，理由是：我们需要尽快完成迁移，而且B方案迁移流程相对比较简单，不过需要对副本选择策略做源码改造，解决datanode的热点问题，同时对于balance可以进一步做性能优化，解决可能的RPC问题。

经验和教训

DN下线过慢

刚开始datanode 下线的时候发现一组机架decommssion结束需要6H+，这个相对比较容易解决，需要做下参数优化，提高数据replication的速度，最后实现了一组机架下线时间从6个多小时到1个多小时，满足了迁移的需求。

DN数据严重不均衡

采取扩缩容策略来进行迁移不可避免的会遇到DN节点下线后，存储压力会平摊到剩下的DN节点上，继而可能出现其他问题，下面是我们遇到的几个典型的问题。

1，新写入的数据仍然会选择DN使用率比较高的节点目前同程旅行的大数据服务基本都是标准部署模式，DN服务基本和NM服务进行了同节点部署，如果新写入的数据写到了使用率比较高的DN上，可能会引发下面两个问题。

•产生DN热点，可能影响任务的读写我们的磁盘SKU相差不大，使用率比较高的节点一般会有更多的数据，可能会有更多IO操作，导致硬件出现性能瓶颈，影响到数据的正常读写。•NodeManager无法通过健康检测，会进入unhealthy状态 NM有磁盘空间检测项，一旦无法完成健康检测，服务将进入到UnHealthy状态，从可用服务列表中剔除，计算资源相应会减少。

为了解决这个问题，我们在hadoop2.5支持了基于空间策略的副本，这个策略的作用是让HDFS副本选择的时候优先考虑DN使用率比较低的DN节点（大多是新机房新上线的节点），这样数据在写入的时候就会写到新机房，减少了后续的迁移压力，不过低版本的策略有缺陷，存在出现空指针的场景,需要修复后才可以上线，同时我们也改进了源码中部分逻辑，并已贡献到hadoop社区，以便更合理的使用这个策略，可以参考下面的ISSUE。

https://issues.apache.org/jira/browse/HDFS-10715 https://issues.apache.org/jira/browse/HDFS-14578 https://issues.apache.org/jira/browse/HDFS-8131

同时我们还通过数据迁移工具来加快迁移历史数据、通过优先下线高水位节点等手段有效控制了高水位节点的比例。

2，新写入的数据会大量选择DN使用率比较低的节点

支持可用空间策略后，可以减少使用率过高的DN被写入，不过假设大量副本如果都选择到较低使用的DN，该DN有可能会成为新的“热点”，为此我们继续在源码上优化了此策略，副本选择的时候会参考DN的心跳汇报情况和线程数的情况，如果该DN过于繁忙，将不会被选择，基于新优化的可用空间策略既解决了数据过多写入到使用率比较高的DN上，也解决了数据过多写入到使用率过低的DN上引起的热点问题。

3，对于本地短路读的优化

短路读的开启充分利用了客户端和DN节点在同一个节点的优势，如果首选节点和客户端在同一个机器，那么pipeline很大可能会选择这个节点作为pipeline的第一个，数据写完本地后，然后按照副本选择策略去选择剩下的副本，我们在源码中改造了这块逻辑，在首选DN节点压力比较大时，可以不选择该DN节点，去选择更优的DN节点。

balance是把双刃剑

1，封装balance程序 Balance程序默认会把所有节点纳入balance list,然后进行节点筛选，对不满足threshold的DN做balance,但是实际上我们更期望把一些使用率比较高的DN作为source,使用率比较低的DN作为destination,所以我们重新封装了Balance程序，支持按照指定IP的方式进行数据均衡，减少“无效”节点参与均衡占用宝贵的线程资源和RPC。

2，balance程序支持按照文件大小运行同时过程中我们发现即使很少的文件都要占用一个线程和RPC去操作，这些比较小的文件对整体数据迁移起的作用不大，所以支持Balance过程中指定需要均衡的文件大小，优化后balance效率提升一倍，社区也在讨论默认balance的时候支持这种场景。