并行DB介绍与探讨

在前面的“双活数据中心建设系列之---基于软件架构的双活数据中心建设方案深入探讨（GPFS部分）”中（点击标题可回顾），我们详细介绍了GPFS的三种模式架构以及其容灾和双活方式，这是对需要共享存储的应用系统，利用软件架构的方式，去实现跨中心的应用双活，那么又该如何基于软件架构，去实现OLTP数据库的跨中心双活呢？

这里我们需要提到并行DB的概念：并行数据库系统的目标是高性能和高可用性，通过多个处理节点并行执行数据库任务，提高整个数据库系统的性能和可用性。

性能指标关注的是并行数据库系统的处理能力，具体的表现可以统一总结为数据库系统处理事务的响应时间。并行数据库系统的高性能可以从两个方面理解，一个是速度提升，一个是范围提升。速度提升是指，通过并行处理，可以使用更少的时间完成数据库事务。范围提升是指，通过并行处理，在相同的处理时间内，可以完成更多的数据库事务。并行数据库系统基于多处理节点的物理结构，将数据库管理技术与并行处理技术有机结合，来实现系统的高性能。

可用性指标关注的是并行数据库系统的健壮性也就是当并行处理节点中的一个节点或多个节点部分失效或完全失效时，整个系统对外持续响应的能力。高可用性可以同时在硬件和软件两个方面提供保障。在硬件方面，通过冗余的处理节点、存储设备、网络链路等硬件措施，可以保证当系统中某节点部分或完全失效时，其它的硬件设备可以接手其处理，对外提供持续服务。在软件方面，通过状态监控与跟踪、互相备份、日志等技术手段，可以保证当前系统中某节点部分或完全失效时，由它所进行的处理或由它所掌控的资源可以无损失或基本无损失地转移到其它节点，并由其它节点继续对外提供服务。

为了实现和保证高性能和高可用性，可扩充性也成为并行数据库系统的一个重要指标。可扩充性是指，并行数据库系统通过增加处理节点或者硬件资源（处理器、内存等），使其可以平滑地或线性地扩展其整体处理能力的特性。

那么基于以上的并行DB的高性能和高可用性概念，如何去理解并行DB的架构呢？又该如何去设计并行DB的跨中心双活架构呢？由于数据库产品众多，这里只挑选两款企业OLTP数据库系统用得非常多、认可度高的产品：ORACLE和DB2，进行深入的探讨。

Oracle RAC

对于Oracle RAC，想必大家已经非常了解了，那么下面开始一步步引导大家逐步过渡至跨中心双活的并行Oracle架构。

一.存储架构层

文件系统的选择是并行Oracle的关键。传统的文件系统不支持多系统的并行挂载。因此，必须将Oracle数据文件存储在支持多系统并发访问的文件系统中。这样并行Oracle节点才能同时对共享的文件系统进行读写操作。这里主要有三种方式来实现：

（1）自动存储管理（ASM）

ASM提供了一个纵向的统一管理的文件系统和卷标管理器，专门用于建立Oracle数据库文件。ASM可以提供文件系统给多个Oracle RAC的集群节点。ASM无需再手动调节I/O，它会自动的分配 I/O 负载到所有的可用资源中，从而优化性能。ASM可以维护数据的冗余备份，从而提高故障的容错。它也可以被安装到可靠的存储机制中。

（2）通用并行文件系统（GPFS）

前面已经详细介绍了，用在并行Oracle架构的话，GPFS的SAN模式架构和NSD服务模式均可。它相对于ASM这样一个黑盒子来说，优势主要体现在可视化、管理能力和灵活性上，但ASM是专用于的Oracle RAC产品，对非条带化的磁盘数据也能分布均匀，I/O均匀。

（3）存储双活

这里说的存储双活并不是单一存储中的控制器双活，而是两台存储的A-A模式，如在“基于SVC的三种主流双活数据中心架构深入探讨”活动中探讨的SVC Enhanced Stretched Cluster和SVC HyperSwap，通过这种存储双活的架构结合并行Oracle，也是一种非常好的想法，Oracle RAC节点可以分别挂载不同的A-A存储，而无需考虑底层存储间的同步和双活过程，相当于把并行文件系统的功能交由底层存储硬件去实现，Oracle RAC节点纯粹做好并行Oracle的工作即可，并且这种架构少了一层（ASM/GPFS）文件系统层，I/O深度更浅。

二.并行Oracle软件架构层

Oracle RAC的软件层是在多个节点上运行多个数据库实例，利用多个节点组成一个数据库，这样在保证了数据库高可用性的情况下更充分的利用了多个主机的性能，而且可以通过增加节点进行性能的扩展。实现Oracle RAC需要解决的关键问题就是多节点进行数据访问时如何保证数据的一致性，Oracle是通过各节点间的私有连接进行内存融合（cache fusion）来保证各节点数据访问的一致性。

什么是cache fusion？

这是Oracle RAC的重要概念，它是通过Oracle RAC节点间的互连网络，在各节点的 SGA 之间进行块数据传递，以实现SGA数据块共享和一致性。它相当于把所有节点实例的SGA虚拟成一个大的SGA区，每当不同的实例请求相同的数据块时，这个数据块就通过互连网络在实例间进行传递。这样一种方式可以避免不同实例需要相同数据块时，首先将块推送到磁盘，然后再重新读入其他实例的缓存中这样一种低效的实现方式。

当一个数据块被读入 RAC 环境中某个实例的缓存时，该块会被赋予一个锁资源，以确保其他实例知道该块正在被使用。之后，如果另一个实例请求该块的一个副本，而该块已经处于前一个实例的缓存内，那么该块会通过互连网络直接被传递到另一个实例的 SGA。如果内存中的块已经被改变，但改变尚未提交，那么将会传递一个修改块副本。这就意味着只要可能，数据块无需写回磁盘即可在各实例的缓存之间移动，从而避免了同步多实例的缓存所花费的额外 I/O。

很明显，不同的实例缓存的数据可以是不同的。所以，一个实例要访问特定数据块，并且之前该实例从未访问过该数据块，那么它要么从其他实例 cache fusion 过来，要么从磁盘中读入。

既然cache fusion如此重要，要发挥cache fusion的作用，要有一个前提条件，那就是互连网络的速度要比访问磁盘的速度要快。否则，就根本没有引入cache fusion的意义。但是这样又带来了另外一个问题，随着Oracle RAC节点数的不断增加，节点间通信的成本也会随之增加，当到某个限度时，增加节点可能不会再带来性能上的提高，甚至可能造成性能下降。

这个问题的主要原因是 Oracle RAC对应用透明，应用可以连接至集群中的任意节点进行处理，当不同节点上的应用争用资源时，RAC 节点间的通信开销会严重影响集群的处理能力。所以通常而言，Oracle RAC 更多情况下用来提高可用性，而不是为了提高扩展性和性能。但是对于使用 ORACLE RAC 有以下三个建议：

（1）节点间通信尽量使用高速互连网络。

（2）每个ORACLE数据页面使用较少的行，通过数据库分区来避免热页面。

（3）尽可能将不同的应用分布在不同的节点上，利用业务分割的方式，来保证整体Oracle RAC的系统性能。业务分割的根本在于尽量使不同的实例不能访问相同的数据块，这样业务分割规则可以小到表的级别，大到表空间、Schema的级别。

可以看到，建议（2）和建议（3）实际上又削减了Oracle RAC的应用透明度，可见并行DB要同时提高高可用性、扩展能力、性能和应用透明度是十分艰难的。

三.跨中心的存储架构和并行Oracle扩展

前面谈到了并行Oracle存储架构的三种方式，那么这三种方式被拉伸至两个数据中心后，存储架构和并行Oracle又该如何扩展呢？

（1）自动存储管理（ASM）

Oracle RAC节点被拉开至两个站点后（Oralce Extend RAC），为了保证两个站点的存储数据一致，需要在所有节点操作系统层识别两个存储，并做LVM镜像。所有节点通过ASM对LV裸设备或者文件系统进行读写操作。

如果SiteA的存储作为主存储，那么SiteA的某一节点的写入操作需要如下过程：SiteA节点写SiteA存储，同时跨站点写SiteB存储，所有存储均写返回后，代表一次写入操作完成。SiteB的某一节点的写入操作需要如下过程：SiteB节点写SiteB存储，同时跨站点写SiteA存储，所有存储均写返回后，代表一次写入操作完成。所以这种方式下，一次写操作的速度取决于最慢的存储。

另外cache fusion是基于TCP/IP或者Infiniband的跨站点融合，对两个站点间的带宽、衰减和稳定性有很高的要求。

（2）通用并行文件系统（GPFS）

在单一站点的话，GPFS的三种模式中的SAN模式架构和NSD服务模式架构都是可以胜任并行Oracle的存储架构的。

SAN模式架构是Oracle RAC节点通过SAN网络共享存储，再在共享存储之上建立GPFS文件系统，Oracle的数据库文件存储在GPFS文件系统中，最终实现两个Oracle RAC节点并行对GPFS文件系统读写的功能。

当SAN模式架构扩展至两个站点的话，两个站点的存储需要保持实时同步，但是SiteB的Oracle RAC节点只能通过SAN网络或者TCP/IP网络访问SiteA的共享存储，对于OLTP数据库来说，站点B的RAC节点I/O访问路径过长，性能不够稳定，而且前面提及的cache fusion需要跨站点通讯，两个数据中心的距离不宜太远。所以这种模式并不理想。

NSD服务模式架构是Oracle RAC节点通过SAN网络分别挂载不同的存储盘，Oracle RAC节点均作为NSD SERVER，数据一致性是通过NSD盘间的实时复制保持的，通讯网络为TCP/IP网络或者INFINIBAND网络。

当NSD服务模式架构扩展至两个站点，每个站点均包含一个Oracle RAC节点和一套存储，这种模式下，每个站点的RAC节点访问各自站点的存储，存储数据块的同步为跨站点的NSD间的同步，通过跨站点的网络实现，每个站点的RAC节点I/O深度浅，路径短，但考验的是数据一致性、跨站点NSD实时同步和cache fusion的效率，最起码需要万兆或者INFINIBAND网络级联。

（3）存储双活

前面也讲了，当Oracle RAC的存储拉开至两个站点后，从底层存储的角度来看，这种方式较为理想，两个站点的RAC节点无需关心存储是否共享，底层存储会做好数据层所有数据同步的工作，RAC节点I/O深度浅，路径短，带宽高

相比前面两种方式，在跨中心并行Oracle的存储架构来说，最为合适，当然这里也需要考虑Oracle RAC节点间的cache fusion的效率，不建议过高并发的数据库系统需求，跨中心Oracle RAC节点的数量也需要控制。

上面三种方式，对于跨中心的Oracle RAC来讲，也是建议将业务尽量分割，对不同的表或者表空间操作的事物放在不同的Oracle RAC节点跑，尽量减少跨中心的I/O流量和网络流量，不至于为了双活而双活，反而导致可靠性和性能降低。

DB2 PureScale

DB2 PureScale是以IBM DB2 for z/OS技术(集中锁定和集中缓冲池技术)为基本原则，主要针对分布式系统的在线事务处理(OLTP)提供集群技术。

DB2 PureScale并不是一个硬件解决方案，它是一个应用在AIX系统（现在也可运行在Linux系统）上的数据库集群软件。如果该软件在IBM Power Systems上运行，在降低扩展IT系统的风险和成本的同时，可以帮助客户提高数据库交易能力。其目的是让企业在不牺牲性能的前提下扩展DB2集群，DB2 PureScale具有无限扩展、应用透明性、持续可用性等特点：

(1)无限扩展

DB2 PureScale为各种事务处理工作负载提供了几乎无限的产能。系统扩展非常简单，只需要与一个新节点连接，并发出两个简单的命令即可。DB2 PureScale基于集群、磁盘共享的架构通过有效利用系统资源，降低了成本。

(2)应用透明性

使用DB2 PureScale，无需改变企业的应用程序代码，就可以有效地运行在多个节点上。久经验证的、可扩展的架构能够随需扩展应用程序，以满足变化的业务需求。企业只需做少量改变或无需做任何改变，就能够运行为其他数据库软件编写的应用程序；DB2 为常用的语法规则和PL/SQL语言提供了全面的支持，使从Oracle数据库迁移到 DB2 变得比以往更轻松了。

(3)持续可用性

DB2 PureScale通过在IBM Power Systems上和冗余架构中使用高可靠的IBM PowerHA PureScale技术，提供了持续的可用性。此系统能够瞬间从节点故障中恢复，立即将工作负载重新分配给其他可用的节点。

如何理解以上的三个特点呢，我们先来看下DB2 PureScale的整体系统架构图：

从图中可以看出，一套DB2 PureScale架构上包含以下几个部分：

（1）数据库集群

DB2 PureScale数据库集群由成员和CF节点组成。

a.成员member

代表一个DB2处理引擎（一个DB2实例），一个成员拥有自己的内存、缓冲池、交易日志和锁机制，能自行编译和执行DB2事务。

b.耦合设施coupling facility(CF)

CF节点管理着DB2数据页的全局缓存和全局锁，以此为所有成员提供服务，CF节点采用集中式锁机制和集中式缓存机制来保证所有成员事务层数据的一致性。在实际应用中，通常配置两个CF节点，一主一从，这样可用避免CF节点单点故障。

另外，主从CF间的全局缓存和全局锁也是实时复制的，来保证CF节点故障后，备CF节点能够快速无缝接管。基于以上的机制，成员对数据页的访问，在成员本地缓冲池没有命中或者需要修改数据页时，需要成员和向主CF节点发起通信请求，来获得数据页和锁信息，在数据库并发较大、事务更新多的情况下，通信频繁度非常高，为了尽可能地提高通信效率，DB2 PureScale使用了RDMA（Remote Direct Memory Access）技术。RDMA支持直接读写另一台计算机的内存，并且不需要占用目标计算机的CPU资源。RDMA技术结合超高速网络，如InfiniBand、万兆或聚合以太网(RoCE)，大幅缩短成员与CF间的通信时间。

（2）数据库集群服务

DB2 PureScale中整合了DB2 Cluster Services，来支持错误检测和自动恢复的任务，这些技术服务包含了TSA（Tivoli System Automation）和RSCT。其中TSA用来实现监控、失败检测、成员的重启和恢复、CF节点切换的任务。

（3）GPFS文件系统

DB2 pureScale各个节点通过GPFS文件系统访问共享存储。从图中也可以看出，采用了GPFS SAN网络模式架构，所有节点均直接通过SAN网络连接存储，GPFS高可用上采用了2N节点+1TiebreakerDisk的方式。

通过以上的介绍，大家也可以看出DB2 PureScale的CF节点是重中之中和核心关键点，在集群数据库运行时，虽然成员多个并行运行，但CF节点工作时只是单节点运行，虽然CF节点的主备节点可以实现故障切换和内存的无缝衔接，但是是否可以判断说CF节点可能会存在性能的瓶颈呢？

我们都知道一个系统的瓶颈无非是CPU，内存，磁盘I/O和网络I/O这四大方面。那我们就一一来分析CF可能会存在瓶颈的点：

(1)CPU

CF的用途仅仅是作为全局锁管理（GLM）和全局缓冲池管理（GPM）,为成员提供服务，服务是通过RDMA技术实现的，RDMA是内存与内存的直接交互，所以CF的CPU几乎不可能成为瓶颈。

(2)内存

因为只有节点更改过的数据才会被写入到CF中的全局缓冲池当中，而大部分节点还是在自己的缓冲池中缓存自己的数据，因此CF的全局缓冲池中只会保存一部分数据。 另外，通常而言一个典型的OLTP应用，全库的数据一般也就在几百G左右，经常要改动的数据量可能更小，而当前单台服务器的总内存越来越大，上百G甚至上T，内存价格也越来越便宜，所以对于OLTP数据库来说，只要初期规划合理，CF的缓冲池不大可能不够，因此CF的内存成为瓶颈可能性也是非常小的。

(3)磁盘I/O

对于CF来说就更不会成为瓶颈了。因为CF仅仅用于GLM和GPM，都存放在内存当中，CF根本就不会从磁盘中读写数据，磁盘I/O瓶颈也就无从谈起。另外，因为DB2 PureScale是基于Share Disk架构的，所有的member和CF都是共享存储（CF也可不共享GPFS），如果磁盘I/O成为瓶颈，那肯定是整个集群的GPFS I/O都是瓶颈，这时需考虑的只是成员的磁盘访问性能。

(4)网络I/O

先说TCP/IP网络，CF的TCP/IP网络只负责和集群中的其他节点做管理通信以满足集群软件管理上的需求，根本就不会处理来自成员和数据库客户端的TCP/IP请求，因此CF的TCP/IP网络永远不可能成为瓶颈；再说InfiniBand网络, CF和Member之间的数据通信主要通过InfiniBand网络。当成员数量增加，并发交易量增加的时候，CF和成员之间的InfiniBand网络带宽是关键点。首先现在InfiniBand网卡的传输速度是40Gb/s, 是万兆网的4倍。其次，CF节点支持多块InfiniBand卡，即使真的出现了InfiniBand网络带宽不足的问题，也可以通过给CF增加InfiniBand卡的办法来解决。所以InfiniBand网络成为瓶颈的可能性也不大。

综合以上的分析，DB2 PureScale是一款非常优秀的并行数据库产品，相较于OracleRAC，在以下几个方面，存在一定的优势：

（1）更好的性能伸缩

与Oracle RAC所不同的是，DB2 Purescale采用了CF来提供集中化的锁管理和全局缓存，而Oracle RAC采用的分布式锁管理和分布式缓存。

由于分布式管理，RAC随着集群节点的增多，在极端情况下（如多个节点同时修改在另外一个节点管理的缓存中的数据时），多节点间的的通讯协调复杂性将指数型增长，虽然Oracle也可以将InfiniBand应用于Oracle RAC集群的多节点通信，但是 Oracle RAC没有利用 RDMA技术，那么意味着 Oracle RAC节点通信将使用速度较慢的套接字协议，并且需要一些开销较大的 CPU 中断，这样会大大降低通信处理效率。

而DB2 Purescale，基于全局锁管理和全局缓存，所有成员节点都和CF单一通讯，为了获取CF中全局缓存数据，直接采用了RDMA内存复制技术，从而避免了高成本的进程间通讯。另外采用CF来管理全局锁和缓存，相对来说，简化了管理，因此DB2 Purescale能扩展到128节点，还保持着比较好的性能线性。

（2）更高的应用透明性

前面也说了，为了保持Oracle RAC的性能，通常是通过数据库分区的方式来避免热页面，通过业务分割的方式将不同的应用分布在不同的节点上的方式来减少缓存融合的频度。这样对应用来说，应用跑的Oracle节点固定化了，Oracle节点的伸缩，应用的配置也需要相应变更，所有这些都会造成管理和开发成本增加；而DB2 Purescale不需要通过应用或数据分区来实现可伸缩性，增加或减少成员节点时，不会让应用集群感知到，也无需对应用进行修改，同时这也极大地降低了管理和应用开发成本。

（3）更高的持续可用性

Oracle RAC的节点故障需要涉及四个步骤：故障检测、Remaster数据块、锁定需要恢复的页面和重做和撤销恢复。具体来说，在Oracle RAC中，每个数据页都由集群中的一个实例来管控。Oracle采用分布式的锁机制，因此集群中的每个实例都需要负责管理和批准对它所管理页的锁请求。

当某个节点出现故障时，首先，故障节点所管理的数据页将立即变为孤立的，直到RAC会通过重新分配流程将这些孤立页面的管控权分配给集群中健康的节点。在GRD（全局内存资源目录）重新配置的过程中，对页面的所有读取和锁请求都会被冻结。此时，它们不能执行任何I/O操作或请求任何新锁。

其次，锁定所有需要恢复的数据页面。这项任务必须在GRD冻结被释放之前完成。如果某个实例在获得适当的页解锁之前被允许读取磁盘中的页面，则故障实例的更新操作可能会丢失。恢复实例将读取故障实例的重做日志文件，并锁定任何需要恢复的页面。这可能需要大量随机的I/O操作，因为日志文件和需要恢复的页都可能不在任何健康节点的内存中。仅当恢复实例执行了所有这些I/O操作并锁定适当的页之后，GRD冻结才会被释放，停滞的应用才能继续运行。

相比之下，DB2 PureScale的设计初衷是最大限度地提高在故障恢复处理中的可用性，当数据库成员出现故障时，DB2 PureScale不需要在集群中进行全局冻结，只有动态数据仍然保持为锁定，直到成员恢复完成。因为CF在任何成员出现故障时始终知道哪些页面需要恢复。如果某个成员出现故障，集群中的所有其他成员可以继续处理事务和执行I/O操作。只有对需要恢复的页面的访问请求会在故障成员的恢复流程完成之前被阻塞。

另外故障恢复时，由于Oracle RAC是日志恢复，根据故障节点在出现故障时正在进行的工作量，整个恢复过程可能会花费几十秒到几分钟不等的时间；而DB2 pureScale是内存恢复，所以DB2 PureScale恢复时间比RAC短很多，动态数据在线恢复的目标时间小于20秒。

当然Oracle RAC也有自身强大之处，自从发布之后，Oracle RAC同时解决了客户对于性能扩展和高可靠性的要求，多年来没有匹配的对手，成熟度和稳定性高，功能强大，可运行的环境多样，兼容性强，架构相对简单等。

而DB2 PureScale也存在一定的不足和缺陷，如DB2 Purescale需要独立的两个CF节点资源；为了保证足够的性能，需要独立的InfiniBand卡和相应的交换机，并且目前只能通过GPFS才能实现磁盘共享，整体软硬件要求较高；整体架构的复杂度也较高；虽然说现在也可以运行在X86的Linux平台上，但对Linux平台操作系统版本的兼容性不够，更多的是定位于高端数据库，采用UNIX平台居多，而IBM的Power平台是Unix中的第一选择，存在一定的局限性；DB2 PureScale的CF重要性太高，即使DB2成员节点的数量很多，但CF故障一个就会造成一小段时间的中断，故障两个就会造成数据库集群全部中断。

好了，前面谈了很多，今天的话题是双活数据中心，那么DB2 PureScale的跨中心双活又是如何的呢？这里我们要谈到IBM GDPC（Geographically Dispersed DB2 PureScale Clusters）同城异地双活灾备解决方案---基于IBM DB2 PureScale技术实现地理跨越同城双活。

IBM GDPC是一种配置，允许分布式 DB2 pureScale 集群，从而可以使集群的成员位于不同站点。因此，我们将DB2 PureScale的成员和CF节点均分至两个站点SiteA和SiteB，并在站点SiteC也搭建一个仲裁节点，这样对于4节点成员和2节点CF的数据库集群来说，SiteA包含成员1和3，CF主，SiteB包含成员2和4，CF备，SiteC包含GPFS仲裁节点，所有成员节点和CF节点通过跨站点级联的SAN网络共享存储，并在存储之上建立GPFS，架构模式为NSD服务模式，SiteA存储与SiteB存储的数据通过网络实时同步。所有数据库日志文件和数据库文件均存放在GPFS上，实际上对于存储来说，两个站点各存放了一份数据。所有成员均通过Infiniband网络，利用RDMA技术访问SiteA的CF 主，最后两个站点的TCP/IP网络,Infiniband网络和SAN网络统一通过裸光纤级联。GDPC整体架构图如图所示：

另外提一点，由于DB2 PureScale应用透明度高，所以DB2 PureScale拉伸至GDPC架构后，跨中心的集群应用可以不需要做任何修改，只需要保持现状，由DB2客户端自动路由分发请求至两个站点的成员节点即可。

然而我们可能还会有这样一种需求，正常情况下，两个站点的应用节点只访问本站点的数据库成员节点，并且数据库成员节点只访问本站点的GPFS NSD存储，那么我们不但需要在DB2客户端（应用端）配置跨站点的冗余性，提供容错功能，还需要配置客户端亲缘关系与GDPC配合使用，并且两个站点的GPFS NSD盘的属性需要优先本地站点的成员节点。