Section 12.2. Planning for Ignite-UX Archive Storage and Recovery

12.2. Planning for Ignite-UX Archive Storage and Recovery

An Ignite-UX client system contains a subset of the software installed on the Ignite-UX server. The primary difference between the client and the server is that the server will be used to manage, among other things, the recovery operations of one or more remote clients. This primarily involves the enabling of additional network services, consideration of additional disk space to store recovery archives, and planning for the remote boot procedure that is used during recovery.

12.2.1. Considerations for the Remote Booting of Clients

Here are the initial considerations for remotely booting an HP-UX client system for Ignite-UX recovery:

Is there a running OS on the client, and does it have networking capabilities?

If there is a running OS with networking capabilities, the network boot of the client may be initiated from the Ignite-UX server with a recovery image being pushed across the network to the client. In this scenario, the Ignite-UX server uses the bootsys command to initiate the OS recovery to one or more clients, without having to interact with the console of each client. bootsys copies the Ignite-UX install kernel and root filesystem to the client, configures the client to boot automatically from this kernel, and reboots. The archive recovery is then performed across the network.

If the client has no running OS communicating with the network, it must be booted from either a directly connected or a remote console to pull a recovery image across the network from the Ignite-UX server. When booting an HP Integrity client across the network in this manner (pull operation), any EFI-supported network interface may be used. When booting an HP9000 client in a pull operation, the client's built-in network interface must be used; otherwise, the HP9000 client needs to be recovered from a local recovery image such as a make_tape_recovery tape, custom CD/DVD Ignite-UX bootable recovery image, or other OS installation media. The latter options, of course, assume that there is a tape or CD/DVD drive available for the client systems.

Are the client and Ignite-UX servers on the same network subnet?

If the client and Ignite-UX boot server are on different subnets, either an Ignite-UX boot helper must be configured on the same subnet as the client, or as discussed earlier, local tape or CD/DVD operations should be used for the initial boot prior to connecting with the Ignite-UX server.

The purpose of the boot helper is to provide the temporary IP address, install kernel, and install root filesystem. In other words, the initial network boot of a client to a boot protocol server must be across the same subnet. From that point, the client will be able to communicate with an Ignite-UX server on another subnet to download and install the recovery archive. Configuration of a boot helper system is detailed in the Ignite-UX Administration Guide at docs.hp.com.

How can I plan ahead for remote boot scenarios?

For client systems that might potentially fail in such a way as to require booting across the network from firmware using the client's local console and a specific network interface, it may be helpful to prepare ahead of time by collecting the network information that will be needed during recovery.

In the following example, an HP Integrity system has five network interfaces, four of which are on a four-port network card. The primary interface used for the remote network boot is found at the hardware address 0/0/8/1/0/4/0. The rx designation in the server model indicates that this is an HP Integrity system. The lanscan command output includes the hardware addresses and Link Level MAC addresses. The ioscan command output includes the HP part numbers for the interfaces.

# model ia64 hp server rx7620 # lanscan Hardware Station        Crd Hdw   Net-Interface  NM  MAC       HP-DLPI DLPI Path     Address        In# State NamePPA        ID  Type      Support Mjr# 0/0/8/1/0/4/0 0x00306EF397E9  0   UP    lan0 snap0    1   ETHER     Yes     119 0/0/14/1/0/4/0 0x000E7F4FB144 1   UP    lan1 snap1    2   ETHER     Yes     119 0/0/14/1/0/5/0 0x000E7F4FB145 2   UP    lan2 snap2    3   ETHER     Yes     119 0/0/14/1/0/6/0 0x000E7F4FB146 3   UP    lan3 snap3    4   ETHER     Yes     119 0/0/14/1/0/7/0 0x000E7F4FB147 4   UP    lan4 snap4    5   ETHER     Yes     119 # ioscan -fnC lan Class I H/W Path     Driver S/W State H/W Type Description =========================================================================== lan 0 0/0/8/1/0/4/0  igelan CLAIMED INTERFACE HP A6794-60001 PCI 1000Base-T lan 1 0/0/14/1/0/4/0 btlan  CLAIMED INTERFACE HP A5506B PCI 10/100Base-TX 4 Port lan 2 0/0/14/1/0/5/0 btlan  CLAIMED INTERFACE HP A5506B PCI 10/100Base-TX 4 Port lan 3 0/0/14/1/0/6/0 btlan  CLAIMED INTERFACE HP A5506B PCI 10/100Base-TX 4 Port lan 4 0/0/14/1/0/7/0 btlan  CLAIMED INTERFACE HP A5506B PCI 10/100Base-TX 4 Port

12.2.2. Sizing the Recovery Archive

It's important to properly size the recovery archive. If the archive is large and you use make_tape_recovery, the archive could potentially span multiple tapes. This represents a disadvantage during both archive creation and recovery by requiring user interaction in a process that might otherwise occur unattended (for example, through a cron job). Many system administrators schedule tape creation during times when the system has reduced utilization, such as during the night and on weekends. For make_net_recovery archives, the added complexities would include calculations for required disk space as well as for offline storage space and tape backup completion times. Note that the number of successive archives to be retained on disk is specified either through the Ignite-UX server interface or from the command line using the -n option. The Ignite-UX parameter that records this information is called save_num_archives and is stored in the /var/opt/ignite/clients/client_name/recovery/defaults file.

Another consideration involving the sizing of recovery archives involves the placement of filesystems into other volume groups that are normally found in the root volume group. Avoid the temptation to fragment required system directories and files across volume groups. The best practice when deciding what to include or not to include within the root volume group and within a recovery archive is to maintain a bootable system of a reasonable size completely within the root volume group.

When creating an archive for the Ignite-UX server itself, consider excluding the collection of on-disk client recovery archives that are found by default under the /var filesystem. Another example of a filesystem that might be excluded from a recovery archive is /home. Consider the size of that filesystem in relation to the rest of the archive, how often the recovery archives are created, and if it would be acceptable following an OS recovery operation to restore the most recently saved /home filesystem from normal tape backups.

make_net_recovery uses the network to store and retrieve archives via two NFS mount points. One mount point stores configuration information about the client; the other stores the archive itself. The archive does not need to be stored on the Ignite-UX server. The archive may be stored on any properly configured NFS server. In this configuration, the Ignite-UX recovery management process involves three different systems including the Ignite-UX server, the client, and (optionally) a remote archive server.

The default storage location for individual recovery archives is defined during the initial client configuration through the Ignite-UX server interface. You may choose alternate locations using the a option to the make_net_recovery command. The Ignite-UX parameter that records this information is called recovery_location, and is stored in the /var/opt/ignite/clients/client_name/recovery/defaults file. The directories and NFS export rules of an alternate location must be manually created before the alternate location may be used.

12.2.3. Configuring an Ignite-UX Network Server

Following the installation of Ignite-UX using the swinstall command, you begin the process of configuring an Ignite-UX network server the first time root brings up the server interface with the /opt/ignite/bin/ignite command.

While the configuration of Ignite-UX is required before running the network-based make_net_recovery, make_tape_recovery may be used to create recovery archives to a local tape drive as soon as Ignite-UX is installed on an HP-UX system. The advantage to initiating make_net_recovery and make_tape_recovery operations from the Ignite-UX server is that the Ignite-UX software required for recovery archive operations is automatically installed onto the clients.

The initial "Welcome To Ignite-UX" screen has a Server Setup button and a "Tutorial and Demo" button, in case you would like an onscreen reference.

The Server Setup wizard steps the system administrator through the following activities:

1. Setting up temporary IP addresses that help boot client systems to an install kernel from the server in preparation for installation/recovery. It is important to verify that these temporary IP addresses are not already in use. One address is required for each anticipated simultaneous installation/recovery operation.

2. Setting up DHCP addresses (optional) used by the client systems after the initial remote boot from the server. The DHCP service is used only for client configurations that do not have predefined system hostnames and IP addresses.

3. Setting up a software depot containing core OS software that is used in the Ignite-UX deployment model. (This is not used in system recovery.)

The next time that the "Welcome To Ignite-UX" screen appears following configuration, select the OK button to display the main Ignite-UX server interface. From the main interface in the Options drop-down menu, select Server Configuration to review and modify a number of Ignite-UX server and configuration parameters. The Session Options control the behavior of the client systems during installation/recovery.

Select Actions"Add New Client for Recovery". After entering a client hostname, Ignite-UX uses either remsh or ssh to gather needed information from the client. Recovery software needed on the client is automatically installed or updated when working from the Ignite-UX server interface. If make_net_recovery is run from the command line of the client, and the recovery software is a different version than is on the server, an error may be generated. To manually initiate the update (not the installation) of recovery software on the client, refer to the make_net_recovery manpage for an example script that uses the /opt/ignite/lbin/check_version and SD-UX swinstall commands.

The previously mentioned new functionality for HP-UX 11.23 bootpd support of DHCP device pool groups requires the manual editing of the /etc/dhcptab file using the new dhcp_device_group configuration options re and ncid. re instructs the DHCP server to perform regular expression matching on the class-id. ncid indicates that the response from the server will not contain a class-id because BOOTP does not support the full PXE protocol.

Following is an example dhcp_device_group enTRy with the two new options that would be referenced by bootpd starting at HP-UX 11.23. The bf (boot file) option specifies that the network bootstrap program for EFI-partitioned boot disks be downloaded to continue booting (EFI is the Intel Extensible Firmware Interface used by HP Integrity systems). The other dhcp_device_group options in this example direct the IP address assignment.

dhcp_device_group:\    re:\    ncid:\    class-:\    lease-time=300:\    subnet-mask=255.255.255.0:\    addr-pool-start-address=192.168.1.10:\    addr-pool-last-address=192.168.1.20:\    bf=/opt/ignite/boot/nbp.efi

For complete configuration details, refer to the most recent Ignite-UX Administration Guide, found online at http://docs.hp.com, as well as the manpages for the various Ignite-UX and HP-UX commands.

12.2.4. Recovery Archive Management

You may initiate the creation or restoration of system recovery archives from the Ignite-UX GUI or via the command line. If a graphics display is not available on the Ignite-UX server, use the TUI mode to run the ignite interface.

The make_net_recovery command may be initiated from the command line of the client, or through the Ignite-UX server interface. The make_tape_recovery command may be initiated from either the command line on the client or through the Ignite-UX interface on the server. When initiated from the Ignite-UX server, make_tape_recovery executes on the client and writes to the client's local tape drive. When make_tape_recovery is initiated from the client's command line instead of from the Ignite-UX server interface, no NFS mounting is required nor is any Ignite-UX server configuration required. If the make_tape_recovery -s option is used from the client to specify an Ignite-UX server, then NFS mounting occurs, and it uses the configuration information stored from that client's last server-initiated make_tape_recovery session.

Following the initial Ignite-UX server configuration, you can continue to use the GUI or TUI server interface to manage network-based archives. Here are some of its advantages:

• There is centralized management and control of network-wide activities.

• Configuration settings made in the GUI or TUI are saved on the Ignite-UX server and are automatically loaded in subsequent runs.

• The required recovery tools are automatically installed and updated to the client systems.

• An icon representing the system being archived is graphically displayed; a status monitor that indicates progress of the archive creation from start to finish can also be displayed.

• Default directories are automatically created with related NFS mounts and exportfs configuration information that facilitates client/server interaction. If the directories used for storing archives are not the default (including being on a server different from the Ignite-UX server), this step is required to be performed manually on both the Ignite-UX server and on the archive server.

Here are three scenarios in which users might consider using the command-line interface.

• The system recovery commands have been run once from the GUI, and the stored settings from that session must be overridden.

• The system recovery commands have been run once from the GUI, and future invocations of the commands should use those exact same settings as stored.

• The system recovery commands are being run for the first time, and as an experienced user, you want to see the output directly from the commands.