超级可用性的定义

　　我至今还清楚地记得最近的一次由一名大型公司的高级 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 的相反过程中，所发生的事情是同样的)。