db2 HA环境下许可证的问题

核心提示： 正如前面提到的，DB2 Express-C 不支持 高可用性配置，db2 HA环境下许可证的问题(5)，但是，DB2 Express-C FTL 支持，warm 备用可能适合您的环境，也可能不适合；然而，在高可用性环境中为 DB2 Express-C FTL 颁发许可时，不采用本节描述的规

正如前面提到的，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）时间。