Host failure recovery

Power Virtual Server is built on the IBM Power enterprise infrastructure with redundant networking and storage area network (SAN) fabric capabilities. IBM Power Virtual Server 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, you must manually recover the failed host.

The host failure recovery process restarts VSIs on a different available host. This process completely reboots the operating system. After the operating system restarts, you must restart your applications according to your standard boot procedures.

The automated remote restart feature enables host failure recovery by default for all VSIs in the Power Virtual Server environment. To disable this feature, you can set Automated remote restart to off during VSI creation. Alternatively, you can modify 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 VSIs to specific hosts results in extended downtime because recovery depends on the time required to repair the failed host. To minimize downtime, ensure that VSIs are not pinned to a host. For more information, see Virtual server pinning and its impacts on VSI availability.

• 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 remain on the same host. A hard-pinned VSI prevents VSIs in 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 (VSNs) for IBM i. Check your independent software vendor (ISV) licensing policy to determine whether VSNs are appropriate.

PowerHA SystemMirror for AIX Standard Edition

PowerHA SystemMirror for AIX Standard Edition is available with a monthly subscription model. 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 create the virtual servers that are part of the PowerHA SystemMirror cluster. Selecting Different Server ensures that the different logical partitions (LPARs) in 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 servers that are part of the PowerHA SystemMirror cluster.

• You do not have access to the HMC, VIOS, and host system on Power Virtual Server. Therefore, 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 ROHA functions. For more information about configuring and using ROHA with Power Virtual Server, see Resource Optimized High Availability in Cloud.

Licenses that are purchased outside a subscription model are not eligible for use with Power Virtual Server.

Disaster recovery mechanisms

You can use Geographic Logical Volume Manager (GLVM) replication to implement disaster recovery between two AIX VSIs that are deployed in separate IBM Cloud data centers. For a complete tutorial, see AIX Disaster Recovery with Power Virtual Server.

You can tune the Transmission Control Protocol (TCP) to improve wide area network (WAN) connection performance between AIX virtual machines. For more information, see TCP tuning for AIX WAN connections.

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 the configuration data that is needed to rebuild a pod. The configuration data includes the virtual machine configurations and private cloud image repositories. However, you are responsible for backing up and restoring client data and client OS images.

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 require significant processing power and network bandwidth. As a result, you can submit only one import or export request at a time. Any additional import or export requests are queued. Typically, you import or export system disks (AIX rootvg disks) that are less than 1 TB to facilitate the transfer to and from Cloud Object Storage. If your image is greater than 1 TB, the transfer might take longer and is more likely to fail or time out. The maximum uncompressed image that you can import or export is 10 TB.