服务热线:
0531-87438999
您的位置: 主页 > 溜溜直播新闻 > 公司新闻 >

溜溜直播买球Uber 容器化 Apache Hadoop 基础设施的实

发布日期:2022-01-08 18:03   浏览量:

  跟着 Uber 的营业连续增加,我们用了 5 年工夫扩大 Apache Hadoop(本文中称为“Hadoop”),溜溜直播首页布置到了 21000 多台主机上,以撑持多种阐发和机械进修用例。我们组建了一支具有多样化专业常识的团队来应对在裸金属效劳器上运转 Hadoop 所面对的各类应战,这些应战包罗:主机性命周期办理、布置和主动化,Hadoop 中心开辟和面向客户的流派。

  跟着 Hadoop 根底设备的庞大性和范围愈来愈大,团队愈来愈难以应对办理云云宏大体系时需求负担的各类职责。基于剧本和东西链的部分系范围运营事情耗损了大批的工程工夫。破坏的主机愈来愈多,修复事情逐步跟不上节拍。

  在我们持续为 Hadoop 保护本人的裸金属布置时,公司的其他部分在微效劳范畴获得了严重停顿。容器编排、主机性命周期办理、效劳网格和宁静性等范畴的处理计划逐步成型,让微效劳办理起来愈加高效和烦琐。

  2019 年,我们开端了重构 Hadoop 布置手艺栈的路程。两年工夫已往了,现在有超越 60% 的 Hadoop 运转在 Docker 容器中,为团队带来了明显的运营劣势。作为这一方案的功效之一,团队将他们的很多职责移交给了其他根底设备团队,而且得以更专注于中心 Hadoop 的开辟事情。

  在详细阐发架构之前,有须要扼要引见一下我们之前运维 Hadoop 的办法及其缺点。彼时,几个相互别离的处理计划协同事情,驱动 Hadoop 的裸金属布置。这些计划包罗:

  在底层,它们是经由过程几个 Golang 效劳、大批 Python 和 Bash 剧本、Puppet 清单和一些 Scala 代码完成的。晚期我们利用了 Cloudera Manager(免费版)并评价了 Apache Ambari。但是,因为 Uber 利用了自界说布置模子,这两个别系都被证实是不敷用的。

  部分系范畴的变动需求冗长的工夫来做手动方案和编排。我们前次的操纵体系晋级被推延了,终极花了 2 年多的工夫才完成。

  几个月后,办理不善的设置招致了诸多变乱。我们毛病地设置了 dfs.blocksize,终极招致我们的一个集群中的 HDFS RPC 行列工夫升级。

  主动化与人类交互之间缺少优良的左券,这会招致一些意想不到的严峻结果。因为一些主机不测退役,我们丧失了一些副本。

  “宠物”主机 的存在和愈来愈多的“宠物”所需的野生处置历程招致了一些影响严峻的变乱。我们的一次 HDFS NameNode 迁徙激发了一同影响全部批处置阐发栈的变乱。

  我们之前利用号令式、基于行动的剧本来设置主机和运维集群的办法曾经到了无觉得继的境界。鉴于负载的无形态(HDFS)和批处置(YARN)性子,和布置运维所需的自界说部门,我们决议将 Hadoop 归入 Uber 的内部无形态集群办理体系。

  集群办理体系经由过程几个基于通用框架和库构建的松懈耦合组件来运维 Hadoop。下图代表了我们明天所用的架构的简化版本。组件形貌了中心集群办理体系,而绿色标识表记标帜的组件代表了特地为 Hadoop 构建的自界说组件。

  集群办理(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 Worker 按期从集群办理器中获得节点的目的形态,并在节点当地施行各类行动以完成目的形态(这是一个掌握轮回,也是 K8s 的中心观点)。该形态界说要启动、截至或停用的 Hadoop 容器和其他设置。在运转 HDFS NameNode 和 YARN ResourceManager 的节点上,Hadoop Worker 卖力更新“主机文件”(比方 dfs.hosts 和 dfs.hosts.exclude)。这些文件唆使需求包罗在集群中或从集群中解除的 DataNodes/NodeManager 主机。Hadoop Worker 还卖力将节点的实践(Actual)形态(或当前形态)报答给集群办理器。集群办理器在启动新的 Cadence 事情流时,按照实践形态和目的形态将集群收敛到界说的目的形态。

  一个与集群办理器优良集成的体系卖力连续检测主机成绩。集群办理器能做出许多智能决议计划,比方限定速度以免同时停用过量的破坏主机。Hadoop 办理器在采纳任何动作之前会确保集群在差别的体系变量下都是安康的。Hadoop 办理器中包罗的查抄可确保集群中不存在丧失或复制不敷的块,而且在运转枢纽运维操纵之前确保数据在 DataNode 之间连结平衡,并施行其他须要查抄。

  利用声明式运维模子(利用目的形态)后,我们削减了运维集群时的野生操纵。一个很好的例子是体系能够主动检测到破坏主机并将其宁静地从集群中停用以待修复。每退役一台破坏主机,体系城市弥补一个新主机来连结集群容量稳定(保持目的形态中所界说的容量)。

  下图显现了因为各类成绩在一周工夫段内的各个工夫点退役的 HDFS DataNode 数目。每种色彩描画了一个 HDFS 集群。

  在已往,我们根底设备的内涵可变性曾屡次给我们带来了意想不到的费事。有了新架构后,我们得以在不成变 Docker 容器中运转一切 Hadoop 组件(NodeManager、DataNode 等)和 YARN 使用法式。

  YARN NodeManager 运转在主机上的 Docker 容器中。主机 Docker 套接字挂载到 NodeManager 容器,利用户的使用法式容器可以作为兄弟容器启动。这绕过了运转 Docker-in-Docker 会引入的一切庞大性,并使我们可以在不影响客户使用法式的状况下办理 YARN NodeManager 容器的性命周期(比方 重启)。

  在使用法式容器启动时期拉取 Docker 镜像会发生分外的开消,这能够会 招致超时。为了躲避这个成绩,我们经由过程 Kraken 分发 Docker 镜像。Kraken 是一个最后在 Uber 内部开辟的开源点对点 Docker 注册表。我们在启动 NodeManager 容器时预取默许使用法式 Docker 镜像,从而进一步优化了设置。这可确保在恳求进入之前默许使用法式 Docker 镜像是可用的,以启动使用法式容器。

  一切 Hadoop 容器(DataNode、NodeManager)都利用卷挂载(volume mount)来存储数据(YARN 使用法式日记、HDFS 块等)。这些卷在节点放在托管主机上时可用,并在节点从主机退役 24 小时后删除。

  在迁徙过程当中,我们逐步让使用转向利用默许 Docker 镜像启动。我们另有一些客户利用了自界说 Docker 镜像,这些镜像让他们可以带来本人的依靠项。经由过程容器化 Hadoop,我们经由过程不成变布置削减了可变性和堕落的概率,并为客户供给了更好的体验。

  我们一切的 Hadoop 集群都由 Kerberos 卖力宁静性。集群中的每一个节点都需求在 Kerberos(中 注册 主机特定效劳主体 Principal(身份)。在启动任何 Hadoop 保式之前,需求天生响应的密钥表(Keytab)并将其宁静地发送到节点。

  很较着,SPIFFE 和 Kerberos 都用的是它们本人共同的身份考证和谈,其身份和负载证实具有差别的语义。在 Hadoop 中从头毗连全部宁静模子以共同 SPIRE 并非一个可行的处理计划。我们决议同时操纵 SPIRE 和 Kerberos,相互之间没有任何交互 / 穿插证实。

  这简化了我们的手艺处理计划,计划中触及以下主动化步调序列。我们“信赖”集群办理器和它为从集群中增加 / 删除节点而施行的目的形态运维操纵。

  普通来讲,野生干与会招致密钥表办理不善,从而毁坏体系的宁静性。经由过程上述设置,Hadoop Worker 由 SPIRE 停止身份考证,Hadoop 容器由 Kerberos 停止身份考证。上述全部历程是端到真个主动化,无需野生到场,确保了更严厉的宁静性。

  在 YARN 中,散布式使用法式的容器作为提交使用法式的用户(或效劳帐户)运转。用户组(UserGroup)在举动目次(Active Directory,AD)中办理。我们的旧架构需求经由过程 Debian 包装置用户组界说(从 AD 天生)的按期快照。这招致了部分系范畴的不分歧征象,这类不分歧是由包版本差别和装置失利惹起的。

  未被发明的不分歧征象会连续数小时到数周,直到影响用户为止。在已往 4 年多的工夫里,因为跨主机的用户组信息不分歧激发的权限成绩和使用法式启动失利,让我们碰到了很多费事。别的,这还招致了大批的手动调试和修复事情。

  Docker 容器中 YARN 的用户组办理本身存在一系列 手艺应战。保护另外一个保护历程 SSSD(如 Apache 文档中所倡议的)会增长团队的开消。因为我们正在从头构建全部布置模子,因而我们破费了分外的精神来设想和构建用于用户组办理的不变体系。

  我们的设想是操纵一个颠末内部强化、诺言优良的设置分发体系(Config Distribution System)将用户组界说中继到布置 YARN NodeManager 容器的一切主机上。NodeManager 容器运转用户组历程(UserGroups Process),该历程察看用户组界说(在设置分发体系内)的变动,并将其写入一个卷挂载,该挂载与一切使用法式容器(Application Container)以只读方法同享。

  使用法式容器利用一个自界说 NSS 库(内部开辟并装置在 Docker 镜像中)来查找用户组界说文件。有了这套处理计划,我们可以在 2 分钟内完成用户组在部分系范畴内的分歧性,从而为客户明显进步牢靠性。

  我们运营着 40 多个效劳于差别用例的集群。在旧体系中,我们在单个 Git 存储库中自力办理每一个集群的设置(每一个集群一个目次)。成果复制粘贴设置和办理跨多个集群的布置变得愈来愈艰难。

  我们将模板和 Starlark 文件中统共 66,000 多行的 200 多个.xml 设置文件削减到了约 4,500 行(行数削减了 93% 以上)。究竟证实,这类新设置对团队来讲更具可读性和可办理性,特别是由于它与集群办理体系集成得更好了。别的,该体系被证实有益于为批处置阐发栈中的其他相干效劳(比方 Presto)主动天生客户端设置。

  在从前,将 Hadoop 掌握平面(NameNode 和 ResourceManager)挪动到差别的主机不断是很费事的操纵。这些迁徙凡是会招致全部 Hadoop 集群转动重启,还需求与很多客户团队和谐以重启相干效劳,由于客户端要利用主机名来发明这些节点。更蹩脚的是,某些客户端偏向于缓存主机 IP 而且不会在呈现毛病时从头剖析它们——我们从一次严重变乱中学到了这一点,该变乱让全部地区批处置阐发栈升级了。

  Uber 的微效劳和在线存储体系在很大水平上依靠于内部开辟的效劳网格来施行发明和路由使命。Hadoop 对效劳网格的撑持远远落伍于其他 Apache 项目,比方 Apache Kafka。Hadoop 的用例和将其与内部效劳网格集成所触及的庞大性没法满意工程事情的投资报答率目的。取而代之的是,我们挑选操纵基于 DNS 的处理计划,并方案将这些变动逐渐奉献回开源社区(HDFS-14118、HDFS-15785)。

  我们有 100 多个团队天天都在与 Hadoop 交互。他们中的大大都都在利用过期的客户端和设置。为了进步开辟职员的消费力和用户体验,我们正在对全部公司的 Hadoop 客户端停止尺度化。作为这项事情的一部门,我们正在迁徙到一其中间化设置管了解决计划,此中客户无需为初始化客户端指定典范的*-site.xml 文件。

  操纵上述设置天生体系,我们可以为客户端天生设置并将设置推送到我们的内部设置分发体系。设置分发体系以可控和宁静的方法在全部体系范畴内布置它们。效劳 / 使用法式利用的 Hadoop 客户端将从主机当地设置缓存(Config Cache)中获得设置。

  尺度化客户端(具有 DNS 撑持)和中间化设置从 Hadoop 客户那边完整笼统出了发明和路由操纵。别的,它还供给了一组丰硕的可察看性目标和日记记载,让我们能够更轻松地停止调试。这进一步改进了我们的客户体验,并使我们可以在不中止客户使用法式的状况下轻松办理 Hadoop 掌握平面。

  自从 Hadoop 于 2016 年头次布置在消费情况中以来,我们曾经开辟了许多(100 多个)松懈耦合的 python 和 bash 剧本来运维集群。从头构建 Hadoop 的主动化手艺栈意味着我们要重写一切这些逻辑。这一历程意味偏重新完成积累超越 4 年的逻辑,同时还要包管体系的可扩大性和可保护性。

  对 21,000 多台 Hadoop 主机大动兵戈以迁徙到容器化布置,同时抛却一般运维多年的剧本积聚,如许的计划在一开端招致了很多疑心声。我们开端将该体系用于没有 SLA 的新的开辟级集群,然后再用于集成测试。几个月后,我们开端向我们的次要集群(用于数据堆栈和阐发)增加 DataNodes 和 NodeManagers,并逐步成立了自信心。

  我们经由过程一系列内部演示和编写优良的运转手册协助其别人学会利用新体系以后,各人开端意想到了转移到容器化布置的益处。别的,新架构解锁了旧体系没法撑持的某些原语(提拔服从和宁静性)。团队开端承认新架构的收益。很快,我们在新旧体系之间架起了几个组件,以搭建一条从现有体系到新体系的迁徙途径。

  我们新架构接纳的准绳之一是机群中的每台主机都必需是可改换的。由旧架构办理的可变主机积聚了多年的手艺债权(陈腐的文件和设置)。作为迁徙的一部门,我们决议从头镜像我们机群中的每台主机。

  今朝,主动化流程在编排迁徙时需求的野生干涉是少少的。宏观来看,我们的迁徙流程是一系列 Cadence 举动,迭代大批节点。这些举动施行各类查抄以确保集群不变,并会智能地挑选和停用节点,为它们供给新设置,并将它们增加回集群。

  完成迁徙使命的最后预期工夫是 2 年以上。我们花了大批工夫调解我们的集群,以找到一个只管提拔迁徙速率,同时不会损伤我们 SLA 的甜点。在 9 个月内,我们胜利迁徙了约 60%(12,500/21,000 台主机)。我们正走在快车道上,估计在接下来的 6 个月内完成大部门机群迁徙事情。

  假如我们宣称我们的迁徙十分光滑,那必定是在扯谎。迁徙的初始阶段十分顺遂。但是,当我们开端迁徙对变动更敏感的集群时,发明了许多意想不到的成绩。

  我们的一个最大的集群有多个运维事情流同时施行。一个集群范畴的 DataNode 晋级与集群另外一部门发作的迁徙一同触发了 NameNode RPC 提早的升级。厥后发作了一系列不测变乱,我们最初输掉了战役,招致集群中丧失了一些块,我们不能不从另外一个地区规复它们。这迫使我们为主动化和运维法式设置了更多的防护步伐和宁静机制。

  集群办理器署理按期施行磁盘利用状况统计以备利用率阐发,并将其供给给公司范畴的服从方案。不幸的是,该逻辑意味着“遍历”存储在 DataNode 上的 24x4TB 磁盘上的一切 HDFS 块。这招致了大批的磁盘 i/o。它不会影响我们不太忙的集群,但对我们最忙碌的一个集群发生了负面影响,增长了 HDFS 客户端读 / 写提早,这促使我们加强了这一逻辑。

  在已往 2 年中,我们对 Hadoop 的运转方法做出了宏大的改动。我们晋级了我们的布置,从一大堆剧本和 Puppet 清单转向了在 Docker 容器中运转大型 Hadoop 消费集群。

  从剧本和东西过渡到经由过程成熟的 UI 运维 Hadoop,是团队的严重文明改变。我们花在集群运维上的工夫削减了 90% 以上。我们让主动化操纵掌握来全部体系的运维、改换破坏主机。我们不再让 Hadoop 来办理我们的工夫了。

  假如没有先辈的杰出运维手艺,Hadoop 能够会酿成一个难以征服的庞然大物。构造该当按期从头评价布置架构并按期归还手艺债权,免得亡羊补牢。

  大范围根底设备的重构需求工夫。构造该当为此成立壮大的工程团队,专注于前进而不是寻求完善,并随时筹办好对付消费情况中呈现的成绩。

  感激一切到场各个架构团队的工程师,我们的架构十分稳定。倡议与 Hadoop 范畴以外的人们协作以搜集差别的概念。

  跟着我们的迁徙使命逐步步入序幕,我们正在将重点转移到更多使人镇静的事情上。操纵底层容器编排的劣势,我们为将来订定了以下方案:

  Mithun Mathew 是 Uber 数据团队的二级初级软件工程师。他之前作为 Apache Ambari 的开辟职员到场 Hadoop 布置事情。他今朝在 Uber 专注于数据根底设备的容器化。

  Qifan Shi 是 Uber 数据根底设备团队的初级软件工程师,也是 Hadoop 容器化的中心奉献者。他不断在到场可以高效编排大范围 HDFS 集群的多个别系的研发事情。

  Shuyi Zhang 是 Uber 数据根底设备团队的初级软件工程师。她是 Hadoop 容器化的中心奉献者。她今朝专注于 Uber 的计较资本办理体系。

在线咨询 联系方式 二维码

服务热线

0531-87438999

扫一扫,关注我们