Pass Microsoft Azure SAP AZ-120 Exam in First Attempt Easily

Azure IaaS for SAP

1. Overview

Let me now take you through some of the overall advantages of taking this course while also touching on some of the overall characteristics of the AZ-120 Exam. This course will prepare you for the AZ-120 Exam, taking you through key topics and diving into what you need to know. In order to be successful in passing this exam, you need to be aware of the fact that this is a Microsoft exam and not an SAP exam, which means questions will be focused around how you would design, prepare, deploy, and configure the infrastructure in order to support SAP workloads. The exam will consist of the usual single multiple-choice questions (drag and drop) and one or more scenario cases. These consist of a customer scenario where you will be asked a few questions around that scenario, but what you need to be aware of is that you can't go back if you finish that scenario. There will also be a lab scenario where you will be asked a few questions and have to answer them by demonstrating your understanding through the Portal PowerShell or Azure CLI. Let's have a quick look at the Microsoft AZ-120 exam blueprint. This document shows that the focus areas are around design, build, and deploy. This doesn't mean you have to ignore other areas. You do need to get consistent marks across all areas to be able to pass the exam. You will have around 50 questions and about 210 minutes to complete them, so please make sure you keep track of your time. Finally, I want to emphasise that, regarding the nature of this course, we focused our efforts on the design, deploy, and operate side of SAP on Azure, so we won't be covering Azure fundamentals in any depth, but we will touch on those areas that could relate to an SAP design.

2. Microsoft Services

Let's spend some time discussing the advantages and the scale brought by Azure and by Microsoft services in general. Microsoft continues to expand its presence in the cloud by building more data centres globally. With over 61 Azure regions in over 140 countries, there are more data centres being built in Italy, Mexico, Qatar, Poland, Israel, and New Zealand with 1300 miles of high-speed beds highspeed optic. This proves the investment Microsoft is making in expanding its reach and capabilities in order to cater to all customer needs. Today you might be looking for a DRDC, tomorrow you might be moving completely to the cloud, and in the future you might go serverless. Microsoft gives you the platform to build and innovate at an incredibly fast pace. As mentioned previously, Microsoft is building new capabilities and enhancing existing ones in order to meet the demand and need for cloud services. From iOS to PaS Data, AI, ML, and IoT, there are over 600 services available on Azure. The only question is: how will you build your infrastructure and what services will you need to integrate? But luckily there is a cloud adoption framework, a well-architected framework, and an enterprise-scale landing zone to the rescue. Many businesses see Microsoft Azure Security Compliance as a major motivator for migration. Microsoft has an extensive list of compliance certifications from across the globe. Companies in the financial sector, such as banks, trust Microsoft Azure to run their critical customer systems and business obligations. The Microsoft Services have a number of beneficial characteristics. Capabilities are broad, deep, and suited to any industry, along with a global network of skilled professionals and partners. Expertise in the Microsoft portfolio includes both technology integration and digital transformation. Accountability for the long term, addressing complex challenges while mitigating risk, flexibility to engage in a way that works for you with the global reach to satisfy your business needs, and results that demonstrate the ability of Microsoft to lead change and deliver on their promises Assist.

3. Technical Terms Explained

Let's talk about some terms you should know for the exam. You are responsible for configuring OS and application high availability and maintenance, which includes patching the OS and application stack, if you use IAS Infrastructure as a Service, such as Virtual Machines. Pass Platform as a Service, such as SQL, which is maintained by Microsoft, so you don't need to worry about the underlying infrastructure. Microsoft is responsible for availability, patching, and maintaining the system on your behalf, but you can still configure the application layer to your needs. SAS Software as a Service is a preconfigured platform, meaning that you have little or no configuration to make on the platform and just manage your data. SAP component. an individual SAP application such as an ERP central component ECC business warehouse BW Solution Manager or Enterprise Portal SAP components can be based on traditional ABAP or Java technologies or a non-NetWeaver-based application such as Business Objects. SAP Environment One or more SAP components are logically grouped to perform a business function such as development, quality assurance, training, disaster recovery, or production. SAP landscape refers to the entire SAP asset base in your IT landscape. The SAP landscape includes all production and nonproduction environments. SAP System The combination of a DBMS layer and an application layer, for example, in an SAP ERP development system, an SAP BW test system, or an SAP CRM production system Azure deployments don't support dividing these two layers between on-premises and Azure. SAP systems are either on-premises or in Azure. The various systems of an SAP landscape can be deployed in Azure or on-premises. You can, for example, deploy SAP CRM development and test systems in Azure while deploying SAP CRM production systems on-premises. For SAP Hana on Azure large instances, it is intended that you host the SAP application layer of SAP systems in VMs and the related SAP Hana instance on a unit in the SAP Hana on Azure large instances. stamp and a large example Stamp is a hardware infrastructure stack that is SAP Hana TDI certified and dedicated to run SAP Hana instances within Azure. SAP Hana on Azure large instances is the official name for the offer in Azure to run Hana instances on SAP Hana TDI-certified hardware that is deployed in large instance TAMPs in different Azure regions. The related term Hana large instance is short for SAP Hana on Azure large instances and is widely used in this technical deployment guide. Cross-premises describes a scenario where VMs are deployed to an Azure subscription that has site-to-site multi-site or Azure Express route connectivity between on-premises data centres and Azure. In common Azure documentation, these kinds of deployments are described as cross-premises scenarios. The reason for the connection is to extend on-premises domains from Azure Active Directory or Open LDAP and on-premises DNS into Azure. The on-premises landscape is extended to include Azure subscription assets. With this extension, the VMs can be part of the on-premises domain. Users of the on-premises domain can access the servers and run services on those VMs, such as DBMS services. Communication and name resolution between VMs deployed on-premises and Azure-deployed VMs are possible. This scenario is typical of the way in which most SAP assets are deployed. For more information, please see Azure VPN Gateway and Create a Virtual Network with a Site Connection. A customer deployed in the Hana Lodge instance is isolated into a tenant by using the Azure Portal tenant. A tenant is isolated in the networking, storage, and compute layers from other tenants. Storage and compute units assigned to the different tenants can't see each other or communicate with each other. A customer can choose to have deployments into different tenants at the Hana large instance stamp level. Even then, there is no communication between tenants on the Hana Large Instance stamp level. SKU category. For Hana Large Instance, two categories of SKUs are offered: Type One and Type Two, which define the Microsoft internal deployment size of Hana Large Instance. Before Hana Large Instance units can get deployed, a Hana Large Instance stamp consisting of compute network and storage racks needs to be deployed in a data-centered location. Such a deployment is called a Hana large instance. Tab. Or, from revision Four onwards, we use the alternate term, "large instance row revision." There are two different stamped revisions for Hana Large instance stands. These differ in architecture and proximity to Azure Virtual Machine hosts. Revision Three is the original design that got deployed in mid year 2016.Revision Four is a new design that can provide closer proximity to Azure Virtual Machine hosts and, with that, lower network latency between AzureVMs and Hana large instance units. Revision Four. Two existing Revision Four: DC's resources are rebranded as "bare metal infrastructure." Customers can access their resources as baremetal instances from the Azure Portal MSEE Microsoft Enterprise EdgeRouters devices are deployed at the edge of a Microsoft network facing external partners in Azure Express Route architecture.

4. Deployment Options

Let's look at the different ways we can deploy SAP on Azure. SAP Hana large instances, or HLI, are physical servers, meaning bare metal, and we will go into further detail on this particular topic later. Return this module. HLI does not reside in the same data centre as Azure Services, but in close proximity, connected through high-throughput links to satisfy SAP Hana network latency. Requirements As previously stated, HLI are classified into two types: type one and type two. Please make sure that the version of Linux you want to install is supported on HLI. In order to do so, you need to check Azure Services' regional availability for your city Site SAP Hana can also be installed on an IaaS virtual machine running on Azure. Running SAP Hana on IAS supports more Linux versions than HLI, and you just need to make sure you appreciate the constraints before you attempt to plan and design your SAP landscape and regional availability. All this information can be further referenced on the Microsoft SAP support page on Azure docs. SAP. NetWeaver can be installed on both Windows and Linux. iOS VMs running on Azure much like above. Make sure you understand the versions supported by both HLI and IAS. You won't be asked those specific questions in the exam, but you do need to know that SAP Hana can only run on Red Hat and Susie, while NetWeaver can run on Windows, SQL, and Linux.

5. Azure Compute (Part One)

Let's now begin looking at Azure Compute. Azure Compute SKUs come in different flavors, depending on your usage scenarios. The important aspect of choosing the right type of VM is understanding your application behaviour and needs. Questions you may ask yourself include: is the application memory- or storage intensive? Maybe you need access to a dedicated graphics card for applications such as CAD or, in our case, SAP Hana, which requires high memory capacity as its database is loaded into memory for quick access and processing. SAP has devised its supported AzureVM SKUs according to application requirements. Series E and M have a large memory to CPU ratio, which means you get more RAM allocated per virtual CPU. The D series is only used for development purposes as it does not provide the required memory for SAP. Hana. That brings us to Hana. Large instances or HLI? These are bare metal servers with dedicated hardware that are allocated in a dedicated data center. As you can imagine, these are more powerful and can provide more memory for enterprise and large customers. It starts at 36 Intel CPUs with 768 GB of RAM and goes up to 480 Intel CPUs with 24 terabytes of RAM. You would also get network and storage isolation. Not all regions have HLI available, and you will need to check Microsoft Azure documents for region availability. The exam certainly won't test you on numbers in terms of CPU or RAM, but it will test your knowledge on where these SKUs could come in useful, especially from an SAP perspective. Please have a look at SAP article number 192-8533 and ensure that you understand what is supported. Let's now explore the different types of availability that you can design for your SAP workload—or in fact, any other workload on Azure. Let's start with a single VM. Microsoft will offer you 95% SLA on a VM running standard HDD-managed disks, while a VM running standard SSD-managed discs will have a 99.5% SLA, and a premium SSD-ultra discs SLA would be 99 9%. An availability set involves two or more VMs distributed between different fault domains and update domains. You can reference Microsoft Azure documentation to know more about faults and updating domains, but if you have another VM in that availability set, then your service will not be affected and you will have an SLA of 99.95% for availability zones. This is the next level of protection. Availability sets can protect you from service failures in a single data center. While availability zones can protect you against a data centre outage, this has greater resilience and an SLA of 99 99%. There's something important when looking at availability zones. Proximity Placement Groups One of the common use cases for proximity placement groups is with multitiered, mission-critical applications such as SAP. This service will enable customers to achieve collocation of IS resources with low network latency. You can use region pairs to create Azure resources in specific geographic regions, such as the West US. North Europe or Southeast Asia. Within each region, multiple data centres exist to provide redundancy and availability. This approach allows you to be more flexible when designing applications, allowing you to create VMs that are closest to your users while also meeting any legal compliance or tax requirements and purposes. You.

6. Azure Compute (Part Two)

One important feature used for scaling in Azure is Azure scale set in SAP. On Azure, we usually configure application servers in scale-out mode, which means adding more VMs as we need, while for DBMS, we tend to scale up by adding more CPU and memory. Using Azure scale sets can help us add another high availability feature by looking at VM metrics and making decisions based on load. The incoming traffic will be load balanced using either an Azure load balancer or an application gateway. I will touch on various load balancing technologies within Azure later in this module. These thresholds can be set through the Azure scale sets. Management page on the portal. Skill sets will provide not just for the VM but for your application through metrics that can be streamed to Loganalytics and Azure Monitor, which we will touch on later in this course. This type of configuration will use a base image, which could be a custom or Azure Marketplace image, to build and provision new VMs from. This will ensure your VM deployments have the same configurations and updates, hence ensuring consistency across the board. Auto-scaling for Azure scale sets can be triggered in a variety of ways, including via the Portal by changing scale set metrics or automatically via an Azure MonitorCPU alert, which can run a process to scale up or down the Azure scale sets. You have to be mindful when using Azure scale sets. These machines are ephemeral, which means they will be decommissioned as soon as the utilisation normalizes. Hence, you would lose everything on these machines when they are destroyed. Thus, the rule of thumb to use is to use Azure scale sets for a stateless application or for an application that stores its session data outside of that VM, maybe on an NFS share, et cetera. The last point to make is that Azure Scale Sets works on a scale. As the name implies, it can scale up hundreds or 1000 VMs in a short period of time to meet the demands and adhere to the configuration rules. I have avoided diving into each of those load balancing technologies. I recommend that you review each of these topics if you feel you need to before continuing with the course, as this will help you understand SAP Hana on Azure even more. Large Instances is a unique solution to Azure. In addition to providing virtual machines for deploying and running SAP Hana, Azure offers you the possibility to run and deploy SAP Hana on bare metal servers that are dedicated to you. SAP Hana on Azure Large Instances is built on dedicated non-shared host server bare metal hardware. The server hardware is embedded in larger stamps that contain compute, server networking, and storage infrastructure. as a combination. It is. Hana Taylor's. data centre integration TDI. certified as of July, 2019. We differentiate between two different revisions of Hanalarge instance tamps and the location of the deployments. Revision 3 is the set of stamps that were made available for customers to deploy before July 2019. Revision Four: Revision Four is the new stamp design that is deployed in close proximity to Azure VM hosts and which has so far been released in the Azure region. If you bring up the products available by region website and search by SAP, then scroll down to SAP Hana on Azure large instances This page will show Hoi availability per region. This way, when you design your infrastructure, you will be able to do so properly. I will cover network connectivity in the Azure networking section of the scores. For now, we will focus on the compute side of the story. Normally, Hoi customers run their SAP Hana DBSon Hoi application and other middleware on Azure VMs. So when you think of availability for HLI, you have to think in terms of traditional data centers. You should be aware of the SAP supported configurations on HLI, such as single node with one sid and single node m cost, if you have a second hardware server to support your Ha and Dr scenarios. This is just a scale-up configuration with multiple sets. This is also a scale-up configuration with one or more sets of storage that is replicated to a secondary site. There is another scenario where a secondary node in a secondary region is provisioned to serve a purpose, such as running QA testing. While the primary node is used for production, the secondary node can be repurposed in failover scenarios HSR at Stone This type of configuration does not support amp cost. By the way, Stoneth stands for should the offending node be in the head, which is a technique for fencing a VM in a cluster used on the red hat. Let's carry on with more Hoi configuration scenarios. With HSR and Dr using storage replication, this configuration doesn't support m cost, but it will give you the option to repurpose the Dr node in the second region for QA testing purposes while having a standby node in the primary region. Host auto failover one plus one: you can have this type of configuration when you have at least two nodes with one master worker and one on standby. Scale out with standby, which means having one master and one or more workers with a standby. It is supported to also turn the standby node over to another worker, which would give you the scale-out option. also without the standby node. Scale out without standby This configuration supports multiple nodes in a scale-out topology: one node set up with a master role and one or more nodes with a worker role. However, there can only be one masternode at any single point in time. Scale out with Dr. using storage replication It can support multi-node scale-out with a standby or repurposed node using storage replication at the DR site. Single nodes Dr. with HSR This scenario still utilises HSR replication for a scale-up configuration that supports single or multi sits. This configuration can also be enhanced to use the Dr node for QA or development while the Master remains at the primary site. high availability and disaster recovery using Hana system replication. This can have a master worker replicating to a secondary using synchronous HSR while having a doctor note with an asynchronous HSR configuration. Also with this configuration, the Dr node in theDr state can be repurposed for QA or dev. scale out with Dr. using HSR. This occurs when multiple worker nodes or nodes and a standby node or nodes are running on primary sites and replicating the same configuration to Drside in asynchronous mode using HSR. For more detail, you can reference the Microsoft Azure documentation under SAPHana on Azure HLI supported scenarios. HLI resides in a different data centre from Microsoft Azure. As part of the provisioning process, you will have an express route circuit termination for a designed virtual network inside your Azure subscription. We touch on network configuration in more detail when we cover the Azure Networking and the Designing an Azure solution to support SAP workload load sections.

7. Azure Compute (Part Three)

It is important to understand HLI requirements before onboarding, so let's cover them. You will need an Azure subscription, which will be linked to your HLI, and this is where your HLI will be bought, both provisioned and built. Also, you need to ensure you have the right support contract with Microsoft. Please visit SAP article number 20155 to understand more about those requirements. Please note that this is not required for the exam. After going through sizing with SAP, you also need to decide on HLISkew after going through Sizing with SAP. Express Route from on-premises to Azure is advisable in order to benefit from Express Route global reach, which we will come back to in the later section on Azure networking of these cars. Express Route will ensure a private and secure path to your Azure region and resources without transposing them through the Internet. It also provides SLA and high availability configurations. You will also need to have your licence for either Susie or Red Hat Linux servers with a support contract with your chosen Linux provider. Last but not least, which is an important point to remember, HLI has no direct access to the Internet. Thus, in order to update or patch them, you will need to install Susie Linux or Red HatSubscription Management tool on a VM running under your connected subscription to facilitate pushing updates to HLI. This is an important point to remember for the exam. The Azure Load Balancer works at layer four, which means it looks at network protocol and ports to determine the backend load balancing rule. It comes in two SKUs Basic, which is zoned, which means that it does not support availability zones, and Standard, which is zone redundant. As for SAP, we always go for the standard SKU in order to provide the best redundancy. If you require more filtering capabilities, especially for HTTP and HTTPS, then you can use Azure Application Gateway. This service works at layer seven, hence it can detect anomalies with HTTP headers directing traffic to the back end based on protocol, ports, or a HTTP header. Application Gateway can be enhanced to enable web application firewall features, which would help protect web applications against exploits and vulnerabilities such as SQL injections and cross-site scripting. As the most common WAF on Application Gateway is based on the Open Web Application Security Project (Oasp), the WAF automatically updates to include protection against new vulnerabilities with no additional configuration needed. Azure Traffic Manager is a DNS-based traffic load balancer that enables you to distribute traffic optimally to services across global Azure regions while providing high availability and responsiveness. Traffic Manager uses DNS to direct client requests to the most appropriate service endpoint based on a traffic routing method and the help of the endpoints. Endpoints are just Internet-facing services hosted either inside or outside of Azure. Azure Front Door works at layer seven only for HTTP, using any cast protocol with Split, TCP, and Microsoft's Global Network to improve global connectivity based on your routing method, so you can ensure that Front Door will root your client request to the fastest and most available application. Back End An application back end is any internet-facing service hosted inside or outside of Azure. When Door combines the capabilities of all of the above types of load balancers into a single service.

8. Azure Storage (Part One)

Now let's look at Azure storage options. These are the simplest types of storage in Azure. An Azure Storage account should have a unique name within Azure as of its creation date that is three to 24 alphanumeric or numeric characters in length, all in lowercase. It comes in two performance tiers, standard and premium. Depending on your application requirements, you could drive maximum ingress of 10GB and egress of 50GB per storage account. They are highly durable, with availability ranging from at least three copies in one region to six copies split between paired regions. They are secure, as data is encrypted at rest with 256 bits. With AES encryption, which is one of the strongest block cyphers available and is Phipps 142 compliant, an Azure Storage account can scale up to five petabytes in capacity, which is huge considering that you can grow this by provisioning up to 200 storage accounts per Azure subscription. Azure Storage accounts offer blob storage—either block append or page blobs. Block storage is used to store unstructured data such as files, images, videos, etc. Append Blob is optimised for append operations, as blocks are added to the end of the blob only. while page blobs are used to create unmanaged Azure VM disks. It is optimised for random read and write operations. Azure Storage accounts offer various replication options. Locally. Redundant Storage This simple and low-cost configuration offers three copies of your datasynchronous within your primary region. Zone-redundant storage ZRS: This offers three copies of your data across three availability zones within your primary region. Georgeundant Storage offers a cross-regional configuration that offers high availability and maximum durability. Data will be copied three times synchronously while having another three copies asynchronously in the second region. There is another flavour of this configuration, which is called Georedundant Storage with Read Access, which gives you the flexibility to read the secondary region copies only for reporting purposes. This is great when you want to minimise the impact on production by reporting against secondary When thinking of your storage design, Azure Storage offers various access tiers. HS is optimised for frequent access to data. This is the default configuration when creating a storage account. Cool is optimised for storing large amounts of data that is infrequently accessed and stored for at least 30 days. The cost of storage is lower than Hot Tier, but there is a cost for accessing the data, which could make it more expensive than Hot Tier, but there Only available for individual blocks, this configuration is suitable for data that can tolerate several hours of retrieval. Latency. One last thing to reiterate here is that access to Azure Storage accounts is encrypted in transit over HTTPS and addressed using AES encryption. As we have mentioned earlier, in order to access the storage account, there are three ways to limit access from the control plane, which is the point where you change storage configuration, such as with Portal PowerShell or Azure CLI. One way is called role-based access control, which uses Azure Active Directory to authenticate and authorise access for admins and operation personnel. The other way is by using primary and secondary account keys. These keys will give you access to everything in that storage account for both read and write operations. Normally, account keys are used for applications that require access to the storage account. Having two account keys will give you the flexibility to rotate keys on a regular basis without service downtime. Shared access signatures are timed accesses for a specific operation—read, write, and delete. This avenue has greater control over the operation of the storage account, and access can be confined to a single container. And by the way, when you create Blob Storage, the first thing you do is create a container with private or public access. This container will host your blobs or files.

Hide