阶段性总结系列2 大批量机器的管理规则

任何业务都是从零开始,业务量也是逐步上升,发展到现在,应对小批量业务有多种方式,大多设计巧妙的,都是小而美的方式,(当然,更多的是那种四不像的,屎山一样的业务)。然而,随着业务量的不算上升,即便原来小而美的的设计,方方面面也逐渐触及边缘,问题不断增多,到最终也势必面临着革新。

我们先不从小业务逐渐扩大这个方向讲起。

先简化初始条件,最终再反向思考。

我们开始做下假设,凭空出现出现了一个业务,量超级大,那么随之而来的大批量机器该如何管理?

机器,是资源,是一切服务,软件运行的基础。

首先明确我们的目标,是提供一个标准化,统一的资源给服务使用,这是一个中间层,拉齐所有服务运行条件的过程。

首先,是机器上架,不同厂商,不同型号,乃至不同型号硬件的的机器,出厂设置可能均不同。我们按步骤说:

1. 网络分配,建立管理用户,这块只能依赖手工操作,没有好的办法。机器的网络管理模块首先入网,有了网络,下面就好做了,注意网络隔离,毕竟谁也不想将管理模块暴露给不怀好意的人

2. 通过厂商管理接口,比如ipmi,如今的redfish,或者不同厂商提供的接口,配置BIOS,RAID及其他硬件

3. 系统安装及初始化,涉及PXE相关工具,使用KickStart,cobbler等工具批量部署系统,如果是云服务器,则应根据云厂商提供的接口,对系统进行安装及初始化,对系统内参数设置,相应配置,所建用户,内核参数,提供的工具,软件,基本运行库等初步建立统一标准,例如监控,部署系统,服务管理工具等,此过程不应涉及业务相关特殊需求,尽量提供统一的解决方案。

4. 业务SRE使用ansible相关工具,根据所在业务对系统进行进一步调整,使之更符合业务需求,并要不断完善,当业务要求在某台机器上做其他调整时,要考虑是否对存量机器有害,如无害,则应对存量机器做同等处理,力求保持环境统一,如不适用于存量机器,则应分组处理

5. 当大批量机器构建完成,则要注意一个重要的思想的转变,那就是将以服务为中心,而不再是以机器为中心。现代大型服务系统是分布式系统,不存在单个节点,也不应存在单个节点,我们应考虑的是某个服务的某个节点挂了,不应影响整个系统的健康。因为在大批量的机器管理中,几乎每天都有机器硬件或其他问题导致机器故障,单个机器导致整个业务出现问题是不可接受的。

6.资源调度问题,即使是虚拟机或容器平台,都会存在负载均衡问题,我们简化一下,只考虑服务部署于物理机器的情况,在大批量的机器中,多个服务部署与同一个机器,总是有机器处于高负载,而有机器处于低负载的状况。诚然,我们可以不断完善监控,如:机器维度的各项资源监控,再进一步,服务发布时,发布系统自动生成该服务的各项资源使用指标。然后,我们可以再进一步,考虑如何在机器资源趋于不足时,自动进行迁移或扩容,而要做到自动进行迁移或扩容:

i. 服务必须无状态化,不能绑定单个机器

ii.需监控服务各项资源指标

迁移或扩容又需分开说:

(1). 扩容,当多个节点,或全部节点均处于资源使用率升高时,进行扩容

(2). 迁移,当单个或个别节点出现问题时,进行迁移

要完成这两项,需考虑的内容有:

(1).定义资源使用率的阈值

(2).定义问题节点占全部节点的阈值

(3).服务各个节点与机器当前资源状况的对应

7. 机器层面扩容缩容,机器数量应该是动态的,随着业务量上升或下降动态提升或缩减,需设计相应工具,当资源全部不足时给出预警,而资源冗余量过高是应自动给出提示,这其中需考虑业务状况,例如:

i.业务平稳,没有大起大落

ii.业务量经常忽大忽小,这种情况下,又可从三方面考虑:

(1).保留一定冗余的资源,阈值根据业务峰值及平时资源使用量而定

(2).公司内提供的容器平台或虚拟平台等弹性基础设施,平时需建立备用机制,当出现突峰时能够快速接入备用资源

(3).大型节假日,例如春节,春晚,五一,国庆等。可考虑接入云厂商,当冗余资源消耗到一定程度时,通过云厂商的接口,自动下单购买资源,由于这其中具有一定的时间滞后性,需考虑冗余资源消耗阈值及如何缩短时间,因为这时购买的资源,大多以时间计费。另外,考虑到成本,也应健全审批环节

未完……

发表评论

您的电子邮箱地址不会被公开。