《OpenStack高可用集群（上册）：原理与架构》—1.6 云环境下的高可用设计

1.6　云环境下的高可用设计

在云计算布道的阶段，关于如何对待云计算环境下服务器与传统数据中心服务器的最形象的比喻也许就是“宠物”与“绵羊”了。在传统数据中心里，用户总是小心翼翼地维护如宠物般珍贵的服务器，而在云环境下，服务器就像放养的绵羊，出了任何问题随时可以将其替换掉。这种云计算概念上的普及似乎在告诉用户，上了云便可以高枕无忧，再也不用担心服务器宕机带来的噩耗，也不用再担心业务系统的高可用受到影响。然而，事实似乎并非如此，尽管各个公有云运营商推出了4个9甚至5个9 的SLA来承诺云服务的高可用性，但是对于很多严重依赖IT系统的企业而言，即使完全如云运营商所承诺的那样实现了99.99%的高可用，但是也无法承受全年52分钟的宕机时间，更何况很少有云运营商真正做到SLA的承诺，而云运营商对于SLA失信的赔偿似乎也远不及用户的损失。随着云计算的不断成熟和使用用户的增加，各种云宕机事故所造成的影响和损失也越来越严重，不管是国外云巨头亚马逊的AWS、Google的GAE、微软的Azure，还是国内的阿里云、青云、盛大云等均有不同程度的云宕机事件发生，而PaaS巨头CRM领域的领头羊Salesforce在2016年5月份丢失用户近5个小时的数据，而且很多数据无法找回更是引起了云计算发展的一些争议。

从理性的角度来看，公众对于云计算领域的各种宕机事故如此关注，尤其是AWS、Azure、阿里云等巨头的宕机事故，其关注度甚至高于自己企业的宕机事件，这与云计算早期的宣传致使很多用户对云计算抱有100%高可用的不切实际的期望有关。事实上，云计算不可能万无一失，云计算会宕机也不应该成为质疑或反对云计算的理由，任何业务系统的高可用性都不是与生俱来的，而是要求用户必须做好自己系统的设计，然后充分利用云计算提供的资源机制，而不是用户不做任何系统高可用性设计和考虑，直接把应用程序扔到云端就万事大吉。其实云计算和传统IT基础设施一样，不可能万无一失，系统和应用在设计时本来就应该为故障做好准备，而不是完全依赖IT基础架构100%的可用性，例如在AWS 2011年4月份的宕机事故中，很多运行在AWS上的企业都受到了不同程度的影响，但是Twilio公司却因为良好的业务系统高可用性设计而免于此次事故。

1.6.1　云计算HADR架构设计原则

传统数据中心的HADR主要是基于服务器的部署架构，系统软件主要部署在物理服务器或者虚拟机上，而高可用性设计的主要解决方案是提供冗余的硬件和系统，如应用服务器集群、主从数据库同步复制、冗余网卡和RAID磁盘阵列等。传统数据中心的HADR集群架构可以看作硬件服务器和系统软件的一个垂直集合，每个服务器可以看作它的垂直子集，集群中任何一台服务器故障，其他服务器仍然可以响应应用请求，

如图1-22所示。

与传统数据中心基于服务器的架构不同，对于企业而言，云计算环境下最大的技术转换便是云的出现只是为了提供服务，即云架构的核心应该是如何呈现和利用云服务。传统数据中心需要提供运行时的设备，如应用和数据库服务器，并且是以独立且不可再分的服务器单元提供，然后这些独立不可再分的服务器单元通过软件组成逻辑上的集群。相比之下，云架构被设计为资源抽象，如对存储、计算、网络以及运行时依赖资源的抽象，同时云架构也被设计成为多租户高可扩展的架构。云架构可以看成是多种逻辑服务的水平层面集合，这种水平层面并不是简单硬件设备的集合，而是云架构所提供的服务域（Zone），云架构上的水平层可以是API层、UI层、逻辑业务层等，如图1-23所示。

图1-23　云计算中基于逻辑服务的水平架构

针对云计算的架构环境，在云环境下要实现应用系统的HADR，需要遵循如下最佳实践原则：

避免单点故障（SPOF）。

构成应用系统的每个组件（负载均衡器、应用服务器、数据库）至少放置到两个AZ（Availability Zone）上。

在独立的AZ上预建足够的资源以容纳云宕机时AZ上需要进行迁移的云资源。

跨多个AZ进行数据同步复制或者跨区域（Region）进行数据备份以应对云宕机时进行应用程序的Failover，

AZ与Region的区别如图1-24所示。

设置监控、告警及故障识别和自动解决或自动Failover的运行机制。

构建弹性无状态的应用程序以便灾难发生时在安全的AZ内进行实例reboot或者relaunch以恢复应用正常运行。

上述最佳云计算HADR实践原则总结起来可以归为4个步骤，即为Server故障设计高可用、为Zone故障设计高可用、为Cloud/Region故障设计高可用、自动故障恢复与穷尽测试：

（1）针对Server故障的高可用设计

Server在云环境以Instance（实例）的形式存在，实例通常并不像传统的物理服务器一样被小心呵护长期使用，云环境下的实例在任何时候都可能被替换掉，因此，针对Server级别的高可用设计最根本的就是设计弹性无状态的应用程序，因为只有弹性无状态的应用程序才能原生态地适应云计算环境下的高可用，无状态应用可以通过迅速relaunch或者reboot实例而得到快速恢复，除此之外，还应该设计数据库的镜像（Mirror）备份、主从（Master/Slave）配置等以同步和保证数据的完整性，从而在宕机后迅速恢复数据可用性，在应用服务器的设计上应该尽量保证服务器的可扩展性，如果在成本预算上可以接受，则AWS的跨Zone自动扩展与数据同步复制高可用架构是最为理想的设计模式，如图1-25所示。

图1-25　AWS跨Zone自动扩展与数据同步架构

（2）针对Zone故障的高可用设计

在现实中，除了单个服务器故障外，还可能会出现数据中心的电源故障、网络故障、闪电雷击以及人为施工破坏等数据中心的故障，因此还需为你的应用考虑Zone故障。Zone是指一个使用独立电源，并且与其他Zone彼此隔离的数据中心，Zone内的Server共享高带宽、低延时、可通过私有网络访问的局域网。应对Zone故障的方案就是将每一个应用层的Server都扩展到至少两个Zones上，数据也需要进行至少跨两个Zone的复制，图1-25中的AWS高可用架构便是如此。

（3）针对Cloud/Region的高可用设计

从AWS的观点来看，Servers集群不是云，独立Zone也不是云，云是由多个Zone组成的Region，Zone与Region的关系如图1-24所示。Region就像岛屿（island），彼此之间不共享任何资源，它是一个有着自己独立API接入点的资源系统，并且在地理位置上相距很远，如亚洲Region与北美Region，通常将Region看成是真正的cloud。尽管一个Cloud发生出现故障的概率较低，但是如果要实现多个9的高可用性，那么跨Cloud的高可用设计也是需要考虑的，跨Cloud不仅仅是跨同一个供应商的Region，也可以是跨多个供应商的Region。

（4）自动故障恢复与穷尽测试

在设计了针对Server、Zone、Cloud故障的高可用架构后，应该让一切故障的Failover都变得自动化，因为在真正的故障发生时，时间极其珍贵，而你很可能正好没时间应对复杂的数据迁移与恢复等工作。任何HADR的设计都必须在考虑到全部故障点的充分测试下才能符合生产使用的要求，在高可用架构正式上线前，充分的压力和故障模拟测试是必经的过程。