Data Domain : guide de mise à niveau du système d’exploitation pour les systèmes haute disponibilité (HA)
Résumé: Aperçu du processus de mise à niveau de Data Domain Operating System (DDOS) sur les appliances Data Domain « Haute disponibilité » (DDHA).
Instructions
Maintenance planifiée du système HA
Afin de réduire le temps d’indisponibilité lors des opérations de maintenance planifiées, la mise à niveau consécutive du système est incluse dans l’architecture HA. Une mise à niveau consécutive peut d’abord mettre à niveau le nœud en veille, puis effectuer un basculement HA attendu pour transférer les services du nœud actif vers le nœud en veille. Enfin, les nœuds actifs précédents seront mis à niveau et rejoindront à nouveau le cluster HA en tant que nœud en veille. Tous les processus sont exécutés dans une seule commande.
Une autre méthode de mise à niveau manuelle est la « mise à niveau locale ». Elle consiste à mettre à niveau manuellement le nœud en veille en premier, puis le nœud actif. Enfin, le nœud en veille rejoindra à nouveau le cluster HA. Une mise à niveau locale peut être effectuée pour une mise à niveau régulière ou pour résoudre des problèmes.
Toutes les opérations de mise à niveau du système sur le nœud actif nécessitent la conversion des données peut ne pas démarrer tant que les deux systèmes ne sont pas mis à niveau vers le même niveau et que l’état HA n’est pas entièrement restauré.
Cet article de la base de connaissances doit être vérifié avant de poursuivre cette procédure :
PowerProtect Data Domain : Pré-vérification de la mise à niveau DDHA
À partir de DDOS 5.7, deux méthodes de mise à niveau des systèmes HA sont prises en charge :
-
Mise à niveau consécutive : mettez automatiquement à niveau les deux nœuds HA à l’aide d’une seule commande. Le service est déplacé vers l’autre nœud après la mise à niveau.
-
Mise à niveau locale : mettez à niveau manuellement les nœuds HA un par un. Le service est conservé dans le même nœud après la mise à niveau.
Préparation du système pour la mise à niveau :
-
Assurez-vous que l’état du système HA est « disponibilité élevée ».
Interface graphique de connexion -> Accueil -> Tableau de bord
- Le fichier RPM DDOS doit être placé sur le nœud actif et la mise à niveau doit commencer à partir de ce nœud.
Interface graphique de connexion -> Accueil -> Tableau de bord
- Téléchargez le fichier RPM sur le nœud actif
UPLOAD UPGRADE PACKAGE Aprèsle téléchargement, le fichier RPM est répertorié.
- Exécutez une vérification préalable sur le nœud actif. La mise à niveau doit être abandonnée en cas d’erreur.
Veuillez également arrêter le nettoyage des systèmes de fichiers, le déplacement des données et la réplication avant de lancer la mise à niveau (étape #6) afin que ces tâches n’entraînent pas un temps d’arrêt DDFS plus long pendant la mise à niveau. Un temps d’arrêt plus court de DDFS permet de réduire l’impact sur les clients. Ces charges applicatives n’affectent pas les opérations de sauvegarde/restauration des clients.
En fonction des besoins, ces services peuvent être repris une fois la mise à niveau terminée à l’aide des commandes d’activation correspondantes . Veuillez consulter le Guide d’administration pour plus de détails.
D’autres vérifications et commandes manuelles sont décrites dans le guide d’administration, mais elles ne sont pas strictement nécessaires pour un système HA. Un pré-redémarrage est actuellement recommandé comme test pour les systèmes à nœud unique. Il n’est pas nécessaire pour les systèmes HA, car l’étape 5 « ha failover » ci-dessous inclut déjà un redémarrage automatique pendant le processus de basculement.
- En option. Avant d’exécuter une mise à niveau consécutive, il est recommandé d’effectuer deux fois le basculement HA manuellement sur le nœud actif. L’objectif est de tester la fonctionnalité de basculement. L’opération redémarre le nœud actif. Veuillez en tenir compte.
Tout d’abord, préparez-vous au basculement en arrêtant le nettoyage, le déplacement des données et la réplication. Reportez-vous au guide d’administration pour savoir comment procéder via l’interface graphique. Ces services n’ont aucun impact sur les charges applicatives de sauvegarde/restauration des clients. Exécutez ensuite « ha failover ».
(lorsque l’état du système HA redevient « hautement disponible », exécutez le deuxième « basculement haute disponibilité » et attendez que les deux nœuds soient en ligne)
Après le basculement HA, les services arrêtés peuvent être repris à l’aide des commandes d’activation correspondantes. Veuillez consulter le Guide d’administration pour plus de détails.
Les tests de basculement décrits ci-dessus sont optionnels et n’ont pas besoin d’être effectués immédiatement avant la mise à niveau. Les tests de basculement peuvent être effectués avant la mise à niveau, par exemple deux semaines avant, afin de pouvoir utiliser une fenêtre de maintenance plus courte pour la mise à niveau ultérieure. L’interruption du service DDFS pour chaque basculement est d’environ 10 minutes (plus ou moins selon la version de DDOS et d’autres facteurs). Les versions DDOS 7.4 et ultérieures présentent un temps d’arrêt réduit à chaque nouvelle version grâce aux améliorations continues du logiciel DDOS.
- Si la vérification préalable s’est terminée sans aucun problème, procédez à la mise à niveau consécutive sur le nœud actif.
- Veuillez attendre la fin de la mise à niveau consécutive. Avant cela, ne déclenchez aucune opération de basculement HA.
Disponibilité de DDFS pendant la commande ci-dessus :
-
Le système met d’abord à niveau le nœud en veille et le redémarre avec la nouvelle version. En fonction de divers facteurs, il faut compter entre 20 et 30 minutes. Le service DDFS est opérationnel et fonctionne sur le nœud actif pendant cette période sans aucune dégradation des performances
-
Après l’application du nouveau DDOS, le système effectue un basculement du service DDFS vers le nœud en veille mis à niveau. Il faut compter environ 10 minutes (un peu plus ou moins en fonction de divers facteurs).
-
La mise à niveau du firmware du boîtier de disque (DAE) est un facteur important. Cela peut entraîner environ 20 minutes d’interruption de service supplémentaires en fonction du nombre de boîtiers DAE configurés. Veuillez consulter l’article de la base de connaissances « Data Domain : la mise à niveau consécutive HA peut échouer lorsque le firmware du boîtier externe a été mis à niveau », afin de déterminer si une mise à niveau du firmware du boîtier DAE est requise. Notez qu’à partir de DDOS 7.5, une amélioration permet la mise à niveau en ligne du firmware du boîtier DAE, ce qui élimine ce problème.
-
Le support Dell peut être contacté pour discuter des facteurs susceptibles d’affecter les délais de mise à niveau. Selon le système d’exploitation client, l’application et le protocole utilisé entre le client et le système HA, il peut parfois être nécessaire de relancer manuellement les charges applicatives du client juste après le basculement. Par exemple, avec des clients DDBoost, si le temps de basculement dépasse 10 minutes, le client peut expirer et l’utilisateur devra relancer manuellement les charges applicatives. Cependant, la plupart des clients disposent de paramètres configurables permettant de définir les valeurs de délai d’expiration et le nombre de tentatives de reprise.
-
Veuillez noter que le service DDFS est interrompu pendant la période de basculement. En surveillant la sortie de la commande « filesys status » sur le nœud mis à niveau, il est possible de savoir si le service DDFS a repris ou non. Les versions de DDOS 7.4 et ultérieures devraient présenter des temps d’arrêt de plus en plus courts grâce aux améliorations continues du code DDOS.
Après le basculement, le nœud actif précédent est mis à niveau. Après l’application de la mise à niveau, le système redémarre avec la nouvelle version, puis rejoint le cluster HA en tant que nœud en veille. Le service DDFS n’est pas affecté au cours de ce processus, car il a déjà été repris ci-dessus.
Vérification :
- Une fois la mise à niveau consécutive terminée, vous avez besoin de vous connecter à l’interface utilisateur via l’adresse IP du nœud en veille. Dans ce cas, il s’agit du nœud 1.
- Vérifiez s’il y a des alertes inattendues.
- À ce stade, la mise à niveau consécutive est terminée avec succès.
Mise à niveau consécutive via la CLI :
Préparation du système pour la mise à niveau :
- Assurez-vous que l’état du système HA est « disponibilité élevée ».
#ha status
HA System name: HA-system
HA System status: highly available <-
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node0 0 active online
Node1 1 standby online
----------------------------- ------- ------- --------
- Le fichier RPM DDOS doit être placé sur le nœud actif et la mise à niveau doit commencer à partir de ce nœud.
#ha status
HA System name: HA-system
HA System status: highly available
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node0 0 active online Node0 is active node
Node1 1 standby online
----------------------------- ------- ------- --------
- Téléchargez le fichier RPM sur le nœud actif
Client-server # scp <rpm file> sysadmin@HA-system.active_node:/ddr/var/releases/
Password: (customer defined it.)
(From client server, target path is “/ddr/var/releases”)
You might need the -O option to get scp to work
Active-node # system package list
File Size (KiB) Type Class Name Version ------------------ ---------- ------ ---------- ----- ------- x.x.x.x-12345.rpm 2927007.3 System Production DD OS x.x.x.x ------------------ ---------- ------ ---------- ----- -------
- Exécutez une vérification préalable sur le nœud actif. La mise à niveau doit être abandonnée en cas d’erreur.
Active-node # system upgrade precheck <rpm file>
Upgrade precheck in progress:
Node 0: phase 1/1 (Precheck 100%) , Node 1: phase 1/1 (Precheck 100%)
Upgrade precheck found no issues.
Veuillez également arrêter le GC, le déplacement de données et la réplication avant de lancer la mise à niveau (étape 6), afin d’éviter que ces tâches n’allongent le temps d’arrêt de DDFS pendant la mise à niveau. Un temps d’arrêt plus court de DDFS permet de réduire l’impact sur les clients. Ces charges applicatives n’affectent pas les opérations de sauvegarde/restauration des clients. En fonction des besoins, ces services peuvent être repris une fois la mise à niveau terminée à l’aide des commandes d’activation correspondantes. Veuillez consulter le Guide d’administration pour plus de détails. Active-node # filesys clean stop Active-node # cloud clean stop Active-node # replication disable all
Notez qu’il existe plusieurs commandes « watch » permettant de vérifier si les opérations ci-dessus sont terminées.
Active-node # filesys clean watch
Active-node # cloud clean watch
D’autres vérifications et commandes manuelles sont décrites dans le guide d’administration, mais elles ne sont pas strictement nécessaires pour un système HA. Un pré-redémarrage est actuellement recommandé comme test pour les systèmes à nœud unique. Il n’est pas nécessaire pour les systèmes HA, car l’étape 5 « ha failover » ci-dessous inclut déjà un redémarrage automatique pendant le processus de basculement.
- En option. Avant d’exécuter une mise à niveau consécutive, il est recommandé d’effectuer deux fois le basculement HA manuellement sur le nœud actif. L’objectif est de tester la fonctionnalité de basculement. L’opération redémarre le nœud actif. Veuillez en tenir compte.
Tout d’abord, préparez le basculement en désactivant le GC, le déplacement des données et la réplication. Ces services n’ont aucun impact sur les charges applicatives de sauvegarde/restauration des clients. Exécutez ensuite « ha failover ».
Les commandes à exécuter sont les suivantes :
Active-node # filesys clean stop
Active-node # cloud clean stop
Active-node # replication disable all
Notez qu’il existe plusieurs commandes « watch » permettant de vérifier si les opérations ci-dessus sont terminées.
Active-node # filesys clean watch
Active-node # cloud clean watch
Puis exécutez la commande de basculement:
Active-node # ha failoverThis operation will initiate a failover from this node. The local node will reboot.
Do you want to proceed? (yes|no) [no]: yes
Failover operation initiated. Run 'ha status' to monitor the status
(Lorsque l’état du système HA redevient « disponibilité élevée », exécutez le deuxième « ha failover » et attendez que les deux nœuds soient en ligne)
Après le basculement HA, les services arrêtés peuvent être repris à l’aide des commandes d’activation correspondantes. Veuillez consulter le Guide d’administration pour plus de détails.
Les tests de basculement décrits ci-dessus sont optionnels et n’ont pas besoin d’être effectués immédiatement avant la mise à niveau. Les tests de basculement peuvent être effectués avant la mise à niveau, par exemple deux semaines avant, afin de pouvoir utiliser une fenêtre de maintenance plus courte pour la mise à niveau ultérieure. L’interruption du service DDFS pour chaque basculement est d’environ 10 minutes (plus ou moins selon la version de DDOS et d’autres facteurs). Les versions DDOS 7.4 et ultérieures présentent un temps d’arrêt réduit à chaque nouvelle version grâce aux améliorations continues du logiciel DDOS.
- Si la vérification préalable s’est terminée sans aucun problème, procédez à la mise à niveau consécutive sur le nœud actif.
Active-node # system upgrade start <rpm file> The 'system upgrade' command upgrades the Data Domain OS. File access
is interrupted during the upgrade. The system reboots automatically
after the upgrade.
Are you sure? (yes|no) [no]: yes ok, proceeding. Upgrade in progress: Node Severity Issue Solution ---- -------- ------------------------------ -------- 0 WARNING 1 component precheck script(s) failed to complete 0 INFO Upgrade time est: 60 mins 1 WARNING 1 component precheck script(s) failed to complete 1 INFO Upgrade time est: 80 mins ---- -------- ------------------------------ -------- Node 0: phase 2/4 (Install 0%) , Node 1: phase 1/4 (Precheck 100%) Upgrade phase status legend: DU : Data Upgrade FO : Failover .. PC : Peer Confirmation VA : Volume Assembly Node 0: phase 3/4 (Reboot 0%) , Node 1: phase 4/4 (Finalize 5%) FO Upgrade has started. System will reboot.
Disponibilité de DDFS pendant la commande ci-dessus :
-
Le système met d’abord à niveau le nœud en veille et le redémarre avec la nouvelle version. En fonction de divers facteurs, il faut compter entre 20 et 30 minutes. Le service DDFS est opérationnel et fonctionne sur le nœud actif pendant cette période sans aucune dégradation des performances.
-
Après l’application du nouveau DDOS, le système effectue un basculement du service DDFS vers le nœud en veille mis à niveau. Il faut compter environ 10 minutes (un peu plus ou moins en fonction de divers facteurs).
-
La mise à niveau du firmware du boîtier de disque (DAE) est un facteur important. Cela peut entraîner environ 20 minutes d’interruption de service supplémentaires en fonction du nombre de boîtiers DAE configurés. Veuillez consulter l’article de la base de connaissances « Data Domain : la mise à niveau consécutive HA peut échouer lorsque le firmware du boîtier externe a été mis à niveau », afin de déterminer si une mise à niveau du firmware du boîtier DAE est requise. Notez qu’à partir de DDOS 7.5, une amélioration permet la mise à niveau en ligne du firmware du boîtier DAE, ce qui élimine ce problème.
-
Le support Dell peut être contacté pour discuter des facteurs susceptibles d’affecter les délais de mise à niveau. Selon le système d’exploitation client, l’application et le protocole utilisé entre le client et le système HA, il peut parfois être nécessaire de relancer manuellement les charges applicatives du client juste après le basculement. Par exemple, avec des clients DDBoost, si le temps de basculement dépasse 10 minutes, le client peut expirer et l’utilisateur devra relancer manuellement les charges applicatives. Cependant, la plupart des clients disposent de paramètres configurables permettant de définir les valeurs de délai d’expiration et le nombre de tentatives de reprise.
-
-
Après le basculement, le nœud actif précédent est mis à niveau. Après l’application de la mise à niveau, le système redémarre avec la nouvelle version, puis rejoint le cluster HA en tant que nœud en veille. Le service DDFS n’est pas affecté au cours de ce processus, car il a déjà été repris dans ci-dessus.
- Une fois que le nœud en veille (nœud 1) a redémarré et devient accessible, il est possible de se connecter au nœud en veille pour surveiller l’état/la progression de la mise à niveau.
Node1 # system upgrade status
Current Upgrade Status: DD OS upgrade In Progress
Node 0: phase 3/4 (Reboot 0%)
Node 1: phase 4/4 (Finalize 100%) waiting for peer confirmation
- Veuillez attendre la fin de la mise à niveau consécutive. Avant cela, ne déclenchez aucune opération de basculement HA.
Node1 # system upgrade status
Current Upgrade Status: DD OS upgrade Succeeded
End time: 20xx.xx.xx:xx:xx
- Vérifiez l’état du système HA : les deux nœuds doivent être en ligne et l’état du système HA doit être « disponibilité élevée ».
Node1 # ha status detailed
HA System name: HA-system
HA System Status: highly available
Interconnect Status: ok
Primary Heartbeat Status: ok
External LAN Heartbeat Status: ok
Hardware compatibility check: ok
Software Version Check: ok
Node Node1:
Role: active
HA State: online
Node Health: ok
Node Node0:
Role: standby
HA State: online
Node Health: ok
Mirroring Status:
Component Name Status
-------------- ------
nvram ok
registry ok
sms ok
ddboost ok
cifs ok
-------------- ------
Vérification :
- Vérifiez que les deux nœuds ont la même version de DDOS.
Node1 # system show version
Data Domain OS x.x.x.x-12345
Node0 # system show version
Data Domain OS x.x.x.x-12345
- Vérifiez s’il y a des alertes inattendues.
Node1 # alert show current
Node0 # alert show current
- À ce stade, la mise à niveau consécutive est terminée avec succès.
Remarque : Si vous rencontrez des problèmes avec la mise à niveau, veuillez contacter le support Data Domain pour obtenir des instructions et un support supplémentaires.
MISE À NIVEAU LOCALE pour la paire DDHA :
une mise à niveau locale fonctionne généralement comme suit :
Préparation du système pour la mise à niveau :
- Vérifiez l’état du système HA. Même si l’état est dégradé, la mise à niveau locale peut fonctionner dans ce cas.
#ha status HA System name: HA-system HA System status: highly available <- Node Name Node id Role HA State ----------------------------- ------- ------- -------- Node0 0 active online Node1 1 standby online ----------------------------- ------- ------- --------
- Le fichier RPM DDOS doit être placé sur le nœud actif et la mise à niveau doit commencer à partir du nœud en veille.
#ha status
HA System name: HA-system
HA System status: highly available
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node0 0 active online
Node1 1 standby online <- Node1 is standby node
----------------------------- ------- ------- --------
- Téléchargez le fichier RPM sur les deux nœuds.
Client-server # scp <rpm file> sysadmin@HA- system.active_node:/ddr/var/releases/
Client-server # scp <rpm file> sysadmin@HA-system.standby_node:/ddr/var/releases/
Password: (customer defined it.)
You might need the -O option to get scp to work(From client server, target path is “/ddr/var/releases”)
Active-node # system package list File Size (KiB) Type Class Name Version ------------------ ---------- ------ ---------- ----- ------- x.x.x.x-12345.rpm 2927007.3 System Production DD OS x.x.x.x ------------------ ---------- ------ ---------- ----- ------ Standby-node # system package list File Size (KiB) Type Class Name Version ------------------ ---------- ------ ---------- ----- ------- x.x.x.x-12345.rpm 2927007.3 System Production DD OS x.x.x.x ------------------ ---------- ------ ---------- ----- ------
- Exécutez une vérification préalable sur le nœud actif si l’état HA est « disponibilité élevée ». La mise à niveau doit être abandonnée en cas d’erreur.
Active-node # system upgrade precheck <rpm file>
Upgrade precheck in progress: Node 0: phase 1/1 (Precheck 100%) , Node 1: phase 1/1 (Precheck 100%) Upgrade precheck found no issues.
If HA status is "degraded", need do precheck on both nodes.
Active-node # system upgrade precheck <rpm file> local
Upgrade precheck in progress:
Node 0: phase 1/1 (Precheck 100%)
Upgrade precheck found no issues.
Standby-node # system upgrade precheck <rpm file> local
Upgrade precheck in progress:
Node 1: phase 1/1 (Precheck 100%)
Upgrade precheck found no issues.
- Mettez le nœud en veille hors ligne.
Standby-node # ha offline
This operation will cause the ha system to no longer be highly available.
Do you want to proceed? (yes|no) [no]: yes
Standby node is now offline.
(Remarque : Si l’opération hors ligne a échoué ou si l’état HA est dégradé, poursuivez la mise à niveau locale, car les étapes ultérieures peuvent gérer des défaillances.)
- Assurez-vous que l’état du nœud en veille est bien hors ligne.
Standby-node # ha status
HA System name: HA-system
HA System status: degraded
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node1 1 standby offline
Node0 0 active degraded
----------------------------- ------- ------- --------
- Effectuez la mise à niveau sur le nœud en veille. Cette opération entraîne le redémarrage du nœud en veille.
The 'system upgrade' command upgrades the Data Domain OS. File access
is interrupted during the upgrade. The system reboots automatically
after the upgrade.
Are you sure? (yes|no) [no]: yes
ok, proceeding.
The 'local' flag is highly disruptive to HA systems and should be used only as a repair operation.
Are you sure? (yes|no) [no]: yes
ok, proceeding.
Upgrade in progress:
Node 1: phase 3/4 (Reboot 0%)
Upgrade has started. System will reboot.
- Le nœud en veille redémarre avec la nouvelle version de DDOS mais reste hors ligne.
- Vérifiez l’état de la mise à niveau du système. la mise à niveau du système d’exploitation peut prendre plus de 30 minutes.
Standby-node # system upgrade status
Current Upgrade Status: DD OS upgrade Succeeded
End time: 20xx.xx.xx:xx:xx
- Vérifiez l’état du système HA : le nœud en veille (dans ce cas, node1) doit être hors ligne et l’état HA doit être « dégradé ».
Standby-node # ha status
HA System name: HA-system
HA System status: degraded
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node1 1 standby offline
Node0 0 active degraded
----------------------------- ------- ------- --------
- Effectuez la mise à niveau locale sur le nœud actif. Cette opération redémarre le nœud actif.
Active-node # system upgrade start <rpm file> local
The 'system upgrade' command upgrades the Data Domain OS. File access
is interrupted during the upgrade. The system reboots automatically
after the upgrade.
Are you sure? (yes|no) [no]: yes
ok, proceeding.
The 'local' flag is highly disruptive to HA systems and should be used only as a repair operation.
Are you sure? (yes|no) [no]: yes
ok, proceeding.
Upgrade in progress:
Node Severity Issue Solution
---- -------- ------------------------------ --------
0 WARNING 1 component precheck
script(s) failed to complete
0 INFO Upgrade time est: 60 mins
---- -------- ------------------------------ --------
Node 0: phase 3/4 (Reboot 0%)
Upgrade has started. System will reboot.
- Vérifiez l’état de la mise à niveau du système. la mise à niveau du système d’exploitation peut prendre plus de 30 minutes.
Active-node # system upgrade status
Current Upgrade Status: DD OS upgrade Succeeded
End time: 20xx.xx.xx:xx:xx
- Une fois la mise à niveau du nœud actif terminée, l’état du système HA reste dégradé. Exécutez la commande suivante pour remettre le nœud en veille en ligne. Cette opération redémarre le nœud en veille.
Standby-node # ha online The operation will reboot this node. Do you want to proceed? (yes|no) [no]: yes Broadcast message from root (Wed Oct 14 22:38:53 2020): The system is going down for reboot NOW! **** Error communicating with management service.(Remarque : si la commande « ha offline » n’a pas été exécutée lors des étapes précédentes, veuillez ignorer cette étape.)
- Le nœud en veille redémarre et rejoint le cluster. Après cela, l’état HA redevient « disponibilité élevée ».
Active-node # ha status detailed
HA System name: Ha-system
HA System Status: highly available
Interconnect Status: ok
Primary Heartbeat Status: ok
External LAN Heartbeat Status: ok
Hardware compatibility check: ok
Software Version Check: ok
Node node0:
Role: active
HA State: online
Node Health: ok
Node node1:
Role: standby
HA State: online
Node Health: ok
Mirroring Status:
Component Name Status
-------------- ------
nvram ok
registry ok
sms ok
ddboost ok
cifs ok
-------------- ------
Vérification :
- Vérifiez que les deux nœuds ont la même version de DDOS.
Node1 # system show version
Data Domain OS x.x.x.x-12345
Node0 # system show version
Data Domain OS x.x.x.x-12345
- Vérifiez s’il y a des alertes inattendues.
Node1 # alert show current
Node0 # alert show current
- À ce stade, la mise à niveau consécutive est terminée avec succès.
Informations supplémentaires
Mise à niveau consécutive :
-
Notez qu’un seul basculement est effectué lors de la mise à niveau afin que les rôles puissent être échangés
-
Des informations sur la mise à niveau sont toujours disponibles dans infra.log, mais il se peut que des informations supplémentaires soient disponibles dans ha.log
-
La progression de la mise à niveau peut être surveillée via la surveillance des mises à niveau du système
Mise à niveau de nœud local :
-
Une mise à niveau de nœud local n’effectue pas de basculement HA
-
Par conséquent, il y a une période prolongée d’indisponibilité pendant que le nœud actif effectue la mise à niveau, redémarre et exécute les activités de mise à niveau post-redémarrage, ce qui peut entraîner des expirations et des échecs des sauvegardes et restaurations. Il est nécessaire de prévoir une période pour la mise à niveau locale.
-
Même si l’état du système HA est « degraded », la mise à niveau locale peut être effectuée.
-
Pour une raison quelconque, la mise à niveau progressive peut échouer de manière inattendue. Une mise à niveau locale peut être envisagée comme méthode de correction dans cette situation.