DB2管理：超级可用性

之前为大家介绍了DB2开发经验小结，本文主要为大家介绍DB2管理之超级可用性。　

超级可用性的定义

　　我至今还清楚地记得最近的一次由一名大型公司的高级 IT 专家和几名 DB2 DBA 及系统程序员参加的工作会议。会议的讨论主题是战略可用性，即，长期战略和规划，它与公司核心业务应用程序的服务交付紧密相关。我们请这位专家为我们解释开发战略可用性计划需要围绕的目标。他的回答是：

“永不宕机，永不丢失任何东西”

　　这寥寥几个字与商业理论家 Jim Collins(Built to Last and Good to Great的作者)称为 BHAG(Big Hairy Audacious Goal，发音为“bee-hag”)的思想不谋而合。BHAG 倡导大胆的前瞻性思维。(我的一位朋友曾这样反向解释过 BHAG 式思维：“如果目标定得低，所获得的成就也就如此。”)

让我们来剖析一下这个可用性目标

永不宕机

　　首先，很有必要理解“永不宕机”的含义(即我对它的理解以及前面提及的那位IT专家对其含义的定义)。它不是指以某段时间内消逝时间的百分比所表示的数据库或应用服务器的正常运行时间。不要曲解我的意思，设定和争取最佳正常运行时间的目标(比如，99.9%的可用性)很有用，尤其是对于负责应用程序基础架构的那些人(即系统管理员)而言更是如此。然而，从业务角度考虑，更重要的可用性度量手段是故障客户交互数(FCI)。这是一个重要的区分指标。请考虑如下的两个场景：

　　场景 1：公司 A 的 IT 部门经理正兴高采烈地庆祝工作成绩：过去1个月内可用性指标达到了99.95%。不料，负责客户 B 的客户关系经理忽然通知 IT 部门说公司 B 不大满意，原因是上星期发到公司A进行处理的事务中竟有很大一部分都没有被妥善执行。这是怎么回事呢?实际上这不是很难理解。有可能是处理公司 B 请求的某个基础架构组件(比如应用服务器)一时出了故障;当然，这对于有数百个服务器的系统而言还不足以伤及可用性指标，但却足以招致公司 B 的抱怨之声。另一种可能性是由公司 A 负责系统的团队没有注意到的某个应用的程序逻辑错误恰好影响到公司 B 发来的事务处理。

　　场景 2：一星期之后，公司 A 的一名 DB2 DBA Julie 遇到了棘手的事情——Linux 服务器上的一个 DB2 实例受到了宕机的影响。这个DB2 实例是 HADR(High Availability Disaster Recovery)配置的一部分(HADR 是我在“DB2 Disaster Recovery, Part 2”中所描述的一个 DB2 for LUW 特性)。受影响的这个实例在20秒后再度处理请求，但从达到本月的可用性目标而论，这20秒没有任何帮助。负责客户 B 的关系经理恰巧路过，Julie 本准备好了要应对这场免不了的口舌之争。但没想到关系经理却称赞她杰出的工作表现：公司 B 的事务没有出任何故障(事务超时值是30秒)。

　　因此，“永不宕机”真正的含义是“无 FCI”，而不是“无服务器宕机时间”。这无疑是件好事：允许存在某些不足以引起 FCI 的短暂的服务器宕机。这就意味着为了将DB2 for LUW维护应用于维护窗口之外而发起的 HADR 故障转移这样的动作与“永不宕机”的可用性目标没有任何矛盾(DB2 for z/OS 数据共享也允许应用程序维护应用于维护窗口之外，正如在参考资料部分列出的我的“DB2 Disaster Recovery”DB2 DBA 专栏中所描述的那样)。

　　不太好的消息是：高级 IT 专家并没有界定是“由于本地故障而引起的永不宕机”，他只说了“永不宕机”。这就表示 IT 部门不能对因灾难(洪水、火灾、地震、龙卷风)致使整个数据中心瘫痪后所需进行的应用程序服务恢复袖手旁观。

　　现在，已经有很多很棒的技术，可用来显著减少当主站点发生灾难时让应用程序系统在备用站点恢复运行所需的时间，其中最棒的要数基于磁盘阵列的数据复制。而且还有一些编程实践(比如，频繁提交)和 DB2 参数设置(比如检查点频率)可以使用，但是在数据中心范围的故障发生之后恢复系统而同时又要让用户感觉不到任何宕机时间，即使是做到天衣无缝，这个目标看上去也很难实现。

　　想想看：在主站点发生灾难的30分钟内让应用程序在备用站点就绪对 IT 部门来说，已经很不容易了，但30 分钟根本算不上是“永不宕机”。怎么办?如何能让系统恢复时间压缩到最可能短的数值?您不妨换个角度想想，解决方案就会很明显。

永不恢复

　　很明显：要想最大限度地加快灾难恢复，就是不恢复。最快的恢复就是不恢复。这怎么可能呢?一方面，请不要想着所谓的“系统恢复”，与之相反，要开始转而想想“应用程序服务恢复”。我推崇的策略是：在站点 A 和 B 运行应用程序的一个完整实例(包括数据库)，业务流量在这两个站点间分割。如果站点 A 无效，不要试图在站点 B 恢复应用程序系统A，相反，而是要将定向到站点 A 的作业路由到站点 B。

　　很简单，对吧?我知道实现上述方案绝非轻而易举。成功的前提是要让这两个完整但却地理位置各异的应用程序数据库的实例相互同步(或者近似同步)。我本人很钟爱基于磁盘阵列的数据复制，但那(至少，只其本身)并不是一种很好的数据库同步策略。在这种情况下，基于硬件的复制的主要问题在于远端站点的目标磁盘卷在被用于复制时不能被远端站点的服务器使用。换言之，在站点 B，既有用于应用程序的“活动”数据库卷，也有复制在站点A所做的数据库更改所需的卷——基于磁盘阵列的复制并不能导致在站点 A 所做的更改能够反应到站点 B 的“活动”数据库卷。如果站点 A 失陷，可以人为地让站点 B 的目标复制卷可被站点 B 所用，但为了实用的目的，只有当站点A 的 DB2 实例要在站点 B 恢复的时候，这些卷才可用。而这并不是我们所想要的，因为我们的目标是为受站点 A 失陷影响的客户机恢复应用程序服务，而同时又无需在站点 B 执行 DB2 恢复操作。

　　所以，如果出于数据库同步的考虑而把基于磁盘阵列的复制置于考虑之外(即便该技术对于复制某些非数据库文件十分有效)，那么我们应该考虑使用什么技术呢?我的选择是基于软件的复制方案。这些工具(来自多个供应商，包括 IBM)中最为复杂的部分是 与 DB2 事务日志管理器的接口以便识别在站点 A 的数据库更改并将这些更改传递到站点 B(复制过程的“捕获”块)。在站点 B，复制软件产品的“应用”块将会使用 DB2 SQL 接口来在站点 B 的数据库反应对站点 A 的数据库所做的更改(在将站点 B 的数据库更改传递到站点 A 的相反过程中，所发生的事情是同样的)。

　　这个本来很有效的方案中也有不如人意之处：在站点 A 和 B 间发生的双向的数据库更改复制在本质上是异步的，因为基于软件的数据复制工具要等待一个 DB2 COMMIT 以便在将相关的数据库更改传递到远端站点之前在一个站点先流动。这意味着应用程序数据库的两个实例将不会精确同步。实际上，它们只会近似同步，在一个站点提交数据库更改和将更改应用到另一个站点之间有轻微的延迟(可能只有少数几秒)。

　　但，这已经相当不错了，不是么?在发生数据中心级别的故障时能获得如此超级迅速的服务恢复，而且只有几秒钟的数据更改丢失?还有什么更高的希求呢?但除了“永不宕机”之外，还有另一个高要求，即“永不丢失任何东西”。

目标更加严格

　　当我提到的这个 IT 专家给出了“永不宕机，永不丢失任何东西”的目标时，我笑着对他说：“您的意思是说永不丢失任何提交了的数据库更改，是吧?故障发生时正在进行中的与事务相关的数据库更改则会丢失，对吧?”专家笑着回答我说：“不是。我的意思是我们永不丢失任何东西，即使是只完成一部分的事务。”

　　同屋的这些人不禁说到(或想到)：“这不可能。”但我们决定还是试着去相信有这个可能。若真的能找到这样一个解决方案——它能让用户在即使故障发生时事务尚在执行中的情况下也觉察不到系统故障——又该如何呢?这样的一种解决方案该是何模样呢?

　　我脑海中不禁浮现了这样的答案：将所有事务的输入(“输入”指的是所请求的应用程序服务、参数值，比如帐号或订单号等等)都发送到两个站点，但在站点 A 只“播放”与路由到站点 A 的用户相关的那些输入(对于路由到站点 B 的那些用户将会在站点 B 进行同样的处理)。

　　现在，就是问题的技巧所在。不好!发生了一个重大的故障事件，站点 A 失效。一旦确认了站点失效(我希望是在数秒之内)，就会启动站点 B 接管通常路由到站点 A 的流量的过程。该过程将实行如下目标：

　　1. 所有流向站点 B 的事务都(指的是所有的事务，因为站点 A 离线了)暂时悬起。

　　2. 提交到站点 A 而没有在站点 B 应用的数据库更改都应用到站点 B(还记得前面提到过，由于 DB2 事务日志驱动的数据复制工具的异步特性，这两个数据库将会相互有些不同步)。为何如此呢?这是因为数据复制工具都会具有其自己的日志文件，而这些文件可以通过基于磁盘阵列的复制而在备用站点同步复制(虽然这只在两个站点间使用光纤连接的距离在20至30英里内才可行)。理想情况下，在站点 B 安装的复制工具可以读取在站点 A 安装的工具的日志文件副本(一旦人为让相关卷对站点 B 的服务器可用)并使用那些信息来消除站点 A 和站点 B 应用程序数据库实例间的时间间隙。[嘿，复制工具提供商，这可能是您的一个市场商机!]

　　3. 现在，处理当站点 A 离线时还尚在处理中的那些事务。我的想法是每个在站点 A 处理的事务都会在事务执行开始时被分配给一个惟一的标识符。如果这个标识符是一个基于事务输入(正如前面所述，这些输入发送到两个站点)的哈希值，那么只要两个站点使用相同的哈希算法，站点 B 的每个事务都会具有标识符，根本无需复制。当某个事务在站点 A 完成执行时，就会给此事务设一个“完成”指示，而这个完成/未完成文件也会同步复制(很可能是通过基于阵列的复制)到站点 B。在站点 B，路由到站点 A 的事务的那些标识符会与由站点 A 复制过来的“完成/未完成”值相比较。如果在站点 A 接收到的事务还没有在站点 A 完成，相关的事务输入(该输入还是要发送到两个站点)就会在站点 B“播放”，而结果则会发送回提交用户(或提交应用程序过程)。

　　4. 释放悬起的事务(参见步骤 1)以便执行，恢复正常的处理。

　　很容易，是不是?开个玩笑。我知道这个方案相当复杂，而且可能还需要一定的用户编程才能让其工作。但是我相信，这种“永不丢失任何东西”的解决方案(以及“永不宕机”的特性)是可以设计出来并实现的(实际上，类似的计划就构成了这个专家的永不宕机/永不丢失任何东西的解决方案的基础)。诸位尽可以大胆前行。超级可用性是可以实现的。

　　最后说一句：请不要试图逃避您公司与 IT 相关的 BHAG。如果贵公司还没有这类东西，就请奋力争取。不管何种情况，都请您务必参与其中。它们会让您发挥出自己的最大潜能，努力创造自己的一片天地，相信您的明天一定会是非常辉煌的。

文章名称：DB2管理：超级可用性
网页URL：http://www.shufengxianlan.com/qtweb/news19/324769.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联