Using MKSYSB to implement backup and rapid migration of multiple network Nim master in a Vmcontrol management environment

Some issues to consider for backup and migration of the multiple network NIM Master used by Vmcontrol

As an important part of the Vmcontrol management environment, the power system administrator needs to pay great attention to the backup of NIM Master itself, taking into account how fast recovery occurs when a power server fails. For example, there is a hardware failure in the power server where Nim master resides, and we need to quickly migrate Nim master to a new power server.

Theoretically, the power system administrator can take advantage of any NIM master to perform a mksysb backup of the Nim master currently in use by Vmcontrol, and then migrate to restore according to MKSYSB, but this migration needs to be addressed in practical terms to address some of the key issues.

Problem one, the corresponding packages for all Nim Server are automatically deleted and the NIM resource database content is purged using the MKSYSB backup of Nim Master.

Problem two, Nim master used in Vmcontrol environments is often equipped with multiple network IP addresses, multiple NIM routes to meet the problem of communication networks and deployment network isolation, and using existing MKSYSB to create a new NIM Master System must meet the needs of multiple networks simultaneously. And NIM's own limitations, when recovering mksysb backups, often only one IP network address is preserved.

The solution to both of these problems requires some extra setup and some scripting in our backup and NIM Master. This article will help power system administrators master This approach through an example to meet the needs of day-to-day management maintenance.

Schematic diagram of the backup and migration structure of NIM Master

Figure 1. Example diagram of the backup and migration structure of NIM Master

The experimental environment used in this example is shown in Figure 1.

Nim Master A is a NIM server in use in the Vmcontrol environment, which itself has two network IP addresses, namely 9.x Primary Network (public network) and 10.x private network; Administrators use Vmcontrol to configure capture and deployed network traffic to walk 10.32.136.x private network, so that when the capture and deployment occurs, the management Network 9.12.x.x network is not affected, to ensure that the System Management Network normal communication.

This common NIM network configuration often requires a corresponding NIM route to be configured on the NIM server side, for NIM routing settings see developerWorks article: Power Server Capture and system deployment with Vmcontrol 2.4 for multiple networks

Nim Master B is a separate NIM server outside the Vmcontrol environment, which has only 9.x network addresses, which will be used to back up NIM master A;

Nim Master C is a MKSYSB backup used in the event of Nim master A that restores the NIM server generated after the migration, and it needs to be equipped with both public and private network IP addresses and corresponding NIM network objects and routes, as Nim master A does, but Nim M. Aster C uses a different Hostname and IP address.

Create a MKSYSB backup of NIM Master

As mentioned earlier, backup and rapid migration to NIM master A requires that we address two key issues, the first being that the corresponding NIM master package on the NIM server is automatically deleted. This is the limitation of NIM itself, and some Nim scripts are automatically invoked during the Netboot phase as the system is restored using the MKSYSB mirror file, where the script/spot/usr/lpp/bos.sysmgt/nim/methods/c_mk_ The nimclient will automatically uninstall the Bos.sysmgt.nim.master, causing the restored system to be just a NIM Client.

For this issue, although there is no way to fundamentally prevent the NIM master package from being removed, consider using the Fb_script script to reinstall the associated deleted packages when using MKSYSB to recover the deployment, but we also need to note that Nim Master Has its own database, so you also need to restore the NIM database. To do this, we need to complete the following two steps in advance of the MKSYSB backup of NIM Master A.

Backing up the NIM Master database

For the NIM database backup, we can use the NIM command line m_backup_db, as shown below, to back up the database to the temporary directory/tmp of NIM Master A, named/tmp/xnw3055.nimdb.backup. We plan to use this backup file to restore the database on the newly created Nim Master C, which is done after the first boot of the system, and we need to create the Fb_script type of NIM script.

(0) root @ xnw3055::/

#/usr/lpp/bos.sysmgt/nim/methods/m_backup_db/tmp/xnw3055.nimdb.backup

A./etc/objrepos/nim_attr blocks

A./ETC/OBJREPOS/NIM_ATTR.VC 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 1 blocks

A./etc/nim.primary.cpuid 1 blocks contains the NIM Master corresponds to the package version letter

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Servers/cloud-computing/