Debian Wheezy chez Pilot Systems

Généralités

Tout d'abord, un grand bravo aux développeurs Debian pour avoir réalisé, une fois de plus, une distribution d'une très grande qualité.

La Debian Wheezy contient un très grand nombre de nouveautés (comme le support multiarch ou l'intégration des backports à l'archive principale), qui ont été largement analysées sur le Web. Cet article va se concentrer sur les nouveautés qui concernent directement notre activité, à savoir l'hébergement de machines virtuelles et les applications Web en Zope/Plone et en Django.

Au niveau Xen et noyau

La squeeze contenait Xen 4.0 et un noyau Linux en 2.6.32, tandis que la Wheezy contient Xen 4.1 et un noyau Linux en 3.2.

Le premier changement de taille est le passage de la pile d'outils xm à la pile d'outils xl pour gérer Xen. La pile xm est toujours disponible, mais obsolète. Ce changement est principalement technique, et permet d'uniformiser et de simplifier les différentes manières de communiquer avec l'hyperviseur.

Deux autres améliorations significatives ont été apportées :

1. Il est désormais possible de changer, à chaud, le nombre de CPU d'une VM, comme on le pouvait jusque là avec la RAM. On peut spécifier, via l'option maxvcpus du fichier de configuration de la VM, un nombre maximum de CPU virtuels et il sera alors possible de faire varier le nombre de CPU alloués à la machine de 1 et ce nombre, en cours de vie de la VM, sans avoir à la rebooter.
2. Nous utilisons LVM2 sur le DOM0 pour gérer l'espace disque alloué aux différentes VM. Avec la pile Xen/Linux de la Debian Squeeze, il était nécessaire, après un redimensionnement du volume logique, de redémarrer la machine virtuelle pour que le noyau prenne en compte la nouvelle taille. Avec la pile Xen/Linux de la Debian Wheezy, ce n'est plus nécessaire. En combinant donc LVM2, les nouvelles version de Xen et de Linux, et resize2fs il est désormais possible d'ajouter de l'espace disque à chaud.

En résumé, grâce aux nouvelles version de la Wheezy, il nous est possible de modifier, dans certains limites, l'ensemble des ressources (CPU, disque et RAM) allouées aux machines virtuelles, à chaud, sans aucun redémarrage.

Au niveau des applicatifs

La Debian Wheezy contient des nouvelles versions de la quasi-totalité de ses paquets. Nous allons nous concentrer sur ce qui nous concerne le plus à Pilot Systems :

1. Python : la Debian Wheezy fournit la version 2.7 de Python par défaut, et la version 2.6 reste disponible.
2. Django : la Debian Wheezy fournit la version 1.4 de Django, qui était déjà disponible dans les backports de la Squeeze.
3. Zope : la Debian Wheezy fournit la version 2.12 de Zope (nécessaire pour Plone 4.0). La version 2.13 de Zope (nécessaire pour Plone 4.3) est elle disponible depuis peu dans la Sid, et sera disponible en backports pour la Wheezy d'ici quelques jours.
4. PostgreSQL : la Debian Wheezy fournit PostgreSQL en version 9.1, contenant un grand nombre de fonctionnalités, comme le hot standby. Nous utilisions déjà la version 9.1 sur beaucoup de nos projets, en utilisant le backport pour la Squeeze, mais il est toujours préférable (en particulier pour la rapidité des mises à jour de sécurité) d'utiliser la version officielle, ce que nous pourrons désormais faire.

Tests préalables

La migration d'un parc comme celui de Pilot Systems (contenant plusieurs centaines de machines virtuelles) vers Debian Wheezy n'est pas une opération anodine. Une première phase de tests a été réalisée, afin de s'assurer :

1. Du bon déroulement de la migration sur les hyperviseurs et les machines virtuelles.
2. De la bonne cohabitation des versions, pouvoir exécuter des machines virtuelles en Wheezy sur un hyperviseur en Squeeze et inversement.
3. Du bon déroulement du déploiement de nouvelles machines directement en Wheezy.

Toutes ces opérations ont été concluantes. Il est même possible, si nécessaire, d'utiliser un noyau Wheezy avec un espace utilisateur Squeeze, ou l'inverse, en prenant deux précautions :

1. La version de udev de la Wheezy fonctionne mal avec le noyau de la Squeeze ; si on souhaite utiliser une Wheezy avec un noyau Squeeze, il faut s'assurer que le paquet udev reste dans la version de la Squeeze.
2. Si on souhaite utiliser un noyau Wheezy sur une Squeeze, il faut faire attention aux modules (le paquet contenant les modules du noyau 3.2 n'est pas disponible sur la Squeeze).

Le cas de puppet

Un seul problème sérieux a été détecté lors des tests préalables : le client puppet de la Wheezy ne peut pas fonctionner avec le serveur puppet de la Squeeze.

Dans un premier temps, nous avons donc conservé la version Squeeze de puppet sur nos Wheezy de tests, puis, une fois les tests terminés, nous avons mis à jour le serveur puppet.

Migration des hyperviseurs

L'étape suivante a été la migration des hyperviseurs, pour bénéficier des nouvelles fonctionnalités de modification à chaud des ressource, ainsi que pour appliquer des mises à jour de sécurité sur les noyaux.

Cette opération a été réalisée de nuit, afin de limiter les coupures de services.

Particularités sur certains logiciels

1. Zope 2.10 : un certain nombre de sites que nous hébergeons sont sous Plone 3.x, donc sous Zope 2.10 qui nécessite Python 2.4. Nous allons devoir forward-porter Python 2.4 et Zope 2.10 pour la Debian Wheezy, comme expliquer dans un article précédent.
2. PostgreSQL : pour les projets où nous utilisions déjà la version 9.1 des backports, la migration sera transparente. Pour les projets où nous utilisions la version 8.4, il faudra utiliser la commande pg_upgradecluster pour convertir les bases. Cette opération nécessite une légère coupure de service, qui devra être traitée au cas par cas.

LVM snapshot et migrations risquées

Une petite astuce pratique pour les migrations risquées, lorsque c'est possible : effectuer un snapshot LVM (via la commande lvconvert) avant de tenter la migration. Si jamais la migration se déroule mal, il est possible de revenir à la version d'avant, de manière plus rapide et légère que si nous devions restaurer une sauvegarde de la machine virtuelle.