High Availability and Disaster Recovery options in IBM data center

Host failure recovery

Power Virtual Server is built on the IBM Power enterprise infrastructure with redundant networking and storage area network (SAN) fabrics capabilities. IBM Power Virtual Server continuously monitors your infrastructure to ensure that hosts are responsive and operating correctly.

When a host fails unexpectedly, the virtual server instances (VSIs) on the failed host are automatically restarted on another available host. In some cases, manual recovery of the failed host is required.

The host failure recovery process involves restarting the VSIs on alternate hosts and results in a complete reboot of the operating system. After the operating system is rebooted, the applications must be restarted to recover and resume as per your standard boot procedures.

Host failure recovery is enabled by default for all VSIs in the Power Virtual Server environment through the automated remote restart feature. You can disable automated remote restart for a VSI by modifying the settings on the Virtual server instance details page. For more information, see Disabling automated remote restart for a VSI.

Host failure recovery:

• Does not restart a pinned VSI. Pinning virtual server instances to specific hosts results in extended downtime because the recovery depends on the time taken to repair the failed host. To minimize downtime, ensure that VSIs are not pinned to a host. For more information, see What does VSI pinning do?.

• Does not restart a VSI in a server placement group that uses an affinity policy and includes other VSIs that are hard-pinned to the host. Affinity policies require all VSIs in the group to stay together on the same host. A hard-pinned VSI prevents the group from moving to another host.

• Restarts the VSI on another host with a different physical serial number. If your software depends on serial numbers, consider using virtual serial numbers (VSN) for IBM i, depending on your independent software vendor (ISV) licensing policies.

PowerHA SystemMirror for AIX Standard Edition

You can use a monthly subscription model when you purchase PowerHA SystemMirror for AIX Standard Edition. For more information, see Standard Edition monthly pricing options.

After you purchase the software, you can download it from Entitled Systems Support (ESS). You can install PowerHA SystemMirror for AIX on the virtual server that is running in your Power Virtual Server environment. For installation instructions, see Installing PowerHA SystemMirror.

Review the following information for implementing PowerHA SystemMirror for AIX in your Power Virtual Server environment.

• Select Different Server from the Colocation Rules field when you are creating the virtual servers that are part of the PowerHA SystemMirror cluster. Selecting Different Server ensures that the different logical partitions (LPARs) that might be a part of the PowerHA SystemMirror cluster are not deployed on the same host.

• Select On from the Shareable field when you create storage volumes for the virtual severs that are part of the PowerHA SystemMirror cluster.

• You do not have access to the HMC, VIOS, and the host system on Power Virtual Server. Therefore, any PowerHA SystemMirror functions that require access to these capabilities, such as Resource Optimized High Availability (ROHA) and Active Node Halt Policy (ANHP), are not available. However, PowerHA SystemMirror 7.2.6 SP1 or later versions support Resource Optimized High Availability (ROHA) functions. For more information about configuring and by using ROHA with Power Virtual Server, see Resource Optimized High Availability in Cloud

Licenses that are purchased outside a subscription model license are not eligible to be used in the Power Virtual Server.

Disaster recovery mechanisms

You can implement a disaster recovery mechanism between two AIX VSIs that are installed on separate IBM Cloud data centers by using GLVM replication. For a complete tutorial, see AIX Disaster Recovery with IBM Power Virtual Server. The Transmission Control Protocol (TCP) helps in tuning to improve wide area network (WAN) connection performance between AIX virtual machines. For more information, see IBM support.

You can implement disaster recovery mechanisms between two IBM i VSIs by using PowerHA geographic mirroring. For a complete tutorial, see IBM i Disaster Recovery with IBM Power Virtual Server.

Business Continuity through backup and restore

Client location Your application configuration and data are not backed up automatically. To recover from a disaster, IBM backs up your configuration data that is required to rebuild a pod. The configuration data includes the virtual machine configurations and private cloud image repositories. However, backup and restoration of client data and client OS images is your responsibility.

IBM data center Your Power Virtual Server configuration and data are not backed up automatically. You can back up your virtual server to Cloud Object Storage as explained in Backup strategies for Power Virtual Server. You can also restore your virtual server in case a critical failure occurs.

Importing and exporting images requires a considerable amount of processing power and network bandwidth. As a result, you can submit only one import or export request before it is queued. Typically, users import or export system disks (AIX rootvg disks) that are smaller in size (less than 1 TB) to facilitate the transfer to and from Cloud Object Storage. If your image size is greater than 1 TB, your transfer might take a long time and be prone to failure. The maximum uncompressed image size that you can import or export is 10 TB.