Design an Azure Solution to Support SAP Workloads

1. Introduction

Hello and welcome back to the Microsoft Azure for SAP workloads course. In this section, we will be looking at the design recommendations for SAP workloads on Azure. So let's get started. I'm your host, NicolaiCaprice,founder of Reteam Labs. This course is brought to you in partnership with Sam khan Jar, senior Azure cloud solution architect at Microsoft. There are six sections in total in this course covering all of the AZ 120 exam objectives. This current section, two of this course, will cover design principles for SAP workloads on Azure, looking at what you can and should do against what you can't and shouldn't do in order to ensure your designs are certified by SAP and Microsoft. So let's dive in. This second section will build on the previous sections of this course by bringing the technologies together to show how an SAP landscape would look on Azure and what components are needed in order to run your system efficiently. This section will be split into five individual parts.

The first part will take you through sample architectures, understanding the Flow, Ha, and Dry capabilities that can be put in place by looking at both SAP Hana and Net Weaver and both HLI and Azure VMs. Then we will dive into more specific considerations when designing these components to ensure that the solution is architecturally supported by Microsoft and SAP and that it follows their guiding principles wherever possible. Licensing is an important aspect of the design when it comes to purchasing, so understanding what you need to purchase against what's offered as part of the Azure service is important. Then we take a turn to show how to integrate with external systems being on premise or other clouds, finishing with supported scenarios for Ha and Dr. This is a pretty heavy section, so please make sure you have understood the previous section and that you have sufficient knowledge of various Azure services at a reasonable debt before starting this current section.

2. Net Weaver Architecture

Let's look at some sample architectures in order to understand the design mechanisms behind these solutions before diving into more details later in this section. The first thing we'll do is to look at the architecture at a high level. The SAP Net Weaver architecture is based on the Windows operating system and SQL Server, utilizing two very important functionalities of Windows. These are the Windows Failover clustering and the SQL Always On features of SQL Server. These features will give us A and D at the same time through the use of synchronous and asynchronous replication across two Azure regions. The numbers in the diagram on the screen show the flow as we step through each component of the design. Let's analyses this flow number one using Azure Active Directory synchronized with on premises Active Directory. An SAP application user authenticates from on premises to SAP landscape on Azure with single sign-on credentials.

The Azure High Speed Express Route gateway, ranked second, securely connects on-premises networks to Azure Virtual Machines and other resources. Third, the request is routed through highly available SAP Central Services and then through SAP Application Service, which is hosted on Azure Virtual Machines. Number four. The request moves from the SAP App Server to the SQL Server running on a primary high-performance Azure VM.

The number five primary active and secondary standby servers, which are running on SAP certified Virtual Machines, are 99.95% clustered at the OS level. Data replication is handled through SQL Server Always On in synchronous mode from primary to secondary, enabling zero recovery point objective. SQL Server data has persisted to high-performance Azure Premium storage. Number seven: SQL Server data is replicated to Disaster Recovery virtual machines in another Azure region. This is done through Azure's High-Speed Backbone network and using SQL Server's Always On Replication in Asynchronous mode. The Disaster Recovery VM can be smaller than the production VM in order to save costs. Eight VMs in the Disaster Recovery region can be used for nonproduction work to also save costs. The SAP App Server with ASCs on the Dry side can be in standby shutdown mode and can be rebooted when needed to further save costs.

3. SAP HANA Architecture (VM)

This design is based on the SAP Hana backend and the Linux Susie or Linux Red Hot distributions for both. Even though the Linux OS implementation is the same, the vendor licensing differs, so please pay attention to that aspect. Share was also designed for Ha and Dry across two Azure regions using SAP Hana system replication, which is the equivalent of SQL Always On from our last example. It is also utilizing synchronous and asynchronous replication to meet Ha and Dry requirements. With this design, we have also introduced NetApp file share for the NFS volumes used by each of the SAP components, using Azure Site Recovery and building a Dry plan for Apps, ASCs, and the Web dispatcher servers. Let's analyses the data flow number one. Using Azure Active Directory synchronized with on premises Active Directory, an SAP application user authenticates from on premises to SAP landscape on Azure with single sign-on credentials. Number two, the Azure High-speed Express route, The Azure Virtual Machines Gateway secures the connection of on-premises networks to Azure Virtual Machines and other resources. Three, the request flows into highly available SAP SAP Central Services, ASCs, and then through SAP application servers running on Azure Virtual Machines. Number four, the request moves from the SAP App server to the SAP Hana server running on a primary high-performance Azure VM. For 99.5% of the time, the number five primary active and secondary standby servers are running on SAP certified Virtual Machines cluster OS level. Availability data replication is handled through Shrine synchronous mode from primary to secondary, enabling zero recovery point objective. SAP Hana data, at number six, is persistent to high performance Azure Premium storage. Number seven SAP Hana data is replicated to Disaster Recovery Virtual Machines in another Azure region through Azure's high speed backbone network and using HSR in Asynchronous mode. The disaster recovery VM can be smaller than the production VM in order to save costs. Eight VMs in the Disaster Recovery region can be used for nonproduction work in order to save costs. Number nine SAP App server with ASCs on the disaster recovery site can be started in shutdown mode and restarted only when necessary to save money. Or ASR can be used to replicate application VMs to Dry Sights.

4. SAP HANA Architecture (HLI)

This particular diagram shows the an Azure HLI sample architecture. You can see the main differences here where you have an express route going between Azure VMs and HLI stamps, which provides the necessary connectivity. Let's once again analyses the data flow steps. Number One: In this example, an onpremisesSAP user executes a request via the afire interface or another custom interface. Number two, the Azure High-speed Express Gateway, is used to connect to Azure virtual machines. Three, the request flows into highly available SAP Central Services and then through Application Service running on Azure Virtual Machines in an availability set offering a 99.95% uptime SLA. Number four, the request is sent from the app server to SAP Hana running on primary large instance blades. 99.9% of the primary and secondary blades are clustered at the OS level. Availability data replication is handled through Hana system replication in synchronous mode from primary to secondary, enabling zero RPL. SAP Hana data is saved to high-performance NFS storage. Seventh, data from NFS storage is backed up in seconds using built-in storage snapshots on local storage, with no impact on database performance. Number eight, a persistent data volume on secondary storages replicated to a dedicated Dry system through a dedicated backbone network for Hana storage replication. And finally, nine, a large instance on the Dry site can be used for nonproduction to save costs by mounting both the QA storage and the Dry replicated volume read-only.

5. Network Recommendations

The following part of this section will look at the best design principles when approaching an SAP workload and how we could put Azure Services to best use in our design. The network is a fundamental piece of our SAP system design and actually of any system design. It's the core function foundation that brings everything together into a meaningful service accessible internally or externally. When designing for network security, you need to understand how your Vet will be segmented. How much is each subnet's ingress and egress traffic through network security groups, or even firewalls? If you think in terms of the hub and spoke context, there are certain criteria that need to be considered. When thinking of security controls and firewall appliances, That's when network performance really becomes key. And on the topic of network performance, the following aspects are important to consider: Because of VNet segmentation in the context of an SAP system, we need to ensure traffic is confined within a single VNet. For a single SAP system, going through peernetworks and routing through network appliances such as firewalls will impact performance and increase latency.

Your SAP systems are network sensitive, so you must ensure your design decisions factor that in mind when segmenting your VNet and NSGs. There are a few other factors that could help improve network latency, which we will get to when we touch on compute design considerations later in this section. For network reliability, please make sure that you use quality cross-premises connections that are low in latency, with sufficient bandwidth and no packet loss. SAP is very sensitive to these metrics, and you could experience major issues if traffic suffers from latency or packet loss between the application and the SAP system. Proximity placement groups called PPGs can be used to force group different VM types into a single Azure datacenter in order to optimize the network latency between these different VM types to the best possible. In the process of deploying the first VM into such a proximity placement group, the VM gets bounced to a specific data center. This has its limitations and challenges, especially if you are using different types of VM SKUs which might not be available in the same data center. So please make sure to minimize the number of VMs under a single PPG. Also, please have a look at SAP Nodes 20155 Three for more information.

Study with ExamSnap to prepare for Microsoft Certified: Azure for SAP Workloads Specialty Practice Test Questions and Answers, Study Guide, and a comprehensive Video Training Course. Powered by the popular VCE format, Microsoft Certified: Azure for SAP Workloads Specialty Certification Exam Dumps compiled by the industry experts to make sure that you get verified answers. Our Product team ensures that our exams provide Microsoft Certified: Azure for SAP Workloads Specialty Practice Test Questions & Exam Dumps that are up-to-date.