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

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

Diese Anleitung ergänzt die Anleitung von SAP und IBM in IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms. Verwenden Sie für die Installation und Konfiguration eines IBM Db2-Hochverfügbarkeitsclusters auf der GCP 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 auf der GCP entweder mit einer statischen GCP-Route oder einer 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 GCP-Dokumentation, bevor Sie mit den Verfahren in dieser Anleitung beginnen. Während der Bereitstellung kann es mitunter erforderlich sein, die SAP- und die GCP-Dokumentation hinzuzuziehen.

Vorbereitung

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

  • Sie oder Ihre Organisation haben ein GCP-Konto und ein Projekt für die Bereitstellung des IBM Db2-Hochverfügbarkeitsclusters erstellt. Wie Sie GCP-Projekte erstellen, lesen Sie im Abschnitt Vorbereitung der Anleitung zur Bereitstellung von IBM Db2 für SAP.
  • Sie haben auf der GCP ein Virtual Private Cloud-Netzwerk. Wie Sie ein VPC-Netzwerk konfigurieren, Firewallregeln erstellen und 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.

IBM Db2-Hochverfügbarkeitscluster auf der GCP bereitstellen

In dieser Anleitung wird gezeigt, wie Sie zwei VMs bereitstellen, eine Floating-IP-Adresse definieren und die Alias-IP-Adresse oder die GCP-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 GCP-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 die GCP 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 GCP-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 Deployments für Ihr Projekt auf der Seite "Deployments" in der GCP Console ansehen und bearbeiten.

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

  • Beim Löschen eines Deployments 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 Ihrem neuen Deployment 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 das neue Deployment löschen, wird die erworbene VM aus dem Deployment gelöscht, mit dem 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 Konfigurationsdateivorlage template_ha.yaml in Ihr Arbeitsverzeichnis herunter:

    wget https://storage.googleapis.com/sapdeploy/dm-templates/sap_db2/template_ha.yaml
    
  2. Klicken Sie zum Öffnen des Cloud Shell-Codeeditors rechts oben im Cloud Shell-Terminalfenster auf Codeeditor starten und dann auf Erstellen.

  3. Sie können die Datei template_ha.yaml umbenennen, sodass der Name auf die damit definierte Konfiguration verweist. Beispiel: db2_ha_s123_dh1.yaml.

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

  5. Definieren Sie in der Datei template_ha.yaml die VMs und die nichtflüchtigen Speicher. Die Datei template_ha.yaml enthält die beiden 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 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
    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. Diese muss sich in der Region befinden, die Sie für das Subnetzwerk ausgewählt haben.
    subnetwork String Der Name des Subnetzwerks, das Sie in einem vorherigen Schritt erstellt haben. Wenn die Bereitstellung in einer freigegebenen VPC erfolgt, geben Sie als Wert 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 Imagefamilie 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 Imagefamilien finden Sie in der GCP Console auf der Seite Images.
    linuxImageProject String Das GCP-Projekt, in dem das zu verwendende Image enthalten ist. Dabei kann es sich um Ihr eigenes Projekt oder ein GCP-Imageprojekt handeln, z. B. rhel-sap-cloud oder suse-sap-cloud. Eine Liste der GCP-Imageprojekte finden Sie in der Compute Engine-Dokumentation auf der Seite Images.
    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 Fehlern 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, das 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 Datenträger erstellt.
    db2sapdataSSD Boolesch Gibt an, ob das Datenlaufwerk einen nichtflüchtigen SSD-Speicher (Yes) oder einen nichtflüchtigen HDD-Speicher (No) verwendet. Yes ist die Standardeinstellung.
    db2logSSD Boolesch Gibt an, ob das Loglaufwerk einen nichtflüchtigen SSD-Speicher (Yes) oder einen nichtflüchtigen HDD-Speicher (No) verwendet. Yes ist die Standardeinstellung. 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ügbarkeitscuster. 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 die VM-Instanz für Firewall- oder Routingzwecke darstellt. Wenn Sie publicIP: No ohne ein Netzwerk-Tag angeben, müssen Sie eine andere Möglichkeit für den Zugriff auf das Internet bereitstellen.
    publicIP Boolesch Optional. Legt fest, ob die 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 Boolesch Optional. Wenn dieser Wert auf Yes festgelegt ist, werden durch die 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 Masterinstanz 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 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.

    imports:
    - path: https://storage.googleapis.com/sapdeploy/dm-templates/sap_db2/sap_db2.py
    
    resources:
    - name: sap_db2_primary
      type: https://storage.googleapis.com/sapdeploy/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/sapdeploy/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 wird die Bereitstellung auf der Seite Deployments der GCP-Konsole identifiziert.
    • 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.

Bereitstellung überprüfen

In den folgenden Schritten wird Stackdriver Logging verwendet, für das möglicherweise Gebühren anfallen. Weitere Informationen finden Sie unter Stackdriver – Preise.

  1. Öffnen Sie Stackdriver Logging, um nach Fehlern zu suchen und den Fortschritt der Installation zu überwachen.

    Zu Stackdriver Logging

  2. Wählen Sie auf dem Tab Ressourcen die Option Global als Logging-Ressource aus. Wenn für eine VM INSTANCE DEPLOYMENT COMPLETE angezeigt wird, ist die Deployment Manager-Verarbeitung für die VM abgeschlossen.

    Logging-Anzeige

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

  4. Wechseln Sie zum Root-Nutzer.

    sudo su -
  5. Führen Sie über die Eingabeaufforderung df -h aus. 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 "Deployments" das Deployment, 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 eine Routen- oder Alias-IP-Implementierung 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.

    Cloud Shell öffnen

  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-HA-Cluster auf der GCP.

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 GCP-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. Beispiel: db2-dh1-vip-route
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.

    Cloud Shell öffnen

  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 GCP-Alias-IP-Adresse 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. Beispiel: db2-dh1-vip-alias. Standardmäßig wird der Name des Subnetzwerks verwendet.

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.

    Cloud Shell öffnen

  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 Überprüfung 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.

Überprü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 GCP-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. Überprüfen Sie auf der primären Instanz, ob der primäre Datenbankserver online ist.

      lssam

      Im folgenden Beispielauszug der Ausgabe lssam 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 befolgen Sie die 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 der GCP interagieren. Laden Sie hierfür ein Hilfsskript von der GCP herunter, das Sie entsprechend konfigurieren.

GCP-Hilfsskript herunterladen

Laden Sie das GCP-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.

    wget https://storage.googleapis.com/sapdeploy/gceTSAMP/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 auf GCP überprüfen

Bestätigen Sie, dass der IBM Db2-Hochverfügbarkeitscluster ordnungsgemäß konfiguriert wurde. Lösen Sie hierfür ein Failover aus und überprü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 und befolgen Sie die 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.

Aufgaben nach der Bereitstellung ausführen

Bevor Sie das IBM Db2-Hochverfügbarkeitssystem auf der GCP 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 überprü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.

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...