SAP S4 HANA on Azure VMs

By Ashwin Venugopal -

 



High Level Architecture

The following reference architecture shows a set of proven practices for running S/4 HANA in a high availability environment that supports disaster recovery on Azure.




Architectural Components

This reference architecture provides details about an enterprise-grade, production-level system and this configuration can also be reduced to a single virtual machine to suit your business, but the following components are needed:
  • Virtual Network-  The Azure virtual network service can connect all the Azure resources with each other securely while also allowing you to connect to an on-premises environment via virtual gateway provisioned as a part of ExpressRoute or Site-to-Site connection. This virtual gateway resides in the virtual network that serves as the hub of a hub-spoke hierarchy consisting of multiple, peered virtual networks while the spokes represent the individual virtual networks hosting the SAP applications and database tiers.

  • Subnets- All the virtual network is divided into separate subnets hosting application and database tiers with some additional subnets hosting infrastructure services and serving the role of the network perimeter even if they commonly reside in the hub virtual network.

  • Virtual Machines- virtual machines used for running Linux for the application tier as well as database tier can be grouped as:
  1. Application tier- which includes Fiori Front-end Server pool, SAP Web dispatcher pool, application server pool, and SAP Central Services cluster. A highly available Network File System (NFS) service is required for the high availability of Central Services on Azure Linux virtual machines. 
  2. NFS Cluster- It extensively uses an NFS server running on a Linux cluster to store data shared between SAP systems which can also be shared across multiple SAP systems. The High Availability Extension for the selected Linux distribution is used for the high availability of NFS service.
  3. SAP HANA- The database tier can use two or more Linux VMs in a cluster to achieve high availability. While HANA System Replication (HSR) is widely used to replicate contents between primary and secondary HANA systems, the Linux clustering is used to detect system failures and facilitate automatic failover. To ensure if the failed system is completely isolated or shut down in order to avoid the cluster split-brain condition, you can use a storage-based or cloud-based fencing mechanism.
  4. Jumpbox- It is also known as Bastion Host which can easily run a hardened operating system instance that the administrators can use to connect to the other virtual machines while also running Windows or Linux. You can use a Windows jumpbox to run tools like HANA cockpit or HANA studio.   

  • Load balancers- Both the built-in SAP load balancer instances are used to distribute traffic to VMs in the application and database tiers.

  • Availability sets- VMs for all the pools and clusters can be grouped into separate availability sets, from which at least two VMs are provisioned per role which the VMs eligible for a higher Service Level Agreement (SLA).

  • NICs- Network Interface Cards (NICs) can easily attach VMs to a virtual network.

  • Network Security Groups (NSGs)- They can restrict incoming, outgoing, and intra-subnet traffic in a virtual network.

  • Virtual gateway- It allows you to extend your on-premises network to the Azure Virtual network. It is recommended to use the ExpressRoute service for the cross premises connectivity of SAP deployments in Azure, but a Site-to-Site VPN or Virtual WAN can serve as alternatives.

  • Disks- Azure VM disks can provide persistent storage for SAP workloads.

  • SAP Web Dispatcher pool- It can be used as a load balancer for SAP traffic among all the SAP application servers and the parallel Web Dispatcher setup can be implemented to achieve high availability for the Web Dispatcher component. It also uses a round-robin configuration for HTTP(S) traffic distribution among the available Web Dispatchers in the load balanced backend pool.

  • Fiori Front-end server- It uses a NetWeaver Gateway which can be loaded on the Fiori server for small deployments but for large deployments a separate server for the NetWeaver Gateway may be deployed in front of the Fiori Front-end server pool.

  • SAP Central Services cluster- This is a potential Single Point of Failure (SPOF) when deployed to a single VM and if you want to implement a high availability solution, you can readily deploy multiple Central Services instances and configure them as members of a failover cluster with a shared disk or a file share providing highly available storage accessible by all cluster nodes.

  • Database servers- It can easily use two or more Linux VMs in a cluster to achieve high availability. You can also use HANA System Replication (HSR) to replicate contents between the primary as well as secondary HANA systems and Linux clustering to detect system failures  as well as facilitate automatic failover. 

  • Application server pool- You can simply deploy the Primary Application Server with one or more Additional Application servers to achieve high availability of application servers. The SMLG transaction which is used to manage logon groups for ABAP application servers, uses the load balancing function within the message server of the Central Services to distribute workload among SAP application servers pool for SAPGUIs and RFC traffic.   












Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different groups of computers, re
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning of alert rule parameter
Read more

Design Planning (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Complex Organizational Structures SIEM can be an expensive security control, hence, it is common multiple businesses to contribute to the overall expense. Various organizational units may require a level of access to specific dashboards or sets of data. Microsoft Sentinel offers the ability to assign table-level permissions and limit the level of access to the minimum required to perform requisite job functions.  Role-based Access Control (RBAC) Requirements Microsoft Sentinel offers an extensive list of Azure built-in roles that can be used to provide granular access according to the job requirements and permitted level of access. Some of them are various Microsoft Sentinel dedicated roles: Microsoft Sentinel Contributor- Can perform all engineering-related configuration, such as creating alert rules, configuring data connectors, and additional similar tasks.  Microsoft Sentinel Reader- Can query the log data stor
Read more