这些成功的客户使BEA成为基础架构软件的领头羊，它拥有2100多个合作伙伴ISV、ASP和系统集成商，以及11000多家客户。BEA WebLogic是行业内最先进的Java应用服务器，一直赢得最高的市场份额，以及对J2EE和Web service技术的大力支持。
　　BEA WebLogic Server成功的关键之一是它已经证明，通过卓越的集群能力，它能够提供可伸缩性和高可用性。

集群BEA WebLogic Server TOP
　　BEA WebLogic Server集群由许多部署在网络上的BEA WebLogic Server组成。集群服务器一起工作，提供比单台服务器功能更强大、可靠性更高的应用程序平台。集群对于其客户机来讲是单台服务器，但事实上，它是起着一台“超级”服务器作用的一组服务器。

与单一服务器相比，BEA WebLogic集群有两个主要优点：

• 可伸缩性——集群的能力不受某一单台服务器或者单台机器的限制。为了提高处理能力，可以动态地将新的服务器添加到集群中。如果需要更多的硬件，可以在新机器上添加新的服务器。如果单一的服务器不能充分利用现有的机器，可以在该机器上添加其他的服务器。
• 高可用性——集群利用多台服务器的冗余使客户机与硬件或者软件故障隔离开。集群中的多台服务器可以提供相同的服务。如果某台服务器发生故障，另一台服务器可以接管。从发生故障的服务器自动切换到正在运行的服务器的能力，可以保证对客户机而言具有应用程序的无缝可用性，而无需客户机知道出现了问题。

集群的其他特性：

　　BEA WebLogic Server集群可以进一步聚合在某个域内——域指的是能够由控制台作为单一的逻辑安装所管理的一组BEA WebLogic Server实例和/或者集群。如上所述，BEA WebLogic Server集群以对应用程序开发人员透明的方式向J2EE应用程序提供可伸缩性和高可用性。但是，为了使应用程序程序员和管理员最大限度地提高其应用程序的可伸缩性和可用性，让他们了解集群内固有的问题很重要。
　　BEA WebLogic Server有几种形式的复杂的集群，分别是Web集群、对象集群、JMS（Java消息服务）集群和JDBC连接池（元池）集群。
　　除了基本的集群功能之外，集群内的BEA WebLogic Server实例可以与全局共享和复制的（全部集群）JNDI树（Java命名和目录接口）的组合相互配合，并在内存中进行Servlet和EJB会话状态的复制。

访问BEA WebLogic Server集群 TOP
　　BEA WebLogic Server集群在客户机看来是单一的服务器，可以使用简单的URL来寻址。 实际上，该URL必须映射到集群内的多台服务器，以保证连接请求可以在该集群内负载均衡，并且可以透明地进行故障切换。BEA WebLogic Server支持几种实现这种简单访问模型的技术：

• DNS负载均衡
• 代理服务器（BEA WebLogic代理，或者使用BEA WebLogic插件的第三方Web服务器)
• 硬件负载均衡器

DNS负载均衡 TOP
　　访问BEA WebLogic Server集群最简单的方法是使用映射到所有集群服务器的IP地址的单一DNS（域名系统）名称。当一个DNS名称映射到多个地址时，DNS服务器将循环使用该列表，连续查找这个DNS名称。这提供了一种简单的负载均衡和故障切换方式。每次客户机解析URL，它都将得到循环的下一个地址。这样可以保证客户机连接均匀地在集群中得到均衡。如果某一客户机请求失败，客户机可以通过再一次查找该名称来故障切换该请求，并用新地址重新尝试。对某些应用程序而言，这是一种简单但足以解决问题的方法。但是，它不具备其他解决方案可提供的性能和可管理水平。

代理服务器 TOP
　　访问集群的另一种方法是使用代理回该集群的其他Web服务器。代理服务器可以是含有BEA WebLogic Server的Web服务器，或者是具有BEA WebLogic 插件的Apache、Netscape或者Microsoft Web Server。
　　代理服务器被设置为将某些类型的请求重定向到支持它的服务器上。例如，可以配置代理服务器处理静态HTML页面请求，而将针对Servlet和Java Server Page的请求重定向到支持代理的BEA WebLogic集群。
　　代理服务器的作用类似于硬件负载均衡器，因为代理服务器执行负载均衡、在支持它的集群中的多台服务器之间分配请求。当会话建立时，它继续代理该会话的所有请求到单一的服务器。如果该服务器发生故障，它将任务切换到副服务器。

使用 BEA WebLogic Server作为 Web Server TOP
　　BEA在BEA WebLogic Server中加进了具有完全功能的HTTP服务器。因此，BEA WebLogic Server能够作为完全集群解决方案中的主Web服务器。作为Web站点，除继续提供静态HTML文件之外，还提供个性化的、动态的内容，人们可能期望看到更多的Web服务器被Web应用服务器所替代。

　　用作Web服务器时，高性能的BEA WebLogic Server支持最新的J2EE 1.3标准，进而为客户提供了以下好处：

• 与大多数负载均衡硬件，以及最为广泛使用的Web服务器（使用了所提供的插件）集成
• 与大多数Java虚拟机兼容
• 可伸缩性和高可用性的集群
• 跨集群的Servlet状态复制
• Servlet自动故障切换
• 支持Cookies
• Servlet转发和链接
• JSP结果缓冲
• JSP标签库
• 动态部署
• 基于Web的管理和监控

使用 BEA WebLogic Server作为负载均衡代理 TOP
　　BEA WebLogic Server可以作为负载均衡代理与BEA WebLogic 集群接合。就这一点而论，它可以提供负载分配、故障切换和其他的负载均衡器特性，以及处理Web请求的某些部分（例如，快速静态页面服务）。作为代理，然后它可能将大多数请求重定向到支持它的集群。
　　图1显示了使用BEA WebLogic代理作为负载均衡器的第一种可能的BEA WebLogic集群配置。这种配置充分利用BEA WebLogic作为Web服务器。

图1：BEA WebLogic代理作为BEA WebLogic Web Serve前面的负载均衡器

与第三方Web服务器集成 TOP
　　可以将BEA WebLogic Server与第三方Web服务器集成。Web服务器代理向使用BEA WebLogic Server 所供插件的BEA WebLogic Server代理请求。插件是为iPlanet (Netscape) Enterprise Server、Microsoft IIS和在指定平台上的Apache准备的。它设计用于第三方服务器处理静态页面的环境中。在这种情况下，动态内容（动态页面最好由HTTP Servlet或JSP生成）委托给BEA WebLogic Server ，它可能运行在不同的进程中或者在不同的主机上。对于最终用户——浏览器来说，将HTTP请求委派给BEA WebLogic Server 看起来仍然是来自相同的源。
　　在这种情况下，代理插件也可以访问由BEA WebLogic Server所托管的业务组件（如图2所示）。

图2：BEA WebLogic代理插件连接BEA WebLogic Server

　　该配置使用户可将其投资利用到第三方Web服务器中，从而提供到基于WebLogic Server的环境的平稳过渡，同时支持与第三方服务器密切整合，并且支持BEA WebLogic本身的负载均衡和故障切换能力。

硬件负载均衡器 TOP
　　硬件负载均衡器克服了DNS方法的缺点，它工作在IP级而不是在命名级。同时，硬件负载均衡器比代理服务器所实现的软件均衡器的性能更好。硬件负载均衡器相当于集群的代理。客户机连接到负载均衡器上，并且将该连接路由到支持它的集群服务器中的某一服务器。负载均衡硬件可以跟踪每台服务器的“可用状态”，避免向“反常的”访问器发送请求。在其负载均衡判定中，负载均衡硬件也可以结合负载信息。使用负载均衡硬件更容易看见的一些优点是：

• 更宽的负载均衡算法选择范围——您可以选择各种各样的负载均衡算法。例如，您可以根据负载、连接或者简单的“循环”逻辑来选择算法。
• 跳过失效的服务器——负载均衡器将跳过集群中失效的服务器，从而提高响应时间。
• 加速安全套接字层（Secure Socket Layer，SSL）——负载均衡器通常将SSL处理从应用程序服务器转移到专用SSL加速器上，因而可以加速SSL。通过减少处理安全事务所需的时间，这可以极大地提高性能。
• 较少的网络跳数（hop）——在BEA WebLogic Server集群前面直接使用一个硬件负载均衡器导致从负载均衡器到BEA WebLogic Server 只有一个网络跳。这样比将负载均衡器放在第三方代理Web服务器场之前性能要好，因为那样需要标准的两跳——一跳是从负载均衡器到Web服务器，另一跳是从Web服务器到BEA WebLogic Server。

　　然而，硬件负载均衡器一般比用BEA WebLogic Server充当代理更昂贵，并且没有BEA WebLogic Server特有的智能，该智能可提供更好的故障切换性能、降低网络混乱程度。特别是，硬件负载均衡器不能利用HTTP cookies，这些cookies载有BEA WebLogic集群特有的有关集群对象的主实例和副实例位置的信息。
　　 BEA WebLogic Server支持大多数现在市场上流行的负载均衡硬件产品。注意一点很重要，联合使用这些负载均衡产品和BEA WebLogic Server不需要额外的编码。
　　要支持通过负载均衡硬件的直接客户机访问，BEA WebLogic Server的复制系统（replication system）使客户机能够使用副（secondary）会话状态，而不用管客户机故障切换到哪台服务器。BEA WebLogic Server继续使用客户机方的cookies或者URL重写功能，以记录主服务器和副服务器的位置。然而，在部署负载均衡硬件时，这一信息只能用作客户机会话状态位置的历史。通过负载均衡硬件访问集群时，客户机不使用cookie信息主动查找故障后的服务器位置。简而言之，负载均衡硬件使用它的配置策略将请求定向到集群中某一可用BEA WebLogic Server。

图3：硬件负载均衡器连接BEA WebLogic Server

　　一旦服务器选定哪台客户机将进行故障切换，该服务器就使用该客户机cookie中的信息（或者如果使用URL重写功能，就使用HTTP请求中的信息）获得会话状态复制品（稍后会更详细地讨论）。故障切换过程对客户机仍保持完全透明。

WAN集群 TOP
　　BEA WebLogic集群也可以配置在广域网（WAN）上。在这种情况下，尽管配置成单一的集群，但BEA WebLogic Server实例在物理上可能位于不同的数据中心、属于不同的局域网（LAN），并且可能相距很远。这些配置通常用于灾难恢复，或者提供从地理上分布的客户机到全球分布的应用程序（不同的数据中心托管相同的应用程序）的快速本地访问。

WAN集群方案：
1.在构成WAN集群的两个或者多个LAN之间有可靠的、高吞吐能力的连接。该连接可以是专用线路，或者其他受控的“宽管（fat pipe）”型连接。从BEA WebLogic集群的角度来看，这种情况与简单的LAN情况没什么差别。集群可以为持久性状态使用内存中（in-memory）复制，并且两个LAN之间的所有路由器必须允许多播和点到点连接的TCP/IP。

图4：具有可靠的、高吞吐量连接的WAN集群

　　要使WAN集群高度可用，应该跨WAN生成复制组，以便主和副服务器不在同一数据中心（如图4所示）。

2.没有高吞吐量、可靠的连接可以利用，并且每个LAN只能通过常规的Internet连接访问集群的其他部分，并且没有受控的集线器和路由器。
　　值得推荐的是，在这种情况下，只能使用基于磁盘的持久性（基于JDBC－或者文件）。利用这种配置，子集群不能相互通信。然而，他们使用持久的状态存储设备通过Internet进行复制。使用市场上销售的文件和数据库复制产品（用于文件的Veritas，用于数据库的Oracle等）可以实现这一功能。但是，磁盘存储器复制可能不是实时的，即：它可能根据配置的时间间隔进行复制。测试表明：基于JDBC的持久性比基于文件的持久性要快得多。

图5：没有可靠连接的 WAN集群

　　在此方案中（如上面的图5所示），如果第1个数据中心发生故障，请求将被重路由到另外一个数据中心，对象的状态将从持久性存储器中重载，但自最后一次成功复制之后，可能有些信息没有被复制，因而可能丢失。
　　为了使BEA WebLogic WAN集群能够实现，必须使用像Alteon、F5、和Resonate这样的第三方全局负载均衡器（Global Load Balancer）（也称为Global Content Manager）。
为了实现最高的可用性，WAN 集群可能需要大量的网络和系统资源。

Web 集群 TOP
　　BEA WebLogic Server通过保持访问集群Servlet和Java Server Page（JSP）的客户机的HTTP会话状态，为Web应用程序提供集群支持。这种持久性可以通过配置BEA WebLogic控制台获得，可以从下面三个互斥选项中选择：

• In-memory复制
• 文件系统持久性
• 通过JDBC的数据库持久性

　　每个选项分别表现了持久性和性能之间的一种折衷。文件或数据库的持久性提供可能的最可靠持久性。然而，这些选项就性能而言代价更大。In-memory复制通过Servlet和JSP HTTP会话状态自动故障切换为客户提供高可用性优点。该选项最适合那些为了获取最优性能而愿意接受持久性折衷方案的客户。
　　In-memory复制通过创建主会话来提供客户机会话状态的持久性。而主会话保存在客户机最初连接到的BEA WebLogic Server实例上，并且在集群内的另一个BEA WebLogic Server实例上有该会话状态的副复制品。复制品总是保持最新，以便托管主会话状态的服务器发生故障时可以使用它。从一个实例复制会话状态到另一个实例的过程正是In-memory复制的机制。
　　如果可能，BEA WebLogic Server在不同的机器上（有别于托管主会话状态的机器）创建会话状态的复制品。BEA WebLogic Server使您能够利用Administration Console中的复制组（replication group）进一步控制存放副状态的地方。复制组只是用于存储会话状态复制品的集群实例优先级列表。
　　图6描述了客户机利用BEA WebLogic代理或者硬件负载均衡器访问服务器集群。该示例使用BEA WebLogic Server集群处理静态和动态的Web内容，以及托管应用程序的业务逻辑。所有HTTP请求通过负载均衡器转发给集群。

图6：负载均衡（硬件或者代理）将请求发送给集群内的某一可用服务器

　　当客户机请求Servlet时，硬件负载均衡器代理到集群的请求。负载均衡器利用它的配置策略，将客户机请求发送到Server A之后，Server A充当客户机Servlet会话状态的主托管机。
　　在上面的图6中，Server A使用特殊的算法托管会话状态的复制品。选择Server B托管该复制品。通知客户机在本地cookie中记录Server A和Server B的位置。如果客户机不使用cookies，主服务器和副服务器的记录可以记录在通过URL重写功能返回客户机的URL中。
　　当客户机向集群提出另外的请求时，负载均衡器使用客户机方cookie中的标识符来确保这些请求继续发送到Server A（而不是被负载均衡到集群内的其他服务器）。这就确保在会话生存期内，客户机总是保持与托管主会话对象的服务器相关联。
　　文件系统和数据库持久性工作方式类似，只是状态数据保存在磁盘上。在这种情况下，BEA WebLogic Server实例之间没有集群感知的占位程序或者状态复制。在故障切换处理期间，保存的状态由下一个从负载均衡器中得到请求的可用服务器实例从磁盘上读取。

用代理Web服务器的故障切换 TOP
　　在客户机会话期间，万一Server A出现故障，客户机到Server A的下一个连接请求也会失败。
　　发生这种情况时，代理可以确定（从cookie或者URL）JSP或者Servlet对象要访问的副服务器（在该例中是Server B）。请求被代理直接重路由到副服务器（B）。之后，Server B指定自己作为主服务器，并在集群内的任何其他可用服务器上创建另一个副服务器（C）（如图7所示）。

图7：具有代理负载均衡的主服务器出现故障，则将请求重定向到集群中的副服务器

用负载均衡硬件的故障切换 TOP
　　负载均衡硬件为了响应连接失败，会使用其配置策略把请求发送给集群中某一可用的BEA WebLogic Server。在上述示例中，假设在Server A出现故障后，负载均衡器会将客户机的请求定向到Server C。
　　当客户机连接到Server C时，服务器使用客户机cookie中的信息(或者如果使用了URL重写功能，则使用HTTP请求中的信息)获取Server B上的会话状态复制品。故障切换的过程足够快，因而系统故障对客户机是完全透明的。
　　Server C变成客户机主会话状态的新托管主机，Server B继续托管会话状态的复制品。在客户机cookie中，或者通过URL重写功能，会再一次更新有关主、副托管主机的新信息。

图8：具有负载均衡硬件的主服务器出现故障，它将请求重定向到集群中的某一可用服务器

　　在两个服务器集群中，客户机将透明地故障切换到托管副会话状态的服务器。另一台服务器一加入到该集群中，或者原来的主服务器重新启动或重新连接到网络中，就会继续客户机会话状态的复制。

对象集群 TOP
　　BEA WebLogic Server支持的第二种形式的集群是对象集群。如果某一对象被集群，该对象的实例——称为复制品——将被部署在集群内的所有服务器上。
　　在BEA WebLogic Server中，支持集群对象的关键技术是复制品感知的占位程序。连接到BEA WebLogic Server集群、并且查找集群对象的客户机获得一个该对象的占位程序，在调用者看来，它是一般的占位程序。但是，该占位程序不是表示单一的对象，而是表示一个复制品集合。
　　通过使用复制品感知的占位程序和全局共享和复制的JNDI树，客户机可以选择调用对象的哪一个实例。
　　默认情况下，在部署对象、然后连入JNDI树的时候，会自动生成该对象的复制品感知的占位程序。如果该对象不需要复制，可以关闭这一特性。复制品感知的占位程序含有查找某一对象所需的逻辑，而这一对象在部署该对象的任意BEA WebLogic Server实例上。
　　BEA WebLogic Server实例有能力更新该占位程序的本地副本，因而该占位程序含有托管对象复制品的所有可用服务器实例的完整列表。该占位程序还包含在其主服务器之中分配负载时的负载均衡逻辑。每次调用时，占位程序利用其负载均衡算法选择调用哪一个复制品。这种在集群中负载均衡对调用者是透明的。如果在调用过程中出现故障，占位程序截获异常并重新尝试调用另一个复制品。这种故障切换对调用者也是透明的。
　　万一出现故障，占位程序从其列表中删除失效的服务器实例。如果在其列表中没有服务器了，则它再次使用DNS查找某个正在运行的服务器，获得当前正在运行的实例列表。此外，占位程序定期地刷新集群内可用的服务器实例列表。这使得占位程序能够利用添加到集群中的新服务器。
　　BEA WebLogic Server中的对象集群根据维护实体bean和会话bean状态的重要性，有差别地处理实体bean和会话bean。下面描述对各种EJB（Enterprise JavaBean）的不同处理方法。

无状态会话EJB TOP
　　因为无状态bean不保存代表客户机的状态，所以占位程序自由地将所有调用路由到托管该bean的任何服务器。因为bean是集群的，所以在故障事件中，占位程序可以自动进行故障切换。

有状态会话EJB TOP
　　BEA WebLogic Server复制有状态会话bean EJB的状态，方法与它复制HTTP会话状态的方法类似。当客户机创建EJBObject占位程序时，最初由负载均衡器选择的实例会自动选择托管已复制EJB状态的副服务器。
　　客户机接收一个复制品感知的占位程序，它列出集群内托管EJB状态的主、副服务器的位置。主服务器托管与客户机交互的实际EJB实例。副服务器只托管复制的EJB状态，这只消耗很小的内存空间。除非发生故障切换，否则副服务器不创建实际的EJB实例。这样保证在副服务器上消耗的资源最少，保存复制的EJB状态不需要配置额外的EJB资源。
　　当客户机修改EJB的状态时，状态变化被复制到副服务器实例上。对于使用事务的EJB，事务提交后，复制立即发生。对于不使用事务的EJB，调用每个方法后复制发生。在这两种情况下，只有EJB状态的实际变化被复制到副服务器上，从而保证与复制过程相关的开销最小。
　　如果主服务器出现故障，客户机的EJB占位程序会将以后的请求重定向到副BEA WebLogic Server实例。此时，副服务器利用复制的状态数据创建一个新的EJB实例，并在副服务器上继续处理。
　　故障切换后，BEA WebLogic Server选择一个新的副服务器来复制EJB会话状态（如果在集群中有其他可用服务器的话）。在下一个方法调用中，将会自动更新客户机的复制品感知占位程序中的新的主、副服务器实例位置。

实体bean TOP
　　当EJBHome找到或者创建一个实体bean之后，它返回订住该服务器的占位程序。该服务器出现故障之前，有关该占位程序的所有请求都发往相同服务器。在这种情况下，BEA WebLogic Server故障切换至另一台服务器。注意：在这种情况下没有复制，BEA WebLogic Server依靠数据库来存储变化情况。由于EJB部署在集群内，所以只需要另一台可用的服务器从数据库中重载其状态。此时，占位程序将会用托管重新创建的EJB的服务器位置进行更新。
　　实体bean的负载均衡只在主（home）级进行。然而，为了故障切换，复制品感知占位程序将在另一台服务器上重试请求。应该注意的是：只有请求在当前事务外时，才是这种情况。
　　由于在集群内可能存在该实体bean的多个实例，所以每个实例都必须在每个事务之前从数据库中读取，并且每次提交时写入。
　　如果是只读的实体bean，bean的数据由访问该bean的服务器实例在本地缓存。在数据很少修改的情况下，这样做节省数据库访问。当这些数据是由只读的EJB修改时，通过向服务器的其他实例多播无效消息，可明确地使集群内相关的只读bean失效。这种失效方法可用于指定的主键、某一键集或者所有指定类型的bean。

全部集群的JNDI树 TOP
　　某一单独BEA WebLogic Server的客户机使用JNDI兼容的命名服务访问对象和服务。JNDI命名服务包含一系列由服务器提供的公共服务，以“树形”结构进行组织。BEA WebLogic Server通过将名称绑定到表示新服务的JNDI树来提供新的服务。客户机通过连接到服务器并查找服务的绑定名称来获得服务。
　　集群内的服务器实例利用全部集群的JNDI树。全部集群的JNDI树与单一服务器的JNDI树类似，在这种情况下该树包含一系列可用的服务。但是，全部集群的JNDI树除了保存本地服务的名称之外，它还保存复制品感知的占位程序，而该占位程序指向集群内所有服务器上可用的集群对象。集群内的各BEA WebLogic Server实例创建和维护全部集群JNDI树的一个本地副本。

JMS 集群 TOP
　　BEA WebLogic Server通过在整个集群内分布JMS目的地和连接工厂来支持多个JMS服务器的集群。
　　JMS目的地是接收消息的实体。客户机使用JMS连接工厂建立与目的地的连接。
　　利用集群，BEA WebLogic Server的高级JMS可伸缩性可通过如下方法实现：
　　通过连接工厂在多个JMS服务器中分配应用程序的负载。这样提供多个服务器间的连接负载平衡，减少单台JMS服务器上的负载，并通过将连接路由到指定服务器而使会话集中。
　　通过虚拟目的地标识跨多个JMS服务器分配目的地。这可减少指定服务器上各物理目的地的负载，并且极大地提高消息传递的可靠性和性能。
　　可选的多播支持可以减少JMS服务器必需传送的消息数目。JMS服务器只将消息的单个副本转发给每个与多播IP地址相关的主机组，而与订阅的应用程序数目无关。
　　JMS连接工厂可以自动部署在集群内的多台服务器上。使用分布式JMS连接工厂，客户机可以从BEA WebLogic Server的任意实例中取得一个JMS连接。每台BEA WebLogic Server处理一组JMS目的地请求。
　　当JMS客户机请求来自BEA WebLogic Server集群的JMS连接时，它可能根据所用的负载均衡算法从集群的任意服务器上获得。该服务器可能不是处理客户机所需的到指定目的地JMS请求的服务器。但使用JNDI，部署在每个BEA WebLogic Server实例上的连接工厂可以访问集群内任意服务器的目的地组。这样每台客户机可以在集群范围内透明地访问集群内的任何目的地。
　　使用虚拟目的地，允许您配置多个物理目的地作为单一分布式目的地集合的成员，这样万一某台服务器出现故障，BEA WebLogic JMS的高可用性实现可提供某种程度的服务连续性。特别是，管理员可以配置集群内某一给定目的地的多个实例作为虚拟目的地的成员。如果集群内的一个实例出现故障，则同一目的地的其他实例能够为JMS过程和消息使用者提供服务。在这种情况下，可以将遗留在故障服务器上的可迁移目的地服务消息迁移到正在运行的实例上。
　　虚拟目的地和遍及整个集群的分布式连接工厂，使管理员能够通过配置不同的负载均衡算法和为集群各节点设置相对权重来人工均衡JMS服务的负载。

JDBC元池集群 TOP
　　万一正在服务的集群成员发生故障，在不更改连接参数的情况下，集群JDBC（元池）允许外部的JDBC客户机自动重新连接和重启它们的JDBC连接。集群JDBC需要DataSource对象和BEA WebLogic RMI驱动程序以连接到DBMS。利用Administration Console 可以为每个BEA WebLogic Server定义DataSource对象。JDBC元池为部署在BEA WebLogic Server集群内多台服务器上的JDBC连接池提供集群。当客户机向元池请求连接时，集群选择将提供连接的服务器，进行负载均衡和保护，以防止服务器失效。一旦客户机拥有一个连接，由JDBC驱动程序保存的状态使它必需将客户机与主BEA WebLogic Server绑定在一起。

BEA WebLogic Server实例如何在网络上通信 TOP
　　每个BEA WebLogic Server实例运行在惟一IP地址的网络上。整个集群的监听端口必须相同。BEA WebLogic Server允许多宿主（multi-homing），这意味着可以分配多个IP地址给同一台物理机器。因此多宿主主机有多个网络接口，每个网络接口可以运行一个BEA WebLogic Server实例。集群内BEA WebLogic Server实例彼此利用IP多播通信，用以向集群内的所有服务器复制某类信息。IP多播是一种简单的广播技术，它使多个应用程序能够向某一给定IP多播地址和端口号“订阅”，并监听消息。
　　集群中的每台服务器都配置常用的多播地址。当服务器向集群的多播地址发送消息时，所有的服务器都接收消息。这比让服务器发送点到点消息的效率要高得多，但它的确要求集群中的所有服务器必须在支持多播的网络上。多播不能通过Internet上进行，因而集群不能经过Internet。
　　BEA WebLogic Server把IP多播用于集群中各个服务器实例的所有一对多通信。例如：

• 集群范围内的JNDI更新——所有集群成员使用多播通知本地部署或者删除服务的可用性。服务器监视这些通知，以便它们能更新其本地JNDI树以反映当前的部署情况。
• 集群“心跳（heartbeats）”——BEA WebLogic Server使用多播来广播规律的“心跳”消息，通告集群内单个服务器实例的可用性。集群内的所有服务器将监听心跳消息作为确定服务器失效时间的方法。“心跳”的使用是BEA WebLogic确定给定服务器实例是否可用的两种机制之一。BEA WebLogic还监视IP套节字错误作为确定服务器失效时更直接的方法。例如，如果服务器实例A具有到实例B的开放套节字，而该套节字突然关闭了，则Server A假定Server B脱线了。

配置和管理BEA WebLogic 集群 TOP
　　作为一个单位来管理的内部相关BEA WebLogic Server资源集称为域（domain）。一个域包括一台或者多台BEA WebLogic Server，也可能包括BEA WebLogic Server集群。域，以及集群可以跨多个物理机器生成。
　　通过Administration Console，可以使用BEA的图形用户接口（GUI）管理和监视域、集群或者单独的BEA WebLogic Server的配置。
　　BEA WebLogic集群的重要特性之一是能够把单一的视图应用于集群内配置的所有单独服务器上。在该意义上来说，集群被作为某一域内的实体进行管理。在域中配置集群时，集群的所有服务器必须也是该域的一部分。一个域可以包含多个集群。
　　正在运行管理服务的BEA WebLogic Server称为管理服务器（administration server）。管理服务提供配置和监控整个域的控制中心点。为了在该域进行任意管理操作，必须运行管理服务器。
　　在拥有多台BEA WebLogic Server的域中，只有一台服务器是管理服务器，其他服务器称为受管服务器（Managed Server）。每个BEA WebLogic受管服务器在启动时从管理服务器获得其配置。
　　在生产系统的典型配置中，关于您的业务逻辑的应用程序和组件可以部署在受管服务器上，而管理服务器的作用是配置和监视受管服务器。如果管理服务器出现故障，部署在受管服务器上的应用程序不会受影响，继续处理客户机的请求。在这样的情况下，管理服务器一旦重新启动，就可以重新获得活动域的管理控制。

图9：一般的BEA WebLogic Server域架构，它含有单独的服务器、集群、多台物理机器和单台管理服务器

配置集群 TOP
　　利用BEA WebLogic Server的Domain Configuration Wizard，可以简单快速地配置集群。通过直观的图形接口，管理员可以通过检查一系列的窗口并输入特定的参数来创建集群域。这些参数配置拥有管理服务器、受管服务器、物理机器，以及特定应用程序的JDBC数据源参数、JMS工厂和目的地、安全实体、JVM以及其他基本子系统和组件（图10）的集群拓扑。验证并记录用户提供的信息，并由这些信息生成完整的集群配置。

图10：用Domain Configuration Wizard配置BEA WebLogic Cluster

　　Domain Configuration Wizard也可以创建域模板，这样可以复制复杂的环境，简化将集群应用程序转入生产的冗长过程。
　　BEA WebLogic Server域和集群的持久性配置保存在一个XML配置文件中。管理服务器动态管理该配置，并且用户可以通过Administration Console使用它（图11）。

图11：通过BEA WebLogic Server Administration Console管理集群域

　　在Administration Console中可以完成的集群配置任务包括：

• 利用Administration Console的Cluster节点配置服务器集群。利用该节点可以修改的属性包括Cluster Name、Cluster ListenPort和集群中的服务器名称。
• 利用Administration Console的Cluster节点复制服务器集群。集群被复制，保持属性值和原集群中各个服务器，以及在Server节点的Configuration部分设置的新集群名称。
• 利用Administration Console的Cluster节点监视集群中的服务器。
• 利用Administration Console的Cluster节点为集群指派服务器。
• 利用Administration Console的Cluster节点删除集群。

使用节点管理器（Node Manager）自动管理 TOP
　　BEA WebLogic Server生产环境中的受管服务器通常被分布在多台机器和多个地理位置。自动管理允许集群自管理和自动地对各种突发条件和情况做出反应。利用节点管理器实用程序大大方便了这一强大的特性。
　　节点管理器是一个Java实用程序，在BEA WebLogic Server（图12）中作为独立的进程运行，允许您执行受管服务器的常规操作任务，而不管它与其管理服务器的相对位置如何。虽然节点管理器的使用是可以选择的，但如果您的BEA WebLogic Server环境以高可用性要求托管应用程序，则它可提供极有价值的优点。

图12：多机集群域中的节点管理器

　　与只刷新用户请求信息显示的Administration Console不同，节点管理器连续地监视受管服务器。通过基于JMX的开放管理接口，客户可以基于节点管理器构建强大的事件通知和统计监视框架。同时，可以配置节点管理器自动对集群事件做出反应，并根据预先配置的条件采取某些行动。例如，节点管理器可以在突然失效后自动重启某台受管服务器，或者如果由某台服务器所报告的某一统计参数低于配置的阈值时，则给管理员发送消息。

　　有关配置和管理BEA WebLogic服务器、集群和域的更多信息，请参阅BEA WebLogic在线文档，其网址是：http://e-docs.bea.com/wls/docs81/adminguide/。

结束语 TOP
　　本白皮书概述了BEA WebLogic Server中的集群特点，说明了BEA WebLogic架构如何使用集群技术提供企业客户所需的高可用性和可伸缩性。
　　有关BEA WebLogic集群技术的更多细节，请参阅BEA WebLogic Server文档，其网址是：http://e-docs.bea.com/wls/docs81。
　　BEA WebLogic集群的目的之一是消除集群内的单点故障。这一点是通过架构实现冗余来达到的。在硬件或者电源故障事件中，客户机能够利用这种冗余自动故障切换到某一正在运行的系统资源上。正是这种避免停机的能力为BEA客户提供了24×7可管理的保证。
　　另一个目标是推动高度可伸缩的企业电子商务基础结构，这在当今的动态业务环境中可使增长能力无限。
　　BEA相信BEA WebLogic集群技术是业内最先进的，并且向客户提供最高级别的可伸缩性和任务关键型应用程序最需要的可靠性。
　　BEA WebLogic集群，加上其他的性能和可伸缩性特性，例如JDBC连接池和多池、高级缓存、只读/可改写的只读实体bean以及线程池，使WebLogic Server成为市场上最可靠、最具伸缩性和性能最强的Java应用服务器。这也是一些大客户，如FedEx、Charles Schwab、Amazon.com和很多其他客户在WebLogic Server上构建其任务关键型应用程序的原因。
　　BEA WebLogic Server是BEA E-Business Platform?的基础。BEA E-Business Platform专门设计成能够跨多个应用程序和系统共享数据和服务，它是构建在各种开放标准之上的基础结构产品集成套件，这些开发的标准支持大量事务、业务流程管理、应用程序集成、企业内和企业之间的业务协作以及创建和维护动态电子市场（e-market）的能力。
　　要了解关于BEA WebLogic Enterprise Platform?的更多信息，请访问 BEA Web站点，其网址是： www.bea.com/。

BEA 简介 TOP
　　BEA是世界上领先的应用程序基础架构软件公司，在世界各地的客户超过13000家，包括Fortune全球500强企业中的大多数。BEA WebLogic Enterprise Platform提供工业强度（industrial strength）的、易于使用的软件基础，使企业更灵活、生产率更高和连接更强，从而显著地增加了IT生产率并加快了投资回报。BEA的平台是超过1700家系统集成商、独立软件开发商，以及与BEA合作以确保成功部署客户解决方案的应用程序服务提供商们的事实标准。

BEA Systems, Inc.
2315 North First Street
San Jose, CA 95131 U.S.A.
电话: +1.408.570.8000
传真: +1.408.570.8901
网址：http://www.bea.com

原文出处：
http://dev2dev.bea.com/products/wlserver81/whitepapers/WLS_81_Clustering.jsp