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.

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é.

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.

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.

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.

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.

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

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.

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:

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.

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.

Cédric GEORGEOT [MVP]

Je travaille actuellement en tant qu’Enterprise Architect pour le groupe CAPGEMINI. Acteur et expert communautaire reconnu depuis de nombreuses années, j’anime ce site autour des technologies Microsoft, des thématiques du Cloud, des infrastructures, … Je suis également à l’origine de nombreuses publications dans la presse IT.