Planen und Implementieren einer SAP-Bereitstellung in Azure

  • Artikel

In Azure können Organisationen die benötigten Cloudressourcen und -dienste abrufen, ohne einen langen Beschaffungszyklus abzuschließen. Das Ausführen Ihrer SAP-Workload in Azure erfordert jedoch Kenntnisse über die verfügbaren Optionen und die sorgfältige Planung, um die Azure-Komponenten und -Architektur auszuwählen, um Ihre Lösung zu unterstützen.

Azure bietet eine umfassende Plattform für die Ausführung Ihrer SAP-Anwendungen. Azure-Infrastruktur as a Service (IaaS) und Plattform as a Service (PaaS)-Angebote bieten Ihnen optimale Auswahlmöglichkeiten für eine erfolgreiche Bereitstellung Ihrer gesamten SAP-Unternehmenslandschaft.

Dieser Artikel ergänzt die SAP-Dokumentation und SAP Notes, die wichtigsten Quellen zum Installieren und Bereitstellen von SAP-Software auf Azure und anderen Plattformen.

Definitionen

In diesem Artikel verwenden wir die folgenden Begriffe:

  • SAP-Komponente: Eine individuelle SAP-Anwendung wie SAP S/4HANA, SAP ECC, SAP BW oder SAP Solution Manager. Eine SAP-Komponente kann auf herkömmlichen Advanced Business Application Programming (WEAVER) oder Java-Technologien basieren, oder es kann sich um eine Anwendung handeln, die nicht auf SAP NetWeaver basiert, z. B. SAP BusinessObjects.
  • SAP-Umgebung: Mehrere SAP-Komponenten, die logisch gruppiert sind, um eine Geschäftsfunktion auszuführen, z. B. Entwicklung, Qualitätssicherung, Schulung, Notfallwiederherstellung oder Produktion.
  • SAP-Landschaft: Die gesamte Gruppe von SAP-Ressourcen in der IT-Landschaft einer Organisation. Die SAP-Landschaft umfasst alle Produktions- und anderen Umgebungen.
  • SAP-System: Die Kombination aus einer DbMS-Ebene (Database Management System) und einer Anwendungsschicht. Zwei Beispiele sind ein SAP ERP-Entwicklungssystem und ein SAP BW-Testsystem. In einer Azure-Bereitstellung können diese beiden Ebenen nicht zwischen lokal und Azure verteilt werden. Ein SAP-System muss entweder lokal bereitgestellt oder in Azure bereitgestellt werden. Sie können jedoch verschiedene Systeme in einer SAP-Landschaft entweder in Azure oder lokal betreiben.

Ressourcen

Der Einstiegspunkt für die Dokumentation, in der beschrieben wird, wie eine SAP-Workload auf Azure gehostet und ausgeführt wird, ist "Erste Schritte mit SAP auf einem virtuellen Azure-Computer". Im Artikel finden Sie Links zu anderen Artikeln, die Folgendes abdecken:

  • SAP-Workload-Spezifisches für Speicher, Netzwerk und unterstützte Optionen.
  • SAP DBMS Guides für verschiedene DBMS-Systeme in Azure.
  • SAP-Bereitstellungshandbücher, sowohl manuell als auch automatisiert.
  • Details zu hoher Verfügbarkeit und Notfallwiederherstellung für eine SAP-Workload in Azure.
  • Integration in SAP in Azure mit anderen Diensten und Drittanbieteranwendungen.

Wichtig

Für Voraussetzungen, den Installationsprozess und Details zu bestimmten SAP-Funktionen ist es wichtig, die SAP-Dokumentation und Leitfäden sorgfältig zu lesen. In diesem Artikel werden nur bestimmte Aufgaben für SAP-Software behandelt, die auf einem virtuellen Azure-Computer (VM) installiert und betrieben wird.

Die folgenden SAP Notes bilden die Basis der Azure-Anleitungen für SAP-Bereitstellungen:

Hinweisnummer Titel
1928533 SAP-Anwendungen auf Azure: Unterstützte Produkte und Größen
2015553 SAP auf Azure: Supportvoraussetzungen
2039619 SAP-Anwendungen in Azure mithilfe der Oracle-Datenbank
2233094 DB6: SAP-Anwendungen auf Azure Unter Verwendung von IBM Db2 für Linux, UNIX und Windows
1999351 Problembehandlung für die erweiterte Azure-Überwachung für SAP
1409604 Virtualisierung unter Windows: Erweiterte Überwachung
2191498 SAP unter Linux mit Azure: Erweiterte Überwachung
2731110 Unterstützung virtueller Netzwerkgeräte (Network Virtual Appliances, NVA) für SAP in Azure

Allgemeine Standard- und MaximaleInschränkungen von Azure-Abonnements und -Ressourcen finden Sie unter Azure-Abonnement- und Dienstbeschränkungen, Kontingente und Einschränkungen.

Szenarien

SAP-Dienste werden häufig als die unternehmenskritischen Anwendungen angesehen. Die Architektur und der Betrieb der Anwendungen sind komplex, und es ist wichtig, sicherzustellen, dass alle Anforderungen für Verfügbarkeit und Leistung erfüllt sind. Ein Unternehmen denkt in der Regel sorgfältig darüber nach, welcher Cloudanbieter solche geschäftskritischen Geschäftsprozesse ausführen soll.

Azure ist die ideale öffentliche Cloudplattform für unternehmenskritische SAP-Anwendungen und Geschäftsprozesse. Die aktuellste SAP-Software, einschließlich SAP NetWeaver und SAP S/4HANA-Systeme, kann heute in der Azure-Infrastruktur gehostet werden. Azure bietet mehr als 800 CPU-Typen und VMs mit vielen Terabyte Arbeitsspeicher.

Beschreibungen der unterstützten Szenarien und einiger szenarien, die nicht unterstützt werden, finden Sie unter SAP auf unterstützten Azure-VMs. Überprüfen Sie diese Szenarien und die Bedingungen, die als nicht unterstützt angezeigt werden, während Sie die Architektur planen, die Sie in Azure bereitstellen möchten.

Um SAP-Systeme im Allgemeinen in Azure IaaS oder iaaS erfolgreich bereitzustellen, ist es wichtig, die signifikanten Unterschiede zwischen den Angeboten herkömmlicher privater Clouds und IaaS-Angeboten zu verstehen. Ein herkömmlicher Host oder Auslagerungsanbieter passt die Infrastruktur (Netzwerk, Speicher und Servertyp) an die Workload an, die ein Kunde hosten möchte. In einer IaaS-Bereitstellung liegt es in der Verantwortung des Kunden oder Partners, seine potenzielle Arbeitsauslastung zu bewerten und die richtigen Azure-Komponenten von VMs, Speicher und Netzwerk auszuwählen.

Um Daten für die Planung Ihrer Bereitstellung in Azure zu sammeln, ist folgendes wichtig:

  • Ermitteln Sie, welche SAP-Produkte und -Versionen in Azure unterstützt werden.
  • Bewerten Sie, ob das Betriebssystem, das Sie verwenden möchten, mit den Azure-VMs unterstützt werden, die Sie für Ihre SAP-Produkte auswählen würden.
  • Ermitteln Sie, welche DBMS-Versionen für bestimmte VMs für Ihre SAP-Produkte unterstützt werden.
  • Bewerten Sie, ob ein Upgrade oder eine Aktualisierung Ihrer SAP-Landschaft erforderlich ist, um die erforderlichen Betriebssystem- und DBMS-Versionen für die Erreichung einer unterstützten Konfiguration anzupassen.
  • Bewerten Sie, ob Sie zu verschiedenen Betriebssystemen wechseln müssen, um sie in Azure bereitzustellen.

Details zu unterstützten SAP-Komponenten in Azure, Azure-Infrastruktureinheiten und zugehörigen Betriebssystemversionen und DBMS-Versionen werden in SAP-Software erläutert, die für Azure-Bereitstellungen unterstützt wird. Das Wissen, das Sie von der Bewertung von Support und Abhängigkeiten zwischen SAP-Versionen, Betriebssystemversionen und DBMS-Versionen gewinnen, hat erhebliche Auswirkungen auf Ihre Bemühungen, Ihre SAP-Systeme nach Azure zu verschieben. Sie erfahren, ob erhebliche Vorbereitungsbemühungen involviert sind, z. B. ob Sie Ihr SAP-Release aktualisieren oder zu einem anderen Betriebssystem wechseln müssen.

Erste Schritte zum Planen einer Bereitstellung

Der erste Schritt bei der Bereitstellungsplanung besteht nicht darin, nach virtuellen Computern zu suchen, die zum Ausführen von SAP-Anwendungen verfügbar sind.

Die ersten Schritte zum Planen einer Bereitstellung sind die Zusammenarbeit mit Compliance - und Sicherheitsteams in Ihrer Organisation, um zu bestimmen, welche Grenzbedingungen für die Bereitstellung der SAP-Workload oder des Geschäftsprozesses in einer öffentlichen Cloud gelten. Der Prozess kann zeitaufwändig sein, aber es ist wichtig, die Arbeit abzuschließen.

Wenn Ihre Organisation bereits Software in Azure bereitgestellt hat, ist der Prozess möglicherweise einfach. Wenn Ihr Unternehmen zu Beginn der Reise mehr ist, sind möglicherweise größere Diskussionen erforderlich, um die Grenzbedingungen, Sicherheitsbedingungen und Unternehmensarchitektur zu ermitteln, mit denen bestimmte SAP-Daten und SAP-Geschäftsprozesse in einer öffentlichen Cloud gehostet werden können.

Planen der Compliance

Eine Liste der Microsoft Compliance-Angebote, die Ihnen bei der Planung Ihrer Complianceanforderungen helfen können, finden Sie unter Microsoft Compliance-Angebote.

Planen der Sicherheit

Informationen zu SAP-spezifischen Sicherheitsbedenken, z. B. datenverschlüsselung für ruhende Daten oder andere Verschlüsselung in einem Azure-Dienst, finden Sie unter Azure-Verschlüsselungsübersicht und Sicherheit für Ihre SAP-Landschaft.

Organisieren von Azure-Ressourcen

Planen Sie zusammen mit der Sicherheits- und Complianceüberprüfung, wenn Sie diese Aufgabe noch nicht erledigt haben, die Organisation Ihrer Azure-Ressourcen. Der Prozess umfasst entscheidungen über:

  • Eine Benennungskonvention, die Sie für jede Azure-Ressource verwenden, z. B. für VMs und Ressourcengruppen.
  • Ein Abonnement- und Verwaltungsgruppendesign für Ihre SAP-Workload, z. B. ob mehrere Abonnements pro Workload, pro Bereitstellungsebene oder für jede Geschäftseinheit erstellt werden sollen.
  • Unternehmensweite Nutzung von Azure-Richtlinien für Abonnements und Verwaltungsgruppen.

Um Die richtigen Entscheidungen zu treffen, werden viele Details der Unternehmensarchitektur im Azure Cloud Adoption Framework beschrieben.

Unterschätzen Sie nicht die Anfangsphase des Projekts in Ihrer Planung. Nur wenn Vereinbarungen und Regeln für Compliance, Sicherheit und Azure-Ressourcenorganisation eingerichtet sind, sollten Sie Ihre Bereitstellungsplanung voranbringen.

Die nächsten Schritte sind die Planung der geografischen Platzierung und der Netzwerkarchitektur, die Sie in Azure bereitstellen.

Azure-Geografien und -Regionen

Azure-Dienste sind in separaten Azure-Regionen verfügbar. Eine Azure-Region ist eine Sammlung von Rechenzentren. Die Rechenzentren enthalten die Hardware und Infrastruktur, die die Azure-Dienste hostet und ausführen, die in der Region verfügbar sind. Die Infrastruktur enthält eine große Anzahl von Knoten, die als Computeknoten oder Speicherknoten funktionieren oder die Netzwerkfunktionen ausführen.

Eine Liste der Azure-Regionen finden Sie unter Azure-Regionen. Eine interaktive Karte finden Sie in der globalen Azure-Infrastruktur.

Nicht alle Azure-Regionen bieten dieselben Dienste. Je nach sap-Produkt, das Sie ausführen möchten, ihren Größenanforderungen und dem benötigten Betriebssystem und DBMS ist es möglich, dass eine bestimmte Region nicht die VM-Typen anbietet, die für Ihr Szenario erforderlich sind. Wenn Sie beispielsweise SAP HANA ausführen, benötigen Sie in der Regel VMs der verschiedenen VM-Familien der M-Serie. Diese VM-Familien werden nur in einer Teilmenge von Azure-Regionen bereitgestellt.

Wenn Sie mit der Planung beginnen und überlegen, welche Regionen als primäre Region und schließlich sekundäre Region ausgewählt werden sollen, müssen Sie untersuchen, ob die für Ihre Szenarien benötigten Dienste in den Regionen verfügbar sind, die Sie in Betracht ziehen. Sie können genau wissen, welche VM-Typen, Azure-Speichertypen und andere Azure-Dienste in jeder Region in Produkten verfügbar sind, die nach Region verfügbar sind.

Azure-Regionspaare

In einer gekoppelten Azure-Region ist die Replikation bestimmter Daten standardmäßig zwischen den beiden Regionen aktiviert. Weitere Informationen finden Sie unter Regionsübergreifende Replikation in Azure: Business Continuity & Disaster Recovery.

Die Datenreplikation in einem Regionspaar ist an Azure-Speichertypen gebunden, die Sie für die Replikation in eine gekoppelte Region konfigurieren können. Ausführliche Informationen finden Sie unter Speicherredundanz in einer sekundären Region.

Die Speichertypen, die die Replikation gekoppelter Regionen unterstützen, sind Speichertypen, die nicht für SAP-Komponenten und eine DBMS-Workload geeignet sind. Die Benutzerfreundlichkeit der Azure-Speicherreplikation ist auf Azure Blob Storage (für Sicherungszwecke), Dateifreigaben und Volumes und andere Speicherszenarien mit hoher Latenz beschränkt.

Wenn Sie auf gekoppelte Regionen und die Dienste überprüfen, die Sie in Ihren primären oder sekundären Regionen verwenden möchten, ist es möglich, dass die Azure-Dienste oder VM-Typen, die Sie in Ihrer primären Region verwenden möchten, in der gekoppelten Region, die Sie als sekundäre Region verwenden möchten, nicht verfügbar sind. Oder Sie können feststellen, dass eine azure-gekoppelte Region aufgrund von Gründen der Datencompliance für Ihr Szenario nicht akzeptabel ist. Für diese Szenarien müssen Sie eine nicht verairte Region als sekundäre oder Notfallwiederherstellungsregion verwenden, und Sie müssen einige der Datenreplikation selbst einrichten.

Verfügbarkeitszonen

Viele Azure-Regionen verwenden Verfügbarkeitszonen , um Standorte innerhalb einer Azure-Region physisch zu trennen. Jede Verfügbarkeitszone besteht aus einem oder mehreren Rechenzentren, die mit unabhängiger Leistung, Kühlung und Vernetzung ausgestattet sind. Ein Beispiel für die Verwendung einer Verfügbarkeitszone zur Verbesserung der Ausfallsicherheit besteht darin, zwei VMs in zwei separaten Verfügbarkeitszonen in Azure bereitzustellen. Ein weiteres Beispiel ist die Implementierung eines Hochverfügbarkeitsframeworks für Ihr SAP DBMS-System in einer Verfügbarkeitszone und die Bereitstellung von SAP (A)SCS in einer anderen Verfügbarkeitszone, sodass Sie die beste SLA in Azure erhalten.

Weitere Informationen zu VM-SLAs in Azure finden Sie in der neuesten Version von SLAs für virtuelle Computer. Da Sich Azure-Regionen schnell entwickeln und erweitern, wird die Topologie der Azure-Regionen, die Anzahl der physischen Rechenzentren, die Entfernung zwischen Rechenzentren und die Entfernung zwischen Azure-Verfügbarkeitszonen weiterentwickelt. Die Netzwerklatenz ändert sich, wenn sich die Infrastruktur ändert.

Befolgen Sie die Anleitungen in SAP-Workloadkonfigurationen mit Azure-Verfügbarkeitszonen , wenn Sie eine Region mit Verfügbarkeitszonen auswählen. Ermitteln Sie außerdem, welches Zonalbereitstellungsmodell für Ihre Anforderungen, die von Ihnen gewählte Region und Ihre Workload am besten geeignet ist.

Fehlerdomänen

Fehler do Standard s stellt eine physische Fehlereinheit dar. Ein Fehler Standard ist eng mit der physischen Infrastruktur verbunden, die in Rechenzentren enthalten ist. Obwohl ein physisches Blatt oder Rack als Fehler angesehen werden kann Standard gibt es keine direkte 1:1-Zuordnung zwischen einem physischen Computerelement und einem Fehler Standard.

Wenn Sie mehrere VMs als Teil eines SAP-Systems bereitstellen, können Sie indirekt den Azure Fabric-Controller beeinflussen, um Ihre virtuellen Computer in unterschiedlichen Fehlern bereitzustellen Standard, sodass Sie die Anforderungen für Verfügbarkeits-SLAs erfüllen können. Sie haben jedoch keine direkte Kontrolle über die Verteilung von Fehlern Standard über eine Azure-Skalierungseinheit (eine Sammlung von Hunderten von Computeknoten oder Speicherknoten und Netzwerk) oder die Zuweisung von VMs zu einem bestimmten Fehler Standard. Um den Azure Fabric-Controller zu manövrieren, um eine Reihe von VMs über verschiedene Fehler zu bereitstellen Standard müssen Sie den virtuellen Computern zur Bereitstellungszeit einen Azure-Verfügbarkeitssatz zuweisen. Weitere Informationen finden Sie unter Verfügbarkeitssätze.

Updatedomänen

Update do Standard s represent a logical unit that sets how a VM in an SAP system that consists of multiple VMs is updated. Wenn ein Plattformupdate auftritt, durchläuft Azure den Prozess der Aktualisierung dieser Updates Standard eine nacheinander. Indem Sie virtuelle Computer zur Bereitstellungszeit über verschiedene Updates verteilen Standard können Sie Ihr SAP-System vor potenziellen Ausfallzeiten schützen. Ähnlich wie bei Fehlern Standard wird eine Azure-Skalierungseinheit in mehrere Aktualisierungen unterteilt Standard s. Um den Azure Fabric-Controller zu manövrieren, um eine Reihe von VMs über verschiedene Update-Dos bereitzustellen Standard müssen Sie den virtuellen Computern zur Bereitstellungszeit einen Azure-Verfügbarkeitssatz zuweisen. Weitere Informationen finden Sie unter Verfügbarkeitssätze.

Diagram that depicts update domains and failure domains.

Verfügbarkeitsgruppen

Azure-VMs innerhalb eines Azure-Verfügbarkeitssatzes werden vom Azure Fabric-Controller über verschiedene Fehler verteilt Standard s. Die Verteilung über unterschiedliche Fehler Standard besteht darin, zu verhindern, dass alle VMs eines SAP-Systems während der Infrastruktur Standard Tenanz heruntergefahren werden oder wenn ein Fehler in einem Fehler auftritt Standard. Standardmäßig sind VMs nicht Teil eines Verfügbarkeitssatzes. Sie können einen virtuellen Computer in einer Verfügbarkeitsgruppe nur zur Bereitstellungszeit hinzufügen oder wenn eine VM erneut bereitgestellt wird.

Weitere Informationen zu Azure-Verfügbarkeitssätzen und zur Beziehung von Verfügbarkeitssätzen zu Fehler Standard s finden Sie unter Azure-Verfügbarkeitsgruppen.

Wichtig

Verfügbarkeitszonen und Verfügbarkeitsgruppen in Azure schließen sich gegenseitig aus. Sie können mehrere VMs in einer bestimmten Verfügbarkeitszone oder in einem Verfügbarkeitssatz bereitstellen. Aber nicht sowohl die Verfügbarkeitszone als auch die Verfügbarkeitsgruppe können einer VM zugewiesen werden.

Sie können Verfügbarkeitssätze und Verfügbarkeitszonen kombinieren, wenn Sie Näherungsplatzierungsgruppen verwenden.

Wenn Sie Verfügbarkeitssätze definieren und versuchen, verschiedene VMs verschiedener VM-Familien innerhalb eines Verfügbarkeitssatzes zu kombinieren, treten möglicherweise Probleme auf, die verhindern, dass Sie einen bestimmten VM-Typ in einen Verfügbarkeitssatz einschließen. Der Grund dafür ist, dass der Verfügbarkeitssatz an eine Skalierungseinheit gebunden ist, die einen bestimmten Computehosttyp enthält. Ein bestimmter Computehosttyp kann nur für bestimmte Typen von VM-Familien ausgeführt werden.

Sie erstellen beispielsweise einen Verfügbarkeitssatz und stellen den ersten virtuellen Computer im Verfügbarkeitssatz bereit. Der erste virtuelle Computer, den Sie dem Verfügbarkeitssatz hinzufügen, befindet sich in der Edsv5-VM-Familie. Wenn Sie versuchen, einen zweiten virtuellen Computer bereitzustellen, schlägt diese Bereitstellung fehl. Der Grund dafür ist, dass VMs der Edsv5-Familie nicht auf derselben Hosthardware wie die virtuellen Computer in der M-Familie ausgeführt werden.

Das gleiche Problem kann auftreten, wenn Sie die Größe von VMs ändern. Wenn Sie versuchen, einen virtuellen Computer aus der Edsv5-Familie und in einen VM-Typ zu verschieben, der sich in der M-Familie befindet, schlägt die Bereitstellung fehl. Wenn Sie die Größe einer VM-Familie ändern, die nicht auf derselben Hosthardware gehostet werden kann, müssen Sie alle virtuellen Computer, die sich in Ihrem Verfügbarkeitssatz befinden, herunterfahren und deren Größe ändern, damit sie auf dem anderen Hostcomputertyp ausgeführt werden können. Informationen zu SLAs von VMs, die in einem Verfügbarkeitssatz bereitgestellt werden, finden Sie unter SLAs für virtuelle Computer.

Skalierungssätze für virtuelle Maschinen mit flexibler Orchestrierung

Skalierungssätze für virtuelle Computer mit flexibler Orchestrierung bieten eine logische Gruppierung von plattformverwalteten virtuellen Computern. Sie haben die Möglichkeit, einen Skalierungssatz innerhalb der Region zu erstellen oder über Verfügbarkeitszonen hinweg zu erstrecken. Beim Erstellen der flexiblen Skalierung in einer Region mit platformFaultDo Standard Count>1 (FD>1) würden die im Skalierungssatz bereitgestellten VMs über die angegebene Fehleranzahl verteilt Standard in derselben Region. Andererseits würde das Erstellen des flexiblen Skalierungssatzes über Verfügbarkeitszonen hinweg mit platformFaultDo Standard Count=1 (FD=1) virtuelle Computer über die angegebene Zone verteilen, und der Skalierungssatz würde auch VMs über verschiedene Fehlerbereiche verteilen Standard innerhalb der Zone auf best-effort-Basis.

Für SAP-Workload werden nur flexible Skalierungssätze mit FD=1 unterstützt. Der Vorteil der Verwendung flexibler Skalierungssätze mit FD=1 für die domänenübergreifende Bereitstellung anstelle der herkömmlichen Bereitstellung der Verfügbarkeitszone besteht darin, dass die mit dem Skalierungssatz bereitgestellten VMs über verschiedene Fehlersätze verteilt werden Standard innerhalb der Zone auf optimale Weise verteilt werden. Weitere Informationen zur BEREITSTELLUNG von SAP-Workload mit Skalierungssatz finden Sie im Bereitstellungshandbuch für flexible VM-Skalierungen.

Bei der Bereitstellung einer SAP-Workload mit hoher Verfügbarkeit in Azure ist es wichtig, die verschiedenen verfügbaren Bereitstellungstypen zu berücksichtigen und wie sie in verschiedenen Azure-Regionen (z. B. zonenübergreifend, in einer einzelnen Zone oder in einer Region ohne Zonen) angewendet werden können. Weitere Informationen finden Sie unter Bereitstellungsoptionen für hohe Verfügbarkeit für SAP-Workload.

Tipp

Derzeit gibt es keine direkte Möglichkeit zum Migrieren von SAP-Workload in Verfügbarkeitssätzen oder Verfügbarkeitszonen zur flexiblen Skalierung mit FD=1. Um den Umstieg vorzunehmen, müssen Sie den virtuellen Computer und den Datenträger mit Zoneneinschränkungen aus vorhandenen Ressourcen neu erstellen. Ein Open-Source-Projekt enthält PowerShell-Funktionen, die Sie als Beispiel verwenden können, um eine VM zu ändern, die im Verfügbarkeitssatz oder in der Verfügbarkeitszone bereitgestellt wird, um einen flexiblen Skalierungssatz mit FD=1 festzulegen. In einem Blogbeitrag wird gezeigt, wie Sie ein HA- oder Nicht-HA-SAP-System ändern, das in Verfügbarkeitssatz oder Verfügbarkeitszone bereitgestellt wird, um einen flexiblen Skalierungssatz mit FD=1 festzulegen.

Näherungsplatzierungsgruppen

Die Netzwerklatenz zwischen einzelnen SAP-VMs kann erhebliche Auswirkungen auf die Leistung haben. Die Netzwerk-Roundtripzeit zwischen SAP-Anwendungsservern und dbMS kann insbesondere erhebliche Auswirkungen auf Geschäftsanwendungen haben. Optimalerweise befinden sich alle Computeelemente, die Ihre SAP-VMs ausführen, so nah wie möglich. Diese Option ist in jeder Kombination nicht möglich, und Azure weiß möglicherweise nicht, welche virtuellen Computer zusammengehalten werden sollen. In den meisten Situationen und Regionen erfüllt die Standardplatzierung anforderungen der Netzwerk-Roundtriplatenz.

Wenn die Standardplatzierung die Anforderungen an Netzwerkrunden innerhalb eines SAP-Systems nicht erfüllt, können Näherungsgruppen diesen Bedarf erfüllen. Sie können Näherungsplatzierungsgruppen mit den Standorteinschränkungen der Azure-Region, der Verfügbarkeitszone und der Verfügbarkeit verwenden, um die Resilienz zu erhöhen. Bei einer Näherungsplatzierungsgruppe ist die Kombination sowohl der Verfügbarkeitszone als auch des Verfügbarkeitssatzes beim Festlegen unterschiedlicher Aktualisierungs- und Fehler dos möglich Standard. Eine Näherungsplatzierungsgruppe sollte nur ein einzelnes SAP-System enthalten.

Obwohl die Bereitstellung in einer Näherungsplatzierungsgruppe zu der am meisten latenzoptimierten Platzierung führen kann, hat die Bereitstellung mithilfe einer Näherungsplatzierungsgruppe auch Nachteile. Einige VM-Familien können nicht in einer Näherungsplatzierungsgruppe kombiniert werden, oder es treten Probleme auf, wenn Sie die Größe zwischen VM-Familien ändern. Die Einschränkungen von VM-Familien, Regionen und Verfügbarkeitszonen unterstützen möglicherweise keine Colocation. Ausführliche Informationen und Informationen zu den Vorteilen und potenziellen Herausforderungen bei der Verwendung einer Näherungsplatzierungsgruppe finden Sie unter Näherungsplatzierungsgruppenszenarien.

VMs, die keine Näherungsplatzierungsgruppen verwenden, sollten in den meisten Fällen für SAP-Systeme die Standardbereitstellungsmethode sein. Diese Standardeinstellung gilt insbesondere für Zonenbereitstellungen (eine einzelne Verfügbarkeitszone) und zonenübergreifende (VMs, die zwischen zwei Verfügbarkeitszonen verteilt werden) Bereitstellungen eines SAP-Systems. Die Verwendung von Näherungsplatzierungsgruppen sollte nur aus Leistungsgründen auf SAP-Systeme und Azure-Regionen beschränkt sein.

Azure-Netzwerke

Azure verfügt über eine Netzwerkinfrastruktur, die allen Szenarien zugeordnet ist, die Sie in einer SAP-Bereitstellung implementieren möchten. In Azure verfügen Sie über die folgenden Funktionen:

  • Zugriff auf Azure-Dienste und Zugriff auf bestimmte Ports in VMs, die von Anwendungen verwendet werden.
  • Direkter Zugriff auf VMs über Secure Shell (SSH) oder Windows Remote Desktop (RDP) für die Verwaltung und Verwaltung.
  • Interne Kommunikation und Namensauflösung zwischen VMs und von Azure-Diensten.
  • Lokale Konnektivität zwischen einem lokalen Netzwerk und Azure-Netzwerken.
  • Kommunikation zwischen Diensten, die in verschiedenen Azure-Regionen bereitgestellt werden.

Ausführliche Informationen zum Netzwerk finden Sie unter Azure Virtual Network.

Das Entwerfen von Netzwerken ist in der Regel die erste technische Aktivität, die Sie bei der Bereitstellung in Azure durchführen. Die Unterstützung einer zentralen Unternehmensarchitektur wie SAP ist häufig Teil der allgemeinen Netzwerkanforderungen. In der Planungsphase sollten Sie die vorgeschlagene Netzwerkarchitektur so detailliert wie möglich dokumentieren. Wenn Sie zu einem späteren Zeitpunkt eine Änderung vornehmen, z. B. das Ändern einer Subnetznetzwerkadresse, müssen Sie möglicherweise bereitgestellte Ressourcen verschieben oder löschen.

Virtuelle Azure-Netzwerke

Ein virtuelles Netzwerk ist ein grundlegender Baustein für Ihr privates Netzwerk in Azure. Sie können den Adressbereich des Netzwerks definieren und den Bereich in Netzwerksubnetze trennen. Ein Netzwerksubnetz kann für eine SAP-VM zur Verwendung verfügbar sein, oder es kann einem bestimmten Dienst oder Zweck zugeordnet werden. Einige Azure-Dienste, z. B. Azure Virtual Network und Azure-App lizenzierungsgateway, erfordern ein dediziertes Subnetz.

Ein virtuelles Netzwerk fungiert als Netzwerkgrenze. Ein Teil des Entwurfs, der beim Planen der Bereitstellung erforderlich ist, besteht darin, die Adressbereiche für virtuelle Netzwerke, Subnetze und private Netzwerke zu definieren. Sie können die Zuweisung des virtuellen Netzwerks für Ressourcen wie Netzwerkschnittstellen-Karte s (NICs) für VMs nach der Bereitstellung der virtuellen Computer nicht mehr ändern. Wenn Sie eine Änderung an einem virtuellen Netzwerk oder einem Subnetzadressenbereich vornehmen, müssen Sie möglicherweise alle bereitgestellten Ressourcen in ein anderes Subnetz verschieben.

Ihr Netzwerkdesign sollte mehrere Anforderungen für die SAP-Bereitstellung erfüllen:

  • Keine virtuellen Anwendung, wie z. B. eine Firewall, werden über den SAP-Kernel in den Kommunikationspfad zwischen der SAP-Anwendung und der DBMS-Ebene von SAP-Produkten wie S/4HANA oder SAP NetWeaver platziert.
  • Netzwerkroutingbeschränkungen werden von Netzwerksicherheitsgruppen (NSGs) auf Subnetzebene erzwungen. Gruppen-IPs von VMs in Anwendungssicherheitsgruppen (ASGs), die in den NSG-Regeln Standard enthalten sind, und Rollen-, Ebenen- und SID-Gruppierungen von Berechtigungen bereitstellen.
  • SAP-Anwendungs- und Datenbank-VMs werden im selben virtuellen Netzwerk innerhalb desselben oder unterschiedlichen Subnetzs eines einzelnen virtuellen Netzwerks ausgeführt. Verwenden Sie unterschiedliche Subnetze für Anwendungs- und Datenbank-VMs. Alternativ können Sie dedizierte Anwendungs- und DBMS-ASGs verwenden, um Regeln zu gruppieren, die für jeden Workloadtyp innerhalb desselben Subnetzes gelten.
  • Beschleunigtes Netzwerk ist auf allen Netzwerk-Karte aller VMs für SAP-Workloads aktiviert, sofern technisch möglich.
  • Stellen Sie sicheren Zugriff auf abhängigkeiten von zentralen Diensten, einschließlich der Namensauflösung (DNS), der Identitätsverwaltung (Windows Server Active Directory do Standard s/Microsoft Entra ID) und des administrativen Zugriffs.
  • Stellen Sie nach Bedarf Zugriff auf und nach öffentlichen Endpunkten bereit. Beispiele hierfür sind die Azure-Verwaltung für ClusterLabs Pacemaker-Vorgänge in hoher Verfügbarkeit oder für Azure-Dienste wie Azure Backup.
  • Verwenden Sie mehrere NICs nur, wenn sie zum Erstellen von bestimmten Subnetzen mit eigenen Routen und NSG-Regeln erforderlich sind.

Beispiele für die Netzwerkarchitektur für die SAP-Bereitstellung finden Sie in den folgenden Artikeln:

Überlegungen zum virtuellen Netzwerk

Einige konfigurationen für virtuelle Netzwerke müssen bestimmte Aspekte berücksichtigen.

  • Die Konfiguration virtueller Anwendung im Kommunikationspfad zwischen der SAP-Anwendungsschicht und der DBMS-Ebene von SAP-Komponenten mithilfe des SAP-Kernels, z. B. S/4HANA oder SAP NetWeaver, wird nicht unterstützt.

    Virtuelle Netzwerkgeräte in Kommunikationspfaden können die Netzwerklatenz zwischen zwei Kommunikationspartnern locker verdoppeln. Außerdem können sie den Durchsatz in kritischen Pfaden zwischen der SAP-Anwendungsschicht und der DBMS-Schicht einschränken. In einigen Szenarien können virtuelle Anwendung netzwerk virtual Anwendung dazu führen, dass Pacemaker Linux-Cluster fehlschlagen.

    Der Kommunikationspfad zwischen der SAP-Anwendungsschicht und der DBMS-Ebene muss ein direkter Pfad sein. Die Einschränkung enthält keine ASG- und NSG-Regeln , wenn die ASG- und NSG-Regeln einen direkten Kommunikationspfad zulassen.

    Andere Szenarien, in denen virtuelle Anwendung des Netzwerks nicht unterstützt werden, sind:

  • Das Trennen der SAP-Anwendungsschicht und der DBMS-Ebene in verschiedene virtuelle Azure-Netzwerke wird nicht unterstützt. Es wird empfohlen, die SAP-Anwendungsschicht und die DBMS-Ebene zu trennen, indem Sie Subnetze innerhalb desselben virtuellen Azure-Netzwerks anstelle verschiedener virtueller Azure-Netzwerke verwenden.

    Wenn Sie ein nicht unterstütztes Szenario einrichten, das zwei SAP-Systemebenen in verschiedenen virtuellen Netzwerken trennt, müssen die beiden virtuellen Netzwerke peered werden.

    Der Netzwerkdatenverkehr zwischen zwei virtuellen Azure-Netzwerken mit Peers unterliegt Übertragungskosten. Jeden Tag wird ein riesiges Datenvolumen, das aus vielen Terabyte besteht, zwischen der SAP-Anwendungsschicht und der DBMS-Ebene ausgetauscht. Sie können erhebliche Kosten verursachen, wenn die SAP-Anwendungsschicht und die DBMS-Ebene zwischen zwei virtuellen Azure-Netzwerken getrennt werden.

Namensauflösung und -do Standard dienste

Das Auflösen von Hostnamen in IP-Adressen über DNS ist häufig ein wichtiges Element für SAP-Netzwerke. Sie haben viele Optionen zum Konfigurieren von Namen und IP-Auflösung in Azure.

Häufig verfügt ein Unternehmen über eine zentrale DNS-Lösung, die Teil der Gesamtarchitektur ist. Es werden mehrere Optionen für die implementierung der Namensauflösung in Azure nativ beschrieben, statt eigene DNS-Server einzurichten, in der Namensauflösung für Ressourcen in virtuellen Azure-Netzwerken beschrieben.

Wie bei DNS-Diensten kann es eine Anforderung geben, dass Windows Server Active Directory von den SAP-VMs oder -Diensten zugänglich ist.

IP-Adresszuweisung

Eine IP-Adresse für eine NIC re Standard s beansprucht und während des gesamten Vorhandenseins der NIC eines virtuellen Computers verwendet. Die Regel gilt sowohl für dynamische als auch für statische IP-Zuweisungen. Es wird Standard wahr, ob der virtuelle Computer ausgeführt wird oder heruntergefahren wird. Die dynamische IP-Zuordnung wird freigegeben, wenn die NIC gelöscht wird, wenn sich das Subnetz ändert oder die Zuordnungsmethode in statisch geändert wird.

Es ist möglich, virtuellen Computern in einem virtuellen Azure-Netzwerk feste IP-Adressen zuzuweisen. IP-Adressen werden häufig für SAP-Systeme neu zugewiesen, die von externen DNS-Servern und statischen Einträgen abhängen. Die IP-Adresse wird erneut zugewiesen Standard, bis der virtuelle Computer und dessen NIC gelöscht werden oder bis die IP-Adresse nicht zugewiesen ist. Sie müssen die Gesamtanzahl der virtuellen Computer berücksichtigen (ausgeführt und beendet), wenn Sie den Bereich der IP-Adressen für das virtuelle Netzwerk definieren.

Weitere Informationen finden Sie unter Erstellen eines virtuellen Computers mit einer statischen privaten IP-Adresse.

Hinweis

Sie sollten zwischen statischer und dynamischer IP-Adresszuweisung für Azure-VMs und deren NICs entscheiden. Das Gastbetriebssystem der VM ruft die IP ab, die der NIC zugewiesen ist, wenn der virtuelle Computer gestartet wird. Sie sollten einer NIC keine statischen IP-Adressen im Gastbetriebssystem zuweisen. Einige Azure-Dienste wie Azure Backup basieren darauf, dass mindestens die primäre NIC auf DHCP und nicht auf statische IP-Adressen innerhalb des Betriebssystems festgelegt ist. Weitere Informationen finden Sie unter "Problembehandlung bei azure VM Backup".

Sekundäre IP-Adressen für die SAP-Hostnamenvirtualisierung

Die NIC jeder Azure-VM kann mehrere IP-Adressen zugewiesen haben. Eine sekundäre IP kann für einen virtuellen SAP-Hostnamen verwendet werden, der einem DNS-A-Eintrag oder DNS-PTR-Eintrag zugeordnet ist. Eine sekundäre IP-Adresse muss der IP-Konfiguration der Azure NIC zugewiesen werden. Eine sekundäre IP muss auch im Betriebssystem statisch konfiguriert werden, da sekundäre IPs häufig nicht über DHCP zugewiesen werden. Jede sekundäre IP muss aus demselben Subnetz stammen, an das die NIC gebunden ist. Eine sekundäre IP kann von einer Azure NIC hinzugefügt und entfernt werden, ohne die VM zu beenden oder zu ordnen. Um die primäre IP-Adresse einer NIC hinzuzufügen oder zu entfernen, muss der virtuelle Computer zugeordnet werden.

Hinweis

Bei sekundären IP-Konfigurationen wird die unverankerte IP-Adresse des Azure-Lastenausgleichs nicht unterstützt. Der Azure-Lastenausgleich wird von SAP-Hochverfügbarkeitsarchitekturen mit Pacemaker-Clustern verwendet. In diesem Szenario ermöglicht der Lastenausgleich die virtuellen SAP-Hostnamen. Allgemeine Anleitungen zur Verwendung virtueller Hostnamen finden Sie im SAP-Hinweis 962955.

Azure Load Balancer mit virtuellen Computern, die SAP ausführen

Ein Lastenausgleichsmodul wird in der Regel in Hochverfügbarkeitsarchitekturen verwendet, um unverankerte IP-Adressen zwischen aktiven und passiven Clusterknoten bereitzustellen. Sie können auch einen Lastenausgleich für einen einzelnen virtuellen Computer verwenden, um eine virtuelle IP-Adresse für einen virtuellen SAP-Hostnamen zu speichern. Die Verwendung eines Lastenausgleichs für einen einzelnen virtuellen Computer ist eine Alternative zur Verwendung einer sekundären IP-Adresse auf einer NIC oder zum Verwenden mehrerer NICs im selben Subnetz.

Der Standardmäßige Lastenausgleichsmodul ändert den standardmäßigen ausgehenden Zugriffspfad , da seine Architektur standardmäßig sicher ist. VMs, die sich hinter einem Standardmäßigen Lastenausgleich befinden, können möglicherweise nicht mehr dieselben öffentlichen Endpunkte erreichen. Einige Beispiele sind ein Endpunkt für ein Betriebssystemupdate-Repository oder einen öffentlichen Endpunkt von Azure-Diensten. Optionen für die Bereitstellung ausgehender Konnektivität finden Sie unter Public Endpoint Connectivity for VMs by using the Azure standard load balancer.

Tipp

Der grundlegende Lastenausgleich sollte nicht mit einer SAP-Architektur in Azure verwendet werden. Das grundlegende Lastenausgleichsmodul soll eingestellt werden.

Mehrere vNICs pro VM

Sie können mehrere virtuelle Netzwerkschnittstellen-Karte s (vNICs) für eine Azure-VM definieren, wobei jeder vNIC jedem Subnetz im selben virtuellen Netzwerk wie der primären vNIC zugewiesen ist. Mit der Möglichkeit, mehrere vNICs zu haben, können Sie bei Bedarf mit der Einrichtung der Trennung von Netzwerkdatenverkehr beginnen. Beispielsweise wird der Clientdatenverkehr über die primäre vNIC weitergeleitet, und einige Administrator- oder Back-End-Datenverkehr werden über eine zweite vNIC weitergeleitet. Je nach Betriebssystem und Image, das Sie verwenden, müssen möglicherweise Datenverkehrsrouten für NICs innerhalb des Betriebssystems für das richtige Routing eingerichtet werden.

Der Typ und die Größe eines virtuellen Computers bestimmt, wie viele vNICs einer VM zugewiesen werden können. Informationen zu Funktionalität und Einschränkungen finden Sie unter Zuweisen mehrerer IP-Adressen zu virtuellen Computern mithilfe der Azure-Portal.

Durch das Hinzufügen von vNICs zu einem virtuellen Computer wird die verfügbare Netzwerkbandbreite nicht erhöht. Alle Netzwerkschnittstellen nutzen dieselbe Bandbreite. Es wird empfohlen, mehrere NICs nur zu verwenden, wenn VMs auf private Subnetze zugreifen müssen. Wir empfehlen ein Entwurfsmuster, das auf NSG-Funktionen basiert und die die Netzwerk- und Subnetzanforderungen vereinfacht. Das Design sollte möglichst wenige Netzwerkschnittstellen und optimal nur eine verwenden. Eine Ausnahme ist DAS HANA-Scaleout, bei dem eine sekundäre vNIC für das interne HANA-Netzwerk erforderlich ist.

Warnung

Wenn Sie mehrere vNICs auf einer VM verwenden, empfiehlt es sich, das Subnetz eines primären NIC zum Behandeln des Benutzernetzwerkdatenverkehrs zu verwenden.

Beschleunigte Netzwerke

Um die Netzwerklatenz zwischen Azure-VMs weiter zu verringern, wird empfohlen, sicherzustellen, dass das beschleunigte Azure-Netzwerk auf jedem virtuellen Computer aktiviert ist, auf dem eine SAP-Workload ausgeführt wird. Obwohl das beschleunigte Netzwerk standardmäßig für neue virtuelle Computer aktiviert ist, sollten Sie den Status anhand der Prüfliste für die Bereitstellung überprüfen. Die Vorteile beschleunigter Netzwerke sind erheblich verbessert die Netzwerkleistung und Latenz. Verwenden Sie sie, wenn Sie Azure VMs für SAP-Workloads auf allen unterstützten virtuellen Computern bereitstellen, insbesondere für die SAP-Anwendungsschicht und die SAP DBMS-Ebene. Die verknüpfte Dokumentation enthält Unterstützungsabhängigkeiten von Betriebssystemversionen und VM-Instanzen.

Lokale Konnektivität

Bei der SAP-Bereitstellung in Azure wird davon ausgegangen, dass eine zentrale unternehmensweite Netzwerkarchitektur und ein Kommunikationshub vorhanden sind, um die lokale Konnektivität zu ermöglichen. Die lokale Netzwerkkonnektivität ist unerlässlich, damit Benutzer und Anwendungen auf die SAP-Landschaft in Azure zugreifen können, um auf andere zentrale Organisationsdienste zuzugreifen, z. B. das zentrale DNS, do Standard und die Sicherheits- und Patchverwaltungsinfrastruktur.

Sie haben viele Optionen, um lokale Konnektivität für Ihre SAP in Azure-Bereitstellung bereitzustellen. Die Netzwerkbereitstellung ist am häufigsten eine Hub-Spoke-Netzwerktopologie oder eine Erweiterung der Hub-Spoke-Topologie, einem globalen virtuellen WAN.

Für lokale SAP-Bereitstellungen wird empfohlen, eine private Verbindung über Azure ExpressRoute zu verwenden. Für kleinere SAP-Workloads, Remoteregionen oder kleinere Büros ist die lokale VPN-Konnektivität verfügbar. Die Verwendung von ExpressRoute mit einer VPN-Standort-zu-Standort-Verbindung als Failoverpfad ist eine mögliche Kombination beider Dienste.

Ausgehende und eingehende Internetverbindung

Ihre SAP-Landschaft erfordert Konnektivität mit dem Internet, unabhängig davon, ob betriebssystemrepository-Updates empfangen, eine Verbindung mit den SAP SaaS-Anwendungen auf ihren öffentlichen Endpunkten herstellen oder über seinen öffentlichen Endpunkt auf einen Azure-Dienst zugreifen möchten. In ähnlicher Weise müssen Sie Ihren Kunden Zugriff auf SAP Fiori-Anwendungen gewähren, wobei Internetbenutzer auf Dienste zugreifen, die von Ihrer SAP-Landschaft bereitgestellt werden. Ihre SAP-Netzwerkarchitektur erfordert, dass Sie den Pfad zum Internet und für eingehende Anforderungen planen.

Sichern Sie Ihr virtuelles Netzwerk mithilfe von NSG-Regeln, mithilfe von Netzwerkdiensttags für bekannte Dienste und durch Einrichten von Routing- und IP-Adressen an Ihre Firewall oder andere virtuelle Anwendung des Netzwerks. Alle diese Aufgaben oder Überlegungen sind Teil der Architektur. Ressourcen in privaten Netzwerken müssen durch Netzwerkfirewalls mit Layer 4 und Layer 7 geschützt werden.

Kommunikationspfade mit dem Internet stehen im Mittelpunkt einer Architektur bewährter Methoden.

Azure-VMs für SAP-Workloads

Einige Azure-VM-Familien eignen sich besonders für SAP-Workloads und einige speziell für eine SAP HANA-Workload. Die Möglichkeit, den richtigen VM-Typ und seine Fähigkeit zur Unterstützung Ihrer SAP-Workload zu finden, wird unter "Welche SAP-Software für Azure-Bereitstellungen unterstützt wird" beschrieben. Außerdem listet SAP Note 1928533 alle zertifizierten Azure-VMs und ihre Leistungsfunktionen auf, die durch den SAP Application Performance Standard (SAPS)-Benchmark und -Einschränkungen gemessen werden, sofern sie gelten. Die VM-Typen, die für eine SAP-Workload zertifiziert sind, verwenden keine Überbereitstellung für CPU- und Arbeitsspeicherressourcen.

Über die Auswahl der unterstützten VM-Typen hinaus müssen Sie überprüfen, ob diese VM-Typen in einer bestimmten Region basierend auf produkten verfügbar sind, die nach Region verfügbar sind. Mindestens so wichtig ist es, zu bestimmen, ob die folgenden Funktionen für einen virtuellen Computer in Ihr Szenario passen:

  • CPU-Ressourcen und Arbeitsspeicherressourcen
  • Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) Bandbreite
  • Netzwerkfunktionen
  • Anzahl der Datenträger, die angefügt werden können
  • Möglichkeit, bestimmte Azure-Speichertypen zu verwenden

Informationen zu einer bestimmten FM-Familie und einem bestimmten Typ finden Sie unter "Größen für virtuelle Computer in Azure".

Preismodelle für Azure-VMs

Für ein VM-Preismodell können Sie die gewünschte Option auswählen:

  • Ein Pay-as-You-Go-Preismodell
  • Ein einjähriger Reservierter oder Sparplan
  • Ein dreijähriger Reservierter oder Sparplan
  • Ein Spotpreismodell

Ausführliche Informationen zu vm-Preisen für verschiedene Azure-Dienste, Betriebssysteme und Regionen finden Sie unter Preise für virtuelle Computer.

Informationen zu Preisen und Flexibilität von Einjahres- und Dreijahressparplänen und reservierten Instanzen finden Sie in den folgenden Artikeln:

Weitere Informationen zu Spotpreisen finden Sie unter Azure Spot Virtual Machines.

Die Preise für denselben VM-Typ können zwischen Azure-Regionen variieren. Einige Kunden profitieren von der Bereitstellung in einer kostengünstigeren Azure-Region, sodass Informationen zu Preisen nach Region beim Planen hilfreich sein können.

Azure bietet auch die Möglichkeit, einen dedizierten Host zu verwenden. Die Verwendung eines dedizierten Hosts bietet Ihnen mehr Kontrolle über Patchingzyklen für Azure-Dienste. Sie können Patching planen, um Ihren eigenen Zeitplan und Ihre eigenen Zyklen zu unterstützen. Dieses Angebot richtet sich speziell an Kunden, die über eine Workload verfügen, die nicht dem normalen Zyklus einer Workload folgt. Weitere Informationen finden Sie unter dedizierte Azure-Hosts.

Die Verwendung eines dedizierten Azure-Hosts wird für eine SAP-Workload unterstützt. Mehrere SAP-Kunden, die mehr Kontrolle über Infrastrukturpatching und Standard Zusicherungspläne haben möchten, verwenden dedizierte Azure-Hosts. Weitere Informationen dazu, wie Microsoft Standard Die Azure-Infrastruktur, die VMs hostet, enthält und patches, finden Sie unter Wartung für virtuelle Computer in Azure.

Betriebssystem für VMs

Wenn Sie neue VMs für eine SAP-Landschaft in Azure bereitstellen, entweder zum Installieren oder Migrieren eines SAP-Systems, ist es wichtig, das richtige Betriebssystem für Ihre Workload auszuwählen. Azure bietet eine große Auswahl an Betriebssystemimages für Linux und Windows sowie viele geeignete Optionen für SAP-Systeme. Sie können auch benutzerdefinierte Bilder aus Ihrer lokalen Umgebung erstellen oder hochladen, oder Sie können bilderkataloge nutzen oder generalisieren.

Ausführliche Informationen zu den verfügbaren Optionen finden Sie unter:

Planen Sie bei Bedarf eine Updateinfrastruktur des Betriebssystems und deren Abhängigkeiten für Ihre SAP-Workload. Erwägen Sie die Verwendung einer Repository-Stagingumgebung, um alle Ebenen einer SAP-Landschaft (Sandkasten, Entwicklung, Vorproduktion und Produktion) synchron zu halten, indem Sie während des Updatezeitraums dieselben Versionen von Patches und Updates verwenden.

VMs der Generation 1 und Generation 2

In Azure können Sie einen virtuellen Computer entweder als Generation 1 oder 2 bereitstellen. Die Unterstützung für VMs der Generation 2 in Azure listet die Azure-VM-Familien auf, die Sie als Generation 2 bereitstellen können. Im Artikel werden auch funktionsbezogene Unterschiede zwischen VMs der Generation 1 und 2 in Azure aufgeführt.

Wenn Sie einen virtuellen Computer bereitstellen, bestimmt das von Ihnen ausgewählte Betriebssystemimage, ob es sich bei dem virtuellen Computer um eine VM der Generation 1 oder um eine VM der Generation 2 handelt. Die neuesten Versionen aller Betriebssystemimages für SAP, die in Azure (Red Hat Enterprise Linux, SuSE Enterprise Linux und Windows oder Oracle Enterprise Linux) verfügbar sind, sind in der Generation 1 und der Generation 2 verfügbar. Es ist wichtig, ein Image basierend auf der Imagebeschreibung sorgfältig auszuwählen, um die richtige Generation von virtuellen Computern bereitzustellen. Ebenso können Sie benutzerdefinierte Betriebssystemimages als Generation 1 oder 2 erstellen und sich auf die Vm-Generierung auswirken, wenn die VM bereitgestellt wird.

Hinweis

Es wird empfohlen, VMs der Generation 2 in allen Sap-Bereitstellungen in Azure zu verwenden, unabhängig von der VM-Größe. Alle neuesten Azure-VMs für SAP sind 2-fähig oder sind auf die Generation 2 beschränkt. Einige VM-Familien unterstützen derzeit nur VMs der Generation 2. Einige VM-Familien, die in Kürze verfügbar sein werden, unterstützen möglicherweise nur die Generation 2.

Sie können ermitteln, ob ein virtueller Computer die Generation 1 oder nur die Generation 2 ist, basierend auf dem ausgewählten Betriebssystemimage. Sie können einen vorhandenen virtuellen Computer nicht von einer Generation in die andere Generation ändern.

Das Ändern einer bereitgestellten VM von Generation 1 auf Generation 2 ist in Azure nicht möglich. Um die VM-Generierung zu ändern, müssen Sie einen neuen virtuellen Computer bereitstellen, der die gewünschte Generation ist, und Ihre Software auf der neuen Generation der VM neu installieren. Diese Änderung wirkt sich nur auf das VHD-Basisimage der VM aus und hat keine Auswirkungen auf die Datenträger oder die angefügten Netzwerkdateisysteme (NETWORK File System, NFS) oder SMB-Freigaben (Server Message Block). Datenträger, NFS-Freigaben oder SMB-Freigaben, die ursprünglich einer VM der Generation 1 zugewiesen wurden, können an einen virtuellen Computer der neuen Generation 2 angefügt werden.

Einige VM-Familien, z. B. die Mv2-Serie, unterstützen nur die Generation 2. Die gleiche Anforderung kann für neue VM-Familien in Zukunft erfüllt sein. In diesem Szenario kann die Größe einer vorhandenen VM der Generation 1 nicht geändert werden, um mit der neuen VM-Familie zu arbeiten. Zusätzlich zu den Anforderungen der Azure-Plattform zur Generation 2 verfügen Ihre SAP-Komponenten möglicherweise über Anforderungen, die mit der Generierung eines virtuellen Computers zusammenhängen. Informationen zu den Anforderungen der Generation 2 für die von Ihnen ausgewählte VM-Familie finden Sie im SAP-Hinweis 1928533.

Leistungsbeschränkungen für Azure-VMs

Als öffentliche Cloud hängt Azure von der Gemeinsamen Infrastruktur auf sichere Weise während der gesamten Kundenbasis ab. Um Skalierung und Kapazität zu aktivieren, werden Leistungsgrenzwerte für jede Ressource und jeden Dienst definiert. Auf der Computeseite der Azure-Infrastruktur ist es wichtig, die Für jede VM-Größe definierten Grenzwerte zu berücksichtigen.

Jede VM verfügt über ein anderes Kontingent auf Datenträger- und Netzwerkdurchsatz, die Anzahl der Datenträger, die angefügt werden können, unabhängig davon, ob sie über lokalen temporären Speicher verfügt, der über einen eigenen Durchsatz und IOPS-Grenzwerte, Arbeitsspeichergröße und die Anzahl der verfügbaren vCPUs verfügt.

Hinweis

Wenn Sie Entscheidungen zur VM-Größe für eine SAP-Lösung in Azure treffen, müssen Sie die Leistungsbeschränkungen für jede VM-Größe berücksichtigen. Die in der Dokumentation beschriebenen Kontingente stellen die theoretischen maximal erreichbaren Werte dar. Der Leistungsgrenzwert von IOPS pro Datenträger kann mit kleinen Eingabe-/Ausgabewerten (z. B. 8 KB) erreicht werden, kann jedoch nicht mit großen E/A-Werten (z. B. 1 MB) erreicht werden.

Wie VMs gibt es für jeden Speichertyp für eine SAP-Workload und für alle anderen Azure-Dienste dieselben Leistungsgrenzwerte.

Berücksichtigen Sie beim Planen und Auswählen von virtuellen Computern, die in Ihrer SAP-Bereitstellung verwendet werden sollen, die folgenden Faktoren:

  • Beginnen Sie mit den Arbeitsspeicher- und CPU-Anforderungen. Trennen Sie die SAPS-Anforderungen für CPU-Leistung in den DBMS-Teil und die SAP-Anwendungsteile. Bei vorhandenen Systemen kann der SAPS im Zusammenhang mit der verwendeten Hardware basierend auf vorhandenen SAP Standard Application Benchmarks ermittelt oder geschätzt werden. Führen Sie für neu bereitgestellte SAP-Systeme eine Größenübung aus, um die SAPS-Anforderungen für das System zu ermitteln.

  • Bei vorhandenen Systemen sollte der E/A-Durchsatz und IOPS auf dem DBMS-Server gemessen werden. Bei neuen Systemen sollte ihnen die Größenanpassung für das neue System auch eine allgemeine Vorstellung der E/A-Anforderungen auf der DBMS-Seite geben. Wenn Sie unsicher sind, müssen Sie schließlich einen Machbarkeitsnachweis durchführen.

  • Vergleichen Sie die SAPS-Anforderung für den DBMS-Server mit dem SAPS, den die verschiedenen VM-Typen von Azure bereitstellen können. Die Informationen zum SAPS der verschiedenen Azure-VM-Typen sind in SAP Note 1928533 dokumentiert. Der Fokus sollte zuerst auf der DBMS-VM liegen, da die Datenbankschicht die Ebene in einem SAP NetWeaver-System ist, das in den meisten Bereitstellungen nicht skaliert wird. Im Gegensatz dazu kann die SAP-Anwendungsschicht verkleinert werden. Einzelne DBMS-Leitfäden beschreiben die empfohlenen Speicherkonfigurationen.

  • Fassen Sie Ihre Ergebnisse zusammen für:

    • Die Anzahl der Azure-VMs, die Sie verwenden möchten.
    • Einzelne VM-Familien- und VM-SKUs für jede SAP-Ebene: DBMS, (A)SCS und Anwendungsserver.
    • E/A-Durchsatzkennzahlen oder berechnete Speicherkapazitätsanforderungen.

HANA Large Instances-Dienst

Azure bietet Computefunktionen zum Ausführen einer scale-up- oder scale-out großen HANA-Datenbank auf einem dedizierten Angebot namens SAP HANA auf Azure Large Instances. Dieses Angebot erweitert die virtuellen Computer, die in Azure verfügbar sind.

Hinweis

Der HANA Large Instances-Dienst befindet sich im Sonnenuntergangsmodus und akzeptiert keine neuen Kunden. Die Bereitstellung von Einheiten für bestehende HANA Large Instances-Kunden ist weiterhin möglich.

Speicher für SAP in Azure

Azure-VMs verwenden verschiedene Speicheroptionen für Persistenz. In einfachen Worten können die virtuellen Computer in persistente und temporäre oder nicht persistente Speichertypen unterteilt werden.

Sie können aus mehreren Speicheroptionen für SAP-Workloads und für bestimmte SAP-Komponenten wählen. Weitere Informationen finden Sie unter Azure Storage für SAP-Workloads. Der Artikel behandelt die Speicherarchitektur für jeden Teil von SAP: Betriebssystem, Anwendungsbinärdateien, Konfigurationsdateien, Datenbankdaten, Protokoll- und Ablaufverfolgungsdateien sowie Dateischnittstellen mit anderen Anwendungen, ob auf dem Datenträger gespeichert oder auf Dateifreigaben zugegriffen wird.

Temporärer Datenträger auf virtuellen Computern

Die meisten Azure-VMs für SAP bieten einen temporären Datenträger, der kein verwalteter Datenträger ist. Verwenden Sie einen temporären Datenträger nur für expendierbare Daten. Die Daten auf einem temporären Datenträger können bei unvorhergesehenen Standard Tenance-Ereignissen oder während der erneuten Bereitstellung des virtuellen Computers verlorengehen. Die Leistungsmerkmale des temporären Datenträgers eignen sich ideal zum Austauschen/Seitendateien des Betriebssystems.

Auf einem temporären Datenträger sollten keine Anwendungs- oder nicht erweiterbaren Betriebssystemdaten gespeichert werden. In Windows-Umgebungen wird in der Regel als Laufwerk D auf das temporäre Laufwerk zugegriffen. In Linux-Systemen ist der Bereitstellungspunkt häufig /dev/sdb-Gerät, /mnt oder /mnt/resource.

Einige VMs bieten kein temporäres Laufwerk an. Wenn Sie diese VM-Größen für SAP verwenden möchten, müssen Sie möglicherweise die Größe des Betriebssystemdatenträgers erhöhen. Weitere Informationen finden Sie im SAP Note 1928533. Für VMs, die über einen temporären Datenträger verfügen, erhalten Sie Informationen über die temporäre Datenträgergröße und die IOPS- und Durchsatzgrenzwerte für jede VM-Serie in "Größen für virtuelle Computer in Azure".

Sie können die Größe nicht direkt zwischen einer VM-Serie mit temporären Datenträgern und einer VM-Serie ändern, die keine temporären Datenträger aufweist. Derzeit schlägt eine Größenänderung zwischen zwei solchen VM-Familien fehl. Eine Lösung besteht darin, den virtuellen Computer neu zu erstellen, auf dem kein temporärer Datenträger in der neuen Größe vorhanden ist, indem ein Betriebssystemdatenträger Momentaufnahme verwendet wird. Behalten Sie alle anderen Datenträger und die Netzwerkschnittstelle bei. Erfahren Sie, wie Sie die Größe einer VM-Größe ändern, die über einen lokalen temporären Datenträger auf eine VM-Größe verfügt, die dies nicht tut.

Netzwerkfreigaben und Volumes für SAP

SAP-Systeme erfordern in der Regel eine oder mehrere Netzwerkdateifreigaben. Die Dateifreigaben sind in der Regel eine der folgenden Optionen:

  • Ein SAP-Transportverzeichnis (/usr/sap/trans oder TRANSDIR).
  • SAP-Volumes oder freigegebene Sapmnt - oder Saploc-Volumes , um mehrere Anwendungsserver bereitzustellen.
  • Hochverfügbarkeitsarchitekturvolumen für SAP (A)SCS, SAP ERS oder eine Datenbank (/hana/shared).
  • Dateischnittstellen, die Drittanbieteranwendungen für den Dateiimport und -export ausführen.

In diesen Szenarien wird empfohlen, einen Azure-Dienst wie Azure-Dateien oder Azure NetApp-Dateien zu verwenden. Wenn diese Dienste in den von Ihnen ausgewählten Regionen nicht verfügbar sind oder sie für Ihre Lösungsarchitektur nicht verfügbar sind, sind Alternativen die Bereitstellung von NFS- oder SMB-Dateifreigaben aus selbstverwalteten, vmbasierten Anwendungen oder Diensten von Drittanbietern. Siehe SAP Hinweis 2015553 zu Einschränkungen der SAP-Unterstützung, wenn Sie Dienste von Drittanbietern für Speicherebenen in einem SAP-System in Azure verwenden.

Aufgrund der häufig kritischen Art von Netzwerkfreigaben und da sie häufig ein einzelner Fehlerpunkt in einem Entwurf (für hohe Verfügbarkeit) oder Prozess (für die Dateischnittstelle) sind, empfehlen wir, dass Sie sich auf jeden nativen Azure-Dienst für seine eigene Verfügbarkeit, SLA und Resilienz verlassen. In der Planungsphase ist es wichtig, diese Faktoren zu berücksichtigen:

  • NFS- oder SMB-Freigabedesign, einschließlich der Freigaben, die pro SAP-System-ID (SID), pro Querformat und pro Region verwendet werden sollen.
  • Subnetzgröße, einschließlich der IP-Anforderung für private Endpunkte oder dedizierte Subnetze für Dienste wie Azure NetApp Files.
  • Netzwerkrouting an SAP-Systeme und verbundene Anwendungen.
  • Verwendung eines öffentlichen oder privaten Endpunkts für Azure Files.

Informationen zu Anforderungen und zur Verwendung einer NFS- oder SMB-Freigabe in einem Szenario mit hoher Verfügbarkeit finden Sie unter "Hohe Verfügbarkeit".

Hinweis

Wenn Sie Azure Files für Ihre Netzwerkfreigaben verwenden, empfehlen wir, einen privaten Endpunkt zu verwenden. Im unwahrscheinlichen Fall eines Zonalfehlers leitet Ihr NFS-Client automatisch zu einer fehlerfreien Zone um. Sie müssen die NFS- oder SMB-Freigaben nicht auf Ihren virtuellen Computern erneut bereitstellen.

Sicherheit für Ihre SAP-Landschaft

Um Ihre SAP-Workload in Azure zu schützen, müssen Sie mehrere Aspekte der Sicherheit planen:

  • Netzwerksegmentierung und die Sicherheit der einzelnen Subnetz- und Netzwerkschnittstellen.
  • Verschlüsselung auf jeder Ebene im SAP-Querformat.
  • Identitätslösung für Endbenutzer- und Administrativen Zugriff und Einmaliges Anmelden.
  • Überwachung von Bedrohungen und Vorgängen.

Die Themen in diesem Kapitel sind keine vollständige Liste aller verfügbaren Dienste, Optionen und Alternativen. Es werden mehrere bewährte Methoden aufgeführt, die für alle SAP-Bereitstellungen in Azure berücksichtigt werden sollten. Je nach Unternehmens- oder Workloadanforderungen gibt es weitere Aspekte, die abgedeckt werden müssen. Weitere Informationen zum Sicherheitsdesign finden Sie in den folgenden Ressourcen für allgemeine Azure-Anleitungen:

Sichern virtueller Netzwerke mithilfe von Sicherheitsgruppen

Die Planung Ihrer SAP-Landschaft in Azure sollte ein gewisses Maß an Netzwerksegmentierung umfassen, wobei virtuelle Netzwerke und Subnetze nur für SAP-Workloads vorgesehen sind. Bewährte Methoden für subnetzdefinition werden in Netzwerk und in anderen Azure-Architekturhandbüchern beschrieben. Es wird empfohlen, NSGs mit ASGs innerhalb von NSGs zu verwenden, um eingehende und ausgehende Verbindungen zu ermöglichen. Wenn Sie ASGs entwerfen, kann jede NIC auf einer VM mehreren ASGs zugeordnet werden, sodass Sie unterschiedliche Gruppen erstellen können. Erstellen Sie z. B. eine ASG für DBMS-VMs, die alle Datenbankserver im gesamten Querformat enthält. Erstellen Sie eine weitere ASG für alle virtuellen Computer (Anwendung und DBMS) einer einzelnen SAP-SID. Auf diese Weise können Sie eine NSG-Regel für die gesamtdatenbank ASG und eine andere, spezifischere Regel nur für die SID-spezifische ASG definieren.

NSGs beschränken die Leistung nicht mit den Regeln, die Sie für die NSG definieren. Zur Überwachung des Datenverkehrsflusses können Sie optional die NSG-Ablaufprotokollierung mit Protokollen aktivieren, die von einem SIEM (Information Event Management) oder Einem Angriffserkennungssystem (Intrusion Detection System, IDS) Ihrer Wahl ausgewertet werden, um verdächtige Netzwerkaktivitäten zu überwachen und zu reagieren.

Tipp

Aktivieren Sie NSGs nur auf Subnetzebene. Obwohl NSGs sowohl auf der Subnetzebene als auch auf der NIC-Ebene aktiviert werden können, ist die Aktivierung auf beiden Seiten bei der Problembehandlung bei der Analyse von Netzwerkdatenverkehrseinschränkungen sehr häufig eine Hinderung. Verwenden Sie NSGs auf der NIC-Ebene nur in Ausnahmefällen und bei Bedarf.

Private Endpunkte für Dienste

Auf viele Azure PaaS-Dienste wird standardmäßig über einen öffentlichen Endpunkt zugegriffen. Obwohl sich der Kommunikationsendpunkt im Azure-Back-End-Netzwerk befindet, wird der Endpunkt für das öffentliche Internet verfügbar gemacht. Private Endpunkte sind eine Netzwerkschnittstelle innerhalb Ihres eigenen privaten virtuellen Netzwerks. Über Azure Private Link überjiziert der private Endpunkt den Dienst in Ihr virtuelles Netzwerk. Ausgewählte PaaS-Dienste werden dann privat über die IP in Ihrem Netzwerk aufgerufen. Je nach Konfiguration kann der Dienst möglicherweise nur für die Kommunikation über privaten Endpunkt festgelegt werden.

Die Verwendung eines privaten Endpunkts erhöht den Schutz vor Datenlecks und vereinfacht häufig den Zugriff von lokalen und Peer-Netzwerken. In vielen Situationen wird das Netzwerkrouting und der Prozess zum Öffnen von Firewallports vereinfacht, die häufig für öffentliche Endpunkte erforderlich sind. Die Ressourcen befinden sich bereits in Ihrem Netzwerk, da auf sie von einem privaten Endpunkt zugegriffen wird.

Informationen dazu, welche Azure-Dienste die Möglichkeit bieten, einen privaten Endpunkt zu verwenden, finden Sie unter "Privater Link" verfügbare Dienste. Für NFS oder SMB mit Azure Files wird empfohlen, dass Sie immer private Endpunkte für SAP-Workloads verwenden. Weitere Informationen zu Gebühren, die mit dem Dienst anfallen, finden Sie unter "Preise für private Endpunkte". Einige Azure-Dienste können optional die Kosten für den Dienst enthalten. Diese Informationen sind in den Preisinformationen eines Diensts enthalten.

Verschlüsselung

Je nach Ihren Unternehmensrichtlinien ist die Verschlüsselung über die Standardoptionen in Azure hinaus für Ihre SAP-Workloads erforderlich.

Verschlüsselung für Infrastrukturressourcen

Standardmäßig werden verwaltete Datenträger und BLOB-Speicher in Azure mit einem plattformverwalteten Schlüssel (PMK) verschlüsselt. Darüber hinaus wird die BYOK-Verschlüsselung (Own Key) für verwaltete Datenträger und BLOB-Speicher für SAP-Workloads in Azure unterstützt. Für die Verschlüsselung verwalteter Datenträger können Sie je nach Sicherheitsanforderungen Ihres Unternehmens aus verschiedenen Optionen auswählen. Zu den Azure-Verschlüsselungsoptionen gehören:

  • Speicherseitige Verschlüsselung (SSE) PMK (SSE-PMK)
  • Vom Kunden verwalteter SSE-Schlüssel (SSE-CMK)
  • Doppelte Verschlüsselung im Ruhezustand
  • Hostbasierte Verschlüsselung

Weitere Informationen, einschließlich einer Beschreibung der Azure Disk Encryption, finden Sie unter einem Vergleich der Azure-Verschlüsselungsoptionen.

Hinweis

Verwenden Sie derzeit keine hostbasierte Verschlüsselung auf einem virtuellen Computer, der sich in der VM-Familie der M-Serie befindet, wenn sie mit Linux ausgeführt wird, aufgrund einer potenziellen Leistungsbeschränkung. Die Verwendung der SSE-CMK-Verschlüsselung für verwaltete Datenträger ist von dieser Einschränkung unberührt.

Verwenden Sie für SAP-Bereitstellungen auf Linux-Systemen keine Azure Disk Encryption. Azure Disk Encryption umfasst verschlüsselungsausführung innerhalb der SAP-VMs mithilfe von CMKs aus Azure Key Vault. Für Linux unterstützt Azure Disk Encryption nicht die Betriebssystemimages, die für SAP-Workloads verwendet werden. Azure Disk Encryption kann auf Windows-Systemen mit SAP-Workloads verwendet werden, jedoch keine Azure Disk Encryption mit der systemeigenen Datenbankverschlüsselung kombinieren. Es wird empfohlen, die systemeigene Datenbankverschlüsselung anstelle der Azure Disk Encryption zu verwenden. Weitere Informationen finden Sie im nächsten Abschnitt.

Ähnlich wie bei der verwalteten Datenträgerverschlüsselung ist die Azure Files-Verschlüsselung ruhender Dateien (SMB und NFS) mit PMKs oder CMKs verfügbar.

Überprüfen Sie bei SMB-Netzwerkfreigaben Azure Files und Betriebssystemabhängigkeiten mit SMB-Versionen sorgfältig, da sich die Konfiguration auf die Unterstützung für die Verschlüsselung während der Übertragung auswirkt.

Wichtig

Die Bedeutung eines sorgfältigen Plans zum Speichern und Schützen der Verschlüsselungsschlüssel, wenn Sie die vom Kunden verwaltete Verschlüsselung verwenden, kann nicht überstatiert werden. Ohne Verschlüsselungsschlüssel sind verschlüsselte Ressourcen wie Datenträger nicht zugänglich und können zu Datenverlusten führen. Berücksichtigen Sie sorgfältig den Schutz der Schlüssel und den Zugriff auf die Schlüssel nur für privilegierte Benutzer oder Dienste.

Verschlüsselung für SAP-Komponenten

Die Verschlüsselung auf SAP-Ebene kann in zwei Ebenen unterteilt werden:

  • DBMS-Verschlüsselung
  • Transportverschlüsselung

Für die DBMS-Verschlüsselung unterstützt jede Datenbank, die für eine SAP NetWeaver- oder SAP S/4HANA-Bereitstellung unterstützt wird, systemeigene Verschlüsselung. Transparente Datenbankverschlüsselung ist völlig unabhängig von jeder Infrastrukturverschlüsselung, die in Azure vorhanden ist. Sie können die SSE- und Datenbankverschlüsselung gleichzeitig verwenden. Wenn Sie Verschlüsselung verwenden, ist der Speicherort, die Speicherung und die Sichere Aufbewahrung von Verschlüsselungsschlüsseln von entscheidender Bedeutung. Jeder Verlust von Verschlüsselungsschlüsseln führt zu Datenverlust, da Sie Ihre Datenbank nicht starten oder wiederherstellen können.

Einige Datenbanken verfügen möglicherweise nicht über eine Datenbankverschlüsselungsmethode oder erfordern möglicherweise keine dedizierte Einstellung zum Aktivieren. Bei anderen Datenbanken werden DBMS-Sicherungen möglicherweise implizit verschlüsselt, wenn die Datenbankverschlüsselung aktiviert wird. In der folgenden SAP-Dokumentation erfahren Sie, wie Sie die transparente Datenbankverschlüsselung aktivieren und verwenden:

Wenden Sie sich an SAP oder Ihren DBMS-Anbieter, um Unterstützung für die Aktivierung, Verwendung oder Problembehandlung bei der Softwareverschlüsselung zu erfahren.

Wichtig

Es kann nicht überstatiert werden, wie wichtig es ist, einen sorgfältigen Plan zum Speichern und Schützen Ihrer Verschlüsselungsschlüssel zu haben. Ohne Verschlüsselungsschlüssel kann auf die Datenbank oder SAP-Software nicht zugegriffen werden, und Sie verlieren möglicherweise Daten. Überlegen Sie sorgfältig, wie Sie die Schlüssel schützen. Zugriff auf die Schlüssel nur durch privilegierte Benutzer oder Dienste zulassen.

Transport- oder Kommunikationsverschlüsselung kann auf SQL Server-Verbindungen zwischen SAP-Engines und DBMS angewendet werden. Ebenso können Sie Verbindungen über die SAP-Präsentationsebene (SAPGui secure network connection oder SNC) oder eine HTTPS-Verbindung mit einem Web-Front-End verschlüsseln. Lesen Sie die Dokumentation des Anwendungsanbieters, um die Verschlüsselung während der Übertragung zu aktivieren und zu verwalten.

Bedrohungsüberwachung und Warnung

Um Bedrohungsüberwachungs- und Warnungslösungen bereitzustellen und zu verwenden, verwenden Sie zunächst die Architektur Ihrer Organisation. Azure-Dienste bieten Bedrohungsschutz und eine Sicherheitsansicht, die Sie in Ihren gesamten SAP-Bereitstellungsplan integrieren können. Microsoft Defender für Cloud behebt die Anforderung zum Schutz vor Bedrohungen. Defender for Cloud ist in der Regel Teil eines allgemeinen Governancemodells für eine gesamte Azure-Bereitstellung, nicht nur für SAP-Komponenten.

Weitere Informationen zur Sicherheitsinformationsereignisverwaltung (SECURITY Information Event Management, SIEM) und Lösungen zur automatisierten Reaktion (Automated Response, SOAR) finden Sie unter Microsoft Sentinel-Lösungen für die SAP-Integration.

Sicherheitssoftware in SAP-VMs

SAP Note 2808515 for Linux and SAP Note 106267 for Windows describe requirements and best practices when you use virus scanners or security software on SAP servers. Es wird empfohlen, die SAP-Empfehlungen zu befolgen, wenn Sie SAP-Komponenten in Azure bereitstellen.

Hochverfügbarkeit

Die hohe Verfügbarkeit von SAP in Azure umfasst zwei Komponenten:

  • Hohe Verfügbarkeit der Azure-Infrastruktur: Hohe Verfügbarkeit von Azure Compute (VMs), Netzwerk- und Speicherdiensten und wie sie die SAP-Anwendungsverfügbarkeit erhöhen können.

  • HOHE Verfügbarkeit der SAP-Anwendung: Wie sie mit der Hohen Verfügbarkeit der Azure-Infrastruktur kombiniert werden kann, verwenden Sie die Dienstheilung. Ein Beispiel, das hohe Verfügbarkeit in SAP-Softwarekomponenten verwendet:

    • Eine SAP (A)SCS- und SAP ERS-Instanz
    • Der Datenbankserver

Weitere Informationen zur hohen Verfügbarkeit von SAP in Azure finden Sie in den folgenden Artikeln:

Pacemaker unter Linux und Windows Server-Failoverclustering sind die einzigen Hochverfügbarkeitsframeworks für SAP-Workloads, die direkt von Microsoft in Azure unterstützt werden. Jedes andere Hochverfügbarkeitsframework wird von Microsoft nicht unterstützt und benötigt Design-, Implementierungsdetails und Betriebsunterstützung vom Anbieter. Weitere Informationen finden Sie unter "Unterstützte Szenarien für SAP in Azure".

Notfallwiederherstellung

Häufig gehören SAP-Anwendungen zu den geschäftskritischen Prozessen in einem Unternehmen. Basierend auf ihrer Bedeutung und der Zeit, die nach einer unvorhergesehenen Unterbrechung wieder betriebsbereit sein muss, sollten BcDR-Szenarien (Business Continuity and Disaster Recovery) sorgfältig geplant werden.

Informationen zur Behebung dieser Anforderung finden Sie unter Übersicht über die Notfallwiederherstellung und Infrastrukturrichtlinien für SAP-Workload.

Backup

Im Rahmen Ihrer BCDR-Strategie muss die Sicherung ihrer SAP-Workload ein integraler Bestandteil jeder geplanten Bereitstellung sein. Die Sicherungslösung muss alle Ebenen eines SAP-Lösungsstapels abdecken: VM, Betriebssystem, SAP-Anwendungsschicht, DBMS-Ebene und jede freigegebene Speicherlösung. Sicherung für Azure-Dienste, die von Ihrer SAP-Workload verwendet werden, und für andere wichtige Ressourcen wie Verschlüsselung und Zugriffstasten müssen ebenfalls Teil Ihres Sicherungs- und BCDR-Designs sein.

Azure Backup bietet PaaS-Lösungen für die Sicherung:

  • VM-Konfiguration, Betriebssystem und SAP-Anwendungsschicht (Datenänderung auf verwalteten Datenträgern) über Azure Backup für VM. Überprüfen Sie die Supportmatrix , um zu überprüfen, ob Ihre Architektur diese Lösung verwenden kann.
  • SQL Server - und SAP HANA-Datenbankdaten und Protokollsicherung. Es umfasst Unterstützung für Datenbankreplikationstechnologien, z. B. HANA-Systemreplikation oder SQL Always On, und regionsübergreifende Unterstützung für gekoppelte Regionen.
  • Dateifreigabesicherung über Azure Files. Überprüfen Sie die Unterstützung für NFS oder SMB und andere Konfigurationsdetails.

Wenn Sie Azure NetApp Files bereitstellen, stehen auch Sicherungsoptionen auf Volumeebene zur Verfügung , einschließlich SAP HANA- und Oracle DBMS-Integration mit einer geplanten Sicherung.

Azure Backup-Lösungen bieten eine Option zum vorläufigen Löschen, um böswillige oder versehentliche Löschungen zu verhindern und Datenverluste zu verhindern. Das vorläufige Löschen ist auch für Dateifreigaben verfügbar, die Sie mithilfe von Azure Files bereitstellen.

Sicherungsoptionen stehen für eine Lösung zur Verfügung, die Sie selbst erstellen und verwalten oder wenn Sie Software von Drittanbietern verwenden. Eine Option besteht darin, die Dienste mit Azure Storage zu verwenden, einschließlich des unveränderlichen Speichers für BLOB-Daten. Diese selbstverwaltete Option wäre derzeit als DBMS-Sicherungsoption für einige Datenbanken wie SAP ASE oder IBM Db2 erforderlich.

Verwenden Sie die Empfehlungen in den bewährten Methoden von Azure, um Ransomware-Angriffe zu schützen und zu überprüfen.

Tipp

Stellen Sie sicher, dass Ihre Sicherungsstrategie den Schutz Ihrer Bereitstellungsautomatisierung, Verschlüsselungsschlüssel für Azure-Ressourcen und die transparente Datenbankverschlüsselung bei Verwendung umfasst.

Regionsübergreifende Sicherung

Bestimmen Sie für jede regionsübergreifende Sicherungsanforderung das Recovery Time Objective (RTO) und das RPO (Recovery Point Objective), das von der Lösung angeboten wird, und ob sie Ihrem BCDR-Design und Ihren Anforderungen entspricht.

SAP-Migration zu Azure

Es ist nicht möglich, alle Migrationsansätze und Optionen für die große Vielfalt von SAP-Produkten, Versionsabhängigkeiten und systemeigenen Betriebssystem- und DBMS-Technologien zu beschreiben, die verfügbar sind. Das Projektteam für Ihre Organisation und Vertreter von Ihrem Dienstanbieter sollte mehrere Techniken für eine reibungslose SAP-Migration zu Azure in Betracht ziehen.

  • Testen Sie die Leistung während der Migration. Ein wichtiger Bestandteil der SAP-Migrationsplanung ist technische Leistungstests. Das Migrationsteam muss genügend Zeit und Verfügbarkeit ermöglichen, damit wichtige Mitarbeiter Anwendungs- und technische Tests des migrierten SAP-Systems ausführen können, einschließlich verbundener Schnittstellen und Anwendungen. Für eine erfolgreiche SAP-Migration ist es wichtig, die Vormigration und die Nachmigrationslaufzeit und Genauigkeit wichtiger Geschäftsprozesse in einer Testumgebung zu vergleichen. Verwenden Sie die Informationen, um die Prozesse zu optimieren, bevor Sie die Produktionsumgebung migrieren.

  • Verwenden Sie Azure-Dienste für die SAP-Migration. Einige VM-basierte Workloads werden ohne Änderung an Azure mithilfe von Diensten wie Azure Migrate oder Azure Site Recovery oder einem Drittanbietertool migriert. Vergewissern Sie sich sorgfältig, dass die Betriebssystemversion und die ausgeführte SAP-Workload vom Dienst unterstützt werden.

    Häufig wird jede Datenbankarbeitsauslastung absichtlich nicht unterstützt, da ein Dienst die Datenbankkonsistenz nicht garantieren kann. Wenn der DBMS-Typ vom Migrationsdienst unterstützt wird, ist die Datenbankänderungs- oder Änderungsrate häufig zu hoch. Die meisten ausgelasteten SAP-Systeme erfüllen nicht die Änderungsrate, die Migrationstools zulassen. Probleme werden möglicherweise erst nach der Produktionsmigration angezeigt oder erkannt. In vielen Fällen eignen sich einige Azure-Dienste nicht für die Migration von SAP-Systemen. Azure Site Recovery und Azure Migrate haben keine Validierung für eine umfangreiche SAP-Migration. Eine bewährte SAP-Migrationsmethodik ist die Verwendung von DBMS-Replikations- oder SAP-Migrationstools.

    Eine Bereitstellung in Azure anstelle einer einfachen VM-Migration ist vorzuziehen und einfacher zu erreichen als eine lokale Migration. Automatisierte Bereitstellungsframeworks wie Azure Center für SAP-Lösungen und Azure-Bereitstellungsautomatisierungs-Framework ermöglichen eine schnelle Ausführung automatisierter Aufgaben. Um Ihre SAP-Landschaft in eine neue bereitgestellte Infrastruktur zu migrieren, indem Sie systemeigene DBMS-Replikationstechnologien wie HANA-Systemreplikation, DBMS-Sicherung und -Wiederherstellung verwenden oder SAP-Migrationstools etablierte technische Kenntnisse Ihres SAP-Systems verwenden.

  • Infrastrukturskalierung. Während einer SAP-Migration können Sie mit mehr Infrastrukturkapazität schneller bereitstellen. Das Projektteam sollte die Skalierung der VM-Größe in Betracht ziehen, um mehr CPU und Arbeitsspeicher bereitzustellen. Das Team sollte auch die Skalierung des vm-Aggregatspeichers und des Netzwerkdurchsatzes in Betracht ziehen. In ähnlicher Weise sollten Sie auf VM-Ebene Speicherelemente wie einzelne Datenträger in Betracht ziehen, um den Durchsatz mit On-Demand-Bursting und Leistungsstufen für Premium SSD v1 zu erhöhen. Erhöhen Sie IOPS- und Durchsatzwerte, wenn Sie Premium SSD v2 über den konfigurierten Werten verwenden. Vergrößern Sie NFS- und SMB-Dateifreigaben, um Leistungsbeschränkungen zu erhöhen. Beachten Sie, dass Azure-Datenträger verwalten nicht in der Größe reduziert werden können, und dass die Größenreduzierung, Leistungsstufen und Durchsatz-KPIs verschiedene Kühlzeiten aufweisen können.

  • Optimieren Sie die Netzwerk- und Datenkopie. Die Migration eines SAP-Systems zu Azure umfasst immer das Verschieben einer großen Datenmenge. Bei den Daten kann es sich um Datenbank- und Dateisicherungen oder Replikation, eine Übertragung von Anwendungs-zu-Anwendung-Daten oder um einen SAP-Migrationsexport handeln. Je nach dem verwendeten Migrationsprozess müssen Sie den richtigen Netzwerkpfad auswählen, um die Daten zu verschieben. Bei vielen Datenverschiebungsvorgängen ist die Verwendung des Internets anstelle eines privaten Netzwerks der schnellste Pfad zum sicheren Kopieren von Daten in Azure Storage.

    Die Verwendung von ExpressRoute oder einem VPN kann zu Engpässen führen:

    • Die Migrationsdaten verwenden zu viel Bandbreite und beeinträchtigen den Benutzerzugriff auf Workloads, die in Azure ausgeführt werden.
    • Lokale Netzwerkengpässe, z. B. eine Firewall oder eine Durchsatzbegrenzung, werden häufig nur während der Migration erkannt.

    Unabhängig von der verwendeten Netzwerkverbindung ist die Netzwerkleistung für eine Datenverschiebung häufig gering. Um die Geschwindigkeit der Datenübertragung über mehrere TCP-Streams zu erhöhen, verwenden Sie Tools, die mehrere Streams unterstützen können. Wenden Sie Optimierungstechniken an, die in der SAP-Dokumentation und in vielen Blogbeiträgen zu diesem Thema beschrieben werden.

Tipp

In der Planungsphase ist es wichtig, alle dedizierten Migrationsnetzwerke zu berücksichtigen, die Sie für große Datenübertragungen an Azure verwenden werden. Beispiele sind Sicherungen oder Datenbankreplikationen oder die Verwendung eines öffentlichen Endpunkts für Datenübertragungen an Azure Storage. Die Auswirkungen der Migration auf Netzwerkpfade für Ihre Benutzer und Anwendungen sollten erwartet und abgemildert werden. Berücksichtigen Sie im Rahmen Der Netzwerkplanung alle Phasen der Migration und die Kosten einer teilweise produktiven Arbeitsauslastung in Azure während der Migration.

Support und Betrieb für SAP

Einige andere Bereiche sind wichtig, vor und während der SAP-Bereitstellung in Azure zu berücksichtigen.

Azure-VM-Erweiterung für SAP

Azure Monitoring Extension, Enhanced Monitoring und Azure Extension für SAP beziehen sich alle auf eine VM-Erweiterung, die Sie bereitstellen müssen, um einige grundlegende Daten zur Azure-Infrastruktur für den SAP-Host-Agent bereitzustellen. SAP-Hinweise beziehen sich möglicherweise auf die Erweiterung als Monitoring Extension oder enhanced monitoring. In Azure heißt es Azure-Erweiterung für SAP. Für Supportzwecke muss die Erweiterung auf allen Azure-VMs installiert werden, die eine SAP-Workload ausführen. Weitere Informationen finden Sie unter azure VM-Erweiterung für SAP.

SAProuter für SAP-Support

Für den Betrieb einer SAP-Landschaft in Azure ist eine Verbindung mit und von SAP für Supportzwecke erforderlich. In der Regel befindet sich die Konnektivität in Form einer SAProuter-Verbindung, entweder über einen Verschlüsselungsnetzwerkkanal über das Internet oder über eine private VPN-Verbindung mit SAP. Bewährte Methoden und eine Beispielimplementierung von SAProuter in Azure finden Sie in Ihrem Architekturszenario in eingehenden und ausgehenden Internetverbindungen für SAP in Azure.

Nächste Schritte