WebSphere Application Server 常见问题及解答(五)

集群

1. 规划集群方案时应考虑哪些因素？
2. 在异构平台上创建 WAS V6.1 集群，避免使用绝对路径。
3. 在设计和开发运行于 WAS 集群环境的应用程序时需要考虑哪些方面？
4. 在集群环境中，我应该使用数据库持久化的方式还是使用内存到内存复制的方式来进行会话故障转移？
5. 什么是单元（Cell）？什么是节点（Node）？Node、Profile 与 Server 之间的关系是什么？
6. 我可以在多个数据中心上运行 WebSphere Application Server 单元吗？ 



1. 规划集群方案时应考虑哪些因素？

答：
在规划高可用的集群方案时，我们建议按以下因素规划和评估：

1. 分析需求：

·         是否需要持续运转？大多数用户不需要持续运转，硬软件升级可以脱机完成；

·         运转时需要哪种可用性？

·         故障恢复时对性能有什么要求？例如，一个node/server故障时，性能可能会受到影响；

2. 分析成本：

·         如果系统不可用，损失是多少？

·         您准备向可用性投入多少？

3. 评估配置管理的复杂性：系统越复杂，越需要更高的技术人员技能和配置管理成本。

4. 考虑整个系统里各组件的可用性：通常，整体可用性由系统中最弱的点决定。

5. 分析故障恢复时间：主要是故障探测时间和恢复时间。对于不同的技术，故障恢复的时间也是不同的。

6. 分析故障恢复的关键点：这直接关系到工作量和成本。

7. 理解编程模型：这关系到故障恢复对客户端和其他组件是否是透明的。如果部分组件不是透明的，必要时需要添加额外的处理。

8. 考虑故障影响范围：一些系统可能有一些特别的约束。故障发生时，可能有其他的系统受到影响。



2. 在异构平台上创建 WAS V6.1 集群，避免使用绝对路径。

答：
在异构平台上创建 WebSphere Application Server V6.1 集群，最主要的问题是异构操作系统的目录格式不同，产品的缺省安装目录也不同。为了避免因目录和目录格式的不相同所带来的影响，在资源配置和应用部署中，应当避免使用绝对路径，而采用通用的节点作用域 WebSphere 变量来替代，然后根据每个节点的实际情况来对该变量赋值。



3. 在设计和开发运行于 WAS 集群环境的应用程序时需要考虑哪些方面？

答：
在面向集群环境的应用程序中，需要考虑的方面主要包括文件同步，会话管理和动态缓存等。

·         文件同步
如果应用程序使用了存储于文件系统的数据，那么应当保证它们在每个集群服务器中的一致。一个可行的解决方案是使用共享的文件系统或共享的数据库，然而这种方法会导致一个新的单点故障和性能的瓶颈，并且可能会增加编程和配置工作的复杂性。另外一种方法是使用WAS所支持的细粒度文件更新，您可以在集群范围内拥有更灵活的应用程序文件，并避免引入新的单点故障。
关于细粒度文件更新的更多内容，请参见WAS V6.1信息中心： http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp

·         会话管理
会话管理是 Web 应用程序的一个重要的考虑事项。WAS为集群环境下的应用程序提供了实时一致的会话数据共享机制，提供包括基于内存拷贝的共享和基于数据库的共享方式。从应用程序设计的开发的角度，您应该考虑进行对象序列化和反序列化，以便将其放入会话中并在集群范围内进行共享。您可以使用自已定义的类将对象封装到会话中，然后执行验证。会话的复制是一个开销比较大的过程。因此，为了保证性能，您需要尽量降低会话对象的大小，从而提高复制时的效率。

·         动态缓存
您可以通过使用WAS提供的动态缓存和数据复制服务来实现集群范围内应用程序数据的共享，这将显著地提高应用程序的性能。


关于动态缓存的更多内容，可参见WAS V6.1信息中心： http://publib.boulder.ibm.com/in ... n_dynamiccache.html



4. 在集群环境中，我应该使用数据库持久化的方式还是使用内存到内存复制的方式来进行会话故障转移？
答：
数据库持久化和内存到内存复制之间的性能差异并不大。这是因为 95% 的复制或持久化会话开销是在会话对象的序列化/反序列化中产生的——不论会话保存在哪里，这种开销都必定会产生。  决定选择哪种技术将部分基于这两种技术之间的差异：

·         通过使用数据库，您实际上持久化了数据（保存到磁盘中），这样高可用性的数据库服务器就可以在级联故障中幸免于难，而内存复制的方式无法达到此目的。

·         对于两个相同的单元/域，高可用性的数据库完全可以确保两个域之间的会话故障转移，而对于内存到内存复制，两个单元只能有一个通用复制器；因此，它就变为单点故障（Single Point Of Failure，SPOF）。

因此，对于必须进行交叉单元会话故障转移的配置，只能选择高可用性数据库来消除 SPOF。请注意，此时跨单元共享会话是得到支持的，但不建议这样做，因为在单元间共享状态将使得在两个单元中独立升级组件（应用程序和 WAS）异常困难。  另外，利用内存到内存复制，您可以存储的会话信息的数量受应用服务器的 JVM 堆大小的限制。即使在 WebSphere Application Server V6.01 中支持 64 位的 JVM，最大应用服务器堆大小也大大小于数据库服务器（用作会话存储）上可用的磁盘空间数量。因此，尽管在许多组织中，使用内存到内存复制对避免系统管理员和数据库管理员之间的角色和职责冲突更有利，但数据库持久化仍是最佳选择。  有关会话、状态复制的更多资源，请参阅 developerWorks 中国站点的文章《Java 理论与实践：Web 层的状态复制》。



5. 什么是单元（Cell）？什么是节点（Node）？Node、Profile 与 Server 之间的关系是什么？

答：

单元：
单元是整个分布式网络中一个或多个节点的逻辑分组。单元是一个配置概念，是管理员将节点间逻辑关联起来的实现方法。管理员根据具体的业务环境，制定对其整体系统集成环境有意义的条件来定义和组织构成单元的节点。就一般情况来说，可以将单元看作是最大的作用域。

在 IBM WAS ND 产品中，管理配置数据都存储在 XML 文件中。单元保留了它每个节点中每台服务器的主配置文件。同时每个节点和服务器也有其自己的本地配置文件。如果服务器已经属于单元，则对于本地节点或服务器配置文件的更改都是临时的，通过在本地提交更改生效时，本地更改覆盖单元配置，但是当执行单元配置文档同步到节点的操作时，在单元级别上对主控服务器和主节点配置文件所作的更改将会替换对该节点所作的任何临时更改。


节点：

节点是受管服务器（Server）的逻辑分组。节点通常与具有唯一 IP 主机地址的逻辑或物理计算机系统对应，节点不能跨多台计算机。节点分为受管节点与非受管节点。

关于 Node、Profile 与 Server:

这三个概念比较容易混淆，我们拿出来对比说明：Node=Profile。Node 是管理上使用的概念，Profile 是实际的概要文件，它们代表同一事物。Server 就是所谓的 Application Server Instance , 这是我们实际要布署 Application 的地方。在IBM WAS ND 产品中受管节点的 Node Agent 目的就是让 Deployment Manager Server 可以透过 Node Agent 来管 Node (Profile) 中的 Application Server Instance，一个 Node (Profile) 中可以有多个 Application Server Instance。

如果是非 ND 版本 , 则属于 Single Server 版本，那么一个 Node (Profile) 中只能有一个 Application Server Instance，如果你希望在一台机器上有多个 Application Server Instance，那就只能透过创建多个 Profile (Node) 来达成，但这些 Node (Porfile) 彼此独立没有管理上的关系 (RelationShip)，只要使用的 TCP/IP Port 不要冲突即可。  有关分布式网络环境中相关概念的更多资源，请参阅 developerWorks 中国站点的文章《IBM WAS ND 分布式网络环境的理解与集群的实现》。



6.我可以在多个数据中心上运行 WebSphere Application Server 单元吗？

答：
是的。但也许这样做是不明智的。

首先，让我们看一下最明显的问题：数据中心之间的网速和可靠性。在许多情况下，WAN 的性能和可靠性不如 LAN，虽然有些环境下 WAN 非常可靠而且能提供 LAN 带宽；在这种情况下，对于应用程序（例如 WebSphere Application Server）来说，WAN 与 LAN 是一样的。所以简单的回答是：当然，请继续这样做，如果您有一个又快又可靠的 WAN。然而，一个更重要的问题被忽视了：为什么有多个数据中心呢？通常，您这样做是为了提高可靠性，因此如果一个数据中心全部失败或丢失（换句话说，一个真正的“灾难”），则您想让其余的数据中心能处理工作而不会有很大问题。考虑到这一点，人们需要为时间不短的数据中心停机作好计划，因此，这种状态下的可靠性将会变得非常重要。另外，这种情况下的故障转移要正确测试可能非常困难，因为这是在“正常的”WebSphere Application Server 故障转移（处于组件级（服务器、Web、EJB 等），而非数据中心级）范围外。

在这种情况下，特别是当客户机位于一个数据中心而服务器位于另一个数据中心时，WLM 端点会发生什么情况呢？EJB WLM 或 HTTP 服务器插件 WLM 都会出现这种情况，这取决于部署和网络体系结构，虽然这两种 WLM 实现都会还原（通过超时），但这是需要考虑（和可能避免）的另一种情况。

WebSphere Application Server Network Deployment 部署管理器是一个单点失败。因此，如果您失去运行部署管理器的数据中心，也就失去了管理单元的能力，直到仍然存在的数据中心启动备份部署管理器为止。虽然这种问题能够解决，但它仍然是在故障中需要处理的另一个问题。

如果您选择分发 HTTP 会话对象，而且您使用数据库来实现此目的，则如果该数据库位于现在没有运行的数据中心，会话信息会出现什么情况呢？

虽然的确可以构建（和测试）交叉中央集群解决方案（如果您非常谨慎地运用），但也始终存在丢失某些东西的风险，这在真正面临灾难时会出现。这是因为还存在一些我在这里没提到（和我没有考虑过）的问题，它们致使我再次建议跨多个数据中心运行 WebSphere Application Server 单元。正如我经常提到的，灾难不是您在工作中想要经历的事情。