La traînée de poudre

Les nouveaux SSD basés sur les contrôleurs SanForce de la famille 1200 présentent une caractéristique intéressante : la déduplication au niveau bloc intégrée dans le contrôleur, une technologie nommée “DuraWrite” par le fabricant.

Pour bien comprendre les avantages de cette nouvelle fonctionnalité, il convient de rappeler comment fonctionnent les SSDs : un tel “disque” peut écrire par “page” de 4Kio, mais doit effacer par bloc de 128 Kio au minimum; par ailleurs un bloc ne peut être écrit et effacé qu’un nombre limité de fois ( pour plus de détails, voir l’article précédent Les promesses du SSD).

La déduplication de bloc signifie qu’avant chaque écriture, le contrôleur vérifie si un bloc identique n’est pas déjà stocké, auquel cas une nouvelle écriture (et potentiellement, un effacement) est évitée. Du coup, la durée de vie est augmentée proportionellement aux écritures évitées; et la performance augmente dans le même rapport, puiqu’on économise sur les opérations les plus coûteuses, l’écriture et surtout l’effacement.

MLC et SLC

Un petit rappel : il existe deux grandes familles de SSD que l’on identifie par l’organisation de la mémoire flash: les MLC et les SLC. Les MLC stockent deux bits par cellule flash, les SLC 1 seul. Le corollaire est qu’à quantité de mémoire égale, un MLC présente le double de capacité. Par contre le SLC est supposé bien plus rapide en écriture, et surtout bien plus durable : les cellules MLC étaient en 2009 données pour capables de 10 000 écritures, contre 100 000 aux SLC.

Cependant les choses évoluent, et les générations actuelles de puces flash MLC sont généralement données pour capables de 100 000 écritures, et 1 000 000 pour les SLC. Autrement dit, les MLC actuelles ont la même durée de vie que les SLC d’il y a deux ans! Voici un premier point.

Second point, quel gain réel nous apporte les nouveaux disques MLC à contrôleur SF1200? Question à laquelle nous nous sommes empressés de répondre par une série de tests.

Le test

Configuration testée :

• carte-mère Supermicro H8DIi
• 2 processeurs AMD 2376
• 16 Go de RAM DDR2 400Mhz ECC Kingston
• contrôleur RAID Adaptec 5805
• SSD SLC : 8 SuperTalent UltraDrive GX 64 Go (modèle 2010)
• SSD MLC : 8 SuperTalent TeraDrive CT 60 Go (modèle 2011)

Les 8 SSD ont été agrégés en une grappe RAID-10 d’une largeur de bande de 16 Ko. Nous avons ensuite effectué une série de 16 tests avec Bonnie++.

Tout d’abord, le test d’accès séquentiel : écriture, lecture et écriture simultanées, lecture :

Les SSD MLC sont en fait nettement plus performants que les SLC de l’année dernière : 590 Mo/s en écriture contre 200 Mo/s; 1150 Mo/s en lecture contre 600 Mo/s!

Ensuite, le test de création, accès et suppression de fichiers, séquentiel puis aléatoire, en augmentant le nombre de fichiers pour le test à 80 000:

L’écart est assez peu significatif. Il faut dire que le contrôleur RAID lui-même est probablement assez proche de sa performance crête autour de 45 000 IOPS. Cependant le MLC est encore nettement gagnant.

Pour le test simulant des accès de base de données (accès aléatoires de 8 Ko) les SSD MLC ont également été testés en RAID-6 (bande 64 Ko), RAID-5 (bande 16 Ko), RAID-10 (bande de 256 Ko). L’accès en écriture seule a également été testé. En abscisse, nous avons le nombre d’accès parallèles (threads), en ordonnée le nombre d’opérations par seconde:

On constate là encore une forte supériorité du MLC, qui sature les capacités du contrôleur. Il n’y a pas d’écart important entre le RAID-5 et le RAID-6, et le RAID-10 n’apporte pas plus de 10% de gain. On peut raisonnablement envisager de faire des économies et d’utiliser ces SSD en RAID-5 ou RAID-6 sans arrière-pensée, même (sacrilège!) pour de la base de données.

On remarque que la performance en écriture aléatoire est nettement inférieure à la lecture, ce qui est attendu. On relativisera cependant en pensant que pour obtenir cette performance ( 14 700 IOPS, 47 Mo/s) en accès aléatoire avec des disques “en métal rouillé” il faut environ 60 disques SAS 15000 tours/minute, et 120 disques SATA 7200 tours/minute.

Some people wanted some more information on the test setup used in the deduplication benchmarks, so here are some more details :

• dual Opteron 2376 system
• 16 GB RAM
• 2 Adaptec 52445 RAID controllers
• 24 Hitachi Ultrastar 2 TB drives in 2 RAID-6 arrays, 64KB stripe.
• Kernel Linux 2.6.32.11 AMD64 (custom built from vanilla www.kernel.org source)
• RAID arrays agreggated with LVM and mounted as an XFS filesystem.
• Lessfs 1.1.9.10

Here are the bonnie++ results (meaningless and empty columns removed). You can clearly see the very low LessFS metadata performance (though Lessfs 1.2.x improves on this, more benchmarks to come).

The block performance results are drawn below :

As you can see, deduplicated performance is more than enough to saturate a 1 Gb network. For more performance hungry users, it will be a great secondary storage. Notice that it’s possible to both have your cake and eat it as you might use both XFS — for maximum performance — and Lessfs — for maximum capacity — storage simultaneously.

Happy New Year!

I tested various real-time online deduplication implementations at the filesystem level under Linux, namely Opendedup, Lessfs and a couple of proprietary ones. What’s great of course is that it’s transparent, you can share data using all protocols at once (NFS, CIFS, iSCSI, FTP, whatever), namely you can use your dedupe filesystem exactly like an ordinary one.

The only concern can be about performance and particularly IOPS; Some systems get decent throughput but in any case the IOs are all basically turned into random IOs, therefore dedupe hurts performance badly any way you turn it.

Some will ask : why are all IOs made random? Because while you’re sending data to the “deduplicator”, it checksums blocks of data as they’re coming and compares them against its hash index of blocks, throwing away any block previously seen. If the filesystem is big, this database won’t fit in memory and will be continuously scanned while writing so the disk access pattern is basically write a bit sequentially, read the index, write some more data, read the index…

Reading is a different matter; we suppose that about half the data is not unique, so when you’re reading some sequential data, you’re actually reading blocks written at different times and as such physically scattered around the disks. So reading is almost certainly quasi random, limiting seriously performance.

Example from real benchmarks : I created 60 TB of semi-randomized data, occupying a total of 19 TB after combined compression/dedupe. The filesystem performance without dedupe is about 350 MB/s write, 500 MB/s read, 1500 IOPS. With dedupe the figures are 120 MB/s write (but it varies extremely from 30 MB/s to 300 at times) and 200 MB/s read; however IOPS drop to an abysmal 40 to 50.

My conclusion is that it’s not generally commendable as a primary storage application; however as a “warm” archive or backup, or for rarely accessed files, it’s wonderfully effective.

D’après The rise of Worse is Better.

À peu près tous les concepteurs de Common LISP et CLOS, dont moi-même, ont été extrêmement exposés au style de conception du MIT/Stanford. L’essence de ce style peut être rendue par la phrase : “ce qu’il faut”. Pour un tel concepteur, il est important de réussir à obtenir ces caractéristiques:

• simplicité - la conception doit être simple, en implémentation comme en interface. Il est plus important pour l’interface d’être simple que pour l’implémentation.
• exactitude. La conception doit être correcte dans tous les aspects observables. L’inexactitude n’est simplement pas autorisée.
• Cohérence. Le modèle ne doit pas être incohérent. La conception peut être légèrement moins simple et moins complète pour éviter les incohérences. La cohérence est aussi importante que l’exactitude.
• Complétude. La conception doit gérer autant de situations importantes que possible. Tous les cas raisonnablement envisageables doivent être couverts. La simplicité n’est pas autorisée aux dépens de la complétude.

Je pense que la plupart des gens admettront que ce sont de bonnes caractéristiques. J’appellerai l’usage de cette philosophie dans la conception “l’approche MIT”. Common LISP (y compris CLOS) et Scheme représentent l’approche MIT dans la conception et l’implémentation.

La philosophie “moins bien, c’est mieux” diffère subtilement:

• simplicité. la conception doit être simple, en implémentation comme en interface. Il est plus important pour l’implémentation d’être simple que pour l’interface. La simplicité est la plus importante considération dans un concept.
• Exactitude. La conception doit être correcte dans tous les aspects observables. Il est plus important d’être simple que correct.
• Cohérence. La conception ne doit pas être incorrecte de manière trop évidente. La cohérence peut être sacrifiée à la simplicité dans certains cas, mais il est préférable d’abandonner les parties qui concernent les circonstances moins courantes que d’introduire soit plus de complexité dans l’implémentation, soit des incohérences.
• Complétude. La conception doit gérer autant de situations importantes que possible. Tous les cas raisonnablement envisageables devraient être couverts. La complétude peut être sacrifié au profit de toute autre qualité. En fait, la complétude doit être sacrifiée quand la simplicité d’implémentation est en jeu. La cohérence peut être sacrifié pour atteindre la complétude si cela permet de maintenir la simplicité; la cohérence de l’interface n’a pas de valeur particulière.

Les anciennes versions d’Unix et de C sont des exemples de cette école de conception, et j’appellerai cette stratégie “l’approche New Jersey”. J’ai intentionnellement caricaturé la philosophie du “moins bien, c’est mieux” pour vous convaincre que c’est de toute évidence une mauvaise philosophie et que l’approche New jersey est une mauvaise approche.

Cependant, je crois que le “moins bien, c’est mieux”, même présenté comme un épouvantail, a de meilleures capacités de survie que “ce qu’il faut”, et que l’approche New Jersey appliquée au logiciel est supérieure à l’approche MIT.

Permettez moi de répéter une histoire qui montre la validité de la distinction entre MIT et New Jersey, et que les promoteur de chacune de ces philosophies pensent réellement que leur philosophie est la meilleure.

Deux fameux personnages, l’un du MIT et l’autre de Berkeley (mais travaillant sur Unix) se rencontraient pour discuter de problèmes de systèmes d’exploitation. La personne du MIT connaissait bien ITS (le système d’exploitation du labo d’intelligence artificielle du MIT) et avait lu les sources d’Unix. Il voulait savoir comment Unix résolvait le problème du contrôle de processus “loser”. Ce problème apparaît lorsqu’un programme utilisateur invoque une routine système pour effectuer une opération de longue durée qui peut avoir un état significatif, comme des tampons d’entrée-sortie. Si une interruption se produit pendant cette opération, l’état du programme utilisateur doit être sauvegardé. Comme l’invocation de la routine système est généralement une seule instruction, le contrôle de processus du programme ne peut capturer de manière adéquate l’état du processus. La routine système doit donc soit ressortir, soit continuer sur sa lancée. “Ce qu’il faut” est ressortir, restaurer le programme utilisateur à l’instruction précise qui a invoqué la routine système afin qu’à la reprise du programme utilisateur après l’interruption, par exemple, on rentre à nouveau dans la routine système. On appelle cela contrôle de processus “loser” parce que le contrôle de processus est forcé en mode “loser”, “loser” étant le petit nom pour “utilisateur” au MIT.

Le gars du MIT ne voyait aucun code pour prendre soin de ce cas et demanda au gars du New Jersey comment le problème était pris en charge. Le gars du New Jersey répondit que les gens d’Unix étaient conscients du problème, mais que la solution était pour la routine système de toujours finir, mais parfois un code d’erreur serait retourné pour signaler que la routine avait échoué à terminer son action. Un programme utilisateur correct, donc, devait vérifier le code d’erreur pour déterminer s’il devait simplement essayer d’appeler la routine système à nouveau. Le gars du MIT n’aimait pas cette solution parce que ce n’était pas “ce qu’il faut”.

Le gars du New jersey dit que la solution Unix était correcte, parce que la philosophie de conception d’Unix était la simplicité et que “ce qu’il faut” serait trop complexe. Par ailleurs, les programmeurs pouvaient facilement ajouter ce test et cette boucle supplémentaires. Le gars du MIT remarque que l’implémentation était simple mais que l’interface de la fonctionnalité était complexe. Le gars du New Jersey fit alors que le bon compromis avait été choisi dans Unix, à savoir la simplicité d’implémentation était plus importante que la simplicité de l’interface.

Le gars du MIT marmonna alors que parfois il faut être un vrai dur pour faire un poulet bien tendre, mais le gars du New Jersey n’a pas compris (je ne suis pas sûr d’avoir compris non plus).

Maintenant je veux arguer le fait que “moins bien c’est mieux” est mieux. C est un langage de programmation conçu pour écrire Unix, et il a été conçu en suivant l’approche New Jersey. C est par conséquent un langage pour lequel il est facile d’écrire un compilateur acceptable, et il impose au programmeur d’écrire du texte facile à interpréter par le compilateur. Certains ont dit que le C était un langage assembleur sophistiqué. À la fois les anciens Unix et compilateurs C avaient des structures simples, étaient facile à porter, demandaient peu de ressources machine pour s’exécuter, et fournissaient à peu près 50 à 80 % de ce que l’on attend d’un système d’exploitation et d’un langage de programmation.

La moitié des ordinateurs existant à un instant quelconque sont inférieurs à la moyenne (plus petits, plus lents). Unix et C fonctionnent bien sur ceux-ci. L’approche “moins bien, c’est mieux” signifie que la simplicité d’implémentation a la plus haute priorité, ce qui veut dire qu’Unix et C sont faciles à porter sur de telles machines. Par conséquent, puisque les 50% de fonctionnalité fournies par C et Unix sont satisfaisants, on s’attend à ce qu’ils commencent à apparaître partout. Et c’est bien ce qu’il s’est passé, n’est ce pas?

Unix et C sont les virus informatiques ultimes.

Un bénéfice supplémentaire de l’approche “moins bien, c’est mieux” est que le programmeur est conditionné à sacrifier de la sûreté, de la commodité et des ennuis pour obtenir une bonne performance et une utilisation modeste de ressources. Les programmes écrits en utilisant l’approche New Jersey fonctionneront bien sur de petites machines comme sur des grosses, et le code sera portable puisqu’il est écrit par dessus un virus.

Il est important de se rappeler que le virus initial doit être globalement bon. Dans ce cas, la propagation virale est assurée aussi longtemps qu’il reste portable. Une fois que le virus s’est répandu, on fera pression pour l’améliorer, peut-être en augmentant la fonctionnalité plus près de 90%, mais les utilisateurs ont déjà été habitué à accepter quelque chose d’inférieur à “ce qu’il faut”. En conséquence, le logiciel “moins bien c’est mieux” premièrement commencera à être accepté, deuxièmement habituera les utilisateurs à en attendre moins, et troisièmement sera amélioré jusqu’au point où il sera presque comme il faut. En terme concrets, bien que les compilateurs Lisp en 1987 aient été à peu près aussi bons que les compilateurs C, il y a nettement plus d’experts en compilateurs qui veulent améliorer les compilateurs C que les compilateurs Lisp.

La bonne nouvelle c’est qu’en 1995 nous auront un bon système d’exploitation et un bon langage de programmation; la mauvaise nouvelle c’est que ce seront Unix et C++.

Il y a un dernier avantage à “moins bien c’est mieux”: Comme le système et le langage du New Jersey ne sont pas vraiment assez puissants pour construire de grands et complexes logiciels monolithiques, les grands systèmes doivent être conçu pour réutiliser des composants. Par conséquent une tradition d’intégration fleurit.

Comment “ce qu’il faut” se défend-il? Il y a deux scénarios de base : le scénario du “grand système complexe” et celui du “pur joyau”.

Le scénario du “grand système complexe” se déroule ainsi:

Tout d’abord, le système “qu’il faut” doit être conçu. Ensuite l’implémentation doit en être conçue. Enfin il est implémenté. Comme c’est “ce qu’il faut”, il a pratiquement 100% de la fonctionnalité souhaitée, et la simplicité d’implémentation n’ayant pas été une préoccupation cela a pris très longtemps. Le système est vaste et complexe. Il nécessite des outils complexes pour l’utiliser correctement. Les derniers 20% prennent 80% de l’effort, et de fait “ce qu’il faut” prend du temps, et ne fonctionne correctement que sur le matériel le plus sophistiqué.

Le scénario du “pur joyau” se déroule ainsi:

La conception de “ce qu’il faut” demande une éternité, mais le système est plutôt compact. L’implémenter de façon à ce qu’il soit rapide est soit impossible, soit au-delà des capacités de la plupart des développeurs.

Ces deux scénarios correspondent à Common Lisp et Scheme.

Le premier scénario est aussi celui des logiciels d’intelligence artificielle classique.

“Ce qu’il faut” est fréquemment un logiciel monolithique, mais sans raison autre que sa conception est menée ainsi. De fait cette caractéristique est accidentelle.

La leçon à retenir de tout ceci est qu’il est souvent indésirable de commencer par “ce qu’il faut”. Il est préférable d’avoir la moitié de “ce qu’il faut” disponible afin qu’il se répande comme un virus. Une fois que les gens s’y sont attachés, prenez le temps de l’améliorer jusqu’à 90% de “ce qu’il faut”.

La leçon à ne surtout pas retenir serait de prendre cette parabole littéralement et d’en conclure que C est le bon véhicule pour l’intelligence artificielle. La solution à 50% doit être à peu près juste, et dans ce cas elle ne l’est pas.

Mais on peut aussi conclure que la communauté Lisp doit sérieusement reconsidérer sa position sur la conception en Lisp. J’en dirai plus sur ce sujet ultérieurement.

rpg@lucid.com

Un jour, maître Foo dit à un programmeur en visite: “Il y a plus de la nature d’Unix dans une ligne de script shell que dans dix mille lignes de C”.

Le programmeur, qui était très fier de sa maîtrise du C, dit :”Comment est-ce possible? C est le langage dans lequel est écrit le noyau même d’Unix!”.

Maître Foo repondit: “Cela est vrai. Néanmoins, il y a plus de la nature d’Unix dans une ligne de script shell que dans dix mille lignes de C”.

La détresse gagnait le programmeur : “Mais à travers le langage C nous expérimentons l’illumination du Patriarche Ritchie! Nous ne faisons plus qu’un avec le système d’exploitation et la machine, atteignant des performances sans égales!”

Maître Foo repondit: “Tout ce que tu dis est vrai. Mais il y a plus de la nature d’Unix dans une ligne de script shell que dans dix mille lignes de C”.

Le programmeur fit une grimace et se leva pour partir. Mais Maître Foo fit un signe de tête vers son étudiant Nubi, qui écrivit une ligne de script shell sur le tableau blanc tout proche et dit : “Maître programmeur, considérez ce tube (“pipe”). Implémenté en C, ne ferait-il pas près de dix mille lignes?”

Le programmeur marmonna dans sa barbe, en contemplant ce qu’avait écrit Nubi. Finalement, il admit qu’il en était ainsi.

“Et combien d’heures vous faudrait-il pour écrire et déboguer ce programme C?” demanda Nubi.

“Beaucoup.” admit le visiteur. “Mais seul un imbécile y passerait son temps alors que l’attendent de nombreuses tâches plus importantes.”

“Et qui comprend mieux la nature d’Unix?” demanda Maître Foo. “Celui qui écrit dix mille lignes, ou celui qui percevant la vacuité de la tâche, gagne en mérite en ne codant pas?”

Entendant cela, le programmeur fut illuminé.

d’après Rootless Root, the Unix koans of Master Foo.

Suite à l’embauche de l’ex patron d’HP Mark Hurd par Oracle, HP attaque son ex-employé en justice. Le moins que l’on puisse dire est que Larry Ellison n’a pas l’air content, si on en croit le communiqué de presse d’Oracle. En voici une traduction rapide :

“Oracle a longtemps considéré HP comme un partenaire important”, a déclaré Larry Ellison, CEO d’Oracle. “En émettant cette attaque en justice vindicative contre Oracle et Mark Hurd, le conseil d’administration d’HP agit avec un mépris complet de ce partenariat, de nos clients communs, de leurs actionnaires et employés. Le conseil d’administration d’HP rend virtuellement impossible pour Oracle et HP de continuer à coopérer et travailler ensemble sur le marché informatique (souligné par nous).

On peut affirmer sans trop s’avancer qu’il va y avoir du sport.

d’après Seven levels of Perl Mastery

• Novice
• Initié
• Utilisateur
• Expert
• Hacker
• Gourou

Magicien

• Tutoie la femme de Larry.
• A écrit ou récrit des parties majeures du compilateur ou de l’interpréteur Perl.
• Pense récrire le moteur d’expressions régulières, l’allocateur de mémoire ou le ramasse-miettes.
• N’écrit pas de jeux en Perl, parce qu’il a réalisé que Perl lui-même est un jeu.

d’après Seven levels of Perl Mastery

• Novice
• Initié
• Utilisateur
• Expert
• Hacker

Gourou

• Peut répondre à toute question sur Perl instantanément.
• Peut tout écrire en Perl - et le fait.
• Exploite des fonctionnalités non documentées du langage.
• Écrit du code qui étonne même Larry.
• Implémente des objets opaques et des regexps compilées en utilisant les “clôtures”.
• Peut lire et comprendre la sortie du compilateur perl en C.
• Embarque des interpréteurs Perl dans de grosses applications.
• A écrit son propre module de débogage -d:.
• A utilisé la programmation orientée-objet avant même qu’elle existe.
• Discute avec le Pumpking de prendre son tour (encore).

d’après Seven levels of Perl Mastery

• Novice
• Initié
• Utilisateur
• Expert

Hacker

• Écrit des jeux en Perl.
• A écrit des modules d’extension en C.
• Utilise AUTOLOAD et les clôtures de façon originale.
• Apprécie en esthète la “Schwartzian transform”.
• Se régale de la flexibilité du système d’objets de Perl.
• A écrit son propre traducteur pod vers X.
• Comprend la sortie de Perl -D.
• Accède directement à la table des symbôles Perl.
• Soumets des rapports de bogues avec des patchs fonctionnels.
• Édite des fichiers en utilisant une version spéciale de vi ou emacs embarquant Perl.
• A écrit des modules, des pages de manuel et des outils de la distribution standard de Perl.

d’après Seven levels of Perl Mastery

• Novice
• Initié
• Utilisateur

Expert

• Écrit des JAPHs pout impressioner ses amis et embêter ses collègues.
• Commence tous ses programmes par use strict.
• Pense que Perl doit seulement être Perl.
• A suffisemment utilisé les contextes implicites à son avantage pour ennuyer d’autres gens.
• Sait comment créer des enregistrements et des objets avec des hashrefs.
• Utilise syscall pour atteindre un appel système non documenté.
• Maudit la flexibilité du système d’objets de Perl.
• utilise /e dans les substitutions.
• A commencé à se demander à quoi peuvent bien servir les typeglobs.
• A écrit ses propres modules en Perl.
• Commence à envisager toutes les données en termes d’expressions régulières.
• Comprend pourquoi les regexps ne peuvent pas analyser des données imbriquées.
• Récrit des petits utilitaires en Perl.

d’après Seven levels of Perl Mastery

• Novice
• Initié

Utilisateur

• Pense que Perl sert seulement à manipuler du texte.
• Utilise le débogueur Perl.
• A utilisé des modules d’autres gens.
• Se demande ce qu’est un objet.
• Sait se diriger sur CPAN.
• Sait la différence entre local et my.
• Pense que Perl devrait plus ressembler à scheme ou eiffel.
• Soumet de vrais rapports de bugs avec perlbug.

d’après Seven levels of Perl Mastery

• Novice

Initié

• A commencé d’apprendre l’usage de $_ - et n’aime pas ça du tout.
• Pense que use warnings est une perte de temps.
• Pense que Perl devrait plus ressembler à C++ ou Java.
• Essaie toujours de saisir pourquoi Perl a deux sortes de tableaux.
• Say comment utiliser perlbug, mais envoie de faux rapports.
• A souffert des conversions de contexte implicites, mais ne l’a pas encore réalisé.
• Ne distingue pas == de eq, et pense que + devrait concaténer les chaînes.

d’après Seven levels of Perl Mastery

Novice

• Pense que CGI et Perl sont des termes interchangeables.
• Pense encore que Perl ressemble à du mauvais code C transmis sur une ligne bruitée.
• est incertain de l’usage du signe dollar.
• Pense que Perl devrait plus ressembler à sh ou tcl.
• A entendu parlé de “l’état d’esprit Unix”, mais espère que ça se soigne.
• Ne trouve pas comment lire des données depuis le clavier.
• Pense que les expressions régulières sont des insultes.
• Se demande pourquoi ne lui répond clairement si Perl est compilé ou interprété.

D’après www.taobackup.com

chapitre 1 chapitre 2 chapitre 3 chapitre 4 chapitre 5 chapitre 6 chapitre 7

Épilogue.

Le novice venait de terminer la vérification d’une sauvegarde de tous ses fichiers, qu’il surveillait maintenant avec un outil de contrôle d’intégrité. C’était la cinquième sauvegarde de la semaine, et il l’avait contrôlée en la restaurant, puis en vérifiant les données restaurées avant de l’enfermer à clef dans une armoire au loin, avec les sauvegardes des mois précédents.

Le novice dit “Maintenant que j’ai la complétude, la fréquence, la séparation, l’historique, la vérification, la sécurité et l’intégrité, je dois bien avoir atteint l’illumination?”

Le maître dit: “Tu n’es pas encore illuminé, mais tu es sur les dernières marches de l’échelle qui y conduit. La prochaine étape est d’acheter plus de mes solutions de sauvegarde.”

Le novice devint suspicieux et dit : “Maître, est-ce que tout ce Tao de la Sauvegarde n’est pas un prétexte pour vendre vos solutions?”

Le maître répondit : “Maintenant, tu as vraiment connu l’illumination.”

Les sauvegardes sont importantes.

D’après www.taobackup.com

chapitre 1 chapitre 2 chapitre 3 chapitre 4 chapitre 5 chapitre 6

Intégrité.

Le novice s’impatientait sur la route de l’illumination. “Maître, en tant que disciple du Tao, je sauvegarde régulièrement tous mes fichiers. Je les archive en sûreté, au loin, puis je vérifie leur intégrité. Sans doute suis-je maintenant illuminé, maître?”

Le maître des sauvegardes dit seulement : “Tu n’achèveras pas l’illumination tant que tu ne contrôleras pas l’intégrité de tes données mêmes, car une copie est inutile si l’original est corrompu. À quoi sert un miroir si nous ne voyons pas? À quoi sert un écho si nous n’entendons pas?” Mais le novice ne comprenait pas.

Plus tard, le novice revint. “Maître,” dit-il, “un pirate sur internet a pénétré mon réseau il y a six mois et a corrompu des fichiers au hasard depuis lors. Des centaines de fichiers corrompus se sont répandus dans mon système de sauvegarde. Maintenant je ne sais lesquels sont valides et lesquels ne le sont pas. J’ignore quelle sauvegarde contient la dernière copie inaltérée de chaque fichier. Que dois-je faire?”

Mais le maître restait silencieux.

De l’autre côté de la terre, le pirate riait.

Contrôlez l’intégrité des données.

D’après www.taobackup.com

chapitre 1 chapitre 2 chapitre 3 chapitre 4 chapitre 5

Sécurité.

Le maître des sauvegardes rendait visite au novice qui venait de terminer l’installation d’un système de sécurité réseau pour sa société.

“Voyez,” dit le novice, “notre sécurité est totale. Nous avons installé le plus sévère des pare-feux. Toute notre équipe a été entraînée à n’utiliser que des mots de passe obscurs et à ne les dévoiler à quiconque. Nous surveillons tout le trafic du réseau et nos courriels sont chiffrés. Nos données sont en sûreté, à l’abri de toute divulgation.”

Le maître se tint coi, mais sur le chemin de la sortie il empocha une cartouche de sauvegarde de la société totalisant 400 Go, qui traînait par là.

Plus tard, il l’expédia au novice.

Mettez vos sauvegardes en sûreté.

D’après www.taobackup.com

chapitre 1 chapitre 2 chapitre 3 chapitre 4

Vérification.

Le novice demanda au maître des Sauvegardes : “Maître, maintenant que mes sauvegardes sont complètes, que je les fais fréquemment, que je les archive et les disperse aux quatre coins de la terre, j’ai une confiance suprême en elles. Ai-je atteint l’illumination? Sans doute ai-je compris maintenant le Tao de la Sauvegarde?”

Le maître se tint immobile pendant une minute, puis soudain il brandit une hache et broya le disque dur du novice en morceaux. Puis il dit calmement : “Croire en ses sauvegardes est une chose. Avoir à les utiliser en est une autre.”

Le novice avait l’air fort inquiet.

Vérifiez vos sauvegardes.

D’après www.taobackup.com

chapitre 1 chapitre 2 chapitre 3

Historique

Le novice porta au maître une vieille cartouche de sauvegarde et demanda :”Maître, cette bande a plus de six mois. Si je veux atteindre la perfection terrestre, n’est-il pas juste de la réutiliser?”

Le maître prit la cartouche et dit : “Je la réutiliserai. Maintenant hâte-toi, va examiner ton disque dur.”

Le novice examina son disque et découvrit qu’un virus avait corrompu des centaines de fichiers importants mais peu utilisés. Il chargea la sauvegarde de la veille, mais ces fichiers étaient aussi corrompus. Il chargea une sauvegarde datant d’une semaine, mais elle était comme la précédente. Éventuellement, il réalisa que le virus avait frappé quatre mois plus tôt. Il retourna voir le maître et lui dit: “Maître, vous avez la seule copie non corrompue!”

Mais le maître avait déjà récrit la bande avec une copie de DOOM.

Le maître dit : “De même que nous respectons et prenons soin de nos ancêtres, nous devons respecter et prendre soin de nos anciennes sauvegardes, parce qu’un jour elle peuvent atteindre une grande gloire.”

Conservez d’anciennes sauvegardes.

D’après www.taobackup.com

chapitre 1 chapitre 2

Séparation

Le novice demanda au maître des Sauvegardes : “Maintenant que je sauvegarde régulièrement tous mes fichiers, suis-je illuminé dans la voie de la Sauvegarde?”

Le maître répondit :”En sauvegardant tous tes fichiers tu es sur la voie de l’illumination, mais tu ne l’atteindras qu’en répandant tes sauvegardes aux quatre coins du monde. Le pissenlit laisse-t-il choir toutes ses graines à son pied? Le coucou pond-il tous ses oeufs dans le même nid? Aussi longtemps que tes sauvegardes sont en un seul endroit, tu es vulnérable aux caprices de la fortune.”

Mais le novice n’écoutait pas, et cette nuit-là, le bâtiment brûla jusqu’au fondations, détruisant l’ordinateur du novice et toutes ses bandes de sauvegarde. Le novice vint vers le maître et dit “Maître, j’ai perdu tous mes fichiers. Que dois-je faire?”

Le maître dit “Ne désespère pas, car hier j’ai pris une de tes bandes de sauvegarde et je l’ai expédiée à mon frère en Chine. Il la renverra.”

Ce ne fut que plus tard qu’il dit au novice qu’il l’avait envoyé par fret maritime.

Conservez quelques sauvegarde au loin.

D’après www.taobackup.com

chapitre 1

Fréquence

Le novice demanda au maître des Sauvegardes : “À quelle fréquence dois-je sauvegarder mes fichiers? Un mois s’est écoulé depuis ma dernière sauvegarde.”

Le maître répondit : “Comme la nuit suit le jour, et l’automne suit l’été, ainsi les sauvegardes suivent le travail. Chaque fois que tu travailles, tu dois sauvegarder le fruit de ton labeur.”

Le novice dit:”Je travaille chaque jour.”

Le maître répondit:”Alors tu dois sauvegarder chaque jour.”

Le novice reprit: “Je suis d’accord, mais pour l’instant je n’ai pas le temps d’effectuer une sauvegarde, j’ai bien trop de travail à accomplir.”

À ces mots, le maître se tint coi.

Sauvegardez fréquemment.

D’après www.taobackup.com

Un novice voulait connaître le Tao de la Sauvegarde. Le maître lui dit: “Pour connaître l’illumination, tu dois maîtriser les sept voies de la Sauvegarde. Celui qui connaît les sept voies conservera ses données pour toujours. Celui qui ne les connait pas perdra tout.” Et ainsi commença la leçon.

Complétude

Le novice demanda au maître quels fichiers sauvegarder. Le maître dit : “Comme le berger surveille toutes les brebis de son troupeau, comme la lionne garde l’oeil sur tout ses lionceaux, ainsi tu dois sauvegarder tous les fichiers sous ta garde, quelle que soit leur importance. Parce que même le plus petit fichier peut prendre des jours à recréer.”

Le novice répondit : “Je sauvegarderai tous mes documents de travail, mais pas mon système, ni les applications, car je peux toujours les réinstaller depuis leurs supports d’origine.”

Le maître ne répondit pas.

Le jour suivant, le disque du novice fit un atterrissage de tête. Trois jours plus tard, le novice était encore occupé à réinstaller des logiciels.

Sauvegardez TOUTES vos données.

L’attaque d’Oracle contre Google à propos de sa plateforme Dalvik permet de revenir sur le passé récent et s’interroger sur l’avenir de l’héritage Sun au sein d’Oracle, en particulier les nombreuses applications libres et à source ouvertes, à savoir :

• OpenSolaris
• Java
• MySQL
• OpenOffice, VirtualBox

Le futur d’OpenSolaris

Ne le nions pas, il est plus que sombre. D’une part Oracle semble se désintéresser singulièrement de Solaris, en ne communiquant guère sur ses évolutions. Ils ont finalement annoncé cette semaine qu’une nouvelle version apparaîtrait en 2011, après de longs mois d’un silence inquiétant.

Quant à OpenSolaris, c’est l’abandon pur et simple : les ressources de développement ont été supprimées, la version prévue en mars 2010 n’a pas vu le jour, et malgré une mise à jour des sources, la version “officielle” a été officiellement abandonnée . Du coup, la (petite) communauté OpenSolaris tente de lancer un “fork”, pour ne pas rester otage du bon vouloir d’Oracle, mais c’est là que se profile une autre ombre menaçante…

NetApp vs CoRaid

Il y a quelques semaines, NetApp a envoyé une lettre de menaces (disons le mot) au petit constructeur CoRaid (développeur du ATA-over-Ethernet), pour l’obliger à retirer de la vente ses appliances sur base d’OpenSolaris. La source du problème : ZFS.

NetApp a en effet attaqué Sun en justice, pour violation de brevets (concernant le système de fichier NetApp, WAFL). Or si Sun se porte garant des utilisateurs de Solaris (la version commerciale), il n’en est pas de même pour OpenSolaris; bien au contraire, la licence CDDL exclut explicitement la violation des brevets de la responsabilité de Sun…

La licence d’OpenSolaris en général et de ZFS en particulier interdisant de faire appel à la protection d’Oracle (c’est de bonne guerre), NetApp est apparemment nettement décidé à empêcher quiconque d’exploiter ZFS commercialement, et ils en ont clairement les moyens.

Petit aparté : ceci explique sans doute pourquoi Oracle a subitement supprimé la possibilité de télécharger et mettre à jour Solaris (la version commerciale) gratuitement: Oracle ne peut guère se permettre de protéger des utilisateurs sans compensation financière, maintenant que la menace se fait bien réelle.

L’odeur du sapin

Conclusion évidente : le principal attrait d’OpenSolaris étant ZFS, OpenSolaris est bel et bien mort, en tout cas définitivement condamné à rester un outil de hobbyiste ou d’administrateur système, sans aucun avenir commercial. Les tentatives de Nexenta et quelques autres de créer des “forks” sont certainement sans avenir. Sic transit gloria mundi.

La semaine prochaine : Oracle vs Google, le choc des titans.

Les disques SSD existent depuis longtemps, mais il n’y a que récemment qu’ils sont enfin devenus à la fois relativement courants, peu coûteux et fiables. Intellique installe des serveurs avec des disques SSD depuis plus de deux ans déjà, et quelle évolution dans ce laps de temps!

De nombreux passionnés de techno ( qui a dit “geeks”? ) cependant, sont déjà impatients de voir les nouvelles fonctionnalités que promettent les constructeurs, en particulier :

• la commande TRIM et le “Garbage Collector”
• l’interface SATA3

Je me dois donc de vous expliquer tout d’abord ce que sont ces fonctionnalités, ensuite à quoi elles servent, ensuite pourquoi nous ne les proposons pas déjà :)

La fonction TRIM

La commande TRIM permet de demander explicitement à un SSD d’effacer un bloc de données. Il faut savoir qu’un SSD peut écrire généralement des blocs de 4 Kio (appelés pages), mais ne peut effacer que des blocs de 128 Kio ou plus. Ceci peut réduire drastiquement les performances en écriture lorsqu’on modifie des blocs précédemment écrits : en effet, avant de pouvoir écrire telle page de 4 Kio, il faut relire le bloc de 128 Kio auquel elle appartient, le modifier dans une mémoire cache, l’effacer puis le récrire entièrement. On se retrouve donc à lire 124 Kio, effacer le bloc puis écrire 128 Kio pour effectivement modifier 4 Kio… soit à manipuler 64 fois plus de données que prévu, entraînant par là une réduction équivalente de la performance.

Comment pallier ce grave problème? les constructeurs de disques SSD rivalisent d’ingéniosité pour éviter d’avoir à récrire un bloc déjà alloué. Cependant la seule bonne solution réside au niveau du système d’exploitation, qui lui choisit quels blocs utiliser et comment. Cependant, pour tirer la quintessence des SSD, il faut profondément modifier la manière dont nos systèmes de fichiers organisent les données. En fait, il faut même utiliser de nouveaux systèmes de fichiers optimisés pour cela.

C’est là qu’entre en jeu la commande TRIM. Un système de fichier optimisé pour l’utilisation de SSD peut allouer les blocs de manière à éviter les réécritures, et d’autre part demander au disque d’effacer certains blocs de façon à libérer de l’espace en avance plutôt qu’au moment précis où l’on en a besoin. C’est justement ce qu’on appelle un “ramasse miettes”, en anglais “Garbage collector”.

Et nous touchons le premier point délicat : pour utiliser la commande TRIM à bon escient, il faut un nouveau système de fichiers. Adieu, les bons vieux NTFS, ext3 et autres HFS+. On conçoit l’ampleur du problème : vu la difficulté à se débarrasser des scories de MS-DOS et de FAT32, quand les éditeurs seront-ils prêts? Et bien, pas avant un certain ( et même très certain ) temps.

La fonction TRIM et le stockage professionnel

Mais il y a pis : si on peut espérer voir poindre bientôt ( un an? 18 mois?) des solutions matures pour les disques durs SSD destinés aux ordinateurs portables, le problème est encore bien plus épineux en ce qui concerne le stockage d’entreprise. En effet, dans ce cas on utilise les disques ( SSD ou pas ) en grappes RAID, ce qui ajoute un nouveau lot de difficultés :

• L’information permettant d’émettre la commande TRIM est disponible au niveau du système de fichier uniquement; à ce jour seuls certains systèmes de fichiers expérimentaux dédiés à l’utilisation sur SSD la supportent. On évitera de mettre des données critiques sur un système de fichier expérimental…

• dès l’instant où le système de fichier repose sur une couche d’abstraction comme LVM ou un RAID logiciel, il faut implémenter des mécanismes permettant :

  • au système de fichier d’indiquer au gestionnaire de volume sous-jacent qu’il implémente la commande TRIM;
  • au gestionnaire de volume d’indiquer au système de fichier hôte que le(s) périphériques sous-jacents supportent la commande TRIM;
  • enfin et c’est le plus complexe, implémenter dans les gestionnaires de volume les mécanismes permettant la translation des adresses virtuelles de blocs du volume logique en blocs physiques sur lesquels appliquer la commande TRIM.

• de plus, si l’on utilise un contrôleur RAID matériel, il faut également implémenter une norme générale et des méthodes au niveau de chaque pilote de périphérique concerné pour faire de même, c’est à dire indiquer à la couche d’abstraction de niveau bloc que les périphériques blocs sous-jacents supportent le TRIM, d’autre part transmettre les commandes TRIM de façon correcte en faisant les translations d’adresses nécessaires.

On peut donc conclure avec une certaine confiance que nous sommes encore assez loin de pouvoir profiter de la commande TRIM dans les systèmes d’entreprise…

Le SATA 3

Le SATA-3 est la nouvelle norme SATA 6 Gigabits par seconde, qui doit permettre de tirer le meilleur parti des disques SSD. En effet, les 3 Gb/s du SATA-2 permettent de faire transiter au grand maximum 384 Mo/s; or certains SSD peuvent déjà faire mieux. De plus cette nouvelle norme intègre le dernier jeu de commande ATA, dont la fameuse “TRIM”.

Formidable, passons vite au SATA-3!

Petit problème, aucun disque n’existe actuellement à cette norme. Celle-ci a fait son apparition dans le domaine grand public très récemment sur quelques cartes-mères et n’est que très rarement disponible, et il faudra patienter avant qu’il existe des solutions professionnelles (contrôleurs RAID, disques) la supportant.

Inutile d’attendre!

Heureusement, la conclusion générale est malgré tout positive! En effet, les disques SSD ont déjà un immense avantage sur les disques durs ordinaires : leur temps d’accès fabuleusement réduit. Ceci constitue la véritable révolution et le principal attrait du SSD dans le monde de l’entreprise, et on, peut en profiter sans TRIM, sans “garbage collector” et sans SATA-3. Une grappe RAID de quelques disques SSD peut en effet soutenir plusieurs dizaines de milliers d’opérations par seconde, c’est à dire la performance de quelques centaines de disques SAS hors de prix. C’est d’ores et déjà une révolution pour toutes les applications transactionnelles, et nul besoin d’attendre pour en tirer parti! Qui ne rêve de remplacer une pleine armoire de disques en SAN par un simple serveur de 1 ou 2U de rack? C’est déjà une réalité.

Quelques liens :

• La commande TRIM
• Garbage Collection Impact on SSD (en anglais)