jxnxsdengyu
作者jxnxsdengyu2017-04-25 09:21
系统工程师, 江西农信

双活数据中心建设系列之--- 基于软件架构的双活数据中心建设方案深入探讨(并行DB2部分)

字数 5625阅读 3710评论 2赞 7

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的整体系统架构图:
purescale2.jpg

purescale2.jpg

purescale1.jpg
purescale1.jpg

从图中可以看出,一套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秒。
DB2_PURESCALE1.JPG
DB2_PURESCALE1.JPG

DB2_PURESCALE2.JPG
DB2_PURESCALE2.JPG

当然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整体架构图如图所示:
GDPC.JPG
GDPC.JPG

另外提一点,由于DB2 PureScale应用透明度高,所以DB2 PureScale拉伸至GDPC架构后,跨中心的集群应用可以不需要做任何修改,只需要保持现状,由DB2客户端自动路由分发请求至两个站点的成员节点即可。然而我们可能还会有这样一种需求,正常情况下,两个站点的应用节点只访问本站点的数据库成员节点,并且数据库成员节点只访问本站点的GPFS NSD存储,那么我们不但需要在DB2客户端(应用端)配置跨站点的冗余性,提供容错功能,还需要配置客户端亲缘关系与GDPC配合使用,并且两个站点的GPFS NSD盘的属性需要优先本地站点的成员节点。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

7

添加新评论2 条评论

wuwenpinwuwenpin软件开发工程师, 南京
2018-09-13 18:49
不错的资料
sharkbingsharkbing研发工程师, EDI
2018-09-08 23:06
不错
Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广