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 ?

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’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).

Maintenant que les données stockées sur les 3 disques de 1 To externes ont été recopiées sur le serveur, il faut capitaliser sur cet espace disponible en ajoutant ces disques dans le serveur.

En théorie, rien de plus simple :

1. On arrête le serveur
2. On installe les disques
3. On redémarre le serveur
4. On définit une partition de la taille max sur chaque disque, au format « Linux Raid Auto-detect »
5. On ajoute les disques au volume RAID6 existant

En pratique, les disques étant formatés par Mac OS X, ils présentent un « label » de type GPT (le label en environnement Windows est plutôt msdos). Et manifestement, ce label pose problème à OpenFiler (en tout cas tel que généré par Mac OS X). Impossible de redéfinir les partitions en l’état. Par ailleurs, quelle que soit la modification appliquée par fdisk, OpenFiler persiste à trouver les partitions du début…

En cherchant un peu sur le Net, j’ai trouvé un rapport de bug pour la version courante d’OpenFiler 2.3, qui sera a priori corrigé dans la prochaine version. Sans rentrer dans les détails, il faut en fait réécrire un nouveau label de disque, de préférence de type msdos (et pas GPT) :

# parted /dev/sdi mklabel msdos

Ceci fait, je peux alors créer les partitions sur les 3 disques et les ajouter au volume RAID6 existant depuis l’interface d’OpenFiler.

Cependant, cela a pour effet d’ajouter ces disques en SPARE sur le volume. Je n’ai pas trouvé de moyen, depuis l’interface d’OpenFiler,d’utiliser ces disques pour augmenter la taille du volume. Il faut retourner en ligne de commande et taper :

# mdadm --grow /dev/md0 --raid-devices=9

(dans mon cas, je passe de 6 disques à 9). Il ne reste plus qu’à attendre les 1500 minutes (!) nécessaires pour le « reshaping » du volume (bon, c’est vrai, j’utilise le volume en même temps…).

Une fois cela fait, il faut indiquer au volume RAID (le « Physical Volume » en terminologie LVM) de recalculer sa taille, en tapant :

# pvresize /dev/md0

Le volume prend alors toute la place disponible, et le « Volume Group » (toujours en terminologie LVM) est également mis à jour. Un petit coup sur l’interface OpenFiler confirme le nouvel espace libre obtenu.

Se serait sympa si la prochaine version d’OpenFiler pouvait permettre ces opérations directement depuis la console d’administration plutôt que d’amener à taper ces commandes depuis un Shell.