Freigeben über

SAP S/4HANA unter Linux in Azure

Dieser Leitfaden enthält eine Reihe bewährter Methoden für die Ausführung von S/4HANA und Suite auf HANA in einer Hochverfügbarkeitsumgebung (HA), die Notfallwiederherstellung (DR) in Azure unterstützt. Die Fiori-Informationen gelten nur für S/4HANA-Anwendungen.

Architektur

Architekturdiagramm, das SAP S/4HANA für virtuelle Linux-Computer in einem Azure-Verfügbarkeitssatz zeigt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Hinweis

Um diese Architektur bereitzustellen, stellen Sie sicher, dass Sie über die erforderliche Lizenzierung für SAP-Produkte und andere Nicht-Microsoft-Technologien verfügen.

In diesem Handbuch wird ein typisches Produktionssystem beschrieben. Diese Architektur verwendet verschiedene VM-Größen (Virtual Machine). Um die Anforderungen Ihrer Organisation zu erfüllen, können Sie die Größen anpassen oder diese Konfiguration auf einen einzelnen virtuellen Computer reduzieren.

In diesem Leitfaden wird das Netzwerklayout vereinfacht, um Architekturprinzipien zu veranschaulichen. Es stellt kein vollständiges Unternehmensnetzwerk dar.

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

Azure Virtual Network. Der Virtuelle Netzwerkdienst verbindet Azure-Ressourcen mit verbesserter Sicherheit 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. Diese Architektur verwendet mehrere virtuelle Netzwerke, die miteinander verbunden sind. Diese Topologie bietet Netzwerksegmentierung und -isolation für Dienste, die in Azure bereitgestellt werden. Peering verbindet Netzwerke transparent über das Microsoft-Backbone-Netzwerk und verursacht keine Leistungseinbußen, wenn es in einer einzelnen Region implementiert wird. Separate Subnetze werden für jede Ebene verwendet, einschließlich der Anwendungsebene (SAP NetWeaver) und der Datenbankebene sowie für freigegebene Komponenten wie das Sprungfeld und Windows Server Active Directory.

Virtuelle Maschinen (VMs) Diese Architektur organisiert virtuelle Computer, die Linux in Gruppen für die Anwendungsebene und die Datenbankebene auf folgende Weise ausführen:

  • Anwendungsebene. Diese Architekturschicht 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 zentralen Diensten in Azure, die in Linux-VMs ausgeführt werden, ist ein hochverfügbarer Netzwerkdienst für die Dateifreigabe erforderlich, z. B. Dateifreigaben über das Netzwerkdateisystem (NFS) in Azure Files, Azure NetApp Files, gruppierte NFS-Server 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. Auf SUSE Linux Enterprise Server (SLES) 15 SP1 und höheren Versionen oder SLES for SAP Applications können Sie Azure Shared Disks in einem Pacemaker-Cluster als Fence-Gerät verwenden, um HA zu erreichen.

  • SAP HANA. Die Datenbankebene verwendet zwei oder mehr Linux-VMs in einem Cluster, um HA in einer Skalierungsbereitstellung zu erreichen. 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 das automatische Failover zu vereinfachen. Sie müssen einen speicherbasierten oder cloudbasierten Fencingmechanismus verwenden, um sicherzustellen, dass das fehlerhafte System isoliert oder heruntergefahren wird, um einen partitionierten Cluster zu vermeiden. In HANA-Skalierungsbereitstellungen können Sie Datenbank-HA 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.

  • Azure Bastion Mit diesem Dienst können Sie eine Verbindung mit einem virtuellen Computer herstellen, indem Sie Ihren Browser und das Azure-Portal oder den systemeigenen Secure Shell (SSH)- oder RDP-Client (Remote Desktop Protocol) verwenden, der auf Ihrem lokalen Computer installiert ist. Wenn nur RDP und SSH für die Verwaltung verwendet werden, erwägen Sie die Verwendung von Azure Bastion. 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: Verwenden Sie Azure Standard Load Balancer, um den Datenverkehr an VMs im SUBnetz der SAP-Anwendungsebene zu verteilen, um die Verfügbarkeit zu erhöhen. Load Balancer Standard bietet standardmäßig eine Sicherheitsebene. VMs, die sich hinter Load Balancer Standard befinden, verfügen über keine ausgehende Internetkonnektivität. Um ausgehende Internetkonnektivität auf den VMs zu aktivieren, müssen Sie Ihre Load Balancer Standard-Konfiguration aktualisieren. Sie können auch ein Azure NAT Gateway verwenden, um ausgehende Konnektivität zu erhalten. Verwenden Sie für die webbasierte SAP-Anwendung HA den integrierten SAP Web Dispatcher oder einen anderen kommerziell verfügbaren Lastenausgleich. Basieren Sie Ihre Auswahl auf Folgendes:

  • Ihr Datenverkehrstyp, z. B. HTTP- oder SAP-Grafischer Benutzeroberflächendatenverkehr (GUI).
  • Die Netzwerk-Features, die Sie benötigen, z. B. SSL-Terminierung (Secure Sockets Layer).

Standardmäßiger Lastenausgleich unterstützt mehrere virtuelle Front-End-IP-Adressen. Diese Unterstützung eignet sich ideal für Clusterimplementierungen, die die folgenden Komponenten enthalten:

  • Advanced Business Application Programming (ABAP) SAP Central Services (ASCS)
  • Replikationsserver in Warteschlange stellen

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

Standard Load Balancer unterstützt auch SAP-Cluster mit mehrfacher System-ID (Multi-SID). Dieses Feature ermöglicht es mehreren SAP-Systemen auf SLES oder RHEL , eine gemeinsame HA-Infrastruktur zu teilen, um Kosten zu reduzieren. Wir empfehlen Ihnen, die Kosteneinsparungen auszuwerten und nicht zu viele Systeme in einem Cluster zu platzieren. Azure unterstützt bis zu 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 Lastenausgleichsgeräte arbeiten auf der Transportschicht, die als Open Systems Interconnection (OSI)-Ebene 4 bezeichnet wird, mithilfe des Übertragungssteuerungsprotokolls und des Benutzerdatendiagrammprotokolls. Sie leiten den Datenverkehr auf der Grundlage der Quell-IP-Adresse und des Ports an eine Ziel-IP-Adresse und einen Port weiter. Das Anwendungsgateway kann Routingentscheidungen basierend auf zusätzlichen Attributen einer HTTP-Anforderung treffen, z. B. den Pfad zum Uniform Resource Identifier oder Hostheader. Diese Art von Routing wird als Anwendungsschicht oder OSI-Ebene 7, Lastenausgleich bezeichnet. S/4HANA stellt Webdienste über Fiori bereit. Sie können einen Lastausgleich für dieses Fiori-Front-End durchführen, das aus Web-Apps besteht, indem Sie Application Gateway verwenden. Wenn Sie öffentliche IP-Adressen verwenden, stellen Sie sicher, dass sie die Standard-IP-Adress-SKU verwenden. Vermeiden Sie die SKU für die Basis-IP-Adresse, da diese am 30. September 2025 außer Betrieb genommen wird.

Gateway. Ein Gateway verbindet verschiedene Netzwerke und erweitert Ihr lokales Netzwerk auf ein virtuelles Azure-Netzwerk. Azure ExpressRoute ist der empfohlene Azure-Dienst zum Erstellen privater Verbindungen, die nicht über das öffentliche Internet gehen. Sie können auch eine Site-to-Site-Verbindung verwenden. Verwenden Sie ExpressRoute Global Reach oder ExpressRoute FastPath, um die Latenz zu verringern.

Zonenredundantes Gateway: Sie können ExpressRoute- oder VPN-Gateways (Virtuelles Privates Netzwerk) zonenübergreifend bereitstellen, um den Schutz vor Zonenausfällen zu ermöglichen. Diese Architektur verwendet zonenredundante virtuelle Netzwerkgateways zur Resilienz anstelle einer Zonenbereitstellung, die auf derselben Verfügbarkeitszone basiert.

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 hilft beim Erzwingen der Colocation, indem sichergestellt wird, dass VMs im selben Rechenzentrum bereitgestellt werden. Diese Konfiguration reduziert den physischen Abstand zwischen Ressourcen, um die Anwendungslatenz zu minimieren.

Hinweis

Eine aktualisierte Konfigurationsstrategie finden Sie unter "Konfigurationsoptionen", um die Netzwerklatenz mit SAP-Anwendungen zu minimieren. In diesem Artikel werden die potenziellen Kompromisse bei der Bereitstellungsflexibilität beschrieben, wenn Sie ein SAP-System für die Netzwerklatenz optimieren.

Netzwerksicherheitsgruppen (NSGs). Um eingehenden, ausgehenden und intrasubnetzinternen Datenverkehr in einem virtuellen Netzwerk einzuschränken, können Sie 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 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. Es wird empfohlen, azure managed disks zu verwenden.

Empfehlungen

Diese Architektur beschreibt eine kleine, produktionsbereite Bereitstellung. Die Bereitstellung hängt von den geschäftlichen Anforderungen ab, sodass diese Empfehlungen als Startpunkt dienen können.

Virtuelle Maschinen (VMs)

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

Weitere Informationen zur SAP-Unterstützung für Azure-VM-Typen und zu Durchsatzmetriken finden Sie im SAP-Hinweis 1928533. Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto. Eine Liste der zertifizierten Azure-VMs für die HANA-Datenbank finden Sie im 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. Um HA von SAP Web Dispatcher zu erreichen, implementiert Azure Load Balancer entweder einen Failovercluster oder das parallele Web Dispatcher-Setup. Für die in das Internet gerichtete Kommunikation ist eine eigenständige Lösung im Umkreisnetzwerk die empfohlene Architektur, um Sicherheitsanforderungen zu erfüllen. Embedded Web Dispatcher auf ASCS ist eine erweiterte Konfiguration. Wenn Sie diese Konfiguration verwenden, sollten Sie die richtige Dimensionierung wegen der zusätzlichen Belastung des ASCS in Betracht ziehen.

Fiori-Front-End-Server (FES)

Diese Architektur erfüllt mehrere Anforderungen und setzt voraus, dass Sie das eingebettete Fiori FES-Modell verwenden. Alle Technologiekomponenten werden direkt auf dem S/4-System installiert, sodass jedes S/4-System über ein eigenes Fiori-Startpad verfügt. Das S/4-System verwaltet die HA-Konfiguration für dieses Bereitstellungsmodell. Bei diesem Ansatz wird die Notwendigkeit für zusätzliche Clustering oder VMs entfernt. Aus diesem Grund enthält das Architekturdiagramm nicht die FES-Komponente.

Weitere Informationen zu Bereitstellungsoptionen finden Sie unter SAP Fiori-Bereitstellungsoptionen und Empfehlungen zur Systemlandschaft. Aus Gründen der Einfachheit und Leistung sind die Softwarereleases zwischen den Fiori-Technologiekomponenten und den S/4-Anwendungen fest gekoppelt. Dieses Setup macht eine Hubbereitstellung nur für wenige, bestimmte Anwendungsfälle geeignet.

Bei Verwendung der FES-Hubbereitstellung ist FES eine Add-On-Komponente für den klassischen SAP NetWeaver-ABAP-Stapel. Richten Sie die Hochverfügbarkeit (HA) auf die gleiche Weise ein, wie Sie einen dreischichtigen ABAP-Anwendungsstapel schützen, der über Cluster- oder Mehrhost-Funktionalität verfügt. Verwenden Sie eine Standbyserverdatenbankebene, eine gruppierte ASCS-Ebene mit HA NFS für gemeinsam genutzten Speicher und mindestens zwei Anwendungsserver. 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 die Azure Web Application Firewall auf dem Anwendungsgateway als wichtige Komponente, um Bedrohungen zu verzögern. Verwenden Sie Microsoft Entra ID mit Security Assertion Markup Language für die Benutzerauthentifizierung und einmaliges Anmelden für SAP Fiori.

Architekturdiagramm, das den Datenfluss zwischen dem Internet und zwei virtuellen Netzwerken zeigt, eines mit SAP Fiori und eines mit SAP S/4HANA.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Weitere Informationen finden Sie unter Eingehende und ausgehende Internetverbindungen für SAP in Azure.

Anwendungsserverpool

Verwenden Sie die folgenden Transaktionscodes, um Anmeldegruppen für ABAP-Anwendungsserver zu verwalten:

  • SMLG: Lastenausgleich für angemeldete Benutzer.
  • SM61: Verwalten von Batchservergruppen.
  • RZ12: Verwalten von RFC-Gruppen (Remote Function Call).

Diese Transaktionen basieren auf der Lastenausgleichsfunktion auf dem Nachrichtenserver für zentrale Dienste, um eingehende Sitzungen und Workloads über den Pool von SAP-Anwendungsservern zu verteilen, die SAP-GUI- und RFC-Datenverkehr verwalten.

SAP-Zentral-Dienste-Cluster

Die SAP Central Services enthalten eine einzelne Instanz des Nachrichtenservers und den enqueue Replikationsdienst. Im Gegensatz zu den Arbeitsprozessen von Anwendungsservern sind diese Komponenten einzelne Fehlerpunkte im SAP-Anwendungsstapel. 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. Wenn Ihr SLA eine höhere Verfügbarkeit erfordert, müssen Sie diese Dienste in einem HA-Cluster bereitstellen. Weitere Informationen finden Sie unter "Zentrale Dienste" auf der Anwendungsserverebene.

Vernetzung

Diese Architektur verwendet eine Hub-Spoke-Topologie, in der das virtuelle Hubnetzwerk als zentraler Verbindungspunkt mit einem lokalen 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

Herkömmliche lokale SAP-Bereitstellungen implementieren mehrere Netzwerkschnittstellenkarten (NETWORK Interface Cards, NICs) pro Computer, um administrativen Datenverkehr vom Geschäftsdatenverkehr zu trennen. In Azure ist das virtuelle Netzwerk ein softwaredefiniertes Netzwerk, das den gesamten Datenverkehr über eine einzelne Netzwerk fabric leitet. Daher benötigen Sie aus Leistungsgründen nicht mehrere NICs. Wenn Ihre Organisation Datenverkehr trennen muss, können Sie mehrere NICs für jede VM bereitstellen, jede NIC mit einem anderen Subnetz verbinden und dann NSGs verwenden, um verschiedene Zugriffssteuerungsrichtlinien zu erzwingen.

Azure NICs unterstützen mehrere IP-Adressen. Diese Unterstützung entspricht der Praxis, die SAP empfiehlt, virtuelle Hostnamen für Installationen in SAP Note 962955 zu verwenden.

Subnetze und NSGs

In dieser Architektur wird der Adressraum des virtuellen Netzwerks in Subnetze unterteilt. Sie können jedes Subnetz einem NSG zuordnen, das die Zugriffsrichtlinien für das Subnetz definiert. Platzieren Sie Anwendungsserver in einem separaten Subnetz. Dieser Ansatz erleichtert das Sichern von Anwendungsservern, indem die Subnetzsicherheitsrichtlinien anstelle der einzelnen Server verwaltet werden.

Wenn Sie ein NSG einem Subnetz zuordnen, gilt die NSG für alle Server im Subnetz und bietet eine differenzierte Kontrolle über die Server. Richten Sie NSGs mithilfe des Azure-Portals, Azure PowerShell oder der Azure CLI ein.

Globale ExpressRoute-Reichweite

Wenn Ihre Netzwerkumgebung zwei oder mehr ExpressRoute-Schaltkreise enthält, kann ExpressRoute Global Reach Ihnen helfen, Netzwerkhüpfungen zu reduzieren und die Latenz zu verringern. Bei dieser Technologie handelt es sich um ein Border Gateway Protocol-Route-Peering, das zwischen zwei oder mehr ExpressRoute-Circuits eingerichtet wird, um zwei ExpressRoute-Routingdomänen zu überbrücken. Die globale Reichweite verringert die Latenz, wenn der Netzwerkdatenverkehr mehrere ExpressRoute-Schaltkreise durchläuft. Es ist nur für privates Peering auf ExpressRoute-Schaltkreisen verfügbar.

"Global Reach unterstützt keine Änderungen an Netzwerkzugriffs-Steuerungs-Listen oder anderen Attributen." Alle Routen, die von einer ExpressRoute-Verbindung gelernt wurden, unabhängig davon, ob sie von lokalen Netzwerken oder von Azure stammen, werden über Circuit-Peering zu anderen ExpressRoute-Verbindungen bekanntgegeben. Es wird empfohlen, die lokale Netzwerkdatenverkehrsfilterung einzurichten, um den Zugriff auf Ressourcen einzuschränken.

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 reduziert FastPath die Netzwerklatenz, verbessert die Anwendungsleistung und 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 ein mit ExpressRoute verbundenes virtuelles Netzwerk mit anderen virtuellen Netzwerken gekoppelt ist, wird der Datenverkehr von Ihrem lokalen Netzwerk zu den anderen virtuellen Spoke-Netzwerken über das virtuelle Netzwerkgateway weitergeleitet. Um dieses Problem zu beheben, verbinden Sie alle virtuellen Netzwerke direkt mit dem ExpressRoute-Schaltkreis.

Lastenausgleichsgeräte

SAP Web Dispatcher verarbeitet den Lastenausgleich von HTTP- und HTTPS-Datenverkehr an einen Pool von SAP-Anwendungsservern. Dieser Softwarelastenausgleich bietet Anwendungsschichtdienste, die im ISO-Netzwerkmodell als Layer 7 bezeichnet werden, die SSL-Beendigung und andere Offloading-Funktionen bieten.

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 einer Quell-IP-Adresse, Quellport, Ziel-IP-Adresse, 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, Load Balancer Standard für alle SAP-Szenarien zu verwenden. Standard-Load-Balancer ist standardmäßig gesichert, und keine VMs hinter dem Standard-Load-Balancer verfügen über ausgehende Internetkonnektivität. Um ausgehende Internetkonnektivität auf den VMs zu aktivieren, müssen Sie Ihre Load Balancer Standard-Konfiguration anpassen.

Für den Datenverkehr von SAP-GUI-Clients, die über das DIAG-Protokoll (Dynamic Information and Action Gateway) oder RFC eine Verbindung zu einem SAP-Server herstellen, verteilt der Message-Server der zentralen Dienste die Last über SAP-Anwendungsserver-Anmeldegruppen. Es ist kein zusätzlicher Lastenausgleich erforderlich.

Lagerung

Einige Kunden nutzen den Standardspeicher für ihre Anwendungsserver. Da standardverwaltete Datenträger nicht unterstützt werden, empfehlen wir, Azure Premium SSD oder Azure NetApp Files in allen Szenarien zu verwenden. Ein aktuelles Update auf SAP-Hinweis 2015553 schließt die Verwendung von Azure Standard HDD Storage und Azure Standard SSD Storage für einige bestimmte Anwendungsfälle aus.

Da Anwendungsserver keine Geschäftsdaten hosten, können Sie auch die kleineren P4- und P6-Premium-Datenträger verwenden, um die Kosten zu senken. Für SAP-Anwendungen wird dringend empfohlen, Azure SSD v1, SSD v2 oder Ultra Disks zu verwenden. Informationen dazu, wie sich der Speichertyp auf die SLA der VM-Verfügbarkeit auswirkt, finden Sie unter SLAs für Onlinedienste. Für HA-Szenarien sind Azure-Features für gemeinsam genutzte Datenträger auf Azure Premium SSD und Azure Ultra Disk Storage verfügbar. Weitere Informationen finden Sie unter Azure managed disks and Azure managed disk types.

Sie können freigegebene Azure-Datenträger mit Windows Server, SLES 15 SP1 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 Fencing für ein ausgefallenes Blockgerät eines Knotens. Es stellt eine Quorumstimme in einem Clusternetzwerkpartitionierungsszenario bereit. 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 HA für NFS-Freigaben, die für /hana/shared-, /hana/data- und /hana/log-Volumes verwendet werden können. Die Verfügbarkeitsgarantie finden Sie unter SLAs für Onlinedienste. Wenn Sie Azure NetApp Files-basierte NFS-Freigaben für die /hana/data und /hana/log Volumes verwenden, müssen Sie das NFS v4.1-Protokoll 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. Erwägen Sie außerdem die Verwendung der Azure NetApp Files Standard-Ebene als Sicherungsziel oder die Sicherungsoption Azure NetApp Files. Für einen verwalteten Datenträger werden als Sicherungsdatenschichten die Azure-Zugriffsebenen „Kalt“ oder „Archiv“ empfohlen.

Ultra Disk Storage und Azure NetApp Files Ultra tier reduzieren die Datenträgerlatenz erheblich und verbessern die Leistung kritischer Anwendungen und SAP-Datenbankserver.

Premium SSD v2 ist für leistungskritische Workloads wie SAP ausgelegt. Weitere Informationen zu den Vorteilen und Einschränkungen dieser Speicherlösung finden Sie unter Bereitstellen einer Premium-SSD v2.

Leistungsüberlegungen

SAP-Applikationsserver kommunizieren ständig mit den Datenbankservern. Für leistungskritische Anwendungen, die auf jeder Datenbankplattform ausgeführt werden, einschließlich SAP HANA, aktivieren Sie Write Accelerator für das Protokollvolume, wenn Sie Premium SSD v1 verwenden. Dieser Ansatz kann die Latenz beim Protokollschreibvorgang verbessern. SSD Premium v2 verwendet keine Schreibbeschleunigung. Die Schreibbeschleunigung ist für VMs der M-Serie verfügbar.

Um die serverübergreifende Kommunikation zu optimieren, verwenden Sie den beschleunigten Netzwerkbetrieb. Die meisten Größen universeller, computeoptimierter VM-Instanzen mit mindestens zwei vCPUs unterstützen den beschleunigten Netzwerkbetrieb. Auf Instanzen, die Hyperthreading unterstützen, unterstützen VM-Instanzen mit vier oder mehr vCPUs beschleunigte Netzwerke.

Sie sollten den Linux TCP/IP-Stapel und Puffer in der Netzwerkschnittstelle optimieren, um eine konsistente Leistung zu erzielen. Folgen Sie den von Microsoft empfohlenen Einstellungen. Beispielsweise passen Sie Elemente an, z. B.:

  • Kernelparameter zum Optimieren von Lese- und Schreibspeicherpuffern
  • Engpass-Bandbreite und Round-Trip Propagation Time (BBR) zur Steuerung von Überlastungen
  • Passen Sie TCP-Parameter an, um eine bessere Konsistenz und einen besseren Durchsatz zu erzielen.
  • NIC-Ringpuffer für TX/RX

Weitere Informationen zu SAP HANA-Leistungsanforderungen finden Sie im SAP-Hinweis 1943937.

Um hohe Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) und Datenträgerbandbreitendurchsatz zu erzielen, befolgen Sie die allgemeinen Methoden für die Optimierung der Speichervolumeleistung. Wenn Sie beispielsweise mehrere Datenträger gruppieren, um ein Stripesetvolume zu erstellen, können Sie die Leistung der Eingabe/Ausgabe (E/A) verbessern. Das Aktivieren des Lesecaches für Speicherinhalte, die sich selten ändern, kann auch den Datenabruf beschleunigen. Weitere Informationen finden Sie unter SAP HANA: Speicherkonfigurationen für virtuelle Azure-Computer.

Premium SSD v2 ist für leistungskritische Workloads wie SAP ausgelegt. Weitere Informationen zu den Vorteilen, Einschränkungen und optimalen Verwendungsszenarien finden Sie unter Azure managed disk types.

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 unabhängig Metriken wie IOPS und MBps konfigurieren, ohne ihre VM neu zu starten. Es wird empfohlen, nach Möglichkeit Ultra Disk Storage anstelle von Write Accelerator zu verwenden.

Einige SAP-Anwendungen müssen häufig mit der Datenbank kommunizieren. Aufgrund der Entfernung kann sich die Netzwerklatenz zwischen der Anwendung und den Datenbankebenen negativ auf die Anwendungsleistung auswirken. Bei Azure-Näherungsplatzierungsgruppen wird eine Platzierungseinschränkung für VMs festgelegt, die in Verfügbarkeitsgruppen bereitgestellt werden. Innerhalb des logischen Konstrukts einer Gruppe werden Colocation und Leistung gegenüber Skalierbarkeit, Verfügbarkeit und Kosten bevorzugt. Näherungsplatzierungsgruppen können eine deutliche Verbesserung der Benutzererfahrung für die meisten SAP-Anwendungen bewirken.

Die Platzierung eines virtuellen Netzwerkgerät (Network Virtual Appliance, NVA) zwischen der Anwendungs- und der Datenbankschicht eines beliebigen SAP-Anwendungsstapels wird nicht unterstützt. Die NVA benötigt eine beträchtliche Zeit, um Datenpakete zu verarbeiten. Infolgedessen wird die Leistung der Anwendung inakzeptabel verlangsamt.

Außerdem wird empfohlen, die Leistung beim Bereitstellen von Ressourcen mit Verfügbarkeitszonen zu berücksichtigen, wodurch die Dienstverfügbarkeit verbessert werden kann. Erwägen Sie das Erstellen eines klaren Netzwerklatenzprofils zwischen allen Zonen einer Zielregion. 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 öffentliches Netzwerklatenztest-Tool, das Sie stattdessen verwenden können, finden Sie unter Verfügbarkeitszonenlatenztest.

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

Überlegungen zur Skalierbarkeit

Auf der SAP-Anwendungsebene bietet Azure eine Vielzahl von VM-Größen für das Scale-up und Scale-out. Eine umfassende Liste finden Sie unter SAP-Anwendungen in Azure: Unterstützte Produkte und Azure VM-Typen in SAP-Hinweis 1928533. Weitere VM-Typen werden kontinuierlich zertifiziert, sodass Sie in derselben Cloudbereitstellung nach oben oder unten skalieren können.

Auf der Datenbankebene führt diese Architektur SAP S/4HANA-Anwendungen auf Azure-VMs aus, die in einer Instanz bis zu 24 Terabyte (TB) skalieren können. Wenn Ihre Workload die maximale VM-Größe überschreitet, können Sie eine Konfiguration mit mehreren Knoten für bis zu 96 TB (vier 24 TB-Instanzen) für Onlinetransaktionsverarbeitungsanwendungen verwenden. Weitere Informationen finden Sie im Zertifizierten und unterstützten SAP HANA-Hardwareverzeichnis.

Überlegungen zur Verfügbarkeit

Ressourcenredundanz ist das allgemeine Thema bei hochverfügbaren Infrastrukturlösungen. SLAs für die Verfügbarkeit von VMs mit einer Instanz für verschiedene Speichertypen finden Sie unter SLAs für Onlinedienste. Um die Dienstverfügbarkeit in Azure zu erhöhen, stellen Sie VM-Ressourcen mithilfe von Azure Virtual Machine Scale Sets bereit, die flexible Orchestrierung, Verfügbarkeitszonen und Verfügbarkeitssätze bieten.

Das Bereitstellungsmodell für regionale Verfügbarkeitsgruppen von Azure ist eine unterstützte Option. Es wird jedoch empfohlen, die Skalierungssätze des virtuellen Computers mit dem Verfügbarkeitszonenmodell für neue SAP-Bereitstellungen zu übernehmen, um die Verfügbarkeit zu verbessern und die Flexibilität der Bereitstellung zu erhöhen.

In dieser verteilten Installation der SAP-Anwendung wird die Basisinstallation repliziert, um HA zu erreichen. Für jede Ebene der Architektur variiert der HA-Entwurf.

Bereitstellungsansätze

In Azure kann die Bereitstellung von SAP-Workloads je nach Verfügbarkeits- und Resilienzanforderungen der SAP-Anwendungen entweder regions- oder zonenbasiert sein. Azure bietet verschiedene Bereitstellungsoptionen, z. B. Skalierungssätze für virtuelle Computer mit flexibler Orchestrierung (eine Konfiguration einer Fehlerdomäne), Verfügbarkeitszonen und Verfügbarkeitsgruppen, um die Verfügbarkeit der Ressourcen zu verbessern.

Da Kundenbereitstellungen in Azure im Laufe der Jahre gewachsen sind, hat Microsoft azure VM-Bereitstellungsmodelle verbessert, um Skalierungssätze für virtuelle Computer einzuschließen, um die Flexibilität und Resilienz der Cloud sicherzustellen. In Anbetracht der verfügbaren Bereitstellungsoptionen empfehlen wir Ihnen dringend, für alle neuen Bereitstellungen eine zonale Bereitstellung mit Azure für flexible Skalierung zu verwenden. Weitere Informationen zur Bereitstellung über Zonen hinweg, innerhalb einer einzelnen Zone und in Regionen ohne Zonen finden Sie unter HA-Architektur und -Szenarien für SAP NetWeaver.

Web Dispatcher auf Anwendungsserverschicht

Sie können HA mithilfe redundanter Web Dispatcher-Instanzen erreichen. Weitere Informationen finden Sie unter SAP Web Dispatcher. Der Verfügbarkeitsgrad hängt von der Größe der Anwendung ab, die hinter Web Dispatcher steht. In kleinen Bereitstellungen, die nur wenige Skalierbarkeitsprobleme haben, können Sie den Web Dispatcher bei den ASCS-VMs zusammenführen. Dieser Ansatz hilft Ihnen, Kosten bei der Wartung unabhängiger Betriebssysteme zu sparen und gleichzeitig Hochverfügbarkeit (HA) zu erreichen.

Central Services auf Anwendungsserverschicht

Verwenden Sie für HA of Central Services auf Azure Linux-VMs die entsprechende HA-Erweiterung für die ausgewählte Linux-Verteilung. Es ist üblich, die gemeinsam genutzten Dateisysteme mithilfe des SUSE Distributed Replicated Block Device oder Red Hat GlusterFS auf hochverteilten NFS-Speicher zu platzieren. Um eine hoch verfügbare NFS bereitzustellen und die Notwendigkeit eines NFS-Clusters zu vermeiden, können Sie andere kostengünstige oder robuste Lösungen wie NFS über Azure Files oder Azure NetApp Files verwenden. Azure NetApp Files-Freigaben können 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 hochverwendende Dateifreigaben wie /sapmnt und /saptrans in SAP-Installationen.

Azure NetApp Files unterstützt HA von ASCS auf SLES. Weitere Informationen zu ASCS auf RHEL HA finden Sie unter SIOS Protection Suite für Linux.

Der verbesserte Azure-Zaun-Agent ist sowohl für SUSE als auch Für Red Hat verfügbar und bietet wesentlich schnelleres Dienstfailover als die vorherige Version des Agents.

Eine weitere Fencing-Option ist die Verwendung von gemeinsam genutzten Azure-Datenträgern für das Fencing-Gerät. Auf SLES 15 SP1 oder SLES für SAP 15 SP1 und höher können Sie einen Pacemaker-Cluster mithilfe von gemeinsam genutzten Azure-Datenträgern einrichten. Diese Option ist einfach und erfordert keinen offenen Netzwerkport wie den Azure-Zaun-Agent.

Eine kürzlich unterstützte und einfachere Pacemaker-Konfiguration auf SLES 15 und höher ist HA SAP NetWeaver mit einfacher Montage und NFS auf SLES for SAP Applications VMs. In dieser Konfiguration werden die SAP-Dateifreigaben aus dem Clustermanagement herausgenommen, was die Bedienung vereinfacht. Verwenden Sie diese HA-Konfiguration für alle neuen Bereitstellungen.

Um die Kosten einer großen SAP-Landschaft weiter zu verwalten, unterstützt das Linux-Cluster die Multi-SID-Installation von ASCS auf Azure. Die Gemeinsame Nutzung eines Verfügbarkeitsclusters zwischen mehreren SAP-Systemen vereinfacht die SAP-Landschaft und reduziert die Betriebskosten.

Auf standard Load Balancer können Sie den HA-Port aktivieren und vermeiden, dass Lastenausgleichsregeln für viele SAP-Ports konfiguriert werden müssen. Wenn Sie beim Einrichten eines Load Balancers das Feature „Direct Server Return“ (DSR) aktivieren, können Serverantworten auf Clientanfragen den Load Balancer umgehen. Diese Funktion 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-Datenbankcluster empfehlen wir, dass Sie die DSR (Data Service Replication) aktivieren. Wenn VMs im Back-End-Pool eine öffentliche ausgehende Konnektivität erfordern, ist eine weitere Konfiguration erforderlich.

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 Hochverfügbarkeit erreichen, indem Sie den Datenverkehr innerhalb eines Pools von Anwendungsservern durch Lastverteilung steuern.

Datenbankschicht

Die Architektur in diesem Leitfaden stellt ein hochverfügbares SAP HANA-Datenbanksystem dar, das aus zwei Azure-VMs besteht. Die native Systemreplikationsfunktion der Datenbankebene 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 die HSR- als auch die Linux HAE-Erweiterung für Ihre Linux-Distribution. Linux HAE stellt Clusterdienste für HANA-Ressourcen bereit, erkennt Fehlerereignisse und koordiniert das Failover fehlerhafter Dienste auf einen fehlerfreien Knoten.

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 einzelnen Zone werden so behandelt, als ob sie sich in einer einzigen Update- oder Fehlerdomäne befinden. 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. Die maximale Entfernung zwischen Rechenzentren in diesen Zonen ist nicht gewährleistet. Um ein SAP-System mit mehreren Ebenen über Zonen hinweg bereitzustellen, müssen Sie die Netzwerklatenz innerhalb einer Zone und über gezielte Zonen hinweg kennen und wissen, wie sensibel Ihre bereitgestellten Anwendungen für 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 oder VM-Typen in den ausgewählten Zonen

Hinweis

Wir empfehlen keine Verfügbarkeitszonen für DR. Ein DR-Standort sollte mindestens 100 Meilen vom primären Standort entfernt sein, um Naturkatastrophen zu berücksichtigen. Der genaue Abstand zwischen Rechenzentren kann nicht garantiert werden.

Beispiel für eine aktive/passive 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 bei Bedarf aktiviert.

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 alle Komponenten dieses SAP-Systems in derselben Zone zusammengefasst sind, wird die Netzwerklatenz minimiert.

Beispiel für Aktiv/Aktiv-Bereitstellung

In einer aktiven/aktiven Bereitstellung werden zwei Sätze von Anwendungsservern in zwei Zonen erstellt. In jeder Zone sind zwei Anwendungsserver in jedem Satz aktiv. 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 haben möglicherweise eine längere Netzwerklatenz, wenn sie aufgrund des physischen Abstands zwischen den Zonen eine Verbindung mit den ASCS- und Datenbankdiensten herstellen.

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. Informationen zu DR-Strategien und Implementierungsinformationen finden Sie in der DR-Übersicht und in den Infrastrukturrichtlinien für SAP-Workloads und DR-Richtlinien für SAP-Anwendungen.

Hinweis

Wenn es eine regionale Katastrophe gibt, die ein Massenfailoverereignis für viele Azure-Kunden in einer Region verursacht, wird 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.

Um die verfügbare Ressourcenkapazität für eine DR-Region sicherzustellen, verwenden Sie die Reservierung der On-Demand-Kapazität. Azure ermöglicht Es Ihnen, Ihren Reserveinstanzrabatt mit Ihrer Kapazitätsreservierung zu kombinieren, um Die Kosten zu reduzieren.

Kostenaspekte

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

Weitere Informationen finden Sie unter Azure Well-Architected Framework-Kostenoptimierung.

Virtuelle Maschinen (VMs)

In dieser Architektur werden VMs mit Linux für die Verwaltungs-, SAP-Anwendungs- und die Datenbankschicht verwendet.

Es gibt verschiedene Zahlungsoptionen für VMs:

  • Für Arbeitslasten, die keine vorhersehbare Abschlusszeit oder keinen vorhersehbaren Ressourcenverbrauch haben, sollten Sie die Option der nutzungsbasierten Bezahlungin Betracht ziehen.

  • Erwägen Sie die Verwendung von Azure Reservations , wenn Sie sich für die Verwendung eines virtuellen Computers über einen Zeitraum von einem Jahr oder drei Jahren verpflichten können. VM-Reservierungen können Kosten erheblich reduzieren. Sie können im Vergleich zu nutzungsbasierter Bezahlung bis zu 72 % sparen.

  • Verwenden Sie Azure Spot-VMs , um Workloads auszuführen, die unterbrochen werden können und keinen Abschluss innerhalb eines vordefinierten Zeitrahmens oder SLA erfordern. 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 Spot-VMs sind niedriger als andere 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

  • Azure Reserved Virtual Machine Instances können Ihre Gesamtbetriebskosten reduzieren, indem Azure Reserved Virtual Machine Instances-Tarife mit einem kostenpflichtigen Abonnement kombiniert werden, sodass Sie Kosten über vorhersagbare und variable Workloads hinweg verwalten können. Weitere Informationen finden Sie unter Azure Reserved Virtual Machine Instances.

Eine Übersicht über die Preise finden Sie unter Den Preisen für virtuelle Linux-Computer.

Lastverteiler

In diesem Szenario werden Azure Load Balancers verwendet, um den Datenverkehr auf VMs im Anwendungsschicht-Subnetz zu verteilen.

Die Gebühren werden nur anhand der Anzahl von konfigurierten Lastenausgleichsregeln und Ausgangsregeln berechnet. Regeln für die Übersetzung eingehender Netzwerkadressen 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. Alle ausgehenden Datenübertragungen werden basierend auf einem vorausbestimmten Satz berechnet. Weitere Informationen finden Sie unter ExpressRoute – Preise.

Aspekte der Verwaltung und des Betriebs

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

Azure Center für SAP-Lösungen

Azure Center for SAP solutions ist eine End-to-End-Lösung, mit der Sie SAP-Systeme als einheitliche Workload in Azure erstellen und ausführen können und die eine nahtlosere Grundlage für Innovationen bietet. Das Azure Center für SAP-Lösungen bietet eine geführte Bereitstellungserfahrung, die die erforderlichen Compute-, Speicher- und Netzwerkkomponenten erstellt, die Sie zum Ausführen Ihres SAP-Systems benötigen. Anschließend können Sie die Installation der SAP-Software entsprechend den bewährten Methoden von Microsoft automatisieren. Sie können die Verwaltungsfunktionen sowohl für neue als auch für vorhandene Azure-basierte SAP-Systeme nutzen.

Datensicherung

Sie können SAP HANA-Daten auf viele Arten sichern. Nachdem Sie zu Azure migriert haben, verwenden Sie weiterhin vorhandene Sicherungslösungen, die Sie haben. 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 ist Backint-zertifiziert von SAP. Weitere Informationen finden Sie unter Azure Backup – Häufig gestellte Fragen und Unterstützungsmatrix für die Sicherung von SAP HANA-Datenbanken auf Azure-VMs.

Hinweis

Nur HANA Single-Container- oder Scale-up-Bereitstellungen unterstützen Azure Storage Snapshots.

Identitätsverwaltung

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

Überwachung

Verwenden Sie Azure Monitor, um die Verfügbarkeit und Leistung von Anwendungen und Diensten in Azure zu maximieren. Azure Monitor ist eine umfassende Lösung für das Sammeln und Analysieren von Telemetriedaten aus Ihren Cloud- und lokalen Umgebungen und das Reagieren auf diese. In Azure Monitor wird angezeigt, welches Leistungsverhalten Ihre Anwendungen aufweisen. Es werden proaktiv Probleme erkannt, die diese Anwendungen und die Ressourcen, von denen sie abhängen, betreffen. Informationen zu SAP-Anwendungen, die auf SAP HANA und anderen wichtigen Datenbanklösungen ausgeführt werden, finden Sie unter Azure Monitor für SAP-Lösungen. Hier erfahren Sie, wie Azure Monitor für SAP Ihnen helfen kann, die Verfügbarkeit und Leistung von SAP-Diensten zu verwalten.

Sicherheitsüberlegungen

SAP verfügt über ein eigenes Benutzerverwaltungsmodul, um den rollenbasierten Zugriff und die Autorisierung innerhalb der SAP-Anwendung und -Datenbanken zu steuern. Weitere Informationen finden Sie in der Sap HANA-Sicherheitsü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. Um die Datenübertragungskosten zu minimieren, stellen Sie aktive Front-End-Server bereit, die Fiori-Anwendungen im selben virtuellen Netzwerk wie die S/4-Systeme hosten. Alternativ können Sie diese Front-End-Server im Umkreisnetzwerk konfigurieren, wodurch virtuelles Netzwerk-Peering genutzt wird, um eine Verbindung mit den S/4-Systemen herzustellen.

Um die Sicherheit der Infrastruktur zu gewährleisten, sind die Daten während der Übertragung und im Ruhezustand verschlüsselt. Informationen zur Netzwerksicherheit, die für S/4HANA gilt, finden Sie unter Sicherheit für Ihre SAP-Landschaft.

Zum Verschlüsseln von Linux-VM-Datenträgern haben Sie mehrere Optionen. Für die SAP HANA-Verschlüsselung ruhender Daten empfehlen wir, die SAP HANA-native Verschlüsselungstechnologie zu verwenden. Unterstützung der Azure-Datenträgerverschlüsselung für bestimmte Linux-Verteilungen, -Versionen und -Images finden Sie unter Azure Disk Encryption für Linux-VMs.

Hinweis

Verwenden Sie keine HANA-Daten-at-Rest-Verschlüsselung und Azure Disk Encryption auf demselben Speichervolume. Verwenden Sie für HANA die HANA-Datenverschlüsselung über die serverseitige Azure-Datenträgerspeicherverschlüsselung. Die Verwendung von vom Kunden verwalteten Schlüsseln wirkt sich möglicherweise auf den E/A-Durchsatz aus.

Communitys

Communitys können Fragen beantworten und Sie beim Einrichten einer erfolgreichen Bereitstellung unterstützen. Sehen Sie sich bei Bedarf folgende Ressourcen an:

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

Um nichtöffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

Weitere Informationen und Beispiele für SAP-Workloads, die einige der gleichen Technologien wie diese Architektur verwenden, finden Sie in den folgenden Artikeln: