NIM(Network Installation Management) 是 AIX 自带的用于对大量机器进行集中安装、升级和维护的工具。
本文从介绍 NIM 的原理出发，给出几种导致 NIM 服务器崩溃的常见因素，并在此基础上介绍如何对崩溃的 NIM 服务器进行迁移，以便快速恢复 NIM 服务，从而为大规模集群系统提供更可靠的系统安装和维护服务。
引言
由于 NIM 是 AIX 自身携带，并且能够对大量系统进行方便的安装、升级、维护和恢复等操作，因此，在客户环境中被广泛使用。虚拟化、云计算等新技术的广泛使用，在系统安装和维护等方面具备众多优势的 NIM 必将被越来越多的客户使用。当前，绝大部分资料都是介绍关于 NIM 如何使用方面的知识，关于如何迁移 NIM 服务器本身却鲜有文章提及。
基于上述背景，本文将从介绍 NIM 的工作原理入手，并深入分析可能导致 NIM 服务器崩溃的原因。在此基础上，介绍如何迁移 NIM 服务以便为大规模集群系统提供不间断的系统安装和维护服务。
NIM 服务器
NIM(Network Installation Manager) 即网络安装管理器，常被称为网络安装管理服务器 ( 简称 NIM 服务器 )。NIM 是 AIX 自带的服务，用户无需为此支付任何额外的费用。借助 NIM 服务，用户可以高效地对大量机器进行安装、系统升级及系统恢复等维护任务。
理解 NIM 服务中的资源管理及各种资源直接的相互关系是进行 NIM 服务迁移的前提。本节将简要描述 NIM 服务器的各种资源，有关相关资源的详细信息可以查阅 developerworks 其它文章。
NIM 服务器将其管理的信息划分为 4 大类：机器信息、网络信息、资源信息和群组信息。其中，常用的机器信息主要包括 master 机器信息、standalone 类型机器信息等；而网络信息包括众多网络的定义；资源信息包括在使用 NIM 服务进行系统安装、维护过程中用到的各种资源。
在使用 NIM 的环境中，机器 ( 独立的物理机器或是 LPAR) 被划分为三类：NIM master, NIM client 和资源服务器 (Resource Server)。其中，NIM master 即 NIM 服务器，管理 NIM 数据库并为其它系统提供安装服务的机器，NIM client 所有使用 NIM 服务进行系统安装、升级、备份及恢复的机器；而资源服务器即存放 4 大类 NIM 服务信息中的资源类信息的机器，此类机器即为资源服务器 (Resource Server)。资源服务器可以是 NIM master，也可以是任何一台 NIM client。
在 NIM master 中，所有的信息均以对象的形式出现，如图 1 所示：
图 1. NIM master 中的信息
NIM 服务的工作原理
理解 NIM 的工作原理对于成功的 NIM 服务迁移至关重要。NIM 服务基于 bootp 服务和 tftp 服务为 NIM 客户机提供网络引导内核的传递，之后，基于 NFS 服务为 NIM 客户机提供根文件系统和安装包资源，其工作原理如图 2 所示 :
步骤 1：NIM client 在系统启动时，将向指定的 NIM 服务器 IP 地址发出 bootp 系统引导请求，以获取本机 IP 地址及相应的系统引导内核等信息。
步骤 2：NIM master 响应来自 NIM client 的 bootp 请求，并返回相应的网络引导内核的目录地址 ( 例如 /tftpboot/sysperf32.cn.ibm.com) 等信息
步骤 3：NIM client 依据获取的网络引导内核的目录地址，发出 tftp 请求下载该网络引导内核
步骤 4：NIM master 通过 tftp 服务响应来自 NIM client 的 tftp 请求
步骤 5：NIM client 在获取相应的网络引导内核之后，加载该内核，并通过 NFS 服务挂载安装、升级或是维护过程中所需要的各种 NIM 资源。
完成上述步骤之后，NIM client 将开始正式的安装、升级或维护的过程，并将相应的进度信息不断更新给 NIM master。
图 2. NIM 服务的工作原理
NIM 服务器的搭建
developerworks 上已经有大量文章介绍 NIM 服务器的搭建，本文不再详细描述，请参考相关文章。
NIM 服务器的崩溃
通常而言，NIM 服务器的崩溃有三大因素：
大部分用户都会采用偏旧的机器作为 NIM master 服务器，物理机器的不稳定 ( 例如电源异常 ) 是导致 NIM 服务器崩溃的第一个潜在因素；bootp、tftp、NFS 服务及 nimesis 服务的崩溃，也是导致 NIM 服务器失效的第二个潜在因素；多用户操作下的 NIM 数据库，某个用户的异常操作（例如分配资源时的异常终止）是导致 NIM 服务器失效的第三个潜在因素。
如果在 NIM 安装、升级或是维护的过程中出现异常（例如不能正确安装等），那么，判断 NIM 服务器是否已经崩溃的过程就是检查系统是否出现上述三大因素的逐个排除过程：
步骤 1：检查是否能够 telnet 到 NIM master。如果可以，排除第一个因素；如果不行，需要检查 HMC 或是 console 或是机器面板，尝试重启机器并查阅相应的 System Reference Code 以便排除硬件故障。
步骤 2：检查 bootp/tftp/NFS 服务是否正常
清单 1 检查 NIM Master 上的三大服务是否正常
1 2 3 4 5 6 7 8 9 10 | > netstat -na | grep -e 67 | grep udp udp 0 0 *.67 *.* > netstat -na | grep -e 69 | grep udp udp 0 0 *.69 *.* > rpcinfo | grep -v program |grep -v "-" | sort -d +4 -u 100003 2 tcp 0.0.0.0.8.1 nfs unknown 100005 1 tcp 0.0.0.0.128.0 mountd unknown 100021 1 tcp 0.0.0.0.128.1 nlockmgr unknown 100000 2 tcp 0.0.0.0.0.111 portmapper superuser 100024 1 tcp 0.0.0.0.128.2 status unknown |
如果看到上面第一个关于 67 端口的输出，则表明 bootp 服务正常；如果看到第二个关于端口 69 的输出，则表明 tftp 服务正常；如果看到第三个关于 NFS 服务进程的输出，表明 NFS 服务正常（nfs、mountd、nlockmgr、portmapper、status 及 nlockmgr 服务进程缺一不可）。
如果某个服务不正常，那么可以尝试重启该服务或是重启 NIM master。
步骤 3：检查 nimesis 服务和 NIM 数据库是否正常
通过 ps – elf | grep nimesis 检查服务进程 nimesis 是否存在，如果存在则正常；如果不存在，可以通过 startsrc – g nim 重启该服务。
检查 NIM 数据库是否正常可以通过"lsnim – l"命令进行简单的查阅即可。如果 lsnim 命令报错，那么重启 NIM master。
上述步骤中，如果重启不能解决问题，那么就需要考虑对 NIM 服务器进行迁移，以减少 NIM 服务中断的时间。
NIM 服务器的迁移
一般而言，一旦上述异常通过重启服务或是重启系统仍无法解决，那么就需要考虑对 NIM 服务器进行迁移 , 以减少 NIM 服务中断的时间。
在另一方面，由于客户应用需求的增长，使得原有 NIM master 不能满足日渐增加的 NIM client 机器进行系统安装、维护及升级等方面的需求（例如过多的请求使得 NIM master 在 I/O 及网络方面不能满足要求），这也是我们需要对 NIM 服务器进行迁移的主要因素之一。
不管是因为 NIM 服务崩溃或是因为新的业务需求而导致的 NIM 服务器迁移，整个迁移过程都是相同的：需要在新的机器上重现原有的 NIM 数据和服务。
其中，需要在新的机器上重现的 NIM 数据如图 3 所示：
图 3.迁移过程中需重现的 NIM master 数据
如图 3 所示，迁移过程中需要在新的 NIM master 上重现的数据主要包括两个部分：NIM 数据库和 NIM 资源，二者缺一不可。如果我们仅仅迁移了 NIM 数据库或是 NIM 资源，那么在新的 NIM master 上仍然无法正常使用。
搭建易于迁移的 NIM 服务器
迁移过程中，NIM 数据库和 NIM 资源均需要进行迁移，二者缺一不可。既然如此，那么在搭建一个 NIM 服务器时，需要考虑未来对其进行迁移的容易性。
通常而言，管理员应该定期对其数据库进行备份（备份过程如图 4），或是在 NIM 数据发生更改之后对其进行及时备份。如果没有备份 NIM 数据库，一旦 NIM master 崩溃，唯一的途径就是在新的 NIM 服务器上重新创建所有资源，不仅耗时而且效率低下。
图 4. 备份 NIM 服务器
在图 4 中，输入的文件路径 /Builds/backup/plinuxt20_nim.back 是备份文件存放的路径，可以依据实际情况进行修改，之后回车即可。
易于迁移的 NIM 资源都应该存放在非 rootvg 中，包括 SPOT 资源、lpp_source 资源以及 script 等资源。此外，提供 tftp 服务的根目录（默认时 /tftpboot）应该创建在单独的文件系统上，并且同样存放在非 rootvg 上。
基于上述建议搭建的 NIM 服务器就具备良好的可迁移性。
迁移前的准备工作
迁移前的准备工作主要包括两个部分：旧的 NIM Master 资源的整理和准备合适的新 NIM master 机器。
旧的 NIM master 资源的整理主要包括确定最新的 NIM 数据库的备份，确定存放 NIM 资源的所有物理盘。
准备合适的新 NIM Master 机器则需要考虑：空闲的 SCSI 插口是否足够（至少需要等于或大于原来存放 NIM 资源的物理盘数，插口是否能够满足未来的容量扩展需求），确定并安装相应版本的 AIX 系统。在确定新机器上 AIX 版本的时候需要注意的是，由于 NIM master 的软件包是系统自带的，所以新机器的 AIX 版本必须等于或高于原 NIM master 机器的 AIX 版本。
一旦完成上述准备工作，将原 NIM 资源的所有物理盘插入新 NIM master 的 SCSI 接口，至此，我们就可以开始正式的迁移过程。
迁移过程
NIM 服务器的迁移过程主要包括下述几个步骤：
步骤 1：检查 NIM 所需软件包是否已经安装
清单 2 NIM 服务器所需软件包
1 2 3 4 5 | (root@sysperf32) / > lslpp -l | grep nim bos.sysmgt.nim.client 6.1.6.0 COMMITTED Network Install Manager - bos.sysmgt.nim.master 6.1.6.0 COMMITTED Network Install Manager - bos.sysmgt.nim.spot 6.1.6.0 COMMITTED Network Install Manager - |
上述三个软件包是 NIM master 必需的 ;tftp/bootp/NFS 网络服务是系统默认安装的。
步骤 2：对新 NIM master 进行 unconfigure
如果新的 NIM 服务器是全新安装的 AIX，那么直接跳转到第二步；否则，先对新 NIM 服务器进行 unconfigure 操作：smit nimàPerform NIM Administration TasksàUnconfigure NIM，之后回车，过程如图 5 所示：
图5.unconfigure 新的 NIM 服务器
在图 5 所示的过程中，最后一步可以依据实际情况来确定在 unconfigure 之前是否需要备份原来配置的 NIM 数据库信息。
步骤 3：在新的 NIM master 上导入原 NIM 数据库备份
运行 smit nimàPerform NIM Administration Tasksà Backup/Restore the NIM Databaseà Restore the NIM Database from a Backup，之后输入 NIM 数据库的备份文件路径并回车，如图 6 所示：
图 6. 导入原 NIM 数据库备份文件
步骤 4：修改新的 NIM master 的主机名和网络接口信息
如果新 NIM 服务器的 IP 和原来 NIM 服务器的 IP 同属于一个网段，那么无需修改 network 信息。如果不是同一个网段，则先通过 smit nimàPerform NIM Administration Tasksà Manage Networksà Define a Network 定义新的网络名对象。
运行 smit nimà Perform NIM Administration Tasks àChange the master's Primary Interface, 输入新 NIM 服务器的主机名。如果新的 NIM 服务器需要采用新创建的网络名，那么在 Existing NIM Network Name 中选择，之后回车。
至此，NIM 数据库信息恢复完毕。
步骤 5：迁移 /tftpboot 文件系统
导入 /tftp 所在的卷组：通过 importvg – y <VG_NAME> <PV_NAME> 导入原 NIM 服务器上 /tftp 文件系统所在物理卷的卷组。其中，<VG_NAME> 为导入的卷组名，请指定原 NIM 服务器上的相应卷组名，例如 nimvg； <PV_NAME> 即为物理卷的名字，例如 importvg – v tftp_vg hdisk3。
系统在导入上述卷组的同时，会自动更新 /etc/filesystems 文件并在根目录下创建 /tftpboot 目录。完成上述导入之后，直接挂载 /tftpboot 即可。
步骤 6：迁移 SPOT 资源、lpp_resource 资源和其余 NIM 资源所在的物理卷组
迁移其它 NIM 资源（例如 SPOT 资源、lpp_resource 资源）的操作过程与步骤 5 类似 : 即导入相应的卷组，并挂载相应的文件系统即可。
迁移之后的服务验证及常见问题
完成上述迁移之后，需要检查系统上所有服务是否已经正常启动，之后通过实际安装一台机器来验证迁移是否已经成功。
如果一切顺利，迁移过程就此结束。如果迁移过程中出现异常，可以借鉴下述常见问题的处理方法。
问题 1：在恢复备份的 NIM 数据库时出现下述异常：
1 2 3 4 5 6 | The level of the NIM master fileset on this machine is: 5.3.4.0 The level of the NIM database backup is: 6.1.0.0
0042-234 m_restore_db: You can not restore a NIM database backup onto a machine that has an earlier level of the NIM master fileset installed. 正如异常说描述的，新的 NIM 服务器的 AIX 版本低于原 NIM 服务器，需要重新安装高版本的 AIX 系统。 |
问题 2：NIM Master 发起的 push 方式下出现类似下述的异常：
1 2 3 | warning: 0042-140 m_rmmac: unable to remove the /etc/niminfo file on "sysperf32" Permission denied. |
其中"sysperf32"为实际的 NIM client 机器。该异常是由于在 NIM client 机器上没有授权 NIM 服务器进行 rsh 访问，可以通过在 NIM client 机器上 /.rhosts 文件中添加下述类似条目来解决：
1 | Plinuxt16.cn.ibm.com root |
其中 plinuxt16.cn.ibm.com 应该替换为 NIM 服务器的主机名。
问题 3：NIM Master 为 NIM client 分配资源时出现类似下述的异常：
1 2 3 | 0042-001 nim: processing error encountered on "master": 0042-001 m_alloc_boot: processing error encountered on "master": 0042-157 c_alloc_boot: unable to access the "/tftpboot/61J_1003A_spot.chrp.64.ent" file |
其中，61J_1003A_spot.chrp.64.ent 为实际操作中相应的资源名。
出现上述异常是因为 /tftpboot 目录下不存在该资源。对于 NIM Master 而言，/tftpboot 目录下资源都是在创建 SPOT 资源时创建的，如果此类资源丢失，可以通过 nim – F – o check <spot-name> 来重建上述资源
问题 4：NIM client 在引导过程中无法 ping 通 NIM 服务器
该异常需要先确认 NIM client 选用了正确的网卡，其次确认 NIM 服务器已经正确分配了资源。
问题 5：NIM client 能够 ping 通 NIM 服务器，但是在引导过程中报 BOOTP:BOOTP request fail 的异常
对于该异常，需要先检查 NIM 服务器是否已经正确分配了资源。如果已经分配了资源但仍然出现该问题，可以从两个方面来查看问题：
A) 屏蔽 bootp 在 inetd.conf 中的行，执行 refresh – s inetd，再执行 kill – KILL <bootpd_PID>。此后，执行 /usr/sbin/bootpd – s – d – d – d 开启 bootpd 服务进程的详细的错误信息
B) 手动执行 tftp <NIM 服务器的 IP>，之后执行 get < 目标文件 >。如果能够正常下载，说明 tftp 服务没有问题，否则依据提示信息进行问题修正。
总结
本文从介绍 NIM 的原理出发，结合导致 NIM 服务器崩溃的常见因素，介绍了如果搭建易于迁移的 NIM 服务器。在此基础上，针对已经崩溃的 NIM 服务器给出了完整的迁移过程。与此同时，给出了迁移过程中常见问题的解决方法。
声明
本文中包含的迁移方案是在特定的操作条件和环境条件中得出的。 虽然在给定的条件下复查了信息的准确性及相关的问题，但您在生产环境中获得的结果可能会有不同。 因此，本文仅仅代表作者自己的观点，不提供任何有关结果的陈述、承诺、保证或担保。