聚沙成塔-小哈的记事薄

本文根据微软的MSDN上教材进行整理

一、 准备阶段

此阶段是为了以最小的特权运行SQL Server2005的复制工作

A. 在发布服务器上为复制代理创建本地 Windows 帐户

1. 在发布服务器上，从“控制面板”的“管理工具”中打开“计算机管理”。

2. 在“系统工具”中，展开“本地用户和组”。

3. 右键单击“用户”，再单击“新建用户”。

4. 在“用户名”框中，输入 username，提供密码和其他相关信息，然后单击“创建”来创建 “username” 帐户。

5. 单击“关闭”。

B. 在订阅服务器上为复制代理创建本地 Windows 帐户

1. 在订阅服务器上，从“控制面板”的“管理工具”中打开“计算机管理”。

2. 在“系统工具”中，展开“本地用户和组”。

3. 右键单击“用户”，再单击“新建用户”。

4. 在“用户名”框中，输入 username，提供密码和其他相关信息，然后单击“创建”来创建”username” 帐户。

5. 单击“关闭”。

C. 为快照文件夹创建共享并分配权限

1. 在 Windows 资源管理器中，导航到 SQL Server 2005 数据文件夹。默认位置为 C:\Program Files\Microsoft SQL Server\MSSQL\MSSQL.X\Data，可以根据自己需要创建目录所在地。

2. 创建名为 sqlshare的新文件夹。

3. 右键单击该文件夹，然后单击“共享和安全”。

4. 在“sqlshare 属性”对话框的“共享”选项卡上，单击“共享此文件夹”。确保“共享名”的值为 sqlshare。

5. 单击“权限”。

6. 单击“添加”。在“输入要选择的对象名称”文本框中，键入第 1 课中创建的快照代理帐户的名称，格式为 <Machine_Name>\username，其中 <Machine_Name> 是发布服务器的名称。单击“检查名称”，然后单击“确定”。

7. 验证是否允许以下权限：

· username – 完全控制

8. 单击“确定”关闭“username 的权限”对话框。

D. 在发布服务器中设置数据库权限

1. 在 SQL Server Management Studio 中，展开“安全性”，右键单击“登录名”，然后选择“新建登录名”。

2. 在“常规”页中单击“搜索”，在“输入要选择的对象名称”框中输入 <Machine_Name>\username （其中，<Machine_Name> 是本地发布服务器的名称），再单击“检查名称”，然后单击“确定”。

3. 在“用户映射”页中，启用到 所要分发 数据库的用户映射，确保有数据库的db_owner 数据库角色和public角色

单击“确定”创建登录名。

二、 配置分发订阅

A. 在发布服务器中配置分发

1. 在 SQL Server Management Studio 中连接到发布服务器，然后展开服务器节点。

2. 右键单击“复制”文件夹，然后单击“配置分发”。此时分发配置向导启动。

3. 在“分发服务器”页中，选择“‘<服务器名称>’将充当自己的分发服务器；SQL Server 将创建分发数据库和日志”，然后单击“下一步”。

4. 在“快照文件夹”文本框中，输入 之前建立的共享目录，然后单击“下一步”。

5. 根据情况决定执行发布的间隔时间，时时执行还是确定某一时间运行。一般“事务性发布”选择“立即创建快照并保持可用状态”，而“快照发布”选择间隔某一段时间创建快照，比如4个小时

6. 快照代理安全性，在以下Windows账户下运行中输入运行的进程账户名<Machine_Name>\username （其中，<Machine_Name> 是本地发布服务器的名称）和密码，

7. 接受向导剩余页上的默认值。

8. 单击“完成”启用分发。

在发布服务器上配置订阅

1. 选择复制节点

2. 右键本地订阅

3. 选择发布服务器

4. 选择订阅方式（选择推送订阅））填加订阅服务器

5. 安全性——运行的进程选择<Machine_Name>\username，连接的订阅服务器选择数据库上的新建的username

6. 选择代理计划（一般选择连续运行）

7. 其余选择默认项。

注：http://msdn.microsoft.com/zh-cn/library/ms152531.aspx 上有关于使用复制分发后的备份建议。

WebSphere优化中不得不提的是对JVM的优化，OutOfMemory、GC时间太长太频繁、内存碎片、大对象问题……虽说JVM运行效率如何很大程度是和代码有关，但是恰当的参数设置还是可以避免很多问题。因为在JAVA程序中，垃圾回收（Garbage Collection——GC）是内存发生瓶颈的主要因素（在程序没有问题的情况下）。

但是JVM的优化（也就是优化GC）是一个很令人头疼的活。调整JVM需要根据不同的平台分别对待，如果不了解直接Google一个参数加上无法生效事小，适得其反就不好了。在 Sun ™Solaris™ 和 HP-UX 平台上，WebSphere使用的是Sun和HP提供的JDK，而所有其他平台，WebSphere提供的是IBM JDK。所以优化参数主要区别在IBM JDK和非IBM JDK上，Sun和Hp环境下的优化方案基本能共享。

通用配置

          GC优化的关键是降低频率（frequency）和减少持续时间（duration）。但是两者此消彼长，所以平衡一个恰当的值十分关键。频率和堆的大小和分配增长速度有关，而持续时间则和堆大小和堆中对象的多少有关。由此可以看出最先要考虑的就是堆的大小。

          最大堆、最小堆设置：现在32位的堆，一般设置为256～512M或者512～1024M，但是

       对于不同的应用程序，最优化堆大小的设置都有可能不同。如果堆设置较大，可能导致 GC 的次数变少，但每次 GC 所花的时间很长，从而导致系统的处理能力抖动很大。此外如果堆设置过大，会占用过多的内存，使内存资源耗尽，从而会频繁的进行 IO 操作来使用虚拟内存。 如果堆设置较小，可能导致 GC 变的频繁，但每次 GC 所花的时间不会太长，每次 GC 对系统的性能影响相对也会小些。但是如果堆设置过小， 会使得对象可分配空间变小，从而会频繁的 GC 来释放内存空间，而每次 GC，都会耗用一定的系统资源。因此，要通过试验和监控数据，设法使的我们所设置的堆大小能够使得系统运行最优化。

          具体合适的值，可以启用-verbose:gc来观察。一般良好的堆大小，要让回收频率保持在10秒左右，而一次的full gc回收时间在1到2秒之内（一般的回收时间更短才好）。要注意的是，对于32位的JDK，在Windows环境下单个堆不要超过1.7G，AIX平台不要超过3.2G。下面摘自 出色的“清洁工具” ― 理解 IBM Java 垃圾收集器，第一部分：: 对象分配

 

问题	建议措施
在堆达到稳定状态以前，GC 的频率太高。	使用 verbosegc 确定处于稳定状态的堆大小并将 -Xms 设置成这个值。
堆被完全扩展并且占用率大于 70%。	增加 -Xmx 值使堆占用率不超过 70%。为了获取最佳性能，尝试确保堆从不换页。物理内存应该能容纳最大的堆大小（如果可能）。
占用率为 70% 时，GC 的频率过大。	更改 -Xminf 的设置。缺省值是 0.3，它将通过扩充堆来尝试维持 30% 可用空间。设置为 0.4 将可用空间目标增加到 40%，从而降低 GC 的频率。
暂停时间过长。	尝试使用 -Xgcpolicy:optavgpause （在 1.3.1 中引入），它在堆占用增加时减少暂停时间并且使它们更一致。在吞吐量方面要付出代价。代价是变化的，大约在 5% 左右。

确定了堆大小，接下来要考虑的是

GC的策略

IBM JDK（1.5）下WebSphere首先要了解的是4个Policy：

IBM SDK 5.0 中的 GC 策略

针对吞吐量进行优化
-Xgcpolicy:optthruput（可选）
默认策略。对于吞吐量比短暂的 GC 停顿更重要的应用程序，通常使用这种策略。每当进行垃圾收集时，应用程序都会停顿。

针对停顿时间进行优化
-Xgcpolicy:optavgpause
通过并发地执行一部分垃圾收集，在高吞吐量和短 GC 停顿之间进行折中。应用程序停顿的时间更短。

分代并发
-Xgcpolicy:gencon
以不同方式处理短期存活的对象和长期存活的对象。采用这种策略时，具有许多短期存活对象的应用程序会表现出更短的停顿时间，同时仍然产生很好的吞吐量。

子池 （一般平台用不到）
-Xgcpolicy:subpool
采用与默认策略相似的算法，但是采用一种比较适合多处理器计算机的分配策略。建议对于有 16 个或更多处理器的 SMP 计算机使用这种策略。这种策略只能在 IBM pSeries® 和 zSeries® 平台上使用。需要扩展到大型计算机上的应用程序可以从这种策略中受益。

其中optthruput是默认的IBM JDK GC策略，我觉得不是很适合一般电子商务的情况。因为它的GC停顿时间是三种策略里最长的，而且对于频繁分配短生命周期、小对象的应用来说，很容易就产生了内存碎片，虽然标志-扫描-紧凑排列（mark-sweep-compact）的第三个阶段“紧凑排列”可以消除碎片，但是这种动作开销很大。一般需要设置P cluster、K cluster参数来减少碎片Avoiding Java heap fragmentation with Java SDK V1.4.2. （这个参数在1.5中也适用）

optavgpause是以一点吞吐量的牺牲（官方说是5%）换来响应时间的提高，用并发标记（JDK1.4）外加并发扫描（JDK1.5引入）的方式来减少GC “Stop the world”的时间。

但一般而言，我都是设置成-Xgcpolicy:gencon ，gencon就是我们常说的“分代回收”策略，在HP和SUN的JDK实现中是默认的回收策略。这篇文章Java 理论与实践: JVM 1.4.1 中的垃圾收集，介绍的就是分代回收策略，而且肯定是针对SUN的JDK，当然HP的也适用。可以关注下面这张图：

形象直观，文章里的文字总忘掉七零八落，但那些原理可以日后巩固，这幅图保存好了设置参数就没啥大问题。

注意下图显示的IBM JDK的分代回收参数设置和SUN/HP的不同

IBM没有设置MaxPermSize的地方，这点要注意了。

HP和SUN的JDK也有两种主要的回收策略，分别是对应高吞吐率的-XX:+UseParallelGC和快速响应时间的-XX:+UseConcMarkSweepGC。

本文主要是描述GC优化的纲领，指出不同的JDK优化对策的不同。详细的参数测试有待以后慢慢写。

相关阅读：

Java 技术，IBM 风格: IBM Developer Kit 简介

Java 理论与实践: 垃圾收集简史  可以了解为什么不同的回收策略，表现出的gc时间会如此迥异。虽然Java 技术，IBM 风格: 垃圾收集策略，第 1 部分一文也叙述的很详细，但是个人觉得《垃圾回收简史》一文写的更明了，毕竟这是最原始的设计，省略了实现过程中添加的许多特性。

为什么要介绍WAS CE

公司开发的产品几乎都是三层B/A/S结构，生产环境中使用WebSphere Application Server作为中间件的不少。但是限于个人开发机器的性能限制，开发过程中开发人员大部分是基于Tomcat环境实施项目开发，之后将应用程序发布到正式环境——WebSphere Application Server上，而Tomcat与WAS在规范细节上的标准差异，以及对第三方组件支持的区别，导致很多应用迁移到正式生产环境上遇到各种各样的问题。所以本文介绍IBM WebSphere Application Server家族的一款免费的轻量级中间件产品——WebSphere Application Server Community Edition，建议今后有新项目，且明确最终环境是WAS中间件时可以在开发时使用。

WAS CE简介

IBM WebSphere Application Server Community Edition 是在 Apache Geronimo（Apache Software Foundation 的开放源代码应用程序服务器）的基础上构建的 J2EE 应用服务器。

WAS的优点

支持全面

WAS CE21完整支持Java EE5.0，并向下支持j2ee1.4；支持各种数据库；Web2.0的各种特性

J2EE Version 5 编程模型采用 Apache Geronimo（Apache Software Foundation 的开放源代码应用程序服务器项目）技术。Apache Geronimo 将各个主要开放源代码社区的最佳技术组合起来，以支持 J2EE 规范，这些技术包括：

• 用于支持 Servlet 和 JavaServer Pages (JSP) 的 Apache Tomcat
• 用于支持 Enterprise JavaBeans (EJB) 的 OpenEJB
• 用于支持 Java Message Service (JMS) 的 ActiveMQ
• 用于支持 Java Management Extensions (JMX) 的 MX4J
• 用于支持 Java Database Connectivity (JDBC) 的 TranQL
• 用于 Web 服务的 Apache Axis
• 用于 Java Transaction API (JTA) 的 HOWL (ObjectWeb)

WebSphere Application Server Community Edition 支持 IBM 和 Sun 的 Java 开发工具包 (JDK)。

可以看到WAS CE是Tomcat的超集，它使用 Apache Tomcat 作为缺省 Web 容器，还集成了诸多Tomcat所没有的特性。特别是比较常用的Apache Axis，省去了自行调用Axis发生的各种BUG。

安装方便 运行要求低

采用 InstallShield 按需安装，下载包占用空间小。从核心组件到完整下载，大小为85M～191M

下载地址 http://www.ibm.com/developerworks/cn/downloads/ws/wasce/

可以选用不同的JDK，可以根据今后部署的平台来选择。比如今后WebSphere安装在PC Server或者IBM小机上，那么就选用IBM JDK；安装在HP的小机上，那就选用HP JDK

开发工具的支持

Eclipse 插件
该插件使您可以利用基于 Eclipse 技术的 Web 工具平台来提供简单的开发环境，以便创建、部署和调试 WebSphere Application Server Community Edition 应用程序。

http://download.boulder.ibm.com/ibmdl/pub/software/websphere/wasce/updates/

简单而又全面的管理控制台

Tomcat一般不使用管理控制台，而是直接修改配置文件，需要对配置文件了解比较多，而WAS CE则有一个强大的管理和开发控制台，包含诸多工具用来配置和发布应用；配置数据库连接，修改web.xml等等，更重要的是这一切都可以通过向导来完成。

方便迁移

使用 Application Advancement Assistant工具，可以方便的把WAS CE上开发的应用程序迁移到WebSphere Application Server V6.1上去

工具下载地址http://alphaworks.ibm.com/tech/wasma/download

迁移示例

将 WebSphere Application Server Community Edition 应用程序方便地迁移到 WebSphere Application Server

WAS CE和WAS属于同一家族产品，迁移过程中的问题较之使用Tomcat，肯定会大大减少，最重要的是，使用这个工具，就算遇到问题也可以显示出问题出现在哪些地方，方便定位。

简单集群和故障转移的支持

现在很多项目正式运行都是用WAS ND版做了WAS的集群来提高可靠性，但是基本上程序开发时都是考虑单机环境。WAS CE支持web层的负载均衡和故障转移，可以在开发时就考虑到如何更好的利用集群环境。

丰富的文档支持

IBM产品的一大特点就是文档丰富，可以给开发人员极大帮助。

WAS CE的开发社区

http://www.ibm.com/developerworks/spaces/wasce?S_TACT=105AGX01&S_CMP=LP&pageid=710

里面有支持与文档、示例与工具、技术文章、迁移资源等子栏目，可以解决开发过程中遇到的疑难杂症。

WebSphere Application Server Community Edition V2.1 文档，如果纯属使用WASCE的问题，可以先到这里找到快速解决方案

http://publib.boulder.ibm.com/wasce/V2.1.0/zh_CN/index.html

WebSphere Application Server Community Edition 专栏 ，WAS CE在IBM developworks上的专栏，里面有翻译好的专栏文章。

IBM 800 Support

作为免费的Tomcat，缺少技术支持是它不能很好的作为商业运行平台的一个重要因素。JBoss虽然有支持服务，但是它需要每年花费16000美元来购买管理控制台，并且每4个CPU每年另加6750美元（For deployments of under 32 CPUs JBoss requires separate purchase of the admin console support for $16,000 / year in addition to the $6,750 / year for each 4 CPUs ）。相比较而言购买WAS CE的支持则优惠很多。

结束语

上述是我对开发过程中中间件的选用的一个建议，如果今后项目是WAS平台，各位项目经理可以考虑使用WAS CE作为开发平台。至于WAS CE开发的应用程序能否无缝迁移到Weblogic，开未作研究。

WAS CE21的PPT，有兴趣的可以仔细阅读一下。http://docs.google.com/Presentation?docid=dgqfmsbr_1gvbmbjth

前言

What is the Cause of the Performance Problem? 或者是How to Improve the Performance?

这是我们在系统开发、部署过程中都会面对的问题，但是却很难回答。从下面的这幅图就可以看到，一个系统的性能瓶颈（bottleneck)，可能在网络、防火墙，也能在Http Server，Application Server，或者是数据库；系统中一个或者多个“短板”的存在，就能让系统无法达到设计时的目标，无法满足已经签在合同里的SLA……

虽然性能问题牵涉到方方面面，但是本系列关注点在于中间件这一层。希望能用合理的配置避免诸如OutOfMemory（某些情况下）、数据库连接不够的发生，同时能应用一些参数使系统在不优化代码的情况下有5%到100%的提升。

言归正传

池（Pool）是WebSphere中最常涉及的概念之一。从网络、Web 服务器、Web 容器、EJB 容器，一直到数据源，每一个环节都线程池、连接池的影子。要想恰当配置这些池的大小，首先要了解漏斗模型。

通常，WebSphere应用中的一个请求到达服务器，到真正开始处理，要经过一系列的连接池。广域网上可能有大量的并发用户同时访问Web服务器，Web服务器上同时活动（Active）的连接可能高达10000个。但Web服务器到应用服务器（Web容器）的连接池大小可能只有200。Web容器到EJB容器的连接池更小，可能是80。然后，经过数据源（Data source）到数据库的连接最大可能只有25个。从Web服务器的连接池到数据库的连接池尺寸逐渐变小，像一个漏斗（funnel），所以称为漏斗模型。

摘自《构建高性能WebSphere企业级应用》第二章

 

IBM 000-253中有这么一道题：

According to the Upstream Queuing model for performance tuning, what reflets the correct application of recommended settings for maximum concurrent clients?

A Web Server=75, Web container=75, Datasource =25

B Web Server=75, Web container=50, Datasource =25

C Web Server=50, Web container=50, Datasource =50

D Web Server=25, Web container=50, Datasource =75

根据漏斗模型，那么很显然应该选B。

那么实际生产环境中就如此依样画葫芦就可以了么？后面的池一定比前面的小么？如果当前性能不行，增大池的大小就能提高么？

绝没有那么简单。后面的池小于前者，比如数据库连接池小于web线程池，默认的假定是：并非每个JSP和Servlet都需要访问数据库。如果你的应用是数据库密集型的应用，基本上每个JSP和Servlet都需要访问一次或多次数据库，而且系统中还有一些不经过jsp或Servlet的后台进程。那么数据源的连接池就必须大于web容器线程池，否则会报无法得到连接的错。

下面按照我的经验讲述一下每层池大小设置值

对于Web服务器

IBM HTTP Server的优化就是对Apache的优化。一般需要调整httpd.conf中如下参数：

MaxClients：用来定义Web服务器可以同时支持的最大并发连接数或并发用户数，默认值是600。这个值需要根据你所希望的同时支持的并发用户数来设置，一般是峰值的120%。当然这个值不能设的太大，毕竟Apache吃内存也是很厉害。我遇到的项目一般是不用调整的，大家可以根据实际负载动态的调整MaxClients。

将 IBM HTTP Server 配置为显示状态页面：

• 编辑 IBM HTTP Server 的 httpd.conf 文件，从此文件的下列各行中注释注释字符（#）：

  #LoadModule status_module, modules/ApacheModuleStatus.dll,
  #<Location/server-status>
  #SetHandler server-status
  #</Location>

• 保存更改，然后重新启动 IBM HTTP Server。
• 在 Web 浏览器中，转至 http://yourhost/server-status。并且，单击重新装入以更新状态。
• （可选）如果浏览器支持刷新，那么转至 http://your_host/server-status?refresh=5 以便每 5 秒钟刷新一次。

上图给出了一些其它参数的推荐值。注意Windows平台和其它平台的不同（ThreadsPerChild相当于Maxclients）。关于MinSpareServers, MaxSpareServers, 和StartServers 等的设置，以及MPM使用prefork或worker模块时的不同，可以阅读Apache Performance Tuning。

如果你的应用访问量很大，那么也许你需要优化一下操作系统的tcp/ip相关参数。 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tuneopsys.html

并修改“负载均衡”选项和“重试时间间隔”Web 服务器插件属性设置以提高性能http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunewebserv.html

Web容器线程池

要点就是：“通常，对于每个服务器 CPU，5 至 10 个线程将会提供最佳吞吐量”（现在的一个cpu可以用核来代替）。比如你的Pc Server有2块CPU，每块CPU都是4核，那么你一个Application Server可以设置的最小值和最大值可以分别为40、80。但是一般考虑到能充分利用CPU和Memory，或者为不同的应用启用不同的application server，一台Pc Server上并不仅有这么一个appserver，而且还有别的进程在占用着CPU，所以默认的10到50（Linux 系统上 25 个）是一个比较合适的值，当然更准确的值需要通过性能测试来确定。

在进行性能测试的时候，如果吞吐率不是很满意，或者在TPV中看到线程池占用一直是最大值，不要立刻就调大线程池的设置——往往吞吐率会更一步下降。这时候要注意CPU占用率的情况、vmstat的r列值，特别是System状态占用率的情况，如果接近10%，甚至超过10%，那么可以肯定系统在进程切换上面消耗的资源太多了。下调线程池的大小反而会提升吞吐率，而且会由于吞吐率的提升降低页面平均响应时间。

这篇文章也许会使你对线程池大小对性能的影响有个感性的认识。

设置的地方大家应该都晓得，单击服务器 > 应用程序服务器 > server_name > 线程池。

数据库连接池

连接池的最小值，应该和性能测试时TPV观察到的jdbc平均大小一样，最大值根据实际需要设置，每次增长可以设置成大于1，增长一次到位。总之尽量避免连接池频繁的增长和收缩，减少wait的情况发生。

可以使用 Tivoli Performance Viewer 查找池中最优连接数。如果并发等待者的数目大于 0，但是 CPU 负载未接近 100%，那么考虑增加连接池大小。如果使用百分比值一直低于正常工作负载，那么考虑减少池中的连接数。

Application Server 将在使用该数据源的每个应用程序服务器中创建连接池的单独实例。例如：

• 如果运行包含三个服务器的集群，这三个服务器都使用 myDataSource，并且 myDataSource 的“最大连接数”设置为 10，那么可生成多达 30 个连接（3 个服务器乘以 10 个连接）

这是需要考虑的，别数据库端的连接大小不够了。此外，inactive timeout和timeout的时间应该大于收集时间。

总结

这篇文章参考了IBM的inforcenter和developworks，给出了优化WebSphere池大小的一些经验值，但是真正合适的大小还要参考实际的情况，总之调优是个循序渐进的过程。

继续逛逛

调整完了各种池的大小，接下来你需要对内存参数做些优化，这篇是纲领性的。

JVM的恩恩怨怨-WebSphere性能优化（二）

针对不同的JDK，你可以参考：

JAVA性能优化—Sun Hotspot JDK JVM参数设置

JAVA性能优化—IBM JDK JVM参数设置

有了最早的安装WAS6.0和上两篇文章的介绍，接下来安装集群的过程其实很简单。

对于新安装的集群：

1. 安装WAS主程序并升级补丁
2. 建立Deployment Manager profile
3. 新建两个Custom profile，建立过程中就完成联合节点工作
4. 启动两个node中的nodeagent
5. 进入控制台，新建集群，分别在两个节点添加application server

如果新建Custom profile时出现问题，或者更多的情况是想把原来已经建立好的，带有应用的application server profiles联合到DM中来建立集群，那么：

1. 安装WAS主程序并升级补丁
2. 建立Deployment Manager profile
3. 新建两个application server profile（或者原先已经有了）
4. 到profiles/bin目录下执行addnode命令：addnode DM所在IP或主机名 8879（端口）-includeapps（如果有应用的话）-username {用户名} -password {密码}
5. 启动app profiles下的nodeagent
6. 进入控制台，新建集群，用已经存在的application转化为cluster的member

复习一下安装profile的过程

安装DM profile

建立application server profiles

看一下如何新建集群：注意先运行addnode命令，然后启动node agent

看明白了么？没琢磨清的来这里：WebSphere v5 ND在AIX环境中安装和配置

WebSphere V7.0在Windows下的集群配置

还有一份在Unix/Linux下配置V6.1的集群文件比较大，Google Docs无法上传，其实和V7.0没有差别，照着V7做就可以了。传到了纳米盘，《WebSphere v6.1 ND在Unix&Linux环境中安装和配置》，由IBM应用开发合作中心撰写。步骤清晰，图文并茂，最重要是中文。从WebSphere Application Server、IHS、Plugins的安装配置，到WebSphere集群的搭建、节点代理程序（Node agent）的起停方法、如何生存和传播Webserver插件，回话（Session）复制，如何安装补丁。居家旅行必备文档啊

WebSphere v6.1 ND在Unix_Linux环境中安装和配置.pdf

微软的SkyDrive的嵌入方式使用的是iframe，wordpress在2.2之后就不支持iframe语法，所以大家点进去下吧。

紧接上文，我们了解了Application Server，profiles，Managed Node、Umanaged Node等概念，知道了最简单的stand-alone拓扑结构。那为了弥补stand-alone模式的可扩展性（Scalability）可靠性（reliability）要求，有必要提出Cluster的解决方案。

       这副图里我们可以看到分布在两台Machine上的两个Node，每个Node含有三个Application Server，其中两个Server与另一个Node中的两个Server构成了Cluster，这个Cluster通过Node agent被一个Deployment Manager管理。同时我们可以看到每个Node另有一个单独的Application Server，这个Server和之前介绍的Stand-alone application server可以看作是等价的，只是现在被加入到Network Deployment中，接受DM的统一管理。整个的绿色大背景则是一个单元（Cell）。

术语四 Deployment Manager（DMgr）：在分布式拓扑中管理一个或多个节点的特殊profile，通过Node agent把配置和管理动作传达到每个Node中的Server上。可以通过PMT工具建立DM profile，它包含了主配置库，以及各个节点上有的配置文件——启动这个节点所需的XML配置和应用程序文件 。由此可见，各个节点的配置文件是DM上有的子集，所以当我们修改节点上应用里WEB-INF下的诸如web.xml文件，除了在节点上的config目录中要做相应修改，DM节点上config目录里同样要修改，否则重启dm后，一切配置信息将同步到和DM里有的状态。

术语五 单元（Cell）：是一个逻辑上的管理域的称呼，提供了对节点的单独管理入口，这个域由跨多台主机上的Node和一个DM组成，

了解了以上这些术语，那集群的概念就很简单：集群就是一组多个Application Server组成的group，运行着同样的应用程序。一个集群可以运行在一个Node上，或者同一台机器的不同node上（垂直集群），可以运行在不同机器的不同Node上（水平集群）。由此提供故障转移。配合web server，则能做到负载均衡。

有了这些概念，再大的Topology都不怕。

下文将讲述建集群的详细操作步骤。