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 ?

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

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

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.

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

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.

J’ai finalement pris le parti d’installer VMware Server 2.0.2 sur mon serveur OpenFiler. J’ai essayé VirtualBox, mais je n’ai pas réussi à faire fonctionner le binaire graphique (Segmentation Fault), et la gestion en ligne de commande est vraiment très touffue, quand ça marche. Et comme je l’ai dit en préambule, je suis pressé…

Donc, VMware Server 2.0.2. L’installation est relativement simple. Il faut suivre la procédure décrite ici, et lorsqu’on arrive à l’impossibilité de compiler les modules pour OpenFiler, il faut suivre la procédure décrite là, et après le lancement de l’installeur de VMware, tout passe.

Un petit coup de navigateur sur http://<mon serveur>:8222/, et on accède à l’interface d’administration.

L’utilisation de l’outil d’administration Windows ne m’inspire pas tellement, donc je vais m’assurer à chaque création de machine virtuelle d’activer l’accès distant à la console par protocole VNC.

EDIT: Ca marche bien, la console par VNC, sauf que le clavier, c’est n’importe quoi… Il existe bien semble-t-il une entrée RemoteDisplay.vnc.keymap, mais ça ne semble correspondre à rien de concret pour VMware Server 2… Bon, le principal, c’est que mes machines virtuelles redémarrent les unes après les autres. On verra à l’usage cette histoire de clavier (qui est la maladie chronique de la virtualisation à distance depuis un Mac…).

J’ai sauvegardé mes données (une semaine de copies acharnées), arrêté les 2 serveurs (un de fichiers, et un de virtualisation), et j’ai consolidé le tout dans un seul boitier.

Résultat : un seul serveur dans un boitier Antec P180, 6 disques de 1 To en RAID6 gérés par OpenFiler, lui-même installé sur une clé USB bootable de 4 Go, le tout propulsé par un processeur Intel Q6600 et 6 Go de mémoire (qui vont grandir pour devenir 8 Go, le max de la carte-mère). J’en ai profité pour ajouter 4 ports réseau à l’unique proposé par la carte-mère, je vais les utiliser en aggrégation pour obtenir un débit théorique de 5 Gb/s sur le serveur (mon switch Netgear GS716 va bien m’aider puisqu’il supporte la norme 802.ad).

Pour l’instant, je me concentre sur la partie serveur de fichiers. OpenFiler ne m’a pas posé de problèmes particuliers, les volumes, partages et autres comptes d’accès sont créés, et je commence à restaurer les données.

Dans un proche avenir (d’ici la fin de la semaine ?), je vais disposer de 3 disques de 1 To supplémentaires à intégrer dans le Raid6, ce qui me portera le volume utile à environ 6,5 To (9 disques en RAID6, c’est équivalent à 7 disques en RAID0 en terme de volume, et un disque de 1 To fait en réalité plutôt 933 Go…). Ces disques sont actuellement utilisés par les données que je suis en train de restaurer sur le serveur.

En terme de consommation électrique (que je n’ai pas mesurée encore…), lorsque j’aurai terminé la « construction » du serveur, je n’aurai fait que remplacer 2 disques de 300 Go et 6 disques de 500 Go par 9 disques de 1 To dans ce qui était le serveur de virtualisation, donc je ne devrais consommer que l’équivalent d’un disque dur en plus, en ne prenant en compte que la consommation des disques (qui sait, vu qu’il y a changement de génération des disques, j’aurai peut-être la bonne surprise d’avoir une consommation électrique induite par les disques durs plus faible au final. Nous verrons). Globalement, le processeur consommant plus, il y a plus de cartes d’extension, il y a plus de RAM, … au total et au final, ce serveur devrait consommer plus que lorsqu’il n’était que serveur de virtualisation, mais comme il sera le seul serveur, la consommation totale du Lab va baisser mécaniquement.

Concernant la grappe de disques, j’ai retenu le RAID6 plutôt que le RAID5 avec un disque de Spare, car étant peu chanceux concernant la fiabilité des grappes de disques, je préfère un volume qui résiste à la panne de 2 disques (le RAID6), qu’un volume qui ne résiste qu’à une panne (le RAID5); la présence d’un disque de spare n’est pas vraiment faite pour me rassurer, pendant la consolidation du RAID sur le spare, un autre disque peu claquer… Ne rigolez pas, mes propres statistiques sont contre moi et les avis des optimistes : j’ai déjà eu 2 RAID5 perdus par le passé à cause de 2 disques HS quasi-simultanément…

Après restauration des données et des services de partages de fichiers, les étapes suivantes seront :

1. Mettre en place les backups; j’ai intégré un lecteur de bandes dans le serveur, ça va simplifier les choses. Je pense que Bacula va m’aider dans cette tâche.
2. Restaurer le service de virtualisation. Je n’ai pas encore validé mon choix entre VMware Server 2 et VirtualBox. J’hésite très fort, mais VirtualBox serait légèrement en avance. Techniquement, ça se vaut, mais avec VirtualBox je peux administrer à distance par X11, alors qu’avec VMware Server 2, je suis obligé d’avoir un Windows pour exécuter l’outil de gestion (et comme je n’ai qu’un poste de travail et que c’est un Mac, cela veut dire un Windows en machine virtuelle… Du virtuel pour gérer du virtuel, ça me chagrine). Et puis VirtualBox me semble plus clair sur son évolution (on peut trouver une Roadmap) que VMware Server 2.

Suite au prochain numéro.

Ca a été plus simple que prévu. Croyant initialement qu’à cause du déménagement, j’étais reparti pour un engagement d’un an, je craignais de devoir payer mon abonnement à son terme même si je vais voir ailleurs. L’assistance d’Orange sur ce point n’a pas vraiment été d’une grande aide : 3 intervenants différents, 3 discours différents.

Résigné à payer, j’ai demandé la résiliation de l’abonnement chez Orange, en souscrivant un nouvel abonnement chez Free, qui a dégroupé chez moi mi-Août 2009 (c’est tout récent). J’ai pesté par le passé contre Free, tout n’y est pas rose, mais d’un point de vue technique, ça se maintient à un niveau incomparablement meilleur qu’Orange.

Après 3 jours de coupure nécessaire pour basculer sur l’infrastructure Free, 4 bonnes surprises :

1. Ca marche. Bah oui, c’est normal, mais ces derniers temps ça n’était pas vraiment la norme dans l’environnement Orange. Cf. mes problèmes de mails…
2. En passant chez Free, je double de débit. Je passe de 4 Mb/s les jours de beaux temps chez Orange, à 8 Mb/s chez Free, quel que soit le temps (bon, j’exagère un peu avec cette histoire de temps, mais c’était très instable chez Orange, alors que c’est un métronome chez Free).
3. En passant chez Free, j’améliore mon ping. C’est pas que ça m’intéresse tellement, personnellement, mais mon fils, oui. D’ailleurs, depuis le passage chez Free, je trouve qu’il joue un peu trop, il va falloir que je borne tout ça…
4. Finalement, je n’avais plus d’engagement chez Orange, donc je n’ai pas eu à payer double pour ma liaison Internet.

Par contre, je sens bien que le dégroupage est récent, car en 3 semaines, j’ai eu deux interruptions de plus de 3h, suite à une panne ou un dysfonctionnement d’un équipement Free. J’ai redécouvert le site « Grenouille », qui me permet de consulter en quasi-temps réel l’état des équipements, justement.

Wait and see, mais pour l’instant, content