SAP HANA-Dateisysteme auf einzelne Laufwerke migrieren

In diesem Dokument wird beschrieben, wie Sie die Dateisysteme in Ihrer SAP HANA-Bereitstellung auf Google Cloud zu einzelnen SSD-basierten Persistent Disk- oder Google Cloud Hyperdisk-Volumes migrieren.

Bei SAP HANA-Bereitstellungen auf Google Cloud wird entweder das einheitliche Laufwerklayout oder das geteilte Laufwerklayout verwendet. Beim einheitlichen Laufwerklayout wird ein einzelnes Laufwerk zum Hosten aller SAP HANA-Dateisysteme verwendet. Beim Split-Disk-Layout wird jedes SAP HANA-Dateisystem auf einem separaten Laufwerk gehostet. Informationen zu diesen Laufwerklayouts finden Sie unter Unterstützte Laufwerklayouts.

Google Cloud empfiehlt aus folgenden Gründen, das Layout mit geteilter Festplatte zu verwenden:

  • Sie ermöglicht eine unabhängige Laufwerksleistungsoptimierung für die Dateisysteme, insbesondere für /hana/data und /hana/log, und insbesondere bei Verwendung von Hyperdisk.
  • Sie vereinfacht die Wartung.

Zur Veranschaulichung des Migrationsverfahrens wird in diesem Leitfaden ein Beispielsystem verwendet und die SAP HANA-Dateisysteme werden von einem einzelnen Persistent Disk-Volume zu einem Hyperdisk-Volume für jedes Dateisystem migriert. Mit diesem Verfahren können Sie auch die SAP HANA-Dateisysteme zu einzelnen Persistent Disk-Volumes migrieren.

Hinweise zur Migration

  • Dauer der Datenmigration: Bei einem SAP HANA-HA-System können Sie die Dauer der Datenmigration verkürzen, indem Sie den sekundären Knoten abmelden, seine Mandantendatenbanken löschen und dann die Protokolle wiederverwenden. Bei der in diesem Leitfaden beschriebenen Vorgehensweise wird dieser Ansatz verwendet.
  • Ausfallzeit: Bei einem SAP HANA-HA-System migrieren Sie zuerst die sekundäre Datenbank, machen sie zur neuen primären Datenbank und migrieren dann die ehemalige primäre Datenbank. So wird eine minimale Ausfallzeit erreicht.
  • Zurück zu vorhandenen Laufwerken: Bei einem Problem während der Migration können Sie die vorhandenen Laufwerke wiederherstellen, da sie von diesem Verfahren nicht betroffen sind und bis zum Löschen verfügbar sind. Weitere Informationen finden Sie unter Zu vorhandenen Laufwerken wechseln.

Hinweise

Prüfen Sie vor der Migration der SAP HANA-Dateisysteme, die auf einem einzelnen Laufwerk gehostet werden, auf ein Laufwerk pro Dateisystem, ob die folgenden Bedingungen erfüllt sind:

  • SAP HANA wird auf SAP-zertifizierten Compute Engine-Instanzen ausgeführt, die Hyperdisk unterstützen.
  • Eine gültige Sicherung der SAP HANA-Datenbank ist verfügbar. Mit dieser Sicherung kann die Datenbank bei Bedarf wiederhergestellt werden.
  • Wenn die Ziel-Compute Engine-Instanz Teil eines Hochverfügbarkeitsclusters (HA) ist, achten Sie darauf, dass sich der Cluster im Wartungsmodus befindet.
  • Wenn für Ihre SAP HANA-Datenbank eine Bereitstellung mit horizontaler Skalierung verwendet wird, wiederholen Sie die Schritte in dieser Anleitung für jede SAP HANA-Instanz.
  • Die SAP HANA-Datenbank ist einsatzbereit. Bei HA-Systemen muss die Replikation zwischen der primären und der sekundären Instanz Ihrer Datenbank aktiv sein.
  • Entfernen Sie alle nicht benötigten Sicherungen oder Medien von den zu migrierenden SAP HANA-Volumen, um die Zeit für das Kopieren der Daten zu verkürzen.

  • Prüfen Sie mit dem folgenden Befehl, ob die zu migrierenden SAP HANA-Dateisysteme auf einem einzigen Laufwerk gehostet werden:

    lsblk

    Die Ausgabe sieht etwa so aus wie im folgenden Beispiel. Die Ausgabe kann sich je nach Benennungskonvention für die SAP HANA-Dateisysteme oder je nachdem, ob Ihre Compute-Instanz die NVMe-Laufwerkschnittstelle (Non-Volatile Memory Express) unterstützt, von diesem Beispiel unterscheiden.

    NAME                   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda                      8:0    0   30G  0 disk
├─sda1                   8:1    0    2M  0 part
├─sda2                   8:2    0   20M  0 part /boot/efi
└─sda3                   8:3    0   30G  0 part /
sdb                      8:16   0  2.3T  0 disk
├─vg_hana-shared       254:0    0  850G  0 lvm  /hana/shared
├─vg_hana-sap          254:1    0   32G  0 lvm  /usr/sap
├─vg_hana-log          254:2    0  425G  0 lvm  /hana/log
└─vg_hana-data         254:3    0    1T  0 lvm  /hana/data
sdc                      8:32   0  1.7T  0 disk
└─vg_hanabackup-backup 254:4    0  1.7T  0 lvm  /hanabackup

Beispiel für ein SAP-System

Zur Veranschaulichung des Migrationsverfahrens wird in diesem Leitfaden Folgendes getan:

  • Es wird eine Beispielbereitstellung mit vertikaler Skalierung und Hochverfügbarkeit (HA) von SAP HANA angenommen, bei der die Dateisysteme /hana/data, /hana/log, /hana/shared und /usr/sap auf einem einzelnen Volume mit nichtflüchtigem Speicher gehostet werden.
  • Migriert die Dateisysteme zu einzelnen Hyperdisk-Volumes, die in der Konfiguration dem SAP HANA-Hochverfügbarkeitssystem mit vertikaler Skalierung ähneln, das mithilfe des Terraform: Konfigurationsleitfadens für SAP HANA-Hochverfügbarkeitscluster mit vertikaler Skalierung bereitgestellt wurde.

Das folgende Diagramm zeigt die Architektur des Beispielsystems vor und nach der Migration seiner Dateisysteme:

Architekturdiagramm, das die Migration von SAP HANA-Dateisystemen auf einzelne Laufwerke auf Google Cloudzeigt

Die Konfigurationsdetails des Beispiel-SAP-Systems sind:

  • Maschinentyp: n2-highmem-128
  • Betriebssystem: SLES for SAP 15 SP5
  • SAP HANA: HANA 2 SPS07, Rev. 78
  • Vom System verwendeter Laufwerktyp: Nichtflüchtiger SSD-Speicher (pd-ssd)

  • Die Volumes /hana/data, /hana/log, /hana/shared und /usr/sap werden auf demselben Laufwerk bereitgestellt und in den Speichereinstellungen für SAP HANA konfiguriert. Im Folgenden finden Sie ein Beispiel für die Einstellungen für die /hana/data- und /hana/log-Volumes eines SAP HANA-Systems mit der SID ABC:

    [persistence]
basepath_datavolumes = /hana/data/ABC
basepath_logvolumes = /hana/log/ABC

Dateisysteme zu einzelnen Hyperdisk-Volumes migrieren

So migrieren Sie die Dateisysteme einer SAP HANA-Bereitstellung mit vertikaler Skalierung und Hochverfügbarkeit von einem einzelnen Persistent Disk-Volume zu einem Hyperdisk-Volume für jedes Dateisystem:

  1. Sekundäre Instanz für die Migration vorbereiten
  2. Migrieren Sie die sekundäre Instanz.
  3. Stellen Sie die sekundäre Instanz in den primären Status.
  4. Migrieren Sie die bisherige primäre Instanz.

Sekundäre Instanz für die Migration vorbereiten

  1. Versetzen Sie den Hochverfügbarkeitscluster in den Wartungsmodus:

    crm maintenance on

  2. Prüfen, ob die HANA-Systemreplikation (HSR) aktiv ist:

    /usr/sap/ABC/HDB00/exe/python_support> python systemReplicationStatus.py

    Die Ausgabe sieht etwa so aus wie im folgenden Beispiel.

    /usr/sap/ABC/HDB00/exe/python_support> python systemReplicationStatus.py
|Database |Host        |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary |Secondary |Secondary |Secondary   |Secondary     |Replication |Replication |Replication    |Secondary    |
|         |            |      |             |          |        |          |Host      |Port      |Site ID   |Site Name |Active Status |Mode        |Status      |Status Details |Fully Synced |
|-------- |----------- |----- |------------ |--------- |------- |--------- |--------- |--------- |--------- |----------- |------------- |----------- |----------- |-------------- |------------ |
|SYSTEMDB |example-vm1 |30001 |nameserver   |        1 |      1 |example-vm1 |example-vm2 |    30001 |        2 |example-vm2 |YES           |SYNCMEM     |ACTIVE      |               |        True |
|ABC      |example-vm1 |30007 |xsengine     |        2 |      1 |example-vm1 |example-vm2 |    30007 |        2 |example-vm2 |YES           |SYNCMEM     |ACTIVE      |               |        True |
|ABC      |example-vm1 |30003 |indexserver  |        3 |      1 |example-vm1 |example-vm2 |    30003 |        2 |example-vm2 |YES           |SYNCMEM     |ACTIVE      |               |        True |
status system replication site "2": ACTIVE
overall system replication status: ACTIVE
Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mode: PRIMARY
site id: 1
site name: example-vm1

  3. Deregistrieren Sie die sekundäre Instanz Ihrer SAP HANA-Datenbank:

    hdbnsutil -sr_unregister

    Die Ausgabe zeigt, dass die sekundäre Instanz der Datenbank erfolgreich abgemeldet wurde:

    abcadm@example-vm2:/usr/sap/ABC/HDB00> hdbnsutil -sr_unregister
unregistering site ...
done.
Performing Final Memory Release with 10 threads.
Finished Final Memory Release successfully.

  4. Löschen Sie in der sekundären Instanz Ihres SAP HANA-Systems alle Mandantendatenbanken und fordern Sie die Protokolle zurück:

    1. So beenden Sie eine Mandantendatenbank:

      hdbsql -n localhost:3INSTANCE_NUMBER13 -u SYSTEM -p "SYSTEM_DB_PASSWORD" -j "ALTER SYSTEM STOP DATABASE TENANT_DB_SID"

      Ersetzen Sie Folgendes:

      • INSTANCE_NUMBER: die Instanznummer der Mandantendatenbank
      • SYSTEM_DB_PASSWORD: das Passwort für die Systemdatenbank
      • TENANT_DB_SID: die SID der Mandantendatenbank, wobei die Buchstaben in Großbuchstaben geschrieben sind

    2. Löschen Sie die angehaltene Mandantendatenbank:

      hdbsql -n localhost:3INSTANCE_NUMBER13 -u SYSTEM -p "SYSTEM_DB_PASSWORD" -j "DROP DATABASE TENANT_DB_SID"

    3. Protokolle wiederherstellen:

      hdbsql -n localhost:3INSTANCE_NUMBER13 -u SYSTEM -p "SYSTEM_DB_PASSWORD" -j "ALTER SYSTEM RECLAIM LOG"

    4. Wiederholen Sie die vorherigen Schritte für alle Mandantendatenbanken in der sekundären Instanz Ihres SAP HANA-Systems.

    Das folgende Beispiel zeigt eine erfolgreiche Antwort:

    0 rows affected (overall time 9032.460 msec; server time 9032.273 msec)

  5. Beenden Sie die sekundäre Instanz Ihres SAP HANA-Systems:

    sapcontrol -nr INSTANCE_NUMBER -function Stop

Sekundäre Instanz migrieren

  1. Erstellen Sie ein Laufwerk für jedes SAP HANA-Dateisystem. Erstellen Sie für das in diesem Verfahren angenommene Beispielsystem vier Laufwerke, jeweils eines für /hana/data, /hana/log, /hana/shared und /usr/sap.

    Um die Laufwerkgröße für jedes Dateisystem festzulegen, können Sie die Informationen zur Größe verwenden, die in der Ausgabe des Befehls lsblk für Ihr System angezeigt werden.

    Informationen zur empfohlenen Mindestlaufwerksgröße, den IOPS und dem Durchsatz, die zur Erfüllung der SAP HANA-Leistungsanforderungen beitragen, finden Sie unter Mindestgrößen für SSD-basierte Persistent Disk- und Hyperdisk-Volumes.

    gcloud compute disks create USR_SAP_DISK_NAME \
    --project=PROJECT_ID \
    --type=USR_SAP_DISK_TYPE \
    --size=USR_SAP_DISK_SIZE \
    --zone=ZONE \
    --provisioned-iops=USR_SAP_DISK_IOPS
gcloud compute disks create SHARED_DISK_NAME \
    --project=PROJECT_ID \
    --type=SHARED_DISK_TYPE \
    --size=SHARED_DISK_SIZE \
    --zone=ZONE \
    --provisioned-iops=SHARED_DISK_IOPS
gcloud compute disks create DATA_DISK_NAME \
    --project=PROJECT_ID \
    --type=DATA_DISK_TYPE \
    --size=DATA_DISK_SIZE \
    --zone=ZONE \
    --provisioned-iops=DATA_DISK_IOPS
gcloud compute disks create LOG_DISK_NAME \
    --project=PROJECT_ID \
    --type=LOG_DISK_TYPE \
    --size=LOG_DISK_SIZE \
    --zone=ZONE \
    --provisioned-iops=LOG_DISK_IOPS

    Ersetzen Sie Folgendes:

    • USR_SAP_DISK_NAME: der Name, den Sie für das Laufwerk festlegen möchten, auf dem das Volume /usr/sap gehostet wird
    • PROJECT_ID: Projekt-ID Ihres Google Cloud Projekts

    • USR_SAP_DISK_TYPE: die Art des Hyperlaufwerks, das Sie zum Hosten des /usr/sap-Volumes bereitstellen möchten, z. B. hyperdisk-extreme.

    • USR_SAP_DISK_SIZE: die Größe, die Sie für das Laufwerk festlegen möchten, auf dem das Volume /usr/sap gehostet wird

    • ZONE: die Compute Engine-Zone, in der Sie die neuen Laufwerke bereitstellen möchten

    • USR_SAP_DISK_IOPS: die IOPS, die Sie für den erstellten Hyperdisk festlegen möchten, um /hana/data zu hosten. Sie legen die IOPS gemäß Ihren Leistungsanforderungen fest.

    • SHARED_DISK_NAME: der Name, den Sie für das Laufwerk festlegen möchten, auf dem das Volume /hana/shared gehostet wird

    • SHARED_DISK_TYPE: die Art des Hyperlaufwerks, das Sie zum Hosten des /hana/shared-Volumes bereitstellen möchten, z. B. hyperdisk-extreme.

    • SHARED_DISK_SIZE: die Größe, die Sie für das Laufwerk festlegen möchten, auf dem das Volume /hana/shared gehostet wird

    • SHARED_DISK_IOPS: die IOPS, die Sie für das Laufwerk festlegen möchten, auf dem das Volume /hana/shared gehostet wird

    • DATA_DISK_NAME: der Name, den Sie für das Laufwerk festlegen möchten, auf dem das Volume /hana/data gehostet wird

    • DATA_DISK_TYPE: die Art des Hyperdisks, das Sie zum Hosten des /hana/data-Volumes bereitstellen möchten, z. B. hyperdisk-extreme

    • DATA_DISK_SIZE: die Größe, die Sie für das Laufwerk festlegen möchten, auf dem das Volume /hana/data gehostet wird

    • DATA_DISK_IOPS: die IOPS, die Sie für das Laufwerk festlegen möchten, auf dem das Volume /hana/data gehostet wird

    • LOG_DISK_NAME: der Name, den Sie für das Laufwerk festlegen möchten, auf dem das Volume /hana/log gehostet wird

    • LOG_DISK_TYPE: die Art des Hyperdisks, das Sie zum Hosten des /hana/log-Volumes bereitstellen möchten, z. B. hyperdisk-extreme

    • LOG_DISK_SIZE: die Größe, die Sie für das Laufwerk festlegen möchten, auf dem das Volume /hana/log gehostet wird

    • LOG_DISK_IOPS: die IOPS, die Sie für das Laufwerk festlegen möchten, auf dem das Volume /hana/log gehostet wird

  2. Hängen Sie die von Ihnen erstellten Laufwerke an die Compute Engine-Instanz an, auf der die sekundäre Instanz Ihrer SAP HANA-Datenbank gehostet wird:

    gcloud compute instances attach-disk SECONDARY_INSTANCE_NAME \
    --disk=USR_SAP_DISK_NAME \
    --zone=ZONE
gcloud compute instances attach-disk SECONDARY_INSTANCE_NAME \
    --disk=SHARED_DISK_NAME \
    --zone=ZONE
gcloud compute instances attach-disk SECONDARY_INSTANCE_NAME \
    --disk=DATA_DISK_NAME \
    --zone=ZONE
gcloud compute instances attach-disk SECONDARY_INSTANCE_NAME \
    --disk=LOG_DISK_NAME \
    --zone=ZONE

    Ersetzen Sie SECONDARY_INSTANCE_NAME durch den Namen der Compute Engine, auf der die sekundäre Instanz Ihrer SAP HANA-Datenbank gehostet wird.

  3. So verwenden Sie die logische Volumeverwaltung (Logical Volume Management, LVM):

    1. Erstellen Sie physische Volumes für die neuen Laufwerke, die Sie erstellt und angeschlossen haben:

      pvcreate USR_SAP_PV_NAME
pvcreate SHARED_PV_NAME
pvcreate DATA_PV_NAME
pvcreate LOG_PV_NAME

      Ersetzen Sie Folgendes:

      • USR_SAP_PV_NAME: der tatsächliche Gerätepfad des Laufwerks, das Sie zum Hosten des Volumes /usr/sap erstellt haben
      • SHARED_PV_NAME: der tatsächliche Gerätepfad des Laufwerks, das Sie zum Hosten des Volumes /hana/shared erstellt haben
      • DATA_PV_NAME: der tatsächliche Gerätepfad des Laufwerks, das Sie zum Hosten des Volumes /hana/data erstellt haben
      • LOG_PV_NAME: der tatsächliche Gerätepfad des Laufwerks, das Sie zum Hosten des Volumes /hana/log erstellt haben

    2. Erstellen Sie Volume-Gruppen:

      vgcreate vg_hana_usrsap USR_SAP_PV_NAME
vgcreate vg_hana_shared SHARED_PV_NAME
vgcreate vg_hana_data DATA_PV_NAME
vgcreate vg_hana_log LOG_PV_NAME

    3. Erstellen Sie logische Volumes:

      lvcreate -l 100%FREE -n usrsap vg_hana_usrsap
lvcreate -l 100%FREE -n shared vg_hana_shared
lvcreate -l 100%FREE -n data vg_hana_data
lvcreate -l 100%FREE -n log vg_hana_log

  4. Erstellen Sie das Dateisystem:

    mkfs -t xfs /dev/vg_hana_usrsap/usrsap
mkfs -t xfs /dev/vg_hana_shared/shared
mkfs -t xfs /dev/vg_hana_data/data
mkfs -t xfs /dev/vg_hana_log/log

  5. Erstellen Sie temporäre Verzeichnisse für die SAP HANA-Dateisysteme:

    mkdir -p /tmp/usr/sap
mkdir -p /tmp/hana/shared
mkdir -p /tmp/hana/data
mkdir -p /tmp/hana/log

  6. Verwenden Sie die temporären Verzeichnisse, um die neu erstellten Volumes bereitzustellen:

    mount -o logbsize=256k /dev/vg_hana_usrsap/usrsap /tmp/usr/sap
mount -o logbsize=256k /dev/vg_hana_shared/shared /tmp/hana/shared
mount -o logbsize=256k /dev/vg_hana_data/data /tmp/hana/data
mount -o logbsize=256k /dev/vg_hana_log/log /tmp/hana/log

  7. Übertragen Sie die Daten aus dem Quell-Persistent Disk-Volume auf die von Ihnen erstellten Laufwerke. Sie können dazu rsync, LVM-Snapshots oder eine andere Methode verwenden. Im folgenden Beispiel wird das Dienstprogramm rsync für die Datenübertragung verwendet:

    rsync -avz --progress /usr/sap/ /tmp/usr/sap/
rsync -avz --progress /hana/shared/ /tmp/hana/shared/
rsync -avz --progress /hana/data/ /tmp/hana/data/
rsync -avz --progress /hana/log/ /tmp/hana/log/

  8. Trennen Sie die älteren logischen Volumes für die SAP HANA-Dateisysteme:

    umount /usr/sap
umount /hana/shared
umount /hana/data
umount /hana/log

  9. Trennen Sie die temporären Volumes, die Sie für die SAP HANA-Dateisysteme erstellt haben:

    umount /tmp/usr/sap
umount /tmp/hana/shared
umount /tmp/hana/data
umount /tmp/hana/log

  10. Trennen Sie von der Compute Engine-Instanz, auf der die sekundäre Instanz Ihrer SAP HANA-Datenbank gehostet wird, das Volume des nichtflüchtigen Speichers, auf dem Ihre SAP HANA-Dateisysteme gehostet wurden:

    gcloud compute instances detach-disk SECONDARY_INSTANCE_NAME
    --disk=SOURCE_DISK_NAME \
    --zone=ZONE

    Ersetzen Sie SOURCE_DISK_NAME durch den Namen des nichtflüchtigen Speichervolumes, auf dem Ihre SAP HANA-Dateisysteme gehostet wurden und das Sie von der Compute-Instanz trennen möchten.

  11. Aktualisieren Sie als Root-Nutzer oder Nutzer mit sudo-Zugriff die /etc/fstab-Einträge. Im folgenden Beispiel wird gezeigt, wie die Einträge aktualisiert werden müssen:

    /dev/vg_hana_shared/shared /hana/shared xfs defaults,nofail,logbsize=256k 0 2
/dev/vg_hana_usrsap/sap /usr/sap xfs defaults,nofail,logbsize=256k 0 2
/dev/vg_hana_data/data /hana/data xfs defaults,nofail,logbsize=256k 0 2
/dev/vg_hana_log/log /hana/log xfs defaults,nofail,logbsize=256k 0 2

  12. Hängen Sie die neu erstellten logischen Volumes an:

    mount -a

  13. Prüfen Sie die Informationen zum belegten Speicherplatz der Dateisysteme:

    df -h

    Die Ausgabe sieht etwa so aus:

    # df -h
Filesystem                         Size  Used Avail Use% Mounted on
devtmpfs                           4.0M  8.0K  4.0M   1% /dev
tmpfs                              638G   35M  638G   1% /dev/shm
tmpfs                              171G  458M  170G   1% /run
tmpfs                              4.0M     0  4.0M   0% /sys/fs/cgroup
/dev/sdb3                           30G  6.4G   24G  22% /
/dev/sdb2                           20M  3.0M   17M  15% /boot/efi
/dev/mapper/vg_hanabackup-backup   1.7T   13G  1.7T   1% /hanabackup
tmpfs                               86G     0   86G   0% /run/user/0
/dev/mapper/vg_hana_usrsap-usrsap   32G  277M   32G   1% /usr/sap
/dev/mapper/vg_hana_shared-shared  850G   54G  797G   7% /hana/shared
/dev/mapper/vg_hana_data-data      1.1T  5.4G  1.1T   1% /hana/data
/dev/mapper/vg_hana_log-log        475G  710M  475G   1% /hana/log

Sekundäre Instanz befördern

  1. Registrieren Sie als Nutzer SID_LCadm die sekundäre Instanz Ihrer SAP HANA-Datenbank bei der SAP HANA-Systemreplikation:

    hdbnsutil -sr_register --remoteHost=PRIMARY_INSTANCE_NAME \
    --remoteInstance=PRIMARY_INSTANCE_NUMBER \
    --replicationMode=syncmem --operationMode=logreplay \
    --name=SECONDARY_INSTANCE_NAME

    Ersetzen Sie Folgendes:

    • PRIMARY_INSTANCE_NAME: Name der Compute Engine-Instanz, auf der die primäre Instanz Ihres SAP HANA-Systems gehostet wird
    • PRIMARY_INSTANCE_NUMBER: die Instanznummer der primären Instanz Ihres SAP HANA-Systems
    • SECONDARY_INSTANCE_NAME: Name der Compute Engine-Instanz, auf der die sekundäre Instanz Ihres SAP HANA-Systems gehostet wird

  2. Starten Sie die sekundäre Instanz Ihrer SAP HANA-Datenbank:

    HDB start

    Alternativ können Sie die sekundäre Instanz mit dem Befehl sapcontrol starten:

    sapcontrol -nr INSTANCE_NUMBER -function StartSystem

  3. Prüfen Sie in der primären Instanz Ihrer SAP HANA-Datenbank als Nutzer SID_LCadm, ob die SAP HANA-Systemreplikation aktiv ist:

    python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py

  4. Nachdem Sie bestätigt haben, dass die Systemreplikation aktiv ist, machen Sie die sekundäre Instanz Ihrer SAP HANA-Datenbank zur neuen primären Instanz:

    crm resource move msl_SAPHana_SID_HDBINSTANCE_NUMBER SECONDARY_INSTANCE_NAME

    Die Ausgabe sieht etwa so aus wie im folgenden Beispiel.

    INFO: Move constraint created for msl_SAPHana_ABC_HDB00 to example-vm2
INFO: Use `crm resource clear msl_SAPHana_ABC_HDB00` to remove this constraint

  5. Prüfen Sie den Status Ihres HA-Clusters:

    crm status

    Die Ausgabe sieht etwa so aus wie im folgenden Beispiel.

    example-vm1:~ # crm status
Status of pacemakerd: 'Pacemaker is running' (last updated 2025-02-04 10:08:16Z)
Cluster Summary:
  * Stack: corosync
  * Current DC: example-vm1 (version 2.1.5+20221208.a3f44794f-150500.6.20.1-2.1.5+20221208.a3f44794f) - partition with quorum
  * Last updated: Tue Feb  4 10:08:16 2025
  * Last change:  Tue Feb  4 10:07:47 2025 by root via crm_attribute on example-vm2
  * 2 nodes configured
  * 8 resource instances configured
Node List:
  * Online: [ example-vm1 example-vm2 ]
Full List of Resources:
  * STONITH-example-vm1  (stonith:fence_gce):     Started example-vm2
  * STONITH-example-vm2  (stonith:fence_gce):     Started example-vm1
  * Resource Group: g-primary:
    * rsc_vip_int-primary    (ocf::heartbeat:IPaddr2):    Started example-vm2
    * rsc_vip_hc-primary (ocf::heartbeat:anything):   Started example-vm2
  * Clone Set: cln_SAPHanaTopology_ABC_HDB00 [rsc_SAPHanaTopology_ABC_HDB00]:
    * Started: [ example-vm1 example-vm2 ]
  * Clone Set: msl_SAPHana_ABC_HDB00 [rsc_SAPHana_ABC_HDB00] (promotable):
    * Masters: [ example-vm2 ]
    * Slaves: [ example-vm1 ]

  6. Entfernen Sie als Root-Nutzer oder Nutzer mit sudo-Zugriff die Einschränkung, die dafür sorgt, dass für Ihre Ressource keine bestimmte Compute Engine-Instanz bevorzugt wird:

    crm resource clear msl_SAPHana_SID_HDBINSTANCE_NUMBER

    Die Ausgabe sieht etwa so aus:

    INFO: Removed migration constraints for msl_SAPHana_ABC_HDB00

Vorherige primäre Instanz migrieren

  1. Wiederholen Sie die Schritte in den vorherigen Abschnitten, um die ehemalige primäre Instanz Ihres SAP HANA-Systems zu migrieren.

  2. Entfernen Sie den HA-Cluster aus dem Wartungsmodus:

    crm maintenance off

Auf vorhandene Laufwerke zurückgreifen

Wenn die Laufwerksmigration fehlschlägt, können Sie die vorhandenen Volumes des persistenten Laufwerks verwenden, da sie die Daten enthalten, die vor dem Start der Migration vorhanden waren.

So stellen Sie Ihre SAP HANA-Datenbank in den ursprünglichen Zustand wieder her:

  1. Beenden Sie die Compute Engine-Instanz, auf der Ihre SAP HANA-Datenbank gehostet wird.
  2. Trennen Sie die von Ihnen erstellten Hyperdisk-Volumes.
  3. Hängen Sie das vorhandene Persistent Disk-Volume wieder an die Compute-Instanz an.
  4. Starten Sie die Compute-Instanz.

Bereinigen

Nachdem Sie Ihre SAP HANA-Dateisysteme erfolgreich auf einzelne Laufwerke migriert haben, bereinigen Sie die Ressourcen im Zusammenhang mit dem verwendeten Persistent Disk-Volume. Dazu gehören die Laufwerk-Snapshots und das Laufwerk selbst.

  • Informationen zum Löschen von Laufwerk-Snapshots finden Sie unter Laufwerk-Snapshots verwalten.

  • Wenn Sie das Persistent Disk-Volume löschen möchten, das von Ihrem SAP HANA-System verwendet wurde, können Sie den Befehl gcloud compute disks delete ausführen:

    gcloud compute disks delete SOURCE_DISK_NAME
    --ZONE=ZONE