《叱咤风云WebLogic企业级运维实战》第7章集群的安装与配置Word格式.docx
- 文档编号:21373542
- 上传时间:2023-01-30
- 格式:DOCX
- 页数:27
- 大小:1.01MB
《叱咤风云WebLogic企业级运维实战》第7章集群的安装与配置Word格式.docx
《《叱咤风云WebLogic企业级运维实战》第7章集群的安装与配置Word格式.docx》由会员分享,可在线阅读,更多相关《《叱咤风云WebLogic企业级运维实战》第7章集群的安装与配置Word格式.docx(27页珍藏版)》请在冰豆网上搜索。
BEAInternalDevelopment"
serial="
616351266349-1844896394531"
type="
SDK"
units="
5"
signature="
MC0CFQCQrk+Kbddfz3RHVH6uGfj"
/>
2.了解网络和安全拓扑
(1)集群是否位于单个局域网中?
(2)集群是跨LAN还是WAN?
根据您选择的网络拓扑,安全要求也将会有所不同。
某些网络拓扑会干扰多播通信,所以请尽量避免跨防火墙部署集群中的服务器实例。
3.确定集群架构
(1)使用单层架构还是多层架构?
(2)计划如何执行负载均衡?
(3)是否要使用基本的WebLogicServer负载均衡?
(4)是否要使用第三方负载均衡器?
(5)是否将隔离区与防火墙配合使用?
您所选择的架构将对集群的设置方式产生影响。
根据集群架构,您可能还需要安装或配置其他资源,如负载均衡器、HTTP服务器和代理插件。
4.选择要进行集群安装的计算机
(1)可以在单台计算机上设置集群来进行演示或开发,不过这对生产环境并不实用。
(2)计算机不要使用动态分配的IP地址。
(3)理论上对在集群中的服务器实例数量没有限制,只要有合适的许可证(License)。
(4)大型多处理器服务器可以承载大型集群,一般建议每两个CPU对应一个WebLogicServer实例(当然具体还需要根据应用的负载模型来确定)。
集群的主要优点是负载平衡和故障转移。
如果集群中的多个服务器位于同一台计算机上,则这些优点将显现不了。
如果计算机出现故障,位于此计算机上的所有服务器也都将出现故障,即使负载平衡,处理过程也只能由该计算机进行。
负载平衡器和代理服务器需要了解哪些服务器位于一个集群中,因此,一般情况下,您需要在负载平衡器或代理服务器中配置集群中每个服务器的IP地址。
如果将服务器分配给动态分配IP地址的计算机,那么IP地址会变化,负载平衡器或者代理服务器将无法找到它。
5.确定集群中服务器实例的IP地址或DNS名称以及端口号
在程序中调用实体Bean和会话Bean时,建议使用集群地址作为Provider_URL来构造请求,并且在集群地址中使用DNS名称,此名称可通过DNS映射至集群中每个WebLogicServer实例的IP地址。
动态集群地址需要符合以下格式(以集群中有三个实例为例):
listenaddress1:
listenport1,listenaddress2:
listenport2,listenaddress3:
listenport3
7.3代理服务器Proxy
7.3.1代理服务的角色和作用
代理插件提供了以下优点。
1.利用现有的硬件
如果您已经有一个Web服务器(WebServer,一般用于提供静态内容),您可以复用现有的Web服务器,为部署在后端WebLogic上的应用请求提供动态的HTTP负载均衡和故障恢复。
2.熟悉防火墙策略
使用Web服务器代理使您能够使用熟悉的防火墙政策,以确定您的DMZpolicy。
在一般情况下,您可以继续在DMZ区域放置Web服务器,而不允许客户端直接连接到集群内的WebLogic服务器上。
3.错误恢复
简单而言,failover的意思是当一个执行项特定工作的应用组件/服务因为某种原因而变得不可用时,一个该组件的备份可以继续完成该任务。
WebLogicServer使用标准的通信技术和工具,比如多播(Multicast)、IPSockets和JNDI(JavaNamingandDirectoryInterface)来共享和维护集群中对象的可用性信息。
这些技术使得WebLogicServer可以检测对象在未完成其任务之前就停止的错误,并调度另外一个对象的备份来完成剩余的任务。
关于一项工作完成状态(完成了哪些工作)的信息叫做状态。
WebLogicServer维护状态信息的技术包括会话复制和replica-aware存根。
当一个特定的对象非正常终止其工作时,复制技术激活该对象的一个备份,并从该对象停止处继续运行,并完成工作。
4.负载均衡
负载均衡是在计算和网络环境中对任务的分配和互相通信。
负载均衡可能出现在以下情况下。
有多个对象可以处理相同的任务。
有关所有对象的位置和运行状态的信息。
WebLogicServer允许对象被集群(在多个服务器实例上部署),所以有了多个对象可以做同一工作。
代理服务器的类型有以下几种。
基于软件的代理服务器可以是内部WebLogicServlet或第三方应用程序。
基于硬件的代理服务器通常是物理负载平衡器。
7.3.2代理服务器的配置
1.代理服务器的配置
(1)通过WebLogicWizard来配置。
用DomainConfigurationWizard创建新WebLogic域时可以对其进行配置。
在向导中创建集群后,将显示CreateHTTPProxyApplications(创建HTTP代理应用程序)选项。
未定位到集群的服务器都是HTTP代理服务器的候选对象。
选择CreateHTTPproxyfor<
cluster>
(为<
创建HTTP代理)选项以及将承载此代理应用程序的服务器。
(2)手动创建WebLogic代理服务器。
首先在代理服务器的默认Web应用程序的web.xml文件中配置HttpClusterServlet。
此文件位于Web应用程序目录的\WEB-INF目录下。
要配置HttpClusterServlet,可执行以下操作。
配置一个WebLogicServer实例,以其作为代理将请求转到WebLogicServer实例的集群中。
a.在管理控制台中创建服务器实例。
b.将默认Web应用程序部署到此WebLogicServer实例。
在已部署到代理服务器上的默认Web应用程序的web.xml文件中注册HttpClusterServlet。
HttpClusterServlet的完整类名如下。
WLS6.1:
weblogic.servlet.internal.HttpClusterServlet
WLS7.0,8.1:
weblogic.servlet.proxy.HttpClusterServlet
然后使用web.xml部署描述符中的<
init-param>
元素为HttpClusterServlet定义适当的初始化参数。
示例7-2:
servlet>
servlet-name>
HttpClusterServlet<
/servlet-name>
servlet-class>
weblogic.servlet.proxy.HttpClusterServlet
/servlet-class>
param-name>
WebLogicCluster<
/param-name>
param-value>
serverA:
7001:
7002|serverB:
7002|serverC:
7002
/param-value>
/init-param>
DebugConfigInfo<
ON<
/servlet>
代理Servlet需要被定义为受管服务器的默认Web应用程序。
这可以在Web应用程序目录的\WEB-INF目录下的weblogic.xml部署描述符中定义。
Servlet映射如下。
配置Servlet映射。
示例7-3:
…
servlet-mapping>
url-pattern>
/<
/url-pattern>
/servlet-mapping>
*.jsp<
将代理Servlet映射到<
。
具体而言,就是映射所需代理的文件的扩展名,例如*.jsp。
如果将<
设置为“/”,则任何代理服务器无法解析的请求都将被发送到集群中的服务器。
但是,如果您希望代理对*.jsp类型文件的请求,则仍必须专门映射该文件扩展名。
2.第三方代理服务器
如果您使用的是受支持的第三方Web服务器,而不是利用WebLogicServer作为Web服务器,则需要设置一个代理插件。
以下是支持的第三方Web服务器类型。
(1)NetscapeEnterpriseServer。
(2)ApacheWebServer。
(3)MicrosoftInternetInformationServer。
7.3.3F5硬件负载平衡器及其他
F5负载均衡技术
F5BIG-IPLTM(本地流量管理器)是一台对流量和内容进行管理分配的设备。
它提供12种灵活的算法将数据流有效地转发到它所连接的服务器集群中。
而从用户角度看到的只是一台虚拟服务器。
用户此时只需访问定义于BIG-IPLTM上的一台服务器,即虚拟服务器(VirtualServer)。
但它们的数据流却被BIG-IP灵活地均衡分布到所有的物理服务器中。
BIG-IPLTM可以通过多种负载均衡算法对流量进行分配,这些算法包括以下各个方面。
(1)轮询(RoundRobin)。
(2)比率(Ratio)。
(3)优先权(Priority)。
(4)最少的连接方式(LeastConnection)。
(5)最快模式(Fastest)。
(6)观察模式(Observed)。
(7)预测模式(Predictive)。
(8)动态性能分配(DynamicRatio-APM)。
(9)动态服务器补充(DynamicServerAct)。
(10)服务质量(QoS)。
(11)服务类型(ToS)。
(12)规则模式。
关于F5BIG-IP的详细信息,请参考其官方文档。
7.4如何创建集群
7.4.1集群环境确定
集群环境确定见表7-1。
表7-1
Servername
Ip
Port
备注
Ms1
192.168.0.139
7001
管理服务器
As1
本机被管服务器
As2
192.168.0.140
7003
远程被管服务器
Cs
239.192.0.0
7777
多播
7.4.2集群配置步骤
图形化界面的配置比较简单,这里不做介绍,下面主要介绍以Linux下的字符界面配置集群。
(1)成功安装完WebLogic后,转到安装目录下的%weblogic_home%/wlserver_10.3/common/bin,运行config.sh文件,注意模式为console,如图7-2所示。
图7-2
(2)进入安装第一步,选择是新建域还是扩展现有域,我们这就从创建域开始,当然,当您已经拥有一个域时,可以选择扩展现有域。
下面我介绍一下安装过程中输入的合法性,如果提示是有选择性的,当然一般是一个数字,当您选择了相应的数值,界面的指示也会有相应的显示,图7-3所示默认的是选择了1。
选择确定后可以输入“Next”或者“n”进入下一步设置。
(3)接下来是选择域模板,这个模板的作用是定制您要配置哪些组件,比如,如果您就是一个单机,没有必要用集群,您就可以定制自己的配置模板,在配置过程中不显示配置集群这一步。
如果想定制自己的配置过程,您就可以用到WebLogic提供的自定义模板的功能。
这里就不做介绍了。
WebLogic提供了一个通用的配置模板,简单的集群配置可以通过这个完成,所以可以在默认模板下开始集群配置,如图7-4所示。
图7-3
图7-4
(4)选择了默认模板后,就会显示可用模板,这里直接进行下一步操作就可以了,如图7-5所示。
图7-5
(5)接下来是配置doman域了,输入您的域名后按Enter键,再单击Next按钮,如图7-6所示。
图7-6
(6)这一步是选择您将域安装在哪里,这里选择默认位置,如图7-7所示。
(7)配置manager,注意密码至少8位,但不能是单一的数字或者字符,如图7-8所示。
(8)选择域启用的模式,有开发模式和生产模式,图7-9所示是两种模式的区别。
图7-7
图7-8
调整参数
开发模式
生产模式
SSL
可以使用WebLogicServer安全服务提供的示范数字证书和示范密钥库。
利用这些证书,可设计出在由SSL担保的环境中工作的应用程序
不应使用示范数字证书和示范密钥库。
如果这样做,将会显示警告消息
部署应用程序
WebLogicServer实例可以自动部署和更新驻留在domain_name/autodeploy目录中的应用程序(其中domain_name为域名)。
建议只在单服务器开发环境中使用此方法
由于自动部署功能已禁用,因此必须使用WebLogicServer管理控制台、weblogic.Deployer工具或WebLogic脚本工具(WLST)
并发
默认5个
并发数高
图7-9
下面为了测试,选择的是生产模式,如图7-10所示。
图7-10
(9)选择JDK,这里要特别说明的是如果是开发环境,您可以选择自己的JDK,当是生产环境时,建议使用WebLogic提供的JDK,还有JDK的版本要注意与WebLogic版本控制一致,WebLogic10.3使用的JDK版本是1.6。
这里选择自己的JDK,如图7-11所示。
图7-11
(10)接下来是选择要配置的项目,本节主要介绍配置集群,所以选择配置1管理服务器,2受管服务器、集群和计算机,只要输入前面的编号,相应的项目就会被选定,如图7-12所示。
图7-12
(11)接下来配置管理服务器,按照前面表的要求,输入正确的监听地址、端口,确定无误后单击Next按钮,如图7-13所示。
图7-13
(12)配置受管服务器,先输入受管服务器的名称,如图7-14所示。
图7-14
(13)修改相应的项目,确定无误后选择“5-完成”选项,然后用同样的步骤配置受管服务器ms2,如图7-15所示。
图7-15
(14)配置clusterserver,注意选择clustermessagingmode的multicast选项,如图7-16所示。
图7-16
(15)为集群分配受管服务器,如图7-17所示。
图7-17
(16)这里两个都选上,如图7-18所示。
这里简单补充ms2在远程服务器的配置过程。
安装同一个版本的WebLogic。
配置与管理服务器上同名的Doman域名以及manager口令。
配置受管服务器,和主机上配置的ms2监听地址和端口一致。
其他的集群就不用配置了。
图7-18
到这里,一个简单的集群就配置好了,接下来是测试集群配置是否成功。
7.5集群的启动
7.5.1管理服务器AdminServer的启动
首先启动管理服务器,如图7-19所示。
图7-19
管理服务器启动成功,如图7-20所示。
图7-20
7.5.2受管服务器ManagedServer的启动
注意格式,第一个参数是输入启动脚本,第二个是输入您要启动的受管服务器名,第三个是输入您刚配置的管理服务器的地址,如图7-21所示。
图7-21
受管服务器启动成功,如图7-22所示。
图7-22
如果启动远程受管服务器,就不用启动管理服务器了,如图7-23所示。
图7-23
远程受管服务器启动成功,如图7-24所示。
图7-24
到这一步管理服务器和受管服务器都启动成功,表明配置没有问题了。
7.6集群中应用的部署
(1)访问控制台,选择左侧的部署选项,如图7-25所示。
(2)单击“安装”按钮,选择要部署的应用,如图7-26所示。
图7-25图7-26
(3)打开要部署应用的地址,选择要部署的应用,单击“下一步”按钮。
(4)选择定位模式,如果是应用就选择“将此部署安装为应用程序”单选按钮,如果是供给应用调用的公用包,如EJB,就选择“将此部署安装为库”单选按钮,如图7-27所示。
图7-27
(5)选择部署到哪个服务器,这里我们测试的是集群,所以选中Cluster复选框,如图7-28所示。
(6)这里是一些部署可选配置,名称为您访问时对应的应用名,安全属性以后会做介绍,这里选择默认选项,因为是集群,记得选择“将此应用程序复制到每个目标”单选按钮,如图7-29所示。
图7-28
图7-29
单击“完成”按钮后完成部署,接下来就是测试集群了。
7.7集群测试
(1)启动应用服务,如图7-30所示。
图7-30
如果启动成功,则会显示如图7-31所示的活动状态。
图7-31
(2)接下来可以通过浏览器访问应用,测试部署应用成功与否。
控制台输出如图7-32所示。
图7-32
到这里集群的配置、应用部署已经成功了。
7.8Session复制
7.8.1Session复制的原理
1.HTTP会话状态复制
WebLogicServer使用两种方法来跨集群复制HTTP会话状态。
(1)内存中复制。
使用内存中复制时,WebLogicServer会将会话状态从一个服务器实例复制到另一个服务器实例。
主服务器在客户端首先连接的服务器上创建主会话状态,在集群中的另一个WebLogicServer实例上创建次级副本。
该副本总是保持最新状态,当主服务器失败时可以使用该副本。
(2)基于Session的持久化。
WebLogicServer可以将Session持久化到文件或者JDBC数据源,从而达到在各个服务器实例之间共享Session信息的目的。
2.HTTP会话复制流程
(1)代理连接过程。
当HTTP客户端请求Servlet时,HttpClusterServlet将该请求代理传输到WebLogicServer集群。
HttpClusterServlet维护集群中所有服务器的列表以及访问集群时要使用的负载平衡逻辑。
在上面的示例中,HttpClusterServlet将客户端请求路由到了WebLogicServerA承载的Servlet。
WebLogicServerA成为了承载该客户端的Servlet会话的主服务器。
为了对该Servlet提供故障转移服务,主服务器将客户端的Servlet会话状态复制到集群中的某个次级WebLogicServer。
这样可确保即使在主服务器失败(例如由于网络失败)时该会话状态的副本仍存在。
在上面的示例中,服务器B被选择为次级服务器。
Servlet页通过HttpClusterServlet返回到客户端,然后客户端浏览器收到指令,写入列出该Servlet会话状态主位置和次级位置的Cookie。
如果客户端浏览器不支持Cookie,WebLogicServer则可以使用URL重写来代替。
(2)使用URL重写跟踪会话副本。
WebLogicServer的默认配置使用客户端Cookie来跟踪承载客户端Servlet会话状态的主服务器和次级服务器。
如果客户端浏览器禁用了Cookie的使用,WebLogicServer还可以使用URL重写来跟踪主服务器和次级服务器。
使用URL重写时,两个位置的客户端会话状态都会嵌入到在客户端和代理服务器之间传递的URL中。
为了支持此功能,您必须确保在WebLogicServer集群上启用了URL重写。
有关如何启用URL重写的说明,可参阅“使用会话和会话持久性”中的使用URL重写功能。
(3)代理故障转移过程。
如果主服务器失败,HttpClusterServlet就使用客户端的Cookie信息来确定承载会话状态副本的次级WebLogicServer的位置。
HttpClusterServlet会自动将客户端的下一个HTTP请求重定向到次级服务器,故障转移对于客户端是透明的。
发生失败之后,WebLogicServerB成为承载Servlet会话状态的主服务器,并且会创建新的次级服务器(在上面示例中为服务器C)。
在HTTP响应中,代理会更新客户端的Cookie来反映新的主服务器和次级服务器,以考虑后续故障转移的可能性。
在由两个服务器组成的集群中,客户端将以透明方式故障转移到承载次级会话状态的服务器。
但是,客户端会话状态的复制不会继续,除非另一个WebLogicServer变为可用状态并加入该集群。
例如,如果原始主服务器重新启动或重新连接网络,则会使用它来承载次级会话状态。
7.8.2Session复制的配置
1.内存中复制
要配置内存中复制,请执行下列操作。
(1)配置代理服务器(如果适用)。
(2)配置复制组和(或)计算机(可选)。
(3)在weblogic.xml部署描述符中指定持久性类型。
配置内存中复制会话持久性。
示例7-4:
session-descri
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 叱咤风云WebLogic企业级运维实战 叱咤风云 WebLogic 企业级 实战 集群 安装 配置