Implementing HA SAP HANA on Azure VMs

By Ashwin Venugopal -

 


Overview

If you want to go for an on-premises development to establish high availability for SAP HANA, then you can either use shared storage or HANA System Replication which consists of one primary node and at least one secondary node and the changes to the data on the primary node are easily replicated to the secondary node synchronously or asynchronously.

SAP HANA System Replication setup has a dedicated virtual hostname as well as a virtual IP address, but for Azure, a load balancer is needed to use the virtual IP address. The configuration of the load balancer is shown below:

  • Front-end configuration: IP address 10.0.0.13 for hn1-db
  • Back-end configuration: Connected to primary network interfaces of all VMs that should be a part of HANA System Replication.
  • Probe Port: Port 62503
  • Load-balancing rules: 3013 TCP, 30315 TCP, 30317 TCP

Implementing & Verifying HA SAP HANA on Azure VMs

Provision Azure resources

The SUSE Linux Enterprise Server for SAP Applications contains the resource agent for SAP HANA as well as its image is included in Azure Marketplace for SAP Applications 12 that can be easily used to deploy new VMs.

Deploy with a template

One of the quickstart templates that are on GitHub can also be used to deploy all the required resources and the templates can be deployed as follows:
  1. Open the converge template which can create the load-balancing rules for an ASCS/SCS and ERS (Linux only) instance or the database template which can create the load-balancing rules for a database only on the Azure portal. If you want to go for installing a SAP NetWeaver-based system as well as ASCS/SCS instance on the same machines, then you can use the converged template.
  2. Enter the following parameters-
  • SAP System ID- Enter the SAP system ID of the SAP system you want to install. The ID is used as a prefix for the resources that are deployed.
  • Stack Type-  (This parameter is applicable only if you use the converged template). Select the SAP NetWeaver stack type. 
  • OS Type- Select one of the Linux distributions.
  • Db Type- Select HANA.
  • SAP System Size- Enter the number of SAPS that the new system is going to provide, but, if you are not sure about it, you can ask your SAP Technology Partner or System Integrator.
  • System Availability- Select HA.
  • Admin Username & Admin Password- It is a new administrative user account that can be used to sign in to the operating system. 
  • New or Existing Subnet- It finds out if a new virtual network and subnet is required to be created or an existing subnet is used, but if you already have a virtual network that's connected to your on-premises network, then select the Existing. 
  • Subnet ID- If you want to deploy the VM into an existing VNet having a subnet defined the VM should be assigned to, name the ID of that specific subnet.

  Manual deployment (via the Azure portal)

  1. Create a resource group.
  2. Create a virtual network.
  3. Create an availability set.
  4. Create a load balancer (internal).
  5. Create VM 1 and 2.
  6. Add data disks.
  7. Configure the load balancer. Firstly create a front-end IP pool.
  8. Next, create a back-end pool.
  9. Next, create a health probe.
  10. For SAP HANA 1.0, create the load-balancing rules.
  11. For SAP HANA 2.0, create the load-balancing rules for the system database.
  12. For SAP HANA 2.0, first create teh load-balancing rules for the tenant database.

Note: You should not enable TCP timestamps on Azure VMs placed behind Azure load balancer, this may cause the health probes to fail. Set parameter net.ipv4.tcp_timestamps to 0.

Create a pacemaker cluster

You can easily create a basic pacemaker cluster for this HANA server and can use the same pacemaker cluster for both SAP HANA as well as SAP NetWeaver (A)SCS.




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...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
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...
Read more