Rediģēt

Kopīgot, izmantojot

Utilize Azure infrastructure VM restart to achieve “higher availability” of an SAP system

  • Raksts

This section applies to:

Windows logo. Windows and Linux logo. Linux

If you decide not to use functionalities such as Windows Server Failover Clustering (WSFC) or Pacemaker on Linux (currently supported only for SUSE Linux Enterprise Server [SLES] 12 and later), Azure VM restart is utilized. It protects SAP systems against planned and unplanned downtime of the Azure physical server infrastructure and overall underlying Azure platform.

Note

Azure VM restart primarily protects VMs and not applications. Although VM restart doesn't offer high availability for SAP applications, it does offer a certain level of infrastructure availability. It also indirectly offers “higher availability” of SAP systems. There is also no SLA for the time it takes to restart a VM after a planned or unplanned host outage, which makes this method of high availability unsuitable for the critical components of an SAP system. Examples of critical components might be an ASCS/SCS instance or a database management system (DBMS).

Another important infrastructure element for high availability is storage. For example, the Azure Storage SLA is 99.9% availability. If you deploy all VMs and their disks in a single Azure storage account, potential Azure Storage unavailability will cause the unavailability of all VMs that are placed in that storage account and all SAP components that are running inside of the VMs.

Instead of putting all VMs into a single Azure storage account, you can use dedicated storage accounts for each VM. By using multiple independent Azure storage accounts, you increase overall VM and SAP application availability.

Azure managed disks are automatically placed in the fault domain of the virtual machine they are attached to. If you place two virtual machines in an availability set and use managed disks, the platform takes care of distributing the managed disks into different fault domains as well. If you plan to use a premium storage account, we highly recommend using managed disks.

A sample architecture of an SAP NetWeaver system that uses Azure infrastructure high availability and storage accounts might look like this:

Diagram that shows the architecture of an SAP NetWeaver system that uses Azure infrastructure high availability and storage accounts.

A sample architecture of an SAP NetWeaver system that uses Azure infrastructure high availability and managed disks might look like this:

Utilize Azure infrastructure high availability to achieve SAP application “higher availability"

For critical SAP components, you have achieved the following so far:

  • High availability of SAP application servers

    SAP application server instances are redundant components. Each SAP application server instance is deployed on its own VM, which is running in a different Azure fault and upgrade domain. For more information, see the Fault domains and Update domains sections.

    You can ensure this configuration by using Azure availability sets. For more information, see the Azure availability sets section.

    Potential planned or unplanned unavailability of an Azure fault or upgrade domain will cause unavailability of a restricted number of VMs with their SAP application server instances.

    Each SAP application server instance is placed in its own Azure storage account. The potential unavailability of one Azure storage account will cause the unavailability of only one VM with its SAP application server instance. However, be aware that there is a limit on the number of Azure storage accounts within one Azure subscription. To ensure automatic start of an ASCS/SCS instance after the VM reboot, set the Autostart parameter in the ASCS/SCS instance start profile.

    For more information, see High availability for SAP application servers.

    Even if you use managed disks, the disks are stored in an Azure storage account and might be unavailable in the event of a storage outage.

  • Higher availability of SAP ASCS/SCS instances

    In this scenario, utilize Azure VM restart to protect the VM with the installed SAP ASCS/SCS instance. In the case of planned or unplanned downtime of Azure servers, VMs are restarted on another available server. As mentioned earlier, Azure VM restart primarily protects VMs and not applications, in this case the ASCS/SCS instance. Through the VM restart, you indirectly reach “higher availability” of the SAP ASCS/SCS instance.

    To ensure an automatic start of ASCS/SCS instance after the VM reboot, set the Autostart parameter in the ASCS/SCS instance start profile. This setting means that the ASCS/SCS instance as a single point of failure (SPOF) running in a single VM will determine the availability of the whole SAP landscape.

  • Higher availability of the DBMS server

    As in the preceding SAP ASCS/SCS instance use case, you utilize Azure VM restart to protect the VM with installed DBMS software, and you achieve “higher availability” of DBMS software through VM restart.

    A DBMS that's running in a single VM is also a SPOF, and it is the determinative factor for the availability of the whole SAP landscape.

Using Autostart for SAP instances

SAP offers a setting that lets you start SAP instances immediately after the start of the OS within the VM. The instructions are documented in SAP Knowledge Base Article 1909114. However, SAP no longer recommends the use of the setting, because it does not allow control of the order of instance restarts if more than one VM is affected or if multiple instances are running per VM.

Assuming a typical Azure scenario of one SAP application server instance in a VM and a single VM eventually getting restarted, Autostart is not critical. But you can enable it by adding the following parameter into the start profile of the SAP Advanced Business Application Programming (ABAP) or Java instance:

Autostart = 1

Note

The Autostart parameter has certain shortcomings as well. Specifically, the parameter triggers the start of an SAP ABAP or Java instance when the related Windows or Linux service of the instance is started. That sequence occurs when the operating system boots up. However, restarts of SAP services are also a common occurrence for SAP Software Lifecycle Management functionality such as Software Update Manger (SUM) or other updates or upgrades. These functionalities are not expecting an instance to be restarted automatically. Therefore, the Autostart parameter should be disabled before you run such tasks. The Autostart parameter also should not be used for SAP instances that are clustered, such as ASCS/SCS/CI.

For more information about Autostart for SAP instances, see the following articles:

Next steps

For information about full SAP NetWeaver application-aware high availability, see SAP application high availability on Azure IaaS.