SAP on Azure Customer Cases: HANA Large Instances Juergen Thomas Principal Program Manager Lead Azure Customer Advisory Team

HANA Large Instances Architecture Customer Coats Agenda HANA Large Instances Architecture Customer Coats Large Consulting Company Roadmap

SAP HANA Large instances in Azure SKU approach Four offerings reflect different performance attributes: Compute, RAM, storage, and networking pre-configured Additional storage acquired separately if needed EA only SKUs transacted through EA amendment Customer benefits Better use of capital relative to on-premises deployments Overall solution spans hosted and cloud, providing better economics Flexible payment terms through Microsoft EA Configurations for SAP HANA on Azure (Large Instances) SAP Solution SKU (CPU) RAM Storage Optimized for SAP Business Warehouse, BW/4HANA and generic OLAP workload 2 x Intel® Xeon® Processor E7-8890 v3 768 GB 3 TB 4 x Intel® Xeon® Processor E7-8890 v4 2.0 TB 8 TB Optimized for SAP Business Suite on SAP HANA or S/4HANA (OLTP), generic OLTP 1.5 TB 6 TB 4 TB 16 TB

HANA Large instances – Rough Architecture Customer connects via ExpressRoute into Azure Customer creates one or multiple VNets in Azure that run the SAP application layer Tenant gets carved out in co-located HANA certified hardware Blade(s) and Storage get assigned to the tenant Azure VNets of customer are getting connected to HANA Large Instance hardware through ExpressRoute  VNets of customer have two different ER connections

HANA Large instances - Networking Connecting Azure VNets to HANA Large Instances We use an separate MS Enterprise Edge Router to connect to HANA Large instances hardware For every Region the customer has to provide: A /29 IP address range for P2P connections A /24 IP address range for the Server IP pool that is used to assign to HANA Large Instance units Per Azure VNet, you need: A /24 IP address range for the tenant subnets within the VNet. A /28 IP address range for the Gateway subnet or /27 if the customer wants to have an additional P2S connection for emergency If you have problems with calculating the IP address ranges, as I have, check here: https://www.aelius.com/njh/subnet_sheet.html

HANA Large instances – More complex Networking I Customer deploys in 2 regions Issue: Expressroute Transport is not possible  HANA instance in Region #1 can not connect to HANA instance in Region #2  HANA System Replication can be used for DR purposes  HANA System Replication can be used for local HA only DR relies on an offer unique to HANA Large instances that sets up on Storage Replication between two associated regions

Reliability and Resiliency DC Redundancy Network Redundancy Storage Redundancy Hot Spares Scheduled downtime for firmware updates Isolated network and storage Dedicated and Reserved No single instance SLA SAP HANA Server

High Availability HSR Primary Secondary HSR Replication, Synchronous On the same L2 network IP Redirection ( very fast compared to DNS redirection) Standard OS supported fencing SLA: https://azure.microsoft.co m/en- us/support/legal/sla/sap- hana-large/v1_0/ Primary Secondary HSR

High Availability N+M M S1 S2 SB1 SB2 Shared NFS Storage On the same L2 network IP Redirection ( very fast compared to DNS redirection) Standard OS supported fencing M S1 S2 SB1 SB2

HANA Large Instances Architecture Customer Coats Agenda HANA Large Instances Architecture Customer Coats Large Consulting Company Roadmap

Customer Coats Coat is world’s leading thread manufacturer (http://www.coats.com/) Long Term goal is to get rid of own datacenters backend assets into public cloud Actual opportunity realized with HANA Large Instances: Move SAP landscape into Azure At same time exchange DBMS from Oracle to SAP HANA for all systems Run smaller systems in native Azure VMs Leverage HANA Large Instances for larger HANA systems

Coats move into the cloud Landscape: 5 different regional SAP ERP systems One larger SAP SCM system Two SAP BW production systems Each systems has separate development and test instances Move in several steps Move test systems on Oracle into Azure and create performance base line Start migration to SAP HANA using GS5 VMs and test performance Copy test system to HANA Large Instances and perform tests again Migrate single SAP systems on different weekends to Azure, perform migration onto SAP HANA and into HANA Large Instances

Coats – system landscape Application layer of all systems running in Azure Native VMs DBMS for SAP HANA systems that fit into native VMS stay in Azure – quite a few large Dv2 Series and GS-Series VMs DBMS layer for larger SAP HANA systems is in HANA Large Instances HANA Backup against NFS volume placed in Azure VM

Coats HA/DR strategy Though not offering SLAs on single blades, Coats is not using any HA on the DBMS side No DR so far established with Coats Problems encountered so far are around VNet design: Original plan did not foresee that many systems in Azure Hence only one VNet to with all SAP application layer VMs for all HANA Large Instance based systems using High performance Gateway In peak workloads we encounter situation where Vnet Gateway becomes the bottleneck

Customer Coats Future plans Leverage Storage snapshots for fast recovery HA for SCM system Disaster Recovery for HANA Large Instances

HANA Large Instances Architecture Customer Coats Agenda HANA Large Instances Architecture Customer Coats Large Consulting Company Roadmap

Customer: ‘Large Consulting Company’ I Very large SAP landscape with many different SAP systems All SAP systems on Windows/SQL Server Customer drives dual-cloud strategy Decision by CIO of customer to move large SAP BW landscape to Azure instead of AWS after having tested AWS with very positive performance using AWS X1 VMs Only 3 weeks between decision of CIO and first systems on Azure were running. Go-Live of production BW systems 6 months after CIO’s decision

Customer: ‘Large Consulting Company’ II Scale-out requirement for HANA Due to data volume in SAP BW, customer needed Scale-out of SAP HANA HANA offers master-slave scale-out Customer required: One master node S192 3 slave nodes S192 In some systems one Standby node S192 Customer has six SAP BW systems in SAP BW landscape

Customer: ‘Large Consulting Company’ III Challenges/Risks: Performance of business processes in BW on HANA Large Instances slower than in AWS with pure native VM deployment Caused by higher network latency between Azure VMs running SAP application layer and HANA Large Instances Also caused by VNet Gateway bottlenecks which we could resolve with Ultra High Performance Gateway Performance also improved with systems that were deployed on S192 instead of S144 However performance shown by SAP HANA based BW was better than Windows/SQL Server based BW (customer had not used any of SQL Server columnstore features with BW yet) Business deemed performance shown as sufficient and major improvement compared to the old system SAP Delta Loads from on-premise ERP work sufficiently well in throughput and latency

Customer: ‘Large Consulting Company’ IV Move to Azure Move complex since SAP BW system needed to be upgraded to a newer release in the same process Used SAP DMO functionality in SAP’s Software Life Cycle Management tools Moved test and development systems first, system-by system Moved original SAP BW system into Azure first Started Upgrade plus DMO in Azure Import of DMO goes from Azure VM into HANA Large Instance Application layer of SAP BW remains on Windows

Customer: ‘Large Consulting Company’ V Customer separated non-production and production in different Azure subscriptions and different HANA Large Instance tenants Two of the systems have HA Standby node Production system is DR replicated from US East to test system in US West HANA Large Instance storage replication replicate storage to DR location Additional disks for test system in Dr location are targeted In DR case, shutdown of test instance, unmount of tst volumes and mount of replicated storage volumes

Customer: ‘Large Consulting Company’ VI Future plans Customer already received additional S192m blades for S/4HANA Customer already ordered another 3 blades for S/4HANA Customer is evaluating Azure M-Series VMs to evaluate SAP BW on M- Series instead of HANA Large Instances Working with customer to get better SAP HANA backup/restore story with Azure Backup and Restore Services