7 à 4 (!)

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.

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

Etat des lieux

Mon Lab (c’est moins prétentieux et plus approprié que « ma salle machine »), fonctionnel depuis quelques semaines, me donne entière satisfaction quant aux fonctionnalités proposées :

• Un serveur de fichiers sous OpenSolaris, avec un peu plus de 4 To d’espace disque (2x 300 Go en ZFS MIRROR et 6x 1 To en ZFS RAIDZ1) partagés en CIFS et en NFS
• Un serveur de « virtualisation » sous Ubuntu Server 9.10, qui fait tourner quelques machines virtuelles cruciales mais qui ne nécessitent pas de monopoliser une machine à part entière; il dispose lui aussi de 8 disques (2x 300 Go en RAID1 pour le système, et 6 disques de 500 Go en RAID6 pour les données, principalement les machines virtuelles et les images ISO dont j’ai besoin régulièrement)
• Un routeur sous pfSense
• Un switch Netgear GS716T (un peu bruyant, c’est d’ailleurs lui qui fait le plus de bruit…)
• Une borne Apple Airport Extreme (première génération, avec des ports réseau 100 Mb/s, mébon, je ne me sers pas des ports réseau, donc c’est pas dramatique)
• Un onduleur MGE Pulsar Ellipse USB (750 kVA ? Je ne sais plus…)

Il y a un point qui me chagrine néanmoins : la consommation électrique… J’arrive en effet, en moyenne, à plus de 450 W de consommation instantanée. C’est beaucoup. Trop à mon avis.

En détaillant un peu, j’obtiens une consommation moyenne par équipement suivante (je n’ai mesuré que ce qui consomme beaucoup, laissant de côté Airport et Switch) :

• Serveur de fichiers : 160 W en moyenne, 190 W à pleine charge (un p’tit zpool scrub par exemple)
• Serveur de virtualisation : 190 W en moyenne, 230 W à pleine charge (CPUs à fond et disques qui grattent)
• Routeur : 86 W en moyenne, 102 W à pleine charge (mais ça n’arrive jamais, je n’ai que très occasionnellement dépassé 20 % de charge CPU, c’est la plupart du temps en dessous des 10 %)

Ces serveurs/routeurs sont tous configurés pour maximiser les économies d’énergie sur les CPUs et sur les disques (mais les disques étant régulièrement sollicités, le gain reste minime), et les services inutiles sont désactivés (c’est incroyable tout ce que peut démarrer un serveur Unix par défaut de nos jours, on dirait presque du Windows Bluetooth sur une distrib serveur, ça m’a toujours fasciné…).

J’ai besoin des services hébergés, donc impossible de tailler dans le gras en supprimant des , et je n’ai pas les moyens de m’équipper en tout solaire (bien que j’habite maintenant dans une région très ensoleillée où ça pourrait être rentable), il faut donc revoir l’ensemble pour réduire la consommation.

Première étape : le routeur.

Mon routeur est un PC tout bête, avec une carte-mère généraliste ASUS et un Pentium M 1,73 GHz. Il consomme en moyenne 86 W.

Je prévois de remplacer l’ensemble carte-mère + processeur par une carte-mère Mini-ITX avec un ATOM. Je ne sais pas encore s’il sera simple cœur ou double cœur, d’un point de vue prix la différence reste ridicule (d’un point de vue consommation, le double-cœur pompe 4 W maximum de plus). J’ai pour objectif de descendre à 45 W max, ça semble parfaitement jouable.

Coût estimé : +/- 70 € hors frais de port éventuels.

Seconde étape : consolider le serveur de fichiers et le serveur de virtualisation

Le serveur de fichiers consomme 160 W en moyenne, et le serveur de virtualisation consomme quand à lui 190 W. Ca fait un total de 350 W, c’est une grosse partie de la consommation totale.

Je me dis qu’il y a forcément moyen de diminuer ça en fusionnant le serveur de fichiers et le serveur de virtualisation, passer de 2 machines à une seule.

Par exemple, sur les 4 disques de 300 Go servant de disques systèmes en RAID1 sur les 2 serveurs, on pourrait déjà économiser 2 disques avec un seul serveur. A 5W environ la consommation d’un disque dur, c’est déjà 10 W gagnés.

On peut appliquer la même réflexion sur l’espace de stockage (c’est-à-dire ce qui ne correspond pas au système). 12 disques en tout pour 6 To d’espace disque, sachant que je suis loin d’utiliser la totalité des 2 To du serveur de virtualisation, ça fait dans les 60 W de consommation. Passer de 12 disques à 6 amène mécaniquement une économie de 30 W.

A cela on enlève la consommation d’une carte-mère, d’un CPU, de la mémoire, d’une alimentation (parce qu’une alimentation consomme de l’énergie aussi), Cela fait du potentiel.

Il faut maintenant choisir la méthode pour réaliser cela.

1. Système d’exploitation
   
   Il en faut un qui puisse à la fois servir de serveur de fichiers et proposer la virtualisation. J’aime ZFS, mais le support de la virtualisation sous OpenSolaris ne me plait pas du tout. C’est du Xen et c’est en retard d’une version par rapport à ce qu’on trouve sous Linux.

   Linux m’apparaît comme un choix plus intéressant, car il propose plusieurs méthodes de virtualisation, qu’elles sont pour la plupart au top de ce qui se fait dans ce domaine.

2. La distribution Linux
   
   En matière de stockage, mon choix se porte naturellement sur OpenFiler. J’ai déjà joué avec par le passé, je connaîs plutôt bien. J’ai un peu lâché l’affaire, car toute efficace et fiable que soit OpenFiler, un RAID5 ne peut résister à une casse de 2 disques simultanément (oui, j’ai la scoumoune). Cela m’a poussé à tester ZFS, avec succès. Dommage que je ne puisse continuer avec. Mais je fonde de grands espoirs futurs sur BTRFS, qui a pour ambition de rejoindre ZFS dans le peloton de tête des filesystems.

   Concernant la virtualisation, je sais déjà (pour l’avoir là déjà réalisé, cf. un de mes vieux posts) qu’on peut installer VMware Server sur OpenFiler. J’ai pas d’idée encore concernant Xen et/ou KVM (j’utilise KVM actuellement). Mais travaillant par ailleurs pas mal avec les produits VMware pour mon activité professionnelle, ce ne serait pas un mauvais choix (même si je n’aime pas beaucoup être obligé de lancer une machine virtuelle Windows pour administer mes machines virtuelles VMware…).

3. Le boîtier et son alimentation
   
   Je dispose d’un vénérable boîtier Lian-Li (vieux de 6 ans minimum, mais encore particulièrement vaillant; ya pas à dire, Lian-Li, c’est cher, mais c’est de l’excellente camelote) et d’un autre boîtier Antec P180 (ça aussi c’est du bon). A priori, l’Antec accueillera la fusion. J’ai la place d’y caser 7 disques ventilés (4 de base plus 3 dans une baie double-hauteur 5′1/4, elle aussi ventilée) et il me restera de la place pour insérer un lecteur de bande double hauteur 5′ 1/4 pour les backups.

   Concernant l’alimentation, celle qui se trouve dans le boîtier Antec est excellente, modulable, et tout (je ne sais pas si elle est certifiée 80+ cependant).Du coup, accessoirement, le boîtier Lian-Li, actuellement serveur de fichiers, deviendra poste de travail Windows (mais avec beaucoup moins de disque et une carte graphique plus vaillante), pour que je puisse jouer en réseau avec mes enfants, et que j’évite la raclée portée par mon fils par manque d’entraînement Comme je n’ai pas beaucoup le temps de jouer, il ne sera pas allumé souvent…

4. La migration des données du serveur de fichiers
   
   Voilà bien le point qui me travaille le plus. Il faut que je déplace un nombre conséquent d’octets du serveur de fichiers actuel, sous ZFS, vers du Linux. N’existant pas à ma connaissance de moyen (même compliqué) de faire muter des pools ZFS en LVM Linux, il va bien falloir à un moment ou à un autre disposer d’un espace de stockage temporaire pour effectuer le déplacement.J’ai à ma disposition 4 disques de 500 Go inutilisés. Ca fait un peu moins de 2 To, le compte n’y est pas pour vider le serveur de fichiers de son contenu. Il va donc falloir que je m’équipe en espace de stockage supplémentaire. Au plus juste, parce qu’après, il faut que je puisse en faire quelque chose.

   La meilleure solution que j’ai trouvée (en dehors de se faire prêter un NAS de 4 To pendant 2 semaines), c’est d’acheter 2 disques de 1 To supplémentaires. Une fois l’opération terminée, je pourrai réutiliser ces 2 disques avec 2 autres disques d’1 To, placés dans un boitier IcyBox MB-561US-4S que j’ai déjà (qui peut contenir jusqu’à 4 disques SATA, connectable en USB2 ou en eSata); ça me servira d’espace de stockage d’appoint… Enfin, me connaissant, ça va pas « appoindre » longtemps, et devenir vite plein Genre backups sur disques…

5. Encore améliorer la consommation
   
   C’est possible en effet, en remplaçant « tout simplement » le processeur, un Intel Q6600, par un Intel Q9400s. Le gain semble tourner entre 50 et 80 W en consommation moyenne d’après un test que j’ai vu sur le net (je ne sais plus où), c’est plutôt impressionnant. Mais ce résultat dépassant quand même la seule différence de TDP déclarée (95 W pour le Q6600 et 65 W pour le Q9400s), il faut toujours se méfier des discours marketing et des tests sur Internet, donc je ne m’attends pas à une telle économie en réalité. Mais ça vaut le coup d’être étudié (dans le pire des cas), surtout qu’au passage on y gagne en performance. Ca se prête, un CPU ?

Coût estimé : +/- 160 € pour 2 disques d’1 To, +/- 200 € pour le processeur Intel Q9400s, hors frais de port éventuels (+ 150 € environ pour une carte graphique correcte, genre une Radeon HD5770 qui semble pas mal).

Troisième étape : remplacer les ventilateurs du switch

OK, ça n’a rien à voir avec les économies d’énergie, mais c’est bon pour les oreilles

Il suffit, a priori, de changer les ventilateurs 40 mm par des modèles plus discrets.

Coût estimé : +/- 20 € hors frais de port éventuels.

Suite au prochain épisode

J’essaierai de tracer pas à pas la mise en place de ces évolutions. Par souci principal d’en garder une trace (justement) pour moi (perso que je suis), car j’arrive à un âge où les neurones ont tendance à se répandre par les oreilles. Mais si ça peut intéresser d’autres personnes, c’est tant mieux.

Donc, pour rappel : j’ai une Fedora 11 qui tourne nickel sur mon serveur de virtualisation. Mais pour l’instant il ne virtualise rien.

Installation de VMware Server 2. Pas de souci jusqu’à la génération des modules : « Oui mais ça marche pas » (c) Maeva dans « Caméra Café ».

Un peu de grattage sur les forums de VMware, je trouve un article qui propose un patch pour VMware Workstation pour le noyau Linux 2.6.29 utilisé par Fedora 11. Voyons ce patch.

Après une légère modification du fichier patch (il faut ôter ce qui concerne le dossier vmblock-only), ça compile et les modules se chargent. Cool.

Reste à vérifier que l’ensemble fonctionne bien, en créant une machine virtuelle.

UPDATE: L’ensemble fonctionne bien, 8 h environ. Après un reboot, la Fedora m’ayant fait le même cirque que les autres distributions Linux (échec d’activation des coeurs au-delà de 1 provoquant un reboot, même un noyau compilé par mes soins à partir des sources officiels fait pareil), j’ai migré vers Windows 7 (j’envisage même Windows Server 2008), qui lui fonctionne du premier coup et me permet de profiter de tous les raffinements proposés par le serveur. En attendant une distribution Linux qui fonctionne (la prochaine Fedora ? Ubuntu ? CentOS ? Non pas CentOS, ça semble moribond…).

UPDATE2: Comme indiqué en mise à jour de mon billet précédent, j’ai trouvé la cause des dysfonctionnements de Linux sur mon serveur. Du coup, je me suis rabattu sur mon premier choix de distribution Linux, Ubuntu Server 9.04 x86_64. Je n’ai donc pas eu le temps de beaucoup testé la manipulation décrite ici. Peut-être vais-je rencontré le même soucis avec l’Ubuntu, je mettrai alors à jour au besoin.

J’ai dans l’esprit d’utiliser mon serveur QuadCore comme serveur de virtualisation, pour héberger quelques machines qui par ailleurs ne valent pas la peine de tourner sur une machine dédiée au vu des services rendus.

Ce serveur est équipé d’une carte mère Gigabyte GA-P35-DS3R, d’un Core2Quad Q6600 et de 6 Go de mémoire. Je veux aussi profiter des capacités de RAID proposées par le chipset Intel (un ICH9R), afin de disposer d’un volume système en RAID1, et d’un volume de données en RAID10. Je sais que c’est pas du vrai RAID matériel, mais tout ce qui peut décharger un peu le processeur, et simplifier la gestion des volumes, je prends.

Rien d’exceptionnel a priori. Pourtant.

J’ai commencé par VMware ESXi, d’abord pour voir parce que je ne connais pas, et puis parce que je manipule majoritairement des machines virtuelles au format VMware. Conclusion : pas de support du « fakeraid » (surnom affectueux donné aux contrôleurs ICH d’Intel qui proposent du RAID).

Bon. On essaiera alors VMware Server 2 sur un Linux « classique ».

Néanmoins, par curiosité, essayons alors XenServer 5.5.0. Paf, pas de support fakeroot. Surprise parce que c’est basé sur Linux quand même.

J’arrive à installer Ubuntu Server 9.04 x86_64, mais je n’ai pas de gestion de la fréquence des coeurs du processeur. Damned. Apparemment, le BIOS de la carte-mère (version F3 alors si je me souviens bien) ne gère pas correctement le Q6600.

Qu’à cela ne tienne, on update le BIOS en F13. Hop, apparition d’une option pour valider EIST (le « protocole » de gestion des fréquences chez Intel), c’est bon signe, « che valide ».

C’est à partir de maintenant qu’on se marre.

Les distributions Ubuntu Server 9.04 x86_64 et CentOS 5.3 x86_64 ne parviennent pas à booter mon serveur à l’installation. J’ai des messages « Not Responding » en provenance du noyau après le chargement de ce dernier, conduisant à un reboot assuré du serveur. J’ai réussi à booter CentOS en passant « nosmp » au kernel. Ca démarre, la fréquence du coeur est modifiable, mais ça m’intéresse pas vraiment un QuadCore qui n’utilise qu’un coeur… J’ai cherché sur Internet, j’ai rien trouvé de probant. Il semblerait que pour une raison ou une autre, la combinaison des 4 coeurs avec l’ACPI pose problème, mais rien ne change si je désactive l’ACPI.

Finalement, j’ai trouvé une distribution qui s’installe sans sourciller sur le serveur : Fedora 11. Cela n’était pas mon premier choix, mais au final, j’ai pas vraiment le choix, et je ne vais pas tester toutes les distributions Linux de la terre pour inventorier celles qui fonctionnent. J’en tiens une, je la garde.

Maintenant, installation de VMware Server 2 sur Fedora 11. Ca pique… Certains objecteront que je peux utiliser Xen/KVM/VirtualBox/… Ils ont raison. Mais je ne veux pas non plus perdre des journées entières à résoudre les soucis de conversion de machines virtuelles d’un environnement à l’autre quand j’ai besoin d’être efficace (j’ai déjà bien assez galéré comme ça avec les conversions VMware Fusion <-> Parallels Desktop, j’en ai déjà parlé).

Suite au prochain épisode : VMware Server 2 sur Fedora 11, ça se mérite aussi.

UPDATE: Bah en fait, Fedora 11, après plusieurs reboots, finit par faire comme les autres Linux : lors du boot du noyau, lorsqu’il tente de « démarrer » le 2ème coeur et suivants, j’obtiens « Not Responding », et ça aboutit à un reboot automatique.

Du coup, par curiosité, j’ai essayé d’installer Windows 7 (pas taper). Et bah ça marche nickel sans moufter. J’ai tous mes coeurs disponibles, le contrôleur RAID Intel est pris en compte, la gestion de l’énergie est pleinement fonctionnelle.

Je crois que dans l’immédiat, je vais faire un serveur de virtualisation à base de Windows. C’est péché, mais tant que Linux ne boote pas sur mon serveur, j’ai pas vraiment le choix.

UPDATE2: Ca ne me plaît décidemment pas ce serveur sous Windows. J’ai tenté l’installation de XenServer 5.5.0 en sacrifiant le RAID1 sur le disque système, ça s’installe mais au redémarrage, j’aboutis à un écran noir. Je commence à soupçonner la dernière version du BIOS de Gigabyte, je vais tenter un downgrade de BIOS pour voir s’il existe une version qui me permet de booter Linux ET de gérer les fréquences des coeurs du processeur.

PS: Si quelqu’un qui me lit connaît la solution à mon problème, « ça m’intéresse aussi » (c) Elie Semoun.

UPDATE3: J’ai trouvé. C’était le contenu de la mémoire CMOS qui devait être corrompu d’une subtile façon. Après un « Clear-CMOS » puis une réinitialisation des paramètres du BIOS, j’ai réussi à booter une CentOS 5.3 x86_64 puis une Ubuntu Server 9.04 x86_64 avec tous les coeurs, toute la mémoire et la gestion des fréquences du CPU. Ce qui m’a mis sur la piste, c’est qu’ayant réussi à installer une CentOS avec un noyau « Xen » (j’ai pas bien compris comment l’installeur a booté, mais bon), cela m’a permis de booter Linux sur le serveur, avec un seul processeur (le noyau Xen semble plus tolérant aux situations hors normes). J’ai alors constaté 2 points troublants : un processeur défini dans le BIOS comme tournant à 1,6 GHz alors qu’un Q6600 c’est 2,4 GHz, et seulement 5,4 Go de mémoire totale indiquée par le noyau, sur les 6 Go. J’ai jamais vu Linux se tromper sur la taille mémoire, à moins d’un problème de barette ou de mémoire CMOS. J’ai testé les barettes, pas de problème. C’était donc la mémoire CMOS.