此版本适用于:
及所有后续发行版和修订版,直到在新版本中另有声明为止。
通过您当地的 IBM 代表或 IBM 分部可订购出版物。
本书(《WebSphere(R) Application Server Edge Components 的概念、规划和安装》)提供 WebSphere Application Server Edge components 的介绍。它提供高级产品概述、关键组件的详细功能性讨论、网络边际方案、安装和初始配置信息,以及演示用网络。
《WebSphere Application Server Edge Components 的概念、规划和安装》是为熟悉操作系统和因特网服务的、有经验的网络和系统管理员编写的。用户不需要事先了解 WebSphere Application Server 或 WebSphere Application Server Edge components。
辅助功能部件帮助有身体障碍的用户(如行动不便或有视力障碍的用户)顺利地使用软件产品。以下这些是 WebSphere Application Server,版本 6.1 的主要辅助功能部件:
本文档使用以下印刷和键入约定。
约定 | 含义 |
---|---|
粗体 | 当提及图形用户界面(GUI)时,粗体用于表示菜单、菜单项、标签、按钮、图标和文件夹。它还用于强调命令名,否则它们可能会与周围的文本相混淆。 |
等宽字体 | 表示您必须在命令提示符下输入的文本。等宽字体还表示屏幕文本、代码示例和文件摘录。 |
斜体 | 表示您必须提供的变量值(例如,您为 fileName 提供的文件名)。斜体还表示强调和书标题。 |
Ctrl-x | 其中 x 是键的名称,表示“control-字符”序列。例如,Ctrl-c 意味着在按下 c 键时已按住 Ctrl 键。 |
Return | 指标有 Return、字 Enter 字样或左箭头的键。 |
% | 表示 Linux 和 UNIX(R) 命令 shell 提示符,用于不需要 root 用户特权的命令。 |
# | 表示 Linux 和 UNIX 命令 shell 提示符,用于需要 root 用户特权的命令。 |
C:\ | 表示 Windows 命令提示符。 |
输入命令 | 当指示“输入”或“发出”某条命令时,输入此命令然后按 Return 键。例如,指示“输入 ls 命令”意味着在命令提示符下输入 ls,然后按 Return 键。 |
[ ] | 括住语法描述中的可选项。 |
{ } | 括住列表,从中您必须选择一个语法描述项。 |
| | 分隔语法描述中用 { }(花括号)括住的选项列表中的项。 |
... | 语法描述中的省略号表示您可以一次或多次重复先前项。示例中的省略号表示为了简明扼要起见而从示例中省略的信息。 |
这一部分介绍 WebSphere Application Server Edge components(Caching Proxy 和 Load Balancer),并讨论与 Application Server 集成在一起的这些组件。它还定义了Caching Proxy 和 Load Balancer 组件。另外,本节将介绍其他相关的 WebSphere 系列产品。
这一部分包含以下章节:
WebSphere 是因特网基础结构软件,它允许公司开发、部署和集成下一代的电子商务应用程序,如那些企业到企业的电子交易的应用程序。WebSphere 中间件支持从简单 Web 发布到企业范围事务处理的业务应用程序。
作为 WebSphere 平台的基础,WebSphere Application Server 提供全面的中间件集,使用户能够设计、实现、部署和管理业务应用程序。 这些应用程序包括简单 Web 站点前台到组织的计算基础结构的整个版本。
处理器密集型的功能部件(如个性化)为每个电子商务提供竞争优势。 然而,习惯上将这些功能部件委托给中央服务器,可限制因特网由于不断增加重要的功能而膨胀。 所以,随着新 Web 应用程序量的持续增加,商家的因特网基础结构还必定增加其范围和影响力。 另外,可靠性和安全性对电子商务也格外重要。即使最小限度的服务受到损害,也会导致商务上受到损失。
Edge components(以前称为 Edge Server)现在是 WebSphere Application Server 产品的一部分。Edge components 可与 WebSphere Application Server 联合使用,以控制客户机对 Web 服务器的访问,且允许商务企业为那些通过因特网或企业内部网访问基于 Web 内容的用户提供更佳服务。 使用 Edge components 可减少 Web 服务器阻塞,增加内容的可用性和提高 Web 服务器性能。 正如名称所示,Edge components 通常运行在靠近(在网络配置意义上)企业内部网和因特网间边界上的机器上。
WebSphere Application Server 包含 Caching Proxy 和 Load Balancer Edge components。
要点:Caching Proxy 在所有 Edge component 安装版本上提供,但下列情况例外:
Caching Proxy 通过提供一个或多个后端内容服务器的存在点节点,减少带宽的使用和提高 Web 站点的速度和可靠性。Caching Proxy 可高速缓存和服务静态内容和 WebSphere Application Server 动态生成的内容,并为它们提供服务。
Caching Proxy 可在逆向代理服务器或正向代理服务器的角色中配置(前者是缺省配置),同时提供带有改善请求和响应时间任务的网络或内部网络服务器的存在点。有关逆向配置和正向配置的更多信息,请参阅基本 Caching Proxy 配置。
代理服务器拦截来自客户机的数据请求、从托管内容的机器中检索请求的信息并将此内容发回客户机。最常见的情况是,请求针对的是存储在 Web 服务器(也称为源服务器或内容主机)上的文档,并使用超文本传输协议(HTTP)发送请求。但是,您可以配置代理服务器处理其他协议,如文件传输协议(FTP)和 Gopher。
在将可高速缓存的内容发送给请求者之前,代理服务器会将这些内容存储到本地高速缓存中。 可高速缓存内容的示例包含静态 Web 页面和动态生成但极少变化的 JavaServer Page 文件。 通过从本地高速缓存中直接发送上述这些内容,高速缓存使得代理服务器能够满足针对相同内容的后续请求,与再次从内容主机检索这些内容相比,其速度要快得多。
Caching Proxy 的插件为代理服务器添加一些功能。
您可通过编写定制插件模块到应用程序编程接口(API)进一步扩展 Caching Proxy 的功能。API 灵活、易于使用,且与平台无关。代理为要处理的每个客户机请求执行一系列步骤。 插件应用程序将修改或替换请求处理工作流中的一个步骤,如客户机认证或请求过滤。 例如,功能强大的转换接口提供对 HTTP 数据的访问和允许替代或变换 URL 和 Web 内容。 插件可修改或替换指定处理步骤,并且您可为一特定步骤调用多个插件。
Load Balancer 创建可导向网络流量流动的网络边际系统,减少阻塞并平衡各种其他服务和系统间的负载。Load Balancer 提供站点选择、工作负载管理、会话亲缘关系和透明故障转移。
Load Balancer 安装在因特网和企业的后端服务器之间,它可以是内容主机或 Caching Proxy 机器。 在因特网上,即使企业为满足高需求或存放大量内容而使用多个后端服务器,Load Balancer 都将作为企业的单个存在点节点。您也可以安装备份 Load Balancer,以在主 Load Balancer 发生临时故障时,可由它进行接管,从而保证高可用性。
Load Balancer 拦截来自客户机的数据请求,并将每个请求转发到当前可最佳满足该请求的服务器。换句话说,它在一组定义的机器中对到达的请求进行负载均衡,这些机器用于为相同类型的请求提供服务。Load Balancer 可将请求分发到多种类型的服务器,包括 WebSphere Application Server 和 Caching Proxy 机器。可使用定制顾问程序为特定应用程序或平台定制负载均衡。特殊目的的顾问程序可用于获得用于负载均衡 WebSphere Application Server 的信息。
如果基于内容路由组件与 Caching Proxy 安装在一起,则 HTTP 和 HTTPS 请求甚至可以根据 URL 或其他由管理员确定的特征进行分发,这样就不必将同样的内容存储在所有后端服务器上。分派器组件还可提供 HTTP 请求的相同功能。
负载均衡通过显式集群内容服务器来提高 Web 站点的可用性和可伸缩性,此处的内容服务器包含 HTTP 服务器、应用程序服务器和代理服务器,它们是代用品内容服务器。可用性是通过并行性、负载均衡和故障转移支持来完成的。当服务器当机时,业务不会被中断。由于可明显增加后端的处理能力,因此可显著提高基础结构的可伸缩性。
对 IPv6 的支持:在“Load Balancer for IPv4 和 IPv6”中提供了对 IPv6 扩展 IP 地址模式的支持。Load Balancer for IPv4 和 IPv6 是只包含“分派器”组件的独立安装映象。此安装类型对目标为在使用基于分派器 MAC 信息包转发的网络中配置的服务器的 IPv4 和 IPv6 流量提供负载均衡。请注意,在安装 Load Balancer for IPv4 和 IPv6 之前,必须卸载先前的 Load Balancer。不能在同一台机器上安装两个 Load Balancer。(有关“分派器”组件的简要概述,请参阅 分派器。)
Load Balancer 包含以下组件:
对于所有因特网服务(如 HTTP、FTP、HTTPS 和 Telnet),分派器组件对局域网(LAN)或广域网(WAN)中的服务器执行负载均衡。对于 HTTP 服务,分派器可基于客户机请求的 URL 内容执行服务器的负载均衡。
分派器组件能够对大型可伸缩的服务器网络进行稳定、有效管理。使用分派器,您可将许多单独服务器链接为如同一个虚拟服务器。这样,站点对外可作为一个 IP 地址。
如果正在使用 Load Balancer for IPv4 和 IPv6 安装,请参阅《WebSphere Application Server Load Balancer 管理指南》中有关在 Load Balancer for IPv4 和 IPv6 上部署分派器的章节,它包括了有关限制和配置差别的信息。
对于 HTTP 和 HTTPS 服务,基于内容路由组件根据客户机请求的内容对服务器执行负载均衡。基于内容路由组件与 Application Server Caching Proxy 组件联合工作。
要点:基于内容路由(CBR)组件在所有受支持的平台上提供,但下列情况例外:
或者,对于这种安装类型,可以使用 Load Balancer' 的 分派器 组件的 cbr 转发方法来为 HTTP 和 HTTPS 请求提供基于内容路由,而不用使用 Caching Proxy。有关更多信息,请参阅《WebSphere Application Server Load Balancer 管理指南》。
Load Balancer for IPv4 和 IPv6 只支持 分派器 组件的 mac 转发方法。不支持 nat 和 cbr 转发方法。
站点选择器组件通过将它作为网络的存在点节点操作来增强负载均衡系统,通过将 DNS 名称映射到 IP 地址来负载均衡进入请求。 与度量服务器联合使用时,站点选择器可以监视服务器上的活动级别,检测何时服务器的负载最轻,以及检测发生故障的服务器。
所有 Edge component 安装都支持此组件,下列情况例外:
Cisco CSS 控制器组件生成服务器加权度量,并将这些度量发送到 Cisco CSS 交换机以进行服务器选择、负载优化和容错。
所有 Edge component 安装都支持此组件,下列情况例外:
Nortel Alteon 控制器组件生成服务器加权度量,并将这些度量发送到 Nortel Alteon 交换机以进行服务器选择、负载优化和容错。
所有 Edge component 安装都支持此组件,下列情况例外:
度量服务器组件是作为负载均衡服务器上的守护程序运行的,并提供给 Load Balancer 组件有关系统负载的信息。
IBM WebSphere 系列是为帮助用户实现电子商务的目的而设计的。 它是一组帮助用户开发和管理高性能 Web 站点和将新的或现有的非 Web 商务信息系统集成到 Web 站点的软件产品。
WebSphere 系列由 WebSphere Application Server 组成,包括 Edge components 和其他 WebSphere 系列软件,它与 WebSphere Application Server 紧密集成在一起,并增强其性能。要获得 WebSphere Application Server 及其组件的概述,请参阅WebSphere Application Server Edge components 介绍。
Tivoli Access Manager(先前称为 Tivoli Policy Director)可单独使用。它为现有 Web 应用程序提供了访问控制和集中式安全性,以及提供了访问多个 Web 资源时的一次认证能力。Caching Proxy 插件利用 Access Manager 的安全性框架,它使代理服务器能使用 Access Manager 的集成授权或认证服务。
WebSphere Portal Server(可单独使用)提供框架以满足与门户网站关联的表示、安全性、可伸缩性和可用性问题。 使用 Portal Server,公司可构建它们自己的定制门户网站 Web 站点,以为职员、业务合作伙伴和客户的需要提供服务。用户可注册到门户网站,并接收个性化的 Web 页面,这些 Web 页面提供了对用户需要的信息、人员和应用程序的访问。对所有必需资源的这种个性化单点访问减少了信息过载、提高了效率和增加 Web 站点的使用。
WebSphere Portal Server 运行在 WebSphere Application Server 集群中,以达到可伸缩性和可靠性的目的。Application Server Load Balancer 组件还可用于其他负载均衡和高可用性。
WebSphere Site Analyzer(可单独使用)帮助企业预见到容量和性能的问题。 有了 Site Analyzer,Caching Proxy 和 Load Balancer 日志及其他易于管理的辅助程序可通过监视、分析和报告 Web 站点使用情况来预见其他资源的需求。 另外,Site Analyzer 管理性组件可帮助用户安装和升级 Edge components、管理和存储配置、远程操作 Edge components 和查看并报告事件。
WebSphere Transcoding Publisher(可单独使用)可转换 Web 页面以供在移动设备(如具有使用因特网能力的电话)上进行查看、将 Web 内容转换成用户首选的本地语言(通过调用 WebSphere Translation Server)和转换标记语言。Transcoding Publisher 允许为不同的设备和用户提供服务,这增强了 Caching Proxy 的能力。在访问来自 Web 服务器的内容之后,可配置 Caching Proxy 的转换接口来调用 Transcoding Publisher 进行变换数据和标记,以便进行不同的高速缓存和可能的重用。在 Caching Proxy 的登记认证接口上,Transcoding Publisher 将检查代理服务器以查找用户和设备需要匹配的内容,如果找到匹配的,则提供代理服务器高速缓存中内容。
以下特定于 WebSphere Application Server Edge Components 的文档在 Edge Components 信息中心中可找到。
其他 WebSphere Application Server 文档在 WebSphere Application Server 库页面上可找到。
Edge Components 的技术说明支持信息可从 WebSphere Application Server Support 页面获得。
以下是包含关于 Edge Components 或相关信息的 Web 站点的列表。
这一部分包含对 Edge components 中一些重要可用功能的详细讨论。请参阅WebSphere Application Server Edge components 介绍,以获取 Application Server 的 Caching Proxy 组件的概述。
这一部分包含以下章节:
Caching Proxy 的高速缓存功能帮助最大程度减少网络带宽使用率,并确保最终用户接收更快、更可靠的服务。 这是因为由代理服务器执行的高速缓存将卸载后端服务器和对等链接来完成。Caching Proxy 可高速缓存静态内容和 WebSphere Application Server 动态生成的内容。为了增强高速缓存能力,Caching Proxy 还能与 Application Server Load Balancer 组件联合运行。请参阅WebSphere Application Server Edge components 介绍,以获得这些系统的介绍。
要点:Caching Proxy 在所有 Edge component 安装版本上提供,但下列情况例外:
Caching Proxy 可在逆向 Caching Proxy 服务器或正向 Caching Proxy 服务器的角色中配置(前者是缺省配置)。当 Caching Proxy 由内容主机使用时,它是在逆向 Caching Proxy 服务器的角色中配置的,位于因特网与企业的内容主机之间。当 Caching Proxy 由因特网访问提供商使用时,它是在正向 Caching Proxy 服务器的角色中配置的,位于客户机与因特网之间。
当使用逆向代理配置时,Caching Proxy 机器位于因特网和企业的内容主机之间。代理服务器充当代用品时,会拦截来自因特网的用户请求、将这些请求转发给适当的内容主机、高速缓存返回的数据并将此数据通过因特网发送给用户。高速缓存使 Caching Proxy 能立即满足与高速缓存中相同内容的后续请求,这比再次从内容主机检索要快得多。可高速缓存信息取决于信息的到期时间、高速缓存的大小和信息更新时间。从高速缓存命中更快地下载意味着为客户提供更佳的服务质量。图 1 描绘了这种基本 Caching Proxy 功能。
图注:1--客户机 2--因特网 3--路由器/网关 4--Caching Proxy 5--高速缓存 6--内容主机在此配置中,代理服务器(4)拦截 URL 中包含内容主机的主机名(6)的请求。当客户机(1)请求文件 X 时,请求穿越因特网(2)并通过它的因特网网关(3)进入企业的内部网络。 代理服务器会拦截请求,并用其自身的 IP 地址作为源地址生成新请求,然后将新请求发送到内容主机(6)。
内容主机将文件 X 返回到代理服务器,而不是直接返回到最终用户。如果文件是可高速缓存的,那么 Caching Proxy 在将它传递到最终用户之前在其高速缓存(5)中存储一个副本。可高速缓存内容的最显著示例是静态 Web 页面;然而,Caching Proxy 还提供了高速缓存和服务 WebSphere Application Server 动态生成的内容的能力。
向最终用户提供直接因特网访问的效率可能会很低。从 Web 服务器访存给定文件的每个用户在网络中产生等量的流量并且都作为访存该文件的第一个用户通过因特网网关,即使该文件根本就没有更改过。解决方案是在网关附近安装一个正向 Caching Proxy。
当使用正向代理配置时,Caching Proxy 机器位于客户机与因特网之间。Caching Proxy 将客户机的请求转发给位于因特网中的内容主机、高速缓存检索到的数据并将检索到的数据发送给客户机。
图 2 描绘了正向 Caching Proxy 配置。客户机的浏览器程序(在标记为 1 的机器上)配置为将请求转发给正向 Caching Proxy(2),而正向 Caching Proxy 配置为拦截请求。当某个最终用户请求存储在内容主机(6)上的文件 X 时,正向 Caching Proxy 拦截该请求、生成新的请求(将它自己的 IP 地址用作源地址)并通过因特网(5)经企业的路由器(4)发出新请求。
通过这种方法,源服务器将文件 X 返回给正向 Caching Proxy 而不是直接返回给最终用户。如果启用了正向 Caching Proxy 的高速缓存功能,则 Caching Proxy 通过检查其返回头中的设置(例如截止日期和该文件是否动态生成的指示)确定文件 X 是否适合高速缓存。如果该文件可高速缓存,则 Caching Proxy 先在其高速缓存(3)中存储一个副本,然后再将该文件传送给最终用户。在缺省情况下,会启用高速缓存功能并且正向 Caching Proxy 使用内存高速缓存;但是,可以配置其他类型的高速缓存。
对于对文件 X 的第一个请求,正向 Caching Proxy 对因特网访问效率的提高不是很明显。实际上,访问文件 X 的第一个用户的响应时间可能比不使用正向 Caching Proxy 的响应时间要慢一些,原因是正向 Caching Proxy 需要多一些的时间来处理原始请求包以及在接收到文件 X 时检查它的头以了解它是否可高速缓存。使用正向 Caching Proxy 在其他用户接着请求文件 X 时发挥其优点。正向 Caching Proxy 检查它高速缓存的文件 X 的副本是否还有效(未到期),如果有效,则它直接从高速缓存处理文件 X,无须通过因特网将请求转发给内容主机。
即使正向 Caching Proxy 发现请求的文件已过期,它也无须从内容主机重新访存该文件。而是向内容主机发送一条特殊的状态检查消息。如果内容主机表示该文件未更改,则正向 Caching Proxy 仍然可以将高速缓存的版本传递给发出请求的用户。
以这种方式配置的正向 Caching Proxy 称为正向代理,因为 Caching Proxy 充当浏览器,通过因特网将它们的请求转发给内容主机。启用高速缓存功能的正向代理的优点有两个方面:
Caching Proxy 可以代理几个网络传输协议,包括 HTTP(超文本传输协议)、FTP(文件传输协议)和 Gopher。
正向 Caching Proxy 的一个变体是透明 Caching Proxy。在此角色中,Caching Proxy 执行的功能与基本正向 Caching Proxy 相同,但它执行功能时客户机不知道它的存在。只有 Linux 系统支持透明 Caching Proxy 配置。
在正向 Caching Proxy描述的配置中,将每个客户机浏览器分别配置为将请求转发给某个正向 Caching Proxy。维护此类配置可能不是很方便,客户机数目庞大时尤其不方便。Caching Proxy 支持几种方便管理的备用方案。一种可能性是为将 Caching Proxy 配置为透明代理,如图 3中所述。与普通正向 Caching Proxy 一样,透明 Caching Proxy 安装在靠近网关的机器上,但客户机浏览器程序未配置为将请求转发给正向 Caching Proxy。客户机不知道配置中存在代理。实际上,路由器配置为拦截客户机请求并将这些请求转发给透明 Caching Proxy。当在其中一台机器上工作的客户机(标记为 1)请求存储在内容主机(6)上的文件 X 时,路由器(2)将请求传递给 Caching Proxy。Caching Proxy 生成新的请求(将它自己的 IP 地址 用作源地址)并将通过因特网(5)经路由器(2)发出新请求。当文件 X 到达时,如果合适的话,Caching Proxy 高速缓存该文件(视正向 Caching Proxy中描述的情况而定)并将该文件传递给发出请求的客户机。
对于 HTTP 请求,维护有关每个浏览器的代理配置信息的另一个可能备用方案是使用在几个浏览器程序(包括 Netscape Navigator V2.0 及更高版本和 Microsoft Internet Explorer V4.0 及更高版本)中提供的自动代理配置功能。在这种情况下,创建一个或多个中央代理自动配置(PAC)文件并将浏览器配置为引用其中一个 PAC 文件而不是引用本地代理配置信息。浏览器自动监视对 PAC 的更改并相应地调整它的代理用法。这不仅使得不必维护有关每个浏览器的各自配置信息,还使得在某个代理服务器不可用时重新路由请求更容易。
另一个备用方案是使用某些浏览器程序中提供的网络代理自动发现(WPAD)机制。当对浏览器启用此功能时,它自动在它的网络中查找符合 WPAD 的代理服务器并将它的 Web 请求转至该服务器。在这种情况下,您不需要维护中央代理配置文件。Caching Proxy 是符合 WPAD 的。
要提供更高级的高速缓存功能,将 Caching Proxy 与 Load Balancer 组件一起用作逆向代理。通过集成高速缓存和负载均衡能力,您可创建有效的、极易管理的 Web 性能基础结构。
图 4 描绘了如何组合 Caching Proxy 和 Load Balancer,以在面临高需求情况下也能有效地发送 Web 内容。在此配置中,配置代理服务器(4)以拦截其 URL 中包含内容主机集群(7)主机名的请求,这些内容主机由 Load Balancer(6)进行负载均衡。
图注: 1--客户机 2--因特网 3--路由器/网关 4--Caching Proxy 5--高速缓存 6--Load Balancer 7--内容主机当客户机(1)请求文件 X 时,请求穿越因特网(2)并通过它的因特网网关(3)进入企业的内部网络。 代理服务器拦截请求,并用其自身的 IP 地址作为源地址生成新请求,再将此新请求发送到 Load Balancer 的集群地址。 Load Balancer 使用其负载均衡算法,来确定当前哪个内容主机可最好地满足对文件 X 的请求。该内容主机将文件 X 返回到代理服务器而不通过 Load Balancer。 代理服务器确定是否对其进行高速缓存,并使用先前描述的相同方法将其发送给最终用户。
高级高速缓存功能还可通过 Caching Proxy 的动态高速缓存插件来提供。当与 WebSphere Application Server 联合使用时,Caching Proxy 有能力高速缓存、服务和无效化 JavaServer Page(JSP)表单中的动态内容和 WebSphere Application Server 生成的 servlet 响应。
通常,必须对具有不确定到期时间的动态内容标记“不高速缓存”,因为基于标准时间的高速缓存到期逻辑不能确保及时地除去它。 动态高速缓存插件的事件驱动的到期逻辑使具有不确定到期时间的内容能被代理服务器高速缓存。 高速缓存(如网络边缘的内容)能减轻从 Application Server 重复调用内容主机以满足客户机的请求。 这可提供以下优点:
Servlet 响应高速缓存是动态产生 Web 页面的最终目的,这些 Web 页面的到期取决于应用程序逻辑或事件(如来自数据库的消息)。尽管此类页面的生存期是有限的,但在创建同时不能设置生存时间值,这是因为预先无法知道到期触发器。 如果此类页面的生存时间设置为 0,当提供动态内容时内容主机将招致严重恶化。
同步 Caching Proxy 和 Application Server 的动态高速缓存的职责就是由这两个系统共享。例如,公用 Web 页面是由应用程序动态创建的,它给出了可由 Application Server 导出的且由 Caching Proxy 高速缓存的当前天气预报。 然后,Caching Proxy 可为许多不同用户重复地提供应用程序的执行结果,直至通知那个页面无效。Caching Proxy 的 servlet 响应高速缓存中的内容一直是有效的,除非因为高速缓存阻塞,由 Caching Proxy 的配置文件中的 ExternalCacheManager 伪指令设置的缺省超时到期,或 Caching Proxy 接收到无效消息使它从其高速缓存中清除内容,造成代理服务器除去条目。 无效消息是在拥有内容的 WebSphere Application Server 上产生的,并将这些消息传播到每个配置的 Caching Proxy。
Caching Proxy 提供其他关键高级高速缓存功能部件:
Caching Proxy 功能的引入会影响网络性能。单独使用 Caching Proxy 或与 Load Balancer 联合使用可提高您网络的性能。请参阅WebSphere Application Server Edge components 介绍,以获得这些系统的介绍。
企业中 Caching Proxy 的性能只与运行的硬件和它所在的整个系统体系结构有关。 为了优化网络性能,硬件型号和整个网络体系结构要具有代理服务器特征。
Caching Proxy 软件的基本配置和管理以及在操作系统级别上进行调整也会对Caching Proxy性能有很大的作用。 可进行许多软件配置更改以增强性能;这些更改包括(但并不仅限于此)调整日志记录伪指令、映射规则、插件、超时值、高速缓存配置值和活动线程值。有关配置 Caching Proxy 软件的详细信息在《Caching Proxy 管理指南》中进行描述。
也可进行许多操作系统配置更改以增强性能;这些更改包括(但并不仅限于此)调整 TCP 和 ARP、增加文件描述符限制、同步系统时钟、调整网络接口卡(NIC)和当执行系统管理任务时遵循良好的公共惯例。
要点:Caching Proxy 在所有 Edge component 安装版本上提供,但下列情况例外:
本节讨论将 Caching Proxy 功能引入您的网络中时要考虑的网络硬件问题。
必须有大量内存供代理服务器专用。当配置了一个大的单纯内存高速缓存时,Caching Proxy 会消耗 2 GB 的虚拟地址。 内核、共享库和网络缓冲区也都需要内存。因此,代理服务器有可能要消耗 3 或 4 GB 的物理内存。 注意,单纯内存高速缓存明显要比原始磁盘高速缓存快,单独更改此配置可认为是提高性能。
安装 Caching Proxy 的机器上有一个大容量的磁盘空间很重要。当使用磁盘高速缓存时,您会认为这是非常正确的。 读写硬盘是计算机的一个频繁的过程。尽管 Caching Proxy 的 I/O 过程是有效的,但当 Caching Proxy 配置为使用磁盘高速缓存时,硬盘驱动器的机械限制会限制其性能。 有一些惯例可缓解磁盘 I/O 瓶颈,如使用多个硬盘以用于原始高速缓存设备和日志文件,使用具有快速查找时间、旋转速度和传输速率的磁盘驱动器。
网络需要(如速度、类型和 NIC 数及连接到代理服务器的网络的速度)会影响 Caching Proxy 的性能。 通常,最有利于性能的方法是在代理服务器上使用两个 NIC:一个用于入网流量,另一个用于出网流量。 它很可能使一个 NIC 达到单个 HTTP 请求和响应流量的最大限制。此外,NIC 至少应当有 100 MB,且总应该将它们配置为全双工操作。 这是因为路由和交换设备间自动协商可能会引发错误和妨碍吞吐量。最后,网络连接的速度非常重要。 例如,如果连接到的 Caching Proxy 是一个饱和的 T1 载体,那么您就无法指望得到高请求负载和完成优化吞吐量的服务。
Caching Proxy 机器的中央处理器(CPU)可能会成为一个限制因素。CPU 性能会影响处理请求的时间,网络中的 CPU 数会影响可伸缩性。 代理服务器的 CPU 需要与环境匹配,尤其是代理服务器将服务的请求负载的峰值很重要。
对于整体性能,通常有利的方法是扩大体系结构,而并不仅仅是添加几件硬件。 有多少硬件添加到单个机器并不要紧,硬件仍有最大级别的性能。
本节讨论将 Caching Proxy 功能引入您的网络中时的网络体系结构问题。
如果您企业的 Web 站点很受欢迎,则对其内容的需求可能很大,单个代理服务器可能无法有效地满足,这样就可能引起慢响应时间。 要优化网络性能,考虑在您的整个网络体系结构中包含集群、负载均衡 Caching Proxy 机器或使用具有远程高速缓存访问(RCA)的共享高速缓存体系结构。
一种扩大体系结构方法是集群化代理服务器并使用 Load Balancer 组件来平衡它们之间的负载。集群化代理服务器是一种不仅考虑性能和可伸缩性,还考虑了冗余和可靠性的有利设计。 单个代理服务器表示一个单点故障;一旦它发生故障或由于网络故障而使它不可访问,将导致用户无法访问您的 Web 站点。
还得考虑具有 RCA 的共享高速缓存体系结构。 共享高速缓存体系结构延伸了多个 Caching Proxy 服务器间的总虚拟高速缓存,这些服务器通常使用内部高速缓存协议,如因特网高速缓存协议(ICP)或高速缓存阵列路由协议(CARP)。 RCA 旨在通过提供大虚拟高速缓存来最大化集群高速缓存的命中率。
相对使用单个独立 Caching Proxy 或甚至独立 Caching Proxy 机器的集群,使用代理服务器的 RCA 阵列有性能上的优势。 性能优势在极大程度上是通过增加总虚拟高速缓存大小来获得的,它可最大化高速缓存的命中率和最小化高速缓存的不一致和等待时间。 对于 RCA,只有一个特定文档的副本驻留在高速缓存中。对于代理服务器的集群,将增加总高速缓存大小,但多个代理服务器很可能会访存和高速缓存相同的信息。 因此,总高速缓存命中率不会增加。
RCA 通常在大型企业的托管内容方案中使用。但是,RCA 的有效性并不限于超大型企业的部署。当您的网络负载需要高速缓存服务器的集群时和当多数请求为高速缓存命中时,考虑使用 RCA。 依据您的网络设置,RCA 不会总能提高企业性能,因为配置 RCA 时会增加客户机的 TCP 连接数。 这是因为 RCA 成员不仅承担为具有最高分数的 URL 提供服务,它还必须为它获得的不具有最高分数的 URL 转发请求到其他成员或集群。这意味着 RCA 阵列中任何给出的成员可能比它作为独立服务器操作时具有更多打开的 TCP 连接。
改善性能的主要因素取决于 Caching Proxy 的高速缓存能力。然而,当未正确配置代理服务器的高速缓存时,它会成为一个瓶颈。 要确定最佳的高速缓存配置,一项重要的工作就是分析流量特征。内容的类型、大小、数量和属性会在用于从源服务器检索文档的时间和在服务器上装入的时间方面影响代理服务器的性能。 一旦您知道 Caching Proxy 的高速缓存要使用代理或服务的流量类型,您就可以在配置代理服务器时考虑那些特征。 例如,当知道 80% 的高速缓存对象是图像(*.gif 或 *.jpg)且大小在 200 KB 左右,这的确可帮助您调整高速缓存参数和确定高速缓存大小。另外,了解大多数内容是不适合高速缓存的个性化动态页面,也有助于调整 Caching Proxy。
分析流量特征使您能确定是使用内存还是使用磁盘高速缓存可优化您的高速缓存性能。 同时,熟悉网络的流量特征使您能确定是否能通过使用 Caching Proxy 的动态高速缓存功能来提高性能。
磁盘高速缓存适用于要高速缓存大量信息的站点。 例如,如果站点内容很大(大于 5 GB),且其中有 80% 到 90% 高速缓存命中率,那么建议使用磁盘高速缓存。 但是,众所周知使用内存(RAM)高速缓存更快,这里有许多对大型站点切实可行的使用单纯内存高速缓存的方案。 例如,如果 Caching Proxy 的高速缓存命中率不是很重要,或如果使用共享高速缓存配置,那么内存高速缓存是可行的。
Caching Proxy 可进行高速缓存和使由 WebSphere Application Server 动态高速缓存生成的动态内容(JSP 和 servlet 结果)无效,它在基于网络高速缓存中提供 Application Server 高速缓存的虚拟扩展。启用高速缓存动态生成的内容有利于有许多请求动态产生公用 Web 页面的环境中的网络性能,这些 Web 页面的到期取决于应用程序逻辑或事件(如来自数据库的消息)。 页面的生存期是有限的,但无法在创建页面的同时设置到期触发器;因此,必须指定主机而不指定动态高速缓存和无效功能部件,如生存时间值为 0 的页面。
如果在其生存期内由一个或多个用户多次请求此类动态生成的页面,那么动态高速缓存将提供一个重要的卸载,并减少网络的内容主机上的工作负载。 使用动态高速缓存还可提高网络性能,它通过消除网络延迟和减少带宽使用为用户提供更快速的响应,因为它较少进行因特网遍历。
当与内容主机(如 WebSphere Application Server)或与 Application Server Caching Proxy 组件联合工作时,Application Server Load Balancer 组件使您能增强网络的可用性和可伸缩性。(请参阅WebSphere Application Server Edge components 介绍,以获得这些 Edge components 的介绍。) Load Balancer 用于企业网络中,且它安装在因特网和企业的后端服务器之间。 在因特网上,即使企业为满足高需求或存放大量内容而使用多个后端服务器,Load Balancer 都将作为企业的单个存在点。
可用性使通过负载均衡和故障转移支持完成的。
要点:Caching Proxy 在所有 Edge component 安装版本上提供,但下列情况例外:
负载均衡通过透明地建立代理服务器和应用程序服务器集群来提高 Web 站点的可用性和可伸缩性。由于可明显增加后端的处理能力,因此可显著提高 IT 基础结构的可伸缩性。
您可以通过在多个主机上复制内容来满足高需求,然而您需要一种方法在它们之间进行负载均衡。域名服务(DNS)可以提供基本循环法进行负载均衡,但在某些情况下,它的执行情况不够理想。
对多个内容主机进行负载均衡有一种更巧妙的解决方案,即如图 5 中所述使用 Load Balancer 的分派器组件。在这种配置下,所有的内容主机(标记为 5 的机器)都存储相同的内容。 它们被定义为形成一个负载均衡集群,并为 Load Balancer 机器(4)的其中一个网络接口指定集群专用的主机名和 IP 地址。 当使用其中一台标记为 1 的机器的最终用户请求文件 X 时,该请求将穿越因特网(2)并通过它的因特网网关(3)进入企业内部网络。分派器会拦截该请求,因为其 URL 映射到分派器的主机名和 IP 地址。 分派器将确定当前集群中的哪个内容主机最适合为该请求服务,并将请求转发到那个主机,当配置 MAC 转发方法时,文件 X 将直接返回给客户机(即,文件 X 不通过 Load Balancer 传递)。
图注: 1--客户机 2--因特网 3--路由器/网关 4--分派器 5--内容主机缺省情况下,分派器使用类似 DNS 的循环法进行负载均衡,然而即使这样,它却解决了 DNS 的许多不足之处。与 DNS 不同,分派器会跟踪内容主机是否不可用或不可访问,且不会将客户机继续导向不可用的内容主机。此外,它会通过跟踪新的、活动的以及已完成的连接数,来考虑内容主机上的当前负载。 通过激活 Load Balancer 中可选的顾问程序和管理器组件可进一步优化负载均衡,因为这样可以更准确地跟踪内容主机的状态,并将附加信息合并到负载均衡决策过程中。管理器允许您为决策过程中使用的不同因素指定不同的权值,以进一步为您的站点定制负载均衡。
Load Balancer 的分派器还可为多个 Caching Proxy 机器执行负载均衡。如果您的企业 Web 站点很受欢迎,则对其内容的需求可能很大,单个代理服务器可能无法有效地满足,这样就可能使代理服务器的性能降低。
您可使用多个 Caching Proxy 系统来为单个内容主机执行代理功能(类似于图 1 中描绘的配置),但如果您的站点非常热门,需要多个代理服务器,则您可能还需要多个内容主机,它们将通过 Load Balancer 平衡其负载。图 6 描绘了此配置。分派器(标记为 4)对两个代理服务器(5)的集群进行负载均衡,而分派器(标记为 7)对三个内容主机(8)的集群进行负载均衡。
图注: 1--客户机 2--因特网 3--路由器/网关 4--分派器 5--代理服务器 6--高速缓存 7--分派器 8--内容主机标记为 4 的分派器的集群主机名是出现在企业 Web 内容 URL 中的主机名(即,它是因特网上可见的 Web 站点的名称)。 标记为 7 的分派器的集群主机名在因特网上是不可视的,因此可以是您所希望的任何值。例如,对于 ABC 公司,标记为 4 的分派器的适当主机名为 www.abc.com,而如 http-balancer.abc.com 可调用标记为 7 的分派器。
假设在标记为 1 的其中一台客户机上的浏览器需要访问文件 X,该文件存储在标记为 8 的内容服务器上。那么此 HTTP 请求将跨越因特网(2)并通过网关(3)进入企业的内部网络。路由器将该请求导向标记为 4 的分派器,分派器再根据负载均衡算法将此请求传递给当前最适合处理它的代理服务器(5)。 如果代理服务器在其高速缓存(6)中找到文件 X,则它会将此文件直接返回给浏览器,而绕过标记为 4 的分派器。
如果代理服务器在它的高速缓存中并未找到文件 X 的副本,则将创建一个新的请求,并在报头的原始字段中使用它自身的主机名,然后将它发送到分派器(标记为 7)。 Load Balancer 确定当前哪台内容主机(8)最可能满足该请求,并将请求发送给它。 此内容主机从存储器中检索出文件 X,并将它直接返回给代理服务器,而绕过标记为 7 的分派器。如果适当,代理服务器会高速缓存文件 X,并将其转发到浏览器,而绕过标记为 4 的分派器。
如果为大量客户机提供因特网访问,则它们产生的因特网访问需要会超出单个代理的实际提供能力。当 Caching Proxy 对于请求不胜负荷时,这些客户机可能会感到响应时间比直接进行因特网访问还要差。万一 Caching Proxy 发生故障或由于网络故障而变得不可访问时,就不能访问因特网了。解决方案是安装多台 Caching Proxy 机器并使用 Load Balancer 的分派器来在这些机器之间均衡负载。
如果没有分派器,则只有在您的路由器可以将同类的流量路由至多个 Caching Proxy 时才能向多台 Caching Proxy 提供真正的透明代理;然而,并不是所有路由器都支持将同类的流量路由至多个 Caching Proxy 的。不借助分派器也可以在多台 Caching Proxy 机器上提供普通正向代理服务,但必须将客户机浏览器显式配置为使用其中一台 Caching Proxy 机器使用为它们的主代理。如果该 Caching Proxy 发生故障、变得过载或不可访问,最终用户就不能访问因特网了。要避免出现这种情况,可以创建一个代理自动配置(PAC)文件(如透明正向 Caching Proxy(仅适用于 Linux 系统)中所述),它指导浏览器故障转移给一个或多个备用 Caching Proxy。PAC 文件不能满足在 Caching Proxy 机器之间均衡负载的需要;但是,如果一个 Caching Proxy 接收到的请求比另一个接收到的请求多,其性能就有可能会降级,导致它的浏览器客户机放慢响应时间。对于经历过类似性能的所有客户机,必须将数目大致相同的浏览器配置为使用每个 Caching Proxy,同时手工跟踪分布情况,以便在添加或除去浏览器时可使负载保持均匀。
图 7 描述了一个网络配置,分派器在该配置中对一个集群 Caching Proxy 机器进行负载均衡。某一个分派器机器的网络接口配置为集群专用的主机名和 IP 地址。客户机浏览器配置为将它们的因特网请求转向集群主机名。例如,当其中一台客户机(标记为 1)上的浏览器需要访问在内容主机(7)上的文件 X 时,它将它的请求转向集群主机名或地址,在其中,分派器(2)拦截请求并将请求转发给适当的 Caching Proxy(3)。该 Caching Proxy 创建新的请求、通过企业的网关(5)和因特网(6)传递新请求并在合适的情况下将返回的文件存储在它的高速缓存(4)中,这些在正向 Caching Proxy中有更详细的描述。
分派器检查 Caching Proxy 机器之一在何时不可用并自动将请求路由至其他机器。这使得您可以关闭一台 Caching Proxy 机器来进行维护但不会打断因特网访问。分派器具有许多配置选项,可使用它们来控制决定负载均衡时应考虑的因素。还可以在 Caching Proxy 机器上安装辅助分派器程序来监视它们的状态并将信息返回给分派器。有关详细信息,请参阅 《WebSphere Application Server Load Balancer 管理指南》。使用多个 Caching Proxy 可能会使效率变低,原因是如果不同的客户机通过不同的 Caching Proxy 机器请求同一个文件,就会出现多个 Caching Proxy 高速缓存同一个文件的情况。要消除这种重复劳动,可以配置远程高速缓存访问(RCA),它使得定义组中的所有代理互相共享它们高速缓存的内容。RCA 组中的代理都使用同一种算法以确定哪个 Caching Proxy 负责给定的 URL。当某个 Caching Proxy 拦截到它负责的 URL 时,它就会将请求传递给负责的 Caching Proxy。负责的 Caching Proxy 完成满足请求所需的工作,即从它的高速缓存中检索该请求,或者将该请求转发给相关的内容主机并且在合适的情况下高速缓存返回的文件。然后,负责的 Caching Proxy 将该文件传递给原始 Caching Proxy,而原始 Caching Proxy 则把该文件传递给发出请求的最终用户。
在 RCA 组中,如果负责给定 URL 的 Caching Proxy 失败,则接收到客户机请求的原始 Caching Proxy 将直接访问内容主机(或者如果定义了备份 Caching Proxy,则访问它)。这喻示只要 RCA 组中至少有一个 Caching Proxy 工作正常,用户就可以访问文件。
此配置通过使用分派器来在多台 Caching Proxy 之间均衡请求负载满足了高因特网访问需求。一个可能问题是恰恰就分派器发生故障。如果分派器发生故障,或由于网络故障而变得不可访问,则浏览器客户机不能访问 Caching Proxy 或因特网。解决方案是将另一个分派器配置为主分派器的备份使用,如图 8 中所述。
假设一个浏览器在其中一台机器(标记为 1)上运行,它通常将它对文件 X 的请求转发给主分派器(2),而主分派器(2)将该请求路由至根据分派器的负载均衡条件选中的 Caching Proxy(4)。该 Caching Proxy 创建新的请求、将新请求通过因特网(7)经企业的网关(6)路由至内容主机(8)并在合适的情况下将返回的文件 X 存储在它的高速缓存(5)中(有关此处理部分的更详细的描述,请参阅正向 Caching Proxy)。
在此配置中,只要主分派器正常工作,备份分派器(3)就不会执行负载均衡。主分派器和备份分派器通过定期交换消息(称为脉动信号)来互相跟踪对方的状态。如果备份分派器检测到主分派器发生故障,它将通过拦截转发给主分派器的主机名和 IP 地址的请求,自动接管负载均衡的职责。也可将两个分派器配置为相互高可用性。在这种情况下,每个分派器都对各自的 Caching Proxy 集群主动地执行负载均衡,同时又作为彼此的备份。有关进一步的讨论,请参阅《WebSphere Application Server Load Balancer 管理指南》。
分派器通常不会耗费很多处理或内存资源,并且其他应用程序可以在分派器机器上运行。如果您十分重视缩减设备成本,那么甚至可将备份分派器放置在 Caching Proxy 所在的机器上运行。图 9 描绘了这种配置,其中备份分派器在 Caching Proxy 所在的机器(3)上运行。
Load Balancer 将充当您企业的内容主机的单个存在点。这是一个优点,因为您可告知 DNS 中的集群主机名和地址,而不告知每个内容主机的主机名和地址,从而提供一个针对意外攻击的保护层和提供您企业 Web 站点的统一风格。 要进一步增将 Web 站点的可用性,将另一个 Load Balancer 配置为主 Load Balancer 的备份使用,如图 10 中所述。 如果一个 Load Balancer 发生故障,或由于网络故障而变得不可访问,最终用户仍可访问内容主机。
图注: 1--客户机 2--因特网 3--路由器/网关 4--主分派器 5--备份分派器 6--内容主机在通常情况下,在标记为 1 的其中一个机器上运行的浏览器将把文件 X 的请求导向集群主机名,该主机名映射到主 Load Balancer(4)。分派器将此请求路由到根据分派器的负载均衡标准选择的内容主机(6)。内容主机将文件 X 直接发送到浏览器,通过企业网关(3)跨越因特网(2)对其进行路由,但绕过 Load Balancer。
只要主分派器在运行,备份分派器(5)便不执行负载均衡。主和备份分派器通过定期交换消息(称为脉动信号)来互相跟踪对方的状态。如果备份分派器检测到主分派器发生故障,它将通过拦截导向主分派器的集群主机名和 IP 地址的请求,自动接管负载均衡的职责。
也可将两个分派器配置为相互高可用性。在这种情况下,每个分派器都对各自的内容主机集群主动地执行负载均衡,同时又作为彼此的备份。(在 Load Balancer for IPv4 和 IPv6 安装上支持简单高可用性,但不支持相互高可用性。)
分派器通常不会耗费很多处理或内存资源,并且其他应用程序可以在 Load Balancer 机器上运行。如果您十分重视缩减设备成本,那么甚至可将备份分派器放置在执行负载均衡的集群中的某一台机器上运行。 图 11 描绘了这种配置,其中备份分派器运行在集群(5)中的某个内容主机上。
图注: 1--客户机 2--因特网 3--路由器/网关 4--主分派器 5--备份分派器和内容主机 6--内容主机要点:基于内容路由(CBR)组件在所有受支持的平台上提供,但下列情况例外:
或者,对于这种安装类型,可以使用 Load Balancer' 的 分派器 组件的 cbr 转发方法来为 HTTP 和 HTTPS 请求提供基于内容路由,而不用使用 Caching Proxy。有关更多信息,请参阅《WebSphere Application Server Load Balancer 管理指南》。
Load Balancer for IPv4 和 IPv6 只支持 分派器 组件的 mac 转发方法。不支持 nat 和 cbr 转发方法。
当与 Application Server Caching Proxy 组件联合工作时,Application Server Load Balancer 组件允许您将请求分布到托管不同内容的多个后端服务器。(请参阅WebSphere Application Server Edge components 介绍,以获得这些 Edge components 的介绍。)
如果 Load Balancer 的基于内容路由(CBR)组件是与 Caching Proxy 一起安装的,那么 HTTP 请求可根据 URL 或其他由管理员确定的特征进行分发,这样就不必将相同的内容存储在所有后端服务器上。
如果您的 Web 服务器需要执行一些不同的功能或提供多种类型的服务,则使用 CBR 是非常明智的。例如,一个在线零售商的 Web 站点必须既可显示货品目录(其中大部分是静态内容),又可接受订单,这意味着要运行交互式应用程序(如公共网关接口(CGI)脚本),以用于接受货品数目及顾客信息。以下方法通常十分有效,那就是使用两组不同的机器来执行不同的功能,并使用 CBR 将不同类型的流量路由到不同的机器组。同样,企业可以使用 CBR 向付费的客户提供优于此 Web 站点普通访问者的服务,方法是将已付费用户的请求路由到功能更强大的 Web 服务器。
CBR 根据您编写的规则对请求进行路由。最常见的类型是内容规则,它根据 URL 中的路径名来导向请求。例如,ABC 公司可以编写以下规则,以将对 URL http://www.abc.com/catalog_index.html 的请求导向某个服务器集群,而将对 http://www.abc.com/orders.html 的请求导向另一个集群。当然,还存在可根据发送请求的客户机的 IP 地址或根据其他特征来对请求进行路由的规则。如需进一步探讨,请参阅《WebSphere Application Server Load Balancer 管理指南》中有关配置 CBR 以及有关高级 Load Balancer 和 CBR 功能的各章。如需了解规则的语法定义,请参阅《WebSphere Application Server Load Balancer 管理指南》中有关 CBR 规则类型的附录。
图 12 描绘了一种简单配置,其中 Load Balancer 的 CBR 组件和 Caching Proxy 一起安装在标记为 4 的机器上,并且将请求路由到三个存放不同内容的主机(6、7 和 8)。当使用其中一台标记为 1 的机器的最终用户请求文件 X 时,该请求将穿越因特网(2)并通过因特网网关(3)进入企业内部网络。 代理服务器会拦截此请求并将其传递到同一机器上的 CBR 组件,CBR 会对此请求中的 URL 进行语法分析,并确定保存文件 X 的内容主机 6。 代理服务器会为文件 X 生成一个新请求,且如果其高速缓存功能部件已启用,那么当主机 6 返回文件时,将确定该文件是否进行高速缓存。如果此文件可进行高速缓存,则代理服务器在将它传递给最终用户前,会在其高速缓存(5)中存储此文件的一个副本。 其他文件的路由方式也相同:对文件 Y 的请求转至内容主机 7,而对文件 Z 的请求则转至内容主机 8。
图注: 1--客户机 2--因特网 3--路由器/网关 4--Caching Proxy 和 Load Balancer 的 CBR 组件 5--高速缓存 6, 7, 8--内容主机图 13 描绘了一种较复杂的配置,它可能适合在线零售商。Load Balancer 的 CBR 组件和代理服务器一起安装在标记为 4 的机器上,并将请求路由到两台 Load Balancer 机器。 标记为 6 的 Load Balancer 对内容主机集群(8)进行负载均衡,该集群中保存有零售商目录的大部分静态内容,而标记为 7 的 Load Balancer 则对处理订单的 Web 服务器集群(9)进行负载均衡。
当使用标记为 1 的其中一台机器的最终用户访问此零售商目录所在的 URL 时,该请求跨越因特网(2)并通过因特网网关(3)进入企业的内部网络。代理服务器会拦截此请求并将其传递给同一机器上的 CBR 组件, CBR 会对此 URL 进行语法分析,并确定由标记为 6 的 Load Balancer 机器来处理此 URL。代理服务器将创建一个新的访问请求,并将其发送到 Load Balancer,由它确定当前最适合为此请求提供服务的内容主机(标记为 8)(基于您定义的标准)。 该内容主机绕过 Load Balancer 将目录内容直接传递给代理服务器。如先前的示例中,代理服务器确定内容是否可进行高速缓存,如果可以,则将它存储在其高速缓存(5)中。
最终用户通过访问零售商的订购 URL 来进行订购,方法可能是通过目录中的超链接。 除机器 4 上的 CBR 组件将请求路由到标记为 7 的 Load Balancer 机器外,该请求和目录访问请求所游历的路径是相同的。 此 Load Balancer 将请求转发到最适合的 Web 服务器(标记为 9),而该服务器将直接答复代理服务器。因为订购信息通常是动态生成的,代理服务器可能不会对它进行高速缓存。
图注: 1--客户机 2--因特网 3--路由器/网关 4--Caching Proxy 和 Load Balancer 的 CBR 组件 5--高速缓存 6, 7--Load Balancer 8--内容主机 9--Web 服务器Load Balancer 的 CBR 功能支持 cookie 亲缘关系。这意味着,为最终用户的第一个请求提供服务的服务器的身份会记录在一个特殊的信息包(cookie)中,而此信息包包括在服务器响应中。当该最终用户在您所定义的时期内再次访问同一 URL 时,且此请求包含该 cookie,则 CBR 会将该请求路由到源服务器,而不再重新应用其标准规则。如果该源服务器中存储了关于最终用户的信息,而这些信息没有必要再次获取(例如信用卡号),这样通常会减少响应时间。
这一部分讨论使用 IBM WebSphere Application Server Edge components 的商务方案。这些是体系结构合理并经过测试的解决方案,因此可提供极佳的性能、可用性、可伸缩性和可靠性。
这一部分包含以下章节:
基本电子商务 Web 站点是一个商家到消费者网络。在因特网成长的第一个阶段,商务通常集中在简单地创建 Web。 公司信息和产品目录都转换成数字格式,并可用于 Web 站点。通过提供电子邮件地址、电话和传真号,甚至是自动表单都可进行购物。 然而,真正的在线购物是不可用的。所有交易都有一个固定等待时间,因为人们需要处理订单。
在第二个阶段,商家减少了此等待时间,并通过实现安全购物车直接在线购买来形成流水线一样的销售操作。与仓库数据库同步并与银行系统集成在一起是完成这些销售交易的关键。 不能销售不可用的产品,且客户的帐户不会为此项付费。同样地,在发生有效金融交易之前,产品不能从库存中拿走并发货给客户。
在第三个阶段,公司 Web 站点发展成了一个动态表示站点,在此类 Web 站点上客户开始采取客户机方式并得到个性化内容。
下列方案包括 Load Balancer 和 Caching Proxy 两者。
要点:Caching Proxy 在所有 Edge component 安装版本上提供,但下列情况例外:
图 14 显示了设计成提供有效目录浏览的小型商业 Web 站点。 所有客户机请求都会通过防火墙传递到分派器,它将这些请求路由到具有活动高速缓存(充当 Web 服务器的代用品服务器)的代理服务器的集群。度量服务器与代理服务器位于一块,为分派器提供负载均衡数据。 此安排可减少 Web 服务器上的网络负载,并隔离它们与因特网的直接联系。
图 15 显示了商业 Web 站点发展的第二个阶段,它旨在为潜在客户提供有效目录浏览和快速安全的购物车。所有客户请求都将通过分派器路由到相应的网络分支,分派器可根据因特网协议分隔请求。 HTTP 请求转至静态 Web 站点;HTTPS 请求转至购物网络。主要的静态 Web 站点仍由具有活动高速缓存(充当 Web 服务器的代用品)的代理服务器的集群提供服务。 这一部分网络是第一个阶段中的网络的镜像。
Web 站点的电子交易部分还通过代理服务器的集群来提供服务。然而,Caching Proxy 节点是通过几个插件模块来增强的。 SSL 握手被卸载给加密硬件卡,并且通过 Access Manager(先前称为 Policy Director)插件执行认证。动态高速缓存插件通过存储公共数据来减少 WebSphere Application Server 上的工作负载。 在必要时,应用程序服务器上的插件可使动态高速缓存中的对象无效。
所有购物车应用程序都与用于对用户进行认证的客户数据库关联。这就防止了用户必须将个人信息输入系统两次,一次用于认证而一次用于购物。
此网络按客户机的使用划分流量,以从主要 Web 站点除去处理器密集的 SSL 认证和电子交易购物车。此双跟踪 Web 站点允许网络管理员根据此服务器在网络中的角色,调整各种服务器以提供卓越的性能。
图 16 显示了商家到消费者网络发展的第三个阶段,它使用采用动态表示方法的静态 Web。增强了代理服务器集群,以支持高速缓存动态 Web 内容和组装按照侧端包含(ESI)协议编写的页面片段。ESI 机制不是使用服务器端包含机制来构建内容服务器的 Web 页面并接着在整个网络中传播这些特定于客户机、非高速缓存的页面,它允许从网络边缘上高速缓存的内容中组装页面,因此可减少带宽消耗和递减响应时间。
ESI 机制是此第三个阶段方案中的关键,这里每个客户机都可从 Web 站点接收到个性化主页。 这些页面的构建块可从一系列 WebSphere Application Server 中检索到。 包含敏感业务逻辑和尝试保护数据库的应用程序服务器被隔离在防火墙之后。
图 17 显示了有效的在线银行解决方案,它类似于商家到消费者网络中描述的商家到消费者网络。 所有客户机的请求通过防火墙传递到分派器,分派器将根据因特网协议分隔流量。HTTP 请求将传递到具有活动高速缓存(充当 Web 服务器的代用品服务器)的代理服务器集群。度量服务器与代理服务器位于一块,为分派器提供负载均衡数据。这样安排可减少 Web 服务器上的网络负载,创建 Web 服务器和因特网之间的其他缓冲区。
HTTPS 请求传递到安全网络中,此安全网络设计成为客户提供个人金融信息并允许在线银行交易。 增强代理服务器的集群可提供站点的可伸缩性。这些代理服务器支持高速缓存动态 Web 内容,以及组装按照侧端包含(Edge Side Includes,ESI)协议编写的页面片段。 加密硬件卡管理 SSL 握手,它明显地减少了代理服务器主机必需的处理,以及 Access Manager(先前称为 Policy Director)管理客户机认证。
应用程序服务器集群的集合通过分隔业务逻辑(包含在 EJB 组件中)和表示层(包含在 servlet 和 JSP 文件中)来分发请求处理。 这些集群的每一个都由单独的会话服务器进行管理。
下列方案包括 Load Balancer 和 Caching Proxy 两者。
要点:Caching Proxy 在所有 Edge component 安装版本上提供,但下列情况例外:
图 18 显示了设计成为每个客户提供个性化内容时支持高流量的 Web 门户网站网络。要最大程度减少各种服务器上的处理负载,部分网络不会传送 SSL 流量。因为门户网站不会发送敏感数据,所以安全性不是一个重要问题。 对包含客户标识、密码和设置的数据库来说,重要的是具有适当的安全性和不被损害,但此需要不会削弱其余 Web 站点的性能。
所有客户机请求都会通过防火墙传递到分派器,分派器平衡具有活动高速缓存(充当 Web 服务器的代用品服务器)的代理服务器集群上的网络负载。 度量服务器与代理服务器位于一块,为分派器提供负载均衡数据。
实际的动态 Web 站点是应用程序服务器的集群,这些应用程序服务器会生成被传递到代理服务器以进行组装的 ESI 片段。 因为减少了涉及的安全性,所以每个应用程序服务器会执行所有必需的功能以构造 Web 站点。 所有应用程序服务器都是等同的。如果一个应用程序服务器停止了服务,会话服务器可将请求路由到其他服务器,这为整个站点提供了高可用性。 此配置还允许在发生过多流量时快速扩大 Web 站点,例如,由门户网站托管的特殊事件。 其他代理服务器和应用程序服务器可快速配置到此站点中。
所有静态内容(如,图像文件和样本文本)存储在不同的 Web 服务器上,这允许它按需进行更新,而无需冒破坏更多复杂应用程序服务器的危险。
下列方案包括 Load Balancer 和 Caching Proxy 两者。
要点:Caching Proxy 在所有 Edge component 安装版本上提供,但下列情况例外:
这一部分提供了安装 Edge components 的过程。
这一部分包含以下章节:
本章提供指向 Edge components 的硬件和软件需求的链接并描述通过 Web 浏览器使用 Caching Proxy“配置和管理”表单和 Load Balancer 联机帮助的准则。
有关 WebSphere Application Server,版本 6.1 Edge components 的受支持硬件和软件需求的信息,请链接至以下 Web 页面: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921。
SDK 安装:在所有平台上 Java 2 SDK 自动与 Load Balancer 一起安装。
浏览器的最低需求
要使用“配置和管理”表单配置 Caching Proxy,您的浏览器必须执行以下操作:
对于 Linux 和 UNIX 系统:有关建议的 Mozilla 和 Firefox 浏览器版本,请访问以下 Web 站点并访问指向受支持的软件 Web 页面的链接:http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921。
对于 Windows 系统:有关建议的 Internet Explorer、Mozilla 和 Firefox 浏览器版本,请访问以下 Web 站点并访问指向受支持的软件 Web 页面的链接:http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921。
限制:如果要在浏览器窗口中显示的扩展元素数过多,则浏览器无法显示管理表单左侧垂直滚动条。这导致列表底部的扩展元素超出当前浏览器查看窗口,因而无法访问。要解决此问题,限制左侧菜单中扩展元素数。如果扩展元素数过大,折叠一些元素,直到列表底部的元素显示在浏览器窗口中。
为了正确显示表单,实际显示表单的操作系统(浏览器驻留的系统)必须包含编写表单所用语言的相应字体集。然而,浏览器界面无需与表单使用相同的语言。
例如,Solaris 9 系统上运行有中文版的代理服务器。可将英语语言界面的 Mozilla 浏览器装入 Solaris 主机。此浏览器可用于在本地编辑“配置和管理”表单。 (表单是以代理服务器使用的字符集显示在浏览器中的,在此示例中为中文;然而,如果浏览器及其底层操作系统未正确配置以显示由代理服务器发送的字符集,表单可能就无法正确显示。)
或者,如果具有使用中文语言支持的 Windows 工作站可远程地连接到代理服务器,则可以将中文版的 Netscape 浏览器装入 Windows 工作站并使用此浏览器在表单中输入值。对于管理员来说,第二个解决方案更有利于维护语言界面的一致性。
操作系统特定字体集将很大程度地影响浏览器中各种语言的显示,特别是双字节字符。例如,AIX 上的特定中文字体集同 Windows 平台上的中文字体集看上去并不完全一样。这就导致“配置和管理”表单中 HTML 文本和 Java applet 显示外观有些不规则。要获得最佳的显示外观,建议仅使用运行在 Windows 操作系统上的浏览器。
关于 S/390 和 PowerPC 上的 Mozilla 1.4 浏览器的注意事项
与 Mozilla 1.4 一起安装的 Java 插件必须更新为 V1.4.2 或更高版本,以便正确显示管理表单。使用下列步骤更新插件:
要使用 Load Balancer 联机帮助,您的浏览器必须支持以下内容:
使用不支持这些需要的浏览器会导致不能正确使用未正确格式化的页面和功能。
本章提供使用安装程序安装 Edge components 的说明。
在所有平台上 Java 2 SDK 自动与 Load Balancer 一起安装。
在安装完成后,Caching Proxy 封装中的脚本尝试启动使用缺省配置的代理服务器。 如果端口 80 正在使用(如,另一个 Web 服务器正在使用它),代理服务器将启动失败。
要点:Caching Proxy 在所有 Edge component 安装版本上提供,但下列情况例外:
按如下所示使用安装程序将 Edge Components 安装到您的 Windows(R) 系统上:
如果 Edge components 已安装,在“组件选择”窗口打开之前会打开“维护选项”选项。选择修改单选按钮,然后单击下一步。“组件选择”窗口将打开。
限制:在许可证协议窗口中使用 Tab 键来在我接受和我不接受这两个选项之间切换。但是,不能使用 Tab 键来跳到上一步、下一步或取消等导航选项上。变通方法是使用 Shift+Tab 键组合来跳到这些导航选项上。另外,Enter 键只对导航按钮起作用,因此,必须使用空格键来选择我接受或我不接受选项。
如果从 CD 安装,则可按如下所示使用安装程序将 Edge components 安装到您的 Linux 和 UNIX 系统上:
# ./install“欢迎”窗口将打开。
安装程序开始安装所选 Edge components 和所需的软件包。
限制:在许可证协议窗口中使用 Tab 键来在我接受和我不接受这两个选项之间切换。但是,不能使用 Tab 键来跳到上一步、下一步或取消等导航选项上。变通方法是使用 Shift+Tab 键组合来跳到这些导航选项上。另外,Enter 键只对导航按钮起作用,因此,必须使用空格键来选择我接受或我不接受选项。
在 Red Hat Linux 3.0 更新 3 上:运行 Edge Components 的安装程序时,如果先将图形用户界面面板最大化然后还原,则各按钮不起作用。要解决此问题,请执行下列操作:
在 Linux 和 UNIX 系统上:如果使用安装程序来安装 Edge Components,则可以使用图形用户界面卸载程序来卸载 Edge Components。但是,不能使用 Edge Components 图形用户界面卸载程序来卸载使用本机命令安装的更新包。必须先使用本机命令(操作系统的命令)卸载更新包,然后再使用图形用户界面卸载程序来卸载 Components。
有关使用本机命令的信息,请参阅使用系统封装工具安装 Caching Proxy和使用系统封装工具安装 Load Balancer。
本章提供使用系统封装工具安装 Caching Proxy 的说明。
在安装完成后,Caching Proxy 封装中的脚本尝试启动使用缺省配置的代理服务器。如果端口 80 正在使用(如,另一个 Web 服务器正在使用它),代理服务器将启动失败。
要点:Caching Proxy 在所有 Edge component 安装版本上提供,但下列情况例外:
使用您操作系统的软件包安装系统,按表 2 中所列顺序安装软件包。以下是完成该任务通常所必需的步骤的详细过程。
su - root Password: password
cd mount_point/package_directory/
在 AIX(R) 上:
installp -acXd ./packagename
在 HP-UX 上:
swinstall -s source/ packagename
在 Linux 上:
rpm -i ./packagename
在 Solaris 上:
pkgadd -d ./packagename
组件 | 已安装的软件包(以建议的顺序) |
---|---|
Caching Proxy |
|
Edge component 文档 |
doc-en_US1 |
注:
|
文档软件包只包含英文版的文档。Edge Component 文档集的翻译内容在下面的 Web 站点中提供:www.ibm.com/software/webservers/appserv/ecinfocenter.html。
要卸载软件包:
在 AIX 上:
installp -u packagename
要卸载所有 Caching Proxy 软件包,使用命令:
installp -u wses
在 HP-UX 上:
swremove packagename
要查询已安装的 Caching Proxy 软件包,使用命令:
swlist | grep WSES
应以您安装这些软件包的反向顺序除去它们。
在 Linux 上:
rpm -e packagename
要查询已安装的 Caching Proxy 软件包,使用命令:
rpm -qa |grep -i wses
应以您安装这些软件包的反向顺序除去它们。
在 Solaris 上:
pkgrm packagename
要查询已安装的 Caching Proxy 软件包,使用命令:
pkginfo | grep WSES
应以您安装这些软件包的反向顺序除去它们。
本主题定制在 AIX、HP-UX、Linux 和 Solaris 系统上安装 Load Balancer:
根据安装的类型,并没有提供在下面各节中列示的所有 Load Balancer 组件软件包。
安装各软件包的建议顺序与 Load Balancer for IPv4 和 IPv6 安装的建议顺序略有不同。尤其要记住的一点是,必须先安装分派器组件软件包再安装管理组件软件包。使用系统的工具安装 Load Balancer for IPv4 和 IPv6 的软件包的建议顺序为:基本、许可证、分派器组件、管理、文档、度量服务器
如果您从前一版本的 Load Balancer 迁移,或者在操作系统上重新安装,在安装前,您可保存 Load Balancer 的任何先前的配置文件或脚本文件。
如果您在已安装 Load Balancer 后注销机器,当您再次登录时必须重新启动所有 Load Balancer 服务。
表 5 列出了 Load Balancer 的 AIX 文件集以及使用系统的软件包安装工具进行安装的建议顺序。
Load Balancer 组件 | AIX 文件集 |
---|---|
基本 | ibmlb.base.rte |
管理(含有消息) |
|
设备驱动程序 | ibmlb.lb.driver |
许可证 | ibmlb.lb.license |
Load Balancer 组件(含有消息) |
|
文档(含有消息) |
|
度量服务器 | ibmlb.ms.rte |
文档软件包只包含英文版的文档。Edge Component 文档集的翻译内容在下面的 Web 站点中提供:www.ibm.com/software/webservers/appserv/ecinfocenter.html。
在安装 Load Balancer for AIX 之前,确保以下内容:
installp -u ibmlb或者,要卸载先前版本,输入以下命令:
installp -u ibmnd要卸载特定文件集,明确地列出它们而不是指定软件包名称 ibmlb。
安装本产品时,可选择安装以下任何选项(或全部):
建议使用 SMIT 来安装 Load Balancer for AIX,因为 SMIT 可确保所有消息都能自动安装。
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
软件包 | 命令 |
---|---|
基本 | installp -acXgd device ibmlb.base.rte |
管理(含有消息) | installp -acXgd device ibmlb.admin.rte ibmlb.msg.language.admin |
设备驱动程序 | installp -acXgd device ibmlb.lb.driver |
许可证 | installp -acXgd device ibmlb.lb.license |
Load Balancer 组件(含有消息)。包括:分派器、CBR、站点选择器、Cisco CSS 控制器和 Nortel Alteon 控制器 |
installp -acXgd device ibmlb.component.rte ibmlb.msg.language.lb |
文档(含有消息) | installp -acXgd device ibmlb.doc.rte ibmlb.msg.en_US.lb |
度量服务器 | installp -acXgd device ibmlb.ms.rte |
installp -ld device
如果从 CD 安装,要卸装 CD,输入以下命令:
unmount /cdrom
通过输入以下命令验证该产品已安装
lslpp -h | grep ibmlb
如果您已安装全部产品,此命令返回以下信息:
ibmlb.base.rte
ibmlb.admin.rte
ibmlb.lb.driver
ibmlb.lb.license
ibmlb.component.rte
ibmlb.doc.rte
ibmlb.ms.rte
ibmlb.msg.language.admin
ibmlb.msg.en_US.doc
ibmlb.msg.language.lb
Load Balancer 安装路径包含以下内容:
本部分说明如何使用产品 CD 在 HP-UX 上安装 Load Balancer。
在开始安装过程前,确保您具有安装此软件的 Root 用户权限。
如果您已安装早期版本,您应该在安装当前版本前卸载那个副本。首先,确保您已停止执行程序和服务器。然后,卸载 Load Balancer,请参阅卸载软件包的说明。
表 7 列出了 Load Balancer 的安装软件包的名称以及使用系统的软件包安装工具安装这些软件包的建议顺序。
HP-UX 不支持葡萄牙巴西语(pt_BR)语言环境。HP-UX 上支持的语言环境是:
以下过程详细说明完成此任务所需的步骤。
su - root Password: password
发出 install 命令
swinstall -s /source package_name
其中 source 是软件包的位置的绝对目录路径,而 package_name 是软件包的名称。
例如,如果您从 CD 的根目录安装,以下命令安装 Load Balancer 的基本软件包(ibmlb.base)
swinstall -s /source ibmlb.base
要安装 Load Balancer 的所有软件包,如果从 CD 的根目录安装,则发出以下命令:
swinstall -s /source ibmlb
发出 swlist 命令,列出您已安装的所有软件包。例如,
swlist -l fileset ibmlb
使用 swremove 命令卸载软件包。 应以您安装这些软件包的反向顺序除去它们。例如,发出以下命令:
swremove ibmlb要卸载单独的软件包(例如 Cisco CSS 控制器)
swremove ibmlb.cco
Load Balancer 安装路径包含以下内容:
本部分说明如何使用 Edge components CD 在 Linux 上安装 Load Balancer。
在安装 Load Balancer 之前,确保以下内容:
rpm -e pkgname卸载时,按照软件包安装的逆向顺序进行,以确保最后卸载管理软件包。
安装映像是 lblinux-version.tar 格式的文件。
tar -xf lblinux-version.tar其结果是以下一组具有 .rpm 扩展名的文件:
其中 -
文档软件包只包含英文版的文档。Edge Component 文档集的翻译内容在下面的 Web 站点中提供:www.ibm.com/software/webservers/appserv/ecinfocenter.html。
rpm -i package.rpm
Red Hat Linux 系统:由于一个已知的 Red Hat Linux 问题,还需要删除 _db* RPM 文件,否则会出错。
按显示在以下每个组件所需的软件包列表中的顺序安装软件包是很重要的。
rpm -i --nodeps package.rpm
rpm -qa | grep ibmlb
安装整个产品将产生以下输出:
Load Balancer 安装路径包含以下内容:
如果您需要卸载软件包,按照软件包安装的逆向顺序进行,以确保最后卸载管理软件包。
本部分说明如何使用 Edge components CD 在 Solaris 上安装 Load Balancer。
开始安装过程之前,确保您以 root 用户身份登录,并卸载该产品的任何先前版本。
要卸载,确保所有执行程序和服务器已停止。然后,输入以下命令:
pkgrm pkgname
pkgadd -d pathname其中,-d pathname 是该软件包所在 CD-ROM 驱动器的设备名或硬盘驱动器上的目录名;例如:-d /cdrom/cdrom0/。
下面显示了一个软件包列表,显示顺序为建议安装它们的顺序。
文档软件包(ibmlbdoc)只包含英文版的文档。Edge Component 文档集的翻译内容在下面的 Web 站点中提供:www.ibm.com/software/webservers/appserv/ecinfocenter.html。
如果您要安装所有软件包,只需输入 all 并按 Return 键。如果要安装部分组件,输入相应的要安装软件包的名称,用空格或逗号分隔,然后按 Return 键。可能会提示您更改现有目录或文件的许可权。只需按 Return 键或响应 yes 即可。 您需要安装先决条件软件包(因为安装将按照字母顺序进行安装,并非先决条件顺序)。 如果输入 all,然后对所有提示响应 yes,那么安装将成功完成。
如果要安装分派器组件以及文档和度量服务器,则必须安装下列软件包:ibmlbbase、ibmlbadm、ibmlblic、ibmdisp、ibmlbdoc 和 ibmlbms。
pkginfo | grep ibm
Load Balancer 安装路径包含以下内容:
这一部分提供构建使用 Edge components 的基本演示网络的过程。这些网络不计划用于生产环境。初始配置网络的过程可使刚接触此产品的管理员理解许多网络边际的概念。 要完整地了解所有组件功能部件和深入的配置信息,请参阅《Caching Proxy 管理指南》和《Load Balancer 管理指南》。
这些过程允许组件支持的任何计算机系统在任何节点上使用。
这一部分包含以下章节:
图 19 显示使用位于三个网络节点上三个计算机系统的基本代理服务器网络。 此网络将代理服务器绑定到位于服务器 2 的专用内容主机(IBM HTTP Server),且代理服务器向主机提供服务。这可由位于工作站和服务器 1 之间的因特网直观表示。
要点:Caching Proxy 在所有 Edge component 安装版本上提供,但下列情况例外:
要构建 Caching Proxy 网络,按以下顺序执行这些过程:
需要以下计算机系统和软件组件:
按如下所示安装和配置 Caching Proxy:
# htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwd
当提示时,为管理员提供 htadm 程序的用户名、密码和真实姓名。
按如下所示安装和配置 Caching Proxy:
cd "Program Files\IBM\edge\cp\server_root\protect" htadm -adduser webadmin.passwd"
当提示时,为管理员提供 htadm 程序的用户名、密码和真实姓名。
从工作站执行以下操作:
从工作站执行以下操作:
图 20 显示三个本地连接的工作站的基本 Load Balancer 网络,这些工作站使用分派器组件的 MAC 转发方法来负载均衡两个 Web 服务器间的 Web 流量。 该配置在负载均衡任何其他 TCP 或无状态 UDP 应用程序流量时是相似的。
要构建 Load Balancer 网络,按以下顺序执行这些过程;
需要以下计算机系统和软件组件:
工作站 | 名称 | IP 地址 |
---|---|---|
1 | server1.company.com | 9.67.67.101 |
2 | server2.company.com | 9.67.67.102 |
3 | server3.company.com | 9.67.67.103 |
网络掩码 = 255.255.255.0 |
Name= www.company.com IP=9.67.67.104
添加一个 www.company.com 的别名到 server2.company.com 和 server3.company.com 上的回送接口。
ifconfig lo0 alias www.company.com netmask 255.255.255.0
ifconfig lo0:1 www.company.com 127.0.0.1 up
您现在已完成了两个 Web 服务器工作站所需要的全部配置步骤。
对于分派器, 您可以使用命令行、配置向导或图形用户界面(GUI)创建配置。
如果您使用命令行,则按照这些步骤:
dscontrol executor start
dscontrol cluster add www.company.com
dscontrol port add www.company.com:80
dscontrol server add www.company.com:80:server2.company.com
dscontrol server add www.company.com:80:server3.company.com
dscontrol executor configure www.company.com
dscontrol manager start
Dispatcher 现在将基于服务器性能进行负载均衡。
dscontrol advisor start http 80
现在,分派器将确保客户机请求不发送到出故障的 Web 服务器。
现在您具有本地连接的服务器的基本配置已完成。
要点:对于 Load Balancer for IPv4 和 IPv6 安装,分派器命令(dscontrol)的语法是完全一样的,但有一个重要例外情况。dscontrol 命令的定界符是 at 号(@)而不是冒号(:)。(必须定义冒号之外的定界符,原因是 IPv6 格式在它的寻址模式中使用冒号。)
例如(来自上一个“分派器”配置示例)
dscontrol port add www.company.com@80
dscontrol server add www.company.com@80@server2.company.com
dscontrol server add www.company.com@80@server3.company.com
有关更多信息,如果正在使用 Load Balancer for IPv4 和 IPv6 安装,则请参阅《WebSphere Application Server Load Balancer 管理指南》中有关在 Load Balancer for IPv4 和 IPv6 上部署分派器的章节,它包括了有关限制和配置差别的信息。
如果您使用配置向导,请按照这些步骤操作:
dsserver
向导将逐步引导您创建分派器组件的基本配置的过程。它将询问关于网络的问题,并指导您设置一个集群,使分派器能负载均衡一组服务器的流量。
配置向导包含以下面板:
要启动 GUI,遵循这些步骤:
dsserver