Exigences de la solution de reprise après sinistre

des bandes d’un lieu distant, ce qui signifie généralement des heures ou des jours avant la restauration complète. En outre, toutes les mises à jour de données effectuées depuis la dernière sauvegarde sur bande, seront manquantes. Bien sûr, dans certains cas, vous pourrez restaurer manuellement les transactions perdues. Malheureusement, compte tenu du volume croissant de transactions dans l’entreprise moderne, cette façon de faire est de moins en moins satisfaisante.

Ce problème peut être résolu par le pur miroir synchrone : chaque transaction effectuée entre le serveur principal et le serveur de secours, est répliquée sur-le-champ. Ce procédé garde les copies de données primaires et secondaires en lien étroit avec l’état de l’application, comme le miroir disque sur un système unique. Cette méthode est satisfaisante dans un datacenter ou dans un campus, mais, sur de plus longues distances, il n’est pas question de miroir synchrone entre des datacenter dispersés géographiquement. Quand la distance augmente, le temps de réponse de l’application s’allonge, jusqu’à devenir inacceptable. Ici, la vitesse de la lumière n’est pas le facteur limitant : c’est la vitesse de la lumière dans la fibre de verre, environ d’un tiers plus lente que sous vide, plus la latence due aux éléments de routage du réseau. Soit une distance maximale pour la réplication d’environ 40 km. Certaines applications peuvent tolérer deux ou trois fois cette latence et, avec la généralisation de la commutation optique, cette limite reculera, mais pas au point d’accepter des milliers de kilomètres entre les datacenter DR.

La seule solution pratique pour la réplication sur des distances appropriées à la reprise après sinistre, est le miroir asynchrone entre les clusters primaire et secondaire ou le miroir en cluster, dans lequel la réplication des données se produit à la vitesse permise par le réseau. Le RPO passe alors de zéro à quelques minutes, souvent suffisantes pour de nombreuses applications.

Diverses solutions

Dans une topologie cluster PowerHA, la résilience des données peut être obtenue de deux manières : miroir basé sur l’hôte et miroir basé sur le stockage (SAN). Une solution de réplication basée sur l’hôte, comme son nom l’indique, exécute le service miroir HA à partir du noeud du serveur qui héberge l’application et les données de production. Si le noeud de production est immobilisé, le service de réplication l’est aussi. À l’inverse, un service de réplication basée sur le stockage conduit la réplication des données entre deux serveurs de stockage, pour le compte du noeud hôte ou primaire dans le cluster. Si, par exemple, le noeud de production est inopérant, la réplication du serveur de stockage est configurée avec PowerHA de manière à inverser et à reprendre le service de réplication pour le noeud de production qui a pris à son compte la production.