Ask Learn
Preview
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign inThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Introduction
Azure Site Recovery delivers a powerful toolset to customers seeking to deploy or improve their Disaster Recovery solutions.
The key differentiators between Azure Site Recovery (ASR) and competing technologies:
The Azure Site Recovery toolset includes solutions for different Hypervisors and deployment patterns.
There are two tools:
H2A – Hyper-V to Azure uses the native Windows Hyper-V Replica technology to replicate VMs to Azure. This is a Host based replication technology.
V2A – VMware or Physical Servers to Azure uses the InMage toolset to replicate VMs to Azure. V2A is a guest based technology.
More documentation is linked for H2A and V2A
ASR is lower cost than all competing technologies because only the storage cost is charged while VMs are in Synchronization Mode.
ASR also allows customers to do a complete DR test without compromising the DR capabilities. ASR copies all resources before completing a test failover and there is no impact on the DR SLA during DR testing
Top 10 Key Points for Protecting SAP Systems Running on VMware with ASR
Prerequisites
Networking VPN or ExpressRoute is a prerequisite for Failback. It is possible to synchronize VMs from on-premises to Azure and perform a failover without VPN or ExpressRoute as this traffic runs over https port 443. Failback requires access direct to the VMware cluster via ExpressRoute or VPN.
Foundation Services include Networking, Active Directory and Name Resolution Services.
SAP systems running on Windows require Active Directory and Domain accounts must be used for 3 tier systems.
DNS services are essential for consistent name resolution.
It is technically possible to use ASR to replicate a Domain Controller, but this is not recommended. Rather than failing over AD VMs it is recommended to setup a small low cost VM in Azure that is permanently running and synchronizing.
Azure Site Recovery is a Multi-OS solution. Both Windows & Linux are supported. It is recommended to use a Windows Server as the Configuration/Management server since monitoring is simpler on Windows. A Windows Configuration server can monitor and deploy to Linux Guest VMs.
Recommendation:
Recommendations & Limitations
3-Tier systems are strongly recommended for all but the very smallest SAP systems running on Azure.
The use of ASR to provide DR protection for 2-Tier SAP landscapes is not recommended, is not tested and is not discussed in this blog. Production systems should leverage the native DBMS replication technology such as SQL Server AlwaysOn.
Premium Storage is generally recommended for the DBMS datafiles for all SAP systems, especially production systems.
At the time of writing (April 2016) ASR does not support the following features. Many of these will be released in the coming weeks and months and will be removed from this list:
Deployment Phase
Task 1: Establish Foundation Services
Create a vNet in Azure and setup subnets in the chosen target Azure location. This should be the same location where the Azure Recovery Vault will be created
Setup Site to Site VPN or ExpressRoute. Connect VPN or ER to the SAP vNet
Deploy a small VM in the SAP vNet that will function as the AD Domain Controller for the ASR vNet
Assign a static IP address to the Active Directory VM
Get-AzureVM -ServiceName "xxx" -Name "xxx" | Set-AzureStaticVNetIP -IPAddress x.x.x.x | Update-AzureVM
*See the appendix for the ARM command line for static private IP address.
Install the AD and DNS roles and join to existing Corporate AD.
Register the AD and DNS VM as the "DNS1" IP address for the SAP vNet via the menu option in the Azure Portal (path New -> Network Services -> Virtual Network -> Register DNS Server). Assign DNS1 to the vNet
Carefully test AD services and DNS resolution. Create a test VM and failover and failback. Run nslookup in the on-premises and Azure locations. If there are inconsistencies wait for some time for DNS synchronization to occur
Task 2: Follow Azure Installation Procedure on SAP Application Servers and Central Services
The ASR documentation is very clear. It is strongly recommended to watch the videos before deploying each step.
It is recommended to review the entire documentation end to end at this link
https://azure.microsoft.com/en-us/documentation/articles/site-recovery-vmware-to-azure-classic/
Start at Step 1 and continue through Step 11. The documentation is complete and should be simple to follow
As discussed earlier it is recommended to create a small simple VM on VMware and test steps 1 – 11 on this non-SAP VM before attempting to deploy ASR to the SAP landscape
The steps to deploy the Management Server(s) [Step 5] are here
https://azure.microsoft.com/en-us/documentation/articles/site-recovery-vmware-to-azure-classic/#step-5-install-the-management-server
Important Points:
Review the sizing and disk requirements for the Management Server(s)
Ensure the VMware admin account (used to connect ASR to vCenter) and Windows Admin accounts (used to deploy the replication agents into the Guest VMs) are identified
Ensure the Firewall and Ports are opened as documented
Consider using VMware HA to protect the SAP ASCS instead of a shared disk cluster
Ensure that the VMs do not have any one individual disk larger than 1023GB (1TB)
Use the latest release of VMware vSphere PowerCLI 6.0 – downloaded from VMware (free registration required)
ASR obengine.exe and other processes may need to access Internet via the corporate proxy server. A user id may be required. See the documentation for PowerShell to configure the proxy settings including the password
Take care when entering user/pw information into cspsconfigtool.exe
Each VM must be sized and the network configured
Replication Settings of each Recovery Group
Task 3: Setup Native DBMS Replication from on-premises to Azure VM
The ASR Toolset for VMware and Physical servers can create consistent replicas of DBMS servers on both Windows and Linux such as SQL Server.
Due to the size and data churn volumes with SAP databases it is a general recommendation to use the native DBMS replication technology to replicate the database.
Using the native DBMS replication allows greater control over restore and recovery points. For example if there was a failure in the on-premises datacenter, it may be possible to take a Tail of Log backup from SQL Server and apply this to the database in Azure (which will be in recovery mode).
Guidance for setting up DBMS in Azure:
After the installation of the DR solution for the DBMS server conduct tests and become familiar with any change to the application connection string if required (not required with SQL Server AlwaysOn).
Task 4: Protect the SAP Transport Directory and other File System Level VMs
The SAP Transport Directory, File servers for Interface files and SAP and non-SAP standalone engines also need to be protected.
There are several options for handling the SAP Transport Directory and interface directory:
Other SAP and non-SAP standalone applications need to be tested with ASR on a case by case basis.
Test Failover
Test failover into an isolated vNet without connection back to live users, printers and interfaces is recommended.
A Test Failover does not impair the DR SLA because all of the VMs and objects are cloned as part of a test failover.
The original VMs continue synchronizing and the DR SLA is not impacted.
Even during the execution of a Test Failover it is possible to execute a "real" Failover should a DR event occur during a Test Failover
After executing a Test Failover it may be required to add a public RDP endpoint onto one VM in order to access the VMs. This is because there is no external connectivity to the Test Failover vNet as there is no ExpressRoute or VPN
A typical sequence for a Test Failover is:
Illustration of selecting a vNet during a test failover
Failover
It is recommended to create a Recovery Plan to sequence and orchestrate the failover.
It is possible to make one recovery plan that would failover the entire SAP production environment, meaning one recovery plan would trigger ECC, BW, PI and all other Production systems to failover. Most customers do not prefer this. It is generally recommended to create a Recovery Plan for each SAP application. Examples: RecPlan-ECC-Prod, RecPlan-SCM-Prod, RecPlan-SCM-Livecache
The Recovery Plan allows sequencing the startup of VMs. For example it is recommended to put the Central Services into a separate Recovery Plan Group and to ensure these are started before starting the SAP Application Servers
A typical sequence for a Failover is:
Failback
The Failback procedure is similar to failover. At the conclusion of a successful failover, press the Reprotect button to enable synchronization from VMware based VMs to Azure
Protection Against Total Loss of Corporate Network
Azure Site Recovery can be used in combination with other Azure features and capabilities to protect against the total catastrophic loss of an on-premises datacenter and all the associated WAN connections to branch offices. For example, RemoteApp with a custom server image including necessary SAP client software can be planned to protect SAP client services.
RemoteApp goes here: https://azure.microsoft.com/en-us/documentation/services/remoteapp/
Create a Custom Image, install SAPGUI and sysprep the Image. Make sure SAPGUI is in the Start Menu and Publish SAP Logon via the Start Menu in the Azure Portal.
If more complex scenarios such as BEx and other GUI features are used test these well. Check the RemoteApp documentation for Active Directory authentication options. Ensure the AD design is tolerant of the complete loss of the on-premises AD infrastructure.
Protecting Non-NetWeaver Based Applications
SAP applications that are not based on ABAP or Java can be protected with ASR as well. Care should be taken to validate the amount of "churn" or changes on the file system(s). SAP ABAP or Java servers have very little churn, but systems such as TREX could have considerable amounts of writing. It is recommended to use the Azure Site Recovery Capacity Planner tool. This is typically not required for ABAP and Java systems as the amount of data written to these VMs is small.
Stand-alone component | Description | Example |
File-system based | These components can be protected by Azure Recovery Services by simply replicating the VM asynchronously. In general, we recommend minimizing the number of disks on the VM and, ideally, implementing the operating system and application on C: drive, if possible. | CTM OptimizerAdobe Document ServerKWTREXTransport & Interface Directories |
DBMS-based | These SAP stand-alone components use a database and, therefore, must be protected using database tools and Azure Recovery Services. For more information, see the appropriate SAP guidance, such as the LiveCache High Availability Guide. | LiveCacheBusiness ObjectsContent Server |
It is critical to ensure the server holding the Transport Directory and any interface directories is also protected.
It is strongly recommended to use a dedicated Windows server for file server purposes (such as DIR_TRANS) and not to use SAP application servers as file servers. One option to protect and synchronize transport and other interface directories is to use Windows DFS-R.
The SAP /sapmnt file system should never be used for storing interface files or any other data.
Error Handling
Useful tips and tricks for V2A ASR
SAP Azure Monitoring Agent
If a Disaster Recovery Event occurs and it appears likely that the SAP systems will need to run for more than a few days in Azure then it is important that the VMs meet all the supportability requirements. Implement 2015553 - SAP on Microsoft Azure: Support prerequisites
In case of any issues refer to The Azure Monitoring Extension for SAP on Windows – Possible Error Codes and Their Solutions
Links
Guidance for Sizing SAP Solutions on Azure
New White Paper on Sizing SAP Solutions on Azure Public Cloud
Static IP, Reserved IP and Instance Level IP in Azure
https://blogs.msdn.com/b/lalitesh_kumar/archive/2014/10/06/static-ip-reserved-ip-and-instance-level-ip-in-azure.aspx https://social.technet.microsoft.com/wiki/contents/articles/23447.how-to-assign-a-private-static-ip-to-an-azure-vm.aspx
Static IP (Private IP) for ARM Deployments:
https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-static-private-ip-arm-ps/ https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-static-private-ip-arm-pportal/
How to register a DNS server
Azure Site Recovery Blogs
https://azure.microsoft.com/en-us/services/site-recovery/ (Sign up for Free Trial)
https://blogs.technet.com/b/scvmm/archive/2014/10/30/monitoring-azure-site-recovery.aspx https://azure.microsoft.com/en-us/documentation/services/site-recovery/
Win2012 R2 Hyper-V + SQL Server 2014 Free Trial Software
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2012-r2 https://www.microsoft.com/en-us/evalcenter/evaluate-sql-server-2014
Gartner Magic Quadrant for SQL Server
https://www.gartner.com/technology/reprints.do?id=1-237UHKQ&ct=141016&st=sb
Content from VMware, SAP and other sources reproduced in accordance with Fair Use criticism, comment, news reporting, teaching, scholarship, and research
SAP Notes
1928533 - SAP Applications on Azure: Supported Products and Azure VM types 1999351 - Troubleshooting Enhanced Azure Monitoring for SAP 1380654 - SAP support in public cloud environments 2015553 - SAP on Microsoft Azure: Support prerequisites 2039619 - SAP Applications on Microsoft Azure using the Oracle Database: Supported Products and Versions 1329848 - Oracle Support for Microsoft Hyper-V
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign in