Diese Seite wurde von der Cloud Translation API übersetzt.

Konfigurationsanleitung für Hochverfügbarkeitscluster für SAP MaxDB unter RHEL

In dieser Anleitung erfahren Sie, wie Sie ein SAP MaxDB-System in einem Red Hat Enterprise Linux (RHEL)-Hochverfügbarkeitscluster in Google Cloudmit einer aktiven/passiven Clusterkonfiguration bereitstellen.

Informationen zum Bereitstellen eines SAP MaxDB-Systems mit einem einzelnen Knoten unter Linux finden Sie im SAP MaxDB-Bereitstellungsleitfaden.

Diese Anleitung richtet sich an fortgeschrittene SAP MaxDB-Nutzer, die mit Linux-Hochverfügbarkeitskonfigurationen für SAP-Systeme vertraut sind.

System, das in dieser Anleitung bereitgestellt wird

Die Anleitung umfasst folgende Schritte:

Internen Passthrough-Network-Load-Balancer konfigurieren, um Traffic bei einem Ausfall umzuleiten
Pacemaker-Cluster unter RHEL konfigurieren, um die SAP-Systeme und andere Ressourcen während eines Failovers zu verwalten

Der bereitgestellte Cluster enthält die folgenden Funktionen und Features:

Zwei Compute Engine-VMs in verschiedenen Zonen, auf denen eine Instanz von SAP MaxDB ausgeführt werden kann
Ein regionaler nichtflüchtiger Speicher für die Installation von SAP MaxDB.
Hochverfügbarkeitsclusterressourcen-Manager von Pacemaker
STONITH-Fencing-Mechanismus

Eine Hochverfügbarkeitsinstallation von SAP NetWeaver wird in dieser Anleitung nicht behandelt.

Vorbereitung

Vor dem Erstellen eines SAP MaxDB-Hochverfügbarkeitsclusters sind die folgenden Voraussetzungen zu erfüllen:

Sie haben den Planungsleitfaden für SAP MaxDB gelesen.
Sie haben ein Red Hat-Abo.
Sie oder Ihre Organisation haben ein Google Cloud -Konto und Sie haben ein Projekt für die SAP MaxDB-Bereitstellung erstellt.
Wenn Ihre SAP-Arbeitslast die Anforderungen an den Datenstandort, die Zugriffssteuerung oder die Supportmitarbeiter oder gesetzliche Anforderungen erfüllen muss, müssen Sie den erforderlichen Assured Workloads-Ordner erstellen. Weitere Informationen finden Sie unter Compliance und Steuerung der Datenhoheit für SAP in Google Cloud.
Wenn OS Login in den Projektmetadaten aktiviert ist, müssen Sie OS Login vorübergehend deaktivieren, bis die Bereitstellung abgeschlossen ist. Für die Bereitstellung konfiguriert dieses Verfahren SSH-Schlüssel in Instanzmetadaten. Bei aktiviertem OS Login sind metadatenbasierte SSH-Schlüsselkonfigurationen deaktiviert und diese Bereitstellung schlägt fehl. Nach Abschluss der Bereitstellung können Sie die OS Login-Funktion wieder aktivieren.

Weitere Informationen finden Sie unter:
- OS Login aktivieren oder deaktivieren
- SSH-Schlüssel zu VMs hinzufügen, die metadatenbasierte SSH-Schlüssel verwenden

Netzwerk erstellen

Erstellen Sie aus Sicherheitsgründen ein neues Netzwerk. Durch das Festlegen von Firewallregeln oder die Nutzung eines anderen Verfahrens der Zugriffskontrolle steuern Sie, wer Zugriff hat.

Wenn Ihr Projekt ein Standard-VPC-Netzwerk (Virtual Private Cloud) hat, verwenden Sie es nicht. Erstellen Sie stattdessen Ihr eigenes VPC-Netzwerk, sodass nur die von Ihnen explizit formulierten Firewallregeln gelten.

Während der Bereitstellung müssen VM-Instanzen normalerweise auf das Internet zugreifen können, um den Agenten für SAP von Google Cloudherunterzuladen. Wenn Sie eines der von SAP zertifizierten Linux-Images verwenden, die in Google Cloudverfügbar sind, benötigen die VM-Instanzen außerdem einen Internetzugang, um die Lizenz zu registrieren und auf Repositories von Betriebssystemanbietern zuzugreifen. Eine Konfiguration mit einem NAT-Gateway und VM-Netzwerk-Tags unterstützt diesen Zugriff selbst dann, wenn die Ziel-VMs keine externen IP-Adressen haben.

So richten Sie das Netzwerk ein:

Console

Rufen Sie in der Google Cloud -Konsole die Seite VPC-Netzwerke auf.
Zur Seite VPC-Netzwerke
Klicken Sie auf VPC-Netzwerk erstellen.
Geben Sie einen Namen für das Netzwerk ein.
Der Name muss der Namenskonvention entsprechen. VPC-Netzwerke verwenden die Namenskonvention von Compute Engine.
Wählen Sie unter Modus für Subnetzerstellung die Option Benutzerdefiniert aus.
Legen Sie im Abschnitt Neues Subnetz folgende Konfigurationsparameter für das Subnetz fest:
1. Geben Sie einen Namen für das Subnetz ein.
2. Wählen Sie unter Region die Compute Engine-Region aus, in der Sie das Subnetz erstellen möchten.
3. Wählen Sie für IP-Stack-Typ die Option IPv4 (einzelner Stack) aus und geben Sie dann einen IP-Adressbereich im CIDR-Format ein, z. B. 10.1.0.0/24.
  Dies ist der primäre IPv4-Bereich für das Subnetz. Wenn Sie mehrere Subnetze erstellen möchten, weisen Sie den Subnetzen im Netzwerk nicht überlappende CIDR-IP-Adressbereiche zu. Beachten Sie, dass jedes Subnetz und seine internen IP-Adressbereiche einer einzelnen Region zugeordnet sind.
4. Klicken Sie auf Fertig.
Klicken Sie auf Subnetz hinzufügen und wiederholen Sie die vorherigen Schritte, um weitere Subnetze zu erstellen. Sie können dem Netzwerk weitere Subnetze hinzufügen, nachdem Sie das Netzwerk erstellt haben.
Klicken Sie auf Erstellen.

gcloud

Rufen Sie Cloud Shell auf.
Zu Cloud Shell
Führen Sie den folgenden Befehl aus, um ein neues Netzwerk im benutzerdefinierten Subnetzwerkmodus zu erstellen:
```
gcloud compute networks create NETWORK_NAME --subnet-mode custom
```
Ersetzen Sie NETWORK_NAME durch den Namen des neuen Clusters. Der Name muss der Namenskonvention entsprechen. VPC-Netzwerke verwenden die Namenskonvention von Compute Engine.

Geben Sie --subnet-mode custom an und deaktivieren Sie so den standardmäßigen automatischen Modus. Ansonsten würde durch diesen Modus automatisch in jeder Compute Engine-Region ein Subnetz erstellt werden. Weitere Informationen dazu finden Sie unter Modus für Subnetzerstellung.
Erstellen Sie ein Subnetzwerk und geben Sie die Region und den IP-Adressbereich an:
```
gcloud compute networks subnets create SUBNETWORK_NAME \
    --network NETWORK_NAME --region REGION --range RANGE
```
Dabei gilt:
- SUBNETWORK_NAME: der Name des neuen Subnetzwerks.
- NETWORK_NAME: der Name des Netzwerks, das Sie im vorherigen Schritt erstellt haben.
- REGION: die Region, in der sich das Subnetzwerk befinden soll
- RANGE: der im CIDR-Format angegebene IP-Adressbereich, z. B. 10.1.0.0/24
  Wenn Sie mehrere Subnetzwerke hinzufügen möchten, weisen Sie den Subnetzwerken im Netzwerk nicht überlappende CIDR-IP-Adressbereiche zu. Beachten Sie, dass jedes Subnetzwerk und seine internen IP-Adressbereiche einer einzelnen Region zugeordnet sind.
Wiederholen Sie den vorherigen Schritt, falls Sie weitere Subnetze erstellen möchten.

NAT-Gateway einrichten

Wenn Sie eine oder mehrere VMs ohne öffentliche IP-Adressen erstellen müssen, müssen Sie die Network Address Translation (NAT) verwenden, damit die VMs auf das Internet zugreifen können. Verwenden Sie Cloud NAT, einen verteilten, softwarebasierten verwalteten Dienst von Google Cloud , der es VMs ermöglicht, ausgehende Pakete an das Internet zu senden und entsprechende eingehende Antwortpakete zu empfangen. Alternativ können Sie eine separate VM als NAT-Gateway einrichten.

Informationen zum Erstellen einer Cloud NAT-Instanz für Ihr Projekt finden Sie unter Cloud NAT verwenden.

Nachdem Sie Cloud NAT für Ihr Projekt konfiguriert haben, können Ihre VM-Instanzen ohne öffentliche IP-Adressen sicher auf das Internet zugreifen.

Firewallregeln hinzufügen

Standardmäßig verhindert eine implizite Firewallregel eingehende Verbindungen von außerhalb Ihres VPC-Netzwerks. Wenn Sie eingehende Verbindungen zulassen möchten, richten Sie für Ihre VM eine entsprechende Firewallregel ein. Wenn eine eingehende Verbindung zu einer VM hergestellt wurde, ist Traffic über diese Verbindung in beide Richtungen zulässig.

Sie können auch eine Firewallregel erstellen, um externen Zugriff auf bestimmte Ports zuzulassen oder Zugriff zwischen VMs im selben Netzwerk einzuschränken. Wenn der VPC-Netzwerktyp default verwendet wird, gelten auch einige zusätzliche Standardregeln. So etwa die Regel default-allow-internal, die den Zugriff zwischen VMs im selben Netzwerk an allen Ports erlaubt.

Abhängig von der für Ihre Umgebung geltenden IT-Richtlinie müssen Sie möglicherweise die Konnektivität zu Ihrem Datenbankhost isolieren oder anderweitig einschränken. Dazu erstellen Sie Firewallregeln.

Je nach Szenario können Sie Firewallregeln erstellen, die den Zugriff für Folgendes erlauben:

SAP-Standardports, die unter TCP/IP-Ports aller SAP-Produkte aufgeführt sind.
Verbindungen von Ihrem Computer oder dem Unternehmensnetzwerk aus zu Ihrer Compute Engine-VM-Instanz. Wenn Sie sich nicht sicher sind, welche IP-Adresse Sie verwenden sollen, wenden Sie sich an den Netzwerkadministrator Ihres Unternehmens.

So erstellen Sie eine Firewallregel:

Console

Rufen Sie in der Google Cloud Console die Seite Compute Engine-Firewall auf.

Zur Firewall
Klicken Sie oben auf der Seite auf Firewallregel erstellen.
- Wählen Sie im Feld Netzwerk das Netzwerk aus, in dem sich die VM befindet.
- Geben Sie im Feld Ziele die Ressourcen in Google Cloudan, für die diese Regel gelten soll. Geben Sie beispielsweise Alle Instanzen im Netzwerk an. Sie können unter Angegebene Ziel-Tags auch Tags eingeben, um die Regel auf bestimmte Instanzen in Google Cloudzu beschränken.
- Wählen Sie im Feld Quellfilter eine der folgenden Optionen aus:
  - IP-Bereiche, um eingehenden Traffic von bestimmten IP-Adressen zuzulassen. Geben Sie den IP-Adressbereich im Feld Quell-IP-Bereiche an.
  - Subnetze, um eingehenden Traffic von einem bestimmten Subnetz zuzulassen. Geben Sie den Namen des Subnetzwerks im folgenden Feld Subnetze an. Mit dieser Option können Sie den Zugriff zwischen den VMs in einer dreistufigen oder einer horizontal skalierbaren Konfiguration zulassen.
- Wählen Sie im Bereich Protokolle und Ports die Option Angegebene Protokolle und Ports aus und geben Sie tcp:PORT_NUMBER ein.
Klicken Sie auf Erstellen, um die Firewallregel anzulegen.

gcloud

Erstellen Sie mit dem folgenden Befehl eine Firewallregel:

$ gcloud compute firewall-rules create firewall-name
--direction=INGRESS --priority=1000 \
--network=network-name --action=ALLOW --rules=protocol:port \
--source-ranges ip-range --target-tags=network-tags

VMs bereitstellen und MaxDB installieren

Bevor Sie mit der Konfiguration des Hochverfügbarkeitsclusters beginnen, müssen Sie die VM-Instanzen und die SAP MaxDB-Systeme definieren und bereitstellen, die als primäre und sekundäre Knoten in Ihrem Hochverfügbarkeitscluster dienen.

VM für die MaxDB-Bereitstellung erstellen

Im Rahmen der HA-Bereitstellung müssen zwei Google Cloud Compute Engine-VMs erstellt werden. Weitere Informationen finden Sie im Leitfaden Compute Engine-Instanz erstellen und starten.

Hinweis: Regionale nichtflüchtige Speicher werden nur für die Maschinentypen E2, N1, N2 und N2D unterstützt. Weitere Informationen finden Sie im Leitfaden zu regionalen nichtflüchtigen Speichern.

Weitere Informationen zur Auswahl des richtigen Maschinentyps finden Sie im SAP-Hinweis 2456432 – SAP-Anwendungen in Google Cloud: Unterstützte Produkte und Google Cloud Maschinentypen.

Erstellen Sie die beiden VMs in separaten Zonen, um eine zonale Ausfallsicherheit zu erreichen. Dabei gelten die folgenden Mindestanforderungen:

VM-Details:
- Instance Name
- Zone – Ihre bevorzugte Zone
- Machine Type – basierend auf der Größe
- Subnet: Name des Subnetzes, das für diese Region erstellt wurde
Dienstkonto mit mindestens Zugriff auf die folgenden APIs:
- https://www.googleapis.com/auth/compute
- https://www.googleapis.com/auth/servicecontrol
- https://www.googleapis.com/auth/service.management.readonly
- https://www.googleapis.com/auth/logging.write
- https://www.googleapis.com/auth/monitoring.write
- https://www.googleapis.com/auth/trace.append
- https://www.googleapis.com/auth/devstorage.read_write
Zusätzliches Laufwerk auf jeder VM mit mindestens 20 GB für /usr/sap

Ein einzelnes regionales Laufwerk für SAP MaxDB erstellen

Für diese Bereitstellung wird ein regionales Laufwerk verwendet, um die MaxDB-Dateien im Verzeichnis /sapdb zu speichern.

Erstellen Sie das Laufwerk. Achten Sie darauf, dass die Replikationszonen für das regionale Laufwerk mit den Zonen übereinstimmen, in denen Sie die beiden VMs erstellt haben.

Hängen Sie den regionalen Datenträger an eine der VMs an, auf der Sie die MaxDB-Installation und die Konfigurationsaufgaben ausführen.

RHEL-Betriebssystem für die SAP-Installation vorbereiten

Für das SAP-Produkt müssen bestimmte Betriebssystemeinstellungen und -pakete installiert sein. Folgen Sie der Anleitung im SAP-Hinweis 2772999 – Red Hat Enterprise Linux 8.x: Installation und Konfiguration .

Diese Aufgabe muss auf beiden Knoten ausgeführt werden.

Dateisysteme erstellen

Stellen Sie über SSH eine Verbindung zu beiden Instanzen her und erstellen Sie die Bereitstellungspunkte /usr/sap/SID und /sapdb.
```
# sudo mkdir -p /usr/sap/SID
# sudo mkdir -p /sapdb
```
Erstellen Sie die Dateisysteme auf den beiden zusätzlichen Laufwerken, die mit den VMs verbunden sind, mit mkfs.

Derzeit wird das regionale Laufwerk nur an eine der VMs angehängt. Das /sapdb-Dateisystem wird daher nur einmal erstellt.
Bearbeiten Sie die Datei /etc/fstab, damit /usr/sap/SID beim Neustart immer auf beiden Knoten bereitgestellt wird.
Stellen Sie das Dateisystem /sapdb manuell auf dem Knoten bereit, auf dem Sie die MaxDB-Installation ausführen.

Weitere Informationen zum Erstellen und Bereitstellen von Dateisystemen finden Sie im Leitfaden Nicht-Bootlaufwerk auf einer Linux-VM formatieren und bereitstellen.

LVM-Konfiguration ändern

Sie müssen die LVM-Konfiguration (Logical Volume Management) so ändern, dass die freigegebene Volume-Gruppe (VG) immer nur an einen Knoten angehängt und von diesem zugänglich ist.

Führen Sie dazu die folgenden Schritte auf beiden Knoten aus:

Bearbeiten Sie als Root die Datei /etc/lvm/lvm.conf und ändern Sie den Wert system_id_source von none in uname.

Prüfen Sie die Ergebnisse:

# grep -i system_id_source /etc/lvm/lvm.conf

Die Ausgabe sollte in etwa so aussehen:

# Configuration option global/system_id_source.
        system_id_source = "uname"

Um zu verhindern, dass die VMs clusterverwaltete VGs aktivieren, wenn ein Knoten neu gestartet wird, müssen Sie außerdem den folgenden Parameter in der Konfigurationsdatei /etc/lvm/lvm.conf mit kommagetrennten vollständigen VG-Namen pflegen, die nicht vom Cluster verwaltet werden.

Hinweis: Standardmäßig ist in dieser Datei kein Wert festgelegt. Sie müssen daher zum Abschnitt zur Verwendung des Parameters auto_activation_volume_list gehen und ihn manuell hinzufügen.

Beispiel: usrsap ist der Name einer VG, die nicht vom Cluster verwaltet wird:
```
auto_activation_volume_list = [ usrsap ]
```
Wenn es beispielsweise keine VGs gibt, die nicht vom Cluster verwaltet werden, muss dieser Parameter mit leeren Werten hinzugefügt werden:
```
auto_activation_volume_list = [  ]
```

Datenbank und SAP-Host-Agent installieren

Nachdem das Betriebssystem konfiguriert wurde, können Sie nun die SAP MaxDB-Datenbank und den SAP-Host-Agent installieren. MaxDB wird normalerweise zusammen mit dem SAP-Produkt, in dem es enthalten ist, installiert.

Die Installation wird nur einmal durchgeführt, nämlich auf der Instanz, an die Sie den regionalen nichtflüchtigen Speicher angehängt haben.

So installieren Sie SAP MaxDB auf Ihrer VM:

Stellen Sie eine SSH-Verbindung zu Ihrer Linux-basierten VM her.
Laden Sie den SAP Software Provisioning Manager (SWPM), das Installationsmedium des SAP-Produkts und das MaxDB-Installationsmedium entsprechend den SAP-Installationsanleitungen herunter.
Installieren Sie das SAP-Produkt und die SAP MaxDB-Datenbank entsprechend der Installationsanleitungen für Ihr SAP-Produkt. Weitere Informationen finden Sie in der Dokumentation zu SAP MaxDB.

Weitere Informationen von SAP zur Installation finden Sie im SAP-Hinweis 1020175 – FAQ: SAP MaxDB-Installation, Upgrade oder Anwendung eines Patches.

Führen Sie nach Abschluss der Installation die folgenden Prüfungen aus:

Prüfen Sie als sidadm-Nutzer den Status von MaxDB.

# dbmcli -d  SID -u control,password db_state

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

>dbmcli -d  MDB -u control, my_p4$$w0rd db_state
OK
State
ONLINE

Prüfen Sie auch den Status von x_server:

# x_server

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

>x_server
2024-10-23 19:01:43 11968 19744 INF  12916          Found running XServer on port 7200
2024-10-23 19:01:43 11968 19744 INF  13011            version 'U64/LIX86 7.9.10   Build 004-123-265-969'
2024-10-23 19:01:43 11968 19744 INF  13010            installation MDB  - path: /sapdb/MDB/db
2024-10-23 19:01:45 11971 13344 INF  12916          Found running sdbgloballistener on port 7210
2024-10-23 19:01:45 11971 13344 INF  13011            version 'U64/LIX86 7.9.10   Build 004-123-265-969'

Prüfen, ob der SAP-Host-Agent ausgeführt wird:

# ps -ef | grep -i hostctrl

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

>ps -ef | grep -i hostctrl
root      1543     1  0 Oct18 ?        00:00:15 /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile
sapadm    1550     1  0 Oct18 ?        00:03:00 /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/hostctrl/exe/host_profile -D
root      1618     1  0 Oct18 ?        00:03:48 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/exe/host_profile
mdbadm   12751 11261  0 19:03 pts/0    00:00:00 grep --color=auto -i hostctrl

Beenden Sie nach der Überprüfung die MaxDB-Instanz und den x_server.

# dbmcli -d SID -u control, and password db_offline
# x_server stop

Aufgaben nach der Installation ausführen

Bevor Sie Ihre SAP MaxDB-Instanz verwenden, sollten Sie nach der Bereitstellung diese Schritte ausführen:

Aktualisieren Sie die SAP MaxDB-Software mit den neuesten Patches, falls verfügbar.
Installieren Sie alle zusätzlichen Komponenten.
Konfigurieren Sie die neue SAP MaxDB-Datenbank und sichern Sie sie.

Weitere Informationen finden Sie unter Datenbankverwaltung für SAP MaxDB.

Nachdem die SAP MaxDB-Systeme erfolgreich bereitgestellt wurden, definieren und konfigurieren Sie den Hochverfügbarkeitscluster.

Failover-Unterstützung für Cloud Load Balancing konfigurieren

Der interne Passthrough-Network-Load-Balancer-Dienst mit Failover-Unterstützung leitet den Traffic basierend auf einem Systemdiagnosedienst an den aktiven Host in einem SAP MaxDB-Cluster weiter.

IP-Adresse für die virtuelle IP-Adresse reservieren

Die virtuelle IP-Adresse (VIP), die manchmal auch als Floating-IP-Adresse bezeichnet wird, folgt dem aktiven SAP MaxDB-System. Der Load Balancer leitet den an die VIP gesendeten Traffic an die VM weiter, die das aktive SAP MaxDB-System hostet.

Öffnen Sie Cloud Shell:

Zu Cloud Shell
IP-Adresse für die virtuelle IP-Adresse reservieren. Dies ist die IP-Adresse, mit der Anwendungen auf SAP MaxDB zugreifen. Wenn Sie das Flag --addresses weglassen, wird im angegebenen Subnetz automatisch eine IP-Adresse ausgewählt:
```
$ gcloud compute addresses create VIP_NAME \
  --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
  --addresses VIP_ADDRESS
```
Weitere Informationen zum Reservieren einer statischen IP-Adresse finden Sie unter Statische interne IP-Adresse reservieren.

Bestätigen Sie die Reservierung der IP-Adresse:

$ gcloud compute addresses describe VIP_NAME \
  --region CLUSTER_REGION

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

address: 10.0.0.19
addressType: INTERNAL
creationTimestamp: '2024-10-23T14:19:03.109-07:00'
description: ''
id: '8961491304398200872'
kind: compute#address
name: vip-for-maxdb-ha
networkTier: PREMIUM
purpose: GCE_ENDPOINT
region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/vip-for-maxdb-ha
status: RESERVED
subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1

Instanzgruppen für Host-VMs erstellen

Erstellen Sie in Cloud Shell zwei nicht verwaltete Instanzgruppen und weisen Sie die primäre Host-VM der einen und die sekundäre Host-VM der anderen zu:

$ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
  --zone=PRIMARY_ZONE
$ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
  --zone=PRIMARY_ZONE \
  --instances=PRIMARY_HOST_NAME
$ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
  --zone=SECONDARY_ZONE
$ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
  --zone=SECONDARY_ZONE \
  --instances=SECONDARY_HOST_NAME

Bestätigen Sie die Erstellung der Instanzgruppen:

$ gcloud compute instance-groups unmanaged list

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

NAME          ZONE           NETWORK          NETWORK_PROJECT        MANAGED  INSTANCES
maxdb-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
maxdb-ha-ig-2  us-central1-c  example-network  example-project-123456 No       1

Compute Engine-Systemdiagnose erstellen

Erstellen Sie die Systemdiagnose in Cloud Shell: Wählen Sie für die Systemdiagnose einen Port aus dem privaten Bereich 49152-65535 aus, um Konflikte mit anderen Diensten zu vermeiden. Die Werte für Prüfintervall und Zeitlimit sind etwas länger als die Standardwerte, um die Failover-Toleranz während Compute Engine-Live-Migrationsereignissen zu erhöhen. Sie können die Werte bei Bedarf anpassen:
```
$ gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \
  --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
  --healthy-threshold=2
```

Bestätigen Sie die Erstellung der Systemdiagnose:

$ gcloud compute health-checks describe HEALTH_CHECK_NAME

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

checkIntervalSec: 10
creationTimestamp: '2023-10-23T21:03:06.924-07:00'
healthyThreshold: 2
id: '4963070308818371477'
kind: compute#healthCheck
name: maxdb-health-check
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/maxdb-health-check
tcpHealthCheck:
 port: 60000
 portSpecification: USE_FIXED_PORT
 proxyHeader: NONE
timeoutSec: 10
type: TCP
unhealthyThreshold: 2

Firewallregel für die Systemdiagnosen erstellen

Definieren Sie eine Firewallregel für einen Port im privaten Bereich, die den Zugriff auf Ihre Host-VMs aus den IP-Bereichen ermöglicht, die von Compute Engine-Systemdiagnosen verwendet werden: 35.191.0.0/16 und 130.211.0.0/22. Weitere Informationen finden Sie unter Firewallregeln für Systemdiagnosen erstellen.

Fügen Sie Ihren Host-VMs ein Netzwerk-Tag hinzu, falls noch keines vorhanden ist. Dieses Netzwerk-Tag wird von der Firewallregel für Systemdiagnosen verwendet.

$ gcloud compute instances add-tags PRIMARY_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone PRIMARY_ZONE
$ gcloud compute instances add-tags SECONDARY_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone SECONDARY_ZONE

Wenn Sie noch keine haben, erstellen Sie eine Firewallregel, um die Systemdiagnosen zuzulassen:

$ gcloud compute firewall-rules create RULE_NAME \
  --network NETWORK_NAME \
  --action ALLOW \
  --direction INGRESS \
  --source-ranges 35.191.0.0/16,130.211.0.0/22 \
  --target-tags NETWORK_TAGS \
  --rules tcp:HLTH_CHK_PORT_NUM

Beispiel:

gcloud compute firewall-rules create  fw-allow-health-checks \
--network example-network \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags cluster-ntwk-tag \
--rules tcp:60000

Load-Balancer und Failover-Gruppe konfigurieren

Erstellen Sie den Back-End-Dienst des Load-Balancers:

$ gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --load-balancing-scheme internal \
  --health-checks HEALTH_CHECK_NAME \
  --no-connection-drain-on-failover \
  --drop-traffic-if-unhealthy \
  --failover-ratio 1.0 \
  --region CLUSTER_REGION \
  --global-health-checks

Fügen Sie die primäre Instanzgruppe dem Back-End-Dienst hinzu:

$ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group PRIMARY_IG_NAME \
  --instance-group-zone PRIMARY_ZONE \
  --region CLUSTER_REGION

Fügen Sie die sekundäre Failover-Instanzgruppe dem Back-End-Dienst hinzu:

$ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group SECONDARY_IG_NAME \
  --instance-group-zone SECONDARY_ZONE \
  --failover \
  --region CLUSTER_REGION

Erstellen Sie eine Weiterleitungsregel. Geben Sie darin die IP-Adresse an, die Sie für die VIP reserviert haben: Wenn Sie von außerhalb der unten angegebenen Region auf das SAP MaxDB-System zugreifen müssen, fügen Sie das Flag --allow-global-access in die Definition ein:
```
$ gcloud compute forwarding-rules create RULE_NAME \
  --load-balancing-scheme internal \
  --address VIP_ADDRESS \
  --subnet CLUSTER_SUBNET \
  --region CLUSTER_REGION \
  --backend-service BACKEND_SERVICE_NAME \
  --ports ALL
```
Weitere Informationen zum regionenübergreifenden Zugriff auf Ihr SAP MaxDB-Hochverfügbarkeitssystem finden Sie unter Internes TCP/UDP-Load Balancing.

Konfiguration des Load-Balancers testen

Auch wenn Ihre Back-End-Instanzgruppen erst später als fehlerfrei registriert werden, können Sie die Konfiguration des Load-Balancers testen. Richten Sie dazu einen Listener ein, der auf die Systemdiagnosen reagiert. Wenn der Load-Balancer nach der Einrichtung eines Listeners korrekt konfiguriert ist, ändert sich der Status der Back-End-Instanzgruppen in "fehlerfrei".

In den folgenden Abschnitten werden verschiedene Methoden vorgestellt, mit denen Sie die Konfiguration testen können.

Load-Balancer mit dem `socat`-Dienstprogramm testen

Mit dem Dienstprogramm socat können Sie den Port der Systemdiagnose vorübergehend überwachen.

Installieren Sie auf beiden Host-VMs das Dienstprogramm socat:
```
$ sudo yum install -y socat
```
Starten Sie einen socat-Prozess, um 60 Sekunden lang den Port der Systemdiagnose zu überwachen:
```
$ sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork
```

Warten Sie in Cloud Shell einige Sekunden, bis die Systemdiagnose den Listener erkennt, und prüfen Sie dann den Status Ihrer Back-End-Instanzgruppen:

$ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
  --region CLUSTER_REGION

Die Ausgabe sollte in etwa so aussehen:

---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/maxdb-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/maxdb-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/maxdb-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/maxdb-ha-vm-2
   ipAddress: 10.0.0.34
   port: 80
 kind: compute#backendServiceGroupHealth

Load-Balancer über Port 22 testen

Wenn Port 22 für SSH-Verbindungen auf Ihren Host-VMs geöffnet ist, können Sie die Systemdiagnose so bearbeiten, dass vorübergehend Port 22 verwendet wird, da hier ein Listener konfiguriert ist, der auf die Systemdiagnose reagieren kann.

So verwenden Sie vorübergehend Port 22:

Klicken Sie in der Konsole auf Ihre Systemdiagnose:

Zur Seite "Systemdiagnosen"
Klicken Sie auf Bearbeiten.
Ändern Sie im Feld Port die Portnummer in 22.
Klicken Sie auf Speichern und warten Sie ein bis zwei Minuten.

Prüfen Sie in Cloud Shell den Status Ihrer Back-End-Instanzgruppen:

$ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
  --region CLUSTER_REGION

Die Ausgabe sollte in etwa so aussehen:

---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/maxdb-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/maxdb-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/maxdb-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/maxdb-ha-vm-2
   ipAddress: 10.0.0.34
   port: 80
 kind: compute#backendServiceGroupHealth

Wenn Sie fertig sind, ändern Sie die Portnummer der Systemdiagnose wieder in die ursprüngliche Portnummer.

Pacemaker einrichten

Mit dem nachstehend beschriebenen Verfahren wird die Red Hat-Implementierung eines Pacemaker-Clusters auf Compute Engine-VMs für SAP MaxDB konfiguriert.

Das Verfahren beruht auf der Red Hat-Dokumentation zum Konfigurieren von Hochverfügbarkeitsclustern, einschließlich:

Hochverfügbarkeitscluster für Red Hat Enterprise Linux 2012 (und höher) in Google Cloud installieren und konfigurieren

Cluster-Agents auf beiden Knoten installieren

Führen Sie die folgenden Schritte auf beiden Knoten aus.

Installieren Sie als Root die Pacemaker-Komponenten:
```
# yum -y install pcs pacemaker fence-agents-gce resource-agents-gcp resource-agents-sap-hana
# yum update -y
```
Wenn Sie ein von Google bereitgestelltes RHEL-for-SAP-Image verwenden, sind diese Pakete bereits installiert, möglicherweise sind jedoch einige Updates erforderlich.
Legen Sie das Passwort für den Nutzer hacluster fest, der gemeinsam mit den Paketen installiert wird:
```
# passwd hacluster
```
Geben Sie in den Eingabeaufforderungen ein Passwort für hacluster an.
In den von Google Cloudbereitgestellten RHEL-Images ist der Firewalldienst des Betriebssystems standardmäßig aktiv. Konfigurieren Sie den Firewalldienst so, dass Traffic mit hoher Verfügbarkeit zugelassen wird:
```
# firewall-cmd --permanent --add-service=high-availability
```
```
# firewall-cmd --reload
```
Starten Sie den pcs-Dienst und konfigurieren Sie ihn so, dass er beim Booten startet:
```
# systemctl start pcsd.service
# systemctl enable pcsd.service
```

Prüfen Sie den Status des pcs-Dienstes:

# systemctl status pcsd.service

Die Ausgabe sollte in etwa so aussehen:

● pcsd.service - PCS GUI and remote configuration interface
  Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
  Active: active (running) since Sat 2023-10-23 21:17:05 UTC; 25s ago
    Docs: man:pcsd(8)
          man:pcs(8)
Main PID: 31627 (pcsd)
  CGroup: /system.slice/pcsd.service
          └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd
Oct 23 21:17:03 maxdb-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
Oct 23 21:17:05 maxdb-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.

Prüfen Sie, ob alle erforderlichen HA-Dienste auf beiden Knoten aktiviert und ausgeführt werden.
```
# systemctl enable pcsd.service pacemaker.service corosync.service
```

Fügen Sie in der Datei /etc/hosts den vollständigen Hostnamen und die internen IP-Adressen beider Hosts im Cluster hinzu. Beispiel:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.0.40 maxdb-ha-vm-1.us-central1-a.c.example-project-123456.internal maxdb-ha-vm-1  # Added by Google
10.0.0.41 maxdb-ha-vm-2.us-central1-c.c.example-project-123456.internal maxdb-ha-vm-2
169.254.169.254 metadata.google.internal  # Added by Google

Weitere Informationen von Red Hat zum Einrichten der Datei /etc/hosts auf RHEL-Clusterknoten finden Sie unter https://access.redhat.com/solutions/81123.

Cluster erstellen

Autorisieren Sie als Root den Nutzer hacluster auf einem der Knoten. Klicken Sie auf den Tab für Ihre RHEL-Version, um den Befehl anzuzeigen:
RHEL 8 und höher:
```
# pcs host auth primary-host-name secondary-host-name
```
RHEL 7
```
# pcs cluster auth primary-host-name secondary-host-name
```
Geben Sie bei Aufforderung den Nutzernamen hacluster und das Passwort ein, das Sie für den Nutzer hacluster festgelegt haben.

Erstellen Sie den Cluster:

RHEL 8 und höher:

# pcs cluster setup cluster-name primary-host-name secondary-host-name

RHEL 7

# pcs cluster setup --name cluster-name primary-host-name secondary-host-name

Standardeinstellungen für "corosync.conf" bearbeiten

Bearbeiten Sie die Datei /etc/corosync/corosync.conf auf dem primären Host, um einen geeigneteren Ausgangspunkt für das Testen der Fehlertoleranz Ihres Hochverfügbarkeitsclusters in Google Cloudfestzulegen.

Öffnen Sie auf beiden Hosts Ihren bevorzugten Texteditor, um die Datei /etc/corosync/corosync.conf zur Bearbeitung zu öffnen:
```
# /etc/corosync/corosync.conf
```
Wenn /etc/corosync/corosync.conf eine neue Datei ist oder leer ist, können Sie im Verzeichnis /etc/corosync/ nach einer Beispieldatei suchen, die als Basis für die Corrosync-Datei verwendet werden soll.
Fügen Sie im Abschnitt totem der Datei corosync.conf folgende Attribute mit den vorgeschlagenen Werten für Ihre RHEL-Version hinzu:
RHEL 8 und höher:
- transport: knet
- token: 20000
- token_retransmits_before_loss_const: 10
- join: 60
- max_messages: 20
Beispiel:
```
totem {
version: 2
cluster_name: hacluster
secauth: off
transport: knet
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
}
...
```
RHEL 7
- transport: udpu
- token: 20000
- token_retransmits_before_loss_const: 10
- join: 60
- max_messages: 20
Beispiel:
```
totem {
version: 2
cluster_name: hacluster
secauth: off
transport: udpu
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
}
...
```
Synchronisieren Sie auf dem Host, der die bearbeitete Datei corosync.conf enthält, die corosync-Konfiguration für den gesamten Cluster:
RHEL 8 und höher:
```
# pcs cluster sync corosync
```
RHEL 7
```
# pcs cluster sync
```
Legen Sie fest, dass der Cluster automatisch gestartet wird:
```
# pcs cluster enable --all
```
```
# pcs cluster start --all
```
Prüfen Sie mit dem Dienstprogramm "corosync-cmapctl", ob die neuen Corosync-Einstellungen im Cluster aktiv sind:
```
# corosync-cmapctl
```

Fencing einrichten

RHEL-Images, die von Google Cloud bereitgestellt werden, enthalten den für Google Cloudspezifischen fence_gceFencing-Agent. Sie verwenden fence_gce, um für jede Host-VM Fencing-Geräte zu erstellen.

Um die korrekte Abfolge der Ereignisse nach einer Fencing-Aktion sicherzustellen, konfigurieren Sie das Betriebssystem so, dass der Neustart von Corosync nach dem Fencing einer VM verzögert wird. Sie können auch das Pacemaker-Zeitlimit für Neustarts anpassen, um die Verzögerung zu berücksichtigen.

Wenn Sie alle Optionen sehen möchten, die für den Fencing-Agent fence_gce verfügbar sind, fragen Sie fence_gce -h ab.

Ressourcen für Fencing-Geräte erstellen

Als Root auf dem primären Host:

Erstellen Sie ein Fencing-Gerät für jede Host-VM:

# pcs stonith create primary-fence-name fence_gce \
  port=primary-host-name \
  zone=primary-host-zone \
  project=project-id \
  pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
  op monitor interval="300s" timeout="120s" \
  op start interval="0" timeout="60s"
# pcs stonith create secondary-fence-name fence_gce \
  port=secondary-host-name \
  zone=secondary-host-zone \
  project=project-id \
  pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
  op monitor interval="300s" timeout="120s" \
  op start interval="0" timeout="60s"

Beschränken Sie jedes Fencing-Gerät jeweils auf die andere Host-VM:

# pcs constraint location primary-fence-name avoids primary-host-name
# pcs constraint location secondary-fence-name avoids secondary-host-name

Testen Sie auf dem primären Host als Root das sekundäre Fencing-Gerät:
1. Fahren Sie die sekundäre Host-VM herunter:
```
# fence_gce -o off -n secondary-host-name --zone=secondary-host-zone
```
  Wenn der Befehl erfolgreich ausgeführt wurde, wird die Verbindung zur sekundären Host-VM getrennt und in der Google Cloud Console auf der Seite VM-Instanzen als gestoppt angezeigt. Möglicherweise müssen Sie die Seite aktualisieren.
2. Starten Sie die sekundäre Host-VM neu:
```
# fence_gce -o on -n secondary-host-name --zone=secondary-host-zone
```
Testen Sie als Root auf dem sekundären Host das primäre Fencing-Gerät Wiederholen Sie dazu die vorherigen Schritte und verwenden Sie dabei in den Befehlen die Werte für den primären Host.

Prüfen Sie als Root auf jedem Host den Status des Clusters:

# pcs status

Die Fencing-Ressourcen werden im Ressourcenbereich des Clusterstatus angezeigt, ähnlich wie im folgenden Beispiel:

[root@maxdb-ha-vm-2 ~]# pcs status
Cluster name: maxdb-ha-cluster
Stack: corosync
Current DC: maxdb-ha-vm-1 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
Last updated: Mon Jun 15 17:19:07 2020
Last change: Mon Jun 15 17:18:33 2020 by root via cibadmin on maxdb-ha-vm-1

2 nodes configured
2 resources configured

Online: [ maxdb-ha-vm-1 maxdb-ha-vm-2 ]

Full list of resources:

 STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
 STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Verzögerung für den Neustart von Corosync festlegen

Erstellen Sie auf beiden Hosts als Root eine systemd-Drop-in-Datei, die den Start von Corosync verzögert, um die richtige Reihenfolge der Ereignisse nach dem Neustart einer umzäunten VM zu gewährleisten:
```
systemctl edit corosync.service
```
Fügen Sie der Datei die folgenden Zeilen hinzu:
```
[Service]
ExecStartPre=/bin/sleep 60
```
Speichern Sie die Datei und beenden Sie den Editor.
Laden Sie die Konfiguration des systemd-Managers neu.
```
systemctl daemon-reload
```

Prüfen Sie, ob die Drop-in-Datei erstellt wurde:

service corosync status

Sie sollten eine Zeile für die Drop-in-Datei sehen, wie im folgenden Beispiel gezeigt:

● corosync.service - Corosync Cluster Engine
   Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/corosync.service.d
           └─override.conf
   Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago

Listener installieren und Systemdiagnose-Ressource erstellen

Zum Konfigurieren einer Systemdiagnose-Ressource müssen Sie zuerst die Listener installieren.

Listener installieren

Der Load Balancer verwendet einen Listener am Systemdiagnose-Port jedes Hosts, um zu ermitteln, wo die MaxDB-Instanz ausgeführt wird.

Installieren Sie als Root auf beiden Hosts einen TCP-Listener. In dieser Anleitung wird HAProxy als Listener installiert und verwendet.
```
# yum install haproxy
```

Öffnen Sie die Konfigurationsdatei haproxy.cfg zur Bearbeitung:

# vi /etc/haproxy/haproxy.cfg

Ändern Sie im Abschnitt Defaults der Datei haproxy.cfg den Parameter mode in tcplog.

Erstellen Sie nach dem Abschnitt Defaults einen neuen Abschnitt, indem Sie Folgendes hinzufügen:

#---------------------------------------------------------------------
# Health check listener port for SAP MaxDB HA cluster
#---------------------------------------------------------------------
listen healthcheck
  bind *:healthcheck-port-num

Der Bind-Port ist derselbe, den Sie beim Erstellen der Systemdiagnose verwendet haben.

Wenn Sie fertig sind, sollten die Aktualisierungen in etwa so aussehen:

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
  mode                    tcp
  log                     global
  option                  tcplog
  option                  dontlognull
  option http-server-close
  # option forwardfor       except 127.0.0.0/8
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000

#---------------------------------------------------------------------
# Set up health check listener for SAP MaxDB HA cluster
#---------------------------------------------------------------------
listen healthcheck
 bind *:60000

Starten Sie als Root den Dienst auf jedem Host, um zu prüfen, ob er richtig konfiguriert ist:
```
# systemctl start haproxy.service
```
Klicken Sie in der Google Cloud Console auf der Seite „Load Balancer“ auf den Load Balancer-Eintrag:

Seite "Load-Balancing"

Wenn auf der Seite Details zum Load-Balancer im Bereich Back-End der HAProxy-Dienst an beiden Hosts aktiv ist, wird in der Spalte Fehlerfrei jedes Instanzgruppeneintrags 1/1 angezeigt.
Beenden Sie auf beiden Hosts den HAProxy-Dienst:
```
# systemctl stop haproxy.service
```
Nachdem Sie den HAProxy-Dienst auf beiden Hosts beendet haben, wird in der Spalte Fehlerfrei jeder Instanzgruppe 0/1 angezeigt.

Später, wenn die Systemdiagnose konfiguriert ist, startet der Cluster den Listener auf dem aktiven Knoten neu.

Systemdiagnose-Ressource erstellen

Erstellen Sie als Root auf jedem Host eine Systemdiagnose-Ressource für den HAProxy-Dienst:

# pcs resource create healthcheck_resource_name service:haproxy op monitor interval=10s timeout=20s —-group SAPMaxDB_Group

Prüfen Sie, ob der Systemdiagnosedienst auf demselben Host wie Ihre SAP MaxDB-Instanz aktiv ist:
```
# pcs status
```
Wenn sich die Systemdiagnoseressource nicht auf demselben Host wie MaxDB befindet, verschieben Sie sie mit dem folgenden Befehl:
```
# pcs resource move healthcheck_resource_name target_host_name
# pcs resource clear healthcheck_resource_name
```
Der Befehl pcs resource clear belässt die Ressource an ihrem neuen Speicherort, entfernt aber die unerwünschte Standortbeschränkung, die mit dem Befehl pcs resource move erstellt wurde.

Der Status im Bereich "Ressourcen" sollte in etwa so aussehen:
```
Full list of resources:

STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

Resource Group: SAPMaxDB_Group
  rsc_healthcheck_MDB    (service:haproxy):      Started maxdb-ha-vm-1
```

Standardeinstellungen für den Cluster festlegen

Richten Sie Migrationsschwellenwerte und Wiederkehrrate ein, um festzulegen, wie viele Failover-Versuche ausgeführt werden sollen, bevor der Vorgang fehlschlägt, und um das System so zu konfigurieren, dass es zuerst auf dem aktuellen Host neu gestartet wird. Für die Anwendung auf den Cluster muss dies nur auf einem Knoten festgelegt werden.

Legen Sie als Root auf einem der Hosts die Standardeinstellungen für Ressourcen fest:
```
# pcs resource defaults resource-stickiness=1000
# pcs resource defaults migration-threshold=5000
```
Das Attribut resource-stickiness steuert, wie wahrscheinlich ein Dienst dort ausgeführt wird, wo er sich befindet. Bei höheren Werten ist der Dienst fixierter. Mit dem Wert 1000 ist der Dienst stark fixiert.

Das Attribut migration-threshold gibt die Anzahl der Fehler an, die auftreten müssen, bevor der Dienst per Failover auf einen anderen Host verlagert wird Ein Wert von 5.000 ist hoch genug, um bei nur kurzzeitig auftretenden Fehlern ein Failover zu vermeiden.

Sie können die Standardeinstellungen für Ressourcen prüfen, indem Sie pcs resource defaults eingeben.
Standardeinstellungen für Zeitlimits bei Ressourcenvorgängen festlegen:
```
# pcs resource op defaults timeout=600s
```
Sie können die Standardeinstellungen für Ressourcenvorgänge prüfen, indem Sie pcs resource op defaults eingeben.
Legen Sie die folgenden Clusterattribute fest:
```
# pcs property set stonith-enabled="true"
# pcs property set stonith-timeout="300s"
```
Sie können die Einstellungen der Attribute mit pcs property list prüfen.

MaxDB-Ressourcen im Cluster erstellen

Bevor Sie diese Schritte ausführen, müssen MaxDB und x_server beendet und das /sapdb-Dateisystem getrennt werden.

gcp-pd-move-Ressource erstellen

Die gcp-pd-move-Ressource ist ein Ressourcenagent, mit dem der nichtflüchtige Datenträger bei einem Cluster-Failover von einem Knoten zu einem anderen verschoben wird.

Erstellen Sie die Ressource mit dem folgenden Befehl als Root auf einem beliebigen Knoten:

# pcs resource create pd_move_resource_name gcp-pd-move \
  disk_name=regional_pd_name mode="READ_WRITE" disk_scope=regional \
  op monitor interval=10s timeout=15s \
  op start interval=0s timeout=300s \
  op stop interval=0s timeout=15s \
  --group SAPMaxDB_Group

LVM-Ressource erstellen

Ein LVM-aktivierter Ressourcenagent wird verwendet, um LVM zu aktivieren, nachdem der Datenträger auf den anderen Knoten verschoben wurde.

Erstellen Sie die LVM-Ressource mit dem folgenden Befehl als Root auf einem beliebigen Knoten:

# pcs resource create lvm_resource_name LVM-activate \
  vgname=vgname_for_maxdb \
  vg_access_mode=system_id activation_mode=exclusive \
  --group SAPMaxDB_Group

Beispiel:

# pcs resource create sapdb_lvm LVM-activate \
  vgname=sapdb vg_access_mode=system_id \
  activation_mode=exclusive \
  --group SAPMaxDB_Group

Dateisystemressource erstellen

Die Dateisystemressource wird im Cluster verwendet, um /sapdb während des Failover-Vorgangs zu trennen und auf einem anderen Knoten bereitzustellen.

Erstellen Sie die Dateisystemressource mit dem folgenden Befehl als Root auf einem beliebigen Knoten:

# pcs resource create fs_resource_name Filesystem \
  device=filesystem directory=/sapdb fstype=fs_type \
  --group SAPMaxDB_Group

Beispiel:

# pcs resource create sapdb_FS Filesystem \
  device=/dev/mapper/sapdb-sapdblv directory=/sapdb fstype=ext4 \
  --group SAPMaxDB_Group

Vorbereitungen für die MaxDB-Ressourcengruppe

Führen Sie die folgenden Schritte aus, um die MaxDB-Ressourcengruppe zu aktivieren.

Synchronisieren Sie Nutzer und Gruppen vom Knoten, auf dem Sie die MaxDB-Installation durchgeführt haben, mit dem anderen Knoten.
1. Die SAP MaxDB-Nutzer müssen zwischen den Knoten synchronisiert werden. Kopieren Sie dazu die Einträge in /etc/passwd, z. B.:
```
 sdb:x:1002:1003:MaxDB User:/home/sdb:/bin/false
 madbadm:x:1003:1005:SAP System Administrator:/home/mdbadm:/bin/csh
```
2. Ebenso müssen die SAP-Gruppen synchronisiert werden, indem die Einträge in /etc/group von einem Knoten zum anderen kopiert werden, z. B.:
```
 dba:x:1003:mdbadm
 sapsys:x:1005:
```

Synchronisieren Sie MaxDB-spezifische Dateien, die in den Betriebssystemverzeichnissen gespeichert werden. Führen Sie als Root-Nutzer die folgenden Befehle aus:

# rsync -av /etc/services target_host:/etc/services
# rsync -av /home/* target_host:/home
# rsync -av --exclude=sapservices /usr/sap/* target_host:/usr/sap
# rsync -av --ignore-existing /usr/sap/sapservicestarget_host:/usr/sap/sapservices
# rsync -av /etc/init.d/sapinittarget_host:/etc/init.d/

# MaxDB specific files
# rsync -av /etc/opttarget_host:/etc
# rsync -av /var/lib/sdbtarget_host:/var/lib

Benennen Sie die folgenden Umgebungsdateien für die SAP OS-Nutzer auf dem zweiten Knoten um, damit in ihren Basisverzeichnissen der jeweilige Hostname verwendet wird, z. B.:

mv .sapenv_maxdb-ha-vm-1.sh .sapenv_maxdb-ha-vm-2.sh
mv .sapenv_maxdb-ha-vm-1.csh .sapenv_maxdb-ha-vm-2.csh
mv .sapsrc_maxdb-ha-vm-1.sh  .sapsrc_maxdb-ha-vm-2.sh
mv .sapsrc_maxdb-ha-vm-1.csh  .sapsrc_maxdb-ha-vm-2.csh
mv .dbenv_maxdb-ha-vm-1.sh .sapenv_maxdb-ha-vm-2.sh
mv .dbenv_maxdb-ha-vm-1.csh .dbenv_maxdb-ha-vm-2.csh

Der SAPDatabase-Ressourcenagent verwendet keine datenbankspezifischen Befehle zum Stoppen oder Starten der Datenbank, sondern saphostctrl-Befehle. Für den SAP-Host-Agent müssen xuser-Einträge erstellt werden, damit MAXDB mit saphostctrl überwacht und gesteuert werden kann. Weitere Informationen finden Sie im SAP-Hinweis 2435938 – SAP Host Agent SAP MaxDB: DBCredentials for DB connect.

Führen Sie als Root den folgenden Befehl auf dem aktiven Knoten aus:SetDatabaseProperty

/usr/sap/hostctrl/exe/saphostctrl -host primary-host-name -user sapadm password \
  -dbname SID -dbtype ada -function SetDatabaseProperty DBCredentials=SET \
  -dboption User=SUPERDBA -dboption Password=password

Testen Sie die Einträge mit dem folgenden Befehl. Selbst wenn die Datenbank angehalten ist, sollte der Befehl den Status wiederherstellen können:

/usr/sap/hostctrl/exe/saphostctrl -host secondary-host-name -dbname SID \
  -dbtype ada -function GetDatabaseStatus

Der Befehl „saphostctrl agent“ verwendet das Programm xuser aus der MaxDB-Installation. Um den zweiten Knoten jetzt vorzubereiten, verschieben Sie SAPMaxDB_group also zu „maxdb-node-b“.

Führen Sie auf einem beliebigen Knoten als Root-Nutzer den folgenden Befehl aus:
```
pcs resource move SAPMaxDB_group
```

Die vier erstellten Ressourcen „Systemdiagnose“, gcp-pd-move, LVM und Dateisystem wurden jetzt migriert und auf dem zweiten Knoten erfolgreich gestartet.

Mit dem folgenden Befehl können Sie sich die ausgeführten Aktionen auf einem beliebigen Knoten ansehen:
```
watch pcs status
```

Sobald alle vier Ressourcen auf dem zweiten Knoten gestartet wurden, führen Sie den Befehl saphostctrl aus.

Führen Sie als Root den folgenden Befehl aus, um die Datenbankeigenschaft für den jetzt aktiven Knoten festzulegen:

/usr/sap/hostctrl/exe/saphostctrl -host secondary-host-name -user sapadm password \
  -dbname SID -dbtype ada -function SetDatabaseProperty DBCredentials=SET \
  -dboption User=SUPERDBA -dboption Password=password

Starten Sie auf Knoten b MaxDB und x_server manuell, um zu prüfen, ob sie richtig gestartet werden können:
```
# dbmcli -d SID -u control, and password db_online
# x_server start
```

Fahren Sie mit dem nächsten Schritt fort, um eine Ressource für die SAP-Datenbank zu erstellen. Wenn an dieser Stelle Fehler auftreten, erstellen Sie die Datenbankressource nicht.

Ressource für SAP MaxDB erstellen

RHEL Pacemaker verwendet den SAP-Datenbankressourcen-Agenten, um die SAP-Datenbank zu überwachen und zu steuern.

Erstellen Sie die Datenbankressource auf dem Knoten, auf dem SAPMaxDB_group aktiv ist, mit dem folgenden Befehl:

# pcs resource create SAPDatabase_resource_name SAPDatabase \
  DBTYPE="ADA" SID="SID" STRICT_MONITORING="TRUE" \
  MONITOR_SERVICES="Database|x_server" AUTOMATIC_RECOVER="TRUE"
  --group SAPMaxDB_Group

Die endgültigen Clusterressourcen können mit pcs status angezeigt werden. Das erwartete Ergebnis sieht so aus:

# pcs status
  Cluster name: maxdb-cluster
  Stack: corosync
  Current DC: maxdb-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
  Last updated: Wed Oct 23 02:04:32 2024
  Last change: Wed Oct 23 02:01:41 2024 by hacluster via crmd on maxdb-ha-vm-1

  2 nodes configured
  7 resource instances configured

  Online: [ maxdb-ha-vm-1 maxdb-ha-vm-2 ]

  Full list of resources:

  STONITH-maxdb-ha-vm-1  (stonith:fence_gce):    Started maxdb-ha-vm-2
  STONITH-maxdb-ha-vm-2  (stonith:fence_gce):    Started maxdb-ha-vm-1
  Resource Group: SAPMaxDB_Group
     healthcheck_maxdb  (service:haproxy):      Started maxdb-ha-vm-1
     sapdb_regpd        (ocf::heartbeat:gcp-pd-move):   Started maxdb-ha-vm-1
     lvm_sapdb  (ocf::heartbeat:LVM-activate):  Started maxdb-ha-vm-1
     sapdb_fs   (ocf::heartbeat:Filesystem):    Started maxdb-ha-vm-1
     MDB_SAPMaxDB       (ocf::heartbeat:SAPDatabase):   Started maxdb-ha-vm-1

  Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Failover testen

Testen Sie Ihren Cluster, indem Sie einen Ausfall auf dem aktiven Host simulieren. Verwenden Sie ein Testsystem oder führen Sie den Test auf Ihrem Produktionssystem durch, bevor Sie das System für die Verwendung freigeben.

Sichern Sie vor dem Test das System.

Sie können einen Ausfall auf unterschiedliche Weise simulieren, z. B. so:

MaxDB oder x_server manuell beenden
MaxDB- oder x_server-Prozess beenden
reboot (auf dem aktiven Knoten)
ip link set eth0 down für Instanzen mit einer einzelnen Netzwerkschnittstelle
iptables ... DROP für Instanzen mit mehreren Netzwerkschnittstellen
echo c > /proc/sysrq-trigger

Diese Anleitung verwendet ip link set eth0 down oder iptables, um eine Netzwerkunterbrechung zwischen den beiden Hosts in Ihrem Cluster zu simulieren. Verwenden Sie den Befehl ip link für eine Instanz mit einer einzelnen Netzwerkschnittstelle und den Befehl iptables für Instanzen mit einer oder mehreren Netzwerkschnittstellen. Der Test validiert sowohl Failover als auch Fencing. Wenn für die Instanzen mehrere Netzwerkschnittstellen definiert sind, verwenden Sie den Befehl iptables auf dem sekundären Host, um eingehenden und ausgehenden Traffic anhand der IP-Adresse zu löschen, die vom primären Host für die Cluster-Kommunikation verwendet wird, wodurch ein Verlust der Netzwerkverbindung zum primären Knoten simuliert wird.

Schalten Sie als Root auf dem aktiven Host die Netzwerkschnittstelle offline:
```
# ip link set eth0 down
```
Stellen Sie eine SSH-Verbindung zu einem der Hosts her und wechseln Sie zum Root-Nutzer.

Geben Sie pcs status ein, um zu prüfen, ob der zuvor passive Host jetzt den regionalen nichtflüchtigen Speicher angehängt hat und die MaxDB-Dienste ausführt. Da im Cluster der automatische Neustart aktiviert ist, wird der angehaltene Host neu gestartet und übernimmt wie im folgenden Beispiel gezeigt die Rolle des passiven Hosts:

Cluster name: maxdb-ha-cluster
Stack: corosync
Current DC: maxdb-ha-vm-2 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
Last updated: Wed Oct 23 02:01:45 2024
Last change: Wed Oct 23 02:01:41 2024 by hacluster via crmdon maxdb-ha-vm-2

2 nodes configured
7 resources configured

Online: [ maxdb-ha-vm-1 maxdb-ha-vm-2 ]

Full list of resources:

STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

Resource Group: SAPMaxDB_Group
 healthcheck_maxdb  (service:haproxy):      Started maxdb-ha-vm-2
 sapdb_regpd        (ocf::heartbeat:gcp-pd-move):   Started maxdb-ha-vm-2
 lvm_sapdb  (ocf::heartbeat:LVM-activate):  Started maxdb-ha-vm-2
 sapdb_fs   (ocf::heartbeat:Filesystem):    Started maxdb-ha-vm-2
 MDB_SAPMaxDB       (ocf::heartbeat:SAPDatabase):   Started maxdb-ha-vm-2

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Fehlerbehebung

Informationen zur Fehlerbehebung bei Problemen mit Hochverfügbarkeitskonfigurationen für SAP-Systeme unter RHEL finden Sie unter Fehlerbehebung bei Hochverfügbarkeitskonfigurationen für SAP.

Support für SAP HANA unter RHEL

Wenn Sie Hilfe bei einem Problem mit Hochverfügbarkeitsclustern für SAP HANA unter RHEL benötigen, stellen Sie die erforderlichen Diagnoseinformationen zusammen und wenden Sie sich an den Cloud Customer Care. Weitere Informationen finden Sie unter Diagnoseinformationen zu Hochverfügbarkeitsclustern auf RHEL.

Konfigurationsanleitung für Hochverfügbarkeitscluster für SAP MaxDB unter RHEL

System, das in dieser Anleitung bereitgestellt wird

Vorbereitung

Netzwerk erstellen

Console

gcloud

NAT-Gateway einrichten

Firewallregeln hinzufügen

Console

gcloud

VMs bereitstellen und MaxDB installieren

VM für die MaxDB-Bereitstellung erstellen

Ein einzelnes regionales Laufwerk für SAP MaxDB erstellen

RHEL-Betriebssystem für die SAP-Installation vorbereiten

Dateisysteme erstellen

LVM-Konfiguration ändern

Datenbank und SAP-Host-Agent installieren

Aufgaben nach der Installation ausführen

Failover-Unterstützung für Cloud Load Balancing konfigurieren

IP-Adresse für die virtuelle IP-Adresse reservieren

Instanzgruppen für Host-VMs erstellen

Compute Engine-Systemdiagnose erstellen

Firewallregel für die Systemdiagnosen erstellen

Load-Balancer und Failover-Gruppe konfigurieren

Konfiguration des Load-Balancers testen

Load-Balancer mit dem socat-Dienstprogramm testen

Load-Balancer über Port 22 testen

Pacemaker einrichten

Cluster-Agents auf beiden Knoten installieren

Cluster erstellen

RHEL 8 und höher:

RHEL 7

RHEL 8 und höher:

RHEL 7

Standardeinstellungen für "corosync.conf" bearbeiten

RHEL 8 und höher:

RHEL 7

RHEL 8 und höher:

RHEL 7

Fencing einrichten

Ressourcen für Fencing-Geräte erstellen

Verzögerung für den Neustart von Corosync festlegen

Listener installieren und Systemdiagnose-Ressource erstellen

Listener installieren

Systemdiagnose-Ressource erstellen

Standardeinstellungen für den Cluster festlegen

MaxDB-Ressourcen im Cluster erstellen

gcp-pd-move-Ressource erstellen

LVM-Ressource erstellen

Dateisystemressource erstellen

Vorbereitungen für die MaxDB-Ressourcengruppe

Ressource für SAP MaxDB erstellen

Failover testen

Fehlerbehebung

Support für SAP HANA unter RHEL

Load-Balancer mit dem `socat`-Dienstprogramm testen