Tout savoir sur le stockage

Dans cet article, vous allez tout savoir sur le stockage, comment le dimensionner, choisir son niveau de RAID en fonction des applicatifs, les considérations liées à la sauvegarde, à la réplication, les impacts sur le réseau, bref un MUST READ 😉

1. Dimensionner le stockage

Pour bien dimensionner son stockage et l’espace disque requis, il est recommandé de prévoir au moins 20 % de plus par rapport à l’espace disque actuel réellement utilisé afin de prévoir et d’anticiper la croissance de vos données estimées. Si vous comptez profiter de la fonctionnalité de snapshot (instantanée de données) de votre baie, sachez que Microsoft recommande au minimum 20% d’espace disque disponible afin de pouvoir utiliser cette fonctionnalité sous peine d’obtenir des échecs. A cette valeur, vous devez adjoindre le ROC (Rate Of Change, le taux de changement) et leur fréquence.

La formule à appliquer pour les snapshots est la suivante : Taille totale = Espace actuel + ROC * fréquence + Espace réservé + croissance

Prenons un exemple : Vos données représentent 100 Go et vous estimez le ROC à environ 10% soit 10 Go. Vous désirez avoir une rétention de 10 jours à raison de 1 snapshot par jour, soit 100 Go (10 Go * 10 jours) en tenant compte de la réserve de 20% imposée par Microsoft nécessiteront 220 Go auxquels il convient de rajouter 20 % croissance (valeur estimée) pour une année soit un total de 240 Go.

Selon les performances des baies de stockage qui peuvent varier sensiblement d’un modèle à un autre, il peut être nécessaire de limiter le nombre de réservations SCSI qui peuvent dégrader les I/O (opérations entrées/sorties) de façon importante. Pour cela, connectez une dizaine de serveurs physiques par LUN, et que chaque LUN héberge entre 6 à 12 machines virtuelles. Il est également recommandé de créer des machines virtuelles de taille fixe pour des raisons de performances (activité disque élevée, …) et d’utiliser le mode PassThru ou RDM (Raw Device Mapping) pour certaines applications.

2. Les niveaux de RAID

Il est important en fonction du type d’application à héberger sur le stockage partagé de bien choisir le niveau de RAID car cela va directement impacter les performances aussi bien en termes de débit qu’en opérations d’entrée/sortie.

Lors de la création de vos Arrays (Pile ou Grappe RAID) pensez à intégrer dans le calcul du nombre de disques nécessaires au moins un disque de SPARE. Selon les baies de stockage, le(s) disque(s) de Spare peut être dédié à une pile RAID ou être défini comme global et sera affecté automatiquement à une pile RAID dont l’un des disques venait à tomber en panne.

En cas de défaillance de l’un des disques au sein de la grappe RAID, les temps de reconstructions peuvent être problématiques si votre applicatif nécessite des performances soutenues à tout moment. Vous trouverez ci-dessous l’impact sur les performances et les temps de reconstruction entre un RAID de niveau 5 et 10, le RAID de niveau 6 n’est pas abordé, car du fait de sa double parité cela impactera encore plus durement les performances et les temps de reconstruction, nous y reviendrons plus tard.

Niveau de RAID Impact IOPS lors d’une reconstruction Temps de reconstruction
RAID-5 50% 15 à 50% plus lent que du RAID 10
RAID 10 / 1 / 0 20 à 25% 15 à 50% plus rapide que le RAID 5

Les niveaux de RAID selon leurs calculs de parité sont impactés par une pénalité en écriture, le RAID de niveau 6 ayant une pénalité très forte du fait de sa double parité.

Pénalité RAID
1 RAID-0
2 RAID-1 et 10
4 RAID-5
6 RAID-6

Nous allons maintenant aborder la notion de Pattern I/O (modèle) qui déterminera le niveau de RAID par rapport aux applications. Chaque type d’application possède son propre Pattern I/O qui le caractérise par sa prédominance des accès en lecture aléatoire sur des blocs de 4 Ko par exemple.

Pattern I/O des applications les plus courantes
Applications Accès Taille de bloc Ecriture / lecture
Serveur de fichier et  d’impression – Messagerie Aléatoire 4k – 64k 20% / 80%
Vidéo Streaming Séquentiel 256k – 512k

1M

25% / 75%
Backup, CAO / DAO Séquentiel 256k – 512k

1M – 2M

10% / 90%
Base de données Aléatoire 4k – 8k –  16k

32k – 64k

20% / 80%
Serveur Web Aléatoire 512b – 512k 5% / 95%
Business, Ingénierie Séquentiel

Aléatoire

2k – 16k 20% / 80%

Une fois votre Pattern I/O déterminé, le tableau ci-dessous vous indiquera le niveau de RAID recommandé afin d’obtenir les meilleures performances.

RAID 0 Station de travail High End, Fichiers journaux, rendu temps réel, vidéo, imagerie
RAID 1 Système d’exploitation, BDD transactionnelle
RAID 5 ERP, serveurs web, Bases de données, CRM, Streaming, serveurs de fichiers, applicatifs métier
RAID 6 Archivage, Sauvegarde disque, solutions haute disponibilité, serveur avec grande capacité de stockage, serveurs de fichiers
RAID 10 ou 0+1 Calcul, R&D, base de données rapide, serveurs d’applications et de messagerie
RAID 50 Grosses BDD, serveurs de fichiers, serveurs d’applications, messagerie
RAID 60 Archivage, Sauvegarde disque, solutions haute disponibilité, serveur avec grande capacité de stockage

Si vous n’arrivez pas à déterminer le Pattern I/O de votre application, ce tableau sera à même de vous y aider en synthétisant les performances, coût, et niveau de protection des niveaux de RAID les plus couramment utilisés.

RAID Performances des lectures (aléatoires et séquentielles) Performances des écritures (aléatoires et séquentielles) Niveau de protection Coût
1 / 10 Très bon / très bon Très bon / bon Très bon €€€€
5 Très bon / bon Moyen / bon Moyen
6 Très bon / bon Mauvais / moyen Très bon €€
50 Très bon / bon Bon / bon Bon €€€

Vous trouverez ci-dessous quelques tests qui vous permettront de vous faire une idée sur les performances en fonction des niveaux de raid et du type de disques utilisés. Ces tests de performance ont été réalisés sur une baie de 8 disques durs avec un Pattern I/O de 70% des en lecture et 30% en écriture, le cache paramétré à hauteur de 50% en lecture et 50% en écriture avec un stripe de 64 k et taille des I/O de 64k.

RAID 10 RAID 5
Disques 147 Go SAS

15.000 Tours/min

iops 2300.50

débit 143.78 MB/s

iops 1574.03

débit 98.83 MB/s

Disques 900 Go SAS

15.000 Tours/min

 

iops 2178.35

débit 136.15 MB/s

 

iops 1490.45

débit 93.15 MB/s

Disques 1 To

Enterprise SATA

7.200 Tours/min

iops 934.76

débit 58.42 MB/s

iops 639.57

débit 39.97 MB/s

Disques 2 To SATA

5.400 Tours/min

iops 583.72

débit 36.48 MB/s

iops 399.39

débit 24.96 MB/s

Certaines applications requièrent un nombre d’opérations entrée/sortie par seconde pour fonctionner correctement. Par exemple, lors du dimensionnement d’un serveur de messagerie Exchange version 2010, Microsoft donne la marche à suivre pour calculer le nombre d’IOPS requis en fonction de certains critères (nombre de courriels reçus par jour, etc…). Dans l’exemple ci-dessous, imaginons que nous devons soutenir 40 lectures et 80 écritures. La formule de calcul à appliquer est la suivante: IOPS = IOPS requis lecture + (pénalité RAID * IOPS requis écriture)

Calcul du nombre disque requis en RAID de niveau 1

RAID-1 => 40 + (2* 80) = 200 IOPS

Pour des disques 10.000 tours => 200 / 125 = 2 disques requis

Pour des disques 5400 tours => 200 / 50 = 4 disques requis

Calcul du nombre disque requis en RAID de niveau 5

RAID-5 => 40 + (4* 80) = 360 IOPS

Pour des disques 10.000 tours => 360 / 125 = 3 disques requis

Pour des disques 5400 tours => 360 / 50 = 8 disques requis

Tours par min IOPS
SSD 100000
15.000 175
10.000 125
7200 75
5400 50

Estimation constructeurs en moyenne

Le RAID de niveau 6 offre une protection  plus élevée que le RAID de niveau 5, car la parité est doublée, et nécessite donc 2 disques durs dédiés pour celle-ci. Il en résulte un coût plus élevé que le RAID de niveau 5 avec des performances en retrait, et des temps de reconstruction plus importants.

Ainsi, afin de pallier à cette baisse de performances, certains contrôleurs RAID embarquent un processeur spécialisé ASIC (Application Specific Integrated Circuit) dotés d’algorithmes dédiés au calcul de parité du RAID de niveau 6.

Le RAID de niveau 6 est surtout employé pour les piles RAID contenant de nombreux disques. En effet, une défaillance de plusieurs disques au sein d’une pile RAID de quinze disques sera plus probable que sur une pile ne contenant que quatre disques. Le tableau ci-dessous montre les différences de débits entre les niveaux de RAID 5 et 6.

Type d’accès Débit MB/s RAID 6 Débit MB/s RAID 5
4k séquentiel en lecture 166,07 168,45
4k séquentiel en écriture 38,37 39,44
8k séquentiel en lecture 228,08 234,88
8k séquentiel en écriture 72,79 75,49
16k séquentiel en lecture 299,11 320,83
16k séquentiel en écriture 133,36 139,36
64k séquentiel en lecture 386,00 438,85
64k séquentiel en écriture 162,54 208,34
1M séquentiel en lecture 434,77 463
1M séquentiel en écriture 167 194

2.1. Paramètres RAID avancés

Le principe du RAID consiste à découper les fichiers en petits morceaux afin de les répartir sur les différents disques durs composant une pile RAID. On parle alors de chunk, stripe, bloc size, etc…. Beaucoup de confusion règne autour de ces termes, et chacun s’approprie sa propre définition.

Voici une définition de ces termes:

  • Spindle: disque dur
  • Secteur (ou unité d’allocation): ensemble d’octets
  • Bloc: ensemble de secteurs
  • chunk: équivalent au bloc dans le monde RAID
  • Stripe (ou stripe unit): certains l’assimile à un bloc ou chunk sur un même spindle
  • Stripe Width (largueur de bande): nombre de disques composants une pile RAID
  • Stripe Size (taille de bande): certains l’assimilent à un ensemble de chunks (ou blocs) sur un même disque ou répartis sur plusieurs disques (nous allons retenir cette dernière définition)

Le chunk correspond à la taille des données contigües qui sont écrites sur un disque dur avant que le contrôleur RAID ne passe à un autre disque dans la bande.

Notez également que si vous comptez utiliser une taille relativement petite, prenez le soin de bien choisir votre contrôleur (doté d’un processeur ASIC puissant) car celui-ci va être très sollicité pour découper les données. Pour définir correctement votre paramètre chunk, faîtes correspondre votre Pattern I/O à la taille du chunk, dans la mesure du possible.

La taille de la bande (stripe size) définit la taille d’un bloc (ou chunk) dont les secteurs sont répartis sur plusieurs disques. Par exemple, un fichier de 1M représentera seize blocs sur un RAID dont le stripe size est de 64k. A l’inverse, si le fichier est inférieur à la taille de la bande, le contrôleur RAID enverra la donnée sur un seul disque ne sachant pas la découper, entrainera l’occupation de la bande et une baisse de performance.

Prenons un exemple, une base de données lit ou écrit en une opération de petites données contenues dans les tables, comme des numéros de carte de crédit, des coordonnées de clients, … Une taille de 64k parait surdimensionné, car il est rare qu’une coordonnée pèse 60k, de plus l’espace réservé de 64k ne sera pas consommé, d’où une perte de performances et d’espace disque.

Tandis que pour des opérations de serveurs de fichiers, il convient d’envoyer le maximum de données en une opération, il convient alors de prendre une taille importante, 128k voire 256k, par exemple.

La taille de la bande s’obtient en multipliant le nombre de disques dans votre pile RAID (en capacité utile, c’est à dire un disque en moins dans votre calcul pour un RAID de niveau 5) par la taille de chunk, ou doit être un multiple de votre Pattern I/O.

Exemple: 32k de données sur un stripe de 8k = 4k de taille de chunk

Exemple: 1M de données sur un chunk de 64k = 16k de taille de stripe

Pour résumer, une petite taille favorisera les temps d’accès et les opérations d’entrée/sortie alors qu’une taille importante favorisera les débits de transfert.

Si vos accès sont en moyenne de 16k sur un stockage paramétré avec un chunk de 64k, les serveurs accéderont à un seul disque dans la pile RAID, ce qui n’est pas recommandé car le but est de répartir les données sur plusieurs disques afin d’en accélérer le traitement.

Dans l’exemple suivant, je compare un RAID composé de 4 disques durs, l’un avec un largueur de bande de 64 k, l’autre avec un largueur à 256k, avec des fichiers de tailles différentes. Le fichier de 128k est réparti sur l’ensemble des disques, et les autres fichiers sont également répartis sur l’ensemble des disques ne laissant que peu d’espace disque disponible.

Dans l’exemple ci-dessous, le fichier de 128k est stocké sur un disque seulement, celui de 256k sur deux disques et le fichier de 1M demeure sur quatre disques mais on constate que nous disposons de plus d’espace disque (disque dur 3 et 4).

Il est essentiel de retenir deux notions, les bases de données requièrent des opérations d’entrée/sortie par seconde très élevées tandis qu’un serveur de fichier requiert du débit. En règle générale, il convient de choisir une taille comprise entre 64 k et 1 M (nombreux gros chunks lus sur un même stripe) pour les accès séquentiels et 512B à 8 k pour les accès aléatoires.

Les schémas suivants comparent les débits en fonction de la taille du chunket du Pattern I/O.

Ces tests démontrent que pour des bases de données (4 à 8k), la taille de chunk idéale est 32 ou 64k, tandis que pour des Pattern I/O « classique » (256 à 1M), la taille idéale du chunk est 128 ou 256k; et que pour les accès séquentiels intensifs la valeur idéale est 256 ou 512 et pour applications vidéo, streaming celle-ci est de 1024.

Ces tests ont été réalisés sur des accès séquentiels, pour des accès aléatoires, les conclusions tirées de l’analyse des schémas précédents s’appliquent également.

Vous avez constaté qu’il est important de tenir compte des paramètres abordés ici, sous peine de perdre inutilement de l’espace disque et d’obtenir des performances médiocres. Certaines baies analysent pour vous la taille de vos requêtes. Dans la capture suivante, la baie nous informe que les accès en lecture ont en moyenne une taille de 4k et 1M et 64k en écriture. On peut en déduire que cette baie de stockage héberge certainement une base de données, des fichiers de taille moyenne et importante.

2.2. La longueur de file d’attente et ses impacts

Le paramètre de la profondeur de la file d’attente (Queue Depth) définit le nombre d’opérations d’entrée/sortie d’une commande qui peuvent être envoyées à un port en une seule fois, soit le nombre de requêtes disques exécutées au maximum.

Une profondeur de file d’attente trop faible ou trop importante peut brider ou diminuer les performances, ainsi ce paramètre doit être défini de façon judicieuse pour optimiser les IOPS et les temps d’accès. Néanmoins, les paramètres par défaut des cartes fibre optique et des baies de stockage demeurent tout à fait acceptables.

Une fois la file d’attente remplie, les autres opérations peuvent être refusées ou alors la carte HBA peut passer son temps à attendre qu’une file soit remplie. La plupart du temps la valeur par défaut est de 16 ou 32. Un paramètre de 32 indique qu’une carte HBA peut envoyer 32 opérations dans la file d’attente avant de créer une autre commande.

A titre d’exemple, un contrôleur d’une baie de stockage dispose d’un Queue Depth de 128 opérations d’entrée/sortie par port. Si cette même baie embarque deux ports par contrôleur et qu’ils sont redondants, le Queue Depth sera de 512 pour l’ensemble de la baie. En règle générale, la plupart des baies actuelles disposent d’un Queue Depth de 2048. En revanche, certaines cartes fibre optique ne disposent pas de la même profondeur de file d’attente : QLogic permet des files d’attente de 255 où Emulex n’offre que 128, mais il est rare de définir un paramétrage aussi élevé.

Ce paramétrage peut être défini sur la baie, une cible, une LUN, un port ou encore un disque, …. Les bonnes pratiques veulent que l’on paramètre le Queue Depth au niveau d’une cible ou d’une LUN.

Définir une profondeur de file d’attente au niveau d’une cible (et donc tous ses LUNs) permet de limiter intentionnellement les IOPS, tandis qu’un paramétrage d’un Queue Depth par LUN définit le nombre IOPS qu’on peut envoyer au maximum sur ce LUN. Ainsi, une valeur Queue Depth élevée priorisera l’accès d’un serveur, et à l’inverse une valeur faible permettra de se prémunir d’un engorgement du stockage.

Prenons un exemple, votre baie dispose d’un Queue Depth de 1000 sur laquelle vous avez créé 20 LUNs avec une profondeur de 64 par LUN. Cette configuration provoquera un engorgement en appliquant la formule suivante : 20 LUNs * 64 = 1280 commandes. Il convient, dans cet exemple, d’abaisser la profondeur de la file d’attente à 32. Lorsque vous procédez à des modifications de Queue Depth, appliquez votre paramétrage au niveau de votre carte HBA et de votre baie de stockage.

Autre exemple, pour 4 LUNs rattachée à un port pouvant gérer 128 commandes, la valeur idéale Queue depth sera de 32 (128 commandes / 4 LUNs)

Il convient ainsi de retenir que modifier le Queue Depth peut améliorer les performances du stockage, et accélérer les IOPS. Dans des environnements de virtualisation, un paramétrage de 32 voire 64 est idéal, aussi bien pour Microsoft Hyper-V, VMWare ESX que pour un serveur SQL.

Pour résumer, le Queue Depth (appelé également Execution Throttle) doit avoir une certaine taille de façon à ce que le stockage traite suffisamment d’informations pendant que l’application traite les précédentes. Pour de petits chunks, il est important d’avoir en tête que le temps de rotation et d’accès (seek time) sont des paramètres importants.

Un disque dur SAS 15.000 tours délivre 180 IOPS avec une profondeur de 1, si la profondeur est supérieure cela permettra de traiter simultanément plusieurs I/O avant une autre commande. Partant de ce principe, augmenter la profondeur de 2 à 4 augmentera les IOPS du disque, soit 200 à 240 IOPS, mais les gains ne sont pas linéaires au-delà de ces valeurs.

Plus la profondeur est grande, plus on accumule de données donc plus le débit augmente et la latence également, à l’inverse une petite profondeur va multiplier les commandes, soit une meilleure latence. Une grande profondeur est idéalement paramétrée quand on dispose de larges piles RAID, et une petite profondeur est paramétrée pour des petites piles RAID, typiquement des bases de données transactionnelles qui requièrent des latences très basses.

Donc, le Queue Depth doit être calculé par disque avec le plus souvent une valeur à 1 mais il convient que la somme des Queue Depth de toutes vos HBA ne dépasse celle permise par votre stockage.

Prenons un exemple: 4 disques durs en RAID avec un chunk de 16k. Il faudra donc 8 opérations de 16k pour écrire un fichier de 128k, soit un Queue Depth de 2 par disque.

2.3. Notion avancée du stripe size

Pour configurer une baie de stockage, il existe deux façons de faire: la plus simple est de créer un RAID, l’autre est de créer un RAID en paramétrant des tailles de chunk, stripe, …. Ces paramètres barbares sont essentiels, et on passe bien souvent à côté. Un bon paramétrage consiste à minimiser les opérations mécaniques (temps d’accès) sur chaque disque pour écrire la donnée !

Observons la tableau ci-dessous:

Niveau de RAID Nb de disques dans l’array Disque utiles Chunk Size Taille de stripe
5 6 5 64 Ko 320 Ko
0 10 10 16 Ko 160 Ko
10 8 4 32 Ko 128 Ko

Dans le cas d’un RAID-5, on multiplie le chunk size par le nombre de disques, y compris celui de parité. Donc 6*64 Ko = 320 Ko de taille de stripe.

Dans le cas d’un RAID-0, on multiplie le chunk size par le nombre de disques composant l’array. Donc 10*16 Ko = 160 Ko de taille de stripe.

Dans le cas d’un RAID-10, on multiplie le chunk size par le nombre de disques utiles. Donc 4*32Ko = 128 Ko de taille de stripe.

La taille de bloc ou chunk size définit la taille d’une lecteur ou d’une écriture d’un disque avant de passer au disque suivant => d’où l’importance de l’alignement de partitions !

L’alignement des partitions est un facteur important de performance souvent négligé. Il y a peu de temps, lors d’un audit d’un serveur SQL, je me suis aperçu que les partitions de serveur n’étaient pas alignées. Heureusement que Windows 2008 le réalise automatiquement (à 1024 k). Il est difficile de rattraper le coup pour la partition système, mais il convient absolument de le faire pour une partition de données. Comme les pistes ne sont pas alignées avec les partitions, une opération d’E/S peut s’étendre sur deux pistes, ce qui entraîne une altération des performances, jusqu’à 25% de perte.

Chaque disque contient un MBR (Master Boot Record) de 63 secteurs, et le donnée commence au secteur 64. La plupart des disques disposent  de 512 bytes * 63 secteurs = 32256 soit 31.5 ko alors qu’une partition alignée doit être de 512 * 64 = 32768 soit 32 k. Dans un stripe size de 256k d’une pile RAID, un mauvais alignement générera beaucoup plus opérations pour une seule E/S. Le script VBS suivant permet de tester l’alignement de vos partitions:

strComputer = "." ' Local Computer

SET objWMIService = GETOBJECT("winmgmts:\\" & strComputer & "\root\CIMV2")

SET colItems = objWMIService.ExecQuery("SELECT * FROM Win32_DiskPartition",,48)

FOR EACH objItem in colItems
Wscript.Echo "Disk: " & objItem.DiskIndex & " Partition: " & objItem.Index & " StartingOffset: " & objItem.StartingOffset/1024 & "KB"
NEXT

Pour aligner les partitions, utilisez DISKPART en ligne de commande:

diskpart 
list disk
select disk 1 
clean
create partition primary align=1024
format quick fs=ntfs ou format fs=ntfs unit=64K label= »MyFastDisk »
active

Chaque disque contient un MBR (Master Boot Record) de 63 secteurs, et le donnée commence au secteur 64. La plupart des disques disposent  de 512 bytes * 63 secteurs = 32256 soit 31.5 ko alors qu’une partition alignée doit être de 512 * 64 = 32768 soit 32 k. Dans un stripe size de 256k d’une pile RAID, un mauvais alignement générera beaucoup plus opérations pour une seule E/S.

Prenons le cas du RAID-5, nous voulons écrire 640 Ko, il sollicitera deux fois chaque disque, étant donné que le stripe size est de 320 Ko. La solution serait de définir une taille de bloc de 128 Ko pour que l’écriture d’une donnée de 640 Ko s’effectue en 1 seule opération ! A l’inverse une petite taille de bloc pour traiter des fichiers vidéos va engendrer des performances catastrophiques et une grosse taille de bande (stripe) entrainera une occupation disque inutile pour de fichiers très petits (exemple BDD).

Voici donc une tableau, qui en fonction du type d’application détermine la taille de bloc à appliquer, on parle de Pattern I/O qui caractérise la prédominance du type d’accès d’une application.

Pattern I/O Taille de bloc
Serveur de fichiers 4 – 64 Ko
Vidéo 256 Ko – 512 Ko – 1 Mo
Backup 1 – 2 Mo
Base de données 4 – 8 – 16 -32 -64 Ko
Web 512b – 512 Ko
CAO/DAO 2 -16 Ko

3. Réplication des données

Les entreprises doivent faire face à des applications qui doivent être disponibles 24/7, qu’elles soient hébergées dans un datacenter, accédées via des clients nomades ou depuis des sites distants, …. Bien entendu, il faut également gérer l’augmentation des volumes de données ! De nos jours, de plus en plus d’applications sont/deviennent critiques, ainsi, il n’est pas rare de constater dans une entreprise que la moitié des applications (voir plus) sont indispensables ! Celles-ci doivent donc être intégrés dans le cadre d’un PCA ou PRA, ce qui sous-entends une continuité applicative ET des données !

Voici donc quelques éléments techniques et fonctionnels relatifs à la réplication.

Dans le cadre de PRA, les sauvegardes sont encore couramment utilisées, mais restent contraintes pas des limites géographiques. Les temps de reprise peuvent être considérablement allongés, alors le choix d’avoir un site de secours d’une distance assez faible de celui de production est réalisé, mais ce choix géographique ne prends pas en compte d’éventuelles catastrophes naturelles, comme des tremblements de terre, etc…. De plus, certaines entreprises doivent respecter des conformités HIPAA, Sarbanes-Oxley …. Les solutions de type « Cloud » (attention si vous hébergez vos données chez une société Américaine, la loi Patriotic Act peut potentiellement être dangereuse pour la confidentialité de vos données !) et de virtualisation apportent des réponses concrètes ! En effet, la virtualisation de  serveurs ne sont que de « simples » fichiers à manipuler, sauvegardable comme un simple fichier WORD, ou presque mais ce n’est pas l’objet du thème abordé ici.

Pour palier aux sauvegardes et leurs contraintes associées, une réplication peut être déployée de façon synchrone ou asynchrone, mais cela alourdit beaucoup le trafic WAN. Il existe des appliances/solutions appelées accélérateurs WAN qui permettent d’optimiser de façon incroyable le trafic généré sur les WAN, ce qui facilité grandement le déploiement de PCA/PRA.

Il convient d’avoir à l’esprit qu’une réplication n’inclut pas (forcément) des notions de reprise/bascule automatique, et n’est pas une sauvegarde ! En effet, une erreur faite à la source sera répliquée vers les cibles ! Une réplication a pour seule fonction de répliquer les données d’un point vers un autre, en s’assurant bien entendu, que celle-ci soit cohérente d’un point de vue données. Les solutions de réplications sont nombreuses sur le marché EMC SRDF/A, Hitachi True Copy, Netapp SnapMirror, Dell Auto-Replication, etc… pour les données et VMWARE SRM, Veeam Backup & Replication, Platespin Protect, vReplicator, etc… pour les serveurs.

Cette étude menée en 2009 (donc pas si lointaine que cela) montre que les moyens mis en oeuvre sont assez rudimentaires… On est loin d’une disponibilité des applications et des données efficaces: la réplication est employée à hauteur de 20% des serveurs virtualisés !

Plusieurs types de protection et de disponibilité de services: High Availability, Business Continuity, Disaster Recovery. HA – haute disponibilité – représente les moyens locaux: disques durs en RAID, carte réseaux double ports, …. BC – continuité d’activité –  fait appel à des notions de clustering (CSV, …) de synchronisation de baie de stockage, VMware HA en local ou sur une distance relativement courte (limite d’une fibre optique, par exemple). DR, ou reprise après sinistre, s’opère la plupart du temps à une échelle WIDE (réseau étendu WAN) de façon asynchrone et demeure complexe à mettre en oeuvre du fait que les paramètres réseaux diffèrent (DNS, …), bande passante relativement faible, appréhender la bascule (failover / failback), …

Nous l’aurons bien compris, la qualité nos liaisons WAN sera une critère déterminant pour la mise en oeuvre de PCA/PRA. Ces PCA/PRA doivent tenir compte de notions de RPO et RTO. Le schéma ci-dessous montre comment déterminer son plan, la situation  idéale est le résultat du recoupement des coûts associés à la mise en oeuvre un PCA/PRA et des coûts liés à une perte de données et/ou d’indisponibilité. Si le coût d’une solution type VMware SRM (Site Recovery Manager) permettant une haute disponibilité du système coûte 100.000 € et que l’indisponibilité du système mettrait 40 salariés au chômage technique d’un coût de 50.000 € par heure, votre objectif doit être de reprendre en 2 heures. Voici un peu l’esprit du schéma présenté ci-dessous.

L’organisme SNIA, Storage Networking Industry Association, nous gratifie également d’un joli tableau prenant en compte les TIER, si vous désirez vous lancez dans l’hébergement d’application ou pour respecter les standards.

Bien entendu, les niveaux de disponibilité sont liés à la fréquence et à la rapidité des transferts entre les sites ! La définition d’un lien WAN pourrait être la suivante: lien réseau disposant d’une bande passante limitée avec une latence non constante, voire hasardeuse, qui peut envoyer les paquets dans le désordre. Bref, tout pour mettre en péril les objectifs RPO/RTO. Le nouveau challenge consiste  à prendre en compte la croissance ininterrompue des données, la criticité des applications et l’augmentation des distances entre les datacenters. Nous avons à l’esprit que la réplication génère un trafic soutenu en plus des éventuelles applications métiers.

Quelles solutions s’offrent à nous ? Deux. L’un consiste à optimiser les liaisons, l’autre d’implémenter des appliances d’accélérations WAN et/ou de déduplication. La plupart du temps, les DSI commandent des liens plus gros, sans mener des investigations préalables, et bien souvent ces nouveaux liens, loués très cher, ne solutionnent pas leur problème de performance ! Mais dans un premier temps, il est important de classifier les données et les applications par criticité, il est inutile d’avoir un RPO/RTO très faible pour une application ne servant qu’une fois par mois, tandis qu’une logiciel de facture ou CRM sera très important et impactant pour l’activité d’une entreprise. De plus, il convient d’analyser les moyens/protocoles employés, certaines technologies propriétaires ou reposant sur de l’encapsulation (FCIP, FCoE) peuvent affecter les performances d’une appliance du fait que les données soient déjà compressées, par exemple. Il est également important de connaître le trafic généré en moyenne, les pics et leur fréquences, combien est-il nécessaire pour transférer un élément ou son delta, …

3.1. Impact sur la bande passante

Il existe deux principaux ennemis qui dégradent la bande passante, la latence et la perte de paquets (voir même la réception dans le désordre). L’oversubscription consiste pour un routeur a mettre en file d’attente des paquets (dans le désordre ou inutilisables) en évitant de les perdre et si possible sans dégrader les performances (cela dépend des capacités du routeur). Une retransmission excessive entraine une baisse du GOODPUT. Cette notion fait référence à de la bande passante utile et non théorique. Par exemple, une liaison 2 Mb ne délivre pas 2 Mb, mais peut-être 1.8 Mb, c’est ce que l’on appelle le GOODPUT (voir la définition ici et ici).

Imagine that a file is being transferred using HTTP over a switched Ethernet connection with a total channel capacity of 100 megabits per second. The file cannot be transferred over Ethernet as a single contiguous stream; instead, it must be broken down into individual chunks. These chunks must be no larger than the maximum transmission unit of Ethernet, which is 1500 bytes. Each packet requires 20 bytes of IP header information and 20 bytes of TCP header information, so only 1460 bytes are available per packet for the file transfer data itself (Unix systems, Linux, and Mac OS X are further limited to 1448 bytes as they also carry a 12 bytes time stamp[1]). Furthermore, the data are transmitted over Ethernet in a frame, which imposes a 26 byte overhead per packet. Given these overheads, the maximum goodput is 1460/1526 × 100 Mbit/s which is 95.67 megabits per second or 11.959 megabytes per second. Source: http://en.wikipedia.org/wiki/Goodput

Ce schéma montre bien l’impact des pertes des paquets sur le GOODPUT.

Il convient d’analyser tous vos flux et s’ils sont soumis à des règles de QoS ? Limiter les bandes passantes par flux de façon à assurer le service ou afin de se prémunir de la monopolisation d’une application au détriment d’une autre, demeure essentiel. La paramètre « latence » est également nécessaire d’être pris en compte car plus la distance est grande  plus le chemin à parcourir pour les paquets est important ! (avec le risque de pertes, etc….)

Afin de se prémunir de ce type de problèmes, il existe FEC (Forward Error Correfction), POC (Packet Order Correction), l’optimisation de la fenêtre TCP, etc… Ce lien détaille les différentes optimisations WAN possibles.

À titre d’exemple, augmenter la bande passante devient inopérant en cas de forte latence due à des distances trop importantes entre les équipements sources et cibles.  De même, la bande passante importe peu si les paquets sont perdus ou fournis de manière non-séquencée compte tenu des phénomènes de congestion, comme c’est souvent le cas au sein des environnements Cloud et MPLS plus économiques, mais de moindre qualité.

Enfin, lorsque tous les facteurs sont considérés, le coût de l’ajout plus de bande passante est souvent nettement plus élevé que le coût du déploiement d’une solution d’accélération WAN. Mis à part une augmentation spectaculaire des dépenses de la bande passante récurrents (30% à 60% en moyenne),

Certaines appliances spécialisées dans l’optimisation comme SRDF/A  EMC, Symmetrix Remote, Data Facility/Asynchronous FCIP, etc… promettent:

  • Accélère de 5 à 50 fois les applications sur le WAN et même jusqu’à 100 fois dans certains cas
  • Réduit de 65 à 95 % la congestion du réseau et l’utilisation de la bande passante du WAN
  • Fournit des performances de type LAN aux employés mobiles du monde entier

Riverbed met à disposition un outil permettant de calculer les gains, disponible ici.

 

Plus le débit WAN est important, meilleur pourra être le RPO/RTO. En effet, la capacité à reprendre d’un site à l’autre et la capacité de sauvegarder le plus vite possible impactent directement la possibilité de mise en oeuvre d’une continuité d’activité et/ou de récupération après sinistre. La diminution de la perte de données maximale admissible (RPO) et la réduction de la durée maximale d’interruption admissible (RTO) s’opère en optimisant les WAN et les VPN.

3.2. Considérations liées au stockage

Certains dispositifs de stockage disposent de mécanismes qui leurs sont propres et dédiés à la réplication, comme la déduplication (très bon rendement), la compression, Packet Striping, … Cela peut apparaitre étonnant, mais il convient la plupart du temps de désactiver ces options qui peuvent rendre les algorithmes des appliances inopérants ou moins efficaces. Prenons l’exemple de la compression, en désactivant la fonctionnalité sur la baie, on déporte le calcul CPU vers l’appliance qui est spécialisée pour ce traitement. A noter qu’une appliance d’accélération WAN sera également incapable de traiter une encryption activée au niveau d’une baie. Voici le schéma a respecter:

OPTIMISER -> ENCRYPTER -> DECRYPTER -> DELIVRER

Pour une réplication synchrone, la latence est un facteur très important car les lectures s’effectuent en local mais les écritures sont envoyées vers la baie distante dont l’ acknowledgment est nécessaire !

Prenons le cas d’une fibre noire qui ne nous posera pas de problèmes particuliers jusqu’à 10km (1300nm laser) ou 35km (1550nm laser). On peut partir sur une perte de 5 μs par kilomètres. Une transaction iScsi typique traverse le lien 8 fois, soit 4 roundtrips. Ce qui équivaut donc à donc 5 μs * 35 kms * 8(trips)= 1400 μs soit 1.4 ms. Il faut avoir en tête que les connexions iSCSI longues distances (inter-site) qui traversent des équipements WAN ou de type FC avec IP (iFCP, FCIP, FCoE, …) alourdissent la latence !

3.3. TCP Window Size

C’est un paramètre important, voire même le plus important, pour maximiser la bande passante d’un réseau, la bande passante peut être doublée ! Prenons un exemple pour bien différencier les termes: le tuyau d’arrosage représente le lien, le diamètre représente la bande passante, la longueur du tuyau la latence (ou RTT Round Trip Time) et la fenêtre TCP définit la quantité d’eau (données) nécessaire pour remplir le tuyau.

Voici la formule pour calculer la fenêtre: ( bande passante * RTT ) / 8 / 1024 donc pour un lien 2 Mb/sec et 20 ms de latence => ( 2.000.000 * 0.02 )  / 8 / 1024 = 48 Kb – attention il faut convertir le ping exprimé en ms en sec !

Pour calculer le débit, la formule suivante s’applique: Taille de la fenêtre en bits / latence en sec = débit en bits. Exemple d’une fenêtre de 64 Kb  avec 30 ms de latence => 65536 * 8 / 0.030 => 17.4 Mbps

La taille de la fenêtre correspond au nombre maximal de paquets qui peut être envoyé sans attendre un accusé de réception positif. Les grandes fenêtres TCP améliorent les performances TCP/IP lorsque des quantités importantes de données transitent entre l’émetteur et le récepteur. Dans les communications TCP classiques, la taille maximale de la fenêtre est généralement fixée sur l’ensemble des connexions et limitée à 64 kilo-octets (65,535 octets). Donc si votre calcul renvoi à un fenêtre de 85 Kb sur un lien 4 Mb, la fenêtre par défaut (64 Kb) sous-utilisera le lien => 64/85 => 75% soit 3 Mb.

Avec une grande fenêtre, vous pouvez recalculer de manière dynamique et adapter la taille de la fenêtre réelle en utilisant une option TCP selon vos besoins au cours des sessions plus longues. Avec cette option, un plus grand nombre de paquets de données est en transit sur le réseau en une seule fois, ce qui augmente le débit.

Par défaut, les ordinateurs exécutant des systèmes d’exploitation Windows Server 2003 n’acceptent, pour l’option de grandes fenêtres TCP, que les requêtes émises par les clients des ordinateurs TCP1323Opts auxquels ils sont connectés. Les ordinateurs TCP1323Opts déposent des requêtes pour l’option de grandes fenêtres TCP au cours de la poignée de mains en trois temps. Si vous voulez que votre ordinateur fasse des demandes de grande fenêtre TCP, vous devez activer TCP1323Opts dans le Registre. Pour plus d’informations sur les grandes fenêtres TCP, voir la RFC 1323, « TCP Extensions for High Performance ».

Vous pouvez vous amusez à tester les différentes fenêtre TCP à l’aide de l’outil iPerf. Cet outil permet de mesurer la performance d’un réseau entre 2 points. Le paramètre -w influe sur la taille de la fenêtre, dans un test passer de 60 à 130 donne un gain conséquent en passant de 5.2 à 15.7 Mb/s !

Pour appliquer une fenêtre TCP, la formule est le suivante: taille de la fenêtre en bits * 2 ^ facteur d’échelle – Donc pour fenêtre de 32 Ko avec un facteur 3 => 32768 * (2*2*2) = 262.144. Cette valeur sera à appliquer dans le registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters – TcpWindowSize.

Fenêtre TCP(RTT 70ms)
Débit théoriqueen Mb/s
Débit réalisteen Mb/s
8 Kb 0.9 0.8
16 Kb 1.9 1.8
32 Kb 3.7 2-3.5
64 Kb 7.5 3-7
128 Kb 15 6-14
256 Kb 30 10-25
512 Kb 60 20-40
1 Mb 120 30-60

Le facteur d’échelle se trouve par le biais d’un analyse de trame et correspond à TCP: Window Scale Option – TCP: Option Type = Window Scale – TCP: Option Length = 3 (0×3) – TCP: Window Scale = 3 (0×3). Plus d’informations ici.

3.4. Meilleure estimation RTT ou latence

TCP utilise le temps RTT pour faire une estimation de la durée nécessaire pour une communication de boucle entre un émetteur et un récepteur. Les serveurs fonctionnant sous Windows Server 2003 prennent en charge l’utilisation de l’option horodatage TCP de la RFC 1323 pour améliorer l’estimation RTT. En calculant plus souvent des informations RTT plus précises, TCP utilise de meilleures estimations pour définir la retransmission des temporisateurs, ce qui permet d’améliorer la vitesse et les performances TCP globales.

Les améliorations apportées à l’estimation RTT sont très utiles pour les liens plus longs de réseau en boucle, comme les réseaux étendus qui s’étendent sur les continents ou qui utilisent des liens de communication sans fil ou par satellite.

A noter que la taille de la fenêtre TCP est ajustée à quatre fois la taille MSS (MSS, Maximum Segment Size), jusqu’à une taille maximale de 64 K, à moins que l’option de mise à l’échelle de la fenêtre (RFC 1323) ne soit utilisée, d’où sont intérêt !

Par défaut, les ordinateurs exécutant des systèmes d’exploitation Windows Server 2003 n’acceptent, pour l’option horodatage TCP, que les requêtes émises par les clients des ordinateurs TCP1323Opts auxquels ils sont connectés. Les ordinateurs TCP1323Opts déposent des requêtes pour l’option horodatage TCP au cours de la poignée de mains en trois temps. Si vous voulez que votre ordinateur fasse des demandes d’horodatage TCP, vous devez activer TCP1323Opts dans le Registre. Pour plus d’informations sur l’horodatage TCP, voir la RFC 1323, « TCP Extensions for High Performance ».

Voici quelques liens et leur valeurs pratiques et théoriques. Généralement, on retire 30% pour obtenir une valeur réaliste.

Type de lien Mb/s GB/h en théorie
T1 1.536 0.66
LAN 100 43.95
OC3 155 68.12

Ce site est excellent, il permet de calculer les temps de transferts, etc… pour un débit => https://toolstud.io/data/bandwidth.php?speed=4&unit=Mbpshttp://web.forret.com/tools/bandwidth.asp?speed=4&unit=Mbps

Prenons un exemple, vous devez sauvegarder 200 Go et vous disposez d’une liaison 4 Mbps. En théorie, cette liaison peut transmettre (théoriquement) 1.8 Go par heure, soit 200 / 1.8 = 111.11 heures pour transférer les données soit presque 5 jours ! Donc envoyer une cartouche de sauvegarde à l’autre bout du monde prendra moins et coûtera largement moins cher qu’acheter une liaison d’un débit plus important !

Prenons un autre exemple, 9 heures de travail génèrent 20 Go de données (ROC – Rate Of Change) et vous disposez d’une fenêtre de 24 heures – 9 heures de travail soit 15 heures disponibles pour réaliser la sauvegarde, soit au minimum 20 Go/ 15 heures = 1.33 Go/heure donc une ligne de 3 Mbps suffit pour atteindre l’objectif !

Il est important de connaitre le ROC et la fenêtre de sauvegarde disponible concernant les données à sauvegarder et/ou répliquer, bien entendu tout ceci est  directement influencé par le RPO ! Il est donc très important de définir une criticité des applicatifs par ordre d’importance – critique: AD, DNS, CRM – important: Sharepoint, … – peu important: archive, … – Il convient également de faire attention au type de serveur à prendre en compte, un serveur Exchange représente, par exemple 2 partitions, une système et l’autre contenant les fichiers EDB, c’est à dire qu’il est nécessaire de sauvegarder régulièrement les EDB, et moins souvent le système, en excluant par exemple le SWAP, les temps, … Le cas de la VDI est plus complexe, car il faut sauvegarder les profiles, cache web, … Pour un serveur Oracle, une réplication du redo log peut s’avérer suffisant !

3.5. Conclusion

Pour conclure, la réplication de données inter-sites et les éventuelles problèmes de performances associés ne se résolvent pas uniquement en louant une liaison plus importante, il est important de:

  • Définir un niveau de criticité des applications et données à protéger
  • Analyser et réaliser un tuning TCP de vos liaisons
  • Mettre en oeuvre des appliances d’accélération WAN
  • Analyser, au niveau serveur, ce qu’il est nécessaire de sauvegarder
  • Connaitre sa fenêtre de sauvegarde et son ROC (par application, ….)
  • Dans le cadre de PRA (réplication de VM en asynchrone, …), prioriser les flux (QoS, …)

4. La sauvegarde

Mettre en œuvre une sauvegarde est indispensable pour plusieurs raisons: externaliser les données, restaurer un système complet, récupérer un document, … La situation idéale serait de ne perdre aucune donnée (valeur RPO proche de zéro) et d’avoir un arrêt de production le plus court possible (valeur RTO le plus proche possible de zéro). Des systèmes de réplication ou de sauvegarde continue, de basculement ou de reprise automatique répondent à ces problématiques.

Depuis quelques années, les volumes à sauvegarder sont de plus en plus importants, on parle maintenant de plusieurs To (Téraoctets). Les temps de sauvegarde sont donc importants, et automatiquement la restauration également. Plus le temps de restauration est long, plus l’arrêt de production est important et impactera financièrement l’entreprise.

Il ne faut jamais négliger la sauvegarde à cause de considérations financières. Le coût d’une centaine de salariés au chômage technique, de pertes de transactions commerciales, d’une image de marque écornée, sera certainement supérieur à celui d’un dispositif de sauvegarde. Certains cabinets d’études statistiques mettent en avant le constat suivant: « une entreprise sur deux fermera ces portes dans les deux années à venir consécutif à un sinistre ayant entrainé une perte de données majeure ».

Une notion importante à ne pas négliger dans le monde de la sauvegarde est la Data Protection Windows (DPW) qui correspond au temps dont on dispose pour réaliser une sauvegarde consistante des données. En effet, si votre chaine de production ne s’arrête jamais, la DPW est nulle, et il faudra alors analyser des solutions telles que le CDP, réplication, …

Nous avons vu que certaines techniques comme les snapshots sont capables de réaliser une sauvegarde consistante. Si votre DPW est nul, mais qu’il vous est impératif de sauvegarder, les agents d’un logiciel de sauvegarde pourront réaliser une sauvegarde à chaud.

L’exemple le plus courant dans le monde Windows est l’agent de type Open Files (fichiers ouverts). En effet, si vous n’utilisez pas les clichés instantanés et que vous désirez sauvegarder un fichier ouvert, la sauvegarde n’en sera pas capable. Il faut avoir recourt à cet agent, spécialisé dans la sauvegarde à chaud de fichiers ouverts. Selon les logiciels de sauvegarde, les éditeurs disposent d’un catalogue plus ou moins étoffé d’agents disponibles pour des bases de données comme Oracle, DB2, etc…. Avant de choisir un logiciel de sauvegarde, assurez-vous qu’il est possible d’acquérir un agent spécifique pour votre applicatif.

Néanmoins en environnement virtualisé, la plupart des éditeurs commercialisent des agents spécifiques ou reposent sur les API des hyperviseurs. Ainsi, l’agent est capable non seulement de sauvegarder à chaud l’intégralité de la machine virtuelle mais également son contenu. Ainsi il est possible de restaurer l’intégralité d’une machine virtuelle à son emplacement d’origine ou sur un autre serveur, pour répondre à une problématique de RTO ou simplement de restaurer un fichier d’une machine virtuelle.

L’agent spécialisé dans la virtualisation permet d’économiser de l’argent car il intègre une « sorte » d’agent Open Files mais nécessite toujours des agents spécialisés pour Microsoft Exchange, par exemple. Des applications de sauvegarde dédiées à la sauvegarde d’hyperviseurs existent comme Veeam Backup, ou vRanger de VizionCore.

Comment calculer la fenêtre d’une sauvegarde, comment estimer l’espace de ma stratégie de sauvegarde, …. ? Autant de questions auxquelles les infrastructures de stockage de type SAN répondront. En effet, les stockages SAN nécessitent un réseau qui leur est propre et indépendant et surtout isolé du réseau de production. Abordé dans le chapitre C.1.C, l’environnement idéal d’une sauvegarde dans un environnement SAN est de créer un réseau dédié ou une zone afin de séparer les différents flux.

Calcul de taille d’une sauvegarde d’une machine virtuelle:

Taille de la sauvegarde = espace disque utilisé + mémoire vive (prévoir une marge de 10 %)

Calcul de taille d’une sauvegarde d’une machine virtuelle avec des clichés:

Taille de la sauvegarde = espace disque utilisé + mémoire vive + taille totale des clichés (prévoir une marge de 10 %)

Calcul de la taille d’une sauvegarde complète

Taille de la sauvegarde = espace disque utilisé * nombre de jours de rétention

Calcul de la taille d’une sauvegarde complète et incrémentale:

Taille de la sauvegarde = (espace disque utilisé * nombre de jours de rétention) + ((espace disque utilisé * taux de changement) * nombre de sauvegarde d’incrémentale)

Prenons l’exemple d’une librairie qui dispose des caractéristiques suivantes: un débit LTO4-HH théorique natif de 2.16 To/heure avec 3 lecteurs et de 4.32 To/heure. Le débit réaliste d’un lecteur LTO-4 est de 120 MB/s et dispose d’une capacité native de 800 Go sans compression. Nous devons sauvegarder 12 To d’un SAN en fibre optique et 1 To via un réseau Ethernet Gigabit.

La bande passante de la fibre optique 4 Gb est de 800 MB/s (en full duplex) soit 2.88 To par heure, donc dans notre exemple, le flux de sauvegarde ne saturera pas le réseau de stockage fibre optique. Le temps estimé sera de 12 To / 2.16 To/heure soit 25.92 heures en natif  sans compression.

Pour sauvegarder 1 To (1000 Go) en Gigabit, la bande passante théorique est de 125 MB/s soit 450 Go/heure, mais partons plutôt sur un débit réaliste de 70 % soit environ 87.5 Mo/s ou encore 315 Go / heure. Le temps estimé de la sauvegarde par ce média sera de 1000 Go / 315 Go/heure soit 3.17 heures.

Une autre formule, plus réaliste que je vous recommande, tient compte des changements de cartouches au sein de la librairie:

Taille de la sauvegarde en Mo / débit de la sauvegarde en Mo/sec / 60 / 60 + (temps de changement  de cartouche en minute(s) * nombre de cartouches utilisées)

Détail du calcul:

12000000 / 120 / 60 / 60 + (2 * (12000 Go / 800 Go)) soit 28h30 environ.

Alors que les lecteurs actuels dépassent le débit réalisable par les disques durs, leurs performances sont considérablement ralenties lors d’opérations de restauration dues aux opérations de chargement de la bande, de positionnement, … En réalité, les restaurations effectuées à partir de disques durs peuvent être de deux à dix fois plus rapide !

Le schéma suivant synthétise le découpage des temps d’un lecteur de bande pendant une opération de restauration. Le temps où le lecteur restaure les données ne représente que 8% du temps au total, le lecteur passant la plupart de son temps à des opérations non productives de chargement de média, de localisation des données sur la bande, ….

Si les disques accélèrent les temps de sauvegarde et de restauration, n’utiliser que ce média comporte des risques. La sauvegarde étant stockée sur un serveur relié au réseau, les données sont vulnérables aux virus, pannes disques, sinistre, … de plus, il sera très difficile de l’externaliser.

La sauvegarde disque doit être employée dans une stratégie disk-to-disk-to-tape (disque vers disque puis sur bande ou D2D2T), pour diminuer les temps de restauration et de sauvegarde ou lorsque celle-ci doit être déportée sur un autre site.

Bien entendu, les disques servant à héberger la sauvegarde peuvent être de type SATA à 7.200 tours par minutes, le flux étant séquentiel, ce type de disque correspond tout à fait à cet usage. Bien logiquement, la sauvegarde sur bande prends plus de temps qu’une sauvegarde sur disque, mais les clichés est la technique, à ce jour, qui dispose de la fenêtre la plus courte.

Les administrateurs de sauvegarde s’aperçoivent que la plupart des demandes de restauration concernent des données vieilles de 24 à 48 heures. La sauvegarde sur disque prend toute sa dimension dans ce cas de figure en adoptant la stratégie d’une rétention de 72 heures sur disque et au-delà un stockage sur bande.

On parle alors de Virtual Tape Library (VTL) qui sont en fait des Appliances dédiées aux opérations de sauvegarde sur disque qui émulent des lecteurs de bande de façon transparente pour les logiciels de sauvegarde.

L’avantage évident des Appliances VTL réside dans le fait qu’elles s’insèrent dans des environnements de librairies déjà en place sans remettre en cause la politique de sauvegarde et des investissements déjà réalisés. Techniquement les VTL permettent une augmentation des débits, une diminution des fenêtres de sauvegarde et du RTO tout en conservant une possibilité d’évolution de la capacité de sauvegarde par l’ajout de disques durs supplémentaires.

Il est possible de répliquer le contenu d’une VTL sur un autre site et bien entendu d’y adjoindre une solution de déduplication.

Partagez si ça vous plait !
0 0 votes
Évaluation de l'article
S’abonner
Notification pour
guest

0 Commentaires
Commentaires en ligne
Afficher tous les commentaires
0
Nous aimerions avoir votre avis, veuillez laisser un commentaire.x