7 à 4 (!)

Ayant pour objectif de rendre silencieux mon switch réseau (un NetGear FS716T pour rappel), qui fait en temps normal un bruit digne d’un Airbus, je l’ai démonté ce matin pour vérifier la taille des ventilateurs responsables du décollage permanent.

Après avoir constaté qu’il s’agit de modèles en 40 x 40 mm, j’ai eu l’idée saugrenue (je me demande encore d’où ça m’est venue) de rebrancher le switch sans remettre le capot. Et à ma grande surprise, le bruit s’est considérablement réduit. Du coup, je crois que je vais laisser mon switch comme ça.

Et ce n’est pas le mettre en danger de se faire pourrir la carte-mère par une dispose accidentelle, puisqu’il est placé entre 2 étagères qui laissent à peine la place pour le switch…

Et hop, une économie de 2 ventilos silencieux. Bon, ok, c’est jamais qu’une 10aines d’€, mais en ces temps troublés, il n’y a pas de petites économies

Au hasard de mes recherches pour résoudre mes problèmes de stabilité de réseau pour les machines virtuelles, je suis tombé sur cet article (en anglais).

Pour faire simple, le principe est de modifier le lancement du noyau Linux des machines virtuelles pour utiliser le « I/O Scheduler » appelé « noop » (pour no operation). Quel est l’intérêt ?

D’abord, j’explique rapidement ce qu’est un I/O Scheduler. Il s’agit d’un mécanisme qui va tenter d’optimiser au maximum les accès disques, afin de limiter autant que possible les situations où des écritures vont empêcher des lectures, ou les situations où un processus de haut niveau serait en train d’accaparer le disque.

Il existe plusieurs ordonnanceurs (schedulers en anglais donc), avec chacun leurs particularités propres. En standard sont disponibles les ordonnanceurs appelés CFQ (le défaut actuel), Deadline, Anticipatory et Noop. Je ne détaillerai pas les 3 premiers, la particularité de l’ordonnanceur « noop » est de ne quasiment rien faire.

Lorsque une machine virtuelle fait tourner un Linux, il y a donc un « I/O scheduler » qui tourne pour optimiser les accès disque. Cependant, si les disques virtuels utilisés sont des fichiers, son utilité est discutable. Laisser à la machine virtuelles le choix de comment accéder à son disque, alors qu’elle n’a qu’une vision étriquée de ce qui se passe réellement avec le sous-système disque du serveur hôte, est au mieux inutile, au pire un gaspillage de ressources. Il vaut mieux laisser le serveur hôte faire seul le travail d’optimisation. Par contre, si la machine virtuelle utilise des disques en accès direct (les fameux disques « Raw ») ou des disques iSCSI, il faut conserver un ordonnanceur « normal » dans la machine virtuelle (et dans une situation mixte, on peut changer l’ordonnanceur à utiliser disque par disque, en utilisant /sys/block/<device>/queue/scheduler).

C’est là que l’utilisation de l’ordonnanceur « noop » prend son sens : en configurant le noyau Linux des machines virtuelles pour utiliser « noop », on déporte la logique d’optimisation vers le serveur hôte, diminuant donc la charge CPU des machines virtuelles (et donc du serveur hôte).

Pour faire cela, on peut utiliser le paramètre noyau « elevator », par exemple en modifiant l’entrée GRUB adéquate :

title CentOS (2.6.18-164.6.1.el5)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-164.6.1.el5 ro root=/dev/VolGroup00/LogVol00 elevator=noop
    initrd /initrd-2.6.18-164.6.1.el5.img

Bon, pour être honnête, je n’ai pas fait de tests précis pour vérifier cela (juste du ressenti positif), mais ça a du sens d’un point de vue théorique. Et comme sur mes 6 machines virtuelles actuelles, j’ai 5 Linux, moins de CPU et d’accès disque gaspillés, c’est toujours ça de gagné.

EDIT: Pour rappel, pour modifier grub sur Ubuntu, il ne faut pas aller éditer un fichier à la sauvage dans /boot/grub (comme pour une CentOS par exemple), mais il faut modifier le fichier /etc/default/grub, en mettant à jour le contenu de GRUB_CMDLINE_LINUX_DEFAULT, puis en exécutant update-grub.

J’ai découvert à mes dépends que VMware Server 2 n’apprécie pas tellement le « port trunking/nic bonding/agrégation de ports réseau/quelque-soit-le-nom-qu’on-lui-donne », en mode « bridge » (c’est-à-dire quand on demande à utiliser une interface réseau directement, pas en NAT).

J’ai constaté que si on fait ça, l’accès distant à une machine virtuelle est très instable : on y parvient quelques secondes, puis on n’y parvient plus, puis on y parvient de nouveau, puis on y parvient plus, … En particulier, lorsque je fais un ping vers une machine virtuelle, j’obtiens des duplications de séquences (!). Alors pour un serveur dédié Counter Strike, c’est pas glop.

Alors que par ailleurs, les accès concurrents sur le serveur de fichiers (de plusieurs machines clientes, depuis une seule n’aurait pas sens…) fonctionnent très bien, toutes les interfaces sont (quasi-)pleinement utilisées.

Je ne suis pas sûr de bien comprendre pourquoi ça se comporte comme çà (j’ai mon idée sur le pourquoi, mais ne disposant pas du savoir absolu concernant le réseau, je vais éviter de me ridiculiser ). C’est juste un peu frustrant. J’ai pensé au début à un souci avec le mode d’agrégation utilisé (la norme 802.3ad supportée par mon switch), mais j’ai essayé tous les modes proposés (aussi bien ceux qui nécessitent un switch que les autres), et le comportement est le même.

J’ai donc enlevé une interface de l’aggrégation, reconfiguré VMware Server 2 pour ajouter cette interface en mode Bridge, puis reconfiguré les machines virtuelles pour utiliser ce nouveau Bridge. Depuis, plus de souci, les accès réseau sont stables. Cette unique interface réseau pour 6 machines virtuelles semble suffisante pour l’instant.

J’utilise sur mon serveur 4 interfaces réseau « agrégées » ensemble pour fournir un semblant d’interface à 4 Gbits/s. Ca n’a évidemment de sens que dans un contexte où plusieurs clients accèdent simultanément à ce serveur bien entendu.

Jusqu’à il y a une heure, tout fonctionnait bien. Plus maintenant. Enfin si, depuis 5 mn. J’explique.

J’ai voulu jouer avec les « Jumbo Frames ». C’est une fonctionnalité (plus ou moins bien) supportée par les matériels réseau. Mon switch le supporte, les cartes réseau de mon serveur le supportent (en théorie, comme je l’explique ci-dessous…), le MacBookPro le supporte, …

Le but des « Jumbo Frames » est d’améliorer la bande passante en validant les « Jumbo Frames » de 9000 octets. Cela veut dire qu’on demande à faire circuler sur le réseau des paquets de (plus ou moins…) 9000 octets, plutôt que des paquets de 1500 octets (le réglage par défaut en général). L’avantage de n’émettre qu’un paquet plutôt que 6, c’est d’éviter de « consommer » 6x les entêtes IP (ou TCP, je ne sais plus; peu importe) et d’éviter d’imposer 6x plus de traitements aux systèmes d’exploitation.

Donc en théorie (et en pratique, j’ai testé par le passé), sur des transferts de données conséquents (plus de 9 Ko donc), on gagne en bande passante.

Sauf que.

Sur mes 4 interfaces, 3 sont des Intel Gigabit/s, la 4ème (intégrée sur la carte mère) est une Realtek. Et c’est elle qui pique. En fait, bien que l’activation du mode Jumbo Frame ne lui pose pas de problème, elle s’en fout complètement. Et du coup, 3 interfaces en 9000 et une en 1500, sur une agrégation, ça gazouille plus… Problème de driver sous Linux ou mauvaise implémentation chez Realtek, peu importe. J’affectionnais pas tellement Realtek, maintenant je suis conforté dans mon (res)sentiment…

Pour contourner le problème, j’ai rétrogradé l’interface Realtek comme interface d’accès au serveur, pour l’administration Openfiler par exemple, et j’ai agrégé les 3 interfaces Intel, qui elles acceptent sans broncher les Jumbo Frames. J’ai récupéré ainsi ma bande passante améliorée ( 3Gbits/s, c’est pas si mal) vers/depuis mon serveur tout en améliorant légèrement la bande passante grâce aux Jumbo Frames.

La première phase de l’évolution du Lab, la consolidation de 2 serveurs en un seul, est terminée. Le serveur est en ligne, configuré, fonctionnel, tous les services proposés par les 2 serveurs initiaux sont restaurés (et même plus, comme le lecteur de bande).

Au niveau consommation, avant de brancher le nouveau serveur, j’en étais à 141 W instantané. Après connexion du serveur, je suis grimpé à 286 W après le boot (login affiché sur la console), et à 320 W en pleine charge (tous les cœurs du processeur à 100 %, tous les disques et le lecteur de bande au boulot).

Je rappelle qu’avant l’opération, je dépassais les 450 W, sans particulièrement mettre les serveurs au travail (et j’avais pas branché le lecteur de bande). J’économise donc déjà un peu plus de 160 W en fonctionnement normal. Sur 24h, c’est pas rien (ça me fait grosso-modo 135 € d’économie par an, au tarif EDF actuel, pour un fonctionnement 24/7).

Je peux facilement (enfin, facilement, ça va coûter un peu…) diminuer d’au moins 40 W instantané, en changeant mon routeur pfSense pour une plate-forme ATOM. Ce sera l’étape suivante. Je pense pouvoir aussi réduire encore la consommation de mon serveur, en changeant le processeur (actuellement un Q6600 avec un TDP de 95 W) pour un Q9400s (ou un Q9550s, mais en tout cas « s » pour avoir un TDP de 65 W), mais l’investissement est plus lourd (plus de 200 €) pour une économie pas forcément si importante que ça en réalité (un TDP ne présage pas d’une consommation maximale, mais d’un dégagement de chaleur maximal, d’après ce que j’ai compris).