Livre blanc. Technologies "thin" HP Comparaison avec les solutions concurrentes

(1)

89 Fifth Avenue, 7th Floor New York, NY 10003,

Etats-Unis www.TheEdison.com

212.367.7400

Livre blanc

Technologies "thin" HP Comparaison

avec les solutions concurrentes

(2)

Imprimé aux Etats-Unis

Copyright 2012 Edison Group, Inc. New York. Edison Group n'apporte aucune garantie, expresse ou implicite, concernant les informations contenues dans ce document, et décline toute responsabilité en cas d'erreur découlant de leur utilisation.

Tous les noms de produits sont des marques commerciales de leurs propriétaires respectifs.

Première édition : Septembre 2012

Equipe de rédaction : Chris M Evans, Analyste principal ; John Nicholson, Analyste principal ; Barry Cohen, Rédacteur en chef ; Manny Frishberg, Réviseur

(3)

Sommaire

Sommaire ___________________________________________________________ 2 Résumé à l'intention des décideurs ______________________________________ 1 Introduction _________________________________________________________ 2 Objectif _________________________________________________________________2 Public concerné ___________________________________________________________2 Terminologie_____________________________________________________________2 Vue d'ensemble ______________________________________________________ 3

Présentation de l'allocation dynamique ______________________________________3 Inconvénients de l'allocation dynamique _____________________________________4 Technologie "thin" de HP 3PAR StoreServ _________________________________ 5 Analyse de la concurrence _____________________________________________ 6 EMC VMAX _______________________________________________________________6

Aperçu général _________________________________________________________________ 6 Comparaison avec HP 3PAR StoreServ — Démarrer "thin" ______________________________ 6 Comparaison avec HP 3PAR StoreServ — Devenir "thin" ________________________________ 7 Comparaison avec HP 3PAR StoreServ — Rester "thin" _________________________________ 7 Restrictions inhérentes au système VMAX ___________________________________________ 7 NetApp __________________________________________________________________8

Aperçu général _________________________________________________________________ 8 Comparaison avec HP 3PAR StoreServ — Démarrer "thin" ______________________________ 8 Comparaison avec HP 3PAR StoreServ — Devenir "thin" ________________________________ 9 Comparaison avec HP 3PAR StoreServ — Rester "thin" _________________________________ 9 Hitachi VSP ______________________________________________________________9

Aperçu général _________________________________________________________________ 9 Comparaison avec HP 3PAR StoreServ — Démarrer "thin" _____________________________ 10 Comparaison avec HP 3PAR StoreServ — Rester "thin" ________________________________ 10 EMC VNX _______________________________________________________________ 11

Comparaison avec HP 3PAR StoreServ — Démarrer "thin" _____________________________ 11 Comparaison avec HP 3PAR StoreServ — Devenir "thin" _______________________________ 11 Comparaison avec HP 3PAR StoreServ — Rester "thin" ________________________________ 11 Questions de performances ______________________________________________________ 12 IBM XIV _______________________________________________________________ 12

Comparaison avec HP 3PAR StoreServ — Démarrer "thin" _____________________________ 12 Comparaison avec HP 3PAR StoreServ — Devenir "thin" _______________________________ 12 Comparaison avec HP 3PAR StoreServ — Rester "thin" ________________________________ 13 Dell Compellent ________________________________________________________ 13

Comparaison avec HP 3PAR StoreServ — Démarrer "thin" _____________________________ 13 Comparaison avec HP 3PAR StoreServ — Devenir "thin" _______________________________ 14 Comparaison avec HP 3PAR StoreServ — Rester "thin" ________________________________ 14 Présentation des tests et méthodologie _________________________________ 15

(4)

Test 2—Pré-allocation d'une capacité importante ____________________________ 16

Résultats du test ____________________________________________________ 17 Test 1—Performances Zero-Page-Reclaim __________________________________ 17 Test 2—Pré-allocation d'une capacité importante ____________________________ 20 Conclusions et recommandations ______________________________________ 22

Méthodes recommandées ________________________________________________ 22 Annexe A—Documents de référence ____________________________________ 24 Annexe B—Caractéristiques des équipements de test _____________________ 25 Baies _________________________________________________________________ 25 Serveurs ______________________________________________________________ 25

(5)

Résumé à l'intention des décideurs

A une époque où la nécessité de faire davantage avec moins de moyens est une évidence pour un grand nombre d'entreprises, de nombreux services informatiques font tout pour optimiser l'usage de leurs ressources. Or le stockage reste l'un des principaux postes de coût dans le déploiement des infrastructures actuelles. Les technologies dites "thin", et notamment l'allocation dynamique, entraînent des gains d'efficacité qui permettent de réduire considérablement aussi bien les dépenses d'investissement que les frais d'exploitation. Toutefois, la mise en œuvre de ces technologies "thin" diffère selon le fournisseur de stockage.

Fer de lance des technologies "thin", la plateforme HP 3PAR StoreServ répond à trois impératifs majeurs :

1. Démarrer "thin" : assurer une allocation dynamique du stockage en limitant au maximum les surcharges.

2. Devenir "thin" : faire en sorte que les données déplacées vers HP 3PAR StoreServ restent thin après leur migration.

3. Rester "thin" : garantir une efficacité optimale du stockage des données sur la durée.

Pour vérifier le bien-fondé de cette affirmation, Edison a procédé à une étude de la

documentation disponible, mené des entretiens approfondis avec les clients et réalisé deux tests :

1. Performances de la fonction Zero-Page-Reclaim : ce test permet de vérifier la capacité à récupérer les ressources libérées dans le cadre d'opérations normales.

2. Pré-allocation d'une capacité importante : teste l'aptitude à créer de nouveaux volumes de stockage en limitant au maximum les surcharges.

Globalement, c'est la plateforme HP 3PAR StoreServ qui a obtenu les meilleurs résultats par rapport aux objectifs "démarrer thin", "devenir thin" et "rester thin".

(6)

Introduction

Objectif

Dans ce rapport, nous étudierons les technologies d'allocation dynamique proposées par les principaux acteurs du marché du stockage. Nous comparerons les mises en œuvre de ces technologies sur sept plateformes de stockage, parmi lesquelles les baies de stockages 3PAR de Hewlett Packard. Ce livre blanc s'intéresse plus particulièrement à trois aspects spécifiques de la technologie "thin" de HP 3PAR StoreServ :

1. Démarrer "thin" : la capacité de stockage allouée au moment du déploiement est minimale.

2. Devenir "thin" : possibilité de déplacer des données d'un système "thick" à un système

"thin".

3. Rester "thin" : conserver des unités logiques "thin".

Public concerné

Les décideurs d'organisations qui envisagent de mettre en œuvre une technologie "thin"

trouveront dans ce dossier des informations détaillées sur les solutions proposées par les différents fournisseurs. Les techniciens professionnels qui souhaitent mieux comprendre la mise en œuvre des solutions de technologie "thin" des différents constructeurs pourront également y puiser des informations utiles.

Terminologie

Ce livre blanc emploie des termes couramment utilisés, parmi lesquels :

• LUN "thick" : volume de stockage d'une baie où la totalité de l'espace correspondant à la taille logique du LUN (logical unit number ou unité logique) est réservée en exclusivité au volume en question.

• LUN "thin" : volume de stockage d'une baie qui ne correspond pas à l'allocation d'une capacité de stockage physique et qui consomme sur la baie uniquement l'espace physiquement occupé par des données.

• Technologies "thin" : ensemble de fonctionnalités, parmi lesquelles l'allocation dynamique, permettant d'optimiser l'utilisation d'une baie de stockage.

(7)

Vue d'ensemble

Depuis quelques années, le stockage représente l'un des principaux postes de coût d'un datacenter. Bien que le coût des systèmes de stockage ne cesse de baisser, le rythme de croissance des données continue de s'accélérer dans la plupart des entreprises et entraîne une gestion plus coûteuse de ces systèmes de stockage. Chaque année, les entreprises doivent "faire davantage avec moins de moyens". Pour ce faire, elles ont besoin d'utiliser leurs ressources de stockage de façon plus efficace sans consacrer davantage d'argent à leur exploitation. Plusieurs initiatives importantes ont été mises en œuvre par des

organisations désireuses de réduire leur consommation de ressources de stockage. Il s'agit de recourir à des technologies dites "thin".

• Réduction du gaspillage : le taux d'utilisation des capacités de stockage n'atteint jamais 100 % de l'espace physique alloué sur une baie car chaque niveau de configuration entre la baie et l'hôte génère des pertes d'efficacité. En limitant ce gaspillage, il est possible d'accroître le taux d'utilisation et donc de différer de nouvelles dépenses d'investissement.

• Réduction des surcharges : le déploiement d'un système de stockage est une opération de longue haleine ; entre la commande et le déploiement dans le datacenter, plusieurs mois peuvent s'écouler. Les administrateurs de stockage conservent généralement de la capacité de stockage en réserve pour couvrir la période entourant l'achat.

• Flexibilité : les utilisateurs finaux exigent que leurs applications subissent le moins de perturbations possible. C'est pourquoi de nombreuses entreprises commandent des ressources de stockage superflues, souvent jusqu'à 36 mois avant que la capacité de stockage achetée devienne réellement nécessaire. L'idéal serait que les utilisateurs définissent leurs besoins en stockage en fonction des plans de croissance et que la capacité correspondante leur soit allouée à la demande.

• Accroissement de la rentabilité : le stockage multiclasse (qui permet de placer les données sur le support le plus rentable par rapport au profil d'entrées/sorties nécessaire) joue un rôle majeur dans la réduction du coût du stockage. Le stockage multiclasse dynamique permet d'automatiser le placement des données et emploie des pools de stockage pour créer des LUN. Les LUN alloués de façon dynamique contribuent directement au déploiement d'un modèle de stockage multiclasse. Un LUN "thin" est créé à partir de blocs ayant la capacité des disques physiques d'un pool de stockage.

Des métadonnées permettent d'associer le LUN logique à l'espace physique. Les blocs physiques peuvent donc provenir de différents pools, chaque pool correspondant une classe de stockage différente.

Présentation de l'allocation dynamique

L'allocation dynamique ou "thin provisioning" est une technique de réduction de l'espace mise en œuvre par tous les grands constructeurs de systèmes de stockage. Par rapport aux déploiements "thick", elle permet de mieux exploiter la capacité de stockage d'une baie.

(8)

Dans les déploiements classiques ("thick") de systèmes de stockage, l'espace physique du disque est immédiatement réservé pour la taille totale d'un volume (ou "LUN") au moment de la création, quel que soit l'espace utilisé par la suite par l'hôte. Dans un déploiement

"thin", aucun espace n'est réservé à l'avance pour le LUN. A mesure que l'hôte copie des données sur le LUN, l'espace physique de la baie est alloué à la demande, généralement par blocs de 4 Ko à 42 Mo, selon le constructeur. Les LUN à allocation dynamique sont donc beaucoup plus efficaces et correspondent beaucoup plus précisément à l'espace réellement utilisé sur l'hôte.

Pour des raisons diverses, la capacité de stockage d'un hôte n'est jamais utilisée à cent pour cent. En revanche, avec les LUN "thick", un espace physique correspondant à la taille du volume entier est réservé sur la baie. Les systèmes à allocation dynamique peuvent exploiter tout le stockage physique disponible, en créant une capacité de stockage logique supérieure à la capacité physique réelle. La "surallocation" permet donc de mieux utiliser l'espace de stockage physique que dans les déploiements normaux.

Inconvénients de l'allocation dynamique

La possibilité de surallouer de la capacité de stockage ne va pas sans quelques

inconvénients. Si l'espace est totalement épuisé, les hôtes reçoivent des erreurs d'écriture signalant un problème physique sur la baie. Les erreurs d'écriture sont généralement mal gérées par le système d'exploitation hôte et peuvent provoquer une panne du système. Il est donc important de gérer soigneusement l'équilibre entre espace physique et capacité logique.

Au fur et à mesure que des fichiers sont créés et supprimés, les LUN "thin" perdent de leur efficacité. Cela est dû au mode de gestion de l'allocation de fichiers, de l'espace libre et des métadonnées par le système de fichiers du LUN. Certaines mises en œuvre du système de fichiers sont plus adaptées au mode thin que d'autres et sont conçues de façon à réutiliser l'espace libéré. Toutefois, le stockage alloué de façon dynamique doit être nettoyé pour conserver de bonnes performances. Les constructeurs de systèmes de stockage ont créé des fonctionnalités permettant à la baie de récupérer les ressources de stockage non utilisées :

• Zero-Page-Reclaim (ZPR) : si une baie détecte qu'un bloc de stockage est uniquement composé de zéros binaires, ce bloc est considéré comme non utilisé et est remis dans le pool de capacité disponible. L'aptitude à identifier les blocs non utilisés dépend d'un certain nombre de facteurs, notamment la taille des blocs de la baie et du système de fichiers et le degré de fragmentation des fichiers. Les blocs de petite taille sont mieux adaptés aux opérations ZPR.

• SCSI UNMAP : la commande UNMAP est une opération E/S de bas niveau utilisable par l'hôte pour signaler à la baie de stockage qu'un bloc n'est plus utilisé et peut être restitué au pool de capacité disponible. Malheureusement, cette fonctionnalité n'est actuellement prise en charge que par un nombre très limité de systèmes d'exploitation.

(9)

Technologie "thin" de HP 3PAR StoreServ

La plateforme de stockage HP 3PAR StoreServ a une architecture conçue dès le départ pour le mode "thin", et qui n'impose aucune limite à l'utilisation de LUN "thin" ou "thick". Cela est vrai aussi bien pour les performances des LUN que pour leur capacité. L'administrateur du stockage n'a donc pas besoin d'agencer la baie de telle sorte qu'elle soit compatible avec la technologie "thin". HP 3PAR StoreServ est spécialement optimisé pour l'allocation

dynamique et comprend un grand nombre de fonctionnalités exclusives qui permettent de

"démarrer thin", de "devenir thin" et de "rester thin".

• RAID : les baies HP 3PAR StoreServ correspondent à une technologie RAID originale qui garantit la haute disponibilité du châssis et divise les disques physiques en "petits morceaux" de 256 Mo ou 1 Go. Ces morceaux sont regroupés pour former des Volumes logiques (LV ou Logical Volumes) et des Groupes d'allocation communs (CPG ou Common Provisioning Groups) à partir desquels sont créés les Volumes virtuels.

L'allocation dynamique de volumes virtuels utilise des blocs dont la taille augmente par incréments de 16 Ko, ce qui correspond à la plus petite unité de stockage récupérable de la baie.

• ASIC matériel : dans la nouvelle version de HP 3PAR StoreServ (il s'agit de la quatrième génération), le système utilise des circuits ASIC (Application Specific Integrated Circuit) adaptés et dédiés à l'identification et à la récupération des ressources non utilisées dans les volumes virtuels à allocation dynamique. L'ASIC permet au système de se décharger des tâches consommatrices de temps-processeur sur du matériel dédié. Cela permet d'éviter les baisses de performances liées à des fonctions comme la restitution d'espace de la baie et garantit des temps de réponse E/S réguliers sur l'hôte. L'ASIC HP 3PAR StoreServ rend possible toute une série de fonctions, notamment les opérations ZPR en ligne.

• Persistence "thin" : tâche réalisée par le système d'exploitation et permettant d'identifier et de récupérer les ressources libérées.

• Conversion "thin" : effectue la migration de volumes "thick" vers des volumes "thin"

par le biais d'une opération en ligne de détection de zéros. A mesure que les données sont copiées sur la baie, les blocs de données contenant des zéros sont identifiés et mappés logiquement avec le disque (et non copiés physiquement sur celui-ci).

• Restitution des copies "thin" : récupère de l'espace dans la baie, sur les copies des volumes.

• Thin Reclamation API : cette API est le fruit d'une collaboration entre HP 3PAR StoreServ et Symantec. Cette fonctionnalité permet au système de fichiers d'envoyer un signal lorsque des ressources libérées peuvent être mises à disposition sur la baie.

Elle est prise en charge par les systèmes Symantec Veritas Storage Foundation, Version 5 et supérieures.

• Prise en charge de la virtualisation : HP 3PAR StoreServ prend en charge l'API VMware VAAI, notamment la commande "block zeroing".

• Gestion : les baies HP 3PAR StoreServ émettent des alertes en cas de problèmes spécifiques d'allocation dynamique d'espace. Déclenchées lorsqu'un seuil prédéfini est franchi, elles permettent une surveillance efficace de la capacité dans les

environnements "thin".

(10)

Analyse de la concurrence

EMC VMAX

Symmetrix VMAX, fer de lance des plateformes de stockage d'entreprise d'EMC, est le premier matériel de stockage d'entreprise à ne pas être conçu en fonction des exigences propres à chaque entreprise. Equipé de matériel personnalisé, il s'appuie sur des

processeurs Intel grand public qui gèrent l'interconnexion entre les modules de stockage.

Le système d'exploitation VMAX, Enginuity, est une évolution du code mis au point pour le premier système Symmetrix ICDA (Integrated Cache Disk Arrays) en 1991, et conserve encore une grande partie des caractéristiques de conception architecturale et des limites d'origine. Les systèmes VMAX décrits dans cette section correspondent aux nouveaux modèles 10K, 20K et 40K.

Aperçu général

L'allocation dynamique est mise en œuvre dans les systèmes VMAX sous la forme d'une fonctionnalité appelée Virtual Provisioning (Allocation virtuelle), du nom donné à la technologie d'allocation dynamique d'EMC. Les LUN alloués dynamiquement sont appelés périphériques "thin" et tirent leur capacité de stockage physique de pools également "thin".

Un pool "thin" est créé à partir de LUN "thick" standard (unités de données à durée limitée), eux-mêmes divisés en unités d'allocation appelées "thin device extents" (extensions de périphériques "thin"). Les pools "thin" doivent utiliser le même type d'émulation et de protection RAID. EMC recommande de les créer à partir de disques ayant la même vitesse de rotation et la même taille d'unité de données.

Une extension "thin" compte 12 pistes, soit une taille de 768 Ko. Cela correspond à la taille minimale initiale affectée à tous les périphériques "thin" associés à un pool "thin" ainsi que le plus petit incrément en cas d'extension de la capacité d'un périphérique "thin". La technologie "thin" HP 3PAR StoreServ utilise des incréments bien plus petits, de 16 Ko, ce qui permet d'éviter les gaspillages, en particulier avec les systèmes de fichiers fragmentés et peu adaptés aux technologies "thin". Les périphériques "thin" sont en fait des objets en cache qui renvoient simplement au pool physique qui sous-tend les LUN standard de la baie. Ces LUN, à leur tour, sont associés aux disques physiques. Un seul système VMAX prend en charge jusqu'à 512 pools et 64 000 dispositifs "thin".

Comparaison avec HP 3PAR StoreServ — Démarrer "thin"

La fonction VMAX Virtual Provisioning nécessite une importante planification initiale. EMC recommande d'utiliser des unités de données de grande taille dans les pools. Comme les unités de données correspondent en fait à des LUN standard, les configurations habituelles créent des LUN à utiliser uniquement pour les pools "thin" et des LUN destinés à d'autres usages que l'allocation dynamique. Les métapériphériques (série de plusieurs

périphériques standard reliés entre eux) ne peuvent pas servir d'unités de données. En effet, cela entraînerait des gaspillages ainsi qu'une pénurie de capacité de stockage du type adéquat. Il est possible de dissoudre et de redimensionner des LUN standard, mais cette opération demande du temps et peut entraîner des déséquilibres. Avec la technologie "thin"

HP 3PAR StoreServ, les disques physiques sont simplement affectés à un pool à partir duquel sont allouées des LUN "thin" ou "thick".

(11)

Lorsque des périphériques VMAX "thin" sont liés à un pool de stockage "thin", une allocation minimum d'une extension "thin" (soit 768 Ko) est réservée. Comme ces périphériques sont en fait des objets en cache, chacun d'eux consomme 148 Ko de cache supplémentaire, auxquels s'ajoutent 8 Ko par gigaoctet, selon la taille du périphérique "thin". La technologie

"thin" HP 3PAR StoreServ ne nécessite aucune réservation initiale d'espace.

Comparaison avec HP 3PAR StoreServ — Devenir "thin"

Il n'existe aucune fonctionnalité, dans la baie VMAX, qui permette d'optimiser le stockage lorsque des LUN "thick" sont convertis en périphériques "thin". Lorsque les LUN "thick" sont copiés sur un périphérique "thin", l'espace occupé par ce dernier représente 100 % de l'espace logique alloué. Les périphériques "thin" doivent être optimisés selon un processus appelé Restitution d'espace. Autrement dit, les migrations de données entre des LUN "thick"

et "thin" nécessitent une capacité physique supplémentaire pour l'opération de migration.

La technologie "thin" HP 3PAR StoreServ utilise la fonctionnalité Thin Conversion pour optimiser la migration en temps réel, à la vitesse de ligne, de LUN "thick" vers des LUN

"thin".

Comparaison avec HP 3PAR StoreServ — Rester "thin"

Grâce à la fonction de restitution d'espace (Space Reclamation), les baies EMC VMAX peuvent restituer les pages "vides" ou composées de zéros sur un périphérique "thin". Cette fonction s'exécute en arrière-plan sur l'adaptateur de disque associé au LUN. Une extension

"thin" entière est copiée dans le cache et les valeurs T10-DIF de chaque bloc de données sont comparées à la valeur T10-DIF connue pour un bloc uniquement composé de zéros. Si l'extension "thin" ne contient que des données effacées, elle est restituée. Tant que l'opération de restitution d'espace n'a pas été réalisée, les zones d'un périphérique "thin"

contenant des zéros continuent d'utiliser de l'espace physique. La fonction de restitution d'espace de VMAX n'est pas utilisable avec les périphériques "thin" présents dans une paire SRDF (Symmetrix Remote Data Facility) active ou utilisant une réplication locale. Avec la technologie "thin" 3PAR StoreServ, la détection des zéros se fait en ligne à l'aide d'un circuit ASIC personnalisé. Cette opération n'a aucune conséquence sur le niveau d'utilisation du processeur du contrôleur ou du cache et se fait en temps réel, à la vitesse de ligne. Il n'y a aucune restriction concernant les LUN répliqués.

Restrictions inhérentes au système VMAX

EMC recommande un taux d'utilisation compris entre 60 et 80 % par pool "thin" pour éviter que l'espace ne devienne insuffisant. Si l'on a plusieurs pools (nécessaires pour bénéficier de différents types de protection des données RAID), cette exigence peut entraîner un important gaspillage. La technologie "thin" HP 3PAR StoreServ ne nécessite pas des pools distincts pour chaque type de protection. Lorsqu'on utilise un SRDF synchrone avec VMAX, une seule écriture active est possible par périphérique "thin". Lorsque des périphériques

"thin" sont créés dans des métapériphériques, les performances peuvent se dégrader. Il existe également une limite de huit demandes de lecture par chemin pour chaque

périphérique "thin", qui peut se traduire par un ralentissement des performances et un taux élevé d'échecs de lecture.

(12)

NetApp

A l'origine, les appliances de stockage NetApp ont été développées pour fournir un dispositif de stockage NAS utilisant soit le protocole CIFS, soit le protocole NFS. Peu à peu, NetApp a fait évoluer sa plateforme pour qu'elle prenne en charge le stockage de blocs, soit via iSCSI, soit via Fibre Channel. Les versions actuelles des filers NetApp peuvent être configurées en mode 7 ou en mode cluster et constituent deux familles de produits différentes basées l'une sur le système d'exploitation Data ONTAP originel, l'autre sur le code base obtenu avec l'acquisition de Spinnaker, Inc.

Aperçu général

Pour mettre en œuvre un stockage par blocs dans Data ONTAP, les filers NetApp émulent les LUN dans des volumes appelés FlexVols. Les FlexVols sont ensuite créés sur des agrégats (pools de stockage physique) et sur des groupes RAID de disques physiques.

L'architecture sous-jacente s'appuie sur une disposition des données appelée WAFL (Write Anywhere File Layout) qui exécute une stratégie de réécriture pour les nouvelles données comme pour les mises à jour ; aucune donnée de bloc ou de fichier n'est jamais mise à jour au même endroit. Le modèle WAFL utilise des pages de 4 Ko et stocke les mises à jour dans la RAM non volatile avant de copier une "bande" entière de données sur le disque. De cette façon, les écritures sont optimisées lors de la validation sur disque effectuée avec une matrice de disques physiques RAID-4. Les LUN NetApp sont émulés par le biais des fichiers présent sur les volumes ; ainsi, les données de bloc et de fichiers peuvent être mêlées sur le même pool de stockage. La création de LUN est simple à réaliser, en revanche l'utilisation de LUN par blocs est très complexe.

Tous les volumes NetApp font par défaut l'objet d'une allocation statique (ou "thick") et les volumes "thin" n'ont tout simplement pas de garantie d'espace. De leur côté, les LUN d'un volume font l'objet d'une allocation dynamique si la réservation d'espace est désactivée.

Par défaut, tous les LUN font l'objet d'une allocation statique, avec la réservation d'espace activée. L'administrateur doit désactiver cette fonction après la création du LUN pour que celui-ci puisse être alloué de façon dynamique. Cependant, comme les blocs de données ne sont pas écrasés à leur place, un espace supplémentaire (appelé Réserve fractionnaire (Fractional Reserve) ou espace réservé à la réécriture (Overwrite Reserved Space)) doit être réservé pour gérer les mises à jour de données lorsque des instantanés sont utilisés sur le LUN. Par défaut, la Réserve fractionnaire est de 100 % lorsque la garantie d'espace est définie sur "fichier" pour un volume. Il s'agit là du seul moyen de garantir que l'espace disponible dans le volume est suffisant pour conserver les mises à jour de tout le contenu du LUN. Les garanties d'espace sont complexes et, si elles sont mal utilisées, peuvent aboutir à la mise hors ligne des LUN afin de protéger les données. Ce système entraîne une tendance à surallouer le stockage pour éviter les problèmes d'accès aux données. La mise en œuvre de la technologie d'allocation dynamique HP 3PAR StoreServ est beaucoup plus simple et ne rend pas la gestion aussi complexe que sur la plateforme NetApp.

(13)

NetApp ne comporte aucune fonctionnalité native permettant d'importer des LUN depuis d'autres plateformes de stockage. Les LUN peuvent être déplacés vers la plateforme NetApp à l'aide d'outils situés sur l'hôte qui allouent un espace physique équivalent à la taille logique du LUN entier. Il n'existe pas non plus dans Data ONTAP de fonctionnalités natives permettant d'identifier et de restituer les pages vides ou composées de zéros. Data ONTAP permet cependant la déduplication de données (fonction dedupe) au niveau des blocs, et cette fonction permet aussi de dédupliquer les pages de données effacées.

Toutefois, la taille des LUN sur lesquelles cette fonction est activée est limitée. En outre, dans le cas de LUN fréquemment utilisés, la déduplication peut avoir un effet négatif sur les performances. NetApp renvoie à des tests qui montrent que plus la taille du système est importante, plus cet impact est marqué lorsque les données sont copiées sur des volumes dédupliqués ; ainsi, pour le système FAS6080, la dégradation des performances peut atteindre 35 %. La technologie "thin" HP 3PAR StoreServ n'a aucune incidence sur les performances.

Progressivement, à mesure que les données sont copiées sur un LUN de bloc NetApp, l'espace physique utilisé se rapproche de la taille du LUN logique. Il n'existe aucune fonction intégrée permettant d'identifier et de restituer les blocs de zéros. Au contraire, un agent appelé SnapDrive doit être déployé sur l'hôte pour suivre les mises à jour effectuées sur le système de fichiers. Cet agent doit être présent sur chaque serveur auquel des LUN NetApp sont présentées, sans quoi il n'est pas possible de suivre les suppressions de fichiers. Un certain nombre de plateformes, y compris des systèmes d'exploitation aussi courants que RHEL6, ne sont pas compatibles avec SnapDrive. La technologie "thin" HP 3PAR StoreServ détecte automatiquement, en ligne, les données effacées, sans dégrader les performances et sans nécessiter la mise en œuvre d'un agent sur l'hôte.

Hitachi VSP

La plateforme VSP est la baie de stockage d'entreprise actuellement proposée par Hitachi. Il s'agit d'une évolution de deux modèles précédents, Lightning et USP-V. La baie VSP

continue d'utiliser une technologie mettant en jeu des circuits ASIC personnalisés, dans laquelle les processus de stockage sont gérés par des Virtual Storage Directors reliés à la matrice de commutation en back-end. Le recours à des ASIC personnalisés est une

caractéristique commune à toutes les plateformes de stockage Hitachi. Toutefois, elle n'est pas directement utilisée dans le processus d'allocation dynamique ou dans la gestion du stockage de façon dynamique.

Aperçu général

La technologie d'allocation dynamique en œuvre dans VSP est appelée HDP, pour Hitachi Dynamic Provisioning. Les LUN "thin" HDP (appelés LDEV ou périphériques logiques) sont créés à partir d'un pool HDP composé de périphériques LDEV standard. De leur côté, les LDEV sont créés à partir de groupes RAID composés de 16 disques au maximum, dans l'une des sept variantes de la technologie RAID-5 ou RAID-6. Au niveau physique, les données sont écrites sur des pistes de 256 Ko par disque physique, soit une taille de page logique standard de 42 Mo pour accueillir tous les niveaux RAID possibles. Autrement dit,

(14)

dynamique. Avec la technologie "thin" HP 3PAR StoreServ, l'allocation d'espace se fait par incréments de 16 Ko, ce qui évite beaucoup de gaspillages dans les environnements inadaptés à l'allocation dynamique.

La création de pools VSP HDP doit être très planifiée. Hitachi recommande que les pools soient créés à partir de LUN de grande taille créés à partir de groupes RAID classiques. La création de groupes RAID se fait généralement en une seule fois, au moment de

l'installation de la baie. La taille du groupe RAID dépend du nombre de disques physiques et de directeurs installés en back-end dans le système VSP. Toutefois, il est normal de créer des pools HDP à partir d'un nombre important de groupes RAID sur l'ensemble des

directeurs en back-end pour garantir des performances d'E/S optimales. On parle de "wide striping". S'il est possible de créer les LDEV standard, à allocation statique, à partir des groupes RAID utilisés pour créer les pools HDP, cette pratique n'est pas recommandée car elle risque de dégrader les performances. La mise en œuvre d'HDP peut se solder par un gaspillage de ressources et nécessite en permanence que de nombreux groupes RAID soient réservés pour l'allocation dynamique. En revanche, avec la technologie "thin"

HP 3PAR StoreServ, les disques physiques sont simplement affectés à un pool à partir duquel il est possible d'allouer des LUN "thin" ou "thick".

Sur le système VSP, les LDEV dynamiques allouent au minimum une page de 42 Mo

lorsqu'ils sont affectés à un pool HDP. Avec latechnologie "thin" HP 3PAR StoreServ, aucune réservation initiale d'espace n'est effectuée.

La plateforme Hitachi VSP permet d'importer dans le système des LUN classiques,

"statiques", à l'aide de la fonction de virtualisation externe de la baie, appelée Universal Volume Manager. Par ailleurs, les LUN "statiques" peuvent être importés depuis d'autres systèmes VSP via la fonction de réplication TrueCopy. Tous les LUN importés conservent leur taille logique initiale, jusqu'à ce que la fonction zero-page-reclaim restitue les blocs effacés. Cette tâche de post-traitement qui s'exécute en arrière-plan examine chaque LDEV et restitue les pages de 42 Mo au pool HDP. Hitachi recommande d'exécuter la fonction ZPR pendant les périodes d'inactivité. En effet, cette tâche est réalisée par les directeurs en back-end et risque de dégrader les performances d'E/S en production. Comme la fonction ZPR n'est pas exécutée en ligne, les LDEV "thin" "grossissent" peu à peu, à mesure que les données sont copiées sur le système de fichiers du LUN. En d'autres termes, les pools "thin"

doivent recevoir davantage de capacité pour prendre en charge cette croissance entre deux exécutions de la fonction ZPR. Avec la technologie "thin" 3PAR StoreServ, la détection des données effacées se fait en ligne avec un circuit ASIC personnalisé. L'opération se fait en temps réel, à la vitesse de ligne, et n'a aucune incidence sur le processeur du contrôleur.

(15)

EMC VNX

La plateforme VNX d'EMC est une évolution de deux produits antérieurs, CLARiiON et Celerra (pour les protocoles de bloc et de fichier, respectivement). Ces deux produits ont été rassemblés et commercialisés sous la forme d'une même plateforme utilisant un seul outil de gestion appelé Unisphere. Les LUN de stockage par blocs sont présentés depuis l'unité matérielle de base, l'accès aux fichiers étant mis en œuvre sur les volumes x-blade.

L'allocation dynamique se fait à travers la fonction Virtual Provisioning (VP). Avec VP, les LUN peuvent être configurés de telle sorte qu'un même pool de disques comporte à la fois des LUN "thick" et "thin". Les pools VP peuvent se composer d'un nombre important de disques (plus important que le pool de disques standard, limité à 16 unités). Les disques sont toutefois toujours configurés en groupes RAID pour assurer la résilience.

La taille logique des LUN VNX "thin" peut être fixée entre 1 Mo et 16 To. Toutefois, chaque LUN réserve au moins 3 Go. Autrement dit, si un grand nombre de LUN est alloué, l'espace physique réservé est important. Dans la technologie HP 3PAR StoreServ, en revanche, il n'y a pas de quantité minimum d'espace physique à réserver.

VNX ne comprend pas de fonction intégrée en ligne pour la restitution de pages effacées.

Les pages "vides" doivent être restituées par le biais soit de la fonction LUN Migration (à l'intérieur de la baie), soit de la fonction SAN Copy (à partir de baies externes). Autrement dit, la capacité physique des LUN dynamiques se rapproche peu à peu de leur taille logique.

EMC recommande d'utiliser la commande sdelete sur l'hôte et la migration de LUN pour restituer l'espace non utilisé sur la baie VNX. De son côté, la technologie "thin" HP 3PAR StoreServ détecte et élimine en ligne les pages de données effacées sans qu'il soit nécessaire d'effectuer de nouvelles migrations de données. VNX prend en charge l'API Symantec Thin Reclamation API, à condition de déployer le système de fichiers Veritas sur chacun des serveurs devant faire l'objet d'une restitution d'espace.

Les LUN VNX "thin" se développent par incréments de 1 Go d'espace physique, le niveau minimum de granularité correspondant à des blocs de 8 Ko. Le bloc de 8 Ko représente l'espace dans lequel il est possible de restituer les pages effacées, mais l'espace affecté à un LUN augmente par incréments de 1 Go. Les "trous" de 8 Ko dans une tranche de 1 Go ne peuvent donc être réutilisés que par le même volume. Cet espace n'est pas utilisable par l'ensemble des volumes disponibles. La technologie "thin" HP 3PAR StoreServ utilise une mise en correspondance entre les LUN et les disques logiques internes pour des pages de 32 Mo. Là, la granularité minimum des pages à des fins d'allocation dynamique est de 16 Ko. De ce fait, le système 3PAR et beaucoup plus efficace avec les LUN "thin".

Contrairement à HP 3PAR StoreServ, VNX ne dispose pas de technologie ASIC pour restituer l'espace libéré.

(16)

Questions de performances

EMC note que si l'allocation virtuelle de LUN "thin" offre davantage de souplesse, elle apporte des performances inférieures à celles des LUN "thick" classiques. EMC conseille donc de ne les utiliser que pour les applications exigeant des performances "modérées". La technologie "thin" HP 3PAR StoreServ ne limite pas les performances.

IBM XIV

La plateforme de stockage IBM XIV a été achetée à une startup israélienne fondée par le créateur du système EMC Symmetrix, Moshe Yanai. Cette plateforme se démarque

radicalement des baies classiques. Elle se compose exclusivement de disques durs SATA ou SAS de grande capacité, même si une couche de cache SSD a récemment été ajoutée pour accélérer les E/S. Le système XIV en est maintenant à sa troisième génération de matériel et utilise des disques de 2 ou de 3 To, avec 6 To de cache SSD. Chaque baie se compose de six à quinze nœuds serveur comprenant chacun douze disques durs. La configuration maximum est donc de 180 disques durs. Sur chaque nœud, les disques sont divisés en portions de 1 Mo réparties entre les différents disques pour former un immense pool de données en miroir. Les termes "soft size" et "hard size" sont employés pour différencier la taille logique et la taille physique d'un LUN. Ces termes s'appliquent également aux pools qui peuvent se voir allouer de la capacité physique. Il peut arriver que la capacité physique (hard) d'un pool soit épuisée et que celui-ci bloque l'accès à un volume, même s'il existe de l'espace physique disponible dans d'autres pools. La capacité globale d'une baie XIV est appelée "system hard size" (taille physique du système). La taille logique du système, ou

"system soft size" (autrement dit le niveau de surallocation autorisé au niveau de la baie) est également défini, mais il ne peut pas être modifié par l'administrateur système. Cette valeur doit être définie par un technicien IBM et le client doit dégager IBM de toute responsabilité en cas de problème découlant de cette modification.

Par défaut, tous les LUN XIV font l'objet d'une allocation dynamique et sont placés dans des pools de stockage. Les données étant uniformément réparties entre les différents disques du système, les pools de stockage représentent un avantage logique purement

administratif pour l'allocation dynamique ; aucune ségrégation des charges de travail n'est possible. Du fait de l'architecture du système, tous les LUN réservent un espace initial de 17 Go à la création, ce qui peut se traduire au départ par un gaspillage important d'espace.

En outre, tous les LUN augmentent par blocs de 17 Go. La technologie "thin" HP 3PAR StoreServ ne nécessite pas de réservation d'espace à la création des LUN et utilise des incréments de 16 Ko qui garantissent une efficacité élevée.

La fonction de migration des données du système XIV prend en charge la conversion thick/thin des volumes. Pendant cette opération, les pages vides sont identifiées et supprimées sur les volumes importés d'autres systèmes. Toutefois, la fonction de

migration des données nécessite une modification de la configuration et la mise "en ligne"

du système XIV avec l'hôte et le volume d'origine. Pour cette tâche, le système doit être arrêté. Avec la technologie "thin" HP 3PAR StoreServ, il est possible de migrer les données vers la baie via l'hôte et d'identifier les pages vides en ligne sans arrêter le serveur hôte.

(17)

XIV met en œuvre une fonction ZPR pour identifier et éliminer les blocs de données "vides".

Toutefois, cette fonction est intégrée à la routine de "récurage" des données qui, en arrière- plan, ratisse la baie pour détecter les problèmes d'intégrité des données et de parité. La restitution des données ZPR peut prendre de longues journées (jusqu'à trois semaines), ce qui se traduit par une surallocation d'espace physique tant que toutes les pages vides n'ont pas été identifiées et récupérées. La technologie "thin" HP 3PAR StoreServ inclut une fonction de détection ZPR active en ligne qui s'exécute au moment de l'écriture des données. Elle permet d'identifier et d'éliminer immédiatement les pages "vides" avant que les données ne soient copiées sur le disque physique.

Le système XIV prend en charge l'API Symantec Thin Reclamation API pour la restitution instantanée d'espace, qui permet aux hôtes exécutant la version 5 ou une version

supérieure de Symantec Storage Foundation de signaler directement à la baie la libération d'espace de stockage. Cette fonction nécessite que le système de fichiers Veritas soit déployé sur chacun des hôtes connectés à la baie. La restitution instantanée d'espace ne prend pas en charge les volumes en miroir, les volumes contenant des instantanés ou les instantanés eux-mêmes, ce qui limite le processus de récupération.

Dell Compellent

Créée en 2002, la société Compellent Technologies, Inc. a été rachetée par Dell en 2011, date qui a marqué la naissance de la marque Dell Compellent. Compellent propose une solution originale, basée sur des composants grand public et baptisée Data Progression.

La technologie d'allocation dynamique de Compellent est appelée Dynamic Capacity. Les LUN "thin" alloués sont composés de blocs de 2 Mo qui peuvent provenir de n'importe quelle unité physique de la baie. Cette taille par défaut de 2 Mo peut être modifiée par l'administrateur qui a la possibilité d'opter pour des blocs de 512 Ko ou de 4 Mo.

Tous les LUN Dell Compellent sont alloués sous la forme de LUN à allocation dynamique.

L'allocation minimum est de 2 Mo mais varie en fonction de la méthodologie de protection utilisée (par exemple, dans un système RAID-10, deux blocs de 2 Mo seront alloués). De son côté, la technologie HP 3PAR StoreServ n'exige pas qu'une allocation minimum soit

réservée. Les blocs Dell Compellent peuvent aussi avoir une taille de 512 Ko ou de 4 Mo ; toutefois, Dell conseille de ne pas mélanger des blocs de taille différente dans un même système pour éviter de gaspiller l'espace physique.

(18)

Dell Compellent permet de déplacer des données dans la baie et de supprimer l'espace non utilisé via la fonction Thin Import. HP 3PAR StoreServ prend également en charge cette fonction ; toutefois, contrairement à ce qui se passe dans Compellent, le processus est réalisé en ligne à l'aide d'un circuit ASIC dédié, et non dans le logiciel. Il n'a donc aucun impact sur les performances de la baie.

Dans Dell Compellent, il est possible de récupérer de l'espace sur les volumes existants avec l'outil "Free Space Recovery" qui utilise la commande SCSI UNMAP ; mais il faut alors que l'outil soit installé sur chacun des serveurs sur lesquels la récupération doit être réalisée. En revanche, HP 3PAR StoreServ permet la récupération des pages de données effacées, qui se fait en ligne, de façon dynamique, sans faire intervenir aucun agent de l'hôte.

(19)

Présentation des tests et méthodologie

L'objectif de ces tests est de comparer les performances et l'efficacité du système HP 3PAR StoreServ par rapport aux solutions d'autres fournisseurs. Si les solutions de chaque fournisseur semblent offrir des fonctionnalités comparables, elles sont très différentes en termes de performances et d'efficacité. Les tests suivants ont été réalisés sur les produits concurrents.

Il n'était pas possible de comparer directement les performances visées ou les

spécifications des systèmes de stockage testés. En effet, ces systèmes étaient différents par le nombre, la taille et le type de disques durs, le nombre de contrôleurs et d'autres caractéristiques physiques. De ce fait, pour les données obtenues dans le test de

performance zero-page-reclaim réalisé par Edison, seules les différences entre chaque baie testée et la référence du test ont un sens. La seule exception concerne les résultats du test de Pré-allocation d'une capacité importante, qui s'intéresse aux effets des différentes architectures de stockage et d'allocation dynamique sur l'utilisation des capacités, plutôt qu'à leurs conséquences sur les performances des systèmes.

Les caractéristiques détaillées du matériel testé figurent en annexe, à la fin du document.

Test 1—Performances Zero-Page-Reclaim

L'objectif de ce test est de montrer l'impact de la fonction zero-page-reclaim sur chaque baie. La fonction de restitution est essentielle pour "rester thin" : elle garantit que les allocations permanentes ne transforment pas peu à peu les volumes en volumes statiques ou thick. Dans l'absolu, ce test ne devrait avoir aucune incidence sur les performances d'entrée/sortie. Les étapes du test sont les suivantes :

1. Création d'un LUN "thick" de grande taille, de 200 Go, et affectation de ce LUN à un hôte Windows.

2. Formatage rapide du LUN à l'aide du système de fichiers NTFS.

3. Réalisation d'un test de charge avec IOMETER, écriture des zéros binaires sur le LUN, enregistrement des E/S par seconde et des données de latence.

4. Répétition du test avec un LUN "thin" de 200 Go.

Avant le test, la fonction zero-page-reclaim a été activée sur le système VSP. Pour les plateformes EMC, cette fonction a été activée en réalisant une migration de LUN, conformément à la recommandation d'EMC.

(20)

Test 2—Pré-allocation d'une capacité importante

L'objectif de ce test est de montrer la surcharge associée à la création initiale de LUN "thin", l'objectif étant de "démarrer thin". Dans l'idéal, lors de la création de LUN "thin", la quantité de stockage réservée sur la baie doit être la plus faible possible. Les étapes du test sont les suivantes :

1. Création de cinq LUN "thin" de 200 Go et affectation de ces LUN à un hôte Windows.

2. Formatage rapide des LUN à l'aide du système de fichiers NTFS.

3. Mesure de la quantité d'espace consommée, indiquée par la baie.

(21)

Résultats du test

Test 1—Performances Zero-Page-Reclaim

Les données présentées dans les tableaux suivants représentent les performances de chaque baie pouvant faire l'objet d'une restitution des pages effacées, conformément aux conditions du test. Le système NetApp FAS n'a pas été intégré à ce test car il ne comprend pas de fonction zero-page-reclaim native. Les données relatives à IBM XIV n'apparaissent pas ici car le temps d'exécution de la restitution par ce système ne correspond pas aux conditions fixées pour le test.¹

Plateforme

Dégradation par rapport à la référence (%)

EMC VMAX 48,19 %

Dell Compellent 42,33 %

EMC VNX 29,99 %

Hitachi VSP 23,34 %

HP 3PAR 0,00 %

Tableau 1 - Test 1 - Performance d'E/S par seconde pendant l'exécution de la fonction ZPR

1 Selon un livre rouge IBM intitulé IBM XIV Storage System: Copy Services and Migration, la diminution de la quantité d'espace utilisé indiquée peut prendre jusqu'à trois semaines… Cela est dû au fait que la récupération d'espace vide est une tâche qui s'exécute en arrière-plan. (Page 264 du document anglais). Outre le fait que la durée nécessaire à l'exécution de la fonction ZPR ne correspond pas aux conditions fixées pour notre recherche, l'activation de la surallocation "ne fait pas partie du rôle de

(22)

Figure 1 - Test 1 - Performance d'E/S par seconde pendant l'exécution de la fonction ZPR

Plateforme

Dégradation par rapport à la référence (%)

EMC VNX 42,61 %

EMC VMAX 40.58%

Dell Compellent 74,22 %

Hitachi VSP 30,33 %

HP 3PAR 1,23 %

Tableau 1 - Test 1 - Latence des E/S pendant l'exécution de la fonction ZPR 48,19%

42,33%

29,99%

23,34%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

EMC VMAX Dell Compellent EMC VNX Hitachi VSP 3PAR

Zero Page Reclaim

Dégradation des performances durant la restitution

Dégradation des performance durant la restitution (%)

(23)

Figure 2 - Test 1 - Latence des E/S pendant l'exécution de la fonction ZPR

Les résultats de ce test montrent que l'activité ZPR a un impact aussi bien en termes de latence que de débit sur toutes les plateformes à l'exception de HP 3PAR StoreServ. Les conséquences les plus notables concernent les performances du système EMC VMAX et l'augmentation de la latence sur le système Dell Compellent.

Edison a pu déterminer que la dégradation des performances du système EMC VMAX est due au fait que cette plateforme doit copier dans le cache chaque extension de périphérique

"thin" pour réaliser l'opération ZPR. Cette charge dans le cache a, de toute évidence, un impact direct sur les performances de la baie.

Edison n'a pas été en mesure d'identifier les raisons de l'accroissement de la latence sur le système Dell Compellent.

La baie HP 3PAR StoreServ dispose de circuits ASIC dédiés pour gérer la charge de travail ZPR sans dégrader le débit des E/S sur les hôtes.

74,22%

42,61% 40,58%

30,33%

1,23%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

Dell Compellent EMC VNX EMC VMAX Hitachi VSP 3PAR

Zero Page Reclaim

Augmentation de la latence durant la restitution

Augmentation de la latence durant la restitution (%)

(24)

Test 2—Pré-allocation d'une capacité importante

Les résultats de ce test figurent dans le tableau et le graphique suivants.

Plateforme Espace alloué (en Mo)

EMC VMAX 17

NetApp FAS 368

Dell Compellent 800

Hitachi VSP 1230

HP 3PAR 3125

EMC VNX 20 039

IBM XIV 86 000

Tableau 2 - Test 2 - Pré-allocation d'une capacité importante

Figure 3 - Test 2 - Pré-allocation d'une capacité importante 0

10 000 20 000 30 000 40 000 50 000 60 000 70 000 80 000 90 000

Capacité (Mo)

Pré-allocation d'une capacité importante

Espace alloué (Mo)

(25)

D'après ce test, la pré-allocation est médiocre sur les systèmes EMC VNX et IBM XIV.

EMC VNX réserve au minimum 3 Go par LUN ; IBM XIV réserve au moins 17 Go par LUN. Les performances des autres plateformes sont bonnes. De toute évidence, lorsque les

systèmes ont de grandes quantités de LUN, la réserve minimum peut avoir un effet négatif sur l'objectif "démarrer thin" et se traduire par un gros volume d'espace inutilisable.

(26)

Conclusions et recommandations

L'allocation dynamique de ressources est une fonction importante pour optimiser l'espace et peut aider à augmenter le taux d'utilisation des baies de stockage. Elle se traduit directement par une réduction des dépenses d'investissement et des frais d'exploitation consacrés à l'achat de matériel et à sa gestion. Toutefois, comme le montrent les tests réalisés, certaines technologies d'allocation dynamique sont plus aptes que d'autres à optimiser l'espace sans dégrader les performances.

Les systèmes HP 3PAR StoreServ respectent trois principes de base :

1. Démarrer "thin" : la création de nouveaux LUN entraîne une surcharge minimale. Le Test 2 montre que l'ensemble des baies offrent à cet égard de bonnes performances, à l'exception des plateformes EMC VNX et IBM XIV. Grâce à la faible surcharge liée à la création des LUN, les plateformes les plus performantes peuvent atteindre un nombre de LUN bien plus important et donc permettre une allocation plus efficace des

ressources de stockage.

2. Devenir "thin" : possibilité de déplacer des données d'un déploiement "thick" à un déploiement "thin". L'importation dans une baie de données existantes nécessite des fonctionnalités permettant d'optimiser les données à mesure qu'elles sont copiées sur le disque. Le système HP 3PAR StoreServ est le seul capable de réaliser une détection en ligne des zéros au moment de l'écriture. EMC VNX, Dell Compellent et IBM XIV sont capables de détecter les zéros lorsque les données sont importées dans des conditions précises, par exemple dans le cadre d'une réplication. Toutefois, ces solutions ne sont pas totalement souples.

3. Rester "thin" : aptitude à détecter et à restituer progressivement l'espace non utilisé. A mesure que les données sont copiées sur les volumes "thin", les LUN ont tendance à grossir jusqu'à atteindre la capacité logique allouée. Ce phénomène peut être dû à la défragmentation ou à des systèmes de fichiers peu adaptés à l'allocation dynamique qui intègrent des métadonnées au contenu, ou qui sont inefficaces pour réutiliser les ressources libérées. La plupart des fournisseurs, à l'exception de NetApp, prennent désormais en charge, sous une forme ou une autre, la fonction zero-page-reclaim ou UNMAP, qui permet de restituer de l'espace à la baie lorsque cet espace est libéré par l'hôte. Toutefois, ces tâches qui s'exécutent en arrière-plan peuvent avoir une incidence importante sur les performances d'E/S de l'hôte, comme le montre le Test 1.

La plateforme HP 3PAR StoreServ est la seule à offrir une solution d'allocation dynamique qui garantisse une utilisation du stockage vraiment efficace.

Méthodes recommandées

Les tests et les recherches traités dans ce livre blanc mettent en lumière un certain nombre de points importants concernant les méthodes à suivre :

1. Mise en œuvre de la fonction Zero-Page-Reclaim : cette fonction doit être utilisée pour garantir que les LUN restent "thin". Toutefois, sur la plupart des plateformes (à

l'exception de la plateforme 3PAR, du fait des circuits ASIC personnalisés, et de la plateforme XIV à cause de son exécution particulièrement lente), cette fonction doit être programmée en dehors des heures normales de production pour éviter une baisse trop importante des performances.

(27)

2. Tenir compte de la taille minimum des LUN : lorsque vous définissez une taille de référence pour les LUN à allocation dynamique, veillez à ce que la taille minimum configurée ne risque pas de se traduire par de la capacité perdue.

(28)

Annexe A—Documents de référence

La rédaction de ce livre blanc s'est appuyée sur les documents suivants :

• TR-3505 - NetApp Deduplication for FAS and V-Series Deployment and Implementation Guide (Déduplication NetApp pour systèmes FAS et série V - Guide de déploiement et de mise en œuvre)

• TR-3563 – NetApp Thin Provisioning Increases Storage Utilization with On Demand Allocation (Grâce à l'allocation à la demande, le système NetApp Thin Provisioning augmente le taux d'utilisation du stockage)

• TR-3483 – Thin Provisioning in a NetApp SAN or IP SAN Enterprise Environment (Allocation dynamique dans un environnement d'entreprise NetApp SAN ou IP SAN)

• GC27-3913-03 - IBM XIV Storage System Planning Guide (Guide de planification du système de stockage IBM XIV)

• GC27-3912-02 – IBM XIV Storage System Product Overview (Présentation du système de stockage IBM XIV)

• 4AA3-3516ENW – HP 3PAR Architecture (Architecture HP 3PAR)

• 300-006-718 – Best Practices for Fast, Simple Capacity Application with EMC Symmetrix (Bonnes pratiques pour une application simple et rapide de capacité avec EMC Symmetrix)

• H2222.3 – EMC VNX Virtual Provisioning White Paper (Livre blanc sur la fonction EMC VNX Virtual Provisioning)

• 300-011-798 – EMC VNX Series Release 7.0 VNX System Operations (Série EMC VNX - Fonctionnement du système VNX version 7.0)

• Dell Compellent – Data Progression Data Sheet (Dell Compellent – Fiche technique sur la progression des données)

(29)

Annexe B—Caractéristiques des équipements de test

Les tests décrits dans ce livre blanc ont été réalisés avec les équipements suivants :

Baies

• Hitachi VSP

• NetApp FAS3140 fonctionnant sous Data ONTAP 8.0.2, RAID-DP sur 28 disques.

• Dell Compellent—RAID-5 sur 72 disques SAS de 600 Go

• EMC VNX5700 avec microcode 5.31, matrice RAID-5 sur 24 disques SAS 15K de 300 Go.

• HP 3PAR F400 InForm OS 3.1.1 (MU1)

• EMC VMAX-20K

• IBM XIV Gen2, 72 disques SATA de 1 To

Serveurs

• Serveurs lames HP BL, 2 processeurs Intel X5650, 16 Go de RAM, E/S HP Flex10

• Windows 2008R2 SP1 et CentOS 6.2

• IOMeter v2006.07.27

4AA4-4079FRE