【IT168 服务器学院】新术语，平衡相互接管，哈哈。高可用，涉及的东西太多了。os系统支持，db功能，共享盘阵功能结合在一起，才有点点意义。。。

　　简介
　　高可用性（HA）是大多数计算系统追求的一个特性。健壮的 HA 解决方案最小化了停机时间，如果想要消除系统停机造成的负面财务影响，这是一个必需的能力。

　　专门研究关键业务软件和电子商务的市场研究公司 Standish Group International 进行了一项研究，尝试量化数据停机（data outage）所造成的成本。他们估计，对于一个事务处理系统，与停机相关联的成本大约为每分钟 2,500 美元 1 相当于每小时 15 万美元。事实上，与营业高峰时间的停机相关联的成本估计为每分钟 7,800 美元，或者说每小时 468,000 美元。

　　并非只有在线拍卖商和图书销售商才需要他们的系统一直运行。Standish Group 的研究还考察了数据仓库系统的停机相关成本，结果发现这个成本惊人地达到每分钟 5,800 美元，而在运行决策支持的高峰负载期间，这个成本更是高达每分钟 6,300 美元。由于客户关系管理、实时风险评估、供应链管理和企业资源计划等应用与公司的数据流紧密相连， 您会开始看到业务数据需求是如何改变了公司的运营方式。

　　尽管这些数字对于一次停机会损失多少金钱只提供了保守的估计，但它们的确从某个侧面说明了如今我们为何要重视保持系统 24 X 7 地正常运行。

　　但是为什么停机数据的机会成本是如此之高呢？如今，数据前所未有地成为了公司的生命线。围绕在业务周围的正是商业智能的原始成分以及大多数的业务活动。因此，在失去数据访问的那一刻，业务就停止了，宝贵的资源（同时包括人力和资本投资）就变得低效或不可用。

　　业务市场与短短的三年前相比，已经变成了一个非常不同的实体。顾客要求您的服务迎合他们的方便。这种"不愿等待"的现象所带来的影响，已经被具有 Internet 连通性的、广泛的设备多样性的迅速扩散而复杂化：随时连接，随时准备就绪。政治也增加了对可用数据的需求。对于像 Basel II 这样强制性的实时风险评估模型，以及关于如何存储类似 HIPPAA 的医学信息这样的严格标准 来说，信息资产正日益成为日常业务运作的中坚部分。

　　本质上，可用的数据以可用的磁盘子系统、网络层和存储体系结构为前提。然而，可从数据资产中利用的“智能”依赖于您选择的数据管理软件。IBM DB2® Universal Database™ (DB2 UDB) 是为可靠性和可用性而构建的，因此当您开门营业时，它就一直正常运行；在 Internet 上，这就意味着永远在线。

　　影响业务数据可用性的停机有两种类型。计划的停机通常是指由于维护而导致数据不可用的操作 - 比如数据加载、数据重新组织、统计数据收集等活动。DB2 UDB Version 8.1 充满了许多特性，这些特性几乎消除了用于管理活动的所有计划的停机。

　　非计划的停机是指那些您不能预料的事件：灾难、服务器故障，等等。本文着重介绍用于降低与非计划的停机相关联的停机时间的方法，同时比较和对比这些方法各自的优点和缺点。

　　高可用性路标图
　　数据库领域中针对非计划的停机的高可用性（HA）包含以下三个重要方面：

• 数据库本身。您希望数据库保持持续运行，速度快，可伸缩，具有良好的查询和实用性能，避免基于软件的破坏，提供从任何种类的故障中快速恢复的能力，并且具有用于 在线的细粒度维护的工具。
• 硬件和软件冗余。当硬件或者操作系统失效时，您怎么办呢？我们将讨论群集技术，它用于支持备用机器在生产机器失效时接管生产机器。
• 灾难恢复。如果整个站点都失效了，您该怎么办？如果发生了某种未预见到的灾难（自然的或者人为的），您又该怎么办？您如何保持业务正常运转？

　　用于非计划停机的高可用性群集
　　当某个系统失效时会发生什么呢？到目前为止，最常用的解决办法就是让另一个系统等待，以承担失效系统的工作负载并继续业务运作。用于高可用性的群集概念涉及到许多互连的机器（称为 可用性群集 2 ）。如果这些机器中的某一台失效了，维护业务运转所必需的资源将被转移到该群集中另一台可用的机器上。

　　在建立群集时，您必须为几个关键事项作好准备：

• 用于存储数据的群集必须通过专用互联网或者 LAN 来连接到构成群集的服务器。例如，在一个两节点的群集中，如果机器 1 失效了，机器 2 必须拥有到机器 1 的磁盘的物理和逻辑访问。
  
  
• 能够自动检测失效资源的方法。在群集术语中，驱动这种自动检测的守护进程或者进程称为心跳监视器。使用一个检查资源心跳的进程，资源的故障转移伙伴 就能够确保该资源在正常运行并且操作能够照常继续。如果没有检测到心跳，群集中的另一台服务器就可以开始往另一台机器转移资源，从而恢复业务运作。
  
  
• 资源拥有者向幸存的一个或多个群集成员的自动转移。例如，如果用户连接到失效的机器，您希望让该机器的 IP 地址指向某台幸存的服务器，以便客户应用程序能够连接到服务器，而不必改变客户应用程序本身。在故障转移之后，指向相同 IP 地址的一个简单重连 （reconnection）现在将运行在备份群集中的某台服务器上。

　　高可用性群集可用于当今大多数最流行的操作系统。 表 1列出了 DB2 UDB v8.1 上的群集软件支持。

　　表 1 - 高可用性软件和 DB2 UDB

　　DB2 UDB 附带了特殊的脚本和命令，它们是为 DB2 UDB 支持的所有平台上的每家供应商的群集软件量身定制的。这些脚本和命令允许数据库管理员（DBA）部署广泛 而灵活的高可用性群集方案。在 DB2 UDB 中，故障转移群集既可以在分区的数据库中实现，也可以在非分区的数据库中实现。

　　在实现故障转移群集时，DBA 应该考虑到许多因素。首先， 应该考虑到检测故障所花的时间量，以及对备用服务器进行新的资源分配所花的过渡时间量。在定义心跳时还要考虑一些特殊事项。例如，您不会希望实现这样一个方案，其中正常的网络延迟或者应用程序性能被误认为是服务器失效，而实际上服务器并没有失效。下一个考虑事项是在备用服务器上恢复数据库所花的时间量。在尝试配置一个可用的环境时，这可能是最大的考虑因素。最后，DBA 应该知道应用程序的超时时间和重新连接到服务器所花的时间。

　　当DBAS遇到失效转移分群时他会考虑到很多因素。首先，要考虑检测错误所需花费的时间及重定向到备份服务器的传输时间，在定义心跳时要特别注意，例如在正常网络等待或应用程序执行时检测到一个错误的数据库，但错误还未实际发生，您就不想再继续执行这个方案了。下一个要考虑的是数据库重新备份到服务器上所消耗的时间。这可能是试图建立一个有效环境时最要考虑的因素。最后，DBAs还应该考虑到应用请求和重联接到数据库服务器上消耗的总时间。

　　HA 群集配置
　　图 1显示了最常见的高可用性群集配置。支持高可用性群集的供应商很多，表 1 列出的所有这些供应商支持以下四种配置：

　　图 1 - 最常见的 HA 配置
 

　　注意 DB2 UDB 对高可用性具有特殊的报价。您可以阅读 Paul Zikopoulos 撰写的文章 向高可用性配置下的分布式 DB2 V8 服务器颁发许可证以了解更多情况。

　　现在我们看看这其中的每一种配置所提供的内容：

　　空闲备用

　　请考虑 图 2. 所示的 4 节点数据库群集。该群集中有 4 台物理机器，每台一个分区。在这个配置中，有一台机器（ 图 2中最右端的那台机器）处于空闲状态，准备在另一台机器失效时接管该机器。

　　空闲备用的优点在于，在故障转移之后，您将有三台机器在工作，这和以前的机器数量相同，因此不会在故障转移之后出现性能下降。

　　这种方法的缺点就是它似乎很昂贵，您必须准备一台机器随时等待另一台机器失效。然而值得注意的是，您可以在这台机器空闲的时候将它用于其他目的，比如开发、测试，等等。而且，您还需要做一定的工作来把整个系统连接起来。虽然感觉起来比较昂贵，相比于与如今市场上可用的流行群集数据库相关联的“活动/活动”系统，DB2 UDB 具有竞争力的价格使得实现空闲备用系统更能承受（包括服务器和软件成本）。

　　图 2显示了一个详细的空闲备用高可用性解决方案。在这个例子中，有三台机器正在工作，第四台机器处于备用状态，等待接管。当 3 号机器遇到故障时，它的工作负载将转移到那台空闲的机器上。先前空闲的机器承担了3号机的工作负载和IP地址。

　　连接到出故障的机器（在此例中为 3 号机）的最终用户将失去他们原来的连接。然而 3 号机的 IP 地址已经被 4 号机代替了。当应用程序发出一个新的 CONNECT 语句来连接到 3 号机时，他们将被连接到 4 号机。这样的连接转移对他们来说是透明的，他们并不知道连接已经被转移了。

　　其他机器上的最终用户根本不会受到这次故障的影响。他们能够继续访问 1 号分区和 2 号分区上的数据。只要这些分区上的最终用户不尝试访问 3 号分区上的数据，他们就不会受到任何影响。

　　图 2 - 空闲备用群集解决方案
 

　　正如其名称所揭示的, 空闲备用配置是关于 DB2 UDB 高可用性许可条款的“主动/空闲”设置的一个例子。

　　活动备用

　　除了故障转移机器是活动的以外，活动备用配置和空闲备用配置相似。在故障发生之后，工作负载转移到其他机器上。取决于活动备用的工作负载，响应时间可能会恶化，也可能不会恶化。例如，我们经常看到活动机器执行某种低优先级工作（例如生成报告）的情况，当某个故障发生时，低优先级的工作将被中断，以维持与出故障的服务器相一致的响应时间。正如其名称所揭示的，活动备用配置是关于 DB2 UDB 高可用性许可条款的“主动/主动”设置的一个例子。

　　相互接管

　　在相互接管配置中, 如 图 3所示,4 台活动的机器在进行生产工作。这个配置的优点在于没有空闲的硬件，缺点就是在出现故障之后，只有 3 台机器在负责生产工作负载，而之前是 4 台机器，所以响应时间就更可能会延长。

　　图 3中的红箭头表示用于相互接管的群集系列定义。在 1 号群集中，1 号分区将在发生故障后转移到 2 号机。如果 2 号机出现故障，2 号分区将转移到 1 号机。同样地，2 号群集中的 3、4 号机和它们各自的数据库分区之间也是这样的关系。

　　这里需要重点注意的一件事情就是，DB2 UDB 在这个方案中只识别一个群集，即一个包含 4 台机器的群集。您可能会感到疑惑，因为您可能已经注意到 图 3 中有两个群集。这是为什么呢？因为这些是高可用性群集。在此例中，我们定义了两个独立的群集，1 号群集有 2 台机器，2 号群集也有 2 台机器。就 DB2 UDB 而言，这两个群集是独立的 — 即使它是一个分区数据库系统。

　　相互接管配置的一个突出优点在于：您可以重复使用这个高可用性故障转移方案，而不必考虑数据库群集的规模。例如，考虑一个数据库中具有 125 个群集的方案，其中每一个群集有两个节点。该数据库具有 250 个节点，每个节点都在一个高可用性环境中，每个环境都在一个只有两节点的 HA 群集内。 图 3 中的存储器互连在任何时刻只需要连接到两个系统 — 这就是好处。相比于像在 图 3中那样把所有机器连接起来所带来的潜在线路连接麻烦，这类互连是相对廉价和相当受欢迎的。

　　图 3 - 相互接管群集解决方案
 

　　从 图 3 可以看出，定义 4 号分区的逻辑定义现在已转移到 3 号机。在接管发生之后，3 号机同时处理 3 号分区和 4 号分区的工作负载。这说明了为什么 4 号分区所在的磁盘必须可以从 3 号机访问。

　　图 3 中的相互接管配置是围绕 DB2 UDB 高可用性许可条款的“活动/活动”设置的一个例子。

　　平衡相互接管

　　这是另一种流行配置中的特殊种类的相互接管，我们可以看到这种配置使用在许多分区数据库环境中。在这种配置中，一台机器将它的工作负载平衡地分配到其他机器上。这种方法需要一些工作来设置分区数据库，以便任何机器上的逻辑数据库分区（称为多逻辑节点，MLN）数目等于您的环境中的物理服务器的数目减去 1。对于总共 12 个 DB2 分区，4 台物理服务器中每台服务器将需要 3 个MLN。

　　平衡相互接管配置如 图 4所示。

　　图 4 - 平衡相互接管群集解决方案
 

　　在相互接管例子中( 图 3)您的配置在发生故障之后将成为一个不平衡的系统。您有4个节点，每个节点下面有一个分区在运行，但是在故障接管之后，这些节点有一个节点将会有两个分区，因此它是不平衡的。1 号群集将轻松胜过 2 号群集。

　　在平衡相互接管的情况下，您可以看到最终每台机器上有同样数目的分区，因此故障所带来的影响扩散到了整个系统中。这是非常重要的。是不是意味着贯穿整个系统的所有事务都变慢了呢？如果这是一个问题，您可以使用活动/空闲配置。但是很多 IT 部门将它提升为 Service Level Agreement(SLA)。这种方法允许 DBA 配置环境，通过将工作负载平等地展开到多台机器，这些环境可以在发生故障后保持在 SLA 区域内。

　　在 图 4 中, 1 号机有 1、2 和 3 区，2 号机有 4、5 和 6区，3 号机 有 7、8 和 9 区，4 号机有 10、11 和 12 区。4 号机发生故障后，10 区被移到 3 号机上，11 区被移到 2 号机上，12 区被移到 1 号机上。

　　可是这种方法的缺点很快就暴露出来了。这种配置需要互连的存储器对所有 4 个系统均可存取。在相互接管的例子中，两个系统间仅需要一个互连存储器。这样配置起来也稍微复杂一些；但当故障发生后，一个平衡系统就被破坏了。这并不意味着当您有 4 个系统的时候，您将获得与您在故障发生前所具有的同样的性能。现在您只有三个系统，但性能将被平衡，每台机器分担相同的负载。

　　平衡相互接管配置是关于 DB2 UDB 许可证条款的活动的/活动的设置的一个例子，这些条款是与高可用性相关的。但是您也能将它设置为活动的/空闲的实现。

　　灾难恢复
　　前一章主要处理由于一些网络故障或硬件故障导致的计划外宕机。但是还有一些其他种类的计划外宕机也是 DBA 在设计一个容错性好的数据存储方案时必须考虑的。必须对灾难恢复策略加以更多的关注。

　　灾难恢复包含很多领域。例如，像水灾、飓风、地震等自然灾害可以影响到数据中心。像电源故障、火灾、水源中断等基础设施灾难也可能发生。像病毒、人为错误、人为破坏等操作性灾难也应该加以考虑。

　　如果有正确的计划，即使一个站点出现故障，数据仍然可以保存起来，操作也可以在其他地方继续进行。本章详细介绍了 DBA 保证系统避免物理中断的几种不同方法。

　　数据库备份的传输
　　实施灾难恢复策略最简单的方法就是将备份传输到另一台机器上，并根据这些备份恢复数据库。我们在这里不介绍这种方法，因为这是一个非常简单的概念。

　　DBA 喜欢这种方法肯定是因为它的代价低，而且可以将任何事情恢复到最后一次数据库备份。当然，自您最后一次备份以来发生的所有事务都会丢失。这对您的环境可能重要，也可能不重要。DB2 UDB V7.2 引入了许多新的备份特性，像增量备份和 delta 备份，它们使备份过程更简单 -- 尽管必须对所用已发生的文件具有访问权。

　　您也可以通过传输日志来增强这个方法。然后您就可以在另一台服务器上对日志执行前滚操作，从最后一次备份的日期一直前滚到日志结尾。该方法可以让您恢复更多的数据，但加长了恢复时间，因为您必须从最后一次备份前滚所有的数据库日志。此外，您无法捕获那些在活动日志中是活动的事务。

　　日志传送到备用数据库
　　在说明什么是日志传送之前，我们首先确定 DB2 UDB 确实支持日志传送。很多人存在着一种误解，认为 DB2 UDB 不支持这种数据保护模式。

　　日志传送可能是支持备用数据库最常用的一种方法。什么是备用数据库？它可以自动操作，是生产数据库一个完整的备份站点。在进行的商务活动中所有日志都被拷贝到备用数据库上，备份日志通过支持这一特性的解决方案转移到备用机上，使用FTP协议的客户端描述或本地用户退出支持日志传送的DB2 UDB程序。

　　备用数据库经常性地在日志中进行前滚操作以确定当前最后一次成功地发送日志文件。当主数据库出现故障，通过简单的拷贝覆盖记录的任何日志，前滚至日志尾停下。客户重新连接到备用数据库。这个过程参见 图 5。

　　图 5 - 日志传送和 DB2 UDB
 

　　日志传送的建立和使用是非常简单的。这是该方法对于灾难恢复来说最明显的一个主要优点。它不需要任何额外的软件，并且可以利用DB2 UDB 提供的所有特性很自然地执行。它对生产系统的影响很小，并且可以像一个没有事务丢失的系统一样来执行。

　　对于那些担心数据关键性的人来说，都应该考虑这个方法。例如，假设生产站点由于遭到某种自然灾害而被破坏。更坏的情况是，我们假设每完成一个完整的日志就会出现灾难，但是就在日志被传送到灾难恢复站点之前。这个例子中，备用数据库将导出这个完整的日志和活动日志中的任何事务。如果您无法承受这种数据的“日志泛滥”，还可以使用镜像技术（下面将讨论）来增强日志传送。当然您可以配置日志，使其所容纳的事务数目是有限的，但该方法会导致性能损失，并且只能最小化丢失事务的影响。您还是会丢失一些关键的事务。

　　日志传送的另一个缺点是备用数据库必须与生产数据库在物理上和逻辑上完全相同，同时也不能应用到读操作上，因为它处于前滚暂挂状态。最后，还有一些管理性的变更（如创建索引）不会反映到日志中。

　　日志传送到备用数据库而不会丢失事务

　　但是在考虑到数据时间性时，如果您不能享受“日志延迟”这种奢求，那该怎么办呢？

　　为了在保持日志传送的优点的同时解决这个问题，当今很多系统都为它们的日志部署了某种专有的镜像系统，例如 IBM 的 Peer to Peer Remote Copy ( PPRC)®。利用该类型的特性，在 图 5的基础上建立了 图 6 。不是在日志一归档就进行传送，而是对日志进行镜像。这种情况下，PPRC 执行磁盘镜像，但仅仅是对日志而言。该方法的好处是镜像包含数据；如果生产服务器确实遭到破坏，您不会丢失任何事务。DB2 UDB 自 7.2 版本以来就支持日志镜像。

　　图 6 - 日志传送和 带有日志镜像的 DB2 UDB
 

　　还可以使用新的 I/O 挂起功能，像分离/镜像的支持一样，可以快速地初始化备用数据库。通常，备用数据库需要进行初始化。经常采用的方案是，未记录的数据定义语言(DDL)的更改意味着在日志应用之前，需要创建一个新的备用数据库。DB2 的 I/O 挂起功能解决了这个问题。与 I/O 相关的另一个特性是将生产系统备份转移到备用数据库上的能力。DB2 支持创建备用数据库，然后使用这个数据库来创建一个备份镜像。这减轻了生产系统建立备份的工作负载。

　　日志传送还可用于保护您的数据免受各种人为错误的伤害。例如，DBA 可能引入一个延迟到日志前滚过程中。他们可能只向前滚动日志到业务日的起点。这将为用户创造了在生产数据库上的机会，从而认识到他们可能造成的错误；也许他们运行一个不应该运行的大的删除操作，或者甚至偶然地删除了一个表。因为这种延迟，就有机会在调用下一次前滚操作之前从这种错误中恢复，因此保护您的数据免受人为错误。

　　Dale McInnis 的 DB2 日志传送基础知识是介绍 DB2 UDB 日志传送的好读物。如果您对保护数据的常用方法感兴趣，建议您读这篇文章。

　　复制到备用数据库
　　维护备用数据库的另一项技术是复制，如 图 7 所示。分布式平台上的 DB2 UDB 带有复制功能，该项功能内置在基本服务器中。DB2 UDB 中的复制是一项基于日志的、而不是基于触发器的技术，该项技术使把数据传输到另一台服务器上的过程变得十分灵活而快捷。

　　图 7 - 使用 DB2 UDB 中内置的 CAPTURE 和 APPLY 过程将数据复制到备用数据库中
 

　　复制优于日志传送的地方是可以对备用数据库进行读/写（R/W）访问。在日志传送时，因为数据库处于前滚挂起状态，用户不能对其进行查询。把备用数据库作为报告工具使用，直到需要它充当生产服务器为止，这样做是很有好处的。

　　同样地，因为实际上，您正在复制的数据是备用服务器上日志的回放，所以基本硬件或操作系统并不需要与生产数据库相同。例如，您可能在一个防弹专用的 UNIX 系统上支持您的生产系统，却选择使用一些低成本的商用硬件以及备用机器上的基于 Windows 的报告工具。

　　某些 DBA 喜欢的关于使用复制的另一项特性是 DB2 UDB 支持双向复制。这意味着一个应用程序能够更新备用数据库中的数据，而这个更新过程也会在生产数据库中进行一次——同时使用完全冲突解决策略来处理数据更新时的偏差。

　　最后，您不必复制整个数据库。因为 DB2 UDB 是在表的级别上启用复制功能的，您可以标识出一些关键的表（例如，事务表）进行复制，而不要去管那些可以很快被单独重新装入的表（例如，汇总表或报表）。

　　使用复制来维护备用数据库的一个缺点是，复制天生就是异步的。这可能导致某些事务在站点灾难事件中不能被重放。更糟糕的是，您可能不知道哪个事务还没有被重放，因为您可能不知道在复制过程之前队列有多长。除此之外，与日志传送的情况相似，某些管理性操作（比如创建索引）并没有反映在日志中。

　　复制的设计目的在于解决与灾难恢复场景中进行错误恢复完全不同的问题。这一设计点意味着会出现与复制（不与日志传送一起存在）相关的可观开销。阅读日志和创建分段表（CAPTURE 组件）将工作负载加入到生产服务器。如果出于此目的而使用复制的话，那么将其扩展用于灾难恢复可能是非常有意义的。不过要注意复制无法保证确定数量的事务位于分段表中等待应用到目标服务器。这意味着必须进行测试，以确定可能丢失的事务的最大数量。接收这个最大数的业务也必须接收这样一个可能性，即真实故障发生时表明估算是不正确的。那么工作负载改变了，还需要其他的测试吗？如果出现这种情况的话，在估算事务丢失方面，您还能维护自己的信用吗？利用日志传送的话，开销可能是日志的规模，或者更好，即使用 PPRC 这样的技术，以保证没有事务丢失。

　　远程镜像
　　由于可用性安装的需要，软件和硬件厂商都在飞速地响应产品和应用程序，以符合 24*7 的服务需求，没有哪项业务会例外。组合每个可用性方案能够大大从这些业务中受益，这里高可用性比成本更重要。很简单的道理，对于许多公司来说，当机的成本实在太高了。

　　也许最终的解决方案将是同步地远程镜像所有内容：数据和日志，如 图 8所示。远程镜像跨越“砖墙”或本地灾难站点获取日志和数据（如果产品服务器和备用服务器位于两栋相邻的大楼内，那么远程镜像不再属于灾难恢复计划）。有大量的远程镜像方法。

　　图 8 - 将远程镜像用于灾难恢复 

　　组合注重可用性的硬件和软件，是交付可用性的功能较多药。例如，IBM Enterprise Storage Server® ( ESS)和 RAMAC® Virtual Array 通过存储子系统提供了镜像数据和日志的能力。而这是一种更廉价的方法，它是达到较高级别可用性的现实方式。采用这种“无数据丢失技术”的其他厂商实现包括 CLARiiON 的 SRDF，它通过 EMC 和 Hitachi 的 HDS 来实现。

　　通过这种方法，所有与数据库关联的数据被镜像到远程站点。在发生故障的情况下，镜像磁盘被装载到远程站点。启动 DB2 并执行应急恢复。这是一种简单的方法，但出于下述原因，可能比较昂贵：

• 传送所有已更改的数据到灾难站点的花费。写入数据库的所有更改都要通过线路发送。
  
  
• 与系统规模相关的花费。因为写入到灾难恢复站点的活动需要是同步的，在主站点上提交活动时，您可能有过延迟的经验。数据只能传输得那么快，并且两个站点离得越远，所花费的往返写入时间越长。要最小化这个问题，您可能需要一个比理想环境更大的真实环境。多重存储区域网络（SAN）系统，每次都会制作自己的远程镜像，这将有助于传播写入活动。当然，每个 SAN 都需要有效的通信带宽。

　　结束语
　　DB2 UDB 使得管理具有优秀可用性特征的大型数据库变得容易。无论从硬件还是软件方面来说，构建和管理数据库都具有很大的灵活性。高可用性在业务运作中已经变成了关键因素。每种方法都有其相关的优点和缺点。我们希望本文能从一个较高的层次来给您有关 DB2 UDB 环境的可用性的概述。

　　不管您选择了哪种可用性解决方案，也不管花费了多少资金，甚至不管您的部门使用何种技术，但有一项关键因素对于获得高可用性规划是很重要的：实践、实践、再实践。不要到出现了一次实际的系统崩溃或者服务器当机，才发现其重要性。