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所示。

针对云计算的架构环境，在云环境下要实现应用系统的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所示。

（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的设计都必须在考虑到全部故障点的充分测试下才能符合生产使用的要求，在高可用架构正式上线前，充分的压力和故障模拟测试是必经的过程。

1.6.2 云计算HADR架构设计实现

对于HADR而言，永远都是方案越完善成本越昂贵，HADR与成本预算总是正相关，因此，企业在真正考虑自身业务系统的高可用设计时，不可能完全按照最完美的HADR方案来实现，很多中小企业和初创企业更是如此。因此，企业在设计高可用云计算方案时，应该在自身可以承受的高可用级别和能够接受的预算成本之间进行权衡，从而进行不同层次的HADR设计考虑。在云计算环境的HADR领域，有跨Cloud的冷备DR（Multi-Cloud Cold DR）、跨Cloud半热备DR（Multi-Cloud Warm DR）、跨Cloud热备DR（Multi-Cloud Hot DR）以及跨Cloud热备HA（Multi-Cloud Hot HA）几种方式，同时这几种HADR部署架构的RTO/RPO与预算成本成正相关关系，如图1-26所示。

如果企业仅希望降低成本，在云宕机出现后再将业务系统迁移到其他云上，则Cold DR方案是最佳选择，但是Cold DR方式是不能迅速恢复业务系统的，同步数据到其他云上也很缓慢，要将数据库启动到运行状态也很缓慢，企业通常要经历几个小时的业务中断才能重新恢复，以AWS部署为例，Cold DR的架构如图1-27所示。

如果企业希望以最小的额外成本和尽可能快的速度在另外的云上恢复业务系统，则Warm DR方案是最佳选择。在这种方案下，备份云中心运行Slave数据库的服务器，同时数据被实时复制到备份云中心，一旦主中心出现云宕机事故，便可在备份云中心迅速启动实例恢复应用系统，Warm DR的部署架构如图1-28所示。

Warm DR方案在灾备云中心并不同时运行实例，而只进行数据层面的备份与同步，相比之下，Hot DR方案不仅在灾备云中心进行数据层面的保护，还同时运行同等规模的应用实例，但是灾备云中心的实例并不负载客户的访问请求，一旦主中心出现云宕机事故，则灾备中心的云实例迅速接管用户访问请求。与Warm DR方案相比，Hot DR方案显然要支付更多的费用，并且在云环境与传统IT数据中心不同，启动应用实例的速度本身已经非常快，因此Hot DR的恢复时间不会比Warm DR高很多，但是费用却要昂贵得多，因此并不推荐Hot DR的方案，Hot DR的架构如图1-29所示。

跨云DR方案虽然可以保证企业应用的恢复，但是始终存在中断时间，对于大型企业，尤其是金融领域的企业而言，业务中断是不能允许的，因此跨云HA（Multi-Cloud HA）将是最佳选择，Multi-Cloud HA类似于传统数据中心的双活方案，主备云中心均同时运行同一套应用系统，并通过负载均衡器实现跨地理位置的负载均衡，打通云之间的网络后实现应用服务器的跨云扩展部署和数据存储，这样即使主备云中心出现云宕机事故，企业应用系统均不会中断，真正实现了云架构上应用系统的高可用，但是Multi-Cloud HA架构的成本费用也将最昂贵的，面临的技术难题也是最多的，因此通常是具有成熟技术和资金实力的大型企业才会选择Multi-Cloud HA的架构模式，Multi-Cloud HA的架构如图1-30所示。