Ceci est une ancienne révision du document !
SIDUS est l'acronyme de Single Instance Distributing Universal System et se propose de simplifier à l'extrême l'administration de machines.
Son origine latine d'ensemble de corps stellaires est une allégorie : nous vous laissons trouver celle qui vous convient le mieux .
SIDUS a deux principales propriétés :
SIDUS n'est donc :
CQQCOQP est une démarche analytique simple vous permettant, simplement en lisant les réponses aux questions élémentaires Pourquoi ? Quoi ? Qui ? Où ? Quand ? Combien ? et Comment ? les tenants et les aboutissants de SIDUS.
Le temps d'administration système des équipements informatiques (noeud de calcul, poste personnel ou station de travail, machine virtuelle d'expérimentation) augmente avec leur nombre et leur diversité. Ainsi, tous ces matériels partagent essentiellement les mêmes fichiers, mais chacun sur son propre disque. Comment limiter le temps d'installation et d'administration des machines tout en conservant la flexibilité liée à leur destination ?
C'est le défi relevé par SIDUS (pour Single Instance Distributing Universal System), développée au Centre Blaise Pascal à l'origine essentiellement pour simplifier la tâche de l'unique administrateur système face à la gestion de centaines de machines de toutes natures pour toutes destinations (plateaux techniques multi-noeuds, multi-coeurs, GPU, etc).
Une approche permettant le démarrage en réseau et l'offre d'un système parfaitement générique pour toutes les machines.
La première version de Sidus date de février 2010, elle était à l'origine sur Debian Etch. Elle a suivi toutes les évolutions de la distribution Debian, socle essentiel (voire exclusif) du Centre Blaise Pascal.
Début 2013, SIDUS sert près de 90 noeuds permanents de cluster au CBP (jusqu'à 120 simultanés en fonction des prêts), des serveurs de GPGPU, des stations de travail multi-coeurs et des postes COMOD (pour Compute On My Own Device).
SIDUS s'adresse à tous ceux qui veulent se simplifier la tâche et qui :
Le Centre Blaise Pascal, hôtel à projets de l'ENS-Lyon dans le domaine du calcul et de l'informatique scientifiques, utilise SIDUS pour tous ses équipements dont l'uniformité doit être conservée le plus possible : un simple redémarrage doit suffire à replacer le système dans son état d'origine.
Le Pôle Scientifique de Modélisation Numérique (PSMN), centre de calcul de l'ENS-Lyon, utilise maintenant SIDUS sur une centaine de noeuds et prépare sa généralisation pour la mise en place de Equip@Meso (près de 200 noeuds supplémentaires).
Le laboratoire de Chimie utilise “COMOD” pour quelques postes de travail “à la demande”.
Les laboratoires de l'IGFL, du LBMC et du LJC utilisent “COMOD” : un cluster de 5 stations de travail gavées de GPU au LBMC, des stations graphiques à l'IGFL et au LJC.
L'université Joseph Fourier, dans le cadre de ses écoles thématiques sur le calcul scientifique, utilise depuis 2011 SIDUS pour l'infrastructure de travaux pratiques des auditeurs.
De 8 clients légers Neoware gonflés en CPU et mémoire et détournés début 2010 de leur vocation originelle, nous approchons les 120 machines au CBP utilisant ce système.
De quelques machines déployées à des fins expérimentales, le Pôle Scientifique de Modélisation Numérique utilise également SIDUS en production pour 400 noeuds. L'équipement informatique Equip@Meso d'environ 200 noeuds à lui tout seul, utilise également SIDUS comme socle.
Quelques chercheurs du laboratoire de chimie utilisent SIDUS via COMOD : la disponibilité en offrant la possibilité de déployer une machine complète et opérationnelle sur son poste de travail en quelques secondes.
Lors des école thématiques des Houches sur le calcul scientifique, SIDUS était servi à près d'une cinquantaine de machines simultanément.
Quant au prix du logiciel (question posé au dernier Scipy 2013), tous les composants qu'il utilise étant Open Source, SIDUS l'est aussi, ainsi que toutes les documentations associées ! SIDUS est donc sous licence CeCILL.
Si vous utilisez SIDUS, informez l'auteur et faites en la promotion !
Si vous voulez déployer SIDUS sur vos installations et vous faire aider, vous pouvez contacter l'auteur.
SIDUS se base sur une majorité de composants simples et éprouvés, disponible sur la majorité des distributions GNU/Linux.
Nous allons maintenant détailler comment installer le sien !
Nous devons préparer un peu notre système pour accueillir SIDUS. Pour cela, nous avons la main sur plusieurs services pour déployer nos clients : serveurs DHCP, TFTP, NFS. Vous entretenez de très bonnes relations avec votre service IT ou vous êtes assez libres pour accéder sans contraintes aux serveurs Ldap et DNS bien définis :
next-server
et le nom du binaire PXE, souvent nommé pxelinux.0
.pxelinux.0
, le noyau et le démarrage du système du client. Si nous avons besoin d'offrir des paramètres à tel ou tel client, nous contruisons un document spécifique dont le nom sera contruit à partir de son adresse MAC (préfixé de 01 et dont les : sont remplacés par des -)./srv/nfsroot/sidus
que nous allons installer notre système client.Sur nos configurations nous utilisons respectivement isc-dhcp-server, tftpd-hpa et nfs-kernel-server pour les serveurs DHCP, TFTP et NFS.
Regardons plus en détail la configuration des différents services que nous venons de citer :
next-server
est défini à l'IP 172.16.20.13
, c'est préférable de l'avoir dans le même sous-réseau : 10.13.20.13 est un choix plus judicieux.
Pour le serveur DHCP, dans le fichier de configuration /etc/dhcp/dhcpd.conf
:
next-server 10.13.20.13; filename "pxelinux.0"; allow booting;
Pour le serveur TFTP, dans le dossier /srv/tftp
, nous avons 3 fichiers et un dossier (pxelinux.cfg). Le fichier pxelinux.0
vient le paquet syslinux-common.
./pxelinux.0 ./vmlinuz-Sidus ./initrd.img-Sidus ./pxelinux.cfg
Dans le dossier pxelinux.cfg, nous avons le fichier “default”. Voici un exemple de fichier de démarrage précisant au client tout ce qu'il faut pour démarrer. Il comprend deux entrées, tmpfs et iscsi. Nous reviendrons plus loin sur cette seconde entrée iscsi :
vmlinuz-Sidus
initrd.img-Sidus
10.13.20.13
avec le point de montage /srv/nfsroot/sidus
DEFAULT tmpfs LABEL tmpfs KERNEL vmlinuz-Sidus APPEND console=tty1 root=/dev/nfs initrd=initrd.img-Sidus nfsroot=10.13.20.13:/srv/nfsroot/sidus,rsize=8192,wsize=8192,tcp ip=dhcp aufs=tmpfs LABEL iscsi KERNEL vmlinuz-Sidus APPEND console=tty1 root=/dev/nfs initrd=initrd.img-Sidus nfsroot=10.13.20.13:/srv/nfsroot/sidus,rsize=8192,wsize=8192,tcp ip=dhcp aufs=iscsi ISCSI_TARGET_IP=10.13.20.13 ISCSI_INITIATOR=iqn.2013-04.zone.sidus.target:default root=LABEL=ISCSI
Pour le serveur NFS, sa configuration prend un ligne dans le fichier /etc/exports. Ici, nous ouvrons un accès en lecture seule pour les machines dont l'IP est comprise entre 10.13.20.128 et 10.13.20.254 :
/srv/nfsroot/sidus 10.13.20.128/255.255.255.0(ro,no_subtree_check,async,no_root_squash)
Une fois ces 3 services DHCP, TFTP et NFS configurés, nous pouvons installer un Sidus complet.
Attention cependant ! Il faudra également prévoir une racine contenant les comptes des utilisateurs (par NFS version 4) et un processus permettant leur identification/authentification (par Ldap ou Kerberos). Nous avons ainsi déployé Sidus dans des environnements où ces services étaient fournis par des serveurs tierces tout comme des environnements complètement autonomes. L'installation d'un serveur OpenLDAP avec SSL ou d'un serveur Kerberos sortant de ce sujet, nous nous contenterons de préciser les fichiers de configurations clients qu'il nous conviendra d'adapter à notre infrastructure de site : ici, du Ldap pour identification/authentification et du NFS version 4 pour les dossiers utilisateurs.
Debootstrap permet l'installation d'un système dans une racine. Il exige plusieurs paramètres comme la racine d'installation, l'architecture matérielle, la distribution et l'archive FTP ou HTTP Debian à solliciter pour le téléchargement.
Warning : là commence la “spécialisation” de notre installation, à l'origine construite autour d'une distribution Debian. Cet outil est familier de toutes les distributions Debian-like : il sera donc disponible chez les dérivées du système à la spirale (à commencer par Ubuntu). Il sera cependant assez facile de réaliser cela sur les Redhat-like, Fedora intégrant par exemple un clone, Febootstrap, mais que nous n'avons pas testé.
Debootstrap accepte aussi en entrée une liste d'archives (vous savez que Debian est très tatillon sur les licences en séparant les archives en main, contrib et non-free), une liste de paquets à inclure et une liste de paquets à exclure. Nous aurions été ravi de pouvoir, ici, préciser la liste complète des paquets à inclure ou exclure, mais, malheureusement, cette approche est une voie sans issue : nous installerons donc, dès cette commande debootstrap
, un ensemble d'outils qu'il nous semble indispensable d'inclure dès le début (par exemple le noyau, des firmwares pour un support étendu de tous les matériels et un ensemble d'outils d'audit).
Nous avons par commodité défini des variables d'environnement correspondant à la racine de notre système $SIDUS
et une commande permettant l'exécution d'une commande par chroot
avec une option particulière d'installation de paquet. La variable $MyInclude
intègre la liste des paquets souhaités (séparés d'une virgule) et $MyExclude
la liste des paquets rejetés dont :
export SIDUS=/srv/nfsroot/sidus alias sidus="DEBIAN_FRONTEND=noninteractive chroot ${SIDUS} $@"
Nous avons définis les $MyInclude
et $MyExclude
suivants pour une architecture 64 bits AMD64 :
export MyInclude="adduser,apt,apt-utils,aptitude,aptitude-common,aspell,aspell-en,aufs-tools,bsdmainutils,btrfs-tools,busybox,ca-certificates,clusterssh,console-setup,cpio,cron,cups-pdf,debian-archive-keyring,dmidecode,dselect,emacs,environment-modules,ethtool,firmware-bnx2,firmware-linux,firmware-linux-nonfree,gnupg,gpgv,groff-base,htop,hwinfo,hwloc,iftop,ifupdown,info,initramfs-tools,install-info,iotop,iperf,ipmitool,iproute,iptables,iputils-ping,isc-dhcp-client,isc-dhcp-common,kmod,ldap-utils,less,libapt-inst1.5,libapt-pkg4.12,libboost-iostreams1.49.0,libcwidget3,libept1.4.12,libgcrypt11,libgdbm3,libgnutls26,libgpg-error0,libidn11,libkmod2,libncursesw5,libnet-ldap-perl,libnewt0.52,libnfnetlink0,libnss-ldap,libp11-kit0,libpam-ldap,libpipeline1,libpopt0,libprocps0,libreadline6,libsigc++-2.0-0c2a,libsqlite3-0,libssl1.0.0,libstdc++6,libtasn1-3,libudev0,libusb-0.1-4,libxapian22,linux-headers-3.2.0-4-amd64,linux-image-3.2.0-4-amd64,locales,logrotate,lsof,man-db,manpages,mbw,mtr,mutt,nano,net-tools,netbase,netcat-traditional,nfs-common,nscd,ntpdate,open-iscsi,openssh-server,pciutils,procps,python-ldap,readline-common,rsyslog,screen,scsitools,sdparm,ssh,ssmtp,sudo,tasksel,tasksel-data,tmux,traceroute,tshark,udev,usbutils,vim,wget,whiptail,xinit,python-html2text" export MyExclude="nano,exim,mysql-server,mysql-server-5.5,mysql-server-core-5.5,network-manager,apache2,apache2-mpm-worker,apache2-utils,apache2.2-bin,apache2.2-common,libapache2-mod-dnssd,libapache2-mod-php5,r-cran-fecofin,libmpich1.0gf,gerris,gspiceui,qucs,ktimetrace,kseg,ghdl,earth3d,libopenigtlink1,qtdmm,scilab-overload,gmsh,klogic,g++-doc,openturns-wrapper,xorsa,r-cran-rpvm,labplot,zygrib,libteem1,magnus,libcomplearn-dev,libtorque2,torque-common,torque-server,gridengine-client,gridengine-exec,gridengine-master,gridengine-qmon,gnuplot,gnuplot-nox,rtai,rtai-doc,libhdf5-dev,libhdf5-1.8,libgd2-xpm"
Dans le $MyInclude
, nous avons tous nos outils “de base”. Il est IMPERATIF de placer au moins le noyau linux-image-3.2.0-4-amd64
dans cette liste !
Par défaut, la commande suivante installe une version wheezy dans /srv/nfsroot/sidus pour une architecture amd64 à partir du miroir Debian http://ftp.debian.org/debian :
debootstrap --arch amd64 --components='main,contrib,non-free' --include=$MyInclude --exclude=$MyExclude wheezy $SIDUS http://ftp.debian.org/debian
A la suite de cette commande, nous devons prendre quelques précautions :
/usr/sbin/policy-rc.d
) :#!/bin/sh exit 101
Ou sous forme de commande :
printf '#!/bin/sh\nexit 101\n' > ${SIDUS}/usr/sbin/policy-rc.d chmod +x ${SIDUS}/usr/sbin/policy-rc.d
sidus mount -t proc none /proc sidus mount -t sysfs sys /sys mount --bind /run/shm ${SIDUS}/run/shm mount --bind /dev/pts ${SIDUS}/dev/pts
De manière à simplifier l'installation de paquets appartenant à la même famille, Debian a créé de nombreux meta-paquets, préfixés de “science” : science-chemistry désigne par exemple tous les paquets de chimie. La commande d'installation de tous paquets scientifiques se fait par une seule commande. Comme nous sommes épris de complétude, nous allons “aussi” rajouter les paquets “suggérés” (attention, l'option –install-suggests
n'est présente qu'à partir de la distribution Wheezy) :
sidus apt-get install --install-suggests -f -m -y --force-yes science-*
Durant l'installation, les phases les plus longues sont le téléchargement des paquets qui représente plusieurs Go (et dépend donc de la connectivité à Internet et aux miroirs officiels) et la configuration initiale de certains paquets (comme Perl et LaTeX).
Dans le meilleur des scénarii, cela prend 45 minutes pour un arbre complet de 32 Go.
Malheureusement, cette boulimie d'installation n'est pas sans effet. Des paquets s'installent encore un peu “mal” et une purge de quelques uns, notamment un installeur Matlab, nous hérisse le poil !
sidus apt-get purge -y -f --force-yes matlab-*
L'environnement local a une importance et, par défaut, rien n'est défini. Le défaut étant l'américain, nous paramétrons :
Les services NFS et Ldap exigent une petite configuration. L'importation des fichiers directement configurés est préférable.
Dans notre cas, nous avons choisi de les mettre tous sur un serveur Web http://MyServeur.MySite/sidus. Un wget
permet directement de les récupérer et les placer au bon endroit avec l'option -O
. Par exemple, pour le fichier nsswitch.conf
:
wget -O ${SIDUS}/etc/nsswitch.conf http://MyServeur.MySIte/sidus/nsswitch.conf
Ainsi, voici les fichiers à télécharger :
${SIDUS}/etc/nsswitch.conf
, ${SIDUS}/etc/libpam_ldap.conf
, ${SIDUS}/etc/libnss-ldap.conf
, ${SIDUS}/etc/ldap/ldap.conf
${SIDUS}/etc/default/nfs-common
, ${SIDUS}/etc/default/idmapd.conf
, ${SIDUS}/etc/fstab
${SIDUS}/etc/fstab
Comment partager SIDUS sans le dupliquer ? Nous allons nous inspirer de mécanisme utilisé dans certains LiveCD : le montage de la racine du système consiste en la superposition de deux couches, l'une lecture seule (le système NFSroot) et l'autre en lecture/écriture (un TMPFS dans le cas le plus simple). Les deux couches sont liées par la glue AUFS, le projet successeur de UnionFS.
Tout réside dans un seul et unique “hook” au démarrage : rootaufs, placé très tôt dans le démarrage initrd. Son principe repose sur cinq étapes :
/ro
, /rw
et /aufs
/ro
, /rw
/ro
et /rw
dans le dossier /aufs
/aufs
vers le point de montage originel
Ce script, rootaufs
se place dans ${SIDUS}/etc/initramfs-tools/scripts/init-bottom
rootaufs
manque dans la définition du fichier destination.
Le script originel a été inspiré par le projet rootaufs de Nicholas A. Schembri (http://code.google.com/p/rootaufs/). Il a été profondément modifié pour l'adapter à notre infrastructure : une version est disponible sur http://www.cbp.ens-lyon.fr/sidus/rootaufs :
wget -O ${SIDUS}/etc/initramfs-tools/scripts/init-bottom/rootaufs http://www.cbp.ens-lyon.fr/sidus/rootaufs chmod 755 ${SIDUS}/etc/initramfs-tools/scripts/init-bottom/rootaufs
Nous n'en avons pas encore fini pour disposer d'un système fonctionnel : nous allons créer un initrd
spécifique pour notre boot NFS:
aufs
dans ${SIDUS}/etc/initramfs-tools/modules
eth0
comme DEVICE dans ${SIDUS}/etc/initramfs-tools/initramfs.conf
sidus update-initramfs -k all -u
vmlinux-Sidus
est mentionné en lieu et place de vmlinuz-Sidus
comme noyau servi par le serveur TFTP.
Il suffit ensuite de copier les noyau et boot loader dans la définition :
cp ${SIDUS}/boot/vmlinuz-* /srv/tftp/vmlinuz-Sidus cp ${SIDUS}/boot/initrd.img-* /srv/tftp/initrd.img-Sidus
A l'origine, nous avons exploré la possibilité d'offrir un second partage NFS en lecture/écriture pour la persistance des modifications associées aux clients d'un redémarrage à l'autre. Cette version, bien que fonctionnelle, exigeait l'ouverture d'un partir NFS atomique pour chaque client avec ce qu'on imagine comme charge pour leur serveur !
Nous avons donc préféré une autre approche de persistance, sous la forme d'un disque réseau de technologie iSCSI, dont nous avons vu la définition dans notre fichier /srv/tftp/pxelinux.cfg/default
, avec la définition de LABEL=iscsi
. Avec cela, pour assurer la persistance, nous créons un partage iSCSI par client. Les paramètres de montage du disque iSCSI sont définis dans la commande en ligne.
Pour des raisons de simplicité, le volume offert porte l'IP du client et nous ne fournissons que le serveur de volume iSCSI. Des login et mot de passe d'accès par défaut sont dans le fichier rootaufs
.
/etc/hostname
/etc/resolv.conf
avec une définition persistente/etc/network/interfaces
: définir un loopback/etc/security/limits.conf
(indispensable dans un environnement HPC)/etc/fstab
avec l'entrée du serveur NFS des comptes utilisateursecho ASYNCMOUNTNFS=no >> ${SIDUS}/etc/default/rcS
/etc/modules
et regénérer le initrd
/etc/rc.local
un script permettant de récupérer l'adresse IP Ethernet et construire une adresse IP pour la carte Infiniband.Pour la majorité des cartes Nvidia, les paquets proposés dans la Debian Wheezy permettent une installation complète des pilotes propriétaires, des libraries OpenGL, Cuda et OpenCL.
Attention cependant si vous désirez utiliser simultanément l'ICD (Installable Client Loader) OpenCL d'AMD pour exploiter vos processeurs ET votre carte graphique : nous avons dû installer toute l'infrastructure pilote, Cuda et OpenCL pour le permettre.
Pour les cartes Quadro 2000M de portable, il semble que la dernière bouture “qui fonctionne” soit la version 319.60. Pour les cartes plus récentes, dont les GTX Titan, un pilote supérieur à la 319 est indispensable.
Dans tous les cas, le rétroportage des paquets Nvidia de Sid ou Experimental pour Wheezy fonctionne plutôt bien.
Pour la majorité de cartes ATI, les paquets proposés dans la Debian Wheezy permettent une installation complète des pilotes propriétaires, des libraries OpenGL, Cuda et OpenCL.
De manière à installer correctement SIDUS, nous avons été contraint de lier étroitement système hôte et chroot. Il est donc nécessaire de réaliser les opérations opposées du début d'installation de SIDUS.
umount ${SIDUS}/run/shm umount ${SIDUS}/dev/pts sidus umount /proc/sys/fs/binfmt_misc sidus umount /proc sidus umount /sys
cp /sbin/start-stop-daemon ${SIDUS}/sbin/start-stop-daemon
Si vous souhaitez que votre SIDUS chrooté démarre ses services (mauvaise idée), vous devez supprimer le hook correspondant.
rm -f ${SIDUS}/usr/bin/policy-rc.d
rm -r ${SIDUS}/run/* ${SIDUS}/tmp/*
lsof | grep ${SIDUS} | awk '{ print $2 }' | sort -u | xargs -I '{}' kill '{}'
L'administration d'une instance Sidus s'administre comme tout système chrooté : il y a cependant des précautions à prendre, toutes les fonctions d'administration n'exigeant pas les mêmes contraintes les unes des autres.
C'est certainement la fonction la plus courante. Le problème de la mise-à-jour est double :
/etc/init.d
: une séquence va donc tenter d'arrêter et redémarrer le service/proc
monté
Pour réaliser une mise-à-jour d'une instance SIDUS installée dans ${SIDUS}
en toute tranquillité, il suffit d'enchaîner les commandes suivantes :
mount --bind /dev/shm ${SIDUS}/dev/shm mount --bind /dev/pts ${SIDUS}/dev/pts chroot ${SIDUS} mount -t proc none /proc
chroot ${SIDUS} aptitude update chroot ${SIDUS} aptitude -y full-upgrade chroot ${SIDUS} aptitude clean
umount -l /proc umount -l ${SIDUS}/dev/shm umount -l ${SIDUS}/dev/pts lsof | grep ${SIDUS} | awk '{ print $2 }' | sort -u | xargs -I '{}' kill '{}'
La dernière ligne des commandes aval est une précaution pour éviter que des processus lancés dans l'instance tourne sur l'hôte.
Les images suivantes Sidus4Scipy2013 et Sidus4Client permettent de juger de l'efficacité de Sidus à offrir un environnement complet sur un poste de travail unique.
Ces deux images nécessitent toutes les deux l'outil de virtualisation Open Source VirtualBox disponibles sur les plates-formes Linux, MacOS X, Windows et Solaris.
L'instance SIDUS est intégrée dans la machine virtuelle sidus4scipy issue de l'importation de la machine Sidus4Scipy. Elle offre un bureau Gnome complet avec des outils Python présentés lors de Scipy 2013
La machine virtuelle sidus4client intègre la machine virtuelle minimale permettant de démarrer un client utilisant l'instance SIDUS. Après quelques secondes, un bureau Gnome s'ouvre.
Quelques éléments :
Il est très facile de repasser dans un mode “français” pour le clavier et le fuseau via les commandes
dpkg-reconfigure keyboard-configuration
dpkg-reconfigure tzdata
sidus dpkg-reconfigure keyboard-configuration
sidus dpkg-reconfigure tzdata
Il est aussi possible de démarrer l'instance sur une autre machine en sélectionnant dans la configuration de la machine virtuelle l'interface réseau que vous comptez utiliser (généralement eth0
),
Dans les deux cas, le forwarding doit être activé : /proc/sys/net/ipv4/ip_forward
mis à 1
.
— Emmanuel Quemener 2013/11/03 15:38