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

[email protected]

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:


• 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


for Linux


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


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


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


Repository LUN

HA LUN10 GB

10 GB

Same (2) LUNs

shared across all

VIO servers in HG

VMR SSP Cluster



[ 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


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


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



[ 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


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


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


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


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


HMCs

Shared SAN Storage

VM

R H

A –

VM

Re

sta

rt M

od

el

VMR-HA


How does VMR for DR compare to a PowerHA Enterprise Edition Cluster ?

DataData

Primary VM

VIO

VIO

OS Data

VIO

VIO


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


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


• 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


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


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


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


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_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


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


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_VM01_Work_Aux -target S822_VM01_Work_DR_Test -copyrate 100




ssh [email protected] svctask mkfcmap -source S822_VM102_Shared0_Aux -target S822_VM102_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


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


individual host level

VLAN Policy

Active Site Backup Site DR Test

VLAN 1 VLAN 11 VLAN 21



VSWITCH Policy

Active Site Backup Site DR Test

vswitch1 vswitch10 vswitch11



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.



# ksysmgr modify VM VM01_atssg190,VM02_atssg191 host=8284_22A_SN218ABCV priority=high



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



Priority: Low


skip_power_on: No


cpu_capacity: none

Dr Test State: INIT

Name: VM03_atssg192

UUID: 12CD1A9E-D242-4758-9C33-5DD4C49E7293



Priority: Low


skip_power_on: No


cpu_capacity: none

Dr Test State: INIT

Name: VM01_atssg190

UUID: 199AEE3A-702A-4AC5-AC41-A50BD1446C17



Priority: High


skip_power_on: No


cpu_capacity: none

Dr Test State: INIT

Name: VM02_atssg191

UUID: 33D4C645-BB70-488E-A516-DE66B6394130



Priority: High


skip_power_on: No


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


State: UNMANAGED

Priority: Medium


skip_power_on: No


cpu_capacity: none

Dr Test State: INIT

Name: VM05_atssg194

UUID: 54B3E149-20D0-4270-8400-B1B67B70B6A4



Priority: Low


skip_power_on: No


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


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


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


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


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: 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


• 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


• VLANs, vSwitches per Site

Advanced Policies:


• 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

[email protected]

Thank you for your time!

vm recovery manager - ibm · vm restart hadr solutions powerha systemmirror for linux powerha...

Documents