摘要:
WebSphere代理服务器(Proxy Server)作为WebSphere应用服务器中的逆向代理(reverse proxy),不仅能够为用户屏蔽后台应用服务器,进行请求转发,同时也提供动态负载平衡和缓存等主要功能,满足用户的高性能需求。从WebSphere产品的长期发展趋势来看,Proxy Server将逐渐替代现有的代理服务组件,如缓冲代理服务器(Caching proxy)和IBM HTTP 服务器插件。本文将从当前使用缓冲代理服务器的用户角度出发,指导用户完成WebSphere代理服务器的创建、管理及配置工作,实现从Caching Proxy到Proxy Server有效迁移。
自WebSphere应用服务器Network Deployment产品6.0.2版本之后,WebSphere代理服务器作为其中一个重要组件,提供了一个高性能的逆向代理。它获取客户端Web请求,进行请求转发,并同时提供负载均衡和缓存等主要功能。WebSphere应用服务器7.0版本中,WebSphere代理服务器不仅在安全性方面有了很大程度的改进,使其可用于非军事化区域(DMZ),同时在可管理性、缓存、负载均衡以及地址改写等各项功能均有了较大的增强。
WebSphere代理服务器主要包含以下几项功能:
Ÿ 逆向代理
逆向代理是WebSphere代理服务器中最重要的一项功能,简单的来说就是请求转发。WebSphere代理服务器接受来自Internet中的用户连接请求,然后将请求转发至内部网络上的服务器,并将从服务器上获取的结果返回给请求连接的客户端。对于终端用户来说,WebSphere代理服务器是唯一的访问入口,后端的应用服务器被完全屏蔽。WebSphere代理服务器中提供了多种配置策略用于转发和负载均衡的规则设定。
Ÿ URL地址改写
WebSphere代理服务器的另一个重要的特性是URL地址改写功能,以此将服务器和客户端实现有效隔离,从而保护提供内容的服务器访问地址。同时,内容的本地缓存可以大大的提高访问效率。
Ÿ 负载均衡
WebSphere代理服务器接受到用户访问请求后,可以根据相应的负载均衡算法将请求均匀的转发到多台内部服务器中,避免由于一台服务器负载过重造成性能下降,或单点故障引起的服务不可用状况。
Ÿ 缓存
WebSphere代理服务器使用WebSphere 应用服务器中动态缓存(dynamic cache)组件,对访问内容实现本地缓存,可以大大的提高访问效率。
目前,WebSphere产品中有两个组件提供逆向代理功能,它们分别是Web服务器插件(web server plug-in)和Edge Components proxy Web Traffic Express (WTE),即Caching Proxy。Web服务器插件是一个非常简单的代理,仅有消息转发和负载均衡的功能。Caching Proxy相对来说功能较全,它不仅具有基本的请求转发功能,还提供了静态动态内容缓存,URL地址改写,安全,动态路由以及正向代理等一系列功能。
然而,目前逆向代理的这两种解决方法,包括Web服务器插件以及缓冲代理服务器,它们都有一个最大的问题就是无法和WebSphere应用服务器的管理系统进行有机的结合。
Ÿ Web服务器插件是一个基于C语言的应用程序,也就是说当应用服务器在Java代码级别增加一项新功能,都需要在C语言级别进行重新开发。这不仅使得开发工作重复,不利于代码维护和系统升级,同时Web服务器插件在新功能的引入方面将不可避免的有一定程度的延后。
Ÿ Edge中的缓存代理服务器是一个相对独立的组件,同样无法和WebSphere应用服务器的管理系统实现结合。缓存代理服务器中的配置信息由管理员手动生成,当后台应用服务器的拓扑结构或配置发生变动时,管理员需要再次手动的更新代理服务器的配置信息。
综上所述,Web Server plugin以及缓冲代理服务器都无法充分利用WebSphere组件和服务提供的相应功能,包括高可用性管理, 工作负载管理,请求优先级处理机制等等,而WebSphere Proxy Server可以有效的使用应用服务器现有的功能组件和服务,为用户提供更优的用户体验。因此,从WebSphere产品的长期发展策略来看,WebSphere代理服务器将取代缓存代理服务器以及Web服务器插件,成为提供反向代理功能的主要组件。
在本节中,我们将从一个典型的Caching Proxy使用场景出发,指导用户通过创建Proxy Server,完成同样的请求转发功能。
一个典型的Caching Proxy使用场景拓扑结构图如图1所示,缓冲代理服务器位于非军事区,对用户请求进行鉴别,以保护安全区内的应用系统不受安全攻击。Web服务器插件以及WebSphere应用服务器位于内部网络中,处理代理服务器转发的请求。
图1 Caching Proxy拓扑结构图
为了完成该场景的构建,用户需进行以下操作:
1. 安装WebSphere Application Server Network Deployment至机器E,创建Dmgr配置文件
2. 安装WebSphere Application Server至机器C和机器D,分别创建Custom类型的配置文件,并添加节点到机器E的Dmgr配置文件
3. 创建Cluster,并在该Cluster中创建四个应用服务器,其中应用服务器AppServer1,AppServer2位于机器C上,应用服务器AppServer3和AppServer4位于机器D上。
4. 安装IBM HTTP服务器及插件至机器B,配置插件,确保可以通过HTTP服务器的访问地址访问后台的四个应用服务器。
5. 在非军事化区域中安装Caching Proxy至机器A,通过Caching Proxy配置向导或直接修改配置文件ibmproxy.conf定义Proxy规则,实现对后台HTTP服务器的消息转发功能。其中,Proxy规则定义如下所示:
Proxy /* http://IHS_host:IHS_port
在该场景中,用户首先通过浏览器发出访问请求至非军事化区的Caching Proxy,Caching Proxy根据其配置文件ibmproxy.conf中的相关信息将请求转发至内部网络中的IBM HTTP Server,IBM HTTP Plugin根据当前后端服务器的配置信息及请求转发算法选择出合适的服务器进行请求转发,并获取访问结果返回至Caching Proxy,Caching Proxy对返回页面中的地址进行转换,将最终的结果呈现给用户。另一方面,管理员通过访问Deployment Manager对后端应用服务器和HTTP服务器进行配置管理,而以及Caching Proxy的管理工作则通过Caching Proxy Manager完成。
针对上述使用场景,用户可以通过从缓存代理到WebSphere代理服务器的迁移,实现同样的请求逆向转发功能。非军事区中缓存代理以及安全区的Web服务器提供的功能均由WebSphere代理服务器替代,同时该代理服务器被部署在非军事区中,我们称其为WebSphere安全代理服务器,这也是WebSphere应用服务器7.0版本提供的一个新特性。
WebSphere安全代理服务器中并没有一个内置的Web容器,因此也没有提供基于Web的管理控制台。这是因为在非军事区中,附加一个应用(管理控制台)被视为增加了安全风险,同时也增加了不必要的内存消耗。尽管没有提供管理控制台,但是,安全管理服务器仍然提供了多种不同安全级别的管理方式,以供用户选择。其中包括本地wsadmin工具管理、仅配置profile导入以及使用JobManager远程管理。本地wsadmin工具管理的方式不需要打开任何端口,是最安全的管理方式,但难以采用可视化的方式进行管理。仅配置profile导入的方式是通过创建仅配置profile后,通过Admin Agent管理控制台进行配置管理,并在安全代理服务器本地将该配置文件导入,从而完成对安全代理服务器的管理。JobManager远程管理是指用户可以使用Job Manager的管理控制台启动或停止安全代理服务器。不过,在使用Job Manager管理之前,需要使用上述的两种管理方式之一创建一个安全代理服务器。使用这种管理方式可以很方便地对多个安全代理服务器进行统一管理,但是相比较前面两种方式,它在安全性方面略差,因为需要打开SOAP的监听端口与远程的Job Manager通信。本文采用的管理方式为仅配置profile导入,其不仅可以提供较强的安全性,同时可视化的界面操作使得管理工作更加简单易行。
迁移后的拓扑结构图如图2所示。从图中可以看出,机器C以及机器D上的应用服务器配置无需做任何改变,机器B在新的拓扑结构中不再需要,我们的迁移操作集中在机器A和机器E中。
图2 WebSphere Proxy Server拓扑结构图
具体迁移步骤如下:
1. 创建“仅配置安全代理”profile
安全代理服务器无法在DMZ本地创建,只可以在其它的WAS Cell上创建,之后再导入到DMZ中。为了创建安全代理服务器,WAS 7.0中给出了一种新的profile:仅配置安全代理。在机器E上运行Profile管理工具,在选择Profile类型时,选择“安全代理(仅用于配置)”,即可以创建该类型的profile(如图3所示)。
图3 仅配置安全代理Profile创建页面
创建仅配置安全代理profile与创建普通profile的过程基本一致,其最大的不同在于需要选择安全代理服务器的安全级别。如图4所示,用户需要选择所创建的代理服务器采用高、中、低何种安全级别,之后会根据用户的选择生成具有相应配置的代理服务器。这里,我们选用的是高级安全级别。
图4 代理服务器的安全级别设置页面
2. 配置安全代理服务器
“仅配置安全代理”profile创建完成后,在必要的时候,需要对刚创建的安全代理服务器进行配置,修改其中的一些缺省属性。由于该profile没有基于Web的管理控制台,因此需要首先将其注册到Admin Agent中,再对其进行管理。在机器E中使用Profile管理工具创建一个Admin Agent Profile,并启动Admin Agent,然后在
registerProfile –profilePath ../../SecureProxy –connType IPC –port 9630
现在,可以通过AdminAgent的管理控制台对以前创建的安全代理进行配置。访问AdminAgent的管理控制台,选择安全代理所属的结点并点击“继续”按钮(如图5所示),将进入安全代理的管理控制台。
图5 使用Admin Agent管理控制台访问安全代理配置文件
从安全代理服务器的管理控制台,进入“服务器—>服务器类型—>WebSphere代理服务器”,选择需要配置的安全代理服务器(通常是proxy1),进入代理安全性设置页面(如图5所示)。在该管理界面可以对管理、路由、启动许可权与定制错误页策略进行配置,管理控制台会根据具体的配置信息判断当前配置的代理安全级别。
3. 安装WebSphere Proxy Server至非军事化区。
安装WebSphere Application Server的NDDMZ版本至机器A,进入目录
./manageprofiles.sh -create -profileName SecureProxySrv01 -profilePath ../profiles/SecureProxySrv01 -templatePath ../profileTemplates/secureproxy/
4. 导出/导入配置文件
在创建并配置完毕后,需要将在机器E上创建的安全代理服务器导入到DMZ中,使其正常运行。这分为两个步骤:在WAS Cell中导出配置文件与在DMZ中导入配置文件。
在配置结束后,可以使用wsadmin工具将安全代理服务器导出为CAR(configuration archive)后缀的配置文件。在
AdminTask.exportProxyProfile(['-archive', '/home/proxy.car'])
在获得配置文件后,需要将其拷贝到DMZ中安全代理服务器所在的机器上,再使用wsadmin工具将其导入。
AdminTask.importProxyProfile(['-archive','/opt/proxy.car')
5. 静态路由配置
对于用户请求,安全代理服务器可以采用静态或者动态路由的方式将其分发给后台的应用服务器。为了使代理服务器能够正常工作,在确定路由方式(动态/静态)后,还需要进行一定的配置工作。这里我们以静态路由为例,介绍路由配置方式。
配置成静态路由的安全代理服务器需要在本地创建一个配置文件,安全代理服务器可以从中获取路由信息。安全代理服务器配置成静态路由后,首先需要将路由信息从Dmgr导出为一个文件targettree.xml。
set MBean [$AdminControl queryNames *:*,type=TargetTreeMbean,process=dmgr] AdminTask.importProxyProfile(['-archive','/opt/proxy.car')
随后将targettree.xml静态路由配置文件拷贝到DMZ中安全代理profile的staticRoutes目录下,即$WASInstallDir/profiles/SecureProxySrv01/staticRoutes/
通过上述的5个步骤,用户完成了从缓存代理服务器到WebSphere代理服务器的迁移。在迁移后的场景中,访问者首先通过浏览器发出访问请求至非军事化区的WebSphere代理服务器,代理服务器根据静态路由配置信息及请求转换算法选择出合适的内部网络中的服务器进行请求转发,并获取访问结果返回至WebSphere代理服务器。另一方面,管理员访问Deployment Manager管理控制台对后端应用服务器进行配置管理,访问Admin Agent管理控制台修改仅配置安全代理profile,并通过导出导入操作完成对非军事化区中WebSphere安全代理服务器的配置管理。
在上节中,我们给出了从缓存代理服务器到WebSphere代理服务器的迁移方法,本节我们将通过对WebSphere代理服务器和Caching Proxy的压力测试,给出两者的性能对比数据。
我们首先将应用安装到集群中,使用AKStress工具模拟50个客户端,通过缓存代理服务器访问应用,持续时间1小时,相关的性能数据如下所示:
AKstress Process Statistics Uptime: 1 hours 0 minutes 2 seconds Number of Clients: 50 Pages Attempted: 899312 Pages To Be Attempted: 0 Pages per second: 249.67 Requests completed: 899296 Requests per second: 249.67 Failed Connections: 0 Incorrect response codes: 0 Content verification failed: 0 Request write failures: 0 Number of early server closes: 0 Number of timeouts: 0 SSL handshake failures: 0 Page statistics for page Page1 Successes: 899320 Min time (milliseconds): 16 Max time (milliseconds): 11255 Mean time (milliseconds): 199 Request statistics for request /trade/scenario (cVerifyRequest1) Successes: 895009 Connects: 894960 Return Code Failures: 0 Early Server Closes: 0 Content Verification Failures: 0 Timeouts: 0 Connect Min time (milliseconds): 0 Connect Max time (milliseconds): 26 Connect Mean time (milliseconds): 0 Min time (milliseconds): 15 Max time (milliseconds): 11251 Mean time (milliseconds): 196
接下来,我们使用AKStress工具对WebSphere代理服务器进行压力测试,模拟50个客户端,持续时间同样为1小时,此时相关的性能数据如下所示:
AKstress Process Statistics Uptime: 1 hours 0 minutes 1 seconds Number of Clients: 50 Pages Attempted: 963699 Pages To Be Attempted: 0 Pages per second: 267.62 Requests completed: 963699 Requests per second: 267.62 Failed Connections: 0 Incorrect response codes: 0 Content verification failed: 0 Request write failures: 0 Number of early server closes: 0 Number of timeouts: 0 SSL handshake failures: 0 Page statistics for page Page1 Successes: 963699 Min time (milliseconds): 17 Max time (milliseconds): 6484 Mean time (milliseconds): 185 Request statistics for request /trade/scenario (cVerifyRequest1) Successes: 956994 Connects: 956949 Return Code Failures: 0 Early Server Closes: 0 Content Verification Failures: 0 Timeouts: 0 Connect Min time (milliseconds): 0 Connect Max time (milliseconds): 30 Connect Mean time (milliseconds): 0 Min time (milliseconds): 15 Max time (milliseconds): 6482 Mean time (milliseconds): 183
从实验数据可以看出,对缓存代理服务器进行的压力测试,每秒访问页面数为249.67;而对于WebSphere代理服务器进行的压力测试,每秒访问页面数为267.62。因此,自缓存代理服务器迁移至WebSphere代理服务器并不会产生系统性能下降等不良因素的影响。
WebSphere代理服务器保证性能的前提下,相对于Caching Proxy提供了更多的功能和更强的易用性,这些都将成为Proxy Server逐渐替代现有的Caching Proxy的主要原因。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/21631650/viewspace-600239/ ,如需转载,请注明出处,否则将追究法律责任。