VERITAS Cluster Server 灾难恢复架构解析

newplayer

许多企业需要实施高可用性架构，同样，他们也需要对其关键任务应用和数据库实施灾难恢复/业务永续方案。如果能够充分利用现有的硬件和基础架构，那么就极有可能在有限的预算之内实现这些需求。进行灾难恢复的传统步骤包括多种方法，从标准的基于磁带的数据恢复到广泛区域内的同步数据复制。对于那些没有基础架构支持广泛区域内数据复制方案的企业，仍然可以采用其他方法获得应用和数据库的快速恢复，同时还能够对本文中所讨论的站点故障实施保护。
VERITAS 支持几种集群架构，满足多种数据中心的需求。本文意图详细解释各种数据中心的架构，并提供了配置每种架构的细节信息。
  
    理解灾难恢复的基本术语
  
    需要理解的两个关键概念是您的恢复点目标（Recovery Point Objective，RPO）和恢复时间目标（Recovery Time Objective，RTO）。发生故障或灾难时，对于恢复工作所需时间有一个清楚的认识是至关重要的，同样，了解现在的数据在恢复之后是什么样子的也同等重要。可能并非所有应用和数据库都需要相同级别的可用性，如下是对RPO和RTO的简要描述：
   
    恢复点目标（RPO）
  
    灾难或故障之后你能承受丢失多少数据？能够接受的丢失数据总量是多少？恢复点目标指的是必须把数据恢复如初的位置。
  
    企业必须制定令人满意的恢复点目标和恢复时间目标。很多人侧重于RTO或能够接受的停机时间。
    但是，它应该与考虑能忍受丢失多少数据同等重要。数据是至关重要的，数据的丢失（即使仅仅是几分钟、几小时或是几天）能给企业带来深远的负面影响。今天，许多公司灾难恢复计划的主要方法是依靠磁带进行备份和恢复。虽然磁带备份很重要且是一切全面的灾难恢复计划的基础，但是这通常意味着至少损失一天的数据和停机几天，原因来自于从磁带恢复的时间总量。这种方法也许能满足某种业务需求，但是如果不能满足，必须采取一些能够减少恢复数据时间的技术。
  
    恢复时间目标（RTO）
  
    恢复时间目标是恢复系统对数据的访问所需的时间。
  
    例如，如果客户宣称需要45分钟才能使应用系统恢复在线，可忍受的停机时间的极限是1小时，那么在实际的灾难中，只有15分钟时间制定强制切换决策点（Mandatory Decision Point）。
  
    强制切换决策点（Mandatory Decision Point）的 解释如下：
  
    一旦产生中断，时钟开始计时。最终用户将受到多长时间的影响？
  
    商业需求：需要应用在1小时内在线。问题：时钟是从灾难生的那一时刻而开始计时的，而不是备用系统开始启动的时刻。
   
    1.最多承受1小时的停歇
    2.故障检测时间耗费掉IT恢复时间
    3.即使仅仅是本地故障，仍然需要一些时间检测实际的故障
    4.这决定了强制切换决策点只有15 分钟
  
    计划内停机
  
    如果对应用、数据库或服务器进行升级或维护，在这期间使用集群是维持高可用性的必要方法。
  
    非计划内停机
  
    如果应用、数据库或服务器发生故障，运行在服务器上的服务将切换到其他服务器上，以避免长时间的停机，并且还要保持快速的恢复目标。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/1337/showart_18133.html