Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Déduplication : comment faire le bon choix ?

juin 2017 par Mike Uzan, Évangéliste du stockage chez Kaminario

La déduplication a d’abord été introduite par les fournisseurs de sauvegarde puis embarquée dans les baies All-Flash pour les rendre économiquement rentables ailleurs que sur les applications critiques nécessitant de la performance et bénéficiant de budget illimité. En l’absence de mécanisme de réduction de données (déduplication/compression/thin) le stockage en mémoire (Flash/SSD) n’est pas accessible pour la plupart des clients (environ $10/GB). Pour la petite histoire, sur le stockage primaire ce sont les environnements VDI (Virtual Desktop Infrastructure) qui sont à l’origine du décollage de l’adoption du Flash dans l’IT.

LA DEDUP N’EST PAS UNE FIN, C’EST UN MOYEN

La déduplication (au même titre que la compression) n’est pas une fin, les clients n’achètent pas la déduplication, elle rend simplement l’équation économiquement viable car la capacité réellement nécessaire pour héberger les données est réduite par l’élimination des données redondantes. La déduplication permet d’en mettre plus dans moins, elle influe directement sur
 la densité (GB/U) : la latence (car dans la chaîne de liaison IO)
 la charge back-end en écriture (car un IO dédupliqué ne descend pas sur disque mais est pointé dans une table) : la capacité à délivrer des IO (car effectuée par les CPU qui traitent les IO)

Lorsqu’on développe un mécanisme de déduplication il faut composer avec 3 contraintes :
 le type et le poids des algorithmes qui va peser sur les CPU des contrôleurs : plus la signature d’unicité (hash) est importante plus elle pèsera sur les contrôleurs au détriment des IO.
 la gestion des métadonnées (MD) : La déduplication à taille variable limite l’empreinte des MD. Le stockage des MD influe directement sur les latences

LA DÉDUPLICATION AU QUOTIDIEN

Les taux de déduplication sont toujours bas au début et augmentent au fur et à mesure de l’ajout/du déplacement des données sur/dans la baie choisie.

Cas d’usage qui empêchent ou limitent la déduplication, les 3 principales causes :
 1. L’encryption des données : L’encryption/chiffrage des données en amont (côté base par exemple) limite le nombre de répétition à cause de l’obfuscation générée
 2. Les données compressées : Comme l’encryption/chiffrage, la compression en amont (côté base par exemple) limite également les répétitions. Il est conseillé de compresser côté baie, cela n’altère pas la déduplication et permet en plus d’économiser des CPU côté serveurs (voir des licences)
 3. La granularité du système de déduplication embarqué dans la baie : Un système de déduplication à taille fixe empêchera notamment la déduplication des bases de données (entête/signature des blocs de 8KB)

Il convient aussi de prendre en considération les données générées par les ordinateurs (photo/vidéo/audio...) comme non déduplicables alors que les données générées par l’homme le seront beaucoup plus (documents office/logs/enregistrement de base...). Il est donc préférable de désactiver la dédup sur les bases de données pour économiser des ressources côté contrôleur de baie qui ont des ressources CPU limités. La finalité étant de délivrer des IOPS (input/output operations per second en anglais, opérations d’entrée-sortie par seconde).

En résumé, une déduplication efficace sera INLINE, à taille de block variable, débrayable (ON/OFF) pour la désactiver côté base et activer côté bureautique/VDI/VSI.
L’efficacité de la déduplication est dépendante de la nature des données actuelles et futures ; d’autre part une garantie de la capacité dite "effective" (après dedup) s’avère indispensable pour ne pas se retrouver 6 mois après l’achat bloqué avec une baie pleine faute de déduplication suffisamment efficace.


Voir les articles précédents

    

Voir les articles suivants