High availability features

Edit online

This section describes the features that are available in the HADR type of deployment of the IBM® VM Recovery Manager DR for Power Systems solution and HADRHA type of deployment of the IBM VM Recovery Manager DR for Power Systems.

The high availability features are available across sites, and within the same site. For example, you can back up a failed virtual machine and restart a virtual machine within the same site, or move the failed virtual machine to other site. The failover operations for disaster recovery can be performed from one site to another site.

VM Recovery Manager DR high availability features for HADR type of deployment

The important high availability features of the HADR type of deployment of the VM Recovery Manager DR solution includes the following features:
  • Live Partition Mobility (LPM) support within site
  • Support for VM failure and host failure within site
  • Application failover support within site
  • Fibre Channel (FC) adapter failure within site
  • Network adapter failure within site
  • Monitoring CPU and memory usage within site
  • Move operation and failover rehearsal operation across site and within a site
  • Disaster recovery support from one site to another site

VM Recovery Manager DR high availability features for HADRHA type of deployment

The important high availability features of the HADRHA type of deployment of the VM Recovery Manager DR solution includes the following features:
  • Live Partition Mobility (LPM) support both in home site and backup site
  • Support for VM failure and host failure in both home site and backup site
  • Application failover support in both home site and backup site
  • Fibre Channel (FC) adapter failure within site
  • Network adapter failure within site
  • Monitoring CPU and memory usage within site
  • Move operation and failover rehearsal operation across the site
  • Disaster recovery support from one site to another

File system usage monitoring

You can configure a specific LPAR and VIOS such that during each discovery operation, the KSYS subsystem fetches the size of the VIOS file system and the current file system usage in the VIOS. When the percentage of file system usage reaches the threshold value of 80%, the KSYS subsystem notifies you with a warning message so that you can make necessary updates to the VIOS file system.

The host monitor monitors the following file systems: /, /tmp, /usr, /var, /home. When the KSYS subsystem requests for the file system usage details, the host monitor responds with the details about the file system usage, which includes information about each file system and its usage. An event is generated when the file system usage surpasses the threshold value of the file system usage, also an event is generated when the file system usage moves under the threshold value.

Configuring network isolation events

The KSYS subsystem uses the network isolation feature to configure the VIOS netmon file, which is used by IBM Reliable Scalable Cluster Technology (RSCT) to monitor the network status. The KSYS subsystem generates the NETWORK_ISOLATION_SUCCESS and the NETWORK_ISOLATION_ERROR events depending on whether the configuration of the VIOS netmon file succeeded. You can use the ksysmgr command to configure the IP addresses for the VIOS netmon file. After the discovery operation completes, the KSYS subsystem checks the configured IP addresses at site remote copy program (RCP) and generates a put message request for the host monitor to configure the VIOS netmon file. To add the IP addresses for network isolation detection feature, run the following command:
ksysmgr modify system network_isolation=[IP1,IP2,IP3|ALL] action=add
To delete the IP addresses from the network isolation detection features, run the following command: 
ksysmgr modify system network_isolation=[IP1,IP2,IP3|ALL] action=delete

Automatic replacement of repository disk

The HADR and HADRHA types of deployment of the VM Recovery Manager DR solution supports automatic replacement of the repository disk. To automatically replace the repository disk, you must provide the details about the backup repository disk. A maximum of six backup repository disks can be added for automatic replacement. When the storage framework detects failure of a repository disk, the KSYS subsystem sends an event notification. Then, the KSYS subsystem searches each disk on the backup repository list and locates a valid and active backup repository disk, and replaces the failed repository disk with the backup repository disk without any interruption. The failed repository disk will then be placed as the last backup repository disk in the backup repository disk list. The failed backup repository disk can be reused after the disk failure is fixed and it becomes valid and active.