In Google Cloud wird für die Implementierung einer virtuellen IP-Adresse (VIP) für einen betriebssystembasierten HA-Cluster (Hochverfügbarkeit) für SAP die Failover-Unterstützung eines internen TCP/UDP-Load-Balancers empfohlen.
Wenn Sie in Google Cloud einen RHEL-HA-Cluster (Red Hat Enterprise Linux) für SAP haben, der eine mit einer Alias-IP-Adresse implementierte VIP-Adresse nutzt, können Sie die VIP-Adresse migrieren, um stattdessen einen internen Load-Balancer zu verwenden.
Wenn Sie die nicht mehr unterstützte Deployment Manager-Vorlage sap_hana_ha
verwendet haben, um ein vertikal skalierbares SAP HANA-System in einem HA-Cluster auf RHEL bereitzustellen, wird Ihre VIP-Adresse mit einer Alias-IP-Adresse implementiert.
In dieser Anleitung wird gezeigt, wie Sie eine VIP-Adresse in einem RHEL-Cluster migrieren.
Voraussetzungen
In dieser Anleitung wird angenommen, dass Sie bereits einen korrekt konfigurierten HA-Cluster in Google Cloud haben, der für die VIP-Implementierung eine Alias-VIP-Adresse nutzt.
Die einzelnen Schritte im Überblick
- Konfigurieren und testen Sie einen Load-Balancer mithilfe einer temporären Weiterleitungsregel und einer temporären IP-Adresse anstelle der VIP-Adresse.
- Versetzen Sie den Cluster in den Wartungsmodus und beenden Sie nach Möglichkeit die Instanzen Ihrer SAP-Anwendungsserver, um unerwartetes Verhalten zu vermeiden.
- Heben Sie die Zuweisung der Alias-IP-Adresse vom primären Host auf. Diese Adresse wird zur VIP-Adresse des Load-Balancers.
- Gehen Sie in der Konfiguration des Pacemaker-Clusters so vor:
- Ändern Sie die Klasse der vorhandenen VIP-Ressource.
- Ersetzen Sie die vorhandenen Parameter für die Alias-IP-Adresse durch die Parameter für den Systemdiagnosedienst.
Vorhandene VIP-Adresse bestätigen
Rufen Sie auf der primären VM-Instanz die vorhandene Alias-IP-basierte Clusterkonfiguration als Root auf:
$
pcs configure show
In der Ressourcendefinition wird der VIP-Adressbereich in den Ressourcen alias
und IPaddr2
angezeigt. Wenn Sie die VIP-Adresse ändern müssen, müssen Sie beide Ressourcen aktualisieren. Sehen Sie sich folgendes Beispiel an:
Resource rsc_alias (class=ocf provider=heartbeat type=gcp-vpc-move-vip) \ Attributes: alias_ip=10.10.0.90/32 Operations: monitor interval=60s timeout=60s (vip_hkn_00-monitor-interval-60s) start interval=0s timeout=600s stop interval=0s timeout=20s Resource rsc_vip(class=ocf provider=heartbeat type=IPaddr2) \ Attributes: cidr_netmask=32 ip=10.10.0.90 nic=eth0 Operations: monitor interval=10s timeout=20s (vip_hkn_00-monitor-interval-10s) start interval=0s timeout=20s (vip_hkn_00-start-interval-0s) stop interval=0s timeout=20s (vip_hkn_00-stop-interval-0s)
Bestätigen Sie in der Google Cloud Console, dass die IP-Adresse, die mit der Alias-IP-Adresse verwendet wird, reserviert ist. Die IP-Adresse kann die IP-Adresse sein, die für die Alias-IP-Adresse verwendet wurde, oder eine neue IP-Adresse.
$
gcloud compute addresses list --filter="region:( cluster-region )"
Wenn die IP-Adresse reserviert und der primären VM-Instanz zugewiesen ist, wird ihr Status als IN_USE
angezeigt. Wenn Sie die IP-Adresse dem Load-Balancer neu zuweisen, müssen Sie sie zuerst von der aktiven primären Instanz trennen. Der Status wechselt dann zu RESERVED
.
Wenn die Adresse nicht in den IP-Adressen enthalten ist, die vom Befehl "list" zurückgegeben werden, reservieren Sie sie jetzt, um in Zukunft Konflikte zu vermeiden:
$
gcloud compute addresses create vip-name \
--region cluster-region --subnet cluster-subnet \
--addresses vip-address
Listen Sie die Adressen noch einmal auf, um zu prüfen, ob die IP-Adresse als RESERVED
angezeigt wird.
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 HANA-Cluster weiter.
Wenn Sie Konflikte vermeiden und Tests vor Abschluss der Migration ermöglichen möchten, müssen Sie gemäß dieser Anleitung eine temporäre Weiterleitungsregel mit einer Platzhalter-IP-Adresse aus dem Subnetz erstellen, dem die VIP-Adresse zugeordnet ist. Wenn Sie bereit sind, die VIP-Implementierung zu ändern, erstellen Sie mit der VIP-Adresse eine neue endgültige Weiterleitungsregel.
Temporäre IP-Adresse für virtuelle IP-Adresse reservieren
Die VIP-Adresse folgt dem aktiven SAP HANA-System. Der Load-Balancer leitet den an die VIP gesendeten Traffic an die VM weiter, die derzeit das aktive SAP HANA-System hostet.
Öffnen Sie Cloud Shell:
Reservieren Sie zu Testzwecken eine temporäre IP-Adresse für das Subnetz, dem die Alias-IP-Adresse zugeordnet ist. 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_ADDRESSWeitere 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_REGIONDie Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:
address: 10.0.0.19 addressType: INTERNAL creationTimestamp: '2020-05-20T14:19:03.109-07:00' description: '' id: '8961491304398200872' kind: compute#address name: vip-for-hana-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-hana-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 Master-Host-VM der einen und die sekundäre Master-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_NAMEBestätigen Sie die Erstellung der Instanzgruppen:
$
gcloud compute instance-groups unmanaged listDie Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:
NAME ZONE NETWORK NETWORK_PROJECT MANAGED INSTANCES hana-ha-ig-1 us-central1-a example-network example-project-123456 No 1 hana-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=2Bestätigen Sie die Erstellung der Systemdiagnose:
$
gcloud compute health-checks describe HEALTH_CHECK_NAMEDie Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:
checkIntervalSec: 10 creationTimestamp: '2020-05-20T21:03:06.924-07:00' healthyThreshold: 2 id: '4963070308818371477' kind: compute#healthCheck name: hana-health-check selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/hana-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_ZONEWenn 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_NUMBeispiel:
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-checksFü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_REGIONFü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_REGIONErstellen Sie eine temporäre Weiterleitungsregel. Geben Sie als IP-Adresse die temporäre IP-Adresse an, die Sie zum Testen reserviert haben. Wenn Sie von außerhalb der unten angegebenen Region auf das SAP HANA-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 ALLWeitere Informationen zum regionenübergreifenden Zugriff auf Ihr SAP HANA-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 socatStarten Sie einen
socat
-Prozess, um 60 Sekunden lang den Port der Systemdiagnose zu überwachen:$
sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,forkWarten 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_REGIONDie Ausgabe sollte in etwa so aussehen:
--- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-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/hana-ha-ig-2 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-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:
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_REGIONDie Ausgabe sollte in etwa so aussehen:
--- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-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/hana-ha-ig-2 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-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.
VIP-Implementierung für Nutzung des Load-Balancers migrieren
Mit den folgenden Schritten bearbeiten Sie die Konfiguration des Pacemaker-Clusters und die Weiterleitungsregel des Load-Balancers, um die VIP-Migration abzuschließen.
System für Bearbeitung vorbereiten
Beenden Sie falls möglich die SAP-Anwendung, damit keine Verbindung zur SAP HANA-Datenbank hergestellt wird, da Sie die Verbindung kurzzeitig unterbrechen, um die IP-Adressen auszutauschen. Über die NetWeaver-Arbeitsprozesse kann wieder eine Verbindung zur Datenbank hergestellt werden. Es sind jedoch Fehler oder Verzögerungen möglich, die durch das Unterbrechen der Verbindung verhindert werden können. Achten Sie darauf, dass Ihre IP-Adresse in einem internen Bereich registriert ist, der Teil Ihrer VPC in der Zielregion ist.
Fügen Sie den Cluster als Root in die aktive primäre Instanz ein und aktivieren Sie für den Cluster den Wartungsmodus:
$
pcs property set maintenance-mode="true"Sichern Sie die Clusterkonfiguration:
$
pcs config show > clusterconfig.backup
Zuweisung der Alias-IP-Adresse aufheben
Bestätigen Sie in Cloud Shell die Alias-IP-Bereiche, die der primären Instanz von SAP HANA zugewiesen sind:
$
gcloud compute instances describe \ primary-host-name \ --zone primary-zone \ --format="flattened(name,networkInterfaces[].aliasIpRanges)"Aktualisieren Sie in der Google Cloud Console die Netzwerkschnittstelle. Wenn Sie keine Alias-IP-Adressen beibehalten müssen, geben Sie
--aliases ""
an:$
gcloud compute instances network-interfaces update primary-host-name \ --zone primary-zone \ --aliases "ip-ranges-to-retain"
VIP-Weiterleitungsregel erstellen und bereinigen
Erstellen Sie in der Google Cloud Console eine neue Frontend-Weiterleitungsregel für den Load-Balancer. Geben Sie dazu die IP-Adresse an, die zuvor für die Alias-IP-Adresse als IP-Adresse verwendet wurde. Das ist Ihre VIP-Adresse.
$
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 ALLBestätigen Sie die Erstellung der Weiterleitungsregel und notieren Sie sich den Namen der temporären Weiterleitungsregel zum Löschen:
$
gcloud compute forwarding-rules listLöschen Sie die temporäre Weiterleitungsregel:
$
gcloud compute forwarding-rules delete rule-name --region=cluster-regionGeben Sie die reservierte temporäre IP-Adresse frei:
$
gcloud compute addresses delete temp-ip-name --region=cluster-region
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 primäre Instanz des SAP HANA-Clusters ausgeführt wird. 1. Installieren Sie als Root auf der Masterinstanz auf dem primären und dem sekundären System 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 Parametermode
intcp
.Erstellen Sie nach dem Abschnitt Defaults einen neuen Abschnitt, indem Sie Folgendes hinzufügen:
#--------------------------------------------------------------------- # Health check listener port for SAP HANA 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 HANA 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.serviceKlicken Sie in der Google Cloud Console auf der Seite „Load-Balancer“ auf den Load-Balancer-Eintrag:
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.serviceNachdem 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 Masterknoten 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
Bearbeiten Sie die Clusterkonfiguration, um die Systemdiagnose-Ressource zu verwenden, und entfernen Sie die Alias-Ressource
Entfernen Sie
Colocation Constraints
für die vorhandene Gruppe mit der Alias-IP-Ressource, die der primären Instanz von SAP HANA zugeordnet ist:#
pcs constraint remove colocation-alias-vip-group-sap_hana_resource_nameErstellen Sie eine neue Ressourcengruppe, die die VIP- und Systemdiagnoseressourcen zusammenfasst:
#
pcs resource group add rsc-group-namehealthcheck_resource_namevip_resource_nameDieser Befehl ersetzt in der Clusterkonfiguration den vorherigen Gruppennamen der Alias-IP-Adresse und der VIP-Ressourcen durch den neuen Ressourcengruppennamen.
Prüfen Sie den Namen der neuen Ressourcengruppe in der Clusterkonfiguration:
#
pcs config showDie Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:
Group: ilb-vip-group Resource: vip_hkn_00 (class=ocf provider=heartbeat type=IPaddr2) Attributes: cidr_netmask=32 ip=10.10.0.90 nic=eth0 Operations: monitor interval=10s timeout=20s (vip_hkn_00-monitor-interval-10s) start interval=0s timeout=20s (vip_hkn_00-start-interval-0s) stop interval=0s timeout=20s (vip_hkn_00-stop-interval-0s) Resource: ilb-health-check (class=service type=haproxy) Operations: monitor interval=60 timeout=100 (ilb-health-check-monitor-interval-60) start interval=0s timeout=100 (ilb-health-check-start-interval-0s) stop interval=0s timeout=100 (ilb-health-check-stop-interval-0s)
Löschen Sie die Alias-Ressource:
#
pcs resource delete alias_resource_namePrüfen Sie den Clusterstatus:
#
pcs statusDer Bereich "Ressourcengruppe" sollte in der Ausgabe ähnlich dem folgenden Beispiel angezeigt werden:
STONITH-hana-ha-vm-1 (stonith:fence_gce): Started hana-ha-vm-2 STONITH-hana-ha-vm-2 (stonith:fence_gce): Started hana-ha-vm-1 Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22] Started: [ hana-ha-vm-1 hana-ha-vm-2 ] Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22] Masters: [ hana-ha-vm-1 ] Slaves: [ hana-ha-vm-2 ] Resource Group: g-primary rsc_healthcheck_HA1 (service:haproxy): Started hana-ha-vm-1 rsc_vip_HA1_22 (ocf::heartbeat:IPaddr2): Started hana-ha-vm-1
Beenden Sie den Wartungsmodus des Clusters:
#
pcs property set maintenance-mode=false
Aktualisierten HA-Cluster testen
Prüfen Sie über die Anwendungsinstanz, ob Sie auf die Datenbank zugreifen können. Führen Sie dazu einen der folgenden Befehle aus:
Als
sidadm
-Nutzer:>
R3trans -dAls beliebiger Nutzer:
telnet VIP HANA SQL port
oder
nc -zv VIP HANA SQL port