Ausführen von SAP NetWeaver unter Windows in Azure

In diesem Leitfaden erfahren Sie mehr über bewährte Methoden zum Ausführen von SAP NetWeaver in einer Windows-Umgebung in Azure mit Hochverfügbarkeit. Die Datenbank ist AnyDB. „AnyDB“ ist der SAP-Begriff für alle unterstützten Datenbank-Managementsysteme (DBMS) neben SAP HANA.

Aufbau

Das folgende 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.

Laden Sie eine Visio-Datei dieser Architektur herunter.

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

Laden Sie eine Visio-Datei dieser Architektur herunter.

In diesem Leitfaden wird ein Produktionssystem beschrieben. Dieses System wird mit bestimmten virtuellen Computern (VM) bereitgestellt, deren Größe Sie je nach den Anforderungen Ihres Unternehmens ändern können. Das System kann auf eine einzelne VM reduziert werden. In diesem Leitfaden ist das Layout des Netzwerks stark vereinfacht, um die Architekturprinzipien zu demonstrieren. Es dient nicht dazu, ein gesamtes Unternehmensnetzwerk zu beschreiben.

Workflow

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 -isolation 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 Windows Server Active Directory.

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

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

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

• Jumpbox/Bastionhost Administratoren verwenden eine VM mit verbesserter Sicherheit, die als Jumpbox oder Bastionhost bezeichnet wird, um Verbindungen mit anderen VMs 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 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 VMs und Benutzer in der Domäne verwendet.

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: Lastenausgleichsmodule werden verwendet, um Datenverkehr auf VMs im Subnetz der Logikschicht zu verteilen. Für Hochverfügbarkeit von SAP-Anwendungen 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, z. B. SSL-Abschluss (Secure Sockets Layer). Bei der Integration von Load Balancer in eine zonale Bereitstellung von SAP muss Load Balancer Standard ausgewählt werden, da der Lastenausgleich der Basic-SKU nicht über Zonenredundanz verfügt.

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

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

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

Die Dienste können einen Lastenausgleich teilen, um die Lösung zu vereinfachen.

Die Standard-SKU unterstützt auch SAP-Cluster mit Multi-SID (Multi-Security Identifier). Mit anderen Worten: Mehrere SAP-Systeme unter Windows können sich eine gemeinsame Hochverfügbarkeitsinfrastruktur teilen, um die Kosten zu senken. Werten Sie die Kosteneinsparungen aus, und platzieren Sie nicht zu viele Systeme in einem Cluster. Azure unterstützt nicht mehr als fünf SIDs pro Cluster.

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

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 VMs 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. 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. Eine Näherungsplatzierungsgruppe bevorzugt die Zusammenstellung, bei der VMs im selben Rechenzentrum platziert werden, um die Wartezeit für Anwendungen zu minimieren.

Netzwerksicherheitsgruppen: Um eingehenden, ausgehenden und subnetzinternen Datenverkehr in einem virtuellen Netzwerk einzuschränken, 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. Anwendungssicherheitsgruppen bieten eine Möglichkeit, VMs nach Namen zu gruppieren und helfen Ihnen, Anwendungen zu schützen, indem sie den 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. Wir empfehlen Azure Managed Disks.

Empfehlungen

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

VMs

Passen Sie in Anwendungsserverpools und -clustern die Anzahl von VMs anhand Ihrer Anforderungen an. Ausführliche Informationen zum Ausführen von SAP NetWeaver auf VMs finden Sie unter Azure Virtual Machines – Planung und Implementierung für SAP NetWeaver.

Ausführliche Informationen zur SAP-Unterstützung für Azure-VM-Typen und 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

Die Web Dispatcher-Komponente wird für den Lastenausgleich von SAP-Datenverkehr zwischen den SAP-Anwendungsservern verwendet. Zur Erzielung von Hochverfügbarkeit für die Web Dispatcher-Komponente wird Load Balancer verwendet, um entweder den Failovercluster von Web Dispatcher-Instanzen oder das parallele Web Dispatcher-Setup zu implementieren. Eine detaillierte Beschreibung der Lösung finden Sie unter Hochverfügbarkeit für 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 (Remote Function Call) 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 Architektur 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 Ihnen, Azure Files-Freigaben als vollständig verwaltete, cloudnative Server Message Block (SMB)- oder Network File System (NFS)-Freigaben zu 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 Services-Instanzen auch mithilfe eines Windows Server-Failoverclusters mit Azure Files implementieren. Diese Lösung unterstützt auch einen Windows-Cluster mit freigegebenen Datenträgern, indem ein freigegebener Azure-Datenträger als freigegebenes Clustervolumen 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 Partnerprodukte 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 verwendet die Clustersoftware Quorumabstimmungen, um ein Segment des Netzwerks und die damit verbundenen Dienste auszuwählen, das als „Gehirn“ des fragmentierten Clusters dient. Windows bietet viele Quorummodelle. Diese Lösung verwendet einen 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 bereitzustellen.

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. 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 VMs, die dieselbe Rolle ausführen, in derselben Verfügbarkeitsgruppe zusammen. Auf diese Weise können Sie sich vor geplanter und ungeplanter Downtime schützen, die durch die Wartung der Azure-Infrastruktur oder durch Hardwarefehler verursacht werden. Um eine höhere Vereinbarung zum Servicelevel zu erfüllen, müssen Sie mindestens zwei VMs pro Verfügbarkeitsgruppe verwenden.

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

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)

NICs ermöglichen die gesamte Kommunikation zwischen VMs 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 entspricht der von SAP empfohlenen Vorgehensweise, 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.

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

ExpressRoute Global Reach

Wenn Ihre Netzwerkumgebung zwei oder mehr ExpressRoute-Verbindungen umfasst, kann Ihnen ExpressRoute Global Reach helfen, Netzwerkhops und Wartezeiten zu reduzieren. Diese Technologie ist eine Einrichtung eines Peerings der BGP-Route (Border Gateway Protocol), die zwischen zwei oder mehr ExpressRoute-Verbindungen zur Überbrückung von zwei ExpressRoute-Routingdomänen eingerichtet ist. 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 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. Mit FastPath 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 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.

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. Bei SAP-Bereitstellungen in Azure wird der Lastenausgleich in Clustersetups genutzt, um Datenverkehr an die primäre Dienstinstanz oder bei einem Fehler an den fehlerfreien Knoten zu leiten.

Wir empfehlen Ihnen, Load Balancer Standard für alle SAP-Szenarien zu verwenden. Wenn VMs im Back-End-Pool öffentliche ausgehende Konnektivität benötigen oder im Rahmen einer Azure-Zonenbereitstellung verwendet werden, sind für Load Balancer Standard weitere Konfigurationsschritte erforderlich, da sie standardmäßig sicher sind. Sie lassen ausgehende Verbindungen nur zu, wenn Sie diese explizit konfigurieren.

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. Sie benötigen für diese Art von Setup keinen weiteren Lastenausgleich.

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. Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto. Es wird empfohlen, in allen Fällen verwaltete Azure-Premium-Datenträger zu verwenden. Durch ein vor Kurzem durchgeführtes Update an SAP-Hinweis 2015553 wird die Verwendung von HDD Standard-Speicher und SSD Standard-Speicher für einige spezielle Anwendungsfälle nicht mehr möglich sein.

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 Azure SSD Premium-Datenträger und Azure Disk Storage Ultra sind für freigegebene Azure-Datenträger verfügbar, und SSD Premium ist 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.

Disk Storage Ultra reduziert die Datenträgerlatenz erheblich. Davon profitieren leistungskritische Anwendungen wie die SAP-Datenbankserver. Informationen zum Vergleichen der Optionen für Blockspeicher in Azure finden Sie unter Verwaltete Azure-Datenträgertypen.

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 erzielen, befolgen Sie die gängigen Praktiken zur Optimierung der Leistung von Speichervolumes, die auch für das Azure-Speicherlayout gelten. Sie können beispielsweise mehrere Datenträger zusammen positionieren, 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.

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

Ausgezeichnete Ratschläge zur Optimierung von Azure-Speicher für SAP-Workloads auf SQL Server finden Sie unter Azure Virtual Machines – Planung und Implementierung für SAP NetWeaver.

Wir empfehlen nicht, ein virtuelles Netzwerkgerät (Network Virtual Appliance, NVA) für SAP-Anwendungsstapel zwischen den Logik- 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 VMs 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, die auf GitHub vom AzureCAT SAP-Bereitstellungsteam zur Verfügung gestellt werden, finden Sie unter Skripts.

Verfügbarkeitszonen

Verfügbarkeitszonen bieten Ihnen die Möglichkeit, zonenübergreifend VMs bereitzustellen, d. h. über physisch getrennte Standorte innerhalb einer bestimmten Azure-Region hinweg. Sie dienen zur Verbesserung der Dienstverfügbarkeit. Die zonenübergreifende Bereitstellung von Ressourcen kann jedoch die Wartezeit erhöhen, sodass Sie die leistungsbezogenen Überlegungen im Auge behalten sollten.

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 VMs bereit. Empfohlene Tools für diese Tests sind beispielsweise PsPing und Iperf. Wenn die Tests abgeschlossen sind, entfernen Sie die VMs, die Sie für die Tests verwendet haben. Alternativ können Sie ein Tool zur Überprüfung der Wartezeit zwischen Azure-Zonen verwenden.

Überlegungen zur Skalierbarkeit

Für die SAP-Logikschicht sind in Azure viele verschiedene VM-Größen für Hochskalieren und Aufskalieren verfügbar. Eine umfassende Liste finden Sie im SAP-Hinweis 1928533: „SAP-Anwendungen in Azure: Unterstützte Produkte und Azure-VM-Typen“. Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto.

Sie können die SAP-Anwendungsserver und die Central Services-Cluster hoch- und herunterskalieren. Sie können sie auch auf- oder abskalieren, indem Sie die Anzahl der von Ihnen verwendeten Instanzen ändern. 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 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. Wenn Sie diese Option verwenden, sollten Sie wegen der zusätzlichen Workload für ASCS die richtige Dimensionierung auswählen.

Central Services auf Anwendungsserverschicht

Hochverfügbarkeit von Central Services wird mit einem Windows Server-Failovercluster 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.

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

• 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. Ein Implementierungsbeispiel finden Sie unter ASCS-Cluster mit freigegebenen Azure-Datenträgern. 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 Sie die Laufwerke als freigegebenes Clustervolumen für den Cluster-Manager.

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

Durch die Einführung von Load Balancer Standard können Sie 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 Lastenausgleiche einrichten (ob lokal oder in Azure), das Feature „Direct Server Return“ aktivieren, das auch als Floating IP oder DSR bezeichnet wird. So können die Serverantworten den Lastenausgleich umgehen. Diese direkte Verbindung verhindert, dass der Lastenausgleich zu einem Engpass auf dem Datenübertragungspfad wird. Für die 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

Bei dieser Architektur wird die Quelldatenbank in AnyDB ausgeführt – einem 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.

Bereitstellung von VMs über Verfügbarkeitszonen hinweg

Eine Verfügbarkeitszone ist ein logisches Konstrukt, das die Verfügbarkeit von Workloads verbessern und Anwendungsdienste und VMs vor Ausfällen im Rechenzentrum schützen soll. 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 VMs in derselben Zone auf bestmögliche Weise auf Fehler- und Upgradedomänen verteilt.

In Azure-Regionen, die mehrere Zonen 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 VMs in einer Zone
• Wartezeit zwischen VMs in ausgewählten Zonen
• Verfügbarkeit der gleichen Azure-Dienste (VM-Typen) in den ausgewählten Zonen

Beispiel für Aktiv/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 aktiviert, wenn sie benötigt werden.

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, da sie heruntergefahren sind. 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 VMs in der sekundären Region anwenden. Sie müssen z. B. die ausführbaren Dateien des SAP-Kernels auf die VMs für die Notfallwiederherstellung kopieren.

Sollen Anwendungsserver automatisch in einer sekundären Region repliziert werden, empfehlen wir hierfür Azure Site Recovery. Sie können 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 (Notfallwiederherstellung) verwenden Sie die Replikation. Suchen Sie insbesondere die SMB Azure-Dateifreigabe oder den freigegebenen Azure-Datenträger Ihres ASCS-Clusters, der das Verzeichnis /sapmnt und andere Inhalte enthält. Replizieren Sie diese Daten auf einer entsprechenden SMB-Azure-Dateifreigabe oder 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 eine VM 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 der VM in der Region für die Notfallwiederherstellung vornehmen. Informationen zum Erstellen, Kopieren und Testen des Failoverprozesses dieser Replikationsmethode finden Sie unter „4.3. SAP SPOF layer (ASCS)“ (SAP-SPOF-Schicht (ASCS)) in 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).

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 Verzeichnis-, Sicherungs- und Überwachungsdienste, werden von 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 Site Recovery

Um Site Recovery für die automatische Erstellung eines vollständig replizierten Produktionsstandorts Ihrer Originalkonfiguration zu erstellen, müssen Sie benutzerdefinierte Bereitstellungsskripts ausführen. Beispielsweise stellt Site Recovery zunächst die VMs in Verfügbarkeitsgruppen bereit. 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 Failover-VMs anzufügen. Ein Beispiel auf GitHub für ein benutzerdefiniertes Site Recovery Automation Runbooks-Skript finden Sie unter Azure Site Recovery Runbooks.

Aspekte der Verwaltung und des Betriebs

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

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 VMs 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, verwenden Sie VSS-Momentaufnahmen für anwendungskonsistente Sicherungen.

Identitätsverwaltung

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

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

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

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

Ü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 enthält jetzt Log Analytics und Application Insights. Sie können Azure Monitor verwenden, um Infrastruktur- und Anwendungsanomalien zu überwachen, Administratoren zu warnen 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. Überprüfen Sie sorgfältig, 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. Informationen zum Startsatz von Metriken finden Sie auf GitHub.

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. Informationen zur Netzwerksicherheit finden Sie im Abschnitt „Sicherheitsempfehlungen“ in Azure Virtual Machines – Planung und Implementierung für SAP NetWeaver. 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 einer Windows-VM 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. Die Daten auf den Datenträgern der VM werden im Ruhezustand in Ihrem Azure-Speicher 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 Synapse Analytics-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 (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. Eine Anleitung zur Bereitstellung finden Sie unter Bereitstellen von Threat Monitoring für SAP in Microsoft Sentinel.

Verwalten Sie wie immer Sicherheitsupdates und Patches, 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 zu senken, die pro vCPU berechnet werden.

VMs

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

Es gibt verschiedene Zahlungsoptionen für VMs:

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

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

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

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

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

VMs und Verfügbarkeitsgruppen

Für alle Pools und Cluster (Web Dispatcher, SAP-Anwendungsserver, Central Services und die Datenbank) werden die VMs 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.

Load Balancer

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

Sie zahlen nur für die Anzahl konfigurierter Lastenausgleichs- und Ausgangsregeln sowie für die durch den Lastenausgleich verarbeiteten Daten. Die Regeln für eingehende Netzwerkadressenübersetzung (NAT) sind kostenlos. Für Load Balancer Standard fallen keine Kosten auf Stundenbasis an, wenn keine Regeln konfiguriert sind.

ExpressRoute

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

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

Communitys

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

• Ausführen von SAP-Anwendungen auf der Microsoft-Plattform (Blog)
• Azure-Communitysupport
• SAP Community
• Stapelüberlauf für SAP

Beitragende

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

Hauptautor:

• Ben Trinh | Principal Architect

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

Nächste Schritte

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

• Azure Virtual Machines – Planung und Implementierung für SAP NetWeaver
• Verwenden von Azure zum Hosten und Ausführen von SAP-Workloadszenarien

Zugehörige Ressourcen

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