实际的生产环境如下所示,为了保证高可用性,所有的服务器包括应用服务器\WebServer\WebSeal都做了负载均衡,最前端是由一台F5负载均衡交换机进行分发。应用服务器和IHS实际有两台机器,都分别部署了WAS和IHS,每个WAS都创建了两个profile,每两个profile做一个集群,两个个集群上分别部署了不同的应用(portal和OA)。
方便起见,两个Cluster使用了同一个DM进行管理,在这个DM里面,又注册进来两个IHS,并且两个IHS都做相同配置,每个IHS都可以对两个cluster进行负载均衡转发。这样的效果是,只需要访问呢http://ihs1/oa就能访问OA了,访问http://ihs1/portal就能访问portal了,主机名换成ihs2也是一样,其中任何一个服务器down掉也可以继续提供服务。
webserver貌似把后端各应用服务器的地址、端口都隐藏起来了,只需要通过一个地址和端口,通过不同的上下文,就可以访问不同应用服务器上应用了。
恩,看上去很爽,但有什么问题呢?为方便起见,我们把这个部署简化一下,去掉所有的集群相关的东西,F5和webseal都不要了,只说最关键的东西。
简化后的部署如下图,只剩下一个IHS,后端两台应用服务器,分别部署portal和OA。实现的效果仍然是只需要通过http://ihs/oa和http://ihs/portal就可以分别访问portal和OA了。
这样的部署,如果OA和Portal之间各管各的,不需要在一个浏览器进程中同时访问两个应用,也没有任何问题。但如果两个应用间确实有联系,比如需要先访问portal,然后链接到一个OA的页面,操作完了再返回portal页面。而且这些操作都是要先登录认证的,而且portal和OA都是使用session来维护当前用户信息的,问题就来了。你可能会发现,访问完OA后,再去访问portal,portal又要你登录了!
真是奇怪呀,这是为什么呢?稍微分析一下,其实也很简单。
我们都知道,http协议是不能保持状态的,所有应用服务器会使用一个session cookie来识别当前用户维护状态。在一般的java应用里,这个cookie的名字叫jsessionid。当应用第一次请求访问session时,应用服务器就会为这个请求生成一个session,并将相应seesionid通过这个cookie发送到客户端。在以后(同一个浏览器进程)的每次访问请求中,浏览器都会将这个cookie又传回到应用服务器,通过这个sessionid应用服务器又能为当前用户获取到session了,是不是很简单?
在我们的场景中,用户现在appsrv1进行了一次登录,appsrv1生成了一个session通过jsessionid这个cookie名称发送给浏览器,因为有个ihs做分发,所以浏览器认为这个cookie是ihs设置的。当用户访问appsrv2时,浏览器仍然是面对的ihs,所以仍将jseesionid发送了过去。appsrv2拿到这个jsessionid,到自己维护的session列表中一查询,肯定没有这个id了,所以认为是无效的,appsrv2自己又生成一个session,并将新的sessionid发送到客户端。客户端再访问appsrv1,这时候sessionid已经变成appsrv2生成的了,在appsrv1中肯定又找不到了,当然就会再要求你重新登录了~~~~
解决这个问题,比较容易想到的当然是改一下每个应用服务器用来维护session的cookie名称,不要都使用默认的jessionid,这样各管各的,当然就没问题了,但这个要应用服务器支持才行。要么就使用多个ihs,每个集群都使用专用的ihs,也OK。在我们的生产环境中,因为使用了webseal反向代理,我的方法是分别为两个集群的上下文配置了一个junction,webseal就会分别去维护两个集群的cookie了,相当与是用了两个浏览器在同时访问应用,也就不会有session冲突的问题了。
分享到:
相关推荐
在当前项目中,为了满足特殊的应用需求,采用了**IHS + WAS6ND**实现多应用服务器集群与多Web端口服务器架构。该架构旨在解决传统单一应用服务器集群无法满足的复杂业务场景需求,特别是在有限的硬件资源条件下,...
这个过程展示了在有限资源下如何通过集群和端口复用实现多应用部署,同时确保了服务的高可用性。虽然看似简单,但在实际操作中可能会遇到各种挑战,需要精细的配置和测试。 值得注意的是,这样的架构设计虽然灵活,...
IHS集群环境下多应用配置,比较不错的例子,可供参考
本经验分享主要探讨如何使用IBM HTTP Server (IHS) 和 WebSphere Application Server Network Deployment (WAS6ND) 创建一个多应用服务器集群,同时支持多个Web端口的服务器架构。在特定情况下,这种架构能够应对...
总的来说,IHS与WAS的关联配置是一个复杂但至关重要的过程,它涉及到多个层面的设置,包括网络、服务器配置、安全以及性能优化。通过正确配置,可以构建一个高效、可靠的分布式Web服务架构。在实际操作中,应遵循...
### WebSphere 应用服务器部署、JNDI 配置与优化、IHS 部署详解 #### 一、WebSphere 应用服务器部署概述 WebSphere Application Server (WAS) 是 IBM 提供的一款高性能的企业级应用服务器,用于部署 Java EE 应用...
WAS(WebSphere Application Server)是IBM公司开发的一种基于Java EE的应用服务器软件,旨在提供高性能、可靠性和安全的企业级应用程序服务器环境。 IHS安装和配置: 1. 安装IHS服务:下载IHS For Linux软件包ihs...
该架构主要是为了满足高可用性和高性能的应用系统需求,通过采用IHS和WAS6ND来实现多应用服务器集群和多web端口服务器架构。 首先,需要建立一个应用系统,以保证应用系统的高可用性和高性能。为此,我们采用了2台...
2. **负载均衡**:IHS可以作为负载均衡器,将客户端请求分发到多个WAS实例上,从而实现资源的合理分配。 3. **安全性增强**:IHS可以通过配置实现SSL加密,保护数据传输的安全性;同时也可以通过设置防火墙规则等...
IHS安装配置手册摘要 本文档为IHS安装配置手册,旨在指导用户安装、配置、管理和调优IHS7.0,提供实用的参考指南。手册涵盖了IHS7.0的安装、配置、日常管理、性能调优和故障诊断等方面的内容。 一、IHS安装配置...
在进行IHS服务器的安全配置时,管理员应该始终遵循最小权限原则,并对服务器上运行的每个应用程序和脚本进行细致的审查,确保它们不会对服务器的安全构成威胁。同时,应该使用强密码策略,并定期更换密码,以及使用...
为了构建一个稳定的WebSphere Application Server (Was7)环境,首先需要创建管理服务器(Management Server)和应用服务器(Application Server)。在本节中,将详细介绍如何在指定的IP地址上创建相应的管理服务器和...
WAS集群是一种高可用性、高性能的架构,通过将多个独立的WAS实例组织在一起,实现应用程序的横向扩展和故障转移。集群中的每个节点都能处理请求,当某个节点故障时,其他节点可以接管其工作,保证服务连续性。 3. ...
在WAS中,一个物理服务器可以拥有多个虚拟主机,每个虚拟主机可以独立托管不同的应用程序,实现多站点、多服务的部署。配置虚拟主机时,主要涉及以下几个步骤: - **创建虚拟主机**:在管理控制台中,选择“网络...
IHS(Intensity, Hue, ...总的来说,IHS融合算法在MATLAB中的实现是一个结合了色彩空间转换、权重分配和反转换的过程,它能够有效地结合不同源图像的优点,提供高质量的融合图像,广泛应用于遥感、医学成像等多个领域。
"IHS无法通过80端口连接到...IHS无法通过80端口连接到WAS应用端口的问题是由于IHS的配置文件或插件配置文件不正确所引起的,解决办法可以通过观察IHS的配置文件、生成插件配置文件和覆盖插件配置文件并重启IHS来解决。
本篇文章主要聚焦于IHS(IBM HTTP Server)的性能优化,它是一款广泛应用于前端集群分发的Web服务器软件。在进行LoadRunner压力测试时,可能会遇到IHS负载不均、无法响应请求等问题,此时就需要对IHS的参数进行调整...
这种配置在面对特定需求时,如硬件限制、多应用系统部署以及多个Web端口的需求时,展现出其灵活性和实用性。 首先,让我们理解为何需要这种架构。传统的WebSphere应用集群通常由一对Web服务器和应用服务器组成,...