同城应用容灾系统方案.pdf

同城应用容灾系统方案目录1 容灾系统需求.32 容灾技术的选择.32.1 基于SAN城域网的镜像技术.32.2 构建容灾系统的技术要求.53 容灾系统建议解决方案拓扑图和配置说明.64 VERITAS基于镜像技术的容灾方案及其实现.74.1 数据容灾方案的实现.74.1.1 方案的结构原理.74.1.2 数据系统故障和灾难的响应.104.1.2.1 生产中心数据系统故障.104.1.2.2 灾备中心数据系统故障.114.1.2.3 生产中心和灾备中心SAN链路故障.114 1.3 方案的技术优势.144.L4 对系统性能的影响.184.1.5 容灾案例.194.2 构建完整的应用级灾备中心.21421 纯手工应用灾备的问题.21422 建立覆盖灾备中心的统一集群体系.244.2.2.1 跨越几十公里的心跳技术支持.254.2.2.2 为什么需要人工确认灾难.264.2.2.3 建立一个满足灾备需要的集群系统.27423 业务系统故障和灾难的响应.294.2.3.1 生产中心主业务服务器不可用.294.2.3.2 生产中心所有服务器不可用.304.23.3 生产中心和灾备中心之间心跳链路故障.314.2.3.4 生产中心所有服务器和磁盘系统不可用.32424 方案的优势.335 附件:VERITAS CLUSTER SERVER 简介.365.1 业界领先的企业高可用应用解决方案.365.2 VERITAS Cluster Server产品要点.365.3 VERITAS Cluster Server 的先进性.385.4 VERITAS Cluster 的特点和好处.406 VERITAS STORAGE FOUNDATION FOR ORACLE RAC 概述.42双磁盘阵列实现RAC系统存储支持案例.471 容灾系统需求1号线工程经国家发展和改革委员会国家发展改革委关于杭州市地铁1号线 工程可行性研究报告的批复（发改投资2006684号）核准同意建设,并已列为 浙江省重点建设项目。项目建设规模为全长54公里，车站33座、总投资约为 220.76亿元人民币，建设地址位于杭州市，计划于2011年建成。而的IT系统 是职能正常运转的重要支撑。考虑到IT系统的重要性，为了保证IT系统的正常运 转，保证和提高的服务能力，准备建立现有IT核心业务系统的应用容灾系统。目前，的核心业务系统主要为数据库系统为Oracle,运行在两台小型机系统 上。考虑到核心数据库系统的安全和可靠，准备在同城建立现有数据库系统的数据 容灾系统，并可以简单地实现生产系统的应用级容灾。2 容灾技术的选择2.1 基于SAN城域网的镜像技术目前实现容灾的技术方案看起来很多，不过目前比较通用的和实用的容灾技术，主要有两 类，一种是基于主机的容灾方案，一种是基于磁盘系统的数据复制的容灾方案。而随着光纤存储网络技术的成熟和在距离上的拓展，光纤城域存储网络的实现已经趋于成 熟，这就使得我们今天可以不再需要依赖复杂的数据复制技术，就可以实现同城容灾了。新的容灾方案所利用的，是最为传统的磁盘镜像技术，也就是说我们可以利用基于城域SAN存储网上的镜像技术，轻松实现数据容灾，然后在此基础上，我们可以利用先进的集 群软件，构建应用级的容灾系统，以满足对容灾的需要。为什么我们建议选择基于镜像技术的容灾方案？/成熟性：镜像技术是从磁盘容错技术中最成熟、历史最悠久、可靠性最高的数据 保护技术。/简单性：镜像技术是实现最为简单的数据容错技术/异构性：镜像技术不仅可以在磁盘阵列内部实现，也可以跨越不同磁盘系统来实 现，镜像技术完全不依赖于磁盘系统的品牌和型号。所以，利用镜像技术实现容 灾，我们就可以保留在任何时候自由、灵活的选择磁盘系统的权利。为什么以前比较少用镜像做容灾，而用复制做容灾？/在SCSI技术时代，SCSI只能支持25米的距离，所以虽然基于磁盘系统间的镜 像被广泛采用，但无法实现远距离容灾/远程复制技术可以很好的解决远距离和低带宽带来的问题，所以一直以来，是容 灾方案的主要选择。/FC光纤存储出现以后，为远距离镜像提供了可能，随着同城光纤存储网络的普及，利用镜像技术构建同城容灾系统，将是一个即简单、又实用的容灾解决方案。为什么现在不建议采用基于磁盘系统的复制来构建容灾系统？/数据复制技术所能解决的距离和带宽的问题，当前已经不再是问题了/利用数据复制技术实现容灾，由于其技术本身的局限性，必然导致容灾系统的结 构要比没有容灾系统的时候复杂得多。/同时，这样的容灾系统的故障环节不可避免的会增加，导致维护难度、维护成本的增加。/基于磁盘系统的数据复制技术，要求生产中心和灾备中心选用同一个厂商的磁盘 系统，甚至要求选用同一系列、同一型号的磁盘系统，用户完全失去讨价还价的 余地，完全失去了在任何时候自由、灵活地选择合作厂商和磁盘系统的权利，必 然给用户造成被动和经济上的损失。总上所述，针对的容灾系统建设，我们认为，既然我们可以提供基于光纤的城域SAN网 络，那么，我们就没有必要再采用过时的基于磁盘系统数据复制的容灾方案，采用基于主 机镜像技术来实现容灾方案，应该是一个更好的选择。2.2 构建容灾系统的技术要求基于磁盘镜像技术构建容灾系统，在数据系统容错实现的逻辑上，和本地磁盘系统间的镜 像没有任何区别，所以我们大可以放心的去构建这样的系统。但是，在实际应用环境中，我们还是发现了一个不同的地方，是我们在考虑容灾方案的时 候必须解决的，那就是距离。不是说我们已经解决了距离的问题吗？是的,我们在技 术上已经解决了远距离数据镜像的问题，但是，有几个问题是任何技术都必须考虑的，不 管是镜像技术还是复制技术，包括：1距离决定了链路的可靠性。我们在短距离（比如一个机房内）可以忽略不计的链路故障（可以通过链路冗余解决）在 长距离上就无法忽略了，比如，我们无法保证我们的光纤不会被野蛮施工挖断。A距离会影响我们管理一个系统的复杂性和现场感 远距离灾备系统永远都是生产中心的附属品，如果我们不能将其用直观的方式纳入到日常 的管理体系中，很快我们就会发现我们对生产系统和灾备系统的管理会脱节，所以，容灾 系统肯定不仅仅是镜像那么简单，他需要一个完整的、直观的管理界面去管理，才能形成 一个行之有效有的灾备系统。所以，我们在构建容灾系统的时候，必须考虑由距离引起的问题给我们的技术方案造成的 各种负面影响，并要很好的解决它。有关问题和解决方法，我们会在下一节中详细论述，这里我们先简单的把要求提出来，供参考。/对磁盘镜像容灾管理的要求：可视化磁盘管理和容灾管理/应对链路故障引起的各种问题：实现增量镜像和避免Split-Brain等3 容灾系统建议解决方案拓扑图和配置说明同城应用容灾系统拓扑图酉己置:Veritas 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个LICENSE.4 VERITAS基于镜像技术的容灾方案及其实现基于镜像技术实现容灾，从技术实现上，分为两个部分，其一是数据的容灾实现，其二是 应用级容灾实现。下面，我们就分别从这两个方面入手，论述VERITAS的容灾方案。4.1 数据容灾方案的实现4.1.1 方案的结构原理VERITAS建议利用VERITAS Volume Manager软件的镜像技术，来构建IT系统的容灾 方案。利用VERITAS Volume Manager的镜像技术构建容灾系统是非常简单的，它只有 一个条件，就是将生产中心和灾备中心之间的SAN存储区域网络通过光纤连接起来，建 立城域SAN存储网络。然后,我们就可以通过Volume Manager提供的非常成熟的跨阵 列磁盘镜像技术来实现同城容灾了，容灾方案的结构如下图所示：光纤 交换机生产中心主机容灾中心主机光纤 交换机容灾中心磁盘从原理上讲，在城域SAN存储网络上的两套磁盘系统之间的镜像，和在一个机房内的 SAN上的两个磁盘系统之间的镜像并没有任何区别。就如上图，如果我们把同城容灾中 心几个字去掉，我们就无法分辨左边的系统和右边的系统到底是在同一个机房，还是远 在几十公里以外。利用光纤将生产中心和灾备中心的SAN网络连接起来，构成城域SAN网络以后，利用 VERITAS Volume Manager的先进的逻辑卷管理功能，我们就可以非常方便的实现生产 中心磁盘系统和灾备中心磁盘系统之间的镜像了。如下图所示。这里，逻辑卷Volume A是业务系统访问磁盘的逻辑设备名，在VERITAS Volume Manager管理下的磁盘系 统,所有业务系统对磁盘系统的访问，都将通过Volume实现。光纤 交换机生产中心磁盘容灾中心磁盘我们可以看到，利用VERITAS Volume Manager,我们可以创建任意一个逻辑卷(Volume)供业务主机使用，比如Volume A，这个Volume A实际上是由两个 完全对等的，容量和Volume A相同的磁盘片构成的，我们这里可以称在生产中心磁 盘系统上的磁盘片为Volume A:Plex 1，而称在灾备中心磁盘系统上的磁盘片为Volume A:Plex 2，这两个磁盘片上的数据完全一样，业务主机对该Volume的任 意修改，都将同时被写到位于生产中心和灾备中心的两个磁盘系统上。采用这种方式，生产中心的磁盘阵列与同城容灾中心的磁盘阵列对于两地的主机而言是完 全同等的。利用城域SAN存储网络和VERITAS Volume Manager镜像功能，我们可以 非常轻松的实现数据系统的异地容灾。下面，我们来看一下，在各种数据系统(本节暂时不讨论应用系统全面灾难的应对，我们 把它放到下一节中另行展开讨论)故障和灾难情况下，容灾系统是怎样响应的。4.1.2 数据系统故障和灾难的响应在建立了容灾系统以后，数据系统的故障和灾难主要将发生在3个地方（请注意，没有建立容灾系统时，数据系统的主要故障点是1个）：4.1.2.1 生产中心数据系统故障生产中心数据系统故障意味着灾难，这也就是我们现在建立容灾系统的根本目的，对于这样的灾难，我们来看一下我们推荐的容灾方案是如何响应的，见下图：光纤 交换机生产中心主机容灾中心主机生产中心磁盘容灾中心磁盘当生产中心的磁盘系统发生故障（灾难）时，由于同城容灾中心的磁盘是它的镜像，所以操作系统会自动隔离生产中心的磁盘，转而对容灾中心的数据进行访问。从上图我们看到，业务系统可以通过城域SAN网络直接访问灾备中心的磁盘系统的数据，而不需要有任何 针对业务系统的动作。也就是说，生产中心磁盘系统的灾难，对业务系统是透明的，应用 和数据库不会因为生产中心磁盘系统的故障而停止；更重要的是，因为应用和数据库不会 因为灾难而异常中止，从而避免了发生数据库损坏的可能。生产中心磁盘系统故障之后,我们只需要更换损坏的磁盘系统，然后利用Volume Manager重新生成镜像即可，重新生成镜像的过程，实际上就是将数据从灾备中心磁盘系 统复制到生产中心磁盘系统的过程。值得注意的是：整个过程对应用完全透明，不需要也不会中断业务系统的正常运行。这是 基于磁盘系统间复制技术构建的容灾系统无法实现的。4.1.2.2 灾备中心数据系统故障灾备中心数据系统故障，这是灾备系统建立以后出现的新问题，这种故障就同上一种故障 类似，但对业务系统的影响更小。4.1.2.3 生产中心和灾备中心SAN链路故障这种故障也是灾备系统建立以后出现的新问题。相对于以上两种灾难，这种故障在容灾系 统建立以后，出现的概率会更大一些，导致链路故障的原因很多，包括光纤断裂，光端设 备故障等，都会导致链路中断。这个问题其实是由距离引起的，正如我们在前面讨论 的那样，虽然在原理上，基于城域SAN网络实现的镜像技术和基于本地SAN网络实现的 镜像技术完全一样，但是，我们还是不得不承认，他们是有区别的，因为我们很少会担心 一个机房内部不同磁盘系统之间的镜像会遭遇链路故障，而在城域范围，我们是无法回避 这个问题的。一个完整的灾备系统，除了在数据灾难发生时，能够完成灾备的使命，同时，也需要考虑,灾备系统本身的可维护性和可操作性。而对于链路故障，直接导致的就是业务数据在写到 本地磁盘系统的同时，无法写到灾备系统中，对于镜像技术而言，这又成为一个新的课题。传统的镜像技术，在镜像链路被中断以后，中断的镜像会被认为完全作废，在链路恢复以后，我们不得不将数据完整地从Volume:Plex 1拷贝一份到Volume:Plex 2，如下图所示。生产中心磁盘 容灾中心磁盘这将对业务系统的I/O性能造成不必要的影响，链路方面的故障如果经常发生，我们就需 要不断的重复将生产中心的数据全部同步到灾备中心的磁盘系统上，实际上，这种方案不 具有可实施性和可维护性，是不现实的。这也是什么主机厂商虽然也有类似镜像功能,但 不会用于容灾的的根本原因。为了解决这个问题，VERITAS Volume Manager提供了 DCO+FMR技术，其中DCO(Data Change Object)是一种针对镜像的Log技术，该技术允许Volume Manager 在镜像链路中断后记录逻辑卷的数据变化情况，以便在镜像链路恢复后，由FMR实现数 据的增量恢复。所谓FMR,其全称是Fast Mirror Resync,意思就是镜像的快速再同 步，FMR是和DCO技术对应的镜像快速恢复技术，利用VERITAS Volume Manager 的DCO和FMR技术，我们现在可以不用再担心容灾系统本身的可维护性了。利用DCO 和FMR,针对同样的链路问题，我们的应对步骤如下：1.SAN链路发生故障2.生产中心的Volume Manager利用DCO日志记录Volume:Plex 1因业务数据 的变化而变化的数据块，灾备端Volume:Plex 2的数据不会作废3.一旦SAN链路恢复正常，Volume Manager的FMR功能模块，会根据DCO 日志记录的情况，将Volume:Plex 1中链路中断后更新的业务数据拷贝到灾备 端Volume:Plex 2,实现增量更新。Volume Manager用DCO和FMR技术实现增量同步的过程如下图所示：生产中心主机容灾中心主机生产中心主机Volume A:Plex 2生产中心主机Volume A容灾中心主机Volume A:Plex 2增量拷贝!.容灾中心磁盘.D8记录生产中心磁盘Volume A:Plex 1生产中心磁盘 容灾中心磁盘容灾中心王机Volume A:Plex 1DCO记录Volume A:Plex 1 FMR 技术 Volume A:Plex i生产中心磁盘容灾中心磁盘4.1.3方案的技术优势和其他容灾方案相比，VERITAS容灾方案具有明显的优势，这些优势不仅仅表现在技术实 现方面，还表现在开放性、可维护性等各个方面。/结构简单VERITAS推荐的基于镜像的容灾方案较任何一种容灾方案为简单。在一个使用逻辑卷管理 的应用系统中（逻辑卷管理的好处我想大家已经深有体会，我想我在这里就不需要重复 了），我们只是利用了其中最常用、最成熟的镜像功能，就可以实现容灾，而不必像其他 容灾系统那样增加很多不必要的环节。比如基于磁盘系统复制技术的容灾方案，我们必须在磁盘系统内部专门配置相应的接口卡，使用该磁盘系统专有的复制软件，才可以构建容灾系统。明显的，该方法增加了一个在非 容灾系统中完全不需要的环节，不仅增加了故障源，同时也增加了维护强度。事实上，基 于主机的复制技术存在同样的问题。/技术成熟镜像技术是比任何数据复制技术更早使用于高可用系统的成熟的功能，这种功能已经广泛 应用于包括IBM Mainframe、AS400s RS6000、HPUX、Digital Unix.SUN Solaris.Linux.Windows等在内的所有服务器系统上，同时也被广泛用于磁盘系统内部作为企业 级解决方案，象EMC、HDS、HP、IBM、SUN、Compaq等众多存储设备生产厂商，都 将镜像技术内置于其磁盘系统内部，用于对数据可用性要求最高的用户群。/存储开放性利用VERITAS Volume Manager的镜像技术，我们构建容灾方案时，不再要求生产系统 和灾备系统的存储系统必须是同一个品牌的，对具体型号更没有任何要求，体现了存储平 台选择的开放性。由此，用户可以获得在存储平台选择上的主动权，避免被存储厂商绑 架的尴尬。,技术的完整性VERITAS Volume Manager拥有一个容灾方案必须的所有技术特性，它不仅可以提供可 靠的镜像技术，实现跨磁盘系统的数据容灾，同时,我们可以利用Volume Manager的 DCO和FMR技术，保证该容灾系统的可维护性。/容灾系统的可视化管理一个灾备系统和生产系统是一个整体，而不是两个孤立的系统，一个系统的可视化管理工 具，有利于管理者将两个系统有机的结合起来，而不是分别处理两个独立的系统。VERITAS Volume Manager VEA提供企业范围内全局的逻辑卷管理视图，通过任何一台 安装有Volume Manager或者其Console的系统,我们就可以访问我们想要访问的系统 的（被授权）逻辑卷，这意味着，我们可以将同一个应用的生产系统和灾备系统的逻辑卷 置于同一个管理视图中，从而实现对生产中心和灾备中心存储的统一管理。VERITAS VEA 管理界面丰富，下图为其中一个管理界面，仅供参考。/应对灾难，应用不中断，数据不丢失VERITAS建议的容灾方案，不会因为生产中心（或者灾备中心）磁盘系统的故障和灾难而 导致应用和数据库的异常中止，这不仅避免了对应用系统正常运作的影响，还避免了发生 数据库损坏的可能。相比较而言，如果采用数据复制的方式（无论是基于磁盘系统的硬件复制方式还是基于软 件的数据复制方式），都需要在生产中心故障时对数据系统进行切换操作，反而造成业务 的停顿。另外，由于在灾难发生时，数据库系统的复制是即刻停止的，数据库系统没有经 过正常的Shutdown,所以不仅不可避免的导致部分交易的损失，甚至还有可能导致数据 库的损坏。/I/O效率最佳从性能上来分析，在操作系统一级进行镜像，数据会在同一时间写入到两地的磁盘。数据 可写入过程是两组并行的操作，即本地写和完成信号返回+异地写和完成信号返回。而相比较而言，数据复制技术需要通过以下4个步骤才算写操作完成：1.数据先有操作系统写入本地磁盘系统2.磁盘系统将数据通过链路复制到异地系统3.异地磁盘系统完成写操作，返回信号给本地磁盘系统4.本地磁盘系统返回信号给操作系统明显的，这个过程和直接数据镜像相比，把原先并行的2组步骤变成了纯串行的4个步骤，并且需要SCSI到复制协议的转换过程，无论在流程上和反应时间上都会比直接镜像造成 更多的延时，对应用系统有更大的影响。另外，在逻辑卷这个层面，我们可以根据需要对镜像的数据灵活设置，我们不需将所有磁 盘进行镜像，而只需镜像必要的逻辑卷（Volume）。这种灵活性在实际使用过程中将大大减少数据远程复制的数量，从而避免对系统不必要的影响。4.1.4 对系统性能的影响大家都比较关心容灾系统建立以后对原有业务系统性能的影响，考察容灾系统对业务系统 性能的影响，主要从两个方面衡量，一是CPU资源的消耗，二是I/O,特别是写操作的延 迟效应。/CPU资源消耗采用主机端的软件镜像技术，对CPU资源的损耗，实际上是微乎其微的，但很多时候被磁 盘系统厂商人为的夸大了。具体的事实我们可以通过简单的测试得到，我们可以设置这样 一个测试，就一目了然了：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的消耗往往都是可以忽略不计的，如果说需要关心的话，也主要针对象RAID-5这 样的技术（需要大量计算，从而消耗主机的CPU资源），而像镜像这样的技术，是几乎不 需要消耗CPU时间的。/I/O的延迟效应（特别是写操作的延迟效应）采用VERITAS Volume Manager的镜像技术构建容灾系统，其对系统I/O的延迟效应要 小于任何一种数据复制技术，不管是基于磁盘系统的硬件数据复制技术，还是基于主机软 件的数据复制技术，这在上一节中已经阐述。这里我想要补充的是在整个容灾系统中，对业务系统的性能的影响最大的不是任何一种技 术所产生的负面作用，而是距离,正如前面提到的，在Cache命中率较高的系统中，距离对写操作的影响较大，这和光的传播速度有关，光在150公里距离上的一个来回需要 1ms,在15KM距离上一个来回需要0.1ms,我们列出一个对照表，供大家参考。本对照 表不包含设备协议转换和光在光纤中的折射等因素。同时，我们知道，100MB光纤对应 的速度是ns级的。距离光传输距离传输时间说明15 km30 kmlOOus同城容灾中心的距离级别150 m300 mlus15 m30 m100ns一个机房的内部距离1.5 m3 m10ns一个主板的内部距离本地Cache写的时间nsus 级本地磁盘写的时间usms 级综上所述，我们的结论是，只要是数据复制方式的同步方式能够做的系统，采用镜像方式 也一定能做，而且会做的更好。4.1.5 容灾案例/中国银联IT中心的同城容灾中心项目中国银联的信息中心的同城容灾中心,就是选择了 VERITAS Volume Manager的镜像技 术来构建的，其生产中心和灾备中心分别位于上海市的浦东和浦西，两地相距超过30公 里。/芜湖卷烟厂信息系统的同城容灾项目另外，VERITAS拥有丰富的容灾系统实施经验，我们参与的容灾项目除了采用镜像方式的，还有利用传统的数据复制方式构建的容灾系统，包括：/中国联通光传输网络系统中国联通光传输网络的容灾系统是由VEITAS通过华为提供的，这个方案是跨省际的，其 中一个容灾项目的生产中心和灾备中心分别在北京和广州。VERITAS提供的这套超远程容 灾方案是国内目前业界唯一真正已实施的超远程容灾方案。要实现这种方案，我们只需要 在现有的Volume Manager的基础上增加VVR模块，体现了技术和方案的延续性。/上海热线的容灾系统/公安部某应用系统从上海到广东南海的远程容灾项目4.2 构建完整的应用级灾备中心4.2.1 纯手工应用灾备的问题本次需要构建的不仅仅是数据容灾中心，我们需要构建的是应用级的同城灾备中心，所以 除了要考虑在灾备中心购置等量的存储用于数据灾备以外，我们还需要购置同等处理能力 的服务器系统作为灾备应用和数据库服务器，以便在灾难发生时，能够完整的接管整个业 务系统，包括数据和业务处理能力。/两套系统配置难以完全同步的风险对两套系统的管理是孤立的，而这两套系统应该是在各方面都相同的并严格的一一对应的。这种局面除了导致管理复杂之外，同时还带来了两套系统配置不能及时同步、不能完全同 步等风险。这种风险将直接导致灾备中心在灾难发生时不能准确、及时地接管业务系统，这和我们建立该容灾中心的基本要求必须保证容灾中心在一小时以内全面接管生产中心 的作用是相背的。事实上，我们在生产中心建立集群系统的时候，集群系统不仅给我们提供了主机故障时的 业务接管功能，同时，还给我们提供了保证业务主机和备用主机之间配置的一致性的同步 资源管理功能。一个系统对另外一个系统的顺利接管，需要日常的、长期的维护和精心的 准备，而不是简单的在备用系统上输入几个命令来完成的，而集群软件为这种需要提供了 行之有效的方法。本地的主服务器和备用服务器之间尚且如此，那么生产中心和灾备中心之间该如何处置呢？事实上，完全靠人工去保持生产中心和灾备中心这两个不在同一个机房的系统的配置保持 动态一致，是一件费力费神的事情，同时还是一件费力不讨好的事情。这种手工操作方式 不利于灾备中心的可靠性、稳健性。/灾备中心接管难度大由于在灾备中心和生产中心之间没有集群系统，灾备中心对生产中心的接管将完全依赖于 手工，这无谓的加大了灾备中心接管的难度，在各种因素引起的专业技术人员不能及时到 位的情况下，这种难度将直接导致灾备中心不能及时的、成功的接管业务。我们知道，我 们建设的是灾难备用系统，灾难的定义不是简单的磁盘系统故障，它可能是任何 情况。所以灾备中心的接管流程要求：1）全面，包括简单的，也包括复杂的；2）尽量提 供简单的流程。/管理难度大生产中心和灾备中心两套系统完全孤立，没有办法同时监控，更不用说在一个界面上对这 些系统统一监控和管理了，我们难以同时对两地配置进行跟踪和修改，无谓的增加了灾备 系统维护的难度和强度。解决以上问题的办法是：在生产中心和灾备中心之间构建高可用集群系统。就如同我们在一开始所讲的，在城域SAN网络上构建的镜像系统和在同一个机房内部构 建的镜像系统在逻辑上是完全相同的，同样的，我们要推荐的在城域SAN网络上构建的 集群系统和在同一个机房内部构建的集群系统在逻辑上也是完全相同的。城域范围内和镜像技术配套的集群技术，和用于远程复制技术下构建远程集群的技术不同，我们这里推荐的城域范围的集群系统不是传统的远程集群模式，而是传统的本地机群技术 的扩展。实际上，它所采用的软件产品和基本技术，完全就是本地集群软件，只是，我们 需要这些集群软件提供必要的功能扩展，以满足城域范围的特定的需要。在这里，我们称 这种模式为准本地集群模式，也可以称为Campus Model。准本地集群模式实际上和大家非常熟悉的本地集群模式是一样的，在这种模式下,生 产中心的系统和灾备中心的系统将被纳入同一个集群主体中，从而我们可以非常轻松的实 现对两个中心的统一管理。其结果，就是给我们带来管理的简单化和灾备系统的可靠性。下图为利用VERITAS集群软件VERITAS Cluster Server(VCS)进行集群管理的一个界面 示意，通过该界面，我们可以知道，利用VCS,我们可以非常方便的管理生产中心和灾备 中心的系统，并将生产中心和灾备中心纳入到统一个集群管理体系内进行统一管理。当然，在我们构建这个准本地集群系统的时候，我们还是要正视由罐巨离引起的一 切问题，我们需要在技术层面去解决它，这也是为什么我们在方案中建议的集群软件是和 本地集群完全相同的VERITAS Cluster Server软件，但却称这种集群模式为准本地集群模 式的原因。4.2.2 建立覆盖灾备中心的统一集群体系为了有效的管理灾备中心，同时保证在灾难发生的时候，能够在要求的时间里快速的恢复 系统的正常运行，我们需要建立一个横跨业务中心和灾备中心的准本地集群系统，这 里，我们建议采用通用的本地高可用集群软件（也称HA软件），构建的应用容灾系统。我们都非常熟悉如何利用HA软件来建立集群系统的，目前的许多系统都有各种各样的 HA软件，那么是否所有的集群软件都可以支持这种准本地集群系统呢？一答案是N0！构建准本地集群系统，我们需要在原有的集群系统的功能上有新的扩展，以便满足城 域环境下的特殊要求。我们现在分析一下同城集群系统和本地集群系统的区别，然后再来 分析需要怎样的技术扩展。在磁盘镜像结构和集群系统结构上，城域SAN+城域IP网络的环境和本地系统没有什 么逻辑上的区别，但是就集群系统而言，仅仅是距离的变化，就会导致以下两个新问题（距离对镜像技术的影响和相应的方案，我们在数据容灾一节已经详细阐述，这里不再说 明）：1.集群系统的心跳线需要跨越几十公里，而不是几十米2.同城生产中心和灾备中心的网络更容易因意外而中断，其中包括心跳线这两个因为距离而产生的新问题，需要我们在构建集群系统时，不得不从技术层面仔细分 析，以便保证我们推荐的方案的可靠性和可行性。下面，我们就这两个问题从技术层面展 开讨论。4.2.2.1 跨越几十公里的心跳技术支持城域集群将跨越几十公里，这对集群心跳的技术要求非常简单，就是要求集群软件能够支 持跨越几十公里的心跳技术。VERITAS Cluster Server能够很好的支持远程心跳通道，VCS对远程心跳通道只有一个要 求，就是支持广播。也就是说，只要两个Site之间有不经过路由器、桥这样的设备的通道，就可以支持VCS的心跳。需要说明的是，我们这里需要心跳的动机和传统的心跳技术的目的不同，传统的集群心跳 的目的包括：1.同步集群配置信息和集群状态信息2.监控Active的业务服务器是否运行正常3.根据监控信息，激发集群在主业务服务器系统没有相应的时候，自动切换服务器。但是，我们这里需要心跳的目的只包含前两条，而不包含最后一条，原因是我们的生产中 心灾难后的切换，应该是在人工确认后手动发起的，我们不需要自动切换。但不管怎样，我们还是需要心跳来构建这样的集群系统。4.2.2.2 为什么需要人工确认灾难我们好像已经已经习惯了 生产中心到灾备中心的切换需要人工确认的这个规则了，我 们也已经习惯了 如果不经过人工确认，就有可能导致误操作这种说法了，但是为什么 本地集群系统就可以自动切换呢？我们的准本地集群系统和真正的本地集群系统在逻 辑上是相同的，为什么我们还是需要坚持采用灾难人工确认原则呢？其实，在没有必要自动切换的说法背后，其真正原因是：凡是远距离的集群系统，都 无法象本地集群系统那样，可以提供足够可靠的心跳通道。我们知道，本地集群系统可以提供多种冗余技术，保证心跳通道不在同一时间一起中断，常见的心跳冗余技术有：1.采用双以太网卡作为冗余心跳通道2.采用双RS232端口作为冗余心跳通道3.采用公网（业务以太网通道）作为辅助冗余心跳通道4.采用共享磁盘作为辅助冗余心跳通道相对而言，远程集群系统除了能够利用远距离以太网连接作为心跳以外，就没有其他冗余 措施了，我们知道，城域范围的网络本身的可靠性要比一个信息中心内部的专用网络的可 靠性低很多的，而且具有更多的不确定性，比如，一次光纤事故就可能会导致所有的心跳 通道同时中断。如果我们无法保证心跳通道的可靠性，那么就有可能出现因为心跳通道本身的故障而引起 的虚假灾难，也就是说，当主业务系统实际在正常运行的情况下，备用系统却因为无 法收到对方的心跳而认为对方已经停止运行，并强行接管数据和网络系统，这种情况 在技术领域我们称为Split-Brain，也就是说一份数据，两个大脑。这种情况对数据系 统是非常危险的，两个服务器对一个数据资源的强制争用，会导致业务数据的不一致，更 有甚者，会导致业务数据的不可逆损坏。一个假灾难会引起真灾难的发生，这是 谁都不会允许的。除非我们有足够可靠的心跳安全技术和策略，否则，为了避免这种意外灾难的发生，我们都会建议在灾备系统的接管策略上，采用灾难人工确认原则的。这里，我想补充说明一下，实际上，我们推荐的VERITAS Cluster Server可以提供其他特 有的技术手段来弥补远距离心跳安全性方面的缺陷，严格来讲,VCS可以支持容灾系统的 远程自动切换。通过配置I/O fencing仲裁盘方式可以规避由于心跳原因造成的裂脑 现象。但是我们原则上还是建议异地应用容灾采用灾难人工确认原则。4.2.2.3 建立一个满足灾备需要的集群系统现在新的技术需求出现了，因为我们需要构建这样一个集群系统：1.一个集群系统，覆盖一个应用相关的所有服务器系统，不仅仅包括生产中心的系 统，还需要包括灾备中心的备用系统。2.一个应用的集群系统内，生产中心内的服务器节点间是可以自由切换的，并且是 需要自动切换的，而生产中心到灾备中心的节点的切换却是不允许自动发生的。我们知道，要统一管理生产中心和灾备中心的系统，我们必须将同一应用的不同服务器同 时纳入同一个集群系统，如下图。在集群逻辑上，我们要求这3台服务器同时属于同一个应用的集群系统，任意对这个应用 集群的调整，其配置信息都将同步的传递到这3台服务器上，同时，这3台服务器作为集 群节点，都处于Enable状态，都在监视彼此的活动状态，并及时把配置和状态信息的变 化传递给集群内部的其他服务器系统。光纤 交换机一个统一的集群系统光纤 交换机Volume A Plex 1镜像+Volume A Plex 2生产中心磁盘容灾中心磁盘但是从应用逻辑上来看，我们对这3台服务器的角色要求还是有区别的，我们要求生产中 心的服务器A和B之间是允许并要求支持自动切换的，而容灾中心的服务器C,是不允许 自动接管生产中心的业务的。我们要求服务器节点C对业务的接管，需要经过人工确认，然后我们利用在服务器节点C 上的接管定义，实现应用的单键切换。这种要求需要服务器节点C的各种资源配置始终和 生产中心的服务器节点A和B保持一致。这样，相对于纯手工切换，我们推荐的这种方式 要平滑的多，并可以更好的保证灾备系统在计划的时间内顺利投入运行。本方案推荐的VERITAS Cluster Server软件可以全面地提供这方面的技术，满足这种策略的需要，从而可以帮助建立覆盖生产中心和灾备中心的统一的集群系统。4.2.3业务系统故障和灾难的响应业务系统故障和灾难的种类很多，不过我们只要解决了一下几个问题，其他的问题就不是 问题了，下面，我们就这几个问题分别予以阐述。1.生产中心主业务服务器不可用2.生产中心所有服务器不可用3.生产中心和灾备中心之间心跳链路故障4.生产中心所有服务器和磁盘系统不可用4.2.3.1 生产中心主业务服务器不可用生产中心主业务服务器A发生故障，这只是常规意义上的服务器单点故障，利用VCS集 群软件，我们可以非常简单的在生产中心内部完成应用从服务器A到服务器B的自动切换。如下图：同样的，在服务器A的故障修复以后，我们可以继续让应用运行在服务器B上，而把服务器A作为第一备用服务器；也可以将应用回切到服务器A，恢复到故障发生前的状态。4.2.3.2 生产中心所有服务器不可用当生产中心所有的服务器系统都发生故障时，就遇到了我们所谓的服务器系统灾难，这个 时候，服务器系统C发现服务器A、B均出现了问题，于是做好的了接管应用的准备,但 是根据预先定义的规则，服务器C不会自动接管该应用，而是等我们人工确认灾难的真实 性后，由管理员连接到服务器C的集群系统上，启动接管流程。集群软件会根据我们在集 群软件中定义好的接管流程，依次启动该应用需要的系统资源、存储资源、网络资源、数 据库和应用资源，实现应用的平滑接管。整个应用接管的过程如下图：4.2.3.3 生产中心和灾备中心之间心跳链路故障当生产中心和灾备中心之间所有的心跳链路同时发生故障时，生产中心会认为灾备中心的 服务器C发生故障，并将该服务器C从集群中隔离出去，整个过程对应用系统没有任何影 响，之后，我们在生产中心仍然保持一个由服务器A和服务器B构成的集群。与此同时，在灾备中心，灾备服务器同样会认为生产中心发生灾难，从而将服务器A和服 务器B从集群中隔离，保留自身构成单节点集群。由于我们预先定义的策略是灾备系统不 自动接管业务，所以灾备系统不会试图接管任何和业务相关的系统资源。在人工确认以后，我们发现这是由心跳链路故障引起的假灾难，于是我们可以Disable灾备中心的集群 系统，并设法修复心跳链路，然后，我们可以再将灾备中心的服务器C重新加入到由服务 器A和B构成的集群中去。VERITAS Cluster Server支持动态的集群节点加入,所以，事件的整个过程对业务系统不会产生任何影响。相反的，其他我们以前使用