WebSphere 反向投资者: 高可用性（重申）与持续可用性

核心提示： 对于数据库更新，如果尝试更新一个仍在处理应用程序数据请求的单个数据库服务器，WebSphere 反向投资者: 高可用性（重申）与持续可用性(3)，其引入的操作复杂性类似于试图使用单个单元来满足 HA 或 CA 服务级别要求且同时应用硬件或软件维护，这就是为什么其他的管理工作（应该与运行两次 &m

对于数据库更新，如果尝试更新一个仍在处理应用程序数据请求的单个数据库服务器，其引入的操作复杂性类似于试图使用单个单元来满足 HA 或 CA 服务级别要求且同时应用硬件或软件维护。这就是为什么其他的管理工作（应该与运行两次 — 且每个单元各一次 — 相同的管理脚本一样简单）应该是造成简化操作过程这一结果的明显折中。

防止灾难性中断的保险

如果您无法为生产中的所有管理活动编写脚本，那么满足 HA 或 CA 服务级别几乎是不可能的。简单地说，WebSphere Application Server 管理控制台中的 “指向并单击” 不是一个可重复的进程，至少不足够重复以可靠地满足这些服务级别。我甚至知道有些用户为了确保为所有管理操作编写脚本而没有安装管理控制台。我并不建议您也到不安装管理控制台的程度，但我建议您开始使用 命令帮助 或 IBM Rational Automation Framework for WebSphere 以便为可重复的生产管理建立所需的脚本库。

对于生产环境中所有管理操作编写脚本是提供可重复过程的基础，这对于维护 HA 或 CA 环境是必要的，其更改可引起错误或其他灾难性结果。疲劳系统管理员的无意按键可能会导致文件系统中的文件被删除、整个应用程序被卸载或内存升级烧坏内部硬件。在运行高可用性站点时，您必须假设某一天单元内会发生一起灾难性事件。这就是独立单元的无价之处。如果单元中的变更没有按计划进行 — 该单元应该已经在预生产环境中进行了排练 — 则在对单元和问题的来源采取纠正措施时，其他单元可以继续服务生产。

与管理单独的单元和付出的额外努力有关，遇到这种使用磁盘复制来维护第二个单元（或站点）镜像的客户端的情况并不常见。如果您正在使用或仔细考虑这种方法，则要认真考虑在错误的情况下会发生什么（如同上面所描述的那样），以及使错误从您的生产单元（使之不再使用）自动复制到备用单元的影响。这并不是说我反对使用像磁盘复制那样的自动机制来从一个环境到另一个环境传播变更或数据 — 这项技术非常有用 — 而是要确保您在应用变更以前拥有文件系统备份或环境 “快照” 以便您在有问题的情况下有一个恢复点。我认为多次运行脚本是最简单的方法，因为它不仅可以维护一致的环境并且不需要付出过多的努力，但您可以决定带有备份的磁盘复制这种方法对您的环境更有效。重要的是，如果您依靠自动机制，为了以防万一，您需要确保有恢复计划可以终止在整个基础架构内传播问题。请记住磁盘复制通常是用于 创建与主站点事务性一致的灾难修复站点 的唯一可行的途径。因此，如果您既需要灾难恢复又需要这里描述的持续可用性，一个好的方法就是在一个数据中心中有两个单元，每一个都使用脚本管理，其中单元的内容（配置、日志、数据等）可复制到一个远程数据中心。

越多越好？

还有一个有关运行多个单元的问题，即两个单元足够了吗？提及这个的原因是 “规则 3”。基本上，如果您有其中任何两个（单元、服务、路由等），并且其中一个从服务（无论是进行维护还是破坏的结果）中被删除，则剩下的单个单元或组件现在就是单一故障点。此外，现在您是在一半的容量下运行。您需要仔细考虑需要多少冗余级别来满足企业的操作需求，或许需要为您的基础架构购买三个（或更多个）级别。显然对您可以获得的冗余数量会有限制；除了财务上的限制，还有面临的实际问题，即您不能拥有所有级别，您将把它放置到哪里？