IBM WAS ND 分布式网络环境的理解与集群的实现（转载自乔自忠）
IBM WAS ND 分布式网络环境的理解与集群的实现(一)
2009-04-13 22:23
| 基于 IBM WAS ND v6.1 搭建稳定高效的集群环境 中间件厂商对分布式网络环境的定义和理解并非完全相同，因此不同的中间件产品实现集群时所使用的概念和方式也有所不同。本文基于较为普遍应用的中间件产品 IBM WAS ND v6.1 讲述集群及分布式网络环境的相关概念，并且使用一个实例来演示集群环境的完整实现过程。 如今的电子商务及电子政务应用系统的发展已经到了一个新的阶段，应用系统的成熟度和可用性都达到了更高的水准。因此庞大的部署规模和海量的用户访问成为目前大型电子商务及电子政务应用系统的显著特征。在这样的情况下，企业对系统关键业务：如金融信息，通信，交通等要求确保系统24*7*365不停歇运行业务的分布式部署结构和负载抗压能力，以及高可用性都提出了更高的要求。IBM WAS ND产品可以帮助我们在多应用服务器分布式部署环境下实现集群，确保系统的负载能力和高可用性。 下面按照逻辑概念的层次关系，由大到小依次了解IBM WAS ND产品定义的分布式网络环境中的相关概念。 单元（Cell） 单元是整个分布式网络中一个或多个节点的逻辑分组。单元是一个配置概念，是管理员将节点间逻辑关联起来的实现方法。管理员根据具体的业务环境，制定对其整体系统集成环境有意义的条件来定义和组织构成单元的节点。如图1所示，就一般情况来说，可以将单元看作是最大的作用域。 在IBM WAS ND产品中，管理配置数据都存储在 XML 文件中。单元保留了它每个节点中每台服务器的主配置文件。同时每个节点和服务器也有其自己的本地配置文件。如果服务器已经属于单元，则对于本地节点或服务器配置文件的更改都是临时的，通过在本地提交更改生效时，本地更改覆盖单元配置，但是当执行单元配置文档同步到节点的操作时，在单元级别上对主控服务器和主节点配置文件所作的更改将会替换对该节点所作的任何临时更改。 同步操作在指定的事件发生时进行，例如服务器启动时等很多操作。也就是说，通过对本地节点或服务器配置文件进行修改而达到调整节点或服务器配置的做法不是安全的，临时修改很容易被同步操作所覆盖。
图 1. 单元的作用域 Deployment Manager Deployment Manager 是管理代理程序，它提供集中式管理单元中所有节点的可视化人机交互管理视图。之前提到单元是一个逻辑上的配置概念，那么Deployment Manager 就为单元中所有元素提供了单一的管理控制中心点。每个单元都会包含一个 Deployment Manager，由Deployment Manager提供管理功能来修改单元的主配置文件。在最新的v6.x版本中还提供集群管理以及在一个或多个节点作用域内进行应用程序服务器工作负载平衡。
节点（Node） 节点是受管服务器（Server）的逻辑分组。节点通常与具有唯一 IP主机地址的逻辑或物理计算机系统对应，节点不能跨多台计算机。节点分为受管节点与非受管节点。 IBM WAS ND 拓扑中的节点可能是受管的，也可能是非受管的。受管节点有相应的 Node Agent 进程来管理它的配置和服务器。非受管节点没有 Node Agent。Node Agent 表示管理单元中的节点并负责保持配置始终处于最新状态。非受管节点对于单元来说是未知的，所以 Deployment Manager 无法对其进行管理。 分布式网络环境中的非受管节点可以有服务器定义（例如 Web 服务器），但不能有应用程序服务器定义，并且非受管节点无法添加 Node Agent，因此它不能成为受管节点。另外一种情况在独立应用程序服务器环境中，节点尚且没有 Node Agent，它们也可以暂时被视为非受管节点，但是这类节点可以通过联合独立应用程序服务器而变为单元中的受管节点。通过调整独立应用程序服务器概要文件，将单独的Server节点添加到单元，这个过程称为联合。在联合独立应用程序服务器时，节点将自动创建 Node Agent，该节点就可以被Deployment Manager 管理。
Node Agent Node Agent 是将管理请求路由至服务器的管理代理程序。Node Agent 是服务器，是一个管理代理程序，并不涉及应用程序服务功能。Node Agent 进程在每个受管节点上运行，并专门执行特定于节点的管理功能，如服务器进程监视、配置同步、文件传输和请求路由。Deployment Manager通过与Node Agent的交互完成对单元内节点的控制。
WAS Plug-in 在前面的章节我们讨论过受管节点是通过Node Agent进程与Deployment Manager交互。而非受管节点，最常见的是web服务器节点（如IBM HTTP Server），则是通过Web 服务器插件方式来接受Deployment Manager管理，加入到单元当中来的。IBM WAS ND产品支持所有符合规范的Web 服务器的基本管理功能，可以为所有支持的 Web 服务器生成插件配置。插件生成之后，对于非受管节点，可以通过“传播给远程 Web 服务器”完成插件配置；如果定义在受管节点上，则直接通过节点间同步即可完成插件配置的传播。 Web 服务器插件允许 Web 服务器将动态内容的请求发送到应用程序服务器。Web 服务器插件与每个 Web 服务器定义关联。为每个插件生成的配置文件（plugin-cfg.xml）基于通过关联的 Web 服务器路由的应用程序。Web 服务器插件帮助面向的网络中的应用程序服务器之间的工作负载平衡，改进请求响应时间。
|
概要文件（Profile）
概要文件定义一个独立应用程序服务器（Server）的运行时环境，包括服务器在运行时环境中处理的所有文件。创建独立应用程序服务器时应该使用概要文件而不是多个产品安装，这样只需要保留一组产品核心文件即可，管理能力将得到极大的增强。不仅节省了磁盘空间，而且简化了产品的更新，只需要保留一组产品核心文件即可。而且与完整产品安装相比，创建新概要文件更快速，而且减少了出错的可能性，这允许开发者创建单独的产品概要文件以进行开发和测试。核心产品文件是由所有概要文件共享的产品二进制文件,如果希望二进制文件位于不同服务级别，在应用安装时设置。概要文件管理工具未提供删除功能，所以必须使用 manageprofiles 命令来删除概要文件。
使用概要文件创建独立应用程序服务器，则每个定义的应用程序服务器进程都在 profiles 目录内，除非在创建概要文件时指定新目录。如果将概要文件放在安装根目录中，则存在概要文件可能被例行系统维护破坏的风险。这些文件在随创建新的概要文件、重新配置现有的概要文件或删除概要文件等操作而更改。
IBM WAS ND提供了多种类型的概要文件，以下是最常用的三种：
单元概要文件
基本功能是在 Deployment Manager的管理下将应用程序提供给因特网或内部网。创建单元概要文件其实就是同时创建Deployment Manager 概要文件和已联合到单元的节点概要文件，构建一个最简单的单元环境。在创建初始单元概要文件后，可单独创建定制概要文件或独立概要文件，再通过联合操作将他们添加到 Deployment Manager管理的单元环境中。
Deployment Manager 概要文件
基本功能是将应用程序部署到WAS的管理单元。每个属于该单元的Server都作为受管节点引用。
Application Server 概要文件
基本功能是将应用程序提供给因特网或内部网。IBM WAS ND 产品的重要功能就是通过将 Server 节点添加到单元，调整独立应用程序服务器概要文件。单元中的多个应用程序服务器进程可以部署它需要的应用程序。也可以从单元除去 Server 节点以将节点返回到独立应用程序服务器的状态。每个独立应用程序服务器都具有其自己的管理控制台应用程序，可以使用它来管理Server。
图 6. 一个节点对应一个概要文件，一个节点内可以有多个Server
集群（Cluster）
集群是一起进行管理并参与工作负载管理的多个服务器集合。作为集群成员的服务器可以位于不同的主机上，与此相对的是作为同一节点下的服务器必须位于同一台主机上。单元可以没有集群，也可以有一个或多个集群。集群负责平衡服务器之间的工作负载。作为集群一部分的服务器称为集群成员。当在集群上安装应用程序时，会在每个集群成员上自动安装此应用程序。当删除集群时，也就同时删除了该集群的成员的任何应用程序服务器。没有办法保存任何集群的成员。除去集群成员的仅有方法就是删除应用程序服务器。如果希望保留要删除的集群中的应用程序或模块，则应该先将这些模块重新映射至另一集群。
图 7. 由两个节点内的三个Server组成的集群
关于Node、Profile与Server
这三个概念比较容易混淆，我们拿出来对比说明：Node=Profile。Node是管理上使用的概念，Profile是实际的概要文件，它们代表同一事物。Server 就是所谓的 Application Server Instance , 这是我们实际要布署 Application 的地方。在IBM WAS ND 产品中受管节点的Node Agent 目的就是让 Deployment Manager Server 可以透过 Node Agent 来管 Node (Profile) 中的 Application Server Instance，一个 Node (Profile) 中可以有多个 Application Server Instance。
如果是非ND版本 , 则属于 Single Server 版本，那么一个 Node (Profile) 中只能有一个 Application Server Instance，如果你希望在一台机器上有多个 Application Server Instance，那就只能透过创建多个 Profile (Node) 来达成，但这些 Node (Porfile) 彼此独立没有管理上的关系 (RelationShip)，只要使用的 TCP/IP Port 不要冲突即可。
2009-04-13 22:24
| 一个较为复杂的实例 在完成了对IBM WAS ND 产品中相关概念的理解之后，我们通过一个较为复杂的实例来了解一个集群的构建过程。此次搭建的集群环境使用了三台测试服务器：
客户端直接访问192.9.100.14上的IBM HttpServer，由IBM HttpServer根据节点本身设置的负载权重，分发访问请求。
以下是该集群拓扑结构的安装步骤，只描述需要提示的关键步骤。 首先创建运行时环境。打开Profile Management Tool概要文件管理工具创建概要文件。选择创建单元概要文件，即同时创建一个Deployment Manager 概要文件和一个已经被联合的应用服务器节点概要文件，也可以创建DM概要文件再联合已存在节点。
创建成功后在Deployment Manager 概要文件环境中登录到管理控制台，可以在“系统管理”中看见DM相关资源。
节点列表。可以看见各种类型的节点：应用服务器节点、单元节点、HttpServer非受管节点。可以在此添加新的节点或联合已有非受管节点。各节点与单元主配置文件的同步操作也可以在这里完成。
Node Agent列表。可以看见3个应用服务器节点被联合到单元之后，成为受管节点，开启了Node Agent进程。Node Agent在这里只能停止和重新启动。停止了之后就不能在此启动，需要回到Node下的概要文件中使用命令行去启动Node Agent。
在“服务器”中选择“集群”，新建。一般来说，如果创建了集群，那么对各个单独节点的操作都应该在集群或DM中操作，而不应该去“服务器”中的“应用程序服务器”中单独操作。
为集群添加成员（节点），并且在添加成员的同时重命名一个短名称。分配负载权重。指定分配给应用程序服务器的工作量。值的范围是 0 到 20。权重值越大表明将分得越多的工作量。
可以对集群进行启动和停止操作。对集群进行启动停止，就是对集群内的成员节点进行启动停止。
|