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

Une demande simple de la part de deux clients dotés d' environnements complètement différents a incité ma réponse habituelle aux meilleures pratiques, à savoir «oui, mais cela nécessitera une reconstruction coordonnée 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 d'indisponibilité et de ressources ... Quand on m'a demandé pourquoi il était nécessaire de réinstaller complètement les systèmes, je n'avais pas une bonne réponse: "c'est comme ça ... "

Je n'essaie pas d'obtenir des réponses sur la gestion de la configuration (" Tout marionnettise " ne s'applique pas toujours ) ou sur la meilleure planification des clients. 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 clair pour passer à la prochaine version de leur système d'exploitation.

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

Environnement B:
société de négoce financier à haute fréquence avec 200 systèmes CentOS 5.x dans plusieurs installations de co-implantation menant des opérations de négociation en production, prenant en charge les fonctions de développement interne et de back-office. Les serveurs de négociation s'exécutent sur du matériel de serveur de base «bare metal». Ils ont de nombreux sysctl.conf, rtctl, interruption de liaison et quelques réglages du pilote en place pour réduire la latence de messagerie. Certains ont des noyaux personnalisés et / ou en temps réel. Les postes de travail des développeurs exécutent également une version similaire de CentOS.

Dans les deux cas, les environnements fonctionnent correctement tels quels. Le désir de mise à niveau découle du besoin d'une application ou d'une fonctionnalité plus récente disponible dans EL6.

• Pour l'entreprise à but non lucratif, cela est lié à Apache, au noyau et à certaines choses qui rendront les développeurs heureux.
• Dans la société de négoce, il s’agit d’améliorations apportées au noyau, à la pile réseau et à GLIBC, ce qui rendra les développeurs heureux.

Les deux sont des choses qui ne peuvent pas être facilement emballés ou mis à jour sans modifier radicalement le système d'exploitation .

En tant qu'ingénieur système, j'apprécie le fait que Red Hat recommande de procéder à une reconstruction complète pour passer d'une version majeure à une autre. Un début propre vous oblige à refactoriser et à faire attention aux configs en cours de route.

Étant sensible aux besoins professionnels des clients, je me demande pourquoi cette tâche doit être si lourde . Le système de packaging RPM est plus que capable de gérer les mises à niveau sur place, mais ce sont les petits détails qui vous /bootimportent : avoir besoin de plus d'espace, de nouveaux systèmes de fichiers par défaut, RPM pouvant éventuellement interrompre la mise à niveau, les packages obsolètes et obsolètes ...

Quelle est la réponse ici? Les 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 la bonne façon:

• Que doivent 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 à une reconstruction complète toutes les quelques années?
• Cela semble avoir empiré avec l'évolution de Enterprise Linux ... Ou est-ce que je viens de l'imaginer?
• Est-ce que cela a dissuadé quiconque d'utiliser Red Hat et les systèmes d'exploitation dérivés?

Je suppose qu'il y a un angle de gestion de la configuration, mais la plupart des installations de Puppet 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 ifconfigsortie ressemble à ceci ). Il serait intéressant d'entendre des suggestions sur la façon dont la gestion de la configuration peut être utilisée pour aider les organisations à traverser la bosse majeure de version de RHEL, cependant.

(Remarque 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, il convient de noter qu'il existe deux manières d'effectuer la mise à niveau sur place:

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

La méthode 1 est simplement non prise en charge. La méthode 2 concerne les vrais cow-boys. En plus des nouvelles installations recommandées, j'ai effectué ces deux ...

Ai-je besoin d'aide?

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 supporte SMTP"). La seconde est que le vendeur va vous en parler. La définition à laquelle on entend ne ressort pas toujours du contexte.

Pour accomplir une tâche, vous avez évidemment besoin d'un soutien au premier sens. Lorsque le support des fournisseurs intervient, il vous aide à résoudre les problèmes et vous donne des informations sur les fonctionnalités qui doivent exister ou être améliorées. De nombreux sites paient une fortune en support fournisseur lorsqu'ils disposent de l'expertise interne pour résoudre tout problème susceptible de survenir, plus rapidement et même moins cher que le fournisseur. L’achat d’une assistance fournisseur est en définitive une décision d’entreprise que vous devrez prendre (ou conseiller la direction).

Pourquoi ne pas faire une mise à niveau sur place?

Voici ce que Red Hat en dit :

Red Hat ne prend pas en charge les mises à niveau sur place entre les versions principales 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 deux versions majeures de Red Hat Enterprise Linux.

Les mises à niveau sur place des principales versions ne préservent pas tous les paramètres du système, services ou configurations personnalisées. En conséquence, Red Hat recommande vivement de nouvelles installations lors de la mise à niveau d’une version majeure à une autre.

Ils avertissent en outre:

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

• Les fichiers de configuration de packages individuels peuvent ou ne peuvent pas fonctionner après une mise à niveau en raison de modifications apportées à divers formats de fichiers de configuration ou dispositions.
• Si l'un des produits en couches de Red Hat (tel que la suite de clusters) 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, juste au cas où vous voudriez vraiment le faire. La fonctionnalité existe et Red Hat y met 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 demandera d’installer une nouvelle version. ils ne fourniront aucune assistance aux fournisseurs pour les problèmes causés par 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 packages renommés, de référentiels tiers et de différences de version occasionnelles entre les architectures i386 et x86_64 d'un package. L'installateur est un peu mieux à gérer que yum, je pense.

Comment dois-je mettre à niveau?

Je préviens généralement les utilisateurs qu'ils doivent prévoir une fenêtre de maintenance tous les 3-4 ans pour mettre à jour les systèmes RHEL d'une version majeure à la suivante. Bien que les mises à niveau se déroulent généralement sans heurts, des imprévus peuvent toujours se produire.

Je m'attends à ce qu'une mise à niveau sur place fonctionne correctement pour vos deux environnements, bien que je vous recommande fortement de la tester en premier. 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 va se passer.

Pour un déploiement de grande envergure comme celui que vous avez ici, envisagez d'utiliser l'approche "un-plusieurs-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 avoir résolu tous les problèmes, mettez-les à niveau, et mettez-les à jour.

À un moment pareil, je vous recommande également de jeter un regard long sur le processus de déploiement de vos applications. S'il n'est pas suffisamment automatisé pour que vous puissiez démarrer avec une seule commande et être raisonnablement sûr que l'application sera déployée correctement, les développeurs doivent peut-être se mettre au travail. Un tel processus de déploiement faciliterait grandement la nouvelle installation de la nouvelle version d’EL, puis son déploiement.

Est-ce que changer de distribution vous aidera?

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

Vous pouvez gagner en optant pour une distribution à publication continue telle que Gentoo ou Arch. Cependant, cela ne vous protège pas non plus des problèmes; cela signifie simplement que vous devez faire face aux problèmes de mise à niveau de façon continue tout au long de la 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 que tout à la fois à un moment de mise à niveau de la distribution bien planifié. Vous n'avez également aucun fournisseur à fournir un soutien.

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é preupgradequi a été abandonné et remplacé par un nouvel outil appelé fedup commençant par Fedora 18 . Cela a été ajouté à RHEL7 et les mises à niveau sur place prennent désormais en charge toutes les versions , du moins de RHEL 6 à RHEL 7 . D'après ma propre expérience, je peux dire que, même s'il a fedupencore quelques problèmes , il est en train de devenir un outil très utile.

CentOS expérimente également un type de référentiel à version progressive, mais il ne s'applique qu'entre les versions mineures (par exemple, 6.3 à 6.4).

Mon point de vue sur votre dernier paragraphe:

Je suppose qu'il y a un angle de gestion de la configuration, mais la plupart des installations de Puppet 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). Il serait intéressant d'entendre des suggestions sur la façon dont la gestion de la configuration peut être utilisée pour aider les organisations à traverser la bosse majeure des versions de RHEL, cependant.

Je pense que la véritable valeur des systèmes de gestion de la configuration, en particulier dans le contexte de l'environnement B, est qu'ils fournissent les outils nécessaires à la construction d'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 ne vous 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 provient de la pensée de l'organisation en termes de serveurs plutôt que de services. Dans la pensée centrée sur le service, il n'est pas nécessaire de préserver la personnalité des serveurs individuels tant que le service continue de fonctionner. Si un CMS est utilisé de manière disciplinée pour créer l'ensemble du service, le transfert de ce service vers un autre système doit être relativement simple, car toute la personnalité de la machine sera créée par le CMS.

PS: je ne suis pas tout à fait sûr de la signification de la sortie d'ifconfig dans ce contexte: elle est produite par un fichier de configuration et des scripts (sinon, elle ne serait pas disponible au démarrage), et ceux-ci peuvent être gérés par un CMS, si nécessaire.