"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 /boot
importent : 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 ifconfig
sortie 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.
upgradeany
paramètre de démarrage, oui? Je l'ai testé deux fois, une fois sur une installation C5 propre où tout fonctionnait bien. une fois sur une (copie de test) un ancien cruel "était C4 et a été mis à jour" installer là où il a échoué de façon spectaculaire.
*-release files
etc.). Mais les questions des clients de cette semaine m'ont amené à réfléchir davantage à la manière dont un environnement peut devenir enraciné avec une version spécifique, sans aucune issue.
yum
, ce qui a fonctionné pour moi la plupart du temps. Mon seul espoir est que RH ait pris un sacré coup de baton chez ses clients payants pour leur décision de ne pas avoir de chemin de mise à niveau pris en charge 5-> 6, et le repensera pour 6-> 7.