大规模机器集群-单机/集群/服务/机房/从零恢复的快速交付

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

本篇内容，依赖之前的3篇文章。

 大规模机器集群-故障自动处理(一)

 大规模机器集群-故障自动处理(二)

大规模机器集群-基础环境一致性 

名词定义

• ARS: AutoRepairSystem, 故障自动维修系统

• 服务树：一个树形数据结构，记录着机器与业务线的对应关系

• Deployer: 企业内部的CI/CD系统，记录和执行着所有的业务程序的变更和版本

• Executor: 企业内部的机器作业系统，可登录机器执行任务

• 运维人员：运维工程师 = SRE = OP，系统工程师 = sys

 

背景

在ARS上线运行一段时间之后，解决了SRE处理机器故障耗时费力的问题，同时也产生了新需求，

web SRE：既然机器故障自动修好了，能不能顺手帮我们把static/目录部署上？不大，几个G。

PaaS 平台SRE: 我们的机器修好后，需要部署一个PaaS agent，这服务不能简单地”随开机启动”，需要和当前线上各个机房的版本保持一致，你们的平台能搞吗？

机器学习平台SRE: 我们的服务是有状态的，机器修好后，要部署服务，还要观察数据加载的进度，要追上master才能引流。

。。。

 

ARS 在规划设计之初，目标只是机器、系统环境的自动处理，不涉及服务，随着基础能力的提升，用户自然而然地提出了这些需求。所以，本篇以“需求驱动”的方式，讲述如何高效地以单机、集群、机房为单位，交付机器。

 

 

机器交付的基础能力

一台机器从上架，到承载流量开始提供服务，要经过如下步骤，

1、 重装机器

2、 执行初始化任务，设置各类系统参数，部署依赖软件包

3、 部署业务程序，等待数据加载完成；部署有三种方式，物理机/PaaS/容器化部署

4、 修改上下游关联关系，引入流量，正式对外提供服务

 

我们使用ARS解决硬件故障自动维修、基础环境一致性问题之后，第一二步已经自动化，得到了一个基础能力：

输入: 任何机器，不管是否有故障，环境是否正确

输出: 无硬件故障，符合业务环境需求的可用机器

在这个能力的基础上，结合SRE提出的“部署业务程序”需求，ARS可以更进一步，向SRE提供“直接可用”的机器：

• 无硬件故障

• 符合业务环境需求

• 部署了正确版本的业务程序

• 业务数据加载完毕，服务处于可用状态

此时，SRE 只需要打开流量开关，即可提供服务。

 

下图显示了这种能力的加强过程，可以看到，第1阶段SRE需要投入人力的环节是4个，第3阶段降低到1个，

 

ARS直接向SRE提供“硬件、系统、业务程序、业务数据”可用的机器，这个过程，我们称之为“机器交付”。

 

“机器交付”大幅提升了SRE交付服务的效率。

比如在新机房建设的场景中，在1天内，1个人力，交付“完整的搜索系统”：约3000台物理机器，运行着接入、web、cache、业务程序、存储等数十个程序模块。

 

 

下面按照需求的时间线，介绍“机器交付”是如何实现的。

需求1-单机交付

需求2-集群交付

需求3-机房交付

需求4-从零恢复

 

需求1-单机交付

故障机器自动修复之后，ARS会向业务SRE发送通知，然后SRE自行部署程序。

 

由于机器修复后的程序部署，流程非常固定明确，SRE希望能自动完成，进一步节约SRE时间。

 

程序部署需要明确2个问题，

1、这台机器要部署什么程序，什么版本？

2、部署完之后，如何确定部署的程序及数据是正确的？

 

 

上图回答了问题1，ARS 从服务树查询机器所属业务，有了业务信息，就能从 Deployer 查到应该部署什么业务和当前线上版本，比如，归属Web前端的机器，部署nginx和静态文件，归属大数据的机器，部署Hadoop程序。

 

 

下表回答了问题2，服务状态检查都是通过curl服务端口，分析判断返回数据来实现，这部分逻辑由业务SRE提供。

服务类型	部署逻辑	服务检查
无状态服务	拉取当前线上版本部署，然后启动服务； 示例，nginx 服务，需要部署nginx binary 和静态目录	Curl 端口, 检查返回状态
有状态服务	拉取当前线上版本部署，然后启动服务，观察数据加载进度，完成后向配置中心注册。	Curl 端口, 检查返回状态及demo数据
基础agent服务	类似有状态服务，只是需要根据机房来区分版本； 此类服务，通常某种平台的agent，在每台机器上都有部署	Curl 端口, 检查返回状态及master&agent状态
系统工具集	静态binary文件，如iotop/iptraf等	无

 

综上所述，单机交付的任务树及部署伪代码如下图，

(这部分内容的理解，依赖前文   大规模机器集群-故障自动处理(一) )

 

只需要在任务树 online_service 方法里加入从服务树查询归属，调用Deployer 触发部署任务的逻辑， check_servercie 方法里加入curl 端口查询判断的逻辑，

ARS会轮询查询服务状态，直到服务可用，完成机器交付。

 

 

 

需求2-集群交付

集群交付很好理解，就是通过重装+初始化+部署程序的方式，一次性交付多台运行着相同服务的机器，这种需求通常来自于业务扩容。

可能有朋友会问，扩容为什么不直接部署服务呢，还要多此一举重装？

 

这是因为扩容的机器来源不确定，可能是新机器，也可能是借别的业务线的，环境不符合要求；

比如系统参数不对，或者有残留程序和数据，直接投入使用会带来隐患，历史也确实有过因未清理程序出现服务混跑从而影响业务的case；

而且未重装的机器，可能内核版本、lib so版本过于老旧，在部署服务过程中，排查问题的耗时比重装还要长。

所以走重装初始化，既能保证扩容的机器的交付质量，还能节约时间。

 

由于ARS底层使用了工作流，天然就支持对多台机器执行同一个部署任务，

 

 

集群交付的任务树scale_up_hosts_trees如下图所示，

 

 

实际运行的任务图，

 

 

 

需求3-机房交付

机房交付的需求，来自于新机房服务搭建的场景，机器数量通常是几千台，各个业务SRE 领取自己的机器，搭建服务，传输数据，检查，修改关联关系；

在ARS 未投入使用前，耗时通常是以几周计，很难精确衡量； ARS投入后，可以在1天内，1个人力，交付“完整的搜索系统”：约3000台物理机器，运行着接入、web、cache、业务程序、存储等数十个程序模块。

 

在集群交付的基础上，机房交付变得很简单，只需要将机器挂载到相应的服务树，触发ARS  scale up任务即可.

下图是，机房建设新旧方式的对比，

 

可见，将人工处理的多个流程（重装+初始化+部署基础agent+环境正确性检查+服务部署+数据传输+服务状态检查）通过ARS自动化交付，机器规模越大，SRE团队越大，节约的时间越可观， 而且还保证了交付质量。

 

用一个不太恰当的比喻来说，

对于一个公司，工作日的开始时间，基本处于 8点～11点这个区间，因为员工是陆陆续续到工位的；

机房交付的作用，相当于接管了所有员工的一系列动作：“起床，洗簌，吃早餐，乘坐交通工具到办公楼，刷卡，乘坐电梯，走到工位，坐下，开机”，

直接缩短为：“起床 -> 开机”，统一9点开始工作, 公司越大，员工越多，节约的时间越可观。

 

 

需求4-从零恢复

从零恢复，用一句蹭热点的话来说，就是 “极限生存的假设”，假设接二连三地出现整个机房异常，如何在其它机房用最短时间内搭建一整套可用的服务？

 

这个需求，其实是一个很大的项目，涉及 rd-sre-sys-network多方协作，这里只着重讲述整体思路和涉及ARS的部分。

 

1. 筛选出主干模块，减少非核心功能，这样需要传输的数据+文件总量就小，要操作的模块数量也小，有利于更快恢复

2. 在机房交付的基础上，放开所有限制，包括并发数目， QoS优先级，下载速度，使用p2p进行传输, 对失败机器直接丢弃，只尽全力交付机器，能交付多少就交付多少

3. 开发全局关联关系管理专用工具，管理所有连接关系的变更，不管是配置文件还是zk 注册、PaaS平台托管、容器化服务，做到一键完成lvs –>nginx->java application -> cache -> db -> zk 整条链路的关联关系变更；在ARS机房交付的基础上，从ARS获取所有实例列表，一键修改所有的配置，从上至下关联起来。

 

整个过程如图，

从演练的结果来看，从零恢复我们做到了3小时内，其中机器重装+初始化耗时30分钟，服务程序部署30分钟，数据传输1.5小时，上下游连接关系生效30分钟。

 

为什么不自动接流量

以上几个场景，ARS都交付了带服务的机器，理论上，“接入流量”这个动作，也能程序化，从机器重装到接入流量做到完全自动。

但这样存在极大的风险，因为有些业务异常，并不是在上线后马上发生的，有可能是在流量高峰上来之后才触发，或者是某个分支条件满足才触发。

想象一下，如果下午自动上线了一批机器，结果半夜触发了异常，止损恢复的时间就难以保证了，所以为了业务稳定性，这一步不做。

 

长尾处理

批量操作机器硬件时，通常有1%的失败率，原因有很多，诸如BIOS设置不正确，内存插拔顺序异常等。

 

ARS 在设计之初，就考虑了长尾问题，通过任务分支、机器原子操作的机制，保证了机器任务的闭环，最终能达到一个明确的结束状态。（详见前文: 大规模机器集群-故障自动处理(一)）

 

这个能力，在机器规模大的时候，比如机房建设，可以节约SRE大量处理时间，比如反复问询SYS修复状态，这种耗时是难以估量的。

 

虽然这部分效率的提升在述职PPT里没有卵用，但结结实实地帮助 SRE 节省了时间和心力, 你见过因为SRE反复催促SYS同学交付机器，在大群里互相质询连喷三十句，直到双方经理架构师出面安抚制止的场面么？

 

交付质量

由于引入了 Apply-Check机制，ARS能保证交付的每一台机器都是硬件无故障+系统环境正确的，因机器厂商、硬件型号、系统发行版、内核版本、lib so 版本导致的初始化失败，都会在check 环节里发现，初始化失败的机器不会被交付，这节约了大量因环境不符合预期导致的返工时间。

 

容器化时代

有运维同行问，现在是容器化时代了，这套系统还有用武之地吗？这个问题很好回答.

 

第一，ARS 设计之初，就是为了解决硬件和系统问题的，与容器的相交边界为

“机器交付”，如图所示，

可以看到，ARS与容器化并不冲突，实际上，ARS会交付运行着 docker daemon 的机器。

第二，服务整个技术栈的容器化，不一定适合每个企业，也不是短期能实现的。 有些企业引入容器化技术，推行了3年，也只覆盖了不到30%的服务。

 

一个脑洞

既然机器已经可以自动交付，那么是否可以在 CI/CD 流程里，把机器也作为pipeline的一个环节？ 当然这种设想不一定合理，只是一个脑洞。

 

 

本篇到这结束，下一篇会讲述 SRE OnCall时，如何提升机器相关任务的效率。

 

来源：oschina

链接：https://my.oschina.net/u/4150750/blog/3149221