La virtualisation de serveurs se généralise, avec à la clé de nombreux avantages relatifs à la gestion de l’infrastructure : diminution du nombre de serveurs physiques, simplification du cycle de vie, rationalisation des architectures.
Pourtant les infrastructures virtuelles amènent de nouvelles pratiques qui ne font pas forcément bon ménage avec les anciennes habitudes, notamment lorsqu’il s’agit de provisionner un nouveau serveur.
Nous ne parlerons pas de la facilité de création d’un nouveau serveur en trois clicks, source d’une incroyable prolifération chez certains utilisateurs, mais plutôt de la difficulté de configurer correctement les caractéristiques d’une machine virtuelle.
La devise « Small is beautiful » n’a que rarement présidé au choix de la configuration d’un serveur, les habitudes ont souvent été de surdimensionner sa capacité afin d’éviter d’éventuels problèmes de performance. C’est souvent cette optique qui perdure lorsqu’il s’agit de configurer une nouvelle machine virtuelle, pourtant le surdimensionnement dans le monde virtuel amène des problèmes bien réels :
• de façon assez évidente, une machine virtuelle sous-dimensionnée va engendrer des problèmes de performance
• plus étonnamment, une machine virtuelle surdimensionnée va également engendrer des problèmes de performance.
Dans le cas de la gestion processeur en environnement virtuel, il ne faut pas perdre de vue que pour permettre à une machine virtuelle de s’exécuter, l’hyperviseur doit être en mesure d’associer chaque processeur virtuel à un processeur physique. On comprend alors rapidement que, sur un serveur physique quadri-processeur, la création de plusieurs machines virtuelles configurées avec 4 processeurs virtuels va générer une compétition importante sur les processeurs physiques, rendant plus difficile l’exécution simultanée de plusieurs machines virtuelles. Les temps d’attente qui en découlent vont donc impacter globalement les performances de l’ensemble des machines virtuelles.
En ce qui concerne la gestion mémoire, l’hyperviseur distribue les pages de mémoire physique aux machines virtuelles selon leurs besoins, et gère la pénurie par une pagination globale de la mémoire au détriment de l’ensemble de machines virtuelles. Une configuration excessive de mémoire pose problème avec des applications ayant une stratégie opportuniste visant à occuper l’ensemble de la mémoire disponible (ex : Oracle, SAP, SQL Server, Exchange …). Dans ce cas de figure, ni le système d’exploitation ‘guest’ ni l’hyperviseur ne sont en mesure de déterminer efficacement quelles pages doivent rester en mémoire physique, aboutissant à une situation de contention et à une pagination qui dégrade les performances de l’ensemble des machines virtuelles du serveur.
On touche donc ici les limites de l’apparente simplicité apportée par les infrastructures virtuelles, ainsi que les risques engendrés par les effets de bord entre les machines virtuelles. Quelle que soit la plateforme technique adoptée (Xen, VMware, POWER …), la mise en place d’une infrastructure virtualisée ne dispense pas, voire même renforce la nécessité de gérer finement les performances d’un ensemble à l’équilibre délicat. Après tout, n’avons-nous jamais été mis en garde de mettre tous nos œufs dans le même panier ?
Retrouvez les solutions de Gestion de la Capacité avec Lean et 6Sigma et de Management des Opérations sur le nouveau site web d'ORSYP!
Commentaires