2-10-1263集团公司应用服务器中间件建设技术规范-20101022

PAGE集团公司应用服务器中间件建设技术规范中国航天科工集团公司二〇一〇年九月PAGEI目录TOC\o"1-5"\h\z\u1目的及范围 12术语和定义 12.1J2EE 12.2负载均衡(LoadBalance) 12.3服务器集群 13人员岗位职责 14产品选型 24.1选用范围 24.2基本原则与技术要求 25应用服务器中间件建设基本策略要求 25.1应用服务器中间件安装与卸载要求 25.2应用服务器中间件配置要求 35.3应用系统部署要求 35.4应用服务器安全管理要求 35.4.1全局安全管理要求 35.4.2资源访问安全管理要求 35.5应用服务器集群管理要求 46技术规范 46.1WebSphere应用服务器中间件技术规范 46.1.1应用服务器中间件安装与卸载 4安装准备 4应用服务器中间件安装 7应用服务器中间件卸载 96.1.2应用系统部署 96.1.3性能调优 106.1.4备份与恢复 126.2Jboss应用服务器中间件技术规范 136.2.1应用服务器中间件安装与卸载 13安装准备 13应用服务器中间件安装与配置 13应用服务器中间件卸载 136.2.2应用系统部署 146.2.3性能调优 146.2.4备份与恢复 167集群与负载均衡规范 167.1配置规划基本规范 167.2集群配置内容 177.3WebSphere应用服务器集群配置规范 187.4Jboss应用服务器集群配置规范 198日常管理 208.1应用服务器性能数据监控 208.2应用服务器升级和移植规范 208.3日志管理规范 229安全管理规范 22PAGE1目的及范围本规范规定了中国航天科工集团公司应用服务器中间件建设的相关技术要求，重点对应用服务器管理员的日常管理活动进行规范，适用于集团公司所属各单位应用服务器中间件建设工作，各个建设阶段的过程可参照本约定执行。术语和定义J2EE“Java2Platform,EnterpriseEdition”的缩写，即Java2平台企业版，是由SUN、BEA、IBM、Oracle等主要EBusiness平台开发商合作定义的一组技术规范与指南，简化并规范应用信息系统的开发与部署，提高应用可移植性、安全与再用价值，已成为工业标准。负载均衡(LoadBalance)负载均衡是由多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，通过某种负载分担技术，将外部发送来的请求均匀分配到对称结构中的某一台服务器上，而接收到请求的服务器可以独立地回应客户的请求，籍此提供快速获取重要数据，解决大量并发访问服务问题。服务器集群服务器集群是指将很多服务器集中起来一起进行同一种服务，在客户端看来就象是只有一个服务器，群集化操作可以获得很高的计算速度或减少单点故障数量，实现了群集化资源的高可用性。服务器集群分为水平集群和垂直集群两种实现形式。垂直集群是指同一机器上部署多个服务器，充分利用硬件资源；而水平集群利用多台机器资源，每台机器部署相同的应用。人员岗位职责J2EE规范按照企业应用开发、部署等不同阶段各类人员的不同任务分工，将各类人员分为J2EE产品提供商、工具提供商、应用程序组件开发者、应用程序组装者、应用程序部署者和系统管理员等五类角色。本规范涉及的角色是应用程序部署者和系统管理员，负责配置和部署J2EE应用程序，在程序运行时管理计算机和网络结构，并且监控运行时环境，包括设置事务控制、安全属性和指定数据库连接等。其主要职责如下：应用服务器管理根据应用系统的应用范围、发展趋势、性能等因素，为应用系统规划合适的硬件配置和合理的应用服务器中间件。规划合理的集群配置，建立有效的负载均衡机制，提高应用系统的吞吐量和可用性。应用服务器中间件的安装与卸载完成应用服务器中间件的安装卸载，根据各类应用系统的需要，设置连接配置、目录配置、Java引擎配置、会话跟踪等全局配置参数。应用系统部署合理规划各类应用系统部署环境，配合应用系统实施人员完成应用系统的部署工作。日常管理与性能调优监控应用服务器的各项性能指标，并能根据检测结果和各项性能调优的最佳实践，对影响性能的相关参数进行调整，优化应用服务器的性能。建立有效的备份与恢复机制，以便应对各种突发情况快速恢复应用系统。安全管理结合集团对应用系统安全的相关规定和应用服务器中间件提供的安全机制，制定合理的安全策略，提高应用服务器和应用系统的安全保护级别。产品选型选用范围根据应用服务器中间件的市场占有率、性能和技术指标、可扩展性，是否具有外部工具的支持以及应用服务的可移植性等要求，规定应用服务器应该主要产品包括如WebSphere、WebLogic、IplanetApplicationServer、OracleIAS、金蝶Apusic、Jboss等，以及Web服务器如MicrosoftIIS、ApacheTomcat等。基本原则与技术要求集团公司各级单位应用服务器层建设应遵循如下原则要求：应用服务器层建设应遵循业界主流技术标准，以提供更宽泛的技术适应能力为原则开展中间件的选型工作，采用J2EE为主的技术体系产品，同时应兼顾在必要时能容纳.Net技术体系产品。各级单位应统筹规划本级单位内J2EE基础应用服务器的软件选型建设，将各类应用服务器软件的种类限定在有限范围内，包含商用和开源应用服务器在内应控制在2种以内，禁止超过3种。各级单位应在系统分析本级单位整体业务应用在功能访问、性能、可靠性等方面的需求后，统筹规划本级单位应用服务器层的软硬件部署，应避免按单个业务应用进行应用服务器软硬件部署。应用服务器中间件建设基本策略要求应用服务器中间件安装与卸载要求安装之前需要根据应用系统的需要，从内存、操作系统、Web服务器、Java开发组件（JDK）、JavaservletAPI、Web浏览器等方面的要求，结合集团技术架构的规定，选择合适的应用服务器中间件，为应用服务器中间件的安装规划合理的服务器配置。文件备份。将所需要的重要文件及应用服务进行备份，防止在安装过程中由于错误发生文件和应用服务丢失的情况。如果服务器上安装过该类应用服务器中间件，新安装前需要对原安装进行完整卸载。对于部分保留安装痕迹的应用服务器中间件，卸载过程包括软件卸载、操作系统关键路径和历史数据清理等，不能仅删除应用服务器中间件的相关安装文件。应用服务器中间件配置要求根据应用服务器类型，安装完成后需要对应用服务器管理页面、连接池、JNDI、Java引擎、会话跟踪、日志等全局参数进行设置。在应用服务器运行过程中，对活动会话、数据库缓冲池使用情况、错误日志等数据进行收集和监控，分析资源的实时使用情况，并根据监控的数据，对应用服务器中间件相关参数进行调整，优化应用服务器的性能。应用系统部署要求J2EE应用可以以企业应用包（EnterpriseApplicationArchive,简称为EAR）的形式或者是展开目录格式的形式部署到应用服务器上。一个组件可以被打包在EJB包（JAR）文件中，也可以在Web应用包（WebApplicationArchive，简称为WAR）文件中，或者是资源适配器包（ResourceAdaptorArchive，简称为RAR）文件中。如果以展开格式的形式部署J2EE应用，则在此格式中只应包含Web应用组件。如果是以包的形式部署J2EE应用，则所有应用组件都应采用包的形式。应将一类应用尽量规划到一个应用服务器。应用服务器安全管理要求全局安全管理要求检查应用服务器默认的安全性配置是否符合要求。关闭不必要的访问端口。关闭共享文件夹的普通用户访问权限。关闭不必要的服务。及时安装应用服务器补丁。资源访问安全管理要求在应用服务器配置过程中，需要对以下资源进行设置和保密，保证应用服务器安全，需要的配置包括：管理员帐户名、密码。登录认证模式。根据需要配置CA登录认证模式。操作系统用户权限。为应用服务器所在的操作系统用户配置合适的管理权限，防止一般用户不经授权直接具有应用服务器管理权限。配置应用程序安全性。根据需要定义访问控制列表（ACL）、配置应用服务器中的应用程序资源的访问安全性。应用服务器集群管理要求根据应用的需要选择集群形式，包括水平集群和垂直集群。集群服务应充分考虑所有可能出现的失效情况，包括HTTP服务器、Web容器、EJB容器、管理服务器和数据库等。集群服务至少保证进程可用和数据可用。进程可用指如果一个节点上的进程出现了故障，在另一个节点上能够恢复这个进程；数据可用是指不会因为节点故障影响它正在处理的数据。集群服务至少要为应用服务提供如下功能：简单清晰地进行集群系统的拓扑管理。支持多种负载平衡算法。能够完整地对组件状态进行复制。在服务器出现故障时，透明地对客户程序进行故障恢复。在不同网络环境下支持多种通信方式。技术规范WebSphere应用服务器中间件技术规范应用服务器中间件安装与卸载安装准备WebSphere应用服务器中间件安装前，需要从服务器硬件配置、操作系统版本、网络配置、主机名、拓扑架构等方面规划应用服务器安装环境。主要内容如下：应用服务器硬件配置WebSphere应用服务器对硬件配置的要求主要体现在待部署平台的硬件架构、CPU、内存和磁盘存储空间上，通常最低内存要求在512M以上，根据硬件平台、WebSphere应用服务器版本、组件的不同，要求的配置会略有区别。确认操作系统版本是否满足要求使用WebSphere服务器支持的操作系统平台，能确保应用服务器安装、使用过程中环境的正常稳定运行。如果操作系统平台不是IBMWebSphere应用服务器官方支持的平台，在WebSphere应用环境出现问题后则无法获得WebSphere应用服务器的售后支持。确认网络配置/主机名满足要求主机名是WAS安装节点的物理机器的网络名，它必须解析到服务器上的物理网络节点。主机名的值可以是全限定DNS主机名（例如：）、短主机名(例如：hosta)，或甚至是数字IP地址(例如：)，但必须是WAS所在服务器实际配置的主机名。建议在安装WebSphere应用服务器之前配置主机名当WAS配置完毕投入使用之后，更改主机名的过程比较复杂，不推荐更改设定的主机名。如果采用全限定DNS主机名或短主机名，可以通过hostname命令来查看当前系统的主机名。如果没有配置，则到hosts文件中添加相应的条目。选择保持不变的主机名形式，作为WAS使用的主机名在创建WAS的概要文件（Profile）之前，需要根据实际情况，选择三种形式的主机名（全限定DNS主机名、短主机名或数字IP地址)中保持不变的那种主机名形式，作为WAS使用的主机名。如果使用DHCP或者如果经常更改IP地址，建议在概要文件创建时使用全限定DNS主机名或短主机名。如果机器ip固定，而全限定DNS主机名或短主机名有可能更改，则在概要文件创建中使用数字ip。避免带下划线的主机名在unix/linux系统中经常会碰到带下划线的主机名，这在WAS安装中会出现错误,不能正常安装。而且不能通过单纯修改主机映射的方式来修改主机名，所以在安装操作系统的时候要注意避免。确认磁盘空间是否满足要求需要从以下几个方面来计算要预留的空间：WebSphere应用服务器自身代码的占用空间。这个空间一般在1G左右，在不同的系统平台上略有差异。应在WAS安装目录下预留此空间。WebSphere应用服务器在Linux下的默认安装路径是/opt/IBM/WebSphere/AppServer，在AIX下的默认安装路径是/usr/IBM/WebSphere/AppServer（后面我们把此路径简称为WAS_HOME）。用户可以在安装WAS时修改此安装路径。概要文件所占的空间。WebSphere应用服务器创建的概要文件基本类型有3种，每个概要文件所占用的空间如下：应用程序服务器(ApplicationServer)：在WebSphere应用服务器安装没有选择安装样本程序时，这一概要文件所占磁盘空间约为200M。DeploymentManager：30M。定制概要文件（Custom，即nodeagent）：10M。如果要安装WEB服务器，则在WEB服务器所在服务器上要预留WEB服务器所占的磁盘空间。IBMHTTP服务器一般占用110M左右的空间。如果安装WEB服务器，则在WEB服务器所在机器上通常也要安装WebServerPlug-in组件，该组件所占磁盘空间约为200M。WebSphere应用服务器系统日志的占用空间。日志空间的估算要结合系统对日志的配置情况。WebSphere应用服务器的主要日志有SystemOut.log、SystemErr.log。可设置日志文件的大小和保存的历史日志文件数量，从而可以估算出其需要的空间。如果有WEB服务器，需考虑WEB服务器的日志空间。如果客户开启了WEB服务器的访问日志access.log（默认开启），此日志增长的速度极快，要预留足够的空间。备份文件需要的空间。WebSphere应用服务器提供了一个备份命令（backupConfig.bat/sh），用来备份应用服务器的配置及其上应用。建议在系统稳定之后及时备份。对于一个典型生产系统，WebSphere应用服务器这个配置文件经常超过100M。可在发出backupConfig命令时，使用-logfile参数指定该备份文件的存放位置。系统出错时日志，例如JVM在发生OutOfMemory时，在大多数平台上WebSphere应用服务器会默认写javacore文件和heapdump文件，记录错误出现时的JVMHeap、线程情况，以备错误诊断使用。虽然可以调整应用服务器参数使之不产生此类文件，但为了分析问题，通常需要从此类文件入手。这类文件通常都特别大，例如heapdump文件，可能达到几百M。如果多次出现OutOfMemroy，对磁盘空间的占用很快。因此，必须考虑为此类文件预留磁盘空间。WAS安装程序还需要在系统的临时目录（tmp）中有100M以上的空闲空间。用户发布到WebSphere应用服务器上所有应用程序以及应用自身的应用日志的占用空间。这个大小与实际应用相关，而且不同应用可以差别很大。针对特定操作系统的调整WAS对特定的操作系统版本安装的包、内核参数等有特殊要求。例如，对于RHELAS4，必须安装compat-libstdc++-33-3.2.3-47.3.ppc.rpm包（这是保持C++运行时兼容性所必需的，供诸如GSKit的组件、Java2软件开发包（SDK）以及Web服务器插件使用）以及其他一些包。对于Linux、Solaris、HP等系统，需要调整一些相应的内核参数。对于Linux/Unix系统，确认能启动图形界面在Linux/UNIX平台的服务器安装WAS，需要在服务器预先安装Xmanager、X-Win32等支持XWindow的工具软件，以支持启动图形界面。准备合适的安装介质在unix/linux上是32位、64位的安装的介质是不同的，在64位的系统上一样可以按照32位的WAS。两者的安装方式是相同的，但是在后期管理中如果想要使用图形方式来管理profile，在64位上是不支持的，在64位上的profile管理只能使用命令行。所以在安装的时候需要注意版本的问题，应从订购的WAS产品包（包括各个平台、组件的多张CD）中根据安装的WAS组件、操作系统版本、操作系统位数选择需要的安装介质。设计WebSphere环境的拓扑架构根据实际应用场景的不同，规划WAS、Web服务器的网络拓扑结构，如果需要配置集群环境，还需要考虑DeploymentManager、各个结点和集群成员的分布情况。拓扑结构图中应该描述服务器的分布情况、集群的构成、每台服务器实际安装、配置的组件等信息。应用服务器中间件安装安装WAS的过程主要包括安装WAS产品、为产品打补丁、创建概要文件等3个步骤。安装过程如果服务器上曾经安装过WAS产品，安装WAS产品之前，需要停掉正在运行的WAS进程。避免HttpServer的冲突。安装过程中需要注意原有环境中是不是已经有了HTTPServer并且已经安装的Server是不是占用了80端口。安装过程中应该将本地操作系统语言设置为中文。如果发现向导中语言显示为乱码，可以先把本地操作系统语言设置为英文，使用英文语言安装WAS，这样安装完毕的WAS仍然具有中文支持。建议不要安装样本应用程序，以在开发环境和生产环境中都能获得更高性能。通过省略样本，可以将应用程序服务器启动时间缩短60％并节省15％的磁盘空间；可以节省相当程度的进程占用量；并且可以节省WAS产品安装以及每次创建应用服务器概要文件的时间。建议在打完补丁后再创建初始概要文件，以节省打补丁所需的时间。打补丁建议先在测试环境中安装补丁，确认安装的补丁不会对运行环境带来负面影响，再将补丁安装到生产环境中。经过了适当的测试后，主动地安装预防补丁，将避免一些可能导致系统出故障的问题。WAS补丁的命名规范为：版本名-产品名-产品组件名-平台名-补丁编号名.pak。对于同样补丁编号的补丁，建议先装WASSDK补丁，再装WAS补丁。打补丁的具体步骤如下：把补丁文件拷贝到补丁工厂安装目录的maintenance目录下。在补丁工厂的安装目录下，执行./update.sh命令启动补丁工厂。在“安装目录”中选择将要打补丁的组件的安装目录。通常，对WAS组件，补丁会自动识别出安装位置；对于IBMHttpServer（简称IHS）或者Plug-in这样的组件，需要选择正确的安装位置。在maintenancepackageselection页面中选择想要打的补丁。创建概要文件概要文件是一组用于定义运行时环境的文件，每个概要文件都是一组完全隔离的运行时环境。创建概要文件应该注意如下事项：概要文件创建有两种方式，图形化创建向导和命令行方式。如果用命令行方式，必须注意命令和参数是大小写敏感的。建议在一个cell(Cell指WAS多个实例组成的一个受管域)中使用同一种类型的主机名(全限定名称、短名称、数字IP地址)，不要混用多种名称方式。应该根据需要选择创建适用于开发环境或生产环境使用的应用服务器实例。在开发环境，应该选择“使用开发模板”来创建服务器；在生产环境中，不要选择“使用开发模板”。概要文件创建过程应该选择“启用管理安全性”，让用户在进行登陆管理控制台、停止WAS实例等管理任务时需要输入用户名、密码。应该根据需要修改概要文件所占的port，避免端口冲突。其他注意事项JDK的版本：在WAS中所带的JDK是IBM的,不要用SUN或者其它公司的JDK去替换它。虽然它们的接口相同,但是底层实现并不同，效率也不同。所以安装后在检测某些java应用程序时候，要注意使用的JDK。安装后要及时\o"备份"备份配置信息。WAS提供的backupConfig命令可以将配置信息方便地进行\o"备份"备份。升级时要注意UpdateInstaller工具的版本升级WAS需要使用UpdateInstaller这个工具，对于不同版本的WAS需要注意的是要用不同版本的UpdateInstaller，不同版本的UpdateInstaller互相之间不兼容。升级产品WAS的升级过程包含多个方面的升级，应该根据实际需要来进行的。特别是升级ApplicationServer本身并不包括相应的JDK的升级，而是分为两个不同的升级包。应用服务器中间件卸载WebSphere禁止通过直接删除WebSphere安装目录的方式卸载，否则将不能再次成功安装WebSphere。在卸载WAS之前，必须先停止机器上的WAS进程。做好应用系统的程序备份。卸载WAS的主要步骤如下：用ps–ef|grepjava确保没有was进程在运行。执行WAS_HOME/uninstall/uninstall.sh命令卸载WAS。应用系统部署在WebSphere上部署应用系统的主要任务是配置应用所需要的环境和资源。环境配置的内容包括系统变量、虚拟主机、类路径、安全性等，资源配置的内容包括JMS资源、数据源等。在应用系统部署过程中应该注意如下事项：应用打包部署在WebSphere应用服务器上的应用可以是打包的*.ear、*.war文件，也可以是未打包但符合J2EE规范要求的组件。在生产环境中，建议使用打包的*.ear、*.war文件，便于版本控制和管理。合理放置公用的UtilityJar包，避免Jar包冲突禁止在同一个类载入路径下存在同一个类的多个版本，否则会在实际运行中带来很多莫名其妙且难以诊断的问题。对于JDBC驱动这类通用等级较高的UtilityJar包，建议放置在<WAS_HOME>/lib/ext目录下。对于多个应用共享的UtilityJar，建议放在sharedlibrary（共享库）中。共享库的使用能够避免UtilityJar包多个版本的混乱，以及UtilityJar包的冲突。对于单个应用使用的UtilityJar，可与应用打包在一起，或放入sharedlibrary中。合理设置会话超时时间和会话级别应该针对不同的应用场景，为会话设置合理的超时时间和会话级别。WebSphere应用服务器的会话管理分为Applicationserver、Application、WebModule三个级别。部署在WebSphere应用服务器上的应用，默认的会话超时时间为30分钟，默认的会话管理级别是ApplicationServer。通过应用编程接口实现J2EE应用的部署和管理当应用程序要运行在同一个WebSphere应用服务器上，而且其中涉及到的EJB组件、JNDI名修改和资源（引用）修改较多时，建议通过应用编程接口实现J2EE应用的部署和管理，避免通过手工完成部署。性能调优部署在WAS上的J2EE应用程序，其性能是由多个因素决定的。例如网络、数据库、\o"内存"内存分配、WAS服务器的配置以及应用程序的设计。对于一个标准的J2EE应用，一个请求的完成需要经过多次转发：网络>Web服务器>Web容器>EJB容器>数据库。而每一次转发，都可能造成请求处理的瓶颈，使得应用程序整体性能下降。在生产环境中安装完毕WebSphere，必须根据实际情况进行必要参数的调整，以便提高WAS性能、方便错误诊断。参数的调整需要综合考虑运行环境的实际情况、实际的并发量和服务器的资源利用情况等因素，调优的内容涉及操作系统、应用、应用服务器和数据库等的综合调整。对于WAS调优的一个基本原则是：使得在队列中等待的请求数量最小化。所以建议的配置方式是使得队列成为一个“漏斗”，即越靠近客户端的队列，其容量越大，而后面的队列，其容量要略小于或等于前面的队列。按照这个原则，调优的基本步骤如下：启用servlet高速缓存建议在Web容器配置选项中启用servlet高速缓存。设置WebServer的最大并发用户数在文件conf/httpd.conf中配置WebServer的最大并发用户数。在Unix系统中，对应的属性是MaxClient；在Windows系统中，对应的属性是ThreadsPerChild。配置线程池线程池使服务器的组件能重用线程以消除在运行时创建新线程的需要。应该根据观察的性能情况和应用情况设置合适的最小进程数、最大进程数、线程不活动超时等选项。最小线程数指定池中允许的最小线程数（缺省值10）。最大线程数指定池中允许的最大线程数。该值一般设置为等于峰值压力下应用在线用户数大小。缺省值50，如果硬件资源允许，建议把线程池的最大值调到100。线程不活动超时指定在收回空闲线程之前应该等待毫秒数。为“0”的值表明不等待，而负值（小于0）意味着永远等待。单位是毫秒，缺省值为3500。可增长的线程池指定线程数是否能增加至超过为线程池配置的最大线程数。有效值是允许线程分配超过最大线程大小或“未启用”。缺省值是未启用。设置对象请求代理（ORB）的线程池大小：在管理控制台中点击应用程序\o"服务器"服务器>server1>ORB服务>线程池，根据观察的性能情况和应用情况输入合适的最小、最大进程数。设置数据库的连接池属性连接池的大小影响着服务器资源的占用情况。若连接池过大，则会长期占用服务器可利用资源，JVM有限的资源都耗费在维护连接池、处理与数据库连接上，造成WAS性能的下降。若连接池过小，则无法满足现场环境应用高负载使用的压力。默认大小为1到10。根据资源设置的队列(Queue)原则，从Web容器线程池，到数据源连接池的参数设置，应该是从大到小的管道。假如Web容器线程池的最大值设置100，对于数据源连接池，设置的最大值建议不超过50，多数情况下调整为30。实际运行中可以修改此参数值，评估调整对性能造成的影响。Java虚拟机设置设置JVM堆参数控制JVM代码可使用的堆大小。JVM堆的最大值默认是256M，在生产环境中通常要根据机器物理内存情况、应用运行特性来设置，且多数情况下都要把此参数调大。内存充足时，建议调整在500M到1024M之间。如果JVMHeapSize过大，可能会引起内存分页，或者造成JVM垃圾回收时间过长，影响应用服务器性能。对于32位系统，建议JVMHeap的最大值不要超过1024M，对于64位系统，根据应用情况具体设置（可以通过使用verbose:gc参数，设置监控垃圾收集分析GC性能调整）。启用JIT编译器指定是否禁用JVM代码的JustinTime（JIT）编译器选项。如果禁用JIT编译器，吞吐量明显减少。因此，出于性能原因，建议保持JIT启用。ORB参数调用方式的性能调优应用程序\o"服务器"服务器>server1>ORB服务>选中按引用传递。关闭动态加载开关企业应用程序>应用名称>关闭启动类重新装入开关。关闭会话序列化应用程序\o"服务器"服务器>server1>会话管理>分布式环境设置>分布式会话选择无即可。WAS进程日志参数WAS进程日志常用的有SystemOut.log和SystemErr.log。这两份日志默认大小为1M，历史日志文件数为1份。在生产环境中，这样的设置通常不足以充分保存发生问题时的错误信息。我们可以通过修改日志默认大小、历史日志文件数来保存更多的信息。不要把单份日志文件大小设置过大（例如，超过10M以上），否则可能影响WAS性能。建议把应用日志与WAS日志分离开。如果应用中大量以System.out.print或者System.err.print来保存应用状态日志，也可能会影响服务器性能。Heapdump文件Heapdump文件对磁盘空间占用很快，建议设置IBM_HEAPDUMP参数把Heapdump文件存放到指定目录下。Web服务器的访问日志access.logIBMHttpServer的访问日志access.log默认是打开的，其中记录了经过Http服务器的请求信息。在高并发的系统中，这一日志增长非常快，当日志过大时，可能占用过多磁盘空间或引起性能下降，如果不需要该日志，或者有其他技术手段保存用户访问信息，建议关闭该日志。性能监控服务在不需要进行性能检测或者有其他工具监控应用服务器性能的情况下，建议停止WAS\o"服务器"服务器的性能监控服务。优化应用程序的设计除利用WAS\o"服务器"服务器参数的调整来优化应用程序的性能外，应用程序的性能好坏很大部分是取决于应用的设计。一般说来，性能调优大概可以提高10％－40％效率，而不合理的代码设计却会使得性能几倍的下降。备份与恢复WebSphere应用服务器需要备份的内容主要包括服务器概要文件配置的备份和业务系统的备份。生产环境、概要文件配置过于复杂或经常更改时，建议定期备份概要文件。业务系统的备份需要注意版本问题。可以通过集群实现备份，也可以由管理员人工备份。Jboss应用服务器中间件技术规范应用服务器中间件安装与卸载安装准备在生产环境建议安装二进制发布版，在开发环境建议安装源代码发布版。必须根据实际的操作系统平台选择适合相应平台的安装程序。需要在机器上使用合适版本的JDK。建议至少使用JDK1.4以上的版本。正确设置环境变量JAVA_HOME。应用服务器中间件安装与配置在Jboss的安装过程中需要注意以下事项：安装目录的完整路径（比如，Windows操作系统中的ProgramFiles目录）上不能够含有空格。规划JBoss各项服务的端口，避免端口冲突。建议将JBoss安装成系统服务。当目标机器启动时，JBoss将作为服务或者后台应用运行。建议删除不需要使用的组件，减少服务器的启动时间。根据需要选择合适的服务器实例配置(all、default以及minimal)或定制服务器实例配置。建议按照如下方式定制服务器实例配置：拷贝最接近用户需求的现有配置，然后修改其具体内容。比如，如果不需要使用消息服务，则只需要拷贝default目录，并重新命名为myconfig，然后删除jms子目录。最后，启动myconfig配置。建议将安全性域添加给JMX控制台应用。通过JMX控制台基本上能够控制JBoss服务器的各个方面，因此应该将安全性域添加给该控制台。建议在perties文件中删除admin用户或修改该用户的密码。为提高Jboss的安全性，建议关闭jmx-console、web-console以及status统计信息，删除jboss主页相关的目录和文件。应用服务器中间件卸载在卸载Jboss之前，必须先停止机器上的相关进程。做好应用系统的程序备份。删除安装目录下的相关文件。删除相关的环境变量.应用系统部署Jboss支持热部署，只需要将EAR文件拷贝到deploy目录即可。如果应用已经部署，则可以通过覆盖相关的包来再次部署它。如果需要卸载应用，只需要将相应的存档从deploy目录删除即可，JBoss服务器始终不需要重启。部署过程需要妥善解决包冲突和应用程序的版本问题。性能调优通过适当的参数调整、关闭不必要的服务，可以提高JBoss服务器的服务性能。参数调整调整JVM的参数修改JVM配置参数可以在启动脚本run.sh/run.cmd下实现。建议如下：建议JDK使用JDK1.5以上版本。JDK5在垃圾收集方面比1.4有显著的改善。在x86硬件建议使用BeaJRockit虚拟机。建议使用64位的机器和支持64位的虚拟机来提供比通常2-4GB更大的堆。如果应用不需要32位地址（2-4GB）以上的堆空间，建议不要使用-d64（64位支持的选项）。使用64位地址，在完成相同任务的情况下需要更多的内存，而且不能够为应用带来任何好处。合理设置堆空间的大小。堆空间的大小影响代式垃圾的收集和扫描堆的时间。在堆空间较小的情况下，很难有效地进行性能调优；但是过大的堆空间将会在垃圾收集时需要更长的时间来扫描堆空间。在-server选项中建议将TheadStackSize设置为-Xss128k或以上，可以使线程使用更少的内存作为栈，从而能够创建更多的线程。但是在运行复杂的递归代码时栈空间的减少将可能导致栈溢出。通过负载测试（OpenSTA、JMeter等）来选择合适的垃圾收集器。建议使用多余2个处理器的多处理器计算机，并采用并行和并发的垃圾收集选项来获得最佳性能和更高的垃圾收集吞吐量。

如果使用JDK1.4，建议调整JDK的NewSize的缺省值为小于20%，设置为大于20%将非常危险，可能引起虚拟机错乱地进行完整的垃圾收集（fullgarbagecollection）,并且不会休眠或释放足够的空闲内存。JDK5已经修正了这个Bug，而且在缺省值的设置上更加合理。数据库连接池的配置建议将访问数据库的方式设置为使用数据库“连接池”，避免使用“单连接”方式访问数据库。应该根据系统的并发数、数据库的处理能力及数据库并发连接数等确定合适的最大连接数。建议在数据源中指定最小连接数等于最大连接数。调整Tomcat的参数修改server.xml、web.xml文件中的相关参数。建议如下：设置maxThreads为一次性并发访问最大预期值的25％以上。如预期的最大并发数为200，则maxThreads至少应该设置为50。监控应用的正常负载，设置minSpareThreads的值恰好比正常负载多一点。监控应用的峰值负载，设置maxSpareThreads的值恰好比峰值负载多一点。移除任何不需要的值和日志。生产环境中，建议在web.xml文件中里关闭development（开发）模式。调整RMI远程调用的参数默认情况下,JBoss为每个RMI请求创建一个新线程。建议将RMI转向被集中的池.调整日志的参数建议将日志跟踪级别改变为ERROR(或者WARN)。建议关闭将日志打印到控制台选项。调整部署扫描器的参数如果将部署扫描的扫描间隔时间设置为5秒，将给服务器带来一定负担。在应用服务器上不需要频繁部署新应用的情况下，建议将扫描间隔时间设置为较大值。关闭不必要的服务应该根据需要关闭不必要的服务，可以关闭的服务主要包括：mail-service服务(J2EE标准的JavaMail客户端)缓存失效服务J2EE客户端部署服务。集成HAR部署和Hibernate会话管理服务HypersonicJBossMQ(JMS服务器)HTTPInvokerXA数据源(分布式and/or可恢复的事务)

JMX-Consoleweb-console控制台/email监控警报如果不需要部署EAR文件，从server/slim/conf/jboss-service.xml文件删除或注释相关XML片段。

如果不需要JMS对列，从server/slim/conf/jboss-service.xml文件删除或注释相关XML片段。

如果不需要CORBA/IIOP，从server/slim/conf/jboss-service.xml文件删除或注释相关XML片段。

如果不需要client-side事务管理，从server/slim/conf/jboss-service.xml文件删除或注释相关XML片段。如果不使用RMI类装载器（在服务器上利用classes从客户端装载代码），从server/slim/conf/jboss-service.xml文件删除或注释相关XML片段。如果不使用JBossSX（为EJBs或者Web层组件继承的基于JAAS的安全），从server/slim/conf/jboss-service.xml文件删除或注释相关XML片段。如果不使用BeanShelldeployer，从server/slim/conf/jboss-service.xml文件删除或注释相关XML片段。如果不使用热部署文件到server/slim/deploy文件夹，而从外部重启JBoss,则从server/slim/conf/jboss-service.xml文件删除或注释相关XML片段。如果不使用集群，建议从"default"配置启动，而不是使用"all"配置启动。备份与恢复Jboss应用服务器需要备份的内容主要包括：配置文件server.xml、web.xml的备份。业务系统的备份。集群与负载均衡规范集群(Cluster)由一组应用服务器组成，它们作为一个整体向用户提供一组网络资源，每个服务器上部署同样的应用程序。集群对用户是透明的，用户由单一入口访问集群的资源，而不会意识到集群中的节点。从用户应用的角度，集群是一个系统，而非多个计算机系统。通过集群可以实现可扩展性（服务更多客户，提高吞吐量）、负载均衡（平衡负载资源，使资源得以有效利用）、高可用性（提供故障恢复和补偿机制，在关键性业务中提供容错功能）。配置规划基本规范在规划集群配置时，应该注意以下关于网络环境与集群配置的限制。集群中服务器必须保证主机名正确。如果主机名采用数字IP地址，则主机必须使用静态IP地址。动态IP地址分配不能用于集群环境。如果服务器位于防火墙后面，而客户机位于防火墙前面，那么服务器必须有公共的静态IP地址，只有这样，客户端才能访问服务器。集群中的所有服务器必须位于同一个局域网，并且必须是IP广播可到达的。集群中的所有服务器必须使用同类应用服务器中间件的相同版本。对于使用了JDBC连接的EJB，所有分发了某EJB的服务器必须具有相同的分发与持久化配置。也就是说所有服务器都应该有相同的JDBC配置。所有分发了servlet的主机必须维护一组具有相同ACL的servlets。如果客户端应用直接使用JDBC连接池，则必须为每个应用服务器创建相同的连接池（并具有相同的ACL）。即集群所使用的连接池应该在所有的机器上创建。例如，一台运行应用服务器中间件的NT服务器配置了连接MicrosoftSQLServer数据库的连接池，那么一个包含非Windows机器（即不支持MicrosoftSQLServer连接的机器）的集群不能使用这个连接池。集群中的每个应用服务器在所有与服务、类文件以及外部资源（例如数据库）相关的方面应该具有相同的配置。为保持同步，确保集群中的每个应用服务器的时区、时间一致，建议误差控制在秒级。集群配置内容在完成集群配置后，应用服务器管理员需要根据应用的实际情况，完成主服务器、成员服务器的相关配置。应用服务器管理员根据各类应用服务器中间件软件的特点，集群配置的主要任务包括：集群配置配置集群服务器。可以配置的属性包括ClusterName,ClusterListenPort以及集群中的服务器名。克隆一个集群。克隆的服务器与原服务器具有相同的属性设置，包含同样的服务器。需要对新集群的名字进行重新设置。监控集群中的服务器。为集群分配服务器。删除集群。服务器配置：配置单独的服务器。需要配置的属性包括名字，监听端口与IP地址。克隆一个成员服务器。克隆的服务器保存了原来服务器的属性值，需要配置新服务器的名字。删除成员服务器。查看服务器的日志、JNDI树、执行队列、serversockets、服务器连接。使用管理控制台的Server节点进行强制垃圾收集。监控服务器的安全。安全信息包括无效登录的统计信息，被锁用户的统计信息与开启用户的统计信息等。查看服务器的版本。分发EJB。监控分发在某一服务器上的所有EJB。将web应用组件分发在某一服务器上。监控某一服务器上的所有web应用组件。在服务器上分发启动与终止类。分配web服务器。为服务器分配JDBC连接池。监控某一服务器的JDBC连接池。为服务器分配JMS服务器、连接工厂以及消息收信方。分配邮件会话。WebSphere应用服务器集群配置规范应该从需求、成本、管理复杂性、故障恢复时间等因素综合考虑集群配置方案。搭建集群的Websphere应用服务器必须选择WebsphereApplicationServerNetworkDeployment版本,简称WASND版。建议避免在异构平台上创建WAS集群，避免使用绝对路径异构操作系统的目录格式不同，产品的缺省安装目录也不同，建议避免在异构平台上创建WAS集群。如果在异构平台上创建WAS集群，在资源配置和应用部署中，应当避免使用绝对路径，而采用通用的节点作用域WebSphere变量来替代，然后根据每个节点的实际情况来对该变量赋值。配置集群前应先对管理节点和被联合节点的各类概要文件作备份。在备份概要时，进程会停止，在成功备份完成后，需要手工重启进程。根据WAS组件种类的不同，FixPack的种类也有所不同，各组件FixPack的版本应该保持一致。FixPack和FeaturePack的安装应该严格按照其发布的时间顺序依次叠加安装。集群中的机器应该能互相解析机器名。需要分别在Windows和Linux机器上修改hosts文件。建议更新集群中各台主机的hosts文件（默认目录为/etc/hosts），确保每台机器均包含对方的hostname和对应的IP地址，以便主机间的相互访问。如果系统在Linux或Unix上，请编辑/etc/hosts文件以将localhost注释掉，并添加带主机名称的实际IP地址。如果在windows平台配置集群，在配置过程中建议选中“将应用服务器进程作为windows服务运行”选项。在设计和开发运行于WAS集群环境的应用程序时需要从文件同步，会话管理和动态缓存等方面考虑集群对应用程序的影响。在集群中部署应用系统应该注意以下内容：建立数据源时要选择作用域范围为集群范围；集群控制台中，做了配置修改后要同步各个节点，建议在系统管理->控制台首选项中勾选上选择同步节点项，以保证每次更改会自动同步各个节点；Jboss应用服务器集群配置规范Jboss负载均衡架构由负载均衡器和N个集群节点组成。每个节点是一个JBoss服务器实例。负载均衡器是全局唯一的前置机，全部用户请求都发到负载均衡器，由其转发到各节点。当负载均衡器发现一个节点失效后，会将请求转发到另一个节点上，从而保证服务得以延续。负载均衡方案Jboss的负载均衡目前有两种方案，一是使用apache的mod_jk，二是使用Jboss自带的负载均衡模块。Jboss自带的负载均衡器的缺点是负载能力相对不高，配置参数少。建议采用apache+mod_jk作为负载均衡器。负载均衡的粒度可以选择针对每个request的均衡，或者是针对每个用户的均衡。应该根据不同的应用需要选择不同的负载均衡粒度。在无特殊要求的情况下，建议采用基于用户的负载均衡。基于request的负载均衡该种方式下，负载均衡器根据各个集群节点的状况，把每个httprequest进行分发。使用这样的均衡策略，就必须在多个节点之间复制用户的session，实时保持整个集群的用户状态同步，这种操作被称为session复制(sessionreplication)。该方式的优点是客户不会被绑定都具体的集群节点，只要还有一个服务器节点存活，用户状态都不会丢失，集群都能够继续工作。缺点是集群节点之间通信频繁，对响应速度有影响，多并发、高频操作的情况下性能下降比较厉害。基于request的负载均衡有两种session复制模式，同步与异步。使用同步的方式，jboss会把session复制的操作和对request的响应放到一个应用事务，session复制完成后才处理request。异步复制则发送session复制的消息后马上处理request，session复制则会稍有延迟。但是在多框架的web页面中，这样的集群方式会有问题。由于frame在同一时间发出多个request，会造成一些混乱。基于用户的负载均衡该种方式下，当用户发出第一个request后，负载均衡器动态的把该用户分配到某个节点，并记录该节点的jvm路由，以后该用户的所有request都会被绑定这个jvm路由，用户只会与该server发生交互，这种策略被称为粘性session(sessionsticky)。该方法的优点是响应速度快，多个节点之间无须通信。缺点是某个集群节点死掉以后，它负责的所有用户都会丢失session。合理设置负载加权集群节点的负载加权值越大，获得负载的机会就越大，应该根据集群节点的硬件性能合理分配各节点的负载加权值。日常管理应用服务器性能数据监控应用服务器管理员需要运用相关监控工具对应用服务器性能及运行状况等参数进行监控，并记录、分析相关数据，根据应用服务器特点进行相应的调整。为各类监控参数设置合理的预警值，提高系统的可用性。主要监控的数据有：服务器信息，如CPU使用状态、内存使用状态、启动时间、无效登录、堆的状态、套接字的数量、服务器重启次数等。性能数据，包括JVM内存堆使用状况、请求对象与等待请求的实时数据等。集群的信息（例如集群中有多少服务器处于活动状态）。服务器安全信息，如无效登录的统计信息，被锁用户的统计信息与开启用户的统计信息。JMS对象的统计信息：JMS服务器、连接、会话、收信方、消息生产者、消息使用者以及服务器会话池。JTA的统计信息，如有关事务与所有回滚的统计信息。JDBC连接池信息，对Java数据库连接（JDBC）子系统实行监控，如JDBC连接池的初始容量、容量增量、JDBC多池的负载平衡等相关数据。连接服务器的相关数据，如连接时间、远程地址、所发送的字节数与接收到的字节数。有关Web应用的统计数据，如最大池容量以及最长的执行时间。服务器的各类日志文件。应用服务器升级和移植规范在应用服务器版本的升级过程中，系统管理员在保证应用稳定运行的情况下通过合理的升级和移植策略降低系统宕机时间。WebSphere提供本地升级（In-placeupgrade）和版本移植(Version-to-Versionmigration)两种形式的运行时升级支持，Jboss尚未提供完整的升级和移植策略。本规范主要对WebSphere的升级和移植进行规范。本地升级本地升级是通过更新已有的WAS安装目录下的文件来实现的，以单个的WAS安装目录为单位，每次本地升级操作会将某一个安装目录下所有的概要文件（Profile）、节点（Node）和服务器（Server）进行更新。已部署的应用程序可以在更新后的系统上继续运行，无需进行任何更改或重新配置操作。版本移植版本移植以单个概要文件为操作单位，依次进行。移植工具将低版本WAS概要文件上的应用程序及配置信息备份到本机的一个临时目录，将其中的应用程序自动安装到新版本的WAS概要文件上，并根据临时目录中已保存的配置信息对新版本概要（Profile）进行相应配置。移植完成后，原有的WAS系统可以被完全卸载也可以原封不动，但