Pourquoi est-il si difficile de mettre à niveau entre les principales versions de Red Hat et CentOS?

Question

"Pouvons-nous mettre à niveau nos serveurs EL5 de production existants vers EL6?"

Une demande simple de deux clients avec complètement des environnements différents a incité ma réponse aux meilleures pratiques habituelles de "oui, mais cela nécessitera une coordination reconstruction de tous vos systèmes = "...

Les deux clients estiment qu'une reconstruction complète de leurs systèmes est une option inacceptable pour des raisons de temps d'arrêt et de ressources ... Lorsqu'on leur a demandé pourquoi il était nécessaire de réinstaller complètement les systèmes, je n'ai pas eu une bonne réponse au-delà, "c'est comme ça que c'est ... "

Je n'essaye pas d'obtenir des réponses sur la gestion de la configuration ("Puppetize everything" ne s'applique pas toujours ) ou comment les clients auraient dû mieux planifier. Il s'agit d'un exemple concret d'environnements qui ont grandi et prospéré dans une capacité de production, mais ne voient pas de chemin propre pour passer à la prochaine version de leur système d'exploitation.

Environnement A:
Organisation à but non lucratif avec 40 x Red Hat Enterprise Linux 5.4 et 5.5 Web, serveurs de base de données et serveurs de messagerie, exécutant un Java, équilibreurs de charge logicielle et bases de données Postgres. Tous les systèmes sont virtualisés sur deux clusters VMWare vSphere à différents emplacements, chacun avec HA, DRS, etc.

Environnement B:
Société de négociation financière à haute fréquence avec 200 systèmes CentOS 5.x dans plusieurs installations de co-implantation exécutant des opérations de négociation de production, soutenant -des fonctions de développement et de back-office. Les serveurs de trading s'exécutent sur du matériel de serveur de produits de base. Ils ont de nombreux sysctl.conf, rtctl, interruption de la liaison et réglages du pilote pour réduire la latence de la messagerie. Certains ont des noyaux personnalisés et/ou en temps réel. Les postes de travail des développeurs exécutent également une ou des versions similaires de CentOS.

Dans les deux cas, les environnements fonctionnent bien tels quels. Le désir de mise à niveau vient du besoin d'une nouvelle application ou fonctionnalité disponible dans EL6.

Pour l'entreprise à but non lucratif, c'est lié à Apache, au noyau et à certaines choses qui feront le bonheur des développeurs.
Dans la firme commerciale, il s'agit de quelques améliorations dans le noyau, la pile de mise en réseau et GLIBC, qui feront le bonheur des développeurs.

Les deux sont des choses qui ne peuvent pas être facilement empaquetées ou mises à jour sans modifiant radicalement le système d'exploitation .

En tant qu'ingénieur système, j'apprécie le fait que Red Hat recommande des reconstructions complètes lors du passage entre les principales versions. Un bon départ vous oblige à refactoriser et à prêter attention aux configurations en cours de route.

Étant sensible aux besoins commerciaux des clients, je me demande pourquoi cela doit être une telle tâche onéreuse . Le système d'emballage RPM est plus que capable de gérer les mises à niveau sur place, mais ce sont les petits détails qui vous permettent: /boot nécessitant plus d'espace, de nouveaux systèmes de fichiers par défaut, des RPM pouvant casser en cours de mise à niveau, des packages obsolètes et disparus ...

Quelle est la réponse ici? D'autres distributions (basées sur .deb, Arch et Gentoo) semblent avoir cette capacité ou un meilleur chemin. Disons que nous trouvons le temps d'arrêt pour accomplir cette tâche de la manière à droite:

Que devraient faire ces clients pour éviter le même problème lorsque EL7 est libéré et se stabilise?
Ou est-ce un cas où les gens doivent se résigner à reconstruire complètement toutes les quelques années?
Cela semble avoir empiré à mesure que Enterprise Linux a évolué ... Ou est-ce que j'imagine ça?
Cela a-t-il dissuadé quiconque d'utiliser Red Hat et les systèmes d'exploitation dérivés?

Je suppose qu'il y a l'angle de gestion de la configuration, mais la plupart des installations de marionnettes que je vois ne se traduisent pas bien dans des environnements avec des serveurs d'applications hautement personnalisés ( L'environnement B pourrait avoir un serveur unique dont ifconfig sortie ressemble à ceci ). Je serais intéressant d'entendre des suggestions sur la façon dont la gestion de la configuration peut être utilisée pour aider les organisations à surmonter le bump de la version majeure de RHEL.

Michael Hampton · Accepted Answer

(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 se trouvent à la fin.)

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

Déposez le DVD d'installation (ou utilisez l'image DVD via iLO/iDRAC), démarrez-le et choisissez Mettre à niveau, par ex. linux upgradeany.
Mettez à jour le redhat-release RPM manuellement, exécutez yum distro-sync (c'est un peu simplifié) et redémarrez.

La méthode 1 n'est simplement pas prise en charge. La méthode 2 concerne les vrais cowboys. En plus des nouvelles installations recommandées, j'ai fait les deux ...

Ai-je besoin d'assistance?

Le support a deux significations complémentaires dans notre monde. La première est qu'un produit a une fonctionnalité donnée (par exemple, "Postfix prend en charge SMTP"). La seconde est que le vendeur vous en parlera. La définition que l'on entend n'est pas toujours claire du contexte.

Pour accomplir une tâche, vous avez évidemment besoin de soutien dans le premier sens. Lorsque le support du fournisseur intervient, c'est pour vous aider à résoudre les problèmes et à fournir au fournisseur des commentaires sur les fonctionnalités qui doivent exister ou être améliorées. De nombreux sites paient une fortune pour le support des fournisseurs lorsqu'ils disposent de l'expertise interne pour résoudre les problèmes qui peuvent survenir, plus rapidement et même moins cher que le fournisseur. Que ce soit pour acheter le support d'un fournisseur est en fin de compte une décision commerciale que vous devrez prendre (ou conseiller la direction).

Pourquoi ne pas effectuer une mise à niveau sur place?

C'est ce que Red Hat en dit :

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

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

Ils avertissent en outre:

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

Les fichiers de configuration de package individuels peuvent ou peuvent ne pas fonctionner après avoir effectué une mise à niveau en raison de changements dans divers formats de fichier de configuration ou mises en page.

Si l'un des produits en couches de Red Hat (tels que Cluster Suite) est installé, il peut être 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 sûr, 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 car elle existe. Mais si quelque chose se passe mal, Red Hat vous demandera d'installer une nouvelle version; ils ne fourniront pas de support aux fournisseurs pour les éléments qui se cassent à la suite de 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 des packages renommés, des référentiels tiers et de la non-concordance de version occasionnelle entre les architectures i386 et x86_64 d'un package. L'installateur est un peu meilleur pour gérer ces derniers que yum, je pense.

Comment dois-je mettre à niveau?

Je préviens généralement les gens qu'ils doivent planifier sur une fenêtre de maintenance tous les 3-4 ans pour mettre à jour les systèmes RHEL d'une version majeure à l'autre. Bien que les mises à niveau se déroulent généralement sans heurts, l'inattendu peut toujours se produire.

Pour vos deux environnements, je m'attends à ce qu'une mise à niveau sur place fonctionne, bien que je recommande fortement de la tester d'abord en profondeur. 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 la production réelle sur la base d'une meilleure connaissance de ce qui se passera.

Pour un déploiement de grande envergure comme celui que vous avez ici, envisagez d'utiliser l'approche "un-un-plusieurs" de Limoncelli. Mettez à niveau une machine, voyez quels problèmes se produisent, 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 que tous les problèmes ont été résolus, mettez à niveau de grands lots d'entre eux.

À un moment comme celui-ci, je recommande également de jeter un long regard sur le processus de déploiement de votre application. 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 les développeurs doivent peut-être y travailler. Un tel processus de déploiement faciliterait considérablement la nouvelle installation de la nouvelle version d'EL, puis son déploiement.

Est-ce que changer de distribution sera utile?

Les distributions basées sur Debian ont une méthode de mise à niveau sur place prise en charge, et cela fonctionne principalement, mais elle n'est pas à l'abri des problèmes. Beaucoup de choses ont éclaté pour les gens mise à niveau d'Ubuntu 10.04 LTS vers 12.04 LTS via la méthode prise en charge, par exemple. Il n'est pas clair que Debian ou Canonical consacrent un temps de développement suffisant à "supporter" cette fonctionnalité, c'est-à-dire à s'assurer qu'elle fonctionne. Et vous devez toujours acheter le support du fournisseur 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 en passant à une distribution à diffusion continue telle que Gentoo ou Arch. Cependant, cela ne vous immunise pas non plus aux problèmes; cela signifie simplement que vous devez faire face aux problèmes de mise à niveau en continu pendant la durée de vie du serveur (par exemple, lorsque vous ou les développeurs décidez de mettre à jour quelque chose sur le système), plutôt que tout à la fois à un moment de mise à niveau de distribution bien planifié. Vous n'avez également aucun fournisseur pour fournir une assistance.

Que réserve l'avenir?

Le projet Fedora travaille sur un outil pour améliorer les mises à niveau sur place. Ils avaient un outil appelé preupgrade qui a été abandonné et remplacé par un nouvel outil appelé fedup commençant par Fedora 18 . Cela a été ajouté à RHEL7 et maintenant les mises à niveau sur place ont un support complet , au moins de RHEL 6 à RHEL 7 . D'après ma propre expérience, je peux dire que même si fedup a encore quelques défauts , il se présente comme un outil très utile.

CentOS expérimente également avec n type de référentiel à diffusion continue , mais il ne s'applique qu'entre versions mineures (par exemple 6.3-6.4).

Paul Gear · Answer

Mon point de vue sur votre dernier paragraphe:

Je suppose qu'il y a l'angle de gestion de la configuration, mais la plupart des installations de marionnettes que je vois ne se traduisent pas bien dans des environnements avec des serveurs d'applications hautement personnalisés (l'environnement B pourrait avoir un seul serveur dont la sortie ifconfig ressemble à ceci). Je serais intéressant d'entendre des suggestions sur la façon dont la gestion de la configuration peut être utilisée pour aider les organisations à surmonter le bump de la version majeure de RHEL.

Je pense que la vraie valeur des systèmes de gestion de configuration, en particulier dans le contexte de l'environnement B, est qu'ils fournissent les outils pour construire un service indépendamment des serveurs qui l'exécutent. Si un CMS n'a pas été utilisé pour créer les services existants, il n'aidera probablement pas beaucoup à recréer les services.

Je sais que cela ne résout pas votre problème immédiat, mais pour moi, cela découle de la pensée de l'organisation en termes de serveurs plutôt que de services. Dans la pensée axée sur les services, la personnalité des serveurs individuels n'a pas besoin d'être maintenue tant que le service continue de fonctionner. Si un CMS est utilisé de manière disciplinée pour créer l'intégralité du service, le déplacement de ce service vers un autre système devrait être relativement simple, car toute la personnalité de la machine sera créée par le CMS.

P.S. Je ne sais pas exactement ce qui est important à propos de la sortie ifconfig dans ce contexte - elle est produite par un fichier de configuration et certains scripts (sinon elle ne serait pas là au démarrage), et ceux-ci peuvent être gérés par un CMS, si nécessaire.