OpenStack高可用集群(上册):原理与架构
上QQ阅读APP看书,第一时间看更新

1.5 传统IT架构高可用设计

1.5.1 传统数据中心HADR设计原则

任何HADR设计架构都需要遵循一定的高可用设计原则,对于一个成熟完善的HADR高可用解决方案,其架构设计必须包含以下基本模块Q. Dino, F. Steven, H. Mike, et al. High Availability and Disaster Recovery Planning: Next-Generation Solutions for Multiserver IBM Power Systems Environments[J/OL]. IBM Red Book.2010. http://www.redbooks.ibm.com/.

❑应用数据的高可用。对于很多企业来说,数据便是一切,任何HA和DR的恢复都要以数据为基础,没有数据则谈不上任何的恢复,因此,数据高可用是任何HA和DR架构设计首要考虑的基本元素。图1-19中的远程数据复制(Replication)便是数据高可用的设计体现之一,应用数据的高可用通常通过以下方式实现:

图1-19 HADR设计案例

○基于存储的数据冗余。基于存储的数据冗余分为本地集群的数据冗余和多站点之间的数据同步冗余,集群节点之间的存储并行访问和共享磁盘配置都属于本地集群数据冗余,并行访问常见的如NFS和GPFS文件系统,都允许集群多个节点同时读写存储。共享磁盘配置常见的如IBM的PowerHA共享盘,这是一种Active-Passive的访问模式,只有在Active的节点故障的情况下,磁盘锁才会被释放同时Passive节点才能读写共享盘。跨站点数据复制分为基于存储的数据复制和基于服务器端的数据复制。服务器端的远程数据复制主要通过镜像(Mirror)技术来实现;存储端的数据复制又分为同步复制(Synchronous Replication)和异步复制(Asynchronous Replication),异步复制意味着主节点应用程序可以继续执行而不用等待存储端的数据复制完成,同步复制则需要等待远程存储写完成的应答信号,因此同步复制的应用程序响应性能不如异步复制,但是同步复制在故障恢复时不存在数据丢失的情况,而异步复制无法做到这点。

○基于日志的数据复制。基于日志的数据复制功能主要应用在数据库的容灾恢复上,如IBM的DB2数据库便有HADR功能,其主要思想是数据库可以通过记录的操作日志来进行数据恢复。因此,备份了操作日志,便间接地备份了保存在数据库中的数据。

❑应用基础架构的高可用。基础架构设施为应用的正常运行提供了全部的软硬件资源,基础架构的高可用体现在两个方面,其一是提供在集群节点中重新启动应用所需的全部软硬件资源,其二便是通过监控和验证确保集群的完整性。应用基础架构的高可用最常见的便是双机主备或者双机互备集群环境,两个节点从物理硬件到操作系统软件和参数配置上都保持一致,主节点故障后,应用切换到备节点运行,由于备节点拥有与主节点几乎完全一样的环境,因此应用的重启不存在任何问题。

❑应用运行状态的高可用。在传统企业级业务系统中,很多应用是有运行状态的,如果要确保应用正常恢复,则需要保存应用的运行状态,并将恢复后的应用从故障前的最新状态点重新运行。应用程序的运行状态通常保存在内存中,而应用程序的恢复点依赖于你的应用程序设计和故障类型等很多环境因素,以DB2数据库为例,DB2每进行一次提交操作(Commit),则内存中的数据便会写入磁盘,数据库认为此次数据操作正常完成,而如果用户还没有提交便出现了宕机事件,则恢复后的应用(DB2数据库)不会从宕机时刻的状态开始重新启动,而数据库的恢复点应该是宕机前的最后一次提交操作点。就应用程序状态的冗余性设计而言,高可用性设计的重点应该在于监控应用程序栈的健康状况,通过集群HA的方式降低应用系统的恢复时间和切换时间,例如某些中间件便能够将主节点上的应用程序状态信息复制到集群备份节点的缓存中,通过这样一种设计方式,应用程序的切换和恢复便可得到加速。

1.5.2 故障划分与HADR高可用实现

在传统IT领域,高可用设计通常利用设备的冗余热备和软件的集群方式来实现,如IBM的z系列大型机便是利用每个关键部件的冗余设计来保证硬件层面上的高可用,当然这种大型机的设计思路也被应用到了很多小型机里面,包括IBM的POWER系列小型机和HP的Superdome等企业级服务器和存储设备。传统IT领域的高可用性设计主要分为硬件层面和软件层面的设计,而根据IBM的调查,硬件故障引起的宕机只占了小部分比例,接近50%的宕机事件是由软件问题和人为误操作引起的。而高可用性设计所要解决的问题便是引起业务系统宕机的各种故障,然后根据这些故障的特点进行针对性的高可用性设计。表1-2总结了可能引起宕机事件的故障组,这些故障组是高可用设计时需要考虑的首要因素。

表1-2 高可用设计故障归类

在业务系统出现故障的时候,HA有助于降低故障引起的业务中断时间,同时促使关键资源在高可用集群服务器之间进行可靠的故障切换,而在多站点容灾恢复的场景中(DR),高可用集群解决方案除了能够增强业务的高可用性之外,还能够管理和保障站点之间的数据复制,因此集合HA与DR的HADR高可用容灾解决方案将会是企业业务系统真正实现高可用和持续性运行的理想解决方案,并且HADR几乎可以覆盖表1-2中的全部故障组。一个典型的HADR设计案例如图1-19所示http://www.cnblogs.com/sammyliu/p/4741967.html.

图1-19中,本地数据中心与远程数据中心之间通过远程数据复制的方式实现数据容灾,本地数据中心内部构建HA集群,同时除了本地HA集群之间需要建立心跳检测机制之外,本地数据中心与远程数据中心之间也需要实现相应的心跳检测机制。如果本地数据中心内部的Master Server出现故障,则本地HA集群将触发资源切换(Failover),如图1-20所示。

图1-20 HADR架构设计中的HA切换

图1-20中发生HA故障触发资源切换时,并不会触发容灾恢复,此时远程数据复制仍然进行,数据中心之间的站点心跳也保持正常进行,此时如果本地数据中心出现灾难性事故,导致整个数据中心IT系统无法使用,则会立即触发DR容灾恢复过程,本地数据中心业务系统将全部迁移至容灾数据中心,或者说容灾数据中心将利用平时同步复制的数据进行业务系统的恢复,如图1-21所示。

图1-21 HADR架构设计中的DR切换