Uber 容器化 Apache Hadoop 基础设施的实践( 二 ) _信息快讯

对 Hadoop 核心的更改应该保持在最低水平，以免同开源代码分道扬镳（例如用于安全性的 Kerberos）
Hadoop 守护进程必须容器化，以实现不可变和可重复的部署
必须使用声明性概念（而不是基于动作的命令式模型）来建模集群运维
集群中的任何主机都必须在发生故障或降级时易于更换
应尽可能重用和利用 Uber 内部的基础设施，以避免重复
以下部分详细介绍了定义新架构的一些关键解决方案。
集群管理
我们之前使用命令式、基于动作的脚本来配置主机和运维集群的方法已经到了无以为继的地步。鉴于负载的有状态（HDFS）和批处理（YARN）性质，以及部署运维所需的自定义部分，我们决定将 Hadoop 纳入 Uber 的内部有状态集群管理系统。
集群管理系统通过几个基于通用框架和库构建的松散耦合组件来运维 Hadoop 。下图代表了我们今天所用的架构的简化版本。黄色组件描述了核心集群管理系统，而绿色标记的组件代表了专门为 Hadoop 构建的自定义组件。

文章插图

图 2：集群管理架构
集群管理员（Cluster Admin）与集群管理器界面（Cluster Manager Interface）Web 控制台交互，来触发对集群的运维操作。管理员的意图被传播到集群管理器（Cluster Manager）服务，然后触发突变集群目标状态（Goal State）的 Cadence 工作流。
集群管理（Cluster Management）系统维护预配置的主机，称为托管主机（Managed Hosts）。一个节点（Node）代表一组部署在一个托管主机上的 Docker 容器。目标状态定义了集群的整个拓扑结构，包括节点位置信息（主机位置）、集群到节点的归属、节点资源（CPU、内存、磁盘）的定义及其环境变量。一个持久数据存储负责存储目标状态，使集群管理系统可以从非常严重的故障中快速恢复。
我们非常依赖 Uber 开发的开源解决方案 Cadence 来编排集群上的状态变化。 Cadence 工作流负责所有运维操作，诸如添加或停用节点、升级整个队列中的容器等等。 Hadoop 管理器（Hadoop Manager）组件定义了所有工作流。
集群管理器（Cluster Manager）不了解 Hadoop 的内部运维操作以及管理 Hadoop 基础设施的复杂性。 Hadoop 管理器实现了自定义逻辑（类似于 K8s Custom Operator），以在 Hadoop 的运维范围内以安全的方式管理 Hadoop 集群和模型工作流。例如，我们所有的 HDFS 集群都有两个 NameNode；而 Hadoop 管理器组件内有一些相关的防护措施，例如禁止同时重启这两个 NameNode 。
Hadoop Worker 是在分配给 Hadoop 的每个节点上启动的第一个代理（agent）。系统中的所有节点都在 SPIRE 注册， SPIRE 是一个开源身份管理和负载证明系统。 Hadoop Worker 组件在容器启动时使用 SPIRE 进行身份验证，并接收一个 SVID（X.509 证书）。 Hadoop Worker 使用它与其他服务通信，以获取其他配置和密钥（例如 Kerberos 密钥表）。
Hadoop 容器（Hadoop Container）代表在 Docker 容器中运行的任何 Hadoop 组件。在我们的架构中，所有 Hadoop 组件（HDFS NameNode、HDFS DataNode 等）都部署为 Docker 容器。
Hadoop Worker 定期从集群管理器中获取节点的目标状态，并在节点本地执行各种动作以实现目标状态（这是一个控制循环，也是 K8s 的核心概念）。该状态定义要启动、停止或停用的 Hadoop 容器以及其他设置。在运行 HDFS NameNode 和 YARN ResourceManager 的节点上， Hadoop Worker 负责更新“主机文件”（例如 dfs.hosts 和 dfs.hosts.exclude）。这些文件指示需要包含在集群中或从集群中排除的 DataNodes/NodeManager 主机。 Hadoop Worker 还负责将节点的实际（Actual）状态（或当前状态）回报给集群管理器。集群管理器在启动新的 Cadence 工作流时，根据实际状态和目标状态将集群收敛到定义的目标状态。

特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。