Lors de l’acquisition d’une nouvelle technologie le prix est souvent un des premiers critères. Néanmoins un critère doit attirer l’attention des décideurs le “EXIT COST”. Ce critère permet d’estimer le coût en cas de changement de technologie après son acquisition. Une solution peu couteuse mais avec un exit cost très important doit pondérer le prix d’acquisition … car un jour il faudra en sortir.
Leader incontesté de la déduplication @Riverbed pour les flux réseaux. L’algorithme est terriblement efficace et basé sur un catalogue symétrique. Ainsi, une fois le paquet passé, le boitier source et le boitier destination possèdent la même référence. L’économie de bande passante et donc la réduction de la latence est très importante. Il faut alors deux boitiers pour dé-dupliquer le trafic entre les deux sites.
La déduplication est aussi utilisé pour le stockage. Sur les flux réseau ça permet d’économiser de la bande passante et réduire la latence. La bande passante est de plus en plus importante et un cout moindre permettant de douter sur une telle technologie se justifiant sur ce critère. La latence est un autre élément car il est possible de fluidifier des transactions et s’autoriser à déporter des applications sans se soucier de la distance … synonyme de latence.
Pour le stockage, le besoin est différent en permettant de réduire la surface utilisé. Mais comme toutes technologies regardons les inconvénients appliqués à des environnements de production.
Prenons une technologie proposant de la déduplication permettant de faire des snapshots des environnements de production à une vitesse fulgurante. Nous ne nous attarderons pas à un catalogue centralisé, symétrique … ou autres approches. Nous ne discuterons pas non plus de la crédibilité d’appeler un snapshot un backup ou pas.
Comment schématiser la déduplication :
A partir d’un ensemble de blocs il est possible de constituer un « mot » comme dans l’exemple suivant avec « COMPUTING » représentant 9 caractères.
En cas de modification de certains blocs pour modifier le mot « COMPUTNG » par « COMPUTER », il est possible de faire un snapshot pour retourner à l’état avant la modification sans avoir à conserver une copie complète du mot. Nous n’avons alors qu’à conserver 2 caractères à la place de 9. Nous économisons donc 7 caractères.
S’il était nécessaire de faire plusieurs snapshots l’économie de surface disque va devenir très rapidement exponentiel.
Il est alors possible de conserver un très grand nombre de versions d’un même environnement afin de pouvoir revenir à la version intéressante en fonction des évènements. Il est même possible pour les puristes de « monter » le snapshot en lecture et parcourir l’arborescence pour y trouver « LE » fichier nécessaire sans restaurer l’ensemble de la VM.
Prenons l’exemple de 2 VMs de 1 TB et leurs backups/snapshots utilisant la déduplication. Nous obtenons un total de 2 VMs au total de 2 TB et des snapshots pour 880 GB.
Pour différentes raisons il peut arriver d’être obligé d’externaliser les VMs sur un environnement différent. A ce stade pour externaliser les VMs et les Snapshots/Backups le système doit réhydrater les Snapshots pour les transformer en VMs. NA ce stade le DSI doit faire face à un choix :
- Est-ce qu’il est acceptable d’abandonner et donc de perdre les snapshots utilisés comme des backups ?
- Perdre des snapshots/Backups est inacceptable et il faut trouver la surface disque suffisante pour stocker la taille de toutes les VMs comme dans le diagramme ci-dessous .
L’environnement passe donc de 2 VMs de 2 TB à 11 VMs de 11 TB. Sur un système comme celui-ci ca n’est pas un gros problème, mais imaginons un environnement de 400 VMs avec des Backups depuis 2 ans à raison d’un backup (snapshot) toutes les 6 heures (1460 Snapshots/Backups).
400 + 1460 = 584 000 VMs de 584 000 TB soit 570 PetaBytes
Dans un tel environnement les 400 TB de VMS se transforme en 584 000 VMs de 570 PB. Pour la migration des VMs du système utilisant la déduplication utilisant un système de snapshot pour faire office de backup, il faut un environnement de stockage de 570 PB.
Maintenant le deuxième effet kisscool de la solution. Imaginons que l’export n’était que temporaire avant de réimporter l’environnement de production sur un environnement utilisant la même technologie de déduplication/snapshot. Le problème est que dans un tel cas, le « ancien » snapshot des VMS sont devenus des VMs et qu’une fois dans l’environnement la déduplication va s’appliquer sur les VMs mais sans être capable de reconstruire les Snapshots et les associer aux bonnes VMS. La preuve qu’une telle solution ne doit pas se substituer aussi pour cet argument à une vraie solution de backup.
Nous nous retrouverons donc avec les 11 VMs de l’exemple avec diagramme totalisant les anciennes VMs et leurs anciens snapshots.
Pour reprendre l’exemple de 400 VMs de productions, il faudrait alors administrer dans l’environnement les 570 PB mais surtout administrer 584 000 VMs ! Autant dire qu’à l’usage ca devient impossible à administrer et il est préférable d’effacer toutes les VMs de backup …
Voilà un exemple de l’exit cost d’une nouvelle technologie qu’il faut considérer avant d’en faire l’acquisition.