Clustering the NSM Engine
Layout
The following diagram illustrates the cluster layout discussed in this article.
- Virtual Server: NSM-VS
- Cluster Volume: NSM

1. Setup a dedicated Cluster Volume
The first step in clustering the NSM Engine is dedicating a Cluster Volume which will host its executables and database files. For this example, the NSM volume on the NSM-VS virtual server was selected. When creating this volume, be sure to allow adequate space for collected snapshot report data.
2. Install NSM 2.0
Run the NSM 2.0 installation package for eDirectory. When asked where to install the files, direct the installer to \\<virtual_server>\<volume>\FACTORY as the installation path.

After the initial file copy is complete, the NSM configuration utility will run. The first screen should show the installation path again, with the same \\<virtual_server>\<volume>\FACTORY directory from the initial file copy.
When presented with the option to load the Engine and modify AUTOEXEC.NCF, uncheck both options. The next sections show how to prepare the cluster resources for loading the Engine via the Cluster Resource load / unload scripts, instead.

3. Modify the Cluster Resource scripts
Now that the NSM Engine software has been installed to the Cluster Volume, we need to modify the Cluster Resource load and unload scripts. Two entries in particular are needed:
- HTTPBIND to add the Virtual Server's IP address to the running HTTP stack of the current node
- Load command to start the NSM Engine
A typical Cluster Volume resource load script is shown below, with the last two lines showing how to add the HTTPBIND and NSM Engine load lines:
Load Script for the DATASERV Cluster Volume
nss /poolactivate=DATA
mount DATA VOLID=254
CLUSTER CVSBIND ADD DATAServ 172.17.2.120
NUDP ADD DATAServ 172.17.2.120
add secondary ipaddress 172.17.2.120
HTTPBIND 172.17.2.120:8009 /SSL /KEYFILE:"SSL CertificateIP"
DATA:\factory\fsfengin.nlm
For unloading the Cluster Volume resource, the unload script needs to unload the NSM Engine and unbind the Virtual Server's IP address
from the running HTTP stack. In this case, however, these lines are added to the top of the unload script:
Unload Script for the DATASERV Cluster Volume
unload fsfengin
HTTPUNBIND 172.17.2.120
del secondary ipaddress 172.17.2.120
CLUSTER CVSBIND DEL DATAServ 172.17.2.120
NUDP DEL DATAServ 172.17.2.120
nss /pooldeactivate=DATA /overridetype=question
4. Test the installation
- Take the Cluster Volume holding the NSM Engine offline, then bring it online. The NSM Engine service should load and initialize.
- Run NSMAdmin.exe and try connecting to the NSM Engine using the Virtual Server IP address. If NSMAdmine successfully connects, the Cluster Resource load scripts are working.
- Migrate the NSM Engine Cluster Volume to another node and try connecting with NSMAdmin again. NSMAdmin will prompt for a login again since the Engine has gone down and come back up, but the login should continue to work with the same IP address for management.
5. Deploy the NSM Sentinel
The current version of the NSM Engine tries to deploy the NSM Sentinel to other servers on a like-named volume as what the Engine itself is running on. In many instances, the NSM Sentinel may not be deployed to servers having like-named volumes. For now, the following manual process must be carried out to deploy NSM Sentinels in these conditions.
- Copy the following three files from the NSM Engine FACTORY directory to SYS:\FACTORY directory on the target server.
- FSFEVENT.NLM
- LICENSE.DAT
- EVENT.CFG
- Modify AUTOEXEC.NCF to load the Sentinel at boot time:
LOAD SYS:FACTORY\FSFEVENT.NLM -S<EngineServer>
where <EngineServer> is the name of the NetWare server running FSFENGIN.NLM.
A future revision of the NSM Engine and NSMAdmin interface will allow for distribution of the NSM Sentinel to a volume of choice.
