Déploiement simplifié de stations sans disque avec FaDDeF
Philippe Depouilly
Institut de mathématiques de Bordeaux
351 Cours de Libération – F 33405 TALENCE Cedex
Zouhir Hafidi
Division Technique de l'INSU
BP 330 Zone portuaire de Brégaillon – 83500 LA SEYNE SUR MER Cedex
Résumé
Faddef (Fast Diskless Deployment Framework), est un ensemble de scripts qui permettent de déployer très rapidement et très facilement un ensemble de PC hétérogènes sans disque dur tout en exploitant pleinement les ressources locales du PC. Contrairement à des solutions comme Thinstation ou LTSP, le PC ne se comporte pas comme un terminal X avec XDMCP mais les applications sont bien exécutées localement : le client Faddef est en réalité un client mi-léger, mi-lourd. Pendant son utilisation toutes les écritures disque sont masquées par le module unionfs ou aufs, elles ne sont donc pas permanentes et disparaissent au reboot du PC à la manière d'un Live CD. La force de Faddef réside dans la simplicité des technologies utilisées, la facilité de déploiement et l'adaptation aux différentes distributions GNU/Linux du marché.
Mots clefs
Déploiement, diskless, unionfs, aufs.
Un ensemble d'administrateurs systèmes ont déjà présenté lors des JRES 2001 [1] puis 2005 [2] le choix d'un grand nombre de laboratoires de mathématiques qui privilégient l'utilisation de clients légers comme postes de travail pour les chercheurs. Ce choix est toujours d'actualité et afin de palier l'instabilité du marché des constructeurs de clients légers « clé en main », certains administrateurs s'orientent vers l'utilisation du projet Thinstation1.
Cependant, les limitations et contraintes liées aux solutions clients légers sous toutes leurs formes (gestion du son, vidéo, périphériques USB, graveurs, applications 3D ou OpenGL, etc.) amènent une demande croissante des utilisateurs d'avoir toutes les fonctionnalités d'un poste lourd. Nous nous sommes donc penchés sur une solution intermédiaire qui offre les fonctionnalités d'un poste lourd tout en préservant la qualité d'administration des postes légers : les postes « diskless ».
Comme nous travaillons sur les mêmes technologies, mais dans des environnements différents (les projets « diskless » des distributions GNU/Linux déployées sur chacun des sites), nous avons opté pour le développement d'un projet commun, FaDDeF, qui serait une solution universelle quelle que soit la distribution GNU/Linux déployée.
Avant d'aller plus loin, il est nécessaire de comprendre ce que l'on entend par poste « diskless ». En effet, on peut trouver ici et là des définitions qui prêtent à confusion, car non seulement tous les postes « diskless » ne fonctionnent pas de la même manière, mais en plus un poste « diskless » ne veut pas dire nécessairement un poste dépourvu de disques.
Selon Wikipedia anglophone2, un poste « diskless » peut se résumer à un poste qui :
démarre sur le réseau ;
n'a pas besoin d'un disque dur mais qui peut en avoir ;
exploite pleinement, peu, ou pas du tout les ressources locales.
Pour bien situer le type de poste « diskless » que nous utilisons, nous avons illustré dans la Figure 1 les différents types de postes de travail.
Figure 1 - Les différents types de postes de travail
On peut distinguer ceux qui démarrent en local et ceux qui démarrent sur le réseau. Les postes de travail qui démarrent en local peuvent le faire à partir d'un disque dur (c'est typiquement le cas des postes lourds), à partir d'un Live CD/DVD, ou depuis une mémoire ou un disque compact flash (on trouve dans cette catégorie des terminaux X, des boîtiers constructeurs appelés aussi clients légers, etc.).
Les postes de travail qui démarrent sur le réseau peuvent être classés essentiellement en deux catégories : ceux qui n'exploitent pas (ou très peu) les ressources locales (puissance de traitement et usage des périphériques) et ceux qui utilisent pleinement les ressources locales à la manière d'un poste lourd. Le système « diskless » que l'on va développer tout au long de cet article rentre dans le cadre de cette dernière catégorie.
Dans notre cas, un système « diskless » fonctionne de la manière suivante :
Chargement du noyau et d'un ramdisk initial via le réseau.
Montage de l'arborescence racine en lecture seule (readonly root) via un protocole réseau (souvent NFS).
Initialisation de l'environnement « diskless ».
en apparence, fonctionnement identique au poste lourd avec moins de bruit ;
pleine exploitation des ressources matérielles locales (puissance CPU, RAM) notamment pour faire des traitements lourds (par exemple du calcul scientifique) ;
meilleure prise en charge des périphériques locaux que les clients légers (son, graveur, etc.) ;
meilleure prise en charge logicielle que les clients légers (3D, OpenGL, fontes, etc.).
gestion centralisée : tout le travail se fait sur une machine de référence et un serveur donc gain de temps conséquent ;
pas besoin de serveurs de terminal (XDMCP par exemple) comme c'est le cas pour la plupart des clients légers ;
déploiement simplifié : on déballe le poste de travail, on récupère l'adresse MAC pour une configuration sur le serveur (inscription dans le DHCP, inventaire), et on met en route ;
portabilité : pas besoin d'avoir un parc de machines homogènes. L'hétérogénéité est gérée nativement par une configuration à la volée du poste de travail au moment du démarrage pour peu que le matériel soit reconnu par la distribution GNU/Linux en usage ;
sécurité : l'arborescence racine est montée en lecture seule ce qui empêche toute modification ou altération. Les écritures se font en RAM et sont donc volatiles ;
coût de possession optimal.
requiert des configurations matérielles « assez » récentes et « assez » généreuses notamment en RAM (2 Go minimum) ;
dépendance vis à vis du réseau, nécessité d'un serveur FaDDeF connecté en Gb/s ;
limité aux distributions GNU/Linux (car basé sur des modules propres à ce système). Nous n'avons pas prospecté autour d'autres familles de systèmes d'exploitation telles que Windows, BSD ou Solaris.
FaDDeF (Fast Diskless Deployment Framework) est un système de déploiement rapide et simplifié de systèmes GNU/Linux sur des postes de type « diskless » où toutes les ressources locales sont pleinement exploitées. L'idée est de reprendre les principes de base du fonctionnement d'un Live CD [3] et de les adapter au système « diskless ». Dans ce cas, au lieu de démarrer à partir d'un CD on démarrera à partir du réseau. Le système racine quant à lui est accessible en lecture seule au même titre qu'un Live CD.
Dans le cas d'un Live CD le système racine doit être préparé avant d'être gravé sur un support physique. Avec FaDDeF, nous utilisons une machine quelconque appelée machine de référence. Son système racine sera déposé sur un serveur NFS et exporté en lecture seule.
Durant l'élaboration du projet FaDDeF, nous nous sommes fixé un certain nombre d'objectifs qui nous ont guidé tout au long du développement du projet :
prendre en charge les différentes distributions GNU/Linux ou du moins les plus utilisées ;
supporter des machines avec des configurations matérielles différentes ;
éviter tant que possible d'utiliser des outils qui ne sont pas fournis en standard dans une distribution donnée ;
éviter au maximum d'appliquer des correctifs (patch) sur le noyau fourni en standard ;
s'interdire de modifier tout fichier faisant partie d'un paquetage afin de faciliter les mises à jour ;
adapter la solution à différentes situations (utilisation en laboratoire, en enseignement, lors de conférences, sur un cluster de calcul, etc.) ;
simplifier la mise en œuvre.
Dans cette phase de développement, il a fallu résoudre un certain nombre de problèmes notamment :
durant sa durée de fonctionnement, un système doit pouvoir écrire à différents endroits (/proc, /sys, /dev, /tmp, /etc/mtab, /var/log, /var/run, /var/lock, /var/tmp, etc.). Mais où peut-on écrire sachant qu'il n'y a pas de disque dur et que la racine est montée en lecture seule ?
certains scripts de démarrage/arrêt du système ne sont pas adaptés au fonctionnement du « diskless ». En effet, le service réseau doit être démarré très tôt dans la phase d'initialisation afin de pouvoir accéder à la racine. De même, lors de l'arrêt du système, il ne faut pas démonter le système de fichiers racine ;
certains fichiers (typiquement les fichiers de configuration) reflètent le matériel sur lequel le système a été installé à l’origine et qui n’est pas forcément le même partout.
Pour pouvoir écrire, nous allons utiliser la mémoire RAM au même titre qu'un Live CD. Nous aurons donc une partie du système de fichiers en lecture/écriture qui réside en mémoire ; l'autre partie en lecture seule réside sur un serveur NFS. Il ne reste plus qu'à trouver un moyen pour que le système puisse avoir une vision « unifiée » de ces deux systèmes de fichiers (une seule arborescence racine). Pour cela, plusieurs techniques existent dont unionfs [4] et aufs [5] qui se basent sur un mécanisme de recouvrement ou d'union et qui fonctionnent de la manière suivante :
une union est composée de deux ou plusieurs systèmes de fichiers appelés branches. Chaque branche peut être configurée pour être utilisée en lecture seule ou en lecture/écriture. Ces dernières doivent précéder les branches en lecture seule dans l'union ;
une entrée (fichier, répertoire, lien, etc.) est recherchée successivement dans toutes les branches en balayant de gauche à droite. Si la même entrée existe dans plusieurs branches alors c'est celle la plus à gauche de l'union qui sera utilisée ;
une création d'une nouvelle entrée se fait dans la première branche accessible en lecture/écriture ;
une modification d'une entrée dans une branche en lecture seule provoque la copie de celle-ci dans la première branche accessible en lecture/écriture, puis sa modification ;
une suppression d'une entrée dans une branche en lecture seule provoque la création d'une entrée spéciale dans la première branche accessible en lecture/écriture matérialisant la suppression.
Dans le cas de FaDDeF, une union est établie de la manière suivante : /union (union, rw) = /memory (tmpfs, rw) + /sysroot (nfs, ro) où /memory est le point de montage d'un système de fichiers ramdisk, /sysroot est le point de montage nfs en lecture seule du système de fichiers racine obtenu à partir de la machine de référence, et /union est le recouvrement des deux précédents systèmes de fichiers. /union constituera le système de fichiers racine durant la durée de fonctionnement du « diskless ».
Concernant les scripts de démarrage, on peut penser au premier abord qu'il suffit juste de les modifier ou de les patcher dans le « readonly root ». Le problème est que cela risque de compliquer les mises à jour surtout dans les distributions qui fonctionnent par paquetages car les modifications apportées peuvent disparaître. Nous avons donc opté pour des modifications à la volée lors du démarrage du « diskless » juste après la mise en place de l'union. En effet, toutes les modifications seront faites dans la RAM.
Enfin, pour les fichiers de configuration, notamment du matériel, nous avons opté également pour une reconfiguration à la volée en s'appuyant sur udev. D'autres paramètres de configuration tels que le choix du clavier ou de la langue peuvent être passés en ligne de commande au noyau. En effet les « diskless » sont facilement paramétrables.
La mise en œuvre d'une solution « diskless » avec FaDDeF est très simple. Nous aurons besoin d'au moins un réseau local 100 Mb/s ou plus, commuté, d'une machine de référence et d'au moins un serveur comme le montre la Figure 2. Les scripts FaDDeF permettant de préparer l'environnement « diskless » peuvent être téléchargés à partir de l'URL suivante : http://projets.mathrice.org/faddef/. Actuellement, FaDDeF fonctionne pour les distributions Fedora, Mandriva, Ubuntu et CentOS.
Figure 2 - Mise en œuvre des « diskless » avec FaDDeF
Tout d'abord, installez votre distribution préférée, supportée par FaDDeF, sur la machine de référence. La machine de référence peut être un PC de bureau, un PC portable, ou même une machine virtuelle. Configurez à votre guise cette machine selon vos besoins. Si nécessaire paramétrez l'accès aux répertoires de base des utilisateurs, le système d'authentification, ou tout autre dispositif dont vous avez besoin comme si vous alliez mettre en place un poste lourd.
La deuxième étape consiste à préparer au moins un serveur NFS et PXE/DHCP/TFTP (se référer au site FaDDeF pour des détails techniques concernant la configuration de ces services). Depuis le serveur NFS, exécutez le script mkreadonlyroot.diskless qui va copier l'arborescence racine depuis la machine de référence et y placer les scripts d'initialisation FaDDeF. Exécutez le script mkinitrd.diskless qui va générer le ramdisk initial nécessaire à la création de l'union et à la configuration du « diskless ».
La dernière étape consiste à démarrer vos PC « diskless ».
Pour maintenir votre installation FaDDeF au cours du temps (mise à jour, installation de nouveaux paquetages, modifications, etc.), il suffit de suivre le schéma présenté dans la Figure 3. À noter que pour ajouter un paquetage, il suffit de faire un chroot dans l'arborescence racine sur le serveur NFS, de l'installer et il sera instantanément disponible sur tous les postes « diskless ».
FaDDeF est actuellement utilisé dans les endroits suivants et pour certains depuis quelques années :
Institut de mathématiques de Bordeaux (laboratoire, bibliothèque) : le laboratoire utilise cette solution depuis 2006, avec deux serveurs FaDDeF fournissant plusieurs versions d'une distribution Mandriva pour un parc de 200 postes clients. Les serveurs sont des machines dotées de 4 Go de RAM, d'un processeur Xeon 32 bits, connectées sur un réseau commuté en Gb/s. Les serveurs ont une charge CPU à peu près nulle (service NFS en lecture seule). Nous avons constaté une surcharge du trafic NFS lorsque les serveurs étaient connectés en 100 Mb/s (que les postes clients soient en 100 Mb/s ou 1 Gb/s). Actuellement, les utilisateurs exploitent au quotidien des logiciels de visualisation tels que Visit ou Paraview, des environnements de développement, des logiciels commerciaux de calcul formel ou de calcul scientifique numérique, etc. ;
Laboratoire de mathématiques Paul Painlevé de Lille (laboratoire, enseignement, bibliothèque) : FaDDeF est utilisé dans le laboratoire depuis 2006. Actuellement le parc compte plus de 200 postes « diskless » et la distribution utilisée est Fedora. Le serveur NFS est un server NetApp FAS250 en Gb/s. Les « diskless » utilisent un réseau commuté 100Mb/s.
UFR des Sciences et Techniques, Université François Rabelais de Tours (salles de cours et salles en libre accès) : en plus d'un usage classique tout au long de l'année sur 100 postes dans 5 salles, FaDDeF est utilisé de manière particulièrement astucieuse afin d'installer une seule fois Windows. Pour cela, une image VMware est préalablement déposée sur le disque local, habituellement non utilisé, puis elle est exécutée automatiquement dans l'environnement FaDDeF. En revanche, deux des trois salles ont un lien montant en 100 Mb/s vers le cœur de réseau et l'on perçoit alors un goulot d'étranglement, comparativement aux trois autres salles pour lesquelles le lien montant est de 1 Gb/s ;
Institut d'Études Politiques de Lyon (salle de libre accès du service documentation) : le service de documentation de l'IEP met à disposition une vingtaine de machines sous FaDDeF comme postes en libre accès offrant un environnement bureautique et un accès aux ressources documentaires ;
CREMI Université Bordeaux 1 (salles de cours) : le bâtiment CREMI (enseignement mathématiques et informatique Bordeaux 1) a déployé FaDDeF pour plusieurs salles d'enseignement (plus de 100 postes sur deux serveurs). Il a été indispensable de déployer un système de répartition de charge entre les serveurs (avec LVS) car une montée en charge considérable sur le serveur NFS a été constatée lorsque plusieurs postes dans différentes salles démarrent quasiment simultanément.
Ces retours d'expérience nous montrent que FaDDeF se comporte très bien au quotidien (performance constatée sur les postes des utilisateurs) mais qu'il est important de bien concevoir le réseau et le service NFS lorsqu'il est exploité dans le cadre de salles où les postes accèdent simultanénement à un grand nombre de fichiers (telles que des salles d'enseignement).
Notons que les clients « diskless » sont paramétrables à travers leurs fichiers de configuration PXE et il est donc possible d'utiliser les postes « diskless » dans diverses situations, notamment pour la mise en place d'une salle de machines lors de l'organisation d'une conférence, ou encore pour faire des travaux pratiques en administration système et réseau en donnant un accès root aux étudiants sans trop de risque et avec moins d'efforts de préparation.
Le déploiement de parc avec des postes « diskless » et en particulier avec FaDDeF est possible si l'adminitrateur maîtrise son réseau (comme le service DHCP ou bien la qualité de commutation) et les impacts en termes de sécurité (postes en libre accès ou postes dédiés aux chercheurs). En effet, chaque poste après démarrage peut monter des données utilisateurs, la plupart du temps à travers NFS, tout comme un poste lourd. Il est donc préférable que l'accès à ces données soit bien contrôlé. Pour cela, nous préconisons un service authentifié et chiffré (par exemple avec NFSv4 et Kerberos). Le déploiement de solutions facilitant l'administration d'un parc telles que FaDDeF implique donc un contexte favorable. Par exemple, nous pouvons difficilement défendre le déploiement de cet outil dans le cadre de réseaux épars, non maîtrisés, avec un parc méconnu, etc.
C'est aussi pour cela que FaDDeF est pour nous la concrétisation d'une organisation du travail favorable (comme la maîtrise des acquisitions de matériels). FaDDeF ne permettra pas de palier une méconnaissance de son réseau et de son parc. En revanche, l'apport conséquent dans l'administration au quotidien et dans le service apporté à l'utilisateur a été un argument nous permettant de proposer dans nos laboratoires respectifs une certaine vision de la gestion d'un parc informatique, c'est à dire un service mutualisé, performant, plus proche des besoins des utilisateurs, plus proche du poste de travail du chercheur et de l'évolution des modes de travail.
FaDDeF est un projet très utile car il permet de déployer un nombre important de postes de travail « diskless » tout en réduisant le travail de gestion et d'administration de ces machines. FaDDeF ne nécessite pas des moyens importants pour sa mise en œuvre, il suffit juste d'avoir une machine de référence et un serveur. Il se résume à deux scripts, l'un pour préparer l'arborscence racine qui va être utilisée par les postes « diskless » et l'autre pour créer un ramdisk initial nécessaire au démarrage du poste « diskless ».
FaDDeF est en production depuis longtemps dans un certain nombre de laboratoires et les retours sont positifs aussi bien de la part des utilisateurs des postes « diskless » que de la part des personnes qui les administrent.
Denis Auroux, Jean-Luc Bellon, Philippe Depouilly, Joel Marchand et Albert Shih, Clients Légers. Dans Actes du congrès JRES2001, pages 37-49, Lyon, Décembre 2001.
David Bonnafous, David Delavennat, Philippe Depouilly, Zouhir Hafidi, Gérard Henry, Joel Marchand, Bernard Perrot, Albert Shih, Les clients légers quatre ans après. Dans Actes du congrès JRES2007, http://2007.jres.org/articles/75.pdf
Scientific Linux Live System, http://www.livecd.ethz.ch/
Unionfs: A Stackable Unification File System, http://www.filesystems.org/project-unionfs.html
Advanced multi layered unification filesystem, http://aufs.sourceforge.net/
1http://www.thinstation.org/
2http://en.wikipedia.org/wiki/Diskless_node