使用 IBM DB2 pureScale 实现透明的应用程序扩展

核心提示：简介在经济复苏的过程中，对核心业务数据的即时访问始终是企业赖以生存，使用 IBM DB2 pureScale 实现透明的应用程序扩展，乃至获得成功的关键因素，随着越来越多的美元流入国内市场，对于需要高可用性以及通过横向发展实现成本收益的应用程序来说，DB2 pureScale 提供了一个可以满足这些需求的解决方案，企业

简介

在经济复苏的过程中，对核心业务数据的即时访问始终是企业赖以生存，乃至获得成功的关键因素。随着越来越多的美元流入国内市场，企业需要借助具备高可用性和适用性的基础设施来提高自己的敏捷性，以便能够抓住新的发展机会。

大多数分布式软件公司在营销时都将可用性水平与“类大型机”或“5-9”可用性这样的术语联系在一起。这些短语都在试图传达业界公认的高可用性“黄金”标准（即 DB2 for z/OS ）所设定的持续可用性目标。

可用性 　每年宕机时间
99.999%	5 分钟
99.99%	50 分钟
99.9%	8 小时 20 分钟
99%	3 天 11 小时 18 分钟
95%	18 天 6 小时
90%	34 天 17 小时 17 分钟
85%	54 天 18 小时

如今，可用性并不仅仅意味着能够从容应对组件故障并恢复正常的事务处理。如果您的服务水平协议（SLA）指定预期的查询响应时间应在数秒之内，而服务器却花费了 1 分钟才返回查询，那么这就是可用性方面的问题。要确保可用性，您的系统不仅需要提供事务服务，还需要在 SLA 指定的期限内提供服务。

举例来说，如果业务周期中的季节性波动造成了扩展方面的可用性问题，则真正具备可用性的架构必须能透明地增加资源，同时避免更改应用程序，以满足不断变化的性能需求。透明性是一个关键因素：在提高容量时，不应该让应用程序具备集群感知性（应用程序知道哪些数据在哪个节点上，以避免节点之间的争用）。企业无法投入足够的资金来开发这些复杂的应用程序，因此无法实现合理的扩展。这是为什么呢？首先，显而易见的是，集群感知的应用程序需要适应数据量和分布状态的不断变化。集群感知的应用程序并不仅仅要求代码随着集群的发展而改变：这些代码还需要经历测试、质量保证（Q/A）、部署和认证等过程。这可能造成企业花费数周时间来进行协调，并且不可避免地会耗尽基础设施中本应该有更好用途的资源。

用于在分布式平台（非大型机）上扩展数据库事务的其他产品通常采用过时的架构，因此会为扩展带来不必要的困难（比如说增加开销），从而无法确保符合 SLA 协议。

IBM DB2 pureScale 技术（以下称为 DB2 pureScale）可以将高可用性与真正的透明应用程序扩展结合在一个系统中，以便满足您当前和未来对持续可用性的需求。IBM Power Systems 服务器和 IBM 存储解决方案的整合是 DB2 pureScale 架构交付这种高价值解决方案的内在基础。

到目前为止，“类大型机”仍然是一个引人注目的市场营销词汇。DB2 pureScale 标志着真正透明的扩展架构首次应用程序于分布式平台。本文将介绍 DB2 pureScale 技术的基本概念、背景信息，以及它在高可用性和透明应用程序扩展方面具备独特优势的奥秘。

DB2 pureScale 的基本信息

DB2 pureScale 是一种新的 DB2 可选特性，它允许您通过“双机（active-active）”配置将数据库扩展到一组服务器上，以便交付高水平的可用性和可伸缩性。在这种配置中，运行于各主机（或服务器）上的 DB2 副本可以同时读取和写入相同的数据。

共享 DB2 数据的一台或多台 DB2 服务器被称作数据共享组。数据共享组中的 DB2 服务器是该组的成员。目前，数据共享组支持的最大成员数量是 128。

除了 DB2 成员外，PowerHA pureScale™ 组件还提供了整合的锁管理以及针对数据分页的全局缓存（称作分组缓冲池）。

数据共享组中的各成员可以通过一个非常有效的 InfiniBand™ 网络直接与 PowerHA pureScale 组件交互，如下图所示。这意味着各成员与集中化的锁和缓存设备之间建立了点到点（P2P）连接。

图 1. InfiniBand 网络直接与 PowerHA pureScale 组件交互

DB2 pureScale 的起源

您所听到或看到的任何关于大型机级可用性的描述均指的是 DB2 for z/OS 针对可用性设定的黄金标准。事实上，世界上还没有任何一款数据库解决方案能在可用性方面与运行 DB2 for z/OS 的 System z 服务器相提并论。

DB2 for z/OS 数据共享所采用的底层技术可以确保服务器持续满足 SLA 需求，因为 Coupling Facility 提供了集中化的锁管理和全局缓存，这为快速从故障中恢复提供了保障。事实上，DB2 for z/OS 从严格意义上讲已经实现了“5-9s”级的可用性，同时在无缝线性扩展工作负荷方面享有很高的声望。

起 DB2 for z/OS，很多人都会想到广泛的可伸缩性和极高的可用性。这种市场声誉并非空穴来风，而是源于这些系统在数据库工作负荷可用性方面的市场领先地位始终无人憾动。或许，最能佐证 DB2 for z/OS 强大功能的莫过于 Oracle 创始人兼 CEO Larry Ellison 的评论：

图 2. Larry Ellison 的评论

图字：我取笑过其他许多数据库，但唯独对大型机版本的 DB2 抱有尊重之心。它是当之无愧的一流技术。

DB2 for z/OS 究竟有何独特之处，让 Ellison 对它如此赞赏有加？ DB2 for z/OS 在数据共享领域中的“独门秘笈”对其用户来说再熟悉不过了，那就是众所周知的 Coupling Facility。Coupling Facility 不仅为 DB2 for z/OS 赋予了线性扩展的能力，还提供了一个集中化设备来管理锁。除此之外，它还充当脏分页（dirty page）的全局共享缓冲池（有助于可伸缩性和可恢复性操作）。

DB2 pureScale 技术秉承了 DB2 for z/OS Coupling Facility 的传统血脉，因此积累了诸多优势，从而为 DB2 for z/OS 成为可用性和可伸缩性方面的“黄金”标准奠定了基础。这是如何做到的呢？ DB2 pureScale 随带了一个 IBM powerHA pureScale 组件，该组件提供了同样集中化的锁管理和严格意义上的全局共享缓冲池架构。

其他供应商已经实现了采用共享磁盘架构的数据库，其中最有影响力的是 Oracle Real Application Clusters (Oracle RAC)。但是，在开发和设计 Oracle RAC 时，分布式平台技术还不允许有效地访问集中共享缓存。结果，Oracle RAC 的设计最终成为了一次模拟 DB2 for z/OS 的一次尝试；这也是 Oracle RAC 的分布式锁管理技术和分布式缓存架构的起源。Oracle RAC 在引入横向扩展的共享磁盘架构之后也失去了 DB2 for z/OS 解决方案的简洁性优势。另一方面，DB2 for z/OS 和 DB2 pureScale 提供了相同的集中化资源管理，因此也解决了这些复杂的可伸缩性和可用性问题。本文将在稍后讨论这方面的内容。

最根本的问题是，市场上只有一种架构交付了真正透明的应用程序可伸缩性和高可用性。随着现代硬件在分布式平台上实现了互连，以及基于 InfiniBand 的无中断 Remote Direct Memory Access (RDMA) 的深入发展，DB2 for z/OS 所采用的集中锁和缓冲缓存算法已经不再是它所独享的专利。DB2 pureScale 将这项久经行业考验的技术引入到了分布式平台中，而这也代表了整个 IBM 家族的进步。

DB2 pureScale 实现透明的应用程序可伸缩性

在横向扩展的数据库环境中节省成本的关键是实现真正透明的应用程序扩展机制。透明的扩展意味着数据库引擎可以为 OLTP 应用程序提供更大的吞吐量和更快的响应速度，而对数据本地性没有要求。

数据的本地性表示应用程序所需的数据位于它所连接的服务器上，并且节点之间很少会争用相同的数据分页。在横向扩展架构中，如果采用基于网络的消息传递基础设施来共享集群中的数据，则数据的本地性就显得格外重要。

依靠本地性实现有效扩展的横向扩展架构要求开发人员创建复杂的事务应用程序来实现集群感知性。集群感知的应用程序在开发和部署方面不仅更加复杂，而且成本更加高昂，同时当集群发生更改时还要求重新设计应用程序。一些供应商可能声称它们的架构能运行任何应用程序，而不需要修改；但是，如果在设计时没有实现某种形式的集群感知性，它们就不会扩展任何应用程序。

透明的应用程序扩展意味着应用程序不需要具备集群感知性便可利用横向扩展架构。DB2 pureScale 是分布式平台上所特有的，其高效性源于对现代网络和硬件架构，以及 pureScale 的集中化锁和缓存机制的利用。

为了减少集群中各节点之间的通信，以便实现锁管理和全局缓存服务，DB2 pureScale 使用 powerHA pureScale 集群加速设备（以下简称为 CF）和 RDMA 技术来提供透明的应用程序可伸缩性。

RDMA 允许集群中的各个成员直接访问 CF 中的内存，而 CF 也可以直接访问各成员的内存。举例来说，假定集群中的某成员（成员 1）希望读取未存储在本地缓冲池中的数据分页。DB2 会分配一个代理（或线程）来执行此事务；然后，代理使用 RDMA 直接向 CF 的内存写入数据，声称自己需要读取某个特定分页。如果成员 1 希望读取的分页位于 CF 的全局集中缓冲池中，则 CF 会将该分页直接推送到成员 1 的内存中，而不是让该成员的代理执行 I/O 操作从磁盘读取它。通过使用 RDMA，成员 1 的代理只需向远程服务器发起一个 memcopy（内存复制）调用，从而避免了成本较高的进程间通信、处理器中断、IP 栈调用等。简单来说，pureScale 允许成员的代理通过执行本地内存复制操作来执行远程内存复制操作。

这些轻量级的远程内存调用，连同集中缓冲池和锁管理设备，意味着应用程序不需要连接到已经包含数据的成员。集群中的任何成员都可以有效地从全局缓冲池接收数据分页，无论集群有多大。大多数 RDMA 调用都非常迅速，这使得发起调用的 DB2 进程在等待 CF 的响应时不需要让出已分配的 CPU 时间，并且不需要重新调度便可完成任务。举例来说，为了向 CF 通知某行即将更新（因此需要一个 X 锁），某个成员的代理需要执行 Set Lock State (SLS) 请求，也就是将锁信息直接写入到 CF 上的内存中。CF 会确认集群中的其他成员没有锁定这个行，并直接修改请求成员的内存以批准锁请求。这个 SLS 只需 15 微秒就可以完成整个过程，因此代理不需要让出已分配的 CPU 时间。代理可以持续高效运行，而不需要像其他横向扩展架构那样等待 IP 中断（避免不必要的上下文切换）。对于长时间运行的批量事务等特定操作来说，DB2 代理有必要让出 CPU 时间，而 DB2 会自动决定是否动态让出 CPU 时间。

DB2 pureScale 内置的针对集群成员的负载均衡机制是另一个重要的 DB2 可伸缩性特性。应用程序不需要具备集群感知性便可利用负载均衡机制。DB2 for z/OS 数据共享客户如今所使用的客户端驱动程序可以为 DB2 pureScale 提供集群负载均衡特性。

DB2 pureScale 实现可用性

横向扩展架构的作用并不仅限于为容量的增加保留资源。采用这种架构设计的系统在遇到组件故障时可以继续处理事务，从而能够交付更高的可用性。

与分布式平台上的其他产品相比，DB2 pureScale 将可用性提升到了一个新的高度。DB2 pureScale 允许访问所有不需要恢复的数据分页，并且随时可以洞察哪些分页需要恢复，而不需要执行任何 I/O 操作。这是通过集中化 CF 的独特功能实现的另一项重要创新。

每当成员将分页读取到它的缓冲池中时，CF 都会感知到这一事件并持续对其进行跟踪。只要成员希望更新分布中的行，CF 同样能够知晓相关事件。当一个应用程序执行事务时，成员会将脏分页直接写入到 CF 的内存中。此流程允许集群中希望读取这些经过更改的分页的任何其他成员直接从 CF 获取更新。更加重要的是，从恢复的角度来说，如果任何成员出现故障，CF 中会存在该失败成员正在更新的一些分页，同时还有一些分页已经完成更新和提交，但尚未写入磁盘。

任何关系数据库管理系统（RDBMS）的恢复流程首先都需要重新执行任何已提交的事务，以确保磁盘上这些事务的分页是最新的（此流程称作重做恢复）。此外，任何数据库服务器都需要撤销任何挂起的事务，即在故障之前对磁盘数据执行了更改但尚未提交（此流程称作撤销恢复）。

在共享磁盘集群中，应确保集群中的其他节点没有读取或更新尚未恢复的磁盘中的任何分页（恢复这些分页之后才可以对这些行执行新的事务）。这正是 CF 的闪光之处：由于 CF 知道哪些分页正处于故障节点的更新过程之中，并且 CF 已经将该节点提交的脏分页保存在它的集中缓冲池中，因此 DB2 pureScale 在确定哪些分页需要恢复时不必阻塞其他成员持续处理事务。其他架构则需要了解哪些节点占用的处理时间较多，以便根据锁信息的分布来确定哪些节点必须恢复（详见下文）。

从较高的层面来看，可以很容易地解释 DB2 pureScale 环境中的这种恢复进程。每个成员都有空闲的进程，但它们都随时准备着处理故障事件。当某个成员出现故障时，其中一个恢复进程便会激活；由于这些进程已经存在，因此操作系统不必浪费宝贵的系统时间来创建进程，为它分配内存等。此恢复进程会立即将 CF 中的脏分页预取到它自己的本地缓冲池中。大部分恢复过程都不需要 I/O 操作，因为需要恢复的分页已经在 CF 的集中缓冲池中了。此外，这种分页预取机制将使用轻量级的 RDMA 在 CF 与恢复成员之间实现迅速有效的传输。在这段时间内，所有其他成员上的所有其他应用程序将继续处理请求。如果它们需要从不需要恢复的任何分页获取任何数据，那么它们可以

继续执行自己事务。因此，它们可以继续从磁盘读取分页，因为 CF 已经知道磁盘上的哪些分页是干净的，以及哪些分页需要恢复。然后，恢复进程读取故障成员的日志文件，以便于重放必要的事务来重做或撤销故障成员所做的更新。

对于典型的事务工作负荷来说，从成员出现故障到故障节点未更新完的分页可供其他事务使用的时间间隔通常在 20 秒以内。注意，这同时还包括故障检测时间，而某些供应商在提到恢复时间时都排除了这一时间。数据库中的所有其他分页无时不刻（甚至在成员出现故障之后）都是完全可用的。

此外，系统中像 PowerHA pureScale 集群加速器这样的组件是冗余的。DB2 pureScale 支持双重 CF 功能，这样锁和共享缓存信息就可以存储在两个相互独立的位置，以应对主 CF 出现故障的情况。

结束语

通过利用现代化的硬件架构，DB2 pureScale 可以将之前仅在 DB2 for z/OS 上可用的集中锁和缓存功能引入到分布式平台中。对硬件和网络的利用提高了并发性水平并显著降低了开销，从而提供了更高水平的可伸缩性。此外，集中锁和分页缓存允许 DB2 pureScale 持续感知在成员遇到故障时需要恢复哪些分页。因此，在遇到故障时，所有不需要恢复的数据仍然能供其他应用程序使用，而故障节点正在更新的分页将更加迅速地被恢复。

对于需要高可用性以及通过横向发展实现成本收益的应用程序来说，DB2 pureScale 提供了一个可以满足这些需求的解决方案，并且已经过了市场的考验。