Uber 容器化 Apache Hadoop 基础设施的实行
发布时间：2021-11-29 11:17:57 所属栏目：大数据 来源：互联网
导读：随着 Uber 的业务持续增长，我们用了 5 年时间扩展 Apache Hadoop（本文中称为Hadoop），部署到了 21000 多台主机上，以支持多种分析和机器学习用例。我们组建了一支拥有多样化专业知识的团队来应对在裸金属服务器上运行 Hadoop 所面临的各种挑战，这些挑战包
|
随着 Uber 的业务持续增长，我们用了 5 年时间扩展 Apache Hadoop（本文中称为“Hadoop”），部署到了 21000 多台主机上，以支持多种分析和机器学习用例。我们组建了一支拥有多样化专业知识的团队来应对在裸金属服务器上运行 Hadoop 所面临的各种挑战，这些挑战包括：主机生命周期管理、部署和自动化，Hadoop 核心开发以及面向客户的门户。 随着 Hadoop 基础设施的复杂性和规模越来越大，团队越来越难以应对管理如此庞大系统时需要承担的各种职责。基于脚本和工具链的全系统规模运营工作消耗了大量的工程时间。损坏的主机越来越多，修复工作逐渐跟不上节奏。 在我们继续为 Hadoop 维护自己的裸金属部署时，公司的其他部门在微服务领域取得了重大进展。容器编排、主机生命周期管理、服务网格和安全性等领域的解决方案逐渐成型，让微服务管理起来更加高效和简便。 2019 年，我们开始了重构 Hadoop 部署技术栈的旅程。两年时间过去了，如今有超过 60% 的 Hadoop 运行在 Docker 容器中，为团队带来了显著的运营优势。作为这一计划的成果之一，团队将他们的许多职责移交给了其他基础设施团队，并且得以更专注于核心 Hadoop 的开发工作。 图 1：团队职责转移 本文总结了这一过程中我们面临的各种问题，以及我们解决这些问题的方法和途径。 回顾过去 在具体分析架构之前，有必要简要介绍一下我们之前运维 Hadoop 的方法及其缺陷。彼时，几个互相分离的解决方案协同工作，驱动 Hadoop 的裸金属部署。这些方案包括： 让主机设置就地突变的自动化方案 手动触发和监控，基于非幂等动作的脚本 松散耦合的主机生命周期管理解决方案 在底层，它们是通过几个 Golang 服务、大量 Python 和 Bash 脚本、Puppet 清单和一些 Scala 代码实现的。早期我们使用了 Cloudera Manager（免费版）并评估了 Apache Ambari。然而，由于 Uber 使用了自定义部署模型，这两个系统都被证明是不够用的。 我们旧的运维方法遇到了一些挑战，包括但不仅限于以下方面： 生产主机的手动就地突变导致了许多漂移，后来这让我们感到很惊讶。工程师经常就部署过程发生争论，因为在事件响应期间某些更改没有经过审查和识别。 全系统范围的更改需要漫长的时间来做手动计划和编排。我们上次的操作系统升级被推迟了，最终花了 2 年多的时间才完成。 几个月后，管理不善的配置导致了诸多事故。我们错误地配置了 dfs.blocksize，最终导致我们的一个集群中的 HDFS RPC 队列时间降级。 自动化与人类交互之间缺乏良好的契约，这会导致一些意想不到的严重后果。由于一些主机意外退役，我们丢失了一些副本。 “宠物”主机 的存在和越来越多的“宠物”所需的人工处理过程导致了一些影响严重的事件。我们的一次 HDFS NameNode 迁移引发了一起影响整个批处理分析栈的事件。 我们在重构期间仔细考虑了从以前的经验中吸取的各种教训。  架 构 开始设计新系统时，我们遵循以下原则： 对 Hadoop 核心的更改应该保持在最低水平，以免同开源代码分道扬镳（例如用于安全性的 Kerberos） Hadoop 守护进程必须容器化，以实现不可变和可重复的部署 必须使用声明性概念（而不是基于动作的命令式模型）来建模集群运维 集群中的任何主机都必须在发生故障或降级时易于更换 应尽可能重用和利用 Uber 内部的基础设施，以避免重复 以下部分详细介绍了定义新架构的一些关键解决方案。 （编辑：辽源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |