Maintenir la disponibilité des services pendant une mise à niveau de SLES 15 SP5 vers SP6

Il est difficile de planifier une courte fenêtre de maintenance lorsqu'un serveur SLES exécute un service destiné aux clients. SUSE prend en charge la migration en ligne des Service Packs de SLES 15 SP5 vers SP6, mais la machine mise à niveau nécessite toujours un redémarrage ; « en ligne » ne signifie pas sans redémarrage. Pour maintenir l'accessibilité d'une application, mettez à niveau les nœuds redondants un par un ou créez un serveur de remplacement SP6 et redirigez le trafic vers celui-ci. Un serveur unique ne peut pas maintenir son propre système d'exploitation disponible pendant son redémarrage.

Scénario illustratif : une équipe fictive exécute une application web sur trois nœuds SLES 15 SP5 derrière un équilibreur de charge. L’application peut traiter les requêtes des deux autres nœuds lorsqu’un nœud est en maintenance. La séquence ci-dessous montre comment cette équipe pourrait migrer le cluster ; il s’agit d’un exemple, et non d’une affirmation selon laquelle un test a été effectué ou que tous les clusters peuvent tolérer la panne d’un nœud.

1. Choisissez un chemin qui correspond au service

Pour la migration de SLES 15 SP5 vers SP6, SUSE documente les méthodes de mise à niveau en ligne et hors ligne. La méthode en ligne utilise la migration YaST ou zypper migrations'effectue pendant l'exécution du système d'exploitation, puis nécessite un redémarrage après la migration. Les modifications apportées aux paquets peuvent également entraîner le redémarrage de services ; par conséquent, la migration en ligne seule ne garantit pas la continuité des applications.

N’utilisez la procédure de mise à niveau progressive de la haute disponibilité SLE que si votre charge de travail est déjà protégée par un cluster opérationnel et pris en charge. Le cluster doit conserver le quorum et une capacité suffisante pour assurer le fonctionnement du service même en cas d’indisponibilité d’un nœud. Un équilibreur de charge classique sans redondance applicative, ou un cluster à deux nœuds perdant le quorum lorsqu’un nœud s’arrête, ne suffit pas. Si le serveur est autonome, utilisez un hôte SP6 parallèle et une procédure de basculement de charge de travail/données testée pour garantir la disponibilité ; sinon, planifiez une interruption de service pour son redémarrage.

2. Vérifier la cible et préparer un plan de récupération

Avant toute intervention sur le cluster, vérifiez la version de démarrage, l'enregistrement, les dépôts et les extensions prises en charge. SUSE indique que la migration de SLES 15 SP5 à SP6 est prise en charge. La migration en ligne nécessite que la machine soit enregistrée auprès du SUSE Customer Center ou d'un serveur RMT local ; les clients SUSE Manager doivent utiliser la procédure de migration du client Manager au lieu d'une exécution zypper migrationdirecte. La cible disponible peut dépendre des produits et extensions enregistrés.

À compter du 1er janvier 2026, les informations de version de SUSE indiquent que SLES 15 SP6 est passé en version LTSS. Avant de planifier cette migration, assurez-vous que votre abonnement et votre source d'enregistrement proposent bien la version SP6. Si ce n'est pas le cas, ne forcez pas la modification du dépôt pour simuler une migration prise en charge.

Sauvegardez les données et la configuration de l'application à l'aide de la méthode prise en charge et assurez-vous de pouvoir les restaurer. Consultez le guide de mise à niveau SLE HA et les notes de version SP6 pour vos extensions, bases de données, stockage et matériel. Dans le cluster fictif, l'opérateur vérifie également le quorum, le fencing, l'état de la réplication, la capacité disponible, l'état de l'équilibreur de charge et une méthode éprouvée pour rediriger le trafic hors de chaque nœud. Un instantané peut faciliter la restauration sur les configurations racine Btrfs prises en charge, mais ne remplace pas les sauvegardes d'application ou de base de données.

3. Mettez à niveau un nœud déchargé à la fois.

Pour chaque nœud, suivez la procédure de mise à niveau progressive SLE HA et le manuel d'exploitation de votre cluster. Ne mettez jamais à niveau plusieurs nœuds simultanément, sauf si la procédure spécifique au produit l'autorise explicitement.

1. Vérifiez que les nœuds restants peuvent supporter la charge de travail. Contrôlez l'état de l'application et du cluster. Réduisez le trafic du nœud en suivant les instructions de votre équilibreur de charge et des ressources du cluster. N'effectuez aucune autre opération si les nœuds restants ne peuvent maintenir le quorum ou atteindre la capacité minimale du service.
2. Arrêtez la pile de cluster sur ce nœud. SUSE avertit que le maintien du gestionnaire de ressources de cluster actif pendant la mise à jour logicielle peut entraîner l'isolation des nœuds actifs. Sur le nœud sélectionné pour la maintenance, exécutez :

sudo crm cluster stop

3. Démarrez la migration du Service Pack et examinez la proposition. Exécutez la commande de migration Zypper documentée :

sudo zypper migration

Sélectionnez SLES 15 SP6 uniquement s'il apparaît comme cible disponible. Consultez le dépôt et le plan de mise à jour des paquets, en particulier les paquets proposés pour suppression ou rétrogradation, et interrompez la mise à jour si les changements sont inattendus. N'acceptez pas un plan que vous n'avez pas examiné. La liste exacte des paquets varie selon les logiciels installés et les extensions enregistrées.

4. Redémarrez le nœud mis à niveau. Une fois que Zypper aura signalé une migration réussie, redémarrez la machine pour qu'elle démarre le noyau et les services SP6 :

sudo reboot

5. Rejoignez la connexion et vérifiez avant de passer au nœud suivant. Une fois le nœud opérationnel, démarrez sa pile de cluster :

sudo crm cluster start
sudo crm status

Attendez que le cluster signale que le nœud a rejoint le cluster et que ses ressources sont opérationnelles, puis remettez-le en service conformément à votre procédure d'exécution. Vérifiez l'application depuis l'extérieur du cluster. Répétez ensuite le processus pour le nœud suivant. SUSE n'autorise que brièvement l'utilisation de versions mixtes lors d'une mise à niveau progressive et recommande aux administrateurs de terminer la mise à niveau du cluster en une semaine.

4. Vérifiez le service, et pas seulement l'étiquette du système d'exploitation.

Une fois tous les nœuds mis à niveau, confirmez leur mise en service avec `npm install` cat /etc/os-release, vérifiez l'état du cluster avec ` npm install` crm statuset contrôlez les unités systemd défaillantes avec `npm install` systemctl --failed. Testez ensuite l'application via son adresse client habituelle, en incluant les contrôles d'intégrité, l'accès à la base de données ou au stockage, et toutes les tâches planifiées importantes pour les utilisateurs. Consultez les journaux de migration et assurez-vous que les dépôts et extensions attendus sont actifs sur chaque nœud.

Une migration réussie du système d'exploitation ne garantit pas la compatibilité de toutes les dépendances applicatives ni l'absence d'interruption de requêtes. Si l'application ne tolère pas un basculement de nœud, utilisez un déploiement bleu-vert avec réplication des données validée et commutation contrôlée des points de terminaison, ou planifiez une fenêtre de maintenance. Pour connaître les options de commande exactes et les conditions de prise en charge, consultez le guide de mise à niveau en ligne de SUSE SLES 15 SP6 , les chemins de mise à niveau pris en charge , la procédure de mise à niveau progressive SLE HA et les notes de version de SUSE Multi-Linux Manager 5.1 relatives à la transition vers le SP6.