Linux existe depuis un certain temps maintenant. Initialement créé par Linus Torvalds en 1991, il est devenu un acteur majeur du paysage des systèmes d'exploitation pour serveurs (OS), aux côtés de Windows et des principales distributions Unix. Bien qu'il n'y ait rien de mal en soi avec Unix, il est devenu plutôt "long dans la dent" et il y a une tendance croissante à migrer d'Unix vers Linux.
Alors pourquoi migrer ?
Si vous êtes administrateur d'un centre de données existant (que ce soit sur site ou dans une installation de colocation), en particulier celui qui existe depuis longtemps, il y a de fortes chances que vous ayez une certaine saveur commerciale d'Unix en cours d'exécution. Ceux-ci nécessitent généralement du matériel propriétaire, et bien que cela puisse fonctionner sans problème, il existe des défis pour maintenir ces environnements hérités. Le plus grand de ces défis auxquels la haute direction pourrait être confrontée est les coûts de support à la fois pour le matériel et le système d'exploitation lui-même. De plus, les extensions peuvent être de plus en plus difficiles à faire, car le matériel hérité est obsolète et les pièces peuvent être difficiles à trouver et, une fois trouvées, peuvent être coûteuses (oh, l'offre et la demande, vous êtes une maîtresse si dure !).
Quelque chose qui peut survenir au cours de cette transition est la possibilité que vous découvriez une application qui ne peut pas être migrée. Peut-être que le fournisseur a fait faillite ou n'a pas porté l'application sur Linux. Peut-être qu'ils l'ont fait, mais cela nécessiterait une implication directe du fournisseur dans un engagement professionnel qui coûte trop cher. Si cela se produit, vous devrez peut-être voir si vous pouvez migrer la charge de travail vers une nouvelle application prise en charge sur Linux ou envisager de conserver ce serveur hérité particulier.
Un autre problème lié au fait de rester sur des systèmes Unix hérités est l'impossibilité de virtualiser. Bien qu'il existe une certaine virtualisation dans quelques environnements Unix, les hyperviseurs modernes offrent beaucoup plus de fonctionnalités et de flexibilité, si vous pouvez passer à un système d'exploitation pris en charge par l'hyperviseur que vous avez choisi.
Ok, donc je vais migrer, comment dois-je commencer ?
Le succès d'une migration d'Unix vers Linux commence par une solide enquête. Il y a plusieurs choses sur lesquelles se concentrer. Il y a deux façons d'aborder cela, et j'ai trouvé qu'un hybride des deux peut donner les meilleurs résultats. Les deux approches, telles que je les ai vues, sont "ascendantes" et "descendantes". Ces phrases sont courantes et assez faciles à appliquer ici.
Pour l'approche ascendante, vous commencez au niveau du système d'exploitation. Commencez par vérifier le système d'exploitation et la version actuels. Identifiez les packages, modules ou logiciels supplémentaires installés auprès du fournisseur du système d'exploitation. Ensuite, recherchez les logiciels tiers, en capturant le fournisseur et la version que vous utilisez. La dernière chose est tout logiciel maison que vous pourriez avoir, y compris non seulement les programmes écrits dans un langage formel comme C (ou l'un de ses descendants) ou Java , mais aussi des scripts écrits dans l'un des langages shell courants (sh , ksh , csh ) ou des langages interprétés comme PERL , Python , etc.
Un autre endroit à regarder est le cron planificateur. Tout ce qui y est programmé, qu'il soit fourni par le fournisseur ou développé en interne, est quelque chose que vous souhaitez passer plus de temps à tester.
L'approche descendante peut être plus difficile, car elle implique de commencer par les utilisateurs finaux et de découvrir d'eux ce qu'ils exécutent sur le système. Cette approche peut être une expérience éprouvante, car les utilisateurs ne comprennent pas toujours comment quelque chose fonctionne, juste comment ils l'utilisent. Par exemple, un utilisateur peut savoir qu'il utilise un site Web, mais ne pas savoir que "sous le capot" est Apache ou Tomcat , qu'il ait ou non un CGI scripts et si oui, dans quelle langue ils sont. Cependant, des informations supplémentaires peuvent être glanées, comme découvrir qu'un serveur que vous pensiez être plus ou moins autonome est étroitement lié à un autre, et que vous devrez migrer les deux à en même temps.
Ma préférence est de faire les deux... J'essaierai de trouver qui dirige les utilisateurs professionnels d'un système particulier et je les rencontrerai pour savoir à quoi ils l'utilisent. J'essaierai également de faire correspondre les fonctionnalités qu'ils utilisent avec des composants système identifiables. Un exemple serait un serveur Web. Est-ce un serveur statique ou dynamique ? Vous ne le verrez peut-être pas en examinant les packages installés sur le serveur. Pourtant, un entretien avec un utilisateur peut vous dire que le site est basé sur WordPress , ce qui signifie que vous devez trouver la base de données qui la pilote, qu'elle se trouve sur le même serveur ou peut-être sur un autre qui devra peut-être migrer en même temps.
Ok, maintenant je sais ce qui est en cours d'exécution, et ensuite ?
Vous devez décider vers quelle distribution Linux vous allez migrer. Beaucoup de choses entrent en ligne de compte dans cette décision, qui devrait franchement être un article de blog à part entière. Pour l'instant, ce que je vais souligner, c'est que vous devez examiner les fonctionnalités en jeu sur le serveur et découvrir quelles distributions prennent en charge ces mêmes fonctionnalités. Si, par exemple, le serveur est un simple serveur Web ou FTP, à peu près n'importe quel Linux suffira. Si vous avez un logiciel tiers en cours d'exécution, le fournisseur peut ne prendre en charge que certaines distributions, vous pouvez donc commencer par ce logiciel, puis affiner à partir de là.
Une fois que vous avez sélectionné votre distribution, créez vous-même un environnement de développement, installez le système d'exploitation de base et les packages nécessaires, les logiciels tiers, etc. Configurez les utilisateurs pour les tests et copiez leurs programmes et scripts, ou assurez-vous qu'ils peuvent le faire.
Tout va fonctionner, n'est-ce pas ?
Dans un monde parfait, ce serait vrai. Cependant, nous savons tous que le monde n'est pas parfait. Les fonctionnalités fournies par le système d'exploitation fonctionnent généralement comme prévu. Si vous sautez dans les versions pour quelque chose comme Apache, il peut y avoir des différences dans la façon de le configurer pour que votre site Web fonctionne de la même manière. La documentation vous aide généralement à y arriver. Les logiciels tiers peuvent parfois avoir plus de problèmes. Si vous devez les gérer, assurez-vous d'avoir confirmé les niveaux de version du système d'exploitation. Un fournisseur avec lequel j'ai traité prend en charge RHEL 6, mais pas RHEL 7. Parfois, ils n'ont peut-être testé qu'une certaine version ponctuelle et prennent en charge jusqu'à cela mais pas au-delà, comme la prise en charge de RHEL 6.4 mais pas de RHEL 6.10. Il peut également y avoir des problèmes si vous avez installé une version 64 bits du système d'exploitation, mais que le fournisseur tiers n'a testé que sur une installation 32 bits.
Les logiciels et les scripts maison sont une autre affaire. Vous êtes presque assuré d'avoir des problèmes là-bas, cela dépend beaucoup de qui a écrit le code et de sa complexité. Les langages formels peuvent être transférés plus facilement, tant que le système d'exploitation Linux dispose des bonnes bibliothèques pour prendre en charge la compilation.
Il pourrait y avoir des problèmes si vous utilisiez une version plus ancienne d'Unix, car les choses peuvent avoir changé dans la langue. Certaines valeurs par défaut peuvent avoir changé et les options des appels de fonction, en particulier les appels système, peuvent être différentes. La recommandation est de faire les premières compilations de code avec la plus grande quantité de débogage que vous pouvez activer, puis une fois que vous avez résolu les problèmes, recompilez avec ce débogage désactivé pour économiser sur la charge du serveur à l'avenir.
Pour les scripts, la même chose est vraie, mais avec une plus grande chance de changements impairs. L'expérience personnelle a montré que le shell standard (alias sh ) les scripts s'exécutent généralement sous Bourne Again Shell (alias bash ). Pourtant, il peut y avoir des pièges cachés qui ne généreront pas réellement d'erreur, mais ne produiront pas les résultats attendus. Un exemple clé est cet extrait de code que j'ai beaucoup utilisé à l'époque de HPUX :
cat datafile.txt | while read line ; do
set - $line
var1 = $1
if [ $var1 = “yes” ] ; then saved_value = “$2”
done
echo “$saved_value”
Sous HPUX, cela a bien fonctionné. Sous bash dans RHEL, la variable $saved_value serait vide, en raison de la façon dont ce shell faisait la portée par rapport à la façon dont HPUX l'a fait. J'ai dû changer ce qui précède en quelque chose comme ceci :
while read line ; do
set - $line
var1 = $1
if [ $var1 = “yes” ] ; then saved_value = “$2”
done < datafile.txt
echo “$saved_value” Il est donc important de faire des exécutions côte à côte entre l'ancien système et le nouveau pour vérifier que la même entrée dans un script crée la même sortie sur les deux systèmes.
Ok, nous avons tout testé, et maintenant ?
L'étape réelle de la transition de l'ancien système vers le nouveau peut varier considérablement en complexité, en fonction de votre environnement. Pour que le sujet soit vraiment bien traité, il devrait avoir son propre blog. Après avoir effectué votre migration, un post-mortem est pratique, surtout si vous avez des migrations supplémentaires à faire. Un examen approfondi de ce qui a fonctionné et de ce qui n'a pas si bien fonctionné peut générer des "leçons apprises" utiles à appliquer à votre prochain projet de migration.
Conclusion
J'espère que cet article a aidé à mettre en évidence les types de choses à rechercher, les conversations à avoir, les plans à établir et vous a donné une longueur d'avance sur votre voyage vers les migrations Unix vers Linux. Espérons qu'avec les éléments que vous retenez de cet article et un peu de chance, vous aurez une transition relativement fluide.
[ Voulez-vous essayer Red Hat Enterprise Linux ? Télécharge le maintenant gratuitement. ]