Verwenden eines VM-Neustarts der Azure-Infrastruktur, um eine "höhere Verfügbarkeit" eines SAP-Systems zu erzielen

Dieser Abschnitt gilt für:

Windows- und Linux

Wenn Sie sich entscheiden, keine Funktionen wie Windows Server Failover Clustering (WSFC) oder Pacemaker unter Linux zu verwenden (derzeit nur für SUSE Linux Enterprise Server [SLES] 12 und höher unterstützt), wird der Azure-VM-Neustart verwendet. Es schützt SAP-Systeme vor geplanten und ungeplanten Ausfallzeiten der Physischen Serverinfrastruktur von Azure und der insgesamt zugrunde liegenden Azure-Plattform.

Hinweis

Der Neustart einer Azure-VM schützt vorrangig VMs und keine Anwendungen. Obwohl der VM-Neustart keine hohe Verfügbarkeit für SAP-Anwendungen bietet, bietet er ein bestimmtes Maß an Infrastrukturverfügbarkeit. Sie bietet auch indirekt eine "höhere Verfügbarkeit" von SAP-Systemen. Es gibt auch keine SLA für die Zeit, die es dauert, einen virtuellen Computer nach einem geplanten oder ungeplanten Hostausfall neu zu starten, was diese Methode der hohen Verfügbarkeit für die kritischen Komponenten eines SAP-Systems ungeeignet macht. Beispiele für kritische Komponenten können eine ASCS/SCS-Instanz oder ein Datenbankmanagementsystem (DBMS) sein.

Ein weiteres wichtiges Infrastrukturelement für hohe Verfügbarkeit ist Speicher. Die Azure Storage-SLA ist beispielsweise 99,9% Verfügbarkeit. Wenn Sie alle virtuellen Computer und deren Datenträger in einem einzigen Azure-Speicherkonto bereitstellen, verursacht potenzielle Azure Storage-Nichtverfügbarkeit die Nichtverfügbarkeit aller virtuellen Computer, die in diesem Speicherkonto platziert sind, und alle SAP-Komponenten, die innerhalb der virtuellen Computer ausgeführt werden.

Anstatt alle virtuellen Computer in ein einzelnes Azure-Speicherkonto zu setzen, können Sie dedizierte Speicherkonten für jeden virtuellen Computer verwenden. Indem Sie mehrere unabhängige Azure-Speicherkonten verwenden, erhöhen Sie die allgemeine Verfügbarkeit von VM- und SAP-Anwendungen.

Azure-Managed-Disks werden automatisch in die Fault Domain der virtuellen Maschine platziert, an die sie angehängt sind. Wenn Sie zwei virtuelle Computer in einem Verfügbarkeitssatz platzieren und verwaltete Datenträger verwenden, kümmert sich die Plattform um die Verteilung der verwalteten Datenträger in verschiedene Fehlerdomänen. Wenn Sie beabsichtigen, ein Premium-Speicherkonto zu verwenden, empfehlen wir dringend die Verwendung von verwalteten Datenträgern.

Eine Beispielarchitektur eines SAP NetWeaver-Systems, das hohe Verfügbarkeit und Speicherkonten von Azure verwendet, kann wie folgt aussehen:

Eine Beispielarchitektur eines SAP NetWeaver-Systems, das hohe Verfügbarkeit von Azure-Infrastruktur und verwalteten Datenträgern verwendet, könnte wie folgt aussehen:

Für kritische SAP-Komponenten haben Sie bisher Folgendes erreicht:

• Hohe Verfügbarkeit von SAP-Anwendungsservern

  SAP-Anwendungsserverinstanzen sind redundante Komponenten. Jede SAP-Anwendungsserverinstanz wird auf einer eigenen VM bereitgestellt, die in einer anderen Azure-Fehler- und Upgradedomäne ausgeführt wird. Weitere Informationen finden Sie in den Abschnitten "Fehlerdomänen " und " Domänen aktualisieren ".

  Sie können diese Konfiguration mithilfe von Azure-Verfügbarkeitsgruppen sicherstellen. Weitere Informationen finden Sie im Abschnitt "Azure-Verfügbarkeitssätze ".

  Potenzielle geplante oder ungeplante Nichtverfügbarkeit einer Azure-Fehler- oder Upgradedomäne führt zu einer nicht verfügbaren Anzahl von virtuellen Computern mit ihren SAP-Anwendungsserverinstanzen.

  Jede SAP-Anwendungsserverinstanz wird in einem eigenen Azure-Speicherkonto platziert. Die potenzielle Nichtverfügbarkeit eines Azure-Speicherkontos führt dazu, dass nur ein virtueller Computer mit seiner SAP-Anwendungsserverinstanz nicht verfügbar ist. Beachten Sie jedoch, dass die Anzahl der Azure-Speicherkonten innerhalb eines Azure-Abonnements begrenzt ist. Um den automatischen Start einer ASCS/SCS-Instanz nach dem Neustart des virtuellen Computers sicherzustellen, legen Sie den Autostart-Parameter im STARTprofil der ASCS/SCS-Instanz fest.

  Weitere Informationen finden Sie unter Hohe Verfügbarkeit für SAP-Anwendungsserver.

  Auch wenn Sie verwaltete Datenträger verwenden, werden die Datenträger in einem Azure-Speicherkonto gespeichert und sind im Falle eines Speicherausfalls möglicherweise nicht verfügbar.

• Höhere Verfügbarkeit von SAP ASCS/SCS-Instanzen

  Verwenden Sie in diesem Szenario den Azure VM-Neustart, um den virtuellen Computer mit der installierten SAP ASCS/SCS-Instanz zu schützen. Bei geplanten oder ungeplanten Ausfallzeiten von Azure-Servern werden virtuelle Computer auf einem anderen verfügbaren Server neu gestartet. Wie bereits erwähnt, schützt azure VM-Neustart in erster Linie VMs und nicht Anwendungen, in diesem Fall die ASCS/SCS-Instanz. Durch den VM-Neustart erreichen Sie indirekt die "höhere Verfügbarkeit" der SAP ASCS/SCS-Instanz.

  Um sicherzustellen, dass die ASCS/SCS-Instanz nach dem Neustart des virtuellen Computers automatisch gestartet wird, legen Sie den Autostart-Parameter im STARTprofil der ASCS/SCS-Instanz fest. Diese Einstellung bedeutet, dass die ASCS/SCS-Instanz als einzelner Fehlerpunkt (SPOF), der in einer einzelnen VM ausgeführt wird, die Verfügbarkeit der gesamten SAP-Landschaft bestimmt.

• Höhere Verfügbarkeit des DBMS-Servers

  Wie im obigen SAP ASCS/SCS-Instanzanwendungsfall verwenden Sie den Azure VM-Neustart, um den virtuellen Computer mit installierter DBMS-Software zu schützen, und Sie erreichen "höhere Verfügbarkeit" der DBMS-Software über den VM-Neustart.

  Ein DBMS, das in einer einzelnen VM ausgeführt wird, ist auch ein SPOF, und es ist der determinative Faktor für die Verfügbarkeit der gesamten SAP-Landschaft.

Verwenden von Autostart für SAP-Instanzen

SAP bietet eine Einstellung, mit der Sie SAP-Instanzen unmittelbar nach dem Start des Betriebssystems innerhalb der VM starten können. Die Anweisungen sind im SAP Knowledge Base-Artikel 1909114 dokumentiert. SAP empfiehlt jedoch nicht mehr die Verwendung der Einstellung, da die Steuerung der Reihenfolge der Instanzneustarts nicht zulässig ist, wenn mehrere VM betroffen sind oder mehrere Instanzen pro VM ausgeführt werden.

Angenommen, in einem typischen Azure-Szenario wird eine SAP-Anwendungsserverinstanz in einem virtuellen Computer betrieben, und eine einzelne VM wird irgendwann neu gestartet, so ist Autostart nicht entscheidend. Sie können dies jedoch aktivieren, indem Sie den folgenden Parameter in das Startprofil der SAP Advanced Business Application Programming (ABAP) oder Java-Instanz einfügen.

Autostart = 1

Hinweis

Der Autostart-Parameter weist auch bestimmte Mängel auf. Insbesondere löst der Parameter den Start einer SAP ABAP- oder Java-Instanz aus, wenn der zugehörige Windows- oder Linux-Dienst der Instanz gestartet wird. Diese Sequenz tritt auf, wenn das Betriebssystem gestartet wird. Neustarts von SAP-Diensten sind jedoch auch ein häufiges Vorkommen für SAP Software Lifecycle Management-Funktionen wie Software Update Manager (SUM) oder andere Updates oder Upgrades. Diese Funktionen erwarten nicht, dass eine Instanz automatisch neu gestartet wird. Daher sollte der Parameter "Autostart" deaktiviert werden, bevor Sie solche Aufgaben ausführen. Der Autostart-Parameter sollte auch nicht für SAP-Instanzen verwendet werden, die gruppiert sind, z. B. ASCS/SCS/CI.

Weitere Informationen zum Autostart für SAP-Instanzen finden Sie in den folgenden Artikeln:

• Starten oder Beenden von SAP zusammen mit Ihrem Unix Server Start/Stop
• Starten und Beenden von SAP NetWeaver Management Agents

Nächste Schritte

Informationen zur vollständigen, anwendungsfähigen SAP NetWeaver-Hochverfügbarkeit finden Sie unter SAP-Anwendung mit hoher Verfügbarkeit auf Azure IaaS.