VM Recovery Manager - IBM · VM Restart HADR solutions PowerHA SystemMirror for Linux PowerHA...
Transcript of VM Recovery Manager - IBM · VM Restart HADR solutions PowerHA SystemMirror for Linux PowerHA...
VM Recovery ManagerHA & DR for IBM PowerVM LPARs
Michael Herrera
Certified IT Specialist - HA & DR SME
IBM Washington Systems Center
Power Systems Virtual User Group 2019
YouTube: https://www.youtube.com/user/MrPowerHA/videos
@Herrera_HADR
Session Objectives
— VM Recovery Manager Offerings in 2019
• Product Positioning
— VM Recovery Manager for HA• Product Use Cases
• Deployment Requirements
• Architectural requirements & Solution Design
— VM Recovery Manager for DR• Product Use Cases
• Deployment Requirements
• Architectural requirements & Solution Design
— Upcoming Features in V1.4 – Q4 2019
KSYSCLI or GUI
Administration
HA
DR
1.2 Beta
Oct
2017
1.3 Product Beta
• Support for P7+, P8, P9
• Graphical & CLI management
• LPM Management
Automated End-to-End management:
• Host, VM, & App Level HA
• Application start sequence mgmt
Jun
2017
GDR Release 1.1.0.1
Dec
2018
• HA or DR deployments support
• Hitachi TrueCopy management
• Failover Rehearsal support for
Hitachi storage
Nov
2018
• Expanded storage
support:
✓ SVC/Storwize:
Sync,Async
✓ DS8K Async
✓ EMC Sync
• IBM i Guest VM
• Boot list mgmt
• Host Group DR
• Failover
Rehearsal
VMR DR Release 1.3
Sept
2018Dec
2017
GDR Release 1.2
• Advanced DR policies (Host Groups)
• DR Failover Rehearsal
• Hitachi HUR replication support
• Flex Capacity Management
• VLANs, vSwitches per Site
Advanced Policies:
• Flex Capacity Management
• Collocation / Anti-collocation
• Priority Based Failovers
• Host Blacklisting
HA agents for key middleware:
• DB2, Oracle, SAP HANA
VMR HA Release 1.3
VM Recovery Manager Offering – Product Evolution
June
2019
SP2
SP2
PowerHA SystemMirror
for AIX
Cognitive Systems HADR
VM Restart HADR solutions
PowerHA SystemMirror
for Linux
PowerHA SystemMirror
for IBM i
VM Recovery Manager
HA
VM Recovery Manager
DR (GDR)
Suited for
• Protecting mission critical workloads that
require quick recovery - Platinum Tier
• Advanced HA solutions (eg: HyperSwap)
• Storage and network management
• Automated Disaster Recovery
Suited for
• Cloud environments – Gold, Silver Tier
• Multi OS simplified HADR management
• Protecting few to large number of LPARs
• Optimized capacity deployments (no 1 to 1 backup)
5765-H39 Std. Edition
5765-H37 Ent. Edition
• Supported on all Power
servers
• Premier clustering
solution for AIX workloads
on Power for 25+ years
• Tightly coupled with
Cluster Aware AIX
• Enterprise Edition
available for Automated
DR functionality (IP &
Block Level replication
integration)
5765-L22 Std. Edition
• Supported on Power 8
and later servers
• SUSE & SLES Support
• Integrated support for
SAP HANA & NetWeaver
• New Shared User
Interface with AIX
PowerHA clusters
5765-DRG
• Supported on Power 7 and
later servers
• VM Restart across sites for
virtualized AIX, IBM i & Linux
VMs
• Leverages Block level
replication of OS & data
volumes
• Supports IBM, EMC & Hitachi
block level replication as well
as shared storage model
• Simple to deploy & use DR
management
5765-VRM
• Supported on Power 7+ and
later servers
• VM Restart among local
hosts for virtualized AIX, IBM
I & Linux VMs
• Provides Host level, VM level
and application level
monitoring
• LPM Management
• New User Interface for
deployment & management
operations
5770-HAS Std. Edition (opt 2)
5770-HAS Ent. Edition (opt1)
• Supported on all Power
servers
• Premier clustering
solution for IBM i
workloads on Power for
10+ years
• Enterprise Edition offering
is the primarily used
solution for HA mirroring
between Power Systems
Cluster HADR solutions
HA & DR Solutions for Cognitive Systems (PowerVM based Servers)
VM Failure
Detection
Host
Failure
Detection
VM Placement
Scheduling
Single-
Site/HAMulti-Site/DR
Application
Monitoring*
Automated
Initiation
HMC/NovaLink No Limited No Yes No No No
PowerVC No Limited Yes Yes No No Limited
VMR HA | DR (K-sys) Yes * Comprehensive Yes Yes Yes Yes * Yes
*: Available for AIX & Linux VMs with installed agent
HMC
PowerVCLPM
Automation
Tool
Client
Managed Systems
KSYS
VM Recovery Manager – HA Solution:
1. Host Level failure
2. VM Level Failure
3. Application Level Failure
NovaLink
VMR-DR
VMR-HA
VM Recovery Manager vs. Other VM Management Offerings
LP
M &
Rem
ote
Resta
rt C
apabili
ties Managed VM
Managed VM
Managed VM
Managed VM
LP
M &
Rem
ote
Resta
rt Capabilitie
s Unmanaged
Unmanaged
Unmanaged
Ho
st
Gro
up
AH
ost
Gro
up
B
Host Pair 1
Host Pair 2
KSYS
Disk Group
Primary SecondaryD
isa
ste
r R
eco
ve
ry M
od
el
HA
VM
Re
sta
rt M
od
el
Managed VM
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
KSYSVMR-HA
VMR-DR
Host Group
VM
VM
VM
VM
VM
VM
VIO
VIO
VIO
VIO
LPM & Remote Restart Capabilities
HMCs
Shared SAN Storage
Expand up to 12 hosts per Host Group
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
Block Level Replication
Pro
du
ct ID
–5
76
5-D
RG
Pro
du
ct ID
–5
76
5-V
RM
LP
M &
Rem
ote
Resta
rt C
apabili
ties Managed VM
Managed VM
Managed VM
Managed VM
LP
M &
Rem
ote
Resta
rt Capabilitie
s Unmanaged
Unmanaged
Unmanaged
Ho
st
Gro
up
AH
ost
Gro
up
B
Host Pair 1
Host Pair 2
KSYS
Disk Group
Primary Secondary
KSYS
VM
VM
VM
VM
VM
VM
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
LPM & Remote Restart Capabilities
HMCs
Shared SAN Storage
Dis
aste
r R
eco
ve
ry M
od
el
HA
VM
Re
sta
rt M
od
el
Managed VM
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VMR-HA
VMR-DR
Host Group
Pro
du
ct ID
–5
76
5-D
RG
Pro
du
ct ID
–5
76
5-V
RM
KSYS
VM
VM
VM
VM
VM
VM
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
LPM & Remote Restart Capabilities
HMCs
Shared SAN Storage
HA
VM
Resta
rt M
ode
lVMR-HA
Host Group A
VM
VM
VM
VM
VM
VM
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Shared SAN Storage
Host Group B
VM
VM
VM
VM
VM
VM
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VM
VM
VM
VM
VM
VM
VM
VM
VM
Shared SAN Storage
Host Group C
(Local D
ata
Cente
r)
IBM Knowledge Center states
4 Host Group maximum when
using VMR HA
* That is a testing statement
VIO 1
VIO 2
VIO 1
VIO 2
KSYS VM
Unmanaged
Unmanaged
HMC
Host 1: S824 Host 2: S922 Host 3: E980
Repository LUN
HA LUN10 GB
10 GB
Same (2) LUNs
shared across all
VIO servers in HG
VMR SSP Cluster
[ 1 ] LPM Management ➔ LPM Individual VMs or Evacuate Managed VMs from Host & Return to Homehost
[ 2 ] VM Restart Capability ➔ Restart Offline or Failed VMs on new host (Independent of Simplified Remote Restart)
Unmanaged
Unmanaged
HMC
VMR_oraDB
Host
Gro
up
PHA_VMR_node1 PHA_VMR_node2
CLI or GUI
Administration
VMR-HA
VMR HA: Graphical User Interface
Migration Operations
# ksysmgr lpm vm <vm1>[,vm2,..] to=<hostname>
or
# ksysmgr lpm vm <vm1>[,vm2,..] to=<hostname> action=validate
LPM individual VM/s
LPM Validation only
# ksysmgr lpm host <hostname> to=<hostname>
or
# ksysmgr restore host <hostname>
Migrate all Managed VMs off host
Restore all Managed VMs to Homehost
LPM Operations
from the KSYS
controller CLI
LPM Operations
at Host Level
from the KSYS
GUI Interface
VMR HA: LPM Host Evacuation (All VMs | Individual VMs)
Migration Operations
# ksysmgr lpm host ATS-S824-8286-42A-SN2170AAV to=ATS-S922-9009-22A-SN7811D90 Migrate all Managed VMs to target host
VMR HA: KSYS VM Relocation Plans [ Host or VM Level ]
Relocation
Plan Report at
Host Level
Relocation
Plan Report
at VM Level
VMR HA : VM Restart Actions
VM Manual Restart Operations
# ksysmgr restart vm <vm1>[,vm2,..] to=<hostname> Relocate & Restart Managed VM/s
# ksysmgr restart host <hostname> to=<hostname> Relocate & Restart ALL Managed VMs in a host
Remote Restart
Operations from
KSYS CLI
Remote Restart
Operations from
KSYS GUI
VIO 1
VIO 2
VIO 1
VIO 2
KSYS VM
Unmanaged
Unmanaged
HMC
Host 1: S824 Host 2: S922 Host 3: E980
Repository LUN
HA LUN10 GB
10 GB
Same (2) LUNs
shared across all
VIO servers in HG
VMR SSP Cluster
[ 1 ] LPM Management ➔ LPM Individual VMs or Evacuate Managed VMs from Host & Return to Homehost
[ 2 ] VM Restart Capability ➔ Restart Offline or Failed VMs on new host (Independent of Simplified Remote Restart)
[ 3 ] Host Failure ➔ Automated VM Restart of Managed VMs or Notification if set to Advisory mode
Unmanaged
Unmanaged
Other Tools deliver
similar functionality
HMC
VMR_oraDB
Host
Gro
up
PHA_VMR_node1 PHA_VMR_node2
CLI or GUI
Administration
VMR-HA
VMR HA: What if I don’t want Automatic Restarts ?
The default behavior is for VMs to be automatically restarted on host failure
VIO 1
VIO 2
VIO 1
VIO 2
KSYS VM
Unmanaged
Unmanaged
HMC
Host 1: S824 Host 2: S922 Host 3: E980
Restart Automatically Locally or on next available host within VMR HA Host Group
Repository LUN
HA LUN10 GB
10 GB
Same (2) LUNs
shared across all
VIO servers in HG
VMR SSP Cluster
[ 1 ] LPM Management ➔ LPM Individual VMs or Evacuate Managed VMs from Host & Return to Homehost
[ 2 ] VM Restart Capability ➔ Restart Offline or Failed VMs on new host (Independent of Simplified Remote Restart)
[ 3 ] Host Failure ➔ Automated VM Restart of Managed VMs or Notification if set to Advisory mode
[ 4 ] VM Failure ➔ Individual VM Level Monitoring for AIX & Linux only
[ 5 ] Application Failure ➔ Included Agents for SAP HANA, Oracle, DB2, Postgres or framework for Custom Applications
Unmanaged
Unmanaged
Other Tools deliver
similar functionality
Differentiating
Features for AIX &
Linux VMs
HMC
VMR_oraDB
Host
Gro
up
PHA_VMR_node1 PHA_VMR_node2
Oracle Agent
Custom User Defined Scripts
CLI or GUI
Administration
VMR-HA
VMR_oraDB2
VIO 1
VIO 2
VIO 1
VIO 2
KSYS VM
Unmanaged
Unmanaged
HMCHost 1: S824 Host 2: S922
Host 3: E980
Host
Gro
up
Repository LUNHA LUN10 GB 10 GBVMR SSP Cluster
PHA_VMR_node1 PHA_VMR_node2
HMC
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
CLI or GUI
Administration
Failure Scenarios:
• Host Failure ( AIX | Linux | IBM i VMs )
• VM Failure Detection (Agent Installed on AIX or Linux VMs)
• Application Failure Detection (Agent Installed on AIX or Linux VMs)
VMR_oraDB2
PHA_VMR_node1
ora_app
custom_app1
VMR HA : Recap of Levels of Protection
What is the VM Agent installing inside the VM ?
Agents provided for SAP HANA,
DB2, Oracle & Postgres but
users can define their own to
monitor any other applications
Command specific to VMM
functionality only in VMs
Daemon will be
automatically started
upon installation
Attribute Oracle DB2 SAP HANA
TYPE ORACLE DB2 SAPHANA
version Taken from application Taken from application Taken from application
instancename Oracle user DB2 instancename SAP HANA instancename
database Oracle SID DB2 database SAP HANA database
Sample Scripts will be used automatically when ksvmmgr app is defined specifying the TYPE:
start_script* /usr/sbin/agents/oracle/startoracle /usr/sbin/agents/db2/startdb2 /usr/sbin/agents/sap/startsaphana
stop_script* /usr/sbin/agents/oracle/stoporacle /usr/sbin/agents/db2/stopdb2 /usr/sbin/agents/sap/stopsaphana
monitor_script* /usr/sbin/agents/oracle/monitororacle /usr/sbin/agents/db2/monitordb2 /usr/sbin/agents/sap/monitorsaphana
Specific parameters for built-in supported application agents :
VMR HA: Details on Included Application VM Agent scripts
*** Table doesn’t reflect the Postgres scripts
Oracle VM Configuration Steps
# ksysvmmgr add app <appname> type=ORACLE instancename=<oracle_username> database=<database_name>
# ksysvmmgr sync
# ksysvmmgr –s add app ora_app type=ORACLE instancename=oracle database=vrmrsd
or
# ksysvmmgr –s add app ora_app type=ORACLE instancename=oracle database=vrmrsd critical=yes
Oracle Agent
Enablement
VM Agent: Application Monitoring Enablement within VM
Other Included Agents and Custom Application Configuration
# ksysvmmgr –s add app <name> type=SAPHANA instancename=<HANAinstancename> critical=yes
# ksysvmmgr –s add app <name> type=DB2 instancename=<DB2instancename> critical=yes
# ksysvmmgr –s add app <name> type=POSTGRES instancename=<POSTGRESinstancename> critical=yes
# ksysvmmgr –s add app <name> start_script=<name> stop_script=<name> monitor_script=<name> critical=yes
SAP HANA
Enablement
Sample Syntax
* The “critical” option is not set by default.
It will attempt to restart the VM 3 times and
then attempt on the next available host
DB2
Enablement
Postgres
Enablement
Custom
Application
VMR HA: Oracle VM Agent GUI View
The application status value GREEN
indicates a stable application. The YELLOW
value indicates an intermediate state of
application in which the application is
attempted to be restarted. The RED value
indicates permanent failure of an application
VMR HA : Enablement of VM Level & Application Level Monitoring
Step 1 : Install Agent in VM
Step 1a) Configure Application Definition with provided | custom agent
Step 2 : Enable HA Monitoring for VM
Step 3 : Re-Run Discovery
VMR HA : Failure Detection Tuning & Collocation Policies
1. Will VMR HA restart VMs if the PowerVM SRR flag is not set for them ?
2. Will IBM i VMs get automatically started in the event of a VM failure ?
3. How does the implementation time change based on the number of servers ?
4. Can / should I replace my HA clusters with VMR HA ?
Common Questions
Yes, it does not use the same profile configuration store. It already stores the configuration for
the managed VMs on the KSYS VM.
The VM agent packages are only available for AIX & Linux today. They allow the KSYS to do
additional monitoring at the VM level or the application level.
The discovery process may take a little bit longer but unlike clustered environments there is no
special customized set up or actively running standby LPARs.
True ”Mission Critical workloads” are typically better suited with a cluster configuration.
CLI or GUI
Administration
VM Recovery Manager for HA: Deployment Requirements
KSYS Controller:
• (1) VM running AIX with 1CPU and 8GBs of memory
Hardware Management Console (HMC):
• (2) HMCs for redundancy – Version 9.1.1 and on
Servers:
VIO Server/s & SSP Cluster:
• (2) VIOs per Host - Version 3.1.0 and on
• (2) 10GB LUNs shared across all involved VIO servers / Host Group
*** Recommend additional 0.5 core and 2 GB memory on top of the VIOS sizing planned for the environment
Storage:
• Shared Storage configuration (NPIV or VSCSI)
• LUNs & zoning must be configured to provide LPM capabilities
KSYS LPAR
VIO 1
VIO 2
P7+ • FW770.90 or later’
• FW780.70 (except 9117-MMB models)
• FW783.50 or later
P8 • FW 840.60 or later
• FW 860.30 or above
P9 • FW910 or later
10 GB 10 GB
VM Recovery Manager HA is included in AIX Enterprise Cloud Edition
• VMR HA is installed on an AIX partition that
provides the KSYS cluster functionality. The
KSYS cluster is configured as type “HA”
• KSYS is the Orchestrator that will act on the VMs
containing the managed cores in the host group
• The default behavior is for automated VM restart
on Host failure. Advisory mode may be enabled.
• Admin moves the VMs via LPM or via restart to
another system in the VMR HA host group
• There can be up to 12 systems in the host group
and up to ~ 300 VMs can be managed by KSYS
Scenario #1:
(6) Managed VMs consuming 10 processors
On Scale-out server: (500 x 10 = $5000)
On Scale-up server: (800 x 10 = $8000)
Scenario #2:
(4) Additional VMs consuming 8 processors
On Scale-out server: (+ $4000)
On Scale-up server: (+ $6400)
VMR HA
KSYS
AIX
Unmanaged
Unmanaged
AIX
Linux
Linux
Linux
Linux
Unmanaged
Ma
na
ge
d V
Ms AIX
Linux
Linux
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Ma
na
ge
d V
Ms
IBM i
New
ly c
rea
ted
VM
s
Host Group
VM Recovery Manager for HA [PID 5765-VRM ] – Licensing Scenario
VM Recovery Manager HA- High Availability -
VM Recovery Manager DR- Disaster Recovery -
Product ID • 5765-VRM • 5765-DRG
Solution Type • High availability within one site • Disaster Recovery across sites
Auto Restart Capabilities
• Automated or Manual ”Advisory mode” restart1. Host failures2. VM Failures (VM agent needed)
3. Application failures (VM agent needed)
• Manual restart (admin initiated automation)
Storage Support • Shared storage based solution• Block Level Replication management• Site management• Shared storage configuration support
Capacity Management• Flex Capacity management, Best fit relocation• Enterprise pool management tool
Restart order • Priority based relocation
Application HA management
• Application restart sequencing (within VM or across VMs-future)
• HA agents for common middleware (DB2, Oracle, SAP HANA)
• Same support possible if HA is also deployed
Advanced VM policies• Collocation and anti collocation• Host exclusion/blacklist for VM relocation
• Future
Planned HA management(LPM)
• Vacate a host for maintenance• Restore VMs to the original host
• Not applicable
Graphical User Interface • Available for deployment & management • Available in V1.3.0 SP2
VM Recovery Manager HA vs. DR Comparison
DataData
VM
VIO
VIO
OS Data
VIO
VIO
Primary Data Center
LPM & Remote Restart Capabilities
Remote Restart Capabilities
• Manual or Automated
• Single OS instance (Same shared storage)
• Localized within same Site
• Flat Network
Primary VM
VIO
VIO
OS Data
VIO
VIO
LPM & Remote Restart CapabilitiesClustered VMs
• Automated Fallover
• Independent OS volumes for each VM
• Shared Data Volumes
• Truly “Mission Critical” workloads
Standby VM
OS
DataData
Primary VM
VIO
VIO
OS Data
VIO
VIO
LPM & Remote Restart Capabilities
Standby VM
OS
Secondary Data Center
DataDataData
VIO
VIO
Standby VM
OS
Automated IP or Block Level Replication
DR Clustering with Automated Fallover:
• Integrate with IP or Block Level Replication
Traditional Mobility & HA / DR Clustered Configurations
Can Automate these functions with VMR HA
VM
VIO
VIO
OS Data
VIO
VIO
Primary Data Center Secondary Data Center
VM
VIO
VIO
OS
VIO
VIO
Block Level Replication of OS & Data Volumes
KSYS
Data OS Data
Environment Specs:
• Different Network Segments
• Different Storage Enclosures
• Can I use replication & do this manually with separate profiles?
• What if I had to do this at scale?
HMC HMCVM
VM
VM
VM
VM
VM
VM
Why not Replicate & Relocate the VMs to a Remote Site myself ?
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Inactive
Profiles
VMR-DR
LP
M &
Re
mo
te R
est
art
Ca
pa
bil
itie
s Managed VM
Managed VM
Managed VM
Managed VM
LP
M &
Re
mo
te R
esta
rt Ca
pa
bilitie
s
Unmanaged
Unmanaged
Unmanaged
Ho
st
Gro
up
AH
os
t G
rou
p B
Host Pair 1
Host Pair 2
KSYS
Primary Datacenter Secondary Datacenter
VM
R D
R –
Sit
e R
ec
ove
ry M
od
el
Managed VM
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VMR-DR
KSYS
VM
VM
VM
VM
VM
VM
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
Local Datacenter
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
LPM & Remote Restart Capabilities
HMCs
Shared SAN Storage
VM
R H
A –
VM
Re
sta
rt M
od
el
VMR-HA
Block Level Replication
How does VMR for DR compare to a PowerHA Enterprise Edition Cluster ?
DataData
Primary VM
VIO
VIO
OS Data
VIO
VIO
LPM & Remote Restart Capabilities
Standby VM
OS
Secondary Data Center
DataDataData
VIO
VIO
Standby VM
OSAutomated Site
Fallover of the
Workload
Primary Data Center
DataData
Managed VM
VIO
VIO
OS Data
VIO
VIO
LPM & Remote Restart Capabilities
VIO
VIO
KSYS LPARVMR-DR
DataDataData DataDataDataSync or Async IP or Block Level Replication of Data LUNs
DataDataOS Data DataDataOS DataSync or Async Block Level Replication of OS & Data LUNs
User Initiated
Planned or
Unplanned
VM Moves
Po
we
rHA
En
terp
ris
e E
dit
ion
Clu
ste
rV
M R
ec
ove
ry D
R S
olu
tio
n
DR Managed
DR Managed
UnmanagedHo
st
Gro
up
AHost Pair 1
Primary Site Secondary Site
Disk Group
DR Managed
VIO
VIO
DR Managed
DR Managed
Unmanaged
Unmanaged
Ho
st
Gro
up
B
Host Pair 2
VIO
VIO VIO
VIO
VIO
VIO
Disk Group
DR Managed
DR Managed
Unmanaged
Unmanaged
Ho
st
Gro
up
C
Host Pair 3
VIO
VIO VIO
VIO
Disk Group
HMCs HMCs
VM Recovery Manager DR: Solution Overview
Product Use Cases:
• Planned DR [ Site | Host Group Level ]
• Unplanned DR [ Site | Host Group Level ]
• DR Testing [ Site | Host Group Level ]
KSYS LPARVMR-DR
LP
M &
Rem
ote
Resta
rt C
apa
bili
ties
Managed VM
Managed VM
Unmanaged
Managed VM
Managed VM
Managed VM
Managed VM
LP
M &
Rem
ote
Resta
rt Capabilitie
s
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Host G
roup A
Host G
roup B
Host G
roup C
Host G
roup D
KSYS
Host Pair 1
Host Pair 2
Host Pair 3
Host Pair n
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
# ksysmgr move site from=Primary to=Secondary
Storage
Subsystem 1
Storage
Subsystem 2
Primary Secondary
VM Recovery Manager DR: Site Level Planned Move
VMR-DR
LP
M &
Rem
ote
Resta
rt C
apabili
ties
Managed VM
Managed VM
Unmanaged
Managed VM
Managed VM
Storage
Subsystem 1
Managed VM
Managed VM
Storage
Subsystem 2
LP
M &
Rem
ote
Resta
rt Capabilitie
s
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Ho
st
Gro
up
AH
ost G
roup B
Host G
roup C
Host G
roup D
Host Pair
Host Pair
Host Pair
Managed VM
Managed VM
KSYS
Disk Group 1
Disk Group n
# ksysmgr move host_group <HGA> from=Primary to=Secondary
Primary Secondary
VM Recovery Manager DR: Host Group Level Planned Move
VMR-DR
Unmanaged
Unmanaged
Ho
st
Gro
up
A
Host Pair
Managed VM
KSYS
Primary Secondary
What about an Individual VM level move ?
Managed VM
Unmanaged
# ksysmgr unmanage vm name=<vm1,vm2,vmx>
# ksysmgr discover hg <hgA> verify=true
# ksysmgr move hg <HGA> from=Primary to=Secondary
Sto
rag
e L
ayer
Disk Group Rebuilt Consistency Group
Disk Group
VMR-DR
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
# ksysmgr move host_group <HGA> from=Primary to=Secondary
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
Disk Group Disk Group
LP
M &
Rem
ote
Resta
rt C
apabili
ties
Managed VM
Managed VM
Unmanaged
Managed VM
Managed VM
Managed VM
Managed VM
LP
M &
Rem
ote
Resta
rt Capabilitie
s
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Host G
roup A
Host G
roup B
Host G
roup C
Host G
roup x
Host Pair
Host Pair
Host Pair
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
Primary Secondary
KSYS# ksysmgr move site from=Primary to=Secondary dr_type=unplanned
# ksysmgr cleanup site Primary
VM Recovery Manager DR: Un-Planned Outage Site Move
VMR-DR
Block Level replication
• Host Groups
• Support for Flex Capacity
• Priority Based Restarts
• DR Fallover Rehearsal
• Network Isolation
• Support for Shared Storage
configurationsVM Restart Management w/out mirror management i.e. SVC Stretched Clusters or EMC VPLEX
Increase or Decrease CPU & Memory resources
at the backup site. i.e. Perform DR operation with
fewer resources at the remote site
Ability to perform non-disruptive testing by
leveraging a Flashcopy at the DR site
Additional granularity - ability to perform the move of
only a Host Group instead of an entire Site
Tier VMs in your environment to restart them in a
prioritized order. High | Medium | Low
Enable VLAN based network customization across
Sites. VMs can be brought up on backup Site with
different VLAN and/or different vSwitch configuration
VM Recovery Manager DR: V1.2 Feature Highlights 2017
Primary
VM01 – RHEL 7.5
HANA 2.0 DB
VIO 1
Secondary
VIO 2
VM02 – RHEL 7.5
HANA 2.0 DB
VM03 – RHEL 7.5
App Server
VM04 – SLES 12
HANA 2.0 DB
VM05 – SLES 12
HANA 2.0 DB
VIO 1
VIO 2
KSYS
Managed
Native IP Replication
VM06 – SLES 12
App Server
VM01 – Test Clone
VM02 – Test Clone
VM03 – Test Clone
VM04 – Test Clone
VM05 – Test Clone
VM06 – Test Clone
Isola
ted N
etw
ork
Consistency
Group
Flashcopy
Target LUNs
1. # ksysmgr discover site Primary dr_test=yes
2. # ksysmgr verify site Primary dr_test=yes
3. # ksysmgr move site from=Primary to=Secondary dr_test=yes
……………………… Test Period ………………………….
4. # ksysmgr cleanup site Primary dr_test=yes
1
1
21
-
2
840
VMR-DR
Managed VM
Managed VM
Unmanaged
Managed VM
Managed VM
Managed VM
Managed VM
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Host G
roup A
Host G
roup B
Host G
roup C
KSYSManaged VM
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
Primary Secondary
VMR-DRFeature Highlights:
• Priority Based Restarts
– High, Medium, Low Priorities to control stop &
restart VM order
• Flex Capacity Support
– Lower or Higher CPU & Memory Values
– Provision PEP Activations
• Network Mapping Policies
– VLAN & Vswitch Map for Planned | Unplanned
– VLAN & Vswitch Map for DR Rehearsal
– Sample Scripts to prime VMs on boot
Wait … You skipped past a few other cool features
50% CPU
60% Memory
High Priority
Med Priority
High Priority
50% CPU
60% Memory
50% CPU
60% Memory
Site 1 Site 2 DR Test
VLAN1 VLAN1 VLAN1T
VLAN12 VLAN22 VLAN2T
VLAN13 VLAN23 VLAN3T
VLAN5 VLAN5 VLAN5T
Managed VM
Managed VM
Unmanaged
Unmanaged
Host G
roup D Managed VM
Managed VM
Low Priority
50% CPU
60% Memory
• HA or DR deployment support
• Hitachi TrueCopy management
• XIV / A9000 Replication management
• Cluster KSYS LPAR with PowerHA
• Graphical User Interface
The VMR-DR code base now includes the VMR-HA packages.
Although this release only support the KSYS as type “HA” or type
“DR” be on the lookout for a new cluster type in 2019
Hitachi Synchronous replication support
Ability to create KSYS pair & have it automatically Fallover with
the PowerHA SystemMirror software
Latest release brings the Dashboard view into the UI server
& some of the Administrative controls.
Same UI server will manage VMR HA & VMR DR clusters
VMR for DR: Newest Feature Highlights [ Latest Version 1.3.0.2 ]
XIV / A9000 replication support
Managed VM
VIO 1
Primary Secondary
VIO 2
Managed VM
Managed VM
Managed VM
Managed VM
VIO 1
VIO 2
Managed
Block Level Replication
1
1
21
-
2
840
Managed VM
HMCHMC
KSYS LPAR #1
OS: AIX 7.2.2
PHA: V7.2.3.1
VMR: V1.3.0.2
CPU: 1
Memory: 8GB
OS Disk: 30GB
CAA Disk: 1GB
KSYS #1VMR-DR
KSYS LPAR #2
OS: AIX 7.2.2
PHA: V7.2.3.1
VMR: V1.3.0.2
CPU: 1
Memory: 8GB
OS Disk: 30GB
CAA Disk: 1GB
KSYS #2VMR-DR
PHA Cluster PHA Cluster
KSYS
HA pair
LPAR
User Interface
Administrative
Controls
VMR for HA videos:
YouTube: Video Demonstrations & Education Series
VMR for DR videos: • Concepts
• Requirements
• Deployment
• Demonstration
Clustering the KSYS:
YouTube Channel: https://www.youtube.com/user/MrPowerHA/videos
YouTube: Video Demonstration & Education Series
Introducing VMR DR into an existing environment
Native IP Replication
VM15
VM17
VIO
VIO
VIO
VIO
VM15_AUX
VM17_AUX
Inactive
Profile
Definitions
P ower780
1
24
System
Storage
0 16
1 17
2 18
3 19
S A N 3 2 B - E 4
G E 0
1
1
1
2
1
-
2
840
0 16
1 17
2 18
3 19
S A N 3 2 B - E 4
G E 0
1
VM15 - Consistency Group 1
VM17 - Consistency Group 2
VM15_L1
VM15_L2
VM15_L3
VM15_L4
VM15_L1_AUX
VM15_L2_AUX
VM15_L3_AUX
VM15_L4_AUX
VM17_L1
VM17_L2
VM17_L3
VM17_L4
VM17_L1_AUX
VM17_L2_AUX
VM17_L3_AUX
VM17_L4_AUX
P o w er 740
Our Environment before VMR DR: User Defined Consistency Groups
Native IP Replication
VM15
VM17
VIO
VIO
VIO
VIO
P ower780
1
24
System
Storage
0 16
1 17
2 18
3 19
S A N 3 2 B - E 4
G E 0
1
1
1
2
1
-
2
840
0 16
1 17
2 18
3 19
S A N 3 2 B - E 4
G E 0
1
Ma
na
ge
d
KSYS
Un
ma
na
ge
d
Un
ma
na
ge
d
VMRDG_KSYS - Consistency Group
VM15_L1
VM15_L2
VM15_L3
VM15_L4
VM15_L1_AUX
VM15_L2_AUX
VM15_L3_AUX
VM15_L4_AUX
VM17_L1
VM17_L2
VM17_L3
VM17_L4
VM17_L1_AUX
VM17_L2_AUX
VM17_L3_AUX
VM17_L4_AUX
VM30
VM32
VM35
VM24
VM26
VM28
P o w er 740
Delete Duplicate
Target Profiles
Introducing VMR DR into Environment: VMR Defined Consistency Group
VMR-DR
VM15 - Consistency Group 1
VM17 - Consistency Group 2
VM15_L1
VM15_L2
VM15_L3
VM15_L4
VM15_L1_AUX
VM15_L2_AUX
VM15_L3_AUX
VM15_L4_AUX
VM17_L1
VM17_L2
VM17_L3
VM17_L4
VM17_L1_AUX
VM17_L2_AUX
VM17_L3_AUX
VM17_L4_AUX
VM15_AUX
VM17_AUX
Vie
w o
f G
DR
Consis
tency G
roup
(managing all 6 VMs)
User Actions:• Define the LUNs for the Source VMs• Define Target LUNs & Establish Replication (Sync or Async)• Match zoning between the 2 Sites
KSYS:• Discovery Process will create the Consistency Group encompassing all VMs• Default behavior is to manage all VMs on that Host
VM Recovery Manager DR: LUN Provisioning Steps
VMR Managed VM01
VIO 1
VIO 2
P ower780
1
24
System
Storage
0 16
1 17
2 18
3 19
S A N 3 2 B - E 4
G E 0
1
1
1
2
1
-
2
840
0 16
1 17
2 18
3 19
S A N 3 2 B - E 4
G E 0
1
P o w er 740
vfcs0
vfcs1
vfcs2
vfcs3
Site A - Zones
WWPN-P
WWPN-S
WWPN-P
WWPN-S
WWPN-P
WWPN-S
WWPN-P
WWPN-S
VMR Managed VM02
vfcs0
vfcs1
vfcs2
vfcs3
WWPN-P
WWPN-S
WWPN-P
WWPN-S
WWPN-P
WWPN-S
WWPN-P
WWPN-S
WWPN-P1A
WWPN-P2A
WWPN-P3A
WWPN-P4A
WWPN-P5A
WWPN-P6A
WWPN-P7A
WWPN-P8A
WWPN-P
WWPN-S
WWPN-P
WWPN-S
WWPN-P
WWPN-S
WWPN-P
WWPN-S
WWPN-P
WWPN-S
WWPN-P
WWPN-S
WWPN-P
WWPN-S
WWPN-P
WWPN-S
Storage Controllers A
WWPN-P1B
WWPN-P2B
WWPN-P3B
WWPN-P4B
WWPN-P5B
WWPN-P6B
WWPN-P7B
WWPN-P8B
WWPN-P1A
WWPN-P2A
WWPN-P3A
WWPN-P4A
WWPN-P5A
WWPN-P6A
WWPN-P7A
WWPN-P8A
VIO 1
VIO 2
WWPN-P1B
WWPN-P2B
WWPN-P3B
WWPN-P4B
WWPN-P5B
WWPN-P6B
WWPN-P7B
WWPN-P8B
Site B - Zones
Storage Controllers B
VM15 VM17 VM15 VM17
VM vFC adapter WWPNs are the same across
the two sites (manual input on target)
VM Recovery Manager DR: Lab Environment High Level Zoning Example
DR Rehearsal FeatureDR Testing without impacting Production
Primary
VM01 – RHEL 7.5
HANA 2.0 DB
VIO 1
Secondary
VIO 2
VM02 – RHEL 7.5
HANA 2.0 DB
VM03 – RHEL 7.5
App Server
VM04 – SLES 12
HANA 2.0 DB
VM05 – SLES 12
HANA 2.0 DB
VIO 1
VIO 2
KSYS
Managed
Native IP Replication
VM06 – SLES 12
App Server
VM01 – Test Clone
VM02 – Test Clone
VM03 – Test Clone
VM04 – Test Clone
VM05 – Test Clone
VM06 – Test Clone
Isola
ted N
etw
ork
Consistency
Group
Flashcopy
Target LUNs
1. # ksysmgr discover site Primary dr_test=yes
2. # ksysmgr verify site Primary dr_test=yes
3. # ksysmgr move site from=Primary to=Secondary dr_test=yes
……………………… Test Period ………………………….
1
1
21
-
2
840
VMR-DR
Native IP Replication
P ower780
1
24
System
Storage
0 16
1 17
2 18
3 19
S A N 3 2 B - E 4
G E 0
1
1
1
2
1
-
2
840
0 16
1 17
2 18
3 19
S A N 3 2 B - E 4
G E 0
1
P o w er 740
VMRDG_KSYS - Consistency Group
VM15_L1
VM15_L2
VM15_L3
VM15_L4
VM15_L1_AUX
VM15_L2_AUX
VM15_L3_AUX
VM15_L4_AUX
VM17_L1
VM17_L2
VM17_L3
VM17_L4
VM17_L1_AUX
VM17_L2_AUX
VM17_L3_AUX
VM17_L4_AUX
Provision Optional 3rd set of LUNs to
enable the creation of clone LPARs at the
remote site when a DR test is initiated
VM15_L1_DR_TEST
VM15_L2_DR_TEST
VM15_L3_DR_TEST
VM15_L4_DR_TEST
VM17_L1_DR_TEST
VM17_L2_DR_TEST
VM17_L3_DR_TEST
VM17_L4_DR_TEST
VM15
VM17
VM15_DRTest
VM17_DRTest
DR Rehearsal Feature: Additional Flashcopy LUN Configuration
* Target LUNs & DR Test Flashcopy LUNs
Target
Storage
Subsystem
Establish DR_Test LUN Relationships from KSYS:
ssh [email protected] svctask mkfcmap -source S822_VM01_Boot_Aux -target S822_VM01_Boot_DR_Test -copyrate 100
ssh [email protected] svctask mkfcmap -source S822_VM02_Boot_Aux -target S822_VM02_Boot_DR_Test -copyrate 100
ssh [email protected] svctask mkfcmap -source S822_VM03_Boot_Aux -target S822_VM03_Boot_DR_Test -copyrate 100
ssh [email protected] svctask mkfcmap -source S822_VM04_Boot_Aux -target S822_VM04_Boot_DR_Test -copyrate 100
ssh [email protected] svctask mkfcmap -source S822_VM05_Boot_Aux -target S822_VM05_Boot_DR_Test -copyrate 100
ssh [email protected] svctask mkfcmap -source S822_VM06_Boot_Aux -target S822_VM06_Boot_DR_Test -copyrate 100
ssh [email protected] svctask mkfcmap -source S822_VM01_Work_Aux -target S822_VM01_Work_DR_Test -copyrate 100
ssh [email protected] svctask mkfcmap -source S822_VM02_Work_Aux -target S822_VM02_Work_DR_Test -copyrate 100
ssh [email protected] svctask mkfcmap -source S822_VM04_Work_Aux -target S822_VM04_Work_DR_Test -copyrate 100
ssh [email protected] svctask mkfcmap -source S822_VM05_Work_Aux -target S822_VM05_Work_DR_Test -copyrate 100
ssh [email protected] svctask mkfcmap -source S822_VM102_Shared0_Aux -target S822_VM102_Shared0_DR_Test -copyrate 100
ssh [email protected] svctask mkfcmap -source S822_VM0102_Shared0_Aux -target S822_VM0102_Shared0_DR_Test -copyrate 100
ssh [email protected] svctask mkfcmap -source S822_VM0102_Shared1_Aux -target S822_VM0102_Shared1_DR_Test -copyrate 100
ssh [email protected] svctask mkfcmap -source S822_VM0405_Shared0_Aux -target S822_VM0405_Shared0_DR_Test -copyrate 100
1) Creating Snapshot Copy:
# ssh admin@<hostname/IP> svctask mkfcmap -cleanrate 0 -copyrate 0 -source <source_disk_name> -target <target_disk_name>
2) Creating Clone Copy:
# ssh admin@<hostname/IP> svctask mkfcmap -source <source_disk_name> -target <target_disk_name> -copyrate 100
VMRM_Consistency_Group
Flashcopy
Target LUNs
Primary Site Secondary Site
VLAN Switch & VLAN Matrix Description
System-level network mapping policy:# ksysmgr modify system network_mapping=enable network=vlanmap sites=siteA,siteB
siteA=VLAN1,VLAN12,VLAN13,VLAN5 siteB=VLAN11,VLAN22,VLAN23,VLAN25
Variation of the command done at the
KSYS management VM level
Site-level network mapping policy:# ksysmgr modify site site1 network=vlanmap backupsite=site2 site1=1,2,3 site2=4,5,6 dr_test=yes
Variation of the command done at the site
definition level
Host-Group-level network policy:# ksysmgr modify host_group HG1 options network=vswitchmap sites=site1,site2
site1=vswitch1,vswitch2 site2=vswitch2,vswitch1
Variation of the command done at the
Host group definition level
Host-level network policy:# ksysmgr modify host host_1_2, host 2_2 network=vlanmap sites=Site1, Site2
site1= VLAN1,VLAN12,VLAN13,VLAN5 site2= VLAN1,VLAN22,VLAN23,VLAN5
Variation of the command done at the
individual host level
VLAN Policy
Active Site Backup Site DR Test
VLAN 1 VLAN 11 VLAN 21
VLAN 2 VLAN 22 VLAN 32
VLAN 3 VLAN 23 VLAN 33
VSWITCH Policy
Active Site Backup Site DR Test
vswitch1 vswitch10 vswitch11
vswitch2 vswitch20 vswitch22
vswitch3 vswitch30 vswitch33
Sample Matrix tables:
VM Recovery Manager DR: Configuring the Network Mapping Policy
# ksysmgr modify VM VM03_atssg192,VM04_atssg193,VM05_atssg194 host=8284_22A_SN218ABCV priority=low
For VM VM03_atssg192 attribute(s) 'host', 'priority' are successfully modified.
For VM VM04_atssg193 attribute(s) 'host', 'priority' are successfully modified.
For VM VM05_atssg194 attribute(s) 'host', 'priority' are successfully modified.
# ksysmgr modify VM VM01_atssg190,VM02_atssg191 host=8284_22A_SN218ABCV priority=high
For VM VM01_atssg190 attribute(s) 'host', 'priority' are successfully modified.
For VM VM02_atssg191 attribute(s) 'host', 'priority' are successfully modified.
Name: VM05_atssg194
UUID: 54B3E149-20D0-4270-8400-B1B67B70B6A4
Host: 8284_22A_SN218ABCV
State: READY_TO_MOVE
Priority: Low
skip_resource_check: No
skip_power_on: No
memory_capacity: none
cpu_capacity: none
Dr Test State: INIT
Name: VM04_atssg193
UUID: 79282FC8-F4D2-4162-A53C-74E3A6CE6238
Host: 8284_22A_SN218ABCV
State: READY_TO_MOVE
Priority: Low
skip_resource_check: No
skip_power_on: No
memory_capacity: none
cpu_capacity: none
Dr Test State: INIT
Name: VM03_atssg192
UUID: 12CD1A9E-D242-4758-9C33-5DD4C49E7293
Host: 8284_22A_SN218ABCV
State: READY_TO_MOVE
Priority: Low
skip_resource_check: No
skip_power_on: No
memory_capacity: none
cpu_capacity: none
Dr Test State: INIT
Name: VM01_atssg190
UUID: 199AEE3A-702A-4AC5-AC41-A50BD1446C17
Host: 8284_22A_SN218ABCV
State: READY_TO_MOVE
Priority: High
skip_resource_check: No
skip_power_on: No
memory_capacity: none
cpu_capacity: none
Dr Test State: INIT
Name: VM02_atssg191
UUID: 33D4C645-BB70-488E-A516-DE66B6394130
Host: 8284_22A_SN218ABCV
State: READY_TO_MOVE
Priority: High
skip_resource_check: No
skip_power_on: No
memory_capacity: none
cpu_capacity: none
Dr Test State: INIT
VM Recovery Manager DR: VM Acquisition / Release Priority Modification
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
High Priority
Med Priority
High Priority
Managed VM
Managed VM
Low Priority
Server A
Server B
Managed / Unmanaged VMs recognized by KSYS cluster Description
Display VMs:# ksysmgr query vm
Unmanaged VMs:
test_atssg195
Managed VMs:
VM05_atssg194
VM04_atssg193
VM03_atssg192
VM02_atssg191
VM01_atssg190
All VMs:
Name: test_atssg195
UUID: 1EBC0937-9329-4AE2-9C2B-7DCAE8E45608
Host: 8284_22A_SN218ABCV
State: UNMANAGED
Priority: Medium
skip_resource_check: No
skip_power_on: No
memory_capacity: none
cpu_capacity: none
Dr Test State: INIT
Name: VM05_atssg194
UUID: 54B3E149-20D0-4270-8400-B1B67B70B6A4
Host: 8284_22A_SN218ABCV
State: READY_TO_MOVE
Priority: Low
skip_resource_check: No
skip_power_on: No
memory_capacity: none
cpu_capacity: none
Dr Test State: INIT
Detailed listing of the VMs that the
KSYS management knows about in all
of the defined servers in the
environment
Display Managed VMs (Short Listing)# ksysmgr query vm state=manage | grep –p Managed
# ksysmgr query vm state=unmanage | grep -p Unmanaged
Display only the list of VMs the KSYS
node Is actually controlling / or not
controlling when a move is initiated
Manage / Unmanage VMs that you do not want KSYS to control# ksysmgr manage vm name=VM,VM host=<host>
# ksysmgr unmanage vm name=VM,VM host=<host>
Syntax to add / remove VMs from
KSYS control (default behavior is for
the discovery to try to manage all VMs)
VM Recovery Manager DR: Managing & Unmanaging VMs
Managed VM
Managed VM
VIOS
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
VIOS
Managed VM
Managed VM
VIOS
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
Managed VM
VIOS
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Unmanaged
Server A
Server B
Primary
VM01
Unmanaged
VIO 1
Secondary
VIO 2
VM02
Unmanaged
VM03
Unmanaged
VM04 – SLES 12
HANA 2.0 DB
VM05 – SLES 12
HANA 2.0 DB
VIO 1
VIO 2
KSYS
Managed
Block Level Replication
1
1
21
-
2
840
VM06 – SLES 12
App Server
VM Recovery Manager DR: Test VM Management Scenario from Videos
VMR-DR
Unm
anaged
Modifie
d C
on
sis
tency G
roup
Origin
al C
onsis
tency G
roup
* Managing only 3 VMs
* Managing all 6 VMs
VM01 – RHEL 7.5
HANA 2.0 DB
VIO 1
VIO 2
VM02 – RHEL 7.5
HANA 2.0 DB
VM03 – RHEL 7.5
App Server
VM04 – SLES 12
HANA 2.0 DB
VM05 – SLES 12
HANA 2.0 DB
Managed
VM06 – SLES 12
App Server
VM01
Unmanaged
VIO 1
VIO 2
VM02
Unmanaged
VM03
Unmanaged
VM04 – SLES 12
HANA 2.0 DB
VM05 – SLES 12
HANA 2.0 DB
Managed
VM06 – SLES 12
App Server
Unm
anaged
2 ] # ksysmgr discover site <Site> verify=true
1 ] # ksysmgr unmanage vm name=vm1,vm2,vm3 host=<name>
Flexible Capacity Description
VM Level Values:
# ksysmgr modify vm file=ListOf3VMs.xml memory_capacity=60 cpu_capacity=50
skip_resource_check=yes
An xml file can be used to set the
desired values for a number of VMs at
the same time
Host Level Values:
# ksysmgr modify host Site1_Host1,Site2_Host1 memory_capacity=50 cpu_capacity=50
skip_power_on=yes skip_resource_check=yes
Alterations may be specified for all of
the VMs on a specific host
Host Group Level Values:
# ksysmgr modify host_group Site1_HG1,Site1_HG2 memory_capacity=50
cpu_capacity=50 skip_power_on=yes skip_resource_check=yes
Alterations may be specified at the
Host Group level to encompass all of
the VMs in that group
Power Enterprise Pool Manipulation Description
VM Level Values:
# ksysrppmgr -o execute -h :hmc_2_1:hmcuser -m host_2_2:set:n: <memory_amount>:
<no_of_processors>
Sample command to manipulate CPU
& memory values in a scenario with
PEP at the remote site
Reference: https://www.ibm.com/support/knowledgecenter/en/SS3RG3_1.2.0/com.ibm.gdr/admin_cod_EP.htm
VM Recovery Manager DR: CPU & Memory Flexible Capacity
2019 IBM Systems Technical University
Custom Script Management [ Introduce Pre or Post Event Custom Logic ]
— To register scripts for specific KSYS operations such as discovery and verification:
# ksysmgr add script entity=site | host_group pre_offline | post_online | pre_verify | post_verify=<script_file_path>
— Receive Separate Notifications on specific Events:
# ksysmgr add notify script=<full_path_script> events=event_name
* You can add a maximum number of 10 event notification scripts to the KSYS configuration settings
2019 IBM Systems Technical University
Sample Scripts Provided to Prime VMs on Remote Boot
data_collection.ksh
— System host name
— Network adapter information
— Host bus adapter (HBA) configuration
— Domain Name System (DNS) server and domain
— LPAR attributes
— Volume group attributes and hard disk attributes
— AIX kernel (sys0) configuration
setup_dr.ksh
— Reconfigures the HBA adapters of the backup LPAR to be the same as the source LPAR
— Reconfigures the Ethernet adapter of the backup LPAR by reading the contents of the failover_config.cfgconfiguration file and set the host name, IP address, and the base network of the backup LPAR
— Reconfigures any additional Ethernet adapters on the backup LPAR by using the appropriate IP addresses
— Imports any volume groups from the source LPAR to the backup LPAR
failover_config.cfg
— IP address of LPAR at the source site
— IP address of LPAR at the backup site
— Network netmask to use at the backup site
— DNS server that must be used at the backup site
— Network domain name to use at backup site
— Default gateway IP address to use the backup site
Run script
periodically on
source VMs
/usr/local/bin
You must manually
edit this file and fill
appropriate
information about the
AIX operating
system configuration
in the backup LPAR
/usr/local/dr/data
Run this script on the
backup LPAR during a
disaster recovery event. It
will read the contents of the
failover_config.cfg file
/usr/local/bin
Check Out: /opt/IBM/ksys/samples/site_specific_nw/AIX/README
2019 IBM Systems Technical University
Sample Scripts Provided to Prime VMs on Remote Boot
VM Recovery Manager DR : Deployment Requirements
VMR-DR
* Usually hosted at the remote location
HMC
VM
Operating
Systems
PowerVM
VIOs
Block Level
Replication
Power
Hardware
Models
Min Levels:
• V8 R8.7.0 (2017) + SP1
• V9 R9.1.0 (2018) +
• AIX V6 or later
• IBM i V7.2 or later
• RedHat(LE/BE) 7.2 or later
• SUSE(LE/BE) 12.1 or later
• Ubuntu 16.04 or later
• EMC SRDF: VMAX Family, Solutions Enabler SYMAPI V8.1.0.0
• DS8K PPRC: DS8700 or later DS8000 (DSCLI 7.7.51.48 or later)
• SVC/Storwize Metro or Global: SVC 6.1.0 (or later) or Storwize (7.1.0 or later)
• Hitachi VSP, G1000, G400: Universal Copy: Universal Copy (CCI version 01-39-03 or later)
• XIV / A9000: XIV Storage System command-line interface (XCLI) Version 4.8.0.6, or later ➔ VMR V1.3.0.2
• VIOS 2.2.6 (2017) + Fixes
• VIOS 3.1.0 (2018) +
• P7+
• POWER 8
• POWER 9
• AIX 7.2 TL1 SP1+
• 1 Proc | 8GB of memory
• Connectivity to HMCs & Storage at both sites
• Provides CLI & UI Server Management
* PowerVM may be Standard or Enterprise Edition when using a VMR DR setup
KSYS VM
VM Recovery Manager DRLicensing & Architectural Design Variations
• VMR is installed on an AIX partition that provides the
KSYS cluster functionality. The KSYS would be
configured as cluster type “DR”
• KSYS is the Orchestrator that will enable planned,
unplanned & DR Test operations at either the Site
level of Host Group Level
Scenario #1:
(6) Managed AIX & Linux VMs consuming 10 processors
On Scale-out server: (1020 x 10 = $10200)
On Scale-up server: (1575 x 10 = $15750)
Scenario #2:
(1) Manage additional IBM i VM consuming 2 processors
On Scale-out server: (+ $1020 X 2= $2040)
On Scale-up server: (+ $1575 X 2= $3150)
VMR DR
KSYS
AIX
Unmanaged
Unmanaged
AIX
Linux
Linux
Linux
Linux
Ma
na
ge
d V
Ms
Unmanaged
Unmanaged
IBM i
How to license VM Recovery Manager DR [ 5765-DRG ]
Host G
rou
p X
Primary Secondary
Disk Group
Disk Group
Unmanaged
HG
B_
VM
R1
DR Managed
DR Managed
DR Managed
DR Managed
Unmanaged
Unmanaged
HG
A_
VM
R1
Host Pair
Host Pair
KSYS #1
DR Managed
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VMR-DR
VM Recovery Manager DR: Active | Active Configurations
Primary Secondary
KSYS #2VMR-DR
Host Pair
Host Pair
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
DR Managed
DR Managed
DR Managed
DR Managed
DR Managed
DR Managed
HG
A_
VM
R2
HG
B_
VM
R2
VM Recovery Manager DR: Active | Active Configurations
Primary Secondary
KSYS #2VMR-DR
Disk Group
Disk Group
Unmanaged
HG
B_
VM
R1
DR Managed
DR Managed
DR Managed
DR Managed
Unmanaged
Unmanaged
HG
A_
VM
R1
Host Pair
Host Pair
KSYS #1
DR Managed
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VMR-DR
DR Managed
DR Managed
DR Managed
DR Managed
DR Managed
DR Managed
HG
A_
VM
R2
HG
B_
VM
R2
VM Recovery Manager DR: Active | Active Configurations
VM Recovery Manager DR: Many to One Configurations
VM Recovery ManagerUpcoming Features in 2019
HA
DR
1.2 Beta
Oct
2017
1.3 Product Beta
• Support for P7+, P8, P9
• Graphical & CLI management
• LPM Management
Automated End-to-End management:
• Host, VM, & App Level HA
• Application start sequence mgmt
Jun
2017
GDR Release 1.1.0.1
Dec
2018
• HA or DR deployments support
• Hitachi TrueCopy management
• Failover Rehearsal support for
Hitachi storage
Nov
2018
• Expanded storage
support:
✓ SVC/Storwize:
Sync,Async
✓ DS8K Async
✓ EMC Sync
• IBM i Guest VM
• Boot list mgmt
• Host Group DR
• Failover
Rehearsal
VMR DR Release 1.3
Sept
2018Dec
2017
GDR Release 1.2
• Advanced DR policies (Host Groups)
• DR Failover Rehearsal
• Hitachi HUR replication support
• Flex Capacity Management
• VLANs, vSwitches per Site
Advanced Policies:
• Flex Capacity Management
• Collocation / Anti-collocation
• Priority Based Failovers
• Host Blacklisting
HA agents for key middleware:
• DB2, Oracle, SAP HANA
VMR HA Release 1.3
VM Recovery Recovery Manager Offering – Product Roadmap
VMR DR Release 1.4 (In-plan)
• Many to One Configurations
• Type ”HADR” KSYS
• GUI Administrative Controls
• VM Level Moves
Dec
2019
VMR HA Release 1.4 (In-plan)
• Proactive HA Management
• Graphical Updates
• Additional VM Agents
• PowerVC Integration
• and others…
June
2019
SP2
SP2
DR Managed
DR Managed
DR Managed
DR Managed
Unmanaged
Unmanaged
Unmanaged
Ho
st
Gro
up
AH
os
t G
rou
p B
Host Pair
Host Pair
KSYS
Disk Group
Primary Secondary
KSYS
DR Managed
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VIO
VMR-DRVMR-HA
HA Managed
HA Managed
Unmanaged
HA Managed
Disk Group
To accomplish this you would need (2) separate independent KSYS clusters:(1) Type=DR ➔ Would manage VMs had block level replication to remote site(1) Type=HA ➔ Would manage VMs that could only move locally
Ho
st
Gro
up
C
VM Recovery Manager: Today its “HA” or “DR” for your VMs
VMR HA Code:
ksys.ha.license 1.3.0.0 COMMITTED Base Server Runtime
ksys.hautils.rte 1.3.0.0 COMMITTED Base Server Runtime
ksys.main.cmds 1.3.0.0 COMMITTED Base Server Runtime
ksys.main.msg.en_US.cmds 1.3.0.0 COMMITTED Base Server Runtime
ksys.main.rte 1.3.0.0 COMMITTED Base Server Runtime
ksys.ui.agent 1.3.0.0 COMMITTED VMRestart User Interface
ksys.ui.common 1.3.0.0 COMMITTED VMRestart User Interface
ksys.ui.server 1.3.0.0 COMMITTED VMRestart User Interface
Prompted to run:
/opt/IBM/ksys/ui/server/dist/server/bin/vmruiinst.ksh
UI Server Only Deployment:
ksys.ui.common: (GUI common)
ksys.ui.server (GUI server)
ksys.ui.agent (GUI agent)
Prompted to run:
/opt/IBM/ksys/ui/server/dist/server/bin/vmruiinst.ksh
• UI Server code is optional and may be
installed on a different VM
• Separate packages are available for the
VM and Application monitoring
available for the AIX, RHEL & SLES
distributions
• IBM i partitions only support Host level
monitoring in the V1.3 release
• UI Server code may be installed on a
separate standalone AIX VM
• Recommended starting points are the
same as the KSYS baseline 1CPU &
8GB of memory
VMR DR (GDR) Code:
ksys.license 1.3.0.1 COMMITTED Base Server Runtime
ksys.main.cmds 1.3.0.1 COMMITTED Base Server Runtime
ksys.main.msg.en_US.cmds 1.3.0.1 COMMITTED Base Server Runtime
ksys.main.rte 1.3.0.1 COMMITTED Base Server Runtime
ksys.mirror.ds8k.rte 1.3.0.1 COMMITTED Base Server Runtime
ksys.mirror.emc.rte 1.3.0.1 COMMITTED Base Server Runtime
ksys.mirror.hitachi.rte 1.3.0.1 COMMITTED Base Server Runtime
ksys.mirror.svc.rte 1.3.0.1 COMMITTED Base Server Runtime
• Code base includes the various storage
agent packages that enable us to
handshake with the block level
replication and orchestrate DR moves
• Some of the code is shared with VMR-
HA hence why the DR solution will
enable you to define a “HA” cluster type
VM Recovery Manager: V1.3.0 Product Packaging
VM
R H
A :
PID
57
65-V
RM
VM
R D
R :
PID
57
65
-DR
G
KSYS
Primary Secondary
VIO
VIO
VIO
VIO
VIOVIO
VMR-HADR
Unmanaged
VMR DR License: Will allow 3 Cluster Types(1) HA – local availability / shared storage(2) DR – VM mobility between remote sites / block level replication(3) HADR – VMs can be restarted automatically locally and also replicated to a DR location for planned or unplanned DR events
Lo
ca
l R
esta
rt
DR VM Mobility
Managed
Managed
Managed
VM Recovery Manager DR: Introducing 3rd Cluster Type in V1.4.0 (Q4 2019)
Combined HA & DR Functionality
Many to One DR Setup
VM Recovery Manager DR: Many to One Configurations
KSYS
Primary Secondary
VIO
VIO
VIO
VIO
VMR-HADR
Unmanaged
Managed
Managed
Managed
Unmanaged
Managed
Managed
Managed
VIO
VIO
VM Level Movement
VM Recovery Manager DR: Individual VM Level Granularity
KSYS
Primary Secondary
VMR-HADR
Managed
Managed
Managed
Managed
VIO
VIO
VIO
VIO
VIO
VIO
Session Summary
VM Recovery Manager for HA [ 5765-VRM ] VM Recovery Manager for DR [ 5765-DRG ]
Local Datacenter Solution for VM Restarts DR Orchestration to relocate VMs between remote sites
Additional Capabilities: Additional Capabilities:
Priority Based Restarts
Flexible Capacity (Recreate VMs with Lower | Higher CPU & Memory values)
LPM Management (Host Level or VM Level) N/A
Remote Restart Feature (Automated or Manual) N/A
Collocation | Anti-Collocation Policies N/A
Application Agents (HANA, Oracle, DB2, Postgres & Custom App framework) N/A
CLI or Graphical User Interface (GUI to be combined further in upcoming release)
Auto Restart of VMs locally or Advisory Mode:
• Host Level Failure
• VM Level Failure
• Application Level Failure
User Initiated Actions:
• Planned DR Movement [ Site | Host Group ]
• Unplanned DR Movement [ Site | Host Group ]
• DR Testing Capability [ Site | Host Group ]
• 2017 Redbook [SG24-8382] ➔ based on GDR V1.1
• New 2019 Redbook [ SG24-8426 ] ➔ based on VMR DR V1.3.0
• Product Documentation
• IBM Knowledge Center
• LinkedIn Group
VM Recovery Manager Intellectual Capital & References
Thank you for your time!