Stockage : comprendre les mécanismes du Thin provisionning

Personne ne veut payer pour une ressource inutilisée, mais les administrateurs stockage le font tout le temps. La nature souvent inflexible des procédures d'achat de stockage (on achète dès le départ une baie configurée avec plus de disques que nécessaire), la tendance naturelle à acheter plus que nécessaire pour se protéger d'éventuelles demandes imprévues sont autant de facteurs qui conduisent les entreprises à sous-utiliser de façon surprenante les capacités disponibles – avec les inconvénients liés en matière de consommation électrique. C’est pourquoi l’amélioration de l'efficacité de stockage est un thème récurrent de l'industrie et un objectif pour la plupart des professionnels du stockage depuis une décennie. Reste que malgré tous les efforts ou initiatives passées, rares sont les technologies qui se sont montrées capables d'optimiser de façon tangible l'usage des capacités installées : le Thin provisioning est l'une d'entre-elles.

Les mécanismes du Thin Provisionning reposent sur un concept simple : plutôt que d'attribuer ou de réserver dès le départ la capacité physique nécessaire à une application, au risque de se retrouver avec une partie inutilisée, la capacité physique est allouée dynamiquement au fur et à mesure des besoins réels. Cette astuce permet une bien meilleure utilisation de la capacité disponible dans la baie. Elle permet aussi de démarrer en production avec un minimum de disques et de n’ajouter de nouvelles capacités qu’au fur et à mesure qu'apparaissent les besoins réels, ce qui est aussi en phase avec les objectifs de réduction de la consommation électrique dans les datacenters.

Allocation de capacité au fil de l'eau

Avec le provisionning de stockage traditionnel, il y a une correspondance un pour un entre la capacité allouée à un serveur et la capacité provisionnée sur la baie de stockage. Ainsi, si l’on provisionne un LUN de 100 Go pour un serveur Windows, ces 100 Go sont immédiatement « immobilisés » sur la baie, qu’il y ait effectivement 100 Go ou 3 Go de données stockées sur le serveur.

Avec le Thin provisionning, lorsque l’on crée un volume de 100 Go, ces 100 Go ne sont pas consommés immédiatement. Ils sont en fait alloués de façon granulaire par page ou par bloc (selon les capacités de la baie). Au fur et à mesure que de nouvelles données sont écrites, de nouvelles pages sont allouées par la baie et la capacité de stockage disponible sur la baie diminue en conséquence.

L’un des problèmes est que les volumes ainsi créés ne restent vraiment « minces » que pour un temps. Les systèmes de fichiers traditionnels, comme FAT32, NTFS ou Ext4, ne font en effet pas la différence entre un disque traditionnel et un volume « thin provisionné » - ce qui est normal puisque la baie fait tout pour masquer la nature « mince » du volume. Pour éviter la fragmentation des fichiers, ils ont tendance à privilégier l’usage de nouveaux blocs pour la création de nouveaux fichiers. Les fichiers effacés quant à eux sont mis à zero – littéralement, leur contenu est remplacé par des zéros. Progressivement, un volume « mince » va donc grossir et la part d’espace occupé par des plages de zéro va s’accroitre, ce qui nuit à l’efficacité du système. Cela ne veut as dire que  le Thin provisioning devient inutile mais simplement que sans mécanisme de récupération de ces espaces de zéro, son efficacité à terme va se réduire. Les constructeurs ont donc tous adopté des stratégies pour lutter contre ce problème en mettant notamment en œuvre des techniques de réclamation d’espaces vides.

Des volumes au régime en permanence…

Et c’est là que tous les systèmes de Thin provisionning ne se valent pas : tous ne sont en effet pas capables de récupérer les espaces occupés par des zéros ou en tous cas pas avec la même efficacité.

Le problème principal est que les applications  - et notamment les systèmes de fichiers - et les baies de stockage ne communiquent pas efficacement. Les systèmes de fichiers ne sont généralement pas conscients que le volume est « mince » et donc ne peuvent transmettre à la baie l’information qui lui permettrait de récupérer immédiatement un espace effacé.

Il n’existe donc que deux façons de récupérer de l’espace :

•   soit la baie de stockage balaie régulièrement, en tâche de fond, les données stockées à la recherche de plages de zéros pour les récupérer;

•  soit le système de fichier est modifié pour communiquer avec la baie pour l‘informer en temps réel. C’est un travail qu’a par exemple effectué Symantec avec le file System de Veritas pour les baies de 3Par, Compellent, EMC, HDS, IBM et Netapp en créant sa « Thin Reclamation API ».

La première option est de toute façon nécessaire puisque, dans l’immédiat, tous les vendeurs de systèmes d'exploitation ne semblent pas désireux de modifier leur code pour ajouter des fonctionnalités « minces » . Mais elle est compliquée à mettre en œuvre car il faut s’assurer de ne pas mettre en péril la compatibilité de la baie avec les différents systèmes de fichiers. Mais la clé pour l’avenir est sans doute dans la standardisation de mécanismes de communication entre les baies et les systèmes de fichiers.

En attendant la standardisation…

Même si une baie a une fonction de récupération de « pages zéro » encore faut-il que les zéros en question soient écrits. La plupart des systèmes d'exploitation ont besoin d'une commande spécifique, comme Windows "SDelete - c". Mais ce genre de commande n’est exécuté que très occasionnellement.

Certains comme VMware ESX  savent effectivement mettre à zéro les nouveaux espaces. La commande ESX "eagerzeroedthick" remplit ainsi de zéros l’intégralité d’un volume nouvellement créé  - un processus accéléré par l’API vStorage for Array Integration (Vaai) sur les baies compatibles.  Les fonctions de réclamation de la baie peuvent dès lors fonctionner à plein.

Nous avons évoqué plus haut le cas de VxFS, le système de fichier de Symantec et l’API Veritas Thin Reclamation, mais on peut aussi signaler le cas du support de la commande TRIM par les principaux environnements Windows et Linux (ainsi que par Mac OS X). Un support qui a requis de subtiles modifications destinées à optimiser leur fonctionnement avec les disques SSD et qui préfigure sans doute les évolutions que pourraient subir ces OS pour optimiser leur fonctionnement sur des volumes « minces ».

Article inspiré et partiellement adapté d’un article de Stephen Foskett par Christophe Bardy, LeMagIT. Steve Foskett est un consultant responsable de Gestalt IT, une communauté d’utilisateurs IT américains que vous pouvez retrouver sur GestaltIT.com.