日期:2014-05-16 浏览次数:20626 次
简介: ?通过提供无限的容量、持续的可用性和应用程序透明性,DB2 pureScale 降低了业务增长的风险和成本。DB2 pureScale on IBM Power Systems 融合了 PowerHA pureScale 技术,在 UNIX 或 x86 系统上交付了无与伦比的数据库可伸缩性和可用性水平。该产品是无可争议的总体系统可用性、可伸缩性、安全性和可靠性领先产品 DB2 for z/OS and System z 的有力补充。
?
在经济复苏的过程中,对核心业务数据的即时访问始终是企业赖以生存,乃至获得成功的关键因素。随着越来越多的美元流入国内市场,企业需要借助具备高可用性和适用性的基础设施来提高自己的敏捷性,以便能够抓住新的发展机会。
大多数分布式软件公司在营销时都将可用性水平与“类大型机”或“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 提供了相同的集中化资源管理,因此也解决了这些复杂的可伸缩性和可用性问题。本文将在稍后讨论这方面的内容。
最根本的问