玩转Hadoop集群DNS改造

作者：李佩京
时间：2018-09-14

---

背景：

Hadoop生态系统中，集群节点间通常使用主机名（域名）来通信。目前我们的集群是使用/etc/hosts文件来做主机名和IP的映射关系。使用hosts文件的优点是简单，但一个非常显著的缺点是其维护成本会随着集群规模的扩大而变得越来越大，集群扩容时因hosts文件未同步导致的故障非常频繁。更优的方案是使用DNS来管理主机名和IP的映射关系。

解决的问题：

1. 主机名能够同时在集群内外部解析
2. 主机IP在集群内部可以反解
3. 需要兼容集群现有的基于hosts文件的主机名

详细的架构参照：http://www.yunxiaobai.net/archives/1645

操作一流程：更改resolv.conf文件

版本：V1.0

生效范围：Hadoop集群

生效日期：2018-08-01

重大调整的标准

1. 线上10%以上的机器或者模块可能会受到影响
2. 线上整体可能受到影响（如数据库，DNS缓存，DNS）

标准流程

一、责任明确：本次操作的责任人Me，操作失败承担全部责任

二、线下测试：在线下环境进行相关操作以及预案的模拟，确认影响面和风险

测试步骤：在预发环境（DEV环境）测试方案可行性

1. 备份/etc/resolv.conf文件
2. 备份namenode和计划扩容机器的/etc/hosts
3. 停止namenode和计划扩容机器上puppet服务，防止同步/etc/hosts
4. 修改namenode resolv.conf文件
5. 停止准备扩容机器的puppet服务
6. 修改准备扩容机器的resolv.conf文件
7. 使用域名申请脚本和修改主机名脚本修改准备扩容机器的主机名
8. 测试namenode和计划扩容机器是否可以正常解析域名（测试准备扩容机器的正解，反解）
9. 重启namenode和计划扩容机器的nscd服务
10. 执行扩容操作
11. 验证${HADOOP_LOG_DIR}/xx.xx.datanode.log，Datanode：查看是否有block落在上面

三、提前通告：提前在大群里面告知研发以及相关人员，（并且邮件正文需要明确说明快速回滚和紧急预案分别是什
么）

四、数据备份：在操作线上的环境前，将/etc/hosts /etc/resolv.conf文件进行全量备份，避免灾难场景下无法进行恢复

五、避开高峰期：安排在全天流量低峰时间段，即使出现问题，也不会造成重大影响

DNS改造实施操作：

准备工作：

1. 打开和配置nscd（全量）
2. 关闭puppet同步resolv.conf的策略
3. 停止puppet同步hosts的策略

修改resolv.conf文件

1. 使用ansible追加nameserver到resolv.conf（全量），追加一条自己搭建的dns nameserver
2. 测试dns解析是否正常

六、灰度发布：通过时间间隔，确保所有集群不在同一时间段内被操作而避免全局崩溃的风险

第一阶段（停留至少一小时，至多一天）：1%流量或者最多一台机器，两者取流量最小值
第二阶段（停留至少两小时，至多一天）：10%流量或者最多两台机器，两者取流量最小值
第三阶段（停留至少一小时，至多一天）：50%流量，距上次操作至少间隔两小时
第四阶段：100%流量
第五阶段：修改resolv.conf，按照计划流程修改resolv.conf文件。

标题计划流程:

占比	改造数量	备注
1%	1	namenode
10%	10	resourcemanager&journalnode&jobhistory
50%	xxx	Datanode& nodemanager
100%	xxx	Datanode& nodemanager

七、效果检查：基于业务功能和核心指标进行效果检查，不能仅仅检查错误日志和端口状态

检查点：

1. 检查dns是否解析正确
2. 配置datanode读写监控
3. 配置计算任务监控
4. 检查机器日志文件
5. 检查管理界面信息

八、监控预警：监控系统应该介入变更的全过程，从而发现潜在的问题，错误和隐患，避免问题流入线上造成重大影响

九、快速回滚：发现任何异常，应该立即基于修改内容的备份进行快速回滚，不要等待原因定位

回滚策略：

将之前旧/etc/resolv.conf文件覆盖新resolv.conf文件

十、紧急预案：基于全量的数据备份进行重建

操作二流程：删除hosts条目

版本：V1.0

生效范围：Hadoop集群

生效日期：2018-08-10

标准流程

一、责任明确

二、线下测试

测试步骤：在预发环境（DEV环境）测试方案可行性

1. 备份/etc/hosts文件
2. 备份namenode和计划扩容机器的/etc/hosts
3. 停止namenode和计划扩容机器上puppet服务，防止同步/etc/hosts
4. 停止准备扩容机器的puppet服务
5. 使用域名申请脚本和修改主机名脚本修改准备扩容机器的主机名
6. 测试namenode和计划扩容机器是否可以正常解析域名（测试准备扩容机器的正解，反解）
7. 重启namenode和计划扩容机器的nscd服务
8. 执行扩容操作
9. 验证${HADOOP_LOG_DIR}/xx.xx.datanode.log，Datanode：查看是否有block落在上面

三、通报删除hosts条目及信息

四、备份hosts文件

五、避开高峰期

六、灰度发布

第一次通过删除1条，通过ansible同步hosts文件，之后每次翻倍推进。每次操作完成后验证，间隔12小时操作。

七、效果检查

1. 检查dns是否解析正确
2. 配置datanode读写监控
3. 配置计算任务监控
4. 检查机器日志文件
5. 检查管理界面信息
6. 检查机器剩余hosts条目是否一致

八、监控预警

九、快速回滚

出现问题记录，执行回滚操作，回复之前的hosts文件

十、紧急预案

心德体会

• 域名解析工作流程: DNS client -> hosts file -> DNS Servers -> DNS Servers on the internet -> Website.
• 新建集群需要调研好一个便于维护和扩容的配置
• 针对hostname问题，可以在hdfs-site.xml文件中配置dfs.namenode.datanode.registration.ip-hostname-check为false- 取消hostname解析
• 在操作之前需要完善操作文档以及相关预案
• 文档中需要包含：备份机制、回滚机制、验证机制
• 预案中需要包含：快速止损、快速定位问题
• 操作的时候需要做到分级发布，此次改造按照分集群、分角色改造，将可能发生的故障点缩小到可控范围