AZ-120 Microsoft Azure SAP – Migrate SAP Workloads to Azure Part 2

6. HA & DR Inventory

When evaluating High Availability and Disaster recovery requirements, it is very important to also consider the implications of choosing between twotier and three tier architectures. In two tier configurations, you install the Database and NetWeaver components on the same Azure VM in order to avoid network contention. In three tier configurations, the database and application components are installed on separate Azure VMs. This choice also has additional implications regarding Sizing, since two tier and three tier SAPS ratings for a given VM SKU differ. In the case of High Availability for different SAP Net Weaver server roles, you usually don’t need a specific High Availability option for the SAP application servers, you can achieve High Availability by employing Redundancy to implement it. You can simply install individual application servers on separate Azure VMs.

You can achieve ha for ASCs Ses servers running on Windows through using Windows Failover clusting with SIOs Data Keeper. The same can also be achieved by implementing the Scale out File Server and Storage Spaces Direct feature of Windows Server 2016 in a single Sid scenario, and it can also be achieved in a Linux environment with Linux clustering and highly available NFS share by using Azure network files for multisided configurations. This is only supported on Windows server available cluster using File share or shared disks. For DBMS servers, you should use DB replication technology through redundant nodes in an Availability set or across multiple Availability Zones.

Azure offers High Availability through redundancy of its own infrastructure and capabilities such as Azure VM Restarts, which plays an important role in a single VM deployment. You will also find that core services such as Compute, Network and Storage offer greater capabilities through redundancy across Availability Sets and Availability Zones. It’s important to understand those components as you design the SAP landscape and set the foundation elements that pull everything together. For example, like thinking of extending your Adds and DNS to Azure by provisioning multiple adds servers in an Availability Set or Availability zone using managed disks, which give you higher SLAs.

Speaking of SLAs, Azure offers different SLAs depending on your configuration. If you deploy a highly available pair, for example, two VMs in an Availability zone, Azure will offer 99. 99% SLA, but for a single instance, Azure offers only 99. 9% SLA. S AP landscapes are a way of organizing SAP servers into different tiers that are defined by how the system is used. Typical SAP deployments are divided into three different landscapes development, quality assurance, and production. Smaller implementations may only have two landscapes, and larger implementations may have four or more. Your SAP landscape is often hybrid from a DBM and SAP application point of view for example, a mixture of NetWeaver and S four Hana and SAP, Hana and other DBMS.

7. Horizontal and Vertical Migration Strategies

Up next, we will look at the different migration strategies for different environments as we move some example SAP landscapes to Azure. Typically, enterprises have SAP systems for business functions like enterprise, resource planning, ERP, global trade, business intelligence, bi and others. Within those systems, there are different environments such as sandbox, development, test and production. Each horizontal row in the figure is an environment. Each column, that is, each vertical dimension is an SAP system for a business function, for example ERP or Bi. The rows or layers at the bottom are lower risk environments and are less critical. Those towards the top are higher risk and more critical. As you move up the stack, there’s more risk in the migration process, so production is the most critical environment. And the environment for user acceptance testing, that is, the test environment, which is also generally used for business continuity, is the second most critical. The systems at the bottom are smaller in that they have fewer computing resources, lower availability and size requirements, and less throughput. However, they do have the same amount of storage as the production database. With a horizontal migration strategy, you start from the bottom of the stack because it’s a safe way to experiment and gain experience with Azure. It’s also a good strategy to use while you redefine your operational deployment and approval processes.

These processes will change as you move to Azure. To gain experience with production systems on Azure, you can use a vertical strategy with low risk systems in parallel to the horizontal strategy. This also offers a chance to adjust internal processes for Azure and train team members. It’s also a great way to spot any issues in production early on. Let’s now have a look at how migrating using a horizontal strategy works. To limit risk, start with low impact sandboxes or training systems. If something goes wrong, there’s very little danger of affecting many users or mission critical business functions. Then, as you gain experience with running, hosting and administering SAP systems in Azure, apply what you’ve learned to the next layer of systems of the stack. Then, for each layer, estimate costs potential, money saved, performance and optimization potential and adjust if needed. For the vertical migration strategy, this is how it all works.

You look at the impact on cost, customers, SLAs and legal requirements. First, move systems from sandbox up to production that have the lowest risk the Governance Risk and Compliance System and then the Object Event repository, OER. You then move the higher risk ones like Bi and DRP. When you have a brand new SAP system, it’s better to start in Azure by default rather than putting it on premises and moving it later. In the previous diagram, OER was an example of this. OER was a brand new low risk system. After moving some of our other systems into Azure with the horizontal strategy, you can deploy the entire OER vertical stack to Azure end to end from sandbox all the way up to production. Don’t attempt to move your most critical system first. The last system you move is the highest risk most mission critical system, usually the ERP production system.

You need the most performance intensive virtual machines queues and the largest storage move standalone systems first. Some systems are closely joined with other systems. In our example, this would be our ERP and GPS systems. There’s a lot of synchronous real time traffic between the two. If you move the ERP on to Azure but keep GTS on premises, it will affect performance because of network latency. So that’s why you need to move them together. This is an important consideration to have when migrating. If you have several SAP systems, look for upstream and downstream dependencies from one SAP system to the other, or from SAP to apps outside the SAP ecosystem.

It is essential that you examine traffic patterns in areas with high sensitivity to latency. If you have tightly connected systems, you need to do a performance analysis to see what effect moving them will have. If there isn’t much impact, move them separately to Azure, for example. Systems like a business warehouse independent of ERP otherwise, create migration groups and move them together. In some cases, you might need to consider waiting. Sometimes you don’t want to move certain systems to Azure right away. This could be related to Sizing requirements. In particular, when the processing requirements are so high that the virtual machines aren’t yet big enough. You might need to run tests to ensure sure that moving these systems isn’t going to affect SLAs with customers.

8. Planning and Deployment Checklist: Project Preparation and Planning (Part One)

For many SAP customers, compelling events in their migration of SAP Hana to the cloud have been driven by two factors. The first one is End of Life firstgeneration, SAP Hana appliances causing customers to reevaluate their platform. The second one is the desire to take advantage of the early value proposition of SAP business Warehouse BW on Hana in a flexible TDI model over traditional databases and later BW for Hana. As a result, numerous initial migrations of SAP Hana to Microsoft Azure have focused on SAP BW to take advantage of SAP Hana’s in memory capability. For the BW workload. This means migration of the BW application to utilize SAP Hana at a database layer and eventually the more involved migration of BW on Hana to BW for Hana.

The SAP database migration option DMO with system move option of Sum used as part of the migration allows customers the option to perform the migration in a single step all the way from source system on premises to the target system residing in Microsoft Azure minimizing. Overall done time. In general, when initiating a project to deploy SAP workloads to Azure, you should divide it into the following phases project Preparation and Planning Pilot nonproduction Production Preparation Go live and Post Production I will now take you through the Project Preparation and Planning steps before you tackle your first SAP workload in Azure. Let’s explore each step of the Project Preparation and planning phase in detail. I will not call out each of them because we will cover each in detail, step by step. I will just show them to you for a highlevel overview.

Please note this Project Preparation and planning phase is in itself made up of a sequence of steps as shown on screen. Remember, we are in the Project Preparation and Planning phase, which in itself has a number of steps and this is the first one. An appropriate translation of requirements to an HLD document is a must before attempting to work on the product. This phase should produce the following set of items one high level design documents containing the following an inventory of the plans and in the migration scenario the existing SAP landscape a responsibility Assignment matrix which defines the responsibilities and assignments of all parties involved in project delivery.

A high level solution architecture selection of target Azure regions notes that resource availability is not consistent across regions. Networking architecture that provides connectivity between on premises and Azure. You should consider aligning your design with the Virtual Data Center Blueprint for Azure security principles for running high business impact data in Azure. You should consider referencing Azure security documentation for this . 2 a technical design document containing a solution block diagram the sizing of compute, Storage and networking components in Azure for SAP Sizing of Azure VMs. Please consult SAP support Node 192-8533 for full details. High Availability and Disaster Recovery Architecture The architecture should be based on the business provided RTO and RPO for High availability within the same zone. Identify the capabilities of the target DBMS product.

Most DBMS offer synchronous hot standby recommended for production systems. In addition, please check the SAP related documentation for the different databases, starting with considerations for Azure Virtual machines. DBMS Deployment for SAP workloads, please note that using the Windows Failover cluster service with shared misconfiguration for the DBMS layer is not supported. Instead, please consider solutions such as SQL Server Always on Oracle Data Guard Hana system replication for disaster recovery of the DBMS tier across Azure regions. Identify product specific options offered by the DBMS vendors. Most of them support Asynchronous replication or log shipping. For the SAP application layer, define whether you will run your business regression test systems which should match your production systems in the same Azure region or the Dr region. In the latter case, you could leverage the regression systems as the Dr targets for production. If you decide not to leverage the regression test systems as the Dr targets, consider using Azure Site Recovery as the method of replicating the SAP application layer into the Azure Dr region. For more information, please refer to the Microsoft documentation on setup disaster recovery for a multi tier SAP Net Weaver app deployment. If it decides to use a combined H ADR configuration that leverages Azure availability zones, please ensure that the Azure region you select supports availability zones. Please note that cross zone latency is higher compared with latency between Azure VMs that are part of the same availability set.

The document also needs to contain a detailed inventory of OS DB kernel and SAP support pack versions. SAP support for a given configuration in onpremises scenarios does not imply that the same configuration is supported by Azure VMs. Depending on the outcome, you might have to upgrade some of these software components. Three tier designs for SAP production systems are strongly recommended over two tier designs. Combining ASCs and application servers on the same Azure VM is not recommended. Using multi Sid cluster configurations for SAP Central services is supported with Windows as guest OS on Azure, whereas SAP Central Services multisid cluster configurations are not supported with Linux operating systems on Azure.

9. Planning and Deployment Checklist: Project Preparation and Planning (Part Two)

Step three inventory of all SAP interfaces. SAP and Nonsap. Step Four design of foundational services, including authentication and name resolution services active Directory and DNS network topology resource Group topology rolebased access controls for management of infrastructure structure and applications tagging strategy naming convention for infrastructure components, including for Azure VMs. Step Five microsoft Premier Support contract reference, including a direct contact with Microsoft Technical Account Manager Tan. For SAP support requirements, please refer to SAP. Note 201-5553. Step six the list of Azure subscriptions and their respective core quotas. If necessary, open a support request to increase quotas of Azure subscriptions.

Step seven the Data Reduction and Data Migration Plan for transferring SAP data into Azure in migration scenarios for SAP net weaver systems, SAP offers guidelines on how to keep the volume of data limited and the final. Step number eight automated Deployment approach. The goal of automation and infrastructure deployments on Azure is to ensure deterministic results. Many customers use PowerShell or Azure CLI based scripts and Azure Resource Manager templates. But there are other open source technologies, such as Ansible, that can be used to deploy Azure infrastructure for SAP and even to install SAP software.

10. Planning and Deployment Checklist: Pilot (Part One)

We’re now entering the pilot phase of the Toplevel SAP workload planning and deployment checklist. Pilot can run in parallel to the project planning and preparation phase. This phase can also be used to test options identified in the planning and preparation phase. As part of the pilot, it is recommended to set up and validate a full H ADR solution as well as a security design. In some cases, it might be also possible to use this phase to perform scalability tests or to deploy SAP sandbox systems. To run a pilot, customers should start by identifying a noncritical system that they want to migrate into Azure and continue by carrying out the following tasks task number One optimize data transfer into Azure. The approach and outcome are highly dependent on the customer’s connectivity to Azure.

Depending on the amount of data, it might be possible to use the Express route for this purpose site to site VPN or offline data transfer services such as Azure Data Box or the Azure Import Export Service. Task number two in case of an SAP Heterogeneous platform migration that involves an export and import of the database data, you need to test and optimize export and import phases. You can use Migration Monitor SWPM in case you do not need to combine the migration with a release upgrade, or you can use SAP Database Migration option DMO otherwise. Task number three perform technical validation for VM types. Please reference SAP support. Notes 192-8533 SAP Hana hardware directory and SAP product availability matrix to ensure accuracy of the information regarding supported Azure VM. SKUs, supported OS releases for these Azure VM.

SKUs and supported SAP and DBMS releases. In addition, please reference the information provided in SAPS Ratings on Azure VMs. Evaluate and test the Sizing of your Azure VMs regarding maximum storage throughput and network throughputs of the different VM types you chose in the planning phase. This data can be found in sizes for Virtual Machines in Azure. When the Azure VM Guest Operating system is Windows, it is important to consider the Maxed uncached this throughput for Sizing. In the case of Linux, it is also important to consider the Maxed uncached this throughput for Sizing now.

For storage, use Azure Standard SSD storage as a minimum for VMs representing SAP application layers and for nonperformance sensitive DBMS deployments, use Azure Premium storage for any DBMS VMs that are performance sensitive. Avoid using Azure Standard HDD disks. Use azure managed disks. Enable Azure write accelerator for DBMS log drives with Miseries Azure VMs. Please note that you need to be aware of documented write accelerator limits and usage restrictions. Never mount Azure data disks to an Azure Linux VM by using the device ID. Instead, use the universally unique identifier UUID. You also need to be careful when you use graphical tools to mount Azure data disks. You need to double-check the Andres Etc FS tab to make sure that the disks are mounted using the UUID.

• Category: Uncategorized