Deploying SAP on Azure Architecting SAP HANA on Azure

Deploying SAP on Azure Architecting SAP HANA on Azure

Course Agenda Module 1 – Introduction to SAP on Azure
9/17/2018 Course Agenda Module 1 – Introduction to SAP on Azure Module 2 – Microsoft Azure Virtual Machines Module 3 – Microsoft Azure Networking Module 4 - Architecting SAP NetWeaver on Azure Module 5 - Building SAP NetWeaver on Azure Module 6 - SAP NetWeaver Silent Install Whiteboard Design: Architecting an SAP NetWeaver Solution on Azure Module 7 - SAP HANA Architecture Design Module 8 – Building SAP HANA on Azure Whiteboard Design: Architecting an SAP HANA Solution on Azure © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Agenda SAP HANA on Azure Overview High Availability Solutions
SAP HANA Production Environment in Azure SAP HANA Dev/Test/DR Environment in Azure Notes We’ll start with an overview of SAP HANA offering on Azure. Next, we will present high availability aspects of SAP HANA deployments on Azure. We will also step through different architectural design options intended for SAP HANA production workloads on Azure and provide an equivalent coverage of the Development, Test, and Disaster Recovery workloads.

SAP HANA on Azure Overview
Let’s start with an overview of deployment options of SAP HANA on Azure

What is SAP HANA? SAP HANA is a modern, in-memory database and platform that is deployable on- premises or in the cloud The SAP HANA platform is a flexible data-source-agnostic in-memory data platform that allows customers to analyze data in real-time It is a development platform The ‘SAP HANA platform’ is the foundation of various SAP HANA editions, like the SAP HANA Platform Edition and the SAP HANA Enterprise Edition The SAP HANA platform is a flexible data source agnostic in-memory data platform that allows customers to analyze large volumes of data in real-time. It is also a development platform, providing an infrastructure and tools for building high-performance applications based on SAP HANA Extended Application Services (SAP HANA XS). It is the foundation of various SAP HANA editions, like the SAP HANA Platform Edition, providing core database technology, and the SAP HANA Enterprise Edition, bundling additional components for data provisioning. The SAP HANA Platform Edition integrates a number of SAP components, including the SAP HANA database, SAP HANA studio, and SAP HANA clients

HANA on Azure Characteristics
Highly responsive with low DB/network latency In-memory Database Performance High Availability & Disaster Recovery Enterprise Data Protection & Security Safe Migration with Downtime Minimized Taking advantage of HANA applications 1 2 3 4 5 6 Let’s consider the most common characteristics of SAP HANA environments on Azure SAP HANA must be highly responsive, which implies not just the sufficient computing resources but also low latency database platform and low network latency. Considering that HANA operates as an in-memory database, this also imposes requirements on the amount of available memory. You also should take into account high availability and disaster recovery requirements. Since you are dealing with business-critical data, it is highly recommended to implement data protection and security provisions. You must also strive to minimize downtime during migration from on-premises or across Azure regions. Finally, keep in mind that HANA functions as a back end to a number of SAP applications, so their capabilities and requirements should be incorporated into your design.

SAP HANA on Azure Workloads Azure Region Solution
SAP BW on SAP HANA, SAP Business Suite on HANA, and S/4HANA Azure Region Tenant VNets On- Premises Datacenter Tenant 1 Router On- Premises Datacenter Tenant 2 SAP HANA Deployment in Azure-certified Datacenter ExpressRoute to Azure Region ExpressRoute to Azure Tenant to Datacenter Tenant 1 ExpressRoute to Azure Tenant to Datacenter Tenant 2 Solution Virtualized: production SAP BW and S/4HANA workloads1 Microsoft offers SAP-certified SAP HANA capabilities on GS5 VM in the Azure public cloud. (Non-production workloads can be run on other SAP-certified Azure VM types). Large Instances: for production and non-production workloads Microsoft offers certified SAP HANA capabilities via purpose-built hardware specifically tuned for SAP HANA. SAP HANA instance runs in a non-virtualized environment on SAP HANA TDI certified hardware in an Azure-certified data center. SAP HANA is connected to the SAP application tier running on Azure VMs. The two environments are connected via Azure ExpressRoute. There are two main options that provide the ability to run SAP Business WareHouse on HANA, SAP Business Suite on HANA, and S/4HANA. The first one allows you to use Azure virtual machines. The second one, intended for the most resource-demanding workloads, relies on purpose-built bare metal hardware, without the overhead of the hypervisor. In particular, you can use Azure virtual machines to run production SAP Business Warehouse and S/4HANA workloads. Microsoft offers SAP-certified HANA capabilities on the GS5 VM sizes in the Azure public cloud. Non-production workloads can be run on other, smaller SAP-certified Azure VM types. In addition, Microsoft offers certified SAP HANA capabilities via purpose-built hardware specifically tuned for SAP HANA. SAP HANA instance runs in a non-virtualized environment, according to the SAP HANA Tailored Datacenter Integration specifications in Azure-certified data centers. In such cases, SAP HANA is connected to the SAP application tier running on Azure VMs via ExpressRoute. 1 in controlled availability

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:

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

SAP HANA on Azure Reference Architecture
From the architectural standpoint, these are the options available to customers when deploying HANA DB workloads on Azure

Azure VM Options for SAP Applications
Red : SAP certification is in roadmap VM Series VM Type VM Size Temp SSD SAPS # of v-disks Max IOPS Max Disk Bandwidth Max Network Bandwidth Compute (Windows) Compute (Linux) Supported HANA scenarios Remark SAP certification D v2 DS11_v2 2 vCPU, 14 GB 28 GB 3,530 4 6,400 96 MB/sec High $ /h $ /h Intel Xeon E v3 (Haswell), 2.4 GHz Certified (Any DB, App) DS12_v2 4 vCPU, 28 GB 56 GB 6,680 8 12,800 192 MB/sec $ /h $ /h DS13_v2 8 vCPU, 56 GB 112 GB 12,300 16 25,600 384 MB/sec $ /h $ /h DS14_v2 16 vCPU, 112 GB 224 GB 24,180 32 50,000 768 MB/sec Very high $ /h $ /h DS15_v2 20 vCPU, 140 GB 280 GB 30,430 40 62,500 960 MB/sec $ /h $ /h G GS1 2 vCPU, 28 GB 3,580 5,000 125 MB/sec $ /h $ /h Intel® Xeon® E5 v3 (Haswell) Certified (Any DB, App) GS5 certified for OLAP and S/4 GS2 4 vCPU, 56 GB 6,900 10,000 250 MB/sec $ /h $ /h GS3 8 vCPU, 112 GB 11,870 20,000 500 MB/sec $ /h $ /h GS4 16 vCPU, 224 GB 448 GB 22,680 40,000 1,000 MB/sec Extremely high $ /h $ /h GS5 32 vCPU, 448 GB 896 GB 41,670 64 80,000 2,000 MB/sec $ /h $ /h OLAP and S4 E v3 E2s_v3 2 vCPU, 16 GB 32 GB 4,000 48 MB/sec Moderate SAP certification coming soon (Any DB, APP) E4s_v3 4 vCPU, 32 GB 64 GB 8,000 E8s_v3 8 vCPU, 64 GB 128 GB 16,000 E16s_v3 16 vCPU, 128 GB 256 GB 32,000 OLTP/OLAP SAP certification coming soon (Any DB, App, HANA) E32s_v3 32 vCPU, 256 GB 512 GB 64,000 Extremely High E64s_v3 64 vCPU, 432 GB 864 GB 128,000 1,200 MB/sec M M64s 64 vCPU, 1,024 GB 2,048 GB 67,315 Intel® Xeon® E v3 (Haswell) M64ms 64 vCPU, 1,792 GB 68,930 OLTP M128s 128 vCPU, 2,048 GB 4,096 GB 134,630 M128ms 128 vCPU, 4,096 GB Let’s first take a look at the Azure VM options for HANA applications – for both production and non-production workloads. As you can see on the current slide these options include DS series VMs – namely DS14_v2 and DS15_v2 – as well as GS series VMs, namely GS4 and GS5. Across these 4 VM sizes, we can implement systems supporting between 24,180 and 41,670 SAPS. The first three VM sizes are intended for non-production workloads, while the last one allows us to deploy SAP Business Warehouse on HANA, HANA Online Analytical Processing, and S/4HANA, with database of up to about half a TB in size. The size limit is imposed by the amount of memory available in GS5 – equal to 448 GB. HANA database and logs must reside on Premium Storage disks. This gives us effectively three choices of disk sizes – represented by the premium storage disk types – P10, P20, P30. Each size corresponds to specific number of IOPS per disk and throughput per disk. In particular, P10 gives us 128GB of storage with 500 IOPS and 100MB/sec throughput, P20 offers 512GB of storage with 2,300 IOPS and 150MB/s, and with P30, you get 1TB of storage with 5000 IOPS and 200 MBPs. If you want to further increase these values, in terms of storage space, IOPS, or throughput, you can create multi-disk volumes by using either MDADM or logical volume manager.

What is SAP HANA on Azure Large Instances ?
SAP TDI (Tailor Datacenter Integration) certified purpose built HANA hardware infrastructure hosted in Azure HANA server blade Storage hardware (persistent, 4 x RAM) Snapshot backup capability Storage replication capability in paired datacenter Volume encryption capability Network devices including backend ExpressRoute to connect to Azure VNET (10Gbps) Supported HANA scenarios OLAP : BW, BPC, Enterprise Edition, DWH, Side Car Scale Out to 60TB OLTP : Business Suite on HANA, S/4HANA, NetWeaver Scale Up to 20TB SKU # # CPU threads RAM (GB) HANA NFS Storage (GB) (persistent) Supported HANA scenarios SAP Certification + GA (* subject to change) HANA on Azure Large Instances Intel® Xeon® Processor E v3 (Haswell) SR72 72 768 3,072 OLAP/OLTP Certified SR72m 1,536 6,144 OLTP SR192 192 2,048 8,192 SR192m 4,096 16,384 HANA on Azure Very Large Instances Intel® Xeon® Processor E v4 (Broadwell) SR384 384 SR384m 18,432 SR384xm 22,528 SR576m 576 12,288 28,672 SR768m 36,864 SR960m 960 20,480 47,104 As we pointed out earlier, in addition to deploying Azure VMs to host HANA, you can also take advantage of the SAP HANA on Azure large instance offering. From the SKU perspective, there are four offerings that reflect different performance attributes. In each case, compute, memory, storage, and networking are pre-configured, however, you have the option of purchasing additional storage if required. This arrangement requires an Enterprise Agreement, since HANA large instance deployments are facilitated through its amendment. This gives customer a number of advantages, such as extending the benefits inherent to cloud solutions to bare-metal deployments, allowing minimizing or avoiding altogether capital expenditures. Customers can also take advantage of flexible payment terms available via Enterprise Agreement. Your choices depend on the SAP Solution you intend to implement. For OLAP workloads, including SAP Business Warehouse on SAP HANA, you can choose between 2CPU and 4 CPU Intel Xeon processor E v3 and v4, with up to 2 TB of memory and up to 8 TB of storage. Note that OLAP workloads support multi-node deployments, with up to 16 nodes, as stipulated by Tailored Datacenter Integration specifications, which yields the maximum of 32 TB of memory. For OLTP workloads, such as SAP Business Suite on HANA or S4/HANA, you get the same choice of CPUs but the amount of available memory and storage increases to 4TB and 16 TB, respectively. The new offerings are being introduced in July and December of 2017

SAP HANA on Azure Large Instances - Management
SAP Applications (including custom add-ons) SAP NetWeaver (Basis) SAP Kernel HANA DB OS Large instances of SAP HANA on Azure is a unique offering considering that it provides direct connectivity to Azure virtual machines but it runs on bare metal, without the virtualization layer. However, its support model still resembles the one applicable to a traditional IaaS-based service. The datacenter facility, hardware, storage, and networking are still supported by Microsoft. Microsoft also handles the installation of the operating system, but any SAP HANA specific customizations are performed by a customer. That customer is also responsible for installation of the SAP Kernel, HANA DB, and SAP NetWeaver, as well as SAP applications including any custom add-ons. HANA Hardware, Storage and Network Managed by Customer/Partner Datacenter Facility Managed by Microsoft

SAP HANA on Azure Large Instances - requirements
Microsoft Azure a subscription (1-1 relationship to the large instance tenant in a region) Microsoft Premier Mission Critical support (SAP Note ) Infrastructure ExpressRoute circuits From on-premises (1 Gbps or higher) From the large instance stamp (2 Gbps or10 Gbps) one or more Azure VNets (use VNet peering to minimize cross-VNet latency) Azure Resource Manager deployment model (Classic not supported) An NTP server VM on the Azure VNet Operating System SUSE Linux Enterprise Server 12 SP1 for SAP Applications SUSE Linux Subscription Management Tool (SMT) on an Azure VM Red Hat Enterprise Linux 6.7 or 7.2 for SAP HANA Red Hat Subscription Manager on an Azure VM Let’s review requirements that must be in place in order to provision AP HANA on Azure Large Instances You will need an Azure subscription, since connectivity to large instances is established from an Azure virtual network in the same region. There is also a 1-1 relationship between an Azure subscription and the large instance tenant in a given region. Customers also must have Microsoft Premier Mission Critical support, as stipulated in the SAP Note From the infrastructure standpoint, you will need two ExpressRoute circuits – one from on-premises (1 Gbps or higher) and the other, provisioned by Microsoft, from the large instance stamp (2 Gbps or10 Gbps). As mentioned earlier, you must have one or more Azure VNets. Your VNets should host an NTP server to ensure time synchronization between the application tier and the HANA large instance. Azure Large instances require Azure Resource Manager deployment model You can request a large instance running either SUSE Linux Enterprise Server 12 SP1 for SAP Applications or Red Hat Enterprise Linux 6.7 or 7.2 for SAP HANA. In either case, you must ensure that you have a mechanism to provide operating system updates, either in the form of SUSE Linux Subscription Management Tool (SMT) or Red Hat Subscription Manager running on an Azure VM.

SAP HANA on Azure Large Instances - networking
Routing Large instances are accessible only by Azure VMs (not directly from on-premises) Use a reverse proxy (e.g. F5 BIG-IP) if required No Internet connectivity (inbound or outbound) For each VNet One or more CIDR blocks for VNet subnets (/24 recommended) A /28 or /27 address range for VNet gateway subnet For each Azure region A CIDR block for the large instance NAT pool (/24 recommended) A /29 IP address range for P2P connections Large instances communicate via NAT-ed IP addresses ) Add the name to NAT IP mapping to global.ini (HANA) for SAP HANA clients [public\_hostname\_resolution] use\_default\_route = no map\_<hostname of Large Instances> = <NAT-ed IP Address> Add the name to NAT IP mapping to hosts files (App servers) Windows %windir%\system32\drivers\etc\hosts Linux /etc/hosts You also must address networking requirements. In particular, as far as routing is concerned, it is important to note that large instances are accessible only by Azure VMs on the adjacent VNet. In order to connect to large instances from your on-premises environment, you can leverage reverse proxy functionality offered by Marketplace virtual appliances, such as F5 BIG-IP. Large instances are not accessible directly from the Internet and they do not have Internet connectivity. To implement Azure VNets, you will need to designate one or more CIDR blocks for VNet subnets (/24 recommended) as well as a /28 or /27 address range for VNet gateway subnet. Communication to large instances is NAT-ed, which implies that for each Azure region, you will also need to allocate a CIDR block for the large instance NAT pool (/24 recommended) as well as a /29 IP address range for P2P connections. To account for NAT-ing, you also need to add the name to NAT IP mapping to global.ini (HANA) for SAP HANA clients and add the name to NAT IP mapping to hosts files (App servers).

SAP HANA on Azure Large Instances network diagram
Customer Corporate Network Azure IaaS Azure IaaS/VM HANA on Azure Large Instances Azure Virtual Network #1 ER P2P HANA Server Pool – Prod DB MPLS WAN Active Directory Availability Set SAP Business Suite S/4HANA, BW application servers HA Pair ER GW Subnet ExpressRoute/S2SVPN GW ER Active Directory HANA System Replication SAP Router Palo Alto Web Disp DMZ - SAP Fiori, Web Dispatcher, Gateway, SAP Router, Power BI Gateway, Linux Patching Server, 3rd party security appliance Managed Services Provider Review the diagram representing networking aspects of SAP deployment to Azure Large Instances SAP Support Internet SaaS, PaaS Azure Active Directory O365 Power BI Dynamics 365 Intune SCP Ariba SuccessFactors Concur Field Glass

SAP HANA options on Azure
A combination of VMs and purpose-built Large instances provides the largest scale and widest range for SAP HANA of any hyper-scale cloud G-series VMs for Dev/Test and PoC M-series VMs for most implementations SAP HANA Large Instances for extreme scale & performance In Azure, Microsoft provides highly scalable and performant infrastructure for HANA. Azure has virtual machines for dev/test, POCs as well as certified by SAP for production. They provide pay-as-you-go infrastructure with full certification for HANA and support upto ½ TB of RAM. SAP HANA Large Instances are based on purpose-built infrastructure for HANA, are fully managed with 99.99% SLA and have up to 4 TB RAM per node. This will be increasing over time. Microsoft is also investing in VMs that are capable of handling large HANA workloads. M-series VMs are expected to be certified by SAP by end 2017, with support for up to 3.5TB RAM per node. M-series are being launched in three waves: Wave 1 (all before end of CY17): US East 2, US West, West Europe, UK South, Australia East, Australia SE, JPN East, JPN West Wave 2 (in CY18): India, Canada East and Canada Central Wave 3: Other regions - Gov Cloud, Singapore, UK West, W Europe. No timeline here yet. On-demand infrastructure Purpose-built infrastructure Up to 0.5TB RAM Up to 4TB RAM Largest scale (up to 4TB RAM) Up to 20 TB RAM (from July)

M-Series Virtual Machines Massive memory, CPU, storage, and scale
Hyper-Threaded support Premium Storage support Based on Intel® Xeon® Processor E v3 High Performance DDR4 memory Support Nested Virtualization with Windows Server 2016 SAP Certified for Netweaver on AnyDB HANA certification soon Key talking points: The M-series is the largest instance size with up to 128 virtual cpu’s (VCPUs). These instances support premium storage for low latency workloads and are designed for the largest enterprise workloads. These have huge RAM sizes from 1.75TB to 4.0TB of RAM! M-series VMs are specifically optimized for large in-memory databases. They support hyper-threading and provide extremely low latency storage and network infrastructure, with up to 80,000 IOPS or 2,000 MBps for uncached disk I/O. For cached operations, the number of IOPS can effectively double. VM size vCPU’s Memory: TB Local SSD: TB Persistent Data Disks Max Network Bandwidth Availability M64s 64 1.0 2 Extremely high GA in US M64ms 1.75 M128s 128 2.0 4 M128ms 4.0 Launching soon

Microsoft NDA Content, subject to change
SAP on Azure Roadmap (*) DS v3 and E v3 will be available in all regions. UK South East US East US2 West US West US2 US Gov Virginia Canada East Canada Central North Europe West Europe Germany Central Australia East Australia Southeast Japan East Japan West Southeast Asia L G M G G G M L M M L L G G L M M G US Gov Arizona M L M M G Central India M South India M GS-series M-series M G G M HANA LARGE INSTANCES L G M L Generally available Coming in CY17 Coming in CY18 M L Microsoft NDA Content, subject to change

Qualifying SAP on Azure Opportunities (HANA, CY2017)
HANA Scenario and DB size Solution for HANA Database servers Solution for application servers 1 Dev and Test – 4TB DS13-15 v2 , GS3-5, M Series VM D v2 VMs (as needed) 2 OLAP and S/4HANA – 500GB GS5 VM 3 OLTP 768GB – 20TB HANA Large Instances OLTP Scale Up (single node) D v2 VMs 4 OLAP 768GB – 4TB HANA Large Instances OLAP Scale Up (single node) 5 OLAP 4 – 60TB HANA Large Instances OLTP Scale Out (multi nodes) *1) *2) *2) This is the table listing Azure service offering / for customers deploying SAP HANA / within this calendar year / Please note that this table is for HANA, / not for Any DB. / And also this table is the guidance for this calendar year, / and next CY is going to look different / with all the upcoming SAP certification / especially for M Series VM. Dev/Test up to 3.8TB of RAM –/ DS v2, GS, M Series VM / as SAP certification is usually not required. BTW M Series VM / is going to be certified / later this calendar year. OLAP and S/4HANA / up to half a TB of RAM – GS5 is the certified VM. / Note that S/4HANA is currently under controlled availability / and GBB and PEAT can support for SAP engagement. OLTP up to 20TB – HANA Large Instances offering / is purpose built bare metal SAP HANA infrastructure in Azure. This offering is available / in US, Europe and Australia / and will be available in Japan soon. OLAP up to 4TB - HANA Large Instances / scale up with a single node. OLAP up to 40TB - HANA Large Instances / scale out with multiple nodes – up to 15 nodes are fully supported by both SAP and Microsoft. *2) *1) S/4HANA with its HANA database on GS5 VM is under controlled availability *2) HANA Large Instances are available at US (East, West), EU (North, West), AU (East, Northeast) and will be at JP (East, West) *3) Have standby VM/blade for DB and AP if HA is required

Qualifying SAP on Azure Opportunities (HANA, CY2018)
HANA Scenario and DB size Solution for HANA Database servers Solution for application servers 1 Dev and Test – 3.8TB E v3, M Series VM E v3 VMs, D v3 VMs (as needed) 2 OLAP/OLTP GB E v3 Series VM 3 OLTP 1 – 4TB M Series VM 4 OLAP 1- 2TB 5 OLTP 2 – 20TB HANA Large Instances OLTP Scale Up (single node) E v3 VMs, D v3 VMs 6 OLAP 2 – 4TB HANA Large Instances OLAP Scale Up (single node) 7 OLAP 4 – 60TB HANA Large Instances OLAP Scale Out (multi nodes) *1) *1) *2) *2) *2) *1) M Series VMs will be available in US (East, East 2, West 2, Gov Virginia, Gov Arizona), CA (East, Central), EU (West, UK South), Asia (Southeast, AU East, AU Northeast, IN Central, IN South, JP East, JP West) *2) HANA Large Instances are available at US (East, West), EU (North, West), AU (East, Northeast) and will be at JP (East, West) *3) Have standby VM/blade for DB and AP if HA is required MS Confidential

S/4HANA, BW on HANA, HANA Enterprise, Side Car – Single VM 3-tier - Components
Customer Corporate Network Azure Datacenter East US 2 Azure Virtual Network #1 Storage Auto mation GW Subnet Subnet #1 – Prod Subnet #2 Mgmt MPLS WAN or Internet HANA Database Server(s) Prod Backup OMS Log Analytics Site Recovery Security Center 1 SAP Application Server(s) to scale out when needed 1 nodes x 448GB (RAM) uptime SLA : 99.9% 2TB SSD Storage Domain Controller, Monitoring, Backup Server, SAP Router in VM Site to Site VPN or ExpressRoute 4 2 3

S/4HANA, BW on HANA, HANA Enterprise, Side Car – Single VM 3-tier
Included Frontend ExpressRoute (customer – Azure VM) 500Mbps – Microsoft cost 5TB outbound (Azure VM -> outside) SAP application server VM x 1 node 4-core, 28GB of RAM, 6.6k SAPS / node Pay-per-use (* option : Compute Pre-Purchase) SAP HANA server VM x 1 node 448GB RAM / node 2TB SSD Storage / node Pay-per-use or 1-year commitment thru MS EA High-performance ExpressRoute Gateway NOT Included Frontend ExpressRoute (customer – Azure VM) 500Mbps – MPLS provider cost Software licenses of HANA, S/4 HANA applications, SUSE Linux or Red Hat Linux for SAP OS subscription Microsoft Premier Support Migration SI, Managed Services And let’s review its components

S/4HANA, BW on HANA, HANA Enterprise, Side Car, Suite on HANA – Single Blade 3-tier - Components
10Gbs backend ExpressRoute to HANA Large Instances is provisioned and managed by Microsoft 4 Customer Corporate Network Azure Datacenter East US ExpressRoute Azure IaaS/VM HANA on Azure Large Instances Azure Virtual Network ER P2P HANA Server Pool – Prod DB Storage Auto mation GW Subnet MPLS WAN Azure VM Subnet #1 – Prod AP Azure VM Subnet #2 – Management Blade - HA Pair NFS Storage MSEEs Backup OMS Log Analytics Express Route Azure VM Subnet #3 – Others Express Route Gateway Site Recovery Security Center Frontend ExpressRoute between customer on-prem and Azure IaaS is recommended Reverse proxy, Patch Server, Jump box, SAP Router running in VM 1-node x 4TB (RAM) HANA NFS storage 16TB x 1 Snapshot backup available 3 SAP Application Server(s) in VM 7 1 5 ExpressRoute Gateway High Perf 2Gbps or Ultra Perf 9Gbps is recommended 6 2

S/4HANA, BW on HANA, HANA Enterprise, Side Car, Suite on HANA – Single Blade 3-tier
Included Frontend ExpressRoute (customer – Azure VM) 1Gbps – Microsoft cost 10TB outbound (Azure VM -> outside) Backend ExpressRoute (Azure VM – HANA Large Instances) 10Gbps SAP application server VMs x 1 node 8-core, 56GB of RAM, 12.8k SAPS / node Pay-per-use (* option : Compute Pre-Purchase) SAP TDI certified HANA hardware x 1 node 4TB RAM / node 16TB NFS Storage / node SnapMirror backup available 1 or 3-year commitment thru MS EA Ultra-performance ExpressRoute Gateway NOT Included Frontend ExpressRoute (customer – Azure VM) 1Gbps – MPLS provider cost Software licenses of HANA, S/4 HANA applications, SUSE Linux or Red Hat Linux for SAP OS subscription Microsoft Premier Support Migration SI, Managed Services And let’s review its components

High Availability/Disaster Recovery Solutions
Now, let’s review the high availability and disaster recovery solutions available when deploying HANA on Azure.

RPO and RTO -> SAP HANA HA/DR Solutions in Azure
The two core concepts that should be taken into account when designing your high availability and disaster recovery strategy are Recovery Point Objective and Recovery Time Objective. Recovery Point Objective, or in short, RPO, represents the amount of potential data loss following a disaster recovery. The recovery time objective, or in short, RTO is the expected duration of time to restore a targeted functionality following a disaster. Note that, as the diagram on the current slide illustrates, restoring the operational state might actually take longer than RTO, since you must account for the detection period and performance ramp. In the context of this presentation, the primary mean for providing high availability and disaster recovery capabilities for Azure VM-based deployments is HANA DB system replication, which is part of native HANA capabilities. In general, Azure large instance supports the HA schemes supported by SAP HANA Tailored Datacenter Integration specifications. That includes HANA DB system replication, the use of standby nodes in multi-node deployments, or backup and restore of storage snapshots.

HA considerations for SAP deployments on Azure
SAP application layer has a single point of failure with SAP ASCS/SCS which is critical for whole SAP system Azure does not support shared disks to configure Windows failover cluster and run ASCS/SCS SIOS DataKeeper : host-based block-level replication for Windows Server to create a shared disk and failover cluster in public cloud using local disks Use SIOS Datakeeper to run SAP ASCS/SCS cluster Windows Failover Cluster As we already know based on earlier presentations included in this course, high availability provisions of SAP deployments must take into account both the database and the application tier. In particular, you should keep in mind that the SAP application layer, by default, contains a single point of failure in the form of the SAP ASCS/SCS component. The traditional approach to providing resiliency in this case is to implement a clustering solution. However, Azure platform does not support shared disks to configure Windows failover cluster. To remediate it, you can use third party solutions such as SIOS DataKeeper to emulate shared storage by relying on host-based block-level disk replication SIOS DataKeeper

Linux-based HA Architecture (SUSE)
Messaging/infrastructure (Corosync) carries Inter-node communication Resource allocation (Pacemaker) Cluster Resource Manager (CRM) coordinates changes and monitors state Cluster Information Base (CIB) in-memory XML representation of cluster configuration and status Policy Engine (PE) computes next cluster state in response to CIB changes Designated Coordinator (DC) manages CIB and initiates cluster-wide changes by relying on PE Local Resource Manager (LRM) manages local Resource Agents Fencing subsystem (STONITH) remote “power switch” Resource layer Resource-specific shell scripts SUSE Linux Enterprise High Availability Extension uses Pacemaker as CRM. The CRM is implemented as daemon (crmd) that has an instance on each cluster node. Pacemaker centralizes all cluster decision-making by electing one of the crmd instances to act as a master. Should the elected crmd process (or the node it is on) fail, a new one is established. A CIB, reflecting the cluster’s configuration and current state of all resources in the cluster is kept on each node. The contents of the CIB are automatically kept synchronous across the entire cluster. Many actions performed in the cluster will cause a cluster-wide change. These actions can include things like adding or removing a cluster resource or changing resource constraints. It is important to understand what happens in the cluster when you perform such an action. For example, suppose you want to add a cluster IP address resource. To do this, you can use one of the command line tools or the Web interface to modify the CIB. It is not required to perform the actions on the DC, you can use either tool on any node in the cluster and they will be relayed to the DC. The DC will then replicate the CIB change to all cluster nodes. Based on the information in the CIB, the PE then computes the ideal state of the cluster and how it should be achieved and feeds a list of instructions to the DC. The DC sends commands via the messaging/infrastructure layer which are received by the crmd peers on other nodes. Each crmd uses its LRM (implemented as lrmd) to perform resource modifications. The lrmd is not cluster-aware and interacts directly with resource agents (scripts). All peer nodes report the results of their operations back to the DC. After the DC concludes that all necessary operations are successfully performed in the cluster, the cluster will go back to the idle state and wait for further events. If any operation was not carried out as planned, the PE is invoked again with the new information recorded in the CIB. In some cases, it may be necessary to power off nodes to protect shared data or complete resource recovery. For this Pacemaker comes with a fencing subsystem, stonithd. STONITH is an acronym for “Shoot The Other Node In The Head” and is usually implemented with a remote power switch. In Pacemaker, STONITH devices are modeled as resources (and configured in the CIB) to enable them to be easily monitored for failure. However, stonithd takes care of understanding the STONITH topology such that its clients simply request a node be fenced and it does the rest.

SAP HANA Large Instance HA
SLA 99.99% Implementation: two or more identical SAP HANA on Azure large instances deployed in the same region configured by the customer for system replication at the application layer. declared as the members of a High Availability Pair to Microsoft during the architecture design process. HA deployments of SAP HANA large instance offer the availability SLA of 99.99%. Such deployments consist of two or more identical SAP HANA on Azure large instances, deployed in the same region, configured by the customer for system replication at the application layer, and declared as the members of a High Availability Pair to Microsoft during the architecture design process.

SAP HANA VM HA SLA 99.95% Implementation:
Up to three VMs in the same availability set (behind a load balancer) configured by the customer for system replication at the application layer Linux HA extensions (SUSE, RedHat) Multi-disk configuration (LVM recommended): /hana/data /hana/log /hana/shared Cluster software HANA HA package STONITH device An Azure AD application and a service principal SAP HANA resources HA deployments of SAP HANA on Azure VMs offer the availability SLA of 99.95%. Such deployments consist of up to three VMs in the same availability set (behind a load balancer), are configured by the customer for system replication at the application layer, rely on Linux HA extensions (SUSE, RedHat) to deliver high-availability functionality, typically include multi-disk configuration (LVM recommended) to host the /hana/data, /hana/log, and /hana/shared volumes. They are running open-source cluster software, with HANA HA resource agents and the STONITH device configured as an Azure AD application and a service principal.

(*) High Availability of SAP database and SAP SCS/ASCS
DB layer : HANA System Replication SAP (SCS/ASCS) layer : WSFC with SIOS Datakeeper DB DB SAP AP SAP AP SAP AP (*1) SAP SCS/ASCS application servers usually need very small amount of server resources HANA System Replication SAP SCS/ASCS (*1) SAP SCS/ASCS (*1) SAP SCS/ASCS Application (Message/Enqueue) Note that in order to provide high availability on the SAP system level, you would combine the application high availability with the database high availability. The current slide illustrates this approach. We are using Windows Server Failover Cluster with SIOS DataKeeper Cluster Edition to provide high availability of the SAP ASCS/SCS application components, including the message and enqueue services. We also rely on the HANA system replication to implement high availability on the database level. Windows Server Failover Cluster DB DB DB Sync Replica SIOS DataKeeper Cluster Edition SAP SAP Block-level Sync Replica

Failover of SAP database and SAP SCS/ASCS
Auto failover 3-tier DB DB SAP AP SAP AP SAP AP Auto failover HANA System Replication SAP SCS/ASCS (*1) SAP SCS/ASCS (*1) SAP SCS/ASCS Application (Message/Enqueue) Scheduled scale out/up/in/down Windows Server Failover Cluster A failover in this configuration would be automatic on the application level. It is possible to implement failover on the database level as well. However, it is important to point out that HANA System Replication does not include such functionality. Instead, you would need to leverage either the platform or server level capabilities. For example, SUSE Linux Enterprise Server supports SUSE High Availability Extension which is available in the ‘SUSE for SAP Applications’ distribution images from Azure. Such capability is supported by Azure Large Instances, which can be deployed in a paired configuration. Note though that implementing automatic failover is the customer’s responsibility. DB DB DB Sync Replica SIOS DataKeeper Cluster Edition SAP Block-level Sync Replica SAP

S/4HANA, BW on HANA, HANA Enterprise, Side Car – VM with HA - Components
ExpressRoute is recommended 1 Customer Corporate Network Azure Datacenter East US 2 Azure Virtual Network #1 Storage Auto mation GW Subnet Subnet #1 – AP Prod Subnet #2 – DB Prod Subnet #3 Mgmt Availability Set SAP ASCS MPLS WAN HANA Database Server(s) Prod Availability Set Availability Set SAP AP MSEE Backup OMS Log Analytics Express Route Availability Set NFS Share Express Route Gateway Site Recovery Security Center Highly available SAP ASCS and NFS Clusters uptime SLA 99.95% 2-node x 448GB (RAM) HANA System Replication Cluster uptime SLA : 99.95% 2TB SSD Storage 2 3

S/4HANA, BW on HANA, HANA Enterprise, Side Car – VM with HA - Components
Included Frontend ExpressRoute (customer – Azure VM) 500Mbps – Microsoft cost 5TB outbound (Azure VM -> outside) SAP application server VMs x 2 nodes 4-core, 28GB of RAM, 6.6k SAPS / node Uptime SLA : 99.95% Failover cluster configurable Pay-per-use (* option : Compute Pre-Purchase) SAP HANA server VMs x 2 nodes 448GB RAM / node 2TB SSD Storage / node HANA System Replication configurable Pay-per-use or 1-year commitment thru MS EA High-performance ExpressRoute Gateway NOT Included Frontend ExpressRoute (customer – Azure VM) 500Mbps – MPLS provider cost Software licenses of HANA, S/4 HANA applications, SUSE Linux or Red Hat Linux for SAP OS subscription, cluster software (e.g. SIOS) Microsoft Premier Support Migration SI, Managed Services And let’s review its components

S/4HANA, BW on HANA, HANA Enterprise, Side Car, Suite on HANA – Blade HA
10Gbs backend ExpressRoute to HANA Large Instances is provisioned and managed by Microsoft 4 Customer Corporate Network Azure Datacenter East US ExpressRoute Azure IaaS/VM HANA on Azure Large Instances Azure Virtual Network ER P2P HANA Server Pool – Prod DB Storage Auto mation GW Subnet MPLS WAN Availability Set SAP ASCS Azure VM Subnet #1 – Prod AP Azure VM Subnet #2 – Management Blade - HA Pair NFS Storage Availability Set SAP AP MSEEs Backup OMS Log Analytics Express Route Azure VM Subnet #3 – Others Availability Set NFS Share Express Route Gateway Site Recovery Security Center Frontend ExpressRoute between customer on-prem and Azure IaaS is recommended Reverse proxy, Patch Server, Jump box, SAP Router running in VM 2-node x 4TB (RAM) HANA System Replication Cluster uptime SLA : 99.99% NFS storage 16TB x 2 Snapshot backup available 3 Highly available SAP ASCS and NFS on Linux Clusters – VM uptime SLA : 99.95% 7 1 ExpressRoute Gateway High Perf 2Gbps or Ultra Perf 9Gbps is recommended 5 6 2

S/4HANA, BW on HANA, HANA Enterprise, Side Car, Suite on HANA – Blade HA - Components
Included Frontend ExpressRoute (customer – Azure VM) 500Mbps – Microsoft cost 5TB outbound (Azure VM -> outside) SAP application server VMs x 2 nodes 4-core, 28GB of RAM, 6.6k SAPS / node Uptime SLA : 99.95% Failover cluster configurable Pay-per-use (* option : Compute Pre-Purchase) SAP HANA server VMs x 2 nodes 448GB RAM / node 2TB SSD Storage / node HANA System Replication configurable Pay-per-use or 1-year commitment thru MS EA High-performance ExpressRoute Gateway NOT Included Frontend ExpressRoute (customer – Azure VM) 500Mbps – MPLS provider cost Software licenses of HANA, S/4 HANA applications, SUSE Linux or Red Hat Linux for SAP OS subscription, cluster software (e.g. SIOS) Microsoft Premier Support Migration SI, Managed Services And let’s review its components

S/4HANA, BW on HANA, HANA Enterprise, Side Car – VM with HA/DR
2 nodes x 448GB (RAM) HANA System Replication Cluster uptime SLA : 99.95% 2TB SSD Storage 4 Highly available SAP ASCS and NFS on Linux Clusters – VM uptime SLA : 99.95% 2 Azure Datacenter East US 2 Azure Virtual Network #1 Storage Auto mation GW Subnet Subnet #1 – AP Prod Subnet #2 – DB Prod Subnet #3 Mgmt Availability Set SAP ASCS HANA Database Server(s) Prod Availability Set Customer Corporate Network Availability Set SAP AP MSEE Backup OMS Log Analytics Express Route Availability Set NFS Share Express Route Gateway Site Recovery Security Center HANA System Replication for async volume replica MPLS WAN 3 Azure Datacenter West US Azure Virtual Network #2 Auto mation GW Subnet Subnet #4 – AP DR Subnet #5 – DB DR Subnet #6 Mgmt Storage Availability Set SAP ASCS HANA Database Server(s) Prod Availability Set SAP AP Express Route MSEE Backup OMS Log Analytics One ExpressRoute contract can connect to all datacenters in a geopolitical region (e.g. All US DCs) Availability Set NFS Share Express Route Gateway 1 Site Recovery Security Center Shutdown VMs when unused (then no Compute charge) 5

S/4HANA, BW on HANA, HANA Enterprise, Side Car – VM with HA/DR - Components
Included Frontend ExpressRoute (customer – Azure VM) 500Mbps – Microsoft cost 5TB outbound (Azure VM -> outside) SAP application server VMs x 2 nodes 4-core, 28GB of RAM, 6.6k SAPS / node Uptime SLA : 99.95% Failover cluster configurable Pay-per-use (* option : Pre-Purchase ) SAP HANA server VMs x 3 nodes 448GB RAM / node 2TB SSD Storage / node HANA System Replication configurable Pay-per-use or 1-year commitment thru MS EA High-performance ExpressRoute Gateway NOT Included Frontend ExpressRoute (customer – Azure VM) 500Mbps – MPLS provider cost Software licenses of HANA, S/4 HANA applications, SUSE Linux or Red Hat Linux for SAP OS subscription, cluster software (e.g. SIOS) Microsoft Premier Support Migration SI, Managed Services Now let’s review a HA/DR architecture that involves S/4HANA, BW on HANA, HANA Enterprise, Side Car on an Azure Large Instance

S/4HANA, BW on HANA, HANA Enterprise, Side Car, Suite on HANA – Blade HA/DR
Azure Datacenter East US ExpressRoute Azure IaaS/VM HANA on Azure Large Instances Azure Virtual Network ER P2P HANA Server Pool – Prod DB Storage Auto mation GW Subnet Availability Set SAP ASCS Azure VM Subnet #1 – Prod AP Azure VM Subnet #2 – Management Blade - HA Pair NFS Storage Customer Corporate Network Availability Set SAP AP MSEEs Backup OMS Log Analytics Express Route Azure VM Subnet #3 – Others Availability Set NFS Share Express Route Gateway Site Recovery Security Center MPLS WAN 2-node x 4TB (S192m) HANA System Replication Cluster uptime SLA : 99.99% 2 NFS Storage Replication 3 Azure Datacenter West US ExpressRoute Azure IaaS/VM HANA on Azure Large Instances Here’s the reference architecture / for HANA on Azure Large Instances. First of all / #1 – HANA Large Instances environment / is hosted / in a colocation datacenter section / behind Azure VM . And #2 – / 10Gbps backend expressRoute / connect between Azure VM and Large Instances. This backend network / is included / in the prices of Large Instances / and is provided / and managed by Microsoft. #3 HANA System Replication / in a HA pair / provide SLA of / 99.99%, / four nines. #4 NFS storage hardware / is also included in the service / and storage snapshot backup capability / is available. And lastly #5 Customer can enable / HANA “Storage” replication / through Microsoft backbone network. Azure Virtual Network ER P2P HANA Server Pool – DR DB Storage Auto mation GW Subnet Availability Set SAP ASCS Azure VM Subnet #1 – DR AP Azure VM Subnet #2 – Management Blade NFS Storage Availability Set SAP AP Express Route MSEEs Backup OMS Log Analytics One ExpressRoute contract can connect to all datacenters in a geopolitical region (e.g. All US DCs) Azure VM Subnet #3 – Others Express Route Gateway Availability Set NFS Share 1 NFS storage 16TB for Storage Replication target 4 Shutdown VMs when unused (then no Compute charge) Site Recovery Security Center 5

S/4HANA, BW on HANA, HANA Enterprise, Side Car, Suite on HANA – Blade HA/DR - Components
Included Frontend ExpressRoute (customer – Azure VM) 1Gbps – Microsoft cost 10TB outbound (Azure VM -> outside) Backend ExpressRoute (Azure VM – HANA Large Instances) 10Gbps SAP application server VMs x 2 nodes 8-core, 56GB of RAM, 12.8k SAPS / node Uptime SLA : 99.95% Failover cluster configurable Pay-per-use (* option : Pre-Purchase ) SAP TDI certified HANA hardware x 3 nodes 4TB RAM / node 16TB NFS Storage / node SnapMirror backup available Uptime SLA : 99.99% HANA System Replication and Storage Replication configurable Storage West US 1 or 3-year commitment thru MS EA Ultra-performance ExpressRoute Gateway NOT Included Frontend ExpressRoute (customer – Azure VM) 1Gbps – MPLS provider cost Software licenses of HANA, S/4 HANA applications, SUSE Linux or Red Hat Linux for SAP OS subscription, cluster software (e.g. SIOS) Microsoft Premier Support Migration SI, Managed Services And let’s review its components

BW on HANA, HANA Enterprise – Scale Out Blade with HA
10Gbs backend ExpressRoute to HANA Large Instances is provisioned and managed by Microsoft 4 Customer Corporate Network Azure Datacenter East US ExpressRoute Azure IaaS/VM HANA on Azure Large Instances Azure Virtual Network ER P2P HANA Server Pool – Prod DB Storage Auto mation GW Subnet MPLS WAN Availability Set SAP ASCS Azure VM Subnet #1 – Prod AP Azure VM Subnet #2 – Management Blade – Scale Out NFS Storage Availability Set SAP AP MSEEs Backup OMS Log Analytics Express Route Azure VM Subnet #3 – Others Availability Set NFS Share Express Route Gateway Site Recovery Security Center Frontend ExpressRoute between customer on-prem and Azure IaaS is recommended Reverse proxy, Patch Server, Jump box, SAP Router running in VM 3-node x 2TB (RAM) HANA Scale Out NFS storage 8TB x 3 Snapshot backup available 3 Highly available SAP ASCS and NFS on Linux Clusters – VM uptime SLA : 99.95% 7 1 5 ExpressRoute Gateway High Perf 2Gbps or Ultra Perf 9Gbps is recommended 6 2

BW on HANA, HANA Enterprise – Scale Out Blade with HA - Components
Included Frontend ExpressRoute (customer – Azure VM) 1Gbps – Microsoft cost 10TB outbound (Azure VM -> outside) Backend ExpressRoute (Azure VM – HANA Large Instances) 10Gbps SAP application server VMs x 2 nodes 8-core, 56GB of RAM, 12.8k SAPS / node Pay-per-use (* option : Pre-Purchase ) SAP TDI certified HANA hardware x 3 nodes 2TB RAM / node 8TB NFS Storage / node SnapMirror backup available HANA System Replication and Storage Replication configurable 1 or 3-year commitment thru MS EA Ultra-performance ExpressRoute Gateway NOT Included Frontend ExpressRoute (customer – Azure VM) 1Gbps – MPLS provider cost Software licenses of HANA, BW applications, SUSE Linux or Red Hat Linux for SAP OS subscription, cluster software (e.g. SIOS) Microsoft Premier Support Migration SI, Managed Services And let’s review its components

BW on HANA, HANA Enterprise – Scale Out Blade with HA/DR
NFS storage 8TB x 5 Snapshot backup available Azure Datacenter East US ExpressRoute 2 Azure IaaS/VM HANA on Azure Large Instances Azure Virtual Network ER P2P HANA Server Pool – Prod DB GW Subnet Availability Set SAP ASCS Azure VM Subnet #1 – Prod AP Azure VM Subnet #2 – Management Blade – Scale Out NFS Storage Customer Corporate Network Availability Set SAP AP MSEEs Express Route Azure VM Subnet #3 – Others Availability Set NFS Share Express Route Gateway MPLS WAN 3 5-node x 2TB (RAM) HANA Scale Out 1 NFS Storage Replication Azure Datacenter West US ExpressRoute Azure IaaS/VM HANA on Azure Large Instances Azure Virtual Network ER P2P HANA Server Pool – QA/DR DB GW Subnet Availability Set SAP ASCS Azure VM Subnet #1 – DR AP Azure VM Subnet #2 – Management Blade – Scale Out NFS Storage NFS Storage Availability Set SAP AP Express Route MSEEs Azure VM Subnet #3 – Others Availability Set NFS Share Express Route Gateway 8 TB x 5 Storage Replication target 4

BW on HANA, HANA Enterprise – Scale Out Blade with HA/DR - Components
Included Frontend ExpressRoute (customer – Azure VM) 1Gbps – Microsoft cost 10TB outbound (Azure VM -> outside) Backend ExpressRoute (Azure VM – HANA Large Instances) 10Gbps SAP application server VMs x 4 nodes 4-core, 28GB of RAM, 6.6k SAPS / node Pay-per-use (* option : Pre-Purchase ) Uptime Prod : 744 hours /month (=24 x 7) QA/Dev : 200 hours /month SAP TDI certified HANA hardware x 6 nodes 2TB RAM / node 8TB NFS Storage / node SnapMirror backup available HANA System Replication and Storage Replication configurable 1 or 3-year commitment thru MS EA Ultra-performance ExpressRoute Gateway NOT Included Frontend ExpressRoute (customer – Azure VM) 1Gbps – MPLS provider cost Software licenses of HANA, BW applications, SUSE Linux or Red Hat Linux for SAP OS subscription, cluster software (e.g. SIOS) Microsoft Premier Support Migration SI, Managed Services And let’s review its components

SAP HANA on Azure Pricing Tips
Estimate uptime of each Azure VM Especially Non-Production systems Use Compute Pre-purchase Plan (CPP) for Azure VM VMs that are 24 x 7 Use 3-year commitment for HANA Large Instances “Step-up” SKUs available to start small Make sure to include costs for storage and VPN/ExpressRoute Gateway Make sure to quote costs for SAP licenses, OS (RHEL/SLES) licenses and Microsoft Support In case of HANA Large Instances Premier Support is required Tips to calculate costs of Azure / very accurately / so that you win every SAP opportunity by design - / #1 (CLICK) VM uptime is a critical input / for Compute Cost. #2 (CLICK) – think about using Compute Pre-purchase Plan – / or CPP / for VMs that need to be 24 x 7. CPP is a VM discount program / with 1-year pre-commit / which is available through Microsoft Enterprise Agreement / or EA. #3 (CLICK) –licensing of HANA Large Instances is / 1 or 3-year commitment, / there’s no pay-per-use – / and 3-year / s much more cost efficient / than 1-year. Note that ‘step-up’ SKUs are available / so that customer can start small / with a small SKU / let’s say 1.5TB / and switch to a larger SKU / say 4TB / even during the commitment period, / and paying only delta. #4 (CLICK) – make sure to include storage and network / in the bill of material. #5 (CLICK) – make sure to ask customer / to quote / SAP licenses, / linux os licenses / and Microsoft Support/ separately from our proposal. Note that / in case HANA Large Instances is used/ Microsoft Premier Support is required.

T-Shirt Pricing Model (HANA)
# DB/memory size (GB) HANA scenario HANA DB HANA # of vCPUs/threads SSD/NFS Storage (GB) ExpressRoute Note 1 448 OLAP/S4HANA Scale up, VM 32 2048 500Mbps App servers on VM, Storage, ER, QA included 2 768 OLAP/OLTP Scale up, Large 72 3072 3 1536 OLTP 6144 1Gbps 4 192 8192 5 4096 16384 6 OLAP Scale Out, Large 576 24576 7 1024 OLAP/OLTP Scale up, VM 64 4096 500Mbps App servers on VM, Storage, ER, QA included 8 1792 OLTP 7168 1Gbps 9 2048 128 8192 10 3891.2 10240

HANA DB T-Shirt Pricing Model
HANA : 448GB RAM, (GS5 VM) 32 vCPUs, 2TB SSD Storage App servers on VM, OLAP/OLTP 500Mbps ExpressRoute, Prod + QA HANA : 768GB RAM, (S72, SR72) 72 threads, 3TB NFS Storage App servers on VM, OLAP/OLTP 500Mbps ExpressRoute, Prod + QA HANA : 1.5TB RAM, (S72m, SR72m) 72 threads, 6TB NFS Storage App servers on VM, OLTP 1Gbps ExpressRoute, Prod + QA This slide - / SAP on Azure T-shirt pricing model / for HANA DB. - by HANA DB memory size / 448GB to 6TB, / by licensing model / pay as you go, 1 year or 3 year / and by service level / single, HA or HA+DR. Azure and HANA Large Instances are / very cost effective by design, / that’s how we priced our offering, / and your customer is very likely to be surprised /to see these prices from us. HANA : 6 TB (3 x 2TB) RAM, (S192, SR192) 3-node scale out 576 threads, 24TB Storage App servers on VM, OLAP 1Gbps ExpressRoute, Prod + QA HANA : 2TB RAM, (S192, SR192) 192 threads, 8TB NFS Storage App servers on VM, OLAP/OLTP 1Gbps ExpressRoute, Prod + QA HANA : 4TB RAM, (S192m, SR192m) 192 threads, 16TB NFS Storage App servers on VM, OLTP 1Gbps ExpressRoute, Prod + QA

HANA DB T-Shirt Pricing Model (M-series)
HANA : 1TB RAM, (M64s VM) 64 vCPUs, 4TB SSD Storage App servers on VM, OLAP/OLTP 500Mbps ExpressRoute, Prod + QA HANA : 1.75TB RAM, (M64ms VM) 64 vCPUs, 7TB SSD Storage App servers on VM, OLAP/OLTP 1Gbps ExpressRoute, Prod + QA This slide - / SAP on Azure T-shirt pricing model / for HANA DB with M-series VMs HANA :2TB RAM, (M128s VM) 128 vCPUs, 8TB SSD Storage App servers on VM, OLAP/OLTP 1Gbps ExpressRoute, Prod + QA HANA :3.8TB RAM, (M128ms VM) 128 vCPUs, 10TB SSD Storage App servers on VM, OLAP/OLTP 1Gbps ExpressRoute, Prod + QA

SAP HANA Dev/Test/DR Environment in Azure
Now let’s take a closer look at deployment strategy of SAP HANA Development, Test, and DR Environments in Azure

SAP/HANA Dev/Test on Azure Characteristics
Scripted and automated Dev/Test deployment Automated Dev/Test shutdown Support for Windows and Linux Typically the first step of Cloud Migration 1 4 2 Let’s start with the common characteristics of SAP/HANA Dev/Test environments on Azure Such characteristics typically include the need for automated deployment, automated maintenance, shutting down virtual machines during idle periods, as well as support for both Windows and Linux. Their deployment also typically constitutes the first step in migration from on-premises to Azure. 3

Setting Up SAP HANA Enterprise Edition on Azure VM
Software : SAP HANA Platform Edition 1.0 SPS12 OS : SUSE Linux Enterprise Server for SAP 12 SP2 Local Host Name : hana-dbsrv OS user : demouser Location : US West VM size : Standard_GS4 (16 core, 224GB RAM) Storage account : Premium Storage Disks: 4 x P20 disks for HANA database (/hana/data) 1 x P20 disks for HANA database log (/hana/log) 1 x P20 disk for /hana/shared 1 x P20 disk for /usr/sap Resource Group : hana-rg Virtual network : hana-vnet Installation Path :/hana/shared SAP HANA System ID: AZD Instance number: 00 Database Mode : single_container Location of Data Volumes : /hana/data/AZD Location of Log Volumes : /hana/log/AZD System Administrator Home Directory: /usr/sap/AZD/home System Administrator Login Shell: /bin/sh System Administrator User ID: 487 ID of User Group (sapsys): 1001 ` TCP 22 (SSH) inbound ` Putty SAP HANA Studio Internet TCP 30015 (HANA) inbound Here is our sample design, implementation of which we will step through in our next presentation. We deploy a single Azure VM running SAP HANA Platform Edition 1.0 SP12 on SUSE Linux Enterprise Server for SAP 12 SP2. The target Azure region is US West, the VM size is Standard_GS4 with 16 cores and 224GB of RAM, and we use Premium Storage to host the database and log files. In particular, we create a RAID 0 array consisting of 4 P20 disks for HANA database which will be mounted as /hana/data and store HANA database log on a single P20 disk that which will be mounted as /hana/log. In addition, we will use a couple of extra P20 disks to host /hana/shared content and /usr/sap for the local SAP system instance directories. As part of the SAP setup, we assign the SAP HANA System ID of AZD. Our implementation creates a single container database, with its data located in /hana/data/AZD and its log in /hana/log/AZD. We access the VM over the Internet via standard SSH port TCP 22. We also open TCP port to allow access via SAP HANA studio. Azure Premium Storage

Setting Up SAP NetWeaver on SAP HANA Enterprise on Azure VM
SAP HANA Studio ` Software : SAP NetWeaver 7.5 ABAP OS : Windows Server 2012 R2 Local Host Name : hana-appsrv OS user : demouser Location : US West VM size : Standard_DS3 (4 core, 14GB RAM) Virtual network : hana-vnet Resource Group : hana-rg SAP System ID: AZH Instance Number : 00 TCP (HANA) TCP 3389 (RDP) ` SAP GUI SAP NetWeaver 7.5 SAP HANA R2 TCP 3200 (SAP) And here is the application tier of our sample design. We deploy another VM into the same virtual network. The VM will be running SAP NetWeaver 7.5 ABAP stack on Windows Server 2012 R2. We use Standard_DS3 VM with 4 CPU cores and 14GB of RAM, assign the SAP System ID of AZH, and set the instance number to 00. In addition to standard RDP traffic, we also allow inbound traffic via TCP port 3200 to accommodate SAP GUI connections. Azure Blob Storage Azure Premium Storage Microsoft PowerBI

Automated & Scripted SAP System Copy to Azure with Azure Resource Manager
(*)AzCopy does not require S2S VPN or ExpressRoute You can use SAP Migration Monitor ftp Consider using DS15v2 for import Azure Storage Azure Market Place Azure Active Directory Authenticate SAP Inst Master ***** ***** Azure Resource Manager Deployment of Base VMs using ARM Win2012R2 + SQL2014 SUSE Enterprise12 Customer Corporate network Automation Features PowerShell DSC Copy SAP Silent Install/ Import using DSC Azure Virtual Machines Exp files Backup/Export (Az)Copy (*) Exp files (Az)Copy 1 Admin Access Tester Access 2 To automate the process of deployment of our development and test environment, we leverage a number of features provided as part of SAP and Azure platform. We start by performing SAP System Copy-based export and then use AzCopy to transfer exported files to Azure storage. Next, we provision Azure virtual machines that will be hosting our development, test, or DR environment with Azure Resource manager templates and customize their operating system settings, including importing content exported from on-premises systems with PowerShell Desired State Configuration. Finally, we apply Role Based Access control via Azure Active Directory tenant linked to our Azure subscription to control administrative and tester access. Azure Virtual Network, ExpressRoute etc 3 Role Based Access Control

SAP HANA VM Backup on Azure
Currently no integration between Azure Backup service and HANA backup API Backup to the file system Azure Backup agent not supported on Linux VMs Use HANA native backup methods (SAP HANA Studio, SAP GUI with ABAP DBACOCKPIT/DB13, SAP HANA Admin Console) Followed by copy to Azure blob or file storage Built-in integrity and consistency You must account for extra file system space on local disk for backup files Backup based on storage snapshots Using Azure Storage Blob snapshots Using Azure VM level backup Requires additional provisions to ensure integrity and consistency Regardless of the backup method, ensure to back up HANA configuration files No support for backups of a secondary replica (SAP HANA limitation) To verify backups: Run hdbbackupdiag and hdbbackupcheck to confirm integrity of the catalog/metadata Perform a restore and run table consistency checks (SAP Note ) Currently, there is no integration between Azure Backup service and HANA backup API. As the result, in order to implement SAP HANA VM Backup on Azure, you will need to use either the file system or snapshot based backups. When backing up to the file system, you will not be able to use the Azure Backup agent, since at this point, there is no agent available on Linux OS. The backup process will involve the use of HANA native backup method, followed by a copy to Azure blob or file storage. This ensures backup integrity and consistency although you must account for extra file system space on local disk for backup files. The other option involves the use of storage snapshots. You can perform such snapshots either on the Azure Storage Blob level or the Azure VM level backup. In either case, you must implement additional provisions to ensure integrity and consistency. Regardless of the backup method, you should include HANA configuration files in your backups. Note that currently there is no support from SAP for backups of a secondary replica. To verify backups, run hdbbackupdiag and hdbbackupcheck, which allows you to confirm integrity of the catalog/metadata. You should also perform a test restore and run table consistency checks, as stipulated in the SAP Note

SAP HANA VM Backup on Azure – local file system
Run backup locally using HANA native methods and then transfer to Azure storage Use blobxfer from within the Azure VM Support for md5 hash and automatic parallelism Consider impact on the VM I/O performance Use Start-AzureStorageBlobCopy Attach dedicated backup VHDs Unmount or freeze (via xfs_freeze) prior to copy Does not impact the VM I/O performance Azure blob (up to 500 TB limit, with 1 TB per file) Consider using “cool” blob storage Use a GRS Azure storage account for region-level resiliency Azure file (up to 5 TB limit, with 1 TB per file) Direct backup to CIFS mount not yet supported by SAP Backup duration dependent on disk I/O performance Premium Storage (P10 – 100 MB/s 500 IOPS, P20 – 150 MB/s 2300 IOPS, P30 – 200 MB/s 5000 IOPS) Aggregate throughput with multi-disk volumes (take into account the VM SKU I/O limits) To improve performance, split backup into multiple files Limit maximum file size from HANA Studio Does not affect HANA backup time (sequential writes) but improves blobxfer due to parallelism When backing up SAP HANA to local file system, you run backup locally using HANA native methods and then transfer the resulting dump files to Azure storage. To perform file transfer, you can use blobxfer from within the Azure VM . The tool supports generating md5 hash and automatic parallelism. On the flipside, using this approach introduces potential impact on the VM I/O performance. To minimize such impact, you might consider modifying this approach and relying on the Start-AzureStorageBlobCopy cmdlet. In this case, before starting the backup process, you first attach dedicated backup VHD and, once the backup completes, you unmount it or freeze the file system (via xfs_freeze) prior to copy. When copying backups to Azure storage, consider using Azure “cool” blob storage. If you want to ensure that your backups remain available even in the case of a regional failure, use a GRS Azure storage account. Backup duration is dependent on disk I/O performance. With premium storage, this depends on the disk size. You can further improve throughput by creating multi-disk volumes, although you also need to consider the VM throughput limits. You also might consider splitting backup into multiple files to further improve performance.

SAP HANA VM Backup on Azure – Storage snapshots
Based on SAP HANA snapshots: Single container-systems only (no support for multi-tenant containers) - SAP Note Backup: 1 – Perform SAP HANA snapshot 2 – Run xfs_freeze - HANA must be in disk-consistent state before storage snapshot starts 3 – Perform storage snapshot 4 – Perform file system unfreeze 5 – Perform SAP HANA snapshot confirmation (BACKUP DATA CLOSE SNAPSHOT) Updates the catalog and removes the SAP HANA snapshot Ensures that snapshot does not cause excessive local file system usage Required in order to start another backup Restore: 1 – Shut down the Azure VM 2 – Detach the data disks 3 – Overwrite the data disks with the storage snapshots 4 – Attach the data disks to the Azure VM 5 – Restore SAP HANA snapshot When using storage snapshots to back up SAP HANA running in Azure VMs, you typically combine them with SAP HANA snapshots. Note that currently this is supported only on single container-systems, as stipulated in the SAP Note The backup consists of the following steps: Performing a SAP HANA snapshot Running xfs_freeze to ensure that HANA is in the disk-consistent state before storage snapshot start Performing a storage snapshot Performing the file system unfreeze Confirming the SAP HANA snapshot (BACKUP DATA CLOSE SNAPSHOT). The last step is necessary in order to update the catalog and removing the SAP HANA snapshot, ensuring that snapshot does not cause excessive local file system usage. This is also necessary before you can start another backup To perform a restore: you: Shut down the Azure VM Detach the data disks Overwrite the data disks with the storage snapshots Attach the data disks to the Azure VM Restore SAP HANA snapshot

SAP HANA VM Backup on Azure – VM level backup
File system-consistent (not application consistent) on Linux (VSS is Windows-specific) Backup: Two phases: Azure Backup service snapshot (a few minutes) Transfer data to the Azure Recovery vault (dependent on the amount of data to back up) Confirm the HANA snapshot once the Azure Backup service snapshot phase is completed Automate via Azure PowerShell (the status of the first phase must be Complete) $ars = Get-AzureRmRecoveryServicesVault -Name hana-backup-vault Set-AzureRmRecoveryServicesVaultContext -Vault $ars $jid = Get-AzureRmRecoveryServicesBackupJob -Status InProgress | Select-Object -ExpandProperty jobid Get-AzureRmRecoveryServicesBackupJobDetails -Jobid $jid | Select-Object -ExpandProperty subtasks $st = Get-AzureRmRecoveryServicesBackupJobDetails -Jobid $jid | Select-Object -ExpandProperty subtasks $st[0] | select -ExpandProperty status Restore: Requires creation of a new VM a new SAP HANA license key is needed (SAP hardware key depends on VM ID, which is unique for a new VM) File level restore currently in preview Another possibility is to perform VM level backup. If you use this approach, you must keep in mind that the resulting backup Is file-system – not application consistent when dealing with Linux VMs. A VM-level backup is divided into two phases: Azure Backup service snapshot (a few minutes) Transfer data to the Azure Recovery vault (dependent on the amount of data to back up) Once the first of these two phases is complete, you can confirm the HANA snapshot The backup process can be automated via Azure PowerShell A restore currently requires provisioning a new VM, which, in case of HANA, forces you to apply a new SAP HANA license key. This is due to the fact that SAP hardware key depends on VM ID, which is unique for each VM. File level restore is currently in preview

Deployment of HANA *Developer Edition* from SAP Cloud to Azure
SAP Cloud Appliance Library Microsoft Azure An alternative approach to automated provisioning of HANA test or development environments takes advantage of SAP Cloud Appliance Library. The library is essentially a SAP managed portal from which you can deploy ready to use SAP applications into Azure or AWS. Cloud Appliance Library based deployments offer additional automation features, such as, for example, the ability to schedule time window during which Azure virtual machines should be running or target date when they should be deleted.

Deploying NetWeaver ABAP/BW powered by HANA Developer Edition on Azure
HANA template VM images available on SAP Cloud Appliance Library HANA Enterprise Cloud) with free of charge (no licensing cost) and can be automatically deployed to Azure within 60 minutes Hana Developer Edition on Azure NetWeaver ABAP/BW HANA Developer Edition on Azure Test your HANA workloads on Azure with DS Series and Premium Storage today More on SAP Cloud Appliance Library Cloud Appliance Library includes the ability to deploy Azure virtual machines containing installation of SAP HANA without the need to purchase a license. To accomplish this, after you register, simply log on to the SAP Cloud Appliance Library portal, specify the application you want to deploy, such as, for example, SAP Business Warehouse/4HANA Developer Edition, provide deployment parameters, such as, for example, the Azure region, target virtual network and subnet, virtual machine sizes, and endpoints through which you will be access the virtual machines, and wait for about an hour for the deployment to complete. Afterwards, you will be able to connect via HANA Studio to your HANA database. It is worth noting that Cloud Appliance Library relies currently on a management certificate to authenticate to Azure with administrative credentials, so, effectively it uses classic deployment model. Create a HANA instance from SAP Cloud Appliance Library HANA instance deployed on Microsoft Azure Connecting to HANA Database with HANA Studio

SAP/HANA DR on Azure Characteristics
Primary site is on-premises or Cloud Ability to failover to a DR site within hours Never lose transaction data Transparent failover to end users and sub systems Ability to failback 1 2 5 Now it is turn to examine the design and implementation options of SAP HANA Disaster Recovery environments in Azure. Common characteristics of SAP/HANA DR environments on Azure include the failover from the primary site that resides either on-premises or in the cloud, the ability to complete failover within hours, minimizing or even eliminating transaction data loss, failover that is transparent to end users and subsystems, and the ability to fail back. 4 3

SAP HANA High Availability and Disaster Recovery Options
There are three main ways to architect disaster recovery capabilities in SAP HANA based on SAP-specific capabilities – system replication, storage replication, and backup shipping. Each of these has its advantages and limitations.

SAP HANA HA and DR Options – Pros and Cons
Let’s start with backups. Their advantages include relatively low cost and simplicity, as well as support of point-in-time recovery. They also allow you to clone existing systems. On the other hand, the recovery point objective they offer is relatively high, potentially extending to hours, depending on frequency of backups and the method used for shipping them to the disaster recovery location. To prepare for a disaster, you also need to ensure you have a spare system where the restore can be performed. Bringing such system to the fully operational status could take hours, which affects the recovery time objective. Storage replication addresses a number of these limitations. Its recovery point objective can be eliminated if you can set up synchronous replication. Even without it, asynchronous replication typically reduces the RPO to a few seconds. You can also use secondary system during normal operations for other purposes. Storage replication does have, however, some limitations as well. In particular, there is still typically a considerable failover delay resulting from the need to set up the secondary system once the disaster recovery event is invoked. In addition, solutions based on this approach have a number of storage and networking dependencies that must be certified by SAP to be considered compliant. Another consideration is that synchronous replication is typically restricted to locations that are no further than 60 miles away from each other. Storage replication is also vulnerable to storage corruption issues and it tends to be more bandwidth intensive than system replication. System replication is supported natively by HANA, which means it is supported by all partner solutions. It can be used in both high availability and disaster recovery scenarios, with no dependencies on specialized storage hardware. With synchronous mode, there is no data loss following the failover, giving you RPO equal to 0. RTO is also typically reduced to a few minutes only – corresponding to the preload time. The recovery system is typically ready at that point to operate at its full capacity. If you opt not to preload data, then the secondary system can be utilized for other purposes. Primary drawbacks of system replication include the need for a dedicated live standby system and sufficient bandwidth between the primary and recovery locations. Another is the requirement for additional provisions to facilitate client connectivity following the failover, since the target server name and IP address change. As we mentioned earlier, Azure HANA large instances in the multi-node configuration also support host auto-failover. Typically you would use it in combination with system replication to facilitate automatic failover from a primary node to a standby. However, keep in mind that this capability relies on shared access to database storage, which requires either network-based storage or a specialized storage hardware solution.

Disaster Recovery Solutions for LOB applications/SAP on Azure
Business requirements Minimum data loss in case of a disaster Failover complete within hours including SAP application layer Clear failover process Failover transparent to users and sub systems Minimum costs for DR IT requirements Production environment is on virtualization, bare metal or cloud Minimum overhead on Production systems and network Retire traditional SAN/Tape-based solutions 1 2 Database Replication (e.g. HANA System(*)/Storage Replication) File Replication (e.g. OS File Copy) Application VM Replication (Azure Site Recovery) In addition to relying on SAP-specific capabilities, you also have the option of leveraging other Azure-compliant disaster recovery solutions, such as file copy or Azure Site Recovery. However, note that at the time of recording of this presentation, Azure Site Recovery between two Azure regions is limited to failover only – without the certified failback functionality. (*)System Replication with Large Instances only for HA

Running HANA DR, Dev/Test in Azure
` 5 On-premises Datacenter Scheduled copy of flat files to Azure (e.g. sapmnt) 4 Azure Backup Vault Transfer older backup sets to Azure for long-term retention Set up HANA System Replication to have a DB replica in Azure File Server Backup Server 1 2 Take HANA DB backups online DR DB 3 QA system refresh using Production database copy HANA System Replication DB Replica ExpressRoute Gate way VPN Gate way Here is a sample design that illustrates the approach where Azure serves as a disaster recovery site for an on-premises SAP system. We have a highly available on-premises implementation consisting of an SAP ASCS cluster, multiple SAP app servers, and two HANA servers configured with system replication and host auto-failover. There is an ExpressRoute connection between our on-premises environment and the Azure virtual network, which we intend to configure as our disaster recovery site. We already deployed Azure VMs that will function as the dev/test environment. <click> To provide disaster recovery functionality, we provision a VM that will serve as a replica of HANA DB and we set up asynchronous HANA system replication from the on-premises instance. <click> At that point, we also start performing regular backups of that VM by using Azure Backup Server <click> We also perform database copy from our disaster recovery HANA DB to the dev/test environment, which allows us to use that system for quality assurance purposes. <click> and transfer older backups to Azure Backup vault for a long-term retention. <click> Finally, we also schedule copy of files from the sapmnt share on the SAP ASCS system on-premises cluster to a file server VM in Azure, which, in turn, is backed up to an Azure Backup vault. SAP ASCS Cluster SAP App Servers DevTest HANA Host Auto-Failover and System Replication Prod HANA DB + SAP AP Dev/Test

HANA Host Auto-Failover or System Replication
Failover to DR Site ` On-premises Datacenter 4 Copy sapmnt files to new ASCS if needed Azure Backup Vault 5 Users and sub systems reconnect 1 File Server Backup Server Stop replication Shutdown (Failover) 2 Promote to Production DB DR DB -> Prod DB HANA DB Replica ExpressRoute In case of a disaster affecting the on-premises location, <click> we stop system replication, assuming of course that it was not terminated automatically as a result of the disaster, <click> promote SAP HANA DR instance to production, <click> change the DB hostname parameter on our SAP dev/test environment application servers, including the ASCS instance, <click> and copy to it the content of sapmnt share replicated from the on premises ASCS sapmnt share. <click> At that point, we can initiate the failover <click> and ask users to reestablish their connections to our SAP HANA-based applications. Gate way VPN Gate way 3 SAP ASCS Cluster SAP App Servers Change DB hostname parameter to point to Production HANA Host Auto-Failover or System Replication Prod Dev -> Prod AP

Failback to On-premises
` On-premises Datacenter Azure Backup Vault 4 Users and sub systems reconnect 1 File Server Backup Server Resume replication DR DB -> Prod DB HANA DB Replica ExpressRoute 2 To revert this process, once the original site and the former production environment is stable, <click> we resume replication between the two HANA deployments. <click> Next, we promote the on-premises database instance back to production, <click> restart SAP service on the application servers and the ASCS cluster, <click> and finally, we ask users to reconnect again. Gate way VPN Gate way Promote to Production DB SAP ASCS Cluster SAP App Servers HANA Host Auto-Failover or System Replication 3 Restart SAP Service Prod Dev -> Prod AP

SAP HANA on Azure Large Instances - DR
Infrastructure DR - large instance SKUs of the same size as production (can be used for QA or sandbox) Disaster Recovery profile - allocates storage volumes Cross-region connectivity A VNet can connect to up to 4 ExpressRoute circuits (2 per region) Each circuit via a different MSEE (MS Enterprise Exchange) routers Two circuits from on-premises and two from the large instance stamp location To provide disaster recovery for SAP HANA large instances, from the infrastructure standpoint, you need to submit a request to Microsoft to provision a separate large instance of the same size as the production one by defining the Disaster Recovery profile. Note that you can use that instance as your QA environment. To facilitate DR from the connectivity standpoint, each VNet connects to multiple ExpressRoute circuits, with each circuit via a different MSEE (MS Enterprise Exchange) routers, providing redundancy for connectivity from your on-premises locations and from the large instance stamp location

SAP HANA on Azure Large Instances - DR
Storage replication Storage snapshots – ready-to-use scripts to be implemented by the customer A prerequisite for DR A snapshot of the boot LUN and HANA volumes (hana/data, hana/log, hana/log_backup, hana/shared) RPO from 60 to 90 minutes – to lower, include transaction log backups Up to 255 snapshots supported – although a lower number is recommended The customer responsible for space allocation and usage, and scheduling (cron) Serves as the built-in backup and restore method Invokes a HANA snapshot, performs a storage snapshot, and deletes the HANA snapshot Customers can implement other backup methods (Azure Backup or Marketplace) Restores require engagement of SAP HANA on Azure Service Management Avoid snapshots during R3load, restores, table reorganization, etc. Transaction log backups – implemented by the customer (HANA Studio) Requires at least one file-based backup (e.g. via HANA Administration console) DR: Backup to /hana/log/backup Copy to an Azure VM in the same region Copy from the Azure VM in the same region to an Azure VM in the DR region Restore from the Azure VM in the DR region to the large instance in the DR region Restore: apply after snapshot restore for point-in-time restore (DR or Prod) Database level DR is provided through the combination of storage replication and transaction log backups. Storage replication relies on Storage snapshots, which are implemented by customers based on ready-to-use scripts provided by Microsoft. The snapshots include the boot LUN and HANA volumes. Based on the snapshot frequency, customers can achieve the RPO between 60 and 90 minutes. In order to further reduce this value, it is necessary to implement transaction log backups. Customers are responsible for space allocation and usage, and scheduling of storage snapshots. Customers can also implement other backup methods based on Azure Backup or Marketplace-based solutions. Restores require engagement of SAP HANA on Azure Service Management. Transaction log backups are implemented by the customer using HANA native tools. The backups require at least one file-based backup. The process of backup and recovery in such scenario involves the following sequence of steps: Transaction log backup to /hana/log/backup Copy to an Azure VM in the same region Copy from the Azure VM in the same region to an Azure VM in the DR region Restore from the Azure VM in the DR region to the large instance in the DR region Restore: apply after snapshot restore for point-in-time restore (DR or Prod)

Summary SAP HANA on Azure Overview High Availability Solutions
SAP HANA Production Environment in Azure SAP HANA Dev/Test/DR Environment in Azure Notes This concludes our presentation dedicated to Architecture Design of SAP HANA deployments on Azure. We started with an overview of SAP HANA offering on Azure. Next, we covered high availability aspects of SAP HANA deployments on Azure. Afterwards, we stepped through different architectural design options intended for SAP HANA production workloads on Azure and concluded with an equivalent coverage applicable to the Development, Test, and Disaster Recovery workloads.

Deploying SAP on Azure Architecting SAP HANA on Azure

Similar presentations

Presentation on theme: "Deploying SAP on Azure Architecting SAP HANA on Azure"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Deploying SAP on Azure Architecting SAP HANA on Azure

Similar presentations

Presentation on theme: "Deploying SAP on Azure Architecting SAP HANA on Azure"— Presentation transcript:

Similar presentations

About project

Feedback