安全环境中的WebSphere代理服务器路由功能

为了以优化的成本提供足够的性能，大量的网站通常依赖使内容更接近客户端的机制。这通常意味着某种缓存和缓存管理。

尽管必须不要低估由静态内容引起的负载，但对于大多数情况而言，仅缓存静态内容已不再足够。当今的现代缓存机制还必须提供缓存动态内容的功能。

IBM WebSphere Application Server网络部署（以下称为网络部署）提供了多个内置解决方案，它们可以用作中介服务，还可以提供静态和动态缓存功能。除了应用程序服务器本身可用的动态缓存功能外，这些还提供了缓存功能：

IBM WebSphere软件产品线还提供了针对应用程序和业务数据缓存进行了优化的特殊解决方案，例如IBM WebSphereDataPower®Appliance XC10。

HTTP插件。
WebSphere代理服务器。
DMZ安全代理服务器。
边缘组件缓存代理。

这些解决方案中的每一个都有其自身的优点和缺点。代理服务器与HTTP插件：选择最佳的WebSphere Application Server工作负载管理选项一文，很好地概述了Network Deployment提供的中间服务。有关WebSphere代理服务器在拓扑结构和配置中的位置的其他有价值的信息，可以从两部分的文章中找到，该文章从“ 超级集群”一章开始，第1部分。

本文仔细研究了WebSphere Proxy服务器提供的路由功能。还讨论了托管通过代理服务器传递的内容的受保护的WebSphere Application Server单元所需的配置步骤。

WebSphere代理服务器管理概述

WebSphere代理服务器最初是在WebSphere Application Server Network Deployment V6.0.2中引入的，并且需要扩展Deployment Manager概要文件才能显示。在较新版本的WebSphere Application Server中，可直接在Deployment Manager管理控制台中进行配置的WebSphere代理服务器。

WebSphere代理服务器作为网络部署单元的一部分运行，因此不适合放置在网络拓扑的DMZ中。借助Network Deployment V7.0，发布了WebSphere代理服务器的强化版本和DMZ就绪版本，即DMZ安全代理服务器 。但是，本文将仅讨论在单元内运行的WebSphere代理服务器。

从管理和配置的角度来看，WebSphere代理服务器是在受管节点上的WebSphere Application Server单元内运行的独立服务器类型。您可以通过打开WebSphere Application Server管理控制台或使用wsadmin进行基于脚本的管理来在单元中创建和配置WebSphere代理服务器定义。

要使用管理控制台管理单元的WebSphere代理服务器，请导航至服务器>服务器类型> WebSphere代理服务器 。您可以按照创建服务器的标准过程从那里创建WebSphere代理服务器。要使用WebSphere代理服务器将请求路由到单元中部署的应用程序，必须执行以下最小配置：

代理服务器定义的PROXY_HTTP_ADDRESS和PROXY_HTTPS_ADDRESS端口必须位于已部署应用程序的虚拟主机定义的主机别名列表中。
需要通过代理服务器提供服务的模块必须设置“启用代理”属性（请参阅下一节）。

本质上，WebSphere代理服务器可以将请求路由到两种类型的内容资源：

托管资源

托管资源是由WebSphere Application Server管理的资源，可以在与WebSphere代理服务器相同的单元中，也可以在远程单元中。由于这些资源完全由WebSphere Application Server管理，因此每个资源的状态以及到该资源的路由信息都通过高可用性管理器的公告板服务动态传播。因此，托管资源的路由是动态的；但是，根据环境的不同，它需要正确的核心组配置，以便高可用性管理器可以传播每个资源的状态。

要为托管资源启用动态路由，您需要为已部署的应用程序模块选中“ 启用代理”复选框。在应用程序部署期间，默认情况下会设置此框。

要验证是否为模块选择了“启用代理”选项，请打开管理控制台，然后导航至“ 应用程序”>“应用程序类型”>“ WebSphere企业应用程序”>“ <应用程序名称 >>管理模块> <模块名称>> Web模块代理配置” （图1）。

图1. Web模块代理配置

默认情况下，“ 启用代理”复选框处于活动状态，从而启用该模块以供代理服务器进行路由。 Web模块传输协议下拉框使您能够选择代理服务器和应用程序服务器之间使用的协议（HTTP或HTTPS）。
非托管资源
非托管资源是不受WebSphere Application Server管理和控制的那些资源。因为WebSphere Application Server无法控制这些资源，所以对它们的当前状态和可用性了解有限，因此需要手动配置。因此，WebSphere代理服务器只能检查TCP / IP通信级别的可用性以及托管该内容的服务器是否可用。

此外，WebSphere Application Server没有机会收集此类资源的路由信息，因此，也需要手动配置到非托管资源的路由。非托管内容资源的典型示例是HTTP服务器，其他J2EE™应用程序服务器等提供的资源，可以使用HTTP或HTTPS协议进行访问。

动态路由和核心组

可以使用WebSphere代理服务器以不同的方式完成路由，具体取决于托管内容的服务器的类型以及环境的构建方式。尽管托管内容资源启用了完全动态的请求路由，但非托管内容资源需要手动路由配置。

如前所述，动态路由仅适用于托管资源。托管资源的路由信息是通过高可用性管理器的公告板服务传播的。该服务基于核心组传播路由和可用性信息。这使得WebSphere代理服务器的路由配置与代理配置无关，而与核心组配置有关 。因此，可能的配置受到可能的核心组配置的限制。 WebSphere Application Server信息中心提供有关核心组桥接的详细信息。

由于核心组配置是WebSphere代理服务器路由配置任务的重要组成部分，因此需要对核心组和核心组术语有很好的了解。在本文中将使用以下核心组术语。（有关更多详细说明，请参阅WebSphere Application Server v7.0信息中心。）

核心组是高可用性管理器中的高可用性域。它定义了可以建立直接的高可用性关系的一组过程。高可用性组件只能故障转移到同一核心组中的进程。
接入点组定义了一组相互通信并可以交换高可用性信息的核心组。
接入点在核心组中定义了一组应用程序服务器，用于与其他核心组进行通信。在访问点中配置为桥接接口的应用程序服务器称为核心组桥接服务器 。
核心组桥接接口定义了节点，应用程序服务器以及用于跨核心组边界交换数据的传输通道链。
核心组桥接服务是WebSphere Application Server中与高可用性管理器相关的服务，它支持核心组之间的高可用性信息共享。
对等核心组是相互连接以交换与核心组相关的信息的核心组，但是它们位于不同的单元中。
对等访问点是用于对等核心组之间通信的访问点。核心组的每个对等访问点都需要在对等小区中有一个对应的核心组访问点。

样本配置

尽管配置的复杂性实际上是无限的，但是图2显示了将在本文中使用的示例拓扑，以演示动态路由功能和WebSphere代理服务器所需的配置。

图2.使用的样本拓扑

该拓扑由两个单元组成。第一个单元d0002承载代理服务器，并分为两个核心组，DefaultCoreGroup和WebCoreGroup。代理服务器是DefaultCoreGroup的成员。第二个单元d0003包含一个核心组DefaultCoreGroup。通过配置核心组桥接，单元d0002的代理服务器不仅可以将流量动态路由到同一核心组（d0002-DefaultCoreGroup）中的应用程序服务器，而且还可以动态路由到部署到不同核心组中的服务器的应用程序（d0002- WebCoreGroup），以及部署到其他单元的应用程序（d0003-DefaultCoreGroup）。

作为生产环境的最佳实践，将使用WebSphere Application Server安全性来保护环境。因此，将对单元内的所有管理通信进行身份验证，授权和加密。但是，管理员有责任确保与其他系统（例如LDAP服务器，数据库服务器等）的通信也安全。

同一单元和同一核心组中的WebSphere Application Server

在这种情况下，WebSphere代理服务器与托管应将请求路由到的应用程序的WebSphere Application Server位于相同的单元和相同的核心组中。图3显示了使用代理服务器群集的简单拓扑（出于高可用性和负载平衡的原因）。

图3.路由到同一核心组中的应用程序服务器

此配置是用于通过WebSphere代理服务器将请求路由到托管内容服务器的非常基本的设置。此设置仅需要最少的配置即可路由流量。实现WebSphere代理服务器并将流量路由到同一单元和核心组中的应用程序服务器的步骤仅要求为应用程序模块启用代理。它甚至不需要将模块映射到代理服务器。只需为应用程序模块设置“ 启用代理”选项就足够了。

同一单元但不同核心组中的WebSphere Application Server

在此设置中，代理服务器将流量路由到与代理服务器本身相同的核心组中的应用程序服务器，以及路由到同一单元的不同核心组中的托管内容服务器。

图4显示了一个单单元配置的拓扑，该拓扑使用代理服务器群集将请求路由到与代理服务器（DefaultCoreGroup）属于同一核心组的应用程序服务器以及不同的核心组（WebCoreGroup）。请注意，需要在这两个核心组之间配置核心组网桥，以使核心组能够交换状态和可用性信息。

图4.路由到同一单元的不同核心组中的应用程序服务器

如前所述，托管资源的路由和可用性信息是通过高可用性管理器公告板服务传播的。尽管核心组定义了WebSphere Application Server单元内交换可用性信息的边界，但是核心组桥接服务使同一单元内的核心组之间以及不同单元中的核心组之间的高可用性信息交换成为可能。

为确保代理服务器可以正确路由请求，每个核心组中至少必须有一个核心组桥接口服务器处于活动状态。出于可用性的原因，您应该在每个核心组的不同节点上配置两个核心组桥接口服务器。多于两个核心组桥接口服务器的配置会增加内存和CPU开销，因此仅应在经过深思熟虑的特定情况下进行。一个示例可能是，如果每个核心组的节点分布在两个以上的服务器上，并且弹性需要最大化，以便两个服务器的故障或维护不会中断核心组网桥通信。

此外，请记住，核心组桥接服务会消耗内存和CPU资源。因此，最佳实践是将专用服务器配置为充当核心组网桥接口服务器，并配置其监视策略以自动重启。

在同一单元中的两个核心组之间建立核心组桥接服务的基本步骤可以概括为：

定义一个访问点组（或使用现有的DefaultAccessPointGroup）。
为接入点组中的每个核心组配置核心组接入点。
为每个核心组访问点配置核心组桥接接口。

下一步将详细描述DefaultCoreGroup和WebCoreGroup之间的核心组网桥的配置。图2概述了所使用的拓扑。创建WebCoreGroup以及将所需的应用程序服务器分配给WebCoreGroup是设置核心组网桥的先决条件。

图5显示了管理控制台中的核心组桥接设置，其中在设置桥接之前配置了两个核心组。

图5.在桥接配置之前，两个核心组的核心组桥接设置

通常，使用一致的命名约定可使管理更轻松，更准确。

表1概述了用于配置示例拓扑的核心组网桥服务的配置对象。

表1.核心组网桥配置参数

细胞	核心小组	节点	核心组访问点名称	核心组网桥接口服务器	主机名/ IP地址	桥接口服务器的DCS端口
d0002	DefaultCoreGroup	hhuelinux_m00021	d0002_dft_ap01	d0002DftCgBr_01	hhuelinux	41266
d0002	DefaultCoreGroup	hhuelinux_m00022	d0002_dft_ap01	d0002DftCgBr_02	hhuelinux	42266
d0002	WebCoreGroup	hhuelinux_m00021	d0002_web_ap01	d0002WebCgBr_01	hhuelinux	41291
d0002	WebCoreGroup	hhuelinux_m00022	d0002_web_ap01	d0002WebCgBr_02	hhuelinux	42291

要在两个核心组之间设置核心组桥接，请执行以下步骤：

在单元d0002的WebSphere Application Server管理控制台中，导航至服务器>核心组>核心组网桥设置 。
核心组之间通过核心组访问点组进行通信。对于这种情况，要在同一单元中的两个核心组之间创建网桥，可以使用预定义的DefaultAccessPointGroup。通过使用DefaultAccessPointGroup为WebCoreGroup配置核心组桥接口服务器来添加核心组访问点。单击DefaultAccessPointGroup ，如图6所示。

图6.选择核心组访问点
单击核心组访问点以配置WebCoreGroup的核心组访问点（图7）。

图7.核心组访问点的配置

当接入点组还包含对等接入点时，每个核心组必须只有一个核心组接入点。

在核心组访问点面板中，可以通过选择现有核心组访问点并按显示详细信息来更新它们，也可以通过单击新建来创建新的核心组访问点。图8显示了如何选择核心组访问点以更新设置。

图8.选择一个核心组访问点以编辑其值

虽然不是必需的，但是最好给核心组访问点一个有意义的名称。

核心组访问点的配置基本上需要以下配置：
1. 核心组访问点名称。
2. 配置了接入点的核心组。
3. 桥接接口的定义。
4. 自定义属性。
输入核心组访问点的名称，然后从下拉框中选择为其定义访问点的核心组（图9）。按“ 应用”按钮，然后单击“ 桥接口”以配置桥接口服务器。

图9.重命名核心组访问点并选择网桥接口
对要添加到此核心组访问点的每个核心组桥接口服务器重复以下步骤：
1. 单击New添加一个新的网桥接口服务器（图10）。
2. 根据#Table 1 Coregroup网桥配置参数，从下拉框中选择应充当核心组网桥接口服务器的服务器。图10显示了为DefaultCoreGroup定义的网桥接口服务器。
图10.为DefaultCoreGroup配置的网桥接口服务器
对WebCoreGroup重复步骤5至9，以定义该核心组的桥接口服务器。
当核心组访问点组的所有核心组桥接服务器定义，回去的核心组桥接设置面板通过单击面包屑路径核心组网桥设置 。展开条目以检查核心组桥接设置。

核心组通信通过服务器的DCS端口运行。因此，在核心组位于由防火墙分隔的不同网络区域的情况下，请确保在防火墙上打开这些端口。

图11显示了DefaultAccessPointGroup，其中所有访问点，核心组桥接服务器及其属性均已扩展，从而概述了桥接配置和相关的网络配置。在单元d0002中的核心组桥接配置的概述中，您可以看到DefaultCoreGroup通过服务器d0002DftCgBr_01，d0002DftCgBr_02，d0002WebCgBr_01和d0002WebCgBr_02的DCS端口桥接到WebCoreGroup。

图11.具有所有网桥接口的核心组网桥设置

关闭并重新启动该访问点组中所有已配置的核心组网桥接口服务器，并通过JVM日志验证网桥是否正常工作。在日志中检查以下消息：

CWRCB0106I
CWRCB0107I

清单1

[11/27/11 16:38:37:081 IST] 00000008 CGBridge      I   CWRCB0106I: This core group
bridge service (d0002\hhuelinux_m0002 1\d0002DftCgBr_01) uses the following DCS
endpoint: 127.0.0.1:41266
[11/27/11 16:38:54:009 IST] 00000008 CGBridge      I   CWRCB0107I: This core group
bridge is stable and has the following Access Point Group member(s) available:
DefaultAccessPointGroup d0002:WebCoreGroup d0002\hhuelinux_m00021\d0002WebCgBr_01
(127.0.0.1:41291), d0002\hhuelinux_m00022\d0002WebCgBr_02 (127.0.0.1:42291)
DefaultAccessPointGroup d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr_01
(127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)

一旦确认核心组桥接服务正在运行，就可以通过WebSphere代理服务器访问两个核心组中的应用程序。要使用HTTP协议访问每个核心组中部署到WebSphere Application Server的应用程序，您需要在浏览器的URL中指定代理服务器的PROXY_HTTP_ADDRESS端口（例如80）。要通过HTTPS协议访问您的应用程序，请使用浏览器URL（例如443）中代理服务器的PROXY_HTTPS_ADDRESS端口。用于访问应用程序的主机名是WebSphere代理服务器的Internet主机名。因此，用于访问Information.ear Web模块的URL例如： https://proxyhost/info/Information.jsp ，而用于访问CoeTest.ear Web模块的URL为https://proxyhost/jdbctest/index.jsp 。

如果由WebSphere代理服务器路由的请求导致503 HTTP返回码（除其他外），则常见原因可能是：

核心组网桥无法正常工作。检查并验证每个核心组访问点中至少有一个核心组桥接服务器正在运行。
企业应用程序本身未启动。

现在是测试和确保可以通过代理服务器访问应用程序的好时机。基于图2中的示例拓扑，这些应用程序现在应该可以工作：

信息耳
CoETest.ear

请记住，每个核心组中至少必须有一个核心组网桥接口服务器已启动并正在运行。

请参阅WebSphere Application Server信息中心，以获取有关设置核心组网桥服务的详细信息。

与代理服务器位于不同单元中的WebSphere Application Server

在此设置中，代理服务器将流量路由到与代理服务器本身相同的核心组中的应用程序服务器，不同的核心组但在同一单元中的应用程序服务器以及远程单元中的托管内容服务器。

图12显示使用代理服务器群集将请求路由到与代理服务器（DefaultCoreGroup）属于同一核心组的应用程序服务器以及代理中不同核心组（WebCoreGroup）的配置的拓扑结构服务器的单元格（d0002）。在这种情况下，代理服务器还将请求路由到与代理服务器的单元不同的单元（d0003）中的应用程序服务器。如上一场景所示，需要在同一单元中的两个核心组之间配置一个核心组网桥。另外，必须在代理服务器的核心组和应将请求路由到的远程单元之间建立对等核心组桥接。

图12.路由到另一个单元中的应用服务器

如前所述，托管资源的路由和可用性信息是使用高可用性管理器的公告板服务传播的。但是，核心组定义了在WebSphere Application Server单元内交换可用性信息的边界。因此，您需要配置核心组网桥以启用核心组和单元之间的高可用性信息交换。将请求路由到一个单独的芯组在同一小区中的部署到服务器应用程序所需的核心组配置记录以上。在这里，我们将重点介绍将请求路由到远程单元中的服务器所需的核心组配置，也称为对等核心组网桥 。

要跨单元桥接核心组，请确保满足以下条件：

为确保代理服务器可以正确路由请求，每个核心组中至少必须有一个核心组桥接口服务器处于活动状态。出于可用性的原因，您应该在每个核心组的不同节点上配置两个核心组桥接口服务器。多于两个核心组桥接口服务器的配置会增加内存和CPU开销，因此仅应在经过深思熟虑的特定情况下进行。例如，如果每个核心组的节点分布在两个以上的服务器上，并且需要最大化弹性，以使两个服务器的故障或维护不会导致核心组网桥通信中断。

此外，请记住，核心组桥接服务会消耗内存和CPU资源。因此，最佳做法是将专用服务器配置为充当核心组网桥接口服务器，并配置其监视策略集以自动重启。

您要在其之间配置核心组网桥通信的单元必须具有唯一的名称。
用于连接两个对等核心组的核心组访问点组在每个单元中必须具有相同的名称。
每个接入点组必须包含：
- 一个本地组核心组的核心组访问点。
- 远程单元中每个核心组的一个核心组访问点。
- 必须使用相同的核心组桥接服务器在同一单元中的核心组之间进行桥接，并桥接至远程单元中的核心组。
在安全环境（通常是生产环境）中工作时，在跨单元设置核心组网桥时还需要考虑一些其他条件，即：
- 两个单元中的安全领域名称必须匹配。
- 单元必须彼此信任，因此必须在两个单元之间交换签名者证书。
- 单元之间的LTPA密钥必须交换。因此，除非采取适当的手动操作，否则LTPA密钥的自动再生将破坏核心组桥接。因此，您应该考虑禁用LTPA密钥的自动再生。

要在两个单元之间设置核心组桥接服务：

定义一个接入点组。请记住，接入点组名称在两个单元中必须匹配。
为接入点组中的每个核心组配置核心组接入点。
为每个核心组访问点配置核心组桥接接口。

以下步骤描述了单元d0002和d0003之间核心组网桥服务的配置。在两个单元中，核心组桥接口服务器将是DefaultCoreGroup的成员。

表2概述了用于配置核心组网桥服务的配置对象：

表2.对等核心组网桥的核心组网桥配置参数

细胞	核心小组	节点	核心组访问点名称	核心组网桥接口服务器	主机名/ IP地址	桥接口服务器的DCS端口
d0002	DefaultCoreGroup	hhuelinux_m00021	d0002_dft_ap01	d0002DftCgBr_01	hhuelinux	41266
d0002	DefaultCoreGroup	hhuelinux_m00022	d0002_dft_ap01	d0002DftCgBr_02	hhuelinux	42266
d0003	DefaultCoreGroup	hhuelinux_m00031	d0003_dft_ap01	d0003DftCgBr_01	hhuelinux	41366
d0003	DefaultCoreGroup	hhuelinux_m00032	d0003_dft_ap01	d0003DftCgBr_02	hhuelinux	42366

必须使用适当的配置值对每个单元执行设置此环境的必需步骤。首先，单元格d0002的配置步骤：

打开单元d0002的WebSphere Application Server管理控制台，然后导航至服务器>核心组>核心组网桥设置 。
选择对等访问点 ，如图13所示。

图13.对等接入点的配置
单击“ 新建”创建一个新的对等访问点。
根据表2中的配置值输入配置（图14）。

图14.创建一个新的核心组对等访问点
单击下一步转到下一个面板。
输入远程单元中第一个网桥接口服务器的DCS连接信息。在您的设置中，这是单元格d0003中DefaultCoreGroup的第一台核心组桥服务器。根据表2，这是服务器d0003DftCgBr_01的主机名和端口名。图15说明了第一个对等端口定义的配置。

图15.核心组访问点对等端口的配置
单击下一步转到摘要面板。
单击完成以完成第一个对等访问点的创建。
要添加其他对等访问点，请单击对等访问点名称，如图16所示。

图16.选择核心组对等访问点以添加端口
单击对等端口以添加其他访问点端口，以实现对等核心组网桥的高可用性（图17）。

图17.添加其他对等端口定义
单击“ 新建”以添加其他对等端口。
在远程单元中输入第二个网桥接口服务器的DCS连接信息。根据表2，这是服务器d0003DftCgBr_02的主机名和端口名。
再次单击Peer端口，以验证对等接入点的对等端口定义（图18）。

图18.对等端口定义的验证

配置核心组接入点组以桥接到d0003

下一步是为核心组桥接服务配置核心组访问点组。在创建核心组访问点组的过程中，可以在同一步骤中分配访问点和对等访问点。或者，您可以稍后将访问点信息分配给该组。对于此示例，您将首先创建一个空的接入点组，然后再分配该接入点和对等接入点。

请记住，接入点组名称必须在两个单元中都匹配。

在单元d0002的WebSphere Application Server管理控制台中，导航到服务器>核心组>核心组网桥设置>访问点组 ，然后单击新建。
在接入点组名称字段中输入要创建的核心组接入点组的名称 。在这种情况下，名称将为dft_d0002_to_dft_d0003 。
在接下来的三个面板中单击“ 下一步 ”，然后单击“ 完成” 。
单击刚刚创建的接入点组的名称，如图19所示。

图19.选择核心组访问点组以添加访问点
要分配对等访问点，请在“ 访问点”容器中单击“对等访问点 ”。
从可用的对等访问点容器中选择先前创建的对等访问点，然后单击向右箭头以将对等访问点分配给访问点组，如图20所示。

图20.将对等访问点添加到访问点组
单击确定。
接下来，将本地核心组的访问点分配给访问点组。如果单元仅包含一个核心组，则可以跳过此步骤。单击“ 访问点”容器中的“ 核心组访问点” ，如图21所示。

图21.将本地访问点添加到核心组访问点组

为了实现核心组网桥的最大弹性，每个网桥接口服务器应在单独的节点和单独的系统上运行。

核心组通信通过服务器的DCS端口运行。因此，如果核心组位于由防火墙分隔的不同网络区域中，请确保在防火墙上打开这些端口。

从可用的对等访问点容器中选择要添加的核心组访问点，然后单击向右箭头以将该访问点分配给该访问点组，如图22所示。在此示例中，您正在配置核心组网桥在单元格d0002中的DefaultCoreGroup和单元格d0003中的DefaultCoreGroup之间。因此，必须选择d0002_dft_ap01 \ DefaultCoreGroup访问点并将其添加到核心组访问点组。

图22.选择要添加到核心组的访问点
单击确定。
单击面包屑试用版中的核心组桥接设置 。展开条目以验证核心组桥接设置。

图23.单元d0002的核心组网桥配置概述

图23显示了单元d0002的两个核心组访问点组，其中所有访问点，核心组网桥服务器及其属性都得到了扩展，从而概述了网桥配置和相关的网络配置。在单元d0002中的核心组桥接配置概述中，您可以看到单元d0002的DefaultCoreGroup通过服务器d0002DftCgBr_01和d0002DftCgBr_02被桥接到单元d0003的DefaultCoreGroup。核心组桥接流量在这两个服务器之间以及具有DCS端口的服务器之间侦听服务器hhuelinux.huebler.at:41366和hhuelinux.huebler.at:42366之间的流量。

这样就完成了单元d0002的核心组网桥配置。

单元d0003的核心组网桥配置

接下来，您将对单元格d0003重复相同的配置步骤。必须使用等效命名对单元d0003执行这些步骤。可以再次从表2中确定配置值。由于步骤基本相同，因此在此简单总结：

在d0003的WebSphere Application Server管理控制台中，导航到服务器>核心组>核心组网桥设置 。
由于单元d0002和d0003之间的核心组访问点组名称必须匹配，因此第一步是创建名为dft_d0002_to_dft_d0003的核心组访问点组。
单击核心组访问点组名称，然后选择核心组访问点 。
在可用核心组访问点下，单击CGAP_1 \ DefaultCoreGroup，然后选择显示详细信息 。
根据表2重命名核心组访问点并添加网桥接口服务器。图9中详细显示了所需的步骤。
将d0003_dft_ap01核心组访问点添加到核心组访问点组dft_d0002_to_dft_d0003。
如图13所示，为单元d0002配置对等访问点，并将对等访问点d0002_dft_peer_ap01添加到核心组访问点组dft_d0002_to_dft_d0003。
单元d0003的核心组网桥配置应类似于图24所示。

图24.单元d0003的核心组网桥配置
关闭并重新启动两个单元中所有已配置的核心组网桥接口服务器。

启动单元d0002的核心组桥服务器，并通过核心组桥服务器的JVM日志验证桥是否在工作。在日志中检查以下消息：

CWRCB0106I
CWRCB0107I

仅启动单元d0002的核心组桥服务器并验证单元d0002的DefaultCoreGroup的核心组桥服务器的SystemOut.log之后，清单2中显示的消息表明到WebCoreGroup的桥工作正常。但是，针对接入点组dft_d0002_to_dft_d0003的消息NO BRIDGES指示到单元d0003的网桥目前不可用。

清单2

[12/6/11 12:08:58:846 IST] 0000000b CGBridge      I   CWRCB0106I: This core group
bridge service (d0002\hhuelinux_m00021\d0002DftCgBr_01) uses the following DCS
endpoint: 127.0.0.1:41266
[12/6/11 12:08:58:850 IST] 0000000b CGBridge      I   CWRCB0107I: This core group
bridge is stable and has the following Access Point Group member(s) available:
DefaultAccessPointGroup d0002:WebCoreGroup d0002\hhuelinux_m00021\d0002WebCgBr_01
(127.0.0.1:41291), d0002\hhuelinux_m00022\d0002WebCgBr_02 (127.0.0.1:42291)
DefaultAccessPointGroup d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr
_01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)
dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup NO BRIDGES
dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr
_01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)

启动单元d0003的核心组桥服务器，并通过核心组桥服务器的JVM日志验证桥是否在工作。在日志中检查以下消息：

CWRCB0106I
CWRCB0107I

启动单元d0003的核心组桥服务器并验证单元d0003的DefaultCoreGroup的核心组桥服务器的SystemOut.log之后，接入点组dft_d0002_to_dft_d0003的消息NO BRIDGES仍然指示到单元d0002的桥不可用，尽管核心组网桥接口服务器已启动并正在运行（清单3）。

清单3

[12/6/11 13:19:19:685 IST] 00000009 CGBridge      I   CWRCB0106I: This core group
bridge service (d0003\hhuelinux_m00031
\d0003DftCgBr_01) uses the following DCS endpoint: 127.0.0.1:41366
[12/6/11 13:19:19:694 IST] 00000009 CGBridge      I   CWRCB0107I: This core group
bridge is stable and has the following Access Point Group member(s) available:
dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01
(127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366)
dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup NO BRIDGES
[12/6/11 13:19:19:702 IST] 00000009 CGBridge      I   CWRCB0108I: The core group
bridge service is currently unstable for Access Point Group(s) DefaultAccessPoint
Group.
[12/6/11 13:19:21:487 IST] 0000000a CGBridge      I   CWRCB0106I: This core group
bridge service (d0003\hhuelinux_m00031\d0003DftCgBr_01) uses the following DCS
endpoint:
127.0.0.1:41366
[12/6/11 13:19:21:495 IST] 0000000a CGBridge      I   CWRCB0107I: This core group
bridge is stable and has the following Access Point Group member(s) available:
DefaultAccessPointGroup d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01
(127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366)
dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01
(127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366)
dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup NO BRIDGES

对SystemOut.log的进一步检查显示，还引发了HMGR0149E错误消息（清单4），从而使您成为问题的核心。

清单4

[12/6/11 13:19:41:763 IST] 00000023 DefaultTokenP E   HMGR0149E: An attempt to open
a connection to core group dft_d0002_to_dft_d0003 has been rejected. The sending
process has a name of 127.0.0.1:41266 and an IP address of /127.0.0.1. Global
security in the local process is Enabled. Global security in the sending process
is Enabled. The received token starts with lf>c%$oO. The exception is com.ibm.
websphere.security.auth.WSLoginFailedException: Validation of LTPA token failed due
to invalid keys or token type. at com.ibm.ws.security.ltpa.LTPAServerObject.validateToken
(LTPAServerObject.java:1161) at com.ibm.ws.security.ltpa.LTPAServerObject.validateToken
(LTPAServerObject.java:1078) at com.ibm.ws.security.token.WSCredentialTokenMapper.validateLTPAToken
(WSCredentialTokenMapper.java:1376) at com.ibm.ws.hamanager.runtime.DefaultTokenProvider.authenticateMember
(DefaultTokenProvider.java:214) at com.ibm.ws.hamanager.coordinator.dcs.MemberAuthenticatorImpl.
authenticateMember(MemberAuthenticatorImpl.java:87) at com.ibm.ws.dcs.vri.transportAdapter.rmmImpl.ptpDiscovery.DiscoveryRcv.
acceptStream(DiscoveryRcv.java:185) at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor.fetchStream(Packet
Processor.java:470)
at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor.run(PacketProcessor.java:860)

之所以收到HMGR0149E错误消息，是因为您试图在启用安全性的两个单元之间建立核心组桥接（在任何生产环境中都应该如此），但尚未在单元之间设置SSO。

核心组网桥服务使用LTPA身份验证机制进行跨单元身份验证。

您需要遵循在WebSphere Application Server中使用LTPA cookie设置进行的轻量级第三方认证和单点登录来进行认证，才能通过LTPA对等核心组网桥进行认证。要考虑的关键点可以概括为：
- 单元之间共享LTPA密钥。为避免将来出现问题，应禁用自动重新生成，并应重新生成和手动分发新密钥。
- 服务器的日期和时间必须同步。
- 用户注册表必须是集中管理的注册表，例如LDAP或Windows®Active目录。
- 如果您正在使用实现LDAPS协议的安全环境来连接到LDAP服务器，则将LDAP服务器的服务器证书的签署者证书导入到WebSphere代理服务器正在使用的信任库中。缺省情况下，这是WebSphere Application Server V7.0中的CellDefaultTrustStore。

使用SSL访问站点时，需要将内容服务器的服务器证书的签署者证书添加到代理所使用的信任存储中。确保将签名者证书确实添加到代理使用的信任存储中，而不是服务器证书中！由于WebSphere Application Server使用一种小型CA，因此使用一个签署者证书来签署单元的所有证书。因此，通常在两个单元之间交换签署者证书（根）即可。

如果您打算使用HTTPS协议来访问您的网页，那么WebSphere代理服务器将使用SSL通过WC_defaulthost_secure端口访问托管应用程序的服务器。尽管通常只要服务器位于同一单元中（这是WebSphere Application Server V7.0和更高版本中的缺省值；该单元中的所有服务器都相互信任），这通常就没有问题，但是如果代理服务器需要交换签署者证书，服务器和内容服务器位于不同的单元中。未能交换签名者证书，将导致CWPKI0022E：SSL握手失败：错误消息，随后出现CWPKI0428I：签名者可能需要添加到代理服务器的SystemOut.log中的本地信任存储错误消息中。在这种情况下，最终用户将获得503服务不可用响应代码。

处理完上述要点并重新启动服务器后，代理单元（在我们的方案中为d0002）默认核心组的核心组桥服务器应包含正确的消息，指示在两者之间建立了核心组桥服务细胞。在日志中检查以下消息：

CWRCB0106I
CWRCB0107I

清单5

[12/7/11 14:43:05:039 IST] 0000000b CGBridge      I   CWRCB0106I: This core group
bridge service (d0002\hhuelinux_m00021\d0002DftCgBr_01) uses the following DCS
endpoint: 127.0.0.1:41266
[12/7/11 14:43:05:045 IST] 0000000b CGBridge      I   CWRCB0107I: This core group
bridge is stable and has the following Access Point Group member(s) available:
DefaultAccessPointGroup d0002:WebCoreGroup d0002\hhuelinux_m00021\d0002WebCgBr_01
(127.0.0.1:41291), d0002\hhuelinux_m00022\d0002WebCgBr_02 (127.0.0.1:42291)
DefaultAccessPointGroup d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr
_01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)
dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01
(127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366)
dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr_01
(127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)

一旦确认核心组桥接服务正在运行，就可以通过WebSphere代理服务器访问两个核心组中的应用程序。要使用HTTP协议访问每个核心组中部署到WebSphere Application Server的应用程序，您需要在浏览器的URL（此示例中为80）中指定代理服务器的PROXY_HTTP_ADDRESS端口。要通过HTTPS协议访问您的应用程序，请在浏览器的URL（此示例中为443）中使用代理服务器的PROXY_HTTPS_ADDRESS端口。用于访问应用程序的主机名是WebSphere代理服务器的Internet主机名。

因此，用于访问Information.ear Web模块的URL例如为： https://proxyhost/info/Information.jsp ，用于访问CoeTest.ear Web模块的URL为https://proxyhost/jdbctest/index.jsp 。按照相同的规则，可以使用URL https://proxyhost/dft/snoop通过WebSphere代理服务器访问使用/ dft上下文根部署到单元d0003的Web模块DefaultApplication.ear。

如果由WebSphere代理服务器路由的请求导致503 HTTP返回码或类似的返回码，这是最常见的原因：

核心组网桥无法正常工作。检查并验证每个核心组访问点中至少有一个核心组桥接服务器正在运行。
企业应用程序本身未启动。
跨不同单元的SSL设置问题。

现在是时候测试并确保可以通过代理服务器访问以下应用程序。根据图2中概述的示例拓扑，这些应用程序现在应该可以工作：

信息耳
CoETest.ear
DefaultApplication.ear

请记住，每个核心组中至少必须有一个核心组网桥接口服务器已启动并正在运行。

路由到非托管资源

与托管资源和动态路由相反，必须对非托管资源执行手动路由配置，因为非托管资源不受WebSphere Application Server的管理和控制。因此，无法通过核心组机制交换状态信息。

图25显示了如何使用WebSphere代理服务器将请求路由到非托管服务器。它说明了需要将处理请求的非托管服务器配置为WebSphere Application Server中的通用服务器集群的成员。

图25.请求到非托管服务器的路由。

通用服务器集群的配置

使用WebSphere代理服务器将请求路由到非托管资源的第一步是在WebSphere Application Server中配置通用服务器集群。要在WebSphere Application Server单元中配置通用服务器集群：

在托管WebSphere代理服务器的单元的管理控制台中，导航至服务器>集群>通用服务器集群>新建 。
输入要创建的通用服务器集群的名称以及要使用的协议（HTTP或HTTPS）（图26）。

图26.通用服务器集群创建
创建通用服务器集群后，输入连接信息以及每个集群成员的权重。图27显示了通用服务器集群成员的配置。您需要以主机名/ IP地址和端口以及权重的形式指定TCP / IP连接信息。权重不应为零，因为权重为零意味着没有请求将被路由到此集群成员。另外，该图显示了来自IBM HTTP Server配置的匹配配置键伪指令。

图27.通用服务器集群成员创建
在通用服务器集群定义中注册通用服务器集群的每个成员。这使WebSphere代理服务器可以在集群成员之间实现负载平衡和故障转移功能：
- 负载平衡是加权循环算法，类似于Web服务器插件使用的算法。
- 由于通用服务器群集的成员仅通过HTTP或HTTPS连接，因此故障检测受到TCP / IP功能的限制。一旦WebSphere代理服务器确定了通用服务器集群成员之一的故障，它将通过尝试建立连接来定期（每五秒钟）检查服务器是否再次可用。
如果使用HTTPS协议，则必须确保非托管服务器的服务器证书的签署者证书在WebSphere代理服务器正在使用的信任存储区中。缺省情况下，这是WebSphere Application Server V7.0和更高版本中的CellDefaultTrustStore。

完成这些步骤后，通用服务器集群的基本WebSphere配置完成。有关配置通用服务器集群的更多详细信息，请参阅WebSphere Application Server信息中心。

将配置路由到通用服务器集群

由于通用服务器集群表示非托管资源，因此WebSphere Application Server无法识别通过通用服务器集群可用的任何应用程序。因此，需要手动配置，以便代理“知道”要转发到通用服务器群集的请求。

对于托管资源，路由决策基于启用了代理路由的Web模块的上下文根，如前所述。要对非托管资源实现相同的功能，您需要配置一个URIgroup，该URIgroup主要提供上下文根和“路由规则”。 WebSphere Application Server中的这两个配置项使代理能够为非托管资源做出路由决策。

以下是创建URIgroup和路由规则的最少步骤：

URI组定义中使用的URI模式必须存在于每个通用集群成员上。此模式是转发到目标服务器的请求的一部分。

在托管WebSphere代理服务器的单元的管理控制台中，导航至服务器>服务器类型> WebSphere代理服务器> <代理名称> <HTTP代理服务器设置>代理设置> URI组>新建 。图28显示了一个URI组的配置，该组基本上由一个符号名和一个或多个URI模式组成。将WebSphere代理服务器正在处理的每个请求与这些URI模式进行比较，以确定该请求是否属于该URI组。

图28. URI组定义屏幕
一旦配置了URI组，就必须显式配置路由，以便WebSphere代理服务器知道将请求路由到何处。通过管理控制台，再次导航至： 服务器>服务器类型> WebSphere代理服务器> <proxy_name >> HTTP代理服务器设置>路由规则>新建 。
图29显示了代理服务器的路由规则的基本配置。该规则基本上是通过指定符号名称并选择此规则适用的WebSphere虚拟主机和URI组来定义的。在“路由操作”下，选择“ 通用服务器群集”的单选按钮，然后从下拉框中选择通用服务器群集。确保已选中“ 启用此规则”复选框。

图29.路由规则配置屏幕
重新启动WebSphere代理服务器。
通过发送与URI组定义的URI模式匹配的请求，测试对非托管资源的访问。

有关WebSphere代理服务器的路由规则配置的更多详细信息，请参阅WebSphere Application Server信息中心。

结论

本文讨论了WebSphere代理服务器可以使用的各种资源类别以及WebSphere代理服务器提供的路由功能。提供了有关示例拓扑的详细说明，以突出显示几种配置方案中的依赖性和可能的问题。希望这些信息将帮助您成功地快速实施任何给定方案。

翻译自: https://www.ibm.com/developerworks/websphere/techjournal/1201_huebler/1201_huebler.html