Migrer des systèmes de fichiers SAP HANA vers des disques individuels

Ce document explique comment migrer les systèmes de fichiers de votre déploiement SAP HANA sur Google Cloud vers des volumes de disques persistants ou Hyperdisk Google Cloud basés sur SSD individuels.

Les déploiements SAP HANA sur Google Cloud utilisent la mise en page de disque unifiée ou la mise en page de disque fractionnée. Dans la mise en page de disque unifiée, un seul disque est utilisé pour héberger tous les systèmes de fichiers SAP HANA. Dans la mise en page de disque fractionné, chaque système de fichiers SAP HANA est hébergé sur un disque distinct. Pour en savoir plus sur ces mises en page de disque, consultez la section Mises en page de disque compatibles.

Google Cloud vous recommande d'utiliser la mise en page de disque fractionné pour les raisons suivantes:

  • Il permet d'ajuster indépendamment les performances des disques pour les systèmes de fichiers, en particulier pour /hana/data et /hana/log, et en particulier lorsque vous utilisez Hyperdisk.
  • Il simplifie la maintenance.

Pour illustrer la procédure de migration, ce guide suppose un exemple de système et migre les systèmes de fichiers SAP HANA d'un seul volume de disque persistant vers un volume Hyperdisk pour chaque système de fichiers. Vous pouvez également utiliser cette procédure pour migrer les systèmes de fichiers SAP HANA vers des volumes de disques persistants individuels.

Examiner les considérations sur la migration

  • Durée de la migration des données: pour un système SAP HANA à haute disponibilité, vous pouvez réduire la durée de la migration des données en désinscrivant le nœud secondaire, en supprimant ses bases de données de locataires, puis en récupérant les journaux. La procédure décrite dans ce guide utilise cette approche.
  • Temps d'arrêt: pour un système SAP HANA à haute disponibilité, vous devez d'abord migrer la base de données secondaire, en faire la nouvelle base de données principale, puis migrer l'ancienne base de données principale. Cela permet de réduire au maximum le temps d'arrêt.
  • Revenir aux disques existants: en cas de problème pendant la migration, vous pouvez revenir aux disques existants, car ils ne sont pas affectés par cette procédure et sont disponibles jusqu'à ce que vous les supprimiez vous-même. Pour en savoir plus, consultez la section Recourir aux disques existants.

Avant de commencer

Avant de migrer les systèmes de fichiers SAP HANA hébergés sur un seul disque vers un disque pour chaque système de fichiers, assurez-vous que les conditions suivantes sont remplies:

  • SAP HANA s'exécute sur des instances Compute Engine certifiées par SAP compatibles avec l'hyperdisque.
  • Une sauvegarde valide de la base de données SAP HANA est disponible. Cette sauvegarde peut être utilisée pour restaurer la base de données, si nécessaire.
  • Si l'instance Compute Engine cible fait partie d'un cluster à haute disponibilité (HA), assurez-vous que le cluster est en mode de maintenance.
  • Si votre base de données SAP HANA utilise un déploiement à scaling horizontal, répétez la procédure décrite dans ce guide pour chaque instance SAP HANA.
  • La base de données SAP HANA est opérationnelle. Pour les systèmes haute disponibilité, assurez-vous que la réplication est active entre les instances principale et secondaire de votre base de données.
  • Pour réduire le temps de copie des données, supprimez les sauvegardes ou supports inutiles des volumes SAP HANA que vous migrez.
  • Vérifiez que les systèmes de fichiers SAP HANA que vous migrez sont hébergés sur un seul disque en exécutant la commande suivante:

    lsblk
    

    Le résultat ressemble à celui de l'exemple ci-dessous. Votre sortie peut différer de cet exemple en fonction de votre convention de dénomination pour les systèmes de fichiers SAP HANA ou si votre instance de calcul est compatible avec l'interface de disque NVMe (non-volatile memory express).

    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
    

Exemple de système SAP

Pour illustrer la procédure de migration, ce guide:

Le schéma suivant illustre l'architecture de l'exemple de système avant et après la migration de ses systèmes de fichiers:

Schéma d'architecture illustrant la migration des systèmes de fichiers SAP HANA vers des disques individuels sur Google Cloud

Les détails de configuration de l'exemple de système SAP sont les suivants:

  • Type de machine : n2-highmem-128
  • OS: SLES pour SAP 15 SP5
  • SAP HANA: HANA 2 SPS07, version 78
  • Type de disque utilisé par le système: disque persistant SSD (pd-ssd)
  • Les volumes /hana/data, /hana/log, /hana/shared et /usr/sap sont installés sur le même disque et sont configurés dans les paramètres de persistance pour SAP HANA. Voici un exemple de paramètres de persistance pour les volumes /hana/data et /hana/log d'un système SAP HANA avec SID ABC:

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

Migrer des systèmes de fichiers vers des volumes Hyperdisk individuels

Pour migrer les systèmes de fichiers d'un déploiement HA à scaling vertical SAP HANA d'un seul volume de disque persistant vers un volume Hyperdisk pour chaque système de fichiers, procédez comme suit:

  1. Préparez l'instance secondaire à la migration.
  2. Migrer l'instance secondaire
  3. Promouvoir l'instance secondaire
  4. Migrer l'ancienne instance principale

Préparer l'instance secondaire pour la migration

  1. Mettez le cluster à haute disponibilité en mode de maintenance:

    crm maintenance on
    
  2. Vérifiez si la réplication du système HANA (HSR) est active:

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

    Le résultat ressemble à celui de l'exemple ci-dessous.

    /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. Annulez l'enregistrement de l'instance secondaire de votre base de données SAP HANA:

    hdbnsutil -sr_unregister
    

    La sortie indique que l'instance secondaire de la base de données a bien été désinscrite:

    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. Dans l'instance secondaire de votre système SAP HANA, supprimez toutes les bases de données de locataire et récupérez les journaux:

    1. Arrêter une base de données locataire:

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

      Remplacez les éléments suivants :

      • INSTANCE_NUMBER: numéro d'instance de la base de données du locataire
      • SYSTEM_DB_PASSWORD: mot de passe de la base de données système
      • TENANT_DB_SID: SID de la base de données locataire, où les lettres sont en majuscules
    2. Supprimez la base de données locataire que vous avez arrêtée:

      hdbsql -n localhost:3INSTANCE_NUMBER13 -u SYSTEM -p "SYSTEM_DB_PASSWORD" -j "DROP DATABASE TENANT_DB_SID"
      
    3. Récupérez les journaux:

      hdbsql -n localhost:3INSTANCE_NUMBER13 -u SYSTEM -p "SYSTEM_DB_PASSWORD" -j "ALTER SYSTEM RECLAIM LOG"
      
    4. Répétez les étapes précédentes pour toutes les bases de données locataires de l'instance secondaire de votre système SAP HANA.

    L'exemple suivant montre une réponse réussie:

    0 rows affected (overall time 9032.460 msec; server time 9032.273 msec)
    
  5. Arrêtez l'instance secondaire de votre système SAP HANA:

    sapcontrol -nr INSTANCE_NUMBER -function Stop
    

Migrer l'instance secondaire

  1. Créez un disque pour chaque système de fichiers SAP HANA. Pour l'exemple de système supposé par cette procédure, créez quatre disques, un pour /hana/data, /hana/log, /hana/shared et /usr/sap.

    Pour définir la taille de disque de chaque système de fichiers, vous pouvez utiliser les informations de dimensionnement affichées dans la sortie de la commande lsblk pour votre système.

    Pour en savoir plus sur la taille de disque, les IOPS et le débit recommandés pour répondre aux exigences de performances de SAP HANA, consultez la section Tailles minimales pour les volumes Persistent Disk et Hyperdisk basés sur SSD.

    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
    

    Remplacez les éléments suivants :

    • USR_SAP_DISK_NAME: nom que vous souhaitez définir pour le disque qui héberge le volume /usr/sap.
    • PROJECT_ID: ID de votre Google Cloud projet
    • USR_SAP_DISK_TYPE: type d'hyperdisque que vous souhaitez déployer pour héberger le volume /usr/sap, par exemple hyperdisk-extreme.

    • USR_SAP_DISK_SIZE: taille que vous souhaitez définir pour le disque qui héberge le volume /usr/sap.

    • ZONE: zone Compute Engine dans laquelle vous souhaitez déployer les nouveaux disques

    • USR_SAP_DISK_IOPS: IOPS que vous souhaitez définir pour l'hyperdisque que vous créez pour héberger /hana/data. Vous définissez les IOPS en fonction de vos exigences de performances.

    • SHARED_DISK_NAME: nom que vous souhaitez définir pour le disque qui héberge le volume /hana/shared.

    • SHARED_DISK_TYPE: type d'hyperdisque que vous souhaitez déployer pour héberger le volume /hana/shared, par exemple hyperdisk-extreme.

    • SHARED_DISK_SIZE: taille que vous souhaitez définir pour le disque qui héberge le volume /hana/shared.

    • SHARED_DISK_IOPS: IOPS que vous souhaitez définir pour le disque qui héberge le volume /hana/shared.

    • DATA_DISK_NAME: nom que vous souhaitez définir pour le disque qui héberge le volume /hana/data.

    • DATA_DISK_TYPE: type d'hyperdisque que vous souhaitez déployer pour héberger le volume /hana/data, par exemple hyperdisk-extreme

    • DATA_DISK_SIZE: taille que vous souhaitez définir pour le disque qui héberge le volume /hana/data.

    • DATA_DISK_IOPS: IOPS que vous souhaitez définir pour le disque qui héberge le volume /hana/data.

    • LOG_DISK_NAME: nom que vous souhaitez définir pour le disque qui héberge le volume /hana/log.

    • LOG_DISK_TYPE: type d'hyperdisque que vous souhaitez déployer pour héberger le volume /hana/log, par exemple hyperdisk-extreme

    • LOG_DISK_SIZE: taille que vous souhaitez définir pour le disque qui héberge le volume /hana/log.

    • LOG_DISK_IOPS: IOPS que vous souhaitez définir pour le disque qui héberge le volume /hana/log.

  2. Associez les disques que vous avez créés à l'instance Compute Engine qui héberge l'instance secondaire de votre base de données SAP HANA:

    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
    

    Remplacez SECONDARY_INSTANCE_NAME par le nom de Compute Engine qui héberge l'instance secondaire de votre base de données SAP HANA.

  3. Pour utiliser la gestion des volumes logiques (LVM), procédez comme suit:

    1. Créez des volumes physiques pour les nouveaux disques que vous avez créés et associés:

      pvcreate USR_SAP_PV_NAME
      pvcreate SHARED_PV_NAME
      pvcreate DATA_PV_NAME
      pvcreate LOG_PV_NAME
      

      Remplacez les éléments suivants :

      • USR_SAP_PV_NAME: chemin d'accès réel de l'appareil du disque que vous avez créé pour héberger le volume /usr/sap.
      • SHARED_PV_NAME: chemin d'accès réel de l'appareil du disque que vous avez créé pour héberger le volume /hana/shared.
      • DATA_PV_NAME: chemin d'accès réel de l'appareil du disque que vous avez créé pour héberger le volume /hana/data.
      • LOG_PV_NAME: chemin d'accès réel de l'appareil du disque que vous avez créé pour héberger le volume /hana/log.
    2. Créez des groupes de volumes:

      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. Créez des volumes logiques:

      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. Créez le système de fichiers:

    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. Créez des répertoires temporaires pour les systèmes de fichiers SAP HANA:

    mkdir -p /tmp/usr/sap
    mkdir -p /tmp/hana/shared
    mkdir -p /tmp/hana/data
    mkdir -p /tmp/hana/log
    
  6. Montez les volumes nouvellement créés à l'aide des répertoires temporaires:

    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. Transférez les données du volume de disque persistant source vers les disques que vous avez créés. Pour ce faire, vous pouvez utiliser rsync, des instantanés LVM ou toute autre méthode. L'exemple suivant utilise l'utilitaire rsync pour le transfert de données:

    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. Démontez les anciens volumes logiques pour les systèmes de fichiers SAP HANA:

    umount /usr/sap
    umount /hana/shared
    umount /hana/data
    umount /hana/log
    
  9. Démontez les volumes temporaires que vous avez créés pour les systèmes de fichiers SAP HANA:

    umount /tmp/usr/sap
    umount /tmp/hana/shared
    umount /tmp/hana/data
    umount /tmp/hana/log
    
  10. Depuis l'instance Compute Engine qui héberge l'instance secondaire de votre base de données SAP HANA, dissociez le volume de disque persistant qui héberge vos systèmes de fichiers SAP HANA:

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

    Remplacez SOURCE_DISK_NAME par le nom du volume de disque persistant qui hébergeait vos systèmes de fichiers SAP HANA, que vous souhaitez dissocier de l'instance de calcul.

  11. En tant qu'utilisateur racine ou utilisateur disposant d'un accès sudo, mettez à jour les entrées /etc/fstab. Voici un exemple de mise à jour des entrées:

    /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. Installez les volumes logiques nouvellement créés:

    mount -a
    
  13. Vérifiez les informations sur l'espace utilisé par les systèmes de fichiers:

    df -h
    

    Le résultat ressemble à ce qui suit :

    # 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
    

Promouvoir l'instance secondaire

  1. En tant qu'utilisateur SID_LCadm, enregistrez l'instance secondaire de votre base de données SAP HANA avec la réplication du système SAP HANA:

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

    Remplacez les éléments suivants :

    • PRIMARY_INSTANCE_NAME: nom de l'instance Compute Engine qui héberge l'instance principale de votre système SAP HANA
    • PRIMARY_INSTANCE_NUMBER: numéro d'instance de l'instance principale de votre système SAP HANA
    • SECONDARY_INSTANCE_NAME: nom de l'instance Compute Engine qui héberge l'instance secondaire de votre système SAP HANA
  2. Démarrez l'instance secondaire de votre base de données SAP HANA:

    HDB start
    

    Vous pouvez également utiliser la commande sapcontrol pour démarrer l'instance secondaire:

    sapcontrol -nr INSTANCE_NUMBER -function StartSystem
    
  3. Sur l'instance principale de votre base de données SAP HANA, en tant qu'utilisateur SID_LCadm, vérifiez que la réplication du système SAP HANA est active:

    python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py
    
  4. Après avoir vérifié que la réplication du système est active, définissez l'instance secondaire de votre base de données SAP HANA comme nouvelle instance principale:

    crm resource move msl_SAPHana_SID_HDBINSTANCE_NUMBER SECONDARY_INSTANCE_NAME
    

    Le résultat ressemble à celui de l'exemple ci-dessous.

    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. Vérifiez l'état de votre cluster à haute disponibilité:

    crm status
    

    Le résultat ressemble à celui de l'exemple ci-dessous.

    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. En tant qu'utilisateur racine ou utilisateur disposant d'un accès sudo, supprimez la contrainte qui garantit que votre ressource n'est pas définie pour préférer une instance Compute Engine spécifique:

    crm resource clear msl_SAPHana_SID_HDBINSTANCE_NUMBER
    

    Le résultat ressemble à ce qui suit :

    INFO: Removed migration constraints for msl_SAPHana_ABC_HDB00
    

Migrer l'ancienne instance principale

  1. Pour migrer l'ancienne instance principale de votre système SAP HANA, répétez les procédures fournies dans les sections précédentes.

  2. Désactivez le mode de maintenance pour le cluster à haute disponibilité:

    crm maintenance off
    

Recourir aux disques existants

Si la migration du disque échoue, vous pouvez utiliser les volumes de disque persistant existants, car ils contiennent les données telles qu'elles existaient avant le début de la procédure de migration.

Pour restaurer votre base de données SAP HANA à son état d'origine, procédez comme suit:

  1. Arrêtez l'instance Compute Engine qui héberge votre base de données SAP HANA.
  2. Dissociez les volumes Hyperdisk que vous avez créés.
  3. Réassociez le volume de disque persistant existant à l'instance de calcul.
  4. Démarrez l'instance de calcul.

Effectuer un nettoyage

Une fois que vous avez correctement migré vos systèmes de fichiers SAP HANA vers des disques individuels, nettoyez les ressources associées au volume de disques persistants que vous utilisiez. Cela inclut les instantanés de disque et le disque lui-même.