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

同城应用容灾系统方案 第 1 页 共 41 页 同同城城应应用用容容灾灾系系统统方方案案 同城应用容灾系统方案 第 2 页 共 41 页 目目 录录 同城应用容灾系统方案同城应用容灾系统方案1 目目 录录2 一、容灾系统需求一、容灾系统需求4 二、容灾技术的选择二、容灾技术的选择5 2.1 基于 san 城域网的镜像技术.5 2.2 构建容灾系统的技术要求.7 三、容灾系统建议解决方案拓扑图和配置说明三、容灾系统建议解决方案拓扑图和配置说明8 四、四、veritas 基于镜像技术的容灾方案及其实现基于镜像技术的容灾方案及其实现.9 4.1、数据容灾方案的实现9 4.1.1方案的结构原理9 4.1.2数据系统故障和灾难的响应11 4.1.3方案的技术优势15 4.1.4对系统性能的影响18 4.1.5容灾案例19 4.2、构建完整的应用级灾备中心20 4.2.1纯手工应用灾备的问题20 4.2.2建立覆盖灾备中心的统一集群体系22 4.2.3跨越几十公里的心跳技术支持23 4.2.4为什么需要人工确认灾难24 4.2.5建立一个满足灾备需要的集群系统25 4.2.6业务系统故障和灾难的响应26 4.2.7方案的优势30 五、五、veritas cluster server 简介简介31 5.1 业界领先的高可用应用解决方案.31 5.2veritas cluster server产品要点.31 5.3veritas cluster server的先进性.33 5.4veritas cluster的特点和好处.35 六、六、storage foundation for oracle rac 概述概述37 6.1veritas storage foundation for oracle rac概述37 6.2双磁盘阵列实现rac系统存储支持案例.41 同城应用容灾系统方案 第 3 页 共 41 页 同城应用容灾系统方案 第 4 页 共 41 页 一一、容容灾灾系系统统需需求求 ( (在在此此插插入入用用户户情情况况介介绍绍) ) it 系统是职能正常运转的重要支撑。考虑到it 系统的重要性，为了保 证 it 系统的正常运转，保证和提高的服务能力，准备建立现有it 核心业 务系统的应用容灾系统。 目前，的核心业务系统主要为数据库系统为oracle ，运行在两台小型 机系统上。考虑到核心数据库系统的安全和可靠，准备在同城建立现有数据库 系统的数据容灾系统，并可以简单地实现 生产系统的应用级容灾。 同城应用容灾系统方案 第 5 页 共 41 页 二二、容容灾灾技技术术的的选选择择 2.1 基于 san 城域网的镜像技术 目前实现容灾的技术方案看起来很多，不过目前比较通用的和实用的容灾技术，主要有两类， 一种是基于主机的容灾方案，一种是基于磁盘系统的数据复制的容灾方案。 而随着光纤存储网络技术的成熟和在距离上的拓展，光纤城域存储网络的实现已经趋于成熟， 这就使得我们今天可以不再需要依赖复杂的数据复制技术，就可以实现同城容灾了。新的容灾方案 所利用的，是最为传统的磁盘镜像技术，也就是说我们可以利用基于城域 san 存储网上的镜像技术， 轻松实现数据容灾，然后在此基础上，我们可以利用先进的集群软件，构建应用级的容灾系统，以 满足对容灾的需要。 为什么我们建议选择基于镜像技术的容灾方案？为什么我们建议选择基于镜像技术的容灾方案？ 成熟性：镜像技术是从磁盘容错技术中最成熟、历史最悠久、可靠性最高的数据保护技术。 简单性：镜像技术是实现最为简单的数据容错技术 异构性：镜像技术不仅可以在磁盘阵列内部实现，也可以跨越不同磁盘系统来实现，镜像 技术完全不依赖于磁盘系统的品牌和型号。所以，利用镜像技术实现容灾，我们就可以保 留在任何时候自由、灵活的选择磁盘系统的权利。 为什么以前比较少用镜像做容灾，而用复制做容灾？为什么以前比较少用镜像做容灾，而用复制做容灾？ 在 scsi 技术时代，scsi 只能支持 25 米的距离，所以虽然基于磁盘系统间的镜像被广泛 采用，但无法实现远距离容灾 远程复制技术可以很好的解决远距离和低带宽带来的问题，所以一直以来，是容灾方案的 主要选择。 fc 光纤存储出现以后，为远距离镜像提供了可能，随着同城光纤存储网络的普及，利用 同城应用容灾系统方案 第 6 页 共 41 页 镜像技术构建同城容灾系统，将是一个即简单、又实用的容灾解决方案。 为什么现在不建议采用基于磁盘系统的复制来构建容灾系统？为什么现在不建议采用基于磁盘系统的复制来构建容灾系统？ 数据复制技术所能解决的距离和带宽的问题，当前已经不再是问题了 利用数据复制技术实现容灾，由于其技术本身的局限性，必然导致容灾系统的结构要比没 有容灾系统的时候复杂得多。 同时，这样的容灾系统的故障环节不可避免的会增加，导致维护难度、维护成本的增加。 基于磁盘系统的数据复制技术，要求生产中心和灾备中心选用同一个厂商的磁盘系统，甚 至要求选用同一系列、同一型号的磁盘系统，用户完全失去讨价还价的余地，完全失去了 在任何时候自由、灵活地选择合作厂商和磁盘系统的权利，必然给用户造成被动和经济上 的损失。 总上所述，针对的容灾系统建设，我们认为，既然我们可以提供基于光纤的城域 san 网络，那么， 我们就没有必要再采用过时的基于磁盘系统数据复制的容灾方案，采用基于主机镜像技术来实现容 灾方案，应该是一个更好的选择。 同城应用容灾系统方案 第 7 页 共 41 页 2.2 构建容灾系统的技术要求 基于磁盘镜像技术构建容灾系统，在数据系统容错实现的逻辑上，和本地磁盘系统间的镜像没 有任何区别，所以我们大可以放心的去构建这样的系统。 但是，在实际应用环境中，我们还是发现了一个不同的地方，是我们在考虑容灾方案的时候必 须解决的，那就是“距离” 。不是说我们已经解决了距离的问题吗？是的，我们在技术上已经解决 了远距离数据镜像的问题，但是，有几个问题是任何技术都必须考虑的，不管是镜像技术还是复制 技术，包括： 距离决定了链路的可靠性。距离决定了链路的可靠性。 我们在短距离（比如一个机房内）可以忽略不计的链路故障（可以通过链路冗余解决）在长距 离上就无法忽略了，比如，我们无法保证我们的光纤不会被野蛮施工挖断。 距离会影响我们管理一个系统的复杂性和现场感距离会影响我们管理一个系统的复杂性和现场感 远距离灾备系统永远都是生产中心的附属品，如果我们不能将其用直观的方式纳入到日常的管 理体系中，很快我们就会发现我们对生产系统和灾备系统的管理会脱节，所以，容灾系统肯定不仅 仅是镜像那么简单，他需要一个完整的、直观的管理界面去管理，才能形成一个行之有效有的灾备 系统。 所以，我们在构建容灾系统的时候，必须考虑由距离引起的问题给我们的技术方案造成的各种 负面影响，并要很好的解决它。有关问题和解决方法，我们会在下一节中详细论述，这里我们先简 单的把要求提出来，供参考。 对磁盘镜像容灾管理的要求：可视化磁盘管理和容灾管理 应对链路故障引起的各种问题：实现增量镜像和避免 split-brain 等 同城应用容灾系统方案 第 8 页 共 41 页 三三、容容灾灾系系统统建建议议解解决决方方案案拓拓扑扑图图和和配配置置说说明明 配置：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. 同城应用容灾系统方案 第 9 页 共 41 页 四四、v ve er ri it ta as s 基基于于镜镜像像技技术术的的容容灾灾方方案案及及其其实实现现 基于镜像技术实现容灾，从技术实现上，分为两个部分，其一是数据的容灾实现，其二是应用 级容灾实现。下面，我们就分别从这两个方面入手，论述 veritas 的容灾方案。 4.1、数数据据容容灾灾方方案案的的实实现现 4 4. .1 1. .1 1 方方案案的的结结构构原原理理 veritas 建议利用 veritas volume manager 软件的镜像技术，来构建 it 系统的容灾方案。利 用 veritas volume manager 的镜像技术构建容灾系统是非常简单的，它只有一个条件，就是将生 产中心和灾备中心之间的 san 存储区域网络通过光纤连接起来，建立城域 san 存储网络。然后，我 们就可以通过 volume manager 提供的非常成熟的跨阵列磁盘镜像技术来实现同城容灾了，容灾方 案的结构如下图所示： 同城应用容灾系统方案 第 10 页 共 41 页 从原理上讲，在城域 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 的任意修改，都将同时被写到位于生产中心和灾备中心的两个磁 盘系统上。 同城应用容灾系统方案 第 11 页 共 41 页 采用这种方式，生产中心的磁盘阵列与同城容灾中心的磁盘阵列对于两地的主机而言是完全同等的。 利用城域 san 存储网络和 veritas volume manager 镜像功能，我们可以非常轻松的实现数据系统 的异地容灾。 下面，我们来看一下，在各种数据系统（本节暂时不讨论应用系统全面灾难的应对，我们把它 放到下一节中另行展开讨论）故障和灾难情况下，容灾系统是怎样响应的。 4.1.2 数数据据系系统统故故障障和和灾灾难难的的响响应应 在建立了容灾系统以后，数据系统的故障和灾难主要将发生在 3 个地方（请注意，没有建立容 灾系统时，数据系统的主要故障点是 1 个）： 1)生产中心数据系统故障生产中心数据系统故障 生产中心数据系统故障意味着灾难，这也就是我们现在建立容灾系统的根本目的，对于这样的 灾难，我们来看一下我们推荐的容灾方案是如何响应的，见下图： 同城应用容灾系统方案 第 12 页 共 41 页 当生产中心的磁盘系统发生故障（灾难）时，由于同城容灾中心的磁盘是它的镜像，所以操作 系统会自动隔离生产中心的磁盘，转而对容灾中心的数据进行访问。从上图我们看到，业务系统可 以通过城域 san 网络直接访问灾备中心的磁盘系统的数据，而不需要有任何针对业务系统的动作。 也就是说，生产中心磁盘系统的灾难，对业务系统是透明的，应用和数据库不会因为生产中心磁盘 系统的故障而停止；更重要的是，因为应用和数据库不会因为灾难而异常中止，从而避免了发生数 据库损坏的可能。 生产中心磁盘系统故障之后，我们只需要更换损坏的磁盘系统，然后利用 volume manager 重 新生成镜像即可，重新生成镜像的过程，实际上就是将数据从灾备中心磁盘系统复制到生产中心磁 盘系统的过程。 值得注意的是：整个过程对应用完全透明，不需要也不会中断业务系统的正常运行。这是基于 磁盘系统间复制技术构建的容灾系统无法实现的。 灾备中心数据系统故障灾备中心数据系统故障 灾备中心数据系统故障，这是灾备系统建立以后出现的新问题，这种故障就同上一种故障类似， 但对业务系统的影响更小。 生产中心和灾备中心生产中心和灾备中心 san 链路故障链路故障 这种故障也是灾备系统建立以后出现的新问题。相对于以上两种灾难，这种故障在容灾系统建 立以后，出现的概率会更大一些，导致链路故障的原因很多，包括光纤断裂，光端设备故障等，都 会导致链路中断。这个问题其实是由“距离”引起的，正如我们在前面讨论的那样，虽然在原理上， 基于城域 san 网络实现的镜像技术和基于本地 san 网络实现的镜像技术完全一样，但是，我们还是 不得不承认，他们是有区别的，因为我们很少会担心一个机房内部不同磁盘系统之间的镜像会遭遇 链路故障，而在城域范围，我们是无法回避这个问题的。 一个完整的灾备系统，除了在数据灾难发生时，能够完成灾备的使命，同时，也需要考虑，灾 备系统本身的可维护性和可操作性。而对于链路故障，直接导致的就是业务数据在写到本地磁盘系 同城应用容灾系统方案 第 13 页 共 41 页 统的同时，无法写到灾备系统中，对于镜像技术而言，这又成为一个新的课题。 传统的镜像技术，在镜像链路被中断以后，中断的镜像会被认为完全作废，在链路恢复以后， 我们不得不将数据完整地从“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 技术，我们现在可以不用再担心容灾系统本身的可维护 同城应用容灾系统方案 第 14 页 共 41 页 性了。利用 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 技术实现增量同步的过程如下图所示： 同城应用容灾系统方案 第 15 页 共 41 页 4.1.3 方方案案的的技技术术优优势势 和其他容灾方案相比，veritas 容灾方案具有明显的优势，这些优势不仅仅表现在技术实现方 面，还表现在开放性、可维护性等各个方面。 结构简单结构简单 veritas 推荐的基于镜像的容灾方案较任何一种容灾方案为简单。在一个使用逻辑卷管理的应 用系统中（逻辑卷管理的好处我想大家已经深有体会，我想我在这里就不需要重复了） ，我们只是 利用了其中最常用、最成熟的镜像功能，就可以实现容灾，而不必像其他容灾系统那样增加很多不 必要的环节。 比如基于磁盘系统复制技术的容灾方案，我们必须在磁盘系统内部专门配置相应的接口卡，使 用该磁盘系统专有的复制软件，才可以构建容灾系统。明显的，该方法增加了一个在非容灾系统中 完全不需要的环节，不仅增加了故障源，同时也增加了维护强度。事实上，基于主机的复制技术存 在同样的问题。 技术成熟技术成熟 镜像技术是比任何数据复制技术更早使用于高可用系统的成熟的功能，这种功能已经广泛应用 于包括 ibm mainframe、as400、rs6000、hpux、digital unix、sun solaris、linux、windows 等 在内的所有服务器系统上，同时也被广泛用于磁盘系统内部作为企业级解决方案，象 emc、hds、hp、ibm、sun、compaq 等众多存储设备生产厂商，都将镜像技术内置于其磁盘系统内 部，用于对数据可用性要求最高的用户群。 存储开放性存储开放性 利用 veritas volume manager 的镜像技术，我们构建容灾方案时，不再要求生产系统和灾备系 统的存储系统必须是同一个品牌的，对具体型号更没有任何要求，体现了存储平台选择的开放性。 由此，用户可以获得在存储平台选择上的主动权，避免被存储厂商“绑架”的尴尬。 同城应用容灾系统方案 第 16 页 共 41 页 技术的完整性技术的完整性 veritas volume manager 拥有一个容灾方案必须的所有技术特性，它不仅可以提供可靠的镜 像技术，实现跨磁盘系统的数据容灾，同时，我们可以利用 volume manager 的 dco 和 fmr 技术， 保证该容灾系统的可维护性。 容灾系统的可视化管理容灾系统的可视化管理 一个灾备系统和生产系统是一个整体，而不是两个孤立的系统，一个系统的可视化管理工具， 有利于管理者将两个系统有机的结合起来，而不是分别处理两个独立的系统。 veritas volume manager vea 提供企业范围内全局的逻辑卷管理视图，通过任何一台安装有 volume manager 或者其 console 的系统，我们就可以访问我们想要访问的系统的（被授权）逻辑 卷，这意味着，我们可以将同一个应用的生产系统和灾备系统的逻辑卷置于同一个管理视图中，从 而实现对生产中心和灾备中心存储的统一管理。veritas vea 管理界面丰富，下图为其中一个管理 界面，仅供参考。 同城应用容灾系统方案 第 17 页 共 41 页 应对灾难，应用不中断，数据不丢失应对灾难，应用不中断，数据不丢失 veritas 建议的容灾方案，不会因为生产中心（或者灾备中心）磁盘系统的故障和灾难而导致 应用和数据库的异常中止，这不仅避免了对应用系统正常运作的影响，还避免了发生数据库损坏的 可能。 相比较而言，如果采用数据复制的方式（无论是基于磁盘系统的硬件复制方式还是基于软件的 数据复制方式） ，都需要在生产中心故障时对数据系统进行切换操作，反而造成业务的停顿。另外， 由于在灾难发生时，数据库系统的复制是即刻停止的，数据库系统没有经过正常的 shutdown，所 以不仅不可避免的导致部分交易的损失，甚至还有可能导致数据库的损坏。 i/oi/o 效率最佳效率最佳 从性能上来分析，在操作系统一级进行镜像，数据会在同一时间写入到两地的磁盘。数据可写 入过程是两组并行的操作，即本地写和完成信号返回+异地写和完成信号返回。 而相比较而言，数据复制技术需要通过以下 4 个步骤才算写操作完成： 1 数据先有操作系统写入本地磁盘系统 2 磁盘系统将数据通过链路复制到异地系统 3 异地磁盘系统完成写操作，返回信号给本地磁盘系统 4 本地磁盘系统返回信号给操作系统 明显的，这个过程和直接数据镜像相比，把原先并行的 2 组步骤变成了纯串行的 4 个步骤，并 且需要 scsi 到复制协议的转换过程，无论在流程上和反应时间上都会比直接镜像造成更多的延时， 对应用系统有更大的影响。 另外，在逻辑卷这个层面，我们可以根据需要对镜像的数据灵活设置，我们不需将所有磁盘进 行镜像，而只需镜像必要的逻辑卷（volume） 。这种灵活性在实际使用过程中将大大减少数据远程 复制的数量，从而避免对系统不必要的影响。 同城应用容灾系统方案 第 18 页 共 41 页 4.1.4 对对系系统统性性能能的的影影响响 大家都比较关心容灾系统建立以后对原有业务系统性能的影响，考察容灾系统对业务系统性能 的影响，主要从两个方面衡量，一是 cpu 资源的消耗，二是 i/o，特别是写操作的延迟效应。 cpucpu 资源消耗资源消耗 采用主机端的软件镜像技术，对 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/oi/o 的延迟效应（特别是写操作的延迟效应）的延迟效应（特别是写操作的延迟效应） 采用 veritas volume manager 的镜像技术构建容灾系统，其对系统 i/o 的延迟效应要小于任 何一种数据复制技术，不管是基于磁盘系统的硬件数据复制技术，还是基于主机软件的数据复制技 术，这在上一节中已经阐述。 这里我想要补充的是在整个容灾系统中，对业务系统的性能的影响最大的不是任何一种技术所 产生的负面作用，而是“距离” ，正如前面提到的，在 cache 命中率较高的系统中，距离对写操作 的影响较大，这和光的传播速度有关，光在 150 公里距离上的一个来回需要 1ms，在 15km 距离上 一个来回需要 0.1ms，我们列出一个对照表，供大家参考。本对照表不包含设备协议转换和光在光 纤中的折射等因素。同时，我们知道，100mb 光纤对应的速度是 ns 级的。 同城应用容灾系统方案 第 19 页 共 41 页 距离距离光传输距离光传输距离传输时间传输时间说明说明 15 km30 km100us 同城容灾中心的距离级别同城容灾中心的距离级别 150 m300 m1us 15 m30 m100ns 一个机房的内部距离一个机房的内部距离 1.5 m3 m10ns 一个主板的内部距离一个主板的内部距离 本地 cache 写的时间nsus 级 本地磁盘写的时间本地磁盘写的时间usmsusms 级级 综上所述，我们的结论是，只要是数据复制方式的同步方式能够做的系统，采用镜像方式也一 定能做，而且会做的更好。 4 4. .1 1. .5 5 容容灾灾案案例例 中国银联 it 中心的同城容灾中心项目 中国银联的信息中心的同城容灾中心，就是选择了 veritas volume manager 的镜像技术来构 建的，其生产中心和灾备中心分别位于上海市的浦东和浦西，两地相距超过 30 公里。 芜湖卷烟厂信息系统的同城容灾项目 另外，veritas 拥有丰富的容灾系统实施经验，我们参与的容灾项目除了采用镜像方式的，还 有利用传统的数据复制方式构建的容灾系统，包括： 中国联通光传输网络系统 中国联通光传输网络的容灾系统是由 veitas 通过华为提供的，这个方案是跨省际的，其中一个容 灾项目的生产中心和灾备中心分别在北京和广州。veritas 提供的这套超远程容灾方案是国内目前 业界唯一真正已实施的超远程容灾方案。要实现这种方案，我们只需要在现有的 volume manager 的基础上增加 vvr 模块，体现了技术和方案的延续性。 上海热线的容灾系统 公安部某应用系统从上海到广东南海的远程容灾项目 同城应用容灾系统方案 第 20 页 共 41 页 4 4. .2 2、构构建建完完整整的的应应用用级级灾灾备备中中心心 4.2.1 纯纯手手工工应应用用灾灾备备的的问问题题 本次需要构建的不仅仅是数据容灾中心，我们需要构建的是应用级的同城灾备中心，所以除了 要考虑在灾备中心购置等量的存储用于数据灾备以外，我们还需要购置同等处理能力的服务器系统 作为灾备应用和数据库服务器，以便在灾难发生时，能够完整的接管整个业务系统，包括数据和业 务处理能力。 两套系统配置难以完全同步的风险 对两套系统的管理是孤立的，而这两套系统应该是在各方面都相同的并严格的一一对应的。这 种局面除了导致管理复杂之外，同时还带来了两套系统配置不能及时同步、不能完全同步等风险。 这种风险将直接导致灾备中心在灾难发生时不能准确、及时地接管业务系统，这和我们建立该容灾 中心的基本要求“必须保证容灾中心在一小时以内全面接管生产中心的作用”是相背的。 事实上，我们在生产中心建立集群系统的时候，集群系统不仅给我们提供了主机故障时的业务 接管功能，同时，还给我们提供了保证业务主机和备用主机之间配置的一致性的同步资源管理功能。 一个系统对另外一个系统的顺利接管，需要日常的、长期的维护和精心的准备，而不是简单的在备 用系统上输入几个命令来完成的，而集群软件为这种需要提供了行之有效的方法。 本地的主服务器和备用服务器之间尚且如此，那么生产中心和灾备中心之间该如何处置呢？事 实上，完全靠人工去保持生产中心和灾备中心这两个不在同一个机房的系统的配置保持动态一致， 是一件费力费神的事情，同时还是一件费力不讨好的事情。这种手工操作方式不利于灾备中心的可 靠性、稳健性。 灾备中心接管难度大 由于在灾备中心和生产中心之间没有集群系统，灾备中心对生产中心的接管将完全依赖于手工，这 无谓的加大了灾备中心接管的难度，在各种因素引起的专业技术人员不能及时到位的情况下，这种 难度将直接导致灾备中心不能及时的、成功的接管业务。我们知道，我们建设的是“灾难”备用系 统，灾难的定义不是简单的“磁盘系统故障” ，它可能是任何情况。所以灾备中心的接管流程要求： 同城应用容灾系统方案 第 21 页 共 41 页 1）全面，包括简单的，也包括复杂的；2）尽量提供简单的流程。 管理难度大 生产中心和灾备中心两套系统完全孤立，没有办法同时监控，更不用说在一个界面上对这些系统统 一监控和管理了，我们难以同时对两地配置进行跟踪和修改，无谓的增加了灾备系统维护的难度和 强度。 解决以上问题的办法是：在生产中心和灾备中心之间构建高可用集群系统。 就如同我们在一开始所讲的，在城域 san 网络上构建的镜像系统和在同一个机房内部构建的镜像系 统在逻辑上是完全相同的，同样的，我们要推荐的在城域 san 网络上构建的集群系统和在同一个机 房内部构建的集群系统在逻辑上也是完全相同的。 城域范围内和镜像技术配套的集群技术，和用于远程复制技术下构建远程集群的技术不同，我 们这里推荐的城域范围的集群系统不是传统的远程集群模式，而是传统的本地机群技术的扩展。实 际上，它所采用的软件产品和基本技术，完全就是本地集群软件，只是，我们需要这些集群软件提 供必要的功能扩展，以满足城域范围的特定的需要。在这里，我们称这种模式为“准本地集群”模 式，也可以称为“campus model” 。 “准本地集群”模式实际上和大家非常熟悉的本地集群模式是一样的，在这种模式下，生产中 心的系统和灾备中心的系统将被纳入同一个集群主体中，从而我们可以非常轻松的实现对两个中心 的统一管理。其结果，就是给我们带来管理的简单化和灾备系统的可靠性。下图为利用 veritas 集 群软件 veritas cluster server (vcs) 进行集群管理的一个界面示意，通过该界面，我们可以知 道，利用 vcs，我们可以非常方便的管理生产中心和灾备中心的系统，并将生产中心和灾备中心纳 入到统一个集群管理体系内进行统一管理。 同城应用容灾系统方案 第 22 页 共 41 页 当然，在我们构建这个“准本地集群系统”的时候，我们还是要正视由“距离”引起的一切问题， 我们需要在技术层面去解决它，这也是为什么我们在方案中建议的集群软件是和本地集群完全相同 的 veritas cluster server 软件，但却称这种集群模式为准本地集群模式的原因。 4.2.2 建建立立覆覆盖盖灾灾备备中中心心的的统统一一集集群群体体系系 为了有效的管理灾备中心，同时保证在灾难发生的时候，能够在要求的时间里快速的恢复系统 的正常运行，我们需要建立一个横跨业务中心和灾备中心的“准本地集群系统” ，这里，我们建议 采用通用的本地高可用集群软件（也称 ha 软件） ，构建的应用容灾系统。 我们都非常熟悉如何利用 ha 软件来建立集群系统的，目前的许多系统都有各种各样的 ha 软件， 那么是否所有的集群软件都可以支持这种“准本地集群系统”呢？ 答案是“no”！ 构建“准本地集群系统” ，我们需要在原有的集群系统的功能上有新的扩展，以便满足城域环 境下的特殊要求。我们现在分析一下同城集群系统和本地集群系统的区别，然后再来分析需要怎样 的技术扩展。 同城应用容灾系统方案 第 23 页 共 41 页 在磁盘镜像结构和集群系统结构上， “城域 san+城域 ip 网络”的环境和本地系统没有什么逻 辑上的区别，但是就集群系统而言，仅仅是距离的变化，就会导致以下两个新问题（距离对镜像技 术的影响和相应的方案，我们在数据容灾一节已经详细阐述，这里不再说明）： 1 集群系统的心跳线需要跨越几十公里，而不是几十米 2 同城生产中心和灾备中心的网络更容易因意外而中断，其中包括心跳线 这两个因为距离而产生的新问题，需要我们在构建集群系统时，不得不从技术层面仔细分析， 以便保证我们推荐的方案的可靠性和可行性。下面，我们就这两个问题从技术层面展开讨论。 4.2.3 跨跨越越几几十十公公里里的的心心跳跳技技术术支支持持 城域集群将跨越几十公里，这对集群心跳的技术要求非常简单，就是要求集群软件能够支持跨 越几十公里的心跳技术。 veritas cluster server 能够很好的支持远程心跳通道，vcs 对远程心跳通道只有一个要求， 就是支持广播。也就是说，只要两个 site 之间有不经过路由器、桥这样的设备的通道，就可以支 持 vcs 的心跳。 需要说明的是，我们这里需要心跳的动机和传统的心跳技术的目的不同，传统的集群心跳的目 的包括： 1 同步集群配置信息和集群状态信息 2 监控 active 的业务服务器是否运行正常 3 根据监控信息，激发集群在主业务服务器系统没有相应的时候，自动切换服务器。 但是，我们这里需要心跳的目的只包含前两条，而不包含最后一条，原因是我们的生产中心灾 难后的切换，应该是在人工确认后手动发起的，我们不需要自动切换。 但不管怎样，我们还是需要心跳来构建这样的集群系统。 同城应用容灾系统方案 第 24 页 共 41 页 4.2.4 为为什什么么需需要要人人工工确确认认灾灾难难 我们好像已经已经习惯了“生产中心到灾备中心的切换需要人工确认的”这个规则了，我们也 已经习惯了“如果不经过人工确认，就有可能导致误操作”这种说法了，但是为什么本地集群系统 就可以自动切换呢？我们的“准本地集群系统”和真正的本地集群系统在逻辑上是相同的，为什么 我们还是需要坚持采用“灾难人工确认”原则呢？ 其实，在“没有必要自动切换”的说法背后，其真正原因是：凡是远距离的集群系统，都无法 象本地集群系统那样，可以提供足够可靠的心跳通道。 我们知道，本地集群系统可以提供多种冗余技术，保证心跳通道不在同一时间一起中断，常见 的心跳冗余技术有： 1 采用双以太网卡作为冗余心跳通道 2 采用双 rs232 端口作为冗余心跳通道 3 采用公网（业务以太网通道）作为辅助冗余心跳通道 4 采用共享磁盘作为辅助冗余心跳通道 相对而言，远程集群系统除了能够利用远距离以太网连接作为心跳以外，就没有其他冗余措施 了，我们知道，城域范围的网络本身的可靠性要比一个信息中心内部的专用网络的可靠性低很多的， 而且具有更多的不确定性，比如，一次光纤事故就可能会导致所有的心跳通道同时中断。 如果我们无法保证心跳通道的可靠性，那么就有可能出现因为心跳通道本身的故障而引起的 “虚假灾难” ，也就是说，当主业务系统实际在正常运行的情况下，备用系统却因为无法收到对方 的心跳而认为对方已经“停止运行” ，并强行接管数据和网络系统，这种情况在技术领域我们称为 “split-brain” ，也就是说一份数据，两个大脑。这种情况对数据系统是非常危险的，两个服务器 对一个数据资源的强制争用，会导致业务数据的不一致，更有甚者，会导致业务数据的不可逆损坏。 一个“假灾难”会引起“真灾难”的发生，这是谁都不会允许的。 除非我们有足够可靠的心跳安全技术和策略，否则，为了避免这种“意外灾难”的发生，我们 都会建议在灾备系统的接管策略上，采用“灾难人工确认”原则的。 同城应用容灾系统方案 第 25 页 共 41 页 这里，我想补充说明一下，实际上，我们推荐的 veritas cluster server 可以提供其他特有的 技术手段来弥补远距离心跳安全性方面的缺陷，严格来讲，vcs 可以支持容灾系统的远程自动切换。 通过配置 i/o fencing 仲裁盘方式可以规避由于心跳原因造成的“裂脑”现象。但是我们原则上还 是建议异地应用容灾采用“灾难人工确认”原则。 4.2.5 建建立立一一个个满满足足灾灾备备需需要要的的集集群群系系统统 现在新的技术需求出现了，因为我们需要构建这样一个集群系统： 1 一个集群系统，覆盖一个应用相关的所有服务器系统，不仅仅包括生产中心的系统，还需 要包括灾备中心的备用系统。 2 一个应用的集群系统内，生产中心内的服务器节点间是可以自由切换的，并且是需要自动 切换的，而生产中心到灾备中心的节点的切换却是不允许自动发生的。 我们知道，要统一管理生产中心和灾备中心的系统，我们必须将同一应用的不同服务器同时纳 入同一个集群系统，如下图。 在集群逻辑上，我们要求这 3 台服务器同时属于同一个应用的集群系统，任意对这个应用集群 的调整，其配置信息都将同步的传递到这 3 台服务器上，同时，这 3 台服务器作为集群节点，都处 于 enable 状态，都在监视彼此的活动状态，并及时把配置和状态信息的变化传递给集群内部的其 他服务器系统。 同城应用容灾系统方案 第 26 页 共 41 页 但是从应用逻辑上来看，我们对这 3 台服务器的角色要求还是有区别的，我们要求生产中心的 服务器 a 和 b 之间是允许并要求支持自动切换的，而容灾中心的服务器 c，是不允许自动接管生产 中心的业务的。 我们要求服务器节点 c 对业务的接管，需要经过人工确认，然后我们利用在服务器节点 c 上的 接管定义，实现应用的单键切换。这种要求需要服务器节点 c 的各种资源配置始终和生产中心的服 务器节点 a 和 b 保持一致。这样，相对于纯手工切换，我们推荐的这种方式要平滑的多，并可以更 好的保证灾备系统在计划的时间内顺利投入运行。 本方案推荐的 veritas cluster server 软件可以全面地提供这方面的技术，满足这种策略的需 要，从而可以帮助建立覆盖生产中心和灾备中心的统一的集群系统。 4 4. .2 2. .6 6 业业务务系系统统故故障障和和灾灾难难的的响响应应 业务系统故障和灾难的种类很多，不过我们只要解决了一下几个问题，其他的问题就不是问题 了，下面，我们就这几个问题分别予以阐述。 1. 生产中心主业务服务器不可用 2. 生产中心所有服务器不可用 3. 生产中心和灾备中心之间心跳链路故障 4. 生产中心所有服务器和磁盘系统不可用 同城应用容灾系统方案 第 27 页 共 41 页 1)生产中心主业务服务器不可用生产中心主业务服务器不可用 生产中心主业务服务器 a 发生故障，这只是常规意义上的服务器单点故障，利用 vcs 集群软件， 我们可以非常简单的在生产中心内部完成应用从服务器 a 到服务器 b 的自动切换。如下图： 同样的，在服务器 a 的故障修复以后，我们可以继续让应用运行在服务器 b 上，而把服务器 a 作为第一备用服务器；也可以将应用回切到服务器 a，恢复到故障发生前的状态。 2)生产中心所有服务器不可用生产中心所有服务器不可用 当生产中心所有的服务器系统都发生故障时，就遇到了我们所谓的服务器系统灾难，这个时候， 服务器系统 c 发现服务器 a、b 均出现了问题，于是做好的了接管应用的准备，但是根据预先定义 的规则，服务器 c 不会自动接管该应用，而是等我们人工确认灾难的真实性后，由管理员连接到服 务器 c 的集群系统上，启动接管流程。集群软件会根据我们在集群软件中定义好的接管流程，依次 启动该应用需要的系统资源、存储资源、网络资源、数据库和应用资源，实现应用的平滑接管。整 个应用接管的过程如下图： 同城应用容灾系统方案 第 28 页 共 41 页 3)生产中心和灾备中心之间心跳链路故障生产中心和灾备中心之间心跳链路故障 当生产中心和灾备中心之间所有的心跳链路同时发生故障时，生产中心会认为灾备中心的服务 器 c 发生故障，并将该服务器 c 从集群中隔离出去，整个过程对应用系统没有任何影响，之后，我 们在生产中心仍然保持一个由服务器 a 和服务器 b 构成的集群。 与此同时，在灾备中心，灾备服务器同样会认为生产中心发生灾难，从而将服务器 a 和服务器 b 从集群中隔离，保留自身构成单节点集群。由于我们预先定义的策略是灾备系统不自动接管业务， 所以灾备系统不会试图接管任何和业务相关的系统资源。在人工确认以后，我们发现这是由心跳链 路故障引起的“假灾难” ，于是我们可以 disable 灾备中心的集群系统，并设法修复心跳链路，然 后，我们可以再将灾备中心的服务器 c 重新加入到由服务器 a 和 b 构成的集群中去。 veritas cluster server 支持动态的集群节点加入，所以，事件的整个过程对业务系统不会 产生任何影响。相反的，其他我们以前使用的集群软件，在遇到上述情况后，恢复该集群新节点时 是需要暂停应用的。 4)生产中心所有服务器和磁盘系统不可用生产中心所有服务器和磁盘系统不可用 生产中心所有服务器和磁盘系统不可用，这种情况一般只有在真正的灾难的情况下才会发生， 同城应用容灾系统方案 第 29 页 共 41 页 包括自然灾难和人为灾难。这种情况下，我们需要灾备系统在确认灾难以后，能够快速的、准确地 接管所有关键业务系统。 这种故障和上面第一种情况的不同之处在于，生产中心的磁盘系统同时发生了故障。这种情况 会带来一个新问题，那就是在一个逻辑卷镜像的一个 plex 损坏的情况下，我们需要将该逻辑卷所 在的 disk group 强制 import，这种处理方式和磁盘系统没有损坏的情况是不同的，对于手动处理， 我们需要制动不同的接管命令流程，而对于集群系统，我们则需要集群系统提供针对这个问题的监 控、判断的能力，以及选择合适启动流程的能力。 针对这种情况，veritas cluster server 提供的 campus agent 可以帮助用户简化灾备系统管 理程序和灾难恢复程序。vcs campus agent 提供了一系列针对城域集群系统的解决方案，利用 vcs campus agent，我们可以非常轻松的构建一个覆盖灾备系统的集群系统。下图是在生产中心发生灾 难的情况下，灾备系统的接管流程的示意图： 同城应用容灾系统方案 第 30 页 共 41 页 4.2.7 方方案案的的优优势势 我们推荐的城域集群方案，为构建稳定的、可靠的、易于管理的灾备中心非常有帮助，该方案 的优势主要表现在以下几个方面： 1 有利于保证生产中心和灾备中心资源配置的一致性 2 有利于简化灾备中心灾难应急的流程，保证灾备中心快速、顺利的接管相应的应用系统。 3 方案在技术上支持远程心跳，可将集群扩展到城域范围。 4 方案拥有先进的 campus agent，解决城域集群特有的问题。 5 方案支持灵活的集群策略，满足灾备中心管理的各种需要。比如自动接管和手动接管并存 这种集群模式。 6 图形化管理，简单直观，减轻管理压力，减少集群系统认为事故。 7 方案支持应用级的监控和集群管理。 相对于 hacmp 仅仅提供硬件级的故障监控，vcs 可以提供应用级的生命监控，不仅能在硬件系统发 生故障时，及时检测并切换主机，还能判断象数据库进程挂起这样的应用级别的软故障，并针对这 些故障，提供快速的处理，包括应用重启或应用切换。 8 支持多平台，简化管理，降低管理成本 veritas cluster server 支持包括 ibm aix，sun solaris，hpux 等在内的多种通用的开放平台， 也支持 linux 和 windows 平台，不管是现在，还是将来，将集群平台集中到 vcs，可以大大简化我 们的日常集群管理工作。我们的技术人员不必再需要针对每一种平台，学习不同的集群软件管理和 问题诊断的方法；我们企业，也不再需要针对每一种平台，都花钱培养相应的集群软件管理员了。 同城应用容灾系统方案 第 31 页 共 41 页 五五、v ve er ri it ta as s c cl lu us st te er r s se er rv ve er r 简简介介 5.1 业业界界领领先先的的高高可可用用应应用用解解决决方方案案 veritas cluster server是业界领先的开放式系统集群解决方案，是消除计划内和计划外停 机时间，简化服务器合并，并有效管理多平台环境内广泛应用的理想选择。 要保障信息访问，应用和数据就必须符合严格的正常运行要求。鉴于用户需要以电子方式获取 更多的服务，提升应用正常运行水平的需求也急剧增长。veritas cluster server