为高可用性环境中分布式 DB2 Universal Database (DB2) Version 8

做HA+DB2的项目倒是有，但是从来也不考虑license，也没做那么复杂的项目，倒是分区功能想尝试一下，哈。

简介
客户之所以选择 IBM® DB2® Universal Database™，是因为它能够在难于置信的时间内体现其价值，能够在各种不同的环境之间伸缩和整合，还有其健壮性以及极少的停机时间（包括计划内的停机和计划外的停机）。在本文中，我们将重点讨论 DB2 的高可用性，但不是从功能的角度来谈（这方面已经有很多的文章了），而是从许可的角度来谈。要得到关于高可用性环境中 DB2 技术方面的好资料，我们建议您购买一本由 Chris Eaton 和 Enzo Cialini 合著的 The High Availabilty Guide for DB2 （ISBN 0131448307）。（注意：这本书没有包括新的高可用性增强，例如 DB2 V8.2 中具备的 High Availability Disaster Recovery，要了解更多关于这方面的信息，请参阅 DB2 V8.2网页。）

我们听到了很多关于高可用性（high availability，HA）环境中 DB2 的许可方面的问题，高可用性环境的设计目标是解决意外停机（有时候也包括计划内的停机）情况下的配置问题。通常，人们的第一层困惑是：在为自己的高可用性环境中数据库产品定价时，不同供应商总是花样百出。令人高兴的是，IBM 在许可方面采取更为体谅的做法，所以更有可能为您的企业节省资金。

另一层困惑主要集中在讨论高可用性时所使用的术语方面。例如术语 集群。有时候 IT 界将高可用性环境称作集群。而我们不喜欢再使用这个术语，因为该术语用到后来已经有点被用滥的感觉，集群可以指可伸缩性方面的集群（例如 DB2 Enterprise Server Edition 中具备的数据库分区特性（DPF）），也可以指可用性方面的集群（例如，在一组 Windows 服务器上使用 Microsoft Cluster Server）。尽管我们不喜欢这个术语，但还是用了它。因此，对于本文，当提到术语 集群时，我们指的是高可用性方面的集群（另行注明的除外）。为简单起见，在与客户、同事等讨论集群时，我们建议在术语集群前面加上 高可用性或 可伸缩性。

另一个容易产生困惑的地方源自在讨论出现停机事件情况下，用来描述将用作故障转移服务器的服务器的术语。如果您接触这一方面的时间比较长（并不是说您年龄比较大，而只是说您在这方面有数年的职业生涯），那么很可能对描述这种服务器的术语已经很熟悉了。这些术语包括： idle、 active、 cold、 warm、 hot、 passive等。

大多数情况下，IBM eServer 文献使用 cold、 warm和 hot这几个术语来描述备用（standby）服务器。不过，在 DB2 这一领域有所不同。DB2 使用术语 idle和 active来描述备用数据库服务器。因此，DB2 中采用的定价和许可方面的术语可能与其他 IBM 软件产品有所不同。这也是常常令客户产生困惑的源头。因此，通过阅读本文可以帮助您分清这些术语，并 知其内情。

在 图 1中，我们将大多数常见的用于描述 HA 环境的术语映射为 DB2 术语：

图 1. 业界高可用性术语与 DB2 术语的对照

在前面的图中，我们在每种类别下面添上了一条 一般经验法则（general rule of thumb ），但是在读完本文之后，这些法则对您来说就是一目了然了。而且要记住，这是一般法则，对于某台机器，您可能在 DB2 中称之为 idle备用机器，而在其他地方又称之为 hot备用机器。

对于高可用性环境中 DB2 的许可取决于您对一些关键问题的回答，这些问题包括：

• 您安装了什么版本的 DB2 服务器？它是 DB2 Express、DB2 Workgroup Server Edition (DB2 WSE)、DB2 Workgroup Server Unlimited Edition (DB2 WSUE) 或者 DB2 Enterprise Server Edition (DB2 ESE) 中的哪一种？
• 您要怎样为 DB2 服务器颁发许可？这取决于您所购买的 DB2 的版本，您可以有这样几种选择：并发用户（功能）许可，注册用户/指定用户许可，或者处理器许可。（如果您想看到关于所有分布式 DB2 服务器以及如何为它们颁发许可的概述，请参阅 Paul Zikopoulos 所著的 哪一个分布式 DB2 UDB V8 版本适合您？。）
• 当出现 has not故障时，如何使用备用机器？是将它用作 DB2 事务和查询工作的生产服务器吗？它是不是空闲并等待故障的发生？也许它正在执行某种级别的工作，而只是在出现故障事件时帮助启动恢复？简言之，当一切正常时，备用服务器正在做什么与如何为那台服务器上的 DB2 获得许可有很大的关系。
• 您是否正在使用 DB2 V8.2 中新的 High Availability Disaster Recovery (HADR) 产品？

最适合用来开始我们的讨论的地方是术语 —— 我们大家的看法都是一致的。如前所述，DB2 定义了两种类型的备用服务器： active 和 idle 。

active standby
在 active standby这种配置中，所有服务器都有用于服务用户事务和查询的、独立的、运行着的 DB2 数据库。这种配置有时候被称作 active/active配置，因为集群中的所有机器在所有时候都在执行某种级别的有用工作。如果集群中的某一台服务器出现故障，那么集群软件将把出故障的服务器上的工作负载转移到集群中仍然正常的一台服务器上。

如果出现了故障，那么资源的转移将使 active 备份服务器（仍然正常运行的机器）的工作负载加倍，因为现在这台机器必须处理它原先的工作负载再 加上出故障的服务器的工作负载。因此，在设置高可用性 active/active 环境时，需要考虑这一点。如果您是一名数据库管理员（DBA），并且您所仰仗的只是一个苛刻的服务水平协议（SLA），那么这未必是最好的选择（除非调整其规模）。

总而言之，在 DB2 中，active 备用服务器是在正常运行期间用来进行服务用户事务和查询的机器。当集群内另一台服务器出现故障时，active 备用服务器将接过出故障机器上的负载，同时还要处理在正常运行期间它自己所执行的工作。因为 active 备用机器仍被用于用户事务和查询，即使没有故障出现， 它也必须是被完全许可的。例如，假设有两个数据库分别处在不同的机器上，其中一台机器上运行着一个 ERP 包，另一台机器处理一些 SCM 工作。如果 SCM 数据库出现故障，那么运行着 ERP 工作负载的机器将不得不同时为所有的 SCM 用户提供服务。

图 2展示了一个 active/active standby 场景。在这个例子中，有两台服务器，在正常运行期间，它们都被用来处理事务和查询工作负载（实心框表示在出现故障之前每台机器上的工作负载，交叉线框是当两台机器分别出现故障时，工作负载所出现的地方）。当机器 2 出现故障时，它的工作负载被转送到它的故障转移伙伴（即机器 1）那里。在这个场景中，相对于机器 2，机器 1 是一台 active 备用服务器（当您仔细观察这个图时，您会发现反过来也是类似的，注意机器 2 上原属于机器 1 的交叉线框）。这种类型的配置常常被称作 高可用性集群对（high-availability clustering pair），在当今的 IT 界，这是很常见的。

机器 1 和机器 2 一直都被用于自己的事务和查询工作负载管理，当机器 2 出现故障时，机器 2 上的 DB2 工作负载被传送到机器 1。同样，在这种情况下，如果没有考虑到承担机器 2 出故障的工作负载而对机器 1 的资源进行调整（反之亦然），那么在出现停机情况并导致工作负载的转移之后，就会引起性能问题。

图 2. 机器 1 是相对于机器 2 的 active standby。当机器 2 出现故障时，机器 2 的工作负载被转移到机器 1

对于 active 备用机器在许可方面的考虑
作为一般经验法则，active/active 配置的定价方式应该与各服务器没有参与高可用性集群情况下的定价方式相同（也存在一些例外，我们在后面会讲到）。接下来的小节将详细介绍对于不同的 DB2 服务器许可方式，您应该知道的一些许可方面的考虑事项。

处理器许可：对于任何按照 处理器许可模型颁发许可的 DB2 服务器产品（例如 DB2 Express、DB2 WSUE 和 DB2 ESE），active 备用服务器（这个例子中是机器 2）上的处理器都必须得到许可。

在 图 2展示的例子中，假设每台机器在一个双 CPU 的服务器上运行 DB2 Express，则必须获得的许可为： 2 个服务器 x 2 个处理器= 4 个处理器。

并发用户：对于按照 并发用户模型进行许可的 DB2 服务器产品（这一次，DB2 WSE 是惟一按此方式进行许可的 DB2 服务器），则必须用一个 DB2 服务器许可 以及将在正常运行期间（即出现故障 之前）访问 active 备用服务器 （机器 2）的并发用户的数量，来对 active 备用服务器颁发许可（如果您要使用连接集中软件或多路器，那么必须在连接被集中 之前算出用户的数量）。在故障期间，可以将出故障的服务器上的并发许可免费移交给 active standby （机器 1）。简言之，每台服务器只需为各自的工作负载环境发放许可，当出现故障时，可以将并发用户许可免费移交给仍然正常运行的机器。

在 图 2展示的例子中，如果每台 DB2 WSE 服务器要为 50 个并发用户发放许可，那么您将需要： (2 台服务器 x 50 个并发用户) = 100 个并发用户许可 + 2 个 DB2 WSE 服务器许可（每台服务器一个许可）。

在机器 2 停机期间，active 备用服务器（在这个例子中是机器 1）为 100 个并发用户获得许可。也就是说，原本属于机器 1 的 50 个并发许可再加上从机器 2 那里得到的另外 50 个并发许可。当两台机器都正常运行时，每台服务器各有 50 个并发用户的许可。

注册用户或指定用户：对于按照 指定用户模型（例如 DB2 Express）或者 注册用户模型（例如 DB2 WSE）颁发许可的任何 DB2 服务器产品，必须用服务器许可来为 active 备用服务器发放许可。（这里澄清一下，DB2 Express 指定用户许可与 DB2 WSE 注册用户许可是一回事）。DB2 注册用户和指定用户许可是为特定个体提供的权利，使他们可以访问公司中任何为指定用户或注册用户许可的 DB2 服务器。例如，您可以让一个指定用户访问您环境中的十个不同的 DB2 数据库服务器，条件是这些服务器按照指定用户或注册用户方式颁发许可。

在 图 2展示的例子中，如果您有 100 个注册用户和两个 DB2 WSE 服务器，那么您将需要： 100 个注册用户 + 2 个 DB2 WSE 服务器许可。请记住，注册用户和指定用户许可只是为特定用户提供的，不能在连接时像并发用户许可那样动态地移交许可。

如果您要使用 DB2 V8.2 中新的 HADR 特性，那么还有一些 High Availability Disaster Recovery (HADR) licensing 方面的考虑是您需要知道的，我们将在本文的后面讲到。

Idle standby
在 idle standby这种配置中，在正常运行期间，高可用性集群中的某一台服务器 没有一个服务用户事务或查询工作负载的 DB2 数据库。这台服务器安装了 DB2 服务器软件，这个软件可能被启用，也可能没有被启用，但是它一直处于闲置状态，并没有执行“有用的”工作。属于“无用”（实际上，这种工作可能反而是最有用的）的工作有：在 failover/HA 场景中的管理动作，例如使一个数据库处于 rollforward pending 状态来支持日志传送，产生一个 DB2 数据库的 flash 副本，然后在另一台服务器上执行该副本的数据库备份，为 HADR 环境提供事务传送支持等。如果在高可用性集群中有某一台服务器出现故障，那么集群软件会将其工作负载转移到 idle 备用数据库服务器上。

对于 idle standby 配置有一种很常见的误解，那就是 idle 备用机器只用于恢复运行，因而是一种资源浪费。其实这是对这种配置的一种不正确理解。实际上，除了作为备用机器以外，idle 机器还有很多用途（既包括与 DB2 相关的用途，也包括与 DB2 无关的用途）。例如，您可以在 idle 机器上创建一个新的 DB2 实例（取决于您选择在那里执行什么样的 DB2 相关工作，它可能隐含许可），并将它用作测试机器，或者将其他工作负载和功能转移到这台机器上。出现故障时，您可以缩减工作负载，允许备用机器用它所有的资源来处理出故障的机器上的负载，从而绕过了在讨论 active standby 配置时提到的关于负载的顾忌。例如，您可以让 idle 备用机器沿着 DB2 日志前滚，与此同时，它在运行另一个实例中的测试场景（或者非 DB2 目的的场景，例如应用程序测试等）。当出现故障时，只需静态测试工作负载并让 DB2 承担出故障的服务器上的负载，而不必考虑吞吐率是否会下降。

客户们采用各种不同的方式来使用备用机器。我们建议在考虑备用机器的使用时，对目标和业务需要划定优先级。例如，有些客户可能会选择在一台备用机器上设立一个日志传送环境。与此同时，他们还想将同一个备用数据库用于当前某个只读的生产机器 —— 这样可以在越来越多的资源之间分摊成本（会计人员确实很喜欢看到这种情况）。大多数供应商将这种模型限制为 either/or 形式 —— 即，当您在读数据库的时候，就不能沿着日志前滚（如果不是 eithyer/or 形式，那么对于前滚过程所能保持的速度要有所折扣，就像在逻辑备用服务器中一样）。此后，由于只读操作要延续一段时间，而让数据库保持打开状态，这增加了故障的修复时间：这正是设计这种配置时希望避免的问题。我们的建议是，如果要突出可用性特征，那么应该将可用性作为首要目标来对环境进行定价和调整。如果您可以承受更长的停机时间，那么可以在考虑备用机器的使用时有更多的选择。

最后，在很多情况下，在 active/idle 环境中许可 DB2 要比其他供应商的 active/active 环境更为廉价（即使 包括硬件，也是如此），这决不是什么营销时的夸夸其谈。DB2 V8.2 for Linux 还包括 Tivoli System Automation for Linux 的一个免费的 2 节点（2-node）许可，后者可以提供 20 种辅助故障转移场景，而复杂性却很小（复杂性的减少是件了不起的事情）。除此之外，不要忘了 所有DB2 服务器都有 HA-licensing，而不仅仅是 Enterprise 版才有。

图 3展示了一个 idle standby 场景。在这个例子中，在正常运行期间，机器 2 被用于事务和查询工作负载（在图中被标为 active 工作），而机器 1 则被当作机器 2 的工作负载的 idle standby，可能还支持其他一些功能，例如应用程序开发，或者干脆将其关闭。当机器 2 出故障时，它的 DB2 工作负载被传递给它的 idle 伙伴，也就是机器 1。在此场景中，很可能出现的情况是，如果在出故障之前有什么工作（包括任何类型的工作）在机器 1 上执行，那么该工作将被缩减，以便处理机器 2 出故障之后到来的新工作负载（或者机器 1 被调整到初始规模，以支持其工作负载，包括 DB2 工作或非 DB2 工作，同时还有机器 2 的工作负载 —— 否则就会有性能问题。）

在图 3 中，从 DB2 的角度来看，在正常运行期间只有一台机器是 active 的，而另一台机器在处理其他事情，因而这种配置常常被称作 active/idle配置。（注意，根据 idle 备用机器上所执行的工作，您可能需要购买附加的 DB2 许可：例如，如果将一台机器用作 idle standby，同时开发人员又要使用这台机器作为 DB2 应用程序开发环境，那么您可能要为开发人员选择购买 DB2 Universal Developer Edition 许可。）这里要注意的一个重要概念是，在出现停机情况之前，机器 1 没有做任何有意义的 DB2 工作。

图 3. 机器 2 的工作负载被传送到 idle 备用服务器，即机器 1

同样，在选择环境时，idle standby 不一定是正确的选择，这取决于可用性需求、工作负载等方面。但是别忘了您为什么将高可用性环境放在第一位 —— 为了减少故障修复的时间。

对于 idle 备用机器在许可方面的考虑
处理器许可：对于按照 处理器许可模型颁发许可的任何 DB2 服务器产品，（例如 DB2 Express、DB2 WSUE 或 DB2 ESE），出于高可用性目的，idle 备用服务器只要求一个处理器是必须颁发许可的。在上面的例子中，假设每台机器在 2 路 CPU（2-way）服务器上运行 DB2 WSUE，那么您需要的许可为： (1 台 active 服务器 x 2 个处理器) + 1 台 idle 备用机器上的 1 个处理器 = 3 个处理器。

分区数据库：对于分区数据库环境中的 idle 备用机器，许可这一术语在 DB2 Version 8.1 中发生了变化。idle 备用机器与 Database Partitioning Feature（DPF）一起使用，DPF 是 DB2 Enterprise - Extended Edition 在 DB2 Version 7 中提供的一个特性，在这里，idle 备用机器的许可方式与没有分区的服务器的许可方式是一样的。而在 DB2 V8.1 之前，必须对 DB2 EEE 环境中所有的故障转移处理器颁发许可。

例如，如果您有 4 台 8 CPU 的服务器，并在其中 3 台服务器上安装了 DB2 ESE，将它们用作生产型服务器，同时将剩下的一台服务器作为备用服务器（带有 DPF 特性），那么您需要的许可为： (3 台 active 服务器 x 8 个处理器) + 1 个 idle 备用机器上的处理器 = 25 个处理器（在这个例子中，我们假设您认为一个处理器许可等于一个 DB2 ESE 处理器许可加上每个处理器为 DPF 特性支付的额外费用）。

并发用户：对于任何按照 并发用户模型颁发许可的 DB2 服务器（例如，DB2 WSE），只需用一个服务器许可就可以获得 idle 备用服务器的许可，因为在故障转移期间，可以将出故障的服务器上的并发用户许可动态地转交给 idle 备用机器。

在前面的例子中，如果您在两台机器上都安装了 DB2 WSE，并为 50 个并发用户授予 active 服务器的权限，那么您将需要： 2 个服务器许可（一个用于生产，一个用于 failover） + 50 个并发用户许可。

请记住，DB2 WSE 是通过使用每个服务器许可加上一个用户的费用（并发用户或注册用户）来获得许可的。在故障转移之后，idle 备用服务器将获得 50 个并发用户的许可，这些许可是机器 2 上原有的 50 个并发许可。

注册用户或指定用户：对于任何按照 指定用户模型（例如 DB2 Express）或者 注册用户模型（例如 DB2 WSE）获得许可的 DB2 服务器，只需用一台服务器来为 idle 备用服务器颁发许可。（更确切地说，DB2 Express 可以用一个指定用户许可来获得许可，而 DB2 WSE 可以用一个注册许可来获得许可，其实这是一回事）。DB2 注册用户许可和指定用户许可是为特定个体提供的一种权利，使他们可以访问公司中任何为指定用户或注册用户颁发许可的 DB2 服务器。

在前面的例子当中，如果您有 100 个指定用户，还有一个生产 DB2 Express 服务器，那么您将需要： 2 个 DB2 Express 服务器许可 + 100 个指定用户许可。由于指定用户许可可以访问环境中的多台服务器，因此不需要将指定用户权利划分给每台服务器。

提示：在这种环境中，如果将 idle 备用机器作为 active 备用机器来使用，不会影响许可成本（由于与指定用户或注册用户相关的术语和条件），所以，您可以从注册用户许可或指定用户许可中获得更大的价值。但是，当出现停机情况时，备用机器上将引入负载，因此您必须仔细权衡这种方法的优缺点。简言之，可以直接在 active/active 配置中使用为注册用户或指定用户许可的 idle 备用机器，无需再去考虑许可问题。

如果您要使用 DB2 V8.2 中新的 HADR 特性，那么还有一些 HADR licensing 方面的考虑事项是必须知道的，我们将在下一节中讲到它们。

关于 HADR 的高可用性定价
DB2 V8.2 引入了一种叫做 High Availability Disaster Recovery (HADR) 选项的新的可用性产品。HADR 产品使 DB2 能够从日志缓冲区交付事务，而在此之前的很长一段时间里，DB2 是从日志文件交付事务的。这种增强为一个更丰富的、更有粒度的、齐全的数据丢失预防环境提供了支持，这种环境带有多种扩展选项，例如无需停机便可更新操作系统的能力。HADR 有三个数据丢失预防级别，其中一个级别保证零丢失事务环境。将所有这些包装起来的是一个功能完备的 GUI，这种 GUI 使得 HADR 环境的建立十分便捷。下面的 图 4展示了一个 HADR 的例子：

图 4. HADR 环境中的 DB2

对 HADR 技术细节的讨论超出了本文的范围。请访问 DB2 V8.2网页，以获得更多信息。

DB2 ESE 附带了 HADR 选项，这个选项没有另外收费，还可以将该选项作为 DB2 Express、DB2 WSE 和 DB2 WSUE 服务器的附带产品 —— 如果您正计划与 ESE 服务器一起使用 HADR，那么只需遵从本文中给出的指南，并跳过此节即可。

购买用于 DB2 Express、DB2 WSE 和 WSUE 的 DB2 High Availability Disaster Recovery 选项的惟一方式是通过一个处理器许可。DB2 服务器上的每个 active 处理器都必须获得 HADR 许可，备用机器获得 HADR 许可的方式应该与您用一个处理器许可为备用机器获得 DB2 服务器许可的方式相同（这取决于备用机器的 active 或 idle 状态）。

如果您使用并发用户、指定用户或注册用户为 DB2 服务器获得许可，那么仍然必须通过服务器上处理器的数量来获得 HADR 选项许可。换句话说，对 DB2 HADR 选项的许可总是基于处理器的数量，而不管 DB2 服务器本身是如何获得许可的。例如，如果您有一台 DB2 WSE 服务器，服务器有 10 个并发用户，并且是在一个 active/idle standby 集群中使用该服务器，同时该集群在一台 2 CPU 的服务器上带有 DB2 HADR Option 产品，那么您将需要： 2 个 DB2 WSE 服务器许可 + 10 个并发用户许可 +（（active 机器上的 2 个 DB2 HADR Option 处理器许可）+ idle 机器上的 1 个 DB2 HADR Option 处理器许可 = 3 个 HADR 处理器许可）。

前一个例子是否让您失去警惕呢？其中可能有些扑朔迷离。我们将为您加以简化。在这个例子中，您有 2 台服务器，每台服务器有 2 个处理器（在集群中一共有 4 个处理器）。其中一台机器是 active 机器，做一些有意义的工作。另一台机器是 idle 机器，它一般做一些其他的工作，但是从 DB2 的角度来看，它只是做一些工作来帮助故障恢复等。由于我们有两台服务器，并且选择使用并发用户模型来为 DB2 WSE 颁发许可，所以我们需要 2 个 DB2 WSE 服务器许可。此外，由于 active 机器每次有不超过 10 个的并发用户，因此您将需要 10 个并发用户许可（这里不需要用于 idle 机器的并发用户许可，因为在出现停机情况时，可以动态转移并发用户许可）。最后，由于您要使用 HADR，因此，对于 active 服务器，需要有 2 个 HADR 处理器许可，而对于备用服务器，需要有一个 HADR 处理器许可。