Freigeben über

Azure Virtual Machines – DBMS-Bereitstellung für SAP-Workload

  • Artikel

Dieses Handbuch ist Teil der Dokumentation zur Implementierung und Bereitstellung von SAP-Software in Microsoft Azure. Lesen Sie vor diesem Handbuch das Planungs- und Implementierungshandbuch sowie die dort erwähnten Artikel. Dieses Dokument behandelt die allgemeinen Aspekte der Bereitstellung von DBMS-Systemen für SAP auf Microsoft Azure Virtual Machines (VMs) mit der IaaS-Funktion (Infrastructure-as-a-Service) von Azure.

Das Dokument ergänzt die SAP-Installationsdokumentation und die SAP-Hinweise, die die primäre Ressource für Installationen und Bereitstellungen von SAP-Software auf verschiedenen Plattformen darstellen.

In diesem Dokument werden Überlegungen zum Ausführen von DBMS-Systemen für SAP auf Azure-VMs vorgestellt. Dieses Dokument enthält nur wenige Verweise auf spezifische DBMS-Systeme. Stattdessen werden die einzelnen DBMS-Systeme in anderen datenbanksystemspezifischen Dokumenten behandelt.

Ressourcen

Zur SAP-Workload in Azure sind weitere Artikel verfügbar. Beginnen Sie mit Erste Schritte mit SAP in Azure-VMs, und wählen Sie dann den gewünschten Bereich.

Die folgenden SAP-Hinweise beziehen sich auf SAP in Azure und die in diesem Dokument behandelten Themen:

Hinweisnummer Titel
1928533 SAP-Anwendungen in Azure: Unterstützte Produkte und Azure-VM-Typen
2015553 SAP auf Microsoft Azure: Supportvoraussetzungen
1999351 Problembehandlung für die erweiterte Azure-Überwachung für SAP
2178632 Wichtige Überwachungsmetriken für SAP in Microsoft Azure
1409604 Virtualisierung unter Windows: Erweiterte Überwachung
2191498 SAP unter Linux mit Azure: Erweiterte Überwachung
2039619 SAP-Anwendungen auf Microsoft Azure mit der Oracle-Datenbank: Unterstützte Produkte und Versionen
2233094 DB6: SAP-Anwendungen in Azure mit IBM DB2 für Linux, UNIX und Windows: Zusätzliche Informationen
2243692 Microsoft Azure (IaaS)-VM: SAP-Lizenzprobleme
2578899 SUSE Linux Enterprise Server 15: Installationshinweis
1984787 SUSE LINUX Enterprise Server 12: Installationshinweise
2772999 Red Hat Enterprise Linux 8.x: Installation und Konfiguration
2002167 Red Hat Enterprise Linux 7.x: Installation und Upgrade
2069760 Oracle Linux 7.x SAP: Installation und Upgrade
1597355 Empfehlung zu Auslagerungsbereichen für Linux
2799900 Zentraler technischer Hinweis für Oracle Database 19c
2171857 Oracle Database 12c: Dateisystemunterstützung unter Linux
1114181 Oracle Database 11g: Dateisystemunterstützung unter Linux
2969063 Fehler bei der Microcodeüberprüfung in HCMT in Azure
3246210 Azure – HCMT schlägt bei einigen Datenträgerleistungstests fehl

Informationen für alle SAP-Hinweise für Linux finden Sie im Wiki der SAP-Community.

Sie benötigen Kenntnisse der Microsoft Azure-Architektur sowie der Bereitstellung und Verwendung von virtuellen Microsoft Azure-Computern. Weitere Informationen finden Sie in der Azure-Dokumentation.

Installation und Konfiguration von Windows, Linux und DBMS sind generell weitgehend identisch mit allen VMs oder Bare-Metal-Computern, die Sie lokal installieren. Bei der Implementierung der Architektur und Systemverwaltung gibt es jedoch einige Entscheidungen, die bei der Nutzung von Azure IaaS anders sind. Dieses Dokument erläutert die spezifischen Unterschiede bei Architektur und Systemverwaltung, die Sie bei der Verwendung von Azure IaaS kennen sollten.

Speicherstruktur einer VM für RDBMS-Bereitstellungen

Damit Sie diesem Kapitel folgen können, sollten Sie diese Informationen gelesen und verstanden haben:

Für Azure-Blockspeicher ist die Verwendung von verwalteten Azure-Datenträgern obligatorisch. Ausführliche Informationen zu verwalteten Azure-Datenträgern finden Sie im Artikel Einführung in verwaltete Azure-Datenträger.

In einer Basiskonfiguration eignet sich eine Bereitstellungsstruktur, bei der das Betriebssystem, das DBMS und eventuelle SAP-Binärdateien von den Datenbankdateien getrennt sind. Wir empfehlen, separate Azure-Datenträger für Folgendes zu verwenden:

  • Betriebssystem (Basis-VHD oder Betriebssystem-VHD)
  • Ausführbare Dateien für das Datenbank-Managementsystem
  • Ausführbare SAP-Dateien wie „/usr/sap“
  • DBMS-Datendateien
  • DBMS-Wiederholungsprotokolldateien

Eine Konfiguration, die diese Komponenten in fünf verschiedene Volumes trennt, kann zu einer höheren Resilienz führen, da eine übermäßige Nutzung auf einem Volume nicht notwendigerweise die Verwendung anderer Volumes beeinträchtigt, solange das VM-Speicherkontingent und die -Grenzwerte nicht überschritten werden.

Die DBMS-Daten- und Transaktions-/Wiederholungsprotokolldateien werden in von Azure unterstützten Blockspeichern oder in Azure NetApp Files gespeichert. Azure Files oder Azure Premium Files wird nicht als Speicher für DBSM-Daten und/oder Wiederholungsprotokolldateien mit der SAP-Workload unterstützt. Sie werden auf separaten Datenträgern gespeichert und als logische Datenträger an die ursprüngliche Azure-VM mit dem Betriebssystemimage angefügt. Für Linux-Bereitstellungen sind andere Empfehlungen dokumentiert. Im Artikel Azure Storage-Typen für die SAP-Workload finden Sie Informationen zu den Funktionen und zur Unterstützung der verschiedenen Speichertypen für Ihr Szenario. Starten Sie insbesondere für SAP HANA mit dem Artikel SAP HANA: Azure-VM-Speicherkonfigurationen.

Ermitteln Sie beim Planen Ihres Festplattenlayouts die beste Balance zwischen diesen Elementen:

  • Die Anzahl der Datendateien.
  • Die Anzahl von Datenträgern, die die Dateien enthalten
  • IOPS-Kontingente eines einzelnen Datenträgers oder einer NFS-Freigabe
  • Datendurchsatz pro Datenträger oder NFS-Freigabe
  • Die Anzahl der für die jeweilige VM-Größe möglichen zusätzlichen Datenträger
  • Gesamtdurchsatz für Speicher oder Netzwerk, den eine VM bereitstellen kann
  • Die Latenz verschiedener Azure Storage-Typen.
  • VM-Speicher-IOPS und Durchsatzkontingent
  • VM-Netzwerkkontingent, falls Sie NFS verwenden: Der Datenverkehr an NFS-Freigaben wird auf das Netzwerkkontingent der VM angerechnet und NICHT auf das Speicherkontingent.
  • SLAs für VMs.

Azure erzwingt ein IOPS-Kontingent pro Datenträger oder NFS-Freigabe. Diese Kontingente unterscheiden sich je nach den Datenträgern, die in den verschiedenen Azure-Blockspeicherlösungen oder -Freigaben gehostet werden. Auch die E/A-Latenz unterscheidet sich zwischen den beiden Speichertypen.

Für jeden der verschiedenen VM-Typen können Sie eine begrenzte Anzahl von Datenträgern anfügen. Eine weitere Einschränkung besteht darin, dass nur bestimmte VM-Typen beispielsweise Storage Premium nutzen können. In der Regel entscheiden Sie sich basierend auf CPU- und Arbeitsspeicheranforderungen für einen bestimmten VM-Typ. Sie müssen auch die Anforderungen an IOPS, Latenz und Festplattendurchsatz berücksichtigen, die normalerweise mit der Anzahl der Festplatten oder dem Typ der Storage Premium-Datenträger v1 skaliert werden. Die Festplattengröße kann insbesondere bei Storage Premium v1 durch die Anzahl der IOPS und den Durchsatz bestimmt werden, den jeder Datenträger erreichen muss. Mit Storage Premium v2- oder Ultra-Datenträgern können Sie die bereitgestellten IOPS und den Durchsatz unabhängig von der Datenträgerkapazität auswählen.

Hinweis

Für DBMS-Bereitstellungen raten wir dringend zu Azure Storage Premium (v1 und v2), Disk Ultra oder auf Azure NetApp Files basierenden NFS-Freigaben für alle Daten-, Transaktionsprotokoll- oder Wiederholungsdateien. Dabei spielt es keine Rolle, ob Sie Produktionssysteme bereitstellen möchten oder nicht. Die Latenz von Azure Standard HDD oder SSD ist für jegliche Art von Produktionssystem ungeeignet.

Hinweis

Zur Maximierung der SLA für einzelne VM-Instanzen in Azure müssen alle angefügten Datenträger den Typ „Azure Storage Premium“ (v1 oder v2) oder „Azure Disk Ultra“ aufweisen. Dies gilt auch für die Basis-VHD (Azure Storage Premium).

Hinweis

Das Hosten von Hauptdatenbankdateien wie Daten- und Protokolldateien von SAP-Datenbanken auf Speicherhardware, die sich in gemeinsam untergebrachten Drittanbieter-Datencentern neben Azure-Datencentern befindet, wird nicht unterstützt. Speicher, der über auf Azure-VMs gehostete Softwareappliances bereitgestellt wird, wird für diesen Anwendungsfall ebenfalls nicht unterstützt. Bei SAP-DBMS-Workloads wird für die Daten- und Transaktionsprotokolldateien von SAP-Datenbanken allgemein nur Speicher unterstützt, der als nativer Azure-Dienst umgesetzt ist. Unterschiedliche Datenbank-Managementsysteme unterstützen möglicherweise unterschiedliche Azure-Speichertypen. Weitere Informationen finden Sie im Artikel Azure Storage-Typen für die SAP-Workload.

Die Platzierung der Datenbank-, Transaktions- oder Wiederholungsdateien sowie der verwendete Azure Storage-Typ werden durch die Anforderungen an IOPS, Latenz und Durchsatz definiert. Damit speziell für Azure Storage Premium v1 ausreichend IOPS verfügbar ist, müssen Sie möglicherweise mehrere Datenträger oder einen größeren Storage Premium-Datenträger verwenden. Falls Sie mehrere Datenträger verwenden, erstellen Sie einen Softwarestripe über die Datenträger hinweg, die die Datendateien oder die Protokoll- und Wiederholungsdateien enthalten. In solchen Fällen sind die IOPS- und die Datenträgerdurchsatz-SLAs der zugrunde liegenden Storage Premium-Datenträger oder der maximal erzielbare IOPS der Storage Standard-Datenträger kumulativ für das resultierende Stripeset.

Wenn Ihre IOPS-Anforderungen die Leistung übersteigen, die eine einzelne VHD bereitstellen kann, müssen Sie die für die Datenbankdateien benötigten IOPS-Vorgänge auf mehrere VHDs verteilen. Die einfachste Möglichkeit, die IOPS-Last auf verschiedene Datenträger zu verteilen, ist das Erstellen eines Softwarestripes über die verschiedenen Datenträger hinweg. Fügen Sie dann den LUNs im Softwarestripe eine Anzahl von Datendateien des SAP-DBMS hinzu. Die Anzahl von Datenträgern im Stripe wird von den Anforderungen an IOPS, Datenträgerdurchsatz und Volumes bestimmt.

Speicherstriping unter Windows Windows

Es wird empfohlen, Windows-Speicherplätze zum Erstellen von Stripesets über mehrere Azure-VHDs hinweg zu verwenden. Verwenden Sie mindestens Windows Server 2012 R2 oder Windows Server 2016.

Speicherstriping unter Linux Linux

Nur MDADM und Logical Volume Manager (LVM) werden unterstützt, um ein Software-RAID unter Linux zu erstellen. Weitere Informationen finden Sie unter

Für Azure Storage Premium v2 und Disk Ultra ist möglicherweise kein Striping erforderlich, weil Sie IOPS und Datenträgerdurchsatz unabhängig von der Größe des Datenträgers definieren können.

Hinweis

Da Azure Storage drei Images der VHDs speichert, ist es nicht ratsam, beim Striping eine Redundanz zu konfigurieren. Sie müssen nur das Striping so konfigurieren, dass die E/A-Vorgänge auf die verschiedenen VHDs verteilt werden.

Verwaltete oder nicht verwaltete Datenträger

Ein Azure-Speicherkonto ist nicht nur ein Konzept für Verwaltungsaufgaben, sondern stellt auch eine Gruppe von Einschränkungen dar. Informationen zu Funktionen und Einschränkungen finden Sie unter Skalierbarkeits- und Leistungsziele für Azure Storage. Denken Sie daran, dass bei Storage Standard eine Begrenzung der IOPS pro Speicherkonto gilt. Finden Sie die Zeile mit der Gesamtanforderungsrate im Artikel Skalierbarkeits- und Leistungsziele für Azure Storage. Für Speicherkonten gilt pro Azure-Abonnement außerdem eine anfängliche Einschränkung. Ab 2017 hat Azure die Konzepte von Azure Managed Disks eingeführt, dank derer Sie sich nicht mehr um die Verwaltung von Speicherkonten kümmern müssen. Die Verwendung von verwalteten Azure-Datenträgern ist das Standardverhalten für die Bereitstellung einer SAP-Workload in Azure.

Wichtig

Angesichts der Vorteile ist es obligatorisch, Azure Managed Disks für Ihre DBMS-Bereitstellungen und SAP-Bereitstellungen im Allgemeinen zu verwenden.

Wenn Sie über eine SAP-Workload verfügen, die noch keine verwalteten Datenträger verwendet, finden Sie hier weitere Informationen zum Konvertieren von nicht verwalteten Datenträgern in verwaltete Datenträger:

Zwischenspeichern für VMs und Datenträger

Wenn Sie Datenträger auf VMs bereitstellen, können Sie auswählen, ob der E/A-Datenverkehr zwischen der VM und diesen Datenträgern in Azure Storage zwischengespeichert wird.

Bei den folgenden Empfehlungen werden die E/A-Merkmale für Standard-DBMS zugrunde gelegt:

  • Es handelt sich hauptsächlich um Lesevorgänge für Datendateien einer Datenbank. Diese Lesevorgänge sind leistungskritisch für das DBMS-System.
  • Das Schreiben in die Datendateien erfolgt in Bursts, die auf Prüfpunkten oder einem konstanten Datenstrom basieren. Pro Tag erfolgen im Durchschnitt weniger Schreib- als Lesezugriffe. Im Gegensatz zum Lesen von Datendateien sind diese Schreibvorgänge asynchron und verzögern keine Benutzertransaktionen.
  • Es gibt kaum Lesevorgänge aus den Transaktionsprotokollen oder Wiederholungsdateien. Ausnahmen sind große E/A-Vorgänge beim Ausführen von Transaktionsprotokollsicherungen.
  • Bei Transaktions- und Wiederholungsprotokolldateien stellen Schreibvorgänge die Hauptlast dar. Je nach Art der Workload kann die Größe von E/As bis zu 4 KB herunter- oder in anderen Fällen bis zu 1 MB oder mehr heraufreichen.
  • Alle Schreibvorgänge müssen zuverlässig und dauerhaft auf einem Datenträger gespeichert werden.

Azure Storage Premium v1 bietet die folgenden Optionen für die Zwischenspeicherung:

  • Keine
  • Lesen
  • Lesen/Schreiben
  • Keine + Schreibbeschleunigung (nur für Azure-VMs der M-Serie)
  • Lesen + Schreibbeschleunigung (nur für Azure-VMs der M-Serie)

Für Storage Premium v1 wird empfohlen, das Zwischenspeichern von Lesevorgängen für Datendateien in der SAP-Datenbank zu nutzen und Kein Zwischenspeichern für die Datenträger von Protokolldateien festzulegen.

Hinweis

Bei einigen der neuen M(b)v3-VM-Typen kann die Verwendung von im Cache zwischengespeichertem SSD Premium v1-Speicher zu niedrigeren IOPS-Raten bei Lese- und Schreibvorgängen und einem geringeren Durchsatz als ohne Lesecache führen.

Für Bereitstellungen der M-Serie wird empfohlen, die Azure-Schreibbeschleunigung nur für die Datenträger Ihrer Protokolldateien zu verwenden. Weitere Informationen, Einschränkungen und Bereitstellungsdetails für die Azure-Schreibbeschleunigung finden Sie im Dokument Schreibbeschleunigung.

Für Storage Premium v2, Disk Ultra und Azure NetApp Files werden keine Optionen für die Zwischenspeicherung angeboten.

Nicht beständige Azure-Datenträger

Azure-VMs bieten Datenträger mit flüchtigem Speicher, nachdem eine VM bereitgestellt wurde. Wenn eine VM neu gestartet wird, werden alle Inhalte auf diesen Laufwerken gelöscht. Daher sollten Datendateien und Protokoll- bzw. Wiederholungsdateien von Datenbanken unter keinen Umständen auf diesen nicht permanenten Laufwerken gespeichert werden. Möglicherweise gibt es Ausnahmen für einige Datenbanken, in denen diese nicht permanenten Laufwerke für die Tabellenbereiche „tempdb“ und „temp“ geeignet sind.

Weitere Informationen finden Sie unter Understand the temporary drive on Windows VMs in Azure (Grundlegendes zum temporären Laufwerk auf Windows-VMs in Azure).

Nicht permanenter Windows-Datenträger Windows

Laufwerk D auf einer Azure-VM ist ein nicht permanentes Laufwerk, das durch einige lokale Datenträger im Azure-Serverknoten gesichert wird. Da es nicht permanent ist, gehen alle auf Laufwerk D vorgenommenen Änderungen am Inhalt verloren, wenn die VM neu gestartet wird. Änderungen umfassen gespeicherte Dateien, erstellte Verzeichnisse und installierte Anwendungen.

Nicht permanenter Linux-Datenträger Linux

Azure-VMs unter Linux stellen ein Laufwerk automatisch unter „/mnt/resource“ bereit. Dies ist ein nicht permanentes Laufwerk, das durch lokale Datenträger auf dem Azure-Serverknoten gesichert wird. Da es nicht permanent ist, gehen alle Änderungen am Inhalt unter „/mnt/resource“ verloren, wenn die VM neu gestartet wird. Änderungen umfassen gespeicherte Dateien, erstellte Verzeichnisse und installierte Anwendungen.

Microsoft Azure Storage – Resilienz

Microsoft Azure Storage speichert die Basis-VM (mit Betriebssystem) und angefügte Datenträger oder Blobs in mindestens drei getrennten Speicherknoten. Diese Art von Speicher wird als „lokal redundanter Speicher“ (LRS) bezeichnet. LRS ist die Standardeinstellung für alle Azure-Speichertypen.

Es gibt andere Redundanzmethoden. Weitere Informationen finden Sie unter Azure Storage-Replikation.

Hinweis

Azure Storage Premium v1 und v2, Disk Ultra und Azure NetApp Files sind die empfohlenen Speichertypen für DBMS-VMs und Datenträger, auf denen Datenbank-, Protokoll- und Wiederholungsdateien gespeichert werden. Mit Ausnahme von Storage Premium v1 ist LRS die einzige verfügbare Redundanzmethode für diese Speichertypen. Daher müssen Sie Datenbankmethoden konfigurieren, um die Replikation von Datenbankdaten in eine andere Azure-Region oder Verfügbarkeitszone zu ermöglichen. Datenbankmethoden sind beispielsweise SQL Server Always On, Oracle Data Guard und HANA-Systemreplikation.

VM-Knoten – Resilienz

Azure bietet verschiedene SLAs für VMs. Weitere Informationen finden Sie im letzten Release der SLA für Virtual Machines. Da die DBMS-Schicht von entscheidender Bedeutung für die Verfügbarkeit in einem SAP-System ist, müssen Sie mit verschiedenen Bereitstellungstypen und Wartungsereignissen vertraut sein. Weitere Informationen zu diesen Konzepten finden Sie unter Verwalten der Verfügbarkeit von virtuellen Computern in Azure.

Mindestempfehlung für DBMS-Produktionsszenarien mit einer SAP-Workload:

  • Stellen Sie zwei virtuelle Computer mithilfe des ausgewählten Bereitstellungstyps in derselben Azure-Region bereit.
  • Führen Sie diese beiden VMs im gleichen virtuellen Azure-Netzwerk aus, und fügen Sie NICs aus den gleichen Subnetzen an.
  • Verwenden Sie Datenbankmethoden, um einen unmittelbar betriebsbereiten Standbyserver mit der zweiten VM beizubehalten. Mögliche Methoden sind SQL Server Always On, Oracle Data Guard oder HANA-Systemreplikation.

Sie können auch eine dritte VM in einer anderen Azure-Region bereitstellen und die gleichen Datenbankmethoden verwenden, um ein asynchrones Replikat in einer anderen Azure-Region anzugeben.

Überlegungen zum Azure-Netzwerk

Verwenden Sie in großen SAP-Bereitstellungen die Blaupause des virtuellen Azure-Rechenzentrums. Verwenden Sie sie für die Konfiguration des virtuellen Netzwerks sowie für Berechtigungen und Rollenzuweisungen zu verschiedenen Teilen Ihrer Organisation.

Diese bewährten Methoden sind das Ergebnis von Tausenden von Kundenbereitstellungen:

  • Die virtuellen Netzwerke, in denen die SAP-Anwendung bereitgestellt wird, haben keinen Zugriff auf das Internet.
  • Die Datenbank-VMs werden im selben Netzwerk ausgeführt wie die Anwendungsschicht, befinden sich aber in einem anderen Subnetz als die SAP-Anwendungsschicht.
  • Die VMs im virtuellen Netzwerk haben eine statische Zuteilung der privaten IP-Adresse. Weitere Informationen finden Sie unter IP-Adresstypen und Zuordnungsmethoden in Azure.
  • Einschränkungen für das ein- und ausgehende Routing für DBMS-VMs werden nicht mit Firewalls festgelegt, die auf den lokalen DBMS-VMs installiert sind. Stattdessen wird Routing mit Netzwerksicherheitsgruppen (NSGs) definiert.
  • Weisen Sie der VM verschiedene NICs zu, um den Datenverkehr zu den DBMS-VMs zu trennen und zu isolieren. Jede NIC erhält eine andere IP-Adresse und ist einem anderen Subnetz des virtuellen Netzwerks zugeordnet. Für jedes Subnetz gelten verschiedene NSG-Regeln. Die Isolation oder die Trennung des Netzwerkverkehrs ist eine Routingmaßnahme. Sie wird nicht zum Festlegen von Kontingenten zur Steigerung des Netzwerkdurchsatzes verwendet.

Hinweis

Statische IP-Adressen über Azure zuzuweisen bedeutet, sie einzelnen virtuellen NICs zuzuweisen. Weisen Sie statische IP-Adressen nicht innerhalb des Gastbetriebssystems einer virtuellen NIC zu. Einige Azure-Dienste (beispielsweise Azure Backup) sind darauf angewiesen, dass mindestens die primäre virtuelle NIC im Gastbetriebssystem auf DHCP festgelegt ist und nicht auf statische IP-Adressen. Weitere Informationen finden Sie unter Problembehandlung bei der Sicherung virtueller Azure-Computer. Wenn Sie einem virtuellen Computer mehrere statische IP-Adressen zuweisen möchten, müssen Sie ihm mehrere virtuelle NICs zuweisen.

Warnung

Das Konfigurieren virtueller Netzwerkgeräte im Kommunikationspfad zwischen der SAP-Anwendung und der DBMS-Schicht eines SAP NetWeaver-, Hybris- oder S/4HANA-basierten SAP-Systems wird nicht unterstützt. Diese Einschränkung gilt aus Funktions- und Leistungsgründen. Der Kommunikationspfad zwischen der SAP-Anwendungsschicht und der DBMS-Schicht muss ein direkter Pfad sein. Die Einschränkung gilt nicht für Regeln für Anwendungssicherheitsgruppen (ASGs) und NSGs, wenn diese ASG- und NSG-Regeln einen direkten Kommunikationspfad zulassen. Dies schließt auch den Datenverkehr an NFS-Freigaben ein, die DBMS-Daten und Wiederholungsprotokolldateien hosten.

Weitere Szenarien, in denen virtuelle Netzwerkgeräte nicht unterstützt werden:

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 Kundenszenarien können virtuelle Netzwerkgeräte fehlerhafte Linux Pacemaker-Clustern zur Folge zu haben. In diesen Fällen erfolgt die Kommunikation zwischen den Linux Pacemaker-Clusterknoten und dem SBD-Gerät über ein virtuelles Netzwerkgerät.

Wichtig

Ein weiterer nicht unterstützter Entwurf ist die Aufteilung der SAP-Anwendungsschicht und der DBMS-Schicht auf verschiedene virtuelle Azure-Netzwerke, für die kein Peering konfiguriert ist. Es wird empfohlen, die SAP-Anwendungsschicht und die DBMS-Schicht durch Subnetze innerhalb eines virtuellen Azure-Netzwerks zu trennen, anstatt verschiedene virtuelle Azure-Netzwerke zu verwenden.

Wenn Sie sich dafür entscheiden, der Empfehlung nicht zu folgen und stattdessen die beiden Schichten auf verschiedene virtuelle Netzwerke aufzuteilen, muss für die beiden virtuellen Netzwerke ein Peering konfiguriert werden.

Beachten Sie, dass für den Netzwerkdatenverkehr zwischen zwei virtuellen Azure-Netzwerken mit Peering Übertragungskosten anfallen. Zwischen der SAP-Anwendungsschicht und der DBMS-Schicht werden riesige Datenmengen im Terabytebereich ausgetauscht. Somit können erhebliche Kosten entstehen, wenn die SAP-Anwendungsschicht und die DBMS-Schicht auf zwei mittels Peering verknüpfte virtuelle Azure-Netzwerke aufgeteilt sind.

Verwenden von Azure Load Balancer zum Umleiten von Datenverkehr

Die Verwendung von privaten virtuellen IP-Adressen, die in Funktionen wie SQL Server Always On oder HANA-Systemreplikation verwendet werden, erfordert die Konfiguration einer Azure Load Balancer-Instanz. Der Lastenausgleich verwendet Testports, um den aktiven DBMS-Knoten zu ermitteln und den Datenverkehr ausschließlich an diesen aktiven Datenbankknoten weiterzuleiten.

Bei einem Failover des Datenbankknotens muss die SAP-Anwendung nicht erneut konfiguriert werden. Stattdessen werden die gängigsten SAP-Anwendungsarchitekturen wieder mit der privaten virtuellen IP-Adresse verbunden. Inzwischen reagiert der Lastenausgleich auf das Failover des Knotens, indem er den Datenverkehr an die private virtuelle IP-Adresse auf dem zweiten Knoten umleitet.

Azure bietet zwei verschiedene Load Balancer-SKUs: Basic und Standard. Angesichts der Vorteile in Bezug auf Setup und Funktionalität empfiehlt sich die Verwendung der Standard-SKU von Azure Load Balancer. Einer der großen Vorteile der Standardversion des Lastenausgleichs besteht darin, dass Datenverkehr nicht durch die Lastenausgleichsinstanz selbst geleitet wird.

Ein Beispiel für die Konfiguration einer internen Load Balancer-Instanz finden Sie im Tutorial: Manuelles Konfigurieren einer SQL Server-Verfügbarkeitsgruppe in Azure Virtual Machines.

Hinweis

Die SKUs „Basic“ und „Standard“ verhalten sich in Bezug auf den Zugriff auf öffentliche IP-Adressen unterschiedlich. Im Dokument Konnektivität öffentlicher Endpunkte für VMs, die Azure Load Balancer Standard in SAP-Hochverfügbarkeitsszenarien verwenden wird beschrieben, wie die Einschränkungen der Standard-SKU beim Zugriff auf öffentliche IP-Adressen umgangen werden können.

Bereitstellen der Hostüberwachung

Für die Verwendung von SAP-Anwendungen auf Azure-VMs in der Produktion benötigt SAP die Möglichkeit, Hostüberwachungsdaten von den physischen Hosts abzurufen, auf denen die Azure-VMs ausgeführt werden. Es wird eine bestimmte SAP-Host-Agent-Patchebene benötigt, die diese Funktion in SAPOSCOL und SAP-Host-Agent ermöglicht. Die Patchebenen sind in SAP-Hinweis 1409604genau dokumentiert.

Weitere Informationen zur Bereitstellung von Komponenten, die Hostdaten für SAPOSCOL und den SAP-Host-Agent bereitstellen, sowie zur Verwaltung des Lebenszyklus dieser Komponenten finden Sie im Artikel Implementieren der Azure-VM-Erweiterung für SAP-Lösungen.

Nächste Schritte

Weitere Informationen zu einem bestimmten DBMS finden Sie unter: