A travers cet avis d’expert publié sur le site des décideurs IT www.silicon.fr découvrez les 4 évolutions majeures induites par la Cloud, la virtualisation et la consolidation des infrastructures.
Introduction
C’est enfoncer une porte ouverte que de dire qu’aujourd’hui toutes les entreprises s’orientent vers la virtualisation pour la mise en place de la plupart des nouvelles applications. L’offre est vaste, que ça soit On Premise ou dans le Cloud. D’ailleurs cette consolidation de serveurs a entrainé la généralisation de la consolidation du stockage et des réseaux également, technologies réservées jusque-là à 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 « est-ce que l’adoption de ces technologies n’a pas été plus rapide que notre capacité d’adaptation aux changements ? ». Pourquoi cette question ? 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 finalement le dimensionnement d’une infrastructure applicative s’aborde encore très souvent comme en environnement physique ? Regardez : vos serveurs virtuels n’ont-ils pas toujours une mémoire multiple de 256 Mo ? Pourtant la mémoire peut s’allouer au Mo près pour éviter le « gaspillage » des ressources physiques. N’appliquez-vous pas les recommandations (physique) des éditeurs pour définir le nombre de processeurs ? Pourtant un processeur virtuel est totalement différent d’un processeur physique : pas de core, pas d’hyperthreading. Ce ne sont là que deux exemples, il y en a bien d’autres. Cela pourrait être plus cohérent pour tirer plus de bénéfices du Cloud (privé, public ou hybride).
Je vais ici attirer votre attention sur quelques éléments de dimensionnement et de suivi d’une infrastructure « virtuelle ». Ce sont ces principes de base qui ont notamment permis à un Client de doubler les performances de son application tout en divisant par quatre le coût de son infrastructure.
De nouvelles règles
Pendant des années les applications ont été dimensionnées avec des ressources dédiées. Tous les raisonnements (architecture, diagnostique, surveillance, …) sont encore fortement attachés à ça. Et pourtant les règles sont différentes désormais. L’ensemble du matériel est partagé à un ensemble de serveurs virtuels. Il ne suffit donc plus de dimensionner les applications mais aussi cette infrastructure mutualisée.
Le premier changement majeur abordé dans cet article concerne les processeurs. Depuis 20 ans l’évolution a été importante dans ce domaine avec l’apparition de la parallélisation d’instructions (des instructions qui peuvent traiter en même temps plusieurs jeux de données), de l’hyperthreading (des instructions qui s’exécutent en même temps dans le même espace mémoire), du multi-cœur (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 (plateforme de virtualisation) scinde les processeurs physiques en processeurs virtuels en considérant que l’hyperthreading double le nombre de processeurs et que chaque cœur est un processeur à part entière. Prenons l’exemple d’un hyperviseur muni de deux processeurs quad cœur hyperthreadés : cela correspond à 16 processeurs virtuels (deux processeurs x 2 pour l’hyperthreading x 4 cœurs). Tant que l’hyperviseur gère des serveurs virtuels demandant moins de processeurs virtuels qu’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.
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 crée alors un fichier d’échange (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 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 rentrent 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, …) 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êmes pas communiquées. Alors calculer combien de disques, de 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.
Dans le prolongement des changements liés au stockage il y a les changements 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 œuvre). 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). Il est facile de réaliser que plusieurs serveurs virtuels peuvent se partager une seule carte physique, donc se partager la bande passante.
Une approche spécifique
Nous le voyons bien, ces quatre règles 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, …) 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 article.
Qu’en pensez-vous? N’hésitez pas à nous faire part de vos commentaires.
