Bearbeiten

Freigeben über

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

Azure
Azure Virtual Machines

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 folgende Diagramm zeigt eine Referenzarchitektur für SAP HANA in Azure:

Diagramm: Architektur mit regionaler Bereitstellung

Laden Sie eine Visio-Datei herunter, die die Diagramme in diesem Artikel 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. Der Azure Virtual Network-Dienst verbindet Azure-Ressourcen miteinander mit erweiterter Sicherheit. In dieser Architektur wird das virtuelle Netzwerk über ein ExpressRoute-Gateway, das im Hub einer Hub-Spoke-Topologie bereitgestellt ist, mit einer lokalen Umgebung verbunden. 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 virtuellen Computern ausgeführt werden, sollten sich die Anwendungs-VMs im selben virtuellen Netzwerk 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 virtuellen Netzwerken 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, aber Sie können auch eine Site-to-Site-Verbindung verwenden. Verwenden Sie zonenredundante Azure ExpressRoute- oder VPN-Gateways, um vor Zonenfehlern zu schützen. Informationen zu den Unterschieden zwischen einer zonenorientierten und zonenredundanten Bereitstellung finden Sie unter Zonenredundante Gateways für virtuelle Netzwerke. Hinweis: Für eine Zonenbereitstellung der Gateways müssen die verwendeten IP-Adressen von der Standard-SKU stammen.

Netzwerksicherheitsgruppen (NSGs). Erstellen Sie Netzwerksicherheitsgruppen, um den 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 (ASGs). Verwenden Sie Anwendungssicherheitsgruppen anstelle von expliziten IP-Adressen, um detaillierte Netzwerksicherheitsrichtlinien in Ihren Netzwerksicherheitsgruppen basierend auf Workloads zu definieren, die auf Anwendungen ausgerichtet sind. Auf diese Weise können Sie Netzwerkschnittstellen von VMs nach Namen gruppieren und Anwendungen schützen, indem Sie Datenverkehr aus vertrauenswürdigen Segmenten Ihres Netzwerks filtern.

Netzwerkschnittstellenkarten (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 es nicht notwendig, aus Leistungsgründen mehrere Netzwerkschnittstellenkarten zu verwenden. Das Netzwerkdurchsatzlimit einer VM gilt für mehrere Netzwerkschnittstellen. 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.

Virtuelle Computer

In dieser Architektur werden virtuelle Computer (Virtual Machines, VMs) verwendet. Azure bietet für einzelne Knoten eine Hochskalierung auf bis zu 23,5 Tebibyte (TiB) Arbeitsspeicher auf VMs. 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 beispielsweise auf einer Edsv4- oder einer Edsv5-VM mit 160 GiB oder mehr RAM ausgeführt werden. Um die größten SAP HANA-Speichergrößen auf virtuellen Computern zu unterstützen, können Sie bis zu 30 TiB virtuelle Maschinen der Mv3-Serie verwenden.

VMs der 2. Generation (Gen2). Wenn Sie VMs bereitstellen, können Sie virtuelle Computer der 1.  oder 2. Generation verwenden. VMs der zweiten Generation unterstützen wichtige Features, die für VMs der ersten Generation nicht verfügbar sind. Für SAP HANA ist dies besonders wichtig, weil einige VM-Familien, wie z. B. Mv2 und Mdsv2, nur als 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 kann als Gen2-VM ausgeführt werden und kann bei der Zuordnung auf den größten virtuellen Computer in Ihrer Region angepasst werden.

Näherungsplatzierungsgruppen (PPGs). Wenn virtuelle Computer in Verfügbarkeitszonen bereitgestellt werden, ist die Latenz innerhalb der Zone in der Regel ideal für fast alle SAP HANA-Anwendungen. Um die Netzwerklatenz weiter zu optimieren, können Sie Näherungsplatzierungsgruppen verwenden. Dies bedeutet, dass sich virtuelle Computer im selben Rechenzentrum befinden, um die Latenz zwischen SAP HANA und dem Verbinden von Anwendungs-VMs zu minimieren. Für die SAP HANA-Architektur selbst sind keine PPGs erforderlich, sie sind nur eine Option, die SAP HANA mit Anwendungsebenen-VMs zu verbinden. 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

In diesem Abschnitt werden wichtige Überlegungen zum Ausführen von SAP HANA in Azure beschrieben.

Skalierbarkeit

Diese Architektur führt SAP HANA auf virtuellen Computern aus, die in einer Instanz bis zu 30 TiB skalieren können.

Wenn Ihre Workload die maximale VM-Größe überschreitet, wird empfohlen, HANA-Konfigurationen mit mehreren Knoten zu verwenden. Bei OLTP-Anwendungen (Online Transaction Processing) kann die Gesamteskalierungsspeicherkapazität so hoch wie 4 x 30 TiB sein. Bei OLAP-Anwendungen (Online Analytical Processing) kann die Skalierungskapazität so hoch wie 16 x 15,2 TiB sein. 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. Die Zwischenspeicherung auf Azure-Datenträgern spielt beim Erreichen der erforderlichen E/A-Leistung ebenfalls eine wichtige Rolle.

Verwenden Sie für SAP HANA-Protokolldatenträger, die auf Azure SSD Premium v1 ausgeführt werden, eine der folgenden Technologien in Speicherorten, die /hana/log für die Produktion enthalten:

Diese Technologien werden benötigt, um die erforderliche Speicherlatenz von weniger als 1 ms konsistent zu erfüllen.

Azure SSD Premium v2 ist für leistungskritische Workloads wie SAP konzipiert. Die Schreibbeschleunigung wird nicht benötigt, wenn /hana/log auf SSD Premium v2 ausgeführt wird. Informationen zu den Vorteilen und aktuellen Einschränkungen dieser Speicherlösung finden Sie unter Bereitstellen eines SSD Premium v2-Datenträgers.

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

  • Kostenbewusster Speicherentwurf für Nicht-Produktionssysteme. Für SAP HANA-Umgebungen, die nicht in allen Situationen eine maximale Speicherleistung erfordern, können Sie eine kostenoptimierte Speicherarchitektur verwenden. Diese Speicheroptimierung kann für wenig verwendete Produktionssysteme oder einige Nicht-Produktionsumgebungen von SAP HANA genutzt werden. Die kostenoptimierte Speicheroption verwendet eine Kombination aus SSD Standard-Datenträgern anstelle der SSD Premium- oder Ultra-Datenträger, die für Produktionsumgebungen verwendet werden. Außerdem werden die Dateisysteme /hana/data und /hana/log auf einem einzelnen Datenträgersatz kombiniert. Richtlinien und Best Practices stehen für die meisten VM-Größen zur Verfügung. Wenn Sie Azure NetApp Files für SAP HANA verwenden, können Sie kleinere Volumes einsetzen, um dasselbe Ziel zu erreichen.

  • Ändern der Speichergröße beim Hochskalieren. Wenn Sie aufgrund geänderter geschäftlicher Anforderungen oder wachsender Datenbanken die Größe einer VM ändern, 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 es sehr sinnvoll, ein neues Speichervolume auf neuen Datenträgern zu erstellen. Kopieren Sie als Nächstes während der Downtime die Inhalte, und ändern Sie die Bereitstellungspunkte. Schließlich verwerfen Sie die alte Volumegruppe und die zugrunde liegenden Datenträger.

  • Azure NetApp Files-Anwendungsvolumegruppe. Für Bereitstellungen mit SAP HANA-Dateien, die sich in Azure NetApp Files NFS-Volumes befinden, ermöglichen Ihnen Anwendungsvolumegruppen die Bereitstellung aller Volumes gemäß Best Practices. Dieser Prozess gewährleistet auch eine optimale Leistung für Ihre SAP HANA-Datenbank. Hier finden Sie Informationen dazu, wie Sie diesen Prozess ausführen. Es sind manuelle Eingriffe erforderlich. Planen Sie genügend Zeit für die Erstellung ein.

Hochverfügbarkeit

Die oben gezeigte Architektur stellt eine Hochverfügbarkeitsbereitstellung dar, bei der sich SAP HANA auf zwei oder mehr VMs befindet. Die folgenden Komponenten werden verwendet.

Lastenausgleichsmodule. Azure Load Balancer wird verwendet, um den Datenverkehr auf SAP HANA-VMs zu verteilen. Wenn Sie Azure Load Balancer in einer zonenbasierten SAP-Bereitstellung einbinden, wählen Sie unbedingt die Standard-SKU von Load Balancer aus. Der Standard-SKU-Balancer unterstützt keine zonal redundanz und ist veraltet. In dieser Architektur fungiert Load Balancer als virtuelle IP-Adresse für SAP HANA. Netzwerkdatenverkehr wird mit der primären Datenbankinstanz an die aktive VM gesendet. Die active/read-enabled-Architektur von SAP HANA ist optional verfügbar (SLES/RHEL), wobei eine zweite virtuelle IP, die auf dem Lastenausgleichsmodul adressiert ist, verwendet wird, um den Netzwerkdatenverkehr an die sekundäre SAP HANA-Instanz auf einem anderen virtuellen Computer für leseintensive Workloads zu leiten.

Load Balancer Standard bietet standardmäßig eine gewisses Maß an Sicherheit. VMs, die sich hinter Load Balancer Standard befinden, verfügen nicht über ausgehende Internetkonnektivität. Um für diese VMs ausgehende Internetverbindungen zu aktivieren, müssen Sie Ihre Load Balancer Standard-Konfiguration aktualisieren. Zudem können Sie auch ein Azure NAT Gateway verwenden, um ausgehende Konnektivität zu erhalten.

Für SAP HANA-Datenbankcluster müssen Sie Direct Server Return (DSR) aktivieren, auch als unverankerte IP bezeichnet. Mit diesem Feature kann der Server mit der IP-Adresse des Front-End-Lastenausgleichs reagieren.

Bereitstellungsoptionen. In Azure kann die Bereitstellung von SAP-Workloads je nach Verfügbarkeits- und Resilienzanforderungen der SAP-Anwendungen entweder regions- oder zonenbasiert sein. Azure bietet verschiedene Bereitstellungsoptionen wie VM-Skalierungsgruppen mit flexibler Orchestrierung (FD=1), Verfügbarkeitszonen und Verfügbarkeitsgruppen, um die Verfügbarkeit von Ressourcen zu verbessern. Umfassende Informationen zu den verfügbaren Bereitstellungsoptionen und deren Anwendbarkeit in verschiedenen Azure-Regionen (zonenübergreifend, innerhalb einer einzelnen Zone oder in einer Region ohne Zonen) finden Sie unter Hochverfügbarkeitsarchitektur und -szenarien für SAP NetWeaver.

SAP HANA. 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 müssen Sie entscheiden, welcher Clusterfencingmechanismus verwendet werden soll. Clusterfencing ist der Prozess, mit dem eine ausgefallene VM im Cluster isoliert und anschließend neu gestartet wird. Bei Red Hat Enterprise Linux (RHEL) ist der einzige unterstützte Fencing-Mechanismus für Pacemaker in Azure der Azure Fence Agent. Für SUSE Linux Enterprise Server (SLES) können Sie entweder den Azure-Fence-Agent oder das STONITH Block Device (SBD) verwenden. Vergleichen Sie die Failoverzeiten für jede Lösung, und wählen Sie – sofern Unterschiede vorhanden sind – basierend auf Ihren Geschäftsanforderungen für das Wiederherstellungszeitziel (RTO) eine geeignete Lösung aus.

Azure-Fence-Agent. Diese Fencing-Methode basiert auf der Azure ARM-API, wobei Pacemaker ARM-API über den Status beider SAP HANA-VMs im Cluster abfragt. Sollte ein virtueller Computer fehlschlagen, z. B. nicht reagierende Betriebssysteme oder VM-Absturz, verwendet der Cluster-Manager erneut die ARM-API, um den virtuellen Computer neu zu starten, und schlägt bei Bedarf die SAP HANA-Datenbank auf den anderen aktiven Knoten fehl. Zu diesem Zweck wird ein Dienstnamenprinzipal (Service Name Principal, SPN) mit einer benutzerdefinierten Rolle zum Abfragen und Neustarten von VMs verwendet, um die Autorisierung für die ARM-API auszuführen. Es ist keine andere Infrastruktur erforderlich, und die SBD-VMs in den Architekturzeichnungen werden nicht bereitgestellt, wenn ein Azure Fence Agent verwendet wird.

SBD. Das STONITH Block Device (SBD) verwendet einen Datenträger, auf den der Cluster-Manager als Blockgerät (unformatiert, ohne Dateisystem) zugreift. 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

Die folgende Architektur zeigt eine HANA-Produktionsumgebung in Azure, die Notfallwiederherstellung bietet. Die Architektur enthält Verfügbarkeitszonen.

Diagramm: Architektur mit Notfallwiederherstellung

Ausführliche Informationen zu Strategien und Implementierung der Notfallwiederherstellung finden Sie unter Übersicht über die Notfallwiederherstellung und Leitlinien für die Infrastruktur für SAP-Workloads und Richtlinien zur Notfallwiederherstellung für SAP-Anwendungen.

Hinweis

Bei einem regionalen Ausfall, der zu einem großen Failoverereignis für viele Azure-Kunden in einer Region führt, ist die Ressourcenkapazität in der Zielregion nicht garantiert. Wie bei allen Azure-Diensten werden auch in Azure Site Recovery ständig Features und Funktionen hinzugefügt. Aktuelle Informationen zur Replikation von Azure zu Azure finden Sie in der Supportmatrix.

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

Ü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.

Informationen zu SAP-Anwendungen, die auf SAP HANA und anderen wichtigen Datenbanklösungen ausgeführt werden, finden Sie unter Azure Monitor für SAP-Lösungen. Hier erfahren Sie, wie Azure Monitor für SAP Ihnen helfen kann, die Verfügbarkeit und Leistung von SAP-Diensten zu verwalten.

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 eine Transparent Data Encryption-Lösung des DBMS-Anbieters (z. B. native SAP HANA-Verschlüsselungstechnologie), um Ihre Daten- und Protokolldateien zu sichern und gewährleisten, 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 von Azure verwalteten Schlüssels auswählen.

  • Informationen zur Unterstützung für Azure Disk Encryption in bestimmten Linux-Distributionen, -Versionen und -Images finden Sie unter 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 bieten Betriebssystem-Startdatenträger für Linux-VMs keine Unterstützung für Azure Disk Encryption. Kombinieren Sie die native SAP HANA-Verschlüsselung stattdessen mit einer serverseitigen Verschlüsselung, die automatisch aktiviert ist. Beachten Sie, dass sich die Verwendung von kundenseitig 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, und verwenden Sie RBAC, um Ressourcen auf IaaS-Ebene, die Ihre SAP-Lösung in Azure hosten, Administratorrechte zuzuweisen. Der grundlegende Zweck von RBAC ist die Trennung und Steuerung der Pflichten für Ihre Benutzer*innen und Gruppen. RBAC ist darauf ausgelegt, Benutzer*innen nur das Maß an Zugriff auf Ressourcen zu gewähren, das sie zum Ausführen ihrer Aufgaben benötigen.

  • Verwenden Sie Ressourcensperren, um versehentliche oder böswillige Änderungen zu verhindern. Ressourcensperren verhindern, dass Administrator*innen kritische Azure-Ressourcen löschen oder ändern, in denen 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:

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Erfahren Sie mehr über die Komponententechnologien:

Erkunden Sie die verwandten Architekturen: