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:
- Partant d'un exemple de déploiement à haute disponibilité (HA) de SAP HANA à scaling vertical, où un seul volume de disque persistant héberge les systèmes de fichiers
/hana/data
,/hana/log
,/hana/shared
et/usr/sap
. - Migre les systèmes de fichiers vers des volumes Hyperdisk individuels, dont la configuration est semblable à celle du système HA à scaling à la hausse SAP HANA déployé par Terraform: Guide de configuration d'un cluster à haute disponibilité SAP HANA à scaling à la hausse.
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:
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 SIDABC
:[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:
- Préparez l'instance secondaire à la migration.
- Migrer l'instance secondaire
- Promouvoir l'instance secondaire
- Migrer l'ancienne instance principale
Préparer l'instance secondaire pour la migration
Mettez le cluster à haute disponibilité en mode de maintenance:
crm maintenance on
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
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.
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:
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 locataireSYSTEM_DB_PASSWORD
: mot de passe de la base de données systèmeTENANT_DB_SID
: SID de la base de données locataire, où les lettres sont en majuscules
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"
Récupérez les journaux:
hdbsql -n localhost:3INSTANCE_NUMBER13 -u SYSTEM -p "SYSTEM_DB_PASSWORD" -j "ALTER SYSTEM RECLAIM LOG"
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)
Arrêtez l'instance secondaire de votre système SAP HANA:
sapcontrol -nr INSTANCE_NUMBER -function Stop
Migrer l'instance secondaire
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 projetUSR_SAP_DISK_TYPE
: type d'hyperdisque que vous souhaitez déployer pour héberger le volume/usr/sap
, par exemplehyperdisk-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 disquesUSR_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 exemplehyperdisk-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 exemplehyperdisk-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 exemplehyperdisk-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
.
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.Pour utiliser la gestion des volumes logiques (LVM), procédez comme suit:
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
.
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
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
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
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
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
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'utilitairersync
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/
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
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
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.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
Installez les volumes logiques nouvellement créés:
mount -a
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
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 HANAPRIMARY_INSTANCE_NUMBER
: numéro d'instance de l'instance principale de votre système SAP HANASECONDARY_INSTANCE_NAME
: nom de l'instance Compute Engine qui héberge l'instance secondaire de votre système SAP HANA
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
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
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
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 ]
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
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.
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:
- Arrêtez l'instance Compute Engine qui héberge votre base de données SAP HANA.
- Dissociez les volumes Hyperdisk que vous avez créés.
- Réassociez le volume de disque persistant existant à l'instance de calcul.
- 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.
Pour savoir comment supprimer des instantanés de disque, consultez la section Gérer les instantanés de disque.
Pour supprimer le volume de disque persistant utilisé par votre système SAP HANA, vous pouvez exécuter la commande
gcloud compute disks delete
:gcloud compute disks delete SOURCE_DISK_NAME --ZONE=ZONE