Dossier stockage : Thin Provisionning ou l'art de se serrer la ceinture (dernière partie)
Pour boucler notre dossier stockage, nous abordons la question à la mode de l'allocation dynamique ou granulaire de capacité, aussi baptisée Thin provisionning par les constructeurs américains. Une technologie qui, bien utilisée, peut permettre de considérables économies. Nous concluons ce dossier avec l'exemple de Lectra Systems, qui a récemment refondu son stockage en mixant iSCSI et Fibre Channel sur une architecture redondante.
 Dossier sponsorisé par EMC |
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.
En savoir plus :
| Dossier sponsorisé par EMC |
Lectra a récemment réorganisé son infrastructure de stockage en mettant en place deux baies jumelles Clariion CX4 en réplication synchrone sur son campus bordelais. Cette infrastructure, qui mixe iSCSI et Fibre Channel est au centre de l'IT du groupe.
Spécialiste des logiciels de design, de découpe et de prototypage pour la mode et l'industrie, l'éditeur bordelais est un familier des architectures de stockage en réseau. Son centre informatique de Bordeaux Cestas, qui concentre l'informatique du groupe au niveau mondial, a ainsi déployé son premier SAN Fibre Channel, basé sur une baie HP, au début des années 2000.
2005 : le périmètre du SAN s'élargit
Depuis, l'usage des réseaux de stockage n'a cessé de se développer. En 2005, Lectra a ainsi décidé d'élargir le périmètre de son SAN au stockage de l'ensemble de ses applications les plus critiques – ERP (Oracle), CRM (Siebel), messagerie (Exchange), applications de R&D – ainsi qu'à celui des données bureautiques (l'accès en mode NAS se faisant au travers des services de partage de fichiers de Windows Server). Comme l'explique Jean-Christophe Glot, le DSI de Lectra, le stockage est au coeur du SI, comme le réseau, et il n'était plus question de maintenir des silos isolés.
A l'époque, Lectra lance un appel d'offre mettant l'accent sur sa volonté de mettre en place une solution de réplication des données du site principal sur le site de secours situé à 300 mètres. La société retient finalement la solution proposée par EMC et son intégrateur APX, comprenant notamment l'installation de deux baies Clariion CX-500 et de la solution de réplication Mirrorview. Cette technologie permet à la sociéte de répliquer de façon croisée les données situées sur chacune des baies dans un mode actif/actif (la société a réparti ses équipements dans ses deux salles).
2009 : allier iSCSI et Fibre Channel
Fin 2008, dans un contexte de virtualisation croissant de ses applications, Lectra renouvelle sa confiance à EMC après un appel d'offre auquel ont aussi participé NetApp et HP. L'un des atouts qui séduit la société est notamment la possibilité de mettre en place une connectivité iSCSI en parallèle de la connectivité Fibre Channel, retenue en 2005.
Comme l'explique Jean-Christophe Glot, si l'utilisation de Fibre Channel se justifie pour les applications critiques de la société, iSCSI permet quant à lui de démocratiser la connexion SAN pour les autres applications. Dans un contexte de production largement virtualisée (pour l'essentiel sur serveurs x86 sous VMware ESX Server 3.5), iSCSI est aujourd'hui utilisé par environ la moitié des 250 serveurs de la société - ceux pour lesquels le coût de Fibre Channel ne se justifiait pas - pour accéder aux deux baies SAN EMC Clariion CX4.
Jean-Christophe GLot souligne aussi le bond en terme de performances apporté par les CX4 par rapport au CX500 antérieurs. Selon lui, Lectra a observé des gains moyens de l'ordre de 30 %. Seul bémol, ce n'est pas la baie qui limite les débits sur le SAN mais le File System de VMware (VMFS) qui, avec ESX Server 3.5, constitue un point de contention. La solution pour l'instant, en attendant la migration vers vSphere : limiter le nombre de VM par volume VMFS.
Migration vers vSphere en ligne de mire
Interrogé sur l'usage du Thin Provisionning, Jean-Christophe Glot indique qu'il n'a pas été utilisé pour l'instant. En revanche, la société fait usage de l'intégration étroite entre les fonctions de réplication des baies Clariion et la solution de plan de reprise de VMware, Site Recovery Manager, qui lui a permis d'automatiser son plan de reprise. Lectra entend aussi tirer un usage maximal de l'intégration de PowerPath, la solution de multipathing réseau d'EMC, avec vSphere, lors de sa migration vers la nouvelle plate-forme de VMware. Une migration qui devrait s'achever au premier semestre 2010. Plus généralement, Jean-Christophe Glot se dit satisfait de l'intégration entre les solutions VMware et EMC - qui font partie du même groupe - et de la qualité du support apporté par la firme d'Hopkington sur les questions du stockage en environnement virtualisé.
Notons pour terminer que le renouvellement de l'infrastructure de stockage a aussi été l'occasion de doper sensiblement la capacité des baies en disques SATA pour la porter à 30 To (sur un total de 50 To). Cette capacité est notamment réservée à des fins d'archivage, la capacité en Fibre Channel étant utilisée pour les applications et les serveurs virtualisés sous VMware. L'objectif de la société est de sauvegarder 80 % de ses données sur disques (contre 20 % avant l'arrivée des CX4) afin de réduire les fenêtres de sauvegarde. Une obligation pour une entreprise dont la production informatique tourne 24 heures sur 24 et dont les utilisateurs sont répartis sur près de 40 sites dans le monde.
Pour approfondir sur SAN et NAS
-
![]()
Kaminario décline ses baies SAN virtuelles en cloud public
Par: Yann Serra
-
![]()
HP Discover : HP présente une baie 3PAR 100% Flash
Par: Cyrille Chausson
-
![]()
SNW Francfort : Fujitsu adopte une approche plus modulaire pour son stockage haut de gamme
Par: Christophe Bardy
-
![]()
Avec Pillar Data Systems, Oracle se met à la hauteur de Dell et HP
Par: Cyrille Chausson
