在GlassFish Version 2中实现集群 - 编程入门网

为了给开放源码的GlassFish应用服务器提供一种轻型的开放源码替代技术，在GlassFish version 2中提供了内存复制特性。内存复制依靠集群中的实例将另一个实例的状态信息存储在内存中，而不是存储在数据库中。但是，HADB解决方案仍然是可用的，而且在许多环境中是首选方案。

集群中的内存复制

对于在内存中维护状态信息的与GlassFish兼容的容错系统，需要几个特性。系统必须为HTTP会话状态、单点登录状态和EJB会话状态提供高可用性。另外，它必须与现有的基于HADB的体系结构兼容。

内存复制特性利用GlassFish的集群特性，提供HADB策略的大多数优点，而安装和管理开销却小得多。

在GlassFish应用服务器中，集群实例组织成一个环形拓扑结构。环中的每个成员将内存状态数据发送给环中的下一个成员（即它的复制伙伴），并接收来自前一个成员的状态数据。当在任何成员中更新状态数据时，数据会沿着环复制。图3给出这个拓扑结构的简化形式。

图3. 集群拓扑结构

在GlassFish Version 2中实现集群(4)

拓扑结构形成环形的方式由实例名称的字母表次序决定。所以，如果实例名称像图3中这样，那么Instance 1将向Instance 2复制，Instance 2向Instance 3复制，以此类推。

典型的集群拓扑结构见图4。在这个图中，显示的实例驻留在不同的物理机器上。将Instances 1和Instances 3放在一台机器上，将Instances 2和Instances 4放在另一台机器上，这可以提高可用性。如果其中一台机器发生灾难性故障，那么另一台机器上会保留所有数据（按照原来的形式，或者作为故障机器上实例的副本）。

图4. 典型的集群拓扑结构

典型的故障转移场景

GlassFish应用服务器的设计方式让负载平衡器层在发生故障时不需要特殊信息就能够执行负载平衡。例如，假设负载平衡器将一个会话分派给Instance 1，当Instance 1发生故障时，它不需要知道应该将会话分派给Instance 2。负载平衡器可以向集群中的任何实例发送一个故障转移请求，这种情况常常称为位置透明性。在集群中对故障进行响应。当负载平衡器将一个会话重新分派给一个正在工作的实例时，如果需要的话，这个实例会从另一个实例获得它需要的会话信息。

来自负载平衡器的故障转移请求属于两种情况之一：

第一种情况：接收故障转移请求的实例已经存储会话数据的副本。在这种情况下，实例获得会话的所有权并继续处理。

第二种情况：接收故障转移请求的实例没有所需的会话数据副本。在这种情况下，实例广播一个self-addressed-stamped-envelope（SASE）形式的请求来请求数据。拥有数据副本的实例将数据传输给请求者，并在收到确认消息（表示已经成功地接收了数据）之后删除它的副本。这个数据交换过程是通过 JXTA （Juxtapose）技术完成的。

图5 给出更详细的集群结构。左边是负载平衡层，它可能在一个web服务器上。在每个服务器实例中，一个本地缓存存储HTTP会话信息，这个缓存被复制到下一个实例的复制缓存。

图5. 带负载平衡器的典型集群拓扑结构

在GlassFish Version 2中实现集群(5)

图6说明故障转移的第一种情况，在这种情况中重新分派的服务器实例可以直接访问会话状态数据。在图中，Instance 1发生故障，负载平衡器的服务请求被分派给Instance 2，而Instance 2包含所需的会话状态信息的副本。

图6. 故障转移，第一种情况

图7说明故障转移的第二种情况，在这种情况中负载平

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!