Fast Diskless Deployment Framework - Mathrice...root) via un protocole réseau (NFS, AFS, GFS, etc.)...

Mars 2006 [email protected][email protected]bordeaux1.fr

1

Fast Diskless Deployment Framework

mailto:[email protected]



2

Petite mise au point

• Un PC diskless est un PC :– sans disque

ou– dont les disques ne sont pas utilisés pour le

système (on dira alors que c’est du diskless++)




3

Classification des postes de travail

• Critère : puissance de traitement locale ou distante– Rien en local : TX, boîtiers constructeurs, PC diskless

(typiquement vieux PC recyclés avec LTSP)– Une infime partie en local (en général un navigateur) :

boîtiers constructeurs, PC diskless Thinstation/LTSP/...– Tout en local : Poste lourd (PC standard), PC

diskless/PC diskless++, PC stateless (cached clients)




4

Avantages du diskless « tout en local »

• Pour l’utilisateur :– en apparence, fonctionnement identique à un poste lourd

avec moins de bruit et zéro admin– Meilleure prise en charge des périphériques locaux que les

clients légers (son, graveur, etc.)

• Pour l’administrateur :– Gestion centralisée, portabilité, sécurité– Pas besoin de Terminal Servers (pas de XDMCP)– Pleine exploitation des ressources matérielles locales

(puissance CPU, RAM)




5

Inconvénients du diskless « tout en local »

• Nécessite des configurations matérielles « assez » récentes et « assez » généreuses notamment la RAM

• Dépendance visàvis du réseau




6

Principe de fonctionnement du diskless « tout en local »

• Ce qui se fait le plus souvent :– Chargement du noyau via le réseau

– Montage de la racine en lecture seule (readonly root) via un protocole réseau (NFS, AFS, GFS, etc.)




7

Cahier de charges

• Eviter le plus possible d’utiliser des outils qui ne font pas partie de la distribution standard

• Faciliter les updates :– Eviter de patcher le kernel– s’interdire de modifier tout fichier faisant partie d’un package

• Adapter la solution à différentes situations (labo, enseignement, conférence, calcul sur cluster, ...)

• Pouvoir porter la solution à d’autres distributions




8

Problématique du readonly root

• Certains scripts de démarrage/arrêt du système ne sont pas adaptés au readonly root

• Certains fichiers (typiquement de config) 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

• Durant sa durée de vie, un système doit pouvoir écrire : Où écrire ? Quoi ? Comment ?




9

Problème des scripts de démarrage/arrêt

• Au premier abord on se dit que le plus simple est de les modifier/patcher dans le readonly root– Problème : ceci complique les updates




10

Problème des fichiers de config

• Chaque client diskless doit pouvoir utiliser ses propres fichiers de config– Utiliser un système tel que clusternfs

• Problème : non adapté aux filers

– Générer à la volée les fichiers de config




11

Problème de l’accès en écriture

• Où écrire ?– Ramdisk– Tmpfs

– Montage réseau en rw

– Clé USB– Disque local




12

Problème de l’accès en écriture (suite)

• Quoi ?– /var (/var/log, /var/run, /var/lock, etc.)– /etc (/etc/mtab)– /dev– /tmp




13


• Comment ?– Avec de la cuisine :

• Mettre des liens symboliques dans le readonly root qui pointent sur des zones « writable » lors de l’initialisation du système

• Des tar.gz dépliés en mémoire• mount bind• ?




14


• Comment (suite) ? (si on regarde du côté des Live CDs)– Avec un sysème d’overlay « recouvrement » :

• Au niveau block device : cowloop, Device mapper snapshots

• Au niveau filesystem (en général du CopyOnWrite) : cowlinks, mini_fo, ovlfs, translucency, MapFS, unionfs




15

Solution retenue

• Utilisation de unionfs :– Overlay = partie « writable » sur tmpfs + / en ro

• Tout ce qui doit être modifié/patché le sera au moment de l’initialisation du diskless

• Les fichiers de config seront générés à la volée au moment de l’initialisation du diskless (autodétection, paramétrage)

• Les clients diskless sont paramétrés via les fichiers de config PXE




16

Implémentation

• Le diskless boote par PXE• Un noyau (standard) + initrd (fabriqué) sont chargés• Le initrd effectue les opérations suivantes :

– Chargement des modules nécessaires pour le réseau– Configuration du réseau par DHCP– Montage nfs ro du / (/mnt/nfs)– Montage d’une zône tmpfs (/memory)– Création d’un overlay unionfs (/union = /memory + /mnt/nfs)




17

Implémentation (suite)

– Si nécessaire faire certaines modifications avant de passer la main à init

– Récupération de certains fichiers comme /etc/resolv.conf– pivot_root

• Init lit /etc/inittab et appelle rc.sysinit• rc.sysinit fait appel à rc.readonly qui prépare le terrain

avant de rentrer dans le runlevel désiré (ajout, patch, ...)• Exécution des scripts rcX.d/ (démarrage des services)• Finir le processus de démarrage en exécutant rc.local




18

Déploiement du diskless « tout en local »

1.Préparer une machine qui servira comme point de départ :– Installer la distribution– Configurer le poste comme si c’était un poste

lourd (authentification, impression, logiciel additionnel, etc.)

– Tout mettre à jour




19

Déploiement du diskless « tout en local » (suite)

2.Préparer le readonly root selon les cas :– Readonly root = / de la machine initiale

• Mauvaise solution surtout si vous avez un filer

– Readonly root = une copie du / faite sur la même machine ou sur une autre machine (ex. un filer)

Un script permet de le faire




20


3.Créer l’image initrd nécessaire à l’initialisation du diskless pour une version donnée du kernel

Un script permet de le faire




21


4.Booter le client diskless :– Au préalable :

• Copier le kernel et l’image initrd sur votre serveur tftp

• Créer un fichier de config PXE pour le client• Configurer votre serveur DHCP pour répondre aux

requêtes PXE des clients diskless

– Power On




22

Paramétrage des clients diskless

• Il est possible d’utiliser les paramètres suivants dans les fichiers de config PXE :– NFSROOT, ETHERNET– RUNLEVEL, ONSERVICES, OFFSERVICES– LANG, KEYBOARD, MOUSE, EMULTHREE– XDRIVER, HSYNC, VSYNC, DEPTH, RESOLUTION,

DESKTOP– GUEST, PASSWD (utiles pour des conférences)– ROOT (utile dans l’enseignement d’admin réseau par ex.)




23

Le diskless++

• Possibilité d’utiliser des disques locaux :– Utile par exemple dans un cluster de calcul ou

juste pour récupérer des données– Par défaut :

• Les partitions swap sont automatiquement détectées et utilisées (sinon utiliser le paramètre NOSWAP)

• Les autres partitions sont automatiquement montées (sinon utiliser le paramètre NOHDD)




24

Portage sur les différentes distros

• FaDDeF repose sur 5 briques :– le module noyau unionfs– le script de création de l'image initrd– le script disklessrc exécuté par initrd– Busybox– les scripts déposés sur le serveur diskless avec

une empreinte minimale




25


• unionfs se compile sur les noyaux > 2.6.9• script d'installation pour les distribution FC,

RH, Mandriva• En cours pour Debian, Ubuntu et OpenSuse

10




26


• Le script de création de initrd fabrique un fichier image ext2

• Il crée les dossiers pour accueillir :– Busybox, les /dev de base, les modules des cartes

réseaux, le script disklessrc

• Porté sur Ubuntu/Debian, FC4, Mandriva et OpenSuse




27


• Busybox :– Binaire statique et autonome– Une soixantaine de programmes (modprobe,

udhcpc, hostname, shell, cut, grep, etc.)– Plateforme indépendant : un binaire pour toutes

les distributions




28


• Le script disklessrc repose sur Busybox, il est donc à 95% générique

• Avant de laisser la place à /sbin/init il a < 5 choses à faire : modifier inittab, fstab, mtab, positionner des infos sur la carte réseau

• Quelques lignes shells selon les distributions (< 5)




29


• La version actuelle cumule ces actions de base pour toutes les distributions

• La version suivante permettra de déposer un script dans /initrd qui sera exécuté avant /sbin/init

• A noter : le montage NFS du serveur se fait sur TCP pour plus de robustesse




30


• Les scripts déposés sur le serveur diskless permettent d'adapter le comportement pour un client diskless, sont portés pour FC4 et Mandriva, en cours pour Ubuntu/Debian et OpenSuse




31


• Une commande pour fabriquer l'image initrd : updateDiskless /racine 2.6.xy.z /depot :

• dépose un fichier initrd et une copie de vmlinuz de 2.6.xy.z

• Il suffit de copier ces fichier dans le dossier du serveur tftp et adapter pxelinux.cfg/default




32


• Une commande pour copier les fichiers scripts sur le serveur diskless : mkreadonlyroot /racine

• Ces scripts s'adaptent très facilement et sont peu nombreux (< 10) et très lisibles




33


• Les portages sont en cours• Ils doivent permettre une configuration d'un

serveur diskless en moins d'une heure (chrono) pour plusieurs distributions (actuellement Fedora, Mandriva, RedHat, Ubuntu, Debian et selon un sondage Mathrice, on y ajoute OpenSuse)




34

Conclusion

• Philosophie indépendante de toute distro• Implémentation technique spécifique à

chaque distro sur certains aspects• Avantages certains du diskless « tout en

local » • Elément à « surveiller » : unionfs




35

Ressources

• Scripts pour configurer le diskless :– https://svn.math.cnrs.fr/faddef – http://wiki.math.cnrs.fr

• Liens :– http://www.amutils.org/projectunionfs.html– http://www.linuxlive.org/– http://linux.web.psi.ch/livecd/



https://svn.math.cnrs.fr/faddef

http://wiki.math.cnrs.fr/

http://www.am-utils.org/project-unionfs.html

http://www.linux-live.org/

http://linux.web.psi.ch/livecd/

Fast Diskless Deployment Framework - Mathrice...root) via un protocole réseau (NFS, AFS, GFS, etc.)...

Documents

Transcript of Fast Diskless Deployment Framework - Mathrice...root) via un protocole réseau (NFS, AFS, GFS, etc.)...