Symantec镜像容灾技术保护Oracle RAC数据库

SPICT 核心业务生产系统建设
构建高可用IT基础架构，保证核心业务系统连续性

上海浦东国际集装箱码头有限公司（以下简称SPICT），是上海市第一个集装箱码头，集装箱箱量从原来的设计的年吞吐量60万TEU到270万TEU,集装箱业务实现了高速发展。这对整个信息系统的发展带来巨大挑战，在复杂的系统架构之下，对业务系统的连续性提出了更高的要求。

一、建设背景

SPICT很早已经意识到IT基础架构对业务系统联系性的重要意义，早在2006年已经构建了双机、双柜的高可用性架构。随着业务系统的不断发展，现有业务系统已经无法满足业务量的增长和管理的需求；因此，在2009年进行新核心业务系统的开发工作，即TOPS 5.0业务系统。凭借此次新业务系统开发和上线的机会，SPICT决心对现有业务系统架构进行优化和调整，构建一个高可用的IT基础架构，保证核心业务系统的连续性。

2008年上半年，SPICT开始同IBM、HP、EMC以及一些系统集成商进行沟通，对此次系统升级的硬件架构进行探讨，借此机会来优化现有IT基础架构，实现数据整合和容灾系统建设；但各厂商和集成商提出的建议方案，或多或少存在一些问题；2008年9月，同Symantec公司进行了沟通，Symantec提供的解决方案完全可以满足SPICT高可用IT基础架构的需求，同时提供了更多丰富的功能。

下面将对对各种容灾技术进行简要介绍，并且针对SPCIT的实际环境和需求，对各种容灾技术进行分析：

二、各种数据复制技术简介

数据是企业的生命，数据的保护向来都非常重要。现有各种数据保护的手段，数据复制就是其中一种。数据复制可以从存储、操作系统、数据库和应用四个层次来做，其中通过应用系统进行数据复制需要应用程序支持，需要进行进行开发，这里不做深入介绍。

2.1 数据库复制数据容灾技术

数据库复制技术一般是由数据库厂商或者第三方开发，基于数据库日志或者数据流实现复制的技术。Oracle DataGuard是典型代表，此处将以此为例进行介绍。

Oracle DataGuard 通过使用称为standby database的数据库来防止出现数据的灾难。它通过将primary database数据库的重做日志传到并应用到standby database数据库来使standby database数据库与primary database数据库同步：

可以将重做日志直接从primary database数据库同步写到standby database数据库来完成完全没有数据损失的灾难保护。这会给primary database数据库的性能带来一定的性能损失。

可以将归档的重做日志从primary database数据库异步写到standby database数据库来使primary database数据库在极少损失性能的前提下，最小化地减少数据的丢失。

如果重做日志数据到达standby database数据库后快速应用到standby database数据库，则在primary database数据库出现问题时可以快速地 failover 到standby database数据库。然而，如果延缓一定时间后再应用重做日志数据，可以避免primary database数据库的错误快速地传播到standby database数据库。

2.2 存储硬件复制数据容灾技术

硬件同步复制技术是以同步复制技术为基础，通过磁盘阵列实现数据同步复制，从而保证产中心阵列与容灾中心阵列的在线数据完全同步。其整体方案中也包含了同步快速恢复、快照等辅助技术。从而实现整个容灾体系的要求。当然，所有的前提就是，生产中心的磁盘阵列和容灾中心的磁盘阵列必须是同构的。

由于复制的基本原理，数据是从主阵列复制到容灾阵列的，虽然在复制正常进行的过程中，能够保证两个阵列上的数据是同步的，但是当主阵列发生宕机时，会导致整个复制无法继续，同时导致生产中心服务器非正常的磁盘丢失，从而导致业务停顿以及巨大的数据一致性风险。

在同城的容灾方案中，基于磁盘阵列的同步复制方案，也是较为流行的一种。其具体原理如下：

以上的原理图清楚地指出了基于磁盘阵列的同步复制方案的原理，其原理适用于所有品牌的磁盘阵列间的同步复制原理。当生产中心的阵列发生问题时，主机必须手工的将I/O 路径切换到容灾中心的阵列上，这将导致无法避免的停机时间和用户的业务停顿。

其次，阵列的切换操作，是直接在磁盘阵列上进行的，在发生磁盘阵列问题，也就是在用户业务处于停顿状态的时候，找什么人来做这个操作（此操作磁盘阵列厂商通常建议由厂商或是由资质的代理来做。），或是用户自己来做此操作，都是对操作人员是非常严峻的考验。

另外，数据库停顿的一瞬间，数据是否一致，或者在第4、5步尚未完成的时候，复制发生停顿，数据实际已经写上的阵列，而主机并为得到反馈，都可能导致切换后的数据，不一定能够被数据库启动，从而需要更长的数据恢复时间。以上这些潜在的风险是我们不得不考虑的因素。