This section provides examples of switchover configurations for each different switchover method.
Each method has its own restrictions regarding the supported hardware environment.
For details, refer to the corresponding "Note" in "2.5 Hardware Environment" in the "Design Guide VE".
Spare server configuration for local boot servers
A spare server should be set aside for servers in local boot environments.
When a primary server fails, a system image (that must be backed up beforehand) will be restored to the spare server, and the spare server will be started up. A spare server can be shared by multiple primary servers.
If a local boot server is using SAN storage for data storing purposes, I/O virtualization can make this SAN storage space accessible to the spare server.
Figure 9.1 Spare Server Configuration for Local Boot Servers
Spare server configuration for booting from SAN/iSCSI storage servers (using virtual I/O)
At least one spare server using virtual I/O should be set aside for servers in a SAN/iSCSI boot environment.
When a primary server fails, the WWN set on its HBA or MAC address, boot configuration, and network configuration set on its NIC is inherited by the spare server, which can then access and start up from the same boot disk. A spare server can be shared by multiple primary servers.
Figure 9.2 Spare Server Configuration for Booting from SAN/iSCSI Storage Servers
For spare server configurations based on I/O virtualization, a spare server can be shared by multiple physical OSs and VM guests (using the high-availability feature provided with their server virtualization software). For details on the server virtualization software supporting this configuration, refer to "D.1 Common Functions of Server Virtualization Software" in the "Design Guide VE".
In this case, spare servers should be set up as a VM hosts booting from a SAN, so that when a physical server hosting VM guests experiences a failure, the high-availability feature provided with their server virtualization software can be used to transfer the VM guests to this spare VM host.
If a server running a physical OS fails, its boot disk will be reconnected to the spare server by means of an HBA address rename. When this happens, the spare server is halted, reconnected to the primary server's boot disk, and started up as the new active server.
In server configurations using I/O virtualization, servers on which a server OS is operating can be used for spare servers.
If a primary server fails and its spare server boots from a SAN, the OS of the spare server will be stopped. After that the boot disk is connected to the spare server using I/O virtualization, and the server started.
Figure 9.4 Configuration Using a Server on which a Server OS is Operating as a Spare Server
Note
A spare server cannot be shared by a local boot server, a SAN boot server, and an iSCSI boot server.
Furthermore, if the primary server is a local boot environment, the same server cannot be used as a spare server between the configurations 1 and 2 shown below.
In a SAN data environment using a physical WWN or VIOM
When using the Red Hat Enterprise Linux 6 ext4 file system
Spare server configuration for booting from SAN storage servers (using storage management software)
Storage management software should be set aside for servers in SAN boot environments.
When a primary server fails, changing the following configuration using storage management software enables access and startup from the same boot disk. A spare server can be shared by multiple primary servers.
Zoning settings for the Fibre Channel switches connected to servers
Host affinity settings for storage CAs
