VM Recovery Manager HA & DR for Power Systems Version 1.7
- Support for Shared Processor Pool:
VM Recovery Manager HA and DR enhanced to restart VMs using the capacity from shared processor pool. User can specify the shared processor pool map between sites using the ksysmgr command. Mapping table exist at the granularity of VM level. VM Recovery Manager uses mapping entries during validation, move, failover rehearsal and recovery operations. While creating VM at target site, KSYS gets the pool details from mapping table and restart the VM accordingly using resources from shared processor pool at given site.
ksysmgr modify vm vm1 mappings=poolmap sites=Site1,Site2 Site1=Pool1 Site2=Pool2 policy=add
- Recovery with reduced SAN configuration on DR site
VM Recovery Manager 1.6 released Phase 1 of reduced SAN configuration feature, where each of the disk must have redundant path at production site to ensure all disks mapped to VM at backup site. With 1.7 release, disks need not have redundant paths on production site, in which case VMRM still ensures all disks with atleast one path is available at target site.
This feature will be useful, when few of the ports are not available at target site.As shown in the picture, VM is having two paths on source site through VIOS1. Here VM has two NPIV adapters and each one would be handled by a different FC adapter at VIOS1. If user says to perform DR move with reduced paths having 1 path at target site, then VM would come up using a single adapter at target site.
Even if paths are not redundant at source site, VMRM ensures all unique disks are still mapped to VM at target site with at least one path during DR restart operations.
Command to set number of paths to 1
ksysmgr modify system min_redundancy_paths=1
When path is set to 1, VM will restarted on backup site, if at least on NPIV adapter can be successfully configured with target disks access.
- KSYS native HA:
VM Recovery Manager introduced clustering for KSYS. Two node KSYS cluster can be created with ksysmgr cli. VM Recovery Manager allows all operations from master or Group Leader node. One of the cluster node becomes master automatically. When current master node fails, another existing node will be selected as master node and operations are allowed from the new master node.
Fig 2: KSYS HA
As shown in Fig 2, both KSYS1 and KSYS2 connect to all VM Recovery Manager resource. In case of HA, after master transition during KSYS1 node failures, auto-restart operation continues from new master node KSYS2.
For DR operations, user needs to initiate command again from the new master node KSYS2, when KSYS1 fails. KSYS2 completes operation gracefully by considering previously initiated activities from KSYS1 node.
Command to create 2 node KSYS cluster:
ksysmgr add ksyscluster test_cluster ksysnodes=KSYS1,KSYS2 sync=yes
Here KSYS1 and KSYS2 DNS names need to be given.
- WorkGroup level Site specific vLAN/vSwtich mapping:
Previously site specific vLAN/vSwitch mappings can be given at the granularity of Site, Host Group and host. To support vLAN/vSwitch mappings at the granularity of VM, Workgroup level mappings introduced in 1.7 release.
ksysmgr modify work_group workgroup1 network=vlanmap sites=site1,site2 site1=1 site2=5
- NPIV disk mapping view:
VM Recovery Manager DR enhanced to show NPIV disk mappings at the target VIOS, when VM exist at source site. KSYS initially captures NPIV adapter details at the source site and for all those NPIV adapters, identifies the disk view at target site. This helps to identify whether target configuration is proper or not.
Command and sample output is shown below:
ksysmgr query diskview vm=vm1 targethost=host1
viosname wwpns disk storage_port vios_port
VIOSv1 0xC0507608BD1D0022 60000970000196800573533030333831 0x500009735808F449 fcs0
- VIOS selection during DR:
VM Recovery Manager DR supports VIOS labelling feature. This feature provides capability to host VMs on selected target VIOSes. To use this feature, user needs to create “VIOS labels” on source VIOS of production site and also on target VIOS of backup site. VM Recovery Manager discovers all the details of VM including VIOS labels that are serving VM. During DR operation, preference would be given to those target VIOS, whose VIOS label match with source site VIOSes.
No special configuration is needed at KSYS level to use this feature. VIOS labels need to be created through HMC cli.
- MFA for GUI:
VM Recovery Manager GUI is enhanced to support Multi Factor Authentication.
Fig 3: MFA screen
As shown in the Fig 3, VM Recovery Manager enables additional authentication mechanism through MFA for non-root users. After enabling the MFA, non-root users need to supply OTP after initial authentication is done to login into GUI server.