Verfügbarkeit von SAP HANA innerhalb einer Azure-Region
In diesem Artikel werden mehrere Verfügbarkeitsszenarien für SAP HANA in einer Azure-Region beschrieben. Azure bietet viele Regionen auf der ganzen Welt. Die Liste mit Azure-Regionen finden Sie unter Azure-Regionen. Für die Bereitstellung von SAP HANA auf VMs in einer Azure-Region bietet Microsoft die Bereitstellung einer einzelnen VM mit einer HANA-Instanz. Für eine höhere Verfügbarkeit können Sie zwei VMs mit zwei HANA-Instanzen bereitstellen, indem Sie entweder einen flexiblen Skalierungssatz mit FD=1, Verfügbarkeitszonen oder einen Verfügbarkeitssatz verwenden, der die HANA-Systemreplikation für die Verfügbarkeit verwendet.
Azure-Regionen, die Verfügbarkeitszonen aus mehreren Rechenzentren bestehen, die jeweils über eine eigene Stromversorgung, Kühlung und Netzwerkinfrastruktur verfügen. Der Zweck, verschiedene Zonen in einer einzelnen Azure-Region anzubieten, besteht darin, die Bereitstellung von Anwendungen über zwei oder drei verfügbare Verfügbarkeitszonen zu ermöglichen. Durch die Verteilung Ihrer Anwendungsbereitstellung über Zonen hinweg würden alle Energie- oder Netzwerkprobleme, die sich auf eine bestimmte Azure-Verfügbarkeitszone-Infrastruktur auswirken, die Funktionalität Ihrer Anwendung innerhalb der Azure-Region nicht vollständig stören. Es kann zwar eine geringere Kapazität geben, wie z. B. der potenzielle Verlust von VMs in einer Zone, aber die virtuellen Computer in den Standard Neuzonen würden ohne Unterbrechung weiter funktionieren. Um zwei HANA-Instanzen in separaten virtuellen Computern einzurichten, die sich über verschiedene Zonen erstrecken, haben Sie die Möglichkeit, virtuelle Computer mithilfe der flexiblen Skalierungsoption FD=1 oder verfügbarkeitszonen bereitzustellen.
Für eine höhere Verfügbarkeit innerhalb einer Region wird empfohlen, zwei VMs mit zwei HANA-Instanzen mithilfe eines Verfügbarkeitssatzes bereitzustellen. Ein Azure-Verfügbarkeitssatz ist eine logische Gruppierungsfunktion, mit der sichergestellt wird, dass die innerhalb des Verfügbarkeitssatzes konfigurierten VM-Ressourcen fehlerisoliert sind, wenn sie in einem Azure-Rechenzentrum bereitgestellt werden. Azure stellt sicher, dass die virtuellen Computer innerhalb einer Verfügbarkeitsgruppe auf mehrere physische Server, Compute-Racks, Speichereinheiten und Netzwerkswitches verteilt werden. Diese Konfiguration wird in einigen Azure-Dokumentationen alternativ als Platzierungen in verschiedene Update- und Fehlerdomänen bezeichnet. Diese Platzierungen erfolgen normalerweise in einem Azure-Rechenzentrum. Unter der Annahme, dass sich Energiequelle- und Netzwerkprobleme auf das Rechenzentrum auswirken, das Sie bereitstellen, sind alle Ihre Kapazität in einer Azure-Region betroffen.
Bei der Platzierung von Rechenzentren, die Azure-Verfügbarkeitszonen darstellen, wird ein Mittelweg zwischen akzeptablen Netzwerklatenzen zwischen Diensten, die in unterschiedlichen Zonen bereitgestellt werden, und einer Entfernung zwischen den Rechenzentren verfolgt. Damit soll im Idealfall erreicht werden, dass die Stromversorgung, das Netzwerk und die Infrastruktur für alle Verfügbarkeitszonen in dieser Region vor Naturkatastrophen geschützt bleiben. Doch angesichts des gewaltigen Ausmaßes, das sich bei Naturkatastrophen abgezeichnet hat, können Verfügbarkeitszonen nicht immer die von Ihnen gewünschte Verfügbarkeit innerhalb einer Region bieten. Denken Sie daran, als Hurrikan Maria am 20. September 2017 die Insel Puerto Rico durchzog. Der Hurrikan richtete fast einen kompletten Stromausfall auf der etwa 150 km langen Insel an.
Szenario mit einer einzigen VM
In einem Szenario mit einer einzigen VM erstellen Sie eine Azure-VM für die SAP HANA-Instanz. Sie verwenden Azure Storage Premium zum Hosten des Betriebssystemdatenträgers und aller Datenträger. Die SLA von Azure mit einer Betriebszeit von 99,9 % und die SLAs anderer Azure-Komponenten reichen für Sie aus, um Ihren Verfügbarkeits-SLAs für Ihre Kunden gerecht zu werden. In diesem Szenario müssen Sie keinen Azure Availability Set für VMs verwenden, die die DBMS-Ebene ausführen. In diesem Szenario kommen zwei verschiedene Features zum Einsatz:
- Automatischer Neustart der Azure-VM (auch als Azure-Dienstheilung bezeichnet)
- AUTOMATISCHer SAP HANA-Neustart
Die Funktion „Automatischer Neustart von Azure-VMs“ bzw. „Dienstreparatur“ funktioniert in Azure auf zwei Ebenen:
- Der Azure-Serverhost überprüft die Integrität einer VM, die auf dem Serverhost gehostet wird.
- Der Azure Fabric Controller überwacht die Integrität und Verfügbarkeit des Serverhosts.
Bei jeder VM, die von einem Azure-Serverhost gehostet wird, wird die Integrität der gehosteten VMs durch eine Funktion zur Integritätsprüfung überwacht. Falls eine VM in einen fehlerhaften Zustand wechseln sollte, kann ein VM-Neustart durch den Azure-Host-Agent initiiert werden, der die Integrität der VM überprüft. Der Fabric Controller überwacht die Integrität des Hosts durch Überprüfung zahlreicher verschiedener Parameter, die auf Probleme mit der Hosthardware hinweisen könnten. Zudem überprüft er den Zugriff auf den Host über das Netzwerk. Ein Hinweis auf Probleme mit dem Host kann zu folgenden Ereignissen führen:
- Ein Neustart des Hosts und der VMs, die auf dem Host ausgeführt wurden, wird ausgelöst, wenn der Host einen fehlerhaften Zustand signalisiert.
- Wenn sich der Host nach erfolgreichem Neustart nicht in einem fehlerfreien Zustand befindet, wird eine erneute Bereitstellung der VMs, die sich ursprünglich auf dem nun fehlerhaften Knoten befanden, auf einem fehlerfreien Hostserver eingeleitet. In diesem Fall wird der ursprüngliche Host als fehlerhaft gekennzeichnet. Er wird erst für weitere Bereitstellungen verwendet, wenn er gelöscht oder ersetzt wird.
- Wenn der fehlerhafte Host während des Neustartprozesses Probleme aufweist, wird ein sofortiger Neustart der VMs auf einem fehlerfreien Host ausgelöst.
Durch die von Azure bereitgestellte Host- und VM-Überwachung werden Azure-VMs, bei denen Probleme mit dem Host auftreten, automatisch auf einem fehlerfreien Azure-Host neu gestartet.
Wichtig
Die Azure-Dienstreparatur startet Linux-VMs nicht neu, wenn sich das Gastbetriebssystem in einem Kernel Panic-Status befindet. Die Standardeinstellungen der häufig verwendeten Linux-Versionen starten VMs oder Server nicht automatisch neu, wenn der Linux-Kernel im Panic-Status ist. Stattdessen sorgt die Standardeinstellung dafür, dass das Betriebssystem im Kernel Panic-Status verbleibt, um einen Kernel-Debugger für die Analyse anzufügen. Azure berücksichtigt dieses Verhalten, indem er einen virtuellen Computer nicht automatisch mit dem Gastbetriebssystem in einem solchen Zustand neu startet. Es wird davon ausgegangen, dass solche Vorkommnisse äußerst selten sind. Sie können das Standardverhalten außer Kraft setzen, um einen Neustart der VM zu ermöglichen. Aktivieren Sie zum Ändern des Standardverhaltens den Parameter „kernel.panic“ in „/etc/sysctl.conf“. Die Zeit, die Sie für diesen Parameter festlegen, wird in Sekunden angegeben. Es wird allgemein empfohlen, 20 bis 30 Sekunden zu warten, bevor der Neustart mit diesem Parameter ausgelöst wird. Weitere Informationen finden Sie unter sysctl.conf.
Das zweite Feature, auf das Sie in einem solchen Szenario angewiesen sind, betrifft den Vorgang, bei dem der auf einer neu gestarteten VM ausgeführte HANA-Dienst nach dem Neustart der VM automatisch gestartet wird. Sie können den automatischen Neustart des HANA-Diensts über die Watchdog-Dienste der verschiedenen HANA-Dienste einrichten.
Sie können dieses Szenario mit einer einzelnen VM durch Hinzufügen eines inaktiven Failoverknotens zu einer SAP HANA-Konfiguration optimieren. In der SAP HANA-Dokumentation wird dieses Setup als Host autofailover bezeichnet. Diese Konfiguration kann in einer lokalen Bereitstellungssituation sinnvoll sein, in der die Serverhardware begrenzt ist, und Sie legen einen Einzelserverknoten als Host-Autofailover-Knoten für eine Reihe von Produktionshosts bereit. Aber in Azure, bei dem die zugrunde liegende Infrastruktur von Azure einen fehlerfreien Zielserver für einen erfolgreichen VM-Neustart bereitstellt, ist es nicht sinnvoll, sap HANA-Host autofailover bereitzustellen. Aufgrund der Azure-Dienstheilung gibt es keine Referenzarchitektur, die einen Standby-Knoten für die automatische Autofailover von HANA-Hosten vorsieht.
Sonderfall von SAP HANA-Konfigurationen mit horizontaler Skalierung in Azure
Hochverfügbarkeitsarchitekturen basierend auf Standbyknoten oder HANA-Systemreplikation finden Sie in den folgenden Dokumenten. In Fällen, in denen Standbyknoten oder DIE HOHE Verfügbarkeit der HANA-Systemreplikation nicht in SAP HANA-Skalierungskonfigurationen verwendet werden, können Sie von den Dienstheilungsfunktionen von Azure-VMs und dem automatischen Neustart der SAP HANA-Instanz abhängig sein, sobald die VM wieder betriebsbereit ist.
- RedHat Enterprise Linux
- SUSE Linux Enterprise Server
Verfügbarkeitsszenarien mit zwei verschiedenen VMs
Um die Verfügbarkeit des HANA-Systems innerhalb einer bestimmten Region sicherzustellen, haben Sie die Möglichkeit, zwei virtuelle Computer in den Verfügbarkeitszonen der Region oder innerhalb der Region zu konfigurieren. Um dieses Ziel zu erreichen, können Sie die virtuellen Computer mithilfe flexibler Skalierungssätze, Verfügbarkeitszonen oder Verfügbarkeitssatz-Bereitstellungsoption konfigurieren. Die grundlegende Einrichtung in Azure würde wie folgt aussehen:
Um die verschiedenen SAP HANA-Verfügbarkeitsszenarien zu veranschaulichen, werden einige der Ebenen im Diagramm weggelassen. In der Abbildung werden nur die Ebenen dargestellt, die VMs, Hosts, Verfügbarkeitsgruppen und Azure-Regionen zeigen. Instanzen, Ressourcengruppen und Abonnements virtueller Azure-Netzwerke spielen bei den in diesem Abschnitt beschriebenen Szenarien keine Rolle.
Replizieren von Sicherungen auf einen zweiten virtuellen Computer
Eine der elementarsten Einrichtungen ist die Verwendung von Sicherungen. Dies ist insbesondere dann sinnvoll, wenn Sie Transaktionsprotokollsicherungen von einer VM für eine andere Azure-VM bereitstellen. Sie können den Azure Storage-Typ auswählen. In diesem Setup sind Sie für die Skripterstellung der Kopie geplanter Sicherungen verantwortlich, die auf der ersten VM auf der zweiten VM durchgeführt werden. Wenn Sie die Instanzen der zweiten VM verwenden müssen, müssen Sie die vollständigen inkrementellen bzw. differenziellen Sicherungen von Transaktionsprotokollen am erforderlichen Zeitpunkt wiederherstellen.
Die Architektur sieht wie folgt aus:
Diese Einrichtung eignet sich nicht gut zum Erreichen großer RPO-Zeiten (Recovery Point Objective) und Recovery Time Objective (RTO). Insbesondere bei den RTO-Zeiten müssen Einbußen in Kauf genommen werden, da die gesamte Datenbank mit den kopierten Sicherungen vollständig wiederhergestellt werden muss. Dieses Setup ist jedoch nützlich, um nach einer unbeabsichtigten Datenlöschung in den Hauptinstanzen Wiederherstellungen durchzuführen. Mit dieser Einrichtung können Sie jederzeit eine Wiederherstellung zu einem bestimmten Zeitpunkt durchführen, die Daten extrahieren und die gelöschten Daten in Ihre Hauptinstanz importieren. Daher kann es sinnvoll sein, eine solche Methode zur Sicherungskopie in Kombination mit anderen Hochverfügbarkeitsfunktionen zu verwenden.
Während des Kopiervorgangs der Sicherungen, können Sie möglicherweise eine kleineren VM als die Haupt-VM verwenden, auf der die SAP HANA-Instanz ausgeführt wird. Denken Sie daran, dass Sie eine kleinere Anzahl von VHDs an kleinere VMs anfügen können. Informationen zu den Grenzwerte für die einzelnen VM-Typen finden Sie unter Größen für virtuelle Linux-Computer in Azure.
SAP HANA-Systemreplikation ohne automatisches Failover
Bei den Szenarien, die in diesem Abschnitt beschrieben werden, wird die SAP HANA-Replikation verwendet. Die SAP-Dokumentation finden Sie unter Systemreplikation. Szenarien ohne automatisches Failover sind für Konfigurationen innerhalb einer Azure-Region nicht üblich. Bei einer Konfiguration ohne automatisches Failover, bei der jedoch ein Pacemaker-Setup vermieden wird, müssen Sie die Überwachung und das Failover manuell durchführen. Da dies auch mit Aufwand verbunden ist, verlassen sich die meisten Kunden stattdessen auf die Azure-Dienstreparatur. In einigen Grenzfällen kann eine Konfiguration dieser Art bei Ausfallszenarien Abhilfe leisten. In anderen Fällen sollte ein Kunde eventuell eine größere Effizienz realisieren.
SAP HANA-Systemreplikation ohne automatisches Failover und ohne Laden von Daten im Voraus
In diesem Szenario verwenden Sie die SAP HANA-Systemreplikation zum synchronen Verschieben von Daten, um eine RPO von 0 zu erzielen. Auf der anderen Seite benötigen Sie eine RTO, die lang genug ist, dass ein Failover oder das Laden von Daten im Voraus in den HANA-Instanzcache überflüssig ist. In diesem Fall ist es möglich, Ihre Konfiguration durch die folgenden Aktionen weiter zu optimieren:
- Führen Sie eine andere SAP HANA-Instanz auf der zweiten VM aus. Die SAP HANA-Instanz auf der zweiten VM belegt den Großteil des VM-Speichers. Bei einem Failover auf die zweite VM müssen Sie die aktive SAP HANA-Instanz herunterfahren, die die Daten vollständig in der zweiten VM geladen hat, damit die replizierten Daten in den Cache der Ziel-HANA-Instanz auf der zweiten VM geladen werden können.
- Verwenden Sie eine kleinere VM als zweite VM. Wenn ein Failover auftritt, müssen Sie vor dem manuellen Failover einen zusätzlichen Schritt durchführen. Bei diesem Schritt ändern Sie die Größe der VM in die der Quell-VM.
Das Szenario sieht folgendermaßen aus:
Hinweis
Selbst wenn Sie Daten im Replikationsziel für das HANA-System nicht im Voraus laden, benötigen Sie mindestens 64 GB Arbeitsspeicher. Sie benötigen zusätzlich zu den 64 GB auch genügend Arbeitsspeicher, um die Rowstore-Daten im Arbeitsspeicher der Zielinstanz beizubehalten.
SAP HANA-Systemreplikation ohne automatisches Failover und mit Laden von Daten im Voraus
In diesem Szenario werden Daten, die auf der zweiten VM in der HANA-Instanz repliziert wurden, im Voraus geladen. Hierdurch fallen die beiden Vorteile weg, dass Daten nicht im Voraus geladen werden müssen. In diesem Fall können Sie kein weiteres SAP HANA-System auf der zweiten VM ausführen. Zudem kann auch keine kleinere VM-Größe verwendet werden. Kunden implementieren dieses Szenario daher nur selten.
SAP HANA-Systemreplikation mit automatischem Failover
In der Standard- und am häufigsten verwendeten Verfügbarkeitskonfiguration in einer Azure-Region haben zwei Azure-VMs, die Linux mit HA-Paketen ausführen, einen Failovercluster definiert. Der HA Linux-Cluster basiert auf dem Pacemaker Framework mit SLES oder RHEL mit einem fencing deviceSLES oder RHEL als Beispiel.
Aus SAP HANA-Sicht wird der verwendete Replikationsmodus synchronisiert, und ein automatisches Failover wird konfiguriert. Auf der zweiten VM agiert die SAP HANA-Instanz als Hot Standby-Knoten. Der Standby-Knoten empfängt einen synchronen Datenstrom von Änderungsdatensätzen aus der primären SAP HANA-Instanz. Da Transaktionen von der Anwendung auf dem primären HANA-Knoten committed werden, wartet dieser mit der Bestätigung des Commits in der Anwendung, bis der sekundäre SAP HANA-Knoten den Commitdatensatz bestätigt hat. SAP HANA bietet zwei verschiedene Modi für die synchrone Replikation. Einzelheiten und eine Beschreibung zu den Unterschieden zwischen diesen beiden Modi für die synchrone Replikation finden Sie im Artikel Replication modes for SAP HANA System Replication (Replikationsmodi für die SAP HANA-Systemreplikation).
Die allgemeine Konfiguration sieht wie folgt aus:
Sie können diese Lösung auswählen, da sie es Ihnen ermöglicht, ein RPO=0 und einen niedrigen RTO zu erreichen. Konfigurieren Sie die SAP HANA-Clientkonnektivität so, dass die SAP HANA-Clients zum Herstellen einer Verbindung mit der HANA-Systemreplikationskonfiguration die virtuelle IP-Adresse verwenden. Durch eine solche Konfiguration entfällt die Notwendigkeit, die Anwendung bei einem Failover auf den sekundären Knoten erneut zu konfigurieren. Bei diesem Szenario müssen die Azure-VM-SKUs für die primären und sekundären VMs identisch sein.
Nächste Schritte
Eine ausführliche Anleitung zum Einrichten dieser Konfigurationen in Azure finden Sie in folgenden Artikeln:
- Hochverfügbarkeit von SAP HANA auf virtuellen Azure-Computern (VMs)
- Your SAP on Azure – Part 4 – High Availability for SAP HANA using System Replication (SAP in Azure – Teil 4: Hochverfügbarkeit für SAP HANA durch Systemreplikation)
Weitere Informationen zur SAP HANA-Verfügbarkeit in Azure-Regionen finden Sie im folgenden Artikel: