备份及容灾方案建议书
VERITAS Software (Beijing) Co., Ltd
Suite 1008, Tower E3, Oriental Plaza No.1 East Chang An Ave, Dong Cheng District, Beijing
Tel: 8610-85180008
Fax: 8610-85186718
Web: www.veritas.com
目 录
背景分析
通过前期接触，我们了解到目前航信的数据中心已经建立一套重要的业务系统，用来支撑电子客票、运价、常客、数据仓库等重要业务。随着业务系统的不断发展，航信数据中心对核心应用的连续性和高可用性的要求越来越高。由此，同城异地的容灾中心是目前条件下能够给数据中心提供更高可靠性的理想方案，也是业界流行的IT架构。受到XXX的委托，Symantec依托于在容灾领域多年的成功经验，根据目前XXX的数据保护现状进行统一考虑，并提供关于容灾建设的一点建议供XXX参考。
数据保护现状
目前，在XXX的数据中心中已经有数据备份软件Netbackup在运行，可以对核心数据进行时间点的备份。但是对现有的数据中心中的核心存储设备平台还有可以优化的余地，也应该在未来的规划中实现对存储资源的统一管理和规划。在未来的系统扩容时，也还可能有不同的硬件平台进入，如果已经有一个统一的存储管理平台，将会把数据中心的自动化上升到一个新的层面。从XXX提供的容灾需求来分析，除了核心的数据库服务器之外，其他的服务器需要满足RPO=24、RTO=48小时的指标。这个指标完全可以通过优秀的本地备份策略来完成。
系统容灾方案
从目前的系统发展来看，系统的容灾可以分为应用级容灾或数据级容灾，应用级的容灾要求从应用层面上实现对系统的容灾，是一种比较高的容灾方案因此对系统的软、硬件的要求都比较高，而且应用级的容灾系统要求对数据的丢失量是0级。而数据级的容灾从某种意义上讲是基于传统的数据的备份，通过对历史的数据备份来实现对数据的保护，当系统出现问题时并不象应用级容灾一样，系统回马上切换到容灾的系统，并确保业务马上运行起来，而且数据级的容灾可以允许系统在一定时间内的数据量的丢失。只要系统能够通过备份的系统把出现灾难的系统恢复起来，或在容灾节点把系统恢复起来即可。
依据XXX最终提供的对系统容灾的要求，我们认为可以分成下列几个部分来建设容灾系统。
l 数据备份和系统容灾
l 部署VERITAS Storage Foundation软件，实现数据统一管理
l 建立数据复制链路，确保数据容灾
l 实现同城异地应用切换，达到应用容灾
下面我们针对这几个步骤作详细阐述。
数据备份
XXX中可以用作数据备份的设备有一台XXXX的XX。在容灾系统中，对于数据的离线备份和磁带保存是利用现有设备实现基础数据和应用容灾的最便捷的方式。
因此，我们建议采用Symantec的Netbackup软件来为生产中心和容灾中心建立数据备份，保证数据库数据的时间点拷贝。备份系统的核心是VERITAS NetBackup Master Server，它安装在性能高、工作稳定的备份服务器上，它对整个备份系统进行监控和管理。对系统中2台数据库服务器，在存储区域网SAN环境下出于节约网络资源和减小备份窗口的目的，通过安装NetBackup SAN Media Server，实现lanfree的备份。对数据库服务器数据库的在线备份可通过相应的NetBackup DB Backup Agent在线完成。
装有机械手的磁带库接入到SAN网络，对于带库的自动化管理和共享使用通过NetBackup Shared Storage Option模块完成。
备份方案特点
数据备份系统是系统数据安全的最后保障，涉及到业务安全运行，影响到对外声誉，是整个方案设计的重中之重。因此，我们加强了对数据备份系统的设计，通过部署连续五年市场占有率第一的NetBackup产品进一步带来了以下独到的优势：
1． 备份系统开放性。利用独立备份软件供应商的优势，提供对业界所有软硬件平台的最完全的、最广泛的支持能力。
2． 产品的市场占有率。VERITAS提供业界领先的成熟产品，在UNIX高端系统和Windows平台中占有领先的市场份额，且具有大量在国内外大型客户中成功实施的案例。
3． 数据的可恢复性。
l 一键恢复——采用业界功能最强、恢复速度最快、支持平台最广泛的单键恢复技术BMR，对HP-UX，AIX，Windows等业务主机进行快速一键恢复
l 磁带灾难恢复——在发生灾难导致备份服务器崩溃的情况下，直接通过TAR命令从磁带上恢复数据。
l 异机恢复——将数据恢复到不同的主机系统上进行合法性测试。
l 检查点恢复——数据恢复过程中途可设立检查点，支持快速断点恢复。
4． 备份系统的可管理性
l 完全图形化管理——百分之百图形化界面，无需任何命令行操作。
l 集中管理——对各地的备份系统进行集中统一管理。
l 策略管理——具备日历备份策略、频率备份策略、即时备份策略、全备份、增量备份、累积备份、真实映像备份等多种备份策略。
l 数据库备份管理——面向数据库的图形化、快速、在线备份。
l 打开文件备份管理——支持对Windows的打开文件进行备份管理
l 磁带管理——磁带可进行容灾复制，并进行出库保存
l 安全管理——支持防火墙，多种安全管理权限设置。
5． 备份系统的性能
l 网络带宽控制——动态指定备份数据流占用的网络带宽，保证征期内的备份数据不影响业务运行。
l 磁带多路复用——来自多个网络客户端的备份作业可同时直接写入单盘磁带，克服网络瓶颈。
l 磁带多路分用——批量备份数据可同时分布到多盘磁带上进行备份，克服磁带机I/O瓶颈。
l 快速备份引擎——业界备份速度最快的备份体系结构
6． 备份系统的可靠性
l 备份服务器可靠性——支持备份服务器集群，支持备份服务器的崩溃重建。
l 备份设备可靠性——多个磁带机可动态互为备份。
l 备份磁带可靠性——备份数据可同时写入多盘磁带进行镜像。
7． 备份系统的可扩展性
l 备份节点扩展——备份系统可无缝扩展，保护投资
l 向灾备系统扩展——可支持设定远程磁带灾备中心
l 向未来的备份技术扩展——VERITAS是业界公认的首席备份软件供应商，和业界的所有硬件厂商形成合作伙伴关系，可保证在目前的规划基础上提供更强的备份功能，如Server Free，0 downtime Backup等等。
数据备份的过程
对于XXX业务系统，我们会在所有数据库服务器上部署相应的Netbackup SAN Media Server软件及用于数据库在线热备份的Agent。
这样，在定义好备份系统资源和策略后，在指定的时间，备份系统就会自动的将数据库服务器上的数据从服务器上、采用指定的方式、通过指定的磁带驱动器备份到指定磁盘池中。
在备份结束后，系统会报告备份的状况，然后，系统管理员就会在VEIRTAS Netbackup管理界面上清楚地看到已经备份的数据的描述。在VERITAS Netbackup上对备份介质上的数据的管理采用的是简单易懂的目录结构。系统管理员通过该目录下的备份项目可以非常方便的察看已经备份的数据的情况，包括：这个数据是什么时候对哪个数据库的备份，采用的是哪一种备份方式（全备份？增量备份？还是累计增量备份？）。一个完整的备份包括一条或几条备份项目，一般包括一个全备份项目、一个累计增量备份项目、几个增量备份项目。你可以保留以前的备份—在最近一次全备份以前的备份。也可以同时对一份数据做两个备份。
备份系统对数据库的备份采用的是在线备份，通过VERITAS Netbackup的database Agent，我们可以在不停止数据库运行的情况下，对数据库数据进行备份，包括全备份、累计增量备份或者增量备份。这种备份方式，保证了系统的7x24小时的运行。
数据的恢复
当发生数据损坏时，我们需要从磁带库恢复数据。
有了VERITAS Netbackup，数据的恢复是非常快速和简单的。通过Netbackup管理界面，系统管理员只需要选定相应的数据备份项目（备份管理目录下的相应的项目名，对应某个时间点备份的某个数据库的数据，并有说明），进行恢复（Restore）即可。选择备份项目时，如前所述，首先选定最近一次全备份进行恢复，然后选定最近一次累计增量备份，最后选定这次累计增量备份以后的所有增量备份项目，依时间顺序进行恢复即可。
系统恢复
在这次方案中，我们建议在主中心和灾备中心各实施一套Netbackup备份系统，将两个数据中心中的核心数据通过相关的数据库代理备份到后台连接的磁带库中。同时，结合Netbackup的Vault（磁带保险库）的功能，我们可以做到在同城两个站点之间的磁带级容灾，也保证了历史数据的高可靠性。数据备份的目的是为了提供一套最基本的数据恢复手段，让用户在第一时间能够使用最便捷的方式实现一定时间内的应用重新上线，特别是对于操作系统级的恢复，本地的磁带备份是不可或缺的。
我们首先将数据备份作为容灾的基本步骤，不仅是因为实现起来方便，也同时能够满足XXX容灾要求中提到的，对iPlanet和Websphere系统PRO和RTO的要求。由此，我们就建立了一套容灾方案，首先将整个系统中最容易完成的部分解决，而后再对核心服务器的数据进一步保护。
Vault功能的简单说明
作为VERITAS NetBackupTM的选件，VERITAS NetBackup Vault 可将冗长的备份复制和异地介质管理过程自动化。用户可以建立档案，控制备份复制的内容、时间和方式，以及磁带何时运往和运出异地磁带保险库（Vault），最大限度地减少灾难发生时的数据损失。NetBackup Vault 能够管理详细信息，从而使系统管理人员能集中精力处理更加紧迫的事务。
需要考虑到，在一套完整的容灾方案中，一定要包括的是针对服务器系统的灾难恢复办法。由此，当重大故障或者灾难发生时，核心服务器的系统恢复也能通过容灾系统在RTO允许的范围内实现。这样，我们使用VERITAS的Bare Metal Restore来对XXX数据中心中的Unix主机进行保护，做到真正的裸机灾难恢复，从而避免了仅由于硬件故障需要的系统重装和配置步骤，节省了大量的恢复时间，为应用系统和数据的恢复提供了良好的工作平台。
Bare Metal Restore的工作原理
Bare Metal Restore与NetBackup软件配合运行。与往常一样，客户端的数据仍将备份到NetBackup服务器上。然而，在每次定时备份前，Bare Metal Restore会自动执行另外一个进程，以记录系统配置的当前状态，包括磁盘分区的布局信息和TCP/IP配置。如果机器的相关配置被更改过，则下次定时备份之前还会自动捕捉和记录这些变化，而无需用户介入。
使用Bare Metal Restore软件，您可以轻松地自动完成服务器恢复过程。用户可在Bare Metal Restore服务器上使用命令行，或者使用基于浏览器的简单界面，发出“Prepare to Restore”命令，开始进行恢复的初始化工作。Bare Metal Restore软件将立即检索客户端的配置数据，并使用这些数据为客户端创建定制的恢复过程，通过网络将客户端定向到相应的引导映像(boot image)和文件系统。
然后，客户端将从准备就绪的引导服务器(boot server)进行引导，开始运行定制的引导程序。该程序将执行以下任务：
l 从文件服务器安装必需的文件系统
l 配置磁盘、逻辑卷和文件系统等
l 向NetBackup软件发出命令，使用NetBackup服务器来恢复文件，包括操作系统、配置数据、应用程序和用户文件
上述任务完成后，客户端将配置引导记录和配置数据库，然后进行重新引导，恢复到正常运行状态。
通过Netbackup+BMR的工作，我们就对数据中心中的核心数据有了一个基础备份，再通过Vault的功能在两地实现磁带容灾后，数据备份和系统的灾难恢复的准备工作就成功完成了。
部署Storage Foundation软件
为什么需要在XXX中部署Storage Foundation软件？通过我们长期与XXX的接触，以及在同其他大客户的工作过程中，我们发现，通常为了保证系统升级的灵活性，不局限于某个硬件厂商，也为了能够在系统扩容和采购时选取到性价比最好的硬件产品，大规模的数据中心中绝大多数采用了混合平台的系统架构。也就是说，核心应用及其数据的存储是分散在不同平台的资源中的。这样，用户解决了同一硬件平台带来的惯性升级和购买限制。但是，显而易见的，多种硬件平台的存在也使得后期维护成本升高，管理复杂，难以实现整合的资源管理和分配，并有可能造成存储资源不必要的浪费。针对这一问题，同时XXX也提出了充分利用现有设备的要求，存储虚拟化就成了最好的解决方案。VERITAS Storage Foundation是Unix/Linux、Windows平台上存储虚拟化的出色产品，它不仅能够做到存储整合，也是后面将要提到的数据复制步骤的前提条件。在核心服务器上部署Storage Foundation之后，无论是现存的硬件还是将来可能要购买的其它硬件都能够在未来的数据中心中作为统一的存储资源被管理和分配。这也是大多数我们的客户最终采用VERITAS Storage Foundation作为存储系统底层支持架构的重要原因。
VERITAS Storage Foundation包含了VERITAS Volume Manager以及VERITAS File System两个组件。
VERITAS Volume Manager允许跨越许多主机和操作系统，通过单一管理控制台执行在线管理，并允许在不中断数据访问条件下，改变磁盘存储器配置，即能够改变RAID布局和增强容量。这将消除代价昂贵的破坏性故障停机时间。VERITAS Volume Manager使用冗余技术保护数据，以免因为磁盘和硬件故障造成数据丢失和破坏，从而增强数据可用性。它支持RAID 0、RAID 1、RAID 1＋0、RAID 0＋1和RAID 5，有利于实现数据冗余性。动态多通道 (DMP) 技术通过提供路径故障切换机制，提升系统可靠性。如果1个磁盘连接发生故障，系统将通过其它正常的磁盘连接访问关键数据，直至故障路径被更换。在线重布局功能允许在不中断数据访问的条件下，改变卷布局。在当今不断变化的以电子商务为重心的环境中，很多客户已开始利用SAN的巨大潜能，保障服务器应用的可用性。VERITAS Volume Manager是实现最大化SAN应用正常运行时间，特别是飞速发展的国际互联网商务运营的理想工具。VERITAS Volume Manager的内在特性，允许在复杂的网络化存储环境内，通过对物理存储资源执行虚拟化处理，增强应用的可用性。通过SAN网络对存储资源执行虚拟化和集中化管理，可以减少管理开销，并为管理国际互联网驱动型商务运营的不可预见性增长，提供一个可缩放基础。
VERITAS File System能够实现在线系统备份，允许在执行备份操作期间访问数据。除此之外，它还能够显著地减少系统崩溃恢复和重新引导所需要的时间，在发生此类事件的数秒钟内，即为用户实现文件系统数据的可用性。提升数据的可用性，有利于提升所有用户和管理员的生产效率。VERITAS File System通过在专用日志维护未完成元数据的变化信息，实现持久不变的文件系统数据完整性。如果发生系统崩溃，恢复过程将遍历该专用日志，以重放未完成事务。除保障数据完整性外，该特性还显著地减少了系统恢复需要的时间，因为文件系统恢复时间现在基于专用日志的大小，而不是文件系统的大小。VFS的在线管理特性包括文件系统备份、整理碎片以及扩大或缩小文件系统规模的能力，以满足用户的动态需求。除交付文件系统管理外，VERITAS File System还允许管理员控制各个文件的某些方面，从而提高控制颗粒度。
通过在即将放置到主中心和灾备中心的Oracle服务器上部署Storage Foundation软件，我们建立了良好的存储虚拟化基础，能够灵活的适应未来的系统扩容要求，也为接下来的数据复制工作做好了准备。
数据容灾
如图所示，前面我们对于RPO=24，RTO=48的iPlanet和中间件系统已经做出了容灾的设计。接下来对于XXX容灾系统中RPO=0的核心部分——同城异地数据容灾，我们有两种考虑供XXX参考。这两种考虑是基于我们长期在容灾领域的经验，对XXX未来容灾中心所作出的建议。一是采用在XXX已经实施过的硬件方案，利用磁盘阵列的复制功能队核心数据提供同步复制以满足RPO=0的要求。二是采用基于主机的软件复制方案来进行数据复制。第二种方案有可以分成两种办法：采用网络的方式进行数据复制；直接利用主中心和灾备中心之间的DWDM光纤线路构架成的SAN网络，做到数据的镜像存储。
在具体谈到某一种技术之前，有必要对不同的方案进行优缺点分析来又针对性的研究相关的实施细节。
对于硬件复制的方案，它的优点很明显，对主机资源的占用非常少，完全可以保证在一定距离内实现真正意义上的同步数据复制。但是，就如同XXX容灾需求中提到的一样，随着距离的加长，拥有低延时、高带宽的数据链路就成为了硬件复制实现的障碍。而且，硬件的复制方案对于平台品牌的选择和异构的存储环境也设置了相当多的限制。
同样，对于软件复制方案来说，优缺点也一目了然。它的优势主要体现在跨平台和超远距离容灾上。基于IP的数据复制完全不受距离的影响，理论上能够让用户在地球上任何两点之间建立容灾关系。在实际的操作过程中，结合Symantec的容灾应验，我们不得不说明的是，在RPO=0这样的前提条件下，无论是硬件，还是软件，它们对于数据链路带宽的要求是相当的高的，这无形中就让容灾成本上升了一个台阶。那么，软件复制虽然在理论上能够实现超远距离的同步复制，它也有不可回避的缺点，那就是对主机资源有一定的占用，和建立多条复制链路的必要。由于软件复制完全基于主机，即便是存放在一个磁盘阵列上的数据，也需要不止一条复制链路来支撑。
软、硬件方案都有各自的优势。由于Symantec公司的容灾产品完全基于软件，因此，在下面的介绍中，我们仅针对Symantec公司目前拥有的软件容灾产品的详细技术细节进行阐述，来让XXX对软件方案的可行性有进一步的了解，从而更清晰的考虑未来容灾中心中应该采用的技术。
最后特别说明的是，Symantec提供的软件方案具有相当大的灵活性，完全可以结合硬件复制技术实现同城异地的应用级容灾，而不是强行将用户捆绑在某一个产品或者技术上。这一点也希望XXX的专家们在对方案进行评估的时候，充分考虑进容灾技术的灵活性和可扩展性上。
数据复制
第一种方式的优点是灵活性比较高，不依赖于光纤线路，只要在主中心和容灾中心之间有连通的IP网络即可。这一方式需要采用VERITAS Volume Replicator作为数据复制的软件，既能做到完全同步的数据复制到灾备中心，同时也能够实现异步复制。
VERITAS Volume Replicator的工作方式说明如下：
首先使用VERITAS Volume Manager(简称VxVM) 在物理磁盘上建立多个或一个逻辑卷(Volume)。以裸设备的方式使用卷，或在卷上建立文件系统。将数据（特别是需要进行远程复制的相关文件系统、数据库）存放在卷上。由于数据复制是基于卷的，所以，Volume 是进行复制的基础。
VERITAS Volume Replicator(简称VVR)负责远程数据复制。VVR复制基于Volume进行。复制的数据可以是数据库中的数据（文件方式或裸设备方式）和文件。复制的示意图见图。
1) VVR与VxVM完全集成在一起。用VxVM管理界面和命令统一配置管理；由于VVR仅仅将Volume上每次I/O的实际数据实时复制到远程节点，所以在网络线路上传输的数据量很少，对带宽的需求也很小。；
2) 将各个业务系统中需要进行远程复制的多个或一个卷定义为一个Replicated Volume Group(简称RVG)；
3) 在Site A定义一条RLINK，指向Site B；在Site B也定义一条指向Site A的RLINK。RLINK是单向的；需要进行复制的两个系统各定义一个指向对方的RLINK；每个RVG定义一个RLINK。
例如有Site A和Site B两套系统同时用Site C的系统作为备份。在Site A定义一个RVGa，包含需要进行数据复制的卷；在Site B定义一个RVGb，包含需要进行数据复制的卷；在Site C定义两个RVG，名为RVGa’和RVGb’，分别作为Site A RVGa和Site B RVGb的备份。然后，在Site A定义RLINK to_c1，指向Site C；在Site B定义RLINK to_c2，指向Site C；在Site C定义两个RLINK，一个to_a,指向Site A,另一个to_b,指向Site B。
4) Storage Replicator Log(简称SRL)是VVR中的重要部件。将数据复制各方的某个卷定义为一个SRL。需要复制的数据首先要写入SRL，然后传到异地。VVR通过SRL保证数据复制严格按照写顺序进行，这在异步工作方式下非常重要。当网络中断或异地系统出现故障时，本地数据将记录在SRL中，等系统恢复正常时再将SRL中的数据按照先进先出的顺序传送到异地。当SRL满后，VVR将通过Data Chang Map（简称DCM）记录变化过的数据块的块号。
VVR数据流程见图五：
图五
5) Data Change Map（简称DCM）与主节点的RVG相关，它其中的内容是位图信息，记录某一时间点后修改过的数据块位置。DCM在正常情况下不使用，在SRL满后记录变化的数据块的块号，当恢复正常复制后，等SRL中的数据传送完后，将DCM中记录的块传送到异地。灾难恢复后的反向复制也用到DCM。
6) 数据复制的工作模式缺省为同步/异步自适应，即在网络延时情况较好、数据能够及时复制时，工作在同步方式，完全保证两边数据的一致性；当网络延时情况较差、数据不能及时复制时，工作在异步方式下，保证主节点的I/O性能。数据复制根据实际情况，自行在两种工作模式之间切换。如果数据复制的线路带宽有限，出于保证本地服务器读写性能的考虑，可以将复制工作模式定义为异步。由于VVR的数据复制严格按照I/O的修改顺序进行，所以，无论在同步还是异步工作方式下，都能保证数据的完整性。对于数据库系统，该复制机制能够保证灾备节点的数据库在灾难发生时正常启动并提供服务。
7) 后备节点的完全同步，即所谓的”建立基线”。在主节点往后备节点正常复制数据前，必须逐块逐块地将主节点中需要复制的数据拷贝到后备节点，也就是说，将双方的RVG进行同步。后备节点的完全同步分为两种情况，一是复制时主节点应用不进行数据更改，二是复制时主节点应用进行数据更改。两种情况下，都可以采用自动同步方式或采用备份和检查点(Check Point)结合的方法。自动同步是指通过网络将数据从主节点(Primary)复制到备份节点(Secondary)。方法很简单，只要进行一步操作即可完成。自动同步对带宽要求较高，否则，将无法完成完全同步。自动同步要求RVG中的每个卷都有DCM。对于网络带宽较小，或者需要完全同步的数据量太大时，使用备份与检查点结合的方法。在备份开始前，在主节点设置检查点，该检查点记录在SRL中，然后将数据备份到活动硬盘、光盘、磁带或其它介质上。备份完成后，将检查点取消。将备份的数据恢复到后备节点上。然后将RLINK连接挂上，主节点SRL中记录的的数据传送到后备节点，完成后，两边数据一致，进入正常数据复制状态。用该方法进行数据完全同步，要求SRL卷大些，等完成后，再将SRL卷通过Volume Manager在线缩小。
8) 当某些严重意外情况发生后，后备节点会变成新的主节点，称为角色转换。在灾难期间，不进行数据复制，新的主节点用DCM记录变化数据位置。
9) 当原来的主节点在灾难后恢复正常，需要进行数据反向同步和角色转换。反向同步有两种情况，一种是在灾难发生时刻，原主节点与灾备节点的数据是同步的（即无未复制的数据）；第二种是在灾难发生时刻，原主节点与灾备节点的数据不是完全同步的（即主节点有数据尚未复制到灾备节点）。第二种情况在反向同步开始时第一步首先要进行重置，指将原主节点SRL和DCM中数据（这些数据在灾难发生时尚未来得及传送）的位置信息修改当前主节点（即原后备节点）的DCM。然后，将DCM中指向的数据全部传送到原主节点。而第一种情况的话，直接进行第二步工作。传送完成后，将当前主节点的数据库和应用停止，将双方角色复原，并在原主节点提供正常服务。
10) 脱机处理。通过使用VVR的In-Band Control(IBC)消息、Snapshot、以及Volume Manager(VxVM)的FastResync(简称FR，即快速同步)功能，可以实现数据的脱机处理。脱机处理主要指对后备节点种的数据进行处理，例如进行备份、打印报表、数据仓库处理等。脱机处理由打破后备节点的镜像卷、对镜像数据进行处理、重镜像等几个过程组成。
11) 双收条（双重确认）机制。指后备节点对复制数据的接收确认有两个阶段。第一个确认当后备节点收到数据后发出；第二个确认当后备节点数据成功写入硬盘后发出。当主节点收到第二个确认后，将SRL中的相应数据清空。
数据镜像
第二种方式，是利用灾备和主中心之间的光纤线路，构成基于DWDM的低延时SAN环境。直接应用Volume Manager在两个中心的服务器之间实现存储镜像。
如上图所示，主中心的服务器在存储是将会同时将数据写入到两个中心的存储中。由于镜像的实现是依托于底层的Volume，所有数据存储的过程对于应用来说都是透明的。20KM的光纤线路会带来一些数据延时。所以，我们可以通过设置Volume Manager的读取策略来指定主中心的服务器从本地的磁盘阵列上读取数据，加快数据查询的速度。
上述两种方式都能够实现在主中心和灾备中心之间的数据容灾。在此的项目中，数据发生物理错误的可能性基本上分为两种，生产中心的存储系统出现物理错误，如硬盘问题、光纤卡问题、光纤连接问题或光纤较换机问题等，另外一种就是整个数据中心出现故障。
对于第一种情况，通过此方案的设计可以完全避免，由于通过Volume Manager在生产中心和备份中心建立了镜像机制，即生产中心和备份中心的存储系统中只要有一个系统完好，生产中心的系统就不受任何影响。如生产中心的磁盘阵列出现问题，生产中心的主机自动将生产中心的磁盘标志为失败，全部的数据读写只在备份中心的磁盘阵列完成，
对于另外一种错误，即生产中心发生重大灾难，全部设备都不能正常工作，这就需要将系统切换到备份中心，由于在备份中心的磁盘阵列上有和生产中心完全一样的数据，在备份中心只需要将数据import到备份中心的主机上就可以将生产中心的数据完全接管。
数据库逻辑错误以及数据的离线处理
数据的逻辑错误处理
由于逻辑错误对于物理存储而言并不是非法操作，对于容灾机制来说生产中心磁盘阵列的逻辑错误也会如实的复制到容灾中心，因此用容灾的方式无法解决逻辑错误。解决逻辑错误最简单有效的方法就是建立数据的不同拷贝以随时准备进行快速恢复。VERITAS的解决方案是对存储数据频繁做逻辑快照的方式来解决逻辑错误问题。举例来说，如果需要对一个数据库进行逻辑错误保护，可以每个小时都对它做一个逻辑的快照。通过VERITAS的Storage Checkpoint技术，可以用少量的磁盘空间为代价生产数据库的多个逻辑备份，每个逻辑备份都可以单独加以使用。当数据库发送重大逻辑错误需要恢复时，可以将数据库的前一个逻辑备份直接挂接到系统中，数据库则立刻恢复到前一个逻辑快照点的状态，再通过数据库日志将数据进行恢复。采用此方法可以缩短数据恢复所需要的时间。
数据的离线处理
在使用了VERITAS Storage Foundation软件之后，我们还可以充分利用其中的FlashSnap的功能实现对核心数据的脱机处理，保证在备份或者其他类似应用的时候将对主机的影响减少到最低。在数据处理完成后，还能使用快速再同步的功能将分离的镜像卷重新加入到主数据卷中。
通过上面的几个步骤，我们在灾备中心和主中心之间建立起了同步复制链路，实现了在主中心的服务器环境稳定之后在两个站点的数据容灾。并且为XXX将来的数据管理和应用做好了全面的准备，充分发挥了VERITAS软件的优势。
应用容灾
待容灾系统的基础——数据容灾工作完成后，我们就可以开始进行上层的应用容灾。VERITAS的解决方案的一个重要优势就是能为XXX提供从存储管理到数据容灾，再到应用容灾的一系列整体办法，保证系统实施后，XXX可以在一个统一的软件平台界面上对核心数据和应用进行操作和管理，并通过软件强大的监测和报告功能，对电子商务平台的应用系统做到真正的无所不知。
应用容灾中采用的软件是VERITAS的Cluster Server。在最终的系统中，我们首先通过VERITAS Cluster Server将主中心的两台Oracle服务器做成本地集群，然后再用VERITAS的Global Cluster Option通过广域网连接做到远程的应用容灾。
VERITAS Cluster Server（简称VCS）是用于本地容灾的集群软件，支持多达32个节点的应用级切换，保证本地业务系统的软硬件高可用性。VCS以其出色的可靠性和易管理性闻名。在本方案中，VCS主要负责以下功能：
l VCS负责监控和管理硬件系统和操作系统，当出现故障时进行切换。
l 通过数据库代理(Agent）监控和管理数据库系统，当出现故障时进行切换。
l 通过API或脚本编写针对性客户化应用代理，监控和管理应用系统，当出现故障时进行切换。
l 通过Replicator 代理监控和管理数据复制过程，当主服务器数据复制发生故障时，自动将数据复制工作切换到后备服务器，保证数据复制过程的连续性。这点对于容灾系统非常重要。该代理充分说明VERITAS提供的是完整的容灾解决方案。
l 主节点和备份节点的VCS集群系统都在Global Cluster Manager的统一监控和管理下，从而实现集群系统间的远程应用切换。GCM在VCS中以两个服务组（指GCM Master和GCM Slave）的形式存在。
Global Cluster Option（简称GCO）可以称为Cluster’s Cluster（集群的集群）。它负责对多个不同地点的多达32个集群系统进行监控和管理，在发生严重灾难时，进行site的切换（即应用的远程切换）。
GCO Console为Web界面，通过浏览器管理各个Cluster系统，并在管理界面中主动控制或响应远程切换。
Global Cluster的工作方式
我们以A和B来分别表示主中心和灾备中心。
切换示意图：
I. 正常情况下：
1） 业务系统运行在地点A，包括数据库实例、有关的文件、数据库数据、应用软件。A节点对外提供服务。
2） A节点所有的有关的数据通过VVR实时复制到B节点。
3） 两地的VCS对的各自节点内的两台服务器的主机情况、数据库服务、应用软件进行实时监控和管理，其中，VCS还对VVR数据复制服务进行监控。
4） GCM 监控两地Cluster系统的运行。
II. 当A地点的主服务器发生硬件或软件故障，导致主服务器无法提供正常服务：
1） VCS进行本地切换，将主服务器的数据库服务、应用软件、VVR数据复制服务切换到本地后备节点。
2） 整个系统运行在本地后备节点，包括VVR数据复制服务，由后备服务器提供对外服务和数据复制服务。
3） GCM将监控到该切换事件的发生。
4） 如果仅仅是主服务器数据复制服务发生故障，可以不进行切换，只需将复制服务修复并正常运行。
III. 如果A地点的主服务器恢复正常，整个系统将重新运行在正常情况下。
IV. 如果在情况二的状态下，A地点的后备服务器也发生硬件或软件故障，整个A地点无法正常提供服务：
1） GCM 将监控到该严重灾难的发生，将对接收到的Site A down事件进行处理：发出严重告警，并在管理界面上弹出服务灾难性切换（及服务切换到远程地点）等待确认画面。
2） 在有关人员确认后，在GCM切换等待确认画面上按确认按钮，将进行地点间的容灾切换。
3） A地点的业务将在B地点正常提供服务。
4） 数据复制暂停。
5） Site B的VVR将从Secondary变成New Primary，使用DCM记录所有变化的数据块。
V. 如果A、B地点间网络发生故障：
1） VVR心跳检测将发现该故障，A地点VVR将根据事先的配置进行处理。我们的建议是VVR将网络故障期间所有数据的更改记录在SRL。
2） 如果在一段较长时间内，网络故障无法恢复。当VVR的SRL卷接近满时，VVR将使用DCM，记录变化的数据块位图。
3） 在网络故障发生后，GCM将探测到，并对Network Down 事件进行处理：向有关管理员发出告警。
VI. 如果A、B地点间网络在短时间内恢复正常。
1） VVR将把A的SRL中积累的数据传送到B。
2） VVR处于正常工作状态。
3） GCM处于正常工作状态。
VII. 如果A、B地点间网络在很长时间内仍无法恢复正常：
1） VVR停止远程数据复制。
2） GCM无法对两地间的Cluster运行进行监控。
VIII. 灾难复原。当A地点的系统恢复正常后，需要进行整个系统的回迁。数据反向复制时只复制灾难期间变化的数据而不是所有的数据，这是本方案优势之一。
1） 在灾难期间，B地点是VVR的New Primary，B的DCM记录所有变化的数据块。
2） A系统正常后，VVR重新建立与B节点的RLINK连接，并自动变成Pseudo Secondary（伪后备节点）。
3） GCM 发现A、B地点Cluster恢复正常，对它们进行正常管理。以下过程将在脚本中自动完成。
4） 进行反向同步的第一步是将A节点的Pseudo Secondary状态转成Secondary状态。
5） 第二步将进行A的SRL和DCM的重置(Replay)，修改B的DCM。
6） 因为在A节点发生灾难时，有可能A的SRL中有没来得及进行传送得数据，甚至DCM中标记的数据块没来得及进行传送。也就是说，A中有一些本地已经修改，而B还未修改的数据。所以，要保持A、B数据的一致性，一定要首先对这些数据进行处理。
7） 处理方法成为重置(Replay)。重置将把A节点SRL中数据或DCM中标记的数据位图信息传送到B节点。B节点将进行判断，根据数据块是否有新的修改，对DCM进行置位。
8） 重置完成后，将进行数据的反向同步，将灾难期间B节点变化的数据（和需要A节点重置的数据）传送到A。
9） 以上的过程中，B的数据库和应用都处于正常运行状态。
10）当反向同步完成后，数据库和应用将停止运行。
11） GCM控制进行整个系统的反向切换。
12）A节点重新成为VVR的Primary，进行正常复制。
13）A节点整个业务系统恢复正常运行。
在本步骤结束的时候，我们既在主中心中拥有了集群系统，也建立了主中心和灾备中心的远程集群，可以保证在主中心发生任何故障时都能够及时地将应用切换到灾备中心，保证核心应用不停机，实现系统容灾的要求。
方案总结
综上所述，我们通过一系列步骤实现本次XXX的容灾要求。其中，主中心中需要应用的软件有VERITAS Netbackup、VERITAS Storage Foundation及相关选件；灾备中心需要的软件有VERITAS Netbackup、VERITAS Storage Foundation及相关选件。
对于容灾需求中提出的几点问题，我们在方案中已经进行了相应的讨论。本方案仅是基于目前容灾需求和硬件环境的大体的设计，我们也希望能够在方案提交后，对方案中涉及到的一些技术问题，同XXX的专家一起进行探讨来进一步完善容灾系统的设计。