Clustern einer SAP ASCS/SCS-Instanz auf einem Windows Failovercluster mithilfe einer freigegebenen Festplatte in Azure

Windows

Windows Server Failover Clustering (WSFC) ist die Grundlage für eine Hochverfügbarkeits-SAP-ASCS/SCS-Installation und Datenbankmanagementsysteme (DBMS) unter Windows.

Bei einem Failovercluster handelt es sich um eine Gruppe von 1+n unabhängigen Servern, die zur Steigerung der Verfügbarkeit von Anwendungen und Diensten zusammenarbeiten. Wenn ein Knotenfehler auftritt, berechnet das WSFC die Anzahl von Fehlern, die auftreten können, und erhält weiterhin einen fehlerfreien Cluster für die Bereitstellung der Anwendungen und Dienste aufrecht. Sie können zwischen verschiedenen Quorummodi wählen, um das Failover-Clustering zu erreichen.

Voraussetzungen

Bevor Sie mit den Aufgaben in diesem Artikel beginnen, lesen Sie den Artikel Hochverfügbarkeitsarchitektur und Szenarien für SAP NetWeaver.

Windows Server Failover-Clustering in Azure

WSFC mit Azure virtuellen Computern (VMs) erfordert zusätzliche Konfigurationsschritte. Wenn Sie einen Cluster erstellen, müssen Sie mehrere IP-Adressen und virtuelle Hostnamen für die SAP ASCS/SCS-Instanz festlegen.

Namensauflösung in Azure und dem virtuellen Clusterhostnamen

Die Azure Cloudplattform bietet nicht die Möglichkeit, virtuelle IP-Adressen wie unverankerte IP-Adressen zu konfigurieren. Sie benötigen eine alternative Lösung für die Einrichtung einer virtuellen IP-Adresse, um die Clusterressource in der Cloud zu erreichen.

Der Azure Load Balancer-Dienst stellt einen internen Lastenausgleich für Azure bereit. Mit dem internen Load Balancer erreichen Clients den Cluster über die virtuelle IP-Adresse des Clusters.

Stellen Sie den internen Lastverteiler in der Ressourcengruppe bereit, die die Clusterknoten enthält. Konfigurieren Sie dann alle erforderlichen Portweiterleitungsregeln mithilfe der Testports des internen Lastenausgleichs. Clients können über den virtuellen Hostnamen eine Verbindung herstellen. Der DNS-Server löst die IP-Adresse des Clusters auf, und der interne Load Balancer übernimmt das Port-Forwarding zum aktiven Knoten des Clusters.

SAP ASCS/SCS HA mit freigegebenen Clusterdatenträgern

In Windows enthält eine SAP ASCS/SCS-Instanz SAP-Zentraldienste, den SAP-Nachrichtendienst, Enqueue-Server-Prozesse und SAP-Globalhostdateien. Globale SAP-Hostdateien speichern zentrale Dateien für das gesamte SAP-System.

Eine SAP ASCS/SCS-Instanz verfügt über die folgenden Komponenten:

• SAP Zentrale Dienste:

  • Zwei Prozesse (für einen Nachrichtenserver und Server zum Einreihen in die Warteschlange) sowie ein virtueller ASCS/SCS-Hostname für den Zugriff auf die beiden Prozesse
  • Dateistruktur: S:\usr\sap\<SID>\ASCS/SCS<Instanznummer>

• Globale SAP-Host-Dateien

  • Dateistruktur: S:\usr\sap\<SID>\SYS...

  • Die sapmnt-Dateifreigabe ermöglicht den Zugriff auf diese globalen Dateien unter S:\usr\sap<SID>\SYS... mittels des folgenden UNC-Pfads:

    \\<Name des virtuellen ASCS/SCS-Hosts>\sapmnt\<SID>\SYS...

Bei der Einstellung für die Hochverfügbarkeit erfolgt ein Clustering von SAP ASCS/SCS-Instanzen. Sie verwenden freigegebene Clusterdatenträger (in diesem Artikel Laufwerk S), um die SAP ASCS/SCS-Dateien und die globalen Hostdateien von SAP zu platzieren.

Mit einer Enqueue Replication Server-Architektur (ERS1):

• Es wird derselbe virtuelle ASCS/SCS-Hostname für den Zugriff auf den SAP Message Server und die Enqueue-Server-Prozesse sowie auf die globalen Dateien des SAP-Systems über die sapmnt-Dateifreigabe verwendet.
• Es wird derselbe freigegebene Clusterdatenträger (Laufwerk S:) gemeinsam genutzt.

Mit der Enqueue Replication Server 2 (ERS2) Architektur:

• Es wird derselbe virtuelle ASCS/SCS-Hostname für den Zugriff auf Prozesse des SAP Message Servers und auf Dateien des globalen SAP-Hosts über die sapmnt-Dateifreigabe verwendet.
• Es wird derselbe freigegebene Clusterdatenträger (Laufwerk S:) gemeinsam genutzt.
• Es gibt einen separaten Namen für den virtuellen ERS-Host für den Zugriff auf den Prozess des Servers zum Einreihen in die Warteschlange.

Freigegebene Datenträger und Enqueue Replication Server

Freigegebene Datenträger werden mit einer ERS1-Architektur unterstützt, wobei die ERS1-Instanz:

• Ist nicht gruppiert.
• Verwendet einen localhost-Namen.
• Wird auf lokalen Datenträgern auf den einzelnen Clusterknoten bereitgestellt.

Geteilte Festplatten werden mit einer ERS2-Architektur unterstützt, wobei die ERS2-Instanz:

• Ist gruppiert.
• Verwendet einen dedizierten virtuellen oder Netzwerk-Hostnamen.
• Benötigt die IP-Adresse des virtuellen ERS-Hostnamens, die auf einem internen Azure-Load Balancer konfiguriert werden muss, zusätzlich zur (A)SCS-IP-Adresse.
• auf lokalen Datenträgern auf den einzelnen Clusterknoten bereitgestellt wird, sodass kein freigegebener Datenträger erforderlich ist.

Weitere Informationen zu ERS1 und ERS2 finden Sie unter Enqueue-Replicationsserver in einem Microsoft Failover Cluster und Neuer Enqueue-Replikator in Failoverclusterumgebungen auf der SAP-Website.

Optionen für freigegebene Datenträger in Azure für SAP-Workloads

Es gibt zwei Optionen für freigegebene Datenträger in einem Windows Failovercluster in Azure:

• Verwenden Sie Azure Shared Disks, um Azure Managed Disks gleichzeitig an mehrere VMs anzuschließen.
• Mithilfe der SIOS DataKeeper Cluster Edition können Sie einen gespiegelten Speicher erstellen, der eine Clusterspeicherlösung simuliert.

Wenn Sie eine Technologie für freigegebene Datenträger auswählen, beachten Sie die folgenden Überlegungen zu Azure freigegebenen Datenträgern für SAP-Workloads:

• Die Verwendung von gemeinsam genutzten Azure-Datenträgern mit Azure Premium SSD wird für die SAP-Bereitstellung in Verfügbarkeitssätzen und Verfügbarkeitszonen unterstützt.
• Ultra Disks und Azure Standard-SSDs werden nicht als Azure freigegebene Datenträger für SAP-Workloads unterstützt.
• Stellen Sie sicher, dass Sie Azure Premium-SSDs mit einer mindesten Datenträgergröße bereitstellen, wie in Premium SSD-Bereichen angegeben, damit sie gleichzeitig an die erforderliche Anzahl von virtuellen Computern anfügen können. Normalerweise benötigen Sie zwei VMs für SAP ASCS Windows Failovercluster.

Beachten Sie dabei die folgenden Aspekte bezüglich SIOS:

• Die SIOS-Lösung bietet synchrone Datenreplikation zwischen zwei Datenträgern in Echtzeit.
• Mit der SIOS-Lösung arbeiten Sie mit zwei verwalteten Datenträgern. Wenn Sie entweder Verfügbarkeitssätze oder Verfügbarkeitszonen verwenden, befinden sich die verwalteten Datenträger auf verschiedenen Speicherclustern.
• Die Bereitstellung in Verfügbarkeitszonen wird unterstützt.
• Die SIOS-Lösung erfordert das Installieren und Ausführen von Drittanbietersoftware, die Sie separat erwerben müssen.

Azure freigegebene Datenträger

Sie können SAP ASCS/SCS HA mit Azure freigegebenen Datenträgern implementieren.

Voraussetzungen und Einschränkungen

Sie können Azure Premium SSD-Datenträger als Azure gemeinsam genutzte Datenträger für die SAP ASCS/SCS-Instanz verwenden. Beachten Sie die folgenden Einschränkungen:

• Ultra Disks und Standard-SSDs werden nicht als Azure freigegebene Datenträger für SAP-Workloads unterstützt.
• Azure Shared Disks mit Premium-SSDs werden für die Bereitstellung von SAP in Verfügbarkeitsgruppen und Verfügbarkeitszonen unterstützt.
• Azure freigegebene Datenträger mit Premium-SSDs bieten zwei Speicheroptionen:
  • Lokal redundanter Speicher (LRS) für Premium-SSD gemeinsam genutzte Datenträger (skuName-Wert von Premium_LRS) wird bei der Bereitstellung in Verfügbarkeitsgruppen unterstützt.
  • Zonenredundanter Speicher (ZRS) für freigegebene Premium SSDs (skuName-Wert von Premium_ZRS) wird bei der Bereitstellung in Verfügbarkeitszonen unterstützt.
• Der Wert der freigegebenen Azure-Disk maxShares bestimmt, wie viele Clusterknoten die freigegebene Disk nutzen können. Bei einer SAP ASCS/SCS-Instanz konfigurieren Sie in der Regel zwei Knoten in WSFC. Anschließend legen Sie den Wert für maxShares auf 2 fest.
• Für freigegebene Azure-Datenträger ist keine Azure Proximity Placement Group (PPG) erforderlich. Für die Bereitstellung von SAP mit PPGs sollten Sie jedoch diese Richtlinien befolgen:
  • Wenn Sie PPGs für ein SAP-System verwenden, die in einer Region bereitgestellt werden, müssen alle VMs, die sich einen Datenträger teilen, Teil derselben PPG sein.
  • Wenn Sie PPGs für ein SAP-System verwenden, die über Zonen hinweg bereitgestellt werden, wie in Näherungsplatzierungsgruppen mit zonalen Bereitstellungen beschrieben, können Sie Premium_ZRS-Speicher für VMs anfügen, die sich einen Datenträger teilen.

Weitere Informationen finden Sie im Abschnitt Einschränkungen in der Dokumentation zu freigegebenen Azure-Datenträgern.

Wichtige Überlegungen zu Premium-SSD-Freigabedatenträgern

Beachten Sie die folgenden wichtigen Punkte zu den freigegebenen Premium SSD-Datenträgern von Azure:

• LRS für freigegebene SSD Premium-Datenträger

  • Die SAP-Bereitstellung mit LRS for Premium SSD shared disks arbeitet mit einem einzigen Azure gemeinsam genutzten Datenträger auf einem Speichercluster. Wenn es ein Problem mit dem Speichercluster gibt, auf dem der freigegebene Azure-Datenträger bereitgestellt wird, wirkt sich dies auf Ihre SAP ASCS/SCS-Instanz aus.

• ZRS für freigegebene SSD Premium-Datenträger:

  • Die Wartezeit beim Schreiben für ZRS ist aufgrund der zonenübergreifenden Kopie von Daten höher als die von LRS.
  • Der Abstand zwischen Verfügbarkeitszonen in verschiedenen Regionen variiert, ebenso wie ZRS-Datenträgerlatenz über Verfügbarkeitszonen. Vergleichen Sie Ihre Datenträger, um die Latenz der ZRS-Datenträger in Ihrer Region zu ermitteln.
  • ZRS für freigegebene SSD Premium-Datenträger repliziert Daten synchron über drei Verfügbarkeitszonen in der Region. Im Falle eines Problems in einem der Speichercluster wird Ihre SAP ASCS/SCS-Instanz weiterhin ausgeführt, da das Speicherfailover für die Anwendungsschicht transparent ist.
  • Weitere Informationen hierzu erfahren Sie im Abschnitt Einschränkungen der Dokumentation für ZRS für verwaltete Datenträger.

Weitere wichtige Überlegungen zur Planung Der SAP-Bereitstellung finden Sie unter Plan und Implementieren einer SAP-Bereitstellung auf Azure und Azure Storage Typen für SAP-Workloads.

Unterstützte Betriebssystemversionen

Windows Server 2016, 2019 und höher werden unterstützt. Verwenden Sie die neuesten Bilder des Rechenzentrums.

Aus diesen Gründen wird dringend empfohlen, mindestens Windows Server 2019 Datacenter zu verwenden:

• WSFC in Windows Server 2019 ist mit Azure kompatibel.
• Windows Server 2019 Datacenter umfasst die Integration und Unterstützung der Azure-Hostwartung sowie eine verbesserte Benutzererfahrung durch die Überwachung von geplanten Azure-Ereignissen.
• Sie können verteilte Netzwerknamen verwenden. (Das ist die Standardoption.) Eine dedizierte IP-Adresse für den Namen des Clusternetzwerks ist nicht erforderlich. Außerdem müssen Sie keine IP-Adresse auf einem internen Azure-Load-Balancer konfigurieren.

Freigegebene Datenträger in Azure mit SIOS DataKeeper

Eine weitere Option für freigegebene Datenträger ist die Verwendung der SIOS DataKeeper Cluster Edition, um einen gespiegelten Speicher zu erstellen, der freigegebenen Clusterspeicher simuliert. Die SIOS-Lösung bietet eine synchrone Datenreplikation in Echtzeit.

So erstellen Sie eine freigegebene Datenträgerressource für einen Cluster

1. Fügen Sie einen zusätzlichen Datenträger an jeden virtuellen Computer in einer Windows Clusterkonfiguration an.
2. Führen Sie SIOS DataKeeper Cluster Edition auf beiden virtuellen Computerknoten aus.
3. Konfigurieren Sie SIOS DataKeeper Cluster Edition so, dass synchron der Inhalt des zusätzlich angefügten Datenträgervolumes vom virtuellen Quellcomputer im zusätzlich angefügten Datenträgervolume des virtuellen Zielcomputers gespiegelt wird. SIOS DataKeeper abstrahiert die lokalen Quell- und Zielvolumes und präsentiert diese beim WSFC als einen freigegebenen Datenträger.

Optionale Konfigurationen

Die folgenden Diagramme zeigen mehrere SAP-Instanzen auf Azure VMs, die Windows Server Failoverclustering ausführen, um die Gesamtanzahl der virtuellen Computer zu reduzieren.

Diese Konfiguration kann entweder lokale SAP-Anwendungsserver auf einem SAP ASCS/SCS-Cluster oder eine SAP ASCS/SCS-Clusterrolle auf Microsoft SQL Server AlwaysOn-Knoten sein.

Sowohl SAP ASCS/SCS als auch die Microsoft SQL Server-Datenbank sind einzelne Fehlerpunkte (SPOFs). WSFC schützt diese SPOFs in einer Windows Umgebung.

Obwohl der Ressourcenverbrauch des SAP ASCS/SCS relativ klein ist, empfehlen wir eine Reduzierung der Speicherkonfiguration für SQL Server oder den SAP-Anwendungsserver um 2 GB.

Dieses Diagramm veranschaulicht SAP-Anwendungsserver auf WSFC-Knoten mit der Verwendung von SIOS DataKeeper:

Da die SAP-Anwendungsserver lokal installiert sind, ist es nicht erforderlich, eine Synchronisierung einzurichten.

Dieses Diagramm veranschaulicht SAP ASCS/SCS auf SQL Server Always On-Knoten mit der Verwendung von SIOS DataKeeper:

Informationen zu anderen Konfigurationen finden Sie in den folgenden Ressourcen:

• Optionalkonfiguration für SAP-Anwendungsserver auf WSFC-Knoten mit Windows Scale-Out Dateiserver

• Optionale Konfiguration für SAP-Anwendungsserver auf WSFC-Knoten mithilfe des Servernachrichtenblocks in Azure NetApp Files

• Optionalkonfiguration für SAP ASCS/SCS auf SQL Server AlwaysOn-Knoten unter Verwendung von Windows Scale-Out Dateiserver

• Optionalkonfiguration für SAP ASCS/SCS auf SQL Server AlwaysOn-Knoten mithilfe des Servernachrichtenblocks in Azure NetApp Files

Nächste Schritte

• Bereiten Sie die Azure-Infrastruktur für SAP-HA vor, indem Sie einen Windows-Failover-Cluster und eine gemeinsame Festplatte für eine SAP-ASCS/SCS-Instanz verwenden

• Installieren Sie SAP NetWeaver HA auf einem Windows Failovercluster und gemeinsam genutzten Datenträger für eine SAP ASCS/SCS-Instanz