Bereitstellungsleitfaden für IBM Db2-Hochverfügbarkeitscluster für SAP

In diesem Leitfaden erfahren Sie, wie Sie Google Cloud-Ressourcen für einen IBM Db2-Hochverfügbarkeitscluster (IBM Db2) für SAP auf dem Linux-Betriebssystem einrichten.

Diese Anleitung ergänzt die Anleitung von SAP und IBM in IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms. Berücksichtigen Sie bei der Installation und Konfiguration eines IBM Db2-Hochverfügbarkeitsclusters in Google Cloud immer die neueste Dokumentation von SAP und IBM.

Diese Anleitung gilt für IBM Db2-Hochverfügbarkeitscluster, die zum Überwachen des Systems und zum Initiieren entsprechender Maßnahmen bei einem Systemausfall IBM Tivoli System Automation for Multiplatforms (TSAMP) verwenden. Der Cluster verwendet die High-Availability Disaster Recovery-Funktion (HADR) von IBM Db2, um die in Logs erfassten Datenänderungen in der Standby-Datenbank zu replizieren.

Der Cluster verwendet eine Floating-IP-Adresse, die von Google Cloud entweder über eine statische Google Cloud-Route oder eine Alias-IP-Adresse implementiert wird. Der Begriff "Floating-IP-Adresse" ist in diesem Zusammenhang synonym mit dem in der SAP-Dokumentation verwendeten Begriff "virtual IP address".

In dieser Anleitung wird erläutert, wie Sie einen IBM Db2-Hochverfügbarkeitssuster einrichten, der aus einem primären IBM Db2-Server und einem sekundären oder Standby-IBM Db2-Server besteht, die jeweils auf einer separaten virtuellen Compute Engine-Maschine bereitgestellt werden.

Diese Anleitung richtet sich an erfahrene SAP- und IBM Db2-Nutzer, die mit Hochverfügbarkeitsclustern vertraut sind.

Weitere Informationen zum Planen eines Db2-Hochverfügbarkeitsclusters finden Sie unter IBM Db2-Cluster mit Hochverfügbarkeit (HA) in der Planungsanleitung von IBM Db2 für SAP.

Erforderliche SAP-Dokumentation

Anleitungen zum Installieren und Konfigurieren der SAP- und IBM-Komponenten finden Sie in der SAP-Dokumentation IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms.

Lesen Sie sowohl die SAP- als auch die Google Cloud-Dokumentation, bevor Sie mit den Verfahren in dieser Anleitung beginnen. Während der Bereitstellung kann es mitunter erforderlich sein, die SAP- und die Google Cloud-Dokumentation hinzuzuziehen.

Voraussetzungen

Achten Sie vor dem Erstellen des IBM Db2-Hochverfügbarkeitsclusters darauf, dass die folgenden Voraussetzungen erfüllt sind:

  • Sie oder Ihre Organisation haben ein Google Cloud-Konto. Außerdem haben Sie ein Projekt für die Bereitstellung des IBM Db2-Hochverfügbarkeitsclusters erstellt. Informationen zum Erstellen von Google Cloud-Projekten finden Sie in der Anleitung zur Bereitstellung von IBM Db2 für SAP unter Voraussetzungen.
  • 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.

  • Sie haben in Google Cloud ein Virtual Private Cloud-Netzwerk. Wie Sie ein VPC-Netzwerk und Firewallregeln konfigurieren sowie ein NAT-Gateway oder einen Bastion Host für IBM Db2 für SAP einrichten, erfahren Sie in der Anleitung zur Bereitstellung von IBM Db2 für SAP.

  • 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 Aktivierung von OS Login sind metadatenbasierte SSH-Schlüsselkonfigurationen deaktiviert. Nach Abschluss der Bereitstellung können Sie die OS Login-Funktion wieder aktivieren.

    Weitere Informationen finden Sie unter:

IBM Db2-Hochverfügbarkeitscluster in Google Cloud bereitstellen

In dieser Anleitung wird gezeigt, wie Sie zwei VMs bereitstellen, eine Floating-IP-Adresse definieren und die Alias-IP-Adresse oder die Google Cloud-Routen konfigurieren, von denen die Floating-IP-Adresse unterstützt wird. Zum Installieren der IBM-Komponenten werden Sie auf die SAP-Dokumentation verwiesen.

Dies sind die wichtigsten Google Cloud-Dienste, die Sie für einen IBM Db2-Hochverfügbarkeitscluster einrichten müssen:

  • VPC-Netzwerk und Subnetzwerk
  • Firewallregeln (sofern Sie keine andere Form der Netzwerkzugriffssteuerung verwenden)
  • Compute Engine-VMs und nichtflüchtigen Festplattenspeicher

Sie können auch ein Hilfsskript für Google Cloud herunterladen und verwenden, wenn Sie die benutzerdefinierte Ressource definieren, mit der TSAMP das Wechseln der Floating-IP-Adresse zwischen Hosts verwaltet. Das Skript ermöglicht TSAMP die Interaktion mit Google Cloud APIs.

Deployment Manager

Anhand dieser Anleitung definieren Sie die Ressourcenoptionen für Ihre Installation in einer Deployment Manager-Konfigurationsdateivorlage.

Deployment Manager behandelt alle Ressourcen, die für Ihr SAP-System erstellt werden, als eine einzige Entität, die als Deployment bezeichnet wird. Sie können alle Bereitstellungen für Ihr Projekt auf der Seite Bereitstellungen in der Google Cloud Console ansehen und bearbeiten.

Beachten Sie bei der Verwendung von Deployment Manager die folgenden Verhaltensweisen:

  • Beim Löschen einer Bereitstellung werden alle damit verbundenen Ressourcen gelöscht, einschließlich der VMs, der nichtflüchtigen Speicher und aller auf der VM installierten SAP-Systeme.

  • Standardmäßig verwendet Deployment Manager die Ressourcenerstellungsrichtlinie ACQUIRE. Wenn Sie einen VM-Namen angeben, der bereits von einer anderen VM in Ihrem Projekt verwendet wird, erstellt Deployment Manager keine neue VM, sondern fügt stattdessen die vorhandene VM Ihrer neuen Bereitstellung hinzu. Wenn die ursprüngliche VM durch eine vorherige Ausführung von Deployment Manager erstellt wurde, ist die VM mit zwei Deployments verknüpft.

    Wenn Sie dann die neue Bereitstellung löschen, wird die erworbene VM aus der Bereitstellung gelöscht, mit der sie ursprünglich erstellt wurde. Ein solches Szenario können Sie dadurch vermeiden, dass Sie entweder die Deployment Manager-Ressourcenrichtlinie auf CREATE setzen oder dafür sorgen, dass Sie in Ihrem neuen Deployment eindeutige Ressourcennamen verwenden.

    Informationen zu den Richtlinien, die Sie beim Erstellen von Ressourcen mit Deployment Manager verwenden können, und wie Sie diese angeben, finden Sie in der Dokumentation zu Deployment Manager.

VMs für einen IBM Db2-Hochverfügbarkeitscluster mit Deployment Manager bereitstellen

  1. Laden Sie in Cloud Shell die Vorlage für die template_ha.yaml-Konfigurationsdatei in Ihr Arbeitsverzeichnis herunter:

    wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/template_ha.yaml

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

  3. Sie können die Datei template_ha.yaml so umbenennen, dass die von ihr definierte Konfiguration im Namen erkennbar ist. Beispiel: db2_ha_s123_dh1.yaml

  4. Klicken Sie doppelt auf die Datei template_ha.yaml, um sie im Code-Editor zu öffnen.

  5. Definieren Sie in der Datei template_ha.yaml die VMs und die nichtflüchtigen Speicher. Die template_ha.yaml-Datei enthält zwei Abschnitte: sap_db2_primary und sap_db2_secondary. Jeder Abschnitt enthält eine Reihe von Attribut/Wert-Paaren, gefolgt von Kommentaren zu seltener verwendeten Attributen.

    Beim Ausfüllen der Abschnitte ist wichtig, dass die Definitionen der VMs identisch sind. Davon ausgenommen sind die Attribute instanceName, zone und otherHost.

    In der folgenden Tabelle werden die Attribute der einzelnen Abschnitte beschrieben. Um ein bestimmtes Attribut zu verwenden, ersetzen Sie den Platzhaltertext und die Klammern durch die Werte für Ihre Installation.

    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, auf der Sie IBM Db2 installieren. Der Name darf maximal 13 Zeichen lang sein und darf nur Kleinbuchstaben, Zahlen und Bindestriche enthalten.
    instanceType String Der Typ der virtuellen Compute Engine-Maschine, auf der Sie IBM Db2 installieren. Geben Sie einen Maschinentyp mit zwei oder mehr vCPUs an. Beispiel: n1-standard-4.
    zone String Die Zone, in der Sie die IBM Db2-Instanz bereitstellen. Sie muss sich in derselben Region befinden, die Sie für Ihr Subnetzwerk ausgewählt haben.
    subnetwork String Der Name des Subnetzwerks, das Sie in einem vorherigen Schritt erstellt haben. Wenn das Deployment in einer freigegebenen VPC erfolgt, geben Sie diesen Wert als shared-vpc-project/SUBNETWORK an. Beispiel: myproject/network1.
    linuxImage String Der Name des Linux-Betriebssystemimages bzw. der -Imagefamilie, die Sie mit IBM Db2 verwenden. Wenn Sie eine Image-Familie angeben möchten, ergänzen Sie den Familiennamen durch das Präfix family/. Beispiel: family/rhel-7-sap-apps oder family/sles-12-sp3-sap. Geben Sie nur den Imagenamen ein, um ein Image anzugeben. Eine Liste der verfügbaren Image-Familien finden Sie in der Google Cloud Console auf der Seite Seite "Images".
    linuxImageProject String Das Google Cloud-Projekt, das das zu verwendende Image enthält. Bei diesem Projekt kann es sich um Ihr eigenes Projekt oder ein Google Cloud-Image-Projekt handeln, z. B. rhel-sap-cloud oder suse-sap-cloud. Eine Liste der Google Cloud-Image-Projekte finden Sie auf der Seite Images in der Dokumentation zu Compute Engine.
    db2SID String Die Datenbankinstanz-ID.
    db2sidSize Ganzzahl Die Größe in GB von /db2/DBSID, dem Stammverzeichnis der Datenbankinstanz. Der Mindest- und Standardwert für db2sidSize beträgt jeweils 8 GB.
    db2homeSize Ganzzahl Die Größe in GB von /db2/db2db2sid, dem Stammverzeichnis der Datenbankinstanz. Der Mindest- und Standardwert für db2homeSize beträgt jeweils 8 GB.
    db2dumpSize Ganzzahl Die Größe in GB von /db2/DBSID/db2dump, das die Dumpdateien von DB2 enthält, die zum Diagnostizieren von Problemen verwendet werden. Der Mindest- und Standardwert für db2dumpSize beträgt jeweils 8 GB.
    db2saptmpSize Ganzzahl Die Größe in GB von /db2/DBSID/saptmp, das den temporären Tablespace der Datenbank enthält. Der Mindest- und Standardwert für db2saptmpSize beträgt jeweils 8 GB.
    db2sapdataSize Ganzzahl Die Größe von /sapdb/DBSID/sapdata, das die Datendateien der Datenbank enthält. Der Mindest- und Standardwert für db2sapdataSize beträgt jeweils 30 GB.
    db2logSize Ganzzahl Die Größe von /db2/DBSID/logdir, die die Transaktionslogs der Datenbank enthält. Der Mindest- und Standardwert für db2logSize beträgt jeweils 8 GB.
    db2backupSize Ganzzahl Die Größe des Volumes /db2backup. Dieses Attribut ist optional. Wenn Sie den Wert auf 0 setzen oder weglassen, wird kein Laufwerk erstellt.
    db2sapdataSSD boolean Gibt an, ob das Datenlaufwerk einen nichtflüchtigen SSD-Speicher (Yes) oder einen nichtflüchtigen HDD-Speicher (No) verwendet. Standardmäßig ist Yes ausgewählt.
    db2logSSD boolean Gibt an, ob das Loglaufwerk einen nichtflüchtigen SSD-Speicher (Yes) oder einen nichtflüchtigen HDD-Speicher (No) verwendet. Standardmäßig ist Yes ausgewählt. SSD wird für das Loglaufwerk empfohlen.
    usrsapSize Ganzzahl Nur erforderlich, wenn Sie IBM Db2 und SAP NetWeaver auf derselben VM-Instanz ausführen.
    sapmntSize Ganzzahl Nur erforderlich, wenn Sie IBM Db2 und SAP NetWeaver auf derselben VM-Instanz ausführen.
    swapSize Ganzzahl Nur erforderlich, wenn Sie IBM Db2 und SAP NetWeaver auf derselben VM-Instanz ausführen.
    otherHost String Der Name der anderen VM-Instanz im IBM Db2-Hochverfügbarkeitscluster. Die VM-Instanz muss in der anderen Gruppe von Attributen in derselben Datei template_ha.yaml festgelegt sein.
    networkTag String Optional. Ein Netzwerk-Tag, das Ihre VM-Instanz für Firewall- oder Routingregeln darstellt. 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.
    publicIP boolean Optional. Legt fest, ob Ihre VM-Instanz eine öffentliche IP-Adresse erhält. Der Standardwert ist Yes.
    serviceAccount String Optional. Wenn Sie ein eigenes Dienstkonto mit gesperrten Berechtigungen erstellen, geben Sie hier den Namen des Kontos ein. Standardmäßig werden VMs mit dem Dienstkonto des Standardprojekts bereitgestellt. Beachten Sie, dass ein falsch definiertes Dienstkonto eine erfolgreiche Bereitstellung verhindert. Das folgende Beispiel zeigt ein benutzerdefiniertes Dienstkonto: myserviceuser@myproject.iam.gserviceaccount.com
    sap_deployment_debug boolean Optional. Wenn dieser Wert auf Yes festgelegt ist, werden bei der Bereitstellung ausführliche Bereitstellungslogs generiert. Aktivieren Sie diese Einstellung nur, wenn Sie von einem Google-Supporttechniker gebeten werden, das Debuggen zu aktivieren.
    post_deployment_script String Optional. Gibt den Speicherort eines Skripts an, das nach Abschluss der Bereitstellung ausgeführt werden soll. Das Skript sollte auf einem Webserver oder in einem Cloud Storage-Bucket gehostet werden. Die URL sollte mit http://, https:// oder gs:// beginnen. Dieses Skript wird auf allen VMs ausgeführt, die mit der Vorlage erstellt werden. Wenn Sie es nur auf der primären Instanz ausführen möchten, setzen Sie oben im Skript ein Häkchen.

    Mit den folgenden Beispiel-VM-Definitionen aus der Konfigurationsdatei template_ha.yaml werden zwei VMs für einen IBM Db2-Hochverfügbarkeitscluster erstellt. Die Konfigurationsdatei weist den Deployment Manager für jede VM an, die VM n1-standard-4 bereitzustellen, auf der ein Betriebssystem der Imagefamilie SLES 12 SP3 ausgeführt wird. Die VM enthält alle Verzeichnisse, die zum Ausführen eines IBM Db2-Hochverfügbarkeitsclusters benötigt werden. Deployment Manager erstellt die SAP NetWeaver-Verzeichnisse nicht, da die Verzeichnisgrößen auf 0 gesetzt sind.

    resources:
- name: sap_db2_primary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/sap_db2.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/202103310846/dm-templates/sap_db2/sap_db2.py
  #
  properties:
    instanceName: db2-ha-s1
    instanceType: n1-standard-4
    zone: us-central1-c
    subnetwork: example-sap-subnetwork
    linuxImage: family/sles-12-sp3-sap
    linuxImageProject: suse-sap-cloud
    db2SID: DH1
    db2sidSize: 16
    db2dumpSize: 16
    db2saptmpSize: 16
    db2sapdataSize: 50
    db2logSize: 16
    db2backupSize: 50
    db2sapdataSSD: Yes
    db2logSSD: Yes
    usrsapSize: 0
    sapmntSize: 0
    swapSize: 0
    otherHost: db2-ha-s2
#
# (Comment section omitted from example)
#
- name: sap_db2_secondary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/sap_db2.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/202103310846/dm-templates/sap_db2/sap_db2.py
  #
  properties:
    instanceName: db2-ha-s2
    instanceType: n1-standard-4
    zone: us-central1-f
    subnetwork: example-sap-subnetwork
    linuxImage: family/sles-12-sp3-sap
    linuxImageProject: suse-sap-cloud
    db2SID: DH1
    db2sidSize: 16
    db2dumpSize: 16
    db2saptmpSize: 16
    db2sapdataSize: 50
    db2logSize: 16
    db2backupSize: 50
    db2sapdataSSD: Yes
    db2logSSD: Yes
    usrsapSize: 0
    sapmntSize: 0
    swapSize: 0
    otherHost: db2-ha-s1

  6. Stellen Sie die VM-Instanz mit Deployment Manager bereit.

    gcloud deployment-manager deployments create DEPLOYMENT-NAME --config TEMPLATE-NAME.yaml

    Dabei gilt:

    • DEPLOYMENT-NAME steht für den von Ihnen für die aktuelle Bereitstellung ausgewählten Namen. Mit diesem Namen lässt sich die Bereitstellung auf der Seite Bereitstellungen der Google Cloud Console identifizieren.
    • TEMPLATE-NAME steht für den von Ihnen für die Konfigurationsdatei festgelegten Namen bzw. den Namen der Standarddatei template_ha.yaml, wenn Sie diesen übernommen haben.

    Deployment Manager liest die Spezifikationen in der Datei template_ha.yaml und konfiguriert die VM und die nichtflüchtigen Speicher entsprechend. Der Vorgang kann einige Minuten dauern. Führen Sie die Schritte im nächsten Abschnitt aus, um den Fortschritt der Bereitstellung zu überprüfen.

Deployment überprüfen

Zum Prüfen der Bereitstellung prüfen Sie die Bereitstellungslogs in Cloud Logging und die Konfiguration der VM.

Log prüfen

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

    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 IBM DB2 for SAP aufgeführten Anforderungen für IBM DB2 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 VM prüfen

  1. Stellen Sie nach Abschluss der VM-Bereitstellung mit ssh eine Verbindung zu jeder VM her. Sie können wahlweise in Compute Engine auf der Seite "VM-Instanzen" für jede VM-Instanz auf die Schaltfläche "SSH" klicken oder Ihre bevorzugte SSH-Methode verwenden.

    Schaltfläche "SSH" auf der Seite "VM-Instanzen" von Compute Engine

  2. Wechseln Sie zum Root-Nutzer.

    sudo su -

  3. Geben Sie bei der Eingabeaufforderung df -h ein. Prüfen Sie, ob eine Ausgabe ähnlich der folgenden angezeigt wird:

    db2-ha-s1:~ # df -h
Filesystem                     Size  Used Avail Use% Mounted on
devtmpfs                       7.4G     0  7.4G   0% /dev
tmpfs                           12G     0   12G   0% /dev/shm
tmpfs                          7.4G   18M  7.4G   1% /run
tmpfs                          7.4G     0  7.4G   0% /sys/fs/cgroup
/dev/sda1                       30G  2.2G   26G   8% /
/dev/mapper/vg_db2sid-vol       16G   33M   16G   1% /db2/DH1
/dev/mapper/vg_db2dump-vol      16G   33M   16G   1% /db2/DH1/db2dump
/dev/mapper/vg_db2sapdata-vol   50G   33M   50G   1% /db2/DH1/sapdata
/dev/mapper/vg_db2saptmp-vol    16G   33M   16G   1% /db2/DH1/saptmp
/dev/mapper/vg_db2log-vol       16G   33M   16G   1% /db2/DH1/log_dir
/dev/mapper/vg_db2home-vol      16G   33M   16G   1% /db2/db2dh1
/dev/mapper/vg_db2backup-vol    50G   33M   50G   1% /db2backup
tmpfs                          1.5G     0  1.5G   0% /run/user/1001

Wenn einer der Überprüfungsschritte auf eine fehlgeschlagene Installation hindeutet:

  1. Korrigieren Sie den Fehler.
  2. Löschen Sie auf der Seite Bereitstellungen die Bereitstellung, um die VMs und nichtflüchtigen Speicher aus der fehlgeschlagenen Installation zu entfernen.
  3. Führen Sie die Bereitstellung noch einmal aus.

Floating-IP-Adresse reservieren

Sie müssen eine IP-Adresse auswählen, die als Floating-IP-Adresse verwendet werden soll. Sie benötigen diese IP-Adresse später, wenn Sie die Metadaten der Host-VM-Instanz festlegen und IBM Db2 sowie den Hochverfügbarkeitscluster installieren und konfigurieren.

Abhängig davon, ob Sie für die Floating-IP-Adresse einen Routen- oder Alias-IP-Implementierungstyp auswählen, gelten für die Floating-IP-Adresse unterschiedliche Anforderungen.

Bei einer statischen Routenimplementierung für die Floating-IP-Adresse muss sich die IP-Adresse außerhalb des IP-Adressbereichs des Subnetzwerks befinden. Außerdem kann sie in den erweiterten Netzwerken Ihres Unternehmens von nichts anderem verwendet werden. Wenden Sie sich an Ihren Netzwerkadministrator, um eine geeignete IP-Adresse zu ermitteln.

Bei einer Alias-IP-Adressimplementierung für die Floating-IP-Adresse müssen Sie eine IP-Adresse aus dem IP-Adressbereich des Subnetzwerks reservieren, das die Hosts verwenden.

Reservieren Sie nur für Alias-IP-Adressimplementierungen eine Alias-IP-Adresse:

  1. Öffnen Sie ein Terminal auf einer Host-VM oder öffnen Sie Cloud Shell.

    Zu Cloud Shell

  2. Reservieren Sie eine IP-Adresse.

    gcloud compute addresses create vip-name --region region --subnet subnet-name \
  --addresses ip-addr-optional

    Die Angabe der IP-Adresse ist optional. Wenn Sie keine IP-Adresse eingeben, wählt Compute Engine eine IP-Adresse aus dem Subnetz aus.

  3. Lassen Sie die reservierte IP-Adresse anzeigen und notieren Sie sie. Sie benötigen sie zum Installieren des Datenbankservers und zum Konfigurieren des Hochverfügbarkeitsclusters.

    gcloud compute addresses describe vip-name --region=region

    Beispiel: 

    db2-ha-s1:~ # gcloud compute addresses describe db2-ha-vip-dh1 --region=us-central1
address: 10.1.0.30
addressType: INTERNAL
creationTimestamp: '2018-11-28T11:34:14.478-08:00'
description: ''
id: '6558342813288977241'
kind: compute#address
name: db2-ha-vip-dh1
region: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1/addresses/db2-ha-vip-dh1
status: RESERVED
subnetwork: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1/subnetworks/example-sap-   subnetwork

Floating-IP-Adresse den Metadaten für jede Host-VM-Instanz hinzufügen

Sie geben Informationen zur Floating-IP-Adresse als benutzerdefinierte Metadaten für jede VM-Instanz im Cluster an. Hierzu zählt auch der gewählte Typ der Routen- oder Alias-IP-Implementierung, Weitere Informationen zum Auswählen eines Implementierungstyps für Ihre Floating-IP-Adresse finden Sie unter Floating-IP-Adressen für IBM Db2-Hochverfügbarkeitscluster in Google Cloud.

Die festzulegenden Metadatenparameter variieren je nach Implementierungstyp. Befolgen Sie in den nächsten beiden Abschnitten die Anleitung, die sich auf den verwendeten Implementierungstyp der Floating-IP-Adresse bezieht.

Metadaten für Routenimplementierung der Floating-IP-Adresse festlegen

Legen Sie die Instanzmetadaten bei einer Routenimplementierung für die Floating-IP-Adresse anhand der Parameter in der folgenden Tabelle und dem darunter angegebenen Verfahren fest.

Parameter Wert Zweck
sap_ibm_vip_solution route Gibt an, dass es sich um eine Bereitstellung in mehreren Zonen handelt, die eine statische Google Cloud-Route verwendet, um den Wechsel der Floating-IP-Adresse zwischen Hosts zu unterstützen.
sap_ibm_db2_vip ip-address Gibt die Floating-IP-Adresse an, die Sie im vorherigen Schritt reserviert haben.
sap_ibm_db2_routename route-name Gibt einen beliebigen Namen für die statische Route an. Sie können beispielsweise db2-dh1-vip-route verwenden.
sap_ibm_db2_routenet vpc-network-name Gibt das VPC-Netzwerk an, das den IBM Db2-Hochverfügbarkeitscluster enthält.

So legen Sie die Instanzmetadaten für eine statische Routenimplementierung der Floating-IP-Adresse fest:

  1. Öffnen Sie ein Terminal auf einer Host-VM oder öffnen Sie Cloud Shell.

    Zu Cloud Shell

  2. Geben Sie für jede Host-VM-Instanz im Cluster dieselben Metadaten für die Routenimplementierung der Floating-IP-Adresse an.

    gcloud compute instances add-metadata instance-name \
--metadata sap_ibm_vip_solution=route,sap_ibm_db2_vip=ip-address,\
sap_ibm_db2_routename=route-name,sap_ibm_db2_routenet=vpc-network-name \
--zone instance-zone

Metadaten für Alias-IP-Adressimplementierung der Floating-IP-Adresse festlegen

Legen Sie die Instanzmetadaten bei einer Alias-IP-Adressimplementierung für die Floating-IP-Adresse anhand der Parameter in der folgenden Tabelle und dem darunter angegebenen Verfahren fest.

Parameter Wert Zweck
sap_ibm_vip_solution alias Gibt an, dass es sich um eine Bereitstellung in einer Zone handelt, die eine Alias-IP-Adresse von Google Cloud verwendet, um den Wechsel der Floating-IP-Adresse zwischen Hosts zu unterstützen.
sap_ibm_db2_vip ip-address Gibt die Floating-IP-Adresse an, die Sie im vorherigen Schritt reserviert haben.
sap_ibm_db2_vip_range alias-ip-range-name Gibt optional einen beliebigen Namen für den Alias-IP-Bereich an. Sie können beispielsweise db2-dh1-vip-alias verwenden. Der Standardwert ist der Name des Subnetzwerks.

So legen Sie die Instanzmetadaten für eine Alias-IP-Adressimplementierung der Floating-IP-Adresse fest:

  1. Öffnen Sie ein Terminal auf einer Host-VM oder öffnen Sie Cloud Shell.

    Zu Cloud Shell

  2. Geben Sie für jede Host-VM-Instanz im Cluster dieselben Metadaten für die Alias-IP-Adressimplementierung der Floating-IP-Adresse an.

    gcloud compute instances add-metadata instance-name \
--metadata sap_ibm_vip_solution=alias,sap_ibm_db2_vip=ip-address,\
sap_ibm_db2_vip_range=alias-ip-range-name --zone instance-zone

Instanzmetadaten überprüfen oder ändern

So überprüfen Sie die von Ihnen festgelegten Instanzmetadaten.

gcloud compute instances describe instance-name --zone instance-zone

So ändern Sie die benutzerdefinierten Metadaten.

gcloud compute instances add-metadata instance-name --metadata  parm-name=parm-value

Hostnamen und IP-Adressen zu /etc/hosts hinzufügen

Während der Einrichtung des Clusters werden vom SAP-Clustereinrichtungstool die Hostnamen und internen IP-Adressen jeder Host-VM sowie die Floating-IP-Adresse überprüft. Für eine erfolgreiche Validierung fügen Sie der Datei /etc/hosts auf jeder Host-VM mithilfe Ihres bevorzugten Editors die IP-Adresse, den Hostnamen und den internen DNS-Namen der VPC hinzu.

Hier ein Beispiel für die Aktualisierung von /etc/hosts als Root-Nutzer:

echo "#Db2 HA floating IP additions" >> /etc/hosts
echo 10.2.0.24 db2-ha-vip-dh1 db2-ha-vip-dh1.c.solutions-writers.internal >> /etc/hosts
echo 10.1.0.3 db2-ha-s1 db2-ha-s1.us-central1-c.c.db2-ha-project.internal >> /etc/hosts
echo 10.1.0.2 db2-ha-s2 db2-ha-s2.us-central1-f.c.db2-ha-project.internal >> /etc/hosts

In diesem Beispiel ist der String zwischen dem Hostnamen und >> in jeder Zeile ein interner VPC-DNS-Name, der vom internen VPC-DNS-Dienst verwendet wird.

Die Host-VMs verwenden einen zonalen internen DNS-Namen, der ein Feld für die Zone enthält. Die Floating-IP-Adresse verwendet einen globalen internen DNS-Namen. Dieser enthält kein Zonenfeld.

Zum Abrufen des internen DNS-Namens für einen VM-Host können Sie von einem Terminal auf der Host-VM aus den folgenden Befehl eingeben:

curl "http://metadata.google.internal/computeMetadata/v1/instance/hostname" \
-H "Metadata-Flavor: Google"

Für eine Floating-IP-Adresse können Sie diese selbst im folgenden Format eingeben.

vip-host-name.c.project-name.internal

Nachdem Sie die Datei /etc/hosts aktualisiert haben, sollten die relevanten Informationen in der Datei /etc/hosts etwa so aussehen:

#Db2 HA floating IP additions
10.2.0.24 db2-ha-vip-dh1 db2-ha-vip-dh1.c.solutions-writers.internal
10.1.0.3 db2-ha-s1 db2-ha-s1.us-central1-c.c.db2-ha-project.internal
10.1.0.2 db2-ha-s2 db2-ha-s2.us-central1-f.c.db2-ha-project.internal

Betriebssystem vorbereiten

Bereiten Sie nach dem Erstellen der VM das Betriebssystem für den IBM Db2-Hochverfügbarkeitscluster vor.

Die Anforderungen werden von SAP und IBM definiert. Laut der SAP-Dokumentation ist die Installation von Software wie Perl- und Korn-Shell erforderlich. Diese ist möglicherweise nicht auf Ihren Compute Engine-Host-VMs vorinstalliert.

Prüfen Sie die folgenden Dokumente bezüglich der aktuellen Anforderungen:

Datenbankserver installieren und IBM Db2-Hochverfügbarkeitscluster erstellen

Lesen Sie erst die Übersicht des folgenden Verfahrens, insbesondere die Hinweise, bevor Sie IBM Db2 und den Hochverfügbarkeitscluster gemäß der Anleitung unter IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms installieren und konfigurieren.

Informationen zum Installieren von SAP NetWeaver und des primären Anwendungsservers finden Sie in der Google Cloud-Dokumentation zu SAP NetWeaver und in den entsprechenden SAP-Installationsanleitungen im SAP Help Portal.

Die folgenden Schritte geben einen groben Überblick über den Installationsvorgang. Weitere Details finden Sie in der SAP-Dokumentation.

  1. Stellen Sie gemäß der Anleitung in der SAP-Dokumentation zwischen der primären und der sekundären Instanz sowie zwischen jeder Instanz und sich selbst eine schlüsselbasierte SSH-Verbindung her. SSH wird vom SAP-Clustereinrichtungstool verwendet. Testen Sie alle Verbindungen auf jedem Host. Testen Sie beispielsweise auf db2-ha-s1 die folgenden beiden Verbindungen.

    • ssh db2-ha-s1
    • ssh db2-ha-s2

  2. Laden Sie den vollständigen SAP-Mediensatz für Db2 vom SAP Support Portal auf die VM herunter oder kopieren Sie ihn.

  3. Installieren Sie auf der primären Host-VM mithilfe von SAP Software Provisioning Manager (SWPM) den IBM Db2-Datenbankserver.

  4. Richten Sie auf der sekundären Host-VM die Standby-Datenbank ein. Verwenden Sie hierfür beispielsweise eine homogene SAP-Systemkopie.

  5. Installieren Sie auf beiden Host-VMs die Lizenzdateien für IBM Db2 und IBM TSAMP. Weitere Informationen zum Installieren der von SAP bezogenen IBM-Lizenzen finden Sie im SAP-Hinweis 816773 zum Installieren einer SAP-OEM-Lizenz für Db6.

  6. Installieren Sie auf beiden Host-VMs die neueste Version von TSAMP, die von Ihrer Datenbank- und Betriebssystemversion unterstützt wird.

  7. Konfigurieren und erstellen Sie auf der primären Host-VM mithilfe der neuesten Version des SAP-Clustereinrichtungstools sapdb2cluster.sh den IBM Db2-Hochverfügbarkeitscluster.

  8. Nachdem der Cluster erstellt wurde, testen Sie auf dem primären Host die Failover-Fähigkeit des Clusters mithilfe des Konfigurationsdienstprogramms für Db2-Hochverfügbarkeitsinstanzen (db2haicu).

    1. Beenden Sie das SAP-Clustereinrichtungstool und die Korn-Shell.

    2. Prüfen Sie auf der primären Instanz, ob der primäre Datenbankserver online ist.

      lssam

      Im folgenden Beispielauszug der lssam-Ausgabe ist die primäre Datenbankinstanz online:

      Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online
        '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs
                |- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1
                '- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2

    3. Wechseln Sie zum Nutzer der Datenbankinstanz.

      sudo su - db2sid

    4. Starten Sie das Dienstprogramm db2haicu.

      db2haicusid

    5. Wählen Sie auf der Benutzeroberfläche von db2haicu Option 5 aus und folgen Sie den Eingabeaufforderungen.

    6. Beenden Sie das Dienstprogramm db2haicu.

    7. Überprüfen Sie auf dem primären Host, ob der sekundäre Host jetzt online ist.

      lssam

      Im folgenden Beispielauszug der lssam-Ausgabe ist die sekundäre Datenbankinstanz online:

      Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online
        '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs
                |- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1
                '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2

Befolgen Sie zum Fertigstellen der Clusterkonfiguration die Anleitung im nächsten Abschnitt. Sie erstellen damit eine benutzerdefinierte TSAMP-Ressource für die Floating-IP-Adresse und verknüpfen diese in TSAMP mit der IBM Db2-Instanzressource.

Benutzerdefinierte TSAMP-Ressource für Floating-IP-Adresse erstellen

Damit TSAMP die Floating-IP-Adresse verwalten kann, müssen Sie eine benutzerdefinierte TSAMP-Ressource erstellen. Zum Verwalten der Ressource für die Floating-IP-Adresse muss TSAMP mit Google Cloud interagieren. Laden Sie hierfür ein Hilfsskript von Google Cloud herunter, das Sie entsprechend konfigurieren.

Google Cloud-Hilfsskript herunterladen

Laden Sie das Google Cloud-Hilfsskript auf jeden Host im Cluster herunter und legen Sie die Berechtigungen des Skripts fest.

  1. Laden Sie das Skript als Root-Nutzer aus dem Verzeichnis /root der primären VM sowohl auf den primären Host als auch auf den Standby-Host herunter.

    Für Instanzen, die keine freigegebene VPC-Konfiguration verwenden: 

    wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_db2/utility/gcp_floating_ip.sh -O gcp_floating_ip.sh
    Für Instanzen mit einer freigegebenen VPC-Konfiguration: 
    wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_db2/utility/gcp_floating_ip_svpc.sh -O gcp_floating_ip.sh

  2. Legen Sie auf beiden Hosts die Skriptberechtigungen fest.

    chmod 744 gcp_floating_ip.sh

Benutzerdefinierte TSAMP-Ressource für Floating-IP-Adresse erstellen und konfigurieren

Erstellen und konfigurieren Sie auf einem beliebigen Host im Cluster eine benutzerdefinierte TSAMP-Ressource für die Floating-IP-Adresse.

  1. Erstellen Sie auf einem beliebigen Host mit der von Ihnen bevorzugten Methode eine Konfigurationsdatei mit dem Namen cluster_res.conf. Fügen Sie den folgenden Text ein, nachdem Sie den Parameter NodeNameList mit den Hostnamen aktualisiert haben.

    PersistentResourceAttributes::
  Name="gcp_floating_ip-rs"
  ResourceType=1
  StartCommand="/root/gcp_floating_ip.sh start"
  StopCommand="/root/gcp_floating_ip.sh stop"
  MonitorCommand="/root/gcp_floating_ip.sh status"
  MonitorCommandPeriod=30
  MonitorCommandTimeout=30
  StartCommandTimeout=600
  StopCommandTimeout=600
  UserName="root"
  RunCommandsSync=1
  ProtectionMode=0
  NodeNameList={"host-1","host-2"}

  2. Erstellen Sie als Root-Nutzer mit folgenden Befehlen die benutzerdefinierte TSAMP-Ressource auf dem primären Host.

    export CT_MANAGEMENT_SCOPE=2
mkrsrc -f cluster_res.conf IBM.Application
mkrg -l None gcp_floating_ip-rg
chrg -o Online gcp_floating_ip-rg
addrgmbr -g gcp_floating_ip-rg -m F IBM.Application:gcp_floating_ip-rs
rgreq -o start gcp_floating_ip-rg

  3. Überprüfen Sie als Root-Nutzer, ob sowohl die Db2-Instanzressource als auch die Floating-IP-Adressressource auf dem primären Host online sind.

    lssam

    In der Ausgabe sollten sich die Onlineressourcen alle auf denselben Host-VMs befinden:

    Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online
        '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs
                |- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1
                '- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2
Online IBM.ResourceGroup:gcp_floating_ip.sh_rg Nominal=Online
        '- Online IBM.Application:gcp_floating_ip.sh_rs
                |- Online IBM.Application:gcp_floating_ip.sh_rs:db2-ha-s1
                '- Offline IBM.Application:gcp_floating_ip.sh_rs:db2-ha-s2

    Wenn die Ressource der Floating-IP-Adresse nicht auf demselben Host wie die Datenbankinstanz online ist, verschieben Sie die Floating-IP-Adressressource.

    rgreq -o move -n host-to-move-from gcp_floating_ip-rg

  4. Stellen Sie als Root-Nutzer auf dem primären Host in TSAMP eine Beziehung zwischen der Datenbankinstanzressource und der Floating-IP-Adressressource her.

    rgreq -o lock gcp_floating_ip-rg
rgreq -o lock db2_db2sid_db2sid_SID-rg
mkrel -o NoCondition -p Collocated \
  -S IBM.Application:gcp_floating_ip-rs -G IBM.Application:db2_db2sid_db2sid_SID-rs \
  db2hadr_colo_gcp_floating_ip
rgreq -o unlock db2_db2sid_db2sid_SID-rg
rgreq -o unlock gcp_floating_ip-rg

    Nachdem Sie eine Beziehung zwischen der Datenbankinstanzressource und der Floating-IP-Adressressource hergestellt haben, können Sie das Failover wie im nächsten Abschnitt beschrieben noch einmal testen.

Bereitstellung des Db2-Hochverfügbarkeitsclusters für SAP in Google Cloud überprüfen

Bestätigen Sie, dass der IBM Db2-Hochverfügbarkeitscluster ordnungsgemäß konfiguriert wurde. Lösen Sie hierfür ein Failover aus und prüfen Sie, ob alle Onlineressourcen von einer Host-VM zur anderen verschoben wurden.

So führen Sie einen Failover-Test durch:

  1. Ermitteln Sie auf dem primären Host als Root-Nutzer die Host-VM, auf der aktuell die Ressourcen online sind.

    lssam

  2. Wechseln Sie auf dem primären Host zum Nutzer der Db2-Instanz.

    sudo su - db2sid

  3. Starten Sie das Dienstprogramm db2haicu.

    db2haicu

  4. Lösen Sie auf der Benutzeroberfläche des Dienstprogramms db2haicu ein Failover aus. Wählen Sie hierfür die Option 5 aus und folgen Sie den Eingabeaufforderungen.

  5. Nachdem die Verarbeitung durch das Dienstprogramm db2haicu abgeschlossen ist, beenden Sie das Dienstprogramm.

  6. Wechseln Sie zum Root-Nutzer.

    sudo su -

  7. Überprüfen Sie, ob die Onlineressourcen zur anderen Host-VM verschoben wurden.

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

Aufgaben nach dem Deployment ausführen

Bevor Sie das IBM Db2-Hochverfügbarkeitssystem auf Google Cloud verwenden, empfiehlt es sich, alle nach der Installation erforderlichen Aufgaben durchzuführen, die in IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms beschrieben sind. Hierzu zählt Folgendes:

  1. Datenbankcluster prüfen

  2. TSAMP-Kernrichtlinie sichern

  3. Datenbank-Fixpacks aktualisieren

  4. Db2-Clientverbindungen mit dem Hostnamen und der IP-Adresse der Floating-IP-Adresse aktualisieren. Aktualisieren Sie beispielsweise die Datei db2cli.ini auf den SAP ABAP-Anwendungsservern.

Wenn Sie für den DB2-Hochverfügbarkeitscluster ein NAT-Gateway verwenden, richten Sie das NAT-Gateway wie in der Anleitung zur Bereitstellung von IBM Db2 für SAP im Abschnitt NAT-Gateway-Installation abschließen beschrieben ein.