mercredi 1 avril 2009

Les machines virtuelles en exploitation


Y en a mare des discours marketing qui incitent les développeurs à faire n'importe quoi. Et ils s'y précipitent sans recul, avec la certitude d'avoir fait les bons choix, alors qu'ils ne font que suivre des discours lénifiants. Où sont les petits artisans qui façonnent un code avec de bons produits, qui réfléchissent avant d'agir ?

Parmi les nombreux sujets me hérissant les poils, il y a l'utilisation de machines virtuelles pour résoudre tous les problèmes de production. Mais où va t'on ?

Initialement, il y avait des systèmes d'exploitations minimalistes n'offrant en gros, qu'un accès à des fichiers. Puis sont venu des systèmes multi-tâches permettant à plusieurs applications de fonctionner ensemble. Qu'elle drôle d'idée ! Chacun sait que le dogme actuelle en déploiement est « une application égale un serveur ». Et oui, grande nouvelle, les systèmes multi-tâches savent gérer plusieurs applications en même temps. Donc, en déploiement, pour mutualiser les ressources, la meilleure approche est d'installer plusieurs applications dans le même système d'exploitation.

Avec l'avènement du Net, il a fallu accepter de très nombreux utilisateurs en mêmes temps pour la même application. Des serveurs d'applications ont été conçus pour différentes technologies : .Net, Java, Php, etc. Ces serveurs ont vocation à accueillir différentes applications gérées par le même serveur. Pour permettre cette mutualisation, des serveurs comme Apache acceptent d'avoir plusieurs noms : les virtuals hosts. Ainsi, le même serveur peut accueillir différentes applications, pour différents sites et cela dans le même programme ! Grande nouvelle, il y a bien un s à serveur d'applications. Donc, même si le système d'exploitation sait gérer plusieurs applications en même temps, il est généralement suffisant d'avoir un seul applicatif coté serveur pour mutualiser les ressources.

Parfois, ce n'est pas possible. Par exemple, si le serveur d'applications utilise une gestion des ressources paraisseuse. La mémoire qui n'est plus nécessaire n'est pas libérée immédiatement, mais plus tard, lorsqu'un ramasse miette le juge nécessaire. Dans ce type d'architecture, mutualiser toutes les applications dans le même serveur d'applications peut entrainer une exigence plus importante de la mémoire et donc un temps de nettoyage des ressources trop important.

Qu'a cela ne tienne. Comme le système d'exploitation sais gérer plusieurs applications en même temps, il n'y a qu'a lancer plusieurs instances de serveurs d'applications avec un partage de la mémoire. Ainsi, deux nettoyages pourront s'effectuer en même temps, mais sur un volume de mémoire moins important pour chacun.

Il est donc possible de mutualiser à plusieurs niveaux : dans un serveur d'applications ou dans le système d'exploitation.

Oui mais voilà que les machines virtuelles pointent leurs nez en production. Pour ne pas remettre en cause le dogme débile : « une application égale un serveur », les marketeurs proposent d'utiliser des machines virtuelles. Ainsi, chaque application possède son propre système d'exploitation et son propre serveur d'applications. Vous souhaitez mutualiser les ressources ? Ajoutez une machine virtuelle ! (on oublie de vous dire qu'il faut également ajouter un autre système d'exploitation et un autre serveur d'applications). Et on fait quoi du dogme ? On s'assoit dessus sans le dire, car il y a bien physiquement plusieurs applications dans le même serveur, non ?

Bonjours le nombre de couches ! Pour chaque application, nous avons : un serveur d'applications qui a perdu son 's' car il ne gère plus qu'une seule et unique application ; un système d'exploitation qui ne sert franchement pas à grand chose, car il ne doit plus gérer qu'un seul processus ; un noyau de virtualisation hébergé ou non dans un autre système d'exploitation, qui se charge d'isoler les applications les unes des autres.

Isoler quoi ? Uniquement l'accès mémoire. Les machines virtuelles n'isolent pas le réseau, la consommation CPU, la place disque, etc. L'isolation mémoire est-elle vraiment nécessaire ? Les systèmes d'exploitations n'exploitent-ils justement pas la mémoire virtuelle des microprocesseurs pour cela ? Avec une machine virtuelle, on isole un isolant. Quelle riche idée !

  • Et c'est mieux ?

  • Oui, oui, madame Michu. Du moment que cela vous coûte plus cher.

À force d'ajouter des couches au bébé, ce dernier n'est pas prêt de marcher. Tout nu, il fera ces premiers pas. Avec trop de couches, il sait faire le grand écart, mais cela ne lui sert à rien. Un peu de bon sens que diable !

Puis, n'ayant pas saisi les vraies raisons motivant d'utiliser une technologie plutôt qu'une autre, le développeur va faire preuve de prouesses dans le grand n'importe quoi. Par exemple, et cela se rencontre dans la vraie vie, deux machines virtuelles seront installées sur le même nœud physique afin d'avoir de la tolérance aux pannes. Ah bon ? Quelles pannes ? Le plantage d'un serveur d'applications ? Pourquoi pas. Mais cela règle vraiment le problème ? Un chien de garde n'est pas suffisant ? Et que se passe-t'il si le disque du nœud plante ? Et bien toutes les machines virtuelles sont instantanément hors circuit. Que se passe-t'il si un des nœuds a son réseau planté ou qu'il est attaqué par déni de services ? Toutes les machines virtuelles sont mortes. Paix à leur âmes... Qui peut me donner un seul argument justifiant cette architecture ? J'entends par là, prouvez moi qu'il n'existe pas une autre solution plus économe en ressource.

À quoi servent vraiment les machines virtuelles ? Voilà la question qu'il faut se poser. Et non : « comment ça fonctionne ». Un bon artisan se pose les bonnes questions et ne cherche pas à ajouter une ligne à son CV : « j'ai mis en place des machines virtuelles ».

Les machines virtuelles servent essentiellement en phase de développement. Elles permettent un retour arrière lors des installations, permettent à chaque développeur de simuler des architectures complexes, facilite les tests de portabilité entres systèmes d'exploitations hétérogènes, etc.

En production, elles permettent une mutualisation des ressources, si et seulement si, chaque instance utilise un système d'exploitation différent. Il n'y a pas d'autre solution pour marier sur le même serveur, une application exigeant Windows et une autre exigeant Linux que d'utiliser des machines virtuelles. Mais avec deux Windows ou deux Linux, n'y a-t'il vraiment pas d'autres solutions ?

Parfois, les machines virtuelles migrent dynamiquement d'un nœud à l'autre, le soir par exemple, afin de pouvoir éteindre physiquement certains serveurs. Il faut par exemple dix serveurs en charge nominale, mais que deux serveurs dans les périodes creuses. Dans ce cas, quel est l'intérêt, le soir, de distribuer dynamiquement dix machines virtuelles sur deux nœuds ? De toutes façons les deux nœuds ne savent pas tenir la charge des dix machines virtuelles. Elles sont donc sous utilisées. N'est-il pas plus judicieux de paramétrer dynamiquement le répartiteur de charge pour lui dire de n'envoyer les requêtes que sur deux nœuds et d'oublier les autres ? Quelques lignes de scripts suffises, mais c'est moins sexy. Cela ne ressort pas pareil sur un CV.

Souvent, par crainte d'affronter les projets pour leurs imposer de mutualiser les ressources dans le même système d'exploitation, les exploitants utilisent des machines virtuelles. C'est un marché de dupes. De qui se moque t'on ? Les ressources sont bien partagées, mais à l'insu du projet. La bonne affaire. On ajoute une couche « système d'exploitation » pour rien, uniquement parce que les développeurs ne savent pas travailler dans le respect du système d'exploitation d'accueil. Qu'ils retournent à leurs fourneaux. C'est leurs jobs que diable ! On ne sait plus écrire un code qui partage le système d'exploitation ?

Parfois, il faut ajuster le système d'exploitation pour les besoins spécifiques d'une application. Le paramétrer de manière particulière. Est-ce que ces ajustements sont incompatibles avec une autre application ? C'est très rarement le cas.

Maintenant, nous arrivons à une évolution naturelle de ces usages : « pourquoi ne pas se passer du système d'exploitation ? » C'est en effet, une bonne question. Certains serveurs d'applications savent se passer de système d'exploitation pour dialoguer directement avec le noyau de virtualisation. D'autres utilisent un noyau Linux minimaliste pour faire la même chose. CQFD.

Le système d'exploitation du futur est la virtualisation. On gagne quoi dans l'affaire ? Rien. On croit résoudre un problème en changeant le nom d'une couche. Il faut arrêter de se leurrer. La virtualisation n'est pas une fin en soi. C'est un moyen de dernier ressort. À n'utiliser que s'il n'existe pas d'autres solutions. Il faut démontrer qu'il n'est pas possible de mutualiser les ressources dans le serveur d'applications, puis dans le système d'exploitation avant d'envisager d'utiliser la virtualisation en production.

Le nombre de couches à traverser pour effectuer un traitement basique est de plus en plus prodigieux. Il faut alors multiplier le nombre de serveurs pour finalement pas grand chose à l'arrivée. Alors que certains gèrent 150 hits par secondes avec deux serveurs, d'autres doivent utiliser 6 serveurs pour obtenir les mêmes résultats. Quelle approche faut-il utiliser ? La plus économe, la plus écologique, ou la plus hype et séduisante sur un CV ?

Les mêmes travers ont été constatés au fil des années, avec l'utilisation des EJB en Java/JEE : « c'est très bien, il faut absolument les utiliser, cela réglera tous vos problèmes », puis plus tard, les mêmes de sermonner : « voyez comme les EJBs ne sont pas efficaces, utilisez maintenant les EJB3 ou les bons vieux objets Java ». On nous présente maintenant les POJO (Plain Old Java Object) comme une nouveauté ! On marche sur la tête. Ceux qui n'ont jamais quitté les objets Java simples, étaient « has been » auparavant et deviennent subitement « in » désormais. Cycle éternel de l'informatique.

L'histoire est un éternel recommencement, dans quelques années, on nous expliquera que les machines virtuelles doivent remplacer les systèmes d'exploitations, puis que finalement, un système d'exploitation bien paramétré est largement suffisant et tellement plus simple à administrer.

À quand une charte de qualité environnement pour les projets informatiques ? Il faut exiger une consommation de ressources minimum dans les appels d'offres. Valoriser les améliorations du code permettant de libérer un des serveur du parc informatique et ainsi contribuer à sauver la planète.

Parce qu'y'en a marre de la médiocrité, des développeurs en batteries et de la disparition des petits artisans soucieux du travail bien fait.

Jean-Pierre Troll

jp.troll(at)gmail.com (parce que j'ai bien qu'on référence ma vie privée)

1 commentaire: