Ausführen von SAP HANA für Linux-VMs in einer zentral hochskalierten Architektur in Azure

Azure
Virtual Machines
Virtuelle Linux-Computer

Anhand dieser Referenzarchitektur werden einige bewährte Methoden für die Ausführung von SAP HANA in einer Hochverfügbarkeits- und zentral hochskalierten Umgebung veranschaulicht, die die Notfallwiederherstellung in Azure unterstützt. Diese Implementierung konzentriert sich nur auf die Datenbankebene.

Aufbau

Diese Referenzarchitektur beschreibt ein gängiges Produktionssystem. Sie können die Größen der VM so auswählen, dass sie den Anforderungen Ihrer Organisation entspricht. Diese Konfiguration kann auch bis hin zu einer VM reduziert werden, je nach den geschäftlichen Anforderungen.

Das erste Diagramm zeigt eine Referenzarchitektur für SAP HANA in Azure mit Verfügbarkeitsgruppen.

Referenzarchitektur für SAP HANA-Hochskalierung (ScaleUp)Abbildung: Die Architektur einer HANA-Proudktionsumgebung in Azure mit Verfügbarkeitsgruppe.

Das zweite Diagramm zeigt eine Referenzarchitektur für SAP HANA in Azure, die Verfügbarkeitszonen nutzt.

Referenzarchitektur für SAP HANA-Hochskalierung (ScaleUp)Abbildung: Die Architektur einer HANA-Proudktionsumgebung in Azure mit Verfügbarkeitszone.

Laden Sie eine Visio Datei dieser Architektur herunter, die alle Versionen einschließlich Notfallwiederherstellung enthält.

Hinweis

Zum Bereitstellen dieser Referenzarchitektur benötigen Sie eine passende Lizenzierung von SAP-Produkten und anderen, nicht von Microsoft stammenden Technologiekomponenten.

Workflow

Mit dieser Referenzarchitektur wird eine typische SAP HANA-Datenbank beschrieben, die in Azure in einer Hochverfügbarkeitsbereitstellung ausgeführt wird, um die Systemverfügbarkeit zu maximieren. Die Architektur und ihre Komponenten können basierend auf den geschäftlichen Anforderungen (RTO, RPO, erwartete Uptime, Systemrolle) angepasst und ggf. auf einen einzelnen virtuellen Computer reduziert werden. Das Netzwerklayout wurde vereinfacht, um die Architekturprinzipien einer solchen SAP-Umgebung zu veranschaulichen, und dient nicht dazu, ein vollständiges Unternehmensnetzwerk zu beschreiben.

Netzwerk

Virtuelle Netzwerke (VNet): Der Dienst Azure Virtual Network verbindet Azure-Ressourcen miteinander und bietet erweiterte Sicherheit. In dieser Architektur wird das virtuelle Netzwerk über ein VPN-Gateway mit einer lokalen Umgebung verbunden, und dieses Gateway wird im Hub einer Hub-Spoke-Topologie bereitgestellt. Die SAP HANA-Datenbank ist in einem eigenen virtuellen Spoke-Netzwerk enthalten. Die virtuellen Spoke-Netzwerke enthalten ein Subnetz für die virtuellen Datenbankcomputer (VMs).

Wenn Anwendungen, die eine Verbindung mit SAP HANA herstellen, auf VMs ausgeführt werden, sollten sich die Anwendungs-VMs im selben VNet befinden, aber innerhalb eines dedizierten Anwendungssubnetzes. Wenn die SAP HANA-Verbindung nicht die primäre Datenbank ist, können sich die Anwendungs-VMs auch in anderen VNets befinden. Durch die Trennung in Subnetze nach Workload können Netzwerksicherheitsgruppen (NSG) einfacher aktiviert werden, um Sicherheitsregeln festzulegen, die nur für SAP HANA-VMs gelten.

Zonenredundantes Gateway Mit einem Gateway werden einzelne Netzwerke verbunden, um Ihr lokales Netzwerk auf das virtuelle Azure-Netzwerk zu erweitern. Wir empfehlen, dass Sie ExpressRoute verwenden, um private Verbindungen zu erstellen, die nicht über das öffentliche Internet gehen. Sie können auch eine Site-to-Site-Verbindung verwenden. Azure ExpressRoute- oder VPN-Gateways können zonenübergreifend bereitgestellt werden, um den Schutz vor Zonenausfällen zu ermöglichen. Informationen zu den Unterschieden zwischen einer zonenorientierten und zonenredundanten Bereitstellung finden Sie unter Zonenredundante Gateways für virtuelle Netzwerke. Für eine Zonenbereitstellung der Gateways müssen die verwendeten IP-Adressen von der Standard-SKU stammen.

Netzwerksicherheitsgruppen (NSG): Erstellen Sie Netzwerksicherheitsgruppen, um eingehenden und ausgehenden Netzwerkdatenverkehr des virtuellen Netzwerks einzuschränken. Diese Netzwerksicherheitsgruppen werden dann wiederum bestimmten Subnetzen zugewiesen. Datenbank- und Anwendungssubnetze werden durch workloadspezifische NSGs geschützt.

Anwendungssicherheitsgruppen (ASG): Verwenden Sie Anwendungssicherheitsgruppen anstelle expliziter IP-Adressen, um in Ihren NSGs differenzierte Netzwerksicherheitsrichtlinien basierend auf anwendungsorientierten Workloads zu definieren. Hiermit können Sie VMs nach Name gruppieren und Anwendungen schützen, indem Sie Datenverkehr aus vertrauenswürdigen Segmenten Ihres Netzwerks filtern.

Netzwerkschnittstellenkarten (Network Interface Cards, NICs) Netzwerkschnittstellenkarten ermöglichen die gesamte Kommunikation zwischen virtuellen Computern in einem virtuellen Netzwerk. In herkömmlichen lokalen SAP-Bereitstellungen sind mehrere NICs pro Computer implementiert, um administrativen Datenverkehr von Geschäftsdatenverkehr zu trennen.

In Azure ist das virtuelle Netzwerk eine softwaredefiniertes Netzwerk, in dem der gesamte Datenverkehr über dieselbe Netzwerkstruktur gesendet wird. Es ist also nicht notwendig, aus Leistungsgründen mehrere NICs zu verwenden. Wenn Ihre Organisation den Datenverkehr jedoch trennen muss, können Sie mehrere NICs pro VM bereitstellen und jede NIC mit einem anderen Subnetz verbinden. Sie können dann Netzwerksicherheitsgruppen verwenden, um verschiedene Zugriffssteuerungsrichtlinien für die einzelnen Subnetze zu erzwingen.

Azure-NICs unterstützen mehrere IPs. Diese Unterstützung hält die von SAP empfohlene Vorgehensweise ein, virtuelle Hostnamen für Installationen zu nutzen. Einen vollständigen Abriss finden Sie in SAP-Hinweis 962955. (Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto.)

Hinweis

Wie im SAP-Hinweis 2731110 erläutert wird, sollten Sie virtuelle Netzwerkgeräte (Network Virtual Appliances, NVAs) für SAP-Anwendungsstapel nicht zwischen der Anwendung und den Datenbankschichten anordnen. Diese Vorgehensweise würde zu einer hohen Verarbeitungsdauer für Datenpakete und somit zu einer inakzeptabel langsamen Anwendungsleistung führen.

Virtual Machines

In dieser Architektur werden virtuelle Computer (Virtual Machines, VMs) verwendet. Azure bietet eine Hochskalierung des Arbeitsspeichers auf einem einzelnen Knoten bis 11,5 Tebibyte (TiB) für VMs und eine Hochskalierung bis 24 TB auf einem einzelnen Knoten für Azure (große Instanzen). Im Verzeichnis mit von SAP HANA zertifizierter und unterstützter Hardware finden Sie eine Liste mit den zertifizierten VMs für die SAP HANA-Datenbank. Ausführliche Informationen zur SAP-Unterstützung für die Typen von VMs und die Durchsatzmetriken (SAPS) finden Sie in SAP-Hinweis 1928533 – SAP Applications on Microsoft Azure: Supported Products and Azure VM Types [SAP-Anwendungen in Microsoft Azure: Unterstützte Produkte und Azure-VM-Typen]. Ein Marketplace-Konto für den SAP-Dienst ist erforderlich, um auf diesen und andere SAP-Hinweise zugreifen zu können.

Microsoft und SAP zertifizieren gemeinsam verschiedene VM-Größen für SAP HANA-Workloads. Kleinere Bereitstellungen können z. B. auf einem virtuellen Computer der Familie Edsv4 und E(d)sv5 ausgeführt werden, beginnend mit 160 GiB RAM. Wenn die größte SAP HANA-Arbeitsspeichergröße auf VMs unterstützt werden soll, nämlich bis zu 11,5 TB, können Sie die Mv2-VMs der M-Serie von Azure, Version 2 verwenden. Die VM-Typen M208 erreichen etwa 260.000 SAPS, und die VM-Typen M416 erreichen etwa 488.000 SAPS.

VMs der zweiten Generation (Gen2). Azure bietet Ihnen beim Bereitstellen von VMs die Möglichkeit, zwischen VMs der ersten oder zweiten Generation zu wählen. VMs der zweiten Generation unterstützen wichtige Features, die für VMs der ersten Generation nicht verfügbar sind. Dies ist insbesondere bei SAP HANA wichtig, da einige VM-Familien wie Mv2 oder Mdsv2nur für Gen2-VMs unterstützt werden. Ebenso bietet die SAP in Azure-Zertifizierung bei einigen neueren VMs u. U. nur für Gen2-VMs vollständige Unterstützung, obwohl Azure die Verwendung beider Generationen zulässt. Weitere Informationen finden Sie im SAP-Hinweis 1928533 (SAP-Anwendungen in Microsoft Azure: Unterstützte Produkte und Azure-VM-Typen).

Da alle anderen VMs, die SAP HANA unterstützen, die Wahl zwischen „Nur Gen2“ oder „Gen1+2“ zulassen, wird empfohlen, alle SAP-VMs als „Nur Gen2“ bereitzustellen. Dies gilt auch für VMs mit niedrigen Arbeitsspeicheranforderungen. Selbst die kleinste SAP HANA-VM mit 160 GiB kann als Gen2-VM ausgeführt werden und kann bei der Aufhebung der Zuordnung auf die größte VM angepasst werden, die in Ihrer Region und Ihrem Abonnement verfügbar ist.

Näherungsplatzierungsgruppen (Proximity Placement Groups, PPGs): Zur Optimierung der Netzwerkwartezeit können Näherungsplatzierungsgruppen verwendet werden, bei denen die Platzierung am selben Ort im Vordergrund steht. Das bedeutet, dass sich virtuelle Computer im selben Rechenzentrum befinden, um die Wartezeit zwischen SAP HANA und verbindenden Anwendungs-VMs zu minimieren. Für die SAP HANA-Architektur selbst sind keine PPGs erforderlich. Sie sind nur eine Option, um SAP HANA mit VMs der Anwendungsebene am selben Ort zu platzieren. Aufgrund potenzieller Einschränkungen durch PPGs sollte die Verfügbarkeitsgruppe (AvSet) der Datenbank nur vereinzelt und nur, wenn dies aufgrund der Wartezeit beim Datenverkehr zwischen SAP-Anwendung und Datenbank erforderlich ist, der PPG des SAP-Systems hinzugefügt werden. Weitere Informationen zu den Verwendungsszenarien für PPGs finden Sie in der verlinkten Dokumentation. Da PPGs Workloads auf ein einzelnes Rechenzentrum beschränken, kann eine PPG nicht mehrere Verfügbarkeitszonen umfassen.

Komponenten

Überlegungen

Skalierbarkeit

Diese Architektur führt SAP HANA auf VMs aus, die auf bis zu 11,5 TiB in einer Instanz hochskaliert werden können.

Wenn Ihre Workload die maximale VM-Größe überschreitet, bietet Microsoft Azure (große Instanzen) für SAP HANA an. Bei Revision 4 sind diese physischen Server zusammen in einem Azure-Rechenzentrum angeordnet. Derzeit werden hierdurch bis zu 24 TB Speicherkapazität für eine einzelne Instanz bereitgestellt.

Eine Konfiguration mit mehreren Knoten ist ebenfalls möglich. Für OLTP-Anwendungen (Online Transaction Processing, Onlinetransaktionsverarbeitung) liegt die Gesamtspeicherkapazität bei bis zu 48 TB. Für OLAP-Anwendungen (Online Analytical Processing, analytische Onlineverarbeitung) liegt die Speicherkapazität bei 96 TB. Sie können beispielsweise SAP HANA in einer Konfiguration mit horizontaler Skalierung mit Standby auf VMs mithilfe von Azure NetApp Files für die freigegebenen Speichervolumes bereitstellen. Auf diesen VMs wird entweder Red Hat Enterprise Linux oder SUSE Linux Enterprise Server ausgeführt.

Storage

Diese Architektur verwendet verwaltete Azure-Datenträger für den Speicher auf den virtuellen Computern oder Azure NetApp Files. Detaillierte Richtlinien für die Speicherbereitstellung mit verwalteten Datenträgern finden Sie im Dokument für Speicherkonfigurationen virtueller Azure-Computer mit SAP HANA. Alternativ zu verwalteten Datenträgern können Azure NetApp Files NFS-Volumes als Speicherlösung für SAP HANA verwendet werden.

Zur Erreichung hoher Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) und eines hohen Durchsatzes beim Datenträgerspeicher gelten für das Azure-Speicherlayout ebenfalls die gängigen Vorgehensweisen zur Leistungsoptimierung für Speichervolumes. Wenn beispielsweise mehrere Datenträger mit LVM kombiniert werden, um ein Stripeset-Datenträgervolume zu erstellen, verbessert sich die E/A-Leistung. Das Zwischenspeichern auf Azure-Datenträgern spielt ebenfalls eine große Rolle bei der Erreichung der erforderlichen E/A-Leistung. Für SAP HANA-Protokolldatenträger sind schreibbeschleunigte Datenträger (auf VMs der M-Familie) oder Ultra Disks (auf VMs der M/E-Familien) oder Azure NetApp Files (auf VMs der M/E-Familien) für Bereiche erforderlich, die „/hana/log“ für die Produktionsnutzung enthalten, um die erforderliche Speicherlatenz von weniger als 1 ms konsistent zu erreichen.

Ausführliche Informationen zu den Leistungsanforderungen von SAP HANA finden Sie unter dem SAP-Hinweis 1943937 – Tool für die Überprüfung der Hardwarekonfiguration.

  • Kostenbewusstes Speicherdesign für nicht produktive Systeme: SAP HANA-Umgebungen, die nicht in allen Situationen maximale Speicherleistung erfordern, können eine Speicherarchitektur nutzen, die stärker unter dem Kostenaspekt optimiert ist. Dies kann auf wenig verwendete Produktionssysteme oder einige nicht produktive SAP HANA-Umgebungen zutreffen. Der kostenoptimierte Speicher verwendet eine Kombination aus Standard-SSDs anstatt nur Premium- oder nur Ultra-SSDs, die für die Produktion verwendet werden, und kombiniert auch „/hana/data“- und „/hana/log“-Dateisysteme auf derselben Gruppe von Datenträgern. Richtlinien und bewährte Methoden sind für die meisten VM-Größen verfügbar. Wenn sie Azure NetApp Files für SAP HANA verwenden, könnten Volumes mit verringerter Größe verwendet werden, um dasselbe Ziel zu erreichen.
  • Ändern der Größe des Speichers beim Hochskalieren: Beim Ändern der Größe des virtuellen Computers aufgrund geänderter geschäftlicher Anforderungen oder wegen einer wachsenden Datenbankgröße kann sich die Speicherkonfiguration ändern. Azure unterstützt die Onlinedatenträgererweiterung ohne Unterbrechung des Diensts. Bei einem Stripeset-Datenträgersetup, wie für SAP HANA verwendet, sollte ein Größenänderungsvorgang gleichermaßen für alle Datenträger in der Volumegruppe vorgenommen werden. Das Hinzufügen weiterer Datenträger zu einer Volumegruppe kann potenziell die Stripeset-Daten aus dem Gleichgewicht bringen. Wenn Sie einer Speicherkonfiguration mehr Datenträger hinzufügen, ist das Erstellen eines neuen Speichervolumes auf neuen Datenträgern deutlich zu bevorzugen. Kopieren Sie als Nächstes den Inhalt während der Ausfallzeit, und ändern Sie Bereitstellungspunkte. Verwerfen Sie schließlich die nicht mehr benötigte alte Volumegruppe und die zugrunde liegenden Datenträger.
  • NetApp-Anwendungsvolumegruppe (Vorschau): Bei Bereitstellungen mit SAP HANA-Dateien, die sich in Azure NetApp Files NFS-Volumes befinden, ermöglichen Ihnen Anwendungsvolumegruppen die Bereitstellung aller Volumes gemäß bewährten Methoden. Dieser Prozess gewährleistet auch eine optimale Leistung für Ihre SAP HANA-Datenbank. Details, wie Sie mit diesem Prozess fortfahren sollten, finden Sie hier. Da er manuelles Eingreifen erfordert, planen Sie für die Erstellung etwas Zeit ein.

Hochverfügbarkeit

Die obige Architektur stellt eine Hochverfügbarkeitsbereitstellung dar, bei der sich SAP HANA auf zwei oder mehr virtuellen Computern befindet. Folgende Komponenten werden verwendet:

Load BalancerAzure Load Balancer wird verwendet, um Datenverkehr auf virtuelle SAP HANA-Computer zu verteilen. Bei der Integration von Azure Load Balancer in eine zonale Bereitstellung von SAP muss der Lastenausgleich der Standard-SKU ausgewählt werden, da der Lastenausgleich der Basic-SKU nicht über Zonenredundanz verfügt. Load Balancer fungiert in dieser Architektur als virtuelle IP-Adresse für das SAP HANA, und Netzwerkdatenverkehr wird an die aktive VM gesendet, auf der die primäre Datenbankinstanz ausgeführt wird. Die aktive/lesefähige SAP HANA-Architektur ist verfügbar (SLES/RHEL), wo eine zweite virtuelle IP-Adresse auf dem Lastenausgleich verwendet wird, um Netzwerkdatenverkehr an die sekundäre SAP HANA-Instanz auf einer anderen VM für leseintensive Workloads weiterzuleiten.

Der Load Balancer Standard ist standardmäßig sicher und hinter dem Load Balancer Standard verfügen keine virtuellen Computer über eine ausgehende Internetkonnektivität. Um ausgehende Internetkonnektivität auf den virtuellen Computern zu aktivieren, müssen Sie Ihre Load Balancer Standard-Konfiguration berücksichtigen.

Sie müssen Direct Server Return (DSR) für SAP HANA-Datenbankcluster aktivieren. Diese Konfiguration ist auch als Floating IP bekannt. Dieses Feature ermöglicht es dem Server, auf die IP-Adresse des Front-Ends des Lastenausgleichsmoduls zu antworten. Diese direkte Verbindung verhindert, dass der Lastenausgleich zum Engpass auf dem Datenübertragungspfad wird.

Verfügbarkeitsgruppen Durch Verfügbarkeitsgruppen werden Server über die physische Azure-Infrastruktur verteilt, um sie auf verschiedene Fehler- und Updatedomänen aufzuteilen und so die Dienstverfügbarkeit zu verbessern. Um Vereinbarungen zum Servicelevel (Service-Level-Agreements, SLAs) zu erfüllen, fassen Sie virtuelle Computer, die dieselbe Rolle ausführen, in einer Verfügbarkeitsgruppe zusammen. Auf diese Weise können Sie sich vor geplanten wie ungeplanten Ausfallzeiten schützen, die durch die Wartung der Azure-Infrastruktur oder durch Hardwarefehler verursacht werden. Um eine höhere Vereinbarung zum Servicelevel zu erhalten, müssen Sie mindestens zwei virtuelle Computer pro Verfügbarkeitsgruppe verwenden.

Alle virtuellen Computer in einer Gruppe müssen dieselbe Rolle ausführen. Mischen Sie keine Server mit unterschiedlichen Rollen in derselben Verfügbarkeitsgruppe.

Sie können Azure-Verfügbarkeitsgruppen in Azure-Verfügbarkeitszonen anordnen, wenn Sie eine Näherungsplatzierungsgruppe verwenden.

VerfügbarkeitszonenVerfügbarkeitszonen sind physisch getrennte Standorte innerhalb einer bestimmten Azure-Region. Sie dienen zur weiteren Verbesserung der Dienstverfügbarkeit. Aufgrund ihrer potenziellen geografischen und netzwerkbezogenen Platzierung benötigen Administratoren ein eindeutiges Netzwerklatenzprofil zwischen allen Zonen einer Zielregion, um die Ressourcenplatzierung mit möglichst geringer Wartezeit zwischen Zonen bestimmen zu können. Stellen Sie zur Erstellung dieses Profils in jeder Zone zu Testzwecken virtuelle Computer bereit. Empfohlene Tools für diese Tests sind beispielsweise PsPing und Iperf. Wenn die Tests abgeschlossen sind, entfernen Sie die virtuellen Computer, die Sie für die Tests verwendet haben. Alternativ steht auch ein Tool zur Überprüfung der Wartezeit zwischen Azure-Zonen zur Verfügung.

Berücksichtigen Sie beim Bereitstellen von virtuellen Computern zwischen Verfügbarkeitszonen für SAP die Entscheidungsfaktoren.

SAP HANA: Wird auf mindestens zwei Linux-VMs ausgeführt, um Hochverfügbarkeit garantieren zu können. SAP HANA-Systemreplikation (HSR) wird verwendet, um Inhalte zwischen primären und sekundären HANA-Systemen (Replikat) zu replizieren. HSR wird auch für eine regions- oder zonenübergreifende Notfallwiederherstellung verwendet. Je nach Wartezeit bei der Kommunikation zwischen Ihren virtuellen Computern kann die synchrone Replikation innerhalb eine Region verwendet werden. HSR zwischen Regionen für die Notfallwiederherstellung wird in den meisten Fällen asynchron ausgeführt.

Für den Linux Pacemaker-Cluster muss eine Auswahl getroffen werden, welcher Clusterfencing-Mechanismus verwendet werden soll. Clusterfencing ist ein Prozess zum Isolieren einer fehlgeschlagenen VM im Cluster mit anschließendem Neustart. Bei Red Hat Enterprise Linux (RHEL) ist der einzige unterstützte Fencing-Mechanismus für Pacemaker in Azure der Azure Fence Agent. Bei SUSE Linux Enterprise Server (SLES) kann entweder der Azure Fence Agent oder das STONITH-Blockgerät (SBD) verwendet werden. Vergleichen Sie die Failoverzeiten für jede Lösung und wählen Sie basierend auf Ihren Geschäftsanforderungen für das Wiederherstellungszeitziel (RTO) aus, wenn ein signifikanter Unterschied vorhanden ist.

Azure Fence Agent: Diese Fencing-Methode basiert auf der Azure ARM-API, wobei Pacemaker den Status beider SAP HANA-VMs im Cluster bei der ARM-API abfragt. Sollte eine VM fehlschlagen, z. B. wenn das Betriebssystem nicht reagiert oder die VM abstürzt, verwendet der Cluster-Manager erneut die ARM-API, um die VM neu zu starten, und führt bei Bedarf ein Failover der SAP HANA-Datenbank auf den anderen, aktiven Knoten durch. Für diesen Zweck wird ein Dienstprinzipalname (SPN) mit einer benutzerdefinierten Rolle zum Abfragen und Neustarten von VMs verwendet, um sich bei der ARM-API zu autorisieren. Es ist keine andere Infrastruktur erforderlich, und die SBD-VMs in den Architekturzeichnungen werden nicht bereitgestellt, wenn ein Azure Fence Agent verwendet wird.

SBD STONITH Block Device (SBD) verwendet einen Datenträger, auf den als Blockgerät (unbearbeitet, ohne Dateisystem) vom Cluster-Manager zugegriffen wird. Dieser Datenträger oder Datenträger, falls mehrere, fungiert(en) als Abstimmung. Jeder der zwei Clusterknoten, auf denen SAP HANA ausgeführt wird, greift auf die SDB-Datenträger zu und liest/schreibt regelmäßig kleine Informationsmengen zum Status darauf. Somit kennt jeder Clusterknoten den Status des anderen, ohne nur abhängig von der Vernetzung zwischen den VMs zu sein.

Vorzugsweise werden drei kleine VMs entweder in einer Verfügbarkeitsgruppe oder einer Verfügbarkeitszone eingerichtet. Jede VM exportiert kleine Teile eines Datenträgers als Blockgerät, auf das von den beiden SAP HANA-Clusterknoten zugegriffen wird. Drei SBD-VMs stellen sicher, dass im Falle geplanter oder nicht geplanter Ausfallzeiten ausreichende Abstimmungsmitglieder für jede der SBD-VMs verfügbar sind.

Alternativ zur Verwendung von SBD-VMs kann stattdessen ein freigegebener Azure-Datenträger verwendet werden. Die SAP HANA-Clusterknoten greifen dann auf den einzelnen freigegebenen Datenträger zu. Der freigegebene Datenträger kann lokal (LRS) oder zonal (ZRS) redundant sein, wenn ZRS in Ihrer Azure-Region verfügbar ist.

Notfallwiederherstellung

Referenzarchitektur für SAP HANA-Hochskalierung (ScaleUp)Abbildung: Die Architektur einer HANA-Proudktionsumgebung in Azure mit Verfügbarkeitszone mit Notfallwiederherstellung.

Bei dieser Architektur wird HSR für die Datenbankreplikation in eine Datenbankinstanz in der sekundären Region verwendet. Es ist optional, einen Cluster in der sekundären Region zu verwenden. Wird dies jedoch getan, kann dies die SAP HANA-Verfügbarkeit nach einem Notfallwiederherstellungsfailover verbessern.

Zusätzlich zu einer lokalen Hochverfügbarkeitsimplementierung auf zwei Knoten unterstützt HSR die Replikation für mehrere Ebenen und mehrere Ziele. HSR ermöglicht also eine zonen- und regionsübergreifende Replikation. Replikation mit mehreren Zielen ist ab SAP HANA 2.0 SPS 03 verfügbar.

Das Auslösen eines Notfallwiederherstellungsfailovers ist ein manueller Prozess. Sie können jedoch Wiederherstellungspläne mit angepassten Bereitstellungsskripts verwenden, um zahlreiche Schritte des Failovers zu automatisieren.

Azure Site Recovery: Sie können Azure Site Recovery verwenden, um Ihre Produktionskonfiguration automatisch an einen sekundären Standort zu replizieren. Zwar wäre dies nicht Ihre Datenbank-VM, da sie mit HSR geschützt ist, doch können alle anderen VMs Ihrer Anwendungsebene von Azure Site Recovery behandelt werden. Sie können angepasste Bereitstellungsskripts verwenden, um Ihre Wiederherstellungspläne zu erweitern. Ein Beispiel für das benutzerdefinierte Skript für Site Recovery-Automatisierungs-Runbooks finden Sie auf GitHub.

Überprüfen Sie die Ressourcenkapazität Ihrer Zielregion.

Azure NetApp Files: Azure NetApp Files kann als Option verwendet werden, um eine skalierbare und hochleistungsfähige Speicherlösung für SAP HANA-Daten und -Protokolldateien bereitzustellen. Azure NetApp Files unterstützt Momentaufnahmen für schnelle Sicherungen, Wiederherstellungen und die lokale Replikation. Für die regionsübergreifende Inhaltsreplikation kann die regionsübergreifende Replikation von Azure NetApp Files verwendet werden, um die Momentaufnahmedaten zwischen zwei Regionen zu replizieren. Details zur regionsübergreifenden Replikation und ein Whitepaper, in dem alle Aspekte für die Notfallwiederherstellung mit Azure NetApp Files beschrieben werden, sind verfügbar.

Backup

SAP HANA kann auf viele verschiedene Arten gesichert werden. Nach der Migration zu Azure können Sie weiterhin alle vorhandenen Sicherungslösungen von Partnern nutzen, die Sie bereits verwenden. In Azure stehen zwei native Ansätze zur Verfügung: SAP HANA-Sicherungen auf Dateiebene und Azure Backup für SAP HANA über die Backint-Schnittstelle.

Bei der SAP HANA-Sicherung auf Dateiebene können Sie ein Tool Ihrer Wahl verwenden, z. B. hdbsql oder SAP HANA Studio, und die Sicherungsdateien auf einem lokalen Datenträgervolume speichern. Ein gängiger Bereitstellungspunkt für dieses Sicherungsvolume ist /hana/backup. Ihre Sicherungsrichtlinien definieren den Aufbewahrungszeitraum für die Daten auf diesem Volume. Sobald die Sicherung erstellt wurde, sollte eine geplante Aufgabe die Sicherungsdateien zur Aufbewahrung in Azure-Blobspeicher kopieren. Die lokalen Sicherungsdateien werden für Wiederherstellungszwecke beibehalten.

Azure Backup bietet eine einfache Lösung für Unternehmen an, die für Workloads eingesetzt werden kann, die auf VMs ausgeführt werden. Azure Backup für SAP HANA stellt eine vollständige Integration mit dem SAP HANA-Sicherungskatalog zur Verfügung und sorgt für Wiederherstellungen, bei denen die Datenbank konsistent bleibt und die entweder vollständig oder für einen bestimmten Zeitpunkt ausgeführt werden können. Azure Backup verfügt über eine BackInt-Zertifizierung von SAP. Siehe auch die Häufig gestellten Fragen zu Azure Backup und die Unterstützungsmatrix.

Azure NetApp Files bietet Unterstützung für momentaufnahmebasierte Sicherungen. Die Integration in SAP HANA für konsistente Momentaufnahmen von Anwendungen erfolgt über das Tool für konsistente Momentaufnahmen in Azure-Anwendungen (AzAcSnap). Die erstellten Momentaufnahmen können zum Wiederherstellen auf einem neuen Volume für die Systemwiederherstellung oder zum Kopieren der SAP HANA-Datenbank verwendet werden. Erstellte Momentaufnahmen können für die Notfallwiederherstellung verwendet werden, wo sie als Wiederherstellungspunkt mit SAP HANA-Protokollen fungieren, die auf einem anderen NFS-Volume gespeichert sind.

Überwachung

Mit Azure Monitor können Sie umfassende Telemetriedaten aus Ihren Cloud- und lokalen Umgebungen für das Überwachen Ihrer Workloads in Azure sammeln, analysieren und auf die entsprechenden Ergebnisse reagieren.

Zum Bereitstellen einer SAP-basierten Überwachung der unterstützten Azure-Infrastruktur und -Datenbanken werden Azure Monitor für SAP-Lösungen (Vorschauversion) verwendet. Azure Monitor für SAP-Lösungen bieten eine einfache Einrichtungserfahrung. Der Kunde kann Telemetriedaten von Azure-Ressourcen erfassen. Anschließend kann er diese Daten mit verschiedenen Überwachungs-KPIs korrelieren und bei der Problembehandlung einsetzen.

Die Azure-Erweiterung zur verbesserten Überwachung für SAP wird verwendet, um SAP-basierte Überwachung von Ressourcen sowie der Leistung von Diensten der SAP-Infrastruktur bereitzustellen. Mit dieser Erweiterung werden statistische Daten zur Azure-Überwachung in die SAP-Anwendung eingespeist, damit die Betriebssystemüberwachung und DBA Cockpit-Funktionen ermöglicht werden. Die erweiterte Überwachung von SAP ist eine obligatorische Voraussetzung für die Ausführung von SAP in Azure. Ausführliche Informationen hierzu finden Sie im SAP-Hinweis 2191498: „SAP unter Linux mit Azure: Erweiterte Überwachung“.

Sicherheit

Viele Sicherheitsmaßnahmen werden verwendet, um die Vertraulichkeit, Integrität und Verfügbarkeit einer SAP-Landschaft zu schützen. SAP verfügt zur Sicherung des Benutzerzugriffs beispielsweise über ein eigenes Modul für die Benutzerverwaltung (Users Management Engine, UME), um den rollenbasierten Zugriff und die Autorisierung in der SAP-Anwendung und den Datenbanken zu steuern. Weitere Informationen finden Sie unter SAP HANA-Sicherheit – Eine Übersicht.

Für Daten im Ruhezustand bieten verschiedene Verschlüsselungsfunktionen folgende Sicherheit:

  • Ziehen Sie in Betracht, zusammen mit der nativen SAP HANA-Verschlüsselungstechnologie auch eine Verschlüsselungslösung von einem Partner zu verwenden, der von Kunden verwaltete Schlüssel unterstützt.

  • Zum Verschlüsseln von Datenträgern virtueller Maschinen können Sie die unter Übersicht über die Datenträgerverschlüsselung beschriebenen Funktionalitäten verwenden.

  • SAP-Datenbankserver: Verwenden Sie Transparent Data Encryption, die vom DBMS-Anbieter angeboten wird (z. B. native SAP HANA-Verschlüsselungstechnologie), um Ihre Daten- und Protokolldateien zu sichern und sicherzustellen, dass die Sicherungen ebenfalls verschlüsselt werden.

  • Ruhende Daten in physischem Speicher in Azure (serverseitige Verschlüsselung) werden automatisch mithilfe eines von Azure verwalteten Schlüssels verschlüsselt. Sie können auch einen kundenseitig verwalteten Schlüssel (Customer Managed Key, CMK) anstelle des verwalteten Azure-Schlüssels auswählen.

  • Für die Unterstützung von Azure Disk Encryption auf bestimmten Linux-Distributionen/Versionen/Abbildern siehe Azure Disk Encryption für Linux VMs.

Hinweis

Kombinieren Sie die native SAP HANA-Verschlüsselungstechnologie nicht mit Azure Disk Encryption oder der hostbasierten Verschlüsselung auf demselben Speichervolume. Außerdem weisen Betriebssystembootdatenträger für virtuelle Linux-Computer keine Unterstützung für Azure Disk Encryption auf. Kombinieren Sie es bei Verwendung der nativen SAP HANA-Verschlüsselung stattdessen mit serverseitiger Verschlüsselung, die automatisch aktiviert ist. Beachten Sie, dass sich die Verwendung von vom Kunden verwalteten Schlüsseln auf den Speicherdurchsatz auswirken kann.

Verwenden Sie für die Netzwerksicherheit Netzwerksicherheitsgruppen (NSGs) und Azure Firewall oder ein virtuelles Netzwerkgerät wie folgt:

  • Verwenden Sie NSGs, um den Datenverkehr zwischen Subnetzen und Anwendungs-/Datenbankschichten zu schützen und zu steuern. Wenden Sie nur Netzwerksicherheitsgruppen (NSGs) auf Subnetze an. NSGs, die sowohl auf die NIC als auch auf das Subnetz angewendet werden, führen sehr oft zu Problemen bei der Problembehandlung und sollten nur selten verwendet werden, wenn überhaupt.

  • Verwenden Sie Azure Firewall oder ein virtuelles Azure-Netzwerkgerät, um das Routing des Datenverkehrs vom virtuellen Hubnetzwerk an das virtuelle Spoke-Netzwerk, in dem sich Ihre SAP-Anwendungen befinden, zu untersuchen und zu kontrollieren sowie um außerdem Ihre ausgehende Internetkonnektivität zu kontrollieren.

Implementieren Sie für Benutzer und Autorisierung wie folgt die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) und Ressourcensperren:

  • Befolgen Sie das Prinzip der geringsten Rechte, indem Sie RBAC verwenden, um Ressourcen auf IaaS-Ebene, die Ihre SAP-Lösung in Azure hosten, Administratorrechte zuzuweisen. Grundsätzlich besteht der Hauptzweck der rollenbasierten Zugriffssteuerung in der Trennung und Kontrolle der Aufgaben für Ihre Benutzer/Gruppen. RBAC ist darauf ausgelegt, den Benutzern nur die Zugriffsrechte zu gewähren, die diese zum Ausführen ihrer Aufgaben benötigen.

  • Verwenden Sie Ressourcensperren, um Risiken zu vermeiden, die entweder versehentlich oder durch böswillige Absichten entstehen können. Ressourcensperren verhindern Szenarien, in denen ein Administrator wichtige Azure-Ressourcen an dem Ort löscht oder ändert, an dem sich Ihre SAP-Lösung befindet.

Weitere Sicherheitsempfehlungen finden Sie in diesen Artikeln von Microsoft und SAP.

Communitys

Communitys können Fragen beantworten und Sie beim Einrichten einer erfolgreichen Bereitstellung unterstützen. Nutzen Sie die folgenden Communitys:

Nächste Schritte

Erfahren Sie mehr über die Komponententechnologien:

Erkunden Sie die verwandten Architekturen: