Konfigurationsanleitung für vertikale skalierbares Hochverfügbarkeitscluster für SAP HANA unter RHEL

In diesem Leitfaden wird beschrieben, wie Sie einen Hochverfügbarkeitscluster unter Red Hat Enterprise Linux (RHEL) für SAP HANA 1.0 ab SP 12 in Google Cloud bereitstellen und konfigurieren.

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

Diese Anleitung enthält auch Schritte zur Konfiguration der SAP HANA-Systemreplikation. Eine ausführliche Anleitung finden Sie in der SAP-Dokumentation.

Wenn Sie ein SAP HANA-System ohne Linux-Hochverfügbarkeitscluster oder einen Standby-Knotenhost bereitstellen möchten, verwenden Sie die Bereitstellungsanleitung für SAP HANA.

Informationen zum Konfigurieren eines HA-Clusters für SAP HANA auf SUSE Linux Enterprise Server (SLES) finden Sie im Konfigurationsleitfaden für HA-Cluster für die vertikale Skalierung von SAP HANA auf SLES.

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

System, das in dieser Anleitung bereitgestellt wird

In dieser Anleitung stellen Sie zwei SAP HANA-Instanzen bereit und richten einen Hochverfügbarkeitscluster unter RHEL ein. Sie stellen jede SAP HANA-Instanz auf einer Compute Engine-VM in einer anderen Zone innerhalb derselben Region bereit. Eine Hochverfügbarkeitsinstallation von SAP NetWeaver wird in dieser Anleitung nicht behandelt.

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

• Zwei Host-VMs mit jeweils einer Instanz von SAP HANA
• Synchrone SAP HANA-Systemreplikation
• Hochverfügbarkeitsclusterressourcen-Manager von Pacemaker
• STONITH-Fencing-Mechanismus
• Automatischer Neustart der fehlgeschlagenen Instanz als neue sekundäre Instanz

In dieser Anleitung verwenden Sie die von Google Cloud zur Verfügung gestellten Cloud Deployment Manager-Vorlagen, um die Compute Engine-VMs und die SAP HANA-Instanzen bereitzustellen. Dadurch wird gewährleistet, dass die VMs und die SAP HANA-Basissysteme die Anforderungen der SAP-Unterstützung erfüllen und den aktuellen Best Practices entsprechen.

In dieser Anleitung wird SAP HANA Studio zum Testen der SAP HANA-Systemreplikation verwendet. Wenn Sie möchten, können Sie stattdessen auch SAP HANA Cockpit verwenden. Informationen zur Installation von SAP HANA Studio finden Sie hier:

• SAP HANA Studio auf einer Compute Engine-Windows-VM installieren
• Installations- und Aktualisierungsanleitung für SAP HANA Studio

Vorbereitung

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

• Sie haben den Planungsleitfaden für SAP HANA und den Planungsleitfaden für SAP HANA – Hochverfügbarkeit gelesen.
• Sie oder Ihre Organisation haben ein Google Cloud-Konto. Außerdem haben Sie ein Projekt für die SAP HANA-Bereitstellung erstellt. Informationen zum Erstellen von Google Cloud-Konten und -Projekten finden Sie unter Google-Konto einrichten in der Bereitstellungsanleitung für SAP HANA.
• 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.

• Die SAP HANA-Installationsmedien sind in einem Cloud Storage-Bucket gespeichert, der in Ihrem Bereitstellungsprojekt und Ihrer Region verfügbar ist. Informationen zum Hochladen von SAP HANA-Installationsmedien in einen Cloud Storage-Bucket finden Sie in der Anleitung zur Bereitstellung von SAP HANA unter SAP HANA herunterladen.

• 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

• Bei einem internen VPC-DNS muss der Wert der Variable vmDnsSetting in Ihren Projektmetadaten entweder GlobalOnly oder ZonalPreferred sein, damit die Knotennamen zonenübergreifend aufgelöst werden können. Die Standardeinstellung von vmDnsSetting ist ZonalOnly. Weitere Informationen finden Sie unter:

  • DNS-Namen für Projekte oder Instanzen konfigurieren
  • Benutzerdefinierte Metadaten abfragen
  • Benutzerdefinierte Metadaten für das gesamte Projekt einrichten

Folgen Sie diesen Empfehlungen, um zu vermeiden, dass Ihre VM-Instanz versehentlich im Internet veröffentlicht wird:

• Verwenden Sie ein NAT-Gateway.
• Erstellen Sie Firewallregeln, die den gesamten externen Zugriff blockieren, den Sie nicht benötigen.
• Gehen Sie beim Erstellen Ihrer VMs so vor:
  • Geben Sie für jede VM ein Netzwerk-Tag zur Verwendung in Routing- und Firewallregeln an. Wenn Sie die von Google Cloud bereitgestellte Deployment Manager-Vorlage nutzen, legen Sie Tags mit networkTag: [TAG] fest.
  • Erstellen Sie die VMs ohne externe IP-Adresse. Wenn Sie die von Google Cloud bereitgestellten Deployment Manager-Vorlagen verwenden, geben Sie publicIP: No an.

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 Google Cloud-Agent für SAP herunterzuladen. Wenn Sie eines der von SAP zertifizierten Linux-Images verwenden, die in Google Cloud verfü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

1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.

   Zur Seite VPC-Netzwerke

2. Klicken Sie auf VPC-Netzwerk erstellen.
3. Geben Sie einen Namen für das Netzwerk ein.

   Der Name muss der Namenskonvention entsprechen. VPC-Netzwerke verwenden die Namenskonvention von Compute Engine.

4. Wählen Sie unter Modus für Subnetzerstellung die Option Benutzerdefiniert aus.
5. 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.
6. 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.
7. Klicken Sie auf Erstellen.

gcloud

1. Rufen Sie Cloud Shell auf.

   Zu Cloud Shell

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

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

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

Wichtiger Hinweis: Wenn Sie Cloud NAT konfigurieren, geben Sie mindestens 160 als Mindestanzahl von Ports pro VM an. Bestimmte Betriebssystem-Updates führen gleichzeitige Prozesse aus, die möglicherweise den Cloud NAT-Standardwert für die Anzahl der Ports überschreiten, was zu Aktivierungs- oder Downloadfehlern führen kann.

Wenn Sie eine Cloud NAT-Instanz erstellen, geben Sie die Anzahl der Ports im Feld Mindestanzahl an Ports pro VM unter Erweiterte Konfigurationen auf der Seite „NAT-Gateway erstellen“ in der Google Cloud Console ein.

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.
• Kommunikation zwischen VMs im SAP HANA-Subnetzwerk, einschließlich der Kommunikation zwischen Knoten in einem SAP HANA-System mit horizontaler Skalierung oder Kommunikation zwischen dem Datenbankserver und Anwendungsservern in einer dreistufigen Architektur.Kommunikation zwischen VMs im SAP HANA-Subnetzwerk, einschließlich der Kommunikation zwischen Knoten in einem SAP HANA-System mit horizontaler Skalierung oder Kommunikation zwischen dem Datenbankserver und Anwendungsservern in einer dreistufigen Architektur. Sie können die Kommunikation zwischen VMs aktivieren, indem Sie eine Firewallregel erstellen, die Traffic aus dem Subnetzwerk zulässt.

Hinweis: Das folgende Verfahren ist eine vereinfachte Version der Anleitung für das Erstellen von Firewallregeln. Eine ausführlichere Anleitung finden Sie unter Firewallregeln erstellen.

So erstellen Sie eine Firewallregel:

Console

1. Rufen Sie in der Google Cloud Console die Seite Firewall des VPC-Netzwerks auf.

   Zur Firewall

2. 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 Cloud an, für die diese Regel gelten soll. Legen Sie beispielsweise Alle Instanzen im Netzwerk fest. Sie können unter Angegebene Ziel-Tags auch Tags eingeben, um die Regel auf bestimmte Instanzen in Google Cloud zu 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.

3. 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 und SAP HANA bereitstellen

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

Zum Definieren und Bereitstellen der Systeme verwenden Sie dieselbe Cloud Deployment Manager-Vorlage, die Sie zum Bereitstellen eines SAP HANA-Systems in der Bereitstellungsanleitung für SAP HANA verwenden.

Wenn Sie jedoch statt eines Systems zwei bereitstellen möchten, müssen Sie die Definition für das zweite System der Konfigurationsdatei hinzufügen. Kopieren Sie hierfür die Definition des ersten Systems und fügen Sie sie ein. Nachdem Sie die zweite Definition erstellt haben, müssen Sie die Ressourcen- und Instanznamen in der zweiten Definition ändern. Geben Sie zum Schutz vor einem Zonenausfall eine andere Zone in derselben Region an. Alle anderen Attributwerte in den beiden Definitionen bleiben unverändert.

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

In der folgenden Anleitung wird Cloud Shell verwendet, sie ist aber allgemein auf Google Cloud-CLI anwendbar.

1. Prüfen Sie, ob Ihre aktuellen Kontingente für Ressourcen wie nichtflüchtige Speicher und CPUs für das zu installierende SAP HANA-System ausreichen. Bei unzureichenden Kontingenten schlägt die Bereitstellung fehl. Welche Kontingente Sie für SAP HANA benötigen, erfahren Sie unter Überlegungen zu Preisen und Kontingenten für SAP HANA.

   Zur Seite "Kontingente"

2. Öffnen Sie die Cloud Shell. Wenn Sie die gcloud CLI auf Ihrer lokalen Workstation installiert haben, können Sie stattdessen auch ein Terminal öffnen.

   Zu Cloud Shell

3. Laden Sie die Konfigurationsdateivorlage template.yaml für den SAP HANA-Hochverfügbarkeitscluster in Ihr Arbeitsverzeichnis herunter. Geben Sie dafür den folgenden Befehl in Cloud Shell oder in der gcloud CLI ein:

   wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/template.yaml

4. Sie können die Datei template.yaml so umbenennen, dass die von ihr definierte Konfiguration im Namen erkennbar ist.

5. Öffnen Sie die Datei template.yaml im Cloud Shell-Code-Editor bzw. bei Verwendung der gcloud CLI in Ihrem bevorzugten Texteditor.

   Klicken Sie zum Öffnen des Code-Editors auf das Stiftsymbol oben rechts im Cloud Shell-Terminalfenster.

6. Erstellen Sie in der Datei template.yaml die Definition des primären SAP HANA-Systems. Geben Sie die Attributwerte an, indem Sie die Klammern und ihren Inhalt durch die Werte für Ihre Installation ersetzen. Die Attribute sind in der folgenden Tabelle beschrieben.

   Wenn Sie die VM-Instanzen ohne Installation von SAP HANA erstellen möchten, löschen Sie alle Zeilen, die mit sap_hana_ beginnen, oder kommentieren Sie diese aus.

   Attribut	Datentyp	Beschreibung
   Typ	String	Gibt Speicherort, Typ und Version der Deployment Manager-Vorlage an, die während der Bereitstellung verwendet werden sollen. Die YAML-Datei enthält zwei type-Spezifikationen, von denen eine auskommentiert ist. Für die standardmäßig aktive type-Spezifikation ist die Vorlagenversion als latest angegeben. Die auskommentierte type-Spezifikation gibt eine bestimmte Vorlagenversion mit einem Zeitstempel an. Wenn Sie möchten, dass alle Ihre Bereitstellungen die gleiche Vorlagenversion nutzen, verwenden Sie die type-Spezifikation, die den Zeitstempel enthält.
   instanceName	String	Der Name der VM-Instanz, die derzeit definiert ist. Geben Sie in der primären und sekundären VM-Definition unterschiedliche Namen an. Namen dürfen nur Kleinbuchstaben, Ziffern und Bindestriche enthalten.
   instanceType	String	Der Typ der virtuellen Maschine in Compute Engine, auf der Sie SAP HANA ausführen müssen. Wenn Sie einen benutzerdefinierten VM-Typ benötigen, geben Sie einen vordefinierten VM-Typ mit einer Anzahl an vCPUs an, die der benötigten Anzahl am nächsten kommt, aber noch darüber liegt. Wenn die Bereitstellung abgeschlossen ist, ändern Sie die Anzahl der vCPUs und den Umfang des Arbeitsspeichers.
   zone	String	Die Google Cloud-Zone, in der die von Ihnen definierte VM-Instanz bereitgestellt werden soll. Geben Sie für die primäre und sekundäre HANA-Definition verschiedene Zonen in derselben Region an. Die Zonen müssen sich in derselben Region befinden, die Sie für Ihr Subnetz ausgewählt haben.
   subnetwork	String	Name des Subnetzes, das Sie in einem vorherigen Schritt erstellt haben. Wenn das Deployment in einer freigegebenen VPC erfolgt, geben Sie diesen Wert im Format [SHAREDVPC_PROJECT]/[SUBNETWORK] an. Beispiel: myproject/network1.
   linuxImage	String	Der Name des Linux-Betriebssystem-Images bzw. der Linux-Image-Familie, die Sie mit SAP HANA verwenden. Wenn Sie eine Image-Familie angeben möchten, ergänzen Sie den Familiennamen durch das Präfix family/. Beispiel: family/rhel-7-6-sap-ha. Wenn Sie ein bestimmtes Image verwenden möchten, geben Sie nur dessen Namen an. Eine Liste der verfügbaren Images und Familien finden Sie in der Google Cloud Console auf der Seite „Images“.
   linuxImageProject	String	Das Google Cloud-Projekt, das das zu verwendende Image enthält. Dies kann Ihr eigenes Projekt oder ein Google Cloud-Image-Projekt wie rhel-sap-cloud sein. Weitere Informationen zu Google Cloud-Image-Projekten finden Sie in der Compute Engine-Dokumentation auf der Seite Images.
   sap_hana_deployment_bucket	String	Name des Cloud Storage-Buckets in Ihrem Projekt, der die von Ihnen in einem vorherigen Schritt hochgeladenen SAP HANA-Installations- und Aktualisierungsdateien enthält. Alle aktualisierten Dateiversionen im Bucket werden während des Bereitstellungsprozesses auf SAP HANA angewendet.
   sap_hana_sid	String	Die ID des SAP HANA-Systems (SID). Die ID muss aus drei alphanumerischen Zeichen bestehen und mit einem Buchstaben beginnen. Alle Buchstaben müssen Großbuchstaben sein.
   sap_hana_instance_number	Ganzzahl	Instanznummer (0 bis 99) des SAP HANA-Systems. Der Standardwert ist 0.
   sap_hana_sidadm_password	String	Das Passwort für den Betriebssystemadministrator. Passwörter müssen mindestens acht Zeichen lang sein und mindestens einen Großbuchstaben, einen Kleinbuchstaben und eine Ziffer enthalten. Achtung: Ändern Sie das Passwort nach Abschluss der Installation.
   sap_hana_system_password	String	Das Passwort für den Datenbank-Superuser. Passwörter müssen mindestens acht Zeichen lang sein und mindestens einen Großbuchstaben, einen Kleinbuchstaben und eine Ziffer enthalten. Achtung: Ändern Sie das Passwort nach Abschluss der Installation.
   sap_hana_sidadm_uid	Integer	Der Standardwert für die SID_LCadm-Nutzer-ID lautet 900, um zu verhindern, dass von Nutzern erstellte Gruppen im Konflikt mit SAP HANA stehen. Sie können diesen Wert bei Bedarf ändern.
   sap_hana_sapsys_gid	Integer	Die Standard-Gruppen-ID für sapsys ist 79. Durch Angabe eines höheren Werts können Sie diesen Wert entsprechend Ihren Anforderungen überschreiben.
   sap_hana_scaleout_nodes	Integer	Geben Sie 0 an. Diese Anleitung gilt nur für vertikal skalierbare SAP HANA-Systeme.
   networkTag	String	Ein Netzwerk-Tag, das Ihre VM-Instanz für Firewall- oder Routing-Zwecke repräsentiert. Wenn Sie zwar publicIP: No, aber kein Netzwerk-Tag angeben, müssen Sie eine andere Möglichkeit für den Zugriff auf das Internet bereitstellen.
   nic_type	String	Optional, aber empfohlen, sofern für die Zielmaschine und die Betriebssystemversion verfügbar. Gibt die Netzwerkschnittstelle an, die mit der VM-Instanz verwendet werden soll. Sie können den Wert GVNIC oder VIRTIO_NET angeben. Wenn Sie eine Google Virtual NIC (gVNIC) verwenden möchten, müssen Sie ein Betriebssystem-Image angeben, das gVNIC als Wert für das Attribut linuxImage unterstützt. Eine Liste der Betriebssystem-Images finden Sie unter Details zu Betriebssystemen. Wenn Sie für dieses Attribut keinen Wert angeben, wird die Netzwerkschnittstelle automatisch basierend auf dem Maschinentyp ausgewählt, den Sie für das Attribut instanceType angeben. Dieses Argument ist in den Deployment Manager-Vorlagenversionen 202302060649 oder höher verfügbar.
   publicIP	Boolesch	Optional. Legt fest, ob Ihre VM-Instanz eine öffentliche IP-Adresse erhält. Der Standardwert ist Yes. Hinweis: Geben Sie No nur an, wenn Sie ein NAT-Gateway mit einem für die VM definierten Netzwerk-Tag konfiguriert oder für die VM eine andere Route zum Internet bereitgestellt haben. Wenn keine Route zum Internet angegeben ist, schlägt die Installation fehl.
   serviceAccount	String	Optional. Gibt ein Dienstkonto an, das von den Host-VMs und den darauf ausgeführten Programmen verwendet werden soll. Geben Sie die E-Mail-Adresse des Dienstkontos an. Beispiel: [e-mail]. Standardmäßig wird das Compute Engine-Standarddienstkonto verwendet. Weitere Informationen finden Sie unter Identitäts- und Zugriffsverwaltung für SAP-Programme in Google Cloud.

7. Erstellen Sie die Definition des sekundären SAP HANA-Systems, indem Sie die Definition des primären SAP HANA-Systems kopieren und nach der Definition des primären SAP HANA-Systems einfügen. Das nach diesen Schritten folgende Beispiel veranschaulicht dies.

8. Geben Sie in der Definition des sekundären SAP HANA-Systems für die folgenden Attribute andere Werte als in der primären SAP HANA-Systemdefinition an:

   • name
   • instanceName
   • zone

9. Erstellen Sie die Instanzen:

   gcloud deployment-manager deployments create DEPLOYMENT_NAME --config TEMPLATE_NAME.yaml

   Der obige Befehl ruft Deployment Manager auf, um die VMs gemäß den Angaben in der Datei template.yaml bereitzustellen, die SAP HANA-Software aus dem Speicher-Bucket herunterzuladen und SAP HANA zu installieren.

   Die Bereitstellungsverarbeitung umfasst zwei Phasen. In der ersten Phase schreibt Deployment Manager seinen Status in die Konsole. In der zweiten Phase schreiben die Bereitstellungsskripts ihren Status in Cloud Logging.

Beispiel für eine vollständige template.yaml-Konfigurationsdatei

Das folgende Beispiel zeigt eine fertige template.yaml-Konfigurationsdatei, die zwei VM-Instanzen mit einem installierten SAP HANA-System bereitstellt.

Die Datei enthält die Definitionen der beiden Ressourcen, die bereitgestellt werden sollen: sap_hana_primary und sap_hana_secondary. Jede Ressourcendefinition enthält die Definitionen für eine VM und eine SAP HANA-Instanz.

Die Ressourcendefinition sap_hana_secondary wurde erstellt, indem die erste Definition kopiert und eingefügt und dann die Werte der Attribute name, instanceName und zone geändert wurden. Alle anderen Attributwerte in den beiden Ressourcendefinitionen sind identisch.

Die Attribute networkTag, serviceAccount, sap_hana_sidadm_uid und sap_hana_sapsys_gid stammen aus dem Abschnitt "Erweiterte Optionen" der Vorlage für die Konfigurationsdatei. Die Attribute sap_hana_sidadm_uid und sap_hana_sapsys_gid werden eingeschlossen, um ihre Standardwerte anzugeben, die verwendet werden, da die Attribute auskommentiert sind.

resources:
- name: sap_hana_primary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-1
    instanceType: n2-highmem-32
    zone: us-central1-a
    subnetwork: example-subnet-us-central1
    linuxImage: family/rhel-8-1-sap-ha
    linuxImageProject: rhel-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Tempa55word
    sap_hana_system_password: Tempa55word
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: [e-mail]
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

- name: sap_hana_secondary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-2
    instanceType: n2-highmem-32
    zone: us-central1-c
    subnetwork: example-subnet-us-central1
    linuxImage: family/rhel-8-1-sap-ha
    linuxImageProject: rhel-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Google123
    sap_hana_system_password: Google123
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: [e-mail]
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79
    

Firewallregeln erstellen, die den Zugriff auf die Host-VMs zulassen

Erstellen Sie gegebenenfalls Firewallregeln, die von den folgenden Quellen Zugriff auf jede Host-VM erlauben:

• Zu Konfigurationszwecken von Ihrer lokalen Workstation, einem Bastion Host oder Jump-Server
• Für den Zugriff zwischen den Clusterknoten von den anderen Host-VMs im Hochverfügbarkeitscluster

Wenn Sie VPC-Firewallregeln erstellen, geben Sie die Netzwerk-Tags an, die Sie in der Konfigurationsdatei template.yaml definiert haben, um Ihre Host-VMs als Ziel für die Regel festzulegen.

Definieren Sie zum Prüfen der Bereitstellung eine Regel, die SSH-Verbindungen von einem Bastion Host oder Ihrer lokalen Workstation an Port 22 zulässt.

Fügen Sie für den Zugriff zwischen den Clusterknoten eine Firewallregel hinzu, die alle Verbindungstypen von anderen VMs im selben Subnetzwerk an allen Ports zulässt.

Achten Sie darauf, die Firewallregeln zum Prüfen der Bereitstellung und für die Kommunikation zwischen den Clustern zu erstellen, bevor Sie mit dem nächsten Abschnitt fortfahren. Eine Anleitung finden Sie unter Firewallregeln hinzufügen.

Bereitstellung der VMs und von SAP HANA prüfen

Prüfen Sie zum Überprüfen der Bereitstellung die Bereitstellungslogs in Cloud Logging sowie die Laufwerke und Dienste auf den VMs des primären und sekundären Hosts.

1. Öffnen Sie in der Google Cloud Console „Cloud Logging“, um den Installationsfortschritt zu überwachen und nach Fehlern zu suchen.

   Hinweis: Wenn Sie diesen Schritt in Cloud Logging ausführen, können Kosten anfallen. Weitere Informationen finden Sie unter Cloud Logging – Preise.

   Zu Cloud Logging

2. Filtern Sie die Logs:

   Log-Explorer

   1. Wechseln Sie auf der Seite Log-Explorer zum Bereich Abfrage.

   2. Wählen Sie im Drop-down-Menü Ressource die Option Global aus und klicken Sie dann auf Hinzufügen.

      Wenn die Option Global nicht angezeigt wird, geben Sie im Abfrageeditor die folgende Abfrage ein:

      resource.type="global"
      "Deployment"
      

   3. Klicken Sie auf Abfrage ausführen.

   Legacy-Loganzeige

   • Wählen Sie auf der Seite Legacy-Loganzeige im einfachen Auswahlmenü die Option Global als Logging-Ressource aus.

3. Analysieren Sie die gefilterten Logs:

   • Wenn "--- Finished" angezeigt wird, ist die Verarbeitung des Deployments abgeschlossen und Sie können mit dem nächsten Schritt fortfahren.

   • Wenn ein Kontingentfehler auftritt:

     1. Erhöhen Sie auf der Seite IAM & Verwaltung > Kontingente alle Kontingente, die nicht die im Planungsleitfaden für SAP HANA aufgeführten Anforderungen erfüllen.

     2. Löschen Sie in Deployment Manager auf der Seite Deployments die Bereitstellung, um VMs und nichtflüchtige Speicher von der fehlgeschlagenen Installation zu bereinigen.

     3. Führen Sie die Bereitstellung noch einmal aus.

Konfiguration der VMs und von SAP HANA prüfen

1. Wenn das SAP HANA-System fehlerfrei bereitgestellt wurde, stellen Sie eine SSH-Verbindung zu jeder VM her. Sie können hierfür wahlweise in Compute Engine auf der Seite mit den VM-Instanzen neben jeder VM-Instanz auf die Schaltfläche "SSH" klicken oder Ihre bevorzugte SSH-Methode verwenden.

   

2. Wechseln Sie zum Root-Nutzer.

   $ sudo su -

3. Geben Sie bei der Eingabeaufforderung df -h ein. Achten Sie darauf, dass Sie auf jeder VM die /hana-Verzeichnisse sehen, z. B. /hana/data.

   Filesystem                        Size  Used Avail Use% Mounted on
   /dev/sda2                          30G  4.0G   26G  14% /
   devtmpfs                          126G     0  126G   0% /dev
   tmpfs                             126G     0  126G   0% /dev/shm
   tmpfs                             126G   17M  126G   1% /run
   tmpfs                             126G     0  126G   0% /sys/fs/cgroup
   /dev/sda1                         200M  9.7M  191M   5% /boot/efi
   /dev/mapper/vg_hana-shared        251G   49G  203G  20% /hana/shared
   /dev/mapper/vg_hana-sap            32G  240M   32G   1% /usr/sap
   /dev/mapper/vg_hana-data          426G  7.0G  419G   2% /hana/data
   /dev/mapper/vg_hana-log           125G  4.2G  121G   4% /hana/log
   /dev/mapper/vg_hanabackup-backup  512G   33M  512G   1% /hanabackup
   tmpfs                              26G     0   26G   0% /run/user/900
   tmpfs                              26G     0   26G   0% /run/user/899
   tmpfs                              26G     0   26G   0% /run/user/1000

4. Wechseln Sie zum SAP-Administrator. Ersetzen Sie dazu im folgenden Befehl SID_LC durch die System-ID, die Sie in der Vorlage für die Konfigurationsdatei angegeben haben. Verwenden Sie Kleinschreibung für Buchstaben.

   # su - SID_LCadm

5. Prüfen Sie, ob die SAP HANA-Dienste wie u. a. hdbnameserver und hdbindexserver auf der Instanz ausgeführt werden. Geben Sie dazu den folgenden Befehl ein:

   > HDB info

6. Wenn Sie RHEL für SAP 9.0 oder höher verwenden, achten Sie darauf, dass die Pakete chkconfig und compat-openssl11 auf Ihrer VM-Instanz installiert sind.

   Weitere Informationen von SAP finden Sie im SAP-Hinweis 3108316 – Red Hat Enterprise Linux 9.x: Installation und Konfiguration.

Installation des Google Cloud-Agents für SAP prüfen

Nachdem Sie eine VM bereitgestellt und Ihr SAP-System installiert haben, prüfen Sie, ob der Google Cloud-Agent für SAP ordnungsgemäß funktioniert.

Ausführung des Google Cloud-Agents für SAP prüfen

So prüfen Sie, ob der Agent ausgeführt wird:

1. Stellen Sie eine SSH-Verbindung zu Ihrer Host-VM-Instanz her.

2. Führen Sie dazu diesen Befehl aus:

   systemctl status google-cloud-sap-agent

   Wenn der Agent ordnungsgemäß funktioniert, enthält die Ausgabe active (running). Beispiel:

   google-cloud-sap-agent.service - Google Cloud Agent for SAP
   Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled)
   Active:  active (running)  since Fri 2022-12-02 07:21:42 UTC; 4 days ago
   Main PID: 1337673 (google-cloud-sa)
   Tasks: 9 (limit: 100427)
   Memory: 22.4 M (max: 1.0G limit: 1.0G)
   CGroup: /system.slice/google-cloud-sap-agent.service
          └─1337673 /usr/bin/google-cloud-sap-agent
   

Wenn der Agent nicht ausgeführt wird, starten Sie den Agent neu.

Prüfen, ob der SAP-Host-Agent Messwerte empfängt

Führen Sie die folgenden Schritte aus, um zu prüfen, ob die Infrastrukturmesswerte vom Agent von Google Cloud für SAP erfasst und korrekt an den SAP-Host-Agent gesendet werden:

1. Geben Sie in Ihrem SAP-System Transaktion ST06 ein.

2. Kontrollieren Sie im Übersichtsbereich die Verfügbarkeit und den Inhalt der folgenden Felder, um die korrekte End-to-End-Einrichtung der SAP- und Google-Monitoring-Infrastruktur zu überprüfen:

   • Cloud-Anbieter: Google Cloud Platform
   • Zugriff für erweitertes Monitoring: TRUE
   • Details für erweitertes Monitoring: ACTIVE

Monitoring für SAP HANA einrichten

Optional können Sie Ihre SAP HANA-Instanzen mit dem Google Cloud-Agent für SAP überwachen. In Version 2.0 können Sie den Agent so konfigurieren, dass er die SAP HANA-Monitoring-Messwerte erfasst und an Cloud Monitoring sendet. Mit Cloud Monitoring lassen sich Dashboards erstellen, um diese Messwerte zu visualisieren, Benachrichtigungen anhand von Messwertschwellen einzurichten und vieles mehr.

Weitere Informationen zur Erfassung von SAP HANA-Monitoring-Messwerten mit dem Google Cloud-Agent für SAP finden Sie unter SAP HANA-Monitoring-Messwerte erfassen.

SAP HANA Fast Restart aktivieren

Google Cloud empfiehlt dringend die Aktivierung von SAP HANA Fast Restart für jede Instanz von SAP HANA, insbesondere bei größeren Instanzen. SAP HANA Fast Restart verkürzt die Neustartzeit, wenn SAP HANA beendet wird, das Betriebssystem jedoch weiter ausgeführt wird.

Hinweis: Wenn Sie SAP HANA mit dem Terraform-Modul sap_hana oder sap_hana_ha von Google Cloud, Version 202309280828 oder höher bereitstellen, ist Fast Restart automatisch aktiviert.

In der Konfiguration der von Google Cloud bereitgestellten Automatisierungsskripts unterstützen die Betriebssystem- und Kerneleinstellungen bereits SAP HANA Fast Restart. Sie müssen das tmpfs-Dateisystem definieren und SAP HANA konfigurieren.

Zum Definieren des Dateisystems tmpfs und zum Konfigurieren von SAP HANA können Sie den manuellen Schritten folgen oder das von Google Cloud bereitgestellte Automatisierungsskript verwenden, um SAP HANA Fast Restart zu aktivieren. Weitere Informationen finden Sie hier:

• Manuelle Schritte: SAP HANA Fast Restart aktivieren
• Automatisierte Schritte: SAP HANA Fast Restart aktivieren

Die Anleitungen für SAP HANA Fast Restart finden Sie in der Dokumentation zu SAP HANA Fast Restart.

Manuelle Schritte

tmpfs-Dateisystem konfigurieren

Nachdem die Host-VMs und die SAP HANA-Basissysteme erfolgreich bereitgestellt wurden, müssen Sie Verzeichnisse für die NUMA-Knoten im tmpfs-Dateisystem erstellen und bereitstellen.

NUMA-Topologie Ihrer VM anzeigen lassen

Bevor Sie das erforderliche tmpfs-Dateisystem zuordnen können, müssen Sie wissen, wie viele NUMA-Knoten Ihre VM hat. Geben Sie den folgenden Befehl ein, um die verfügbaren NUMA-Knoten auf einer Compute Engine-VM anzeigen zu lassen:

lscpu | grep NUMA

Der VM-Typ m2-ultramem-208 hat beispielsweise vier NUMA-Knoten mit der Nummerierung 0–3, wie im folgenden Beispiel gezeigt:

NUMA node(s):        4
NUMA node0 CPU(s):   0-25,104-129
NUMA node1 CPU(s):   26-51,130-155
NUMA node2 CPU(s):   52-77,156-181
NUMA node3 CPU(s):   78-103,182-207

NUMA-Knotenverzeichnisse erstellen

Erstellen Sie ein Verzeichnis für jeden NUMA-Knoten in Ihrer VM und legen Sie die Berechtigungen fest.

Beispiel für vier NUMA-Knoten mit der Nummerierung 0–3:

mkdir -pv /hana/tmpfs{0..3}/SID
chown -R SID_LCadm:sapsys /hana/tmpfs*/SID
chmod 777 -R /hana/tmpfs*/SID

NUMA-Knotenverzeichnisse unter tmpfs bereitstellen

Stellen Sie die Verzeichnisse des tmpfs-Dateisystems bereit und geben Sie für mpol=prefer jeweils eine NUMA-Knoteneinstellung an:

SID: Geben Sie die SID in Großbuchstaben an.

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0 /hana/tmpfs0/SID
mount tmpfsSID1 -t tmpfs -o mpol=prefer:1 /hana/tmpfs1/SID
mount tmpfsSID2 -t tmpfs -o mpol=prefer:2 /hana/tmpfs2/SID
mount tmpfsSID3 -t tmpfs -o mpol=prefer:3 /hana/tmpfs3/SID

Hinweis: Wenn Sie die Maschinentypen ändern und sich die Anzahl der NUMA-Knoten erhöht oder verringert, müssen Sie das tmpfs-Dateisystem und den Abschnitt [persistence] der SAP HANA-INI-Datei ändern, wie im nächsten Abschnitt dargestellt, um die neue Anzahl von NUMA-Knoten abzugleichen.

/etc/fstab aktualisieren

Fügen Sie der Dateisystemtabelle /etc/fstab Einträge hinzu, damit die Bereitstellungspunkte nach dem Neustart eines Betriebssystems verfügbar sind:

tmpfsSID0 /hana/tmpfs0/SID tmpfs rw,relatime,mpol=prefer:0
tmpfsSID1 /hana/tmpfs1/SID tmpfs rw,relatime,mpol=prefer:1
tmpfsSID1 /hana/tmpfs2/SID tmpfs rw,relatime,mpol=prefer:2
tmpfsSID1 /hana/tmpfs3/SID tmpfs rw,relatime,mpol=prefer:3

Optional: Limits für die Speichernutzung festlegen

Das tmpfs-Dateisystem kann dynamisch wachsen und schrumpfen.

Wenn Sie den vom tmpfs-Dateisystem verwendeten Speicher begrenzen möchten, können Sie mit der Option size eine Größenbeschränkung für ein NUMA-Knoten-Volume festlegen. Beispiel:

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0,size=250G /hana/tmpfs0/SID

Sie können auch die tmpfs-Speichernutzung für alle NUMA-Knoten für eine bestimmte SAP-HANA-Instanz und einen bestimmten Serverknoten begrenzen, indem Sie den Parameter persistent_memory_global_allocation_limit im Abschnitt [memorymanager] der Datei global.ini festlegen.

SAP HANA-Konfiguration für Fast Restart

Um SAP HANA für Fast Restart zu konfigurieren, aktualisieren Sie die Datei global.ini und geben Sie die Tabellen an, die im nichtflüchtigen Speicher gespeichert werden sollen.

Aktualisieren Sie den Abschnitt [persistence] in der Datei global.ini.

Konfigurieren Sie den Abschnitt [persistence] in der SAP HANA-Datei global.ini, um auf die tmpfs-Standorte zu verweisen. Trennen Sie die einzelnen tmpfs-Standorte durch ein Semikolon:

[persistence]
basepath_datavolumes = /hana/data
basepath_logvolumes = /hana/log
basepath_persistent_memory_volumes = /hana/tmpfs0/SID;/hana/tmpfs1/SID;/hana/tmpfs2/SID;/hana/tmpfs3/SID

Im vorherigen Beispiel werden vier Arbeitsspeicher-Volumes für vier NUMA-Knoten angegeben, die m2-ultramem-208 entspricht. Bei der Ausführung auf m2-ultramem-416 müssten Sie acht Arbeitsspeicher-Volumes (0..7) konfigurieren.

Starten Sie SAP HANA neu, nachdem Sie die Datei global.ini geändert haben.

SAP HANA kann jetzt den Standort tmpfs als nichtflüchtigen Speicherbereich verwenden.

Tabellen angeben, die im nichtflüchtigen Speicher gespeichert werden sollen

Geben Sie bestimmte Spaltentabellen oder Partitionen an, die im nichtflüchtigen Speicher gespeichert werden sollen.

Wenn Sie beispielsweise nichtflüchtigen Speicher für eine vorhandene Tabelle aktivieren möchten, führen Sie diese SQL-Abfrage aus:

ALTER TABLE exampletable persistent memory ON immediate CASCADE

Um den Standardwert für neue Tabellen zu ändern, fügen Sie den Parameter table_default zur Datei indexserver.ini hinzu. Beispiel:

[persistent_memory]
table_default = ON

Weitere Informationen zur Steuerung von Spalten, Tabellen und dazu, welche Monitoringansichten detaillierte Informationen enthalten, finden Sie unter Nichtflüchtiger SAP HANA-Speicher.

Automatisierte Schritte

Das von Google Cloud bereitgestellte Automatisierungsskript zum Aktivieren von SAP HANA Fast Restart nimmt Änderungen an den Verzeichnissen /hana/tmpfs*, der Datei /etc/fstab und der SAP HANA-Konfiguration vor. Wenn Sie das Script ausführen, müssen Sie möglicherweise zusätzliche Schritte ausführen, je nachdem, ob es sich um die anfängliche Bereitstellung Ihres SAP HANA-Systems handelt oder Sie die Größe Ihrer Maschine in eine andere NUMA-Größe ändern.

Achten Sie bei der ersten Bereitstellung Ihres SAP HANA-Systems oder bei der Größenanpassung der Maschine zur Erhöhung der Anzahl der NUMA-Knoten darauf, dass SAP HANA während der Ausführung des Automatisierungsskripts ausgeführt wird, das Google Cloud zur Aktivierung von SAP HANA Fast Restart bereitstellt.

Wenn Sie die Größe der Maschine ändern, um die Anzahl der NUMA-Knoten zu verringern, müssen Sie darauf achten, dass SAP HANA während der Ausführung des Automatisierungsskripts gestoppt wird, das Google Cloud zur Aktivierung von SAP HANA Fast Restart bereitstellt. Nachdem das Script ausgeführt wurde, müssen Sie die SAP HANA-Konfiguration manuell aktualisieren, um die Einrichtung von SAP HANA Fast Restart abzuschließen. Weitere Informationen finden Sie unter SAP HANA-Konfiguration für Fast Restart.

Hinweis: Wir empfehlen dringend, das von Google Cloud bereitgestellte Script auszuführen, um SAP HANA Fast Restart in einer Nicht-Produktionsumgebung zu aktivieren, und die Ergebnisse vor der Ausführung des Script in Produktionsumgebungen sorgfältig zu prüfen. Sie übernehmen die Verantwortung für die ordnungsgemäße Aktivierung von SAP HANA Fast Restart.

So aktivieren Sie SAP HANA Fast Restart:

1. Stellen Sie eine SSH-Verbindung zu Ihrer Host-VM her.

2. Wechseln Sie zum Root:

   sudo su -

3. Laden Sie das sap_lib_hdbfr.sh-Skript herunter:

   wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/lib/sap_lib_hdbfr.sh

4. Machen Sie die Datei ausführbar:

   chmod +x sap_lib_hdbfr.sh

5. Prüfen Sie, ob das Script Fehler enthält:

   vi sap_lib_hdbfr.sh
   ./sap_lib_hdbfr.sh -help

   Wenn der Befehl einen Fehler zurückgibt, wenden Sie sich an Cloud Customer Care. Weitere Informationen zur Kontaktaufnahme mit Customer Care finden Sie unter Support für SAP in Google Cloud.

6. Führen Sie das Script aus, nachdem Sie die SAP HANA-System-ID (SID) und das Passwort für den SYSTEM-Nutzer der SAP HANA-Datenbank ersetzt haben. Damit Sie das Passwort sicher bereitstellen können, empfehlen wir die Verwendung eines Secrets in Secret Manager.

   Führen Sie das Script mit dem Namen eines Secrets in Secret Manager aus. Dieses Secret muss in dem Google Cloud-Projekt vorhanden sein, das Ihre Host-VM-Instanz enthält.

   sudo ./sap_lib_hdbfr.sh -h 'SID' -s SECRET_NAME 

   Ersetzen Sie Folgendes:

   • SID: Geben Sie die SID in Großbuchstaben an. Beispiel: AHA.
   • SECRET_NAME: Geben Sie den Namen des Secrets an, das dem Passwort für den SYSTEM-Nutzer der SAP HANA-Datenbank entspricht. Dieses Secret muss in dem Google Cloud-Projekt vorhanden sein, das Ihre Host-VM-Instanz enthält.

   Alternativ können Sie das Script mit einem Nur-Text-Passwort ausführen. Nachdem SAP HANA Fast Restart aktiviert wurde, müssen Sie Ihr Passwort ändern. Die Verwendung eines Nur-Text-Passworts wird nicht empfohlen, da Ihr Passwort im Befehlszeilenverlauf Ihrer VM aufgezeichnet werden würde.

   sudo ./sap_lib_hdbfr.sh -h 'SID' -p 'PASSWORD'

   Ersetzen Sie Folgendes:

   • SID: Geben Sie die SID in Großbuchstaben an. Beispiel: AHA.
   • PASSWORD: Geben Sie das Passwort für den SYSTEM-Nutzer der SAP HANA-Datenbank an.

Bei einer erfolgreichen ersten Ausführung sollte die Ausgabe in etwa so aussehen:

INFO - Script is running in standalone mode
ls: cannot access '/hana/tmpfs*': No such file or directory
INFO - Setting up HANA Fast Restart for system 'TST/00'.
INFO - Number of NUMA nodes is 2
INFO - Number of directories /hana/tmpfs* is 0
INFO - HANA version 2.57
INFO - No directories /hana/tmpfs* exist. Assuming initial setup.
INFO - Creating 2 directories /hana/tmpfs* and mounting them
INFO - Adding /hana/tmpfs* entries to /etc/fstab. Copy is in /etc/fstab.20220625_030839
INFO - Updating the HANA configuration.
INFO - Running command: select * from dummy
DUMMY
"X"
1 row selected (overall time 4124 usec; server time 130 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistence', 'basepath_persistent_memory_volumes') = '/hana/tmpfs0/TST;/hana/tmpfs1/TST;'
0 rows affected (overall time 3570 usec; server time 2239 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistent_memory', 'table_unload_action') = 'retain';
0 rows affected (overall time 4308 usec; server time 2441 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM') SET ('persistent_memory', 'table_default') = 'ON';
0 rows affected (overall time 3422 usec; server time 2152 usec)

Optional: SSH-Schlüssel auf der primären und sekundären VM konfigurieren

Die SSFS-Schlüssel (SAP HANA Secure Store) müssen im Hochverfügbarkeitscluster zwischen den Hosts synchronisiert werden. Diese Anweisungen autorisieren direkte SSH-Verbindungen zwischen den beiden Hosts, um die Synchronisierung zu vereinfachen und das Kopieren von Dateien wie Sicherungen zwischen den Hosts im Hochverfügbarkeitscluster zu ermöglichen.

In Ihrer Organisation gelten wahrscheinlich Richtlinien, die die interne Netzwerkkommunikation regeln. Bei Bedarf können Sie nach Abschluss der Bereitstellung die Metadaten aus den VMs und die Schlüssel aus dem Verzeichnis authorized_keys entfernen.

Wenn das Einrichten direkter SSH-Verbindungen nicht den Richtlinien Ihrer Organisation entspricht, können Sie die SSFS-Schlüssel synchronisieren und Dateien mit anderen Methoden übertragen. Beispiele:

• Übertragen Sie kleinere Dateien über Ihre lokale Workstation mithilfe der Cloud Shell-Menüoptionen Datei hochladen und Datei herunterladen. Siehe dazu Dateien mit Cloud Shell verwalten.
• Tauschen Sie Dateien mithilfe eines Google Cloud Storage-Buckets aus. Siehe dazu Mit Objekten arbeiten in der Cloud Storage-Dokumentation.
• Verwenden Sie den Cloud Storage-Backint-Agent für SAP HANA, um HANA-Datenbanken zu sichern und wiederherzustellen. Siehe dazu Cloud Storage-Backint-Agent für SAP HANA.
• Verwenden Sie eine Dateispeicherlösung wie Filestore oder den NetApp Cloud Volumes-Dienst, um einen freigegebenen Ordner zu erstellen. Siehe Dateiserveroptionen.

So aktivieren Sie SSH-Verbindungen zwischen der primären und der sekundären Instanz:

1. Auf der primären Host-VM:

   1. Stellen Sie eine SSH-Verbindung zur VM her.

   2. Generieren Sie einen SSH-Schlüssel für den Nutzer, der die SSH-Verbindung zwischen den Hosts benötigt. Dieser Nutzer sind in der Regel Sie.

      $ ssh-keygen

   3. Akzeptieren Sie die Standardeinstellungen, wenn Sie dazu aufgefordert werden, mit der Eingabetaste.

   4. Aktualisieren Sie die Metadaten der primären VM mit Informationen zum SSH-Schlüssel für die sekundäre VM.

      $ gcloud compute instances add-metadata secondary-host-name \
           --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
           --zone secondary-zone

   5. Autorisieren Sie die primäre VM für sich selbst.

      $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

2. Auf der sekundären Host-VM:

   1. Stellen Sie eine SSH-Verbindung zur VM her.

   2. Generieren Sie einen SSH-Schlüssel für den Nutzer, der die SSH-Verbindung zwischen den Hosts benötigt.

      $ ssh-keygen

   3. Aktualisieren Sie die Metadaten der sekundären VM mit Informationen zum SSH-Schlüssel für die primäre VM.

      $ gcloud compute instances add-metadata primary-host-name \
            --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
            --zone primary-zone

   4. Autorisieren Sie die sekundäre VM für sich selbst.

      $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

   5. Prüfen Sie, ob die SSH-Schlüssel ordnungsgemäß eingerichtet sind. Stellen Sie dazu eine SSH-Verbindung vom sekundären zum primären System her.

      $ ssh primary-host-name

3. Prüfen Sie auf der primären Host-VM die Verbindung, indem Sie eine SSH-Verbindung zur sekundären Host-VM herstellen:

   $ ssh secondary-host-name

Datenbanken sichern

Erstellen Sie Sicherungen Ihrer Datenbanken, um das Datenbank-Logging für die SAP HANA-Systemreplikation zu initiieren und einen Wiederherstellungspunkt zu erstellen.

Wenn Sie in einer MDC-Konfiguration mehrere Mandantendatenbanken haben, sichern Sie sie alle.

Die Deployment Manager-Vorlage verwendet /hanabackup/data/SID als Standardsicherungsverzeichnis.

So erstellen Sie Sicherungen von neuen SAP HANA-Datenbanken:

1. Wechseln Sie auf dem primären Host zu SID_LCadm. Je nach Betriebssystem-Image kann der Befehl unterschiedlich sein.

   sudo -i -u SID_LCadm

2. Erstellen Sie die Datenbanksicherungen:

   • Für ein SAP HANA-System mit Container für eine einzelne Datenbank:

     > hdbsql -t -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

     Das folgende Beispiel zeigt eine positive Antwort von einem neuen SAP HANA-System:

     0 rows affected (overall time 18.416058 sec; server time 18.414209 sec)

   • Erstellen Sie für ein SAP HANA-System mit Container für mehrere Datenbanken (MDC) eine Sicherung der Systemdatenbank sowie aller Mandantendatenbanken:

     > hdbsql -t -d SYSTEMDB -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

     > hdbsql -t -d SID -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

   Das folgende Beispiel zeigt eine positive Antwort von einem neuen SAP HANA-System:

   0 rows affected (overall time 16.590498 sec; server time 16.588806 sec)

3. Prüfen Sie, ob der Logging-Modus auf "normal" eingestellt ist:

   > hdbsql -u system -p SYSTEM_PASSWORD -i INST_NUM \
     "select value from "SYS"."M_INIFILE_CONTENTS" where key='log_mode'"

   Hier sollten Sie das sehen:

   VALUE
   "normal"

SAP HANA-Systemreplikation aktivieren

Im Rahmen der Aktivierung der SAP HANA-Systemreplikation müssen Sie die Daten und Schlüsseldateien für die sicheren SAP HANA-Speicher im Dateisystem (Secure Storage in File System, SSFS) vom primären zum sekundären Host kopieren. Die hier beschriebene Methode zum Kopieren der Dateien ist nur eine von mehreren möglichen Optionen.

1. Aktivieren Sie als SID_LCadm auf dem primären Host die Systemreplikation:

   > hdbnsutil -sr_enable --name=primary-host-name

2. Beenden Sie SAP HANA als SID_LCadm auf dem sekundären Host:

   > HDB stop

3. Kopieren Sie mit demselben Nutzerkonto, mit dem Sie SSH zwischen den Host-VMs eingerichtet haben, die Schlüsseldateien vom primären auf den sekundären Host. Der Einfachheit halber definieren die folgenden Befehle auch eine Umgebungsvariable für Ihre Nutzerkonto-ID:

   $ sudo cp /usr/sap/SID/SYS/global/security/rsecssfs ~/rsecssfs -r
   $ myid=$(whoami)
   $ sudo chown ${myid} -R /home/"${myid}"/rsecssfs
   $ scp -r rsecssfs $(whoami)@secondary-host-name:rsecssfs
   $ rm -r /home/"${myid}"/rsecssfs
   

4. Auf dem sekundären Host mit demselben Nutzerkonto wie im vorherigen Schritt:

   1. Ersetzen Sie die vorhandenen Schlüsseldateien in den rsecssfs-Verzeichnissen durch die Dateien des primären Hosts und legen Sie die Dateiberechtigungen fest, um den Zugriff zu beschränken:

      $ SAPSID=SID
      $ sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ myid=$(whoami)
      $ sudo cp /home/"${myid}"/rsecssfs/data/SSFS_"${SAPSID}".DAT \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo cp /home/"${myid}"/rsecssfs/key/SSFS_"${SAPSID}".KEY \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ sudo chown "${SAPSID,,}"adm:sapsys \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo chown "${SAPSID,,}"adm:sapsys \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ sudo chmod 644 \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo chmod 640 \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY

   2. Bereinigen Sie die Dateien in Ihrem Basisverzeichnis.

      $ rm -r /home/"${myid}"/rsecssfs

   3. Registrieren Sie als SID_LCadm das sekundäre SAP HANA-System bei der SAP HANA-Systemreplikation:

      > hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \
      --replicationMode=syncmem --operationMode=logreplay --name=secondary-host-name

   4. Starten Sie SAP HANA als SID_LCadm:

      > HDB start

Systemreplikation validieren

Prüfen Sie auf dem primären Host als SID_LCadm, ob die SAP HANA-Systemreplikation aktiv ist. Führen Sie dazu das folgende Python-Script aus:

$ python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py

Wenn die Replikation ordnungsgemäß eingerichtet ist, werden unter anderem für die Dienste xsengine, nameserver und indexserver die folgenden Werte angezeigt:

• Der Secondary Active Status ist YES.
• Der Replication Status ist ACTIVE.

Außerdem wird der overall system replication status als ACTIVE angezeigt.

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.

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 HANA-System. Der Load-Balancer leitet den an die VIP gesendeten Traffic an die VM weiter, die derzeit das aktive SAP HANA-System hostet.

1. Öffnen Sie Cloud Shell:

   Zu Cloud Shell

2. IP-Adresse für die virtuelle IP-Adresse reservieren. Dies ist die IP-Adresse, mit der Anwendungen auf SAP HANA 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.

3. 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: '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

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

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

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

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: '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.

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

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

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

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

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

4. 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 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 ALL

   Weitere Informationen zum regionenübergreifenden Zugriff auf Ihr SAP HANA-Hochverfügbarkeitssystem finden Sie unter Internes TCP/UDP-Load-Balancing.

Note: Your backend instance groups won't register as healthy until you have completed the Pacemaker cluster configuration.

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.

1. Installieren Sie auf beiden Host-VMs das Dienstprogramm socat:

   $ sudo yum install -y socat

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

3. 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/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:

1. Klicken Sie in der Konsole auf Ihre Systemdiagnose:

   Zur Seite "Systemdiagnosen"

2. Klicken Sie auf Bearbeiten.

3. Ändern Sie im Feld Port die Portnummer in 22.

4. Klicken Sie auf Speichern und warten Sie ein bis zwei Minuten.

5. 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/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

6. 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 HANA konfiguriert.

Das Verfahren beruht auf der Red Hat-Dokumentation zum Konfigurieren von Hochverfügbarkeitsclustern (dafür wird ein Red Hat-Abo benötigt) und umfasst Folgendes:

• Hochverfügbarkeitscluster für Red Hat Enterprise Linux 2012 (und höher) in Google Cloud installieren und konfigurieren
• Automatisierte SAP HANA-Systemreplikation beim vertikalen Skalieren im Pacemaker-Cluster

Cluster-Agents auf beiden Knoten installieren

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

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

2. Legen Sie das Passwort für den Nutzer hacluster fest, der gemeinsam mit den Paketen installiert wird:

   # passwd hacluster

3. Geben Sie in den Eingabeaufforderungen ein Passwort für hacluster an.

4. In den von Google Cloud bereitgestellten 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

5. Starten Sie den pcs-Dienst und konfigurieren Sie ihn so, dass er beim Booten startet:

   # systemctl start pcsd.service
   # systemctl enable pcsd.service

6. 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 2020-06-13 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
   Jun 13 21:17:03 hana-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
   Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.

7. 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 hana-ha-vm-1.us-central1-a.c.example-project-123456.internal hana-ha-vm-1  # Added by Google
   10.0.0.41 hana-ha-vm-2.us-central1-c.c.example-project-123456.internal hana-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

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

2. Geben Sie bei Aufforderung den Nutzernamen hacluster und das Passwort ein, das Sie für den Nutzer hacluster festgelegt haben.

3. 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 Cloud festzulegen.

1. Öffnen Sie auf beiden Hosts Ihren bevorzugten Texteditor, um die Datei /etc/corosync/corosync.conf zur Bearbeitung zu öffnen:

   # /etc/corosync/corosync.conf

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

3. 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
   }
   ...

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

5. Legen Sie fest, dass der Cluster automatisch gestartet wird:

   1. # pcs cluster enable --all

   2. # pcs cluster start --all

6. 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 Cloud spezifischen Fencing-Agent fence_gce. 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.

Hinweis: Wenn Sie die Hostnamen geändert haben, sodass sie nicht mehr mit den VM-Instanznamen übereinstimmen, lesen Sie den Abschnitt Hochverfügbarkeitscluster für Red Hat Enterprise Linux 2012 (und höher) in Google Compute Cloud installieren und konfigurieren. Für die folgenden Schritte müssen die Hostnamen und die VM-Instanznamen identisch sein.

Ressourcen für Fencing-Geräte erstellen

1. Als Root auf dem primären Host:

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

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

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

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

4. 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@hana-ha-vm-2 ~]# pcs status
   Cluster name: hana-ha-cluster
   Stack: corosync
   Current DC: hana-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 hana-ha-vm-1
   
   2 nodes configured
   2 resources configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Full list of resources:
   
    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
   
   Daemon Status:
     corosync: active/enabled
     pacemaker: active/enabled
     pcsd: active/enabled

Verzögerung für den Neustart von Corosync festlegen

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

2. Fügen Sie der Datei die folgenden Zeilen hinzu:

   [Service]
   ExecStartPre=/bin/sleep 60

3. Speichern Sie die Datei und beenden Sie den Editor.

4. Laden Sie die Konfiguration des systemd-Managers neu.

   systemctl daemon-reload

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

Provider-Hooks für SAP HANA HA/DR aktivieren

Red Hat empfiehlt, die Provider-Hooks für SAP HANA-HA/DR zu aktivieren. Dadurch kann SAP HANA Benachrichtigungen für bestimmte Ereignisse senden und die Fehlererkennung verbessern. Die Provider-Hooks für SAP HANA HA/DR erfordern SAP HANA 2.0 SPS 03 oder eine neuere Version.

Hinweis: Wenn Sie die HA/DR-Provider-Hooks auf einem vorhandenen SAP HANA-System mit Ausfallzeiten von fast null implementieren möchten, lesen Sie stattdessen die Informationen unter Betriebsanleitung für SAP HANA.

Führen Sie sowohl auf der primären als auch auf der sekundären Website die folgenden Schritte aus:

1. Beenden Sie SAP HANA als SID_LCadm:

   > HDB stop

1. Öffnen Sie als Root oder SID_LCadm die Datei global.ini zur Bearbeitung:

   > vi /hana/shared/SID/global/hdb/custom/config/global.ini

2. Fügen Sie der Datei global.ini die folgenden Definitionen hinzu:

   [ha_dr_provider_SAPHanaSR]
   provider = SAPHanaSR
   path = /usr/share/SAPHanaSR/srHook
   execution_order = 1
   
   [trace]
   ha_dr_saphanasr = info

3. Erstellen Sie als Root eine benutzerdefinierte Konfigurationsdatei im Verzeichnis /etc/sudoers.d. Führen Sie dazu den folgenden Befehl aus. Mit dieser neuen Konfigurationsdatei kann der Nutzer SID_LCadm beim Aufrufen der Hook-Methode srConnectionChanged() auf die Clusterknotenattribute zugreifen.

   > sudo visudo -f /etc/sudoers.d/20-saphana

4. Fügen Sie in der Datei /etc/sudoers.d/20-saphana den folgenden Text hinzu:

   Dabei gilt:

   • SITE_A: Standortname des primären SAP HANA-Servers.
   • SITE_B: Standortname des sekundären SAP HANA-Servers.
   • SID_LC: Die SID sollte in Kleinbuchstaben angegeben werden.
   Zum Aufrufen der Websitenamen können Sie den Befehl crm_mon -A1 | grep site als Root-Nutzer entweder auf dem primären SAP HANA-Server oder auf dem sekundären Server ausführen.

   Cmnd_Alias SITEA_SOK = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SITEA_SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SFAIL -t crm_config -s SAPHanaSR
   Cmnd_Alias SITEB_SOK = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SITEB_SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SFAIL -t crm_config -s SAPHanaSR
   SID_LCadm ALL=(ALL) NOPASSWD: SITEA_SOK, SITEA_SFAIL, SITEB_SOK, SITEB_SFAIL
   Defaults!SITEA_SOK, SITEA_SFAIL, SITEB_SOK, SITEB_SFAIL !requiretty

5. Achten Sie darauf, dass in der Datei /etc/sudoers der folgende Text enthalten ist:

   #includedir /etc/sudoers.d

   Beachten Sie, dass die Datei # in diesem Text Teil der Syntax ist und nicht bedeutet, dass die Zeile ein Kommentar ist.

Hinweis: Das Verfahren in diesem Abschnitt wird von Red Hat empfohlen, Sie können jedoch einen alternativen Ansatz verwenden. Anstatt eine Drop-in-Konfigurationsdatei zu erstellen, können Sie den erforderlichen Zugriff direkt auf die Datei /etc/sudoers einfügen.

6. Starten Sie SAP HANA als SID_LCadm:

   > HDB start

7. Testen Sie auf dem primären Host als SID_LCadm den vom Hook-Skript gemeldeten Status:

   > cdtrace
   > awk '/ha_dr_SAPHanaSR.*crm_attribute/ { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*

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.

1. Starten Sie als Root den Cluster auf einem der Hosts:

   # pcs cluster start --all #start the cluster

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

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

4. Folgende Clusterattribute festlegen:

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

   Hinweis: Geben Sie nicht no-quorum-policy = ignore an. Der Wert ignore wird nicht mehr unterstützt.

Ressource SAPHanaTopology erstellen

Die Ressource SAPHanaTopology ruft den Status und die Konfiguration der HANA-Systemreplikation auf den Knoten ab. Außerdem wird der SAP-Host-Agent geprüft.

1. Erstellen Sie als Root auf einem Host die Ressource SAPHanaTopology:

   # pcs resource create topology_resource_name SAPHanaTopology SID=SID \
      InstanceNumber=inst_num \
      op start timeout=600 \
      op stop timeout=300 \
      op monitor interval=10 timeout=600 \
      clone clone-max=2 clone-node-max=1 interleave=true

2. Nachdem die Ressource erstellt wurde, prüfen Sie die Konfiguration. Hängen Sie -clone an den Ressourcennamen an, um die Informationen zum Klonsatz in die Antwort aufzunehmen:

   RHEL 8 und höher:

   # pcs resource config topology_resource_name-clone

   RHEL 7

   # pcs resource show topology_resource_name-clone

   Die Ausgabe sollte in etwa so aussehen:

   Clone: SAPHanaTopology_HA1_22-clone
   Meta Attrs: clone-max=2 clone-node-max=1 interleave=true
   Resource: SAPHanaTopology_HA1_22 (class=ocf provider=heartbeat type=SAPHanaTopology)
    Attributes: InstanceNumber=22 SID=HA1
    Operations: methods interval=0s timeout=5 (SAPHanaTopology_HA1_22-methods-interval-0s)
                monitor interval=10 timeout=600 (SAPHanaTopology_HA1_22-monitor-interval-10)
                reload interval=0s timeout=5 (SAPHanaTopology_HA1_22-reload-interval-0s)
                start interval=0s timeout=600 (SAPHanaTopology_HA1_22-start-interval-0s)
                stop interval=0s timeout=300 (SAPHanaTopology_HA1_22-stop-interval-0s)

Sie können die Clusterattribute auch mit dem Befehl crm_mon -A1 prüfen.

SAPHana-Ressource erstellen

Der SAPHana-Ressourcen-Agent verwaltet die Datenbanken, die für die SAP HANA-Systemreplikation konfiguriert sind.

Die folgenden Parameter in der SAPHana-Ressourcendefinition sind optional:

• AUTOMATED_REGISTER: Wenn dieser Wert auf true festgelegt ist, wird die frühere primäre Instanz automatisch als sekundäre registriert, wenn nach einem Takeover der DUPLICATE_PRIMARY_TIMEOUT eintritt. Der Standardwert ist false

  Für einen mehrstufigen SAP HANA-HA-Cluster legen Sie AUTOMATED_REGISTER auf false fest, wenn Sie eine ältere Version als SAP HANA 2.0 SP03 verwenden. Dadurch wird verhindert, dass eine wiederhergestellte Instanz versucht, sich selbst für eine Replikation auf ein HANA-System zu registrieren, auf dem bereits ein Replikationsziel konfiguriert ist. Bei SAP HANA 2.0 SP03 oder höher können Sie für SAP HANA-Konfigurationen, die eine mehrstufige Systemreplikation verwenden, AUTOMATED_REGISTER auf true setzen.

• DUPLICATE_PRIMARY_TIMEOUT: Zeit in Sekunden, die zwischen zwei Primär-Zeitstempeln verstreichen muss, wenn zwei primäre Instanzen erfasst werden. Der Standardwert ist 7200.

• PREFER_SITE_TAKEOVER: Legt fest, ob lokale Neustarts versucht werden sollen, bevor ein Failover ausgelöst wird. Der Standardwert ist false.

Weitere Informationen zu diesen Parametern finden Sie unter Hochverfügbarkeitscluster für Red Hat Enterprise Linux 7.6 (und höher) in Google Cloud installieren und konfigurieren. Hierfür ist ein Red Hat-Abo erforderlich.

1. Erstellen Sie als Root auf einem der Hosts die SAP HANA-Ressource:

   RHEL 8 und höher:

   # pcs resource create sap_hana_resource_name SAPHana SID=SID \
   InstanceNumber=inst_num \
   PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
   op start timeout=3600 \
   op stop timeout=3600 \
   op monitor interval=61 role="Slave" timeout=700 \
   op monitor interval=59 role="Master" timeout=700 \
   op promote timeout=3600 \
   op demote timeout=3600 \
   promotable meta notify=true clone-max=2 clone-node-max=1 interleave=true

   RHEL 7

   # pcs resource create sap_hana_resource_name SAPHana SID=SID \
   InstanceNumber=inst_num \
   PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
   op start timeout=3600 \
   op stop timeout=3600 \
   op monitor interval=61 role="Slave" timeout=700 \
   op monitor interval=59 role="Master" timeout=700 \
   op promote timeout=3600 \
   op demote timeout=3600 \
   master meta notify=true clone-max=2 clone-node-max=1 interleave=true

2. Überprüfen Sie die ausgegebenen Ressourcenattribute:

   RHEL 8 und höher:

   # pcs resource config sap_hana_resource_name

   RHEL 7

   # pcs resource show sap_hana_resource_name

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

    Resource: SAPHana_HA1_22 (class=ocf provider=heartbeat type=SAPHana)
     Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=22 PREFER_SITE_TAKEOVER=true SID=HA1
     Meta Attrs: clone-max=2 clone-node-max=1 interleave=true notify=true
     Operations: demote interval=0s timeout=3600 (SAPHana_HA1_22-demote-interval-0s)
                 methods interval=0s timeout=5 (SAPHana_HA1_22-methods-interval-0s)
                 monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_22-monitor-interval-61)
                 monitor interval=59 role=Master timeout=700 (SAPHana_HA1_22-monitor-interval-59)
                 promote interval=0s timeout=3600 (SAPHana_HA1_22-promote-interval-0s)
                 reload interval=0s timeout=5 (SAPHana_HA1_22-reload-interval-0s)
                 start interval=0s timeout=3600 (SAPHana_HA1_22-start-interval-0s)
                 stop interval=0s timeout=3600 (SAPHana_HA1_22-stop-interval-0s)

3. Prüfen Sie nach dem Start der Ressource die Knotenattribute, um den aktuellen Status der SAP HANA-Datenbanken auf den Knoten anzeigen zu lassen:

   # crm_mon -A1

   Die Ausgabe sollte in etwa so aussehen:

   Stack: corosync
   Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
   Last updated: Tue Jun 16 20:07:51 2020
   Last change: Tue Jun 16 20:07:26 2020 by root via crm_attribute on hana-ha-vm-1
   
   2 nodes configured
   6 resources configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Active resources:
   
   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 ]
   
   Node Attributes:
   * Node hana-ha-vm-1:
      + hana_ha1_clone_state              : PROMOTED
      + hana_ha1_op_mode                  : logreplay
      + hana_ha1_remoteHost               : hana-ha-vm-2
      + hana_ha1_roles                    : 4:P:master1:master:worker:master
      + hana_ha1_site                     : hana-ha-vm-1
      + hana_ha1_srmode                   : syncmem
      + hana_ha1_sync_state               : PRIM
      + hana_ha1_version                  : 1.00.122.27.1568902538
      + hana_ha1_vhost                    : hana-ha-vm-1
      + lpa_ha1_lpt                       : 1592338046
      + master-SAPHana_HA1_22             : 150
   * Node hana-ha-vm-2:
      + hana_ha1_clone_state              : DEMOTED
      + hana_ha1_op_mode                  : logreplay
      + hana_ha1_remoteHost               : hana-ha-vm-1
      + hana_ha1_roles                    : 4:S:master1:master:worker:master
      + hana_ha1_site                     : hana-ha-vm-2
      + hana_ha1_srmode                   : syncmem
      + hana_ha1_sync_state               : SOK
      + hana_ha1_version                  : 1.00.122.27.1568902538
      + hana_ha1_vhost                    : hana-ha-vm-2
      + lpa_ha1_lpt                       : 30
      + master-SAPHana_HA1_22             : 100

Virtuelle IP-Adressressource erstellen

Sie müssen für die VIP eine Clusterressource erstellen. Die VIP-Ressource ist für das primäre Betriebssystem lokalisiert und kann nicht von anderen Hosts weitergeleitet werden. Der Load-Balancer leitet den an die VIP gesendeten Traffic basierend auf der Systemdiagnose an den Back-End-Host weiter.

Als Root auf einem Host:

# pcs resource create resource_name \
  IPaddr2 ip="vip-address" nic=eth0 cidr_netmask=32 \
  op monitor interval=3600s timeout=60s

Der Wert vip-address ist dieselbe IP-Adresse, die Sie zuvor reserviert und in der Weiterleitungsregel für das Frontend Ihres Load-Balancers angegeben haben. Ändern Sie die Netzwerkschnittstelle entsprechend Ihrer Konfiguration.

Einschränkungen erstellen

Mit Einschränkungen legen Sie fest, welche Dienste zuerst gestartet werden müssen und welche Dienste zusammen auf demselben Host ausgeführt werden müssen. Die IP-Adresse muss sich beispielsweise auf demselben Host wie die primäre HANA-Instanz befinden.

1. Definieren Sie die Einschränkung für die Startreihenfolge:

   RHEL 8 und höher:

   # pcs constraint order topology_resource_name-clone \
   then sap_hana_resource_name-clone symmetrical=false

   RHEL 7

   # pcs constraint order topology_resource_name-clone \
   then sap_hana_resource_name-master symmetrical=false

   Die Angabe von symmetrical=false bedeutet, dass die Einschränkung nur beim Start und nicht beim Herunterfahren gilt.

   Da Sie jedoch in einem vorherigen Schritt für diese Ressourcen interleave=true festgelegt haben, können die Prozesse parallel gestartet werden. Mit anderen Worten, Sie können SAPHana auf jedem Knoten starten, sobald SAPHanaTopology ausgeführt wird.

2. Prüfen Sie die Einschränkungen:

   # pcs constraint

   Die Ausgabe sollte in etwa so aussehen:

   Location Constraints:
    Resource: STONITH-hana-ha-vm-1
      Disabled on:
        Node: hana-ha-vm-1 (score:-INFINITY)
    Resource: STONITH-hana-ha-vm-2
      Disabled on:
        Node: hana-ha-vm-2 (score:-INFINITY)
   Ordering Constraints:
    start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical)
   Colocation Constraints:
   Ticket Constraints:

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

1. Öffnen Sie die Konfigurationsdatei haproxy.cfg zur Bearbeitung:

   # vi /etc/haproxy/haproxy.cfg

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

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

2. Starten Sie als Root den Dienst auf jedem Host, um zu prüfen, ob er richtig konfiguriert ist:

   # systemctl start haproxy.service

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

   

4. 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 Masterknoten neu.

Systemdiagnose-Ressource erstellen

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

2. Prüfen Sie, ob der Systemdiagnosedienst auf demselben Host wie Ihre Master-SAP HANA-Instanz und Ihre VIP-Ressource aktiv ist:

   # pcs status

   Wenn sich die Systemdiagnose-Ressource nicht auf dem primären Host 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-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 ]
   rsc_vip_HA1_22 (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
   rsc_healthcheck_HA1    (service:haproxy):      Started hana-ha-vm-2

3. Gruppieren Sie die Ressourcen für VIP und Systemdiagnose:

   # pcs resource group add rsc-group-name healthcheck_resource_name vip_resource_name

   Im Clusterstatus sollte der Bereich "Ressourcen" in etwa so aussehen:

   Full list of resources:
   
   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

4. Erstellen Sie eine Einschränkung, die die neue Gruppe demselben Knoten zuweist, auf dem sich auch die Master-SAP HANA-Instanz befindet.

   RHEL 8 und höher:

   # pcs constraint colocation add rsc-group-name with master sap_hana_resource_name-clone 4000

   RHEL 7

   # pcs constraint colocation add rsc-group-name with master sap_hana_resource_name-master 4000

   Die endgültigen Einschränkungen sollten in etwa so aussehen:

   # pcs constraint
   Location Constraints:
    Resource: STONITH-hana-ha-vm-1
      Disabled on:
        Node: hana-ha-vm-1 (score:-INFINITY)
    Resource: STONITH-hana-ha-vm-2
      Disabled on:
        Node: hana-ha-vm-2 (score:-INFINITY)
   Ordering Constraints:
    start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical)
   Colocation Constraints:
    g-primary with SAPHana_HA1_22-master (score:4000) (rsc-role:Started) (with-rsc-role:Master)
   Ticket Constraints:

Failover testen

Testen Sie Ihren Cluster, indem Sie einen Ausfall auf dem primären 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:

• HDB stop
• HDB kill
• 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

In dieser Anleitung wird ip link set eth0 down oder iptables verwendet, um eine Netzwerkunterbrechung zwischen den beiden Hosts im 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 den Failover als auch das 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 den Cluster verwendet wird. Kommunikation, wodurch ein Verlust der Netzwerkverbindung zum primären Knoten simuliert wird.

1. Schalten Sie als Root auf dem aktiven Host die Netzwerkschnittstelle offline:

   # ip link set eth0 down

   Wenn mehrere Netzwerkschnittstellen aktiv sind, verwenden Sie iptables auf dem sekundären Host:

   # iptables -A INPUT -s PRIMARY_CLUSTER_IP -j DROP; iptables -A OUTPUT -d PRIMARY_CLUSTER_IP -j DROP

2. Stellen Sie eine SSH-Verbindung zu einem der Hosts her und wechseln Sie zum Root-Nutzer.

3. Geben Sie pcs status ein, um zu prüfen, ob der primäre Host jetzt auf der VM aktiv ist, auf der sich zuvor der sekundäre Host befand. Da im Cluster der automatische Neustart aktiviert ist, wird der angehaltene Host neu gestartet und übernimmt wie im folgenden Beispiel gezeigt die Rolle des sekundären Hosts.

   Cluster name: hana-ha-cluster
   Stack: corosync
   Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
   Last updated: Wed Jun 17 01:04:36 2020
   Last change: Wed Jun 17 01:03:58 2020 by root via crm_attribute on hana-ha-vm-2
   
   2 nodes configured
   8 resources configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Full list of resources:
   
   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-2 ]
       Slaves: [ hana-ha-vm-1  ]
   Resource Group: g-primary
       rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-2
       rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
   
   Daemon Status:
    corosync: active/enabled
    pacemaker: active/enabled
    pcsd: active/enabled

HANA Aktiv/Aktiv konfigurieren (Lesezugriff aktiviert)

Ab SAP HANA 2.0 SPS1 können Sie HANA Aktiv/Aktiv (Lesezugriff aktiviert) in einem Pacemaker-Cluster konfigurieren. Dies ist optional.

Führen Sie die folgenden Schritte aus, um HANA Aktiv/Aktiv (Lesezugriff aktiviert) in einem Pacemaker-Cluster zu konfigurieren.

Failover-Unterstützung für den Cloud Load Balancing für den sekundären Host konfigurieren

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

So konfigurieren Sie die Failover-Unterstützung für den sekundären Host:

1. Öffnen Sie Cloud Shell:

   Zu Cloud Shell

2. Reservieren Sie eine IP-Adresse für die virtuelle IP-Adresse. Führen Sie dazu den folgenden Befehl aus.

   Die virtuelle IP-Adresse (VIP) folgt dem sekundären SAP HANA-System. Dies ist die IP-Adresse, mit der Anwendungen auf Ihr sekundäres SAP HANA-System zugreifen. Der Load-Balancer leitet den an die VIP gesendeten Traffic an die VM-Instanz weiter, die derzeit das sekundäre System hostet.

   Wenn Sie im folgenden Befehl das Flag --addresses weglassen, wird im angegebenen Subnetz automatisch eine IP-Adresse ausgewählt. Weitere Informationen zum Reservieren einer statischen IP-Adresse finden Sie unter Statische interne IP-Adresse reservieren.

   $ gcloud compute addresses create secondary-vip-name \
     --region cluster-region --subnet cluster-subnet \
     --addresses secondary-vip-address

3. Erstellen Sie eine Compute Engine-Systemdiagnose, indem Sie den folgenden Befehl ausführen.

   Wählen Sie für die Systemdiagnose einen Port aus dem privaten Bereich 49152-65535 aus, um Konflikte mit anderen Diensten zu vermeiden. Der Port sollte sich von dem Port unterscheiden, der für die Systemdiagnose konfiguriert ist, die für den primären HANA-Systemzugriff verwendet wird. 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 secondary-health-check-name \
     --port=secondary-healthcheck-port-num \
     --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
     --healthy-threshold=2

4. Konfigurieren Sie den Load-Balancer und die Failover-Gruppe, indem Sie die folgenden Befehle ausführen.

   Hier erstellen Sie einen zusätzlichen Backend-Dienst und verwenden dieselben Instanzgruppen, die Sie zuvor für den Backend-Dienst hinter dem internen TCP/UDP-Load-Balancer für das primäre SAP HANA-System erstellt haben.

   1. Erstellen Sie den Backend-Dienst des Load-Balancers:

      $ gcloud compute backend-services create secondary-backend-service-name \
        --load-balancing-scheme internal \
        --health-checks secondary-health-check-name \
        --no-connection-drain-on-failover \
        --drop-traffic-if-unhealthy \
        --failover-ratio 1.0 \
        --region cluster-region \
        --global-health-checks

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

      $ gcloud compute backend-services add-backend secondary-backend-service-name \
        --instance-group primary-ig-name \
        --instance-group-zone primary-zone \
        --region cluster-region

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

      $ gcloud compute backend-services add-backend secondary-backend-service-name \
        --instance-group secondary-ig-name \
        --instance-group-zone secondary-zone \
        --failover \
        --region cluster-region

   4. Erstellen Sie eine Weiterleitungsregel.

      Geben Sie darin die IP-Adresse an, die Sie für die VIP reserviert haben: Wenn Sie außerhalb der Region, die Sie im folgenden Befehl angeben, auf das sekundäre HANA-System zugreifen müssen, fügen Sie in die Definition der Weiterleitungsregel das Flag --allow-global-access ein.

      $ gcloud compute forwarding-rules create secondary-rule-name \
        --load-balancing-scheme internal \
        --address secondary-vip-name \
        --subnet cluster-subnet \
        --region cluster-region \
        --backend-service secondary-backend-service-name \
        --ports ALL

      Weitere Informationen zum regionenübergreifenden Zugriff auf Ihr SAP HANA-Hochverfügbarkeitssystem finden Sie unter Internes TCP/UDP-Load-Balancing.

HANA Aktiv/Aktiv (Lesezugriff aktiviert) aktivieren

Aktivieren Sie auf Ihrem sekundären Host die Aktiv/Aktiv-Funktion (Lesezugriff aktiviert) für die SAP HANA-Systemreplikation. Gehen Sie dazu so vor:

1. Versetzen Sie den Cluster als Root in den Wartungsmodus:

   $ pcs property set maintenance-mode=true

2. Beenden Sie SAP HANA als SID_LCadm:

   > HDB stop

3. Melden Sie sich als SID_LCadm noch einmal das sekundäre HANA-System bei der SAP HANA-Systemreplikation im Betriebsmodus logreplay_readaccess an:

   > hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \
    --replicationMode=syncmem --operationMode=logreplay_readaccess --name=secondary-host-name

4. Starten Sie SAP HANA als SID_LCadm:

   > HDB start

5. Prüfen Sie als SID_LCadm, ob der HANA-Synchronisierungsstatus ACTIVE lautet:

   > cdpy; python systemReplicationStatus.py --sapcontrol=1 | grep overall_replication_status

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   overall_replication_status=ACTIVE

Pacemaker konfigurieren

Konfigurieren Sie Ihren Pacemaker-HA-Cluster für Aktiv/Aktiv (Lesezugriff aktiviert), indem Sie die folgenden Befehle als Root ausführen:

1. Richten Sie Listener für die Systemdiagnosen ein:

   1. Kopieren und benennen Sie die standardmäßige Konfigurationsdatei haproxy.service um, um sie als Vorlagendatei für die mehreren HAProxy-Instanzen zu erstellen:

      # cp /usr/lib/systemd/system/haproxy.service \
           /etc/systemd/system/haproxy@.service

   2. Bearbeiten Sie Folgendes: [Einheit] und [Dienst] Abschnitte der haproxy@.service die folgende Datei enthalten: %i Instanzparameter, wie im folgenden Beispiel gezeigt:

      RHEL 7

      [Unit]
      Description=HAProxy Load Balancer %i
      After=network-online.target
      
      
      [Service]
      EnvironmentFile=/etc/sysconfig/haproxy
      ExecStart=/usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy-%i.cfg -p /run/haproxy-%i.pid $OPTIONS
      ...
      

      RHEL 8

      [Unit]
      Description=HAProxy Load Balancer %i
      After=network-online.target
      Wants=network-online.target
      
      
      [Service]
      Environment="CONFIG=/etc/haproxy/haproxy-%i.cfg" "PIDFILE=/run/haproxy-%i.pid"
      ...
      

      Weitere Informationen von Red Hat zu systemd-Einheitenvorlagen finden Sie unter Mit instanziierten Einheiten arbeiten.

   3. Erstellen Sie eine haproxy.cfg-Konfigurationsdatei für Ihr primäres SAP HANA-System. Beispiele:

      # vi /etc/haproxy/haproxy-primary.cfg

   4. Fügen Sie in die Konfigurationsdatei haproxy-primary.cfg für Ihr primäres SAP HANA-System die folgende Konfiguration ein und ersetzen Sie healthcheck-port-num durch die Portnummer, die Sie beim Erstellen der Compute Engine-Systemdiagnose für das primäre HANA-System zuvor angegeben haben:

      global
        chroot      /var/lib/haproxy
        pidfile     /var/run/haproxy-%i.pid
        user        haproxy
        group       haproxy
        daemon
      defaults
        mode                    tcp
        log                     global
        option                  dontlognull
        option                  redispatch
        retries                 3
        timeout queue           1m
        timeout connect         10s
        timeout client          1m
        timeout server          1m
        timeout check           10s
        maxconn                 3000
      
      # Listener for SAP healthcheck
      listen healthcheck
        bind *:healthcheck-port-num

   5. Erstellen Sie eine haproxy.cfg-Konfigurationsdatei für das sekundäre SAP HANA-System. Beispiele:

      # vi /etc/haproxy/haproxy-secondary.cfg

   6. Fügen Sie in die Konfigurationsdatei haproxy-secondary.cfg für Ihr sekundäres SAP HANA-System die folgende Konfiguration ein und ersetzen Sie secondary-healthcheck-port-num durch die Portnummer, die Sie beim Erstellen der Compute Engine-Systemdiagnose für das sekundäre HANA-System zuvor angegeben haben:

      global
        chroot      /var/lib/haproxy
        pidfile     /var/run/haproxy-%i.pid
        user        haproxy
        group       haproxy
        daemon
      defaults
        mode                    tcp
        log                     global
        option                  dontlognull
        option                  redispatch
        retries                 3
        timeout queue           1m
        timeout connect         10s
        timeout client          1m
        timeout server          1m
        timeout check           10s
        maxconn                 3000
      
      # Listener for SAP healthcheck
      listen healthcheck
        bind *:secondary-healthcheck-port-num

   7. Entfernen Sie die vorhandene Listener-Konfiguration aus /etc/haproxy/haproxy.cfg:

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

   8. Laden Sie die systemd-Dienste neu, um die Änderungen zu laden:

      # systemctl daemon-reload

   9. Bestätigen Sie, dass die beiden HAProxy-Dienste ordnungsgemäß eingerichtet sind:

      # systemctl start haproxy@primary
      # systemctl start haproxy@secondary
      
      # systemctl status haproxy@primary
      # systemctl status haproxy@secondary

      Der zurückgegebene Status sollte [e-mail] und [e-mail] als active (running) anzeigen. Hier sehen Sie eine Beispielausgabe für [e-mail]:

      ● [e-mail] - Cluster Controlled haproxy@primary
        Loaded: loaded (/etc/systemd/system/haproxy@.service; disabled; vendor preset: disabled)
        Drop-In: /run/systemd/system/[e-mail].d
                 └─50-pacemaker.conf
        Active: active (running) since Fri 2022-10-07 23:36:09 UTC; 1h 13min ago
      Main PID: 21064 (haproxy-systemd)
        CGroup: /system.slice/system-haproxy.slice/[e-mail]
                ├─21064 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy-primary.cfg -p /run/hapro...
                ├─21066 /usr/sbin/haproxy -f /etc/haproxy/haproxy-primary.cfg -p /run/haproxy-primary.pid -...
                └─21067 /usr/sbin/haproxy -f /etc/haproxy/haproxy-primary.cfg -p /run/haproxy-primary.pid -...
      
      Oct 07 23:36:09 hana-ha-vm-1 systemd[1]: Started Cluster Controlled haproxy@primary.

   10. Warten Sie in Cloud Shell einige Sekunden, bis die Systemdiagnose den Listener erkennt, und prüfen Sie dann den Status Ihrer Backend-Instanzgruppen im primären und im sekundären Backend-Dienst:

       $ gcloud compute backend-services get-health backend-service-name \
         --region cluster-region

       $ gcloud compute backend-services get-health secondary-backend-service-name \
         --region cluster-region

       Die Ausgabe sollte in etwa so aussehen: Die healthState, an der Sie gerade arbeiten, lautet HEALTHY:

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

   11. Beenden Sie beide Dienste, damit Pacemaker die Dienste verwalten kann:

       # systemctl stop haproxy@primary
       # systemctl stop haproxy@secondary

   12. Wiederholen Sie die vorherigen Schritte auf jedem Host im Cluster.

2. Erstellen Sie eine lokale Cluster-IP-Ressource für die VIP-Adresse, die Sie für das sekundäre System reserviert haben:

   # pcs resource create secondary_vip_resource_name \
     IPaddr2 ip="secondary-vip-address" nic=eth0 cidr_netmask=32 \
     op monitor interval=3600s timeout=60s

3. Richten Sie den Hilfsdienst für die Systemdiagnose mit den folgenden Befehlen ein:

   Der Load-Balancer verwendet einen Listener am Systemdiagnose-Port jedes Hosts, um zu ermitteln, wo die sekundäre Instanz des SAP HANA-Clusters ausgeführt wird.

   1. Zur Verwaltung der Listener im Cluster erstellen Sie eine Ressource für den Listener:

      1. Löschen Sie die Ressource für den Systemdiagnosedienst für das primäre HANA-System:

         # pcs resource delete healthcheck_resource_name --force

      2. Fügen Sie eine neue Ressource für den Systemdiagnosedienst für das primäre HANA-System hinzu:

         # pcs resource create primary_healthcheck_resource_name \
          service:haproxy@primary op monitor interval=10s timeout=20s

      3. Fügen Sie eine neue Ressource für den Systemdiagnosedienst für das sekundäre HANA-System hinzu:

         # pcs resource create secondary_healthcheck_resource_name \
          service:haproxy@secondary op monitor interval=10s timeout=20s

   2. Ressourcen für die VIP und den Hilfsdienst zur Systemdiagnose gruppieren

      1. Fügen Sie die neue Systemdiagnoseressource der vorhandenen Ressourcengruppe für primäre VIP-Ressourcen hinzu:

         # pcs resource group add rsc-group-name primary_healthcheck_resource_name \
          --before vip_resource_name

      2. Fügen Sie eine neue Ressourcengruppe hinzu, um die Ressourcen für den VIP und den Hilfsdienst für das sekundäre HANA-System zu gruppieren:

         # pcs resource group add secondary-rsc-group-name \
          secondary_healthcheck_resource_name secondary_vip_resource_name

4. Erstellen Sie mit den folgenden Befehlen zwei Standortbeschränkungen:

   Diese Einschränkungen sorgen dafür, dass die sekundäre VIP-Ressourcengruppe auf dem richtigen Clusterknoten platziert wird:

   # pcs constraint location secondary-rsc-group-name rule score=INFINITY \
     hana_sid_sync_state eq SOK and hana_sid_roles eq 4:S:master1:master:worker:master

   # pcs constraint location secondary-rsc-group-name rule score=2000 \
     hana_sid_sync_state eq PRIM and hana_sid_roles eq 4:P:master1:master:worker:master

5. Beenden Sie den Clusterwartungsmodus:

   # pcs property set maintenance-mode=false

6. Prüfen Sie den Clusterstatus:

   # pcs status

   Die folgenden Beispiele zeigen den Status eines aktiven, ordnungsgemäß konfigurierten Clusters für die SAP HANA-Systemreplikation mit Aktiv/Aktiv (Lesezugriff aktiviert). Sie sollten eine zusätzliche Ressourcengruppe für die VIP-Ressourcen des sekundären Systems sehen. Im folgenden Beispiel lautet der Name dieser Ressourcengruppe g-secondary.

   Cluster name: hacluster
     Stack: corosync
     Current DC: hana-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
     Last updated: Sat Oct  8 00:37:08 2022
     Last change: Sat Oct  8 00:36:57 2022 by root via crm_attribute on hana-test-2
   
     2 nodes configured
     10 resource instances configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Full list of resources:
     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
     Resource Group: g-primary
       rsc_healthcheck_HA1-primary        (service:haproxy@primary):      Started hana-ha-vm-1
       rsc_vip_HA1_00     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
     Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
     Master/Slave Set: SAPHana_HA1_00-master [SAPHana_HA1_00]
       Masters: [ hana-ha-vm-1 ]
       Slaves: [ hana-ha-vm-2 ]
     Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable):
       Masters: [ hana-ha-vm-1 ]
       Slaves: [ hana-ha-vm-2 ]
     Resource Group: g-secondary
       rsc_healthcheck_HA1-secondary        (service:haproxy@secondary):      Started hana-ha-vm-2
       rsc_vip_HA1_00-secondary     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
   

SAP HANA-Arbeitslast bewerten

Mit Workload Manager können Sie kontinuierliche Validierungsprüfungen für Ihre hochverfügbaren Arbeitslasten von SAP HANA automatisieren, die in Google Cloud ausgeführt werden.

Mit Workload Manager können Sie Ihre hochverfügbaren Arbeitslasten von SAP HANA automatisch anhand von Best Practices von SAP, Google Cloud und Betriebssystemanbietern scannen und bewerten. Dies verbessert die Qualität, Leistung und Zuverlässigkeit Ihrer Arbeitslasten.

Informationen zu den Best Practices, die Workload Manager für die Bewertung von hochverfügbaren Arbeitslasten von SAP HANA in der Google Cloud unterstützt, finden Sie unter Best Practices von Workload Manager für SAP. Informationen zum Erstellen und Ausführen einer Bewertung mit Workload Manager finden Sie unter Evaluierung erstellen und ausführen.

Fehlerbehebung

Informationen zur Fehlerbehebung bei Problemen mit Hochverfügbarkeitskonfigurationen für SAP HANA 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.

Support

Wenden Sie sich bei Problemen mit der Infrastruktur oder den Diensten von Google Cloud an Customer Care. Kontaktdaten finden Sie in der Google Cloud Console auf der Seite Supportübersicht. Wenn Customer Care feststellt, dass sich um ein Problem Ihres SAP-Systems handelt, werden Sie an den SAP-Support verwiesen.

Reichen Sie bei Problemen in Zusammenhang mit SAP-Produkten Ihre Supportanfrage beim SAP-Support ein. SAP wertet das Support-Ticket aus und leitet es, wenn es sich um ein Problem mit der Google Cloud-Infrastruktur handelt, an die Google Cloud-Komponente BC-OP-LNX-GOOGLE oder BC-OP-NT-GOOGLE weiter.

Supportanforderungen

Bevor Sie Support für SAP-Systeme sowie für die Infrastruktur und Dienste von Google Cloud erhalten können, müssen Sie die Mindestanforderungen für den Supportplan erfüllen.

Weitere Informationen zu den Mindestsupportanforderungen für SAP in Google Cloud finden Sie hier:

• Support für SAP in Google Cloud
• SAP-Hinweis 2456406 – SAP auf der Google Cloud Platform: Support-Voraussetzungen (SAP-Nutzerkonto erforderlich)

Verbindung zu SAP HANA herstellen

Wenn die Host-VMs keine externe IP-Adresse für SAP HANA haben, können Sie die Verbindung zu den SAP HANA-Instanzen nur über die Bastion-Instanz mit SSH oder über den Windows-Server mit SAP HANA Studio herstellen.

• Wenn Sie die Verbindung zu SAP HANA über die Bastion-Instanz herstellen möchten, stellen Sie zuerst über einen SSH-Client Ihrer Wahl eine Verbindung zum Bastion Host und anschließend zu den SAP HANA-Instanzen her.

• Zum Herstellen einer Verbindung mit der SAP HANA-Datenbank über SAP HANA Studio verwenden Sie einen Remote-Desktop-Client, um eine Verbindung zur Windows Server-Instanz herzustellen. Nach dem Verbindungsaufbau installieren Sie SAP HANA Studio manuell und greifen auf Ihre SAP HANA-Datenbank zu.

Aufgaben nach der Bereitstellung

Führen Sie nach der Bereitstellung die folgenden Schritte aus:

1. Ändern Sie die temporären Passwörter für den SAP HANA-Systemadministrator und den Datenbank-Superuser. Beispiel:

   sudo passwd SID_LCadm

   Informationen von SAP zum Ändern des Passworts finden Sie unter System-Passwort der Systemdatenbank zurücksetzen.

2. Bevor Sie Ihre SAP HANA-Instanz verwenden, konfigurieren und sichern Sie die neue SAP HANA-Datenbank.

3. Wenn Ihr SAP HANA-System in einer VirtIO-Netzwerkschnittstelle bereitgestellt wird, empfehlen wir, den Wert des TCP-Parameters /proc/sys/net/ipv4/tcp_limit_output_bytes auf 1048576 zu setzen. Diese Änderung hilft, den Gesamtdurchsatz des Netzwerks der VirtIO-Netzwerkschnittstelle zu verbessern, ohne die Netzwerklatenz zu beeinträchtigen.

Weitere Informationen finden Sie unter:

• Betriebsanleitung für SAP HANA
• Installations- und Aktualisierungsanleitung für SAP HANA

Weitere Informationen

Ressourcen mit weiterführenden Informationen:

• Hochverfügbarkeitscluster für Red Hat Enterprise Linux 7.6 (und höher) in Google Cloud installieren und konfigurieren
• Automatisierte SAP HANA-Systemreplikation beim vertikalen Skalieren im Pacemaker-Cluster
• Supportrichtlinien für RHEL-Hochverfügbarkeitscluster – Allgemeine Anforderungen für Fencing/STONith
• Leitfaden zur Planung der Hochverfügbarkeit für SAP HANA
• Leitfaden zur Notfallwiederherstellung für SAP HANA
• Weitere Informationen zu VM-Verwaltung und VM-Monitoring finden Sie in der Betriebsanleitung für SAP HANA.