SAP S/4HANA unter Linux in Azure

In diesem Leitfaden werden einige bewährte Methoden für die Ausführung von S/4HANA und Suite für HANA in einer Hochverfügbarkeitsumgebung veranschaulicht, die die Notfallwiederherstellung (DR) in Azure unterstützt. Die Fiori-Informationen gelten nur für S/4HANA-Anwendungen.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

In diesem Leitfaden wird ein gängiges Produktionssystem beschrieben. Diese Architektur wird mit virtuellen Computern (VM) bereitgestellt, deren Größe Sie je nach den Anforderungen Ihres Unternehmens ändern können. Sie können diese Konfiguration auf eine einzelne VM reduzieren, um Ihren geschäftlichen Anforderungen zu entsprechen.

In diesem Leitfaden ist das Layout des Netzwerks stark vereinfacht, um die Architekturprinzipien zu demonstrieren. Es dient nicht dazu, ein gesamtes Unternehmensnetzwerk zu beschreiben.

Diese Architektur nutzt die folgenden Komponenten. Einige freigegebene Dienste sind optional.

Azure Virtual Network. Der Virtual Network-Dienst verbindet Azure-Ressourcen sicher miteinander. In dieser Architektur wird ein virtuelles Netzwerk über ein Gateway mit einer lokalen Umgebung verbunden, und dieses Gateway wird im Hub einer Hub-Spoke-Topologie bereitgestellt. Die Speiche (Spoke) ist das virtuelle Netzwerk, das für die SAP-Anwendungen und die Datenbankschichten verwendet wird.

Peering virtueller Netzwerke. Bei dieser Architektur werden mehrere virtuelle Netzwerke genutzt, die per Peering verbunden sind. Diese Topologie ermöglicht die Netzwerksegmentierung und -isolation für Dienste, die in Azure bereitgestellt werden. Beim Peering werden Netzwerke transparent über das Microsoft-Backbone-Netzwerk verbunden, und es kommt nicht zu Leistungseinbußen, wenn die Bereitstellung innerhalb derselben Region erfolgt. Für jede Schicht werden getrennte Subnetze genutzt: Anwendung (SAP NetWeaver), Datenbank und für gemeinsame Dienste, z. B. Jumpbox und Windows Server Active Directory.

VMs. Diese Architektur verwendet VMs, die Linux für die Logikschicht und die Datenbankschicht ausführen, die wie folgt gruppiert sind:

• Anwendungsschicht: Diese Schicht umfasst den Fiori-Front-End-Serverpool, den SAP Web Dispatcher-Pool, den Anwendungsserverpool und den SAP Central Services-Cluster. Für die Hochverfügbarkeit von Central Services in Azure, die in Linux-VMs ausgeführt werden, ist ein hochverfügbarer Netzwerkdateifreigabe-Dienst erforderlich, z. B. NFS-Dateifreigaben in Azure Files, Azure NetApp Files, gruppierte NFS-Server (Network File System) oder SIOS Protection Suite für Linux. Zum Einrichten einer hochverfügbaren Dateifreigabe für den Central Services-Cluster unter Red Hat Enterprise Linux (RHEL) können Sie GlusterFS auf Azure-VMs konfigurieren, die RHEL ausführen. Unter SUSE Linux Enterprise Server (SLES) 15 SP1 und höheren Versionen oder SLES für SAP-Anwendungen können Sie freigegebene Azure-Datenträger in einem Pacemaker-Cluster verwenden, um Hochverfügbarkeit zu erzielen.

• SAP HANA. Auf der Datenbankschicht werden mindestens zwei virtuelle Linux-Computer in einem Cluster verwendet, um Hochverfügbarkeit für eine Bereitstellung mit zentraler Hochskalierung zu erzielen. HANA-Systemreplikation (HSR) wird verwendet, um Inhalte zwischen primären und sekundären HANA-Systemen zu replizieren. Linux-Clustering wird verwendet, um Systemfehler zu erkennen und automatisches Failover zu ermöglichen. Ein speicherbasierter oder cloudbasierter Fencingmechanismus muss verwendet werden, um sicherzustellen, dass das ausgefallene System isoliert oder heruntergefahren wird, um den Split-Brain-Zustand für Cluster zu vermeiden. In HANA-Bereitstellungen für horizontales Skalieren können Sie die Hochverfügbarkeit der Datenbank mithilfe einer der folgenden Optionen erreichen:

  • Konfigurieren Sie HANA-Standbyknoten mithilfe von Azure NetApp Files ohne die Linux-Clusteringkomponente.
  • Führen Sie die Aufskalierung ohne Standbyknoten mithilfe von Azure Storage Premium durch. Verwenden Sie das Linux-Clustering für den Failover.

• Jumpbox/Bastionhost Eine Jumpbox, die auch als Bastionhost bezeichnet wird, ist ein sicherer virtueller Computer im Netzwerk, den Sie verwenden, um eine Verbindung mit anderen VMs herzustellen. Sie wird normalerweise im Rahmen von gemeinsam genutzten Diensten wie Domänencontrollern und Sicherungsdiensten bereitgestellt. Die Jumpbox wird auf einer VM bereitgestellt, um SAP HANA Studio, SAPGUI, Dateiübertragung und andere Funktionen zu unterstützen, die normalerweise zu Installations- und Verwaltungszwecken genutzt werden. Probieren Sie Azure Bastion für RDP- (Remotedesktopprotokoll) oder SSH-Dienste (Secure Shell) aus. Wenn nur RDP und SSH für die Verwaltung genutzt werden, ist Azure Bastion eine gute Alternative. Wenn Sie andere Verwaltungstools verwenden, z. B. SQL Server Management Studio oder das SAP-Front-End, verwenden Sie eine herkömmliche selbstbereitgestellte Jumpbox.

Private DNS-Dienst.Privates DNS von Azure bietet einen zuverlässigen und sicheren DNS-Dienst für Ihr virtuelles Netzwerk. Privates Azure-DNS verwaltet Domänennamen im virtuellen Netzwerk und löst diese auf, ohne dass eine benutzerdefinierte DNS-Lösung konfiguriert werden muss.

Lastenausgleichsmodule: Zum Verteilen des Datenverkehrs auf virtuelle Computer im Subnetz der SAP-Anwendungsebene, um Hochverfügbarkeit zu erzielen, empfehlen wir die Verwendung von Azure Load Balancer Standard. Es ist wichtig zu wissen, dass Load Balancer Standard standardmäßig sicher ist und dass keine VMs, die sich hinter Load Balancer Standard befinden, über eine ausgehende Internetverbindung verfügen. Um ausgehende Internetkonnektivität auf den VMs zu aktivieren, müssen Sie Ihre Load Balancer Standard-Konfiguration aktualisieren. Für die Hochverfügbarkeit webbasierter Anwendungen verwenden Sie den integrierten SAP Web Dispatcher oder einen anderen kommerziell erhältlichen Lastenausgleich. Basieren Sie Ihre Auswahl auf Folgendes:

• Ihren Datenverkehrstyp, z. B. HTTP oder SAP-GUI.
• Die von Ihnen benötigten Netzwerkdienste, z. B. SSL-Abschluss (Secure Sockets Layer).

Load Balancer Standard unterstützt mehrere virtuelle Front-End-IP-Adressen. Diese Unterstützung ist ideal für Clusterimplementierungen, die diese Komponenten enthalten:

• Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
• Ausgewertete Belegabrechnung (Evaluated Receipt Settlement, ERS)

Diese beiden Komponenten können einen Lastenausgleich teilen, um die Lösung zu vereinfachen.

Load Balancer Standard unterstützt auch SAP-Cluster mit Multi-SID (Multi-Security Identifier). Mit anderen Worten: Mehrere SAP-Systeme unter SLES oder RHEL können sich eine gemeinsame Hochverfügbarkeitsinfrastruktur teilen, um die Kosten zu senken. Wir empfehlen Ihnen, die Kosteneinsparungen auszuwerten und nicht zu viele Systeme in einem Cluster zu platzieren. Azure unterstützt nicht mehr als fünf SIDs pro Cluster.

Application Gateway Azure Application Gateway ist ein Lastenausgleich für Webdatenverkehr, mit dem Sie den eingehenden Datenverkehr für Ihre Webanwendungen verwalten können. Herkömmliche Lastenausgleiche arbeiten auf der Transportschicht (OSI-Schicht 4 – TCP und UDP). Sie leiten den Datenverkehr auf der Grundlage der Quell-IP-Adresse und des Ports an eine Ziel-IP-Adresse und einen Port weiter. Application Gateway kann Routingentscheidungen auf Grundlage zusätzlicher Attribute einer HTTP-Anforderung treffen. Beispiele für solche Attribute wären etwa der URI-Pfad oder die Hostheader. Diese Art des Routings wird als Lastenausgleich auf Anwendungsebene (OSI-Schicht 7) bezeichnet. S/4HANA bietet Webanwendungsdienste über Fiori an. Sie können einen Lastausgleich für dieses Fiori-Front-End durchführen, das aus Web-Apps besteht, indem Sie Application Gateway verwenden.

Verfügbarkeitsgruppen: Die VMs für alle Pools und Cluster (Web Dispatcher, SAP-Anwendungsserver, Central Services und HANA) werden in getrennten Verfügbarkeitsgruppen gruppiert. Pro Rolle werden mindestens zwei VMs bereitgestellt. Verfügbarkeitsgruppen erhöhen die Verfügbarkeit von Anwendungen und VMs. Durch das Behandeln von Hostsystemfehlern und Wartungsereignissen legen Verfügbarkeitsgruppen die Verteilung von Rolleninstanzen auf mehrere Hosts fest. Eine Alternative ist die Nutzung von Verfügbarkeitszonen zur Verbesserung der Verfügbarkeit von Workloads, wie weiter unten in diesem Artikel beschrieben.

Gateway. Ein Gateway verbindet verschiedene Netzwerke und erweitert Ihr lokales Netzwerk auf ein virtuelles Azure-Netzwerk. Azure ExpressRoute ist der empfohlene Azure-Dienst für das Erstellen von privaten Verbindungen, die nicht über das öffentliche Internet verlaufen, aber Sie können auch eine Site-to-Site-Verbindung verwenden. Konnektivitätsoptionen zur Reduzierung der Latenz sind ExpressRoute Global Reach und ExpressRoute FastPath. Sie werden weiter unten in diesem Artikel beschrieben.

Zonenredundantes Gateway: Sie können ExpressRoute- oder VPN-Gateways (Virtuelles Privates Netzwerk) zonenübergreifend bereitstellen, um den Schutz vor Zonenausfällen zu ermöglichen. Bei dieser Architektur werden zonenredundante VNet-Gateways zum Erzielen von Resilienz genutzt, anstatt einer Zonenbereitstellung basierend auf derselben Verfügbarkeitszone.

Näherungsplatzierungsgruppe: Mit dieser logischen Gruppe werden VMs, die in einer Verfügbarkeitsgruppe oder einer VM-Skalierungsgruppe bereitgestellt werden, mit einer Einschränkung versehen. Eine Näherungsplatzierungsgruppe bevorzugt die Zusammenstellung, bei der VMs im selben Rechenzentrum platziert werden, um die Wartezeit für Anwendungen zu minimieren.

Netzwerksicherheitsgruppen: Um eingehenden, ausgehenden und subnetzinternen Datenverkehr in einem virtuellen Netzwerk einzuschränken, können Sie Netzwerksicherheitsgruppen erstellen.

Anwendungssicherheitsgruppen: Verwenden Sie Anwendungssicherheitsgruppen anstelle von expliziten IP-Adressen, um detaillierte Netzwerksicherheitsrichtlinien basierend auf Workloads und ausgerichtet auf Anwendungen zu definieren. Sie können VMs nach Name gruppieren und Anwendungen schützen, indem Sie Datenverkehr aus vertrauenswürdigen Segmenten Ihres Netzwerks filtern.

Azure Storage. Azure Storage bietet Datenpersistenz für einen virtuellen Computer in Form einer virtuellen Festplatte. Wir empfehlen Azure Managed Disks.

Empfehlungen

Diese Architektur beschreibt eine kleine einsatzfähige Bereitstellung für die Produktion. Die Bereitstellung hängt von den geschäftlichen Anforderungen ab, sodass diese Empfehlungen als Startpunkt dienen können.

VMs

Passen Sie in Anwendungsserverpools und -clustern die Anzahl von VMs anhand Ihrer Anforderungen an. Ausführliche Informationen zum Ausführen von SAP NetWeaver auf VMs finden Sie unter Azure Virtual Machines – Planungs- und Implementierungshandbuch. Der Leitfaden gilt auch für SAP S/4HANA-Bereitstellungen.

Ausführliche Informationen zur SAP-Unterstützung für Azure-VM-Typen und für Durchsatzmetriken (SAPS) finden Sie in SAP-Hinweis 1928533. Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto. Eine Liste mit den zertifizierten Azure-VMs für die HANA-Datenbank finden Sie im Artikel zum von SAP zertifizierten und unterstützten SAP HANA-Hardwareverzeichnis.

SAP Web Dispatcher

Die Web Dispatcher-Komponente wird für den Lastenausgleich von SAP-Datenverkehr zwischen den SAP-Anwendungsservern verwendet. Zur Erzielung von Hochverfügbarkeit für SAP Web Dispatcher wird von Azure Load Balancer entweder ein Failovercluster oder das parallele Web Dispatcher-Setup implementiert. Für Kommunikation im Internet wird eine eigenständige Lösung im Umkreisnetzwerk als Architektur empfohlen, um Sicherheitsanforderungen erfüllen zu können. Embedded Web Dispatcher auf ASCS ist eine besondere Option. Wenn Sie diese Option verwenden, sollten Sie wegen der zusätzlichen Workload für ASCS die richtige Dimensionierung auswählen.

Fiori-Front-End-Server (FES)

Diese Architektur erfüllt viele Anforderungen und setzt voraus, dass das eingebettete Fiori-FES-Modell verwendet wird. Alle Technologiekomponenten sind auf dem S/4-System selbst installiert. Dies bedeutet, dass jedes S/4-System über ein eigenes Fiori-Launchpad verfügt. Die Einrichtung der Hochverfügbarkeit für dieses Bereitstellungsmodell entspricht dem Verfahren des S/4-Systems. Es ist kein zusätzliches Clustering oder eine zusätzliche VM erforderlich. Aus diesem Grund zeigt das Architekturdiagramm die FES-Komponente nicht.

Eine Beschreibung der primären Bereitstellungsoptionen – je nach Szenario entweder eingebettet oder als Hub – finden Sie unter SAP Fiori: Bereitstellungsoptionen und Empfehlungen für die Systemlandschaft. Aus Gründen der Einfachheit und Leistung sind die Softwarereleases zwischen den Fiori-Technologiekomponenten und den S/4-Anwendungen fest gekoppelt. Dieses Setup ermöglicht eine Hubbereitstellung, die nur für wenige, eingeschränkte Anwendungsfälle geeignet ist.

Bei Verwendung der FES-Hubbereitstellung ist FES eine Add-On-Komponente für den klassischen SAP NetWeaver-ABAP-Stapel. Richten Sie die Hochverfügbarkeit genauso ein, wie Sie beim Schützen eines ABAP-Anwendungsstapels mit drei Ebenen und Cluster- oder Multihostfunktion vorgehen: Verwenden Sie eine Standbyserver-Datenbankschicht, eine ASCS-Clusterschicht mit Hochverfügbarkeits-NFS für gemeinsamen Speicher und mindestens zwei Anwendungsservern. Der Datenverkehr wird über ein Paar von Web Dispatcher-Instanzen ausgeglichen, die entweder gruppiert oder parallel betrieben werden können. Für Fiori-Apps mit Internetzugriff empfehlen wir eine FES-Hubbereitstellung im Umkreisnetzwerk. Verwenden Sie Azure Web Application Firewall auf Application Gateway als wichtige Komponente zur Abwehr von Bedrohungen. Verwenden Sie Azure AD mit SAML für die Benutzerauthentifizierung und SSO für SAP Fiori.

Einige Beispiele für den Entwurf von ein- und ausgehendem Internetzugriff finden Sie unter Eingehende und ausgehende Internetverbindungen für SAP in Azure.

Anwendungsserverpool

Zum Verwalten von Anmeldungsgruppen für ABAP-Anwendungsserver wird häufig die SMLG-Transaktion genutzt, um den Lastenausgleich für Anmeldungsbenutzer durchzuführen, SM61 für Batchservergruppen und RZ12 für RFC-Gruppen (Remote Function Call) zu verwenden usw. Diese Transaktionen verwenden die Lastausgleichsfunktion des Central Services-Nachrichtenservers, um eingehende Sitzungen oder Workloads auf den Pool von SAP-Anwendungsservern zu verteilen, die SAP GUIs und RFC-Datenverkehr verarbeiten.

SAP Central Services-Cluster

Sie können Central Services auf einer einzelnen VM bereitstellen, wenn die SLA (Service Level Agreement) für die Verfügbarkeit der Azure-Einzelinstanz-VM Ihre Anforderungen erfüllt. Allerdings wird die VM zu einem potenziellen Single Point of Failure (SPOF) für die SAP-Umgebung. Verwenden Sie für eine hochverfügbare Central Services-Bereitstellung entweder NFS über Azure Files oder den Azure NetApp Files-Dienst und einen Central Services-Cluster.

Eine weitere Möglichkeit ist die Verwendung von freigegebenen Azure-Datenträgern, um Hochverfügbarkeit zu erzielen. Unter SLES 15 SP1 und höher oder SLES für SAP-Anwendungen können Sie einen Pacemaker-Cluster mithilfe von freigegebenen Azure-Datenträgern für Linux festlegen.

Alternativ können Sie eine NFS-Dateifreigabe für freigegebenen Speicher eines Linux-Clusters verwenden.

Bei einer Azure-Bereitstellung stellen die Anwendungsserver eine Verbindung mit der hoch verfügbaren Central Services-Instanz her, indem die virtuellen Hostnamen von Central Services oder der ERS-Dienste verwendet werden. Diese Hostnamen werden der Cluster-Front-End-IP-Konfiguration des Lastenausgleichs zugewiesen. Load Balancer unterstützt mehrere Front-End-IPs, sodass die virtuellen IPs (VIPs) von Central Services und ERS für einen Lastenausgleich konfiguriert werden können.

Die Unterstützung der ASCS-Multi-SID-Installation in Azure ist jetzt allgemein verfügbar. Die Freigabe eines Verfügbarkeitsclusters für mehrere SAP-Systeme vereinfacht die SAP-Landschaft.

Verfügbarkeitsgruppen

Verfügbarkeitsgruppen verteilen Server auf verschiedene physische Infrastrukturen und Updategruppen, um die Verfügbarkeit des Diensts zu verbessern. Stellen Sie VMs, die dieselbe Funktion erfüllen, in dieselbe Verfügbarkeitsgruppe. Ein solches Setup hilft, Downtime zu vermeiden, die durch die Wartung der Azure-Infrastruktur verursacht wird. Es hilft auch bei der Einhaltung von SLAs. Um eine höhere Vereinbarung zum Servicelevel zu erfüllen, müssen Sie mindestens zwei VMs pro Verfügbarkeitsgruppe verwenden.

Alle VMs in einem Satz müssen die gleiche Rolle erfüllen. Mischen Sie keine Server mit unterschiedlichen Rollen in derselben Verfügbarkeitsgruppe. Platzieren Sie z. B. einen ASCS-Knoten nicht in der gleichen Verfügbarkeitsgruppe wie Anwendungsserver.

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

Netzwerk

Für diese Architektur wird eine Hub-Spoke-Topologie genutzt, bei der das virtuelle Hubnetzwerk als zentraler Verbindungspunkt für ein lokales Netzwerk dient. Die Spokes sind virtuelle Netzwerke mit Peeringverbindung zum Hub. Sie können die Spokes verwenden, um Workloads zu isolieren. Der Datenverkehr wird über eine Gatewayverbindung zwischen dem lokalen Rechenzentrum und dem Hub weitergeleitet.

Netzwerkschnittstellenkarten (NICs)

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. Daher ist die Nutzung von mehreren NICs aus Leistungssicht nicht erforderlich. Wenn Ihre Organisation den Datenverkehr aber aufteilen muss, können Sie mehrere NICs pro virtueller Maschine bereitstellen, jede NIC mit einem anderen Subnetz verbinden und dann Netzwerksicherheitsgruppen verwenden, um verschiedene Zugriffssteuerungsrichtlinien zu erzwingen.

Azure-NICs unterstützen mehrere IPs. Diese Unterstützung steht im Einklang mit der von SAP empfohlenen Methode, virtuelle Hostnamen für Installationen zu verwenden, wie im SAP-Hinweis 962955 dargelegt. Für den Zugriff auf SAP-Hinweise benötigen Sie ein SAP Service Marketplace-Konto.

Subnetze und Netzwerksicherheitsgruppen

In dieser Architektur wird der Adressraum des virtuellen Netzwerks in Subnetze unterteilt. Sie können jedes Subnetz einer Netzwerksicherheitsgruppe zuordnen, in der die Zugriffsrichtlinien für das Subnetz definiert sind. Platzieren Sie Anwendungsserver in einem separaten Subnetz. Hierdurch können Sie sie einfacher sichern, indem Sie die Sicherheitsrichtlinien des Subnetzes und nicht die einzelnen Server verwalten.

Wenn Sie eine Netzwerksicherheitsgruppe einem Subnetz zuordnen, gilt die Netzwerksicherheitsgruppe für alle Server innerhalb des Subnetzes und bietet eine detailliertere Steuerung der Server. Richten Sie Netzwerksicherheitsgruppen über das Azure-Portal, PowerShell oder die Azure CLI ein.

ExpressRoute Global Reach

Wenn Ihre Netzwerkumgebung zwei oder mehr ExpressRoute-Leitungen umfasst, kann Ihnen ExpressRoute Global Reach helfen, Netzwerkhops und Wartezeiten zu reduzieren. Diese Technologie ist eine Einrichtung eines Peerings der BGP-Route (Border Gateway Protocol), die zwischen zwei oder mehr ExpressRoute-Leitungen zur Überbrückung von zwei ExpressRoute-Routingdomänen eingerichtet ist. Global Reach verringert die Wartezeit, wenn der Netzwerkverkehr mehr als eine ExpressRoute-Leitung durchläuft. Es ist derzeit nur für privates Peering mit ExpressRoute-Leitungen verfügbar.

Derzeit gibt es keine Zugriffssteuerungslisten oder anderen Attribute für das Netzwerk, die in Global Reach geändert werden können. Dies bedeutet, dass alle Routen, die von einer bestimmten ExpressRoute-Leitung (lokal oder Azure) ermittelt werden, der anderen ExpressRoute-Leitung über das Leitungspeering angekündigt werden. Wir empfehlen Ihnen, die Filterung des Netzwerkdatenverkehrs lokal einzurichten, um den Zugriff auf die Ressourcen zu beschränken.

ExpressRoute FastPath

FastPath implementiert Microsoft Edge-Austausch am Einstiegspunkt des Azure-Netzwerks. Mit FastPath wird die Anzahl von Netzwerkhops für die meisten Datenpakete reduziert. Daher verringert FastPath die Netzwerklatenz und verbessert die Anwendungsleistung, und es ist die Standardkonfiguration für neue ExpressRoute-Verbindungen mit Azure.

Wenden Sie sich wegen vorhandener ExpressRoute-Leitungen an den Azure-Support, um FastPath zu aktivieren.

FastPath unterstützt kein Peering virtueller Netzwerke. Wenn andere virtuelle Netzwerke per Peering mit einem Netzwerk verbunden werden, das mit ExpressRoute verbunden ist, wird der Netzwerkdatenverkehr von Ihrem lokalen Netzwerk zu den anderen virtuellen Spoke-Netzwerken an das virtuelle Netzwerkgateway gesendet. Die Problemumgehung besteht darin, alle virtuellen Netzwerke direkt mit der ExpressRoute-Leitung zu verbinden.

Load Balancer

SAP Web Dispatcher verwaltet den Lastenausgleich von HTTP(S)-Datenverkehr in einem Pool von SAP-Anwendungsservern. Dieser Softwarelastenausgleich verfügt über Anwendungsschichtdienste (Schicht 7 im ISO-Netzwerkmodell), mit denen die SSL-Beendigung und andere Abladungsfunktionen durchgeführt werden können.

Load Balancer ist ein Dienst auf der Netzwerkübertragungsschicht (Schicht 4), der den Datenverkehr mithilfe eines aus den Datenströmen berechneten 5-Tupel-Hashs ausgleicht. Der Hash basiert auf Quell-IP, Quellport, Ziel-IP, Zielport und Protokolltyp. Load Balancer wird in Clustersetups verwendet, um den Datenverkehr im Falle eines Fehlers auf die primäre Dienstinstanz oder den fehlerfreien Knoten zu leiten. Wir empfehlen Ihnen, Azure Load Balancer Standard für alle SAP-Szenarien zu verwenden. Es ist wichtig zu wissen, dass Load Balancer Standard standardmäßig sicher ist und dass keine VMs, die sich hinter Load Balancer Standard befinden, über eine ausgehende Internetverbindung verfügen. Um ausgehende Internetkonnektivität auf den VMs zu aktivieren, müssen Sie Ihre Load Balancer Standard-Konfiguration anpassen.

Für Datenverkehr von SAP GUI-Clients, die sich über das DIAG-Protokoll oder RFC mit einem SAP-Server verbinden, verteilt der Central Services-Nachrichtenserver die Last über SAP-Anwendungsserver-Anmeldungsgruppen. Es ist kein zusätzlicher Lastenausgleich erforderlich.

Storage

Einige Kunden nutzen den Standardspeicher für ihre Anwendungsserver. Da verwaltete Standarddatenträger nicht unterstützt werden, wie in SAP-Hinweis 1928533 beschrieben ist, wird für alle Fälle die Verwendung von Premium Azure Managed Disks oder Azure NetApp Files empfohlen. Durch ein vor Kurzem durchgeführtes Update an SAP-Hinweis 2015553 wird die Verwendung von HDD Standard-Speicher und SSD Standard-Speicher für einige spezielle Anwendungsfälle nicht mehr möglich sein.

Da Anwendungsserver keine Geschäftsdaten hosten, können Sie auch die kleineren P4- und P6-Premium-Datenträger verwenden, um die Kosten zu senken. Um zu verstehen, wie sich der Speichertyp auf die SLA für die Verfügbarkeit von VMs auswirkt, lesen Sie SLA für Virtual Machines. Für Hochverfügbarkeitsszenarien sind die Features von freigegebenen Azure-Datenträgern für Azure SSD Premium und Azure Disk Storage Ultra verfügbar. Weitere Informationen finden Sie unter Verwaltete Azure-Datenträger.

Sie können freigegebene Azure-Datenträger mit Windows Server, SLES 15 SP 1 und höher oder SLES für SAP verwenden. Wenn Sie einen freigegebenen Azure-Datenträger in Linux-Clustern verwenden, dient der freigegebene Azure-Datenträger als STONITH-Blockgerät (SBD). Es bietet eine Quorumabstimmung in einer Partitionierungssituation für ein Clusternetzwerk. Dieser freigegebene Datenträger verfügt nicht über ein Dateisystem und unterstützt keine gleichzeitigen Schreibvorgänge von mehreren VMs, die Clustermitglieder sind.

Azure NetApp Files verfügt über integrierte Funktionen zur Dateifreigabe für NFS und SMB.

Für NFS-Freigabeszenarien bietet Azure NetApp Files Verfügbarkeit für NFS-Freigaben, die für /hana/shared-, /hana/data- und /hana/log-Volumes verwendet werden können. Informationen zur Verfügbarkeitsgarantie finden Sie unter SLA für Azure NetApp Files. Wenn Sie Azure NetApp Files-basierte NFS-Freigaben für die /hana/data- und /hana/log-Volumes verwenden, müssen Sie das NFS-Protokoll v4.1 verwenden. Für das Volume /hana/shared wird das NFS-Protokoll v3 unterstützt.

Für den Sicherungsdatenspeicher empfiehlt es sich, die Azure-Zugriffsebenen „Kalt“ und „Archiv“ zu verwenden. Diese Speicherebenen sind kostengünstige Möglichkeiten, langlebige Daten zu speichern, auf die eher selten zugegriffen wird. Sie können auch den Standard-Tarif von Azure NetApp Files als Sicherungsziel oder die Sicherungsoption von Azure NetApp Files Backup verwenden. Für einen verwalteten Datenträger werden als Sicherungsdatenschichten die Azure-Zugriffsebenen „Kalt“ oder „Archiv“ empfohlen.

Disk Storage Ultra und die Ultra-Leistungsstufe von Azure NetApp Files verringern die Datenträgerlatenz erheblich, wovon leistungskritische Anwendungen und SAP-Datenbankserver profitieren.

Überlegungen zur Leistung

SAP-Applikationsserver kommunizieren ständig mit den Datenbankservern. Für Anwendungen mit hohen Leistungsanforderungen, die auf einer beliebigen Datenbankplattform ausgeführt werden, einschließlich SAP HANA, sollten Sie die Schreibbeschleunigung für das Protokollvolume aktivieren, um die Latenz der Protokollschreibvorgänge zu verbessern. Die Schreibbeschleunigung ist für VMs der M-Serie verfügbar.

Um die serverübergreifende Kommunikation zu optimieren, verwenden Sie den beschleunigten Netzwerkbetrieb. Diese Option ist nur für unterstützte VMs verfügbar, z. B. D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 und Ms/Mms.

Ausführliche Informationen zu den Leistungsanforderungen von SAP HANA finden Sie unter dem SAP-Hinweis 1943937 – Tool für die Überprüfung der Hardwarekonfiguration. Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto.

Zur Erreichung eines hohen Durchsatzes in Bezug auf IOPS und die Datenträger-Bandbreite gelten für Ihr Speicherlayout die gängigen Vorgehensweisen zur Leistungsoptimierung für Speichervolumes. Wenn Sie z. B. mehrere Datenträger kombinieren, um ein Stripeset-Datenträgervolume zu erstellen, können Sie die E/A-Leistung verbessern. Durch Aktivieren des Lesecaches für Speicherinhalte, die sich in unregelmäßigen Abständen ändern, können Sie eine höhere Geschwindigkeit beim Datenabruf erreichen. Empfehlungen zu Speicherkonfigurationen für verschiedene VM-Größen, wenn Sie SAP HANA ausführen, finden Sie unter SAP HANA: Speicherkonfigurationen für virtuelle Azure-Computer.

Disk Storage Ultra stellt eine neue Generation von Speicher dar, um hohe IOPS-Anforderungen und die Anforderungen an die Übertragungsbandbreite von Anwendungen, z. B. SAP HANA, zu erfüllen. Sie können die Leistung von Ultra-Datenträgern dynamisch ändern und Metriken wie IOPS und MB/s separat konfigurieren, ohne Ihre VM neu zu starten. Wenn Disk Storage Ultra verfügbar ist, empfehlen wir Disk Storage Ultra (SSD Ultra) anstelle der Schreibbeschleunigung.

Einige SAP-Anwendungen müssen häufig mit der Datenbank kommunizieren. Die Netzwerklatenz zwischen der Anwendung und den Datenbankschichten kann sich aufgrund der Entfernung negativ auf die Anwendungsleistung auswirken. Bei Azure-Näherungsplatzierungsgruppen wird eine Platzierungseinschränkung für VMs festgelegt, die in Verfügbarkeitsgruppen bereitgestellt werden. Im logischen Konstrukt einer Gruppe haben die „Zusammenstellung“ (Co-location) und die Leistung Vorrang vor Skalierbarkeit, Verfügbarkeit und Kosten. Näherungsplatzierungsgruppen können eine deutliche Verbesserung der Benutzererfahrung für die meisten SAP-Anwendungen bewirken. Weitere Informationen zu Skripts und Hilfsprogrammen, die auf GitHub für Näherungsplatzierungsgruppen verfügbar sind, finden Sie unter Azure-Näherungsplatzierungsgruppen.

Wir empfehlen, dass Sie kein virtuelles Netzwerkgerät (NVA) zwischen der Logikschicht und der Datenbankschicht eines SAP-Anwendungsstapels platzieren. Die NVA benötigt eine beträchtliche Zeit, um Datenpakete zu verarbeiten. Infolgedessen wird die Leistung der Anwendung inakzeptabel verlangsamt.

Wir empfehlen Ihnen auch, beim Bereitstellen von Ressourcen mit Verfügbarkeitszonen die Leistung zu berücksichtigen, um die Dienstverfügbarkeit zu verbessern. Dies ist weiter unten in diesem Artikel beschrieben. Erwägen Sie, zwischen allen Zonen einer Zielregion ein eindeutiges Netzwerklatenzprofil zu erstellen. Dieser Ansatz erleichtert Ihnen die Entscheidung über die Platzierung von Ressourcen mit dem Ziel, die Wartezeit zwischen den Zonen möglichst gering zu halten. Führen Sie zum Erstellen dieses Profils einen Test durch, indem Sie in jeder Zone kleinere VMs bereitstellen. Empfohlene Tools für den Test sind beispielsweise PsPing und Iperf. Nach dem Testen entfernen Sie diese VMs. Ein Tool zum Testen der Wartezeit im Netzwerk der öffentlichen Domäne, das Sie stattdessen verwenden können, finden Sie unter Test der Latenz der Verfügbarkeitszonen.

Azure NetApp Files verfügt über einzigartige Leistungsfeatures, die eine Echtzeitoptimierung ermöglichen, die die Anforderungen der anspruchsvollsten SAP-Umgebungen erfüllt. Informationen zu Leistungsüberlegungen, die Sie bei der Verwendung von Azure NetApp Files beachten sollten, finden Sie unter Größenanpassung für eine HANA-Datenbank in Azure NetApp Files.

Überlegungen zur Skalierbarkeit

Auf der SAP-Anwendungsschicht sind in Azure viele verschiedene VM-Größen für Hochskalieren und Aufskalieren verfügbar. Eine umfassende Liste finden Sie im SAP-Hinweis 1928533: „SAP-Anwendungen in Azure: Unterstützte Produkte und Azure-VM-Typen“. Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto. Es werden laufend weitere VM-Typen zertifiziert, sodass Sie in derselben Cloudbereitstellung hoch- oder herunterskalieren können.

Auf der Datenbankschicht werden mit dieser Architektur SAP HANA S/4-Anwendungen auf Azure-VMs ausgeführt, die schnell auf bis zu 12 Terabyte (TB) hochskaliert werden können. Wenn Ihre Workload die maximale VM-Größe überschreitet, können Sie die großen Azure-Instanzen für SAP HANA nutzen. Bei dieser Option liegt die Kapazität bei weit über 12 TB RAM. Revision 4-Instanzen dieser physischen Server befinden sich in einem Microsoft Azure-Rechenzentrum. Sie stellen bis zu 24 TB Speicherkapazität für eine einzelne Instanz bereit. Es ist auch eine Konfiguration mit mehreren Knoten möglich. Sie verfügt über eine Gesamtspeicherkapazität von bis zu 24 TB für OLTP-Anwendungen (Onlinetransaktionsverarbeitung) und 60 TB für OLAP-Anwendungen (Analytische Onlineverarbeitung).

Überlegungen zur Verfügbarkeit

Ressourcenredundanz ist das allgemeine Thema bei hochverfügbaren Infrastrukturlösungen. Die verschiedenen Speichertypen zugeordneten SLAs für die Verfügbarkeit von Einzelinstanz-VMs finden Sie unter SLA für Virtual Machines. Wenn Sie redundante Ressourcen in einer Verfügbarkeitsgruppe oder übergreifend in Verfügbarkeitszonen bereitstellen, erhöht sich die Dienstverfügbarkeit.

Bei dieser verteilten Installation der SAP-Anwendung wird die Basisinstallation repliziert, um Hochverfügbarkeit zu erzielen. Der Entwurf für die Hochverfügbarkeit variiert für jede Ebene der Architektur.

Web Dispatcher auf Anwendungsserverschicht

Sie können Hochverfügbarkeit erreichen, indem Sie redundante Web Dispatcher-Instanzen verwenden. Weitere Informationen finden Sie unter SAP Web Dispatcher in der SAP-Dokumentation. Der Verfügbarkeitsgrad hängt von der Größe der Anwendung ab, die hinter Web Dispatcher steht. Bei kleinen Bereitstellungen mit wenig Skalierbarkeitsproblemen können Sie den Web Dispatcher mit den ASCS-VMs zusammenstellen. Auf diese Weise sparen Sie bei der unabhängigen Wartung des Betriebssystems und erreichen gleichzeitig die Hochverfügbarkeit.

Central Services auf Anwendungsserverschicht

Für die Hochverfügbarkeit von Central Services auf Azure-VMs in Linux verwenden Sie die entsprechende Hochverfügbarkeitserweiterung für die ausgewählte Linux-Distribution. Es ist üblich, die freigegebenen Dateisysteme mithilfe von SUSE DRBD oder Red Hat GlusterFS in hochverfügbarem NFS-Speicher zu platzieren. Um ein hochverfügbares NFS bereitzustellen und die Notwendigkeit eines NFS-Clusters zu eliminieren, können Sie stattdessen andere kostengünstige oder robuste Lösungen wie NFS über Azure Files oder Azure NetApp Files verwenden. Nebenbei bemerkt können Azure NetApp Files-Freigaben die SAP HANA-Daten und -Protokolldateien hosten. Dieses Setup ermöglicht das Bereitstellungsmodell für die horizontale HANA-Skalierung mit Standbyknoten, während NFS über Azure Files für die hochverfügbare Freigabe von Nicht-Datenbankdateien geeignet ist.

NFS über Azure Files unterstützt jetzt die hochverfügbaren Dateifreigaben sowohl für SLES als auch für RHEL. Diese Lösung eignet sich gut für hochverfügbare Dateifreigaben wie die von /sapmnt, /saptrans in SAP-Installationen.

Azure NetApp Files unterstützt die Hochverfügbarkeit von ASCS in SLES. Ausführliche Informationen zu ASCS unter RHEL-Hochverfügbarkeit finden Sie unter SIOS Protection Suite für Linux.

Der verbesserte Azure-Fence-Agent ist sowohl für SUSE als auch für Red Hat verfügbar und ermöglicht ein deutlich schnelleres Failover von Diensten als die vorherige Version des Agents.

Eine weitere Möglichkeit ist die Verwendung von freigegebenen Azure-Datenträgern, um Hochverfügbarkeit zu erzielen. Unter SLES 15 SP 1 und höher oder SLES für SAP können Sie einen Pacemaker-Cluster mithilfe von freigegebenen Azure-Datenträgern einrichten, um Hochverfügbarkeit zu erreichen.

Unter Azure Load Balancer Standard können Sie den Hochverfügbarkeitsport aktivieren und vermeiden, dass Lastenausgleichsregeln für viele SAP-Ports konfiguriert werden müssen. Wenn Sie beim Einrichten eines Lastenausgleichs das Feature „Direct Server Return“ (DSR) aktivieren, können Serverantworten auf Clientanfragen den Lastenausgleich umgehen. Dieses Feature wird auch als „Floating IP“ bezeichnet. Der Lastenausgleich kann lokal oder in Azure erfolgen. Diese direkte Verbindung verhindert, dass der Lastenausgleich zum Engpass auf dem Datenübertragungspfad wird. Für die ASCS- und HANA DB-Cluster empfehlen wir, dass Sie DSR aktivieren. Wenn für VMs im Back-End-Pool die öffentliche Konnektivität in ausgehender Richtung erforderlich ist, müssen weitere Konfigurationsschritte ausgeführt werden.

Für Datenverkehr von SAP GUI-Clients, die sich über das DIAG-Protokoll oder RFC mit einem SAP-Server verbinden, verteilt der Central Services-Nachrichtenserver die Last über SAP-Anwendungsserver-Anmeldungsgruppen. Es ist kein zusätzlicher Lastenausgleich erforderlich.

Anwendungsserver auf der Anwendungsserverschicht

Sie können die Hochverfügbarkeit erzielen, indem für Datenverkehr in einem Pool mit Anwendungsservern ein Lastenausgleich durchgeführt wird.

Datenbankschicht

Die Architektur in diesem Leitfaden stellt ein hochverfügbares SAP HANA-Datenbanksystem dar, das aus zwei Azure-VMs besteht. Die native Systemreplikationsfunktion der Datenbankschicht bietet entweder manuelles oder automatisches Failover zwischen replizierten Knoten:

• Für ein manuelles Failover stellen Sie mindestens eine HANA-Instanz bereit und verwenden HSR.
• Verwenden Sie für automatisches Failover sowohl HSR als auch Linux HAE (High Availability Extension. Hochverfügbarkeitserweiterung) für Ihre Linux-Distribution. Linux HAE stellt die Clusterdienste für die HANA-Ressourcen bereit, die Fehlerereignisse erkennen und das Failover von fehlerhaften Diensten auf den fehlerfreien Knoten organisieren.
• Ähnlich wie bei der Anwendungsserverschicht wird als HANA-Hochverfügbarkeitslösung für SLES normalerweise Pacemaker bereitgestellt. Für RHEL ist es SIOS LifeKeeper.

Bereitstellen von VMs über Verfügbarkeitszonen hinweg

Verfügbarkeitszonen können die Dienstverfügbarkeit verbessern. Zonen sind physisch getrennte Orte innerhalb einer bestimmten Azure-Region. Sie werden genutzt, um die Verfügbarkeit von Workloads zu verbessern und Anwendungsdienste und VMs vor Rechenzentrumsausfällen zu schützen. Virtuelle Computer in einer Zone werden so behandelt, als ob sie sich in einer einzelnen Update- oder Fehlerdomäne befinden würden. Wenn die Zonenbereitstellung ausgewählt wurde, werden die VMs in derselben Zone auf bestmögliche Weise auf Fehler- und Upgradedomänen verteilt.

In Azure-Regionen, die dieses Feature unterstützen, sind mindestens drei Zonen verfügbar. Der maximale Abstand zwischen Rechenzentren in diesen Zonen ist allerdings nicht garantiert. Für die zonenübergreifende Bereitstellung eines SAP-Systems mit mehreren Ebenen müssen Sie die Netzwerklatenz innerhalb einer Zone und für die Zielzonen kennen und wissen, wie empfindlich Ihre bereitgestellten Anwendungen in Bezug auf die Netzwerklatenz sind.

Berücksichtigen Sie diese Überlegungen, wenn Sie sich für die Bereitstellung von Ressourcen über Verfügbarkeitszonen hinweg entscheiden:

• Wartezeit zwischen VMs in einer Zone
• Wartezeit zwischen VMs in ausgewählten Zonen
• Verfügbarkeit der gleichen Azure-Dienste (VM-Typen) in den ausgewählten Zonen

Beispiel für Aktiv/Passiv-Bereitstellung

Bei dieser Beispielbereitstellung bezieht sich der Aktiv/Passiv-Status auf den Status des Anwendungsdiensts in den Zonen. Auf der Anwendungsschicht sind alle vier aktiven Anwendungsserver des SAP-Systems in Zone 1 enthalten. Eine weitere Gruppe mit vier passiven Anwendungsservern wird in Zone 2 erstellt, dann aber heruntergefahren. Sie werden nur aktiviert, wenn sie benötigt werden.

Die Cluster mit zwei Knoten für Central Services und die Datenbank sind auf zwei Zonen verteilt. Falls Zone 1 ausfällt, werden Central Services und die Datenbankdienste in Zone 2 ausgeführt. Die passiven Anwendungsserver in Zone 2 werden aktiviert. Da sich alle Komponenten dieses SAP-Systems in derselben Zone befinden, wird die Netzwerklatenz verringert.

Beispiel für Aktiv/Aktiv-Bereitstellung

Bei einer Aktiv/Aktiv-Bereitstellung werden zwei Gruppen mit Anwendungsservern in zwei Zonen erstellt. In jeder Zone sind jeweils zwei Anwendungsserver in jedem Satz inaktiv oder heruntergefahren. Es befinden sich also in beiden Zonen aktive Anwendungsserver im Normalbetrieb.

ASCS und die Datenbankdienste werden in Zone 1 ausgeführt. Die Anwendungsserver in Zone 2 verfügen aufgrund der physischen Entfernung zwischen den Zonen ggf. über eine höhere Netzwerklatenz beim Herstellen der Verbindung mit ASCS und den Datenbankdiensten.

Wenn Zone 1 in den Offlinezustand versetzt wird, erfolgt für ASCS und die Datenbankdienste ein Failover in Zone 2. Die ruhenden Anwendungsserver können in den Onlinezustand versetzt werden, um die vollständige Kapazität für die Anwendungsverarbeitung bereitzustellen.

Überlegungen zur Notfallwiederherstellung

Für jede Ebene im SAP-Anwendungsstapel wird ein anderer Ansatz genutzt, um den Schutz per Notfallwiederherstellung bereitzustellen.

Anwendungsserverschicht

SAP-Anwendungsserver enthalten keine Geschäftsdaten. In Azure besteht eine einfache Strategie für die Notfallwiederherstellung darin, SAP-Anwendungsserver in der sekundären Region zu erstellen und die Server dann herunterzufahren. Bei Konfigurationsänderungen oder Kernel-Updates auf dem primären Anwendungsserver müssen die gleichen Änderungen auf den VMs in der sekundären Region angewendet werden. Sie müssen z. B. die ausführbaren Dateien des SAP-Kernels auf die VMs für die Notfallwiederherstellung kopieren.

Sie können Azure Site Recovery auch verwenden, um die Notfallwiederherstellung für die Bereitstellung einer SAP NetWeaver-Anwendung mit mehreren Ebenen einzurichten.

Central Services

Wie die Anwendungsserver behält auch diese Komponente des SAP-Anwendungsstapels keine Geschäftsdaten bei. Sie können einen virtuellen Computer in der Region für die Notfallwiederherstellung erstellen, um die Central Services-Rolle auszuführen.

Die globalen ASCS-Hostdateien, d h. die /sapmnt-Freigabe, werden in der Regel entweder über NFS über Azure Files oder Azure NetApp Files bereitgestellt. Zum Schutz dieser Inhalte, wenn Sie NFS über Azure Files verwenden, verwenden Sie ein benutzerdefiniertes Replikationsskript, z. B. „rsync“. Dieses Skript wird zeitgesteuert ausgeführt und kopiert Inhalte auf eine andere Dateifreigabe in der Region für die Notfallwiederherstellung. Wenn Sie Azure NetApp Files verwenden, verwenden Sie sein natives Feature zur regionsübergreifenden Replikation, um Inhalte für die /sapmnt-Freigabe des SAP-Systems für die Notfallwiederherstellung zu replizieren.

Site Recovery unterstützt die Replikation von STONITH-Geräten, die mit iSCSI-Zielen erstellt werden.

Sie können Site Recovery nutzen, um die beiden Betriebssystemlaufwerke der Central Services-Server in der Region für die Notfallwiederherstellung zu replizieren.

Eine Schritt-für-Schritt-Anleitung finden Sie unter Entwickeln einer Notfallwiederherstellungslösung für SAP mit Azure Site Recovery.

Datenbankschicht

Verwenden Sie HSR für HANA-unterstützte Replikation. Zusätzlich zu einer lokalen Hochverfügbarkeitseinrichtung mit zwei Knoten unterstützt HSR eine mehrstufige Replikation, bei der ein dritter Knoten in einer separaten Azure-Region als fremde Entität fungiert, die nicht Teil des Clusters ist. Dieser dritte Knoten registriert sich bei dem sekundären Replikat des geclusterten HSR-Paares als Replikationsziel. Dieses Setup bildet eine Replikationsverkettung.

Das Failover zum Notfallwiederherstellungsknoten ist ein manueller Prozess. Mit HANA 2.0 SPS 03 und höher ist es möglich, eine Systemreplikation mit mehreren Zielen zu konfigurieren. Hierbei werden zusätzliche Replikate unterstützt, indem der Primärknoten asynchron in der Region für die Notfallwiederherstellung repliziert wird. Verwenden Sie außerdem rsync oder ein anderes Tool für die Inhaltsreplikation Ihrer Wahl, falls Sie Azure NetApp Files für Central Services oder die HANA-Datenbankschicht einsetzen.

Notfallwiederherstellung für gemeinsame Dienste

Viele IT-Dienste werden von Ihren gesamten bereitgestellten Cloudressourcen gemeinsam verwendet, z. B. Jumpboxes für die Verwaltung, cloudbasierte Verzeichnis-, Sicherungs- und Überwachungsdienste. Replizieren Sie Ihre gemeinsamen Dienste in der Region für die Notfallwiederherstellung, indem Sie die Mittel des jeweiligen Diensts nutzen.

Automatisierte Notfallwiederherstellung mit Site Recovery

Um Site Recovery für die automatische Erstellung eines vollständig replizierten Produktionsstandorts Ihrer Originalkonfiguration zu erstellen, müssen Sie benutzerdefinierte Bereitstellungsskripts ausführen. Beispielsweise stellt Site Recovery zunächst die VMs in Verfügbarkeitsgruppen bereit. Dann führt es Ihre benutzerdefinierten Skripts aus, um den vorhandenen (vordefinierten) Lastenausgleich, für den der Back-End-Pool bereits definiert ist, mit der Netzwerkschnittstelle der Failover-VMs zu verbinden. Ein Beispiel auf GitHub für ein benutzerdefiniertes Site Recovery Automation Runbooks-Skript finden Sie unter Azure Site Recovery Runbooks.

Kostenbetrachtung

Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln.

Weitere Informationen finden Sie im Abschnitt zu Kosten im Microsoft Azure Well-Architected Framework.

VMs

In dieser Architektur werden VMs mit Linux für die Logikschicht und die Datenbankschicht verwendet. Auf der SAP NetWeaver-Schicht werden Windows-VMs verwendet, um SAP-Dienste und -Anwendungen auszuführen. Auf der Datenbankschicht wird AnyDB als Datenbank ausgeführt, z. B. Microsoft SQL Server, Oracle oder IBM DB2. Virtuelle Computer werden auch als Jumpboxes für die Verwaltung verwendet.

Im Allgemeinen gibt es für VMs mehrere Zahlungsoptionen:

• Für Workloads, bei denen der Zeitpunkt des Abschlusses oder der Ressourcenverbrauch nicht vorhersehbar ist, bietet sich die nutzungsbasierte Bezahlung an.

• Verwenden Sie Azure-Reservierungen, wenn Sie die Nutzung einer VM über einen Zeitraum von einem Jahr oder drei Jahren verbindlich zusagen können. VM-Reservierungen können Kosten erheblich reduzieren. Sie zahlen vielleicht nur 72 Prozent der Kosten eines Diensts mit nutzungsbasierter Bezahlung.

• Verwenden Sie Azure-Spot-VMs zum Ausführen von Workloads, die unterbrochen werden können und nicht innerhalb eines vordefinierten Zeitrahmens oder einer SLA abgeschlossen werden müssen. Azure stellt Spot-VMs bereit, wenn Kapazität verfügbar ist, und entfernt sie, wenn die Kapazität wieder benötigt wird. Die mit Spot-VMs verbundenen Kosten sind niedriger als bei anderen VMs. Spot-VMs bieten sich für die folgenden Workloads an:

  • High-Performance Computing, Batchverarbeitungsaufträge oder visuelle Renderinganwendungen
  • Testumgebungen, einschließlich Continuous Integration- und Continuous Delivery-Workloads
  • Umfangreiche zustandslose Anwendungen

Weitere Informationen finden Sie unter Virtuelle Linux-Computer – Preise.

VMs und Verfügbarkeitsgruppen

Für alle Pools und Cluster (Web Dispatcher, SAP-Anwendungsserver, Central Services und HANA) werden VMs in getrennten Verfügbarkeitsgruppen gruppiert. Eine Verfügbarkeitsgruppe verursacht keine Kosten. Sie zahlen nur für jede VM-Instanz, die Sie erstellen.

Load Balancer

In diesem Szenario werden Azure Load Balancer-Instanzen verwendet, um Datenverkehr auf VMs im Logikschichtsubnetz zu verteilen.

Die Gebühren werden nur anhand der Anzahl von konfigurierten Lastenausgleichsregeln und Ausgangsregeln berechnet. Die Regeln für eingehende Netzwerkadressenübersetzung (NAT) sind kostenlos. Für Load Balancer Standard fallen keine Kosten auf Stundenbasis an, wenn keine Regeln konfiguriert sind.

ExpressRoute

Bei dieser Architektur ist ExpressRoute der Netzwerkdienst, der zum Erstellen von privaten Verbindungen zwischen einem lokalen Netzwerk und virtuellen Azure-Netzwerken verwendet wird.

Alle eingehenden Datenübertragungen sind kostenlos. Für alle ausgehenden Datenübertragungen wird eine vorab festgelegte Rate berechnet. Weitere Informationen finden Sie unter Azure ExpressRoute – Preise.

Aspekte der Verwaltung und des Betriebs

Damit Ihr System in der Produktion ausgeführt werden kann, sollten Sie die folgenden Punkte beachten.

Backup

Sie können SAP HANA-Daten auf viele Arten sichern. Verwenden Sie nach der Migration zu Azure weiterhin alle vorhandenen Lösungen zur Sicherung, über die Sie bereits verfügen. In Azure gibt es zwei native Ansätze für Sicherungen. Sie können SAP HANA auf VMs sichern oder Azure Backup auf Dateiebene verwenden. Azure Backup verfügt über eine BackInt-Zertifizierung von SAP. Weitere Informationen finden Sie unter Azure Backup – häufig gestellte Fragen.

Identitätsverwaltung

Verwenden Sie ein zentrales Identitätsverwaltungssystem, um den Zugriff auf Ressourcen auf allen Ebenen zu steuern:

• Stellen Sie Zugriff auf Azure-Ressourcen über die rollenbasierte Zugriffssteuerung in Azure (Azure RBAC) bereit.

• Gewähren Sie den Zugriff auf Azure-VMs per Lightweight Directory Access Protocol (LDAP), Azure Active Directory (Azure AD), Kerberos oder mit einem anderen System.

• Ermöglichen Sie Zugriff in den Apps selbst über die Dienste, die SAP bereitstellt, oder verwenden Sie OAuth 2.0 und Azure AD.

Überwachung

Verwenden Sie Azure Monitor zum Maximieren der Verfügbarkeit und Leistung Ihrer Anwendungen und Dienste. Dies ist eine umfassende Lösung für das Sammeln, Analysieren und Reagieren auf Telemetriedaten aus Ihren cloudbasierten und lokalen Umgebungen. In Azure Monitor wird angezeigt, welche Leistung Ihre Anwendungen aufweisen. Es werden proaktiv Probleme erkannt, die sie und die Ressourcen, von denen sie abhängen, betreffen.

Verwenden Sie die Azure-Erweiterung für die „Erweiterte Überwachung“ von SAP, um die SAP-basierte Überwachung von Ressourcen und Leistung von Diensten für die SAP-Infrastruktur durchzuführen. 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“. Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto.

Sicherheitshinweise

SAP verfügt ü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. Ausführliche Informationen finden Sie unter SAP HANA-Sicherheit – Eine Übersicht.

Um die Netzwerksicherheit zu verbessern, sollten Sie ein Umkreisnetzwerk verwenden, das eine NVA verwendet, um eine Firewall vor dem Subnetz für Web Dispatcher und die Fiori-Front-End-Serverpools zu erstellen. Die Kosten für die Datenübertragung sind ein Grund dafür, aktive Front-End-Server, die Fiori-Apps ausführen, in dasselbe virtuelle Netzwerk wie die S/4-Systeme zu stellen. Die Alternative ist, sie im Umkreisnetzwerk zu platzieren und sie über das Peering virtueller Netzwerke mit S/4 zu verbinden.

Um die Sicherheit der Infrastruktur zu gewährleisten, sind die Daten während der Übertragung und im Ruhezustand verschlüsselt. Der Abschnitt „Sicherheitshinweise“ im SAP NetWeaver in Azure Virtual Machines – Planungs- und Implementierungshandbuch enthält Informationen zur Netzwerksicherheit, die für S/4HANA gelten. In diesem Artikel sind auch die Netzwerkports angegeben, die Sie in den Firewalls öffnen, um die Anwendungskommunikation zu ermöglichen.

Zum Verschlüsseln von Datenträgern von Linux-VMs stehen Ihnen verschiedene Optionen zur Verfügung, die unter Übersicht über die Datenträgerverschlüsselung beschrieben sind. Für die SAP HANA-Verschlüsselung von ruhenden Daten empfehlen wir die Verwendung der nativen SAP HANA-Verschlüsselungstechnologie. Informationen zur Unterstützung von Azure Disk Encryption für bestimmte Linux-Distributionen, -Versionen und -Images finden Sie unter Azure Disk Encryption für Linux-VMs.

Für die SAP HANA-Verschlüsselung von ruhenden Daten empfehlen wir die Verwendung der nativen SAP HANA-Verschlüsselungstechnologie.

Communitys

Communitys können Fragen beantworten und Sie beim Einrichten einer erfolgreichen Bereitstellung unterstützen. Beachten Sie diese Ressourcen:

• Running SAP Applications on the Microsoft Platform (Blog)
• Azure-Communitysupport
• SAP Community
• Stack Overflow SAP

Beitragende

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

Hauptautor:

• Ben Trinh | Principal Architect

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

Nächste Schritte

Weitere Informationen und Beispiele für SAP-Workloads, für die einige derselben Technologien wie für diese Architektur verwendet werden, finden Sie in diesen Artikeln:

• Bereitstellen von SAP S/4HANA oder BW/4HANA in Azure
• Azure Virtual Machines – Planung und Implementierung für SAP NetWeaver
• Verwenden von Azure zum Hosten und Ausführen von SAP-Workloadszenarien

Zugehörige Ressourcen

• Ausführen von SAP-Produktionsworkloads mit einer Oracle Database-Instanz in Azure
• Entwicklungs- und Testumgebungen für SAP-Workloads in Azure