Ausführen von SAP NetWeaver unter Windows in Azure

ExpressRoute
SAP HANA in Azure (große Instanzen)
Virtual Machines
Virtual Network
Azure NetApp Files

Anhand dieser Referenzarchitektur werden einige bewährte Methoden veranschaulicht, wie SAP NetWeaver in einer Windows-Umgebung in Azure mit Hochverfügbarkeit ausgeführt werden kann. Die Datenbank ist AnyDB. „AnyDB“ ist der SAP-Begriff für alle unterstützten Datenbank-Managementsysteme (DBMS) neben SAP HANA.

Aufbau

Das erste Diagramm zeigt SAP NetWeaver in einer Windows-Umgebung in einem Verfügbarkeitsgruppenszenario. Die Architektur verwendet Azure NetApp Files für die Schicht freigegebener Dateien und eine Näherungsplatzierungsgruppe für verbesserte Leistung:

Diagram that shows a reference architecture for SAP NetWeaver on Windows. The database is AnyDB on Azure VMs with availability sets.

Laden Sie eine Visio-Datei mit dieser Architektur herunter.

Das zweite Diagramm zeigt SAP NetWeaver in einer Windows-Umgebung. Verfügbarkeitszonen werden zur Verbesserung der Resilienz verwendet:

Diagram that shows a reference architecture for SAP NetWeaver on Windows. The database is AnyDB on Azure VMs with Availability Zones.

Laden Sie eine Visio-Datei mit dieser Architektur herunter.

Hinweis

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

Diese Referenzarchitektur beschreibt ein Produktionssystem. Sie wird mit virtuellen Computern bestimmter Größen bereitgestellt, die an die Anforderungen Ihres Unternehmens angepasst werden können. Sie kann auf eine einzelne VM reduziert werden. Das Netzwerklayout wurde stark vereinfacht, um die Architekturprinzipale zu demonstrieren. Es dient nicht dazu, ein gesamtes Unternehmensnetzwerk zu beschreiben.

Workflow

Die folgenden Komponenten kommentieren den Workflow dieser Architektur:

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

Peering virtueller Netzwerke. Für diese Architektur wird eine Hub-and-Spoke-Netzwerktopologie mit mehreren virtuellen Netzwerken verwendet, die per Peering verbunden sind. Diese Topologie bietet Netzwerksegmentierung und -isolierung für Dienste, die in Azure bereitgestellt werden. Peering ermöglicht eine transparente Konnektivität zwischen den gepeerten virtuellen Netzwerken über das Microsoft-Backbone-Netzwerk. Es verursacht keine Leistungseinbußen, wenn es innerhalb einer einzelnen Region bereitgestellt wird. Das virtuelle Netzwerk wird für jede Schicht in getrennte Subnetze unterteilt: Anwendung (SAP NetWeaver), die Datenbank und gemeinsame Dienste (wie Jumpbox und Active Directory).

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

  • SAP NetWeaver: Auf der Logikschicht werden virtuelle Windows-Computer verwendet, um SAP Central Services und SAP-Anwendungsserver auszuführen. Die VMs, auf denen Central Services ausgeführt wird, sind als Windows Server-Failovercluster (WSFC) für Hochverfügbarkeit konfiguriert. Sie werden entweder von Azure-Dateifreigaben (AFS) oder freigegebenen Azure-Datenträgern unterstützt.

  • AnyDB: Auf der Datenbankschicht wird AnyDB als Datenbank ausgeführt, z. B. Microsoft SQL Server, Oracle oder IBM DB2.

  • Jumpbox (auch Bastionhost genannt). Administratoren verwenden diesen virtuellen Computer mit verbesserter Sicherheit, um eine Verbindung mit den anderen virtuellen Computern herzustellen. Es ist normalerweise ein Teil von gemeinsam genutzten Diensten wie Domänencontrollern und Sicherungsdiensten. Falls nur das Secure Shell-Protokoll (SSH) und das Remotedesktopprotokoll (RDP) als Dienste für die Serververwaltung genutzt werden, ist ein Azure Bastion-Host eine Alternative. Wenn Sie aber andere Verwaltungstools verwenden, z. B. SQL Server Management Studio oder das SAP-Front-End, verwenden Sie eine herkömmliche selbstbereitgestellte Jumpbox.

  • Windows Server Active Directory-Domänencontroller: Die Domänencontroller werden für die Identitätsverwaltung aller virtuellen Computer und Benutzer in der Domäne verwendet.

Lastenausgleichsmodule: Lastenausgleichsmodule werden verwendet, um Datenverkehr auf virtuelle Computer im Subnetz der Logikschicht zu verteilen. Für Hochverfügbarkeit verwenden Sie den integrierten SAP Web Dispatcher, Azure Load Balancer oder Netzwerkgeräte. Ihre Wahl hängt von der Art des Datenverkehrs (z. B. HTTP oder SAP GUI) oder den erforderlichen Netzwerkdiensten ab, wie z. B. Secure Sockets Layer (SSL)-Terminierung. Bei der Integration von Azure Load Balancer in eine zonale Bereitstellung von SAP muss der Lastenausgleich der Standard-SKU ausgewählt werden, da der Lastenausgleich der Basic-SKU nicht über Zonenredundanz verfügt.

Verfügbarkeitsgruppen: Die VMs für alle Pools und Cluster (Web Dispatcher, SAP-Anwendungsserver, Central Services und Datenbanken) werden in getrennten Verfügbarkeitsgruppen gruppiert. Pro Rolle werden mindestens zwei virtuelle Computer bereitgestellt. Verfügbarkeitsgruppen erhöhen die Verfügbarkeit der Anwendungen und VMs. Sie tun dies durch die Verwaltung von Hostsystemfehlern oder Wartungsereignissen, indem sie Rolleninstanzen auf mehrere Hosts verteilen. Eine Alternative ist die Nutzung von Verfügbarkeitszonen zur Verbesserung der Verfügbarkeit von Workloads, wie weiter unten in diesem Artikel beschrieben.

Zonenredundantes Gateway: Azure ExpressRoute- oder VPN-Gateways können zonenübergreifend bereitgestellt werden, um den Schutz vor Zonenausfällen zu ermöglichen. Informationen zu den Unterschieden zwischen einer zonenorientierten und zonenredundanten Bereitstellung finden Sie unter Zonenredundante Gateways für virtuelle Netzwerke. Hinweis: Für eine Zonenbereitstellung der Gateways müssen die verwendeten IP-Adressen von der Standard-SKU stammen.

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, erstellen Sie Netzwerksicherheitsgruppen.

Anwendungssicherheitsgruppen: Verwenden Sie Anwendungssicherheitsgruppen anstelle von expliziten IP-Adressen, um detaillierte Netzwerksicherheitsrichtlinien basierend auf Workloads zu definieren, die auf Anwendungen ausgerichtet sind. Hiermit können Sie VMs 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 virtuelle Azure-Netzwerk zu erweitern. Wir empfehlen, dass Sie ExpressRoute verwenden, um private Verbindungen zu erstellen, die nicht über das öffentliche Internet gehen, aber Sie können auch eine Site-to-Site-Verbindung verwenden. Zur Verringerung der Wartezeit oder zur Erhöhung des Durchsatzes können Sie erwägen, ExpressRoute Global Reach und ExpressRoute FastPath zu verwenden, wie weiter unten in diesem Artikel beschrieben.

„Azure Storage“. Azure Storage bietet Datenpersistenz für einen virtuellen Computer in Form einer virtuellen Festplatte (VHD). Wir empfehlen Azure Managed Disks.

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.

Ausführliche Informationen zur SAP-Unterstützung für die Typen virtueller Azure-Computer und die Durchsatzmetriken (SAPS) finden Sie in SAP-Hinweis 1928533. (Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto.)

SAP Web Dispatcher (SWD)

Die Web Dispatcher-Komponente wird als Lastenausgleichsmodul für SAP-Datenverkehr zwischen den SAP-Anwendungsservern verwendet. Zur Erzielung von Hochverfügbarkeit für die Web Dispatcher-Komponente wird Azure Load Balancer verwendet, um entweder den Failovercluster von SWDs oder das parallele SWD-Setup zu implementieren. Eine ausführliche Beschreibung der Lösung finden Sie unter Hochverfügbarkeit von SAP Web Dispatcher.

Anwendungsserverpool

Die SAP-SMLG-Transaktion wird häufig verwendet, um Anmeldegruppen für ABAP-Anwendungsserver zu verwalten und den Lastenausgleich für Anmeldebenutzer durchzuführen. Mit anderen Transaktionen wie SM61 für Batchservergruppen und RZ12 für RFC-Gruppen wird der Lastenausgleich auch für Anmeldebenutzer durchgeführt. Bei diesen Transaktionen wird die Lastenausgleichsfunktion auf dem Nachrichtenserver von SAP Central Services genutzt, um eingehende Sitzungen oder Workloads auf SAP-Anwendungsserverpools für SAP GUIs und RFC-Datenverkehr zu verteilen.

SAP Central Services-Cluster

In dieser Referenzarchitektur wird Central Services auf virtuellen Computern auf der Logikschicht ausgeführt. Bei der Bereitstellung auf nur einer VM kann Central Services ggf. einen Single Point of Failure darstellen. Für eine Hochverfügbarkeitslösung muss entweder ein Dateifreigabecluster oder ein Datenträgerfreigabe-Cluster verwendet werden.

Für hochverfügbare Dateifreigaben gibt es mehrere Optionen. Wir empfehlen, dass Sie Azure Files-Freigaben als vollständig verwaltete, cloudnative SMB- oder NFS-Freigaben verwenden. Eine Alternative zu Azure Files ist Azure NetApp Files, das Hochleistungs-NFS- und SMB-Freigaben bietet.

Sie können die hochverfügbaren Dateifreigaben auf den Central Service-Instanzen implementieren, indem Sie WSFC mit (Azure Files) verwenden. Diese Lösung unterstützt auch Windows-Cluster mit freigegebenen Datenträgern, indem ein freigegebener Azure-Datenträger als freigegebenes Clustervolumen (CSV) verwendet wird. Wenn Sie lieber freigegebene Datenträger verwenden möchten, empfiehlt es sich, einen Windows Server-Failovercluster für den SAP Central Services-Cluster mithilfe von freigegebenen Azure-Datenträgern einzurichten.

Es gibt auch Produkte von Drittanbietern wie SIOS DataKeeper Cluster Edition von SIOS Technology Corp. Dieses Add-On repliziert den Inhalt unabhängiger Datenträger, die an die ASCS-Clusterknoten angefügt sind, und stellt anschließend die Datenträger für die Clustersoftware als freigegebene Clustervolumes bereit.

Bei der Partitionierung des Clusternetzwerks wird von der Clustersoftware per Quorumabstimmung ermittelt, welche Segmente des Netzwerks und der zugehörigen Dienste quasi als „Gehirn“ des Clusters dienen, das fragmentiert wurde. Unter Windows sind einige Quorum-Modelle verfügbar. Diese Lösung verwendet einen Azure-Cloudzeugen, weil dies einfacher ist und höhere Verfügbarkeit bietet als ein Computeknotenzeuge. Der Azure-Dateifreigabezeuge ist eine weitere Alternative, um eine Quorumabstimmung für Cluster durchzuführen.

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

Verfügbarkeitsgruppen

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

Alle virtuellen Computer in einer Gruppe müssen dieselbe Rolle ausführen. Mischen Sie keine Server mit unterschiedlichen Rollen in derselben Verfügbarkeitsgruppe. 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

Bei dieser Architektur wird eine Hub-Spoke-Topologie verwendet. Das virtuelle Hubnetzwerk fungiert als zentraler Konnektivitätspunkt für ein lokales Netzwerk. Die „Speichen“ (Spokes) sind virtuelle Netzwerke, die eine Peeringverbindung mit dem Hub herstellen und die Isolation von Workloads bewirken. Der Datenverkehr wird über eine Gatewayverbindung zwischen dem lokalen Rechenzentrum und dem Hub weitergeleitet.

Netzwerkschnittstellenkarten (NICs)

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

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

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

Subnetze und Netzwerksicherheitsgruppen

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

Bei der Zuordnung zu einem Subnetz gilt eine Netzwerksicherheitsgruppe für alle Server des Subnetzes und ermöglicht die detaillierte Steuerung der Server. Richten Sie sie mithilfe des Azure-Portals, der PowerShell oder der Azure CLI ein.

ExpressRoute Global Reach

Wenn Ihre Netzwerkumgebung zwei oder mehr ExpressRoute-Verbindungen umfasst, kann Ihnen ExpressRoute Global Reach helfen, Netzwerkhops und Wartezeiten zu reduzieren. Diese Technologie ist die Einrichtung eines Peerings der BGP-Route zwischen mindestens zwei ExpressRoute-Verbindungen, um zwei ExpressRoute-Routingdomänen zu überbrücken. Global Reach verringert die Wartezeit, wenn der Netzwerkverkehr mehr als eine ExpressRoute-Verbindung durchläuft. Es ist derzeit nur für privates Peering mit ExpressRoute-Leitungen verfügbar.

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

ExpressRoute FastPath

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

Für alle neuen ExpressRoute-Verbindungen mit Azure ist FastPath die Standardkonfiguration. Wenden Sie sich wegen vorhandener ExpressRoute-Leitungen an den Azure-Support, um FastPath zu aktivieren.

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

Load Balancer

SAP Web Dispatcher verwaltet den Lastenausgleich von HTTP(S)-Datenverkehr in einem Pool von SAP-Anwendungsservern. Dieser Softwarelastenausgleich bietet Anwendungsschichtdienste (im ISO-Netzwerkmodell als „Schicht 7“ bezeichnet), die SSL-Beendigung und andere Abladungsfunktionen ausführen können.

Azure Load Balancer ist ein Dienst auf der Netzwerkübertragungsschicht (Schicht 4), der den Datenverkehr mithilfe eines aus den Datenströmen berechneten 5-Tupel-Hashs ausgleicht. (Der Hash basiert auf Quell-IP, Quellport, Ziel-IP, Zielport und Protokolltyp.) In SAP-Bereitstellungen in Azure wird Load Balancer in Clustereinrichtungen verwendet, um den Datenverkehr zur primären Dienstinstanz oder zum fehlerfreien Knoten zu leiten, wenn ein Fehler auftritt.

Wir empfehlen Ihnen, Azure Load Balancer Standard für alle SAP-Szenarien zu verwenden. Wenn für virtuelle Computer im Back-End-Pool öffentliche ausgehende Verbindungen erforderlich sind, oder wenn sie in einer Azure-Zonenbereitstellung verwendet werden, sind für die Load Balancer Standard-Instanzen zusätzliche Konfigurationen erforderlich, da sie standardmäßig gesichert sind. Sie lassen keine ausgehenden Verbindungen zu, es sei denn, Sie konfigurieren sie explizit.

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-Anmeldegruppen. Sie benötigen dafür keinen weiteren Lastenausgleich.

Azure Storage

Einige Organisationen verwenden den Standardspeicher für ihre Anwendungsserver. Managed Disks Standard werden nicht unterstützt. Weitere Informationen finden Sie im SAP-Hinweis 1928533. (SAP Service Marketplace-Konto erforderlich.) Wir empfehlen, in jedem Fall Azure Managed Disks Premium zu verwenden. Beachten Sie, dass durch ein vor Kurzem durchgeführtes Update an SAP-Hinweis 2015553 die Verwendung von HDD Standard-Speicher und SSD Standard-Speicher für einige spezielle Anwendungsfälle nicht mehr möglich ist.

Anwendungsserver hosten keine Geschäftsdaten. So können Sie auch die kleineren P4- und P6-Premium-Datenträger verwenden, um Kosten zu minimieren. Auf diese Weise können Sie auch von der SLA für Einzelinstanz-VMs profitieren, wenn Sie eine zentrale SAP-Stapelinstallation haben.

Für Hochverfügbarkeitsszenarios können Sie Azure-Dateifreigaben und freigegebene Azure-Datenträger verwenden. Verwaltete SSD Premium- und SSD Ultra-Azure-Datenträger sind für freigegebene Azure-Datenträger und SSD Premium für Azure-Dateifreigaben verfügbar.

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 bieten kostengünstige Möglichkeiten zum Speichern langlebiger Daten, auf die eher selten zugegriffen wird.

Mit Ultra-Datenträgern wird die Datenträgerlatenz deutlich reduziert, und es ergeben sich Vorteile für Anwendungen mit hohen Leistungsanforderungen, z. B. SAP-Datenbankserver. Vergleichen Sie hierzu die Optionen für Blockspeicher in Azure.

Verwenden Sie für einen hochverfügbaren, hochleistungsfähigen freigegebenen Datenspeicher Azure NetApp Files. Diese Technologie ist insbesondere für die Datenbankschicht nützlich, wenn Sie Oracle verwenden, und wenn Sie Anwendungsdaten hosten.

Überlegungen zur Leistung

SAP-Applikationsserver kommunizieren ständig mit den Datenbankservern. Für leistungskritische Anwendungen, die auf Datenbankplattformen ausgeführt werden, aktivieren Sie die Schreibbeschleunigung für das Protokollvolume. Dadurch können sich die Wartezeiten der Protokollschreibvorgänge verbessern. Die Schreibbeschleunigung ist für VMs der M-Serie verfügbar. Um die serverübergreifende Kommunikation zu optimieren, verwenden Sie den beschleunigten Netzwerkbetrieb. Der beschleunigte Netzwerkbetrieb ist nur für unterstützte VM-Serien verfügbar, z. B. D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 und Ms/Mms. Weitere Informationen finden Sie unter Maximieren der Leistung Ihres virtuellen Computers mit beschleunigtem Netzwerkbetrieb.

Um hohe IOPS und einen hohen Datenträgerdurchsatz zu erreichen, gelten für das Azure-Speicherlayout die gängigen Vorgehensweisen zur Leistungsoptimierung für Speichervolumes. Sie können beispielsweise mehrere Datenträger kombinieren, um ein Stripeset-Datenträgervolume zu erstellen und so die E/A-Leistung zu verbessern. Eine Aktivierung des Lesecaches für Speicherinhalte, die sich in unregelmäßigen Abständen ändern, bewirkt eine höhere Geschwindigkeit beim Datenabruf.

Ultra-Datenträger sind jetzt für E/A-Anwendungen verfügbar. Wenn sie verfügbar sind, empfehlen wir ihre Verwendung anstelle von Premium-Speicher mit Schreibbeschleunigung. Sie können Leistungsmetriken wie IOPS und MBps individuell erhöhen oder verringern, ohne dass ein Neustart erforderlich ist.

Für SAP in Azure bietet Azure Virtual Machines – Planung und Implementierung für SAP NetWeaver hervorragende Ratschläge zur Optimierung von Azure-Speicher für SAP-Workloads unter SQL Server.

Wir empfehlen nicht, virtuelle Netzwerkgeräte (Network Virtual Appliances, NVAs) für SAP-Anwendungsstapel zwischen den Anwendungs- und Datenbankschichten anzuordnen. Diese Vorgehensweise führt zu einer erheblichen Verarbeitungsdauer für Datenpakete und somit zu einer inakzeptablen Anwendungsleistung.

Näherungsplatzierungsgruppen

Einige SAP-Anwendungen müssen häufig mit der Datenbank kommunizieren. Die physische Nähe der Anwendungs- und Datenbankschichten zueinander wirkt sich auf die Netzwerklatenz aus, und hierdurch kann die Anwendungsleistung negativ beeinflusst werden.

Zur Optimierung der Netzwerklatenz können Sie Näherungsplatzierungsgruppen verwenden, mit denen für die in Verfügbarkeitsgruppen bereitgestellten virtuellen Computer eine logische Einschränkung festgelegt wird. Bei Näherungsplatzierungsgruppen haben „Zusammenstellung“ (Co-Location) und Leistung Vorrang vor Skalierbarkeit, Verfügbarkeit und Kosten. Sie können eine deutliche Verbesserung der Benutzererfahrung für die meisten SAP-Anwendungen bewirken. Skripts finden Sie auf GitHub.

Verfügbarkeitszonen

Verfügbarkeitszonen ermöglichen Ihnen die zonenübergreifende Bereitstellung virtueller Computer. Das heißt physisch getrennte Orte innerhalb einer bestimmten Azure-Region. Der Zweck ist die Verbesserung der Dienstverfügbarkeit, aber Sie sollten beim Bereitstellen von Ressourcen in Zonen immer auch die Leistung im Blick behalten.

Administratoren benötigen ein eindeutiges Netzwerklatenzprofil zwischen allen Zonen einer Zielregion, bevor sie die Ressourcenanordnung mit möglichst geringer Latenz zwischen Zonen bestimmen können. Stellen Sie zur Erstellung dieses Profils in jeder Zone zu Testzwecken virtuelle Computer bereit. Empfohlene Tools für diese Tests sind beispielsweise PsPing und Iperf. Wenn die Tests abgeschlossen sind, entfernen Sie die virtuellen Computer, die Sie für die Tests verwendet haben. Alternativ steht auch ein Tool zur Überprüfung der Wartezeit zwischen Azure-Zonen zur Verfügung.

Überlegungen zur Skalierbarkeit

Für die 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-Anwendungen in Azure: Unterstützte Produkte und Azure-VM-Typen“. (Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto.)

Sie können SAP-Anwendungsserver und die Central Services-Cluster hoch-, herunter- oder aufskalieren, indem Sie weitere Instanzen hinzufügen. Die AnyDB-Datenbank kann hoch- und herunterskaliert, aber nicht aufskaliert werden. Der SAP-Datenbankcontainer für AnyDB unterstützt kein Sharding.

Überlegungen zur Verfügbarkeit

Ressourcenredundanz ist das allgemeine Thema bei Infrastrukturlösungen mit Hochverfügbarkeit. Für Unternehmen mit weniger strengen SLAs ist für virtuelle Azure-Einzelinstanzcomputer mit Premium-Datenträgern eine Betriebszeit-SLA verfügbar. Wenn Sie redundante Ressourcen in einer Verfügbarkeitsgruppe oder übergreifend in Verfügbarkeitszonen bereitstellen, erhöht sich die Dienstverfügbarkeit.

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

Web Dispatcher auf Anwendungsserverschicht

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 empfehlen wir eine eigenständige Lösung im Umkreisnetzwerk (auch als DMZ bezeichnet), um Sicherheitsanforderungen zu erfüllen.

Embedded Web Dispatcher auf ASCS ist eine besondere Option. Sie sollten wegen der zusätzlichen Workload auf ASCS eine ausreichende Dimensionierung berücksichtigen.

Central Services auf Anwendungsserverschicht

Die Hochverfügbarkeit von Central Services wird mit WSFC implementiert. Wenn der Clusterspeicher für den Failovercluster in Azure bereitgestellt wird, können Sie ihn auf zwei Arten konfigurieren: als freigegebener Clusterdatenträger oder als Clusterdateifreigabe.

  1. Wir empfehlen, dass Sie Azure Files als vollständig verwaltete, cloudnative SMB- oder NFS-Freigaben verwenden. Eine weitere Möglichkeit besteht darin, Azure NetApp Files zu verwenden, das hochleistungsfähige NFS- und SMB-Freigaben auf Unternehmensniveau bietet.

  2. Ein Cluster kann auf zwei Arten mit freigegebenen Datenträgern in Azure eingerichtet werden. Zunächst empfiehlt es sich, einen Windows Server-Failovercluster für SAP Central Services mithilfe von freigegebenen Azure-Datenträgern einzurichten. Mit SAP ASCS-Cluster mit freigegebenen Azure-Datenträgern steht ein Implementierungsbeispiel zur Verfügung. Eine weitere Möglichkeit zum Implementieren eines freigegebenen Clusterdatenträgers ist die Verwendung von SIOS DataKeeper, um folgende Aufgaben auszuführen:

    • Replizieren des Inhalts von unabhängigen Datenträgern, die an die Clusterknoten angefügt sind.
    • Abstrahieren der Laufwerke als freigegebenes Clustervolume für den Cluster-Manager.

    Implementierungsdetails finden Sie unter Clustering von SAP ASCS in Azure mit SIOS.

Dank der Einführung der Azure Load Balancer Standard-SKU können Sie jetzt einfach den Hochverfügbarkeitsport aktivieren. Auf diese Weise können Sie vermeiden, Lastenausgleichsregeln für viele SAP-Ports konfigurieren zu müssen. Außerdem können Sie, wenn Sie Lastenausgleichsmodule allgemein einrichten (ob lokal oder in Azure), das Feature „Direct Server Return“ (auch als Floating IP oder DSR bezeichnet) aktivieren. Auf diese Weise können Serverantworten den Load Balancer umgehen. Diese direkte Verbindung verhindert, dass der Lastenausgleich zu einem Engpass auf dem Datenübertragungspfad wird. Für die SAP ASCS- und Datenbankcluster empfehlen wir, dass Sie DSR aktivieren.

Anwendungsdienste auf Anwendungsserverschicht

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

Datenbankschicht

Für diese Referenzarchitektur haben wir angenommen, dass die Quelldatenbank auf AnyDB ausgeführt wird. Das heißt ein DBMS wie SQL Server, SAP ASE, IBM DB2 oder Oracle. Die native Replikationsfunktion der Datenbankschicht bietet entweder manuelles oder automatisches Failover zwischen replizierten Knoten.

Implementierungsdetails zu bestimmten Datenbanksystemen finden Sie unter Azure Virtual Machines – DBMS-Bereitstellung für SAP NetWeaver.

In Verfügbarkeitszonen bereitgestellte virtuelle Computer

Verfügbarkeitszonen sind ein logisches Konstrukt, das konzipiert wurde, um die Verfügbarkeit von Workloads zu verbessern und die Anwendungsdienste und virtuellen 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 Sie die Zonenbereitstellung auswählen, 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 allerdings nicht garantiert. Für die zonenübergreifende Bereitstellung eines SAP-Systems mit mehreren Ebenen müssen Sie die Netzwerkwartezeit innerhalb einer Zone und für die Zielzonen kennen. Ferner müssen Sie wissen, wie empfindlich Ihre bereitgestellten Anwendungen in Bezug auf die Netzwerkwartezeit sind.

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

  • Wartezeit 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 regionale Hochverfügbarkeit, sind aber für die Notfallwiederherstellung nicht effektiv. Die Abstände zwischen den Zonen sind zu kurz. Regionen für die Notfallwiederherstellung sollten normalerweise mindestens 160 km von der primären Region entfernt sein.

Beispiel für Aktiv/Inaktiv-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 Datenbankdienste 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 nun 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 Servergruppe inaktiv (heruntergefahren). Es gibt also in beiden Zonen während des Normalbetriebs aktive Anwendungsserver.

Central Services 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 Netzwerkwartezeit beim Herstellen der Verbindung mit Central Services und den Datenbankdiensten.

Wenn Zone 1 in den Offlinezustand versetzt wird, wird für Central Services und die Datenbankdienste ein Failover in Zone 2 ausgeführt. Sie können die ruhenden Anwendungsserver in den Onlinezustand versetzen, um die vollständige Kapazität für die Anwendungsverarbeitung bereitzustellen.

Überlegungen zur Notfallwiederherstellung

Für jede Ebene des SAP-Anwendungsstapels wird eine andere Strategie für die Notfallwiederherstellung verwendet.

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 Sie dieselben Änderungen auf die virtuellen Computer in der sekundären Region anwenden. Kopieren Sie z. B. die ausführbaren Dateien des SAP-Kernels auf die virtuellen Computer für die Notfallwiederherstellung.

Sollen Anwendungsserver automatisch in einer sekundären Region repliziert werden, empfehlen wir hierfür Azure Site Recovery. Sie können Azure Site Recovery auch verwenden, um die Notfallwiederherstellung für die Bereitstellung einer SAP NetWeaver-Anwendung mit mehreren Ebenen einzurichten.

Central Services

Bei dieser Komponente des SAP-Anwendungsstapels werden keine Geschäftsdaten beibehalten. Für einen regionsübergreifenden DR-Schutz replizieren Sie die AFS-SMB-Dateifreigabe oder den freigegebenen Azure-Datenträger Ihres ASCS-Clusters, der das Verzeichnis „/sapmnt“ und andere Inhalte enthält, auf einer entsprechenden AFS-SMB-Freigabe oder auf einem Datenträger in der DR-Region. Wenn Sie SIOS verwenden, können Sie Site Recovery verwenden, um den Central Services-Cluster mit SIOS DataKeeper-Datenträgern zu replizieren.

Wenn Sie Ihren eigenen Replikationsprozess erstellen, ohne irgendwelche Tools zu verwenden, können Sie einen virtuellen Computer in der DR-Region erstellen, um die Rolle und den Inhalt der Central Services zu replizieren. Der einzige Inhalt, der vom primären Central Services-Knoten synchronisiert wird, ist die Freigabe „/sapmnt“. Wenn sich die Konfiguration ändert oder auf den primären Central Services-Servern Kernelupdates durchgeführt werden, müssen Sie die Änderungen auch auf dem virtuellen Computer in der Region für die Notfallwiederherstellung vornehmen. Ausführliche Informationen zum Erstellungs-, Kopier- und Testfailoverprozess für diese Replikationsmethode erhalten Sie, indem Sie den Artikel SAP NetWeaver: Building a Hyper-V and Microsoft Azure-based Disaster Recovery Solution (SAP NetWeaver: Erstellen einer Lösung für die Notfallwiederherstellung auf Basis von Hyper-V und Microsoft Azure) herunterladen. Siehe „4.3. SAP SPOF layer (ASCS)“ (4.3. SAP-SPOF-Schicht (ASCS)) nachsehen.

Datenbankschicht

Am besten verwenden Sie die integrierte Replikationstechnologie einer Datenbank für die Notfallwiederherstellung. Für SQL Server empfehlen wir Ihnen beispielsweise die Verwendung von Always On-Verfügbarkeitsgruppen, um ein Replikat in einer Remoteregion einzurichten und Transaktionen asynchron mit manuellem Failover zu replizieren. Asynchrone Replikation vermeidet Auswirkungen auf die Leistung von interaktiven Workloads am primären Standort. Wenn Sie ein manuelles Failover verwenden, können Sie dann die Auswirkungen der Notfallwiederherstellung evaluieren, und es kann die Entscheidung getroffen werden, ob der Betrieb vom Notfallwiederherstellungsstandort aus gerechtfertigt ist.

Wenn Sie Azure NetApp Files für Ihren Datenbankspeicher verwenden, sind Sie möglicherweise in der Lage, die regionsübergreifende Replikation zum Replizieren von Daten in eine sekundäre Region zu verwenden. Diese Funktion befindet sich derzeit in der Vorschauphase, weshalb Sie prüfen sollten, ob sie Ihren Anforderungen für Produktionsworkloads entspricht.

Notfallwiederherstellung für gemeinsame Dienste

Viele IT-Dienste, z. B. Jumpboxes für die Verwaltung, cloudbasierte Verzeichnisdienste, Sicherung und Überwachungsdienste, werden von allen Ihren bereitgestellten Cloudressourcen gemeinsam verwendet. 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. Beispielsweise stellt Site Recovery zunächst die virtuellen Computer in Verfügbarkeitsgruppen bereit. 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 zu einem Failover-Massenereignis für viele Azure-Kunden in einer Region führt, ist die Kapazität der Ressource in der Zielregion nicht garantiert. Wie bei allen Azure-Diensten werden auch die Features und Funktionen für Site Recovery ständig verbessert. Die aktuelle Supportmatrix enthält Informationen zur Notfallwiederherstellung von virtuellen Azure-Computern aus einer Azure-Region in einer anderen.

Aspekte der Verwaltung und des Betriebs

Backup

Datenbanken sind kritische Workloads, für die ein niedriger RPO-Wert (Recovery Point Objective) und eine Langzeitaufbewahrung erforderlich sind.

  • Für SAP unter SQL Server besteht ein Ansatz darin, Azure Backup zum Sichern von SQL Server-Datenbanken zu nutzen, die auf virtuellen Computern ausgeführt werden. Eine weitere Möglichkeit ist die Verwendung von Azure Files-Momentaufnahmen zum Sichern von SQL Server-Datenbankdateien.

  • Informationen zu SAP unter Oracle/Windows finden Sie im Abschnitt „Sichern/Wiederherstellen“ unter Azure Virtual Machines – DBMS-Bereitstellung für SAP-Workload.

  • Lesen Sie für andere Datenbanken in den Sicherungsempfehlungen Ihres Datenbankanbieters nach. Wenn die Datenbank den Windows-Volumeschattenkopie-Dienst (VSS) unterstützt, dann anwendungskonsistente Sicherungen mithilfe von VSS-Momentaufnahmen

Identitätsverwaltung

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

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

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

Ermöglichen Sie Zugriff in den Anwendungen selbst über die Dienste, die SAP bereitstellt. Oder verwenden Sie OAuth 2.0 und Azure Active Directory.

Überwachung

Azure Monitor bietet ausgefeilte Tools zum Sammeln und Analysieren von Telemetriedaten. Diese Tools helfen Ihnen, die Leistung und Verfügbarkeit Ihrer lokalen Ressourcen und Anwendungen und diese in der Cloud zu maximieren. (Azure Monitor umfasst jetzt Log Analytics und Application Insights.) Sie können Azure Monitor verwenden, um Infrastruktur- und Anwendungsanomalien zu überwachen, Administratoren zu benachrichtigen und Reaktionen auf vordefinierte Bedingungen zu automatisieren.

Verwenden Sie die Azure-Erweiterung für die „Erweiterte Überwachung“ von SAP, um die SAP-basierte Überwachung von Ressourcen und Leistung von Diensten für die SAP-Infrastruktur durchzuführen. Mit dieser Erweiterung werden statistische Daten zur Azure-Überwachung in die SAP-Anwendung eingespeist, damit die Betriebssystemüberwachung und DBA Cockpit-Funktionen ermöglicht werden. Die erweiterte Überwachung von SAP ist für die Ausführung von SAP in Azure erforderlich. Details finden Sie im SAP-Hinweis 2191498, „SAP unter Linux mit Azure: Erweiterte Überwachung“. (Für den Zugriff auf SAP-Hinweise benötigen Sie ein SAP Service Marketplace-Konto.)

Azure Monitor für SAP-Lösungen sind die Zukunft für eine Azure-native End-to-End-Überwachungslösung für SAP NetWeaver. Diese Lösung befindet sich derzeit in der Vorschauphase und ist nur in einer begrenzten Anzahl von Regionen verfügbar. Sie sollten sorgfältig prüfen, ob sie Ihren Anforderungen entspricht.

Azure Monitor für SAP-Lösungen bieten einen umfassenden ersten Satz von Metriken und Telemetriedaten für die Überwachung. Die Metrikdefinitionen werden als SQL-Abfragen in JSON gespeichert. Sie können sie gemäß Ihren Anforderungen ändern. Sie können den Startsatz von Metriken auf GitHub abrufen.

Sicherheitsüberlegungen

SAP verfügt über ein eigenes Modul für die Benutzerverwaltung (User Management Engine, UME), um den rollenbasierten Zugriff und die Autorisierung in der SAP-Anwendung und den Datenbanken zu steuern. Eine ausführliche Anleitung zur Anwendungssicherheit finden Sie im Sicherheitsleitfaden zu SAP NetWeaver.

Um zusätzliche Netzwerksicherheit zu erzielen, sollten Sie erwägen, ein Umkreisnetzwerk zu verwenden, das ein virtuelles Netzwerkgerät (NVA) nutzt, um eine Firewall vor dem Subnetz für Web Dispatcher zu erstellen.

Sie können ein virtuelles Netzwerkgerät (NVA) bereitstellen, um Datenverkehr zwischen virtuellen Netzwerken zu filtern, aber Sie sollten es nicht zwischen der SAP-Anwendung und der Datenbank anordnen. Überprüfen Sie auch die Routingregeln, die im Subnetz konfiguriert sind, und vermeiden Sie es, Datenverkehr an eine Einzelinstanz-NVA zu leiten. Dies kann zu Ausfallzeiten aufgrund von Wartungsvorgängen und zu Netzwerk- oder Clusterknotenfehlern führen.

Um die Sicherheit der Infrastruktur zu gewährleisten, sind die Daten während der Übertragung und im Ruhezustand verschlüsselt. Im Abschnitt „Sicherheitsempfehlungen“ des Artikels Planung und Implementierung von Azure Virtual Machines für SAP NetWeaver wird die Netzwerksicherheit behandelt. In diesem Artikel sind auch die Netzwerkports angegeben, die Sie in den Firewalls öffnen müssen, um die Anwendungskommunikation zu ermöglichen.

Um Datenträger eines virtuellen Windows-Computers zu verschlüsseln, können Sie Azure Disk Encryption verwenden. Dieser Dienst verwendet das BitLocker-Feature von Windows, 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 Verschlüsselung von ruhenden Daten werden per SQL Server Transparent Data Encryption (TDE) SQL Server-, Azure SQL-Datenbank- und Azure SQL Data Warehouse-Datendateien verschlüsselt. Weitere Informationen finden Sie unter Azure Virtual Machines – SQL Server-DBMS-Bereitstellung für SAP NetWeaver.

Erwägen Sie die Bereitstellung von Microsoft Sentinel (in der Vorschauversion), um Bedrohungen innerhalb und außerhalb der Firewall zu überwachen. Die Lösung bietet kontinuierliche Bedrohungserkennung und Analysen für SAP-Systeme, die in Azure, in anderen Clouds oder lokal bereitgestellt werden. Hier finden Sie ihren Bereitstellungsleitfaden.

Stellen Sie wie immer sicher, dass Sie Sicherheitsupdates und Patches verwalten, um Ihre Informationsressourcen zu schützen. Erwägen Sie, für diese Aufgabe einen Ansatz mit End-to-End-Automatisierung zu nutzen.

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.

Wenn Ihre Workload mehr Arbeitsspeicher und weniger CPUs erfordert, sollten Sie die Verwendung einer der eingeschränkten vCPU VM-Größen in Erwägung ziehen, um die Kosten der Softwarelizenzierung pro vCPU zu senken.

Virtuelle Computer

In dieser Architektur werden virtuelle Computer 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 wie 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 um bis zu 72 Prozent gesenkt werden.

Verwenden Sie Azure Spot Virtual Machines zum Ausführen von Workloads, die unterbrochen werden können und nicht innerhalb eines vordefinierten Zeitrahmens oder einer SLA abgeschlossen werden müssen. Azure stellt Spot-VMs bereit, wenn Kapazität verfügbar ist, und entfernt sie, wenn die Kapazität wieder benötigt wird. Die Kosten für Spot-VMs sind 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

Wenn Sie stärkere Kontrolle über Wartungsereignisse oder Hardwareisolierung benötigen, sei es aus Leistungs- oder aus Compliancegründen, sollten Sie erwägen, Ihre virtuellen Computer auf dedizierten Hosts bereitzustellen.

Virtuelle Computer und Verfügbarkeitsgruppen

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

Wenn Sie einen Workload über Verfügbarkeitszonen hinweg bereitstellen, sind keine Verfügbarkeitsgruppen erforderlich.

Azure Load Balancer

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

Sie zahlen nur für die Anzahl konfigurierter Lastenausgleichs- und Ausgangsregeln sowie für die durch den Lastenausgleich verarbeiteten Daten. 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.

ExpressRoute

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

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

Communitys

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

Nächste Schritte

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