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

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

3. 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 E v3
768 GB
3 TB
4 x Intel® Xeon® Processor E 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

4. 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

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

6. 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

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

8. 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: m/en- us/support/legal/sla/sap- hana-large/v1_0/
Primary
Secondary
HSR

9. 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

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

11. Customer Coats
Coat is world’s leading thread manufacturer (
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

12. 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

13. 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

14. 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

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

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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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