IBM-数据级容灾解决方案

1、1、 基于软件的数据备份技术在应用软件进行灾难备份的解决方案中，应从下面三个层次考虑： 用户应用程序 客户机软件 数据库引擎其中用户应用程序和客户机软件一般不包含关键数据，几乎所有数据都由数据库引擎管理并放置在数据库服务器中。在这三者之中，数据库中的数据保护最为重要。一般情况下，用户应用程序和客户机软件只需要将其执行代码和参数配置文件做以备份，当灾难发生时，可以通过这些备份重新安装和配置用户应用程序和客户机软件。对数据库的备份，如果采用硬件级灾难备份有两种方法：一是采用备份的方法，即定期地将数据备份到硬盘和磁带/磁带库上，这些磁带可以通过运输的方式运到远 程，以防磁带在本地的灾难中发生毁坏。这

2、种方法的缺陷是实时性较差，恢复时间较长；另一种做法就是硬件镜像的做法，这种做法在硬件的投资上较大，对两点间 的网络带宽有较大的要求。那么，有没有一种两者兼顾的解决方案呢？数据库产品提供的数据库复制技术就是一种两者兼顾的灾难备份解决方案。在前面提到的灾难 恢复方案的7个层次中属于第5或第6层次。数据库复制技术在数据库级别的灾难备份解决方案中可以实现远程容灾。目前已有的产品有IBM DB2 HADR、IBM INFORMIX HDR以及ORACLE DATA GUARD。IBM DB2 HADR是High Availability Disaster Recovery 的缩写，HADR 将HA（高可

3、用性）和INFORMIX DR的技术紧密结合起来。INFORMIX HDR是High Availability Data Replication的缩写。HDR的工作原理是通过将主数据库服务器（简称为A）的逻辑日志缓冲区复制到备份数据库服务器（简称为B），而且能在主数据库服务器操作失败时自动切换到 备份数据库服务器。复制方式有同步方式和异步方式两种。我们将在下面详细介绍HDR的工作原理以及同步方式和异步方式。正 常状态下，主数据库服务器做数据库的读写操作，备份数据库服务器为只读方式。当主数据库服务器失败时，备份数据库服务器会自动接管主数据库服务器的事务处 理。此时，备份数据库服务器作为主数据库服

4、务器进行数据库的读写操作。当主数据库服务器被修复后，主数据库服务器作为新的备份数据库服务器。此时备份数据库服务器虽为只读方式，但并不是空闲的。它可以分担主数据库服务器的负载，例如执行查询、出报表等任务。数据库复制对硬件的要求相对较低，只要主数据库服务器和备份数据库服务器的硬件配置相同即可，不是必须使用高端存储设备，例如IBM ESS等。主数据库服务器和备份数据库服务器的距离不受限制，而且对网络的压力并不大，但需要更强的数据库管理能力。 下面介绍一下HDR的工作原理。如下图所示：在 逻辑日志缓冲区（Logical Log buffer）刷新之前，它里面所有的交易（Transaction ）将拷贝

5、到数据复制缓冲区（Data Replication Buffer）。数据复制缓冲区的大小和逻辑日志缓冲区相同。数据复制缓冲区通过TCP/IP网络将数据发送到备份数据库服务器的数据复制缓冲区中。在备 份数据库服务器端，一个数据复制线程接收数据复制缓冲区的数据并把他们放入到恢复缓冲区（Recovery Buffer）. 另一个数据复制线程（或一些线程）记录数据库日志信息。主数据库服务器和备份数据库服务器都有一个“Ping”线程在运行，它会定时唤醒并且检查两个数据 库服务器的连接。如果任何一台服务器上的“Ping”线程检测到连接中断，都会发一条出错信息到消息日志中。HDR有两种复制方式：同步方式（S

6、ynchronous）和异步方式（Asynchronous）在同步复制的方式下，主数据库服务器的逻辑日志缓冲区只有在下面的过程完成后才可以刷新：1. Copy: 逻辑日志缓冲区数据拷贝到数据复制缓冲区；2. Send: 数据从主数据库服务器的数据复制缓冲区通过网络传送到备份数据库服务器；3. Acknowledge:当备份数据库服务器接收到数据后发回确认信息；4. Flush: 此时，主数据库服务器才可以刷新其逻辑日志缓冲区的数据。采用同步方式的优点是两边数据库服务器的数据一致，但是由于每笔在主数据库服务期提交的交易需要发送到备份数据库服务器而且得到确认后才算真正成功完成，由此而产生的时间延迟

7、会使性能受到一定的影响。如果采用异步复制方式，主数据库服务器的逻辑日志缓冲区只要在逻辑日志缓冲区的数据拷贝到数据复制缓冲区之后就可以进行刷新了。这样做的缺点是在某些系统 失败的情况下，可能会有一些数据还没有来得及通过网络传送到备份数据库服务器；优点是主数据库服务器的性能不受影响。对于Oracle DATA GUARD的工作原理，大致上与IBM HADR 和INFORMIX HDR的工作原理类似。Oracle9i DATA GUARD 通过使用称为备份的数据库来防止数据灾难的出现。它通过将源数据库的重做日志传输并应用到备份数据库中，来使备份数据库与源数据库同步： 可以将重做日志直接从源数据库同步

8、的写到备份数据库，来完成零数据损失的灾难保护，这会给源数据库的性能带来一定的性能损失。可以将归档的重做日志从源数据库异步的写到备份数据库，来使源数据库在极少的损失性能的前提下，最小化地减少数据的丢失。 如果重做日志数据到达备份数据库后就快速应用到备份数据库，则在源数据库出现问题时便可以快速地切换到备份数据库。然而，如果延缓一定时间后再应用重做日 志数据，就可以避免源数据库的错误快速地传播到备份数据库。DATA GUARD同样也有同步和异步复制两种方式可以选择。2基于磁盘系统的PPRC数据级容灾解决方案本节介绍的基于磁盘系统的PPRC（Peer-to-Peer Remote Copy）数据级容灾

9、解决方案，是灾难恢复方案的7个级别中的第六个级别，可以保证少量或无数据丢失，实现最高一级数据的实时性，适用于那些几乎不允许数 据丢失和要求能快速将数据恢复到应用中的业务。 此种解决方案提供数据的一致性，不依赖于应用而靠大量的硬件技术来实现。目前业界有两种基本的基于磁盘系统的远程拷贝形式：同步PPRC远程拷贝(synchronous writes)：来自主机的数据被写往本地连接的磁盘系统，该系统将数据转发给远地点连接的磁盘系统。只有当两个系统都拥有数据的拷贝以后，本地系统才会 向主机返回一个I/O完成指示。同步远程拷贝能够在远地点提供最新的数据，但应用程序会因等待写I/O操作的完成而被延迟。由于

10、距离的限制这种方式也叫做 “同城镜像(Metro Mirror)”异 步PPRC远程拷贝(Asynchronous Write )：来自主机的数据被写往本地连接的磁盘系统，该系统立即向主机返回一个I/O完成指示。数据在很短的一段时间(在实际中通常在数秒钟到一分钟左右)以后 被送往一个远程磁盘系统。异步远程拷贝对应用程序性能的影响最小，但远程磁盘系统在数据的更新程度上与本地系统相比会有一个延迟。单纯的异步拷贝由于线路距离较远等原因，本地磁盘和远地磁盘可能会有逻辑卷读写顺序上的差异。这种方式也叫做“全局拷贝(Global Copy)”在全局拷贝(Global Copy)的情况下，比如本地磁盘系统提

11、供给主机5个逻辑卷，某一时刻主机对这些逻辑卷发起了A，B，C，D，E，5个写盘请求，本地的磁盘系统的写顺序 是A，B，C，D，E。但是由于线路等原因，远地的磁盘系统在接收写请求时，收到的顺序可能是A，C，B，D，E。写盘的顺序也是A，C，B，D，E。我 们假设灾难发生在这5个写操作D，B的中间部分，那么这时远地的数据C很有可能是没有意义的，甚至是无理的。为了解决本地磁盘和远地磁盘可能存在的逻辑卷读写顺序的差异，有的磁盘系统提供带有一致性组的异步远程数据拷贝。在这种方式下，远地的磁盘系统会将先收到 的写请求缓存起来(比如上面的数据C)，等到它前面的数据(A,B)到达后，再按照顺序写盘。这种方式也

12、叫做“全局镜像(Global Mirror)”。见下图:IBM异步PPRC远程拷贝提供带有一致性组的异步远程数据拷贝。下面，分别针对两种方案在IBM ESS中的实施方案予以介绍。2.1、 同步PPRC数据级灾难备份方案IBM的PPRC提供了实现灾难备份的方案基础。PPRC全称Peer-to-Peer Remote Copy，是以存储为基础的实时且与应用程序无关的数据远程镜像功能。PPRC的实现较为简单，是无数据丢失且具有完全恢复功能的灾难恢复解决方案。PPRC基于IBM ESS企业级存储服务器，以逻辑卷为基本单位，通过光纤通道将本地ESS上的数据同步镜像到远端的ESS上。为了在保证数据的即时性

13、、完整性和系统性能之间达到平衡，PPRC提供了多种工作方式。同步方式下:点对点远程拷贝(PPRC)是一种同步远程镜像的工具，可用于相隔距离达103公里的两个ESS系统中指定的逻辑卷。这一距离可以通过第三方 提供的通道扩展器加以延长，ESS可以为所有连接的主机支持PPRC功能。PPRC 将确保如果备份卷不能被更新，那么即使源卷更新成功，整个写操作也会返回失败-保证源卷和目的卷的数据彻底一致。同步方式可以保证数据不会丢失，更重 要的是数据的一致性在这种方式下能够得到很好的保证-数据的不一致意味着相关数据的丢失，此时数据库的数据安全机制无法保证数据的安全，严重时有可能 造成数据库无法启动。PPRC的

14、同步实现机制如下图所示：PPRC同步工作过程为：1、应用程序将数据写入磁盘-在生产系统中的应用程序将数据写到生产系统的磁盘。2、生产系统中的磁盘数据传输到备份磁盘-对每一个在生产系统的写操作都要将这个写操作送到备份磁盘。3、备份机磁盘数据复制-备份磁盘复制生产系统的数据。4、将写完的操作信息返给生产磁盘-当生产系统收到备份系统传回的已写信息之后，生产机的磁盘系统通知主机该写操作已完毕，在此之后生产系统的应用将继 续执行。在同步PPRC的建立过程中，卷具有不同的状态，以保证数据的完整性。2.2、 异步PPRC数据级灾难备份方案PPRC + FlashCopy数据备份方案为了提高PPRC数据备份方

15、案的效率，可以考虑结合IBM公司企业级存储服务器ESS的FlashCopy功能软件，采用异步方式实现PPRC数据备份。 在异步工作方式下，PPRC能够在远端更新没有完成的情况下，只要本地更新成功，就可以向主机返回“写成功”的信号。好处是：在主备机房之间的数据链路带 宽成为瓶颈时，采用异步方式可以不影响主机房生产系统的性能。坏处是：1、数据将有可能丢失；2、在异步同步不能最终成功完成的情况下，数据的一致性无法 得到保证。所以当采用异步方式时，IBM建议先采用IBM ESS的快速拷贝功能FlashCopy备份需同步的数据，再进行数据同步。ESS的FlashCopy的使用ESS的FlashCopy提

16、供了一个“时间点”（Point in time）的拷贝服务功能，从源卷到目标卷快速地复制数据。逻辑拷贝通常可以在数秒内完成，然后就释放源卷，进行正常工作，而物理拷贝操作在后台进行。在 物理拷贝的进行过程中，拷贝和被拷贝的数据都能被用户使用。IBM ESS的FlashCopy支持两个选项，它提供NO COPY选项来支持灾备的应用需求。以下的内容讨论了在移动灾备的应用环境中是如何使用这些选项的。FlashCopy COPY选项对于一般的客户应用，需要生产数据实时的时间点物理拷贝。这样的应用示例包括：日常重要卷的备份、日常报表生成、数据仓库和数据挖掘的应用等。FlashCopy COPY选项能够在磁

17、盘存储设备中产生一份生产数据的真实时间点拷贝。该选项可以满足以下的应用需求：1.在磁盘存储设备中保存生产数据的一份时间点拷贝的业务需求。这方面的例子是日常工作系统的备份。2.生产数据的时间点拷贝将被多个应用重复使用，特别是对每日的结束处理和报表生成。3.生产数据的时间点拷贝将被某些统计分析类应用，如MIS或数据挖掘应用的频繁使用。无论是什么原因，只要是需要生产数据的物理拷贝，就可以使用FlashCopy COPY选项来进行支持。对于该选项而言，所需要的磁盘空间容量是需要拷贝的源磁盘容量的总和。下图对FlashCopy COPY选项进行了说明。请注意，生产数据的一份真实拷贝是为其它应用的使用而产

18、生，这些应用通常是办公MIS类应用，如报表的生成。FlashCopy NO COPY选项对 于IBM ESS独有的NO COPY功能，在异步灾备中有极大的作用。NO COPY也需要实时生产数据的时间点拷贝，但并不需要真正的数据拷贝，即在FlashCopy完成以后，不存在源数据的单独的物理拷贝。这一点可以通过 FlashCopy NO COPY选项来实现。使用NO COPY选项的应用通常不需要频繁访问被拷贝映像。NO COPY选项不需要所有的镜像磁盘空间，但是需要一些磁盘空间进行磁盘索引和写I/O缓存的操作。所需磁盘空间的容量取决于FlashCOPY的使用时间 （即从建立到删除的时间）和被拷贝卷的更新速度。在异步灾备的方案中，本地可以用Flashcopy的NO COPY的选项进行时间点的COPY，以保证数据的完整性，再用PPRC进行远程灾备。PPRC/XD数据备份方案PPRC/XD为非同步、长距离的拷贝选项，它较适合于数据迁移、数据库日志的传输及定期的异地数据备份，这个功能是集成在ESS的PPRC选项当中的。 当ESS运行在非同步方式时，被修改的数据持续的传到备份端，修改主ESS端的I/O的操作在被修改的数据传往备份ESS端之前结束。由于是非同步的操 作，这