Category Archives: February 2020

Azure deployment and Disaster Recovery for SAP workload


 Microsoft Azure provides a trusted path to enterprise-ready innovation with SAP solutions in the cloud. Mission critical applications such as SAP run reliably on Azure, which is an enterprise proven platform offering hyperscale, high availability, agility, and cost savings for running a customer’s SAP landscape. As an organization you need to adopt a business continuity and disaster recovery (BCDR) strategy that keeps your data safe, and your apps and workloads up and running, when planned and unplanned outages occur. IoTCoast2Coast helps customers to build their SAP on Azure landscapes and very often we discuss the easiest way to get started. We always recommend improving the Disaster Recovery process by implementing Azure Site Recovery, which is Microsoft’s cloud service that replicates on-premise servers and creates a recovery plan to provision resources in the cloud in case of an unexpected event. During normal operations client have to pay only for the storage – target virtual machines are created during the failover process. Reliable and inexpensive disaster recovery solution and it’s today’s reality. Azure Site Recovery protects your workload by replication of the disks. The process is compatible with SAP NetWeaver products and supported by Microsoft. Azure Site Recovery performs the replication, however it can’t ensure the data consistency between the data and log areas. The recommended solution is to create a System Replication between the on-premise and cloud instances. It will ensure the lowest RPO and RTO, but it requires a constantly running server in the cloud environment. As best practice, when it comes to protecting the HANA instance, we present an alternative solution based on the automatic shipping of data backups to Azure Blob storage. It will require some extra actions, but the total cost of the solution is much lower – the client only pays for the space being used. 

Setup And Configure SAP Backups And Disaster Recovery

Azure VM DBMS deployment for SAP workload

 Azure has two different deployment models we can use to create and work with resources,

  • Azure Resource Manager
  • Classic

IoTCoast2Coast recommend the Resource Manager deployment model for new deployments instead of the classic deployment model. 

Setup And Configure SAP Backups And Disaster Recovery


  1. Azure Subscription
  2. Basic Azure knowledge
  3. SAP knowledge
  4. Administrator Access
  5. PowerShell (Good to have)
  6. Understanding of SAP HANA administration

Definition Throughout the document, these terms are used,

  • IaaS: Infrastructure as a service.
  • PaaS: Platform as a service.
  • SaaS: Software as a service.

SAP Azure Disaster Recovery Solution (Scenario)

 Let’s implement Azure Disaster Recovery Solution. It’s important to establish a rough vision of the end state before taking the first step. It’s not the company starting point, but it shows the potential destination. Assumptions / Challenge In the previous environment, SAP was running on-premise with no/ on-prem DR capability. This exposed the company to business risks:

  • Complete production shutdown on a global level if the SAP instance in the headquarters goes down.
  • Loss of data/other transactional information in case of data corruption.
  • High time for business recovery leading to production losses globally.
  • High risk of both infrastructure (Servers, Network, Storage, Backup failure) as well as application issues leading to unplanned business downtime

The Solution Let’s set up a recovery strategy for SAP using Cloud services on Microsoft Azure Cloud. This is intended to enable the client to have an RTO (Recovery Time Objective) of 4 hours and RPO (Recovery Point Objective) of 2 hours. The same could be configured as an on-demand DR solution, allowing the customer to pay for DR services on an as-needed basis. 

Highlights of the Solution

Setup And Configure SAP Backups And Disaster Recovery

The Key Benefit IoTCoast2Coast implemented best practices for the architecture and business logic on Azure, and through the implementation of architectural best practices and the business logic on Azure, the following benefits were realized by the customer:

  • Higher Agility
  • Reduced RPO/RTO for DR
  • On demand provisioning of non-production environments from production backup on need basis
  • Consumption based pricing for Disaster Recovery
  • Improved Monitoring
  • Dynamic Scaling

    Setup And Configure SAP Backups And Disaster Recovery

Considerations for Azure VM DBMS deployment for SAP workload

 Let’s undiscover the generic deployment aspects of SAP-related DBMS systems on Microsoft Azure virtual machines (VMs) by using the Azure infrastructure as a service (IaaS) capabilities. It complements the SAP installation documentation and SAP Notes, which represent the primary resources for installations and deployments of SAP software on given platforms. Considerations of running SAP-related DBMS systems in Azure VMs are introduced. There are few references to specific DBMS systems in this chapter. Instead, the specific DBMS systems are handled. SAP component An individual SAP application such as ERP Central Component (ECC), Business Warehouse (BW), Solution Manager, or Enterprise Portal (EP). SAP components can be based on traditional ABAP or Java technologies or on a non-NetWeaver-based application such as Business Objects. SAP environment One or more SAP components logically grouped to perform a business function such as development, quality assurance, training, disaster recovery, or production. SAP landscape This term refers to the entire SAP assets in a customer’s IT landscape. The SAP landscape includes all production and nonproduction environments. SAP system The combination of a DBMS layer and an application layer of, for example, an SAP ERP development system, an SAP Business Warehouse test system, or an SAP CRM production system. In Azure deployments, dividing these two layers between on-premises and Azure isn’t supported. As a result, an SAP system is either deployed on-premises or it’s deployed in Azure. You can deploy the different systems of an SAP landscape in Azure or on-premises. For example, you could deploy the SAP CRM development and test systems in Azure but deploy the SAP CRM production system on-premises. Cross-premises Describes a scenario where VMs are deployed to an Azure subscription that has site-to-site, multisite, or Azure ExpressRoute connectivity between the on-premises data centers and Azure. In common Azure documentation, these kinds of deployments are also described as cross-premises scenarios. 

SAP Site Recovery

 The Site Recovery provides a disaster recovery solution for on-premises machines, and for Azure VMs. You replicate machines from a primary location to a secondary. When disaster strikes, you fail machines over to the secondary location, and access them from there. When everything’s up and running normally again, you fail machines back to recover them in the primary site. 

Azure Recovery Services contribute to your BCDR strategy

Site Recovery service Site Recovery helps ensure business continuity by keeping business apps and workloads running during outages. Site Recovery replicates workloads running on physical and virtual machines (VMs) from a primary site to a secondary location. When an outage occurs at your primary site, you fail over to a secondary location, and access apps from there. After the primary location is running again, you can fail back to it. Backup service The Azure Backup service keeps your data safe and recoverable by backing it up to Azure. Site Recovery can manage replication for:

  • Azure VMs replicating between Azure regions.
  • On-premises VMs, Azure Stack VMs and physical servers.


 Azure keeps your applications up and running and your data available. Azure is the first cloud platform to provide a built-in backup and disaster recovery solution.Resiliency is not about avoiding failures but responding to failures. The objective is to respond to failure in a way that avoids downtime and data loss. Business continuity and data protection are critical issues for today’s organizations, and business continuity is built on the foundation of resilient systems, applications, and data. Reliability and resiliency are closely related. Reliability is defined as dependability and performing consistently well. Resiliency is defined as the capacity to recover quickly. Together, these two qualities are key to a trustworthy cloud service. Despite best efforts, disasters happen; they are inevitable but mostly unpredictable, and vary in type and magnitude. There is almost never a single root cause of a major issue. Instead, there are several contributing factors, which is the reason an issue is able to circumvent various layers of mitigations/defenses. 

Disaster Recovery

 Disaster recovery strategy is key to business continuity. Site recovery and data backup are elements of a disaster recovery plan. Organizations using the cloud tend to take the reliability of the public cloud for granted, not recognizing that they may be responsible for choosing and implementing backup and recovery mechanisms. As a cloud customer, you will confront more opportunities to spend extra time and money on optional backup than you can ever take advantage of, so you need to make explicit and careful choices as to what you will and will not do. Your disaster recovery plan should,

  1. Identify and classify the threats and risks that may lead to disasters.
  2. Define the resources and processes that ensure business continuity during the disaster.
  3. Define the reconstitution mechanism to get the business back to normal from the disaster recovery state, after the effects of the disaster are mitigated.

An effective disaster recovery plan plays its role in all stages of operations and it is continuously improved by disaster recovery mock drills and feedback capture processes. Disaster recovery happens in the following sequential phases,

  1. Activation Phase
    In this phase, the disaster effects are assessed and announced.
  2. Execution Phase
    In this phase, the actual procedures to recover each of the disaster-affected Azure services are executed. Business operations are restored into the Azure paired region.
  3. Reconstitution Phase
    In this phase the original Azure region hosted system/service is restored, and execution phase procedures are stopped.

Build Your Enterprise Azure Network Foundation


This article will provides Customers a brief description of networking solution for connecting customers from any location to Azure, leveraging our customers with the leading national and international network providers.

A single hardware failure is mitigated by a Fabric Controller which manages resource allocation, automatically failing-over to a different machine or cluster. Hardware management is transparent to the customer. Without additional configuration, data is protected by locally redundant storage, which maintains multiple replicas of data within a single region. If geo-replication for the virtual machine is configured, that geo-replication provides redundancy of data across regions to help ensure access to data in the event of a local disaster.

Network infrastructure and components are similarly redundant, with N+1 links to regional TelCos, load balancers, and routing switch fabric.

SAP on Azure is a very popular workload. As customers look to deploy their production SAP systems on Azure it is important to consider proper network design to ensure performance. This document will walk you through how to optimally connect to the Microsoft network for SAP and SAP HANA Large Instance.

Latency Optimization

The solution facilitates a seamless, fast migration to SAP on Azure, based on a secure, highly available, performant, and resilient connectivity solution covered by an end-to-end SLA.

When deploying enterprise applications such as SAP in Azure it is important to know the different connectivity methods used with the Microsoft network.

The most common way to interface with applications hosted in Azure is to connect via the Internet. Microsoft today interconnects with Internet Service Providers in over 150 locations around the world. Microsoft provides more than 80 percent of global GDP (Gross Domestic Product) with an experience of sub-30 milliseconds latency.

The most common way to interface with applications hosted in Azure is to connect via the Internet. Microsoft today interconnects with Internet Service Providers in over 150 locations around the world. Microsoft provides more than 80 percent of global GDP (Gross Domestic Product) with an experience of sub-30 milliseconds latency. We are adding new edges every week, and our ambition is to provide this level of performance to all of global audience.

When using Internet connectivity to access SAP applications customers can either leverage Microsoft VPN Gateway or Azure Virtual WAN. VPN Gateway allows customers to establish an IPSEC tunnel from an on-premise device to Azure directly over the internet.  


  1. Azure Subscription
  2. Basic Azure knowledge
  3. SAP knowledge
  4. Administrator Access
  5. PowerShell (Good to have)
  6. Understanding of SAP HANA administration


Throughout the article, these terms are used:

IaaS: Infrastructure as a service.

PaaS: Platform as a service.

SaaS: Software as a service.


This response document helps address standard Requests for Information (RFI) with which IoTCoast2Coast empower customers to evaluate different offerings in the market place today. Through the mappings available in the CCM, we can illustrate how Azure has implemented security and privacy controls aligned to other international standards such as ISO/IEC 27001, US Government frameworks including FedRAMP, and industry certifications such as PCI DSS.


A cloud-specific controls framework such as the Cloud Control Matrix (CCM) reduces the risk of an organization failing to consider important factors when selecting a cloud provider. The risk is further mitigated by relying on the cumulative knowledge of industry experts who created the framework, and taking advantage of the efforts of many offerings.


For organizations that do not have detailed knowledge about the different ways that cloud providers can develop or configure their offerings, reviewing a fully developed framework can provide insight into how to compare similar offerings and distinguish between providers. A framework can also help determine whether a specific service offering meets or exceeds compliance requirements and/or relevant standards.

Azure approach on SAP Connectivity Requirement

Both Azure and the underlying Microsoft Cloud and Infrastructure Operations (MCIO) physical environments employ Network frameworks that span multiple best standards.

Let’s enable a wide range of enterprise and consumer services with a highly available, secure, and agile network

Azure ExpressRoute Challenge

Azure ExpressRoute is the recommended Azure networking service to create a private connection between an on-premises network and Azure virtual networks, bypassing the public Internet (see reference architecture). This is applicable to both SAP S/4HANA as well as SAP HANA on Azure Large Instances deployments.

ExpressRoute enables the initial migration of the data estate, as well as the ongoing secure data transfer between your SAP on Azure solution and applications remaining in your enterprise data center. Most organisations in Northern Europe deploy their SAP on Azure solutions on the Azure West Europe multi-zone region located in The Netherlands.

There are couple of ExpressRoute nodes available in North America, offers <0.5 millisecond latency to SAP Hana on Azure and Large Instances. To safeguard performance of SAP HANA in-memory databases, latency and jitter should be considered when designing connectivity solution.

As physical distance directly impacts latency and jitter, it’s recommended for customers planning to transfer large data volumes and customers running hybrid cloud architectures to consider it seriously.


Let’s This reference architecture describes an enterprise-grade, production-level system. To suit your business needs, this configuration can be reduced to a single virtual machine. However, the following components are required:

Virtual network: The Azure Virtual Network service securely connects Azure resources to each other. In this architecture, the virtual network connects to an on-premises environment through a gateway deployed in the hub of a hub-spoke topology. The spoke is the virtual network used for the SAP applications.

Subnets: The virtual network is subdivided into separate subnets for each tier: gateway, application, database, and shared services.

Virtual machines: This architecture uses virtual machines running Linux for the application tier and database tier, grouped as follows:

Application tier: Includes the Front-end Server pool, SAP Web Dispatcher pool, application server pool, and SAP Central Services cluster. For high availability of Central Services on Azure Linux virtual machines, a highly available Network File System (NFS) service is required.

NFS cluster: This architecture uses an NFS server running on a Linux cluster to store data shared between SAP systems. This centralized cluster can be shared across multiple SAP systems. For high availability of the NFS service, the appropriate High Availability Extension for the selected Linux distribution is used.

SAP HANA: The database tier uses two or more Linux virtual machines in a cluster to achieve high availability. HANA System Replication (HSR) is used to replicate contents between primary and secondary HANA systems. Linux clustering is used to detect system failures and facilitate automatic failover. A storage-based or cloud-based fencing mechanism can be used to ensure the failed system is isolated or shut down to avoid the cluster split-brain condition.

Jumpbox: Also called a bastion host. This is a secure virtual machine on the network that administrators use to connect to the other virtual machines. It can run Windows or Linux. Use a Windows jumpbox for web browsing convenience when using HANA Cockpit or HANA Studio management tools.

Load balancers: Both built-in SAP load balancers and Azure Load Balancer are used to achieve HA. Azure Load Balancer instances are used to distribute traffic to virtual machines in the application tier subnet.

Availability sets: Virtual machines for all pools and clusters (Web Dispatcher, SAP application servers, Central Services, NFS, and HANA) are grouped into separate availability sets, and at least two virtual machines are provisioned per role. This makes the virtual machines eligible for a higher service level agreement (SLA).

NICs: Network interface cards (NICs) enable all communication of virtual machines on a virtual network.

Network security groups: To restrict incoming, outgoing, and intra-subnet traffic in the virtual network, network security groups (NSGs) are used.

Gateway: A gateway extends your on-premises network to the Azure virtual network. ExpressRoute is the recommended Azure service for creating private connections that do not go over the public Internet, but a Site-to-Site connection can also be used.

Azure Storage: To provide persistent storage of a virtual machine’s virtual hard disk (VHD), Azure Storage is required.

Highlights Networking architecture for HANA Large Instance  

The networking architecture for HANA Large Instance can be separated into four different parts:

On-premises networking and ExpressRoute connection to Azure. This part is the customer’s domain and is connected to Azure through ExpressRoute. This Expressroute circuit is fully paid by you as a customer. The bandwidth should be large enough to handle the network traffic between your on-premise assets and the Azure region you are connecting against. See the lower right in the following figure.

Azure network services, as previously discussed, with virtual networks, which again need ExpressRoute gateways added. This part is an area where you need to find the appropriate designs for your application requirements, security, and compliance requirements. Whether you use HANA Large Instance is another point to consider in terms of the number of virtual networks and Azure gateway SKUs to choose from. See the upper right in the figure.

Connectivity of HANA Large Instance through ExpressRoute technology into Azure. This part is deployed and handled by Microsoft. All you need to do is provide some IP address ranges after the deployment of your assets in HANA Large Instance connect the ExpressRoute circuit to the virtual networks. For more information, see SAP HANA (Large Instances) infrastructure and connectivity on Azure. There is no additional fee for you as a customer for the connectivity between the Azure data center network fabric and HANA Large Instance units.

Networking within the HANA Large Instance stamp, which is mostly transparent for you.

The differences to SAP deployments in Azure:

  • The HANA Large Instance units of your customer tenant are connected through another ExpressRoute circuit into your virtual networks. To separate load conditions, the on-premises to Azure virtual network ExpressRoute circuits and the circuits between Azure virtual networks and HANA Large Instances don’t share the same routers.
  • The workload profile between the SAP application layer and the HANA Large Instance is of a different nature, with many small requests and bursts like data transfers (result sets) from SAP HANA into the application layer.
  • The SAP application architecture is more sensitive to network latency than typical scenarios where data is exchanged between on-premises and Azure.
  • The Azure ExpressRoute gateway has at least two ExpressRoute connections. One circuit that is connected from on-premise and one that is connected from HANA Large Instances. This leaves only room for another two additional circuits from different MSEEs to connect to on ExpressRoute Gateway. This restriction is independent of the usage of ExpressRoute Fast Path. All the connected circuits share the maximum bandwidth for incoming data of the ExpressRoute gateway.

HANA Large Instance units in multiple regions

To realize disaster recovery set ups, you need to have SHANA Large Instance units in multiple Azure regions. Even with using Azure [Global Vnet Peering], the transitive routing by default is not working between HANA Large Instance tenants in two different regions. However, Global Reach opens up the communication path between the HANA Large Instance units you have provisioned in two different regions. This usage scenario of ExpressRoute Global Reach enables:

  • HANA System Replication without any additional proxies or firewalls
  • Copying backups between HANA Large Instance units in two different regions to perform system copies or system refreshes.

The figure shows how the different virtual networks in both regions are connected to two different ExpressRoute circuits that are used to connect to SAP HANA on Azure (Large Instances) in both Azure regions.


The Whether you choose to reach the Microsoft cloud / Azure through the Internet or through a private network, IoTCoast2Coast is committed to provides it’s customers to build the fastest and most reliable global network of any public cloud. Microsoft continue innovating and investing in a globally distributed networking platform to enable high performance, low latency, and the world’s most reliable cloud.

IoTCoast2Coast will continue to provide you with the best possible network experience, wherever in the world you happen to be.