熟悉WebLogic的人都知道有一个叫做NodeManager的东西存在，它能够帮助Admin Server远程的管理Managed Server，在Windows下只能做为一个基于Java的进程存在或者直接配成一个Window的服务，而在Linux/Unix下可以做为一个基于脚本的进程或者配置成一个daemon process。

下面是Node Manager的体系结构：

从图中可以看出，NodeManager是跟Machine所绑定的，一般来说一台物理机器上会跑一个NodeManager，帮助起停这台机器上所承载的Servers并收集它们自身健康报告和与Admin Server之间通信的Log。同时NodeManager也甚至可以控制Admin Server的起停(本质上来说Admin Server也是一个Server Instance)。

当我们想启动一个Managed Server的时候，一般的步骤是进入该Domain的目录下的bin目录里有startManagedWebLogic命令，该命令接受两个参数分别是[Server Name]和[Admin Server URL]。不过在真实的生产环境中，各个Managed Server做为集群的节点都布署在不同的物理主机上，所以这时startManagedWebLogic命令就只对拥有该Server的机器上才有效。于是我们可以通过NodeManager来帮助我们达到远程控制Server的目的。

NodeManager的工作原理是Admin Console发出一个启动请求到远程机器的NodeManager服务，NodeManager服务会在本地create一个Managed Server的启动进程，然后即时的反馈Managed Server的启动状态给Admin Server，这样就能在Console控制界面上看到详细反馈信息和Log了。

这里举个例子说明一下大概步骤：

比如Admin Server配置在192.168.0.100上端口为默认的7001，那么对于同样在这台机器上的Managed Server，例如叫Server-1，就可以通过 startManagedWebLogic Server-1 http://192.168.0.100:7001来启动，然后另外一个Server-2配置在192.168.0.101上，那么想远程控制就无法使用这个命令。

我们需要做的就是在192.168.0.101上配置一个NodeManager，并且把它启动起来。方便的是这个流程不限制在101这台机器上完成，任何机器通过登录192.168.0.100:7001/console都可以来做这件事。在Console里配置101的这台Machine，并且添加Server-2进去，接着会在Machine里检查NodeManager的状态。非常关键的一点是在试图监视该Machine的NodeManager状态时，经常会碰到一个Cann’t Connect的错误信息，原因就是NodeManager的远程管理只认机器名(Host Name)不认IP Address，我个人目前觉得可能IP Address很容易伪造但机器名做为标识唯一性和安全性可能更好一些，具体的思想有待进一步验证。由于这一层关系我们给Machine设置NodeManager的Address和Port的时候，必须以Host Name来做为Address而不能填入IP。这样Admin Server就会给远程机器发送一个验证请求，而远程机器会回一个它自己的Host Name，拿到这个回复的Host Name就会与你填入的值进行比对验证，通过之后就说明这个NodeManager是reachable的，可以使用了。

那么做为远程机器这端需要做什么呢？毕竟它这边可能只是刚装了WebLogic，什么配置都没有。在成功扮演一个Managed Server为集群服务之前，它至少得拿到一份Domain的总体配置才行。这个时候也总不至于说跑到Admin Server的100机器那边拿U盘去拷一份回来(虽然这样做理论上是行得通的)。正确的做法应该是利用WLST里的远程导入命令nmEnroll，接受两参数，[Domain Dir]和[NodeManager Home]，可以把Domain的基本信息下载到本地一份。不过如果通过NodeManager服务，由Admin Server发请求到本地启动Server之时，即使本地没有enRoll过Domian的配置，它也会自动再去下载一份的。所以你自己做不做enRoll都问题不大，但原理得清楚。