运维自动化重点解读之监控系统（二）：高可用
2016-02-20 19:33:29   来源： Reboot运维开发 51CTO博客    评论：0 点击：

【引自Reboot运维开发的博客】我借用一个高可用性的定义：高可用性H.A.(High Availability)指的是通过尽量缩短因日常维护操作(计划)和突发的系统崩溃(非计划)所导致的停机时间，以提高系统和应用的可用性。它与被认为是不间断操作的容错技术有所不同。HA系统是目前企业防止核心计算机系统因故障停机的最有效手段。

那么高可用，就是高可用性良好的系统。多少算高呢？我以前待过的BAT某公司喜欢用小数点以后几个9来衡量。当然小数点前面默认就是99。大家普遍认为4个9是还不错的，5个9是核心业务应该具备的。怎么计算呢？这个我后面也可以说一说算法。

对于运维工程师来说，要是能运维一个可用性非常高的系统，我想是一件幸事。系统能高可用，运维处理报警的优先级就不用那么高了。大冬天晚上收个报警，也不用立刻从被窝里面爬起来连VPN处理了。可用性越高，运维工程师睡觉越安心。

影响高可用的因素与计算方式

影响可用性的因素都有哪些?让我们来捋捋。一个服务分为软件、硬件。拿一个网站来讲解。

假设有个网站，域名是www.51reboot.com。部署了一个nginx，部署在一台服务器上，这台服务器在一个叫做zw的电信机房。

用户从浏览器输入www.51reboot.com开始，直到他在浏览器上能打开这个网页内容为止，有哪些步骤?

第一步，域名解析

第二步，向着服务器发起HTTP请求

第三步，请求走网络，到达服务器所在机房的交换机

第四步，数据走几层交换机之后，到达服务器网卡

第五步，网卡数据经过OS，到达Nginx

第六步，Nginx收到HTTP请求

第七步，Nginx调用ThinkPHP框架(这里假定是这个框架)

第八步，PHP连接Mysql数据库获取数据

第九步，PHP处理数据

第十步，Nginx返回数据到用户端

第十一步，用户端浏览器完整接收数据之后，渲染完毕

粗略的分为11个步骤。这里涉及：DNS、服务器、交换机、OS、Nginx、ThinkPHP、PHP、Mysql

服务器又可以分为：磁盘，以及其它部件如CPU、内存。之所以这样分，是因为磁盘作为存储部件是最容易坏的一个部件。

好了，我们接下来算一算，51reboot这个网站的可用性是多少。一次可用，相当于上面的十一个步骤都得正常才叫可用。那么就要考虑了，DNS的可用性是多少，服务器不宕机(可用性)是多少、Nginx之类的软件的可用性是多少、Mysql、磁盘的可用性是多少、网络的可用性是多少等等。这些可用性的乘积，就是该网站的可用性。

这里还没有考虑更多实际情况。比如，Mysql如果和Web端不在同一台机器上、甚至不在同一个机房，或者部署的Nginx实例不止1个，等等。

上面我们讲了可用性怎么计算。下面我们来看看监控系统的高可用。

先定性，再定量

这是我的原则，事情都是先定性，看是否有必要，再定量，看需要定到多少，具体量化。监控系统本身是监控别的服务和系统是否正常运行的。如果监控系统自身可用性不足，会严重影响监控效果。甚至可以说就是没有什么用处，有大隐患。

这里还涉及了另外一个问题，就是监控系统自身的监控。以后会开篇幅来讲。

前面说了，监控系统本身必须高可用。那下面我们就看这个高可用需要怎么量化。读者觉得应该达到小数点之后几个9?我个人觉得至少2个9。也就是 99.99%。否则业务部门的兄弟们急了，因为他们的系统如果要求是99.999%，没人能证明啊！监控系统本身才是99.99%。

如何达到高可用99.99%

这是今天这篇要讨论的另外一个核心问题了。要达到高可用性，还要看系统的架构。按照有没有单点来区分，系统有两类，一类是有单点的架构，一类是没有单点的架构。讲到这里我们有必要说一下什么叫做单点。单点简单来说就是系统里面的某个部位，它在系统里面部署的时候，是一个唯一存在。这个唯一存在不能扩展性的部署一个兄弟实例出来。这种唯一存在将来就最有可能是系统里面的老大难，因为它出了问题，没有兄弟能顶上。

但，我又要说但是了。没有单点，不代表说完全百分之百的没有问题。例如，我们采用Hash的办法，负载均衡的方式，部署了2个Nginx实例。当其中一个实例挂掉的时候，仅影响了50%的请求。不能算整个系统挂掉了。但这个系统的稳定性依然堪忧，我们不能说它的可用性有多高。 如果Hash计算能够结合了实例的健康状态，不健康的自动从hash计算的池子里面摘掉，那可用性就大大提升了。

综上，以及综合我们上一篇，监控系统要想达到高可用，必须要采用去中心化的架构来做。就是让整个系统里面没有任何一个环节是单点。因为单点就意味着瓶颈，意味着可用性提升很难很复杂，不容易做高。

具体说怎么才能去单点。我们从监控系统本身的数据流来分析。

数据采集，这个要分类来说。一个是带内的，跑在OS上的代理Agent。这个的高可用，是另外一个领域的事情，就是怎么写一个高可用的、鲁棒性非常好的客户端。我们以后分开篇幅说。

另外是带外的。比如，HTTP或者端口监控，或者存活监控。我们拿存活监控来举例吧！比如说，我们通过ping的方式，来监控服务器是否存活。那么，我们需要一个批量发ping包的探测器。这个也是一个数据采集端。只是没有在OS上来采集。当然它也存在鲁棒性的问题，但这是另外一个领域的事情，我们这一篇不谈。这个客户端，如果它挂了，可想而知，被它监控的服务器都失去监控了。所以，我们要提高Ping监控模块或者叫环节的可用性。一个最简单办法，我们用两个监控点来监控同一批服务器。但新的问题又来了，俩监控点监控同一台服务器，什么情况下可以断定这个服务器挂了呢？这个是另外一个监控数据合并的问题，我们也放到以后的篇章里面去讨论。另外一个提高可用性的办法，就是ping监控点部署两个，但两个之间不要同时生效，但两个节点之间有心跳，一个挂了，另外一个接管，也是一个办法，但切换略复杂。

数据采集回来了，要做处理。这个处理或者叫计算环节的高可用，有不少现成的办法。第一，部署两个计算实例，但两个实例需要能互备或者同时发挥作用。第二，纯分布式办法。

存储和Web的分布式方案就更多了。

还有一个最关键的地方，如何实现无状态。只有无状态了，才能达到简单的部署切换，就可以支撑高可用。这个问题我们留待之后来讲。（未完待续）

【编辑推荐】