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

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

一、主流容灾技术对比
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.存储硬件复制数据容灾技术
硬件同步复制技术是以同步复制技术为基础，通过磁盘阵列实现数据同步复制，从而保证产中心阵列与容灾中心阵列的在线数据完全同步。其整体方案中也包 含了同步快速恢复、快照等辅助技术。从而实现整个容灾体系的要求。当然，所有的前提就是，生产中心的磁盘阵列和容灾中心的磁盘阵列必须是同构的。
由于复制的基本原理，数据是从主阵列复制到容灾阵列的，虽然在复制正常进行的过程中，能够保证两个阵列上的数据是同步的，但是当主阵列发生宕机时，会导致整个复制无法继续，同时导致生产中心服务器非正常的磁盘丢失，从而导致业务停顿以及巨大的数据一致性风险。
在同城的容灾方案中，基于磁盘阵列的同步复制方案，也是较为流行的一种。其具体原理如下：
 
以上的原理图清楚地指出了基于磁盘阵列的同步复制方案的原理，其原理适用于所有品牌的磁盘阵列间的同步复制原理。当生产中心的阵列发生问题时，主机必须手工的将I/O 路径切换到容灾中心的阵列上，这将导致无法避免的停机时间和用户的业务停顿。
其次，阵列的切换操作，是直接在磁盘阵列上进行的，在发生磁盘阵列问题，也就是在用户业务处于停顿状态的时候，找什么人来做这个操作（此操作磁盘阵列厂商通常建议由厂商或是由资质的代理来做。），或是用户自己来做此操作，都是对操作人员是非常严峻的考验。
另外，数据库停顿的一瞬间，数据是否一致，或者在第4、5步尚未完成的时候，复制发生停顿，数据实际已经写上的阵列，而主机并为得到反馈，都可能导致切换后的数据，不一定能够被数据库启动，从而需要更长的数据恢复时间。以上这些潜在的风险是我们不得不考虑的因素。
3.Symantec镜像数据容灾技术
软件镜像技术是采用以镜像技术为基础，实现生产中心阵列与容灾中心阵列的在线数据完全同步。从而实现数据的容灾功能。当然作为容灾方案来说，仅有镜 像技术是远远不够的。因此在远程镜像技术中，通常包含更丰富的技术手段，来实现数据容灾的完整要求。例如，用于灾难修复后的系统恢复的基于日志的镜像快速 修复技术；用于支持多根光纤通道协同工作的动态多路径技术；用于逻辑错误快速恢复或者容灾中心数据使用的卷快照、文件系统快照技术；用于调整读写性能的读 优先选择技术；用于镜像启动、暂停、继续等镜像过程的镜像监控技术等。
3．1软件远程镜像技术的特点是：
由于镜像的基本原理决定，生产中心的存储与容灾中心的存储在写数据时不存在主从关系，因此，无论哪一个阵列因故停顿，都不会导致数据的读写发生停 顿，可以做到数据容灾意义上的“零”停机。其意义不是单纯的通过“零”停机保障了业务的连续性，并且避免了由于存储非正常停机带来的巨大的数据一致性风险 （也就是数据库遭到破坏，数据不可用），而数据一致性风险是导致长时间业务停顿的主要因素。
Symantec利用VERITAS Storage Foundation系列软件的镜像技术，来构建容灾方案。利用VERITAS Storage Foundation的镜像技术构建容灾系统是非常简单的，它只有一个条件，就是将生产中心和灾备中心之间的SAN存储区域网络通过光纤连接起来，建立城 域SAN存储网络。然后，我们就可以通过Storage Foundation提供的非常成熟的跨阵列磁盘镜像技术来实现同城容灾了。
从原理上讲，在城域SAN存储网络上的两套磁盘系统之间的镜像，和在一个机房内的SAN上的两个磁盘系统之间镜像并没有任何区别。就如上图，如果我们把“同城容灾中心”几个字去掉，我们就无法分辨的左边的系统和右边的系统到底是在同一个机房，还是远在几十公里以外。
利用光纤将生产中心和灾备中心的SAN网络连接起来，构成城域SAN网络以后，利用 VERITAS Storage Foundation的先进的逻辑卷管理功能，我们就可以非常方便的实现生产中心磁盘系统和灾备中心磁盘系统之间的镜像了。如下图所示：

利用VERITAS Storage Foundation，我们可以创建任意一个逻辑卷（Volume）供业务主机使用，实际上是由个完全对等的，容量相同的磁盘片构成，两的个磁盘片上的数 据完全一样，业务主机对该Volume的任意修改，都将同时被写到位于生产中心和灾备中心的两个磁盘系统上。
采用这种方式，生产中心的磁盘阵列与同城容灾中心的磁盘阵列对于两地的主机而言是完全同等的。利用城域SAN存储网络和VERITAS Storage Foundation镜像功能，我们可以非常轻松的实现数据系统的异地容灾。并且消除了复制技术（无论是同步还是异步）的切换的动作，从而保证零停机时 间，零数据损失的实现。
二、数据复制技术分析
数据复制技术主要集中在数据库、操作系统和存储硬件三种技术上，每种技术都有其适用的范围，下面对各种技术对性能的影响做一个简单分析。
1.性能分析
考察容灾系统对业务系统性能的影响，主要从两个方面衡量：
一是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 Storage Foundation的镜像技术构建容灾系统，其对系统 I/O的延迟效应要小于任何一种数据复制技术，不管是基于磁盘系统的硬件数据复制技术，还是基于主机软件的数据复制技术，前面的部分已经做了阐述。
实际上，在整个容灾系统中，对业务系统的性能的影响最大的不是任何一种技术所产生的负面作用，而是“距离”，正如前面提到的，在Cache命中率较 高的系统中，距离对写操作的影响较大，这和光的传播速度有关，光在150公里距离上的一个来回需要1ms，在15KM距离上一个来回需要0.1ms，我们 列出一个对照表，供大家参考。本对照表不包含设备协议转换和光在光纤中的折射等因素。同时，我们知道，100MB光纤对应的速度是ns级的。
针对数据库日志复制技术，可以用如下的方式设置standby database数据库来达到不同的数据库数据保护级别：
1) Guaranteed protection：规定在修改主数据库时，至少有一个备用数据库有效。假如主（Primary Database）备（Standby Database）之间的连接中断，Oracle会通过中断主实例的工作来防止主备数据库之间的数据的不一致，保证无数据丢失。这种模式对数据库性能的影 响较大。
2) Instant protection：规定在修改主数据库时，至少有一个备用数据库有效。与Guaranteed protection模式不同的是当主备数据库之间的连接中断时，允许主备数据库之间的数据的不一致，并当恢复连接后，解决数据不一致的现象。这种模式对 主数据库的性能有较小的影响。
3) Rapid protection：主数据库的修改快速应用在备用数据库上。会出现数据丢失，但对数据库性能的影响小。
4) Delayed protection：主数据库的修改在延迟一定的时间后应用在备用数据库上。Rapid protection和Delayed protection模式即使在网络连接有效时，也允许主数据库与所有的备用数据库有数据分歧，数据的丢失量等同于主数据库联机重做日志的未归档数。这种 方式对数据库性能的影响小。
在primary/standby配置下，所有的归档日志被发送到了standby 节点，这使standby 节点的数据保持着更新。但是，如果primary 数据库意外关闭，联机的日志将会丢失，因为它们尚未归档并发送到standby节点。这使得 primary 和standby 数据库之间会有一个差异。
DBA可以选择让LGWR在将重做日志数据写到本地磁盘的同时将数据发送到 standby 数据库。该功能称为standby零数据丢失（standby zero data loss）。这种方法从本质的角度讲提供了远程重做日志镜像，但带来的问题是会极大地损失性能
2.复制效果分析

分析项目	数据库复制	存储硬件复制	Symantec容灾方案
数据级容灾效果	同步方式对生产中心的性能影响极大。因此基本采用非同步方式，RPO、RTO都不为零，需要停机时间，数据损失量为一个Archive Log 的数据损失量。	RPO接近零。 RTO不为零，应用会中断，需要手工切换存储。切换时间较短，但由于应用中断以及复制机制都可能导致数据不一致性，因此停机时间可能远远大于存储切换时间。	RPO、RTO为零。 无应用中断、无数据损失。
数据容灾性能消耗	消耗系统整体（阵列、主机）性能，因此性能开销极大。	消耗磁盘阵列上的CPU、内存的性能。	消耗主机上的CPU、内存的性能，由于卷操作不需要内存缓冲，镜像也不是复杂计算，因此对主机的性能消耗小于3%
风险	1、采用异步复制，灾难出现后，没有被复制的Archive Log 的数据将丢失； 2、采用同步复制，数据库性能将大幅下降。	1、数据从主存储复制到从存储时，链路中断，可能导致数据不一致，数据库无法启动，丢失； 2、存储Cache出现错误，将复制远端，导致两个存储都不可用。	无

3.技术适用性分析
1. 满足业务需求上：SYMANTEC适合数据要求实现绝对的零丢失，从前面的分析来看，只有Symantec运程镜像技术可以实现。
2. 方案完整性上：
a) Symantec运程镜像技术，存储出现后不需要任何切换，简单、业务零中断，适合应用级容灾；
b) 在服务器切换上，Symantec通过VCS实现零或者10分钟内完成切换，满足应用容灾需求；
c) 基于硬件的复制技术，当主存储出现故障后，需要重新挂接，切换复杂，而且挂接后数据库是否可以正常启动，没有保障；
3. 多品牌支持上：采用Symantec解决方案，其支持各主流品牌存储设备，方便在各品牌之间进行选择。Symantec Storage Foundation for Oracle RAC HA/DR容灾软件，帮用户实现数据零丢失，10分钟内实现切换，满足了业务要求。