评论专栏: Tom Alcott：欲言又止的 WebSphere Application Server 的相关问题，第 5 部分

欢迎回来

欢迎回来继续阅读本系列的第 5 部分，我将尝试回答不断被人问到的关于 WebSphere Application Server 的问题，或者如果答案不明确，我将提供相关信息来帮助您确定最适合您的情况的选择。

这次，我将讨论由于之前讨论的关于跨多个数据中心 WebSphere Application Server 计算单元的内容（即第 2 部分和第 3 部分中的内容）而带来的一个问题。这个问题就是：

问：我想要运行多个数据中心。是否应该跨这些数据中心部署 WebSphere Application Server，以获得高可用性？

答：对于新手，我对此问题的回答通常是“您不需要使用多个数据中心来获得高可用性，仅需要一个容量足够大的数据中心集合获得高可用性”。当然，对此的通常反应是类似于“但如果数据中心出问题了又会如何呢？”的问题。这正是我要的反应。那为什么我会这样呢？因为现在问题才算问对了，针对的是灾难恢复，而不是高可用性。进行这个讨论真的非常重要，因为这是两个差别很大的问题，答案自然也迥然不同。

此外，我还将假定您不会跨两个数据中心运行单个 WebSphere Application Server 计算单元，这种做法非常不好，不应该予以考虑，具体理由我已经在前面谈过了。

如果要使用多个数据中心，每个数据中心包含一个或多个 WebSphere Application Server 计算单元。首先让我们给出此类拓扑的常见选项：

• 主动/被动：一个数据中心处理请求，而另一个不执行相关工作，仅在需要时作为备用。应用程序数据和应用程序状态在数据中心之间进行异步复制，以在出现停机的情况下，在尽可能短的时间内快速完成到仍然存在的数据中心的故障转移（在此，尽可能短指数分钟甚至数小时）。

• 主动/主动：两个数据中心都在处理请求。由于每个数据中心都处于活动状态，因此必须在数据中心之间共享应用程序数据（尽可能少）和应用程序状态（可能），应用程序数据和应用程序状态的复制需要同步进行，延迟需要尽可能小，从而避免出现不一致的情况。

• 改良的 主动/主动：此变体与“主动/主动”方式的主要区别在于，数据中心之间不共享应用程序状态，而且在可能的情况下没有应用程序数据共享——或者如果不能完全避免，至少数据共享尽可能少。为此，需要提供请求与特定数据中心的关联性，而这最好通过负责将负载分布到数据中心的网络交换机（自然这意味着它不驻留在任何数据中心中）进行。

我将稍后进一步对此进行讨论，不过将在此说明此类选项的优缺点：

• “主动/被动”方案实现最为简单和安全，因为只有一个数据中心处理请求——但同时也是开销最大的方案，至少硬件方面如此，因为需要两个具有 100% 容量的数据中心。

• 改良的“主动/主动”方案比“主动/被动”方案略微复杂一些——但通过一些额外的工作，其工作更为可靠。

• “主动/主动”方案是实现方面最复杂的拓扑，需要在数据中心间合适的网络容量方面进行很大的投资，因为不仅需要尽可能减少延迟，而且还要提供足够的网络容量。

网络容量和延迟是影响数据中心故障转移设计的关键问题。为了更具体一些，让我们对这两个属性进行一下讨论：

• 网络延迟：当然可以在光纤网络方面进行投资，使延迟不再成为一道障碍。简单来说，光速为 300,000 公里/秒，因此这就是理论速度上限——但由于我们生活在现实世界中，因此需要考虑真正可以实现哪种类型的网络。光纤中的光速为 200,000 公里/秒。因此，对于在距离为 1000 公里的情况下所传输的数据，可能会有 5 毫秒的延迟（1000（公里）/200000（公里/秒）= 5 毫秒），而对于此距离的往返（应答与响应）的延迟将为 10 毫秒。研究表明 Internet 骨干网络的理论最佳往返延迟的系数为 2，因此对于两个数据中心的示例，1000 公里距离的延迟可能到达 20 毫秒。

  我要补充的是，我所说的延迟是可以验证的，只要在网络基础设施方面进行足够的投资即可。可以访问当前 AT&T Global IP Network 统计数据，以了解 WWW 骨干网络的延迟测定数据。（我最近某个下午查看此数据时，旧金山到西雅图（距离为 1090 公里）的延迟为 23 毫秒）。

• 网络容量：当然，延迟合理也仅是需要考虑的问题的一半，另外还需要有用足够的容量。在与客户的交流中，我听他们提到过数据中心之间的 OC-1 或 OC-3 连接；初看起来，很容易认为这就足够了，但让我们对其进行一下深入分析。

  OC-1 线路提供的最高传输速度为 51.84 Mbit/s，有效负载为 50.112 Mbit/s，而开销为 1.728 Mbit/s。（这是其他 OC-n 标准用于相乘的基准速度。例如，OC-3 连接的速率是 OC-1 速率的 3 倍。）相比之下，802.11g 无线连接上的最大数据速度为 54 Mbit/s。也就是说，通过无线连接到单台计算机的（理论）最大数据速率超过 OC-1 线路的速率。因此，除非仅在每个数据中心运行一台计算机，否则务必保证数据中心之间的网络具有足够的容量，以提供所需的数据同步级别。容量具体将取决于每个数据中心中的应用程序数据和应用程序状态的数据变化量（插入、更新和删除），以及两个数据中心之间的依赖关系级别。换种说法，数据中心之间的依赖关系（或数据和状态的共享）越强，所需的网络容量就越大。

  例如，我最近所接触的一个客户在数据中心之间使用 OC-3 连接，他们感觉到这应该足够了。不过，事实上他们每秒钟更新的应用程序状态数据超过 25 MB，而这在执行容量计算时就意味着在尝试传输超过容量 25% 的数据（应用程序更改的速度超过 200 Mbit/s，而网络仅具有约 153Mbit/s 的数据），而这仅仅是应用程序状态数据（例如，HTTP 会话）；另外还有数据库服务器中的应用程序数据需要传输。毫不意外，他们在尝试以“主动/主动”配置运行两个数据中心时遇到了延迟问题。客户有两个选项，要么投入大量资金升级网络容量，或停止以“主动/主动”方案运行数据中心。他们选择了后者。在继续之前，我希望再次强调，我并不赞同在计算单元之间共享 HTTP 会话，无论计算单元是否位于相同的数据中心都是如此。我之所以说“再次强调”，是因为我已经在第 2 部分对此进行了讨论。

更多问题

正如您现在可能已经猜到的，我并不赞同在“主动/主动”配置中尝试运行多个数据中心；不仅因为这样开销巨大，而且因为这也非常复杂。例如，如果跨计算单元共享会话，这意味着仅依赖于单个数据库服务器（或数据库服务器和故障转移服务器），或尝试在数据中心之间复制数据。因此，维护任何类型的数据库服务器都会导致跨两个计算单元停机（或者避免停机的步骤）。这就增加了复杂性。类似地，更新应用服务器运行时也会使计划和执行停机变得十分困难，因为软件更新（例如，对 WebSphere Application Server 的更新）会导致现有的数据库服务器版本不再受支持。另一方面，如果每个计算单元都是独立的（包括数据中心和数据库服务器间的计算单元），则可以按逐个计算单元（即 WebSphere Application Server 单元及其相关的基础设施）的方式维护和更新，一个计算单元停机不会影响另一个计算单元，它可以继续运行和处理请求。回到复杂性的问题，此基础设施越复杂，数据中心（或计算单元）之间的依赖关系越强，出现停机的可能性越大。也就是说，您所尝试避免的东西（停机）将更可能会出现。虽然这看起来有些自相矛盾，但这并非完全是意外。可靠性工程的基础理论是让事情更加简单，这绝非偶然；换句话说，事物越复杂，出现意外的可能性就越大！

为了避免停机，或至少避免长时间停机，我的建议是依赖于“主动/被动”双数据中心配置。之所以提出这个建议，不仅是因为上面所提到的复杂性，而且还因为我们认识到了计划外停机或数据中心丢失或灾难事件是非常罕见的情况，服务的中断是最终可以接受的（甚至大多数要求极高的客户都能够接受）。对于任何此类事件的事后分析，数据中心之间不共享应用程序状态（如 HTTP 会话）因而客户必须重新登录这一事实并不在优先表中靠前的位置。我给客户的建议是，从最终用户的角度而言，最好能够容忍相对较少数量的停机；通过在数据中心或计算单元之间添加依赖关系（如共享应用程序状态）来消除这些停机情况，可能会增加复杂性，从而导致服务中断出现的频率实际呈上升趋势。另外还需要有这样的认识，存在短时间的意外停机比在由于没有考虑到可能会实际出现的问题而尝试和处理无限期的计划外停机要好得多。

首选的选项？

当然，还要考虑采用“主动/被动”方案意味着将大量的处理容量闲置“无所事事”，这与管理层的看法往往不合拍。如果是这样，那么我建议您考虑“主动/主动”方案的变体，即我所称的“改良的主动/主动”方案。

这样，从容量的角度而言，两个数据中心都得到了利用。不过在出现计划外停机（即“灾难”）时，将会在用户失败并尝试重新连接（将隐式地转移到第二个数据中心）时丢失服务。是的，这还意味着由于未共享应用程序状态，客户将必须重新登录——但由于刚刚出现了“灾难”，因此必须手动重新登录并不具有最高的优先级。还有一个事实，即应用程序状态具有瞬时性，因此不应该将此数据的丢失视为关键事件，而且能够使用一些应用程序技术来尽可能减少此类数据丢失，如通过 URL 重写或通过 smart serialization 来维护应用程序状态。需要处理的一个更为重要的问题是，一个数据中心丧失服务功能的情况下丢失系统容量 50% 所带来的影响。这可能意味着一些略微次要的应用程序以降级模式运行（或许根本不运行）。由于务必保证关键应用程序继续工作，以提供业务连续性——而此时通常并不需要所有应用程序都具有“连续可用性”——因此必须对应用程序进行归类，以针对这种情况做好准备。

问：在不可能出现的真正灾难中，什么最重要？

答：对于此讨论，我假定了答案是“业务连续性”，而且您根本完全不会受到丢失一些应用程序会话的影响。不过，如果您非常关心丢失的应用程序会话，则可能会不恰当地使用应用程序状态（例如，HTTP 会话）。也就是说，如果状态可靠性非常高，应该使用相应的持久性机制，如 JDBC。

问：如果在进行灾难恢复，为了保持业务正常，所需要的正常操作容量的百分比为多少？

答：如果答案是 100%，则需要两个数据中心，每个都具有完全的可用容量，因此绝对不能使用“主动/被动”方案之外的方案。如果您承担不起提供两个冗余数据中心的开销，仅能勉强提供 50% 的容量，则在日常业务操作中采用的是“主动/主动”拓扑，那问题就变成了应该共享什么，如何共享？这里，让人感到欣慰的答案是只共享应用程序数据库，通过使用数据库工具共享，而不是会话状态，而且所有用户固定连接到一个（且仅一个）数据中心——灾难恢复期间例外。

被问到这个问题时，我的标准建议是，组织不要采用使用双（或多）数据中心的“主动/主动”配置，而要将重点放在提高每个数据中心内的可靠性上，并减少采用“主动/被动”（或“改良的主动/主动”）配置运行的数据中心之间的故障转移恢复时间。这是我要采用的方法，之所以如此建议，是因为我遇到了一次灾难（地震）而导致数据中心停止工作。在确信无疑的情况下，我们大家都认为大楼并不会立即考虑用户必须重新登录的问题。当然，并不一定都是像地震这样具有破坏性的事情让数据中心停止工作，因为路由器出错之类的小问题都可能带来这样的后果，我也知道出现过多次这样的情况。

可能会由于一些内部原因而需要尝试“主动/主动”配置；希望这不是因为在当前的单个数据中心或多个独立数据中心遇到了停机情况而做出的决定。如果要采用此配置，正如前面讨论的原因，在数据中心之间增加依赖关系无疑将提高可用性。我对此的建议是，投入精力消除当前停机故障的根源，而不是增加停机故障的其他潜在原因。

我知道，过去的这些 FAQ 专栏讨论了有关不同主题的多个问题，而这仅涉及一个主题（这个主题至少我已经讨论了两次了），但我希望这个非常受关注的主题涵盖的内容非常广泛，不会让您感到上了大当。