通过高级的集群功能，基于BEA WebLogic Server的电子商务应用可以跨越多台服务器。（注意：WebLogic Server支持多种类型的集群，其中仅有一个和本文相关——它叫做Web Clustering.在Web Clustering中，强调了HTTP集群或Web应用的表示层。这就是这儿提到的。） 复制应用的组件及其状态，以及客户端会 话状态信息以提高可用性。如果服务器中间会话（mid-session）失败，可以在另一台服务器上恢复客户端会话，不会丢失会话数据。 WebLogic Server集群使得该功能对视集群为单个"虚拟服务器"的客户端透明。

    伴随着软件基础结构逐渐演变为包含了对Web内容的发送进行优化的专业应用服务器，网络基础结构也演变？quot；内容识别（content aware ）".Cisco  System是内容交换开发的先驱，所谓内容交换是指用来优化基于Web的应用的发送的一类网络设备。这些高性能的网络设备理解基于Web的事 务的本质，并知道如何在规定时间内及时将它们路由到性能最好的服务器上。用它们来提高基于Web的应用的可伸缩性、性能、可用性和安全。 本文介绍了如何使用Cisco CSS 11000 Series Content Services Switches （"Cisco内容交换机"）最大化BEA WebLogic集群的性能。

    起作用的WebLogic集群

    可能需要多个HTTP操作才能完成单个客户端事务。基于Web的股票交易门户的表示接口就是一个这样的简单例子。客户端可能通过多个步骤 来执行交易（获得报价、进行调查、下订单、接收确认等等）。应用程序跟踪该事务的"状态"和它后面的每个阶段。为了避免失败 ，可以将该会话状态复制到另一台服务器上。如果主服务器出现故障，该会话状态被重新初始化到新的服务器上（托管状态副本的服务器或恢 复状态的第三个服务器）。WebLogic支持三类不同的复制和恢复会话状态的方法：数据库复制（通过JDBC）、基于文件的复制和内存中的复制 .

    文件和数据库复制很相似。集群中的每台服务器保持到共享文件服务器或数据库服务器的连接。创建或改变状态信息时将它写入文件或数据 库记录中。当集群中的服务器出现故障时，后续客户端请求被路由到集群中其他可用成员上。新服务器读取会话ID（在初始化会话时建立，并 存储在cookie中或写入到请求的URL中），并且从数据库或文件系统中取得相关的状态。现在新服务器能够继续处理客户端的事务。

    内存中的复制将状态信息从主服务器发送到内存中指定的备份服务器上。如果主服务器出现故障，客户端将被路由到新的服务器上。该新的 服务器具有状态副本（在这种情况下，它指定新的服务器作为备份，创建会话状态的备份副本，并担当主服务器的角色）或从备份中（在这种 情况下，它担当主服务器的角色，从旧的备份中清除会话状态，建立新的备份服务器，并在备份上创建新的状态副本）获取状态。类似于会话 ID，备份服务器的ID也被写入cookie或URL，从而允许新的服务器从备份中恢复会话状态。新的服务器能够继续处理客户端事务。

    请求路由

    由于同一集群中的多个服务器能够服务于一组特定的客户端请求，所以必须通过某些机制，将对"虚拟服务器"的客户端请求路由 到集群中某台真正的服务器。这种请求路由机制的第一个也是最简单的目标如下所述：

    1、均衡集群中可用服务器上的负载

    对于需要多个HTTP操作的事务（也可能是多个TCP连接），一旦和特定的服务器集群成员之间建立了客户会话，后续操作必须被定向到同一个 成员，直到会话结束。这将减少开销，并且能够为每个连续的操作从另一台服务器上获取会话状态。因此改善了用户的响应时间并提高了集群 总的利用率。因此WebLogic集群请求路由的第二个目标是：

    2、保持客户端和协助执行复杂事务逻辑的集群成员之间的"持久会话"

    公共域DNS服务器（如BIND）中可用的基于DNS的简单负载均衡允许操作者配置多个具有特定域名（例如，www.mystore.com）的主机地址。访 问该站点的客户端被按"round robin"（轮循）的方式解析成每个配置的地址。客户端将缓存通过域名本身返回的名字到地址的映射，主要是为了DNS服务器中 time-to-live（生存时间）配置。（注意：虽然这是DNS客户端的指定性能，实际的性能根据操作系统和浏览器有所变化。）对同一主机名的后 续请求将转向同一台服务器（利用缓存映射）——因此执行会话连续性的一个原始类型。然而，基于DNS方案的一个主要的缺点是它们不能在服务 器出现故障时路由。一旦客户端"绑定到"服务器，该绑定将一直保持下去，直到缓存的名字到地址的映射的生存期过期。所以，客 户端将一直尝试连接主机，即使该服务器已经出现故障或者不再服务了。很明显，健壮的本地请求路由机制中需要使用的不仅仅是简单的 round-robin DNS.（注意：当基于DNS的技术中结合了更加强壮的本地请求路由机制后，该技术对于灾难恢复和多个物理隔离的地址之间的均衡负载非常 有用。）因此，我们上面所列的请求路由目标应该再扩展。

    3、快速检测并路由到服务器及处理失败

    基于Proxy Web服务器的请求路由采用的方案是：在前端终止带有其他接受传入客户端请求并将它们定向到适合的服务器的集群。一个典型的 例子是，BEA Weblogic Server充任第三方Web服务的代理。加入集群协议后，代理能够快速检测服务器的故障并路由它们。会话持久性是通过检查会话cookie来提供 的。由于它是集群的正式成员，代理能够理解会话cookie的格式以及会话和服务器之间的关系。然而，由于它们是通用的应用服务器，这些代 理没有针对请求路由进行优化，因此性能比专业的负载均衡应用要差。

    负载均衡应用是通用PC，它具有用于负载均衡应用的软件。这些通用的体系结构和第一代路由器很相像，使用单个、中央CPU进行所有负载 均衡决策和分组转发。通过使用off-the-shelf PC主板（如SSL加速卡）并且编写驱动程序将它们和系统其他部分集成起来，可以添加其他的功能。通过把注意力集中在特定的任务上，这些 应用能够比基于它们的代理服务器的对应部分提供更好的性能、冗余和特性。然而，应用的硬件体系结构最终成为集群性能和可伸缩性的瓶颈 .对于企业级应用，性能是请求路由必须考虑的一个目标。该目标如下所述。

    4、与预期客户端请求的容量和数据传输速率相一致

    和通用处理体系结构成为限制第一代路由器的因素一样，通用PC体系结构成为限制请求路由的因素。意识到这一点后，Cisco System首先开 始开发现在被称为"内容交换"的技术。与内容交换机相关的核心知识产权为一个交换体系结构，它将请求路由的分组转发功能的处 理（如网络地址转换[NAT]、TTL递减、MAC地址替换等等）分割成请求路由的控制功能的处理（如服务器选择、会话建立和健康检查等）。该函 数的基本分割允许Cisco内容交换机提供比基于PC的负载均衡设备更加好的特征和功能及性能。

该帖已被版主加工整理，多个帖子进行了联合编辑

浏览最新整理出的资料贴: http://bbs.landingbj.com:80/t-0-251321-1.html