Hochverfügbarkeit der SAP HANA-Hochskalierung mit Azure NetApp Files unter Red Hat Enterprise Linux (RHEL)
In diesem Artikel erfahren Sie, wie Sie die SAP HANA-Systemreplikation in einer Bereitstellung mit Hochskalierung mithilfe von Azure NetApp Files konfigurieren, wenn die HANA-Dateisysteme über NFS eingebunden sind. In den Beispielkonfigurationen und Installationsbefehlen werden die Instanznummer 03 und die HANA-System-ID HN1 verwendet. Die SAP HANA-Systemreplikation umfasst einen primären Knoten und mindestens einen sekundären Knoten.
Einige Schritte in diesem Dokument sind mit Präfixen gekennzeichnet. Diese bedeuten Folgendes:
- [A] : Der Schritt gilt für alle Knoten.
- [1] : Der Schritt gilt nur für Knoten 1.
- [2] : Der Schritt gilt nur für Knoten 2.
Voraussetzungen
Lesen Sie zuerst die folgenden SAP-Hinweise und -Dokumente:
- SAP-Hinweis 1928533 mit folgenden Informationen:
- Liste der Azure-VM-Größen, die für die Bereitstellung von SAP-Software unterstützt werden.
- Wichtige Kapazitätsinformationen für Azure-VM-Größen
- Unterstützte Kombinationen von SAP-Software, Betriebssystem und Datenbank.
- Erforderliche SAP-Kernelversion für Windows und Linux in Microsoft Azure
- In SAP-Hinweis 2015553 sind die Voraussetzungen für Bereitstellungen von SAP-Software in Azure aufgeführt, die von SAP unterstützt werden.
- Im SAP-Hinweis 405827 sind empfohlene Dateisysteme für HANA-Umgebungen aufgeführt.
- SAP-Hinweis 2002167 enthält empfohlene Betriebssystemeinstellungen für Red Hat Enterprise Linux.
- SAP-Hinweis 2009879 enthält SAP HANA-Richtlinien für Red Hat Enterprise Linux.
- Der SAP-Hinweis 3108302 enthält SAP HANA-Leitfäden für Red Hat Enterprise Linux 9.x.
- SAP-Hinweis 2178632 enthält ausführliche Informationen zu allen Überwachungsmetriken, die für SAP in Azure gemeldet werden.
- SAP-Hinweis 2191498 enthält die erforderliche SAP Host Agent-Version für Linux in Azure.
- SAP-Hinweis 2243692 enthält Informationen zur SAP-Lizenzierung unter Linux in Azure.
- SAP-Hinweis 1999351 enthält Informationen zur Problembehandlung für die Azure Enhanced Monitoring-Erweiterung für SAP.
- Das SAP-Community-Wiki enthält alle erforderlichen SAP-Hinweise für Linux.
- Azure Virtual Machines – Planung und Implementierung für SAP unter Linux
- Bereitstellung von Azure Virtual Machines für SAP unter Linux
- Azure Virtual Machines – DBMS-Bereitstellung für SAP unter Linux
- SAP HANA-Systemreplikation im Pacemaker-Cluster
- Allgemeine Dokumentation zu Red Hat Enterprise Linux (RHEL):
- Azure-spezifische RHEL-Dokumentation:
- Unterstützungsrichtlinien für RHEL-Hochverfügbarkeitscluster – Virtuelle Microsoft Azure-Computer als Clustermitglieder
- Installieren und Konfigurieren eines Red Hat Enterprise Linux 7.4-Hochverfügbarkeitclusters (und höher) in Microsoft Azure
- Konfigurieren der SAP HANA-Systemreplikation mit Hochskalierung in einem Pacemaker-Cluster, wenn sich die HANA-Dateisysteme auf NFS-Freigaben befinden
- NFS v4.1-Volumes unter Azure NetApp Files für SAP HANA
Übersicht
In einer Hochskalierungsumgebung werden üblicherweise alle Dateisysteme für SAP HANA aus dem lokalen Speicher eingebunden. Informationen zum Einrichten der Hochverfügbarkeit (High Availability, HA) der SAP HANA-Systemreplikation unter Red Hat Enterprise Linux finden Sie unter Einrichten der SAP HANA-Systemreplikation unter RHEL.
Um SAP HANA-Hochverfügbarkeit eines Systems mit Hochskalierung auf Azure NetApp Files-NFS-Freigaben zu erreichen, sind einige weitere Ressourcenkonfigurationen im Cluster erforderlich, damit HANA-Ressourcen wiederhergestellt werden können, wenn der Zugriff eines Knotens auf die NFS-Freigaben in Azure NetApp Files unterbrochen wird. Der Cluster verwaltet die NFS-Bereitstellungen und kann daher die Integrität der Ressourcen überwachen. Zwischen den Dateisystembereitstellungen und den SAP HANA-Ressourcen werden Abhängigkeiten erzwungen.
.
SAP HANA-Dateisysteme werden mithilfe von Azure NetApp Files auf NFS-Freigaben auf den einzelnen Knoten eingebunden. Die Dateisysteme /hana/data
, /hana/log
und /hana/shared
sind für jeden Knoten eindeutig.
Eingebunden auf „node1“ (hanadb1):
- 10.32.2.4:/hanadb1-data-mnt00001 in /hana/data
- 10.32.2.4:/hanadb1-log-mnt00001 in /hana/log
- 10.32.2.4:/hanadb1-shared-mnt00001 in /hana/shared
Eingebunden auf „node2“ (hanadb2):
- 10.32.2.4:/hanadb2-data-mnt00001 in /hana/data
- 10.32.2.4:/hanadb2-log-mnt00001 in /hana/log
- 10.32.2.4:/hanadb2-shared-mnt00001 in /hana/shared
Hinweis
Die Dateisysteme /hana/shared
, /hana/data
und /hana/log
werden nicht zwischen den beiden Knoten geteilt. Jeder Clusterknoten besitzt eigene, separate Dateisysteme.
Die Konfiguration der SAP HANA-Systemreplikation verwendet einen dedizierten virtuellen Hostnamen und virtuelle IP-Adressen. Für die Verwendung einer virtuellen IP-Adresse ist in Azure ein Lastenausgleich erforderlich. Die hier dargestellte Konfiguration umfasst einen Lastenausgleich mit:
- Front-End-IP-Adresse: 10.32.0.10 für hn1-db
- Testport: 62503
Einrichten der Infrastruktur für Azure NetApp Files
Bevor Sie mit der Einrichtung der Azure NetApp Files-Infrastruktur beginnen, sollten Sie sich mit der Azure NetApp Files-Dokumentation vertraut machen.
Azure NetApp Files ist in verschiedenen Azure-Regionen verfügbar. Überprüfen Sie, ob Azure NetApp Files in Ihrer ausgewählten Azure-Region angeboten wird.
Informationen zur Verfügbarkeit von Azure NetApp Files in den einzelnen Azure-Regionen finden Sie unter Verfügbarkeit von Azure NetApp Files nach Azure-Region.
Wichtige Hinweise
Beachten Sie beim Erstellen Ihrer Azure NetApp Files-Volumes für SAP HANA-Hochskalierungssysteme die wichtigen Überlegungen unter NFS v4.1-Volumes unter Azure NetApp Files für SAP HANA.
Dimensionierung einer HANA-Datenbank in Azure NetApp Files
Der Durchsatz eines Azure NetApp Files-Volumes ist eine Funktion der Volumegröße und der Dienstebene, wie in Dienstebenen für Azure NetApp Files beschrieben.
Beachten Sie beim Entwerfen der Infrastruktur für SAP HANA in Azure mit Azure NetApp Files die Empfehlungen unter NFS v4.1-Volumes unter Azure NetApp Files für SAP HANA.
Für die Konfiguration in diesem Artikel werden einfache Azure NetApp Files-Volumes verwendet.
Wichtig
Für Produktionssysteme, bei denen die Leistung entscheidend ist, empfiehlt es sich, die Hinweise zu Azure NetApp Files-Anwendungsvolumegruppen für SAP HANA zu prüfen und anzuwenden.
Bereitstellen von Azure NetApp Files-Ressourcen
In der folgenden Anleitung wird davon ausgegangen, dass Sie Ihr virtuelles Azure-Netzwerk bereits bereitgestellt haben. Die Azure NetApp Files-Ressourcen und die virtuellen Computer, auf denen die Azure NetApp Files-Ressourcen eingebunden werden, müssen im gleichen virtuellen Azure-Netzwerk oder in mittels Peering verknüpften virtuellen Azure-Netzwerken bereitgestellt werden.
Erstellen Sie entsprechend den Anweisungen in Erstellen eines NetApp-Kontos ein NetApp-Konto in der ausgewählten Azure-Region.
Richten Sie entsprechend den Anweisungen in Einrichten eines Kapazitätspools einen Azure NetApp Files-Kapazitätspool ein.
Die in diesem Artikel gezeigte HANA-Architektur verwendet einen einzigen Azure NetApp Files-Kapazitätspool auf der Dienstebene Ultra. Für HANA-Workloads in Azure empfehlen wir die Dienstebene Ultra oder Premium für Azure NetApp Files.
Delegieren Sie ein Subnetz an Azure NetApp Files, wie in den Anweisungen in Delegieren eines Subnetzes an Azure NetApp Files beschrieben.
Stellen Sie Azure NetApp Files-Volumes entsprechend den Anweisungen in Erstellen eines NFS-Volumes für Azure NetApp Files bereit.
Stellen Sie beim Bereitstellen der Volumes sicher, dass Sie die Version NFSv4.1 auswählen. Stellen Sie die Volumes im festgelegten Subnetz für Azure NetApp Files bereit. Die IP-Adressen der Azure NetApp-Volumes werden automatisch zugewiesen.
Denken Sie daran, dass sich die Azure NetApp Files-Ressourcen und die virtuellen Azure-Computer im gleichen virtuellen Azure-Netzwerk oder in mittels Peering verknüpften virtuellen Azure-Netzwerken befinden müssen. Beispielsweise sind
hanadb1-data-mnt00001
undhanadb1-log-mnt00001
die Volumenamen undnfs://10.32.2.4/hanadb1-data-mnt00001
undnfs://10.32.2.4/hanadb1-log-mnt00001
die Dateipfade für die Azure NetApp Files-Volumes.Auf hanadb1:
- Volume „hanadb1-data-mnt00001“ (nfs://10.32.2.4:/hanadb1-data-mnt00001)
- Volume „hanadb1-log-mnt00001“ (nfs://10.32.2.4:/hanadb1-log-mnt00001)
- Volume „hanadb1-shared-mnt00001“ (nfs://10.32.2.4:/hanadb1-shared-mnt00001)
Auf hanadb2:
- Volume „hanadb2-data-mnt00001“ (nfs://10.32.2.4:/hanadb2-data-mnt00001)
- Volume „hanadb2-log-mnt00001“ (nfs://10.32.2.4:/hanadb2-log-mnt00001)
- Volume „hanadb2-shared-mnt00001“ (nfs://10.32.2.4:/hanadb2-shared-mnt00001)
Hinweis
Alle Befehle zum Einbinden von /hana/shared
in diesem Artikel gelten für /hana/shared
-Volumes in NFSv4.1.
Falls Sie die /hana/shared
-Volumes als NFSv3-Volumes bereitgestellt haben, müssen Sie daran denken, die Einbindungsbefehle für /hana/shared
für NFSv3 anzupassen.
Vorbereiten der Infrastruktur
Im Azure Marketplace finden Sie Images, die für SAP HANA mit dem Add-On für Hochverfügbarkeit qualifiziert sind und Ihnen das Bereitstellen neuer VMs mithilfe verschiedener Versionen von Red Hat ermöglichen.
Manuelles Bereitstellen von Linux-VMs über das Azure-Portal
In diesem Dokument wird davon ausgegangen, dass Sie bereits eine Ressourcengruppe, ein virtuelles Azure-Netzwerk und ein Subnetz bereitgestellt haben.
Stellen Sie VMs für SAP HANA bereit. Wählen Sie ein geeignetes RHEL-Image aus, das für das HANA-System unterstützt wird. Sie können eine VM mit einer der folgenden Verfügbarkeitsoptionen bereitstellen: Skalierungsgruppe, Verfügbarkeitszone oder Verfügbarkeitsgruppe.
Wichtig
Vergewissern Sie sich, dass das von Ihnen gewählte Betriebssystem für SAP HANA auf den VM-Typen, die Sie verwenden möchten, SAP-zertifiziert ist. Sie können für SAP HANA zertifizierte VM-Typen und deren Betriebssystemversionen unter Für SAP HANA zertifizierte IaaS-Plattformen nachschlagen. Stellen Sie sicher, dass Sie sich die Details des jeweils aufgeführten VM-Typs ansehen, um die vollständige Liste der von SAP HANA unterstützten Betriebssystemversionen für den spezifischen VM-Typ zu erhalten.
Konfigurieren von Azure Load Balancer
Während der VM-Konfiguration können Sie im Abschnitt „Netzwerk“ einen Lastenausgleich erstellen oder einen vorhandenen Lastenausgleich auswählen. Führen Sie die folgenden Schritte aus, um den Standardlastenausgleich für das Hochverfügbarkeitssetup der HANA-Datenbank einzurichten.
Führen Sie die unter Erstellen eines Lastenausgleichs beschriebenen Schritte aus, um über das Azure-Portal einen Standardlastenausgleich für ein SAP-Hochverfügbarkeitssystem einzurichten. Berücksichtigen Sie beim Einrichten des Lastenausgleichs die folgenden Punkte:
- Front-End-IP-Konfiguration: Erstellen Sie eine IP-Adresse für das Front-End. Wählen Sie dasselbe virtuelle Netzwerk und Subnetz aus wie für Ihre Datenbank-VMs.
- Back-End-Pool: Erstellen Sie einen Back-End-Pool, und fügen Sie Datenbank-VMs hinzu.
- Regeln für eingehenden Datenverkehr: Erstellen Sie eine Lastenausgleichsregel. Führen Sie die gleichen Schritte für beide Lastenausgleichsregeln aus.
- Front-End-IP-Adresse: Wählen Sie eine Front-End-IP-Adresse aus.
- Back-End-Pool: Wählen Sie einen Back-End-Pool aus.
- Hochverfügbarkeitsports: Wählen Sie diese Option aus.
- Protokoll: Wählen Sie TCP.
- Integritätstest: Erstellen Sie einen Integritätstest mit folgenden Details:
- Protokoll: Wählen Sie TCP.
- Port: Beispielsweise 625<Instanznr.>
- Intervall: Geben Sie 5 ein.
- Testschwellenwert: Geben Sie 2 ein.
- Leerlauftimeout (Minuten): Geben Sie 30 ein.
- Floating IP aktivieren: Wählen Sie diese Option aus.
Hinweis
Die Konfigurationseigenschaft numberOfProbes
für Integritätstests (im Portal als Fehlerschwellenwert bezeichnet) wird nicht berücksichtigt. Legen Sie die probeThreshold
-Eigenschaft auf 2
fest, um die Anzahl erfolgreicher oder nicht erfolgreicher aufeinanderfolgender Integritätstests zu steuern. Diese Eigenschaft kann derzeit nicht über das Azure-Portal festgelegt werden. Verwenden Sie daher entweder die Azure-Befehlszeilenschnittstelle (Command Line Interface, CLI) oder den PowerShell-Befehl.
Weitere Informationen zu den erforderlichen Ports für SAP HANA finden Sie im Kapitel zu Verbindungen mit Mandantendatenbanken im Handbuch zu SAP HANA-Mandantendatenbanken oder im SAP-Hinweis 2388694.
Hinweis
Wenn VMs ohne öffentliche IP-Adressen im Back-End-Pool einer internen (keine öffentliche IP-Adresse) Azure Load Balancer Standard-Instanz platziert werden, gibt es keine ausgehende Internetkonnektivität, es sei denn, es werden weitere Konfigurationen vorgenommen, um das Routing zu öffentlichen Endpunkten zu ermöglichen. Weitere Informationen zum Erzielen ausgehender Konnektivität finden Sie unter Konnektivität öffentlicher Endpunkte für VMs, die Azure Load Balancer Standard in SAP-Hochverfügbarkeitsszenarien verwenden.
Wichtig
Aktivieren Sie keine TCP-Zeitstempel auf Azure-VMs, die sich hinter Azure Load Balancer befinden. Das Aktivieren von TCP-Zeitstempeln (Transmission Control-Protokoll) kann zu Fehlern bei Integritätstests führen. Legen Sie den Parameter net.ipv4.tcp_timestamps auf 0 fest. Weitere Informationen finden Sie unter Azure Load Balancer-Integritätstests sowie im SAP-Hinweis 2382421.
Einbinden des Azure NetApp Files-Volumes
[A] Erstellen Sie Bereitstellungspunkte für die HANA-Datenbankvolumes.
sudo mkdir -p /hana/data sudo mkdir -p /hana/log sudo mkdir -p /hana/shared
[A] Überprüfen Sie die Einstellung für die NFS-Domäne. Stellen Sie sicher, dass die Domäne als Azure NetApp Files-Standarddomäne (also defaultv4iddomain.com) konfiguriert und die Zuordnung auf nobody festgelegt ist.
sudo cat /etc/idmapd.conf
Beispielausgabe:
[General] Domain = defaultv4iddomain.com [Mapping] Nobody-User = nobody Nobody-Group = nobody
Wichtig
Stellen Sie sicher, dass die NFS-Domäne in
/etc/idmapd.conf
auf der VM so festgelegt ist, dass sie mit der Standarddomänenkonfiguration für Azure NetApp Files übereinstimmt: defaultv4iddomain.com. Im Fall eines Konflikts zwischen der Domänenkonfiguration auf dem NFS-Client (also der VM) und dem NFS-Server (also der Azure NetApp Files-Konfiguration) werden die Berechtigungen für Dateien auf Azure NetApp Files-Volumes, die auf den VMs eingebunden sind, alsnobody
angezeigt.[1] Binden Sie die knotenspezifischen Volumes auf „node1“ ein (hanadb1).
sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-log-mnt00001 /hana/log sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-data-mnt00001 /hana/data
[2] Binden Sie die knotenspezifischen Volumes auf „node2“ ein (hanadb2).
sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-shared-mnt00001 /hana/shared sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-log-mnt00001 /hana/log sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-data-mnt00001 /hana/data
[A] Überprüfen Sie, ob alle HANA-Volumes mit der NFS-Protokollversion „NFSv4“ eingebunden wurden.
sudo nfsstat -m
Vergewissern Sie sich, dass das Flag
vers
auf 4.1 festgelegt ist. Beispiel aus „hanadb1“:/hana/log from 10.32.2.4:/hanadb1-log-mnt00001 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4 /hana/data from 10.32.2.4:/hanadb1-data-mnt00001 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4 /hana/shared from 10.32.2.4:/hanadb1-shared-mnt00001 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
[A] Überprüfen Sie nfs4_disable_idmapping. Diese Angabe sollte auf Y (Ja) festgelegt sein. Führen Sie den Einbindungsbefehl aus, um die Verzeichnisstruktur zu erstellen, in der sich nfs4_disable_idmapping befindet. Sie können das Verzeichnis unter
/sys/modules
nicht manuell erstellen, da der Zugriff für den Kernel und Treiber reserviert ist.Suchen Sie nach
nfs4_disable_idmapping
.sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping
Wenn Sie
nfs4_disable_idmapping
festlegen müssen:sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
Legen Sie die Konfiguration als dauerhaft fest.
sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
Weitere Informationen zum Ändern des Parameters
nfs_disable_idmapping
finden Sie in der Red Hat-Wissensdatenbank.
SAP HANA-Installation
[A] Richten Sie die Hostnamensauflösung für alle Hosts ein.
Sie können entweder einen DNS-Server verwenden oder die Datei
/etc/hosts
auf allen Knoten ändern. In diesem Beispiel wird die Verwendung der Datei/etc/hosts
gezeigt. Ersetzen Sie die IP-Adresse und den Hostnamen in den folgenden Befehlen:sudo vi /etc/hosts
Fügen Sie in der Datei
/etc/hosts
die folgenden Zeilen ein. Ändern Sie die IP-Adresse und den Hostnamen Ihrer Umgebung entsprechend.10.32.0.4 hanadb1 10.32.0.5 hanadb2
[A] Bereiten Sie das Betriebssystem wie im SAP-Hinweis 3024346 – Linux-Kerneleinstellungen für NetApp NFS beschrieben für die Ausführung von SAP HANA in Azure NetApp mit NFS vor. Erstellen Sie die Konfigurationsdatei
/etc/sysctl.d/91-NetApp-HANA.conf
für die NetApp-Konfigurationseinstellungen.sudo vi /etc/sysctl.d/91-NetApp-HANA.conf
Fügen Sie in der Konfigurationsdatei die folgenden Einträge hinzu.
net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 131072 16777216 net.ipv4.tcp_wmem = 4096 16384 16777216 net.core.netdev_max_backlog = 300000 net.ipv4.tcp_slow_start_after_idle=0 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_moderate_rcvbuf = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_sack = 1
[A] Erstellen Sie die Konfigurationsdatei
/etc/sysctl.d/ms-az.conf
mit weiteren Optimierungseinstellungen.sudo vi /etc/sysctl.d/ms-az.conf
Fügen Sie in der Konfigurationsdatei die folgenden Einträge hinzu.
net.ipv6.conf.all.disable_ipv6 = 1 net.ipv4.tcp_max_syn_backlog = 16348 net.ipv4.conf.all.rp_filter = 0 sunrpc.tcp_slot_table_entries = 128 vm.swappiness=10
Tipp
Legen Sie
net.ipv4.ip_local_port_range
undnet.ipv4.ip_local_reserved_ports
in densysctl
-Konfigurationsdateien nicht explizit fest, damit der SAP-Host-Agent die Portbereiche verwalten kann. Weitere Informationen finden Sie im SAP-Hinweis 2382421.[A] Passen Sie die
sunrpc
-Einstellungen wie im SAP-Hinweis 3024346 – Linux-Kerneleinstellungen für NetApp NFS empfohlen an.sudo vi /etc/modprobe.d/sunrpc.conf
Fügen Sie die folgende Zeile ein:
options sunrpc tcp_max_slot_table_entries=128
[A] Führen Sie die RHEL-Betriebssystemkonfiguration für HANA durch.
Konfigurieren Sie je nach RHEL-Version das Betriebssystem wie in den folgenden SAP-Hinweisen beschrieben:
- 2292690 – SAP HANA DB: Recommended OS Settings for RHEL 7 (2292690 – SAP HANA DB: Empfohlene Betriebssystemeinstellungen für RHEL 7)
- 2777782 – SAP HANA DB: Empfohlene Betriebssystemeinstellungen für RHEL 8
- 2455582 – Linux: Running SAP applications compiled with GCC 6.x (Linux – Ausführen von mit GCC 6.x kompilierten SAP-Anwendungen)
- 2593824 – Linux: Ausführen von mit GCC 7.x kompilierten SAP-Anwendungen
- 2886607 – Linux: Ausführen von mit GCC 9.x kompilierten SAP-Anwendungen
[A] Installieren Sie SAP HANA.
Ab HANA 2.0 SPS 01 ist MDC die Standardoption. Wenn Sie das HANA-System installieren, werden SYSTEMDB und ein Mandant mit der gleichen Sicherheits-ID (SID) zusammen erstellt. In einigen Fällen möchten Sie vielleicht nicht den Standardmandaten verwenden. Wenn Sie bei der Installation keinen anfänglichen Mandanten erstellen möchten, befolgen Sie den SAP-Hinweis 2629711.
Führen Sie das Programm hdblcm von der HANA-DVD aus. Geben Sie an der Eingabeaufforderung folgende Werte ein:
- Choose installation: Geben Sie 1 (Installieren) ein.
- Select more components for installation: Geben Sie 1 ein.
- Enter Installation Path [/hana/shared]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Enter Local Host Name [..]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen. Möchten Sie dem System weitere Hosts hinzufügen? (y/n) [n]: n.
- Enter SAP HANA System ID: Geben Sie HN1 ein.
- Enter Instance Number [00]: Geben Sie 03 ein.
- Select Database Mode / Enter Index [1]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Select System Usage / Enter Index [4]: Geben Sie 4 (custom) ein.
- Enter Location of Data Volumes [/hana/data]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Enter Location of Log Volumes [/hana/log]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Möchten Sie die maximale Speicherbelegung beschränken? [n]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Enter Certificate Host Name For Host '...' [...]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Enter SAP Host Agent User (sapadm) Password: Geben Sie das Benutzerkennwort des Host-Agents ein.
- Confirm SAP Host Agent User (sapadm) Password: Geben Sie das Benutzerkennwort des Host-Agents zur Bestätigung erneut ein.
- Enter System Administrator (hn1adm) Password: Geben Sie das Systemadministratorkennwort ein.
- Confirm System Administrator (hn1adm) Password: Geben Sie das Systemadministratorkennwort zur Bestätigung erneut ein.
- Enter System Administrator Home Directory [/usr/sap/HN1/home]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Enter System Administrator Login Shell [/bin/sh]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Enter System Administrator User ID [1001]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Enter ID of User Group (sapsys) [79]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Enter Database User (SYSTEM) Password: Geben Sie das Benutzerkennwort für die Datenbank ein.
- Confirm Database User (SYSTEM) Password: Geben Sie das Benutzerkennwort für die Datenbank zur Bestätigung erneut ein.
- Soll das System nach dem Neustart des Computers neu starten? [n]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Möchten Sie fortfahren? (y/n): Überprüfen Sie die Zusammenfassung. Geben Sie y ein, um fortzufahren.
[A] Führen Sie ein Upgrade für den SAP-Host-Agent durch.
Laden Sie das aktuelle SAP-Host-Agent-Archiv vom SAP Software Center herunter, und führen Sie den folgenden Befehl zum Aktualisieren des Agents aus. Ersetzen Sie den Pfad zum Archiv, um auf die Datei zu verweisen, die Sie heruntergeladen haben:
sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent SAR>
[A] Konfigurieren Sie eine Firewall.
Erstellen Sie die Firewallregel für den Testport von Azure Load Balancer.
sudo firewall-cmd --zone=public --add-port=62503/tcp sudo firewall-cmd --zone=public --add-port=62503/tcp –permanent
Konfigurieren der SAP HANA-Systemreplikation
Führen Sie die Schritte zum Einrichten der SAP HANA-Systemreplikation aus, um die SAP HANA-Systemreplikation zu konfigurieren.
Clusterkonfiguration
In diesem Abschnitt werden die Schritte beschrieben, die für einen reibungslosen Clusterbetrieb erforderlich sind, wenn SAP HANA unter Verwendung von Azure NetApp Files auf NFS-Freigaben installiert wird.
Erstellen eines Pacemaker-Clusters
Führen Sie die Schritte in Einrichten von Pacemaker unter Red Hat Enterprise Linux in Azure aus, um einen einfachen Pacemaker-Cluster für diesen HANA-Server zu erstellen.
Wichtig
Mit dem auf systemd basierenden SAP Startup Framework können SAP HANA-Instanzen jetzt von systemd verwaltet werden. Die mindestens erforderliche Red Hat Enterprise Linux(RHEL)-Version ist RHEL 8 für SAP. Wie in SAP-Hinweis 3189534 beschrieben, wird das SAP Startup Framework bei alle neuen Installationen von SAP HANA SPS07 Revision 70 oder höher sowie bei Updates von HANA-Systemen auf HANA 2.0 SPS07 Revision 70 oder höher automatisch bei systemd registriert.
Bei Verwendung von Hochverfügbarkeitslösungen zur Verwaltung der SAP HANA-Systemreplikation in Kombination mit systemd-fähigen SAP HANA-Instanzen (siehe SAP-Hinweis 3189534) sind zusätzliche Schritte erforderlich, um sicherzustellen, dass der Hochverfügbarkeitscluster die SAP-Instanz ohne Störungen durch systemd verwalten kann. Für ein mit systemd integriertes SAP HANA-System müssen Sie daher die zusätzlichen Schritte in Red Hat KBA 7029705 auf allen Clusterknoten ausführen.
Implementieren des Python-Systemreplikationshooks „SAPHanaSR“
Dies ist ein wichtiger Schritt, um die Integration in den Cluster zu optimieren und besser zu erkennen, wann ein Clusterfailover erforderlich ist. Es wird dringend empfohlen, den SAPHanaSR-Python-Hook zu konfigurieren. Führen Sie die Schritte in Implementieren des Python-Systemreplikationshooks „SAPHanaSR“ aus.
Konfigurieren von Dateisystemressourcen
In diesem Beispiel verfügt jeder Clusterknoten über ein eigenes HANA-NFS-Dateisystem: /hana/shared
, /hana/data
und /hana/log
.
[1] Versetzen Sie den Cluster in den Wartungsmodus.
sudo pcs property set maintenance-mode=true
[1] Erstellen Sie die Dateisystemressourcen für die hanadb1-Einbindungen.
sudo pcs resource create hana_data1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs sudo pcs resource create hana_log1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs sudo pcs resource create hana_shared1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
[2] Erstellen Sie die Dateisystemressourcen für die hanadb2-Einbindungen.
sudo pcs resource create hana_data2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs sudo pcs resource create hana_log2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs sudo pcs resource create hana_shared2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
Das Attribut
OCF_CHECK_LEVEL=20
wird dem Überwachungsvorgang hinzugefügt, sodass jeder Monitor einen Lese-/Schreibtest für das Dateisystem durchführt. Ohne dieses Attribut überprüft der Überwachungsvorgang nur, ob das Dateisystem eingebunden ist. Dies kann ein Problem darstellen, da das Dateisystem im Fall eines Konnektivitätsverlusts möglicherweise eingebunden bleibt, obwohl nicht darauf zugegriffen werden kann.Das Attribut
on-fail=fence
wird auch dem Überwachungsvorgang hinzugefügt. Durch diese Option wird ein Knoten sofort eingegrenzt, wenn beim Überwachungsvorgang für diesen Knoten ein Fehler auftritt. Ohne diese Option werden standardmäßig alle von der ausgefallenen Ressource abhängigen Ressourcen beendet, die ausgefallene Ressource wird neu gestartet, und anschließend werden alle von der ausgefallenen Ressource abhängigen Ressourcen gestartet.Dieses Verhalten kann nicht nur sehr viel Zeit in Anspruch nehmen, wenn eine SAPHana-Ressource von der fehlerhaften Ressource abhängig ist, es kann auch vollständig fehlschlagen. Die SAPHana-Ressource kann nicht erfolgreich beendet werden, wenn der NFS-Server, auf dem sich die ausführbaren HANA-Dateien befinden, nicht erreichbar ist.
Die vorgeschlagenen Timeoutwerte ermöglichen es den Clusterressourcen, eine protokollspezifische Pause im Zusammenhang mit NFSv4.1-Leaseverlängerungen zu überstehen. Weitere Informationen finden Sie in den bewährten Methoden für NFS in NetApp. Die Timeoutwerte in der obigen Konfiguration müssen möglicherweise an das spezifische SAP-Setup angepasst werden.
Für Workloads, die einen höheren Durchsatz erfordern, empfiehlt sich die Verwendung der Einbindungsoption
nconnect
, wie unter NFS v4.1-Volumes unter Azure NetApp Files für SAP HANA beschrieben. Überprüfen Sie, obnconnect
von Azure NetApp Files in Ihrer Linux-Version unterstützt wird.[1] Konfigurieren Sie Speicherorteinschränkungen.
Konfigurieren Sie Speicherorteinschränkungen, um sicherzustellen, dass die Ressourcen, die eindeutige hanadb1-Einbindungen verwalten, niemals auf „hanadb2“ ausgeführt werden können und umgekehrt.
sudo pcs constraint location hanadb1_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb2 sudo pcs constraint location hanadb2_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb1
Die Option
resource-discovery=never
wird festgelegt, weil die eindeutigen Bereitstellungen für jeden Knoten gemeinsam denselben Bereitstellungspunkt nutzen. Beispielsweise verwendethana_data1
den Bereitstellungspunkt/hana/data
, undhana_data2
verwendet ebenfalls den Bereitstellungspunkt/hana/data
. Die gemeinsame Nutzung desselben Bereitstellungspunkts kann zu falsch positiven Ergebnissen bei Testvorgängen führen, wenn der Ressourcenzustand beim Start des Clusters überprüft wird. Dies wiederum kann unnötiges Wiederherstellungsverhalten verursachen. Legen Sieresource-discovery=never
fest, um dieses Szenario zu vermeiden.[1] Konfigurieren Sie Attributressourcen.
Konfigurieren Sie Attributressourcen. Diese Attribute werden auf „true“ festgelegt, wenn alle NFS-Einbindungen eines Knotens (
/hana/data
,/hana/log
und/hana/data
) eingebunden sind. Andernfalls werden sie auf „false“ festgelegt.sudo pcs resource create hana_nfs1_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs1_active sudo pcs resource create hana_nfs2_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs2_active
[1] Konfigurieren Sie Speicherorteinschränkungen.
Konfigurieren Sie Speicherorteinschränkungen, um sicherzustellen, dass die Attributressourcen von „hanadb1“ niemals auf „hanadb2“ ausgeführt werden und umgekehrt.
sudo pcs constraint location hana_nfs1_active avoids hanadb2 sudo pcs constraint location hana_nfs2_active avoids hanadb1
[1] Erstellen Sie Reihenfolgeneinschränkungen.
Erstellen Sie Reihenfolgeneinschränkungen, damit die Attributressourcen eines Knotens erst dann gestartet werden, wenn alle NFS-Bereitstellungen des Knotens eingebunden sind.
sudo pcs constraint order hanadb1_nfs then hana_nfs1_active sudo pcs constraint order hanadb2_nfs then hana_nfs2_active
Tipp
Wenn Ihre Konfiguration außerhalb der Gruppe
hanadb1_nfs
oder der Gruppehanadb2_nfs
Dateisysteme enthält, geben Sie die Optionsequential=false
an, sodass keine Reihenfolgenabhängigkeiten zwischen den Dateisystemen entstehen. Alle Dateisysteme müssen vorhana_nfs1_active
starten, eine bestimmte Reihenfolge untereinander ist aber nicht erforderlich. Weitere Informationen finden Sie unter Konfigurieren der SAP HANA-Systemreplikation mit „Hochskalieren“ in einem Pacemaker-Cluster, wenn sich die HANA-Dateisysteme auf NFS-Freigaben befinden.
Konfigurieren von SAP HANA-Clusterressourcen
Führen Sie die Schritte unter Erstellen von SAP HANA-Clusterressourcen aus, um die SAP HANA-Ressourcen im Cluster zu erstellen. Nachdem die SAP HANA-Ressourcen erstellt wurden, muss eine Regel für Speicherorteinschränkungen zwischen SAP HANA-Ressourcen und Dateisystemen (NFS-Einbindungen) erstellt werden.
[1] Konfigurieren Sie Einschränkungen zwischen den SAP HANA-Ressourcen und den NFS-Einbindungen.
Regeln für Speicherorteinschränkungen werden so festgelegt, dass die SAP HANA-Ressourcen nur dann auf einem Knoten ausgeführt werden können, wenn alle NFS-Einbindungen des Knotens eingebunden wurden.
sudo pcs constraint location SAPHanaTopology_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
Unter RHEL 7.x:
sudo pcs constraint location SAPHana_HN1_03-master rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
Unter RHEL 8.x/9.x:
sudo pcs constraint location SAPHana_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
Beenden Sie für den Cluster den Wartungsmodus.
sudo pcs property set maintenance-mode=false
Überprüfen Sie den Status des Clusters und sämtlicher Ressourcen.
Hinweis
In diesem Artikel wird ein Begriff verwendet, der von Microsoft nicht mehr genutzt wird. Sobald der Begriff aus der Software entfernt wurde, wird er auch aus diesem Artikel entfernt.
sudo pcs status
Beispielausgabe:
Online: [ hanadb1 hanadb2 ] Full list of resources: rsc_hdb_azr_agt(stonith:fence_azure_arm): Started hanadb1 Resource Group: hanadb1_nfs hana_data1 (ocf::heartbeat:Filesystem):Started hanadb1 hana_log1 (ocf::heartbeat:Filesystem):Started hanadb1 hana_shared1 (ocf::heartbeat:Filesystem):Started hanadb1 Resource Group: hanadb2_nfs hana_data2 (ocf::heartbeat:Filesystem):Started hanadb2 hana_log2 (ocf::heartbeat:Filesystem):Started hanadb2 hana_shared2 (ocf::heartbeat:Filesystem):Started hanadb2 hana_nfs1_active (ocf::pacemaker:attribute): Started hanadb1 hana_nfs2_active (ocf::pacemaker:attribute): Started hanadb2 Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03] Started: [ hanadb1 hanadb2 ] Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03] Masters: [ hanadb1 ] Slaves: [ hanadb2 ] Resource Group: g_ip_HN1_03 nc_HN1_03 (ocf::heartbeat:azure-lb): Started hanadb1 vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hanadb1
Konfigurieren der HANA-Systemreplikation im Modus „Aktiv/Lesezugriff“ in einem Pacemaker-Cluster
Ab SAP HANA 2.0 SPS 01 ermöglicht SAP Setups im Modus „Aktiv/Lesezugriff“ für die SAP HANA-Systemreplikation, bei denen die sekundären Systeme der SAP HANA-Systemreplikation aktiv für Workloads mit vielen Lesevorgängen verwendet werden können. Zur Unterstützung eines solchen Setups in einem Cluster ist eine zweite virtuelle IP-Adresse erforderlich, mit der Clients auf die sekundäre SAP HANA-Datenbank mit Lesezugriff zugreifen können.
Um sicherzustellen, dass der sekundäre Replikationsstandort auch nach einer Übernahme noch erreichbar ist, muss der Cluster die virtuelle IP-Adresse mit der sekundären der SAPHana-Ressource umziehen.
Informationen zu der zusätzlichen Konfiguration, die erforderlich ist, um die HANA-Systemreplikation im Modus „Aktiv/Lesezugriff“ in einem Red Hat-Hochverfügbarkeitscluster mit einer zweiten virtuellen IP-Adresse zu verwalten, finden Sie unter Konfigurieren der HANA-Systemreplikation im Modus „Aktiv/Lesezugriff“ in einem Pacemaker-Cluster.
Bevor Sie fortfahren, stellen Sie sicher, dass Sie den Red Hat-Hochverfügbarkeitscluster, der die SAP HANA-Datenbank verwaltet, wie in den obigen Abschnitten der Dokumentation beschrieben, vollständig konfiguriert haben.
Testen der Clustereinrichtung
In diesem Abschnitt wird beschrieben, wie Sie Ihre Einrichtung testen können.
Stellen Sie vor dem Starten eines Tests sicher, dass Pacemaker keine fehlerhaften Aktionen enthält (mit „pcs status“), dass keine unerwarteten Speicherorteinschränkungen bestehen (z. B. durch zurückgebliebene Elemente eines Migrationstests) und dass die HANA-Systemreplikation synchronisiert ist (z. B. mit
systemReplicationStatus
).sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
Überprüfen Sie die Clusterkonfiguration auf ein Fehlerszenario, bei dem ein Knoten den Zugriff auf die NFS-Freigabe (
/hana/shared
) verliert.Die SAP HANA-Ressourcen-Agents benötigen in
/hana/shared
gespeicherte Binärdateien, um während eines Failovers Vorgänge auszuführen. Das Dateisystem/hana/shared
ist in diesem Szenario über NFS eingebunden.Es ist schwierig, einen Fehler zu simulieren, bei dem einer der Server den Zugriff auf die NFS-Freigabe verliert. Zum Testen können Sie das Dateisystem als schreibgeschütztes Dateisystem erneut einbinden. Auf diese Weise lässt sich überprüfen, ob der Cluster ein Failover ausführen kann, wenn der Zugriff auf
/hana/shared
auf dem aktiven Knoten verloren geht.Erwartetes Ergebnis: Wenn
/hana/shared
als schreibgeschütztes Dateisystem festgelegt wird, tritt ein Fehler beim AttributOCF_CHECK_LEVEL
der Ressourcehana_shared1
auf, die Lese-/Schreibvorgänge im Dateisystem durchführt. Es kann nichts mehr in das Dateisystem geschrieben werden, und ein HANA-Ressourcenfailover wird ausgeführt. Dasselbe Ergebnis ist zu erwarten, wenn der HANA-Knoten den Zugriff auf die NFS-Freigaben verliert.Zustand der Ressource vor dem Starten des Tests:
sudo pcs status
Beispielausgabe:
Full list of resources: rsc_hdb_azr_agt (stonith:fence_azure_arm): Started hanadb1 Resource Group: hanadb1_nfs hana_data1 (ocf::heartbeat:Filesystem): Started hanadb1 hana_log1 (ocf::heartbeat:Filesystem): Started hanadb1 hana_shared1 (ocf::heartbeat:Filesystem): Started hanadb1 Resource Group: hanadb2_nfs hana_data2 (ocf::heartbeat:Filesystem): Started hanadb2 hana_log2 (ocf::heartbeat:Filesystem): Started hanadb2 hana_shared2 (ocf::heartbeat:Filesystem): Started hanadb2 hana_nfs1_active (ocf::pacemaker:attribute): Started hanadb1 hana_nfs2_active (ocf::pacemaker:attribute): Started hanadb2 Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03] Started: [ hanadb1 hanadb2 ] Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03] Masters: [ hanadb1 ] Slaves: [ hanadb2 ] Resource Group: g_ip_HN1_03 nc_HN1_03 (ocf::heartbeat:azure-lb): Started hanadb1 vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hanadb1
Sie können
/hana/shared
mithilfe des folgenden Befehls auf dem aktiven Clusterknoten in den schreibgeschützten Modus versetzen:sudo mount -o ro 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
hanadb
wird je nach Aktion, die fürstonith
festgelegt ist (pcs property show stonith-action
), entweder neu gestartet oder abgeschaltet. Wenn der Server (hanadb1
) nicht mehr verfügbar ist, wechselt die HANA-Ressource zuhanadb2
. Sie können den Status des Clusters überhanadb2
überprüfen.sudo pcs status
Beispielausgabe:
Full list of resources: rsc_hdb_azr_agt (stonith:fence_azure_arm): Started hanadb2 Resource Group: hanadb1_nfs hana_data1 (ocf::heartbeat:Filesystem): Stopped hana_log1 (ocf::heartbeat:Filesystem): Stopped hana_shared1 (ocf::heartbeat:Filesystem): Stopped Resource Group: hanadb2_nfs hana_data2 (ocf::heartbeat:Filesystem): Started hanadb2 hana_log2 (ocf::heartbeat:Filesystem): Started hanadb2 hana_shared2 (ocf::heartbeat:Filesystem): Started hanadb2 hana_nfs1_active (ocf::pacemaker:attribute): Stopped hana_nfs2_active (ocf::pacemaker:attribute): Started hanadb2 Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03] Started: [ hanadb2 ] Stopped: [ hanadb1 ] Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03] Masters: [ hanadb2 ] Stopped: [ hanadb1 ] Resource Group: g_ip_HN1_03 nc_HN1_03 (ocf::heartbeat:azure-lb): Started hanadb2 vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hanadb2
Es wird empfohlen, die SAP HANA-Clusterkonfiguration gründlich zu testen, indem Sie auch die unter Einrichten der SAP HANA-Systemreplikation unter RHEL beschriebenen Tests ausführen.
Nächste Schritte
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter:Einreichen und Feedback anzeigen für