Introduction

References -
   1. NIM Setup Guide
   2. NIM Communication Between a Firewall
   3. IBM RedBook - NIM A-Z for AIX 5L

Testing Environment

Procedures -
   1.) Define Server A as NIM Master
   2.) Initializing Server B as the Alternate
   3.) Initiate Server A as alternate of Server B
   4.) Defining a Client to Server A
   5.) Synchronizing the Alternate Master's NIM database
   6.) Taking Over Clients

Conclusion


 

Introduction

             This document was written to provide NIM users with a step by step procedure on how to implement an alternate NIM master for their NIM environment. An alternate NIM master provides the capabilities of having a backup NIM server that can synchronize existing resources with the original NIM master and takeover NIM clients.

             Alternate NIM masters are used to provide redundancy in cases where a primary NIM server has a scheduled outtage for maintenance but NIM operations must continue within the environment. Additionally, the alternate can serve to maintain NIM resources as a backup in case the primary NIM server crashes, becomes corrupted, or resources are removed.

             For testing purposes, this document will work with the AIX version 6.1 Technology Level 2 throughout the examples. Although the examples are worked with AIX 6100-02, testing of alternate master operation was performed for AIX versions 5300-09 to 5300-12 and 6100-00 to 6100-05. It's important to note that beyond 6100-04, nimsh is required as the communication protocol between alternate masters. This will be stressed throughout the examples when the communication between alternate NIM master is addressed.

Back to top
 

References

              A few NIM resources are provided below if needed for references and usage support before working with alternate masters.

1. NIM Setup Guide -

http://www-1.ibm.com/support/docview.wss?rs=0&q1=NIM+Setup+Guide&uid=isg3T1010383&loc=en_US&cs=utf-8&cc=us&lang=en

2. NIM Communication Between a Firewall -

http://www.ibm.com/support/docview.wss?uid=isg3T1011808

3. IBM RedBook - NIM A-Z for AIX 5L -

http://www.redbooks.ibm.com/abstracts/sg247296.html?Open

Back to top
 

Testing Environment

"server A/server A hostname"= Primary 6100-02* NIM Server/LPAR

"server B/server B hostname"= Secondary 6100-02* NIM Server/LPAR used as alternate master

"client/client hostname" =Test 6100-02* NIM Client Server/LPAR

* It is highly recommended to have the systems updated to the latest service pack for the technology level installed. This ensures that all of the latest security and operational fixes are applied to the system.

Back to top
 

Procedures

1.) Define Server A as NIM Master

             Before defining a NIM master, ensure that the following filesets have been installed to the system: bos.sysmgt.nim.master and bos.sysmgt.nim.spot.

Configure Server A as NIM master
============================================================================

# smitty nim >>> Configure the NIM Environment >>> Advanced Configuration >>> Initialize the NIM Master Only

 Configure Network Installation Management Master Fileset

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

                                                        [Entry Fields]
* Network Name                                       [network name]
* Primary Network Install Interface                  [selected interface]                      +

  Allow Machines to Register Themselves as Clients?  [yes]                   +
  Alternate Port Numbers for Network Communications
       (reserved values will be used if left blank)
    Client Registration                              []                       #
    Client Communications                            []

============================================================================


Verify Server A is NIM master:
=========================================================================

Niminfo file of server A:

# more /etc/niminfo
export NIM_NAME=master
export NIM_CONFIGURATION=master
export NIM_MASTER_PORT=1058
export NIM_REGISTRATION_PORT=1059
export NIM_MASTER_HOSTNAME=<server A hostname>
=========================================================================

Back to top

2.) Initializing Server B as the Alternate

             In this situation Server B was not defined as NIM master as in the first step of the procedure per the following instructions:

Initializing the alternate master using SMIT –
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.install/doc/insgdrf/adv_config_alt_master_support.htm?resultof=%22%61%6c%74%65%72%6e%61%74%65%22%20%22%61%6c%74%65%72%6e%22%20%22%6d%61%73%74%65%72%22%20

Initialize Server B as alternate:
=========================================================================

# smitty niminit_altmstr

Initialize This Machine as an Alternate Master

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

                                                        [Entry Fields]
* This Machine Name                                  [server B hostname]
* Primary Network Install Interface                  [selected interface]                   +
* Host Name of Master with which to Initialize       [server A hostname]

  Hardware Platform Type                              chrp
  Kernel to use for Network Boot                     [64]                    +
  Communication Protocol used to communicate with    []                      + 
Alternate Master  

Use F4 to see options. Note this option will display what protocol is supported considering the AIX version running on the system. If nimsh is not an option it’s because it was not supported for alternate masters until 6.1 TL 4
=========================================================================

Results of Alternate Master Initialization Operation:
=========================================================================
 

COMMAND STATUS

Command: OK            stdout: yes           stderr: no

Before command completion, additional instructions may appear below.

0513-071 The nimesis Subsystem has been added.
0513-071 The nimd Subsystem has been added.
0513-059 The nimesis Subsystem has been started. Subsystem PID is 204848.

=========================================================================

             The next step is to ensure that Server A is aware of the new alternate master as a NIM resource:

Confirm that alternate_master resource was defined on Server A
=========================================================================

# lsnim
master         		machines        master
boot           		resources       boot
nim_script     		resources       nim_script
master_net     		networks        ent
server B hostname		machines        alternate_master

=========================================================================

Check the /etc/niminfo file on Server B (the alternate)
=========================================================================

# more /etc/niminfo
export NIM_NAME=master
export NIM_CONFIGURATION=master
export NIM_MASTER_PORT=1058
export NIM_REGISTRATION_PORT=1059
export NIM_MASTER_HOSTNAME=server B hostname
export NIM_ALTERNATE_MASTER="server A hostname"

=========================================================================

             At this point Server B is successfully defined as an alternate of Server A. If server A needs to be an alternate master of Server B, continue to Step 3 of the procedures.

Back to top

3.) Initiate Server A as alternate of Server B

Define Server A as an alternate master of Server B
==========================================================================

# smitty niminit_altmstr

Initialize This Machine as an Alternate Master

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

                                                             [Entry Fields]
* This Machine Name                                  [server A hostname]
* Primary Network Install Interface                  [en0]                   +
* Host Name of Master with which to Initialize       [server B hostname]
  Hardware Platform Type                              chrp
  Kernel to use for Network Boot                     [64]                    +
  Communication Protocol used to communicate with    []                      +
Alternate Master

Use F4 to see options. Note this option will display what protocol is supported considering the AIX version running on the system. If nimsh is not an option it’s because it was not supported until 6.1 TL4

Run the command
=========================================================================

             After the command is run, check the niminfo file of Server A for any updates:

Check the niminfo file of Server A. Updated /etc/niminfo file
=========================================================================

# more /etc/niminfo
export NIM_NAME=master
export NIM_CONFIGURATION=master
export NIM_MASTER_PORT=1058
export NIM_REGISTRATION_PORT=1059
export NIM_MASTER_HOSTNAME=<server A hostname>
export NIM_ALTERNATE_MASTER="<server B hostname>”
=========================================================================

NOTE: Once an alternate master has been added to the NIM environment, previously defined clients should be re-defined to recognize the alternate master(#smitty niminit). Re-defining the clients gives the alternate master remote access to the clients either through rsh or nimsh. A common error encountered is as follows:

0042-372 c_switch_master: The client is not configured to allow this master to execute this command

The issue is resolved simply by removing the /etc/niminfo file from the client and redefining the client on the client side:

Redefine the client:

=========================================================================

# niminit -a name=<client> -a master=<master>

=========================================================================

             Once clients have been re-defined, their sync_required attribute is set to no, indicating that they recognize the alternate master. Only clients running AIX 5.3 or later recognize alternate masters!

Verify the resources of Server B to see the alternate NIM Server A listed
=========================================================================

# lsnim

master         		machines        master
boot			resources       boot
nim_script     		resources       nim_script
master_net     		networks        ent
server A definition        machines        alternate_master

=========================================================================


Verify the resources on Server A to see the alternate NIM Server B listed
=========================================================================

# lsnim

master         		machines        master
boot			resources       boot
nim_script     		resources       nim_script
master_net     		networks        ent
server B definition	machines        alternate_master
client definition		machines	       standalone

=========================================================================

Back to top

4.) Defining a Client to Server A

Define a client to original Server A to test sync and replication
=========================================================================

On the client run:

# smitty niminit

Configure Network Installation Management Client Fileset
                                       [Entry Fields]
* Machine Name                                       [client hostname]


* Primary Network Install Interface                  [en0]                   +
* Host Name of Network Install Master                [server A hostname]

  Hardware Platform Type                              chrp
  Kernel to use for Network Boot                     [mp]                    +
  Communication Protocol used by client              []                      +
  Ethernet Interface Options
    Network Speed Setting                            []                      +
    Network Duplex Setting                           []                      +
  Comments                                           []

  


=========================================================================

Run the command until OK. Check the /etc/niminfo file on the client
=========================================================================

# more /etc/niminfo

#------------------ Network Install Manager ---------------
# warning - this file contains NIM configuration information
#       and should only be updated by NIM
export NIM_NAME=<client NIM name definition>
export NIM_HOSTNAME=<client hostname>
export NIM_CONFIGURATION=standalone
export NIM_MASTER_HOSTNAME=<server A hostname>
export NIM_MASTER_PORT=1058
export NIM_REGISTRATION_PORT=1059
export NIM_SHELL="shell"
export NIM_MASTER_HOSTNAME_LIST="<server A hostname> <server B hostname>"
export NIM_BOS_IMAGE=/SPOT/usr/sys/inst.images/installp/ppc/bos
export NIM_BOS_FORMAT=rte
export NIM_HOSTS=" 127.0.0.1:loopback:localhost  <client IP>:<client hostname>  <server A IP>:<server A hostname>"
export NIM_MOUNTS=""
export ROUTES=" default:0:<default gateway IP> "


=========================================================================

Check client definition on Server A
=========================================================================

# lsnim -l client hostname
client hostname:
   class          = machines
   type           = standalone
   current_master = server A hostname
   sync_required  = no
   connect        = shell
   platform       = chrp
   netboot_kernel = 64
   if1            = net1 client hostname 8EB220004002 ent0
   cable_type1    = N/A
   Cstate         = ready for a NIM operation
   prev_state     = ready for a NIM operation
   Mstate         = currently running
   cpuid          = 00068A0AD700



             Notice that the sync_required = no attribute for this particular client. But if the attribute is set to YES, then synchronization needs to be performed for the clients.
=========================================================================

Back to top

5.) Synchronizing the Alternate Master's NIM database

             Provided is an example of sync-ing a mksysb, spot, and image.data resource from Server A to Server B (resource filesystem /nim already exists and is mounted on Server B)

Example of Synchronization and Replication of Resources
=========================================================================

Server A with mksysb, spot, and image.data resource defined:

# lsnim
master				machines        master
boot				resources       boot
nim_script			resources       nim_script
master_net			networks        ent
server B hostname	  		machines        alternate_master
client hostname			machines        standalone
client hostname_sysb		resources       mksysb
client hostname_spot		resources       spot
clinet hostname_im	  		resources       image_data


Server B with no resources other than alternate_master:

# lsnim
master         		machines        master
boot           		resources       boot
nim_script     		resources       nim_script
master_net     		networks        ent
server A hostname		machines        alternate_master



Resource filesystem /nim (10GB) on Server A

# df -g | grep nim
/dev/fslv01       10.00      8.34   17%     3206     1% /nim

# cd /nim

# ls
im_data     lost+found  lpp         mksysb      spot



Resource filesystem /nim (10GB) on Server B

# df -g | grep nim
/dev/fslv01       10.00     10.00    1%       10     1% /nim

# cd /nim

# ls
lost+found


Confirm which master has control of the clients

             Check the /etc/niminfo file of the client or run the following from one of the masters:

# nim -o lslpp <client hostname>


If the client is assigned to that master and can communicate, then the output of the command will return a list of filesets which are installed on the client. Otherwise the output will return:

0042-001 nim: processing error encountered on "master":
0042-378 m_lslpp: The current master for "<client hostname>"
is "<current master hostname>". You must run the "takeover" operation to
become the current master before you can execute the "/usr/lpp/bos.sysmgt/nim/methods/c_ckspot"
operation on this client.

or…

0042-001 nim: processing error encountered on "master":
0042-006 m_lslpp: (From_Master) connect Connection refused

<client hostname>: Connection refused

             Syncronization will duplicate the resource definitions from the NIM database of server A to server B

NOTE: You should consider the following issues when synchronizing the alternate master's NIM database:

* Object definitions are reset when the database is restored on master B.
* After the database is restored on master B, master B does not control any NIM objects until you perform the takeover operation. As a result, master B can not run any NIM operations to any objects in its database.


On Master A run the following operation to set up the synchronization and replication of resources and clients:

# smitty nim_altmstr >>> Synchronize an Alternate Master's NIM database >>>

Synchronize an Alternate Master's NIM database

Type or select a value for the entry field.
Press Enter AFTER making all desired changes.

                                                        [Entry Fields]
* Alternate Master                                   [Use F4 and select Server B]                      +

 <server B hostname>     machines       alternate_master


Synchronize an Alternate Master's NIM database

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

                                                        [Entry Fields]
* Target Name                                         <server B hostname>     
  Force                                               yes                  +
  Replicate                                           yes                  +


NOTE: Use F1 or Esc+1 while the 'Force' and 'Replicate' fields are highlighted for more information.


Run the command until it returns OK.


Output of Sync and Replication:

COMMAND STATUS

Command: OK            stdout: yes           stderr: no

Before command completion, additional instructions may appear below.

[TOP]
a ./etc/objrepos/nim_attr 8 blocks
a ./etc/objrepos/nim_attr.vc 8 blocks
a ./etc/objrepos/nim_object 8 blocks
a ./etc/objrepos/nim_object.vc 8 blocks
a ./etc/NIM.level 1 blocks
a ./etc/niminfo 2 blocks
The original NIM database was backed up to the
        following location prior to this operation:
        "/export/nim/backups/server B hostname.10073807242010.backup"

0513-044 The nimesis Subsystem was requested to stop.
0513-004 The Subsystem or Group, nimd, is currently inoperative.
0513-083 Subsystem has been Deleted.
0513-083 Subsystem has been Deleted.
5 objects deleted
43 objects deleted
Restoring the NIM database from /tmp/_nim_dir_17626/mnt0
x ./etc/NIM.level, 8 bytes, 1 tape blocks

The level of the NIM master fileset on this machine is: 5.3.9.0
The level of the NIM database backup is: 5.3.9.0

Level check is successful.

x ./etc/objrepos/nim_attr, 4096 bytes, 8 tape blocks
x ./etc/objrepos/nim_attr.vc, 4096 bytes, 8 tape blocks
x ./etc/objrepos/nim_object, 4096 bytes, 8 tape blocks
x ./etc/objrepos/nim_object.vc, 4096 bytes, 8 tape blocks
x ./etc/NIM.level, 8 bytes, 1 tape blocks
x ./etc/niminfo, 233 bytes, 1 tape blocks
0513-071 The nimesis Subsystem has been added.
0513-071 The nimd Subsystem has been added.
0513-059 The nimesis Subsystem has been started. Subsystem PID is 28042.
Finished restoring the NIM database
Updating master definition in database from janky definition
  Updated master attribute platform to chrp
  Updated master attribute netboot_kernel to mp
  Updated master attribute if1 to master_net server B hostname 00145EB74C7E ent2
  Updated master attribute cable_type1 to N/A
Finished updating master definition
Resetting machines
  Reset master
  Reset server B
  Reset client
Finished resetting machines
Removing NIM client client
Finished removing client
Resetting NIM resources
Finished resetting NIM resources
Replicating NIM resources. Please wait, takes time....
Replicating resource client hostname_sysb
Replicated resource client hostname­_sysb
Replicating resource client hostname_spot
version=5
release=3
mod=9
Replicated resource client hostname_spot
Replicating resource client hostname_im
Replicated resource client hostname_im
Finished Replicating NIM resources
Checking NIM resources
  Keeping client hostname_sysb
  Keeping client hostname_spot
  Keeping client hostname_im
Finished checking NIM resources
Checking NIM SPOTs
  checking client hostname_spot
Finished checking SPOTs
nim_master_recover Complete


=========================================================================



Resource results on Server B after sync/replication:
=========================================================================

# lsnim
master				machines        master
boot				resources       boot
nim_script			resources       nim_script
master_net			networks        ent
client hostname			machines        standalone
client hostname_sysb		resources       mksysb
client hostname_spot		resources       spot
clinet hostname_im	  		resources       image_data

# ls /nim
im_data     lost+found  mksysb      spot


=========================================================================

NOTE: It’s highly recommended to create the same filesystem structure and subdirectory locations for the NIM resources as on the primary server to reduce complications during the replication.

             The NIM A-Z manual does not recommend synchronizing the SPOT resources, but rather creating a SPOT from the replicated lpp_source on the alternate master. Regardless, during alternate master testing, the SPOTs were also replicated without any issues.

             As long as the resource locations are the same on the alternate master, the resources will be replicated along with the client definitions. IMPORTANT!: If the resource locations are not re-created or mounted on the alternate_master the resources will try to be created in / and possibly fill up the / directory.

Back to top

6.) Taking Over Clients

             The takeover operation is utilized when the alternate NIM master needs to take control of the NIM environment.

             Before taking over clients on the alternate master, one of two things needs to be completed. First, the client needs to be defined on the alternate master, and second, a sync needs to be run from server A before the takeover (Discussed on Step 5.).

Run the takeover command on Server B to take control from Server A
=========================================================================

# smitty nim_altmstr >>> Takeover control of NIM clients from an Alternate Master

Takeover control of NIM clients from an Alternate Master

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

                                                        [Entry Fields]
* Target Name                                         server A  

  Force                                               no                     +

Run the command:

COMMAND STATUS

Command: OK            stdout: yes           stderr: no

Before command completion, additional instructions may appear below.

Updating the NIM database on the "alternate_master" "server B"...
+-----------------------------------------------------------------------------+
                      "update" Operation Summary
+-----------------------------------------------------------------------------+
 Target                                    Result
 ------                                    ------
 client hostname                           SUCCESS


=========================================================================

             Once the takeover is complete with Result = SUCCESS, perform a few checks to ensure the clients were taken over successfully.

Server B after the sync:
=========================================================================

# lsnim
master				machines        master
boot				resources       boot
nim_script			resources       nim_script
master_net			networks        ent
server A                             machines        alternate_master
client hostname			machines        standalone
client hostname_sysb		resources       mksysb
client hostname_spot		resources       spot
clinet hostname_im	  		resources       image_data


=========================================================================

Client /etc/niminfo defined under Server A before the takeover:
=========================================================================

# more /etc/niminfo
#------------------ Network Install Manager ---------------
# warning - this file contains NIM configuration information
#       and should only be updated by NIM
export NIM_NAME=client hostname
export NIM_HOSTNAME=client fully qualified hostname
export NIM_CONFIGURATION=standalone
export NIM_MASTER_HOSTNAME=server A hostname
export NIM_MASTER_PORT=1058
export NIM_REGISTRATION_PORT=1059
export NIM_SHELL="shell"
export NIM_MASTER_HOSTNAME_LIST="server A hostname server B hostname"
export NIM_BOS_IMAGE=/SPOT/usr/sys/inst.images/installp/ppc/bos
export NIM_BOS_FORMAT=rte
...


=========================================================================

             As long as Server A is defined as an alternate master of Server B, the takeover operation can be run on Server A to take back control of the clients.

Results of Server B takeover from Server A:
=========================================================================

Client /etc/niminfo defined under Server B after takeover:

# more /etc/niminfo
#------------------ Network Install Manager ---------------
# warning - this file contains NIM configuration information
#       and should only be updated by NIM
export NIM_NAME=client hostname
export NIM_HOSTNAME=client fully qualified hostname
export NIM_CONFIGURATION=standalone
export NIM_MASTER_HOSTNAME=server B hostname
export NIM_MASTER_PORT=1058
export NIM_REGISTRATION_PORT=1059
export NIM_SHELL="shell"
export NIM_MASTER_HOSTNAME_LIST="server B hostname server A hostname"
export NIM_BOS_IMAGE=/SPOT/usr/sys/inst.images/installp/ppc/bos
export NIM_BOS_FORMAT=rte
...


=========================================================================

Back to top

Conclusion

             Once the NIM environment has been established to synchronize resources and takeover NIM clients, the implementation of Alternate NIM Masters has been completed.

             A few things to consider when working with Alternate NIM Masters are as follows: 1.) Although an alternate master may be in place as a backup, one should always keep another backup of each NIM servers database for safe measure. 2.) Do not update one master without planning on updating the alternate, as both masters must be at the same oslevel. 3.) Communication protocols (nimsh/rsh) between the masters should be set the same.

             NIM is an ever dynamic and complex tool, but its applications are progressively useful. Alternate Masters is one of many NIM functions provided that may be subject to changes and improvements in the future. If additional support is needed for possible defects, general inquiries, and/or usage, please contact our 1-800-IBM-SERV support line.

Back to top