Mutualisation

La mutualisation est le fait de regrouper plusieurs services ou applications dans le but de réduire le nombre de plateformes physiques. Côté management, l’intérêt consiste à gagner en dépenses et, côté ingénierie, à susciter un gain d’administration mais également une perte de souplesse, car on ne peut plus arrêter une machine en impactant une seule application. Aussi il faut passer beaucoup plus de temps à observer les performances et s’assurer que chaque applications mutualisée bénéficie d’un niveau de performance adéquat.

 Situation initiale :

Seules 2 machines physiques hébergent chacune une seule application : l’une pour des raisons historiques car, à l’époque de la première installation, il faillait disposer d’une machine dédiée incluant des mises à jour sans réinstallation. La seconde machine héberge une application dédiée pour des raisons légales (transactions bancaires).

Le projet qui m’a été confié fut de déplacer la première de ces deux applications sur une autre machine existante (déjà en mutualisation) afin de réduire les coûts relatifs aux licences et maintenance de cette machine ‘unique’.

J’ai pris quelques jours pour identifier la machine cible parmi toutes celles (au nombre de sept) de notre production. L’une d’elle est rapidement sortie du lot car elle avait des ressources matérielles largement suffisantes et était aussi de la machine la moins chargée.

J’ai donc pris la décision que cette machine de production peu chargée et avec suffisamment de ressources accueillerait prochainement l’application actuellement hébergée sur la machine dédiée.

Mise en œuvre :

La première chose que j’ai faite à été d’observer les performances sur la machine initiale avec des outils standards Unix (comme vmstat, uptime, topas, iostat) afin d’avoir une estimation exacte. La conclusion fut que la consommation était de 40% du CPU de la machine et 35% de la RAM.

Côté CPU nous n’avons pas rencontré de problème car la machine cible possédait 9 CPU dont 3 non utilisés. Pour la mémoire il fallait ajouté 3G de RAM, ce qui fut fait dynamiquement et  immédiatement.

Le plus complexe a été le déplacement de données car plusieurs applications Unix possèdent de nombreux liens sur les fichiers dont des fichiers cachés, ce qui rend inutilisable la copie simple avec rsync ou scp. J’ai donc opté pour une autre solution.

L’application étant seule sur la machine initiale, j’ai ajouté 2 disques du SAN sur cette machine afin de créer un nouveau Volume Groupe puis, via AIX, j’ai copié l’intégralité des Volumes Logiques de cette application sur le nouveau Volume Groupe. Le plan a consisté à démonter le Volume Groupe et a le fermer au niveau d’AIX puis, au niveau du SAN, de « détacher » les nouveaux disques de la machine initiale, les lier à « l’initiator » de la nouvelle, puis à ajouter les disques dans le Storage Groupe.

 Déroulement :

Le jour J, un dimanche, j’ai arrêté cette application sans aucun soucis puis ai vérifié les process en cours d’exécution quitte à les terminer. Puis j’ai mis en place un fichier nologin empêchant tous les utilisateurs de se connecter sur cette machine. J’ai par la suite commencé à copier les Logical Volumes sur le nouveau Volume Groupe et là…Premier hic ! la copie est beaucoup plus longue que prévu : celle-ci était censée finir vers 10h et n’a pris fin que vers 13h.

La pression a commencé à monter.

Une fois les données sur le nouveau Volume Groupe, j’ai entrepris de fermer le Volume et de l’exporter niveau AIX (varyoffvg / exportvg). J’ai ensuite déplacé les disques au niveau du SAN afin qu’ils deviennent visibles sur la nouvelle machine dont voici un exemple des commandes passées.

Sur la nouvelle machine j’ai alors rafraîchi la configuration (cfgmgr) afin que les nouveaux disques soient pris en compte sans difficultés. Je suis donc passé aux étapes suivantes: importvg <nom du volume> puis <mount -a> afin d’importer les données et de monter les filesystèmes..

La pression est retombée peu à peu.

Manifestement tout s’est bien déroulé. J’ai donc exécuté un script de test de cette application : catastrophe ! En lisant les messages d’erreur, je constate beaucoup de ‘login failed’ ‘permission denied’ et fais immédiatement le lien avec le LDAP.

Tous nos utilisateurs sont dans un LDAP Apache qui, pour chacun, précise le nom de la machine à laquelle il a le droit de se connecter et ses droits. Le problème se situé ici. A l’aide de plusieurs commandes LDAP (chgroup -R LDAP xxxx), j’ai réussi à changer les attributs de plusieurs utilisateurs techniques qui servent à cette application. J’ai relancé le script de test et celui-ci s’est bien déroulé : j’ai décidé de démarrer l’application complètement avec un œil attentif sur les logs et tout s’est passé normalement.

Après plus d’une heure à tout vérifier, redémarrer l’application, lancer les scripts de test, j’ai contacté les quelques utilisateurs clefs qui étaient censés faire la recette du bon fonctionnement de l’application ce dimanche. A cet instant je me suis dis que la balle n’était plus dans mon camp et que je pouvais prendre le temps de me relaxer quelques minutes…! Malheureusement les utilisateurs clefs m’ont rapidement appelé pour m’informé qu’aucune donnée de leur application n’était visible, en somme qu’elles avaient disparu !!!

Une heure m’a été nécessaire pour faire un diagnostic pertinent. En réalité les données étaient disponible sur la machine : je n’avais aucun doute là-dessus mais je ne comprenais pas comment elles n’étaient pas visibles par les utilisateurs. Après avoir discuté avec eux, j’ai réalisé qu’ils utilisaient une page web pour recourir à l’application : après avoir fait l’inventaire de l’ex machine, je n’ai pas vu de serveur web et, pour cause, tous nos serveurs web sont hébergés sur la même machine mutualisée.

J’ai donc compris que les données de l’application étaient systématiquement exportées vers ces serveurs web mutualisés pour que les utilisateurs puissent y accédé (en utilisant /etc/exports). Aussi j’ai récupéré le fichier export de l’ex machine et l’ai implémenté sur la nouvelle machine en respectant l’existant. Cela a résolu le problème et la recette a été validée.

Conclusion :

Avec une préparation plus longue j’aurais pu identifier cet export de données et éviter une pression inutile. Cependant, d’après mon expérience il est quasiment impossible de « couvrir tous les angles » lors d’une opération complexe comme celle-ci. Même si le terme – improvisation – va à l’encontre de la tâche de l’ingénieur, dans les faits, c’est un phénomène régulier. Il est impossible de penser à tout, même si on y passe un temps infini.