容灾市场谁主沉浮 IBM DB2显现一身虎胆

容灾备份其实是一种让人无法爱上又无法割舍的技术，数据复制有两种方式，同步和异步。如果用同步，对存储性能影响很大，而且要求线路和远端系统非常稳定，否则主用端就不能正常操作。

异步没有这个问题，但是可能会丢失部分事务，这个还是小问题，ESS的异步复制方式，会导致你远端的数据可能更本无法让数据库启动。并且现在的容灾备份都依靠磁盘阵列，而磁盘管理起来很麻烦。所以说容灾技术带来的阴影，让企业管理者苦笑甚至痛哭的时候很多。

　　寻找到一种可靠的容在备份方式似乎很难。

　　IBM DB2在容灾备份的市场上所占份额不小，其具备可用性高和灾难恢复两大特点是用户选择它的关键。这两大特点就像两把利器，至少能让用户内心深处有了安全感。IBM DB2 通用数据库提供了许多基于这两大特性的技术来满足这些需求。那么我们来看看DB2这两大特性到底是什么，它是怎样解决了容灾备份在用户心中的阴影?

　　可用性高

　　可用性高只是一种较为通俗的说法，你也可以叫做高可用性。它是这样一种需求：每当需要时，数据就可用于从属应用程序。其目的是消除或最小化停机时间。DB2在持续可用性和故障转移可用性上表现卓越，另外还具备数据复制选项、日志传送选项、高级存储选项等等特性，让用户在最短的时间内体验到DB2迅速和全面的处理数据的能力。

　　持续可用性

　　持续可用性要求数据库引擎可随时用于处理 SQL 事务。这类可用性通常只在最关键的应用程序中实现。要实现这个目标，要求百分之百的冗余。那意味着用户必须有两个完全互相独立(包括在硬件和软件方面)的系统。

　　基本上，SQL 事务在这两个系统上发生。一个系统发生故障不会造成其伙伴系统上事务的处理发生中断。要使这成为现实，应用程序必须知道这两个系统，并且将每个事务实现为跨两个系统的 分布式工作单元(distributed unit of work，DUOW)。DUOW 是作为在系统之间协调的一个事务而执行的一系列 SQL 语句。应用程序将事务提交给这两个系统，并从这两个系统接收关于成功或失败的返回码。然后应用程序可以继续处理另一个 DUOW 或执行另一种操作。如果发生故障，其中一个数据库系统不能再为应用程序提供服务，则应用程序(被编码为可以捕获该错误)可以利用另一个系统继续处理它的工作负载，而不会发生中断。

　　要实现 DUOW 需要类型 2 数据库连接和事务监视器。类型 2 数据库连接建立了适合于 DUOW 的环境。事务监视器负责实现 DUOW 并确保完成或回滚 DUOW 中的事务。DB2 可以充当事务监视器或者用户可以使用另一家软件供应商(如 Microsoft 或 BEA)的事务监视器。

　　图 1说明了通过使用 DUOW 提供的持续可用性解决方案。

图 1. 分布式工作单元

　　表 1. 持续可用性解决方案的优缺点

　　故障转移可用性

　　故障转移可用性与持续可用性的区别在于：数据库引擎会有一段时间(尽管时间很短暂)无法用于事务处理。这种解决方案的基本元素有：

　　· 主系统和辅助系统

　　· 故障检测

　　· 数据源移动

　　两个系统都有数据库数据的副本，当检测到故障时，就会发生 故障转移。在故障转移过程中，数据源从主系统移到辅助系统。

　　有两种故障转移可用性： 同步(synchronous)和 异步(asynchronous)。同步可用性保证了主系统和辅助系统上的数据源是一致的，而且在故障转移之后维持完整的连续性。异步可用性不保证主系统和辅助系统数据库是完全同步的。将数据库更改从主系统移到辅助系统的方法会不同，但这个过程会生成一个时间窗口，在这段时间内数据还没有从一个系统迁移到另一个系统。数据量也许会非常小，时间窗口可能会非常短，但用户在决定解决方案时必须要考虑这一点。

　　让我们研究可以向用户提供同步或异步故障转移可用性的选项。

　　专用的 HA 软件选项

　　同步方法涉及数据库软件与专用 HA 软件的紧密集成以产生 HA 群集。HA 软件支持由于操作系统平台的不同而不同。常用的 HA 解决方案有：

　　· High Availability Cluster Multiprocessing(HACMP — AIX)

　　· Microsoft Cluster Server(MSCS)— Windows

　　· Sun Cluster — Sun

　　· Steeleye 的 Lifekeeper — Linux 和 Windows

　　这些是我列出的针对各平台的最常见选项。还有其它一些 HA 软件解决方案，也可以使用它们。

　　所有这些解决方案的工作方式基本相同。如果有故障，数据库服务器可以从一台机器移到备份系统上。要完成该任务，HA 软件会将所有必需的资源移到辅助系统。这些资源包括物理数据库的磁盘资源、网络资源和数据库服务器资源。

　　在 HA 群集解决方案中，单个物理数据库副本存储在共享存储系统上。在 DB2 环境中，一次只能有一个系统“拥有”存储器阵列。当检测到故障时，存储器的所有权就会从主系统转移到辅助系统。同时也会转移网络资源。最后，在辅助系统上启动数据库服务器资源，使数据库变为可用。

　　故障的检测由服务器之间的“心跳”连接执行。这个“心跳”是 HA 软件的一个功能，它可以察觉硬件和软件故障。

　　由于只有一个数据库的副本，所以它始终是同步的。数据库引擎的故障转移和重新启动的时间取决于以下因素：

　　· 检测故障所需的时间

　　· 移动数据库资源相关资源(存储阵列和联网资源等)所必需的时间长度

　　· DB2 引擎执行崩溃恢复所需的时间

　　当数据库没有正确关闭时，DB2 总是会执行崩溃恢复。崩溃恢复是日志文件的处理，从而确保将所有已提交的事务都写到磁盘并且回滚未提交的事务。执行该操作所需的时间取决于发生故障时数据库日志中“打开”工作的量。整个故障转移可能只需要几秒钟，如果要从日志文件中处理的工作量很大，可能会需要更长时间。

　　这种可用性解决方案的一个优点是它不需要对应用程序或客户机配置目录做任何更改。HA 软件为数据库连接提供了一个虚拟的 IP 地址资源。当检测到故障时，该 IP 地址就会进行故障转移，应用程序可以使用它以前使用的同一条连接语句。发生故障转移时，所有应用程序都会断开连接，客户机会将通信错误情况返回给应用程序。一旦数据库服务器在辅助系统上运行之后，应用程序只要重新发出连接语句，就可以象以前一样继续处理工作了。

　　这也称作 热备用(hot standby)配置。但是，在等待故障转移时，辅助系统并不一直空闲。也可以以 相互接管(mutual takeover)配置来配置系统，在该配置中，这两个服务器都主动地主管不同的数据库。每台机器都准备在发生故障时接管其伙伴的工作负载。

图 2. 专用的 HA 软件选项

　　表 2. 专用 HA 软件选项的优缺点

　　灾难恢复

　　建立灾难恢复计划对于现代企业至关重要。企业数据库中的信息对于进行业务活动是极其重要的。保护该数据以及在灾难之后确保其“生命”是很重要的活动。当构建 DR 计划时，有三个关键问题：

　　· 需要防止的故障级别

　　· 可接受的数据丢失量

　　· 允许用于恢复的时间量。

　　要防止的故障级别通常是近似性问题。原始数据与其备份之间在物理上有多紧密?备份数据可以在不同的驱动器上、在独立的机器上、在独立的楼层上或在不同的建筑物里。不可能预测所有可能的灾难。火灾、水灾或甚至用户的恶作剧都可能是企业必须面对的问题。解决方案的设计应该包括公司希望防止最坏情况的方案。

　　所有企业都不希望在故障之后丢失任何数据。虽然不丢失数据是可能的，但由于可能需要的复杂性和费用(尤其是如果所防止的故障级别非常高)，这通常是不实际的。可接受的数据丢失量取决于数据对公司有多重要以及有什么资源可用于确保其生命。

　　恢复所需的时间量类似于可用性高的目标。它与可用性高解决方案之间的差异在于所防止的故障类型以及通常认为合理的时间长度。HA 故障转移通常以秒和分钟来衡量，而灾难恢复则可能以小时和天来进行衡量。不过并非总是这样，但这个差异区分了对这些解决方案的相对期望。

　　备份和恢复

　　数据库备份创建了数据库的时间点映象，它是灾难恢复解决方案的基本组件。DB2 提供了几种备份，包括脱机备份、联机备份和增量备份。从备份恢复所需的时间取决于数据库的大小和可用于执行恢复的硬件资源。

　　由于数据库备份只捕获时间点的数据，因此无法通过一个简单恢复来恢复备份之后发生的任何数据更改。要恢复备份之后完成的事务，就需要应用日志文件。可以从备份和日志文件(通过在日志文件中进行“前滚”来应用)来恢复数据库。这允许恢复到某个时间点或恢复到日志文件结束。

　　因此，如果 DR 解决方案必须恢复自上次备份以来的事务，那么保留日志文件是非常关键的。有两个提高日志保留的 DB2 特性：双日志记录和用户出口工具，已在关于数据库复制 HA 选项的部分中进行了讨论。

　　灾难恢复方案

　　灾难恢复方案可以分成三类：简单备份、备份和日志保留、高级存储备份。虽然不是每个解决方案都清晰地被划入这三类中的某一类，但它们确实为用户理解灾难恢复选项提供了合理的框架。在这里这三种灾难恢复方案就不一一赘述了。

　　结束语

　　IBM为DB2构建高可用性和灾难恢复的解决方案提供了出色的技术支持。

　　存储业界的朋友们都听过这样经典的段子：有人抱怨异地容灾带宽不够，什么带宽不够?需要光纤直连?至少也要dark fiber跑DWDM呀，你架一个E1跑GeoRM都不好意思跟人说，那叫容灾么?什么eRCMF，PPRC-XD，PPRC over FC， flashcopy/pprc V2, consistency group， FC-IP director都上，加个svc做虚拟存储整合，配上3584加12个lto2带机做lan free, server less备份，磁带容灾。(画外音：那怎么也得投个一两千万吧?)一两千万?10个Million，美元，这是起价，这还就是个数据级的，接口留着，回头就上二期，应用级的，能双生产，global DR, 全球负载均衡。容灾中心怎么也得建到美国去呀，世贸中心的地听说刚平完，正好买下，就在那建，建一个百年不落后，飞机撞不坏，原子弹炸不烂的，能抗得住拉登、布什折腾，才叫容灾!什么叫成功的容灾，成功的容灾就是不求最好，但求最贵!

　　这是一个容灾业界的《大腕》台词，当然是无稽之谈，所谓最具可用性的容灾方案，其实完全取决于客户的应用需求，用户在选择容灾备份解决方案的时候，，货比三家察其优劣，IBM DB2技术先进，全球服务系统完善，值得参考。