在Linux上部署WebLogic
摘要:本文概述了使用Linux/ WebLogic组合时的部署要点
使用开放源代码软件平台浪潮的兴起,带来了部署在Linux和BEA WebLogic上的关键应用的数量上的增加。事实上,对于很多企业而且,WebLogic部署是Linux系统上的首选安装。
本文概述了使用Linux/ WebLogic组合时的部署要点。
Linux部署将传统的基于Intel的服务器从网格环境跨越到大型机系统(例如,带有Linux客户端的IBM z/VM)。本文只介绍了Intel体系结构,但是本文所介绍的几乎所有要点也适用于非Intel部署。
为什么选择Linux?
为什么Linux部署的数量在不断增加?对于那些专有的操作系统而言,Linux提供了另外一种选择。它降低了一些客户的拥有成本,且拥有大量熟悉它的从业人员。Linux是一个高度可配置且通常可获得源码的操作系统,所以您可以改变行为或者重新编译特定于您的站点的选项。最后,大量供应商支持Linux,从而使客户拥有挑选应用程序软硬件的权利。
软件的选择
WebLogic目前支持主流的Linux发布(Red Hat 和SUSE)。要获得所支持的配置的最新列表,请参考BEA网站((http://edocs.bea.com/wls/certifications/certs_810/overview.html#1043408)。Red Hat和SuSE均包含了一些额外的特性(如群集服务),这或许会对系统的安装有用。在写作此文之时,Red Hat刚发布了企业版Linux v3,并对其内核进行了若干重要的升级,如Native POSIX Threading Library(NPTL),详细情况请浏览有关此版Linux的证书页面。
选择JVM
BEA的JRockit JVM可用于Intel Linux部署上,并且可以提供许多优点,因为它既支持32位环境也支持64位环境。JRockit设计用于服务器端执行,并且拥有一些高级特性,如可改善应用程序性能的自适应优化。如果运行于其他不同的平台(如zLinux),请参考BEA支持的平台页面,以所支持的JVM。
安装JVM(JRockit)
JRockit的安装很简便:首先,根据所用的平台下载安装程序,执行下载的文件(./jrockit-8.1sp1-j2se1.4.1-linux32.bin),并根据屏幕提示操作。
如果运行的是具有超线程功能的Intel处理器,在安装完成后需要一个额外的步骤。任何一个处理器(实际的或虚拟的)的cupid必须可被任意进程读取;此功能既可自动实现也可通过修改/dev/cpu/X/cupid(X是CPU号)文件的权限来实现。有关启用此功能的技术细节,请参考JRockit 的发布说明(http://edocs.bea.com/wljrockit/docs81/relnotes/relnotes.html)。
安装BEA WebLogic
如同JRockit,BEA WebLogic的安装同样十分简便。下载合适版本的安装程序,然后执行所下载的文件(./platform811_linux32.bin)。安装程序提供图形用户界面(缺省)或者控制台(非图形用户界面)安装选项。如果是在没有图形用户界面的平台上或在远程系统上安装,当启动安装程序时,可跳过"-mode=console"选项。此两种安装选项均可引导用户完成安装的全过程,此安装过程是交互的,且允许用户选择安装选项和主目录。
维护
在Linux上部署BEA WebLogic的过程中,有许多因素必须考虑。例如,必须对J2EE应用服务器以及外围系统进行合理的配置,以使系统达到最优性能。在部署环境之前,应启动维护环境的进程以获得最佳的性能表现。此项预先规划将在应用程序的产品阶段得到回馈。收集应用程序及支持其运行的基础结构的性能参数非常重要(即使是在产品阶段之前)。在产品阶段之前对这些数据的记录使对应用程序性能的评估成为可能,同时,也可据此建立一个参考基线。在产品部署前,可根据此基线对应用程序或其环境的变化作出有效性的判断。
一旦进入生产环境阶段,搜集并积累这些数据有利于性能模型的建立。
大多数供应商通过电子邮件向您提供获得最新程序补丁和升级包的信息服务。必须确保已经注册了这种服务,并且这些电子邮件将发给很多IT组负责人员。
毕竟,如果通知只发给一个用户,而又碰巧在此用户休假时发布了一个紧急的补丁,可想而知将会发生什么。尽管也有一些自动更新的服务,可我还是不愿意使用此种服务,我还是优先考虑使用更新通知的方式。然后,您可以决定哪种服务适合自己的安装,以及是否存在任何跨供应商的依赖性。
尽管不同的供应商所提供的产品通常可以很好地协同工作,但在产品部署之前,在自己的环境中,对应用程序和供应商所提供的解决方案之间的融合问题进行测试是很必要的。应该在部署到产品中之前和之后,对系统性能进行衡量和比较。
Tripwire(www.tripwire.com)是一个可用于Linux部署的工具。开放源代码的版本和商业化版本都对确定"周末又发布了什么更新"这种综合症很有帮助。使用Tripwire给服务器创建一个基线,这对于更改管理进程以保证软件和文件的一致性或者回滚更改是有用的。
环境可见度
BEA WebLogic应用程序通常会有一些非Java的外部触点,Web服务器和数据库就是例子。WebLogic应用程序的整体性能受到这些其他组件的执行情况和Linux的整体性能的共同影响。
收集EPA(Environment Performance Agent)数据的例子包括:
· Linux VM(虚拟机)数据
- 是否内存太少从而导致Linux频繁交换?
- 有多少任务处于挂起状态,系统的平均负荷是多少?
· Web服务器数据
- 在测试期间产生了多少http错误?
- 有没有子线程被挂起?
· 数据库
- 剩余多大空间?
- 缓存命中率是多少?
· 网络
- 什么IP在产生最多的请求?
- 网络上是否有任何报警事件?
应对什么进行监控?
这是一个意味深长的问题,答案实际上取决应用程序以及您监控和衡量成功的目标。
作为一条普遍的规则,包括应用程序中的J2EE组件在内,任何给应用程序提供输入的部分,或者应用程序服务器处理请求所依赖的事物都应该受到监控。复习上面的"环境可见度"一节,并考虑您自己的应用程序所具有的触点。您是如何衡量可用性和可接受的性能,您又将实际采取什么措施来处理所搜集的数据(非常有价值)?
收集CPU、组件响应时间、内存利用率、线程、JDBC池利用率和并发请求等性能数据是理解应用程序性能的起点。当然,还有许多其他的组件也是可用的,并且可以统一衡量。
在部署应用程序之前一个需要考虑的问题就是,如果应用程序没有在所设定的基线内运行的话,将会发生什么情况(假定在产品阶段之前创建了一个基线)?
Linux配置
第一步就是要理解物理机器的概念。借助一些显示工具用于:
· 显示CPU信息(cat/proc/cpuinfo)。显示每台机器的CPU类型信息。
· 显示内存信息(cat/proc/meminfo)。显示内存容量、交换分区和缓存的详细情况。
· 显示磁盘容量及剩余空间(du -lh)。
· 显示网络配置(ifconfig)。
以上收集的信息将有助于确定应用程序文件所应驻留的位置、网络绑定,以及应用程序(Java堆)可使用内存的大小。
检查一下机器上正在运行的服务。例如,运行BEA WebLogic的机器是否应该运行FTP或邮件服务器?删除(或注释掉)不必要的服务,并编辑/etc/xinetd.conf或/etc/inetd.conf(取决于Linux发布)。一旦将那些不必要的服务删除掉后,就建立一个关于磁盘和内存利用率的基线。用负载生成工具观察Linux的性能表现,每秒产生多少次I/O操作,使用多少交换空间(iostat和vmstat)。
这些基线数据随后可被用于监控。
运行时秘密
现在,WebLogic已部署在Linux上,让我们从Linux的角度去看一下某些进程信息。
找到针对WebLogic的Linux进程号(ps -eflgrep java)。注意,Linux为每个线程具有一个进程,所以,相对于其他的操作系统,显示的内容会略有不同。
举例来说,假设进程号(pid)为27260。
如果我们想知道哪个终端启动了服务器以及该终端是不是远程的,该怎么办?进入/proc/fd目录,其中包含该进程所使用的文件描述符列表。现在使用列表命令(ls -l)列出fd 0(标准输入设备),则会列出实际所用的设备。在本例中是/dev/pts/6。还可利用Linux的who命令查看登录该设备的用户及其IP地址。
> cd /proc/27260/fd
> ls -l 0 lrwx------ 1 root root 64 Nov 20 14:21 0 -> /dev/pts/6
>who
weblogic pts/6 Nov 20 10:55 (192.168.1.105)
也可显示startup命令和该进程正在使用的环境变量。对于想要跟踪某个功能选项是否已经通过脚本传递给了进程,此项操作尤为有用。
另外一个很有用的技巧可用来确定该进程正在使用哪些文件。显示maps文件(cat maps),此命令显示已经打开的文件。一个例子用例是确定某个JAR文件是否已加载以及它是从什么目录加载而来的。
> grep trader.jar maps
/opt/bea/weblogic81/samples/domains/examples/examplesServer/stage/
_appsdir_webservices_trader_ear/trader.jar
调优考虑
当应用程序进入产品阶段很短时间后(3-6个月),操作系统、应用程序以及任何触点都应该调优--或者至少应该重新检查一下配置参数以确保它们还是适当的。这是对环境及其触点进行持续衡量的好处之一。如果没有针对关键的参数进行持续衡量,那么这种衡量将是徒劳的。
有时,当工作负载发生了变化时,调优是很必要的。当更新的代码或设计已经迁移到产品中之后,或者应用程序现在支持一个更大的用户群,那么调优可能会较为复杂。无论何种原因,对应用程序的调优需要小心谨慎地进行确认,在大多数情况下,只有性能监控人员才能对整个应用程序施加影响。首先,在操作系统级启动,并依次通过不同的堆栈。查看当前性能标准,并使用诸如Transaction Tracer的工具快速显示哪些组件占用一个给定请求中的大部分处理时间。
查看操作系统所报告的各时间段内的平均负载、可运行任务,以及磁盘交换活动进行检查。如果磁盘活动只是在一个设备上进行,请考虑是否是文件重定向的问题。或许并行进程的数量已增加(同一台机器上的附加实例)。如果平均负载很重或可运行任务数很多,那么检查一下是什么别的进程在竞争系统的资源。将若干应���程序实例部署到各个独立的机器上可把工作负载分配到多台机器上,这样就可以降低单个机器的资源占用率。
当调优JVM时,要查看一下内存的使用率和所使用垃圾收集方案。JVM调优文档 http://edocs.bea.com/wljrockit/docs81/tunelnux是一个很好的资源,概要列出了可用的垃圾收集和线程选项。WebLogic应用程序本身也必须检查。文章"Tuning WebLogicServer"http://edocs.bea.com/wls/docs81/perform/WLSTuning.html是很好的入门资料。接下来,利用所收集的数据来验证性能。
检查WebLogic内部的执行队列和线程池。有没有正在等待处理的请求?在JDBC内部,是否有足够的可用连接用于轮询处理预期的工作负载,同时不会造成超限分配。
参考资料
与供应商谈论您的部署方案。他们通常了解问题的多种解决方案并常常能根据他们的经验给出具有洞察力的意见。以下的网站在对在Linux上部署WebLogic会有所帮助:
· www.wilytech.com
· CLICK!!
· http://e-docs.bea.com
总结
希望此文为您提供了有关BEA WebLogic产品以及在您的环境中对Linux进行部署的背景资料。应用程序服务器处理的快慢取决于WebLogic接收请求以及从后端检索数据的速度,所以,调优是很关键的。
我们概要列出的触点和调优考虑只是一个起点。
您的应用程序及环境会存在其他的触点。但请记住,在部署Linux和BEA WebLogic方面,您并不寂寞。
Linux部署问题分析
使用诸如Wily's Introscope的性能监控工具,可以捕获并在永久存储介质上记录应用程序以及构成整个应用程序的其他环境组件的性能参数。
使用Introscope和诸如环境性能代理软件(Environment Performance Agent,EPA)这样的Introscope特性(特别设计用于收集非Java触点的性能参数),可以得到操作环境的一个"整个应用程序"视图。例如,可以利用Introscope EPA来收集最关键的操作系统级数据和Web服务器数据,可以用Introscope收集有关J2EE应用程序的数据,而后,将以上的数据相结合并在面板上显示。此数据随后可被转化为性能参数,并可被Introscope用来提供一个应用程序整体性能的视图。
Introscope Transaction Tracer(Introscope事务跟踪器)这样的工具使您能够为分析捕获基线以外的请求,或者能够创建警报以通知潜在领域的支持人员进行检查。这是用来解决运行时问题的方法之一。 Introscope LeakHunter也可用来跟踪应用程序中的潜在内存泄漏。如果存在内存泄漏,则可给出类名、方法及其大小,以便于程序员对问题进行修改。
使用Introscope,可在产品部署前为公司中不同的支持团队创建不同的面板,以便在生产阶段出现问题时,团队成员就已经从应用程序服务器和支持系统获得了数据,这样,就更有利于问题的解决。
使用Introscope EPA,可以收集Linux的实时性能数据并用于监控和报警。如果将这些数据与用Introscope从BEA WebLogic所收集的数据相结合,一个关于应用程序及其所有支持系统的图像就会完整地呈现在我们眼前(见图1)。
作者简介
Eric Gudgion是Wily Technology公司的一位专业的服务工程师。他有19年以上的计算领域的工作经验,涉及大多数的商用计算机环境。他的大多数时间花在操作系统、网络、应用程序服务器以及性能调试产品方面。