本文详细介绍了IBM WebSphere Application Server Network Deployment (WAS ND) 的架构组成，包括单元(Cell)、节点(Node)、概要文件(Profile)、DeploymentManager、NodeAgent、WAS Plug-in及集群(Cluster)的概念与作用。解释了各组件之间的关系及其在分布式环境中的管理方式。
转自https://www.ibm.com/developerworks/cn/websphere/library/techarticles/0705_qihong/
单元（Cell）
单元是整个分布式网络中一个或多个节点的逻辑分组。单元是一个配置概念，是管理员将节点间逻辑关联起来的实现方法。管理员根据具体的业务环境，制定对其整体系统集成环境有意义的条件来定义和组织构成单元的节点。如图1所示，就一般情况来说，可以将单元看作是最大的作用域。
在IBM WAS ND产品中，管理配置数据都存储在 XML 文件中。单元保留了它每个节点中每台服务器的主配置文件。同时每个节点和服务器也有其自己的本地配置文件。如果服务器已经属于单元，则对于本地节点或服务器配置文件的更改都是临时的，通过在本地提交更改生效时，本地更改覆盖单元配置，但是当执行单元配置文档同步到节点的操作时，在单元级别上对主控服务器和主节点配置文件所作的更改将会替换对该节点所作的任何临时更改。
同步操作在指定的事件发生时进行，例如服务器启动时等很多操作。也就是说，通过对本地节点或服务器配置文件进行修改而达到调整节点或服务器配置的做法不是安全的，临时修改很容易被同步操作所覆盖。
图 1. 单元的作用域
Deployment Manager
Deployment Manager 是管理代理程序，它提供集中式管理单元中所有节点的可视化人机交互管理视图。之前提到单元是一个逻辑上的配置概念，那么Deployment Manager 就为单元中所有元素提供了单一的管理控制中心点。每个单元都会包含一个 Deployment Manager，由Deployment Manager提供管理功能来修改单元的主配置文件。在最新的v6.x版本中还提供集群管理以及在一个或多个节点作用域内进行应用程序服务器工作负载平衡。
图 2. 由Deployment Manager提供管理功能来修改单元的主配置文件
节点（Node）
节点是受管服务器（Server）的逻辑分组。节点通常与具有唯一 IP主机地址的逻辑或物理计算机系统对应，节点不能跨多台计算机。节点分为受管节点与非受管节点。
IBM WAS ND 拓扑中的节点可能是受管的，也可能是非受管的。受管节点有相应的 Node Agent 进程来管理它的配置和服务器。非受管节点没有 Node Agent。Node Agent 表示管理单元中的节点并负责保持配置始终处于最新状态。非受管节点对于单元来说是未知的，所以 Deployment Manager 无法对其进行管理。
分布式网络环境中的非受管节点可以有服务器定义（例如 Web 服务器），但不能有应用程序服务器定义，并且非受管节点无法添加 Node Agent，因此它不能成为受管节点。另外一种情况在独立应用程序服务器环境中，节点尚且没有 Node Agent，它们也可以暂时被视为非受管节点，但是这类节点可以通过联合独立应用程序服务器而变为单元中的受管节点。通过调整独立应用程序服务器概要文件，将单独的Server节点添加到单元，这个过程称为联合。在联合独立应用程序服务器时，节点将自动创建 Node Agent，该节点就可以被Deployment Manager 管理。
图 3. IBM WAS ND 拓扑中的受管节点与非受管节点
Node Agent
Node Agent 是将管理请求路由至服务器的管理代理程序。Node Agent 是服务器，是一个管理代理程序，并不涉及应用程序服务功能。Node Agent 进程在每个受管节点上运行，并专门执行特定于节点的管理功能，如服务器进程监视、配置同步、文件传输和请求路由。Deployment Manager通过与Node Agent的交互完成对单元内节点的控制。
图 4. 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 服务器插件帮助面向的网络中的应用程序服务器之间的工作负载平衡，改进请求响应时间。
图 5. 非受管节点通过插件接受管理
概要文件（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 不要冲突即可。
扫一扫
2857
到【灌水乐园】发言
