GDR Steven Finnes 170579 37AC

Session objectives GDR, the basic technology : VM replication & restart for disaster recovery operations Offering mechanics and errata Marketplace perspectives How it works Licensing Prerequisites Roadmap CBU for Enterprise Servers

Introducing: GDR A disaster recovery solution for everyone VM Restart based DR: Simple, Reliable Disaster Recovery Solution for Power Systems A disaster recovery solution for everyone Automated Disaster Recovery management Low cost to acquire and nearly no cost to manage Eliminates hardware and software resources at backup site Easier deployment compared to clustering or middleware replication technologies VM restart technology has no OS or middleware dependencies Support for IBM POWER7® and POWER8® Systems Support for heterogeneous guest OSs AIX Red Hat SUSE Ubuntu IBM i

Disaster recovery: clustering & VM restart Site 1 Cluster Node Active Site 2 Failover Fig 1: Cluster DR Model Node 2 Standby VM Restart Control System K-sys Site1 Restart Site 2 VM 1 Restart VM 1 VM 1 Replication Replication Fig 2: VM Restart DR Model Deployment Approach Deployment inside each VM Deployment outside VMs (simpler) Workload Failover Time Fast Fast Enough for DR (VM Reboot) Classification warm backup cold backup Cost (some SW duplication) (no SW duplication) Maintenance coverage software and hardware hardware

Clustering and VM restart positioning Cluster HA/DR: mission critical workloads Covers all outage types (planned and unplanned) VM Restart HA/DR: particularly attractive for cloud based disaster recovery Covers hardware outages Some customers currently do restart DR manually (XL sheets etc),

GDR for Power Systems – how it works The storage subsystem at the backup host is prepared and mapped to VIOS VM1 and VM2 are booted up VMs from site 1 are now restarted on the backup host in site 2 The underlying mechanism that enables this to happen is the KSYS orchestrator at site 2 From a customer perspective, this operation is accomplished with a single command

GDR & DRaaS : DR as a Service (Hybrid Cloud) IBM Cloud Centers Easy to deploy & Manage DR solution, central control Extensive Automation, Monitoring, & Validation across sites Manage DR for 100’s of LPARs (AIX, Linux, IBM i) Non-disruptive DR testing Entire datacenter (100’s of LPARs) failover in less than an hour. No software costs for the backup site Reduced hardware costs (Enterprise Pool support) Pair your old P7 systems with P8 for DR Support for: Storwize, DS8K, EMC SRDF, Hitachi (4Q) Wiki, FAQ, blogs: http://ibm.biz/PowerGDR

K-Sys: C(K)ontrol System LPAR K-sys: Controller System: AIX LPAR that orchestrates the DR operations Alerts administrator about key events Administrator initiated DR automation Scripting support: Daily validations & Event notifications Site 1 Site 2 K-sys Controller System LPAR Networks … … … Storage Mirroring … HMCs, VIOSs, LPARs (VMs), Storage HMCs, VIOSs, Storage

GDR use case example automated disaster recovery operations with a PowerHA standard edition cluster Madison Chicago Host level VM restart of production in Madison to Chicago Simple disaster recovery compliance testing

Automation: Critical for successful Business Continuity Capacity Management Reliable, consistent recovery time Essentially eliminates human intervention and errors Cross site or Intra site CPU and memory adjustments before DR Enterprise Pool Exploitation Single Point of Control Validation Daily verification across sites Eg: Check missing mirrors etc Email alerts to administrator Facilitates simple to use regular testing for repeatable results Centralized status reporting Centralized administration through HMCs (eg: centralized LPM initiations) Uni-command based administration

GDR product licensing example GDR for Power Systems Software tier small processor group/core medium processor group price/core List price for managed cores $1020 $1575 Linux AIX AIX Licensing structure: no charge base PID registered to KSYS server Two tier features: small or medium One quantity feature = # of processor cores to be restarted Licenses on target system not required however consider SWMA IBM i Linux 4 systems: 2 production, 2 DR systems Production site: 2 systems, 5 VM partitions, 14 production cores, 14 AIX LPPs, 14 PowerVM LPPs DR site: 2 recovery systems, 5VM partitions, 14 DR cores, one AIX LPAR for Ksys DR site: 1 KSYS system, 1 AIX, 1 Base PID, tier feature = small, quantity feature = 14 restart features => $14,280 + 80 hours @ $23,886 = $38,166 (US prices & subject to change at the discretion of IBM) Implementation service package options: 80 hours, 120 hours, 240 hours > 240 hours # of restart features = number of cores to be restarted 80, 120 & 240 hours charged @ $23,886, $35,828 and 71,657 U.S. prices which can vary by geo and subject to change an any time

GDR (Geographically Dispersed Resiliency for Cognitive Systems) Initial Announce : Oct 11, 2016, current announce: May 2017 Generally Available : Nov. 18, 2016, Enhancements planned for 1H 2017 & 4Q 2017 Delivered as part of GTS Resiliency Service Offering New automation S/W – one time charge, priced per h/w core (only those in VM restart partitions) Installation services, Software maintenance both Power & GTS BP’s & Distributor’ enabled to sell: April 18, 2017 Two Deployment Models On Customer Premise – initial release DR as a Service from IBM or third party DRaaS provider

GDR – How to Order Software License and Maintenance - AAS (via PRPQ) Product IDs (PID) for Ordering in AAS: 5799-DRP – GDR Software 5799-DR1 – 1 year Software Maintenance 5799-DR3 – 3 year Software Maintenance Implementation services: BMS/CFTS (via signed SOW) Implementation services required for first license sold (controlled by PRPQ) Options Power 7 or Power 8 servers AIX, Linux DS8K, Storwize, EMC VMAX Disk with SRDF Replication, IBM i and IBM storage support GA in June (DS8000 Global Mirroring, SVC and Storwize with either Metro or Global Mirror) Sizing of Implementation Services: Small – 2 CEC's and 100 VM's Medium – 4 CEC's and 180 VM's Large – 6 CEC’s and 300 VM’s ** ** Any deal larger than this requires special bid request

GDR First Release Capabilities Capability Customer Value Supports P7 & P8 Systems Enables customer to move older P7 systems to DR site and pair with P8 in main data center Support for AIX, IBM i and Linux Guest VMs DR for AIX, IBM i, and Linux (all major flavors) enables uniform DR solution for Power platform Enterprise Pool Support Flexible capacity management to reduce costs Daily validation Early detection of faulty configuration and other issues Storage Replication Offloaded uniform data copy methods. Support for EMC SRDF Async in 2016 Customization framework Plugin script to do custom checks every day and custom process events as they occur Easy to deploy Less than 10 steps deployment enables simplified DR

GDR Validations & Notifications Daily proactive environment validations Email and Text alerts to administrator about issues/events found Extensible frameworks Administrator can plugin scripts to: Perform custom checks as part of verification Handle events as they occur

GDR Pre-requisites Guest OS in VMs AIX: V6 or later IBM I (June 2017) Linux: RedHat(LE/BE): 7.2 or later,SUSE(LE/BE): 12.1 or later,Ubuntu: 16.04 VIOS VIOS 2.2.5 (2016) HMC V8 R8.6.0 (2016) EMC Storage VMAX family, Solutions Enabler SYMAPI V8.1.0.0, PowerPath IBM DS8K SVC, Storwize June 2017 KSYS LPAR AIX 7.2 TL1 1 2 3 4 5

SAP HANA Disaster Recovery Backup Site Home Site Power GDR KSYS Host 1_2 Host 2_2 … APP NW or HANA App VM1 VM2 Source: http://scn.sap.com/docs/DOC-60334 VIOS 12 Pair VIOS 22 Storage Replication System Test: Test SAP HANA VMs + NetWeaver VM back & forth DR failovers 96 Hour Continuous failover testing: Many failovers and failbacks SAP HANA and its workload will be checked for recovery + functionality (not performance)

DR Failover Rehearsal: easy, non disruptive disaster recovery testing Site 1 (active) Site 2 (backup) Host 11 Host 21 … LPAR 1_11 LPAR 1_12 LPAR 1_1m … LPAR 1_11 LPAR 1_12 LPAR 1_1m VIOS 1_11 VIOS 1_12 VIOS 2_11 VIOS 2_12 Disk Group 1 Mirror S1 S2 S2C K-sys enables non-disruptive DR testing Copy storage on recovery site and use that to start VMs on back up system Network isolation needs to be established by the administrator If site specific VM network config is supported: Test related network config could also be supported

GDR for Power Roadmap Aug Nov 2016 2016 Beta Release Early prototype GA Release 1.1 GA Release SP: GA Release GA Release Support for P7 and P8 Systems Support for vSCSI, NPIV EMC SRDF Async Capacity management Admin controlled recovery IBM i Support for other storage replications: SVC/Storwize DS8K EMC Sync Advanced DR policies (Host Groups, etc) Failover Rehearsal (DR Test) Hitachi Mirror support VLAN per site support Support for sub capacity LPAR DR start Statement of direction As part of the Resiliency portfolio IBM will look to continue the integration of GDR into our Disaster Recovery as a Service offering providing increased value to our client base. IBM intends to add support for additional IBM and OEM storage platforms. IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM's sole discretion. Information regarding potential future products or services is intended to outline our general direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products or services is not a commitment, promise, or legal obligation to deliver any material, code, functionality, or service. Information about potential future products or services may not be incorporated into any contract. The development, release, and timing of any future services or features or functionality described for our products remain at our sole discretion.

GDR market perspectives Some shops are using manual and/or complex middleware data replication DR implementations Some do not test their DR capability due to the complexity Required annual or biannual disaster recovery testing is becoming the norm across all industry segments RPO capabilities of many contemporary DR implementations are unacceptable IBM Geographically Dispersed Resiliency (GDR) provides an easy to deploy and easy to use DR solution Significantly less expensive than contemporary options from both a CAPX and OPX perspective Scales from small shops to large enterprise shops GDR provides total automation through integration with the PowerVM platform Highly automated, consistent, reliable disaster recovery, easy to conduct compliance testing IBM services offers customization of GDR solution and deployment assistance Save costs by customizing use of Enterprise pools and systems in DR site DR testing without disruption to main site GDR along with customized services will provide a complete Power System data center DR solution Recovery Time Objective (RTO), Recovery Point Objective (RPO): Repeatable, reliable, simple DR testing

Who should be interested in GDR ? AIX, i and Linux Power Systems customers PowerHA AIX standard edition customers using manual methods Customers with either no or a roll-your-own HA solution Customers using PowerVC for their datacenter operations Linux on Power customers Customers currently using host based data base replication for their DR solution Software/journal shipping or replication solutions tend to require human intervention to insure synchronization of source and target databases, can be quite expensive, and they consume additional processing overhead GDR is simple to use, inexpensive and insures that the production and DR VMs are in sync and restart operations are simple MSPs offering DRaaS

Use case example: two site two server (E870s) GDR configuration Two-site GDR & CBU for Enterprise Systems CBU feature code: EB3K GDR provides the failover/restart capability to the secondary location Secondary location could be to an MSP site with a restart to an MSP server ! CBU for Enterprise Systems at the Disaster Recovery location for huge savings $$$$

Power Systems CBU for Enterprise Servers Offering All temporarily transferable entitlements must originate on the primary system and may not run concurrently on the primary system and the CBU system Subsequent to the initial workload deployment, production partitions may be moved to the CBU system for workload balancing etc The total number of processor entitlements running production across both servers can not exceed the original total licensed entitlements. Temporarily transferred entitlements return to the production server if either server leaves the registered pairing entitlement transfer Primary CBU Offering requirements overview Primary system and CBU system must be the same machine model (only one CBU to one production server for registration purposes but multiple production servers to one CBU is allowed. More than one Enterprise CBU to a primary or production server not allowed. Primary can be new or installed box, CBU must be a new box A minimum of one entitlement of AIX or IBM i & PowerHA on the CBU or if alternative HA/DR solution is used, as many IBM i or AIX entitlements as needed to support the workload (such as a middleware replication workload) 8 processor static activations on the CBU (no more no less) Minimum of 25% of DIMM memory active on the CBU No charge Memory ECOD days must be activated upon install of CBU system and remain active for 365 days Registration of primary system and CBU prior to CBU order fulfillment (registration validates configuration)Primary and CBU must be within the same enterprise Offering for Power System E880, E880C, E870 & E870C customers HA/DR deployments requiring fast failover via active standby memory CBU offering Features: Deeply discounted processor nodes matching the installed production server processor nodes No charge active standby memory = 365xNx32 GB, where N is the number of active mobile cores on the production server renewable annually Mobile processor activations are transferred from production to CBU via Enterprise Pool transfers The CBU system can be ordered with no-charge processor nodes (subject to the primary system configuration listed below) and one year’s worth of ECOD processor days and memory. ECOD processor days will match the E880 Primary system cores that are licensed with PowerHA -One or two nodes on the primary = 1 no-charge node on the CBU -Three or four nodes on the primary = 2 no-charge nodes on the CBU All transferable entitlements must originate on the primary system and may not run concurrently on the primary system and CBU system Subsequent to the initial workload deployment, production partitions may be moved to the CBU system for workload balancing etc Only whole processor units are transferable (ie no micro-partitions) The total number of processor entitlements running production across both servers can not exceed the original total licensed entitlements. One entitlement (AIX/IBM i and PowerHA) on the primary is not transferable and one core must be permanently licensed on the CBU This CBU system is available to clients with existing E880 or purchasing a new E880 that meets specific configuration requirements E880 primary system must have a minimum of 75% of the processors activated and 50% of installed DIMM memory active CBU system must have a minimum of 25% DIMM memory active, no charge ECOD days to match the primary (minus 25%) CBU will have 8 processor activations and one year of ECOD days for each PowerHA processor licensed on the primary system (minus 8) IBM will provide to the client three hundred and sixty-five (365) ECOD processor days for each active processor core licensed with PowerHA, minus the eight processor cores that the client is required to purchase on the Power E880 CBU system. The ECOD processor days can only be used on the Power E880 CBU system ECOD activations on the CBU must be renewed annually One or two nodes on the primary = 1 no-charge node on the CBU Three or four nodes on the primary = 2 no-charge nodes on the CBU 22

Order Process/Registration Prior to ordering the CBU with PowerHA fill in the worksheet posted on the CBU registration website to determine number of eligible discounted CBU processor nodes no charge memory ECOD activations Submit CBU entitlement worksheet (pwrhacbu@us.ibm.com) IBM verifies client configuration entitlements (discounted processor nodes and ECOD days) Customer agrees to CBU terms and conditions via registration website Send configuration files to pwrhacbu@us.ibm.com After project office approval, order the approved CBU configuration Specify the # of CBU processor nodes & feature code Econfig will automatically add the CBU system feature code: EB3J or EB3K After CBU system is installed, configuration of Primary and CBU system is sent to PowerHACBU@us.ibm.com CBU project office will apply the appropriate number of ECOD days to CBU for Enterprise Systems Implement TCOD (temporary COD) via standard process TCOD contract signed by client ECOD enablement codes ordered via MES Registration website: http://www-03.ibm.com/systems/power/hardware/cbu/

Cognitive Systems HA/DR offerings & positioning Pain point Desired Outcome Solution Offering Technology Benefit Considerations Down time for software maintenance mission critical HA solution requiring minimal admin PowerHA shared/replicated storage based clustering all outages; planed and unplanned are covered, UI/Dashbaord -cluster admin -multiple data -active standby OS’s -vary-on time DR compliance testing is labor intensive and disruptive simple DR solution requiring no admin GDR replicated virtual machine restart low cost simple to use automates DR operations -full frame restart -replicated copies of VMs -reboot time admin required to manage clustering simple HA solution requiring no admin PowerVC virtual machine restart automatic restart -single copy of VM -primarily CEC outage

GDR Reference Material GDR product page: ibm.biz/PowerGDR GDR Intro charts: https://ibm.box.com/s/wh7405mrjfebq59d685t02b1vew2bvu3 Quick Intro to GDR: https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Geographically%20Dispersed%20Resiliency%20%28GDR%29/page/Business%20Continuity%20%26%20Intro%20to%20GDR GDR T3 material (Charts, recordings): https://ibm.box.com/s/ui49l9ccijmatq3tv6sunwvsdset4d09 GDR social forum: https://www.linkedin.com/groups/12012982 5 Things to know about GDR: https://www.ibm.com/developerworks/community/blogs/5things/entry/5_Things_to_To_Know_about_Geographically_Dispersed_Resiliency_for_IBM_Power_Systems?lang=en GDR Redbook: http://www.redbooks.ibm.com/redpieces/abstracts/sg248382.html?Open

Additional Information & Support GDR Sales Essentials – https://w3-03.sso.ibm.com/services/salesone/salesessentials#/ok/60150/ Sales Education – http://lt.be.ibm.com/services/weblectures/dlv/Gate.wss?handler=Component&sequence=1&customer=ibmin tra&offering=gts5&action=load&itemCode=ltu56743&curriculum=&category=&lecture_language= GDR Pricing & ordering – https://apps.na.collabserv.com/communities/service/html/communitystart?communityUuid=d5cdb2a3-80a1- 4dcc-a3c8-ed1815f46d48 Contacts: Dave Clitherow /UK/IBM – GTS Global Offering Mgr. dave.clitherow@uk.ibm.com Vinay Kumar– GTS Global Offering Mgr. . Bangalor India EMail : vinaykumarvs@in.ibm.com Steven Finnes – Cogntive Systems HA/DR product offering manager: finnes @us.ibm.com Functional ID if you need additional assistance - gdr@us.ibm.com GDR License is fufiled via PRPQ through the AAS ordering system. The PRPQ (Program Request for Price Quote) is in place to ensure implementation services are ordered with each customer’s first license. Implementation Services are ordered via GTS standard BMS/CFTS Contract management System. In order to help guide you through this process we have created a one stop web site (IBM Connections Community wiki page below. It is important to note that in order to streamline the order process, that you involve the GDR team presales for help with pricing the solution.

Session summary GDR is the modern way to do disaster recovery operations for Cognitive Systems customers: AIX IBM i and Linux (for IBM i customers, it doesn’t require IASPs) It’s Easy to implement, Easy to use and inexpensive Doesn’t require IBM software licensing on the target server (although you might want to consider having at least one for SWMA purposes) Target server can be owned by the same enterprise or a different enterprise than the production server