XtremIO : Sauvé par les zéros ! (traduction)

Cet article sur XtremIO.com m’a paru tellement intéressant que j’ai pris la liberté de le traduire en français, dans la mesure de mes capacités, bien entendu. J’ai également fait quelques raccourcis et résumés sur certaines parties non essentielles, de mon point d e vue. J’espère que cela pourra vous aider.

Bonne lecture !

Pourquoi les blocks “zéro” sont-ils si spéciaux ?

Dans la plupart des systèmes d’exploitation, lorsque vous formattez un disque ou un volume quel qu’il soit, en général, vous le remplissez de zéro (ndt: en tout cas, vous supposez que c’est le cas, on le verra plus tard, c’est important). Parce que cette opération est particulièrement courante au niveau stockage, VMWare a défini une commande VAAI spécifique pour décharger le système d’exploitation de cette tâche, au profit de la baie elle-même. L’hyperviseur est donc soulagé de cette opération et accessoirement, elle est réalisée de manière beaucoup plus efficace par le stockage sous-jacent.

Les blocs Zéro sont également important dans le monde du stockage flash, mais pour une raison bien différente. En effet, le desgin d’une cellule flash impose, pour procéder à l’écriture d’un bloc de 4K quelconque, que vous l’effaciez préalablement. C’est à dire que vous la remplissez de zéro avant de la ré-écrire. De plus, vous ne pouvez pas vider un bloc individuel de 4K, en effet, vous ne pouvez effacer que le groupe entier dont il dépend (128 blocs, voir plus). Cette opération est particulièrement gourmande en temps et en énergie, vous vous en doutez. Pour pouvoir masquer cette complexité de la remise à zéro, les controleurs de SSD actuels fournissent à leur hôte une carte d’allocation virtuelle de leur espace physique, ce qui leur permet d’optimiser les écritures en validant rapidement celles-ci dans un espace de type “spool d’écriture”. Pendant ce temps, le contrôleur s’occupe, en tâche de fond, de récuperer les blocs qui ont été invalidés par les écritures récentes et donc d’éviter que la remise à zéro de l’ensemble d’un groupe ne grève trop les performances.

En conclusion, sachant qu’écrire des blocs Zéro (ou effacer des blocs existants) sur un SSD est une tâche lourde et consommatrice d’énergie, comment une baie de stockage conçue pour le flash peut-elle limiter au maximum ces opérations ?

Les baies de stockage “flash” n’appliquent aucun traitement particulier pour les blocs zéro

Malgré le fait que ces fameux blocs zéro soient très particuliers dans le monde du stockage flash, un nombre important de baies de type AFA (All-Flash-Arrays) n’ont aucun traitement spécifique sur ceux-ci. Elles utilisent les mêmes processus internes pour traiter les données globalement. La raison principale de ce constat est que les baies actuelles n’analysent pas les données à traiter en temps réel, elles ne sont pas “content-aware” (ndt: difficile de traduire un terme aussi efficace ;) ). Elles lisent et écrivent les données sur les LUNs sans faire attention à ce que les blocs en question contiennent.

A l’opposé, une baie comme XtremIO, conçue dès le départ comme un produit analysant en temps réel le contenu des blocs qui lui sont envoyés (pour assurer la déduplication inline, notamment), est capable d’avoir un traitement particulièrement adapté à la spécificité du bloc zéro, sans recourir à une magie particulière (ndt: mais avec une élégance presque magique, voir plus bas ;) ).

Les blocs zéro sont X’trèmement spéciaux sur XtremIO

Le mécanisme intrinsèque de déduplication à la volée d’XtremIO implique qu’il n’existe jamais plus d’une copie d’un bloc donné sur la baie. On pourrait imaginer que lorsque la baie reçoit un bloc zéro, il soit traité de la même manière que les autres, ainsi, la signature unique du bloc zéro étant bien évidemment toujours la même, il y aurait vite “un bloc zéro” positionné quelque part sur les disques SSD.

Les concepteurs d’XtremIO ont en fait été beaucoup plus loin, du fait notamment de l’universalité des blocs zéro dans de nombreux cas d’usage (bdd, applications, filesystems etc. …). S’il on pouvait résumer en une phrase ce comportement ce serait : un bloc zéro, pas de problème… je ne fais rien, nada, ZERO!

Lorsqu’un hôte tente d’écrire un bloc zéro sur une baie XtremIO à un endroit quelconque de son LUN, celle-ci reconnait donc automatiquement ce bloc de 4K rempli d’octets à zéro – car la signature de ce bloc est bien entendu unique -. Lors de l’identification, la baie accuse tout de suite réception de ce bloc (ndt: et valide l’I/O, donc) mais ne fais rien de plus, le traitement s’arrête là ! Pas d’écriture sur la table de localisation des blocs, pas de mapping sur les signatures et – a forcieri – pas d’écriture sur disque.

L’écriture, certes, est la partie facile. Mais évidemment, une baie de stockage est sencée renvoyer les bonnes données en cas de lecture, c’est un minimum ;) . Lorsqu’XtremIO recoit une demande de lecture sur un bloc zéro préalablement écrit, il ne va pas trouver la correspondance de ce bloc dans la table d’allocation. Dans ce cas, la baie a ordre de renvoyer un bloc zéro, tout simplement. Problème résolu !

Comme vous pouvez le constater, la lecture et l’écriture des bloc zéro sont particulièrement efficaces et accesoirement ne solicitent JAMAIS les disques SSD. On gagne sur les deux tableaux.

Certains d’entre vous, plus perspicaces, trouveront sans doute des failles potentielles vis à vis de cette optimisation. En fait, les développeurs d’XtremIO ont particulièrement fait attention à couvrir tous les cas possibles. Par exemple, si un hôte tente de lire un bloc qui a été déjà écrit, puis logiquement supprimé de la table d’allocation (une commande unmap, techniquement parlant). Dans ce cas le retour est un bloc zéro. Mais, rappelez-vous que c’est précisément le comportement attendu par une LUN avec des blocs vides lors de son formattage initial !

Dernier cas, le plus improbable : qu’arrive-t-il si l’hôte tente de lire un bloc inconnu, jamais ni lu ni écrit auparavant ? Comme il est non-initialisé, lire un bloc de ce type est sensé renvoyer un retour “non identifié”, donc totalement aléatoire. Ceci étant, renvoyer un bloc zéro à la place est, finalement, au moins aussi sécurisé que de renvoyer n’importe quoi d’autre ;)

En conclusion : XtremIO renvoie toujours le meilleur résultat possible en face d’un traitement d’un bloc zéro. Comme ces blocs zéro sont employés très souvent en base de données, en virtualisation, ces optimisations spécifiques fournissent une vraie plus-value en terme d’utilisation/temps de réponse et préservent également grandement les cellules flash du stockage physique sous-jacent.

De plus, étant donné que la baie XtremIO est intrinsèquement “thin-provisionnée” (ndt: pas de traduction en bon français technique ;) ), lorsqu’un serveur créé un disque virtuel de type “complet-zéro” (un disque complètement alloué et rempli de zéro), finalement, la baie ne fait strictement rien et ne consomme pas un octet sur disque ! De plus ce type de formattage est forcément extrèmement rapide, car seul les CPUs des contrôleurs sont sollicités.

Source (anglais) : http://www.xtremio.com/saved-by-zero