7 à 4 (!)

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.

Finalement, les backups par Bacula, ce sera pour plus tard, j’ai un impératif professionnel qui appelle le retour des outils virtualisés au travail le plus vite possible.

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

Après avoir réfléchi à mon problème de consommation électrique un peu excessive à mon goût, je suis passé aux travaux pratiques.

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.