心态的转变
自从 Hadoop 于 2016 年首次部署在生产环境中以来 ， 我们已经开发了很多（100 多个）松散耦合的 python 和 bash 脚本来运维集群 。 重新构建 Hadoop 的自动化技术栈意味着我们要重写所有这些逻辑 。 这一过程意味着重新实现累积超过 4 年的逻辑 ， 同时还要保证系统的可扩展性和可维护性 。
对 21,000 多台 Hadoop 主机大动干戈以迁移到容器化部署 ， 同时放弃正常运维多年的脚本积累 ， 这样的方案在一开始招致了不少怀疑声 。 我们开始将该系统用于没有 SLA 的新的开发级集群 ， 然后再用于集成测试 。 几个月后 ， 我们开始向我们的主要集群（用于数据仓库和分析）添加 DataNodes 和 NodeManagers ， 并逐渐建立了信心 。
我们通过一系列内部演示和编写良好的运行手册帮助其他人学会使用新系统之后 ， 大家开始意识到了转移到容器化部署的好处 。 此外 ， 新架构解锁了旧系统无法支持的某些原语（提升效率和安全性） 。 团队开始认可新架构的收益 。 很快 ， 我们在新旧系统之间架起了几个组件 ， 以搭建一条从现有系统到新系统的迁移路径 。
搬运猛犸象
我们新架构采用的原则之一是机群中的每一台主机都必须是可更换的 。 由旧架构管理的可变主机积累了多年的技术债务（陈旧的文件和配置） 。 作为迁移的一部分 ， 我们决定重新镜像我们机群中的每台主机 。
目前 ， 自动化流程在编排迁移时需要的人工干预是极少的 。 宏观来看 ， 我们的迁移流程是一系列 Cadence 活动 ， 迭代大量节点 。 这些活动执行各种检查以确保集群稳定 ， 并会智能地选择和停用节点 ， 为它们提供新配置 ， 并将它们添加回集群 。
完成迁移任务的最初预期时间是 2 年以上 。 我们花了大量时间调整我们的集群 ， 以找到一个尽量提升迁移速度 ， 同时不会损害我们 SLA 的甜点 。 在 9 个月内 ， 我们成功迁移了约 60%（12,500/21,000 台主机） 。 我们正走在快车道上 ， 预计在接下来的 6 个月内完成大部分机群迁移工作 。
图 9：在大约 7 天内迁移 200 多台主机
要记住的伤疤
如果我们声称我们的迁移非常平滑 ， 那肯定是在撒谎 。 迁移的初始阶段非常顺利 。 然而 ， 当我们开始迁移对更改更敏感的集群时 ， 发现了很多意想不到的问题 。
丢失块和添加更多防护措施
我们的一个最大的集群有多个运维工作流同时执行 。 一个集群范围的 DataNode 升级与集群另一部分发生的迁移一起触发了 NameNode RPC 延迟的降级 。 后来发生了一系列意外事件 ， 我们最后输掉了战斗 ， 导致集群中丢失了一些块 ， 我们不得不从另一个区域恢复它们 。 这迫使我们为自动化和运维程序设置了更多的防护措施和安全机制 。
使用目录遍历进行磁盘使用统计
集群管理器代理定期执行磁盘使用情况统计以备使用率分析 ， 并将其提供给公司范围的效率计划 。 不幸的是 ， 该逻辑意味着“遍历”存储在 DataNode 上的 24x4TB 磁盘上的所有 HDFS 块 。 这导致了大量的磁盘 i/o 。 它不会影响我们不太忙的集群 ， 但对我们最繁忙的一个集群产生了负面影响 ， 增加了 HDFS 客户端读 / 写延迟 ， 这促使我们增强了这一逻辑 。
要点和未来计划
在过去 2 年中 ， 我们对 Hadoop 的运行方式做出了巨大的改变 。 我们升级了我们的部署 ， 从一大堆脚本和 Puppet 清单转向了在 Docker 容器中运行大型 Hadoop 生产集群 。

• 塑化剂对孩子健康有什么影响
• 淘宝卖手办需要营业执照吗？如何优化？
• 9岁有赞发布数字化转型“10大观察”
• 宝宝肠胃不好，总是消化不良，也长不胖，该怎么办？
• 淘宝店铺涨价怎么回事？怎样优化价格？
• 发力“农研”的拼多多，正寻求电商领域的差异化发展路线
• 深蹲可以瘦腿吗？每天深蹲200个，坚持3个月会产生什么变化？
• 安利空气净化器排名 中国空气净化器排名
• 小狗身体强酸强碱化学物质的来源于
• 聚合新兴市场本地化支付，Grepay服务B2C客户跨境收单需求