Vous pouvez maintenir une application disponible lors de la migration d'un cluster SLES 15 SP5 vers SP6, mais vous ne pouvez pas mettre à niveau et redémarrer une instance de système d'exploitation sans interruption de service. SUSE prend en charge la migration des Service Packs de SP5 vers SP6, et le processus de migration en ligne nécessite toujours un redémarrage du système. Pour éviter toute interruption de service, mettez à niveau un nœud à la fois dans un cluster SUSE Linux Enterprise High Availability (SLE HA) compatible, ou créez un environnement SP6 de remplacement et redirigez-y le trafic. Le service doit pouvoir s'exécuter sur un autre serveur disponible pendant l'indisponibilité de chaque hôte.
Ce guide destiné aux débutants se concentre sur la procédure de mise à niveau progressive d'un cluster SLE HA. Il explique également la marche à suivre si vous ne disposez que d'un seul serveur, les vérifications à effectuer avant la modification et comment s'assurer du bon fonctionnement du service. Les commandes exactes et l'ordre de migration des charges de travail dépendent des ressources, du stockage et de l'application de votre cluster.
Une migration par Service Pack remplace les paquets système pendant que le système source est en cours d'exécution. SUSE appelle cela une migration en ligne. Cela réduit la nécessité de démarrer à partir du support d'installation, mais la procédure officielle recommande de redémarrer le système après une migration réussie. La migration en ligne est différente d'une mise à niveau à chaud qui laisse le même hôte continuer à traiter les requêtes.
Pour un service en cluster, une mise à niveau progressive consiste à mettre un nœud hors service, à le migrer et à le redémarrer, puis à le réintégrer au cluster, et enfin à répéter l'opération sur le nœud suivant. L'application peut rester accessible depuis un autre nœud si le basculement fonctionne et si la capacité restante est suffisante. Un basculement peut néanmoins entraîner une brève interruption des sessions actives ; il est donc important de mesurer la qualité du service pour l'utilisateur plutôt que de supposer que la « haute disponibilité » garantit l'absence totale d'interruption de connexion.
SUSE indique que SLES 15 SP5 est une source compatible pour le SP6, en ligne comme hors ligne. La procédure de mise à niveau est décrite dans le guide de mise à niveau de SLES 15 SP6 . La documentation SUSE HA prend en charge la mise à niveau progressive d'un cluster entre les Service Packs d'une même version majeure. Consultez le guide de mise à niveau des clusters SLES HA .
zypper migrationdirecte sur un client SUSE Manager.Si votre service est une base de données ou une autre application avec état, traitez la compatibilité applicative et la réplication des données comme un processus distinct. Une migration du système d'exploitation ne met pas automatiquement à niveau la base de données et ne garantit pas la sécurité de sa réplication et de son architecture de basculement.
Vérifiez que chaque nœud exécute SLES 15 SP5, avec l'extension SLE HA et les autres modules ou produits correctement enregistrés. La liste des cibles de migration dépend des produits et extensions installés. L'absence d'une cible SP6 peut indiquer un problème d'enregistrement, de référentiel ou de disponibilité d'extension ; ne forcez pas un autre chemin de référentiel pour faire apparaître la cible.
Pour un système enregistré, les contrôles en lecture seule suivants peuvent aider à établir son état :
cat /etc/os-release
sudo SUSEConnect --status
sudo zypper lr -u
Comparez les produits SLES et SLE HA installés, les dépôts et l'architecture sur tous les nœuds. Si l'hôte est géré par SUSE Manager, utilisez la procédure de migration client correspondante au lieu des étapes décrites ci-dessous.
SUSE exige que le système source soit à jour avant la mise à niveau. Appliquez les mises à jour de maintenance SP5 actuelles et consultez les notes de version SP6 pour prendre connaissance des modifications apportées aux paquets, modules et applications. Les instructions de préparation à la mise à niveau de SUSE recommandent également d'effectuer une sauvegarde récente et de consulter les notes de version.
Sauvegardez la configuration système et les données applicatives, et vérifiez que la sauvegarde est restaurable. Testez l'ensemble de la procédure sur un cluster de préproduction identique à celui de production, incluant les interfaces réseau, le stockage, les ressources du cluster, les référentiels tiers et les contrôles d'intégrité des applications. Enregistrez la durée de la migration et du redémarrage sur chaque nœud afin d'estimer la fenêtre de modification.
Avant de retirer un nœud, assurez-vous que le cluster est sain et ne présente aucune défaillance de ressources non résolue. Vérifiez qu'un autre nœud peut exécuter les services, accéder au stockage requis et gérer le trafic prévu. Si la suppression d'un nœud risque de surcharger le processeur, la mémoire, le réseau ou le stockage, augmentez la capacité, réduisez la charge ou planifiez une fenêtre de maintenance plutôt que de garantir l'absence d'indisponibilité.
Assurez-vous que le cloisonnement du cluster est configuré et fonctionne conformément à votre architecture haute disponibilité. Ce cloisonnement protège les ressources partagées en isolant un nœud non fiable ; le désactiver pour simplifier une mise à niveau peut engendrer un risque de split-brain. Conservez un accès console ou hors bande disponible au cas où un nœud ne redémarrerait pas.
Utilisez les étapes ci-dessous comme plan de planification. Suivez la procédure correspondant à votre version SLE HA et à votre configuration de ressources ; ne copiez pas aveuglément une séquence de gestion des ressources en production.
crm statusune méthode documentée permet d'inspecter l'état du cluster.crm cluster stop.sudo zypper migration. Examinez la cible SP6 proposée et les modifications apportées aux dépôts. Lisez attentivement les actions proposées sur les paquets, notamment ceux à supprimer ou à rétrograder, avant de confirmer. La documentation officielle de migration SLES en ligne décrit cette procédure.crm cluster start. Vérifiez crm statusavec Hawk2 que le nœud rejoint bien le cluster sans défaillance de ressources.SUSE indique que la prise en charge des nœuds de cluster à versions mixtes est temporaire et que la mise à niveau doit être effectuée en une semaine. Il est recommandé de planifier une séquence courte et contrôlée plutôt que de laisser un cluster à versions mixtes en place indéfiniment. Enfin, vérifiez que tous les nœuds exécutent le Service Pack 6, contrôlez l'état du cluster et des applications, et consultez les journaux et l'enregistrement du dépôt.
Définissez un critère de réussite mesurable avant la modification. Par exemple : le contrôle d’intégrité externe du service doit être validé pendant toute la maintenance de chaque nœud, les taux d’erreur doivent rester inférieurs au seuil convenu et une transaction utilisateur représentative doit aboutir malgré l’indisponibilité d’un nœud. Consignez tout incident de basculement, session interrompue, tâche en file d’attente ou dégradation des performances. Si le point de terminaison est resté opérationnel mais qu’un flux de travail essentiel a échoué, la migration n’a pas atteint l’objectif de niveau de service.
Une mise à niveau progressive permet de maintenir un service correctement conçu disponible pendant le redémarrage des serveurs. Elle ne peut cependant pas garantir la continuité des sessions, compenser une capacité insuffisante du cluster ni supprimer le redémarrage de chaque hôte migré. Pour les déploiements sur un seul nœud, les applications avec état sans réplication testée ou les clusters avec des extensions non prises en charge, il est recommandé de planifier une fenêtre de maintenance ou de créer et valider un environnement de remplacement avant de basculer le trafic de production.
Corrigez les déchirures d'écran des cartes graphiques Intel sous Pardus Linux en vérifiant X11 vs Wayland, les paramètres du compositeur, le taux de rafraîchissement, le pilote Xorg actif et TearFree uniquement lorsque cela est approprié.
Configurer firewalld sur SLES 15 : vérifier les zones, autoriser les services ou les ports, enregistrer les règles permanentes, recharger en toute sécurité et vérifier l’accès.
Activez la mise à jour en direct du noyau sur SLES 15 SP7, appliquez les correctifs pris en charge sans redémarrer, vérifiez les correctifs actifs et comprenez quand un redémarrage du noyau est encore nécessaire.
Activez le mode FIPS sur SLES 15 avec l'utilitaire de configuration pris en charge par SUSE, redémarrez en toute sécurité, vérifiez l'état du noyau et de la politique de chiffrement, et vérifiez les limites de certification.
Installez Google Chrome sur Gooroom OS en toute sécurité grâce aux paquets .deb officiels, à APT, aux vérifications de politique, aux conseils de mise à jour et aux correctifs pour les appareils gérés.
Transférez en toute sécurité les journaux système SLES vers un serveur syslog distant grâce à rsyslog, aux certificats TLS, à la vérification du nom du pair, aux files d'attente, à la validation et aux tests.
Intégrez SLES 15 à Active Directory avec SSSD à l'aide de YaST. Configurez le DNS et l'heure, configurez les connexions au domaine, vérifiez Kerberos et comparez SSSD, Winbind et realmd.
Résolvez les problèmes de Wi-Fi RTL8821CE sur Pardus Linux en vérifiant le pilote rtw88 intégré, le firmware Realtek, rfkill, NetworkManager et les options de repli sécurisées.
Diagnostiquer et corriger les échecs de résolution DNS de Debian 12 avec systemd-resolved, y compris resolv.conf, NetworkManager, networkd, cache et vérification.
Installez Pardus 25.2 à côté de Windows 11 en sauvegardant, en réduisant le volume Windows, en démarrant sur une clé USB UEFI et en protégeant les partitions EFI et de récupération existantes.
