7 à 4 (!)

Le temps est maintenu venu, disposant que quelques deniers, d’investir pour un nouveau routeur fait maison.

Pour rappel, l’actuel routeur est un PC sous pfSense, propulsé par un Pentium M 1,6 GHz, qui consomme 90 W en fonctionnement. Je trouve que c’est beaucoup (trop).

Le prochain routeur doit consommer significativement moins, être silencieux (donc il faut éviter les pièces mécaniques), prendre le moins de place possible, rester performant malgré tout et continuer à tourner sous pfSense. Beaucoup de conditions…

J’ai acheté il y a quelques semaines sur eBay, à bon prix, un boitier Mini-ITX tout mimi, avec alimentation externe de 60 W (sans ventilateur, genre ce qu’on trouve avec les ordinateurs portables). Il me restait à acheter une carte-mère avec au moins 2 ports réseau (plus permettrait quelques fantaisies dans un avenir proche, je reviendrai sur mes fantasmes technophiles dans un autre article; non c’est pas sale ).

Après de nombreuses recherches et hésitations, j’ai choisi une carte-mère Jetway JNF76 avec un processeur Via Nano à 1 GHz, accompagnée d’une carte fille réseau (Jetway toujours) proposant 3 ports Gbps de marque Intel (j’aime pas Broadcom). Un petit investissement de 260 € (quand même) directement chez LinITX, revendeur anglais qui propose (entre autres) un catalogue impressionnant de matériel au format mini-ITX. Et en plus, c’est moins cher que les revendeurs français, port compris.

Pourquoi ce choix :

1. Jetway d’abord parce que c’est le seul constructeur, disponible en France/Europe, qui propose le principe des cartes-filles, permettant de ne pas nécessiter un boitier au format ATX (et donc de pouvoir profiter des boitiers tout fin pour le format mini-ITX).
2. Les cartes-mères ATOM proposées par Jetway qui acceptent les cartes-filles ne sont pas passives (sans ventilateur). Le choix de la passivité est motivé par le souhait de n’avoir aucune pièce sujette à usure mécanique; exit donc les ventilateurs et le disque dur que je vais remplacer par une clé USB rapide.
3. Les cartes-mères avec le nouvel ATOM, passives pour la plupart, ne sont pas encore proposées par JetWay (donc pas de carte-fille), et les rares que j’ai pu trouver disponibles ne proposent qu’un port réseau, souvent 100 Mbps, avec comme seule possibilité d’extension un port PCI (exit mon boitier mini-ITX…).
4. Accessoirement, les processeurs VIA (C7, Nano au moins) disposent d’instructions orientées cryptage, gérées par FreeBSD et donc par pfSense, qui accélèrent notoirement les communications VPN, le cryptage s’effectuant au niveau matériel; ça ne mange pas de pain d’en disposer

Au final, d’après mes estimations, l’ensemble devrait consommer entre 15 et 20 W, un bond en terme d’efficacité énergétique par rapport à l’existant (certes pas de quoi rembourser l’investissement immédiatement, mais je n’ai pas que l’économie financière comme motivation).

Quand j’aurai reçu le matériel, j’essaierai de prendre quelques photos du montage.

« Stay tuned », comme y disent !

PS: A peine je valide la publication de cet article que je reçois le matériel. Très bien, LinITX ! Quelques photos prises, un nouvel article demain ?

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 compatible 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.