Hochverfügbarkeit von SAP HANA auf Azure-VMs unter SUSE Linux Enterprise Server
Für die lokale Entwicklung können Sie entweder die HANA-Systemreplikation oder freigegebenen Speicher verwenden, um Hochverfügbarkeit für SAP HANA einzurichten. Die HANA-Systemreplikation in Azure ist derzeit die einzige auf virtuellen Azure-Computern (VMs) unterstützte Hochverfügbarkeitsfunktion. Die SAP HANA-Replikation umfasst primären Knoten und mindestens einen sekundären Knoten. Änderungen an den Daten auf dem primären Knoten werden synchron oder asynchron an den sekundären Knoten repliziert.
Dieser Artikel beschreibt das Bereitstellen und Konfigurieren der virtuellen Computer, das Installieren des Clusterframeworks sowie das Installieren und Konfigurieren der SAP HANA-Systemreplikation. In den Beispielkonfigurationen und Installationsbefehlen werden die Instanznummer 03 und HANA-System-ID HN1 verwendet.
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 SAP-Software und Kombinationen aus Betriebssystem (OS) 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.
- SAP-Hinweis 2205917 enthält empfohlene Betriebssystemeinstellungen für den SUSE Linux Enterprise Server for SAP Applications.
- SAP-Hinweis 1944799 enthält SAP HANA-Richtlinien für den SUSE Linux Enterprise Server for SAP Applications.
- 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 1984787 enthält allgemeine Informationen zu SUSE Linux Enterprise Server 12.
- SAP-Hinweis 1999351 enthält Informationen zur Problembehandlung für die Azure-Erweiterung zur verbesserten Überwachung für SAP.
- SAP-Hinweis 401162 enthält Informationen zum Vermeiden der Meldung „Adresse bereits verwendet“ beim Einrichten der HANA-Systemreplikation.
- Das WIKI der SAP-Community enthält alle erforderlichen SAP-Hinweise für Linux.
- Zertifizierte SAP HANA-IaaS-Plattformen
- Leitfaden Azure Virtual Machines – Planung und Implementierung für SAP unter Linux
- Azure Virtual Machines – Bereitstellung für SAP unter Linux (dieser Artikel)
- Leitfaden Azure Virtual Machines – DBMS-Bereitstellung für SAP unter Linux
- Leitfäden für bewährte Methoden zu SUSE Linux Enterprise Server für SAP-Anwendungen 12 SP3
- Einrichten einer leistungsoptimierten Infrastruktur für die SAP HANA-Systemreplikation (SLES for SAP Applications 12 SP1). Das Handbuch enthält alle erforderlichen Informationen zum Einrichten der SAP HANA-Systemreplikation für die lokale Entwicklung. Verwenden Sie dieses Handbuch als Grundlage.
- Einrichten einer kostenoptimierten Infrastruktur für die SAP HANA-Systemreplikation (SLES for SAP Applications 12 SP1)
Übersicht
Um hohe Verfügbarkeit zu erreichen, ist SAP HANA auf zwei virtuellen Computern installiert. Die Daten werden mit der HANA-Systemreplikation repliziert.
Das Setup 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 dargestellte Konfiguration zeigt einen Lastenausgleich mit:
- Front-End-IP-Adresse: 10.0.0.13 für hn1-db
- Testport: 62503
Bereitstellen für Linux
Der Ressourcen-Agent für SAP HANA ist im SUSE Linux Enterprise Server für SAP-Anwendungen enthalten. Der Azure Marketplace enthält ein Image für den SUSE Linux Enterprise Server for SAP Applications 12, das Sie zum Bereitstellen neuer virtueller Computer verwenden können.
Bereitstellen mit einer Vorlage
Sie können eine der Schnellstartvorlagen auf GitHub verwenden, um alle erforderlichen Ressourcen bereitzustellen. Die Vorlage stellt die virtuellen Computer, den Lastenausgleich, die Verfügbarkeitsgruppe usw. bereit. Führen Sie diese Schritte aus, um die Vorlage bereitzustellen:
Öffnen Sie die Datenbankvorlage oder die konvergierte Vorlage im Azure-Portal. Die Datenbankvorlage erstellt nur die Lastenausgleichsregeln für eine Datenbank. Die konvergierte Vorlage erstellt auch die Lastenausgleichsregeln für eine ASCS/SCS- und ERS-Instanz (nur Linux). Wenn Sie ein SAP NetWeaver-basiertes System installieren und die ASCS/SCS-Instanz auf denselben Computern installieren möchten, verwenden Sie die konvergierte Vorlage.
Legen Sie die folgenden Parameter fest:
- SAP-System-ID: Geben Sie die SAP-System-ID des SAP-Systems ein, das Sie installieren möchten. Die ID wird als Präfix für die Ressourcen verwendet, die bereitgestellt werden.
- Stapeltyp: (Dieser Parameter gilt nur, wenn Sie die konvergierte Vorlage verwenden.) Wählen Sie den SAP NetWeaver-Stapeltyp aus.
- Betriebssystemtyp: Wählen Sie eine der Linux-Distributionen aus. Wählen Sie für dieses Beispiel SLES 12 aus.
- DB-Typ: Wählen Sie HANA aus.
- SAP-Systemgröße: Geben Sie die SAPS-Anzahl an, die das neue System bereitstellen soll. Wenn Sie nicht sicher sind, welche SAPS-Anzahl für das System benötigt wird, können Sie sich an den SAP-Technologiepartner oder -Systemintegrator wenden.
- Systemverfügbarkeit: Wählen Sie HA (Hohe Verfügbarkeit).
- Administratorbenutzername und Administratorkennwort: Ein neuer Benutzer wird erstellt, der für die Anmeldung beim Computer verwendet werden kann.
- Neues oder vorhandenes Subnetz: Legt fest, ob ein neues virtuelles Netzwerk und Subnetz erstellt oder ein bestehendes Subnetz verwendet werden soll. Wenn Sie bereits über ein virtuelles Netzwerk verfügen, das mit dem lokalen Netzwerk verbunden ist, wählen Sie hier Vorhanden aus.
- Subnetz-ID: Wenn Sie die VM in einem vorhandenen VNET bereitstellen möchten, in dem Sie ein Subnetz definiert haben, dem die VM zugewiesen werden soll, geben Sie die ID dieses spezifischen Subnetzes an. Die ID hat normalerweise das folgende Format: /subscriptions/<Abonnement-ID>/resourceGroups/<Ressourcengruppenname>/providers/Microsoft.Network/virtualNetworks/<VNet-Name>/subnets/<Subnetzname>.
Manuelle Bereitstellung
Wichtig
Stellen Sie sicher, dass das von Ihnen ausgewählte Betriebssystem SAP-zertifiziert ist für SAP HANA auf den spezifischen VM-Typen, die Sie verwenden. Die Liste der SAP HANA-zertifizierten VM-Typen und BS-Releases für diese kann unter Zertifizierte SAP HANA-IaaS-Plattformen nachgeschlagen werden. Stellen Sie sicher, dass Sie in die Details des jeweils aufgeführten VM-Typs klicken, um die vollständige Liste der von SAP HANA unterstützten BS-Releases für den spezifischen VM-Typ anzuzeigen.
Erstellen Sie eine Ressourcengruppe.
Erstellen Sie ein virtuelles Netzwerk.
Erstellen Sie eine Verfügbarkeitsgruppe.
- Richten Sie die maximale Updatedomäne ein.
Erstellen Sie einen Lastenausgleich (intern). Sie sollten Load Balancer Standard verwenden. Wählen Sie das virtuelle Netzwerk aus, das Sie in Schritt 2 erstellt haben.
Erstellen Sie den virtuellen Computer 1.
- Verwenden Sie ein SLES4SAP-Abbild im Azure-Katalog, das für SAP HANA auf dem von Ihnen ausgewählten VM-Typ unterstützt wird.
- Wählen Sie die Verfügbarkeitsgruppe aus, die Sie in Schritt 3 erstellt haben.
Erstellen Sie den virtuellen Computer 2.
- Verwenden Sie ein SLES4SAP-Abbild im Azure-Katalog, das für SAP HANA auf dem von Ihnen ausgewählten VM-Typ unterstützt wird.
- Wählen Sie die Verfügbarkeitsgruppe aus, die Sie in Schritt 3 erstellt haben.
Fügen Sie Datenträger hinzu.
Wichtig
Floating IP-Adressen werden in IP-Konfigurationen mit zwei NICs in Szenarien mit Lastenausgleich nicht unterstützt. Weitere Informationen finden Sie unter Azure Load Balancer – Einschränkungen. Wenn Sie zusätzliche IP-Adressen für die VM benötigen, stellen Sie eine zweite NIC bereit.
Hinweis
Wenn virtuelle Computer ohne öffentliche IP-Adressen im Back-End-Pool einer internen Azure Load Balancer Standard-Instanz (ohne öffentliche IP-Adresse) platziert werden, liegt keine ausgehende Internetverbindung vor, sofern nicht in einer zusätzlichen Konfiguration das Routing an öffentliche Endpunkte zugelassen wird. Ausführliche Informationen zum Erreichen ausgehender Konnektivität finden Sie unter Public endpoint connectivity for Virtual Machines using Azure Standard Load Balancer in SAP high-availability scenarios (Konnektivität mit öffentlichen Endpunkten für virtuelle Computer mithilfe von Azure Load Balancer Standard in SAP-Szenarien mit Hochverfügbarkeit).
Führen Sie zum Einrichten von Load Balancer Standard die folgenden Konfigurationsschritte aus:
Erstellen Sie zunächst einen Front-End-IP-Pool:
- Öffnen Sie den Lastenausgleich, und wählen Sie den Front-End-IP-Pool und dann Hinzufügen aus.
- Geben Sie den Namen des neuen Front-End-IP-Pools ein (z.B. hana-frontend).
- Legen Sie die Zuweisung auf Statisch fest, und geben Sie die IP-Adresse ein (z.B. 10.0.0.13).
- Klicken Sie auf OK.
- Notieren Sie nach Erstellen des neuen Front-End-IP-Pools dessen IP-Adresse.
Erstellen Sie einen einzelnen Back-End-Pool:
- Öffnen Sie den Lastenausgleich, und wählen Sie Back-End-Pools und dann Hinzufügen aus.
- Geben Sie den Namen des neuen Back-End-Pools ein (z.B. hana-backend).
- Wählen Sie für die Backend-Pool-Konfiguration die Option NIC aus.
- Wählen Sie Virtuellen Computer hinzufügen aus.
- Wählen Sie die virtuellen Computer des HANA-Clusters aus.
- Wählen Sie Hinzufügen.
- Wählen Sie Speichern aus.
Erstellen Sie als Nächstes einen Integritätstest:
- Öffnen Sie den Lastenausgleich, und wählen Sie Integritätstests und dann Hinzufügen aus.
- Geben Sie den Namen des neuen Integritätstests ein (z.B. hana-hp).
- Wählen Sie als Protokoll TCP und als Port 62503 aus. Behalten Sie den Intervallwert von 5 bei.
- Klicken Sie auf OK.
Erstellen Sie als Nächstes die Lastenausgleichsregeln:
- Öffnen Sie den Lastenausgleich, und wählen Sie Lastenausgleichsregeln und dann Hinzufügen aus.
- Geben Sie den Namen der neuen Lastenausgleichsregel ein (z. B. hana-lb).
- Wählen Sie die Front-End-IP-Adresse, den Back-End-Pool und den Integritätstest aus, die Sie zuvor erstellt haben (z. B. hana-frontend, hana-backend und hana-hp).
- Erhöhen Sie die Leerlaufzeitüberschreitung auf 30 Minuten.
- Wählen Sie HA-Ports aus.
- Achten Sie darauf, dass Sie „Floating IP“ aktivieren.
- Klicken Sie auf OK.
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.
Wichtig
Aktivieren Sie keine TCP-Zeitstempel auf Azure-VMs hinter Azure Load Balancer. Das Aktivieren von TCP-Zeitstempeln bewirkt, dass bei Integritätstests Fehler auftreten. Legen Sie den Parameter net.ipv4.tcp_timestamps auf 0 fest. Ausführliche Informationen finden Sie unter Lastenausgleichs-Integritätstests. Siehe auch SAP-Hinweis 2382421.
Erstellen eines Pacemaker-Clusters
Führen Sie die Schritte in Einrichten von Pacemaker auf SUSE Linux Enterprise Server in Azure zum Erstellen eines grundlegenden Pacemaker-Clusters für diesen HANA-Server aus. Sie können denselben Pacemaker-Cluster für SAP HANA und SAP NetWeaver (A)SCS verwenden.
Installieren von SAP HANA
Für die Schritte in diesem Abschnitt werden die folgenden Präfixe verwendet:
- [A] : Der Schritt gilt für alle Knoten.
- [1] : Der Schritt gilt nur für den Knoten 1.
- [2] : Der Schritt gilt nur für den Knoten 2 des Pacemaker-Clusters.
[A] Richten Sie das Datenträgerlayout Logical Volume Management (LVM) (Logische Volumeverwaltung) ein.
Es wird empfohlen, LVM für Volumes zu verwenden, die Daten- und Protokolldateien speichern. Im folgenden Beispiel wird davon ausgegangen, dass die virtuellen Computer über vier Datenträger verfügen, die zum Erstellen von zwei Volumes verwendet werden.
Auflisten aller verfügbaren Datenträger:
ls /dev/disk/azure/scsi1/lun*Beispielausgabe:
/dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1 /dev/disk/azure/scsi1/lun2 /dev/disk/azure/scsi1/lun3Erstellen Sie physische Volumes für alle Datenträger, die Sie verwenden möchten:
sudo pvcreate /dev/disk/azure/scsi1/lun0 sudo pvcreate /dev/disk/azure/scsi1/lun1 sudo pvcreate /dev/disk/azure/scsi1/lun2 sudo pvcreate /dev/disk/azure/scsi1/lun3Erstellen Sie eine Volumegruppe für die Datendateien. Erstellen Sie eine Volumegruppe für Protokolldateien und eine für das freigegebene Verzeichnis von SAP HANA:
sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1 sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2 sudo vgcreate vg_hana_shared_HN1 /dev/disk/azure/scsi1/lun3Erstellen Sie die logischen Volumes. Ein lineares Volume wird erstellt, wenn Sie
lvcreateohne den Schalter-iverwenden. Es wird empfohlen, ein Stripesetvolume für eine bessere E/A-Leistung zu erstellen und die Stripegrößen an die in SAP HANA VM-Speicherkonfigurationen dokumentierten Werte anzupassen. Das-i-Argument sollte die Anzahl der zugrunde liegenden physischen Volumes und das-I-Argument die Stripegröße sein. In diesem Dokument werden zwei physische Volumes für das Datenvolume verwendet, daher wird das Argument für den Schalter-iauf 2 festgelegt. Die Stripegröße für das Datenvolume beträgt 256 KiB. Für das Protokollvolume wird ein physisches Volume verwendet, sodass keine-i- oder-I-Schalter explizit für die Protokollvolumebefehle verwendet werden.Wichtig
Verwenden Sie den Schalter
-i, und ändern Sie die Zahl in die Anzahl der zugrunde liegenden physischen Volumes, wenn Sie für die einzelnen Daten-, Protokoll- oder freigegebenen Volumes mehrere physische Datenträger verwenden. Verwenden Sie den Schalter-I, um die Stripegröße festzulegen, wenn Sie ein Stripesetvolume erstellen.
Informationen zu empfohlenen Speicherkonfigurationen, einschließlich Stripegrößen und Anzahl der Datenträger, finden Sie unter SAP HANA VM-Speicherkonfigurationen.sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1 sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1 sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_HN1 sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log sudo mkfs.xfs /dev/vg_hana_shared_HN1/hana_sharedErstellen Sie die Bereitstellungsverzeichnisse, und kopieren Sie die UUID aller logischen Volumes:
sudo mkdir -p /hana/data/HN1 sudo mkdir -p /hana/log/HN1 sudo mkdir -p /hana/shared/HN1 # Write down the ID of /dev/vg_hana_data_HN1/hana_data, /dev/vg_hana_log_HN1/hana_log, and /dev/vg_hana_shared_HN1/hana_shared sudo blkidErstellen Sie
fstab-Einträge für die drei logischen Volumes:sudo vi /etc/fstabFügen Sie die folgende Zeile in die Datei
/etc/fstabein:/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_data_HN1-hana_data> /hana/data/HN1 xfs defaults,nofail 0 2 /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_log_HN1-hana_log> /hana/log/HN1 xfs defaults,nofail 0 2 /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_shared_HN1-hana_shared> /hana/shared/HN1 xfs defaults,nofail 0 2Stellen Sie die neuen Volumes bereit:
sudo mount -a[A] Richten Sie das Datenträgerlayout Einfache Datenträger ein.
Für Demosysteme können Sie Ihre HANA-Daten- und Protokolldateien auf einem Datenträger platzieren. Erstellen Sie auf „/dev/disk/azure/scsi1/lun0“ eine Partition, und formatieren Sie sie mit XFS:
sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0' sudo mkfs.xfs /dev/disk/azure/scsi1/lun0-part1 # Write down the ID of /dev/disk/azure/scsi1/lun0-part1 sudo /sbin/blkid sudo vi /etc/fstabFügen Sie diese Zeile in die Datei „/etc/fstab“ ein:
/dev/disk/by-uuid/<UUID> /hana xfs defaults,nofail 0 2Erstellen Sie das Zielverzeichnis, und stellen Sie den Datenträger bereit:
sudo mkdir /hana sudo mount -a[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“ veranschaulicht. Ersetzen Sie die IP-Adresse und den Hostnamen in den folgenden Befehlen:
sudo vi /etc/hostsFügen Sie in der Datei „/etc/hosts“ die folgenden Zeilen hinzu. Ändern Sie die IP-Adresse und den Hostnamen Ihrer Umgebung entsprechend:
10.0.0.5 hn1-db-0 10.0.0.6 hn1-db-1[A] Installieren Sie die Hochverfügbarkeitspakete für SAP HANA.
sudo zypper install SAPHanaSR
Installieren Sie die SAP HANA-Systemreplikation gemäß Kapitel 4 des SAP HANA SR Performance Optimized Scenario guide \(Handbuch zum Szenario der leistungsoptimierten SAP HANA-Systemreplikation).
[A] Führen Sie das Programm hdblcm von der HANA-DVD aus. Geben Sie an der Eingabeaufforderung folgende Werte ein:
- Wählen Sie die Installation aus: Geben Sie 1 ein.
- Wählen Sie weitere Komponenten für die Installation aus: Geben Sie 1 ein.
- Geben Sie den Installationspfad ein [/hana/shared]: Drücken Sie die EINGABETASTE.
- Geben Sie den Namen des lokalen Hosts ein [..]: Drücken Sie die EINGABETASTE.
- Möchten Sie dem System weitere Hosts hinzufügen? (j/n) [n] : Drücken Sie die EINGABETASTE.
- Geben Sie die SAP HANA-System-ID ein: Geben Sie die HANA-SID ein, z.B.: HN1.
- Geben Sie die Instanznummer ein [00]: Geben Sie die HANA-Instanznummer ein. Verwenden Sie 03, wenn Sie die Azure-Vorlage verwendet oder die in diesem Artikel beschriebene manuelle Bereitstellung durchgeführt haben.
- Wählen Sie den Datenbankmodus / geben Sie den Index ein [1]: Drücken Sie die EINGABETASTE.
- Wählen Sie die Systemnutzung / geben Sie den Index [ein 4]: Wählen Sie den Systemnutzungswert aus.
- Geben Sie den Speicherort der Datenvolumes ein [/hana/data/HN1]: Drücken Sie die EINGABETASTE.
- Geben Sie den Speicherort der Protokollvolumes ein [/hana/log/HN1]: Drücken Sie die EINGABETASTE.
- Möchten Sie die maximale Speicherbelegung beschränken? [n]: Drücken Sie die EINGABETASTE.
- Geben Sie den Zertifikathostnamen für Host „...“ ein [...]: Drücken Sie die EINGABETASTE.
- Geben Sie das Kennwort für den SAP-Host-Agent-Benutzer ein (sapadm): Geben Sie das Kennwort für den Host-Agent-Benutzer ein.
- Bestätigen Sie das Kennwort für den SAP-Host-Agent-Benutzer (sapadm): Geben Sie das Kennwort für den Host-Agent-Benutzer erneut ein, um es zu bestätigen.
- Geben Sie das Kennwort für den Systemadministrator ein (hdbadm): Geben Sie das Systemadministratorkennwort ein.
- Bestätigen Sie das Kennwort für den Systemadministrator (hdbadm): Geben Sie das Systemadministratorkennwort erneut ein, um es zu bestätigen.
- Geben Sie das Basisverzeichnis für den Systemadministrator ein [/usr/sap/HN1/home]: Drücken Sie die EINGABETASTE.
- Geben Sie die Anmelde-Shell für den Systemadministrator ein [/ bin/sh]: Drücken Sie die EINGABETASTE.
- Geben Sie die Benutzer-ID für den Systemadministrator ein [1001]: Drücken Sie die EINGABETASTE.
- Geben Sie die ID der Benutzergruppe ein (sapsys) [79]: Drücken Sie die EINGABETASTE.
- Geben Sie das Datenbankbenutzer-Kennwort ein (SYSTEM): Geben Sie das Kennwort für Datenbankbenutzer ein.
- Bestätigen Sie das Datenbankbenutzer-Kennwort (SYSTEM): Geben Sie das Kennwort für Datenbankbenutzer erneut ein, um es zu bestätigen.
- Soll das System nach dem Neustart des Computers neu starten? [n]: Drücken Sie die EINGABETASTE.
- Möchten Sie fortfahren? (j/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>
Konfigurieren der SAP HANA 2.0-Systemreplikation
Für die Schritte in diesem Abschnitt werden die folgenden Präfixe verwendet:
- [A] : Der Schritt gilt für alle Knoten.
- [1] : Der Schritt gilt nur für den Knoten 1.
- [2] : Der Schritt gilt nur für den Knoten 2 des Pacemaker-Clusters.
[1] Erstellen Sie die Mandantendatenbank.
Wenn Sie SAP HANA 2.0 oder MDC verwenden, erstellen Sie eine Mandantendatenbank für Ihr SAP NetWeaver-System. Ersetzen Sie NW1 durch die SID des SAP-Systems.
Führen Sie den folgenden Befehl als „<hanasid>adm“ aus:
hdbsql -u SYSTEM -p "passwd" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "passwd"'[1] Konfigurieren Sie die Systemreplikation auf dem ersten Knoten.
Sichern Sie die Datenbanken als „<hanasid>adm“:
hdbsql -d SYSTEMDB -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')" hdbsql -d HN1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')" hdbsql -d NW1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupNW1')"Kopieren Sie die PKI-Systemdateien auf den sekundären Standort:
scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/ scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/Erstellen Sie den primären Standort:
hdbnsutil -sr_enable --name=SITE1[2] Konfigurieren Sie die Systemreplikation auf dem zweiten Knoten.
Registrieren Sie den zweiten Knoten zum Starten der Replikation. Führen Sie den folgenden Befehl als „<hanasid>adm“ aus:
sapcontrol -nr 03 -function StopWait 600 10 hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
Konfigurieren der SAP HANA 1.0-Systemreplikation
Für die Schritte in diesem Abschnitt werden die folgenden Präfixe verwendet:
- [A] : Der Schritt gilt für alle Knoten.
- [1] : Der Schritt gilt nur für den Knoten 1.
- [2] : Der Schritt gilt nur für den Knoten 2 des Pacemaker-Clusters.
[1] Erstellen Sie die erforderlichen Benutzer.
Führen Sie den folgenden Befehl als root aus. Achten Sie darauf, die fett formatierten Zeichenfolgen (HANA-System-ID HN1 und Instanzenanzahl 03) durch die Werte Ihrer SAP HANA-Installation zu ersetzen:
PATH="$PATH:/usr/sap/HN1/HDB03/exe" hdbsql -u system -i 03 'CREATE USER hdbhasync PASSWORD "passwd"' hdbsql -u system -i 03 'GRANT DATA ADMIN TO hdbhasync' hdbsql -u system -i 03 'ALTER USER hdbhasync DISABLE PASSWORD LIFETIME'[A] Erstellen Sie den Keystoreeintrag.
Führen Sie den folgenden Befehl als root aus, um einen neuen Keystoreeintrag zu erstellen:
PATH="$PATH:/usr/sap/HN1/HDB03/exe" hdbuserstore SET hdbhaloc localhost:30315 hdbhasync passwd[1] Sichern Sie die Datenbank.
Sichern Sie die Datenbanken als root:
PATH="$PATH:/usr/sap/HN1/HDB03/exe" hdbsql -d SYSTEMDB -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"Wenn Sie eine Installation mit mehreren Mandanten verwenden, sichern Sie auch die Mandantendatenbank:
hdbsql -d HN1 -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"[1] Konfigurieren Sie die Systemreplikation auf dem ersten Knoten.
Erstellen Sie den primären Standort als „<hanasid>adm“:
su - hdbadm hdbnsutil -sr_enable –-name=SITE1[2] Konfigurieren Sie die Systemreplikation auf dem zweiten Knoten.
Registrieren Sie den sekundären Standort als „<hanasid>adm“:
sapcontrol -nr 03 -function StopWait 600 10 hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
Implementieren der HANA-Hooks SAPHanaSR und susChkSrv
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 Python-Hook „SAPHanaSR“ zu konfigurieren. Für HANA 2.0 SP5 und höher wird die Implementierung von SAPHanaSR zusammen mit dem susChkSrv-Hook empfohlen.
SusChkSrv erweitert die Funktionalität des wichtigsten SAPHanaSR-Hochverfügbarkeitsanbieters. Der Hook wird wirksam, wenn der HANA-Prozess hdbindexserver abstürzt. Wenn ein einzelner Prozess abstürzt, versucht HANA in der Regel, ihn neu zu starten. Das Neustarten des Indexserverprozesses kann lange dauern. In dieser Zeit reagiert die HANA-Datenbank nicht.
Wenn susChkSrv implementiert ist, wird eine sofortige und konfigurierbare Aktion ausgeführt, die ein Failover im konfigurierten Timeoutzeitraum auslöst, anstatt auf den hdbindexserver-Prozess zu warten, bis dieser auf demselben Knoten neu gestartet wird.
[A] Installieren Sie den Systemreplikationshook für HANA. Der Hook muss auf beiden HANA-Datenbankknoten installiert werden.
Tipp
Der SAPHanaSR-Python-Hook kann nur für HANA 2.0 implementiert werden. Das SapHanaSR-Paket muss mindestens Version 0.153 aufweisen.
Der susChkSrv Python-Hook erfordert SAP HANA 2.0 SP5, und die SAPHanaSR-Version 0.161.1_BF oder höher muss installiert sein.- Beenden Sie HANA auf beiden Knoten. Führen Sie den Vorgang als <sid>adm aus:
sapcontrol -nr 03 -function StopSystem- Passen Sie die Datei
global.iniauf jedem Clusterknoten an. Wenn die Anforderungen für den susChkSrv-Hook nicht erfüllt sind, entfernen Sie den gesamten Block [ha_dr_provider_suschksrv] aus den folgenden Parametern.
Sie können das Verhalten von susChkSrv mit dem Parameter action_on_lost anpassen.
Gültige Werte sind [ ignore | stop | kill | fence ].
# add to global.ini [ha_dr_provider_SAPHanaSR] provider = SAPHanaSR path = /usr/share/SAPHanaSR execution_order = 1 [ha_dr_provider_suschksrv] provider = susChkSrv path = /usr/share/SAPHanaSR execution_order = 3 action_on_lost = fence [trace] ha_dr_saphanasr = info
Die Konfiguration, die auf den Standardspeicherort /usr/share/SAPHanaSR verweist, hat den Vorteil, dass der Python-Hookcode automatisch über Betriebssystem- oder Paketupdates aktualisiert und von HANA beim nächsten Neustart verwendet wird. Mit einem optionalen eigenen Pfad wie /hana/shared/myHooks können Sie Betriebssystemupdates mit der verwendeten Hookversion entkoppeln.
[A] Der Cluster erfordert die Konfiguration von „sudoers“ auf jedem Clusterknoten für „<sid>adm“. In diesem Beispiel wird dies durch das Erstellen einer neuen Datei erreicht. Führen Sie den Befehl als
rootaus, und passen Sie die Werte von hn1/HN1 mit der richtigen SID an.cat << EOF > /etc/sudoers.d/20-saphana # Needed for SAPHanaSR and susChkSrv Python hooks hn1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_* hn1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=HN1 --case=fenceMe EOF
Weitere Informationen zur Implementierung des SAP HANA-Systemreplikationshooks finden Sie unter Einrichten von Hochverfügbarkeits-/Notfallwiederherstellungsanbietern für SAP HANA.
[A] Starten Sie SAP HANA auf beiden Knoten. Führen Sie den Vorgang als <sid>adm aus:
sapcontrol -nr 03 -function StartSystem[1] Überprüfen Sie die Installation des Hooks. Nehmen Sie die Ausführung als <sid>adm auf dem aktiven Replikationsstandort des HANA-Systems vor.
cdtrace awk '/ha_dr_SAPHanaSR.*crm_attribute/ \ { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_* # Example output # 2021-04-08 22:18:15.877583 ha_dr_SAPHanaSR SFAIL # 2021-04-08 22:18:46.531564 ha_dr_SAPHanaSR SFAIL # 2021-04-08 22:21:26.816573 ha_dr_SAPHanaSR SOKÜberprüfen Sie die Installation des susChkSrv-Hooks. Ausführen als <sid>adm auf allen HANA-VMs
cdtrace egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc # Example output # 2022-11-03 18:06:21.116728 susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9 # 2022-11-03 18:06:27.613588 START: indexserver event looks like graceful tenant start # 2022-11-03 18:07:56.143766 START: indexserver event looks like graceful tenant start (indexserver started)
Erstellen von SAP HANA-Clusterressourcen
Erstellen Sie zuerst die HANA-Topologie. Führen Sie die folgenden Befehle auf einem der Pacemaker-Clusterknoten aus:
sudo crm configure property maintenance-mode=true
# Replace the bold string with your instance number and HANA system ID
sudo crm configure primitive rsc_SAPHanaTopology_HN1_HDB03 ocf:suse:SAPHanaTopology \
operations \$id="rsc_sap2_HN1_HDB03-operations" \
op monitor interval="10" timeout="600" \
op start interval="0" timeout="600" \
op stop interval="0" timeout="300" \
params SID="HN1" InstanceNumber="03"
sudo crm configure clone cln_SAPHanaTopology_HN1_HDB03 rsc_SAPHanaTopology_HN1_HDB03 \
meta clone-node-max="1" target-role="Started" interleave="true"
Erstellen Sie als Nächstes die HANA-Ressourcen:
Wichtig
Kürzlich durchgeführte Tests haben Situationen aufgezeigt, in denen netcat aufgrund von Backlog und der Einschränkung, nur eine Verbindung zu verarbeiten, nicht mehr auf Anforderungen reagiert. Die netcat-Ressource lauscht dann nicht mehr auf Azure Load Balancer-Anforderungen, und die Floating IP-Adresse ist nicht mehr verfügbar.
Für vorhandene Pacemaker-Cluster wurde zuvor empfohlen, netcat durch socat zu ersetzen. Zurzeit wird empfohlen, den Ressourcen-Agent azure-lb zu verwenden, der Teil des Pakets resource-agents ist. Dabei gelten die folgenden Versionsanforderungen für das Paket:
- Für SLES 12 SP4/SP5 muss die Version mindestens resource-agents-4.3.018.a7fb5035-3.30.1 sein.
- Für SLES 15/15 SP1 muss die Version mindestens resource-agents-4.3.0184.6ee15eb2-4.13.1 sein.
Beachten Sie, dass für die Änderung eine kurze Ausfallzeit erforderlich ist.
Wenn die Konfiguration bei vorhandenen Pacemaker-Clustern bereits für die Verwendung von socat geändert wurde, wie unter Azure Load Balancer-Erkennungshärtung beschrieben, müssen Sie nicht sofort zum Ressourcen-Agent azure-lb wechseln.
Hinweis
Dieser Artikel enthält Verweise auf die Begriffe Master und Slave, die von Microsoft nicht mehr verwendet werden. Sobald diese Begriffe aus der Software entfernt wurden, werden sie auch aus diesem Artikel gelöscht.
# Replace the bold string with your instance number, HANA system ID, and the front-end IP address of the Azure load balancer.
sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHana \
operations \$id="rsc_sap_HN1_HDB03-operations" \
op start interval="0" timeout="3600" \
op stop interval="0" timeout="3600" \
op promote interval="0" timeout="3600" \
op monitor interval="60" role="Master" timeout="700" \
op monitor interval="61" role="Slave" timeout="700" \
params SID="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"
sudo crm configure ms msl_SAPHana_HN1_HDB03 rsc_SAPHana_HN1_HDB03 \
meta notify="true" clone-max="2" clone-node-max="1" \
target-role="Started" interleave="true"
sudo crm configure primitive rsc_ip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
meta target-role="Started" \
operations \$id="rsc_ip_HN1_HDB03-operations" \
op monitor interval="10s" timeout="20s" \
params ip="10.0.0.13"
sudo crm configure primitive rsc_nc_HN1_HDB03 azure-lb port=62503 \
op monitor timeout=20s interval=10 \
meta resource-stickiness=0
sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03
sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \
msl_SAPHana_HN1_HDB03:Master
sudo crm configure order ord_SAPHana_HN1_HDB03 Optional: cln_SAPHanaTopology_HN1_HDB03 \
msl_SAPHana_HN1_HDB03
# Clean up the HANA resources. The HANA resources might have failed because of a known issue.
sudo crm resource cleanup rsc_SAPHana_HN1_HDB03
sudo crm configure property maintenance-mode=false
sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000
Wichtig
Es wird als bewährte Methode empfohlen, AUTOMATED_REGISTER nur auf no festzulegen, während gründliche Failovertests durchgeführt werden, um zu verhindern, dass sich eine fehlerhafte primäre Instanz automatisch als sekundäre Instanz registriert. Nachdem die Failover-Tests erfolgreich abgeschlossen sind, legen Sie AUTOMATED_REGISTER auf yes fest, sodass nach der Übernahme die Systemreplikation automatisch wieder aufgenommen werden kann.
Stellen Sie sicher, dass der Clusterstatus gültig ist und alle Ressourcen gestartet sind. Es ist nicht wichtig, auf welchem Knoten die Ressourcen ausgeführt werden.
sudo crm_mon -r
# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
# Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
# Masters: [ hn1-db-0 ]
# Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
# rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
# rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0
Konfigurieren der „Aktiv/Lesezugriff“-HANA-Systemreplikation im Pacemaker-Cluster
Ab SAP HANA 2.0 SPS 01 SAP ist das „Aktiv/Lesezugriff“-Setup für die SAP HANA-Systemreplikation möglich, wobei 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 aktivierten Lesevorgängen zugreifen können. Damit nach einer Übernahme weiterhin auf die sekundäre Replikationswebsite zugegriffen werden kann, muss der Cluster die virtuelle IP-Adresse zusammen mit der sekundären Instanz der SAP HANA-Ressource verschieben.
In diesem Abschnitt werden die zusätzlichen Schritte beschrieben, die zum Verwalten der „Aktiv/Lesezugriff“-HANA-Systemreplikation in einem SUSE-Hochverfügbarkeitscluster mit zweiter virtueller IP-Adresse erforderlich sind.
Bevor Sie fortfahren, vergewissern Sie sich, dass Sie den SUSE-Hochverfügbarkeitscluster, der die SAP HANA-Datenbank verwaltet, wie in den obigen Abschnitten der Dokumentation beschrieben vollständig konfiguriert haben.
Zusätzliches Setup in Azure Load Balancer für „Aktiv/Lesezugriff“-Setup
Um mit zusätzlichen Schritten für die Bereitstellung der zweiten virtuellen IP-Adresse fortzufahren, stellen Sie sicher, dass Sie Azure Load Balancer wie im Abschnitt Manuelle Bereitstellung beschrieben konfiguriert haben.
Führen Sie für den standardmäßigen Lastenausgleich die unten aufgeführten zusätzlichen Schritte für denselben Lastenausgleich aus, den Sie im vorherigen Abschnitt erstellt haben.
a. Erstellen eines zweiten Front-End-IP-Pools:
- Öffnen Sie den Lastenausgleich, und wählen Sie den Front-End-IP-Pool und dann Hinzufügen aus.
- Geben Sie den Namen des zweiten Front-End-IP-Pools ein (z. B. hana-secondaryIP).
- Legen Sie die Zuweisung auf Statisch fest, und geben Sie die IP-Adresse ein (z. B. 10.0.0.14).
- Klicken Sie auf OK.
- Notieren Sie nach Erstellen des neuen Front-End-IP-Pools die Front-End-IP-Adresse.
b. Erstellen Sie als Nächstes einen Integritätstest:
- Öffnen Sie den Lastenausgleich, und wählen Sie Integritätstests und dann Hinzufügen aus.
- Geben Sie den Namen des neuen Integritätstests ein (z. B. hana-secondaryhp).
- Wählen Sie TCP als Protokoll und den Port 62603 aus. Behalten Sie für das Intervall den Wert „5“ und als Fehlerschwellenwert „2“ bei.
- Klicken Sie auf OK.
c. Erstellen Sie als Nächstes die Lastenausgleichsregeln:
- Öffnen Sie den Lastenausgleich, und wählen Sie Lastenausgleichsregeln und dann Hinzufügen aus.
- Geben Sie den Namen der neuen Lastenausgleichsregel ein (z. B. hana-secondarylb).
- Wählen Sie die Front-End-IP-Adresse, den Back-End-Pool und den Integritätstest aus, die Sie zuvor erstellt haben (z. B. hana-secondaryIP, hana-backend und hana-secondaryhp).
- Wählen Sie HA-Ports aus.
- Erhöhen Sie die Leerlaufzeitüberschreitung auf 30 Minuten.
- Achten Sie darauf, dass Sie „Floating IP“ aktivieren.
- Klicken Sie auf OK.
Konfigurieren der „Aktiv/Lesezugriff“-HANA-Systemreplikation
Die Schritte zum Konfigurieren der HANA-Systemreplikation werden im Abschnitt Konfigurieren der SAP Hana 2.0-Systemreplikation beschrieben. Wenn Sie ein sekundäres Szenario mit Lesezugriff bereitstellen, während Sie die Systemreplikation auf dem zweiten Knoten konfigurieren, führen Sie den folgenden Befehl als hanasidadm aus:
sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 --operationMode=logreplay_readaccess
Hinzufügen einer sekundären virtuellen IP-Adressressource für ein „Aktiv/Lesezugriff“-Setup
Die zweite virtuelle IP-Adresse und die geeignete Zusammenstellungseinschränkung können mit den folgenden Befehlen konfiguriert werden:
crm configure property maintenance-mode=true
crm configure primitive rsc_secip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
meta target-role="Started" \
operations \$id="rsc_secip_HN1_HDB03-operations" \
op monitor interval="10s" timeout="20s" \
params ip="10.0.0.14"
crm configure primitive rsc_secnc_HN1_HDB03 azure-lb port=62603 \
op monitor timeout=20s interval=10 \
meta resource-stickiness=0
crm configure group g_secip_HN1_HDB03 rsc_secip_HN1_HDB03 rsc_secnc_HN1_HDB03
crm configure colocation col_saphana_secip_HN1_HDB03 4000: g_secip_HN1_HDB03:Started \
msl_SAPHana_HN1_HDB03:Slave
crm configure property maintenance-mode=false
Stellen Sie sicher, dass der Clusterstatus gültig ist und alle Ressourcen gestartet sind. Die zweite virtuelle IP-Adresse wird zusammen mit der sekundären SAPHana-Ressource am sekundären Standort ausgeführt.
sudo crm_mon -r
# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
# Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
# Masters: [ hn1-db-0 ]
# Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
# rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
# rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0
# Resource Group: g_secip_HN1_HDB03:
# rsc_secip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
# rsc_secnc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1
Im nächsten Abschnitt finden Sie den typischen Satz auszuführender Failovertests.
Beachten Sie beim Testen eines mit lesbarem sekundärem Replikat konfigurierten HANA-Clusters das Verhalten der zweiten virtuellen IP-Adresse:
Wenn Sie die Clusterressource SAPHana_HN1_HDB03 zu hn1-db-1 migrieren, wird die zweite virtuelle IP-Adresse auf den anderen Server hn1-db-0 verschoben. Wenn Sie AUTOMATED_REGISTER="false" konfiguriert haben und die HANA-Systemreplikation nicht automatisch registriert wird, wird die zweite virtuelle IP-Adresse auf hn1-db-0 ausgeführt, da der Server verfügbar ist und die Clusterdienste online sind.
Beim Testen eines Serverabsturzes werden die zweiten virtuellen IP-Ressourcen (rsc_secip_HN1_HDB03) und die Azure Load Balancer-Portressource (rsc_secnc_HN1_HDB03) auf dem primären Server neben den primären virtuellen IP-Ressourcen ausgeführt. Während der sekundäre Server ausgefallen ist, stellen die Anwendungen, die mit einer HANA-Datenbank mit Lesezugriff verbunden sind, eine Verbindung mit der primären HANA-Datenbank her. Das Verhalten wird erwartet, da Sie nicht möchten, dass auf Anwendungen, die mit einer HANA-Datenbank mit Lesezugriff verbunden sind, nicht zugegriffen werden kann, während der sekundäre Server nicht verfügbar ist.
Wenn der sekundäre Server verfügbar ist und die Clusterdienste online sind, werden die zweiten virtuellen IP- und die Portressourcen automatisch auf den sekundären Server verschoben, auch wenn die HANA-Systemreplikation möglicherweise nicht als sekundär registriert ist. Sie müssen sicherstellen, dass Sie die sekundäre HANA-Datenbank als gelesen registrieren, bevor Sie Clusterdienste auf diesem Server starten. Sie können die Clusterressource der HANA-Instanz mit der Parameterfestlegung AUTOMATED_REGISTER=true so konfigurieren, dass die sekundäre Instanz automatisch registriert wird.
Während des Failovers und Fallbacks werden die vorhandenen Verbindungen für Anwendungen unter Verwendung der zweiten virtuellen IP-Adresse zum Herstellen einer Verbindung mit der HANA-Datenbank möglicherweise unterbrochen.
Testen der Clustereinrichtung
In diesem Abschnitt wird beschrieben, wie Sie Ihre Einrichtung testen können. Jeder Test setzt voraus, dass Sie der Stammbenutzer sind und der SAP HANA-Master auf dem virtuellen Computer hn1-db-0 ausgeführt wird.
Testen der Migration
Bevor Sie den Test starten, stellen Sie sicher, dass Pacemaker keine fehlerhaften Aktionen enthält (mit crm_mon -r), dass keine unerwarteten Speicherorteinschränkungen bestehen (z.B. durch zurückgebliebene Elemente vom Migrationstest) und dass HANA synchron ist (z.B. mit SAPHanaSR-showAttr):
hn1-db-0:~ # SAPHanaSR-showAttr
Sites srHook
----------------
SITE2 SOK
Global cib-time
--------------------------------
global Mon Aug 13 11:26:04 2018
Hosts clone_state lpa_hn1_lpt node_state op_mode remoteHost roles score site srmode sync_state version vhost
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED 1534159564 online logreplay nws-hana-vm-1 4:P:master1:master:worker:master 150 SITE1 sync PRIM 2.00.030.00.1522209842 nws-hana-vm-0
hn1-db-1 DEMOTED 30 online logreplay nws-hana-vm-0 4:S:master1:master:worker:master 100 SITE2 sync SOK 2.00.030.00.1522209842 nws-hana-vm-1
Sie können den SAP HANA-Masterknoten migrieren, indem Sie den folgenden Befehl ausführen:
crm resource move msl_SAPHana_HN1_HDB03 hn1-db-1 force
Wenn Sie AUTOMATED_REGISTER="false" festlegen, sollte diese Befehlsfolge den SAP HANA-Masterknoten und die Gruppe, die die virtuelle IP-Adresse enthält, zu „hn1-db-1“ migrieren.
Nachdem die Migration abgeschlossen ist, sieht die Ausgabe von crm_mon -r wie folgt aus:
Online: [ hn1-db-0 hn1-db-1 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started hn1-db-1
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Stopped: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1
Failed Actions:
* rsc_SAPHana_HN1_HDB03_start_0 on hn1-db-0 'not running' (7): call=84, status=complete, exitreason='none',
last-rc-change='Mon Aug 13 11:31:37 2018', queued=0ms, exec=2095ms
Die SAP HANA-Ressource auf „hn1-db-0“ wird nicht als sekundär gestartet. In diesem Fall konfigurieren Sie die HANA-Instanz als sekundär, indem Sie diesen Befehl ausführen:
su - hn1adm
# Stop the HANA instance just in case it is running
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> sapcontrol -nr 03 -function StopWait 600 10
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1
Die Migration erstellt Speicherorteinschränkungen, die erneut gelöscht werden müssen:
# Switch back to root and clean up the failed state
exit
hn1-db-0:~ # crm resource clear msl_SAPHana_HN1_HDB03
Darüber hinaus müssen Sie auch den Status der sekundären Knotenressource bereinigen:
hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0
Sie überwachen den Status der HANA-Ressource mithilfe von crm_mon -r. Nachdem HANA auf „hn1-db-0“ gestartet wurde, sollte die Ausgabe wie folgt aussehen:
Online: [ hn1-db-0 hn1-db-1 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started hn1-db-1
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1
Testen des Azure-Umgrenzungs-Agent (nicht SBD)
Sie können die Einrichtung des Azure-Umgrenzungs-Agent testen, indem Sie die Netzwerkschnittstelle auf dem Knoten „hn1-db-0“ deaktivieren:
sudo ifdown eth0
Der virtuelle Computer sollte jetzt abhängig von Ihrer Clusterkonfiguration neu gestartet oder beendet werden.
Wenn Sie die stonith-action-Einstellung auf „Aus“ festlegen, wird der virtuelle Computer beendet, und die Ressourcen werden zu dem ausgeführten virtuellen Computer migriert.
Wenn Sie den virtuellen Computer erneut starten, wird die SAP HANA-Ressource nicht als sekundär gestartet, wenn Sie AUTOMATED_REGISTER="false" festlegen. In diesem Fall konfigurieren Sie die HANA-Instanz als sekundär, indem Sie diesen Befehl ausführen:
su - hn1adm
# Stop the HANA instance just in case it is running
sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1
# Switch back to root and clean up the failed state
exit
crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0
Testen der SBD-Umgrenzung
Sie können das Setup von SBD testen, indem Sie den inquisitor-Prozess beenden.
hn1-db-0:~ # ps aux | grep sbd
root 1912 0.0 0.0 85420 11740 ? SL 12:25 0:00 sbd: inquisitor
root 1929 0.0 0.0 85456 11776 ? SL 12:25 0:00 sbd: watcher: /dev/disk/by-id/scsi-360014056f268462316e4681b704a9f73 - slot: 0 - uuid: 7b862dba-e7f7-4800-92ed-f76a4e3978c8
root 1930 0.0 0.0 85456 11776 ? SL 12:25 0:00 sbd: watcher: /dev/disk/by-id/scsi-360014059bc9ea4e4bac4b18808299aaf - slot: 0 - uuid: 5813ee04-b75c-482e-805e-3b1e22ba16cd
root 1931 0.0 0.0 85456 11776 ? SL 12:25 0:00 sbd: watcher: /dev/disk/by-id/scsi-36001405b8dddd44eb3647908def6621c - slot: 0 - uuid: 986ed8f8-947d-4396-8aec-b933b75e904c
root 1932 0.0 0.0 90524 16656 ? SL 12:25 0:00 sbd: watcher: Pacemaker
root 1933 0.0 0.0 102708 28260 ? SL 12:25 0:00 sbd: watcher: Cluster
root 13877 0.0 0.0 9292 1572 pts/0 S+ 12:27 0:00 grep sbd
hn1-db-0:~ # kill -9 1912
Der Clusterknoten „hn1-db-0“ sollte neu gestartet werden. Der Pacemaker-Dienst wird anschließend möglicherweise nicht gestartet. Stellen Sie sicher, dass er neu gestartet wird.
Testen eines manuellen Failovers
Sie können ein manuelles Failover durch Beenden des pacemaker-Diensts auf Knoten „hn1-db-0“ testen:
service pacemaker stop
Nach dem Failover können Sie den Dienst erneut starten. Wenn Sie AUTOMATED_REGISTER="false" festlegen, wird die SAP HANA-Ressource auf dem Knoten „hn1-db-0“ nicht als sekundär gestartet. In diesem Fall konfigurieren Sie die HANA-Instanz als sekundär, indem Sie diesen Befehl ausführen:
service pacemaker start
su - hn1adm
# Stop the HANA instance just in case it is running
sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1
# Switch back to root and clean up the failed state
exit
crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0
SUSE-Tests
Wichtig
Stellen Sie sicher, dass das von Ihnen ausgewählte Betriebssystem SAP-zertifiziert ist für SAP HANA auf den spezifischen VM-Typen, die Sie verwenden. Die Liste der SAP HANA-zertifizierten VM-Typen und BS-Releases für diese kann unter Zertifizierte SAP HANA-IaaS-Plattformen nachgeschlagen werden. Stellen Sie sicher, dass Sie in die Details des jeweils aufgeführten VM-Typs klicken, um die vollständige Liste der von SAP HANA unterstützten BS-Releases für den spezifischen VM-Typ anzuzeigen.
Führen Sie abhängig von Ihrem Anwendungsfall alle Testfälle aus, die im Szenario zur leistungsoptimierten SAP HANA-Systemreplikation oder zur kostenoptimierten SAP HANA-Systemreplikation aufgeführt werden. Sie finden diese Anleitungen auf der Seite SLES for SAP – Best Practices.
Die folgenden Tests sind eine Kopie der Testbeschreibungen aus der Anleitung zum Szenario für die leistungsoptimierte SAP HANA-Systemreplikation unter SUSE Linux Enterprise Server for SAP Applications 12 SP1. Eine aktuelle Version finden Sie stets in der Anleitung selbst. Stellen Sie immer sicher, dass HANA synchron ist, bevor Sie den Test starten, und dass die Pacemaker-Konfiguration korrekt ist.
In den folgenden Testbeschreibungen wird davon ausgegangen, dass PREFER_SITE_TAKEOVER="true" und AUTOMATED_REGISTER="false" gelten. HINWEIS: Die folgenden Tests sind darauf ausgelegt, nacheinander ausgeführt zu werden. Sie hängen vom Endzustand der vorherigen Tests ab.
TEST 1: BEENDEN DER PRIMÄREN DATENBANK AUF KNOTEN 1
Zustand der Ressource vor dem Starten des Tests:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0Führen Sie die folgenden Befehle als „<hanasid>adm“ auf dem Knoten „hn1-db-0“ aus:
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB stopPacemaker sollte die beendete HANA-Instanz erkennen und ein Failover auf den anderen Knoten ausführen. Nach Abschluss des Failovers wird die HANA-Instanz auf Knoten „hn1-db-0“ beendet, da Pacemaker den Knoten nicht automatisch als sekundären HANA-Knoten registriert.
Führen Sie die folgenden Befehle aus, um den Knoten „hn1-db-0“ als sekundär zu registrieren und die fehlerhafte Ressource zu bereinigen.
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1 # run as root hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0Zustand der Ressource nach dem Test:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1TEST 2: BEENDEN DER PRIMÄREN DATENBANK AUF KNOTEN 2
Zustand der Ressource vor dem Starten des Tests:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1Führen Sie die folgenden Befehle als „<hanasid>adm“ auf dem Knoten „hn1-db-1“ aus:
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB stopPacemaker sollte die beendete HANA-Instanz erkennen und ein Failover auf den anderen Knoten ausführen. Nach Abschluss des Failovers wird die HANA-Instanz auf dem Knoten „hn1-db-1“ beendet, da Pacemaker den Knoten nicht automatisch als sekundären HANA-Knoten registriert.
Führen Sie die folgenden Befehle aus, um den Knoten „hn1-db-1“ als sekundär zu registrieren und die fehlerhafte Ressource zu bereinigen.
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 # run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1Zustand der Ressource nach dem Test:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0TEST 3: ABSTURZ DER PRIMÄREN DATENBANK AUF KNOTEN 1
Zustand der Ressource vor dem Starten des Tests:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0Führen Sie die folgenden Befehle als „<hanasid>adm“ auf dem Knoten „hn1-db-0“ aus:
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB kill-9Pacemaker sollte die beendete HANA-Instanz erkennen und ein Failover auf den anderen Knoten ausführen. Nach Abschluss des Failovers wird die HANA-Instanz auf Knoten „hn1-db-0“ beendet, da Pacemaker den Knoten nicht automatisch als sekundären HANA-Knoten registriert.
Führen Sie die folgenden Befehle aus, um den Knoten „hn1-db-0“ als sekundär zu registrieren und die fehlerhafte Ressource zu bereinigen.
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1 # run as root hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0Zustand der Ressource nach dem Test:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1TEST 4: ABSTURZ DER PRIMÄREN DATENBANK AUF KNOTEN 2
Zustand der Ressource vor dem Starten des Tests:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1Führen Sie die folgenden Befehle als „<hanasid>adm“ auf dem Knoten „hn1-db-1“ aus:
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9Pacemaker sollte die beendete HANA-Instanz erkennen und ein Failover auf den anderen Knoten ausführen. Nach Abschluss des Failovers wird die HANA-Instanz auf dem Knoten „hn1-db-1“ beendet, da Pacemaker den Knoten nicht automatisch als sekundären HANA-Knoten registriert.
Führen Sie die folgenden Befehle aus, um den Knoten „hn1-db-1“ als sekundär zu registrieren und die fehlerhafte Ressource zu bereinigen.
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 # run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1Zustand der Ressource nach dem Test:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0TEST 5: ABSTURZ DES KNOTENS AM PRIMÄREN STANDORT (KNOTEN 1)
Zustand der Ressource vor dem Starten des Tests:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0Führen Sie die folgenden Befehle als root auf dem Knoten „hn1-db-0“ aus:
hn1-db-0:~ # echo 'b' > /proc/sysrq-triggerPacemaker sollte den beendeten Clusterknoten erkennen und den Knoten umgrenzen. Nachdem der Knoten umgrenzt wurde, löst Pacemaker eine Übernahme der HANA-Instanz aus. Bei einem Neustart des umgrenzten Knotens wird Pacemaker nicht automatisch gestartet.
Führen Sie die folgenden Befehle aus, um Pacemaker zu starten, die SBD-Nachrichten für den Knoten „hn1-db-0“ zu bereinigen, den Knoten „hn1-db-0“ als sekundär zu registrieren und die fehlerhafte Ressource zu bereinigen.
# run as root # list the SBD device(s) hn1-db-0:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE= # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3" hn1-db-0:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-0 clear hn1-db-0:~ # systemctl start pacemaker # run as <hanasid>adm hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1 # run as root hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0Zustand der Ressource nach dem Test:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1TEST 6: ABSTURZ DES KNOTENS AM SEKUNDÄREN STANDORT (KNOTEN 2)
Zustand der Ressource vor dem Starten des Tests:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-1 ] Slaves: [ hn1-db-0 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1Führen Sie die folgenden Befehle als root auf dem Knoten „hn1-db-1“ aus:
hn1-db-1:~ # echo 'b' > /proc/sysrq-triggerPacemaker sollte den beendeten Clusterknoten erkennen und den Knoten umgrenzen. Nachdem der Knoten umgrenzt wurde, löst Pacemaker eine Übernahme der HANA-Instanz aus. Bei einem Neustart des umgrenzten Knotens wird Pacemaker nicht automatisch gestartet.
Führen Sie die folgenden Befehle aus, um Pacemaker zu starten, die SBD-Nachrichten für den Knoten „hn1-db-1“ zu bereinigen, den Knoten „hn1-db-1“ als sekundär zu registrieren und die fehlerhafte Ressource zu bereinigen.
# run as root # list the SBD device(s) hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE= # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3" hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear hn1-db-1:~ # systemctl start pacemaker # run as <hanasid>adm hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 # run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1Zustand der Ressource nach dem Test:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0TEST 7: BEENDEN DER SEKUNDÄREN DATENBANK AUF KNOTEN 2
Zustand der Ressource vor dem Starten des Tests:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0Führen Sie die folgenden Befehle als „<hanasid>adm“ auf dem Knoten „hn1-db-1“ aus:
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB stopPacemaker erkennt die beendete HANA-Instanz und kennzeichnet die Ressource auf dem Knoten „hn1-db-1“ als fehlerhaft. Pacemaker sollte die HANA-Instanz automatisch neu starten. Führen Sie zum Bereinigen des fehlerhaften Zustands den folgenden Befehl aus:
# run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1Zustand der Ressource nach dem Test:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0TEST 8: ABSTURZ DER SEKUNDÄREN DATENBANK AUF KNOTEN 2
Zustand der Ressource vor dem Starten des Tests:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0Führen Sie die folgenden Befehle als „<hanasid>adm“ auf dem Knoten „hn1-db-1“ aus:
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9Pacemaker erkennt die beendete HANA-Instanz und kennzeichnet die Ressource auf dem Knoten „hn1-db-1“ als fehlerhaft. Führen Sie zum Bereinigen des fehlerhaften Zustands den folgenden Befehl aus: Pacemaker sollte die HANA-Instanz dann automatisch neu starten.
# run as root hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1Zustand der Ressource nach dem Test:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0TEST 9: ABSTURZ DES KNOTENS AM SEKUNDÄREN STANDORT (KNOTEN 2), AUF DEM DIE SEKUNDÄRE HANA-DATENBANK AUSGEFÜHRT WIRD
Zustand der Ressource vor dem Starten des Tests:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0Führen Sie die folgenden Befehle als root auf dem Knoten „hn1-db-1“ aus:
hn1-db-1:~ # echo b > /proc/sysrq-triggerPacemaker sollte den beendeten Clusterknoten erkennen und den Knoten umgrenzen. Bei einem Neustart des umgrenzten Knotens wird Pacemaker nicht automatisch gestartet.
Führen Sie die folgenden Befehle aus, um Pacemaker zu starten und die SBD-Nachrichten für den Knoten „hn1-db-1“ sowie die fehlerhafte Ressource zu bereinigen.
# run as root # list the SBD device(s) hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE= # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3" hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear hn1-db-1:~ # systemctl start pacemaker hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1Zustand der Ressource nach dem Test:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03] Started: [ hn1-db-0 hn1-db-1 ] Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] Masters: [ hn1-db-0 ] Slaves: [ hn1-db-1 ] Resource Group: g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0 rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0