Réplication de données, les bonnes pratiques

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, …

Allez, rentrons un peu dans la technique 😉

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

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 !

Le cas CISCO WAAS / Veeam

Prenons l’exemple concret des apports de Cisco Wide Area Application Services. Cette technologie optimise les performances des applications basées sur TCP. Voici les données: sites reliés en 10 Mb MPLS avec 40 ms de latence (données CISCO/Veeam).

SANS WAAS:

Replica initial — 12.8GB transférés via WAN — Temps total: 3 heures 12min 17sec
Second Replica — 948MB transférés via WAN — Temps total: 23min 45sec

AVEC WAAS:

Replica initial — 4.8GB transférés via WAN — Temps total: 2 heures 22 minutes
Second Replica — 149MB transférés via WAN — Temps total: 11min 21sec

CONCLUSION:

Replica initial — Veeam a transféré 12.8GB, WAAS a optimisé de 4.8GB — Compression totale 62%
Second Replica — Veeam a transféré 901MB, WAAS a optimisé de 149MB — Compression totale 83%

Quelques liens complémentaires:

http://forums.veeam.com/viewtopic.php?f=2&t=2608&start=0#p10774

http://forums.veeam.com/viewtopic.php?f=2&t=2607#p15480

Témoignages

Je suis désolé de faire un peu de pub, mais ces témoignages me semblent tout à fait pertinent à propos d’un retour d’expérience.

Avant, de nombreux clients pensaient que la seule solution adaptée à leur demande croissante était d’ajouter en permanence de la bande passante dans l’espoir de rester en phase avec les besoins de l’entreprise. Un client explique : « Lors du premier déploiement, notre utilisation de la bande passante a chuté. Nous avons pu renégocier nos contrats et nous allons économiser plus de 2 millions de dollars ces deux prochaines années ». En moyenne, les clients interrogés économisent 979 973 $ par an en coûts de bande passante depuis le déploiement de Riverbed Steelhead.

Concernant les bandes de sauvegarde, un client a déclaré : « Nous effectuons des sauvegardes à distance, ce que nous ne pouvions pas faire auparavant. Nous évitons l’utilisation de bandes et le coût de trois ou quatre lecteurs par site. » Certains clients réduisent le nombre de lecteurs de bandes dont ils ont besoin, tandis que d’autres les suppriment complètement : « Nous sommes sur le point d’éliminer tous nos lecteurs de bande et de centraliser nos sauvegardes », annonce un responsable. « Avant, lorsque nous transférions beaucoup de données, nous avions souvent trois ou quatre semaines de retard sur les sauvegardes. Mais depuis le déploiement de Riverbed, il est extrêmement rare que nous ayons plus d’un jour de retard ». Nos économies annuelles sur les bandes, les lecteurs de bande et les sauvegardes à distance sont en moyenne de 84 639 $.

Grandes fenêtres TCP (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.

Calcul de la fenêtre TCP optimale

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 !

Calcul du débit TCP

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.

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.

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 (0x3) – TCP: Window Scale = 3 (0x3).

Plus d’informations ici.

Meilleure estimation RTT ou latence

Ce site est excellent, il permet de calculer les temps de transferts, etc… pour un débit => http://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 !

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, …)

Quelques liens supplémentaires

Livre Windows Server® 2008 TCP/IP Protocols and Services

TCP/IP Registry Values for Microsoft Windows Vista and Windows Server 2008

New Networking Features in Windows Server 2008 and Windows Vista

Réglage automatique de la fenêtre de réception TCP

Next Generation TCP/IP Stack

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.