Ausführen von SAP HANA für Linux-VMs in einer zentral hochskalierten Architektur in Azure

Azure
Virtual Machines
Virtuelle Linux-Computer

Anhand dieser Referenzarchitektur werden einige bewährte Methoden für die Ausführung von SAP HANA in einer Hochverfügbarkeits- und zentral hochskalierten Umgebung veranschaulicht, die die Notfallwiederherstellung in Azure unterstützt. Diese Implementierung fokussiert sich auf die Datenbankebene und ist so entworfen, dass sie verschiedene SAP-Anwendungen unterstützt, z. B. S/4HANA und SAP BW/4HANA.

Referenzarchitektur für SAP HANA-Hochskalierung

Hinweis

Zum Bereitstellen dieser Referenzarchitektur ist eine geeignete Lizenzierung von SAP-Produkten und anderen nicht von Microsoft stammenden Technologiekomponenten erforderlich.

Aufbau

Diese Referenzarchitektur beschreibt ein gängiges Produktionssystem. Sie können die Größen der VM so auswählen, dass sie den Anforderungen Ihrer Organisation entspricht. Diese Konfiguration kann auch bis hin zu einem einzigen virtuellen Computer reduziert werden.

Die Architektur besteht aus den folgenden Komponenten:

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

SAP HANA: SAP HANA wird auf mindestens zwei Linux-VMs ausgeführt, um Hochverfügbarkeit garantieren zu können. SAP HANA-Systemreplikation (HSR) wird verwendet, um Inhalte zwischen primären und sekundären HANA-Systemen (Replikat) zu replizieren. HSR wird auch für eine regions- oder zonenübergreifende Notfallwiederherstellung verwendet.

Verfügbarkeitszonen. Virtuelle Computer, die denselben Dienst bereitstellen, werden in zwei verschiedenen Verfügbarkeitszonen in einer Azure-Region bereitgestellt, um eine höhere Vereinbarung zum Service Level (SLA) zu bieten. Zwei oder mehr virtuelle Computer, die denselben Dienst bereitstellen, können auch in einer hochverfügbaren Verfügbarkeitsgruppe gruppiert werden.

Lastenausgleichsmodule: Zum Weiterleiten von Datenverkehr zu VMs in der Datenbankebene wird der Dienst Azure Load Balancer Standard verwendet. Diese Option unterstützt Verfügbarkeitszonen für Szenarios, in denen eine höhere Anwendungsverfügbarkeit erforderlich ist. Es ist wichtig, hervorzuheben, dass der Load Balancer Standard standardmäßig sicher ist, und dass keine virtuellen Computer hinter dem Load Balancer Standard über ausgehende Internetkonnektivität verfügen. Um ausgehende Internetkonnektivität auf den virtuellen Computern zu aktivieren, müssen Sie Ihre Load Balancer Standard-Konfiguration berücksichtigen.

Netzwerksicherheitsgruppen: Sie können Netzwerksicherheitsgruppen (NSGs) für Subnetze oder einzelne VMs erstellen, um eingehenden, ausgehenden und subnetzinternen Datenverkehr im virtuellen Netzwerk einzuschränken.

Speicher: Verwaltete Premium-Datenträger von Azure stellen den für die ausführbaren SAP-Dateien und die SAP HANA-Daten und -Protokolle empfohlenen Speicher bereit. Weitere Speicherkonfigurationen sind ebenfalls verfügbar, z. B. Ultra Disks und Azure NetApp Files.

Empfehlungen

Diese Architektur beschreibt eine kleine Bereitstellung auf Produktionsebene, die in Anzahl und Größe der VMs zentral entsprechend der Anforderungen Ihres Unternehmens hochskaliert werden kann. Verwenden Sie diese Empfehlungen als Startpunkt.

SAP HANA

In dieser Referenzarchitektur wird SAP HANA auf VMs bereitgestellt. Azure bietet eine Hochskalierung auf einem einzelnen Knoten bis 11,5 Terabyte (TB) für VMs und eine Hochskalierung bis 24 TB auf einem einzelnen Knoten für Azure (große Instanzen). Im Verzeichnis mit von SAP HANA zertifizierter und unterstützter Hardware finden Sie eine Liste mit den zertifizierten VMs für die SAP HANA-Datenbank. Ausführliche Informationen zur SAP-Unterstützung für VM-Typen und die Durchsatzmetriken (SAPS) finden Sie im SAP-Hinweis 1928533. Ein Marketplace-Konto für den SAP-Dienst ist erforderlich, um auf diesen und andere SAP-Hinweise zugreifen zu können.

Microsoft und SAP zertifizieren gemeinsam verschiedene VM-Größen für SAP HANA-Workloads. Kleinere Bereitstellungen können beispielsweise auf einer VM der M-Serie mit 192 GB RAM ausgeführt werden. Wenn die größte SAP HANA-Arbeitsspeichergröße auf VMs unterstützt werden soll, nämlich bis zu 11,5 TB, können Sie die Mv2-VMs der M-Serie von Azure, Version 2 verwenden. Die VM-Typen M208 erreichen etwa 260.000 SAPS, und die VM-Typen M416 erreichen etwa 488.000 SAPS.

Der physische Abstand zwischen der Anwendung und den Datenbankebenen kann die Leistung beeinträchtigen, insbesondere bei SAP-Anwendungen, die ein häufiges Kommunizieren mit der Datenbank erfordern. Es wird empfohlen, Näherungsplatzierungsgruppen von Azure für in Verfügbarkeitsgruppen bereitgestellten VMs zu verwenden. Näherungsplatzierungsgruppen sorgen dafür, dass sich VMs im selben Rechenzentrum befinden, um Anwendungslatenz zu minimieren. Beachten Sie jedoch, dass Azure Site Recovery die Replikation von VMs in Näherungsplatzierungsgruppen nicht unterstützt. Skripts und Hilfsprogramme sind auf GitHub verfügbar.

Load Balancer

Es wird empfohlen, Load Balancer Standard zu verwenden und Hochverfügbarkeitsports zu aktivieren. Diese Einrichtung eliminiert die Anforderung, dass Lastenausgleichsregeln für viele SAP-Ports konfiguriert werden müssen. Mit Load Balancer Standard können Sie auch eine Hochverfügbarkeitslösung für Azure-Verfügbarkeitszonen erstellen. Es ist wichtig, hervorzuheben, dass der Load Balancer Standard standardmäßig sicher ist, und dass keine virtuellen Computer hinter dem Load Balancer Standard über ausgehende Internetkonnektivität verfügen. Um ausgehende Internetkonnektivität auf den virtuellen Computern zu aktivieren, müssen Sie Ihre Load Balancer Standard-Konfiguration berücksichtigen. Alternativ können Sie auch Azure Load Balancer Basic verwenden. Dieser Dienst steht Ihnen kostenfrei zur Verfügung, unterstützt jedoch keine Zonen und hat kein SLA.

Sie müssen Direct Server Return (DSR) für SAP HANA-Datenbankcluster aktivieren. Diese Konfiguration ist auch als Floating IP bekannt. Dieses Feature ermöglicht es dem Server, auf die IP-Adresse des Front-Ends des Lastenausgleichsmoduls zu antworten. Diese direkte Verbindung verhindert, dass der Lastenausgleich zum Engpass auf dem Datenübertragungspfad wird. Wenn für VMs im Back-End-Pool die öffentliche Konnektivität in ausgehender Richtung erforderlich ist, müssen zusätzliche Konfigurationsschritte ausgeführt werden.

Netzwerk

Es wird empfohlen, für diese Architektur eine Hub-Spoke-Topologie zu nutzen, bei der das Hub-VNET als zentraler Verbindungspunkt für ein lokales Netzwerk dient. Die „Speichen“ (Spokes) sind VNETs, die eine Peeringverbindung mit dem Hub herstellen und zur Isolation von Workloads verwendet werden können. Der Datenverkehr wird über eine Gatewayverbindung zwischen dem lokalen Rechenzentrum und dem Hub weitergeleitet.

Verfügbarkeitszonen

Wie bereits erwähnt können Sie die Anwendungsverfügbarkeit erhöhen, indem Sie Verfügbarkeitszonen nutzen.

Subnetze und Netzwerksicherheitsgruppen

Das Datenbanksubnetz beinhaltet eine Netzwerksicherheitsgruppe (NSG), die Zugriffsrichtlinien für alle VMs innerhalb dieses Subnetzes definiert. Richten Sie NSGs entweder mithilfe des Azure-Portals, mit PowerShell oder der Azure CLI ein, um den Datenverkehrsfluss zwischen den Servern eines Subnetzes zu steuern. Für weitere Steuerungsmöglichkeiten können Sie das SAP HANA-Subnetz auch mit Anwendungssicherheitsgruppen verknüpfen.

Überlegungen zur Leistung

Diese Implementierung verwendet verwaltete Azure-Datenträger. Zur Erreichung eines hohen Durchsatzes in Bezug auf Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) und die Datenträgerbandbreite gelten für das Azure-Speicherlayout ebenfalls die gängigen Vorgehensweisen zur Leistungsoptimierung für Speichervolumes. Wenn beispielsweise mehrere Datenträger miteinander kombiniert werden, um ein Stripset-Datenträgervolume zu erstellen, verbessert dies die E/A-Leistung, obwohl Sie möglicherweise entsprechende Änderungen an der Datenträgerkonfiguration vornehmen müssen, wenn Sie die Größe der VMs später anpassen.

Eine Aktivierung des Lesecaches für Speicherinhalte, die sich in unregelmäßigen Abständen ändern, bewirkt eine höhere Geschwindigkeit beim Datenabruf. Sehen Sie sich auch die Empfehlungen zu Speicherkonfigurationen für unterschiedliche VM-Größen bei der Ausführung von SAP HANA an.

Disk Storage Ultra bietet die beste E/A-Leistung, um die hohen IOPS- und Übertragungsbandbreitenanforderungen von SAP HANA zu erfüllen. Sie können die Leistung von Ultra-Datenträgern dynamisch ändern und Metriken wie IOPS und MB/s separat konfigurieren, ohne Ihren virtuellen Computer neu zu starten. Die Funktionen von Ultra-Datenträgern werden kontinuierlich weiterentwickelt. Wenn Sie wissen möchten, ob diese Datenträger Ihre Anforderungen erfüllen können, sehen Sie sich die aktuellen Informationen zur Dienstabdeckung von Ultra Disks an, insbesondere, wenn Ihre Implementierung Resilienzfeatures von Azure beinhaltet, z. B. Verfügbarkeitsgruppen, Verfügbarkeitszonen und zonenübergreifende Replikation.

Ausführliche Informationen zu den Leistungsanforderungen von SAP HANA finden Sie unter dem SAP-Hinweis 1943937 zum Tool für die Überprüfung der Hardwarekonfiguration.

Hinweis

Wie im SAP-Hinweis 2731110 erläutert wird, sollten Sie virtuelle Netzwerkgeräte (Network Virtual Appliances, NVAs) für SAP-Anwendungsstapel nicht zwischen der Anwendung und den Datenbankschichten anordnen. Diese Vorgehensweise würde zu einer hohen Verarbeitungsdauer für Datenpakete und somit zu einer inakzeptabel langsamen Anwendungsleistung führen.

Überlegungen zur Skalierbarkeit

Diese Architektur führt SAP HANA auf VMs aus, die auf bis zu 11,5 TB auf einer Instanz hochskaliert werden können.

Wenn Ihre Workload die maximale VM-Größe überschreitet, bietet Microsoft Azure (große Instanzen) für SAP HANA an. Bei Revision 4 sind diese physischen Server zusammen in einem Azure-Rechenzentrum angeordnet und ermöglichen zum Zeitpunkt der Erstellung dieses Dokuments bis zu 24 TB Speicherkapazität für eine einzelne Instanz.

Es ist auch eine Konfiguration mit mehreren Knoten möglich. Sie verfügt über eine Gesamtspeicherkapazität von bis zu 48 TB für OLTP-Anwendungen (Onlinetransaktionsverarbeitung) und 96 TB für OLAP-Anwendungen (Analytische Onlineverarbeitung). Sie können beispielsweise SAP HANA in einer Konfiguration mit horizontaler Skalierung mit Standby auf VMs mithilfe von Azure NetApp Files für die freigegebenen Speichervolumes bereitstellen. Auf diesen VMs wird entweder Red Hat Enterprise Linux oder SUSE Linux Enterprise Server ausgeführt.

Überlegungen zur Verfügbarkeit

Diese Referenzarchitektur beschreibt ein hochverfügbares SAP HANA-Datenbanksystem, das aus zwei VMs besteht. Das native SAP HANA-Systemreplikationsfeature der Datenbankschicht bietet entweder manuelles oder automatisches Failover zwischen replizierten Knoten:

  • Für ein manuelles Failover stellen Sie mindestens eine SAP HANA-Instanz bereit und verwenden SAP HSR.

  • Verwenden Sie für automatisches Failover sowohl HSR als auch Linux HAE (High Availability Extension. Hochverfügbarkeitserweiterung) für Ihre Linux-Distribution. Linux HAE stellt die Pacemaker-Clusterdienste für die SAP HANA-Ressourcen bereit, die Fehlerereignisse erkennen und das Failover von fehlerhaften Diensten auf den fehlerfreien Knoten organisieren.

Für eine SAP HANA-Hochverfügbarkeit unter Linux erstellen Sie ein Pacemaker-Cluster. Diese Option ist sowohl für SUSE Linux Enterprise Server als auch für Red Hat Enterprise Linux verfügbar.

Diese Architektur verwendet Linux-Clustering, um Systemfehler zu erkennen und automatisches Failover zu ermöglichen. Ein speicherbasierter oder cloudbasierter Umgrenzungsmechanismus kann verwendet werden, um sicherzustellen, dass das ausgefallene System isoliert oder heruntergefahren wird, um den Cluster-Split-Brain-Zustand zu vermeiden.

Überlegungen zur Notfallwiederherstellung

Bei dieser Architektur wird HSR für die Datenbankreplikation in eine Datenbankinstanz in der sekundären Region verwendet. Es ist optional, ein Cluster in der sekundären Region zu verwenden. Wird dies jedoch getan, kann dies die SAP HANA-Verfügbarkeit nach einem Notfallwiederherstellungsfailover verbessern.

Zusätzlich zu einer lokalen Hochverfügbarkeitsimplementierung auf zwei Knoten unterstützt HSR die Replikation für mehrere Ebenen und mehrere Ziele. Dies ermöglicht die zonen- und regionsübergreifende Replikation. Replikation mit mehreren Zielen ist ab SAP HANA 2.0 SPS 03 verfügbar.

Ein Notfallwiederherstellungsfailover ist ein manueller Prozess.

Peering in virtuellen Netzwerken

Zur Unterstützung der Notfallwiederherstellung in dieser Architektur leiten virtuelle Netzwerke in der sekundären Region ihren Datenverkehr über ExpressRoute an das lokale Gateway weiter und leiten ihn dann zurück an Azure. Das Ziel dabei sind Dienste in der primären Region.

Sie können auch auf das Peering virtueller Netzwerke zurückgreifen. Dabei werden mehrere virtuelle Netzwerke per Peering miteinander verbunden, um eine Netzwerksegmentierung und eine Isolierung für die Dienste zu gewährleisten, die in Azure bereitgestellt sind. Über Netzwerkpeering können Dienste in unterschiedlichen Netzwerken innerhalb einer Region eine Verbindung zueinander herstellen. Globales Netzwerkpeering verbindet virtuelle Netzwerke in Remoteregionen per Bridges miteinander.

Azure NetApp Files

Azure NetApp Files kann als Option verwendet werden, um eine skalierbare und hochleistungsfähige Speicherlösung für SAP HANA-Daten und -Protokolldateien bereitzustellen. Es ist außerdem auch eine gute Lösung für freigegebenen Linux-Clusterspeicher, z. B. für das Erstellen von Pacemaker-Clustern für (A)SCS. Azure NetApp Files erleichtert die Bereitstellung von Dateifreigaben für Linux-Workloads, ohne dass dafür ein NFS-Dateiserver bereitgestellt werden muss. Außerdem wird so die SAP-Landschaft vereinfacht.

Azure NetApp Files unterstützt Momentaufnahmen für schnelle Sicherungen, Wiederherstellungen und die lokale Replikation. Für eine regionsübergreifende Inhaltsreplikation können Sie den Cloud Sync-Dienst von NetApp, rsync oder eine andere Kopierfunktion verwenden.

Azure Site Recovery

Sie können Azure Site Recovery verwenden, um Ihre Produktionskonfiguration an einem sekundären Speicherort automatisch zu replizieren. Außerdem können Sie angepasste Bereitstellungsskripts verwenden, um die Wiederherstellungspläne auszuweiten. Ein Beispiel für das benutzerdefinierte Skript für Site Recovery-Automatisierungs-Runbooks finden Sie auf GitHub.

Hinweis

Zum Zeitpunkt der Erstellung dieses Artikels unterstützt Site Recovery die Replikation von VMs in Näherungsplatzierungsgruppen nicht. Überprüfen Sie die Ressourcenkapazität Ihrer Zielregion. Wie bei allen Azure-Diensten werden auch für Site Recovery ständig Features und Funktionen hinzugefügt. Aktuelle Informationen zur Replikation von Azure zu Azure finden Sie in der Supportmatrix.

Aspekte der Verwaltung und des Betriebs

Backup

SAP HANA kann auf viele verschiedene Arten gesichert werden. Nach der Migration zu Azure können Sie weiterhin alle vorhandenen Sicherungslösungen von Partnern nutzen, die Sie bereits verwenden. In Azure stehen zwei native Ansätze für Sicherungen zur Verfügung: SAP HANA-Sicherungen auf Dateiebene und Azure Backup für SAP HANA über die Backint-Schnittstelle.

Bei der SAP HANA-Sicherung auf Dateiebene können Sie ein Tool Ihrer Wahl verwenden, z. B. hdbsql oder SAP HANA Studio, und die Sicherungsdateien auf einem lokalen Datenträgervolume speichern. Ein gängiger Bereitstellungspunkt für dieses Sicherungsvolume ist /hana/backup. Ihre Sicherungsrichtlinien definieren den Aufbewahrungszeitraum für die Daten auf diesem Volume. Sobald die Sicherung erstellt wurde, sollte eine geplante Aufgabe die Sicherungsdateien zur Aufbewahrung in Azure-Blobspeicher kopieren. Die lokalen Sicherungsdateien werden für Wiederherstellungszwecke beibehalten.

Azure Backup bietet eine einfache Lösung für Unternehmen an, die für Workloads eingesetzt werden kann, die auf VMs ausgeführt werden. Azure Backup für SAP HANA stellt eine vollständige Integration mit dem SAP HANA-Sicherungskatalog zur Verfügung und sorgt für Wiederherstellungen, bei denen die Datenbank konsistent bleibt und die entweder vollständig oder für einen bestimmten Zeitpunkt ausgeführt werden können. Azure Backup verfügt über eine BackInt-Zertifizierung von SAP. Informationen hierzu finden Sie auch unter Azure Backup – Häufig gestellte Fragen.

Überwachung

Azure Monitor bietet eine umfassende Lösung für das Sammeln, Analysieren und Behandeln von Telemetriedaten aus Ihren Cloud- und lokalen Umgebungen für das Überwachen Ihrer Workloads in Azure.

Zum Bereitstellen einer SAP-basierten Überwachung der unterstützten Azure-Infrastruktur und -Datenbanken werden Azure Monitor für SAP-Lösungen (Vorschauversion) verwendet. Azure Monitor für SAP-Lösungen bieten eine einfache Einrichtungserfahrung. Der Kunde kann Telemetriedaten von Azure-Ressourcen erfassen und dann Daten mit verschiedenen KPIs der Überwachung korrelieren sowie Daten für die Problembehandlung verwenden.

Die Azure-Erweiterung zur verbesserten Überwachung für SAP wird verwendet, um SAP-basierte Überwachung von Ressourcen sowie der Leistung von Diensten der SAP-Infrastruktur bereitzustellen. Mit dieser Erweiterung werden statistische Daten zur Azure-Überwachung in die SAP-Anwendung eingespeist, damit die Betriebssystemüberwachung und DBA Cockpit-Funktionen ermöglicht werden. Die erweiterte Überwachung von SAP ist eine obligatorische Voraussetzung für die Ausführung von SAP in Azure. Ausführliche Informationen hierzu finden Sie im SAP-Hinweis 2191498: „SAP unter Linux mit Azure: Erweiterte Überwachung“. Zum Überwachen der SAP-Anwendung und zugehöriger Infrastrukturen können Azure Monitor für SAP-Lösungen (Vorschauversion) verwendet werden. Azure Monitor für SAP-Lösungen bieten eine einfache Einrichtungserfahrung. Der Kunde kann Telemetriedaten von Azure-Ressourcen erfassen und dann Daten mit verschiedenen KPIs der Überwachung korrelieren sowie Daten für die Problembehandlung verwenden.

Sicherheitshinweise

Viele Sicherheitsmaßnahmen werden verwendet, um die Vertraulichkeit, Integrität und Verfügbarkeit einer SAP-Landschaft zu schützen. SAP verfügt zur Sicherung des Benutzerzugriffs beispielsweise über ein eigenes Modul für die Benutzerverwaltung (Users Management Engine, UME), um den rollenbasierten Zugriff und die Autorisierung in der SAP-Anwendung und den Datenbanken zu steuern. Ausführliche Informationen finden Sie unter SAP HANA-Sicherheit – Eine Übersicht.

Für ruhende Daten kann Sicherheit über Verschlüsselung wie folgt sichergestellt werden:

  • Ziehen Sie in Betracht, zusammen mit der nativen SAP HANA-Verschlüsselungstechnologie auch eine Verschlüsselungslösung von einem Partner zu verwenden, der von Kunden verwaltete Schlüssel unterstützt.

  • Sie können Azure Disk Encryption verwenden, um VM-Datenträger zu verschlüsseln. Die Lösung funktioniert auch für Azure Key Vault, damit Sie die Verschlüsselungsschlüssel und Geheimnisse für die Datenträgerverschlüsselung in Ihrem Key Vault-Abonnement steuern und verwalten können. Der von uns empfohlene Ansatz für die Verschlüsselung Ihrer ruhenden SAP-Daten lautet wie folgt:

    • Azure Disk Encryption für SAP-Anwendungsserver: Betriebssystem-Datenträger und Datenträger.
    • Azure Disk Encryption für SAP-Datenbankserver: Betriebssystem-Datenträger und Datenträger, die nicht vom DBMS verwendet werden.
    • SAP-Datenbankserver: Verwenden Sie Transparent Data Encryption, die vom DBMS-Anbieter angeboten wird (z. B. native SAP HANA-Verschlüsselungstechnologie), um Ihre Daten- und Protokolldateien zu sichern und sicherzustellen, dass die Sicherungen ebenfalls verschlüsselt werden.
  • Ruhende Daten in physischem Speicher in Azure werden automatisch mithilfe eines von Azure verwalteten Schlüssels verschlüsselt.

Hinweis

Vermeiden Sie es, die SAP HANA-Verschlüsselung von ruhenden Daten mit Azure Disk Encryption auf demselben Speichervolume zu verwenden. Betriebssystembootdatenträger für virtuelle Linux-Computer weisen keine Unterstützung für Azure Disk Encryption auf, und Azure Site Recovery unterstützt auch noch keine an Azure Disk Encryption angefügten Datenträger unter Linux.

Verwenden Sie für die Netzwerksicherheit Netzwerksicherheitsgruppen (NSGs) und Azure Firewall oder ein virtuelles Netzwerkgerät wie folgt:

  • Verwenden Sie NSGs, um den Datenverkehr zwischen Subnetzen und Anwendungs-/Datenbankschichten zu schützen und zu steuern.

  • Verwenden Sie Azure Firewall oder ein virtuelles Azure-Netzwerkgerät, um das Routing des Datenverkehrs vom virtuellen Hubnetzwerk an das virtuelle Spoke-Netzwerk, in dem sich Ihre SAP-Anwendungen befinden, zu untersuchen und zu kontrollieren sowie um außerdem Ihre ausgehende Internetkonnektivität zu kontrollieren.

Implementieren Sie für Benutzer und Autorisierung wie folgt die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) und Ressourcensperren:

  • Befolgen Sie das Prinzip der geringsten Rechte, indem Sie RBAC verwenden, um Ressourcen auf IaaS-Ebene, die Ihre SAP-Lösung in Azure hosten, Administratorrechte zuzuweisen. Grundsätzlich besteht der Hauptzweck von RBAC in der Trennung und Kontrolle der Verpflichtungen für Ihre Benutzer/Gruppe und in der Gewährung von Zugriff auf Ressourcen in nur dem Umfang, den Benutzer für die Ausführung ihrer Aufgaben benötigen.

  • Verwenden Sie Ressourcensperren, um Risiken zu vermeiden, die eventuell versehentlich oder mit böswilliger Absicht verursacht werden könnten, wobei ein Administrator kritische Azure-Ressourcen, in denen sich Ihre SAP-Lösung befindet, löschen oder ändern kann.

Weitere Sicherheitsempfehlungen finden Sie in diesen Artikeln von Microsoft und SAP.

Communitys

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