Accélérer le démarrage d'une machine Debian GNU/Linux 🔗

Posted by Médéric Ribreux 🗓 In blog/Sysadmin/

Introduction

Le boot, c'est parfois long. Souvent, on a pas que ça à faire ! C'est très vrai pour les ordinateurs portables ou les stations de travail. Mais d'une manière générale, y compris pour des grosses machines de production, j'aime bien les séquences de boot rapide. En effet, plus le boot est rapide et plus la remise en fonctionnement des services associés à la machine est rapide. Plus on gagne de secondes sur ce sujet et mieux c'est. De plus, avoir une séquence de boot rapide implique que vous ayez passé un peu de temps sur cette dernière. C'est généralement une bonne pratique d'administration système. Si vous n'avez installé que le strict nécessaire, votre séquence de démarrage sera souvent assez rapide.

Néanmoins, il existe des outils techniques qui permettent de gagner de précieuses secondes. Le premier qui me vient à l'esprit est systemd qui permet d'accélérer la séquence de démarrage en parallélisant au maximum le lancement des services, y compris si le réseau n'est pas encore configuré. Sur mes stations de travail, systemd permet d'économiser entre 5 et 10 secondes.

L'autre possibilité est d'utiliser un disque SSD pour le système. C'est le cas d'une de mes stations de travail. Néanmoins pour tout un tas d'autres machines, ce n'est pas forcément possible. Par exemple, un serveur de récupération (c'est du green-IT) n'a pas besoin d'un disque SSD. Ou peut-être n'avez-vous tout simplement pas les moyens de vous offrir un SSD.

Optimiseur de système de fichiers

Pour les systèmes à disques durs classiques, on peut quand même gagner du temps en utilisant un optimiseur de système de fichiers. Il existe par exemple readahead qui fonctionne avec systemd. Sous GNU/Linux Debian Wheezy, il existe un paquet nommé readahead-fedora. Le principe de ce dernier est de lire des fichiers pour les placer en mémoire. readahead est prévu pour être lancé au démarrage de la machine: il utilise une liste de fichiers à lire en amont dans un ordre bien déterminé de manière à accélérer le temps de démarrage. En effet, si on concentre les opérations de lecture de fichiers dont on aura besoin dans tout le processus de démarrage, les accès disques seront beaucoup mieux optimisés.

Mais on peut encore aller plus loin. En effet, on peut agir au sein du système de fichiers. Si tous les fichiers à lire pour accélérer la séquence de démarrage sont placés au même endroit, les uns à la suite des autres, leur lecture pour les placer en mémoire sera beaucoup plus rapide, les têtes de lecture n'ayant pas à se déplacer de manière répartie. Il y a un paquet pour ça: e4rat. Voyons comment l'installer…

Principes d'e4rat

e4rat est un petit logiciel qui se charge de regrouper les fichiers préchargés du système dans un endroit donné, de manière linéaire. Il ne fonctionne que sur les systèmes ext4 mais, comme btrfs n'est pas encore implémenté en standard dans toutes les distributions (et qu'il n'est pas encore prêt pour la production), nous pouvons allègrement l'utiliser.

Son principe d'utilisation est finalement assez proche de celui de readahead à la différence qu'il n'est pas vraiment géré à la sauce Debian. Certes il existe un paquet Debian sur le site web de l'utilitaire, mais il n'est pas intégré à la distribution.

e4rat utilise 3 binaires différents:

Installation d'e4rat

Cette fois, apt-get ou aptitude ne peuvent pas nous aider. Il faut aller sur le site web du projet et télécharger le paquet debian qui va bien. Si vous utilisez autre chose que du x86 ou de l'amd64 (de l'armhf ou du mips), il faudra recompiler à la main !

 # dpkg -i e4rat_0.2.3_amd64.deb

Le paquet installe quelques binaires dans /sbin/ ainsi que les pages de manuel relatives.

Configuration d'e4rat

Pour la partie configuration, elle sort vraiment du lot Debian: il faut intervenir en amont du système et indiquer au noyau linux le nouveau nom du processus init. C'est une technique identique à celle de bootchart. Nous devrons donc gérer tout ça dans la configuration de GRUB2.

Pour résumer, voici ce que nous allons faire:

Voici le déroulé de ces étapes.

menuentry 'E4Rat collect Debian GNU/Linux,3.2.0-4-amd64' --class debian --class gnu-linux --class gnu --class os {
    insmod gzio
    insmod part_msdos
    insmod ext2
    set root='(hd0,msdos5)'
    search --no-floppy --fs-uuid --set=root 9beb0590-6505-41af-8daa-cdf23a108473
    echo    'Chargement de Linux 3.2.0-4-amd64 avec E4RAT collection…'
    linux   /boot/vmlinuz-3.2.0-4-amd64 root=UUID=9beb0590-6505-41af-8daa-cdf23a108473 ro quiet init=/sbin/e4rat-collect
    echo    'Chargement du disque mémoire initial …'
    initrd  /boot/initrd.img-3.2.0-4-amd64
}

Bien entendu cette configuration fonctionne très bien avec systemd, car elle est indépendante du système d'init de la distribution.

Conclusion

L'installation d'e4rat est un peu complexe. Sa configuration n'est pas vraiment dynamique: si vous installez de nouveaux paquets ou de nouvelles versions de paquets existants, il faudra recommencer l'étape de collecte des fichiers en bootant sur l'entrée GRUB E4Rat collect et relancer e4rat-realloc. Néanmoins sur un système en production où ces changements sont peu nombreux, c'est très adapté. Avec e4rat on peut gagner près de 5 à 10 secondes supplémentaires sur la séquence de démarrage. Donc, le jeu en vaut clairement la chandelle vu le faible temps d'administration système nécessaire pour mettre en place la configuration (moins de 30 minutes).

Bien entendu, e4rat n'a pas vraiment d'intérêt sur des disques SSD qui n'ont pas les mêmes problèmes de latence que les disques durs classiques. C'est la même chose pour les machines virtuelles !

Pour ma part, je l'ai déployé sur des stations de travail et des ordinateurs portables avec beaucoup de succès. Je le recommande y compris pour les serveurs de production (physiques bien sûr) comme processus à la mise en production: sur un parc un peu fourni, on peut remettre en service avec un peu d'avance et minimiser les temps d'indisponibilité. Vos utilisateurs seront plus rapidement contents et vos administrateurs systèmes nerveux un peu moins longtemps lors des redémarrages.