Implementing Azure VM based SAP Solutions

By Ashwin Venugopal -

 



Azure VM Deployment Methodologies

VM images & disks

It is one of the main considerations in which installing the operating system and the associated SAP workloads, which allows you to choose from three options.

Azure Marketplace Images

In this approach you can deploy the VMs based on Microsoft or third-party including the VM images from Azure Marketplace. After that, the same method and tools can be used to install the SAP software and/or DBMS inside your VM which can be performed manually or in an automated manner, with the help of configuration management tools, like PowerShell DSC, Custom Script, Ansible, Puppet, or Chef.

Custom Images

In this approach you can deploy the VMs based on customer-specific images, if Azure marketplace images doesn't fit your needs. If the SAP content is already installed in your on-premises VM (mainly for 2-tier systems), then you can easily adapt its settings after the deployment of Azure VM through the instance rename procedure supported by the SAP Software Provisioning Manager.

It is notable that in this system you can also have an option of installing as well as configuring SAP workloads manually or in an automated manner,  with the help of same configuration management tools.

Custom Disks

In this approach you can upload a VM from on-premises to Azure with a non-generalized disk, which helps you to easily move a specific SAP system, from on-premises to Azure and the uploaded VHDs should contain the OS, the SAP binaries as well as DBMS binaries plus the data and log files of the DBMS. Unlikely to the second approach, you can also keep the same hostname, SAP SID, and SAP user accounts. 

Deployment Methodologies

Deployment via the Azure portal

Azure portal provides intuitive interface to perform the most common administrative task and its main advantage is simplicity, however its usage precludes to large extent the use of automation.

Deployment via Microsoft Azure PowerShell cmdlets

Powershell is a powerful as well as extensible framework which is largely adopted by the customers to deploy a large number of systems in Azure and after the release of PowerShell 6.0, it also became possible to run it on Linux and MacOS.

Deployment via Microsoft Azure CLI commands

It is much easy to use Azure CLI instead of PowerShell, for the administrators with Linux background as can closely integrate with Bash shell. Deployment of the Azure Monitoring Extension for SAP is available via PowerShell or CLI which is a mandatory step while deploying or administering a SAP NetWeaver system in Azure.

Deployment via Azure Resource Management templates

You can automatically deploy SAP solutions by creating your own Azure Resource Manager templates or leveraging a large collection of azure-quickstart-templates in a GitHub repository at https://github.com/Azure/azure-quickstart-templates.

Deployment via Terraform

Hashicorp Terraform is an open-source tool for provisioning and managing cloud infrastructure. It is a popular tool choice for multi-cloud scenarios, where similar infrastructure is deployed to Azure and additional cloud providers or on-premises datacenters. It also allows the developers to use the same tools as well as configuration files to manage infrastructure on multiple cloud providers.

The supported scenarios include the full deployment of:
  • HANA single-node instance
  • HANA high-availability pair, having:

  1. single-node HANA instance, two-tier HSR (primary/secondary)
  2. Pacemaker high-availability cluster, fully configured with SBD and SAP/Azure resource agents    




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