Analyse de performance de mon serveur de fichiers…

Si vous suivez mon blog depuis assez longtemps (ou si vous avez été assez curieux pour consulter les articles plus anciens), vous savez que j’ai récemment consolidé 2 serveurs en 1 seul, dans le but d’économiser sur la consommation électrique (avec succès).

Il y a cependant un effet de bord constaté au fil du temps : les performances en écriture du nouveau serveur ont chuté par rapport à celles de l’ancien serveur de fichiers. Rien de chiffré, mais un ressenti net. Après avoir pensé à un problème réseau sur le serveur, levé par l’utilisation de iperf (qui permet de mesurer le débit brut possible entre 2 machines sur le réseau), j’en ai conclu que c’est le sous-système disque qui a un souci.

J’ai pris une demi-journée ce Week-End pour formaliser cette impression, avec l’aide de 2 excellents outils, iozone pour les mesures et OpenOffice pour les graphes, et cela aboutit aux 2 séries de résultats ci-dessous.

Avant de commenter les graphes, quelques informations sur les mesures en elles-mêmes :

- J’ai effectué 3 séries de mesures avec iozone, une avec VMware Server 2 arrêté totalement, une seconde avec VMware Server 2 redémarré sans la machine virtuelle “utopie” (je reviens sur l’usage de cette machine virtuelle quelques lignes plus bas), et enfin une avec utopie démarrée et en pleine charge.

- J’ai pris soin, disposant de 6 Go de RAM sur le serveur, d’utiliser un fichier de test plus grand (8 Go en l’occurrence), afin de m’assurer que le cache disque de Linux n’interfère pas avec les mesures (pour les petits fichiers, avec le cache j’arrive à obtenir des débits au-delà du Go/s, pas très réaliste…).

- Par défaut, iozone effectue ses mesures en utilisant différentes tailles de bloc. L’influence n’apparaît pas significative dans les résultats, mais j’ai conservé ses différentes tailles, ne sachant pas laquelle choisir en particulier.

Je reviens quelques instants sur VMware Server 2 et l’usage que j’en fais. J’ai actuellement 5 machines virtuelles qui tournent en permanence :

- un serveur Windows 2008 avec un AD qui impose les règles d’économie d’énergie (plus quelques contraintes horaires pour les enfants) et gère les mises à jour sur les PCs Windows de la famille (quitte à avoir un AD, autant que ça serve), et qui sert aussi pour me faire la main sur cette version de Windows Serveur.

- un serveur CentOS qui me sert de serveur de développement pour les applications Web (usage interne uniquement).

- un serveur CentOS qui me sert pour héberger les applications Web que je veux rendre accessible depuis l’extérieur (maquettes, …).

- un serveur Ubuntu qu’on nommera “utopie”, qui sert à télécharger les distributions Linux et autres “torrenteries” (dans la légalité). Les données téléchargées/partagées sont stockés sur un montage réseau d’un dossier du serveur de fichiers (j’ai préféré cette option plutôt que de verrouiller et donc perdre un espace disque en permanence affecté à la machine virtuelle).

- un serveur Linux sous Ubuntu 9.04 qui supervise le réseau avec Nagios/Centreon.

Je soupçonne que ces machines virtuelles soient en partie ou totalement la cause de la chute de performance du service partage de fichiers de mon serveur.

Maintenant, les résultats :

On constate que les débits en lecture obtenu, sans VMware, sont tout à fait respectable avec un sous-système disque en RAID6; on avoisine les 350 Mo/s, de quoi saturer n’importe quel port réseau.

Dès que VMware est lancé, avec 4 des 5 VMs actives, le débit chute brutalement, de plus de la moitié, 51 % pour être précis.

Le lancement et l’activité d’utopie font baisser encore un peu le débit en lecture, ajoutant une pression sur le service partage de fichiers du serveur hôte.

Pour les débits constatés en écriture, là encore on obtient des résultats en phase avec ce que peut proposer un RAID6 à base de SATA, environ 150 Mo/s. Une simple interface réseau Gigabit ne parviendra pas là non plus à saturer le sous-système disque. Ca tombe bien, j’en ai deux en aggrégation Mais même deux, avec un débit par port tournant plutôt autour de 50 Mo/s que les 125 Mo/s théoriques annoncés, ne peuvent pas mettre le RAID6 à genou.

On démarre VMware, sans utopie, et les débits chutent, moins qu’en lecture, mais de façon significative tout de même, perdant 37% de débit en moyenne. Les débits chutent moins parce que les machines virtuelles démarrées font plus de lecture que d’écriture à priori, donc exercent une pression moindre.

Utopie démarré, et c’est la dégringolade. On perd 89 % de débit ! Le coupable est donc tout désigné. Cette machine virtuelle passe son temps à envoyer et recevoir des paquets réseau, et sollicite en plus lourdement le service de partage de fichiers pour lire et écrire ce qui est échangé par le réseau.

Après analyse de ces résultats, il m’apparaît qu’il manque une mesure : VMware démarré sans utopie, mais avec un équivalent d’utopie sur une autre machine du réseau, pour mesurer la pression des téléchargements sur le serveur de fichiers, afin de bien déterminer si la chute de performance en écriture est due aux téléchargements dans une machine virtuelle ou aux téléchargements d’où que ça vienne. C’est relativement simple à faire, il me suffit de déplacer la machine virtuelle “utopie” vers mon MacBookpro par exemple.

Autre conclusion : un service partage de fichiers et un service de virtualisation sur un même serveur, c’est pas tellement compatible… Du coup, je vais peut-être revenir en arrière sur la consolidation, et essayer de trouver un compromis performance/économie d’énergie, qui me permettent d’avoir un service de partage de fichiers performants avec la consolidation apportée par un service de virtualisation, sans interférence entre les deux.

J’ai 3 pistes pour l’instant :

- Un serveur de virtualisation basé sur un processeur AMD Phenom II X4 905e ou 910e me semble une bonne piste, le TDP de ces processeurs est de 45 W. Je pourrai réutiliser la mémoire DDR2, et les processeurs AMD sont pas trop chers.

- Un serveur de virtualisation basé sur un processeur Intel de génération i3 ou i5; je ne connais pas encore bien les performances énergétiques de cette gamme… J’ai lu qu’on pouvait faire une machine à base d’i3 qui consomme 25 W au repos, mais il reste à déterminer combien ça consomme en charge (parce que le principe d’un serveur de virtualisation, c’est quand même de l’utiliser au maximum…). Cependant, cela implique d’acheter une nouvelle carte-mère, un nouveau processeur, de nouvelles mémoires (DDR3 oblige)…

- Un échange de processeur entre le serveur actuel (un Q6600, 4 cœurs, 95 W de TDP) et mon poste de travail Windows (un E6550, 2 cœurs, 65 W de TDP); pas besoin d’un quad-core pour un serveur de fichiers (en tout cas, pas à mon niveau d’utilisation), et mon poste de travail Windows n’est pas souvent allumé.

Du boulot en perspective.