Freigeben über


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:

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

Diagramm, das die Hochskalierung von SAP HANA HA-Hochverfügbarkeit auf Azure NetApp Files zeigt.

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.

  1. Erstellen Sie entsprechend den Anweisungen in Erstellen eines NetApp-Kontos ein NetApp-Konto in der ausgewählten Azure-Region.

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

  3. Delegieren Sie ein Subnetz an Azure NetApp Files, wie in den Anweisungen in Delegieren eines Subnetzes an Azure NetApp Files beschrieben.

  4. 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 und hanadb1-log-mnt00001 die Volumenamen und nfs://10.32.2.4/hanadb1-data-mnt00001 und nfs://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:

  1. 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.
  2. Back-End-Pool: Erstellen Sie einen Back-End-Pool, und fügen Sie Datenbank-VMs hinzu.
  3. 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

  1. [A] Erstellen Sie Bereitstellungspunkte für die HANA-Datenbankvolumes.

    sudo mkdir -p /hana/data
    sudo mkdir -p /hana/log
    sudo mkdir -p /hana/shared
    
  2. [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, als nobody angezeigt.

  3. [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
    
  4. [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
    
  5. [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
    
  6. [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

  1. [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
    
  2. [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
    
  3. [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 und net.ipv4.ip_local_reserved_ports in den sysctl-Konfigurationsdateien nicht explizit fest, damit der SAP-Host-Agent die Portbereiche verwalten kann. Weitere Informationen finden Sie im SAP-Hinweis 2382421.

  4. [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
    
  5. [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:

  6. [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:

    1. Choose installation: Geben Sie 1 (Installieren) ein.
    2. Select more components for installation: Geben Sie 1 ein.
    3. Enter Installation Path [/hana/shared]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
    4. 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.
    5. Enter SAP HANA System ID: Geben Sie HN1 ein.
    6. Enter Instance Number [00]: Geben Sie 03 ein.
    7. Select Database Mode / Enter Index [1]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
    8. Select System Usage / Enter Index [4]: Geben Sie 4 (custom) ein.
    9. Enter Location of Data Volumes [/hana/data]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
    10. Enter Location of Log Volumes [/hana/log]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
    11. Möchten Sie die maximale Speicherbelegung beschränken? [n]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
    12. Enter Certificate Host Name For Host '...' [...]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
    13. Enter SAP Host Agent User (sapadm) Password: Geben Sie das Benutzerkennwort des Host-Agents ein.
    14. Confirm SAP Host Agent User (sapadm) Password: Geben Sie das Benutzerkennwort des Host-Agents zur Bestätigung erneut ein.
    15. Enter System Administrator (hn1adm) Password: Geben Sie das Systemadministratorkennwort ein.
    16. Confirm System Administrator (hn1adm) Password: Geben Sie das Systemadministratorkennwort zur Bestätigung erneut ein.
    17. Enter System Administrator Home Directory [/usr/sap/HN1/home]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
    18. Enter System Administrator Login Shell [/bin/sh]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
    19. Enter System Administrator User ID [1001]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
    20. Enter ID of User Group (sapsys) [79]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
    21. Enter Database User (SYSTEM) Password: Geben Sie das Benutzerkennwort für die Datenbank ein.
    22. Confirm Database User (SYSTEM) Password: Geben Sie das Benutzerkennwort für die Datenbank zur Bestätigung erneut ein.
    23. Soll das System nach dem Neustart des Computers neu starten? [n]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
    24. Möchten Sie fortfahren? (y/n): Überprüfen Sie die Zusammenfassung. Geben Sie y ein, um fortzufahren.
  7. [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>
    
  8. [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. [1] Versetzen Sie den Cluster in den Wartungsmodus.

    sudo pcs property set maintenance-mode=true
    
  2. [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
    
  3. [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, ob nconnect von Azure NetApp Files in Ihrer Linux-Version unterstützt wird.

  4. [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 verwendet hana_data1 den Bereitstellungspunkt /hana/data, und hana_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 Sie resource-discovery=never fest, um dieses Szenario zu vermeiden.

  5. [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
    
  6. [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
    
  7. [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 Gruppe hanadb2_nfs Dateisysteme enthält, geben Sie die Option sequential=false an, sodass keine Reihenfolgenabhängigkeiten zwischen den Dateisystemen entstehen. Alle Dateisysteme müssen vor hana_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

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

  2. [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
    
  3. [1] Konfigurieren Sie Reihenfolgeneinschränkungen, sodass die SAP-Ressourcen auf einem Knoten vor einer Beendigung aller NFS-Bereitstellungen beendet werden.

    pcs constraint order stop SAPHanaTopology_HN1_03-clone then stop hanadb1_nfs
    pcs constraint order stop SAPHanaTopology_HN1_03-clone then stop hanadb2_nfs
    

    Unter RHEL 7.x:

    pcs constraint order stop SAPHana_HN1_03-master then stop hanadb1_nfs
    pcs constraint order stop SAPHana_HN1_03-master then stop hanadb2_nfs
    

    Unter RHEL 8.x/9.x:

    pcs constraint order stop SAPHana_HN1_03-clone then stop hanadb1_nfs
    pcs constraint order stop SAPHana_HN1_03-clone then stop hanadb2_nfs
    

    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.

  1. 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"
    
  2. Ü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 Attribut OCF_CHECK_LEVEL der Ressource hana_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ür stonith 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 zu hanadb2. Sie können den Status des Clusters über hanadb2 ü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