Introduction
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.
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.
Prerequisite
- Azure Subscription
- Basic Azure knowledge
- SAP knowledge
- Administrator Access
- PowerShell (Good to have)
- 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
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.
Resiliency/Reliability
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,
- Identify and classify the threats and risks that may lead to disasters.
- Define the resources and processes that ensure business continuity during the disaster.
- 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,
- Activation Phase
In this phase, the disaster effects are assessed and announced.
- 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.
- Reconstitution Phase
In this phase the original Azure region hosted system/service is restored, and execution phase procedures are stopped.