大型机器集群-单机集群-服务-机房快速交付

电脑杂谈  发布时间:2020-06-10 07:20:30  来源:网络整理

刷卡机模块初始化失败_pos机模块初始化失败_即付宝刷卡失败原因

本文依靠前面的三篇文章. 见

屈兴仁: 大型机器集群自动故障处理(一)zhuanlan.zhihu.com

图标

l ARS: AutoRepairSystem,自动故障修复系统,

l服务树: 一种树形数据结构刷卡机模块初始化失败,记录机器和业务线之间的对应关系

l Deployer: 公司的内部CI / CD系统,该系统记录并执行所有业务程序的更改和版本

l执行程序: 企业内部的计算机操作系统,可以登录到计算机以执行任务

l运维人员: 运维工程师= SRE = OP,系统工程师= sys

ARS上线一段时间后,解决了SRE处理机器故障的时间和精力问题,并产生了新的需求,

web SRE: 由于机器故障是自动修复的,您可以帮助我们部署static /目录吗?不大,只有几克.

PaaS平台SRE: 修复机器后,我们需要部署PaaS代理. 该服务不能简单地“从启动开始”. 它必须与每个联机计算机机房的当前版本一致. 您的平台可以做到吗?

机器学习平台SRE: 我们的服务是有状态的. 维修机器后,我们必须部署服务并观察数据加载的进度. 我们必须赶上主人以消耗力量.

. .

在ARS的规划和设计之初,目标只是机器和系统环境的自动处理,而没有涉及服务. 随着基本能力的提高,用户自然会提出这些要求. 因此,本文使用“需求驱动”方法来描述如何在独立,群集或计算机机房的基础上有效交付计算机.

一台机器开始提供从装载到运输的服务. 需要以下步骤,

1. 重新安装机器

2. 执行初始化任务,设置各种系统参数并部署依赖的程序包

3. 部署业务程序并等待数据加载;有三种部署方式: 物理机部署,Paas部署,容器化部署

4. 修改上下游关联,引入流量,并正式提供外部服务

使用ARS解决硬件故障的自动修复和基本环境的一致性后,前两个步骤已实现自动化,并获得了基本能力:

输入: 任何机器,无论是否有故障,环境是否正确

pos机模块初始化失败_即付宝刷卡失败原因_刷卡机模块初始化失败

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

在此功能的基础上,结合SRE提出的“部署业务流程”需求,ARS可以走得更远,并为SRE提供“直接可用”的机器:

l没有硬件故障

l符合商业环境要求

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

l业务数据已加载且服务可用

这时,SRE只需要打开流量开关即可提供服务.

下图显示了增强此功能的过程. 可以看出,第一阶段SRE所需的人力资源数量为四,而在第三阶段则减少为一个.

ARS直接为SRE提供可用于“硬件,系统,业务程序和业务数据”的计算机. 此过程称为“机器交付”.

“机器交付”极大地提高了SRE交付服务的效率.

例如,在新建计算机房的过程中,一天之内,就有1个人可以交付“完整搜索系统”

统一”: 大约3000台物理计算机,运行数十种访问,Web,缓存,业务程序,存储等.

程序模块.

以下是根据所需的时间表如何实现“机器交付”的说明.

按需1个独立交付

按需提供2个集群

3机房需求配送

需求4从零开始恢复

故障机器自动修复后,ARS将向业务SRE发送通知,然后SRE将自行部署程序.

刷卡机模块初始化失败_pos机模块初始化失败_即付宝刷卡失败原因

由于在维修机器后部署了程序,因此该过程非常固定且清晰. SRE希望自动完成它,从而进一步节省SRE时间.

程序部署需要确定2个问题,

1. 应该在此计算机上部署什么程序和版本?

2. 部署后,如何确认已部署的过程和数据正确?

上图回答了问题1. ARS从服务树中查询计算机所属的服务. 借助服务信息,您可以从Deployer中检查应部署的服务以及当前的联机版本. 例如,属于Web前端,部署nginx和静态文件的计算机属于大数据计算机,并且部署Hadoop程序.

下表返回问题2. 服务状态检查通过curl服务端口执行,并且对返回的数据进行分析和确定. 这部分逻辑由业务SRE提供.

总而言之,一台机器交付的任务树和部署伪代码如下,

(对这部分的理解取决于上面的内容: )

只需在任务树online_service方法中添加从服务树查询归因的逻辑,调用部署程序以触发部署任务逻辑,并将curl端口查询判断逻辑添加至check_servercie方法,

ARS将轮询服务状态,直到该服务可用并且机器已交付为止.

集付很容易理解,也就是说,通过重新安装+初始化+部署程序,可以同时交付运行同一服务的多台计算机. 这种需求通常来自业务扩展.

一个朋友可能会问,为什么不直接部署该服务以进行容量扩展,然后一次全部重新安装?

这是因为扩展机器的来源不确定,它可能是新机器,也可能是从其他业务部门借来的,并且环境不符合要求;

例如,如果系统参数不正确,或者存在残留的程序和数据,则直接使用将带来潜在的危险,并且确实存在由于未清理的程序而导致服务用尽的情况,从而影响了服务质量. 业务;

未安装的计算机可能具有太旧的内核版本和lib so version. 在部署服务的过程中,解决问题所需的时间比重新安装所需的时间更长.

因此,重新加载和初始化不仅可以确保扩展机器的交付质量,还可以节省时间.

由于工作流用于ARS的底层,因此自然支持在多台计算机上执行相同的部署任务,

pos机模块初始化失败_刷卡机模块初始化失败_即付宝刷卡失败原因

集群显示的任务树scale_up_hosts_trees显示如下,

实际正在运行的任务图,

交付计算机室的需求来自新计算机室服务大楼的现场. 机器数量通常为数千台. 每个业务SRE都拥有自己的机器,构建服务,传输数据刷卡机模块初始化失败,检查并修改关联关系;

在使用ARS之前,通常需要花费几周的时间来计算,并且难以准确测量; ARS投入使用后,可以在1天1人内交付“完整搜索系统”.

统一”: 大约3000台物理计算机,运行数十种访问,Web,缓存,业务程序,存储等.

程序模块.

基于集付,计算机室的交付变得非常简单,只需将机器安装到相应的服务树并触发ARS扩展任务,

下面的图片是建立计算机房的新旧方法的比较,

可以看到,通过ARS自动交付了手动处理的多个过程(重新安装+初始化+基本代理的部署+环境正确性检查+服务部署+数据传输+服务状态检查),机器尺寸越大,尺寸越大SRE团队,可以节省更多时间,并保证交付质量.

用不恰当的比喻,

对于一家公司来说,工作日的开始时间基本上是在8点至11点之间,因为员工是连续到达工作站的.

交付计算机房的作用等同于接管所有员工的一系列行动: “起床,洗漱,吃早餐,接送去办公大楼,刷卡,走楼梯,步行到车站,坐下,打开”,

简写为: “起床->打开”并在9点开始工作. 公司越大,员工越多,可以节省更多的时间.

用热点的话说,从零恢复是“极端生存假说”. 假设整个机房相继异常,如何在最短的时间内建立其他机房的可用服务集?

这个需求实际上是一个非常大的项目,涉及rd-sre-sys-network多方协作. 这里仅描述了总体构想和与ars相关的部分.

1选择主要模块来减少非核心功能,从而使要传送的数据+文件总数少,并且要操作的模块数也少,这有利于更快地恢复<

即付宝刷卡失败原因_pos机模块初始化失败_刷卡机模块初始化失败

2基于计算机机房的交付,所有限制均被释放,包括并发数,QoS优先级,下载速度,使用p2p进行传输,直接丢弃有故障的计算机,并仅尝试交付计算机尽可能地.

3开发一个用于全局关系管理的特殊工具,管理连接关系中的所有更改,无论是配置文件还是zk注册,PaaS平台托管,容器化服务,一键完成lvs –> nginx-> java应用程序->缓存-> db-> zk整个链接的关联关系已更改;在交付ARS机房的基础上,所有实例列表都是从ARS获取的,所有配置都可以一键修改,并且从上到下进行关联.

整个过程如图所示,

从练习的结果来看,我们在3小时内从零恢复,包括30分钟的计算机重新安装和初始化,30分钟的服务程序部署,1.5小时的数据传输以及30分钟的上下游连接效果.

为什么不自动接收流量

在上述情况下,ARS交付了带有服务的计算机. 从理论上讲,“访问流量”的动作也可以进行编程,从重新安装机器到完全自动化的访问流量.

但是存在很大的风险,因为某些业务异常现象不会在联机后立即发生. 高峰流量出现后或满足特定分支条件时可能会触发该事件.

想象一下,如果一批机器在下午自动启动,并且在半夜触发了异常,则很难保证止损恢复的时间,因此对于业务稳定而言,此步骤不是完成.

批量操作机器硬件时,由于多种原因,例如错误的BIOS设置以及异常的内存插入和取出顺序,故障率通常为1%.

在设计之初,ARS考虑了长尾问题. 通过任务分支和机器原子操作的机制,保证了机器任务的闭环,最终达到了清晰的结束状态. (有关详细信息,请参见上一篇文章: )

当机器规模较大时(例如,计算机房的建设,例如反复要求SYS修复状态),此功能可以节省大量SRE处理时间. 这种耗时很难估算.

尽管效率改进的这一部分在工作报告PPT中没有用,但它可以帮助SRE节省时间和精力. 您已经看到,因为SRE反复敦促SYS同学交付机器,所以他们在一个大小组中互相询问了30次. 一句话,直到双方的经理建筑师来安抚镇压现场?

由于引入了Apply-Check机制,由于机器制造商,硬件型号,系统版本,内核版本,lib,ARS可以确保交付的每台机器都没有硬件并且系统环境正确如此版本如果初始化失败,您将在检查链接中发现未通过初始化的计算机将不会交付,从而节省了由于环境未达到预期而导致的大量返工时间.

一个运维同事问,这是集装箱运输的时代. 这个系统有什么用吗?

这个问题很容易回答,

首先,在ARS设计之初,就是要解决硬件和系统问题,即与容器的交集边界

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

如您所见,ARS与容器化没有冲突. 实际上,ARS会交付运行docker daemon的机器.

第二,服务于整个技术栈的容器化可能并不适合每个企业,短期内也无法实现. 一些公司已经采用了三年的集装箱技术,仅覆盖了不到30%的服务.

由于可以自动交付机器,是否可以在CI / CD流程中将机器用作管道的一部分?当然,这个想法不一定是合理的,只是一个脑袋.


本文来自电脑杂谈,转载请注明本文网址:
https://www.pc-fly.com/a/sanxing/article-240342-1.html

    相关阅读
      发表评论  请自觉遵守互联网相关的政策法规,严禁发布、暴力、反动的言论

      热点图片
      拼命载入中...