Erkunden der Hochverfügbarkeit von SQL Server für SAP in Azure

  • 8 Minuten

Bei Verwendung von SQL Server in Azure-VM-basierten Bereitstellungen für SAP haben Sie mehrere Möglichkeiten, eine hochverfügbare DBMS-Ebene bereitzustellen. Azure bietet unterschiedliche SLAs für Uptime einer einzelnen VM und eines VM-Paars, das in einer Azure-Verfügbarkeitsgruppe bereitgestellt ist. Es wird davon ausgegangen, dass Sie die SLA für die Betriebszeit Ihrer Produktionsbereitstellungen anstreben, was die Bereitstellung in Azure-Verfügbarkeitsgruppen erfordert. In diesem Fall müssen Sie mindestens zwei VMs in einer solchen Verfügbarkeitsgruppe bereitstellen. Eine VM führt die aktive SQL Server-Instanz aus. Die andere VM führt die passive Instanz aus.

SQL Server-Clustering mit dem Windows-Dateiserver mit horizontaler Skalierung

Mit Windows Server 2016 führte Microsoft direkte Speicherplätze ein. Basierend auf der Bereitstellung direkter Speicherplätze wird das SQL Server-FCI-Clustering unterstützt. Die Lösung benötigt eine Azure Load Balancer-Instanz für den Umgang mit der virtuellen IP-Adresse der Clusterressourcen. Die SQL Server-Datenbankdateien werden in Speicherplätzen gespeichert. Daher ist es unumgänglich, dass Sie Windows-Speicherplätze auf Grundlage von Azure Storage Premium bereitstellen müssen. Da die Unterstützung für diese Lösung neu ist, gibt es keine bekannten SAP-Kunden, die diese Lösung in SAP-Produktionsszenarios verwenden.

SQL Server-Protokollversand

Eine weitere Methode für Hochverfügbarkeit ist der SQL Server-Protokollversand. Wenn die an der Hochverfügbarkeitskonfiguration teilnehmenden VMs über eine funktionierende Namensauflösung verfügen, gibt es kein Problem, und die Einrichtung in Azure unterscheidet sich nicht von jeder anderen lokalen Einrichtung.

Die SQL Server-Protokollversandfunktion wird nicht häufig in Azure verwendet, um Hochverfügbarkeit innerhalb derselben Azure-Region zu erreichen. Es gibt jedoch einige Azure-Szenarios, in denen SAP-Kunden den Protokollversand erfolgreich anwenden:

  • Notfallwiederherstellungsszenarien zwischen verschiedenen Azure-Regionen
  • Konfiguration der Notfallwiederherstellung zwischen dem lokalen Standort und Azure
  • Migration vom der lokalen Umgebung zu Azure In diesen Fällen wird der Protokollversand verwendet, um die neue DBMS-Bereitstellung in Azure mit dem vorhandenen lokalen Produktionssystem zu synchronisieren. Zum Zeitpunkt der Migration wird die Produktion heruntergefahren, und die neuesten Transaktionsprotokollsicherungen werden an die Azure-DBMS-Bereitstellung übertragen. Anschließend wird die Azure-DBMS-Bereitstellung als Produktionsinstanz konfiguriert.

Datenbankspiegelung

Die von SAP unterstützte Datenbankspiegelung (gemäß SAP-Hinweis 965908) beruht auf der Angabe eines Failoverpartners in der SAP-Verbindungszeichenfolge. Bei standortübergreifenden Szenarien gehen wir davon aus, dass sich die beiden VMs in derselben Domäne befinden und beide SQL Server-Instanzen im Sicherheitskontext desselben Domänenbenutzerkontos ausgeführt werden. Daher unterscheidet sich die Einrichtung der Datenbankspiegelung in Azure nicht von einer typischen lokalen Einrichtung/Konfiguration.

Bei reinen Cloudbereitstellungen besteht der einfachste Ansatz darin, DBMS-VMs (und idealerweise dedizierte SAP-VMs) in derselben Domäne zu einrichten.

Wenn die domänenbasierte Konfiguration keine Option ist, können Zertifikate für die Endpunkte für die Datenbankspiegelung verwendet werden, wie unter Verwendung von Zertifikaten für einen Datenbankspiegelungsendpunkt (Transact-SQL) beschrieben.

SQL Server Always On

Always On wird für SAP On-Premises unterstützt (siehe SAP-Hinweis #1772688) und in Azure. Es gibt einige besondere Überlegungen zur Bereitstellung des SQL Server-Verfügbarkeitsgruppenlisteners, der in Azure als Front-End eines Lastenausgleichs konfiguriert werden muss.

Es folgen weitere Überlegungen zur Verwendung eines Verfügbarkeitsgruppenlisteners:

  • Die Verwendung eines Verfügbarkeitsgruppenlisteners ist nur mit Windows Server 2012 oder höheren Version als Gastbetriebssystem der VM möglich. Für Windows Server 2012 müssen Sie sicherstellen, dass Sie den verfügbaren Patch anwenden: KB 2854082: Update aktiviert SQL Server-Verfügbarkeitsgruppenlistener unter Windows Server 2008 R2 und Windows Server 2012-basierten virtuellen Microsoft Azure-Computern.
  • Für Windows Server 2008 R2 muss Always On auf die gleiche Weise wie Datenbankspiegelung verwendet werden, indem ein Failoverpartner in der Verbindungszeichenfolge angegeben wird (durch den SAP default.pfl-Parameter dbs/mss/server - siehe SAP-Hinweis #965908).
  • Wenn Sie einen Verfügbarkeitsgruppenlistener verwenden, müssen die Datenbank-VMs mit einem dedizierten Lastenausgleich verbunden sein. Um das Szenario zu vermeiden, in dem Azure neue IP-Adressen zuweist, wenn beide VMs zufällig heruntergefahren werden, empfiehlt es sich, den Netzwerkschnittstellen dieser VMs in der Always On-Konfiguration statische IP-Adressen zuzuweisen.
  • Beim Erstellen der WSFC-Clusterkonfiguration sind besondere Schritte erforderlich, bei denen dem Cluster eine spezielle IP-Adresse zugewiesen werden muss. Azure weist dem Clusternamen die gleiche IP-Adresse zu wie dem Knoten, auf dem der Cluster erstellt wird. Das bedeutet, dass ein manueller Schritt ausgeführt werden muss, um dem Cluster eine andere IP-Adresse zuzuweisen.
  • Der Verfügbarkeitsgruppenlistener wird in Azure mit TCP/IP-Endpunkten erstellt, die den VMs zugewiesen werden, auf denen die primären und sekundären Replikate der Verfügbarkeitsgruppe ausgeführt werden.

Eine ausführliche Dokumentation zum Bereitstellen von Always On mit SQL Server auf Azure-VMs finden Sie unter:

Hinweis

Wenn Sie die Azure Load Balancer-Instanz für die virtuelle IP-Adresse vom Verfügbarkeitsgruppenlistener konfigurieren, stellen Sie sicher, dass DirectServerReturn konfiguriert ist. Wenn Sie die DirectServerReturn-Option konfigurieren, wird die Roundtriplatenz im Netzwerk zwischen SAP-Anwendungsebene und DBMS-Ebene reduziert.

SQL Server Always On ist e in Azure für Windows-basierte SAP-Bereitstellungen die am häufigsten verwendete Hochverfügbarkeits- und Notfallwiederherstellungsmethode. Die meisten Kunden setzen auf Always On für Hochverfügbarkeit innerhalb einer einzelnen Azure-Region. Wenn die Bereitstellung auf nur zwei Knoten beschränkt ist, haben Sie zwei Verbindungsmöglichkeiten:

  • Verwenden des Verfügbarkeitsgruppenlisteners. Wenn Sie den Verfügbarkeitsgruppenlistener verwenden, müssen Sie eine Azure Load Balancer-Instanz bereitstellen. Dies ist in der Regel die Standardbereitstellungsmethode. SAP-Anwendungen müssen so konfiguriert werden, dass sie eine Verbindung mit dem Verfügbarkeitsgruppenlistener und nicht mit einem einzelnen Knoten herstellen.
  • Mithilfe der Verbindungsparameter der SQL Server-Datenbankspiegelung müssen Sie die Konnektivität der SAP-Anwendungen konfigurieren, indem Sie beide Knotennamen angeben. Genaue Details dieser Spiegelungskonfiguration sind in SAP Note #965908 dokumentiert. Mit dieser Option entfällt die Notwendigkeit eines Verfügbarkeitsgruppenlisteners und einer Azure Load Balancer-Instanz. Dadurch ist die Netzwerklatenz zwischen der SAP-Anwendungsschicht und der DBMS-Schicht geringer. Denn der auf der SQL Server-Instanz eingehende Datenverkehr wird über keine Azure Load Balancer-Instanz weitergeleitet. Beachten Sie jedoch, dass diese Option nur funktioniert, wenn Sie Ihre Verfügbarkeitsgruppe auf zwei Instanzen beschränken.

Etliche Kunden nutzen zudem die SQL Server Always On-Funktionalität für die Notfallwiederherstellung zwischen Azure-Regionen. Ein Teil der Kundschaft nutzt auch die Möglichkeit, Sicherungen von einem sekundären Replikat durchzuführen.