Pour rappel, Zone0 est un serveur de type SuperMicro, muni d’un CPU Intel Quad Core, de 6 gigas de mémoire vive et d’un contrôleur RAID1 de type 3ware. Ces éléments hardware sont importants pour la suite, puisqu’ils sont tous à un moment ou un autre impliqués dans un dysfonctionnement. Pour rappel toujours, il s’agit d’un serveur entièrement articulé autour de Xen 3.1. Le dom0 est une Debian stable 64 bits, et quatre domUs répondent aux services par le biais d’une translation de ports. Deux domUs, services et shells tournent sous OpenBSD 4.1 i386, et les deux autres, gcu et www2 tournent sous NetBSD 4.0 i386. Tous les domUs fonctionnent en mode HVM.

Nous le verrons plus loin, des interventions peu banales ont dû être effectuées dans le code source du noyau de la machine. Pour ce faire, nous avons évidemment dû télécharger les sources de ce dernier, opération classique s’il en est, qui a été le point de départ d’un véritable cauchemar.

Après le téléchargement du tar.bz2, un tar jtvf nous fait savoir que l’archive est corrompue. Un peu surpris, nous renouvelons l’opération, puis tout semble se dérouler correctement. Alors qu’un second administrateur avait également besoin de télécharger une archive, ce dernier me communique qu’après trois téléchargements consécutifs, le fichier compressé a eu trois fois un checksum différent. Et l’inquiétude monte.

Naïfs, nous soupçonnons un problème réseau, peut-être un problème de driver, des lutins farceurs, des cafards dans le connecteur RJ45… ou un problème disque ? Encore ? Incrédules, nous effectuons quelques recherches à l’issue desquelles nous nous rendons à l’évidence : nous aurions finalement dû filer un euro à cette voyante dans la rue qui menaçait de faire tomber le malheur sur nous le cas échéant.

Voici ce que nous pouvons lire sur la base de connaissances du constructeur de notre carte RAID 3ware :

Avons-nous un système 64 bits ? Oui.

Avons-nous plus de 4 gigaoctets de mémoire vive ? Oui.

Notre carte contrôleur RAID est-elle de type 7000/8000 ?

Oui.

Enfin, utilisons-nous un noyau compris entre 2.6.15 et 2.6.22 ?… Oui.

Il apparaît donc clairement que nous devons recompiler un noyau. Si cette opération n’est pas des plus complexes, modifier puis compiler un noyau en environnement Xen dans l’optique de changer le driver du contrôleur disque sur une machine qui se trouve à 20 â‚¬ de taxi ne met pas spécialement en confiance, mais nous n’avons pour ainsi dire pas le choix : exécution.

L’archive fournie par 3ware contient les fichiers suivants :

Un rapide diff entre le code stock du driver et celui fourni par le constructeur nous informe que nous suivons probablement la bonne voie :

Nous entreprenons donc de remplacer les fichiers 3w-xxxx.c et 3w-xxxx.h par leurs versions corrigées, puis recréons l’archive linux-2.6.18.tar.bz2, utilisée par l’installation source de Xen.

Il faut maintenant télécharger (plusieurs fois, jusqu’à ce que l’archive ait le bon checksum) l’archive d’installation par les sources de Xen 3.1 (http://bits.xensource.com/oss-xen/release/3.1.3/xen-3.1.3.tar.gz), et suivre la procédure de compilation puis d’installation :

Reste à regénérer un initrd associé

et à rester figé devant son xterm pendant vingt bonnes minutes avec le doigt sur [Entrée] en relisant frénétiquement la ligne suivante :

Un reboot plus tard, divers tests de téléchargements massifs nous font chaud au cœur. Ce problème-là est réglé.

Ah, ah ! Enfin ! La machine est là, elle est stable, nous allons pouvoir comm[reboot intempestif].

Pensez-y, la prochaine fois que vous croisez une voyante, ne lui manquez pas de respect, parlez-lui un peu, demandez-lui des nouvelles de la petite famille, donnez-lui un euro ou deux en lui souhaitant bonne journée et bon courage pour son rude travail, faites mine de compatir, vraiment.

Nous voici devant un nouveau comportement cauchemardesque. Je résume :

Zone0 peut rester up plusieurs jours sans problèmes lorsqu’elle " ne fait rien ".

Lorsqu’elle a de l’activité, c’est-à-dire que tous les domUs sont chargés, translatés, accessibles depuis l’Internet et qu’ils génèrent du trafic, elle reboote de manière aléatoire au bout de plusieurs heures ou plusieurs jours. Le comportement n’est pas reproductible.

Le reboot ne produit aucune forme de log, syslog est désespérément muet lorsque le bug se produit.

Son load average est quasi nul.

Les coupables potentiels, après plusieurs heures d’expériences, sont :

Un mauvais refroidissement entraînant une température excessive.

ipvs : n’ayant jamais vu Å“uvrer ipvs dans une architecture Xen, nous envisageons la possibilité d’un bug engageant ipvs et les interfaces virtuelles montées par Xen. Mais, je vous l’accorde, ce n’est que pure supposition.

Le BIOS de la machine : un bug lié au BIOS ? Pourquoi pas ! Les architectures 64 bits en production ne sont finalement pas légion, encore moins avec les instructions VT (http://en.wikipedia.org/wiki/X86_virtualization) activées.

Pour écarter la première hypothèse, une seule solution : installer lm-sensors pour connaître la température du système en temps réel, en espérant que notre système soit supporté, bien que le noyau Xen ne soit pas tout récent. Les premiers tests suggèrent des capteurs intégrés dans le Super-I/O (un Winbond W83627HF). Super, se dit-on naïvement, c’est supporté depuis longtemps, ça va marcher tout seul.

Sauf que… CPU à 0.0 volt, ventilateurs tous arrêtés, température système 127 degrés Celsius. Soit la machine vient de brûler, soit quelque chose cloche dans les mesures. Le serveur répondant toujours, c’est fatalement les mesures qui sont fausses, et il faut se rendre à l’évidence : les capteurs du W83627HF ne sont pas connectés. Peut-on envisager que SuperMicro ait bêtement omis cette fonctionnalité ? Impensable, pas le genre de la maison. Il y a forcément une explication, encore faut-il la trouver à tâtons dans l’obscurité.

Une version plus récente de sensors-detect, le script de détection des capteurs, semble éclaircir la situation. Si celle-ci indique toujours la présence du W83627HF, elle trouve également un deuxième composant de mesure : un Winbond W83793G, composant de mesure dédié, qui était passé sous le radar la première fois, car trop récent. La présence du W83793G explique pourquoi les capteurs du W83627HF ne sont pas branchés : SuperMicro a fait le choix d’un composant de mesure dédié, plus précis et plus fonctionnel que les capteurs intégrés au Super-I/O. Tout est clair maintenant.

Notre joie est cependant de courte durée quand nous découvrons que le support pour le W83793G n’a été rajouté que dans le noyau 2.6.20. Notre noyau Xen 2.6.18 n’est simplement pas assez équipé. Mais pas de panique, il est tout à fait possible de porter ce genre de pilote vers une version antérieure du noyau, et c’est exactement ce que nous avons fait, avec succès. Une fois le pilote chargé, il ne reste plus qu’à ajuster le fichier de configuration (/etc/sensors.conf) pour notre carte SuperMicro. Le manuel de la carte se révèle un précieux allié dans cet exercice et un quart d’heure plus tard, nous avons sous les yeux les résultats suivants :

Vous trouverez le sensors.conf associé à cette adresse : http://khali.linux-fr.org/devel/lm-sensors/sensors-Supermicro-PDSMi+.conf.

Verdict : le patient est en bonne santé. Les voltages sont tous corrects, les ventilateurs ronronnent et la température d’environ 60 degrés Celsius est somme toute raisonnable pour un boîtier 1U. Une conclusion qui nous renvoie à nos chères études : si la température n’est pas en cause, de quelle maladie exotique mystérieuse souffre donc notre serveur ?

Si nous pouvons intervenir sur ipvs à distance, ne disposant pas de module IPMI sur notre serveur, l’upgrade de BIOS lui, devra se faire sur place. Il est donc indispensable de correctement préparer l’intervention.

Nous nous rendons sur la page http://www.supermicro.com/support/bios/ où, munis des informations livrées par la section Base Board de dmidecode, nous téléchargeons le fichier zip correspondant. Comme d’habitude, et bien malheureusement dans ce genre de situation, les upgrades se font par le biais d’un programme DOS. Au moins, il ne s’agit pas d’un exécutable Windows-only, c’est déjà ça. Notre machine ne disposant pas de lecteur de disquettes, nous entreprenons donc de générer un live CD FreeDOS qui contiendra notre nécessaire de secours.

En suivant scrupuleusement les informations publiées sur le wiki de FreeDOS, nous téléchargeons tout d’abord l’image iso fdfullws.iso à cette adresse : http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/fdfullws.iso, puis exécutons :

Reste à graver l’iso générée, freedos.iso à l’aide de votre logiciel de gravure favori. C’est prêt. Afin de vous assurer que votre image iso est correcte, testez-la à l’aide, par exemple, de QEMU ou KVM :

Oh, une petite " astuce ", j’ai passé 20 minutes à comprendre que le CD-ROM est désigné par la lettre X:. Je sais pas pour vous, mais ça doit bien faire 10 ans que j’avais pas touché un DOS.

On est prêts, on y croit. Taxi !

À la lumière des néons de RedBus Interhouse, nous faisons fébrilement booter le serveur sur le live CD, et exécutons, comme nous l’explique le fichier readme.txt contenu dans l’archive .zip, les commandes suivantes :

Après quelques minutes assez stressantes, la mise à jour est terminée. Les données du BIOS sont évidemment réinitialisées. Nous réactivons donc le support des instructions VT et redémarrons la machine. Upgrade réussi.

Nous l’avons dit plus haut, nous avons identifié deux coupables potentiels, le BIOS et ipvs. Pour rappel, le choix du load balancer ipvs avait été dicté lors de la configuration initiale de la machine (voir GLMF #100) pour la simple raison que, d’aucune façon, nous n’avions réussi à faire fonctionner la redirection de port de l’IP publique du serveur vers les domUs. Pour rappel toujours, cette architecture était imposée par le fait que nous ne disposons que d’une seule IP publique, mais avons décidé de séparer les services en quatre domUs différents. Pour rappel enfin, nous nous étions dit, et nous nous allons bientôt comprendre que c’était une erreur, que, puisque nous disposons de deux interfaces réseau distinctes, il serait du meilleur effet de bridger nos domUs sur l’interface eth1 dans l’hypothèse où un second serveur viendrait un jour s’y connecter, nous permettant ainsi de créer une sorte de LAN privé entre domUs.

Des heures durant, nous avons (ré)essayé l’intégralité des combinaisons possibles :

" domU en mode bridgé : network-script network-bridge / vif-script vif-bridge ;

" domU en mode natté : network-script network-nat / vif-script vif-nat ;

" domU en mode routé : network-script network-route / vif-script vif-route.

Avec à chaque fois, évidemment, une configuration IP adaptée. Aucune d’entre elles n’a daigné laisser durer la session TCP plus loin que la première négociation.

À cours de cartouches, la solution surgit de la bouche de Kmikze, membre du canal. Ce dernier nous dit qu’il possède une configuration fonctionnelle sur une base similaire. La seule différence réside dans l’utilisation de l’interface… dummy. Celle-là même que nous vous conseillions d’utiliser dans notre précédent article si vous n’aviez pas la " chance " de posséder plusieurs interfaces. Ironie, quand tu nous tiens. Notons pour notre défense qu’un récent apt-get upgrade montre que les packages xen* remplacent les appels aux network-scripts network-bridge par network-dummy.

Après avoir automatisé le chargement du module dummy, nous renseignons donc le fichier /etc/xen/xend-config.sxp avec les valeurs suivantes :

Voici un exemple de sortie du brctl show correspondant :

Reste à tester une redirection de port classique à l’aide de Netfilter :

Et à vérifier, incrédules, cette translation de port :

En un mot comme en cent : pardon Krusty.

Voici la version définitive de notre script d’initialisation de Netfilter, comprenant filtrage et NAT :

Et notre /etc/modules :

Vous noterez dans ces deux fichiers les particularités liées à l’immonde protocole FTP. Un jour, l’humanité s’éveillera, un jour…

C’est un peu par hasard que nous avons découvert un troisième coupable potentiel. En même temps que nous réparions notre machine, un autre membre du canal, dzen, effectuait des tests de charge dans une configuration similaire à la nôtre avec un dom0 Linux et plusieurs domUs NetBSD. Ce dernier nous a fait savoir que son serveur de test avait subitement rebooté au bout de deux jours. À peu près dans le même temps, alors que j’utilisais une console VNC branchée sur un des domUs NetBSD, sous mes yeux, a lieu un kernel panic de cet OS invité, et l’arrêt sur ddb, le débuggeur noyau que nous avons activé, nous indique que c’est le driver ne2000 qui vient de faire crasher notre domU.

Rappel, le choix de l’émulation d’une carte ne2000 sur les domUs OpenBSD et NetBSD est lié au fait que le driver du contrôleur présenté par défaut par Xen/QEMU, re0 pour une Realtek 8139, fonctionnait extrêmement mal. Au bout de quelques secondes de transfert, ce dernier stoppait toute transaction et nous affichait des watchdog timeout.

À l’époque de la mise en place du serveur, NetBSD 4.0 était encore une release candidate. Aussi, nous avions opté pour la sûreté et avions installé des versions 3.1 sur les domUs gcu et www2, mais à la lecture de certains threads sur le sujet watchdog timeout sur les listes de diffusion NetBSD, il semblait que des correctifs avaient été apportés dans la branche 4.0. De plus, en janvier, lorsque nous avons retrouvé notre serveur, NetBSD 4.0 était releasé. Aussi, nous entreprenons une mise à jour de l’OS.

Pour réaliser cette opération, nous allons utiliser la méthode binaire. Téléchargeons tout d’abord les sets binaires :

Effectuons quelques backups :

Mettons d’abord à jour le noyau :

Notez que nous choisissons la version NOACPI correspondant à la directive acpi=0 du fichier de configuration du domU. Ce choix est dicté par diverses documentations.

Il est évidemment nécessaire de rebooter sur ce nouveau noyau pour s’assurer que toutes les nouvelles fonctions des sets que nous allons décompresser sont bien supportées. Nous pouvons alors mettre à jour l’espace utilisateur :

Le nettoyage des fichiers dépassés, la mise à jour d’/etc, l’indexation des nouveaux fichiers installés, en un mot, la mise à jour post-installation, se fait à l’aide de l’outil etcupdate. Son utilisation est la suivante :

Le switch -s spécifie l’endroit dans lequel l’outil pourra trouver la version témoin d’un /etc à jour. S’ensuit alors une série de questions parfaitement explicites, essentiellement des diffs entre les fichiers présents sur votre système de fichier et les fichiers témoins. À la fin de ces comparaisons, etcupdate éliminera les fichiers dépassés (liens, bibliothèques, binaires…), recréera les index de la nouvelle arborescence, créera éventuellement de nouveaux devices dans /dev et, finalement, fera appel à l’outil postinstall afin de vérifier la cohérence de l’upgrade.

Si tout s’est déroulé correctement, un nouveau reboot sera nécessaire à la relecture de l’ensemble des scripts d’initialisation. Vous êtes maintenant à jour.

Notre système invité maintenant à jour, c’est un peu méfiants que nous remplaçons

par :

Comme nous l’avons déjà expliqué, l’absence de la directive model= implique que le contrôleur réseau qui sera présenté au domU sera de type Realtek 8139. Un reboot et un transfert plus tard, c’est les doigts crispés que nous lisons :

Fatigue…

À force de recherches, nous finissons par trouver un mail de Monsieur Manuel Bouyer (http://mail-index4.netbsd.org/port-xen/2006/10/25/0001.html), mainteneur de la branche Xen de NetBSD, qui explique qu’il n’est pas improbable qu’il subsiste un bug dans le driver re*, et que, par conséquent, il serait judicieux de le désactiver afin de laisser le driver historique rtk* prendre la main. Nous voici partis dans une nouvelle compilation de noyau.

Récupérons tout d’abord l’arbre des sources de NetBSD dans sa version 4.0 :

Puis préparons notre propre fichier de configuration pour notre noyau custom :

Commentons la référence au driver re* et assurons-nous que le driver rtk* est bien présent :

Préparons maintenant l’environnement de compilation :

Et démarrons la compilation effective :

À l’issue de cette compilation, un nouveau noyau est disponible, reste à le copier à la racine du système, puis à redémarrer :

Le dmesg devrait indiquer :

ifconfig devrait alors confirmer le fonctionnement à vitesse optimale :

C’est gagné.

Depuis cette opération, nos domUs NetBSD n’ont jamais plus montré aucun signe de faiblesse et sont effectivement capables d’effectuer des transferts jusqu’à 10 mégaoctets par seconde.

J’adore NetBSD. Vraiment. Pour un tas de raisons diverses et variées, j’adore ce système. J’aime aussi beaucoup pkgsrc, son système de packaging, qui, comme son OS d’origine, a été pensé pour être portable sur un maximum de systèmes possibles. Notons par exemple DragonFlyBSD qui en a fait son système de packaging officiel ou encore Draco Linux, une sorte de slackware utilisant pkgsrc. Pkgsrc est portable, oui, très propre aussi, mais pkgsrc est un cauchemar à upgrader. La target update existe bien, mais une seule erreur de compilation par exemple lors de l’upgrade d’une dépendance, et c’est toute la chaîne qui se retrouve bancale. Exemple : je dois upgrader, au hasard, ap22-php5, qui a comme dépendance php5, apache22, apr, apr-utils. Sachant qu’il existe également des versions de package plus récentes pour tous ces packages, la première opération qui sera effectuée sera de les pkg_delete afin de les upgrader. Seulement voilà, si, pour une raison ou pour une autre, une compilation de la chaîne échoue, ces packages, à l’instar de ce que réalise portupgrade sous FreeBSD, ne seront pas rollbackés, et les portes de l’enfer s’entrouvriront…

Une solution relativement élégante existe cependant : il s’agit de l’utilitaire pkg_comp. Ce script shell écrit par Julio " jmmv " M. Merino Vidal permet, via une configuration claire, de préparer un upgrade dans un environnement chrooté. L’idée consiste à préparer l’ensemble des packages sous forme d’archives binaires, utilisables entre autres par pkg_add ou encore pkg_chk. Une fois l’ensemble des packages binaires compilés, un upgrade massif à la façon d’un apt-get upgrade pourra être effectué à l’aide de pkg_chk. pkg_chk est également un script shell destiné à la gestion de packages pkgsrc. Lorsqu’il est invoqué avec les switches -u et -a, ce dernier vérifie le contenu du fichier /usr/pkgsrc/pkgchk.conf, lui-même généré avec l’option -g de pkg_chk, qui liste l’ensemble des paquets sur lesquels nous souhaitons qu’il y ait une opération. Si un package binaire est disponible et que ce dernier correspond bien à la version indiquée dans l’arbre pkgsrc, pkg_chk l’utilisera pour mettre à jour le paquet. Le cas échéant, pkg_chk invoquera une compilation classique du package, entraînant un risque potentiel de rupture de la chaîne de mise à jour. Pour cette raison, nous utiliserons l’option -b qui force pkg_chk à n’utiliser que des paquets binaires lors de la mise à jour.

La création de l’environnement chrooté est triviale. On crée tout d’abord un template de configuration destiné à pkg_comp :

On édite ensuite le fichier généré, ${HOME}/pkg_comp/default.conf afin de renseigner certaines valeurs propres à notre système :

Notons que :

" Le répertoire /usr/src doit exister, même s’il n’est pas peuplé de son contenu.

" L’environnement chrooté sera placé dans ${DESTDIR}, soit par défaut : /var/chroot/pkg_comp/default.

Créons maintenant l’environnement :

À l’issue de cette commande, il est désormais possible d’entrer dans le chroot par le biais de pkg_comp :

On peut évidemment passer des arguments à la suite de cette commande, par exemple :

En entrant dans le chroot, vous remarquerez certainement certains messages intéressants, par exemple :

En effet, lorsque pkg_comp est invoqué, ce dernier facilite grandement le travail de recherche de paquets binaires en utilisant directement l’arbre pkgsrc de l’hôte (l’hôte qui est en réalité un système invité dans notre cas… vous suivez toujours ?) :

Ce petit tour de passe-passe est effectué grâce au système de fichiers nullfs, qui permet, entre autres, de mounter une partie du filesystem dans une autre partie du même filesystem. Ainsi, dans notre cas, /usr/pkgsrc est par exemple mounté dans un sous-répertoire du chroot pkg_comp, /var/chroot/pkg_comp/default/usr/pkgsrc. Pratique.

Nous utiliserons la possibilité d’entrer dans le chroot pour, par exemple, ajouter quelques préférences au fichier /etc/mk.conf :

Assurons-nous que le package pkg_install est bien à jour dans notre chroot :

Et nous pouvons alors démarrer la séance de compilation massive :

À l’issue d’un – potentiellement très â€“ long moment, le répertoire /usr/pkgsrc/packages/All de l’hôte devrait être peuplé de l’ensemble des packages mentionnés dans le fichier /usr/pkgsrc/pkgchk.conf. Aussi, après vous être assuré qu’aucun ne manque à l’appel, vous pouvez sereinement invoquer pkg_chk de cette façon :

La mise à jour ne devrait alors pas prendre plus de temps qu’un simple apt-get upgrade sur une Debian ou équivalent.

Votre environnement chrooté étant parfaitement opérationnel, il ne vous reste, pour garantir une mise à jour régulière et sans risques de la machine cible, qu’à réaliser quotidiennement une vérification de type :

L’option -n de pkg_chk garantit qu’aucune opération ne sera menée, mais ce dernier vous résumera les actions qu’il aurait effectuées. Aussi, lorsque vous le jugerez opportun, vous pourrez sans risque demander une génération de nouveaux packages par le chroot en invoquant

puis mettre à jour l’environnement cible via pkg_chk -uab.

Cette technique n’est pas forcément triviale, mais elle est efficace et sûre.

Nos deux domUs NetBSD sont évidemment sortis du même moule, pire, le second n’est qu’un dd du premier. Petit fainéant que je suis, j’avais préféré cette option à une réinstallation complète. On ne se refait pas. De fait, les besoins de l’un et l’autre sont relativement similaires, d’autant que leur rôle à tous deux est de " servir du web ". Il nous a donc paru naturel de partager entre ces deux machines les deux arbres /usr/src et /usr/pkgsrc. Cette configuration est aisée. Sur le serveur NFS, il vous suffit d’ajouter au fichier /etc/rc.conf

de renseigner le fichier /etc/exports

puis de (re)démarrer :

Sur le client NFS, il faudra ajouter au fichier /etc/rc.conf

puis (re)démarrer :

Enfin, pour automatiser le montage de ces répertoires sur le client, on ajoute à sa fstab :

Et on mounte le plus simplement du monde :

Si on peut se rendre la vie un peu plus facile hein…

Oui, Zone0 est en ligne et en production depuis début février 2008. C’est elle qui sert le site principal, les sites tiers, nos mails, notre DNS primaire et master, ainsi que les serveurs FTP et CVS. Ce fut une expérience très enrichissante, bien qu’un peu (beaucoup) stressante… et coûteuse ! Mon seul regret sera de ne pas savoir avec exactitude lequel des trois suspects était responsable des reboots intempestifs du serveur. Bien que j’aie une petite préférence pour le BIOS, rien ne me permet d’affirmer que le problème venait effectivement de là. J’ajoute que, comme je l’expliquais dans le précédent article, j’utilise ipvs en milieu professionnel dans des conditions bien plus extrêmes qu’un simple serveur web/mail/DNS. Aussi, ne prenez pas s’il vous plaît cette expérience comme acquise. Là non plus, rien ne nous permet d’affirmer qu’il était d’une manière ou d’une autre incriminé dans le dysfonctionnement du serveur. Je finirais par de massifs remerciements à tous ceux qui sont intervenus, directement ou indirectement, dans cette aventure : je vous fais des bisous, plein.