同城应用容灾系统方案

1、同城应用容灾系统方案 PAGE 第 PAGE 48 页 共 NUMPAGES 48 页同城应用容灾系统方案目 录 TOC o 1-4 h z u HYPERLINK l _Toc485651052 1容灾系统需求 PAGEREF _Toc485651052 h 3 HYPERLINK l _Toc485651053 2容灾技术的选择 PAGEREF _Toc485651053 h 3 HYPERLINK l _Toc485651054 2.1基于SAN城域网的镜像技术 PAGEREF _Toc485651054 h 3 HYPERLINK l _Toc485651055 2.2构建容灾系统的技

2、术要求 PAGEREF _Toc485651055 h 5 HYPERLINK l _Toc485651056 3容灾系统建议解决方案拓扑图和配置说明 PAGEREF _Toc485651056 h 6 HYPERLINK l _Toc485651057 4VERITAS基于镜像技术的容灾方案及其实现 PAGEREF _Toc485651057 h 7 HYPERLINK l _Toc485651058 4.1数据容灾方案的实现 PAGEREF _Toc485651058 h 7 HYPERLINK l _Toc485651059 4.1.1方案的结构原理 PAGEREF _Toc485651

3、059 h 7 HYPERLINK l _Toc485651060 4.1.2数据系统故障和灾难的响应 PAGEREF _Toc485651060 h 10 HYPERLINK l _Toc485651061 4.1.2.1生产中心数据系统故障 PAGEREF _Toc485651061 h 10 HYPERLINK l _Toc485651062 4.1.2.2灾备中心数据系统故障 PAGEREF _Toc485651062 h 11 HYPERLINK l _Toc485651063 4.1.2.3生产中心和灾备中心SAN链路故障 PAGEREF _Toc485651063 h 11 HY

4、PERLINK l _Toc485651064 4.1.3方案的技术优势 PAGEREF _Toc485651064 h 14 HYPERLINK l _Toc485651065 4.1.4对系统性能的影响 PAGEREF _Toc485651065 h 18 HYPERLINK l _Toc485651066 4.1.5容灾案例 PAGEREF _Toc485651066 h 19 HYPERLINK l _Toc485651067 4.2构建完整的应用级灾备中心 PAGEREF _Toc485651067 h 21 HYPERLINK l _Toc485651068 4.2.1纯手工应用灾

5、备的问题 PAGEREF _Toc485651068 h 21 HYPERLINK l _Toc485651069 4.2.2建立覆盖灾备中心的统一集群体系 PAGEREF _Toc485651069 h 24 HYPERLINK l _Toc485651070 4.2.2.1跨越几十公里的心跳技术支持 PAGEREF _Toc485651070 h 25 HYPERLINK l _Toc485651071 4.2.2.2为什么需要人工确认灾难 PAGEREF _Toc485651071 h 26 HYPERLINK l _Toc485651072 4.2.2.3建立一个满足灾备需要的集群系统

6、 PAGEREF _Toc485651072 h 27 HYPERLINK l _Toc485651073 4.2.3业务系统故障和灾难的响应 PAGEREF _Toc485651073 h 29 HYPERLINK l _Toc485651074 4.2.3.1生产中心主业务服务器不可用 PAGEREF _Toc485651074 h 29 HYPERLINK l _Toc485651075 4.2.3.2生产中心所有服务器不可用 PAGEREF _Toc485651075 h 30 HYPERLINK l _Toc485651076 4.2.3.3生产中心和灾备中心之间心跳链路故障 PAG

7、EREF _Toc485651076 h 31 HYPERLINK l _Toc485651077 4.2.3.4生产中心所有服务器和磁盘系统不可用 PAGEREF _Toc485651077 h 32 HYPERLINK l _Toc485651078 4.2.4方案的优势 PAGEREF _Toc485651078 h 33 HYPERLINK l _Toc485651079 5附件：VERITAS Cluster Server简介 PAGEREF _Toc485651079 h 36 HYPERLINK l _Toc485651080 5.1业界领先的企业高可用应用解决方案 PAGERE

8、F _Toc485651080 h 36 HYPERLINK l _Toc485651081 5.2VERITAS Cluster Server产品要点 PAGEREF _Toc485651081 h 36 HYPERLINK l _Toc485651082 5.3VERITAS Cluster Server的先进性 PAGEREF _Toc485651082 h 38 HYPERLINK l _Toc485651083 5.4VERITAS Cluster的特点和好处 PAGEREF _Toc485651083 h 40 HYPERLINK l _Toc485651084 6VERITAS

9、Storage Foundation for Oracle RAC概述 PAGEREF _Toc485651084 h 42 HYPERLINK l _Toc485651085 双磁盘阵列实现RAC系统存储支持案例 PAGEREF _Toc485651085 h 47容灾系统需求1号线工程经国家发展和改革委员会国家发展改革委关于杭州市地铁1号线工程可行性研究报告的批复(发改投资2006684号)核准同意建设，并已列为浙江省重点建设项目。项目建设规模为全长54公里，车站33座、总投资约为22076亿元人民币，建设地址位于杭州市，计划于2011年建成。而的IT系统是职能正常运转的重要支撑。考虑到I

10、T系统的重要性，为了保证IT系统的正常运转，保证和提高的服务能力，准备建立现有IT核心业务系统的应用容灾系统。目前，的核心业务系统主要为数据库系统为Oracle ，运行在两台小型机系统上。考虑到核心数据库系统的安全和可靠，准备在同城建立现有数据库系统的数据容灾系统，并可以简单地实现生产系统的应用级容灾。容灾技术的选择基于SAN城域网的镜像技术目前实现容灾的技术方案看起来很多，不过目前比较通用的和实用的容灾技术，主要有两类，一种是基于主机的容灾方案，一种是基于磁盘系统的数据复制的容灾方案。而随着光纤存储网络技术的成熟和在距离上的拓展，光纤城域存储网络的实现已经趋于成熟，这就使得我们今天可以不再需

11、要依赖复杂的数据复制技术，就可以实现同城容灾了。新的容灾方案所利用的，是最为传统的磁盘镜像技术，也就是说我们可以利用基于城域SAN存储网上的镜像技术，轻松实现数据容灾，然后在此基础上，我们可以利用先进的集群软件，构建应用级的容灾系统，以满足对容灾的需要。为什么我们建议选择基于镜像技术的容灾方案？成熟性：镜像技术是从磁盘容错技术中最成熟、历史最悠久、可靠性最高的数据保护技术。简单性：镜像技术是实现最为简单的数据容错技术异构性：镜像技术不仅可以在磁盘阵列内部实现，也可以跨越不同磁盘系统来实现，镜像技术完全不依赖于磁盘系统的品牌和型号。所以，利用镜像技术实现容灾，我们就可以保留在任何时候自由、灵活的

12、选择磁盘系统的权利。为什么以前比较少用镜像做容灾，而用复制做容灾？在SCSI技术时代，SCSI只能支持25米的距离，所以虽然基于磁盘系统间的镜像被广泛采用，但无法实现远距离容灾远程复制技术可以很好的解决远距离和低带宽带来的问题，所以一直以来，是容灾方案的主要选择。FC光纤存储出现以后，为远距离镜像提供了可能，随着同城光纤存储网络的普及，利用镜像技术构建同城容灾系统，将是一个即简单、又实用的容灾解决方案。为什么现在不建议采用基于磁盘系统的复制来构建容灾系统？数据复制技术所能解决的距离和带宽的问题，当前已经不再是问题了利用数据复制技术实现容灾，由于其技术本身的局限性，必然导致容灾系统的结构要比没有

13、容灾系统的时候复杂得多。同时，这样的容灾系统的故障环节不可避免的会增加，导致维护难度、维护成本的增加。基于磁盘系统的数据复制技术，要求生产中心和灾备中心选用同一个厂商的磁盘系统，甚至要求选用同一系列、同一型号的磁盘系统，用户完全失去讨价还价的余地，完全失去了在任何时候自由、灵活地选择合作厂商和磁盘系统的权利，必然给用户造成被动和经济上的损失。总上所述，针对的容灾系统建设，我们认为，既然我们可以提供基于光纤的城域SAN网络，那么，我们就没有必要再采用过时的基于磁盘系统数据复制的容灾方案，采用基于主机镜像技术来实现容灾方案，应该是一个更好的选择。构建容灾系统的技术要求基于磁盘镜像技术构建容灾系统，

14、在数据系统容错实现的逻辑上，和本地磁盘系统间的镜像没有任何区别，所以我们大可以放心的去构建这样的系统。但是，在实际应用环境中，我们还是发现了一个不同的地方，是我们在考虑容灾方案的时候必须解决的，那就是“距离”。不是说我们已经解决了距离的问题吗？是的，我们在技术上已经解决了远距离数据镜像的问题，但是，有几个问题是任何技术都必须考虑的，不管是镜像技术还是复制技术，包括：距离决定了链路的可靠性。我们在短距离（比如一个机房内）可以忽略不计的链路故障（可以通过链路冗余解决）在长距离上就无法忽略了，比如，我们无法保证我们的光纤不会被野蛮施工挖断。距离会影响我们管理一个系统的复杂性和现场感远距离灾备系统永远

15、都是生产中心的附属品，如果我们不能将其用直观的方式纳入到日常的管理体系中，很快我们就会发现我们对生产系统和灾备系统的管理会脱节，所以，容灾系统肯定不仅仅是镜像那么简单，他需要一个完整的、直观的管理界面去管理，才能形成一个行之有效有的灾备系统。所以，我们在构建容灾系统的时候，必须考虑由距离引起的问题给我们的技术方案造成的各种负面影响，并要很好的解决它。有关问题和解决方法，我们会在下一节中详细论述，这里我们先简单的把要求提出来，供参考。对磁盘镜像容灾管理的要求：可视化磁盘管理和容灾管理应对链路故障引起的各种问题：实现增量镜像和避免Split-Brain等容灾系统建议解决方案拓扑图和配置说明配置：V

16、eritas Storage Foundation Enterprise HA/DR for Oracle RAC *4说明：Veritas Storage Foundation Enterprise HA/DR for ORACLE RAC可以实现本地数据和异地数据的卷级镜像，实现数据的快速同步，并可以实现ORACLE数据库安装在文件系统上而且具有裸设备的性能。同时Veritas 高速文件系统也能提高数据访问和读写的性能。该license中包括的Veritas Cluster server可以实现ORACLE数据库的切换，并和应用服务器相结合实现应用级容灾。每台服务器需要配置1个LICENS

17、E.VERITAS基于镜像技术的容灾方案及其实现基于镜像技术实现容灾，从技术实现上，分为两个部分，其一是数据的容灾实现，其二是应用级容灾实现。下面，我们就分别从这两个方面入手，论述VERITAS的容灾方案。数据容灾方案的实现方案的结构原理VERITAS建议利用VERITAS Volume Manager软件的镜像技术，来构建IT系统的容灾方案。利用VERITAS Volume Manager的镜像技术构建容灾系统是非常简单的，它只有一个条件，就是将生产中心和灾备中心之间的SAN存储区域网络通过光纤连接起来，建立城域SAN存储网络。然后，我们就可以通过Volume Manager提供的非常成熟的

18、跨阵列磁盘镜像技术来实现同城容灾了，容灾方案的结构如下图所示：从原理上讲，在城域SAN存储网络上的两套磁盘系统之间的镜像，和在一个机房内的SAN上的两个磁盘系统之间的镜像并没有任何区别。就如上图，如果我们把“同城容灾中心”几个字去掉，我们就无法分辨左边的系统和右边的系统到底是在同一个机房，还是远在几十公里以外。利用光纤将生产中心和灾备中心的SAN网络连接起来，构成城域SAN网络以后，利用 VERITAS Volume Manager的先进的逻辑卷管理功能，我们就可以非常方便的实现生产中心磁盘系统和灾备中心磁盘系统之间的镜像了。如下图所示。这里，逻辑卷“Volume A”是业务系统访问磁盘的逻辑

19、设备名，在VERITAS Volume Manager管理下的磁盘系统，所有业务系统对磁盘系统的访问，都将通过Volume实现。我们可以看到，利用VERITAS Volume Manager，我们可以创建任意一个逻辑卷（Volume）供业务主机使用，比如“Volume A”，这个“Volume A”实际上是由两个完全对等的，容量和“Volume A”相同的磁盘片构成的，我们这里可以称在生产中心磁盘系统上的磁盘片为“Volume A : Plex 1”，而称在灾备中心磁盘系统上的磁盘片为“Volume A : Plex 2”，这两个磁盘片上的数据完全一样，业务主机对该Volume的任意修改，都将

20、同时被写到位于生产中心和灾备中心的两个磁盘系统上。采用这种方式，生产中心的磁盘阵列与同城容灾中心的磁盘阵列对于两地的主机而言是完全同等的。利用城域SAN存储网络和VERITAS Volume Manager镜像功能，我们可以非常轻松的实现数据系统的异地容灾。下面，我们来看一下，在各种数据系统（本节暂时不讨论应用系统全面灾难的应对，我们把它放到下一节中另行展开讨论）故障和灾难情况下，容灾系统是怎样响应的。数据系统故障和灾难的响应在建立了容灾系统以后，数据系统的故障和灾难主要将发生在3个地方（请注意，没有建立容灾系统时，数据系统的主要故障点是1个）：生产中心数据系统故障生产中心数据系统故障意味着灾

21、难，这也就是我们现在建立容灾系统的根本目的，对于这样的灾难，我们来看一下我们推荐的容灾方案是如何响应的，见下图：当生产中心的磁盘系统发生故障（灾难）时，由于同城容灾中心的磁盘是它的镜像，所以操作系统会自动隔离生产中心的磁盘，转而对容灾中心的数据进行访问。从上图我们看到，业务系统可以通过城域SAN网络直接访问灾备中心的磁盘系统的数据，而不需要有任何针对业务系统的动作。也就是说，生产中心磁盘系统的灾难，对业务系统是透明的，应用和数据库不会因为生产中心磁盘系统的故障而停止；更重要的是，因为应用和数据库不会因为灾难而异常中止，从而避免了发生数据库损坏的可能。生产中心磁盘系统故障之后，我们只需要更换损坏

22、的磁盘系统，然后利用Volume Manager重新生成镜像即可，重新生成镜像的过程，实际上就是将数据从灾备中心磁盘系统复制到生产中心磁盘系统的过程。值得注意的是：整个过程对应用完全透明，不需要也不会中断业务系统的正常运行。这是基于磁盘系统间复制技术构建的容灾系统无法实现的。灾备中心数据系统故障灾备中心数据系统故障，这是灾备系统建立以后出现的新问题，这种故障就同上一种故障类似，但对业务系统的影响更小。生产中心和灾备中心SAN链路故障这种故障也是灾备系统建立以后出现的新问题。相对于以上两种灾难，这种故障在容灾系统建立以后，出现的概率会更大一些，导致链路故障的原因很多，包括光纤断裂，光端设备故障等

23、，都会导致链路中断。这个问题其实是由“距离”引起的，正如我们在前面讨论的那样，虽然在原理上，基于城域SAN网络实现的镜像技术和基于本地SAN网络实现的镜像技术完全一样，但是，我们还是不得不承认，他们是有区别的，因为我们很少会担心一个机房内部不同磁盘系统之间的镜像会遭遇链路故障，而在城域范围，我们是无法回避这个问题的。一个完整的灾备系统，除了在数据灾难发生时，能够完成灾备的使命，同时，也需要考虑，灾备系统本身的可维护性和可操作性。而对于链路故障，直接导致的就是业务数据在写到本地磁盘系统的同时，无法写到灾备系统中，对于镜像技术而言，这又成为一个新的课题。传统的镜像技术，在镜像链路被中断以后，中断的

24、镜像会被认为完全作废，在链路恢复以后，我们不得不将数据完整地从“Volume : Plex 1”拷贝一份到“Volume : Plex 2”，如下图所示。这将对业务系统的I/O性能造成不必要的影响，链路方面的故障如果经常发生，我们就需要不断的重复将生产中心的数据全部同步到灾备中心的磁盘系统上，实际上，这种方案不具有可实施性和可维护性，是不现实的。这也是什么主机厂商虽然也有类似镜像功能，但不会用于容灾的的根本原因。为了解决这个问题，VERITAS Volume Manager提供了DCO+FMR技术，其中DCO（Data Change Object）是一种针对镜像的Log技术，该技术允许Volu

25、me Manager在镜像链路中断后记录逻辑卷的数据变化情况，以便在镜像链路恢复后，由FMR实现数据的增量恢复。所谓FMR，其全称是Fast Mirror Resync，意思就是“镜像的快速再同步”，FMR是和DCO技术对应的镜像快速恢复技术，利用VERITAS Volume Manager 的DCO和FMR技术，我们现在可以不用再担心容灾系统本身的可维护性了。利用DCO和FMR，针对同样的链路问题，我们的应对步骤如下：SAN链路发生故障生产中心的Volume Manager利用 DCO日志记录Volume : Plex 1 因业务数据的变化而变化的数据块，灾备端Volume : Plex 2

26、的数据不会作废一旦SAN链路恢复正常，Volume Manager的FMR功能模块，会根据 DCO日志记录的情况，将Volume : Plex 1 中链路中断后更新的业务数据拷贝到灾备端Volume : Plex 2，实现增量更新。Volume Manager 用DCO和FMR技术实现增量同步的过程如下图所示：方案的技术优势和其他容灾方案相比，VERITAS容灾方案具有明显的优势，这些优势不仅仅表现在技术实现方面，还表现在开放性、可维护性等各个方面。结构简单VERITAS推荐的基于镜像的容灾方案较任何一种容灾方案为简单。在一个使用逻辑卷管理的应用系统中（逻辑卷管理的好处我想大家已经深有体会，我

27、想我在这里就不需要重复了），我们只是利用了其中最常用、最成熟的镜像功能，就可以实现容灾，而不必像其他容灾系统那样增加很多不必要的环节。比如基于磁盘系统复制技术的容灾方案，我们必须在磁盘系统内部专门配置相应的接口卡，使用该磁盘系统专有的复制软件，才可以构建容灾系统。明显的，该方法增加了一个在非容灾系统中完全不需要的环节，不仅增加了故障源，同时也增加了维护强度。事实上，基于主机的复制技术存在同样的问题。技术成熟镜像技术是比任何数据复制技术更早使用于高可用系统的成熟的功能，这种功能已经广泛应用于包括IBM Mainframe、AS400、RS6000、HPUX、Digital Unix、SUN So

28、laris、Linux、Windows等在内的所有服务器系统上，同时也被广泛用于磁盘系统内部作为企业级解决方案，象EMC、HDS、HP、IBM、SUN、Compaq等众多存储设备生产厂商，都将镜像技术内置于其磁盘系统内部，用于对数据可用性要求最高的用户群。存储开放性利用VERITAS Volume Manager的镜像技术，我们构建容灾方案时，不再要求生产系统和灾备系统的存储系统必须是同一个品牌的，对具体型号更没有任何要求，体现了存储平台选择的开放性。由此，用户可以获得在存储平台选择上的主动权，避免被存储厂商“绑架”的尴尬。技术的完整性VERITAS Volume Manager拥有一个容灾方

29、案必须的所有技术特性，它不仅可以提供可靠的镜像技术，实现跨磁盘系统的数据容灾，同时，我们可以利用Volume Manager 的DCO和FMR技术，保证该容灾系统的可维护性。容灾系统的可视化管理一个灾备系统和生产系统是一个整体，而不是两个孤立的系统，一个系统的可视化管理工具，有利于管理者将两个系统有机的结合起来，而不是分别处理两个独立的系统。VERITAS Volume Manager VEA 提供企业范围内全局的逻辑卷管理视图，通过任何一台安装有Volume Manager或者其Console的系统，我们就可以访问我们想要访问的系统的（被授权）逻辑卷，这意味着，我们可以将同一个应用的生产系统

30、和灾备系统的逻辑卷置于同一个管理视图中，从而实现对生产中心和灾备中心存储的统一管理。VERITAS VEA管理界面丰富，下图为其中一个管理界面，仅供参考。应对灾难，应用不中断，数据不丢失VERITAS建议的容灾方案，不会因为生产中心（或者灾备中心）磁盘系统的故障和灾难而导致应用和数据库的异常中止，这不仅避免了对应用系统正常运作的影响，还避免了发生数据库损坏的可能。相比较而言，如果采用数据复制的方式（无论是基于磁盘系统的硬件复制方式还是基于软件的数据复制方式），都需要在生产中心故障时对数据系统进行切换操作，反而造成业务的停顿。另外，由于在灾难发生时，数据库系统的复制是即刻停止的，数据库系统没有经

31、过正常的Shutdown，所以不仅不可避免的导致部分交易的损失，甚至还有可能导致数据库的损坏。I/O效率最佳从性能上来分析，在操作系统一级进行镜像，数据会在同一时间写入到两地的磁盘。数据可写入过程是两组并行的操作，即本地写和完成信号返回+异地写和完成信号返回。而相比较而言，数据复制技术需要通过以下4个步骤才算写操作完成：数据先有操作系统写入本地磁盘系统磁盘系统将数据通过链路复制到异地系统异地磁盘系统完成写操作，返回信号给本地磁盘系统本地磁盘系统返回信号给操作系统明显的，这个过程和直接数据镜像相比，把原先并行的2组步骤变成了纯串行的4个步骤，并且需要SCSI到复制协议的转换过程，无论在流程上和反

32、应时间上都会比直接镜像造成更多的延时，对应用系统有更大的影响。另外，在逻辑卷这个层面，我们可以根据需要对镜像的数据灵活设置，我们不需将所有磁盘进行镜像，而只需镜像必要的逻辑卷（Volume）。这种灵活性在实际使用过程中将大大减少数据远程复制的数量，从而避免对系统不必要的影响。对系统性能的影响大家都比较关心容灾系统建立以后对原有业务系统性能的影响，考察容灾系统对业务系统性能的影响，主要从两个方面衡量，一是CPU资源的消耗，二是I/O，特别是写操作的延迟效应。CPU资源消耗采用主机端的软件镜像技术，对CPU资源的损耗，实际上是微乎其微的，但很多时候被磁盘系统厂商人为的夸大了。具体的事实我们可以通过

33、简单的测试得到，我们可以设置这样一个测试，就一目了然了：1）在测试系统上，往一个没有镜像的逻辑卷Copy一个大文件，察看CPU使用率；2）在测试系统上，往一个有镜像的逻辑卷上Copy一个大文件，察看CPU使用率。事实上，处理镜像需要的CPU时间是非常非常小的，原因是磁盘I/O操作的速度是毫秒（ms）级的，磁盘系统Cache I/O的速度是受限于光纤通道的100-200MB（8bit*10ns）带宽和距离（15公里 = 0.1ms）的，而相反的，高端主机总线的宽度一般是64-128Byte，甚至更高，主机CPU的处理速度更是在千兆的水平（ns级），所以I/O对主机CPU的消耗往往都是可以忽略不计

34、的，如果说需要关心的话，也主要针对象RAID-5这样的技术（需要大量计算，从而消耗主机的CPU资源），而像镜像这样的技术，是几乎不需要消耗CPU时间的。I/O的延迟效应（特别是写操作的延迟效应）采用VERITAS Volume Manager的镜像技术构建容灾系统，其对系统 I/O的延迟效应要小于任何一种数据复制技术，不管是基于磁盘系统的硬件数据复制技术，还是基于主机软件的数据复制技术，这在上一节中已经阐述。这里我想要补充的是在整个容灾系统中，对业务系统的性能的影响最大的不是任何一种技术所产生的负面作用，而是“距离”，正如前面提到的，在Cache命中率较高的系统中，距离对写操作的影响较大，这和

35、光的传播速度有关，光在150公里距离上的一个来回需要1ms，在15KM距离上一个来回需要0.1ms，我们列出一个对照表，供大家参考。本对照表不包含设备协议转换和光在光纤中的折射等因素。同时，我们知道，100MB光纤对应的速度是ns级的。距离光传输距离传输时间说明15 km30 km100us同城容灾中心的距离级别150 m300 m1us15 m30 m100ns一个机房的内部距离1.5 m3 m10ns一个主板的内部距离本地Cache写的时间nsus级本地磁盘写的时间usms级综上所述，我们的结论是，只要是数据复制方式的同步方式能够做的系统，采用镜像方式也一定能做，而且会做的更好。容灾案例中

36、国银联IT中心的同城容灾中心项目中国银联的信息中心的同城容灾中心，就是选择了VERITAS Volume Manager的镜像技术来构建的，其生产中心和灾备中心分别位于上海市的浦东和浦西，两地相距超过30公里。芜湖卷烟厂信息系统的同城容灾项目另外，VERITAS 拥有丰富的容灾系统实施经验，我们参与的容灾项目除了采用镜像方式的，还有利用传统的数据复制方式构建的容灾系统，包括：中国联通光传输网络系统中国联通光传输网络的容灾系统是由VEITAS通过华为提供的，这个方案是跨省际的，其中一个容灾项目的生产中心和灾备中心分别在北京和广州。VERITAS提供的这套超远程容灾方案是国内目前业界唯一真正已实施

37、的超远程容灾方案。要实现这种方案，我们只需要在现有的Volume Manager的基础上增加VVR模块，体现了技术和方案的延续性。上海热线的容灾系统公安部某应用系统从上海到广东南海的远程容灾项目构建完整的应用级灾备中心纯手工应用灾备的问题本次需要构建的不仅仅是数据容灾中心，我们需要构建的是应用级的同城灾备中心，所以除了要考虑在灾备中心购置等量的存储用于数据灾备以外，我们还需要购置同等处理能力的服务器系统作为灾备应用和数据库服务器，以便在灾难发生时，能够完整的接管整个业务系统，包括数据和业务处理能力。两套系统配置难以完全同步的风险对两套系统的管理是孤立的，而这两套系统应该是在各方面都相同的并严格

38、的一一对应的。这种局面除了导致管理复杂之外，同时还带来了两套系统配置不能及时同步、不能完全同步等风险。这种风险将直接导致灾备中心在灾难发生时不能准确、及时地接管业务系统，这和我们建立该容灾中心的基本要求“必须保证容灾中心在一小时以内全面接管生产中心的作用”是相背的。事实上，我们在生产中心建立集群系统的时候，集群系统不仅给我们提供了主机故障时的业务接管功能，同时，还给我们提供了保证业务主机和备用主机之间配置的一致性的同步资源管理功能。一个系统对另外一个系统的顺利接管，需要日常的、长期的维护和精心的准备，而不是简单的在备用系统上输入几个命令来完成的，而集群软件为这种需要提供了行之有效的方法。本地的

39、主服务器和备用服务器之间尚且如此，那么生产中心和灾备中心之间该如何处置呢？事实上，完全靠人工去保持生产中心和灾备中心这两个不在同一个机房的系统的配置保持动态一致，是一件费力费神的事情，同时还是一件费力不讨好的事情。这种手工操作方式不利于灾备中心的可靠性、稳健性。灾备中心接管难度大由于在灾备中心和生产中心之间没有集群系统，灾备中心对生产中心的接管将完全依赖于手工，这无谓的加大了灾备中心接管的难度，在各种因素引起的专业技术人员不能及时到位的情况下，这种难度将直接导致灾备中心不能及时的、成功的接管业务。我们知道，我们建设的是“灾难”备用系统，灾难的定义不是简单的“磁盘系统故障”，它可能是任何情况。所

40、以灾备中心的接管流程要求：1）全面，包括简单的，也包括复杂的；2）尽量提供简单的流程。管理难度大生产中心和灾备中心两套系统完全孤立，没有办法同时监控，更不用说在一个界面上对这些系统统一监控和管理了，我们难以同时对两地配置进行跟踪和修改，无谓的增加了灾备系统维护的难度和强度。解决以上问题的办法是：在生产中心和灾备中心之间构建高可用集群系统。就如同我们在一开始所讲的，在城域SAN网络上构建的镜像系统和在同一个机房内部构建的镜像系统在逻辑上是完全相同的，同样的，我们要推荐的在城域SAN网络上构建的集群系统和在同一个机房内部构建的集群系统在逻辑上也是完全相同的。城域范围内和镜像技术配套的集群技术，和用

41、于远程复制技术下构建远程集群的技术不同，我们这里推荐的城域范围的集群系统不是传统的远程集群模式，而是传统的本地机群技术的扩展。实际上，它所采用的软件产品和基本技术，完全就是本地集群软件，只是，我们需要这些集群软件提供必要的功能扩展，以满足城域范围的特定的需要。在这里，我们称这种模式为“准本地集群”模式，也可以称为“Campus Model”。“准本地集群”模式实际上和大家非常熟悉的本地集群模式是一样的，在这种模式下，生产中心的系统和灾备中心的系统将被纳入同一个集群主体中，从而我们可以非常轻松的实现对两个中心的统一管理。其结果，就是给我们带来管理的简单化和灾备系统的可靠性。下图为利用VERITA

42、S集群软件VERITAS Cluster Server (VCS) 进行集群管理的一个界面示意，通过该界面，我们可以知道，利用VCS，我们可以非常方便的管理生产中心和灾备中心的系统，并将生产中心和灾备中心纳入到统一个集群管理体系内进行统一管理。当然，在我们构建这个“准本地集群系统”的时候，我们还是要正视由“距离”引起的一切问题，我们需要在技术层面去解决它，这也是为什么我们在方案中建议的集群软件是和本地集群完全相同的VERITAS Cluster Server软件，但却称这种集群模式为准本地集群模式的原因。建立覆盖灾备中心的统一集群体系为了有效的管理灾备中心，同时保证在灾难发生的时候，能够在要求

43、的时间里快速的恢复系统的正常运行，我们需要建立一个横跨业务中心和灾备中心的“准本地集群系统”，这里，我们建议采用通用的本地高可用集群软件（也称HA软件），构建的应用容灾系统。我们都非常熟悉如何利用HA软件来建立集群系统的，目前的许多系统都有各种各样的 HA软件，那么是否所有的集群软件都可以支持这种“准本地集群系统”呢？ 答案是“NO”！构建“准本地集群系统”，我们需要在原有的集群系统的功能上有新的扩展，以便满足城域环境下的特殊要求。我们现在分析一下同城集群系统和本地集群系统的区别，然后再来分析需要怎样的技术扩展。在磁盘镜像结构和集群系统结构上，“城域SAN+城域 IP网络”的环境和本地系统没有

44、什么逻辑上的区别，但是就集群系统而言，仅仅是距离的变化，就会导致以下两个新问题（距离对镜像技术的影响和相应的方案，我们在数据容灾一节已经详细阐述，这里不再说明）：集群系统的心跳线需要跨越几十公里，而不是几十米同城生产中心和灾备中心的网络更容易因意外而中断，其中包括心跳线这两个因为距离而产生的新问题，需要我们在构建集群系统时，不得不从技术层面仔细分析，以便保证我们推荐的方案的可靠性和可行性。下面，我们就这两个问题从技术层面展开讨论。跨越几十公里的心跳技术支持城域集群将跨越几十公里，这对集群心跳的技术要求非常简单，就是要求集群软件能够支持跨越几十公里的心跳技术。VERITAS Cluster Se

45、rver能够很好的支持远程心跳通道，VCS对远程心跳通道只有一个要求，就是支持广播。也就是说，只要两个Site之间有不经过路由器、桥这样的设备的通道，就可以支持VCS的心跳。需要说明的是，我们这里需要心跳的动机和传统的心跳技术的目的不同，传统的集群心跳的目的包括：同步集群配置信息和集群状态信息监控Active的业务服务器是否运行正常根据监控信息，激发集群在主业务服务器系统没有相应的时候，自动切换服务器。但是，我们这里需要心跳的目的只包含前两条，而不包含最后一条，原因是我们的生产中心灾难后的切换，应该是在人工确认后手动发起的，我们不需要自动切换。但不管怎样，我们还是需要心跳来构建这样的集群系统。

46、为什么需要人工确认灾难我们好像已经已经习惯了“生产中心到灾备中心的切换需要人工确认的”这个规则了，我们也已经习惯了“如果不经过人工确认，就有可能导致误操作”这种说法了，但是为什么本地集群系统就可以自动切换呢？我们的“准本地集群系统”和真正的本地集群系统在逻辑上是相同的，为什么我们还是需要坚持采用“灾难人工确认”原则呢？其实，在“没有必要自动切换”的说法背后，其真正原因是：凡是远距离的集群系统，都无法象本地集群系统那样，可以提供足够可靠的心跳通道。我们知道，本地集群系统可以提供多种冗余技术，保证心跳通道不在同一时间一起中断，常见的心跳冗余技术有：采用双以太网卡作为冗余心跳通道采用双RS232端口

47、作为冗余心跳通道采用公网（业务以太网通道）作为辅助冗余心跳通道采用共享磁盘作为辅助冗余心跳通道相对而言，远程集群系统除了能够利用远距离以太网连接作为心跳以外，就没有其他冗余措施了，我们知道，城域范围的网络本身的可靠性要比一个信息中心内部的专用网络的可靠性低很多的，而且具有更多的不确定性，比如，一次光纤事故就可能会导致所有的心跳通道同时中断。如果我们无法保证心跳通道的可靠性，那么就有可能出现因为心跳通道本身的故障而引起的“虚假灾难”，也就是说，当主业务系统实际在正常运行的情况下，备用系统却因为无法收到对方的心跳而认为对方已经“停止运行”，并强行接管数据和网络系统，这种情况在技术领域我们称为“Sp

48、lit-Brain”，也就是说一份数据，两个大脑。这种情况对数据系统是非常危险的，两个服务器对一个数据资源的强制争用，会导致业务数据的不一致，更有甚者，会导致业务数据的不可逆损坏。一个“假灾难”会引起“真灾难”的发生，这是谁都不会允许的。除非我们有足够可靠的心跳安全技术和策略，否则，为了避免这种“意外灾难”的发生，我们都会建议在灾备系统的接管策略上，采用“灾难人工确认”原则的。这里，我想补充说明一下，实际上，我们推荐的VERITAS Cluster Server可以提供其他特有的技术手段来弥补远距离心跳安全性方面的缺陷，严格来讲，VCS可以支持容灾系统的远程自动切换。通过配置I/O fenci

49、ng仲裁盘方式可以规避由于心跳原因造成的“裂脑”现象。但是我们原则上还是建议异地应用容灾采用“灾难人工确认”原则。建立一个满足灾备需要的集群系统现在新的技术需求出现了，因为我们需要构建这样一个集群系统：一个集群系统，覆盖一个应用相关的所有服务器系统，不仅仅包括生产中心的系统，还需要包括灾备中心的备用系统。一个应用的集群系统内，生产中心内的服务器节点间是可以自由切换的，并且是需要自动切换的，而生产中心到灾备中心的节点的切换却是不允许自动发生的。我们知道，要统一管理生产中心和灾备中心的系统，我们必须将同一应用的不同服务器同时纳入同一个集群系统，如下图。在集群逻辑上，我们要求这3台服务器同时属于同一

50、个应用的集群系统，任意对这个应用集群的调整，其配置信息都将同步的传递到这3台服务器上，同时，这3台服务器作为集群节点，都处于Enable状态，都在监视彼此的活动状态，并及时把配置和状态信息的变化传递给集群内部的其他服务器系统。但是从应用逻辑上来看，我们对这3台服务器的角色要求还是有区别的，我们要求生产中心的服务器A和B之间是允许并要求支持自动切换的，而容灾中心的服务器C，是不允许自动接管生产中心的业务的。我们要求服务器节点C对业务的接管，需要经过人工确认，然后我们利用在服务器节点C上的接管定义，实现应用的单键切换。这种要求需要服务器节点C的各种资源配置始终和生产中心的服务器节点A和B保持一致。

51、这样，相对于纯手工切换，我们推荐的这种方式要平滑的多，并可以更好的保证灾备系统在计划的时间内顺利投入运行。本方案推荐的VERITAS Cluster Server软件可以全面地提供这方面的技术，满足这种策略的需要，从而可以帮助建立覆盖生产中心和灾备中心的统一的集群系统。业务系统故障和灾难的响应业务系统故障和灾难的种类很多，不过我们只要解决了一下几个问题，其他的问题就不是问题了，下面，我们就这几个问题分别予以阐述。生产中心主业务服务器不可用生产中心所有服务器不可用生产中心和灾备中心之间心跳链路故障生产中心所有服务器和磁盘系统不可用生产中心主业务服务器不可用生产中心主业务服务器A发生故障，这只是常

52、规意义上的服务器单点故障，利用VCS集群软件，我们可以非常简单的在生产中心内部完成应用从服务器A到服务器B的自动切换。如下图：同样的，在服务器A的故障修复以后，我们可以继续让应用运行在服务器B上，而把服务器A作为第一备用服务器；也可以将应用回切到服务器A，恢复到故障发生前的状态。生产中心所有服务器不可用当生产中心所有的服务器系统都发生故障时，就遇到了我们所谓的服务器系统灾难，这个时候，服务器系统C发现服务器A、B均出现了问题，于是做好的了接管应用的准备，但是根据预先定义的规则，服务器C不会自动接管该应用，而是等我们人工确认灾难的真实性后，由管理员连接到服务器C的集群系统上，启动接管流程。集群软

53、件会根据我们在集群软件中定义好的接管流程，依次启动该应用需要的系统资源、存储资源、网络资源、数据库和应用资源，实现应用的平滑接管。整个应用接管的过程如下图：生产中心和灾备中心之间心跳链路故障当生产中心和灾备中心之间所有的心跳链路同时发生故障时，生产中心会认为灾备中心的服务器C发生故障，并将该服务器C从集群中隔离出去，整个过程对应用系统没有任何影响，之后，我们在生产中心仍然保持一个由服务器A和服务器B构成的集群。与此同时，在灾备中心，灾备服务器同样会认为生产中心发生灾难，从而将服务器A和服务器B从集群中隔离，保留自身构成单节点集群。由于我们预先定义的策略是灾备系统不自动接管业务，所以灾备系统不会

54、试图接管任何和业务相关的系统资源。在人工确认以后，我们发现这是由心跳链路故障引起的“假灾难”，于是我们可以Disable灾备中心的集群系统，并设法修复心跳链路，然后，我们可以再将灾备中心的服务器C重新加入到由服务器A和B构成的集群中去。VERITAS Cluster Server支持动态的集群节点加入，所以，事件的整个过程对业务系统不会产生任何影响。相反的，其他我们以前使用的集群软件，在遇到上述情况后，恢复该集群新节点时是需要暂停应用的。生产中心所有服务器和磁盘系统不可用生产中心所有服务器和磁盘系统不可用，这种情况一般只有在真正的灾难的情况下才会发生，包括自然灾难和人为灾难。这种情况下，我们需

55、要灾备系统在确认灾难以后，能够快速的、准确地接管所有关键业务系统。这种故障和上面第一种情况的不同之处在于，生产中心的磁盘系统同时发生了故障。这种情况会带来一个新问题，那就是在一个逻辑卷镜像的一个Plex损坏的情况下，我们需要将该逻辑卷所在的Disk Group强制Import，这种处理方式和磁盘系统没有损坏的情况是不同的，对于手动处理，我们需要制动不同的接管命令流程，而对于集群系统，我们则需要集群系统提供针对这个问题的监控、判断的能力，以及选择合适启动流程的能力。针对这种情况，VERITAS Cluster Server提供的Campus Agent可以帮助用户简化灾备系统管理程序和灾难恢复程

56、序。VCS Campus Agent提供了一系列针对城域集群系统的解决方案，利用VCS Campus Agent，我们可以非常轻松的构建一个覆盖灾备系统的集群系统。下图是在生产中心发生灾难的情况下，灾备系统的接管流程的示意图：方案的优势我们推荐的城域集群方案，为构建稳定的、可靠的、易于管理的灾备中心非常有帮助，该方案的优势主要表现在以下几个方面：有利于保证生产中心和灾备中心资源配置的一致性有利于简化灾备中心灾难应急的流程，保证灾备中心快速、顺利的接管相应的应用系统。方案在技术上支持远程心跳，可将集群扩展到城域范围。方案拥有先进的Campus Agent，解决城域集群特有的问题。方案支持灵活的集

57、群策略，满足灾备中心管理的各种需要。比如自动接管和手动接管并存这种集群模式。图形化管理，简单直观，减轻管理压力，减少集群系统认为事故。方案支持应用级的监控和集群管理。相对于HACMP仅仅提供硬件级的故障监控，VCS可以提供应用级的生命监控，不仅能在硬件系统发生故障时，及时检测并切换主机，还能判断象数据库进程挂起这样的应用级别的软故障，并针对这些故障，提供快速的处理，包括应用重启或应用切换。支持多平台，简化管理，降低管理成本VERITAS Cluster Server支持包括IBM AIX，SUN Solaris，HPUX等在内的多种通用的开放平台，也支持Linux和Windows平台，不管是现

58、在，还是将来，将集群平台集中到VCS，可以大大简化我们的日常集群管理工作。我们的技术人员不必再需要针对每一种平台，学习不同的集群软件管理和问题诊断的方法；我们企业，也不再需要针对每一种平台，都花钱培养相应的集群软件管理员了。附件：VERITAS Cluster Server简介业界领先的企业高可用应用解决方案VERITAS Cluster Server是业界领先的开放式系统集群解决方案，是消除计划内和计划外停机时间，简化服务器合并，并有效管理多平台环境内广泛应用的理想选择。要保障信息访问，应用和数据就必须符合严格的正常运行要求。鉴于用户需要以电子方式获取更多的服务，提升应用正常运行水平的需求也

59、急剧增长。VERITAS Cluster Server支持UNIX和Windows集群内最广泛的应用程序，为配置基于策略的故障切换方案，满足正常运行要求和履行为客户承担的义务提供了灵活性。除此之外，自动化、智能化工作负荷管理，允许集群管理员从反应型恢复转向瞻型可用性管理，从而优化利用各种资源。由于支持存储局域网（SAN）和传统客户机/服务器环境内的大型集群，VERITAS Cluster Server能够在网络存储环境，灵活地保护从单一数据库实例到大型多应用集群的所有部件。它既能够独立使用，又能与许多成龙配套的VERITAS 软件解决方案相整合，因此在为当今的混合型计算环境提供高可用性和灾难恢

60、复方面，发挥至关重要的作用。VERITAS Cluster Server产品要点多平台支持VERITAS Cluster Server支持Microsoft Windows、Sun、Solaris、HP-UX和IBM AIX。简化管理可以选用基于Web或基于Java的直观控制台，在整个站点范围监控多达16个多平台集群，并使用基于Java的接口执行细颗粒度集群管理。如果与VERITAS Global Cluster Manager相整合，就能够在不同地区站点间或全球范围内，为单一站点的256个集群提供监控和迁移。广泛的应用支持当前支持广泛系列的应用，其中包括Oracle、Sybase、DB2、I