Lorsqu'on parle de redondance, de haute disponibilité et de disque, on parle de Raid. J'en ai déjà parlé

Voici un petit aperçu des différents types de RAID, le but est ici de trouver les qualités de chacun. Un tableau final récapitule les avantage et les inconvénients qu'il y a à choisir un type de raid donné.

Jbod

Just a bunch of disk, ce n'est pas un raid, le choix de ceux qui veulent pouvoir ajouter des disques bout à bout sans gain de performance.

Contrairement au raid 0 il a un avantage, la perte d'un disque n'empêche pas la récupération des données sur les disques restants par un outil de récupération tel que photorec. En effet, comme les disques sont simplement mis bouts à bout, la plupart des fichiers tiennent intégralement sur un seul des disques. Il est donc possible d'en récupérer le contenu après un crash.

Le jbod se fait avec du LVM sans striping ou avec le driver linear de md.

Raid 0

Le choix de ceux qui veulent des performances.

Chaque disque est découpé en bande (stripe) et les bandes sont entrelacées pour donner le disque final. Ce qui donne un gain de performance appréciable puisque les disque peuvent être lus simultanément, même pendant la lecture d'un gros fichier. Et ils peuvent être écrits simultanément pendant les écritures.

Le raid 0 peut être matériel, logiciel avec le driver md de linux ou logiciel avec LVM (avec striping)

Raid 1

Le choix de ceux qui ne veulent pas de pertes.

Tous les disques sont des copies intégrales. L'avantage le plus important est que lors de la perte d'un disque tout fonctionne comme si de rien n'était. On peut donc remplacer ce disque (ou pas :-).

Un autre avantage existe lors des lectures non séquentielles (lors de la lecture de 2 fichiers par exemple), dans ce cas il est possible d'utiliser un disque pour chaque lecture et donc d'accélérer ce type de lecture. Par contre la lecture d'un seul gros fichier n'est pas accélérée (sous linux).

Il n'y a en revanche aucun impact sur l'écriture, c'est le disque le plus lent qui détermine la vitesse d'écriture (la vitesse devrait être à peu près identique pour chacun).

Notez qu'on peut faire du raid 1 avec plus de 2 disques.

Le Raid 1 peut être matériel, logiciel avec le driver md ou logicielle avec LVM (support du miroring), enfin il est possible de faire du raid1 réseau avec drbd.

Raid 5

Le choix des économes.

En raid 5 chaque disque est découpé en bande, pour chaque groupe de bandes situées au même endroit des disques, une des bandes est choisie pour contenir des octets de redondance (la différence avec le 4 c'est le choix de la bande). Ainsi ce type de raid peut survivre au crash d'un des disques (la redondance permet de reconstruire la bande manquante), mais pas de plusieurs.

L'avantage du raid 5 est que lorsqu'on a de nombreux disques on économise des disques de redondance en n'en achetant qu'un pour la redondance et les autres pour les données.

Mais le raid 5 est assez limité en performances. La lecture se passe comme pour le raid 1. Par contre l'écriture nécessite la lecture de chacune des bandes d'un groupe pour écrire la bande de données, puis calculer et écrire la bande de redondance. C'est donc très lent, à éviter pour les bases de données actives.

D'autre part, lors du crash d'un disque, toutes bandes des disques doivent être lues pour reconstituer une bande manquante. Ce qui implique des baisses de performances énormes, auxquelles il faut ajouter la baisse de performances due à la reconstruction du disque qu'on va remettre. Comme les disque tournent à fond, il n'est pas rare de voir un autre disque exploser en vol à ce moment là -> fin des données.

Le raid 5 peut être matériel ou logiciel avec le driver md de linux.

Raid 6

Le choix des très gros disques.

Le raid 6 fonctionne de la même façon que le raid 5 mais ajoute un deuxième disque de redondance. Ce ne sont pas simplement les données de redondance qui sont dupliquée, mais le calcul qui est différent, toutefois le concept est identique.

Le raid 6 soufre des mêmes inconvénients que le raid 5, il utilise même un disque de plus donc est un peu plus cher, de plus cela provoque une écriture supplémentaire pour chaque groupe de bandes.

Mais le raid 6 résiste au crash de 2 disques, ce qui est intéressant lorsque les disques sont assez gros et que la reconstruction du raid comment à être assez longue (et donc le risque de perte plus gros).

Le raid 6 peut être matériel ou logiciel avec le driver md de linux.

Raid 10

Le choix des riches.

Le raid 10 consiste à accumuler plusieurs raid 1 avec du raid 0 pour en augmenter la taille et les performances.

Le raid 10 offre les avantages simultanés du raid 1 et du raid 0. La perte d'un disque n'empêche pas le raid de tourner et l'utilisation de plusieurs disques en striping permet d'augmenter les performances de lectures.

Le seul inconvénient, c'est qu'il coûte deux fois le prix du raid 0.

Il peut se faire en matériel ou logiciel, md ou lvm.

Raid 0+1

Le mauvais choix.

Le raid 0+1 consiste à mettre 2 raid 0 en parallèle pour les redonder avec du raid 1. On pourrait croire que c'est la même chose que du raid 10, mais non. Et même si certains veulent vous faire croire que les performances sont meilleures, il n'en est rien.

Mais surtout imaginez un instant la perte d'un disque. Dans ce cas un des raid 0 sous-jacent est perdu. Il faut donc le recréer avec un nouveau disque (ce qui est à peu près instantané puisqu'on le laisse vide), puis reconstruire le raid 1 situé au dessus. Et cette deuxième partie va être longue puisqu'elle doit être faite sur la taille totale du raid 0, contrairement au raid 10 qui ne l'aurait fait que sur la taille totale du disque perdu.

Petit récapitulatif

Si vous avez aimé, il y a aussi :

1. Que faire et ne pas faire en raid
2. LaVoMatic
3. L’avenir du disque

Aujourd'hui un thème un peu polémique mais pas trop quand même.

Le XML est un descendant du SGML. C'est un format structuré de données comme l'est l'ASN1 ou le LDIF.

Tous ces formats ont été inventés dans une seule optique : être facile à parser par une machine. Et pourtant quand on voit les subtilités du XML et les difficultés à faire un parseur, on peut avoir des doutes... Mais de ce fait ils sont peu lisibles.

Ne vous méprenez pas, le XML a tout à fait sa place dans les échange de données, dans la communication entre machines. Le format est bien défini et fonctionne quel que soit le type de machine. Il est d'ailleurs très utilisé car on trouve des parseurs partout, dans presque tous les langages, et dans presque tous les frameworks.

Mais à force d'en user on en abuse.

Non le XML n'est PAS fait pour les humains ! Le xml n'est pas à sa place dans les fichiers de configuration, à moins que vous n'ayez pour objectif que l'utilisateur ne touche jamais à ces fichiers et que vous ayez le temps de développer une interface entre l'utilisateur et la modification (texte ? graphique ? sonore ?).

Le XML est pratique car il permet au développeur d'éviter l'usage de protocoles binaires incompréhensibles et mal parsés entre deux applications. Il est pratique car un autre développeur peut lire ce protocole sans l'avoir appris. Mais vous remarquerez que je ne parle que de développeurs, pas d'utilisateurs.

Alors par pitié arrêtez le XML dans les fichiers destinés aux HUMAINS. Il existe bien d'autres formats ayant des parseurs et tout aussi lisibles :

• le format INI
• le format YAML
• le format JSON

Mieux, il existe LUA qui vous permet à la fois d'avoir un fichier de configuration simple et lisible, mais qui en plus autorise l'utilisateur à faire des choses que vous n'auriez pas prévu, comme des configuration conditionnelles !

Maintenant que nous savons nous servir d'un interpréteur postscript, nous allons pouvoir développer. Postscript est un langage complet au sens de Turing. C'est à dire qu'on peut tout faire avec, même faire décoller une fusée. Mais bon, avant d'en arriver là, on va essayer de faire quelque chose d'utile.

Pour vous présenter le langage, je vous propose un exemple basé sur la fourmi de Langton. C'est une fourmi qui a ceci de particulier qu'elle ne sait que tourner. Son univers ressemble beaucoup à celui du jeu de la vie, c'est-à-dire une grille infinie de cases noires ou blanches. Lorsque la fourmi est sur une case noire, elle tourne à droite, lorsqu'elle est sur une case blanche, elle tourne à gauche. De plus elle inverse la couleur de la case sur laquelle elle se trouve.

Le concept est assez simple, et lorsqu'on lance la fourmi sur une grille blanche, son comportement a l'air aléatoire. Et pourtant au bout d'un moment elle fabrique ce qui ressemble à une autoroute.

Tout ça pour dire que le postscript c'est bien. C'est un langage à pile, qui fonctionne en notation inversée. Les possesseurs de HP48 et amateurs de RPL y retrouveront leurs petits (ou de vieux souvenirs). Les développeurs forth (faite sous savoir si vous êtes dans la salle) apprécieront aussi probablement.

La base

Les commentaires

Toute ligne commençant par un % est un commentaire. Exemple :

% Rien

Les commandes

Les commandes sont des mots simples. Étant donné la notation inversée, la commande se trouve après ses arguments. Par exemple une addition :

5 9 add

A cette notation est associée une pile. 5 pose 5 sur la pile, 9 pose 9 sur la pile, add retire les 2 derniers éléments (donc 9 et 5) puis additionne et repose le résultat sur la pile. D'où la représentation de la pile :

    %avant la ligne de commande
5   % 5 
5 9 % 9
    %pendant le add (invisible)
14  % après le add 

Les commandes peuvent être séparées par des espaces ou des retours à la ligne.

Les variables

Les variables sont définie avec la commande def. Un nom de variable se pose sur la pile avec le préfixe /. Donc pour définir la variable pi

/pi 3.1415 def

Une variable se lance ou se pose sur la pile avec son nom dans préfixe. Donc pour poser pi sur la pile :

pi

Les fonctions

Une fonction est tout simplement un ensemble d'instruction placées entre { }. Une fonction toute seule n'a que peu d'intérêt, mais une fonction peut être mise dans une variable avec la commande def ce qui permet de la réutiliser autant de fois que voulu.

Exemple une fonction qui incrémente un élément de la pile de 1 :

/incremente { 1 add } def

Manipulation de la pile

La pile étant un élément central, il existe des opérateurs pour la manipuler. Le principaux sont :

• pop : retire un élément de la pile
• dup : duplique un élément de la pile
• exch : échange les 2 derniers éléments de la pile
• pstack : affiche le contenu de la pile (utile pour le debug)
• clear : vide la pile

L'affichage

L'affichage étant le but ultime de postscript, vous comprendrez qu'il y a beaucoup de primitives d'affichage, essentiellement vectoriel.

Regardez bien ça vous rappellera le logo. Dessinons un carré :

newpath
0 0 moveto
10 0 rlineto
10 10 rlineto
0 10 rlineto
0 0 rlineto
stroke

Petite astuce si vous testez les commandes, chaque dessin doit se terminer par un showpage (ici par exemple, juste après le stroke), cela affiche le contenu du buffer sur une page et passe à la feuille suivante.

Quelques exemples de commande :

• setlinewidth (un paramètre : la largeur de trait)
• closepath (ferme le dessin)
• fill (remplit un chemin fermé)

Contrôle de flux

Tous comme n'importe quel langage, le postscript permet des boucles et des if sous la forme "booléen méthode if". Par exemple :

% incrémente le dernier élément de la pile s'il est inférieur à 10
dup 10 lt { 1 add } if

Pour une boucle for, même topo. Exemple une somme de 1 à 10 :

% valeur initiale
0 
% début incrément fin méthode for
1 1 10 { add } for

Voilà, je n'ai fait que survoler le langage, vous trouverez plus de détail dans ce livre référence.

Un exemple

Pour continuer, j'ai écrit un petit exemple commenté disponible en téléchargement. Vous pouvez l'ouvrir avec un éditeur de texte ou utilise ps2pdf pour le rendre affichable. Cet exemple génère 75 pages visibles en PDF, chaque page correspond à 150 itérations du mouvement de la fourmi.

Lisez-le vous verrez que finalement le postscript c'est pas trop compliqué quand c'est pas écrit par une machine sur une seule ligne.

Si vous avez aimé, il y a aussi :

1. Postscript est un langage … de script
2. Torture de cerveau
3. Calculatrice en ligne de commande

Savez-vous vraiment utiliser postscript ?
Savez-vous ce qu'est postscript ?

Postscript est avant tout un langage, relativement complet. Ce langage se destine à l'affichage et à l'impression. Il contient donc de nombreuses primitives pour l'affichage, principalement vectoriel. Mais rien ne vous force à l'utiliser pour ça. Il existe bien des gens qui utilisent php pour faire des scripts d'administration ...

Interprétation

Le postscript s'interprète, les imprimantes sont donc des interpréteurs postscript, ce qui veut dire qu'on peut les programmer comme on veut. Il existe bien des gens qui programment leur carte graphique pour faire du calcul parallèle ...

Apprenons donc à interpréter un fichier nommé toto.ps :

# technique simple pour en faire un pdf
$ ps2pdf toto.ps

# ancienne technique chamane qui passe par l'imprimante
$ gs -dSAFER -dNOPAUSE -sDEVICE=deskjet -sOutputFile=\|lpr toto.ps

Vous pouvez aussi passer par l'interface de cups à la place de lpr.

Notez bien qu'ici l'interpréteur est ghostscript (gs) et qu'on a du spécifier le type d'imprimante, type qu'on n'a pas choisi au hasard. Pour avoir la liste des imprimantes supportées, tapez :

$ gs -help

Et lisez bien la liste vous verrez des bizarreries comme jpeg, png256, bmpgray ... Ce ne sont pas vraiment des imprimantes, donc vous devinez bien qu'il est donc possible de convertir très facilement un fichier postscript en image jpeg (enfin la première page en tout cas) :

$ gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=jpeg -sOutputFile=fichier.jpg toto.ps

Pour avoir les autres pages et la résolution de l'image, voici la commande :

# scriptez le si ca vous sert
$ gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=jpeg -r72 -sOutputFile=fichier-%d.jpg toto.ps

Un peu plus de détail sur les paramètres et les sorties possibles ici : http://pages.cs.wisc.edu/~ghost/doc... ou dans le manuel.

Voila, on n'a pas trop parlé de script ici, mais il en sera question dans le prochain article. D'ailleurs si vous voulez développer dès à présent, il suffit de lancer gs sans -dBATCH et sans fichier postscript pour obtenir une console interactive.

PS : Notez au passage qui toutes les commandes gs fonctionnent aussi avec du PDF car ce dernier est un autre langage compris par gs.

Si vous avez aimé, il y a aussi :

1. M4, un langage de macro
2. Écrire un script en C
3. Un seul langage pour les scripts

J'ai déjà fait des articles sur LVM. Aujourd'hui parlons de snapshot en ram et d'une nouveauté du noyau 2.6.33, le snapshot-merge.

Snapshot en RAM

Tout comme il est possible de faire un LV en RAM, il est possible de faire un snapshot en RAM.

Pour faire un LV (Logical Volume) en RAM : il suffit d'utiliser un ramdisk comme PV(Physical Volume).

$ pvcreate /dev/rd0
$ vgcreate myvg /dev/rd0
$ lvcreate -l 100%FREE -n mylv myvg

Pour faire un snapshot en RAM :

$ pvcreate /dev/rd0
$ vgextend myvg /dev/rd0
$ lvcreate -L 100M -s -n mysnapshot /dev/myvg/mylv

Mais pour quoi faire ? Pour la même chose qu'un livecd : transformer un périphérique en lecture seule en périphérique lecture-écriture qui perdra toutes ses modifications au prochain reboot.

Seul inconvénient, les ramdisk ont une taille prédéfinie au démarrage du noyau (ramdisk_size=).

Mais j'ai gardé le meilleur pour la suite.

Snapshot de test

Maintenant qu'une nouvelle fonctionnalité a été ajoutée au noyau vous allez enfin pouvoir faire les snapshot dont vous aviez toujours rêvé.

Avant il y avait le snapshot qu'on pouvait créer, puis détruire. Selon que l'on travaillait sur le snapshot ou sur la partition originale la destruction nous ramenait à la nouvelle version ou à l'ancienne sans possibilité de choisir entre les 2 une fois le premier octet écrit. Maintenant avec le snapshot merge, il est possible de supprimer un snapshot en réimportant les données qu'il contenait dans la partition originale. Ce qui veut dire qu'on peut choisir.

Prenons un exemple parce que là j'ai franchement mal expliqué.

Toto est un sysadmin prudent, il ne fait jamais de mise à jour du système sans être sûr que ça ne posera pas de problème. Aujourd'hui on lui demande de faire une mise à jour importante, mais il ne sait pas quelles en seront les conséquences. En bon sysadmin il a déjà un noyau à jour et par chance son système est tout en LVM. Hop une synchro (rsync), un snapshot (ou plusieurs, il a bien séparé ses partitions ...), on prévient que ca peut casser et c'est parti, upgrade !

Maintenant 2 choix sont possibles :

• Ça marche ! Alors il suffit de supprimer le snapshot et on n'entendra plus parler de l'ancienne version.
• Ça merde ! Hop un petit snapshot-merge et on revient à l'ancienne version comme si de rien n'était. (lvconvert --merge)

Et voilà ! Maintenant vous pouvez faire vos mises à jour en toute sérénité ! En fin presque : on parle de la racine et donc de nombreux fichiers en cours d'utilisation sur la partition en question, ce qui veut dire reboot pour pouvoir terminer le merge. Mais le merge peut quand même se faire en live (vous pouvez déjà utiliser la partition pendant que le merge se termine en arrière plan). Il est donc possible de lancer la commande de merge, modifier son fstab si besoin et de rebooter.

Enfin n'oubliez pas une chose, les snapshot lvm ne fonctionnent qu'au niveau block device, c'est-à-dire en dessous du système de fichiers. C'est comme si vous enleviez le disque sans éteindre la machine, il se peut que le système de fichier ne soit pas au mieux de sa forme au moment ou vous le lancez, ayez au moins un système journalisé pour éviter les surprises et jouez du sync pour un peu plus de garanties.

Rien ne vaudra jamais les snapshot au niveau du système de fichier comme chez ZFS ou le futur BTRFS.

Si vous avez aimé, il y a aussi :

1. Snapshot de snapshot
2. Les Vauriens M’admirent
3. La carte du périphérique

Un utilisateur expérimenté commencera par explorer cet univers et découvrira à chaque fois une nouvelle façon de faire, une solution plus ou moins adaptée à ses besoins. Progressivement, il se forgera un opinion sur les logiciels qu'il rencontre (emacs c'est bien, vim c'est mal). Celle-ci peut varier au cours du temps et des nouvelles technologies qu'il rentre.

Cette possibilité de choisir est une composante essentielle du logiciel libre et on constate que dans la plupart des domaines des centaines de choix vous sont proposés. Le site distrowatch est un exemple de la diversité des distributions, sa page de statistiques compte 297 distributions.

C'est une bonne chose, mais maintenant plaçons-nous dans la peau d'un novice. La première chose qu'il voit est la même : un choix gigantesque et permanent. Quelle distribution ? Quel éditeur de texte ? Quel navigateur ? Tout ce choix tue le choix.

Devoir choisir est difficile pour trois raisons. La première est que lorsqu'on est nouveau on ne connait pas du tout le domaine ni les critères de choix. Rien ne nous indique pourquoi choisir telle ou telle solution. Il faut alors aller chercher l'information et comparer les différentes possibilités soi-même.

La deuxième est qu'il faut disposer de temps pour faire ce choix. Mais le temps est une richesse qu'on ne veut pas nécessairement dépenser. Une personne riche de son temps peut le dépenser à tout va, mais cette richesse se fait de plus en plus rare et nombreux sont ceux qui préfèreront dépenser leur temps à pêcher ou à partir à la chasse au kangourou.

La troisième est la pression psychologique du choix. Ai-je fait le bon choix ? N'y avait-il pas un meilleur choix ? C'est quelque part une bonne chose pour une personne expérimentée qui va passer son temps à se demander s'il n'y a pas mieux et à sauter sur la moindre occasion d'améliorer les choses. Mais la plupart des gens risquent de trouver cet excès de choix trop difficile.

Conclusion : Trop de choix tue le choix !

Conclusion 2 : Il faut faire les choix à la place des débutants.

Il paraît que sous unix tout est fichier. Vous allez voir que ce n'est pas tout à fait vrai.

La seule interface du noyau avec ses processus est la table des appels systèmes, dont voici la liste pour linux (et les prototypes en C). Vous y trouverez en gros 3 catégories : les appels liés aux fichiers, les appels liés aux processus, les appels liés au temps. Dans les fichiers on trouve entre autre le réseau, et dans les processus on trouve entre autre la gestion de la mémoire et des signaux. Donc sous unix tout est fichier ou processus ou temps (souvenez-vous du temps où on l'appelait time sharing system).

Malgré leur grand nombre, les appels système ne font finalement que peu de choses. Quelques opérations de base, et puis c'est tout. En fait la grande majorité du code de linux est appelé à travers des lectures/écritures sur des fichiers.

Le code du driver de votre disque dur est appelé lors de la lecture d'un répertoire. Le code de nombreux drivers est appelé lors de l'utilisation d'un fichier dans /dev, le code de configuration de linux est appelé lors de l'utilisation de /sys ... Ce qui est beau dans cette histoire c'est qu'on ne s'en rend pas compte, les méthodes utilisées sont toujours les mêmes (open, read, write ...)

Notez quand même que tout cela forme une API du noyau un peu plus vaste que les appels systèmes : les numéros de bloc dans /dev, les noms dans /sys, le format de fichier dans /proc, ne sont pas interchangeables. C'est une API au dessus de l'API fichier. C'est à cause ou plutôt grâce à elle qu'on dit que tout est fichier.

Mais retenez surtout ceci : tout est fichier ou processus ou temps.

Si vous avez aimé, il y a aussi :

1. Gestion des attributs d’un fichier
2. Fichier sorti du chapeau
3. Coup de fil pour le noyau