db2 HA环境下许可证的问题

      客户之所以选择 IBM DB2 数据库，是因为它能够在难于置信的时间内实现其价值，能够跨各种不同的环境伸缩和集成，还有其健壮性以及极少的停机时间（包括计划内的停机和计划外的停 机）。我听到了很多关于高可用性（high availability，HA）环境中 DB2 的许可方面的问题，高可用性环境的设计目标是减少计划外停机（有时候也包括计划内的停机）。通常，人们的第一层困惑的原因是：在为高可用性环境中的数据库 产品定价时，不同的供应商总是花样百出。

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

另一个容易产生困惑的地方源自在讨论出现停机事件情况时，用来描述用作故障转移服务器的服务器的术语。例如，这种服务器可能被称为备用（standby） 或从（secondary） 服务器（还有其他名称）。如果您接触这一方面的时间比较长，那么很可能对描述这种服务器的功能的术语已经很熟悉了。这些术语包括：idle、active、cold、warm、hot 和 passive。

大多数情况下，IBM Software Group（IBM SWG）文献使用 cold、warm 和 hot 这几个术语来描述备用服务器。在 DB2 9.5 之前，在 DB2 领域情况有所不同。DB2 8 和 DB2 9 使用术语 idle 和 active 来描述备用数据服务器。因此，DB2 8 和 DB2 9 中采用的定价和许可术语可能与其他 IBM SWG 术语不同，这也是常常令客户对高可用性许可产生困惑的源头。

 

好 消息是，在 DB2 9.5 中，与高可用性定价相关的许可术语已经与 IBM SWG 术语一致了。例如，如果在高可用性集群中将一个 DB2 9 数据服务器配置为 sat idle，就必须为这个服务器授予部分许可。在 DB2 9.5 中，不再需要这样做了。如果在 DB2 9 中未启动的服务器上安装 DB2，那么也必须为这个服务器授予部分许可。在 DB2 9.5 中，不需要为未启动的数据服务器购买许可。

 

  简单地说，对于高可用性环境中 DB2 服务器的许可取决于您对以下这些关键问题的回答：

• 您安装了什么版本的 DB2 数据服务器？

  它 是 DB2 Express-C、DB2 Express-C FTL、DB2 Express、DB2 Workgroup 还是 DB2 Enterprise？例如，DB2 Express-C FTL 对于备用服务器没有 hot、warm 或 cold 的概念（稍后进一步解释）。另外，不允许用 DB2 Express-C 建立高可用性集群。

• 您要如何为 DB2 数据服务器颁发许可以确保高可用性？

  对于主流的 DB2 9.5 数据服务器（DB2 Express、DB2 Workgroup 和 DB2 Enterprise）有以下选择：授权用户许可（顾名思义，这种许可要识别每个最终用户）和称为 价值单元（Value Unit，VU） 的基于 IBM SWG 处理器的指标（这样就不需要计算用户数量）。如果使用 DB2 Express-C FTL，就要为每个物理服务器颁发许可。（关于所有分布式 DB2 9 数据服务器的概述以及许可方式，请参见 “Which distributed edition of DB2 9.5 is right for you?”。）

• 当没有出现故障 时，如何使用备用机器？

  是将它用作处理 DB2 事务和查询工作的生产服务器吗？这个服务器上的 DB2 实例启动了吗？这个实例可能正在执行某种形式的工作，而只是在出现故障事件时帮助启动恢复（例如在 HADR 场景中）。简单地说，当一切 正常时备用服务器正在做什么与如何为那个服务器上的 DB2 获得许可有很大的关系。

在讨论高可用性集群对 DB2 9.5 许可的影响时，首先给出与新术语相关的示例。DB2 9.5 定义了三种备用服务器： hot 、 warm 和 cold 。

hot 备用

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

如果出现了故障，那么负载的转移将使 hot 备用服务器（两节点集群中仍然正常运行的机器）的工作负载加倍，因为现在这个机器必须处理它原先的工作负载再加上出 故障的服务器的工作负载。在设置任何高可用性环境时，都需要考虑这一点，在这种环境中，每个服务器互为备用，但是它们必须维持自己的服务水平。如果您是一 名数据库管理员（DBA），并且要满足一个苛刻的服务水平协议（SLA），那么这未必是最好的选择（除非调整其规模或使用 Xkoto GRIDSCALE 等技术限制其影响）。

总 而言之，在 DB2 中，hot 备用服务器是在正常运行期间用来处理用户事务和查询的机器。当集群中另一个服务器出现故障时，hot 备用服务器将接管出故障的服务器机器上的负载，同时还要处理在正常运行期间它自己所执行的工作。因为即使没有故障出现，hot 备用机器仍用于处理用户事务和查询，所以它必须是获得完全许可的。例如，假设有两个数据库分别安装在两个不同的机器上，其中一个机器上运行 着一个企业资源计划（ERP）应用程序，另一个机器运行供应链管理（SCM）应用程序。如果 SCM 数据库出现故障，那么承担着 ERP 工作负载的机器将不得不同时为所有的 SCM 用户提供服务。有两个服务器，在正常运行期间，它们都用来处理事务和查询工作负载（实心框表示在出现故障之前每个机器的工作负载，交叉线 框是当两个机器分别出现故障时，工作负载所出现的地方）。在这个场景中，当机器 2 出现故障时，它的工作负载被转送到它的故障转移伙伴（即机器 1）那里。机器 1 是机器 2 的 hot 备用服务器（当您仔细观察这个图时，会发现反过来也是一样的 —— 注意机器 2 上原属于机器 1 的交叉线框）。这种类型的配置常常被称作高可用性集群对（high-availability clustering pair）、孪生故障转移对（twin failover pair） 或 active/active 对， 这在当今的 IT 环境中非常常见。有许多种在 DB2 中实现 active/active 高可用性集群的方法，根据解决方案的需求，可以使用数据库分区特性，在互为故障转移的每个服务器上的数据库中结合使用 HADR，使用 active 备用服务器通过快照技术或磁盘映像拷贝执行报告功能，使用 xKoto GRIDSCALE 技术。机器 1 和机器 2 一直用于处理自己的事务和查询工作负载，当机器 2 出现故障时，机器 2 上的 DB2 工作负载被转移到机器 1。在这种情况下，如果没有考虑到承担机器 2 的工作负载而对机器 1 的资源进行适当的调整（反之亦然），那么在出现停机并导致工作负载的转移之后，就会引起性能问题。

 

 

对于 hot 备用机器在许可方面的考虑事项

作为一般经验法则，active/active 配置的许可方式应该与各服务器没有参与高可用性集群情况下的许可方式相同。接下来的小节将详细介绍对于 DB2 数据服务器许可方式，您应该知道的一些考虑事项。

价值单元（VU）许可：

对于任何按照 VU 模型 颁发许可的 DB2 数据服务器，hot 备用服务器（这个例子中是机器 1）上的所有 VU 都必须得到许可（除非使用 DB2 Enterprise 中的子容量许可功能）。这种许可方式与服务器没有参与 HA 集群时一样，因为服务器用来处理生产负载，所以这没什么奇怪的。

在图 3 所示的例子中，假设每台机器都运行 DB2 Workgroup（这个版本将服务器的最大 VU 级别限制为 400），那么必须购买共 800 VU 的许可：机器 1 的 400 VU 和机器 2 的 400 VU。

授权用户许可：

对于任何按照授权用户模型 颁发许可的 DB2 服务器产品，必须按照将访问它的授权用户的总数购买许可，这也包含将访问 active 主数据服务器的用户数（因为主数据服务器有自己的应用程序，而且它们互为备用服务器）。授权用户是一个个人（在某些情况下，如果它不代表其他用户，那么可 以是一个应用程序或设备），他具有在公司内外有效的身份。也可以通过因特网使用这些许可（比如在线银行应用程序），因为最终用户是已知的，因而必须被许可 明确识别。授权用户许可拥有完全的权力；不需要像 DB2 8 中那样另外使用服务器许可（在 DB2 8 中，用户权力必须与基本服务器许可结合使用）。如果使用多路复用或连接集中软件，那么需要首先完全识别这些用户，然后才能将这些技术应用于连接。

对 于访问数据服务器的每个用户，都需要获得授权用户许可。但是，无论有多少用户访问数据服务器，至少要购买最低数量的授权用户许可：DB2 Express 和 DB2 Workgroup 数据服务器要求最少 5 个授权用户许可，DB2 Enterprise 数据服务器要求为服务器上的每 100 VU 至少购买 25 个授权用户许可。授权用户许可不能随工作转移而转移（但是可以由于雇用关系转移而转移），它们只对特定的 数据服务器有效。当然，因为这个示例是 active/active 配置，它们的许可方式与完全独立的 active 服务器相同，所以这些规则的意义不大。如果有 100 个用户需要访问两个 active DB2 Workgroup 数据服务器，那么需要购买 200 个 DB2 Workgroup 授权用户许可：2 个服务器 x 每个服务器 100 个授权用户。即使这些用户中只有 12 个用户同时连接这两个服务器之一，也必须为每个 数据服务器颁发所有 100 个用户的许可（所以这个示例需要 200 个授权用户许可）。使用 DB2 Express 或 DB2 Workgroup，而且公司中只有 3 个用户，那么需要 10 个 DB2 Express 或 DB2 Workgroup 授权用户许可（2 个服务器 x 最低授权用户数 5 个），这样才能满足这些 DB2 版本对最低授权用户数的要求。使用的数据服务器是 DB2 Enterprise，情况就不一样了。仍然以前一段中的情况为例，如果有 100 个用户需要访问两个 active DB2 Enterprise 数据服务器，那么需要购买 200 个 DB2 Enterprise 授权用户许可：2 个服务器 x 每个服务器 100 个授权用户。同样，即使这些用户中只有 12 个用户同时连接这两个服务器之一，也必须为每个 数据服务器颁发所有 100 个用户的许可（所以这个示例仍然需要 200 个 DB2 Enterprise 授权用户许可）。 DB2 Enterprise 数据服务器是 2 插槽基于 Intel x86 的双核服务器，那么这些服务器的总 VU 级别都是 200。如果公司中只有 3 个用户，那么需要 100 个授权用户许可（2 个服务器 x 200/100 VU x 25 个授权用户），这样才能满足这个 DB2 版本对最低授权用户数的要求。但是，如果 图 3 中的服务器是 2 插槽基于 Power5+ 的双核服务器，那么这些服务器的总 VU 级别就是 400。所以，对于这种服务器硬件，如果公司中只有 3 个用户，那么需要 200 个授权用户许可（2 个服务器 x 400/100 VU x 25 个授权用户），这样才能满足这个 DB2 版本对最低授权用户数的要求。

正如前面提到的，DB2 Express-C 不支持 高可用性配置。但是，DB2 Express-C FTL 支持。在高可用性环境中为 DB2 Express-C FTL 颁发许可时，不采用本节描述的规则。因为 DB2 Express-C 是一种免费的数据服务器，而 Fixed Term License（FTL）是可以另外购买的支持和特性合约，所以采用另一种许可方式。在高可用性环境中为 DB2 Express-C FTL 颁发许可时，只需为集群中的每个服务器 购买支持合约，而不管采用哪种备用类型（hot、warm 或 cold）；不需要识别服务器的活跃程度、最低用户数、底层数据服务器的价值单元级别和其他情况：非常简单！

 

warm 备用

在 warm 备用 配置中，在正常运行期间，高可用性集群中至少有一个服务器上没有 为用户事务或查询工作负载提供服务的 DB2 数据库。由于这个数据服务器没有执行 “有用的” 工作，因而说它是闲置的。被归为 “无用的” 工作（具有讽刺意味的是，这些工作实际上可能是服务器所做的最有用的工作）包括在故障转移场景中起辅助作用的一些管理工作，比如使处于前滚暂挂状态的数据 库支持日志传送（log shipping）、为 HADR 环境提供事务级日志传送支持等等。如果高可用性集群中某一个服务器出现故障，那么集群软件就会将工作负载转移到 warm 备用数据服务器。

 

对 warm 备用配置普遍存在的一个误解是，warm 备用机器若专用于恢复操作，那就是对资源的浪费。如此理解这种配置是不对的。实际上，warm 备用机器不仅可以担任备用角色，还可以有很多其他用途（包括与 DB2 相关和不相关的用途）。例如，可以在 warm 备用机器上创建另一个 DB2 实例（根据要在那里执行的和 DB2 相关的工作，其中可能牵涉到许可问题），并使用它作为测试机器，还可以将其他工作负载和功能分摊到它上面来执行。当有故障发生时，可以推掉这些工作负载， 让 warm 备用机器使用全部资源来处理出故障的服务器的负载，这样便巧妙地解决了前面讨论 hot 备用配置时提到的负载问题。例如，可以让 warm 备用机器根据 DB2 日志进行前滚，与此同时，这台机器还可以在另一个实例中运行测试场景（或者与 DB2 无关的测试场景，例如应用程序测试等等）。当有故障发生时，只需暂停测试工作负载，让 DB2 承担出故障的服务器的负载，这样就不必担心吞吐量降低。给出一个 warm 备用场景。在这个示例中，当正常运行时，机器 2 用于处理事务和查询工作负载（在图中标为活动工作），而机器 1 作为机器 2 工作负载的 warm 备用，也可能支持某些额外功能，比如应用程序开发。一旦机器 2 出现故障，它的 DB2 工作负载被传递到它的 warm 伙伴机器 1。在这个场景中，情况很可能是这样的：如果在出故障之前（任何类型的）所有工作在机器 1 上执行，那么当机器 2 出现故障之后，这些工作就会收回，以便处理新的工作负载（或者，机器 1 最初确定的规模是同时支持它的工作负载和机器 2 的 DB2 工作负载，否则将出现性能问题）。由于从 DB2 的角度看来，在正常运行期间只有一台机器是活动的，而另一台在做其他事（比如准备 HADR 故障转移伙伴），所以这种配置常常称作 active/idle 配置。这里要注意的重要概念是，在发生停机之前，机器 1 不做任何 “有意义” 的 DB2 工作。根据您的可用性需求、工作负载等等，warm 备用可能适合您的环境，也可能不适合；然而，首先不要忘了高可用性环境的目标 —— 减少停机之后的平均恢复（MTTR）时间。

warm 备用机器许可方面的考虑事项

价值单元（VU）许可：

对于任何按照 VU 模型 颁发许可的 DB2 数据服务器，无论 服务器基于哪种处理核心体系结构，都按照 100 VU 为 warm 备用服务器颁发许可。换句话说，尽管具有 4 个双核 AMD 处理器的服务器的 VU 级别是 400，而具有 4 个双核 Power5+ 处理器的服务器的 VU 级别是 800，但是在用作 warm 备用服务器时，只需按照 100 VU 为 DB2 软件颁发许可。假设每台机器都运行 DB2 Workgroup（这个版本将服务器的最大 VU 级别限制为 400），那么必须按照 500 VU 购买许可：warm 备用服务器（机器 1）的 100 VU 和机器 2 的 400 VU。

授权用户许可：

对 于任何按照授权用户模型颁发许可的 DB2 服务器产品，只需为 warm 备用服务器购买最低数量的授权用户许可。对于 DB2 Express 和 DB2 Workgroup，因为必须为物理服务器购买的最低授权用户许可数量是 5 个，所以 warm 备用服务器需要 5 个授权用户许可。在上面的示例中，如果一个 DB2 Workgroup 服务器是 hot 服务器并参与 active/idle 集群，而且您有 100 个用户，那么需要 105 个 DB2 Workgroup 授权用户许可：100 个授权用户 + warm 备用服务器所需的 5 个授权用户（当然，如果用户数低于最低值，那么 hot 服务器必须满足对授权用户许可的最低数量要求。）

对 于 DB2 Enterprise，必须为 warm 备用服务器购买 25 个授权用户许可，这是因为在 VU 模型中一个 DB2 Enterprise warm 备用服务器按照 100 VU 颁发许可，而 DB2 Enterprise 要求每 100 VU 至少购买 25 个授权用户许可。如果有 100 个用户需要访问高可用性集群中的 hot DB2 Enterprise 数据服务器，那么需要 125 个 DB2 Enterprise 授权用户许可：100 个授权用户 + warm 备用服务器所需的 25 个授权用户。服务器是 2 插槽基于 Intel x86 的双核服务器，那么 hot 服务器的总 VU 级别是 200。如果只有 3 个用户访问 hot DB2 Enterprise 数据服务器，那么仍然需要 75 个授权用户许可：（hot 服务器的 200/100 x 25 个授权用户） + DB2 Enterprise warm 备用服务器的 25 个授权用户。但是，如果 服务器是 2 插槽基于 Power5+ 的双核服务器，那么 hot 服务器的总 VU 级别就是 400。如果只有 3 个用户访问 hot DB2 Enterprise 数据服务器，那么仍然需要 125 个授权用户许可：（hot 服务器的 400/100 x 25 个授权用户） + DB2 Enterprise warm 备用服务器的 25 个授权用户。

正如前面提到的，DB2 Express-C 不支持 高可用性配置。但是，DB2 Express-C FTL 支持。在高可用性环境中为 DB2 Express-C FTL 颁发许可时，不采用本节描述的规则。因为 DB2 Express-C 是一种免费的数据服务器，而 Fixed Term License（FTL）是可以另外购买的支持和特性合约，所以采用另一种许可方式。在高可用性环境中为 DB2 Express-C FTL 颁发许可时，只需为集群中的每个服务器 购买支持合约，而不管采用哪种备用类型（hot、warm 或 cold）；不需要识别服务器的活跃程度、最低用户数、底层数据服务器的价值单元级别和其他情况：非常简单！

 

cold 备用

在 cold 备用 配置中，在正常运行期间，集群中至少有一个服务器上没有 为用户事务或查询工作负载提供服务的 DB2 数据库。这个服务器也不执行在故障转移场景中起辅助作用的任何管理工作，比如使处于前滚暂挂状态的数据库支持 HADR；实际上它甚至可能不开机。给出一个 cold 备用场景。在 这个示例中，当正常运行时，机器 2 用于处理事务和查询工作负载（在图中标为活动工作），而机器 1 上没有启动 DB2 实例。一旦机器 2 出现故障，机器 1 就会启动并通过备份映像将 DB2 数据库恢复到某一时间点，然后继续处理用户事务。还可以将机器 1 配置在 TSA 高可用性集群中，但是不启动数据库实例。您可以看出，cold 备用配置并不是很好的可用性解决方案，因为它的 MTTR 通常比 hot 或 warm 备用配置长得多。

但是，在某些环境中 cold 备用服务器是合适的。通常，我建议客户对应用程序的可用性需求进行多级的分类；例如，建立 Copper、Silver 和 Gold 级别。Copper 级别的应用程序可以采用 cold 备用，Silver 级别的应用程序采用 hot 配置，而 Gold 级别的应用程序采用 warm 备用。按照我的观点，如果需要最高的可用性，就使用 warm 配置并结合使用 HADR。通过使用专用服务器，可能（但也不一定）获得比 hot 备用配置更好的故障间平均时间（MTBF）和 MTTR（除非适当地确定其规模）。

cold 备用机器许可方面的考虑事项

从 DB2 9.5 开始，不需要为 cold 备用服务器颁发许可，因此没有许可方面的考虑事项。判断备用机器是否可以归类为 cold 备用的一条经验规则是，查看是否启动 DB2 实例；但是，这条规则有一些例外。例如，如果从生产服务器取得了快照映像，并且只为了执行备份而启动 DB2 备用数据服务器，执行备份之后就停机，那么也可以认为它是 cold 备用服务器，不需要许可。

所以，采用 DB2 9.5 中新的高可用性许可规则可以帮助您节省资金。假设您要为使用 Database Partitioning Feature 的 DB2 9 环境颁发许可。这个集群由 5 个服务器组成，其中 4 个 hot 服务器的 VU 级别都是 800，它们都配置为向一个备用服务器（也是 800 VU）执行故障转移。在 DB2 9 中，因为没有 cold 备用服务器的概念，所以必须按照 Database Partitioning Feature 的 100 VU 和 DB2 Enterprise 的 100 VU 为备用服务器颁发许可。但是在 DB2 9.5 中，如果备用服务器上没有启动 DB2 实例，它就是 cold 备用服务器，就不需要支付许可费用。

与 HADR 相关的高可用性定价

当在高可用性配置中使用 HADR 时，备用服务器必须 按照 warm 或 hot 服务器颁发许可（取决于是否设置了孪生 HADR 故障转移场景）。

从 DB2 9.5 开始，HADR 被包含在 DB2 Workgroup 中（它一直是 DB2 Enterprise 的组成部分）。在 DB2 9 中，在 DB2 Workgroup 数据服务器中添加 HADR 的惟一方法是，为生产服务器和备用服务器都购买 High Availability Feature Pack！从 DB2 9.5 开始，不再需要这样做了，所以节省了资金：只需按照上述说明，作为 warm 服务器为 DB2 Workgroup 备用服务器颁发许可。

另外，如果希望在 DB2 Express 数据服务器上使用 HADR，那么仍然必须购买 DB2 High Availability Feature Pack；但是，从 DB2 9.5 开始，不再需要在备用机器上为 High Availability Feautre Pack 颁发许可，除非将这台机器用作 HADR 孪生集群中的 hot 备用。

最后，DB2 Express-C FTL 总是允许用 HADR 设置高可用性集群；这种配置没有许可方面的考虑事项，只需为安装 DB2 Express-C FTL 的每个服务器购买支持合约。