Un meilleur dimensionnement des applications et des infrastructures
Publié par La rédaction le | Mis à jour le
Sébastien Truttet, directeur opérationnel et cofondateur de Nadra Technologies, nous propose sa vision d'expert sur les 4 évolutions majeures à prendre en compte pour un meilleur dimensionnement des applications et des infrastructures.
C'est enfoncer une porte ouverte de dire qu'aujourd'hui toutes les entreprises s'orientent vers la virtualisation pour la mise en place de la plupart de leurs applications. Cette consolidation de serveurs a également entrainé la consolidation du stockage et des réseaux, technologies réservées auparavant à quelques applications intensives. Le marché a été investi rapidement parce que les technologies sont fiables et que le ROI est généralement très rapide. Ce dernier point est capital. La question que l'on peut se poser est : « L'adoption de ces technologies n'a-t-elle pas été plus rapide que notre capacité d'adaptation aux changements ? »
En effet, si l'on convient que ces transformations technologiques ont un impact majeur sur les compétences des équipes IT, les conséquences d'une défaillance, la qualité du service rendu aux utilisateurs ou encore les possibilités techniques, alors pourquoi aujourd'hui le dimensionnement d'une infrastructure applicative s'aborde encore très souvent comme en environnement physique ?
Pendant des années, les applications ont été dimensionnées avec des ressources dédiées. Tous les raisonnements (architecture, diagnostique, surveillance, etc.) sont encore fortement attachés à cette logique. Et pourtant, les règles sont différentes désormais. L'ensemble du matériel est partagé à un ensemble de serveurs virtuels. Il ne faut donc plus uniquement dimensionner les applications mais également cette infrastructure mutualisée.
L'évolution des processeurs
Depuis 20 ans, l'évolution a été importante dans ce domaine avec l'apparition d'instructions qui peuvent traiter en même temps plusieurs jeux de données, de l'hyper-threading (des instructions qui s'exécutent en même temps dans le même espace mémoire), du multi-cour (plusieurs canaux d'instructions qui s'exécutent en même temps chacun dans leur espace mémoire) ou de l'augmentation des fréquences (interne, bus et mémoire processeur). Connaître la fréquence d'un processeur importe peu puisque les facteurs de performance sont ailleurs. Un processeur de fréquence moindre peut parfaitement être plus performant qu'un processeur à fréquence plus élevée. Dans ce contexte, à quoi correspond un processeur virtuel ? Généralement un hyperviseur scinde les processeurs physiques en processeurs virtuels en considérant que l'hyper-threading double le nombre de processeurs et que chaque cour est un processeur à part entière.
Prenons l'exemple d'un hyperviseur muni de deux processeurs quad cour hyperthreadés : cela correspond à 16 processeurs virtuels (deux processeurs x 2 pour l'hyperthreading x 4 cours). Tant que l'hyperviseur gère des serveurs virtuels demandant moins de processeurs virtuels dont il ne dispose, l'allocation est statique. Cela signifie qu'un serveur virtuel mono processeur qui est exécuté seul sur un hyperviseur ne peut utiliser toute la puissance (1/16ème dans le cas de notre exemple). Quand l'hyperviseur doit « fournir » plus de processeurs virtuels qu'il n'en a la capacité, un ordonnanceur se charge de la ventilation des ressources selon les demandes. Ce principe implique beaucoup de conséquences.
L'allocation de la mémoire des serveurs virtuels
Le second changement majeur est l'allocation mémoire. Il est peut être bon de rappeler que lorsqu'un serveur virtuel utilise toute la mémoire qui lui a été affectée, alors il utilise son fichier d'échange (swap, mémoire virtuelle). Même si l'hyperviseur dispose de plus de mémoire, les spécifications du serveur virtuel sont statiques. L'hyperviseur ne réserve pas sa mémoire au démarrage à l'ensemble de la mémoire qui a été affectée aux serveurs virtuels. Il la distribue à la demande dans la limite du dimensionnement du serveur virtuel. Si un serveur virtuel n'utilise pas la totalité de la mémoire à laquelle il a droit alors l'hyperviseur la conserve.
A partir de ce principe, il est possible d'exécuter sur un hyperviseur des serveurs virtuels dont le cumul de besoin mémoire est supérieur à la capacité de cet hyperviseur. Que se passe-t-il dans ce cas de figure ? Tant que les serveurs virtuels ne demandent pas la totalité de la mémoire auxquels ils ont droit, il n'y a aucune conséquence. Dans le cas contraire l'hyperviseur active différents mécanismes de sur-allocation mémoire. Le premier consiste en une récupération de la mémoire non utilisée sur l'ensemble des serveurs virtuels. Cela s'appelle le « balooning » sur vSphere de l'éditeur VMware. Le second mécanisme est un partage de pages mémoire identiques entre serveurs virtuels. Et le troisième est une compression à la volée de la mémoire des serveurs virtuels. Le dernier mécanisme est la création d'un fichier d'échange sur l'hyperviseur (swap, mémoire virtuelle). La mémoire des serveurs virtuels concernés devient alors un fichier sur disque. Les performances se dégradent fortement.
La mutualisation des disques
C'est un troisième changement profond. Nous connaissons pour la plupart des règles de type : un disque 10 000 tours par minute fournit une performance de 130 I/O par seconde, un disque 15 000 tours par minute fournit une performance de 180 I/O par seconde et le type de RAID influe sur les performances disques agrégés. Cela reste valable dans une certaine mesure mais d'autres paramètres entrent en ligne de compte. Ces disques ne sont plus locaux mais déplacés dans une baie de stockage qui embarque ses technologies de cache et de traitement de données afin de maximiser les performances des supports magnétiques. Chaque constructeur propose des baies et des performances bien différentes. Ensuite, ce stockage est souvent accessible à travers un réseau (iSCSI, Fiber Channel, etc.), ce qui amène à prendre en compte l'architecture du réseau.
Enfin ce « matériel » est accédé par plusieurs serveurs virtuels au même moment. Les performances sont partagées. Dans le cas du Cloud public, les performances IOPS ne sont même pas communiquées. Alors calculer combien de disques sont nécessaires, dans quel format et avec quel type de RAID pour dimensionner un serveur n'est plus adapté. La notion de classe de service de stockage apparait et le suivi de quelques indicateurs clés permet de s'assurer que l'infrastructure fournit le niveau de performances attendues.
Les changements relatifs au réseau
Dans le prolongement des changements liés au stockage, il y a ceux relatifs au réseau. S'il est vrai que l'hyperviseur mutualise ses interfaces réseau pour les serveurs virtuels qu'il exécute, il n'en demeure pas moins que les principes de base du réseau (modèle OSI) s'appliquent. Dans une trame IP, il y a une adresse matérielle (MAC) qui alimente des tables de routage sur les équipements réseau. Les hyperviseurs y sont connectés physiquement. Même si un hyperviseur est équipé de plusieurs cartes réseau, la carte réseau d'un serveur virtuel n'utilisera toujours qu'une seule de ces cartes (ou alors il faut utiliser des protocoles d'agrégation parfois complexes à mettre en ouvre). La répartition des flux réseau des serveurs virtuels sur les cartes réseau des serveurs virtuels est généralement statique (filtre par masque sur adresse MAC par exemple). Plusieurs serveurs virtuels peuvent donc se partager une seule carte physique, donc se partager la bande passante.
Ces quatre éléments de base modifient en profondeur l'approche du dimensionnement d'une infrastructure et sa gestion au quotidien. Le Cloud, qui prend de plus en plus d'ampleur, rendra encore un peu plus caduque l'approche matérielle. En effet, les fournisseurs ne communiquent pas sur la définition du socle (type de processeurs, espace mémoire, performances disques, bande passante hyperviseur, etc.) et d'ailleurs ça n'est pas ce qui est important.
Alors comment fait-on pour dimensionner son infrastructure et ses applications ? Comment peut-on garantir un service de qualité à ses utilisateurs ? Le suivi d'indicateurs clés au sein des serveurs virtuels, au travers de la métrologie, permet de tirer tous les bénéfices de l'abstraction du socle matériel. La présentation de ces indicateurs fera l'objet d'un prochain avis d'expert.
Voir aussi
Silicon.fr étend son site dédié à l'emploi IT
Silicon.fr en direct sur les smartphones et tablettes