SAP S/4HANA unter Linux in Azure

Bastion
ExpressRoute
Load Balancer
SAP HANA in Azure (große Instanzen)
Storage
Virtual Machines
Virtual Network

Anhand dieser Referenzarchitektur 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 in Azure unterstützt. Die Fiori-Informationen gelten nur für S/4HANA-Anwendungen.

Referenzarchitektur für SAP S/4HANA für virtuelle Linux-Computer in Azure

Laden Sie eine Visio-Datei dieser Architektur herunter.

Hinweis

Zum Bereitstellen dieser Referenzarchitektur ist eine geeignete Lizenzierung von SAP-Produkten und anderen nicht von Microsoft stammenden Technologiekomponenten erforderlich.

Aufbau

Diese Referenzarchitektur beschreibt ein gängiges Produktionssystem. Die Architektur wird mit VM-Größen bereitgestellt, die an die Anforderungen Ihres Unternehmens angepasst werden können. Um Ihren Geschäftsanforderungen gerecht zu werden, kann diese Konfiguration bis hin zu einem einzigen virtuellen Computer reduziert werden.

Das Netzwerklayout wurde stark vereinfacht, um die Architekturprinzipale zu demonstrieren, und es dient nicht dazu, ein gesamtes Unternehmensnetzwerk zu beschreiben.

Hierfür sind die folgenden Komponenten erforderlich:

Azure Virtual Network. Der Dienst Azure Virtual Network (VNET) verbindet Azure-Ressourcen sicher miteinander. In dieser Architektur wird ein VNET über ein Gateway mit einer lokalen Umgebung verbunden, und dieses Gateway wird im Hub einer Hub-Spoke-Topologie bereitgestellt. Die „Speiche“ (Spoke) ist das VNET, 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 unter 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 gemeinsame Dienste (z. B. Jumpbox und Active Directory).

Virtuelle Computer: In dieser Architektur werden virtuelle Computer mit Linux für die Logikschicht und die Datenbankschicht verwendet, die wie folgt gruppiert sind:

  • Anwendungsschicht: Umfasst den Fiori Front-End-Serverpool, den SAP Web Dispatcher-Pool, den Anwendungsserverpool und den SAP Central Services-Cluster. Zur Erzielung von Hochverfügbarkeit für Central Services in Azure bei Ausführung auf virtuellen Linux-Computern ist ein hoch verfügbarer Netzwerkdateifreigabe-Dienst erforderlich, z. B. Azure NetApp Files, NFS-Clusterserver (Network File Shares) oder SIOS DataKeeper. Zum Einrichten einer hoch verfügbaren Dateifreigabe für den Central Services-Cluster unter Red Hat Enterprise Linux, kann GlusterFS auf virtuellen Azure-Computern konfiguriert werden, auf denen Red Hat Enterprise Linux ausgeführt wird. Unter SUSE Linux Enterprise Server 15 SP1 und höheren Versionen oder SuSE Linux Enterprise Server 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 Umgrenzungsmechanismus muss verwendet werden, um sicherzustellen, dass das ausgefallene System isoliert oder heruntergefahren wird, um den Split-Brain-Zustand für Cluster zu vermeiden. Bei HANA-Bereitstellungen mit horizontaler Hochskalierung wird die Hochverfügbarkeit von Datenbanken erzielt, indem Standbyknoten konfiguriert werden, ohne dass die Linux-Clusteringkomponente benötigt wird.

  • Jumpbox: Wird auch als „Bastionhost“ bezeichnet. Dieser sichere virtuelle Computer im Netzwerk wird verwendet, um eine Verbindung mit anderen virtuellen Computern herzustellen. Normalerweise wird er als Teil der gemeinsamen Dienste, z. B. Domänencontroller und Sicherungsdienste, bereitgestellt. Die Jumpbox wird auf einem virtuellen Computer 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.

Lastenausgleichsmodule: Lastenausgleichsmodule werden verwendet, um Datenverkehr auf virtuelle Computer im Logikschichtsubnetz zu verteilen. Nutzen Sie Load Balancer Standard, wenn Sie Azure-Zonen verwenden. Es ist wichtig, hervorzuheben, dass der Load Balancer Standard standardmäßig sicher ist, und dass keine virtuellen Computer hinter dem Load Balancer Standard über ausgehende Internetkonnektivität verfügen. Um ausgehende Internetkonnektivität auf den virtuellen Computern zu aktivieren, müssen Sie Ihre Load Balancer Standard-Konfiguration berücksichtigen. Verwenden Sie zum Erzielen von Hochverfügbarkeit den integrierten SAP Web Dispatcher, Azure Load Balancer oder einen anderen Mechanismus. Dies richtet sich nach dem Datenverkehrstyp (z. B. HTTP oder SAP GUI) oder den erforderlichen Netzwerkdiensten, z. B. der SSL-Beendigung (Secure Sockets Layer).

Verfügbarkeitsgruppen: Virtuelle Computer für alle Pools und Cluster (Web Dispatcher, SAP-Anwendungsserver, Central Services und HANA) werden in getrennten Verfügbarkeitsgruppen gruppiert, und pro Rolle werden mindestens zwei virtuelle Computer bereitgestellt. Mit Verfügbarkeitsgruppen wird die Verfügbarkeit der Anwendungen und virtuellen Computer über die Verwaltung von Hostsystemfehlern oder Wartungsereignissen erhöht, indem Rolleninstanzen auf mehrere Hosts verteilt werden. Eine Alternative ist die Nutzung von Verfügbarkeitszonen zur Verbesserung der Verfügbarkeit von Workloads. Dies ist weiter unten in diesem Artikel beschrieben.

Zonenredundantes Gateway: Azure ExpressRoute- oder VPN-Gateways (Virtuelles Privates Netzwerk) können zonenübergreifend bereitgestellt werden, 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. Für eine Näherungsplatzierungsgruppe wird meist die „Zusammenstellung“ (Co-location) genutzt. Dies bedeutet, dass virtuelle Computer in demselben Rechenzentrum angeordnet sind, um die Anwendungslatenz zu verringern.

Netzwerksicherheitsgruppen: Um eingehenden, ausgehenden und subnetzinternen Datenverkehr im virtuellen Netzwerk einzuschränken, können Sie Netzwerksicherheitsgruppen (NSGs) 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 virtuelle Computer nach Name gruppieren und Anwendungen schützen, indem Sie Datenverkehr aus vertrauenswürdigen Segmenten Ihres Netzwerks filtern.

Gateway: Mit einem Gateway werden einzelne Netzwerke verbunden, um Ihr lokales Netzwerk auf das Azure-VNET zu erweitern. ExpressRoute ist der empfohlene Azure-Dienst für das Erstellen von privaten Verbindungen, die nicht über das öffentliche Internet verlaufen, aber es kann auch eine Site-to-Site-Verbindung verwendet werden. Konnektivitätsoptionen zur Reduzierung der Latenz sind ExpressRoute Global Reach und ExpressRoute FastPath. Sie werden weiter unten in diesem Artikel beschrieben.

Azure Storage: Dient zum Erzielen von Datenpersistenz für einen virtuellen Computer in Form einer virtuellen Festplatte (VHD). Die Verwendung eines verwalteten Azure-Datenträgers wird empfohlen.

Empfehlungen

Diese Architektur beschreibt eine kleine einsatzfähige Bereitstellung für die Produktion. Ihre Bereitstellung unterscheidet sich je nach Ihren geschäftlichen Anforderungen. Sie sollten diese Empfehlungen also lediglich als Ausgangsbasis betrachten.

Virtuelle Computer

Passen Sie in Anwendungsserverpools und -clustern die Anzahl von virtuellen Computern anhand Ihrer Anforderungen an. Die Anleitung zur Planung und Implementierung von virtuellen Azure-Computern enthält Informationen über das Ausführen von SAP NetWeaver auf virtuellen Computern. Diese Informationen gelten auch für die SAP S/4HANA-Bereitstellung.

Ausführliche Informationen zur SAP-Unterstützung für die Typen virtueller Azure-Computer und die Durchsatzmetriken (SAPS) finden Sie in der SAP Note 1928533. (Zum Zugreifen auf SAP-Hinweise müssen Sie über ein SAP Service Marketplace-Konto verfügen.) Im Artikel zum von SAP zertifizierten und unterstützten SAP HANA-Hardwareverzeichnis finden Sie eine Liste mit den zertifizierten virtuellen Azure-Computern für die HANA-Datenbank.

SAP Web Dispatcher

Die Web Dispatcher-Komponente wird als Lastenausgleichsmodul für SAP-Datenverkehr zwischen den SAP-Anwendungsservern verwendet. Zur Erzielung von Hochverfügbarkeit für SAP Web Dispatcher wird von Azure Load Balancer entweder der Failovercluster oder das parallele Web Dispatcher-Setup implementiert. Für Kommunikation im Internet wird eine eigenständige Lösung in der DMZ als Architektur empfohlen, um Sicherheitsanforderungen erfüllen zu können. Embedded Web Dispatcher in ASCS ist eine spezielle Option. Hierbei sollte aufgrund zusätzlicher Workloads in ASCS eine angemessene Dimensionierung in Betracht gezogen werden.

Fiori-Front-End-Server (FES)

Bei dieser Architektur geht es um allgemeine Grundanforderungen, und es wird davon ausgegangen, 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 sind keine zusätzlichen Clusteringschritte oder virtuellen Computer erforderlich. Aus diesem Grund ist die FES-Komponente im Architekturdiagramm nicht dargestellt.

Im Dokument SAP Fiori: Bereitstellungsoptionen und Empfehlungen für die Systemlandschaft werden die primären Bereitstellungsoptionen (eingebettet oder Hub) beschrieben. Diese richten sich nach dem jeweiligen Szenario. Zur Erzielung einer Vereinfachung und der gewünschten Leistung sind die Softwarereleases zwischen den Fiori-Technologiekomponenten und den S/4-Anwendungen eng miteinander gekoppelt, sodass eine Hubbereitstellung nur für wenige 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: mit einer Standbyserver-Datenbankschicht, ASCS-Clusterschicht mit Hochverfügbarkeits-NFS für gemeinsamen Speicher und mindestens zwei Anwendungsservern. Für den Lastenausgleich des Datenverkehrs wird ein Paar mit gruppierten oder parallelen Web Dispatcher-Instanzen verwendet. Für über das Internet zugängliche Fiori-Apps wird eine FES-Hubbereitstellung in einer DMZ empfohlen. Verwenden Sie Azure Application Gateway/WAF als zentrale Komponente, um den Datenverkehr mit AAD mit SAML für die Benutzerauthentifizierung und SSO für SAP Fiori zu schützen. Referenzarchitektur für SAP Fiori

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, RZ12 für RFC-Gruppen usw.). Bei diesen Transaktionen wird die Lastenausgleichsfunktion auf dem Nachrichtenserver von Central Services genutzt, um eingehende Sitzungen oder Workloads auf SAP-Anwendungsserverpools für SAPGUIs und RFC-Datenverkehr zu verteilen.

SAP Central Services-Cluster

Central Services kann auf einem einzelnen virtuellen Computer bereitgestellt werden, wenn die Azure-SLA zur Verfügbarkeit von Einzelinstanz-VMs für Ihre Anforderungen geeignet ist. Allerdings wird der virtuelle Computer zu einem potenziellen Single Point of Failure (SPOF) für die SAP-Umgebung. Für eine hoch verfügbare Central Services-Bereitstellung werden der Azure NetApp Files-Dienst und ein Central Services-Cluster verwendet.

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

Alternativ kann eine NFS-Dateifreigabe für freigegebenen Speicher eines Linux-Clusters verwendet werden.

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. Eine Azure Load Balancer-Instanz unterstützt mehrere Front-End-IPs, sodass die virtuellen IPs (VIPs) von Central Services und ERS an einen Lastenausgleich gebunden werden können.

Die Unterstützung der ASCS-Multi-SID-Installation in Azure ist jetzt vorhanden. Weniger Cluster führen zu einer Vereinfachung der SAP-Landschaft.

Verfügbarkeitsgruppen

Verfügbarkeitsgruppen verteilen Server auf verschiedene physische Infrastruktur und aktualisieren Gruppen, um die Verfügbarkeit des Diensts zu verbessern. Ordnen Sie virtuelle Computer, die dieselbe Rolle ausführen, in einer Verfügbarkeitsgruppe an, um vor Ausfallzeiten aufgrund von Wartungsvorgängen für die Azure-Infrastruktur zu schützen und Vereinbarungen zum Servicelevel (SLAs) zu erfüllen. Für die höhere SLA sind mindestens zwei virtuelle Computer pro Verfügbarkeitsgruppe erforderlich.

Alle virtuellen Computer in einer Gruppe müssen dieselbe Rolle ausführen. Mischen Sie keine Server mit unterschiedlichen Rollen in derselben Verfügbarkeitsgruppe. Ordnen Sie beispielsweise keinen ASCS-Knoten gemeinsam mit den Anwendungsservern in derselben Verfügbarkeitsgruppe an.

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 Hub-VNET als zentraler Verbindungspunkt für ein lokales Netzwerk dient. Die „Speichen“ (Spokes) sind VNETs, die eine Peeringverbindung mit dem Hub herstellen und zur Isolation von Workloads verwendet werden können. 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 VNET ein softwaredefiniertes Netzwerk, in dem der gesamte Datenverkehr über dasselbe Netzwerkfabric 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 virtuellem Computer bereitstellen, jede NIC mit einem anderen Subnetz verbinden und dann Netzwerksicherheitsgruppen (NSGs) verwenden, um verschiedene Zugriffssteuerungsrichtlinien zu erzwingen.

Für Azure-NICs wird die Verwendung mehrerer IP-Adressen unterstützt. Dies ermöglicht die von SAP empfohlene Vorgehensweise, bei der virtuelle Hostnamen für Installationen genutzt werden. Dies ist in SAP-Hinweis 962955 beschrieben. (Zum Zugreifen auf SAP-Hinweise müssen Sie über ein SAP Service Marketplace-Konto verfügen.)

Subnetze und Netzwerksicherheitsgruppen

In dieser Architektur wird der Adressraum des VNET in Subnetze unterteilt. Jedes Subnetz kann einer Netzwerksicherheitsgruppe (NSG) zugeordnet werden, in der die Zugriffsrichtlinien für das Subnetz definiert sind. Platzieren Sie Anwendungsserver in einem separaten Subnetz, sodass Sie diese leichter schützen können, indem Sie die Sicherheitsrichtlinien des Subnetzes und nicht die einzelnen Server verwalten.

Bei der Zuordnung zu einem Subnetz gilt eine NSG für alle Server des Subnetzes und ermöglicht die detaillierte Steuerung der Server. Verwenden Sie für die Einrichtung das Portal, PowerShell oder die Azure CLI.

ExpressRoute Global Reach

Wenn Ihre Netzwerkumgebung zwei oder mehr ExpressRoute-Leitungen enthält, ist eine Option zum Reduzieren von Netzwerkhops und Verringern der Latenz die Verwendung von ExpressRoute Global Reach. Dies ist eine Einrichtung eines Peerings der BGP-Route (Border Gateway Protocol) zwischen zwei oder mehr ExpressRoute-Leitungen zur Überbrückung von zwei ExpressRoute-Routingdomänen. Mit Global Reach wird die Latenz verringert, wenn Netzwerkdatenverkehr mehr als eine ExpressRoute-Leitung durchläuft. Dies ist derzeit nur für das private Peering in ExpressRoute-Leitungen verfügbar.

Im Moment sind keine Netzwerk-Zugriffssteuerungslisten (ACLs) oder anderen Attribute vorhanden, 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, über das Leitungspeering für die andere ExpressRoute-Leitung angekündigt werden. Wir empfehlen Ihnen, die Filterung des Netzwerkdatenverkehrs lokal einzurichten, um den Zugriff auf die Ressourcen zu beschränken.

ExpressRoute FastPath

FastPath wird auch als Microsoft Edge Exchange (MSEE) v2 bezeichnet und dient zum Implementieren von MSEE am Einstiegspunkt des Azure-Netzwerks. Hiermit wird die Anzahl von Netzwerkhops für die meisten Datenpakete reduziert. Mit FastPath wird die Netzwerklatenz verringert und die Anwendungsleistung verbessert, und es ist die Standardeinstellung für neue ExpressRoute-Verbindungen mit Azure.

Aktivieren Sie FastPath für vorhandene ExpressRoute-Leitungen über den Azure-Support.

FastPath unterstützt kein VNET-Peering. Wenn Sie für andere VNETs ein Peering mit dem VNET eingerichtet haben, das mit ExpressRoute verbunden ist, wird der für die anderen Spoke-VNETs bestimmte Netzwerkdatenverkehr aus Ihrem lokalen Netzwerk weiterhin an das VNET-Gateway gesendet. Die Problemumgehung besteht darin, alle VNETs 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.

Azure Load Balancer ist ein Dienst auf der Netzwerkübertragungsschicht (Schicht 4), mit dem Datenverkehr mit einem 5-Tupel-Hash aus den Datenströmen ausgeglichen wird (basierend auf Quell-IP, Quellport, Ziel-IP, Zielport und Protokolltyp). Dieser Dienst wird in Clustersetups genutzt, um Datenverkehr an die primäre Dienstinstanz oder bei einem Fehler an den fehlerfreien Knoten zu leiten. Wir empfehlen Ihnen, Azure Load Balancer Standard für alle SAP-Szenarien zu verwenden. Es ist wichtig, hervorzuheben, dass der Load Balancer Standard standardmäßig sicher ist, und dass keine virtuellen Computer hinter dem Load Balancer Standard über ausgehende Internetkonnektivität verfügen. Um ausgehende Internetkonnektivität auf den virtuellen Computern zu aktivieren, müssen Sie Ihre Load Balancer Standard-Konfiguration berücksichtigen.

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

Azure 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, empfehlen wir für alle Fälle die Verwendung von Premium Azure Managed Disks. Beachten Sie, dass durch ein vor Kurzem durchgeführtes Update von SAP-Hinweis 2015553 die Verwendung von HDD Standard-Speicher und SSD Standard-Speicher für einige spezielle Anwendungsfälle nicht mehr möglich ist.

Da Anwendungsserver keine geschäftlichen Daten hosten, können Sie auch die kleineren P4- und P6-Premium-Datenträger verwenden, um die Kosten zu reduzieren und bei einer zentralen Installation des SAP-Stapels von der SLA für Einzelinstanz-VMs profitieren.

Für Hochverfügbarkeitsszenarien sind freigegebene Azure-Datenträger in Azure Managed Disks als SSD Premium und SSD Ultra verfügbar. Freigegebene Azure-Datenträger können mit Windows Server, SUSE Enterprise Linux 15 SP 1 und höher sowie mit SUSE Enterprise Linux for SAP verwendet werden.

In NFS-Freigabeszenarios bietet Azure NetApp Files native NFS-Freigaben, die für die Volumes /hana/shared, /hana/data und /hana/log verwendet werden können. Zur Nutzung von ANF-basierten NFS-Freigaben für die Volumes /hana/data und /hana/log wird das v4.1 NFS-Protokoll benötigt. Für das Volume /hana/shared wird das NFS-Protokoll v3 unterstützt.

Azure Storage wird auch vom Cloudzeugen verwendet, um das Quorum mit einem Gerät in einer Azure-Remoteregion außerhalb der primären Region zu verwalten, in der sich der Cluster befindet.

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.

Mit SSD Ultra-Datenträgern wird die Datenträgerlatenz deutlich reduziert, und für Anwendungen mit hohen Leistungsanforderungen und die SAP-Datenbankserver ergeben sich Vorteile.

Überlegungen zur Leistung

SAP-Anwendungsserver 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 virtuelle Computer 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 SAP-Hinweis 1943937: Tool für die Überprüfung der Hardwarekonfiguration (für den Zugriff ist ein Konto für SAP Service Marketplace erforderlich).

Zur Erreichung eines hohen Durchsatzes in Bezug auf IOPS und die Datenträger-Bandbreite gelten für das Azure-Speicherlayout die gängigen Vorgehensweisen zur Leistungsoptimierung für Speichervolumes. Wenn beispielsweise mehrere Datenträger kombiniert werden, um ein Stripeset-Datenträgervolume zu erstellen, verbessert sich die E/A-Leistung. Eine Aktivierung des Lesecaches für Speicherinhalte, die sich in unregelmäßigen Abständen ändern, bewirkt eine höhere Geschwindigkeit beim Datenabruf. Sehen Sie sich auch die Empfehlungen zu Speicherkonfigurationen für unterschiedliche VM-Größen bei der Ausführung von SAP HANA an.

Ultra-Datenträger stellen 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 Ihren virtuellen Computer neu zu starten. Falls SSD Ultra-Datenträger verfügbar sind, wird die Verwendung dieser Datenträger anstelle von WA empfohlen.

Einige SAP-Anwendungen müssen häufig mit der Datenbank kommunizieren. Die Netzwerklatenz zwischen der Anwendung und den Datenbankschichten kann sich aufgrund der Nähe negativ auf die Anwendungsleistung auswirken. Bei Azure-Näherungsplatzierungsgruppen wird eine Platzierungseinschränkung für virtuelle Computer 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. Mit Näherungsplatzierungsgruppen kann die Benutzerfreundlichkeit für die meisten SAP-Anwendungen deutlich verbessert werden, und Skripts und Hilfsprogramme sind auf GitHub verfügbar.

Wir raten von der Platzierung von virtuellen Netzwerkgeräten (Network Virtual Appliances, NVAs) zwischen der Anwendung und den Datenbankschichten für SAP-Anwendungsstapel ab. Der Grund ist, dass es bei dieser Vorgehensweise zu einer erheblich längeren Verarbeitungsdauer für Pakete und zu einer inakzeptabel langsamen Anwendungsleistung kommt.

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. Dies erleichtert Ihnen die Entscheidung über die Platzierung von Ressourcen mit dem Ziel, die Latenz zwischen den Zonen möglichst gering zu halten. Führen Sie zum Erstellen dieses Profils einen Test durch, indem Sie in jeder Zone kleinere virtuelle Computer bereitstellen. Empfohlene Tools für den Test sind beispielsweise PsPing und Iperf. Entfernen Sie diese virtuellen Computer wieder, nachdem Sie die Tests durchgeführt haben. Das Tool zum Testen der Netzwerklatenz von öffentlichen Domänen ist als Hilfe für Sie ebenfalls verfügbar.

Überlegungen zur Skalierbarkeit

Auf der SAP-Anwendungsschicht sind in Azure viele verschiedene VM-Größen für zentrales Hochskalieren und horizontales Hochskalieren verfügbar. Eine umfassende Liste finden Sie im SAP-Hinweis 1928533: „SAP Applications on Azure: Supported Products and Azure VM Types“ (SAP-Hinweis 1928533 – SAP-Anwendungen in Azure: Unterstützte Produkte und Azure-VM-Typen). Da im Laufe der Zeit weitere VM-Typen zertifiziert werden, können Sie mit derselben Cloudbereitstellung hoch- oder herunterskalieren.

Auf der Datenbankschicht werden mit dieser Architektur SAP HANA S/4-Anwendungen auf virtuellen Azure-Computern ausgeführt, die schnell auf bis zu 6 Terabyte (TB) hochskaliert werden können. Wenn Ihre Workload die maximale VM-Größe überschreitet, können Sie die von Microsoft angebotenen großen Azure-Instanzen für SAP HANA nutzen. Bei dieser Option liegt die Grenze bei weit über 12 TB RAM. Bei Revision 4 sind diese physischen Server zusammen in einem Microsoft Azure-Rechenzentrum angeordnet und ermöglichen zum Zeitpunkt der Erstellung dieses Dokuments bis zu 24 TB Speicherkapazität für eine einzelne Instanz. 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. Für Unternehmen mit weniger strengen SLAs ist für virtuelle Azure-Einzelinstanzcomputer mit Premium-Datenträgern eine Betriebszeit-SLA verfügbar. Wenn redundante Ressourcen in einer Verfügbarkeitsgruppe oder übergreifend in Verfügbarkeitszonen bereitgestellt werden, 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

Hochverfügbarkeit wird über redundante Web Dispatcher-Instanzen erzielt. Informationen hierzu finden Sie in der SAP-Dokumentation unter SAP Web Dispatcher.

Central Services auf Anwendungsserverschicht

Für Hochverfügbarkeit von Central Services auf virtuellen Azure Linux-Computern wird die entsprechende Hochverfügbarkeitserweiterung für die ausgewählte Linux-Distribution verwendet, und die gemeinsam genutzten Dateisysteme werden in hoch verfügbarem NFS-Speicher angeordnet, indem SUSE DRDB oder Red Hat GlusterFS genutzt wird. Azure NetApp Files kann auch verwendet werden, um ein hoch verfügbares NFS bereitzustellen, damit kein NFS-Cluster benötigt wird. Darüber hinaus können hiermit die SAP HANA-Daten- und -Protokolldateien gehostet werden, um die Verwendung des Bereitstellungsmodells HANA mit horizontaler Skalierung mit Standbyknoten zu ermöglichen.

Für Azure NetApp Files wird auch die Hochverfügbarkeit von ASCS auf SUSE Linux Enterprise Servers (SLES) unterstützt. Ausführliche Informationen zu ASCS mit RHEL-Hochverfügbarkeit (Red Hat Enterprise Linux) finden Sie unter SIOS DataKeeper. 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 zum Erzielen von Hochverfügbarkeit ist die Verwendung von freigegebenen Azure-Datenträgern. Um unter SUSE Enterprise Linux 15 SP 1 und höher sowie SUSE Enterprise Linux for SAP Hochverfügbarkeit zu erzielen, kann der Pacemaker-Cluster mit einem freigegebenen Azure-Datenträger eingerichtet werden.

Dank der Einführung der Standard-SKU für Azure Load Balancer können Sie jetzt einfach den Hochverfügbarkeitsport aktivieren und vermeiden, dass Lastenausgleichsregeln für viele SAP-Ports konfiguriert werden müssen. Indem Sie Lastenausgleichsmodule allgemein einrichten (lokal oder in Azure), können Sie durch die Aktivierung des Features „Direct Server Return“ (auch als Floating IP oder DSR bezeichnet) erreichen, dass der Lastenausgleich bei Serverantworten auf Clientanfragen umgangen wird. Diese direkte Verbindung verhindert, dass der Lastenausgleich zum Engpass auf dem Datenübertragungspfad wird. Für die SAP ASCS- und HANA DB-Cluster empfehlen wir, DSR zu aktivieren. Wenn für virtuelle Computer im Back-End-Pool die öffentliche Konnektivität in ausgehender Richtung erforderlich ist, müssen zusätzliche 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ätzliches Lastenausgleichsmodul erforderlich.

Anwendungsserver auf der Anwendungsserverschicht

Hochverfügbarkeit wird erzielt, indem für Datenverkehr in einem Pool mit Anwendungsservern ein Lastenausgleich durchgeführt wird.

Datenbankschicht

Diese Referenzarchitektur beschreibt ein hochverfügbares SAP HANA-Datenbanksystem, das aus zwei virtuellen Azure-Computern besteht. Die native Systemreplikationsfunktion der Datenbankschicht bietet entweder manuelles oder automatisches Failover zwischen replizierten Knoten:

  • Stellen Sie für das manuelle Failover mehrere HANA-Instanzen bereit, und verwenden Sie die HANA-Systemreplikation (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 werden als HANA-Hochverfügbarkeitslösung für SLES normalerweise Pacemaker und SIOS LifeKeeper für RHEL bereitgestellt.

Bereitstellen von virtuellen Computern in Verfügbarkeitszonen

Mit Verfügbarkeitszonen kann die Dienstverfügbarkeit verbessert werden. Zonen sind physisch getrennte Orte innerhalb einer bestimmten Azure-Region. Sie werden genutzt, um die Verfügbarkeit von Workloads zu verbessern und Anwendungsdienste und virtuelle Computer 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 virtuellen Computer 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 aber 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.

Es sollten verschiedene Aspekte berücksichtigt werden, wenn Sie die Entscheidung treffen, Ressourcen in Verfügbarkeitszonen bereitzustellen, z. B.:

  • Latenz zwischen virtuellen Computern innerhalb einer Zone

  • Latenz zwischen virtuellen Computern in ausgewählten Zonen

  • Verfügbarkeit der gleichen Azure-Dienste (VM-Typen) in den ausgewählten Zonen

Hinweis

Verfügbarkeitszonen unterstützen Hochverfügbarkeit, stellen aber keine effektive Strategie für die Notfallwiederherstellung dar. Der Abstand zwischen den Zonen ist zu gering. Regionen für die Notfallwiederherstellung sollten normalerweise mindestens 160 km von der primären Region entfernt sein.

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. Die Server werden nur aktiviert, wenn dies erforderlich ist.

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 der Gruppe inaktiv (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, wird für ASCS und die Datenbankdienste ein Failover in Zone 2 ausgeführt. 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 virtuellen Computern in der sekundären Region angewendet werden. Kopieren Sie z. B. die ausführbaren Dateien des SAP-Kernels auf die-virtuellen Computer für die Notfallwiederherstellung.

Azure Site Recovery kann auch verwendet werden, um die Notfallwiederherstellung für die Bereitstellung einer SAP NetWeaver-Anwendung mit mehreren Ebenen einzurichten.

Central Services

Auch bei dieser Komponente des SAP-Anwendungsstapels werden keine Geschäftsdaten beibehalten. 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, also die Freigabe „/sapmnt“, werden normalerweise über einen hoch verfügbaren NFS-Cluster oder über Azure NetApp Files bereitgestellt. Um diesen Inhalt zu schützen, kopieren Sie ihn in den Remotedateidienst (NFS oder Azure NetApp Files), mit dem die Freigabe „/sapmnt“ für das SAP-Notfallwiederherstellungssystem bereitgestellt wird. Verwenden Sie rsync oder ein anderes zuverlässiges Tool zum Kopieren von Dateien.

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

Sie können Azure 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 einem lokalen Hochverfügbarkeitssetup mit zwei Knoten unterstützt HSR mehrstufige Replikation, wobei ein dritter Knoten in einer separaten Azure-Region als fremdes Element, nicht als Bestandteil des Clusters fungiert und sich beim sekundären Replikat des geclusterten HSR-Paars als dessen Replikationsziel registriert. Auf diese Weise entsteht eine Replikationsverkettung.

Das Failover zum Notfallwiederherstellungsknoten ist ein manueller Prozess. Seit HANA 2.0 SPS 03 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 Verzeichnisdienste, Sicherung 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 Azure Site Recovery

Um Azure Site Recovery für die automatische Erstellung eines vollständig replizierten Produktionsstandorts Ihrer Originalkonfiguration zu erstellen, müssen Sie benutzerdefinierte Bereitstellungsskripts ausführen. Mit Site Recovery werden die VMs beispielsweise zuerst in Verfügbarkeitsgruppen bereitgestellt. Anschließend werden Ihre benutzerdefinierten Skripts ausgeführt, um das vorhandene (vordefinierte) Lastenausgleichsmodul, für das der Back-End-Pool bereits definiert wurde, an die NIC der virtuellen Failovercomputer anzufügen. Ein Beispiel für das benutzerdefinierte Skript für Site Recovery-Automatisierungs-Runbooks finden Sie auf GitHub.

Hinweis

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

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.

Virtuelle Computer

In dieser Architektur werden virtuelle Computer mit Linux für die Logikschicht und die Datenbankschicht verwendet. Auf der SAP NetWeaver-Schicht werden virtuelle Windows-Computer 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 virtuelle Computer 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 eines virtuellen Computers über einen Zeitraum von einem Jahr oder drei Jahren verbindlich zusagen können. Mit VM-Reservierungen können die Kosten im Vergleich zu den Preisen für die nutzungsbasierte Bezahlung auf bis zu 72 Prozent gesenkt werden.

Verwenden Sie Azure-Spot-VMs zum Ausführen von Workloads, die unterbrochen werden können und nicht innerhalb eines vordefinierten Zeitraums 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 Kosten für virtuelle Spot-Computer sind deutlich niedriger. 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 Preise von virtuellen Linux-Computern.

Virtuelle Computer und Verfügbarkeitsgruppen

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

Azure Load Balancer

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

Die Gebühren werden nur anhand der Anzahl von konfigurierten Lastenausgleichsregeln und Ausgangsregeln berechnet. Für NAT-Regeln für eingehenden Datenverkehr fallen keine Gebühren an. Für Load Balancer Standard fallen keine Kosten auf Stundenbasis an, wenn keine Regeln konfiguriert sind.

Azure ExpressRoute

Bei dieser Architektur ist Azure 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

Backup

SAP HANA kann auf viele verschiedene Arten gesichert werden. Nach der Migration zu Azure können Sie weiterhin alle vorhandenen Sicherungslösungen nutzen, die Sie bereits verwenden. In Azure gibt es zwei native Ansätze für Sicherungen. Sie können SAP HANA auf virtuellen Computern sichern und Azure Backup auf Dateiebene verwenden. Azure Backup verfügt jetzt über eine BackInt-Zertifizierung von SAP. Informationen hierzu finden Sie auch unter Azure Backup – Häufig gestellte Fragen.

Hinweis

Zum Zeitpunkt der Erstellung dieses Dokuments werden Azure-Speichermomentaufnahmen nur von HANA-Einzelcontainer-Bereitstellungen unterstützt.

Identitätsverwaltung

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

Ü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 sich auf die Anwendungen und die davon abhängigen Ressourcen auswirken.

Um SAP-basierte Überwachung von Ressourcen sowie der Leistung von Diensten der SAP-Infrastruktur bereitzustellen, wird die Azure-Erweiterung zur verbesserten Überwachung für SAP verwendet. 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 on Linux with Azure: Erweiterte Überwachung“. (Für den Zugriff ist ein SAP Service Marketplace-Konto erforderlich.)

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 zusätzliche Netzwerksicherheit zu erreichen, können Sie eine Netzwerk-DMZ implementieren, für die ein virtuelles Netzwerkgerät verwendet wird, um eine Firewall vor dem Subnetz für die Web Dispatcher- und Fiori Front-End-Server-Pools zu erstellen.

Um die Sicherheit der Infrastruktur zu gewährleisten, sind die Daten während der Übertragung und im Ruhezustand verschlüsselt. Im Abschnitt „Sicherheitshinweise“ der Anleitung Azure Virtual Machines – Planung und Implementierung für SAP NetWeaver geht es um die Netzwerksicherheit, und die Informationen gelten für S/4HANA. In diesem Artikel sind auch die Netzwerkports angegeben, die Sie in den Firewalls öffnen müssen, um die Anwendungskommunikation zu ermöglichen.

Um Linux-VM-Datenträger zu verschlüsseln, können Sie Azure Disk Encryption verwenden. Dieser Dienst verwendet das DM-Crypt-Feature von Linux, um die Volumeverschlüsselung für die Betriebssystem- und die Daten-Datenträger bereitzustellen. Die Lösung funktioniert auch für Azure Key Vault, damit Sie die Verschlüsselungsschlüssel und Geheimnisse für die Datenträgerverschlüsselung in Ihrem Key Vault-Abonnement steuern und verwalten können. Daten auf den VM-Datenträgern werden in Ihrem Azure-Speicher im ruhenden Zustand verschlüsselt.

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

Hinweis

Vermeiden Sie es, die HANA-Verschlüsselung von ruhenden Daten mit Azure Disk Encryption auf demselben Speichervolume zu verwenden. Verwenden Sie für HANA nur die HANA Datenverschlüsselung. Betriebssystem-Bootdatenträger für virtuelle Linux-Computer weisen keine Unterstützung für Azure Disk Encryption auf, und Azure Site Recovery unterstützt auch noch keine an Azure Disk Encryption angefügten Datenträger unter Linux.

Communitys

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

Weitere Informationen und Beispiele für SAP-Workloads, für die einige dieser Technologien verwendet werden, finden Sie in den folgenden Artikeln: