FLASH INFORMATIQUE FI



Clients légers




Vittoria REZZONICO


Un client léger est un PC qui comporte moins de matériel qu’un PC de bureau standard et qui ne doit exécuter que peu de tâches, la plupart du traitement s’exécutant sur des serveurs. C’est assez flou comme définition ; essayons donc de préciser en quoi le client léger est plus petit qu’un PC standard :

  • Périphériques de stockage : le client léger ne comporte pas de stockage sur disque dur. Les données des utilisateurs n’y sont pas stockées, et les données temporaires (logs) non plus. L’OS est stocké sur une mémoire flash (en read-only) ou bien est téléchargé par le réseau.
  • Processeur : un client léger a un processeur peu puissant, parce que les tâches les plus gourmandes en CPU sont effectuées sur les serveurs.
  • RAM : le client léger a relativement peu de RAM.
  • Refroidissement : sans disque dur et avec un processeur peu puissant, le client léger ne nécessite pas de système de refroidissement actif ; il est donc silencieux  !

Historique

Au début, les clients légers étaient appelés Terminaux graphiques (graphical terminals), nom hérité de leurs ancêtres les Terminaux texte (text terminals). Pas très glamour comme nom, mais ces terminaux X (X terminals) étaient assez populaires dans les années 90. Vers 1997, Citrix et Microsoft ont créé un projet appelé Hydra qui permettait de se connecter à un serveur central depuis du matériel de type thin client. Le serveur crée en mémoire une session dédiée à l’utilisateur et les commandes qui normalement sont envoyées vers une carte graphique sont comprimées et envoyées au serveur central.

Depuis, les projets de clients légers sont restés latents et à ce jour peu de monde pense à une autre solution que SunRay quand on parle de client léger. Mais pendant cette pause, des projets peu connus ont eu le temps de mûrir.

Avantages des clients légers

Le premier avantage qui saute aux yeux est la gestion complètement centralisée d’un parc informatique : tous les clients légers utilisant la même image, il n’y a qu’une image à tenir à jour. Ceci réduit les coûts d’administration (une fois qu’on a trouvé un petit pool d’administrateurs avec les bonnes compétences) et d’entretien : moins de matériel (et surtout pas de disque dur) signifie moins de probabilité de panne. De plus, les clients légers sont plus faciles à sécuriser - comme tout parc homogène. Un autre point positif est la sécurité des données : rien n’est stocké sur le client, tout est stocké sur des serveurs centraux, ce qui rend presque nulle la probabilité d’une perte de données. En outre, un client léger est moins vulnérable au vol qu’un desktop ou un laptop, puisqu’il est assez inutilisable tout seul. Je n’ai pas abordé les avantages relatifs aux coûts : un client léger est peu coûteux et peu gourmand en électricité. De plus, il ne doit pas être remplacé au bout de 3-5 ans par souci de pannes et problèmes de garantie. Et si un client léger se casse, on le remplace sans se soucier des données. Même si d’un côté il est vrai que les coûts sont déplacés vers la partie serveur, un calcul attentif (incluant les coûts de climatisation, qui ne sont pas comptés quand la puissance de calcul est locale) indique que la solution client léger reste plus économique.
Ceci semble un miracle, et nous fait penser que le modèle standard avec des fat clients a une faille, ou du moins que quelque part, il y a du gâchis.
Normalement, la puissance d’une station de travail n’est pas exploitée à 100 %, le CPU étant au repos la plupart du temps. Dans un modèle thin clients la charge est partagée de façon plus efficace. De plus si une application est utilisée par plusieurs clients, elle n’est chargée en mémoire qu’une seule fois (si l’application le permet, mais on tendra à choisir ce type d’applications).
Le CPU est donc chargé ponctuellement. Si on prend en considération un parc informatique classique et qu’on regarde l’utilisation du CPU, on notera des pics sur chaque machine. Mais si on regarde la charge globale du parc de machines, on remarquera très peu de pics. C’est un résultat normal - il est très peu probable que tous les utilisateurs chargent leurs machines à 100% en même temps. La charge globale correspondra à une somme de plusieurs charges distribuées aléatoirement dans le temps. La charge totale sera alors distribuée autour de la charge moyenne, selon une loi normale (sortez vos cours de statistiques  !).
Mais l’avantage qui saute le plus aux yeux (ou plutôt aux oreilles) est l’absence de bruit côté client.
Au niveau écologie, en plus des économies d’énergie, on a des économies de matériel. Le système de serveurs derrière une architecture thin clients est remplacé tous les 3-5 ans (c’est d’habitude un serveur supplémentaire par rapport à un système de fat clients), et les thin clients ne le seront qu’en cas de panne. Un parc de stations engendre clairement plus de déchets dus au renouvellement du parc entier tous les 3-5 ans.

Désavantages

Le client léger n’est pas la solution miracle à tous les problèmes IT. Il est plus simple de gérer un PC standard que le serveur dédié aux thin clients et de plus, avec un seul serveur, on a un single point of failure. Pour configurer des serveurs pour les thin clients en failover, il faut plus de compétence que pour installer de simples PC. La preuve : un article sur comment installer un PC ne serait pas lu jusqu’ici.
Et si le réseau ne tient pas la route, l’infrastructure thin-client s’écroule. De plus, certaines applications ne peuvent pas tourner dans un environnement thin client. Je pense en particulier aux applications gourmandes en graphisme comme le multimédia, ou plus simplement certaines applications métier comme la CAO ou la visualisation de données scientifiques. Ou tout simplement, certaines applications sont faites pour un système où le client local a ses propres ressources (applications gourmandes en RAM ou qui nécessitent des périphériques spéciaux). Parfois, il est tout simplement impossible de faire tourner certains logiciels dans un environnement thin client à cause des bibliothèques partagées ou encore plus simplement à cause de problèmes de licences.
Un désavantage assez évident pour l’utilisateur est le mauvais support des périphériques : l’utilisateur ne sait pas trop ce qui se passe si on branche sur le client léger une caméra, une tablette pour dessiner ou un scanner USB.
Côté écologique, même si un PC standard génère plus de déchets, il peut être revendu ou donné plus facilement qu’un thin client.

Modèles thin clients

Au moment de la rédaction de cet article, je me permets de classifier les clients légers dans 3 catégories :

Solutions propriétaires, par exemple SunRay

Je peux dire que je ne connais pas énormément ce sujet, et que dans notre école il y a des personnes que l’on peut appeler expertes en la matière. On peut mentionner que le trafic est purement raster entre serveur et client, c’est-à-dire, seules les informations concernant l’affichage des pixels sont transmises.

Clients rdp, xdmcp, freenx ou nomachine nx

Il s’agit de systèmes qui chargent un OS qui ne fait qu’afficher une fenêtre de login sur un serveur d’applications. L’OS peut résider sur une mémoire interne au client ou bien être téléchargé depuis le réseau par PXE ou similaire. Dans cette catégorie il vaut la peine de citer le projet LTSP.

Clients Web

Le client léger ne fait que charger un navigateur. L’utilisateur peut accéder aux services à travers le Web. Cette solution est beaucoup poussée par Google. Le Web2.0 étant basé sur des technologies qui reposent sur le client (JavaScript, Flash), une certaine puissance est requise côté client. Par exemple, la visualisation de clips youtube est saccadée sur les ALIX, et certaines pages Web sont lentes. On peut choisir un client léger plus puissant, ou bien simplement spécifier des règles d’utilisation.
Dans cet article, je vais montrer comment on construit un environnement clients légers de type nx (NoMachine) et de type clients Web. Il est relativement simple de modifier l’installation de ces clients légers pour avoir un client rdp. Le projet LTSP, qui a été décrit dans l’article Agepolix fournit une solution client léger PXE - xdmcp clefs en main.
Passons maintenant à la partie pratique. Dans cet article, je vais juste donner les idées principales. Le code correspondant se trouvant à la page ou bien dans les liens cités.

Nécessaire

Pour répéter ce qui suit, vous avez besoin de deux ordinateurs connectés à un même réseau dont un a préférablement une connexion internet directe. Avec l’ordinateur qui dispose de la connexion directe, on créera un serveur, par contre l’autre sera notre client semi-léger. J’ai configuré le serveur comme passerelle (il a donc 2 cartes réseau dans mon cas). Il s’agit d’un simple PC, avec la distribution Linux dans laquelle vous vous sentez le plus à l’aise. Le projet se sépare en quatre parties :

  • création du serveur d’installation
  • création des images de type kiosque Web
  • création des images de type client NX
  • mise en place d’un serveur d’applications NX

et j’espère rajouter à un certain point

  • mise en place d’un serveur d’applications Windows.

Matériel utilisé

Pour ma part, j’ai utilisé le matériel suivant :

  • un vieux cluster de calcul [4]. Une machine musclée en mémoire ayant suffi pour supporter une bonne vingtaine de clients, on espère avec un cluster non seulement d’assurer le service en cas de panne d’un noeud, mais aussi de supporter une centaine de clients.
  • des clients léger ALIX3C3 avec une CompactFlash de 1GB
th>

ALIX3

Les spécifications matérielles du client léger utilisé sont les suivantes :

  • CPU : AMD Geode LX800 à 500 MHz
  • 256 MB RAM
  • Storage : CompactFlash
  • 2 slots miniPCI, bus LPC
  • Connectivité Ethernet channel 100Mbps
  • port série, deux ports USB, VGA, audio in/out
  • taille 100 x 160 mm
  • Firmware : Award BIOS

Ce client léger à été acheté chez PC Engines™.


GIF - 8.2 ko
le ALIX3C3

Le cluster de calcul sert à la fois de serveur d’installation et de serveur d’applications en load-balancing. Le cluster, qui à la base comportait un frontend identique aux noeuds et un master (voir l’article Beowulf-me  ! ou la figure 1) a été légèrement transformé pour que le master devienne le serveur d’installation pour le cluster et les clients légers, le frontend a été promu à serveur d’applications, et les noeuds vont se répartir la charge des applications (voir fig. 2).


GIF - 1.3 ko
fig. 1
Cluster avec Master et Frontend séparés

 

JPEG - 6 ko
fig. 2
Serveur d’installation, serveur d’applications et noeuds en load-balancing

Dans un futur proche, on prévoit de mettre le frontend en haute disponibilité en en rajoutant un deuxième qui prendra automatiquement le relais en cas de panne, et d’ajouter des serveurs de démarrage pour fournir du LTSP (voir fig. 3). Le cluster étant vieux est hors garantie, les systèmes de load-balancing et de haute disponibilité permettent de ne pas trop souffrir d’éventuelles pannes hardware.


JPEG - 7.5 ko
fig. 3
Une solution serveur d’applications NX avec LTSP et redondance

Avant de commencer

On a vu tout au début qu’un client léger ne dispose pas de stockage permanent. L’image de l’OS est soit téléchargée par le réseau, soit chargée depuis une mémoire locale en read-only. Mais alors, où sont écrits les fichiers de log ?
À ce problème, il y a plusieurs solutions, la plus classique étant de monter les parties du filesystem, qui vont être modifiées, dans la RAM. Une solution plus élégante consiste à utiliser UnionFS.


GIF - 5.5 ko
Le Logo de UnionFS

UnionFS permet de monter deux devices dans un seul point de montage. On montera donc la partie read-only et une partie tmpfs sur la même racine. Quand le système voudra écrire, il écrira sur la première partie read-write disponible : celle en tmpfs.
En plus, si vous avez des soucis d’espace disque, vous pouvez comprimer la partie read-only avec squashfs.
Si vous voulez à tout prix garder les logs, vous pouvez utiliser un serveur syslog.

Le serveur d’installation

Il faut configurer un serveur de démarrage et créer le root qui sera monté par NFS par les clients. Je vous laisse choisir vos outils préférés sur votre distribution préférée pour ce faire. Il est nécessaire de spécifier les paramètres de démarrage suivants :

default thinclient

label thinclient
kernel vmlinuz-2.6.24-tc
append initrd=initrd.gz ip=dhcp root=/dev/ram0 init=/linuxrc ramdisk_size=130000

Noyau, initrd et distribution d’installation

On télécharge unionfs et on patche

wget http://download.filesystems.org/unionfs/unionfs-2.x/unionfs-2.3.2_for_2.6.24.4.diff.gz
gunzip unionfs-2.3.2_for_2.6.24.4.diff.gz
patch -p1  < unionfs-2.3.2_for_2.6.24.4.diff

De même pour squashfs - il existe de l’excellente documentation sur le net.
Il est souhaitable de configurer un noyau minimal, qui doit inclure les drivers nécessaires au démarrage dans le noyau au lieu de les compiler comme des modules. De plus, il est nécessaire d’activer les options IP : kernel level autoconfiguration, IP : DHCP support, NFS system support et Root file system on NFS.
Une fois qu’on dispose de la distribution d’installation, on peut soit l’utiliser comme image pour les clients légers (alors il faudra l’étoffer comme montré dans les sections Client Web et NX), soit l’utiliser comme plate-forme d’installation pour les ALIX. Ceci nous permet de réinstaller les clients sans besoin de lecteur CDRom externe.

Création de la distribution CF

La distribution qui se trouvera sur la CompactFlash (CF) est créée à partir de la distribution d’installation. Avec une CF déjà insérée, démarrez sur le réseau (distribution d’installation) et ensuite partitionnez la CF et installez-y votre système comme vous avez fait auparavant. Il faudra ensuite chrooter, installer udev et grub et le noyau sans initrd, puis en dehors du chroot, installer grub sur la MBR de la CF.
Le initrd pour la compact flash est construit comme l’initrd de la distribution d’installation, mais avec un linuxrc différent.
Après avoir tout installé (initrd compris), vous pouvez démarrer sur la CF.
Pour ensuite modifier l’installation sur la CF, il faudra démarrer par le réseau sur la distribution d’installation et travailler en chroot.
Une fois votre distribution sur CF fonctionnelle, vous pouvez en sauvegarder une image sur le serveur d’installation. Mon outil de choix est partimage.

Installation de base

On va travailler en chroot depuis le système d’installation si on modifie le contenu de la CF, en chroot depuis le serveur d’installation si on modifie l’image sur le serveur. Je rappelle vite que la distribution d’installation est démarrée depuis le réseau par les noeuds, et peut être utilisée soit pour installer la CF sur les clients légers, ou bien elle peut être la distribution qui tourne sur les clients légers (par exemple, s’ils n’ont pas de CF). La distribution d’installation réside sur le serveur, donc elle est modifiée en se logguant sur le serveur et en faisant un chroot (les clients légers n’y accèdent qu’en read-only). La distribution qui réside sur la CF peut être accédée depuis le client léger, à condition que celui-ci soit démarré par le réseau. Si le client léger est démarré par la CF, celle-ci est montée en read-only, elle n’est donc pas modifiable.
On va maintenant installer un système de base, avec X et le son qui marchent : il faut installer les paquets suivants :

udev grub xserver-xorg-video-geode xinit xfonts-100dpi xfonts-75dpi xfonts-scalable msttcorefonts alsa-utils

On peut aussi changer le mot de passe root, et il est conseillé de configurer le réseau à ce moment et de nettoyer le cache de votre système de paquetages.

On peut déjà rajouter un user sans privilèges :

adduser thinsb

On veut démarrer le serveur X sans privilèges système, et de plus, on veut qu’à chaque fois qu’on quitte X, il soit redémarré. Il ne nous reste qu’à créer le bon fichier /home/thinsb/.xinitrc contenant, par exemple (si vous voulez faire un kiosque Web) :

#&#8201;!/bin/sh
firefox --display=:0

Pour brider Firefox, il faut le bloquer en mode fullscreen et interdire la navigation dans les sites file :/ et about:config. Pour cela, il faut installer les extensions foxfilter, AutoHide, Close Button et r-kiosk (dans cet ordre). Configurez votre Firefox avant d’installer r-kiosk  ! Si on veut une station NX, il faut installer le client NX , en plus d’un windowmanager (malheureusement, on ne peut pas utiliser le mécanisme de respawn avec NX).


GIF - 10 ko

Je ne vais pas expliquer ici les détails d’installation du client NX, je vais juste pointer quelques particularités méconnues de ce système. Premièrement, le client NX a une option daemon — en créant un fichier /usr/NX/share/noexit on permet au client NX d’être relancé à la fin de chaque session. Une autre particularité est la création de clefs personnalisées, qui accroît la sécurité du système. Sur le serveur NX on peut créer une clef ssh avec la commande

/usr/NX/scripts/setup/nxserver --keygen

et ensuite copier le contenu de /usr/NX/share/keys/default.id_dsa.key dans le dialogue Key..., ou bien on copie le fichier sur la machine client dans /usr/NX/share/keys/server.id_dsa.key. On peut bien sûr laisser la clef par défaut, mais il est toujours préférable d’avoir la sienne.


GIF - 10.3 ko
Un desktop Gnome avec quelques applications

Le serveur d’applications NX

Vous pouvez bien sûr installer le serveur d’applications NX sur la même machine que le serveur d’installation. Tout est expliqué à la page.

Conclusions

Avec les clients légers, on réinvente juste ce qui a été fait dans le passé avec les terminaux, mais maintenant, on dispose de nouveaux outils et l’évolution côté logiciels libres est incontestable. La mise en place d’une infrastructure basée sur les clients légers demande beaucoup d’effort et savoir-faire si on ne veut pas choisir une solution complétement commerciale, et personnellement, je pense non seulement que l’effort vaut le coup, mais aussi que les compétences acquises lors de la mise en place sont un bonheur de compréhension acquise.

Installation CentOS ou Ubuntu sur un ALIX

Peut-être êtes-vous juste attiré par le côté léger d’Alix et souhaitez-vous y installer un système d’exploitation complet sans trop de peine. Le même principe peut être appliqué pour créer une clé USB qui permet d’installer une autre distribution. Voici donc une mini-doc sur comment installer CentOS ou Ubuntu sur Alix.
On va préparer une clef USB. Vous aurez donc besoin d’une clef USB (vide) d’au moins 16MB, et un ordinateur avec Linux et lilo (il faut installer juste le paquetage).

Préparation du medium d’installation

Insérez la clef, regardez quel est le device correspondant (chez moi, /dev/sdb), et démontez-la si un système de montage automatique est en place. Il faudra créer une unique partition bootable en fat16, faites-le avec votre outil de partitionnement préféré. Ensuite, il faut formater la nouvelle partition sur la clef : mkdosfs -n "install" /dev/sdb1.

Création de l’image de boot sur la clef USB

Ensuite, téléchargez l’image de boot et placez son contenu sur la partition.

pour CentOS :pour Ubuntu :
wget http://mirror.switch.ch/ftp/mirror/centos/5.2/os/i386/images/diskboot.img
mount -oloop diskboot.img /mnt/loop
wget http://us.archive.ubuntu.com/ubuntu/dists/hardy/main/installer-i386/current/images/netboot/boot.img.gz
gunzip boot.img.gz
mount -oloop boot.img /mnt/loop

puis...

mount /dev/sdb1 /media/sdb1; cp -r /mnt/loop/* /media/sdb1/; umount /dev/sdb1@

Finalisation de la clef USB

On va utiliser syslinux pour rendre la partition de la clef USB bootable, et ensuite on va installer lilo sur la mbr de la clef, pour que le boot soit relayé au syslinux installé sur la partition.

syslinux /dev/sdb1
lilo -M /dev/sdb mbr

L’installation

Maintenant, vous pouvez démarrer votre Alix avec la clef déjà insérée, changer l’ordre des disques pour le démarrage pour placer la clef en premier, et démarrer l’installation en mode texte.



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.