Dossier stockage : Thin Provisionning ou l'art de se serrer la ceinture (dernière partie)
Les mécanismes d’allocation granulaire de capacité (Thin Provisioning en anglais) sont apparus au début des années 2000 et ont notamment été popularisés par 3PAR avec ses baies inServ, mais aussi par des solutions de virtualisation de stockage comme celles de DataCore (avec ses outils de sur-allocation). Ils ont depuis été intégrés par la plupart des constructeurs comme Compellent, EMC, HDS, HP, NetApp ou Pillar Data Systems dans leurs baies - parfois sous des noms différents, par exemple Virtual Provisionning chez EMC… Il est à noter qu'IBM a, quant à lui, ajouté le Thin Provisionning à ses baies DS8000 et XIV, mais aussi à son appliance de virtualisation Storage Volume Controler (SVC).
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 en phase avec les objectifs de réduction de la consommation dans les datacenters.

Traditionnellement, pour allouer une ressource de stockage SAN à un serveur, on crée un LUN (Logical Unit Number, équivalent d'une partition dans le monde SAN) sur la baie et on le met à la disposition de son système de gestion de fichiers. Dans la plupart des cas, ce LUN n'est utilisé que pour une fraction de sa capacité, disons dans le meilleur des cas 40 à 50 %. 50 à 60 % de l'espace physique est donc immobilisé pour rien. Répliqué à l'échelle de dizaines de serveurs, ce processus est source de gaspillage. L'idée avec le Thin Provisionning est de créer un pool de stockage et de le mutualiser entre les différents serveurs.
Mais le Thin provisionning doit aussi être manié avec précaution. Une gestion trop agressive des capacités disponibles peut en effet conduire à l'extrême à des catastrophes. En théorie, le Thin Provisionning permet en effet d'allouer à de multiples applications bien plus de capacité que ce dont dispose réellement la baie. Si une application venait à consommer les ressources disponibles de façon imprévue, elle pourrait littéralement cannibaliser l'espace requis par d'autres applications. Un phénomène similaire à celui de la sur-réservation dans un avion. A ceci près que, si une application ne dispose pas de l'espace disque dont elle a besoin, les conséquences sont en général catastrophiques. L'usage de l'allocation granulaire de capacité contraint donc l’administrateur à une plus grande vigilance. Il lui faut en effet veiller à ce que la capacité physique disponible sur les baies soit toujours supérieure à celle requise par le système d’allocation dynamique.
Attention aux performances
Un autre obstacle potentiel réside dans les questions de performances : en concentrant plus d'accès sur un nombre réduit de LUN, le Thin Provisionning peut avoir un impact sur les performances délivrées. C'est en général pourquoi il est associé à l'aptitude de la baie à distribuer les blocs sur un grand nombre de disques. Par exemple, HDS n'a implémenté le Thin Provisionning qu'en parallèle du stripping (construction d'un LUN en distribuant les données sur un grand nombre de disques) à grande échelle de données (Wide Striping).
Concrètement le Thin Provisionning est une forme de virtualisation du stockage, puisque l’objectif de la technologie est de masquer au système de gestion de fichier le fait qu’il ne dispose pas, à un instant donné, des ressources physiques dont il croit pourtant disposer. Et comme toute couche de virtualisation de stockage, il peut être plus ou moins bien implémenté. Techniquement, il semble que les constructeurs de baies virtualisant l'allocation de stockage au niveau du bloc de données tels que 3Par, Compellent ou LeftHand (HP) ont l'avantage en matière de Thin Provisionning. Leur aptitude à positionner un bloc n'importe où dans la baie, sans organisation préalable de son espace, est en effet une carte maîtresse dans l'aptitude à délivrer des augmentations granulaires de capacité.
Une technologie qui n'est pas exempte de petits défauts
Cela ne veut pas dire que ces baies sont à l'abri des surprises. La plupart des systèmes de gestions de fichiers présument en effet qu'ils ont le contrôle de la pleine capacité que la baie leur alloue et prennent donc des décisions d'allocation de bloc et de positionnement de données qui s'appuient sur ce qu'il croient être la meilleure façon d'optimiser les performances. Ce qui est historiquement valide sur un disque dur, n'a toutefois plus aucun sens dans un environnement de stockage virtualisé et dont la capacité évolue dynamiquement.
NTFS, par exemple, crée une table des fichiers au début du volume et un mirroir partiel de cette table en milieu de volume. Le File System positionne aussi des fichiers sur le volume et fait en sorte qu'ils soient inamovibles (ces fichiers sont eux aussi souvent positionnés en milieu de volume). Les mécanismes d'allocations de blocs de NTFS sont aussi tels que le File System n'utilise pas par défaut les blocs les plus proches du début du volume pour écrire de nouvelles données. De même, il ne réécrit pas forcément en priorité sur les données qui ont été effacées. Le résultat : un volume NTFS, même avec Thin Provisionning, peut rapidement occuper une large part de l'espace qui lui a été alloué. Autre problème, ce n'est pas parce qu'une baie supporte le Thin Provisionning que tout est possible. Par exemple, dans l'implémentation d'EMC, la migration d'un LUN traditionnel vers un LUN avec Thin Provisionning n'apporte aucun bénéfice, la baie allouant l'intégralité de l'espace occupé par le LUN d'origine. Bref, les petits détails comptent...
Ne pas transformer la baie en gruyère
La technologie elle-même introduit son lot d'inefficacités. Ainsi la taille des blocs utilisés par le système de Thin Provisionning varie de 16 Ko chez 3PAR à 42 Mo sur un USP-V. Or, la plupart des File System sont paramétrés pour utiliser par défaut des blocs de 4 Ko. Le risque est donc de voir apparaître un phénomène de gruyère dans la baie au fur et à mesure des créations, effacements et déplacements de données dans un environnement géré par un système d'allocation dynamique de capacité. Là encore, certains constructeurs ont prévu des remèdes, comme HDS avec sa fonction de "réclamation" de blocs inutilisés (Zero Page Reclaim) ou 3Par, qui a récemment annoncé un ensemble de technologies pour récupérer des blocs inutilisés. L'une d'entre elles est d'ailleurs le fruit d'une alliance avec Symantec, qui a fait évoluer son système de gestion de fichiers VxFS pour qu'il s'adapte à la réalité du Thin Provisionning.
Notons pour terminer que Storage Foundation, la couche de gestion du stockage de Symantec, est capable de migrer des données d'espace de stockage traditionnels vers des espaces dynamiques en optimisant au passage la capacité occupée. Le logiciel est notamment optimisé pour fonctionner avec les implémentations de 3PAR, HDS (y compris baies HP XP et Sun) et NetApp.
- Veritas Storage Foundation et le Thin Provisionning
Téléchargez cet article au format PDF









Par DS45


