《OpenStack高可用集群（上册）：原理与架构》—1.5 传统IT架构高可用设计

1.5　传统IT架构高可用设计

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

任何HADR设计架构都需要遵循一定的高可用设计原则，对于一个成熟完善的HADR高可用解决方案，其架构设计必须包含以下基本模块：

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

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

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

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

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

OpenStack 存储

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。