(Note de l'auteur : cette réponse fait référence à RHEL 6 et aux versions antérieures. RHEL 7 dispose désormais d'un chemin de mise à niveau entièrement pris en charge à partir de RHEL 6, dont les détails figurent à la fin).

Pour commencer, je dois noter qu'il y a deux façons pour faire la mise à niveau sur place :

1. Insérez le DVD d'installation (ou utilisez l'image DVD via iLO/iDRAC), démarrez à partir de celui-ci et choisissez Mise à niveau, par exemple. linux upgradeany .
2. Mettre à jour le redhat-release RPM manuellement, exécutez yum distro-sync (c'est un peu trop simplifié) et redémarrer.

La méthode 1 est simplement non soutenue. La méthode 2 est pour les vrais cowboys. En plus des nouvelles installations recommandées, j'ai fait ces deux méthodes...

Ai-je besoin d'un soutien ?

Soutien a deux significations complémentaires dans notre monde. La première est qu'un produit possède une caractéristique donnée (par exemple, "Postfix supporte le SMTP"). La seconde est que le vendeur vous en parlera. Le contexte ne permet pas toujours de savoir quelle définition est la bonne.

Pour accomplir une tâche, vous avez évidemment besoin d'un soutien au sens premier du terme. Là où le support du fournisseur entre en jeu, c'est pour vous aider à résoudre les problèmes et à donner au fournisseur un retour d'information sur les fonctionnalités qui doivent exister ou être améliorées. De nombreux sites paient une fortune pour bénéficier de l'assistance d'un fournisseur alors qu'ils disposent de l'expertise interne pour résoudre tout problème éventuel, plus rapidement et à moindre coût que le fournisseur. L'achat d'une assistance technique est en fin de compte une décision commerciale que vous devrez prendre (ou conseiller la direction).

Pourquoi ne pas faire une mise à jour sur place ?

C'est ce que Red Hat dit à ce sujet :

Red Hat ne prend pas en charge les mises à niveau sur place entre les versions majeures de Red Hat Enterprise Linux. Une version majeure est désignée par un changement de version en nombre entier. Par exemple, Red Hat Enterprise Linux 5 et Red Hat Enterprise Linux 6 sont toutes deux des versions majeures de Red Hat Enterprise Linux.

Les mises à niveau en place dans les versions majeures ne préservent pas tous les paramètres du système, les services ou les configurations personnalisées. Par conséquent, Red Hat recommande fortement de procéder à de nouvelles installations lors de la mise à niveau d'une version majeure à une autre.

Ils mettent également en garde :

Toutefois, notez les limitations suivantes avant de choisir de mettre votre système à niveau :

• Les fichiers de configuration des paquets individuels peuvent ou non fonctionner après l'exécution d'une mise à niveau en raison des modifications apportées aux divers formats ou dispositions des fichiers de configuration.
• Si l'un des produits en couches de Red Hat (tels que Cluster Suite) est installé, il peut s'avérer nécessaire de le mettre à niveau manuellement une fois la mise à niveau de Red Hat Enterprise Linux terminée.
• Les applications tierces ou ISV peuvent ne pas fonctionner correctement après la mise à niveau.

Bien entendu, ils décrivent ensuite comment effectuer une mise à niveau sur place via la méthode 1, au cas où vous voudriez vraiment le faire. La fonctionnalité existe et Red Hat y consacre du temps de développement, elle est donc prise en charge dans la mesure où elle existe. Mais si quelque chose ne va pas, Red Hat vous dira d'effectuer une nouvelle installation ; ils ne fourniront pas de support fournisseur pour les choses qui se cassent suite à la mise à niveau.

Pour mémoire, je n'ai jamais eu de problème avec une mise à niveau sur place d'un système RHEL/CentOS ou Fedora que je n'ai pas pu résoudre moi-même. Les problèmes typiques proviennent de paquets renommés, de dépôts tiers et d'un décalage occasionnel de version entre les architectures i386 et x86_64 d'un paquet. Le programme d'installation est un peu meilleur pour gérer ces problèmes que le programme yum Je pense.

Comment dois-je procéder à la mise à niveau ?

Je préviens généralement les gens qu'ils devraient plan sur une fenêtre de maintenance tous les 3-4 ans pour mettre à jour les systèmes RHEL d'une version majeure à la suivante. Si les mises à jour se déroulent généralement sans problème, l'imprévu peut toujours survenir.

Pour vos deux environnements, je pense qu'une mise à niveau sur place devrait fonctionner, bien que je recommande fortement de la tester minutieusement au préalable. P2V un échantillon représentatif des serveurs et exécutez la mise à niveau sur place sur les systèmes virtuels pour voir quels problèmes vous allez rencontrer. Vous pouvez ensuite planifier la mise à niveau de production réelle en vous basant sur une meilleure connaissance de ce qui se passera.

Pour un grand déploiement comme celui que vous avez ici, envisagez d'utiliser l'approche "un-quelques-uns" de Limoncelli. Mettez à niveau une machine, voyez les problèmes qui surviennent, résolvez-les, puis utilisez les leçons apprises lors de la mise à niveau d'un petit lot de machines, répétez les leçons apprises, puis lorsque vous pensez avoir résolu tous les problèmes, mettez à niveau de grands lots de machines.

Dans un tel contexte, je vous recommande également d'examiner attentivement le processus de déploiement de vos applications. S'il n'est pas suffisamment automatisé pour que vous puissiez le lancer avec une seule commande et être raisonnablement sûr que l'application sera déployée correctement, alors peut-être les développeurs doivent-ils s'y mettre. Avec un tel processus de déploiement, il serait beaucoup plus facile de procéder à une nouvelle installation de la nouvelle version d'EL, puis de la déployer.

Le changement de distribution est-il utile ?

Les distributions basées sur Debian disposent d'une méthode de mise à niveau sur place prise en charge, qui fonctionne généralement, mais qui n'est pas à l'abri de problèmes. Beaucoup de choses se sont cassées pour les gens mise à niveau d'Ubuntu 10.04 LTS vers 12.04 LTS via la méthode supportée, par exemple. Il n'est pas certain que Debian ou Canonical consacrent suffisamment de temps de développement à la " prise en charge " de cette fonctionnalité, c'est-à-dire à s'assurer qu'elle fonctionne. Et vous devez toujours acheter le support du vendeur pour cette distribution si vous voulez que quelqu'un vous tienne la main. Je doute donc que vous gagniez beaucoup à passer à une telle distribution.

Vous pouvez gagner à passer à une distribution à version progressive telle que Gentoo ou Arch. Cependant, cela ne vous met pas non plus à l'abri des problèmes ; cela signifie simplement que vous devez faire face aux problèmes de mise à jour de façon continue pendant la durée de vie du serveur (par exemple, chaque fois que vous ou les développeurs décidez de mettre à jour quelque chose sur le système), plutôt qu'en une seule fois au moment d'une mise à jour bien planifiée de la distribution. Vous n'avez pas non plus de fournisseur pour assurer le support.

Que nous réserve l'avenir ?

Le projet Fedora travaille sur un outil permettant d'améliorer les mises à jour sur place. Ils avaient un outil appelé preupgrade qui a été abandonné et remplacé par un nouvel outil appelé fedup à partir de Fedora 18 . Cela a été ajouté à RHEL7 et maintenant les mises à niveau sur place bénéficient d'un soutien total au moins de RHEL 6 à RHEL 7 . D'après ma propre expérience, je peux dire que si fedup Il y a encore des problèmes il s'avère être un outil très utile.

CentOS expérimente également un dépôt de type rolling-release mais elle ne s'applique qu'aux versions mineures (par exemple, 6.3-6.4).