AZ-120 Microsoft Azure SAP – Design an Azure Solution to Support SAP Workloads

11. NFS Storage

Different types of NFS storage are available. The first type is hosted and this is where you build an NFS solution like Pacemaker on Sushi or Glaster FS on Red Hat. These are rocksolid and performance solutions. The other is managed such as Azure. NetApp files connected to SAP, Hana, Or. NetWeaver and they have been tested and certified by Microsoft for SAP workloads. SMB storage also falls into two categories. The first one is hosted. There are many options for SMB hosted storage depending on your preferred vendor. If you are a Windows Server shop then I would consider Storage Spaces Direct built on top of Windows Server 2016 or 2019. That would be with a scale out file server role or Cluster with shared disk emulated via third party such as SIOs Data Keeper. The other option is managed using Azure files which can offer SMB capabilities. But you need to be aware that Azure files supports file system level permissions only from Azure. Adds joined Azure VMs you.

12. Recommendations for Both SQL Server and Oracle

We will now look at our SQL Server recommendations. Tempdb can be stored on the D drive of Windows Server provisioned from Azure image gallery. This volume is no persistent, hence we could place temdb on that drive as it gets recreated on VM restart. Multiple temdb is a SQL Server feature having multiple temdb files. Equate. The number of cores is good from a performance perspective and it can go up to eight. But please make sure that you don’t exceed that recommendation, as it might have an adverse effect on performance. For data and log volumes, you need to ensure that Caching is disabled on log volume and that read only Caching on data volumes is used. If you are using the M series VM SKUs, please make sure you enable the right accelerator on those managed disks in order to minimize IO latency. Now, in terms of our Oracle recommendations single instance with NTFS formatted data disks, only DB and redo logs must be stored on separate data disks. Temp files like in Temdb file for SQL Server can be stored on the temporary VM drive, which is drive D. There is no support for Oracle Rock implementation. From the networking perspective, oracle recommends using Oracle data guard. Finally, you may choose to check SAP Nodes 203-9619 for a bit more detail.

13. HLI HA

Let’s now cover the details. For Hliha capabilities, you will need at least two nodes to run storage replication. So in this case, two nodes in different stamps within two Azure regions. This is storage capability and not part of Hana functionality. Also, this is the default disaster recovery mechanism method offered for HLI Hana system replication. Or for short, HSR is the builtin functionality within SAP Hana system to replicate data between two SAP Hana systems. This method minimizes the recovery time objective.

Due to regular replication intervals, you can have synchronous and Asynchronous modes depending on where you are replicating to. Normally, this means synchronous to another HLI stamp in the same region, and asynchronous to an HLI stamp in another region. The final option for Hliha is Host Auto Failover, a local fault recovery solution for SAP Hana. That’s an alternative to Hana system replication. If the master node becomes unavailable, you configure one or more standby SAP SAP Hana nodes in ScaleOut mode, and SAP Hana automatically fades over to a standby node.

14. Azure VM Security

When it comes to security recommendations and things to consider around VM security, there are a few more aspects to cover in detail. For network security, there are many ways to protect your perimeter network and traffic flows internally. We have talked about NSGs, but NHGs reside on Subnets, so how can we control egress and ingress traffic flows? Flow at the perimeter firewalls like Azure Firewall or Next Gen Firewall or the so called NVA can control traffic flow using user defined routing UDR. This way, we can control the flow between different VNETs and externally. Normally, a firewall goes in front of your web dispatcher, but never between your application and SAP DBMS servers. This is important. Our recommendation is to follow the Microsoft guiding principles around network security by going through Cloud adoption framework and Virtual Data Center reference architectures.

This is to ensure that you are following networking and security best Practices for Storage Security There are many ways to protect your data storage encryption, and this comes in many flavors. Intransit, which uses Https or Http over TLS to encrypt the traffic during transmission. As Data resides on storage, it can be encrypted at rest using storage service encryption using either Microsoft managed keys or client owned keys. The other storage encryption method is using Ade. We have talked about this type of disk encryption using BitLocker for Windows and Dmcrypts on Linux. VMs encryption keys get stored in the Azure key world. For data residing inside databases such as SQL and SAP Hana, you can use native Hana data encryption methods or SQL transparent data encryption. Just remember that in order to be able to apply SQL TDE, you need to create an empty database and encrypted prior to injecting data.

15. Licensing

We will now look at what you need in order to license your SAP landscape for Azure VMs, Microsoft takes care of licenses for you as part of Azure services such as Windows and SQL licenses. However, as stated in the SAP Note 138-0654, customers need to procure licenses for their SAP software. Also, according to SAP Note 201-5553, SAP requires having a support contract with Microsoft. There are two support contracts available to purchase Professional Direct which is the minimum support level requirement. This will give you access to Azure specific support from Microsoft.

The other option is Premier Support and this is the recommended level of support, especially if your SAP is based on Windows and SQL servers. In addition to the above, if you are using Red Hat or Susie then you will need to purchase the appropriate Linux support for their SAP on Linux implementations. There are also requirements for HLI licensing which you need to be aware of as described in the SAP Notes 201-5553, you need to have a Microsoft Pre Premier Support contract for HLI. If you will be using HLI instances larger than 384 CPUs then you will need to extend your Premier support to include Azure Rapid Response.

16. SAP Integrations and Dependencies

We will now look at SAP integrations and dependencies. There are lots of integrations available for SAP on the Microsoft platform. Working through their close partnership, SAP customers can expose APIs to customers or partners through the API management on SAP Cloud and API management on Microsoft Azure. There are other integrations that need to be documented and modified in case of SAP systems migrations, such as SAP Cloud platform integration, API management, SAP Gateway and SAP Cloud SDKs. Now, when looking at dependencies, you will need to look both at upstream and downstream dependencies between SAP systems and other Nonsap systems. If you are migrating your SAP system to Azure, you need to make sure that those dependencies that integrate closely together stay close during and after the migration is complete. As mentioned before, SAP is sensitive to network latency.

This is where analyzing traffic patterns between various SAP system components is essential in order to understand those dependencies so you can map them in your migration plan. Examining and documenting areas sensitive to latency is key for a successful migration in some circumstances. You can run an analysis to see what effect you would have if you introduce some latency in order to understand the behavior of your application and put the remediation work in place as you perform the migration. While in some scenarios you might start experiencing some issues post migration, perhaps traffic is not routing back to on premise or NSGs are blocking certain types of traffic. So what I’m trying to say is that understanding how these systems are communicating in the first place is paramount to ensure a successful migration. Also, please don’t forget to document your SAP application configuration as you progress through moving SAP to Azure and configuring new instances.

17. Supported HA and DR Options

We will now look at supported Ha and Dr options for Azure VM databases, starting with HLI. We talked about the various ways of making your HLI implementations highly available. For example, using storage replication for single node HLI or single instance. And what we mean here is the disk subsystem is highly available, but not the machine itself. Scale out with or without standby. Here, you have multiple nodes where you have replicationing happening between them. So when one node goes down, the other node will be able to take over, such as having NetApp storage replication. This can protect against regional failure as well. By replicating storage to another region, the Dr site must have the same number of nodes, and Hana volume sets are attached to all nodes. The other option is to use Hana system replication, as we’ve mentioned previously, to enable Ha and DRT.

This is a shared nothing setup. By having separate disks attached to each Hana instance which is replicated to the Dr site. You may choose to look at SAP Note 192-8533 for more details. When evaluating High Availability and Disaster Recovery requirements, it’s important that you consider the implications of choosing between two tier and three tier architecture. In two tier configurations, the database and NetWeaver components are installed on the same Azure VM to avoid network contention. However, in three tier configurations, database and application components are installed on separate VMs. This choice also has additional implications regarding Sizing. Since two tier and three tier SAPS ratings for a given VM SKU differ. Microsoft supports the following SAP Hana High Availability and Disaster Recovery capabilities storage Replication the storage system’s ability to replicate all data to another Hana large instance stump in another Azure region, SAP Hana operates independently of this method. This functionality is the default Dr mechanism offered for Hana large instances. Hana system. Replication. The replication of all data in SAP hana to a separate SAP hana system. The recovery time objective is minimized through data replication at regular intervals. SAP Hana supports asynchronous synchronous in memory and Asynchronous modes.

Synchronous mode is used only for SAP Hana systems that are within the same data center or less than 100 km apart. Another one is SAP Hana multiple components in one database deployments as overlaying scenarios work with the Ha and Dr methods listed above. An exception is the use of Hana system replication with an automatic failover cluster based on pacemaker. Such a case only supports one Hana instance per unit. For SAP Hana MDC deployments, only non storage based Ha and Dr methods work if more than one tenant is deployed. With one tenant deployed, all methods listed are valid. We talked about HLI and Application High Availability, but we haven’t touched on database Ha supported options yet, so let’s do so now.

For SQL Server, we can create Ha through SQL Server failover clustering, log, shipping, database mirroring, and Always on. For SAP Hana, you can use HSR with or without automatic failover or HSR without auto failover and with or without data preload. Not forgetting SAP Hana ScaleOut configuration for Oracle oracle data guard with Fsfa or manual failover are supported. Please look at the Microsoft documentation for further details on each of these configurations and illustrations of how storage subsystems should be configured in each scenario.

• Category: Uncategorized