简介： 高可用性和持续可用性通常作为同义词使用，但两者实际上是有所不同的，虽然提供其中一种或这两种服务级别的基础架构通常均依赖于多个冗余的 IBM WebSphere 应用服务器网络部署（IBM WebSphere Application Server Network Deployment）单元。 本文来自于 IBM WebSphere Developer Technical Journal 中文版。
在每一篇专栏文章中，“WebSphere® 反向投资者” 均会回答问题、提供指导或者讨论有关使用 WebSphere 产品的基础专题，通常还会给出与主流观点相反但却已被证实的建议。
虽然我从未发现有关高可用性或灾难恢复的问题出现短缺，但 上一期 WebSphere 反向投资者（处理 WebSphere Application Server 管理高可用性选项）提示最近这些问题的数量似乎有所增加。因此，在这里我将继续高可用性这一主题，另外会添加一些有关如何获得高可用性（HA）和持续可用性（CA）的想法。但在我们开始讨论这些话题以前，先让我们确保大家对以下两个术语达成共识：
- 高可用性：基础架构（或在其上运行的应用程序）不可以承受一次超过几秒钟或几分钟的计划外中断，但这样做可能并不会对企业的业务产生严重的影响。此外，偶尔终止应用程序几个小时以进行有计划的维护是可以接受的。
- 连续可用性：基础架构（或在其上运行的应用程序）根本不可以中断。基本上，无论计划外的还是计划内的中断都没有任何中断补偿。这种可用性级别通常被称为 “五个 9” 或 99.999% 可用性，即可以理解为每年计划内和计划外的中断总共刚刚超过 5 分钟。
要补充说明的是，很多情况下有些人将声称他们 “只” 需要 “四个 9”（99.99%）的可用性或一个类似的数字，以为这样的可用性会被归类为 HA，实际上在一年的期间内 99.99% 和 99.999% 可用性之间并没有任何有意义的区别。如果您进行一下数学计算，您将发现 99.99% 可用性的情况下每年仍然需要总共刚刚超过 5 小时的中断；换个方式说，您不可能再容忍计划外中断超过 99.999% 可用性的情况，同样您也不可能进行计划内中断的补偿。
在这里我不再描述运行 WebSphere Application Server Network Deployment 时的具体操作过程，因为这些在 这本书 和 这篇文章 中已经进行了记录。阅读完其中一篇或这两篇参考资料后，明显就会了解通过认真管理好的过程和详细的计划，单个 Network Deployment 单元也可以提供 HA。而且，双单元会稍微增加管理工作（因为您需要管理两个单元），借助这些优势，无论是 HA 或 CA 环境，从操作的角度看其管理的复杂性都将大为简化。
有两个（或更多个）单元时无需单独的硬件 — 您可以借助 共存 功能在同一硬件上运行多个单元 — 这可以更好地将硬件充分用于每一个单元。这是因为，如果每个单元都有单独的硬件，就会在单元之间提供完整的硬件和网络隔离。如果一个单元内的服务器、服务器框架、路由或其他设备变得无法操作，硬件的隔离会确保这种情况不会影响到其他单元。这样，具有故障设备的单元会被脱机，而生产将由剩余的单元提供服务。对故障设备的任何修复工作都不会影响其他单元，而且一旦修复完成，即可独立进行测试而不影响生产。多个单元（其中每个单元都有单独的硬件）还可以提供一种方法进行硬件升级。这是因为当服务器或服务器框架交换出时，可以将一个单元旋转出生产而通过其他单元来处理负载，从而进行内存和 CPU 升级。同修复的情况一样，一旦升级完成，即可进行软硬件合并测试，如果升级过程中出现某些问题并导致硬件故障，也不会给任何用户带来负面影响。
在有多个单元的情况下，通过将一个单元旋转出生产这一功能，能够将维护软件（例如，修订包、补丁等）应用于操作系统、基础架构中间件或应用程序本身。一旦升级完成，即可进行软硬件合并测试，如果升级过程中出现某些问题，也不会给任何用户带来负面影响。
很明显，如果应用程序升级需要对共享数据库架构进行相应地更改，这种情况会变得更加复杂。当对这种类型的升级使用多个单元时，需要考虑其他数据库更新策略，因为在生产中运行的单元将不会识别新的数据库架构。
对于数据库更新，如果尝试更新一个仍在处理应用程序数据请求的单个数据库服务器，其引入的操作复杂性类似于试图使用单个单元来满足 HA 或 CA 服务级别要求且同时应用硬件或软件维护。这就是为什么其他的管理工作（应该与运行两次 — 且每个单元各一次 — 相同的管理脚本一样简单）应该是造成简化操作过程这一结果的明显折中。
对于生产环境中所有管理操作编写脚本是提供可重复过程的基础，这对于维护 HA 或 CA 环境是必要的，其更改可引起错误或其他灾难性结果。疲劳系统管理员的无意按键可能会导致文件系统中的文件被删除、整个应用程序被卸载或内存升级烧坏内部硬件。在运行高可用性站点时，您必须假设某一天单元内会发生一起灾难性事件。这就是独立单元的无价之处。如果单元中的变更没有按计划进行 — 该单元应该已经在预生产环境中进行了排练 — 则在对单元和问题的来源采取纠正措施时，其他单元可以继续服务生产。
与管理单独的单元和付出的额外努力有关，遇到这种使用磁盘复制来维护第二个单元（或站点）镜像的客户端的情况并不常见。如果您正在使用或仔细考虑这种方法，则要认真考虑在错误的情况下会发生什么（如同上面所描述的那样），以及使错误从您的生产单元（使之不再使用）自动复制到备用单元的影响。这并不是说我反对使用像磁盘复制那样的自动机制来从一个环境到另一个环境传播变更或数据 — 这项技术非常有用 — 而是要确保您在应用变更以前拥有文件系统备份或环境 “快照” 以便您在有问题的情况下有一个恢复点。我认为多次运行脚本是最简单的方法，因为它不仅可以维护一致的环境并且不需要付出过多的努力，但您可以决定带有备份的磁盘复制这种方法对您的环境更有效。重要的是，如果您依靠自动机制，为了以防万一，您需要确保有恢复计划可以终止在整个基础架构内传播问题。请记住磁盘复制通常是用于 创建与主站点事务性一致的灾难修复站点 的唯一可行的途径。因此，如果您既需要灾难恢复又需要这里描述的持续可用性，一个好的方法就是在一个数据中心中有两个单元，每一个都使用脚本管理，其中单元的内容（配置、日志、数据等）可复制到一个远程数据中心。
还有一个有关运行多个单元的问题，即两个单元足够了吗？提及这个的原因是 “规则 3”。基本上，如果您有其中任何两个（单元、服务、路由等），并且其中一个从服务（无论是进行维护还是破坏的结果）中被删除，则剩下的单个单元或组件现在就是单一故障点。此外，现在您是在一半的容量下运行。您需要仔细考虑需要多少冗余级别来满足企业的操作需求，或许需要为您的基础架构购买三个（或更多个）级别。显然对您可以获得的冗余数量会有限制；除了财务上的限制，还有面临的实际问题，即您不能拥有所有级别，您将把它放置到哪里？
http://www.ibm.com/developerworks/cn/websphere/techjournal/1004_webcon/1004_webcon.html
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-669863/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-669863/
3167
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
