Microsoft在2007年的文章中描述了他们用于维护大规模互联网服务的工具利器AutoPilot,采用简单的模型和设计思想,AutoPilot负责自动化的运维数据中心中提供服务的大规模机器。想起每次上线时的等待,尤其在部分模块启动时间很长的时候,必须到全部都部署完成并check完成后才能完事的痛苦过程,就感叹国外的先进生产力。原文pdf见这里

Design Principles

  1. 被autopilot管理的large-scale web service必须自身有一定的容错性,任何一个节点或者部分节点的失效都应该不影响系统对外的正常服务。autopilot是一个lazy action的监控&修复Service。
  2. Simplicity is as important as fault-tolerance when building a large-scale reliable, maintainable system。最近一年对这句话感触很深,一个本身就很庞大的系统,在很多地方必须尽可能的简单,任何过于精巧的实现解决的问题,一旦出了问题,很可能都会带来更严重的问题,并且很难处理。Autopilot在设计上的机制上非常简单,从错误分类、到执行的操作以及节点的状态定义都简单通用,不进行特化。同时允许用户端程序自己进行部分扩展。

单个Autopilot实例负责管理的一堆机器被成为一个cluster,数据中心中的购置的机器配置都是符合一系列标准套餐中的某种。

autopilot由多个不同的Service组成,这些Service分工协作,共同负责维护cluster中的服务。Overview如下图

image

Autopilot各个核心组件的功能

Autopilot提供给cluster每台机器上默认安装的工具,主要的包括以下两个:

filesync : 文件同步工具,可以从remote server上获取文件,同时又向其他机器提供这种service。自己实现filesync的优势在于拥塞控制,避免电脑或者交互机网卡异常超载。

application manager : 程序所需的binary、数据、配置等都放在一个独立的目录下,application manager能根据提供的配置manifest,确定指定的进程是否正确运行。

Device Manager:  Autopilot系统的大脑,存储cluster中所有机器所需的信息,并且根据这些信息决定对目标节点采取何种操作。Device Manager是一个由5-10个机器组成的分布式系统,作为整个Autopilot的大脑,所有节点的状态信息在Device Manager中必须保证“真实”,且保持强一致性,利用paxos算法实现。

其他围绕着Device Manager的Service被称为satellite service,负责跟Device Manager通信并获取命令,采用定时pull的方式更新状态,各个Service也是分布式的服务,但由于Device Manager中保证了数据的强一致性,Service内可以采用弱一致性模型。同时Device Manager也可以主动要求(kick)Service向自己同步,即使kick失败,定时的pull仍然能保证数据在稍后一段时间内被更新。

Provisioning Service:  周期性的扫描网络,发现新加入cluster的机器后,向Device Manager请求获取该类型的机器需要部署的OS,并通过computer的management接口进行OS的部署、启动,并进行一些burn-in的test,当这些测试通过后,通知Device Manager。完成部署的机器独立的请求Device Manager获取需要部署并运行的Application,这项操作由Deployment Service完成。

Deployment Service: Device Manager中记录着不同type的computer可以运行的程序manifests,computer从Device Manager请求获取这些manifests,包含了多个可以运行在本机上的程序。而Deployment Service上存储着这些manifest对应程序、配置以及数据等(这些东西通常由一个外部的构建系统触发生成)。

但在同一时刻,只有一个manifest处于active状态,application manager则会保证处于active状态manifest记录的程序被正确的运行。同时,会定期的去同步Device Manager获取新的manifest,发现有更新时就从Deployment Service中的随机一台请求获取,或者删除一些还只有在本地保留的数据。这样,机器上根据多个manifests部署,但只有一个active状态的在run的行为,可以保证部署新版本时候所需的文件先完成pre-loaded,但未处于active状态。同时也方便新版本上线后回滚到旧版本。

灰度发布:autopilot利用Deployment Service进行灰度发布,简要过程如下:

1.  先把需要部署的新程序、数据等构建到Deployment Server上。同时更新Device Manager,将对应的manifest存放在需要部署的computer类型上。

2. 执行一次kick或者等待下一次机器主动向Device Manager进行sync,使得所有待部署的computer获取manifest更新,并从Deployment Service上获取需要的数据文件等。

3. 当有足够的机器完成了新版本的部署后,Device Manager会进行rollout。autopilot将整个需要部署的集群分为多个scale-unit用于灰度发布,每次操作一个scale-unit,发送执行将新的manifest设置为active并运行新的部署。当一个scale-unit中有足够量的机器部署运行正确后,才会进行下一个scale unit的操作。

4. 如果某个scale-unit在操作时,执行的超时时间内,还未能有足够量的新部署完成并成功,则认为该scale-unit部署失败,取消rollout,进行rollback,同样一次一个unit操作。

autopilot定义scale unit并进行灰度发布,从小到一个配置项的修改,大到一个新的OS镜像部署,都采用了这样的方式。

Autopilot自动化的异常检测与修复

      Autopilot中的Automatic repair service基于一个简单的状态转换模型,任何一个节点都会被归类为Healthy、Failure或者Probation三种状态中的一个, autopilot根据节点的健康状况以及监控报告,设置节点的状态,并采取不同的action,状态转换图如下:

image

       Autopilot自身针对的failure仅是computer节点或者某个交换机网段异常,而非针对特定程序。提供的修复手段也只有Reboot、Reimage和Replace,这样autopilot本身不关心应用程序级别的异常。节点健康状态的检测通过watchdogs进行监控:

Watchdog : 负责监控computer本身健康状况的工具,将结果通知Device Manager,结果仅为OK、Warning、Error三者中的一类,warning&error可以带简单的reason。watchdog可以运行在一批的watchdog service集群上负责监控目标节点状态,也可以运行在机器本地。watchdog和device manager之间的通信的procotol非常简单,可以方便的写出自定义的watchdog用于程序应用层面的监控。

故障的修复:

  1. 某个watchdog报告了节点状态为error时,节点本身的状态从Healthy被修改为Failure。同时Device Manager会给该节点采取一个动作(从Donothing、Reboot、ReImage、Replace中选取),具体选取的动作会依赖该节点的故障历史,如果该节点最近一段时间内,并没有异常,则首先会Donothing以期望该Error是一个误报或者瞬间错误。对于通用Watchdog检测出BIOS发现的硬件异常,则直接进行Replace。其他类型频繁发生但非致命的错误,会从reboot逐步上升到reimage,最后直到采用Replace操作。
  2. Repair Service则会周期性的去请求Device Manager获取需要进行Repair的computer list,以及对应的操作,修复操作完成后会将节点的状态修改为Probation。此后如果节点在一定时间内运行正常,则状态变为healthy,如上图。否则会重新置为Failure状态并通知Device Manager采用进一步的Repair action。
  3. 对于一次新的部署,在部署完成后,会将节点的状态从Healthy设置为Probation,继续使用上述的模型,当节点恢复为Healthy时,可以认为这次部署是成功的,这样实现保证了修复操作与新部署状态的统一。
  4. 所有的信息都由watchdogs发往Device Manager,由其决定需要执行的操作,这样Device Manager能获取全局信息,可以控制同时在repair的机器数量,避免某种异常时导致所有的都报Error,同时repair大量机器,线上服务不可用。

      最后,文章中提了下autopilot的监控服务,一些常用的工具运行在机器本身,统计机器的性能、处理的平响等,Collection Service是一个分布式的服务,用于收集cluster内多个节点的信息并聚合,可以进行一些复杂的统计。其中值得借鉴的做法是会把实时性能监控的一些数据存储在关系数据库中,便于后续的统计和挖掘。最近也在考虑这种问题,如果把每一个请求经过每一个Service的日志和相关数据都记录下来,那量级会非常大,并且很可能99%的正常处理并没有太大意义。但是如果不记录,就会很容易丢失,如何有效的抽取需要记录用于统计的数据防止冗余数据过多,同时又能避免遗漏那些需要被记录的特殊case。

Autopilot文章中并没有描述一个具体的自动化运维管理数据中心节点在实现各种功能的方式,但通过文章可以全面的了解要自动化管理一个large-scale的web service需要做的工作以及基本的方法。想起我们痛苦的上线,出现异常RD&OP手忙脚乱,着实让M$来的同学看起来很囧啊。

转载请注明来源:Leoncom-《Microsoft AutoPilot – 管理大规模集群的利器》
Trackback

only 1 comment untill now

  1. monkey1d @ 2012-12-25 15:39

    请问博主你怎么看大量的专业pdf和论文?用平板电脑还是对眼睛好的Eink电子书阅读器还是打印出来?

Add your comment now