Répliquez le groupe, pas le disque : la cohérence dans la réplication de baies

La réplication de baies ressemble à la forme la plus simple de disaster recovery : la baie copie vos disques vers une autre baie dans un autre datacenter, et rien à l'intérieur de vos serveurs n'a à changer. C'est effectivement aussi simple, à condition de répliquer ensemble les bonnes choses. Répliquez chaque volume isolément et vous pouvez vous retrouver avec une copie parfaite de chaque disque et une base de données qui refuse de démarrer.

Une copie de chaque disque n'est pas une copie de l'application

La plupart des applications sérieuses écrivent sur plus d'un volume. Une base de données garde ses fichiers de données sur un disque et son journal de transactions sur un autre. Un serveur de messagerie sépare le stockage des messages de ses journaux. Une machine virtuelle peut avoir un disque système et un disque de données qui n'ont de sens qu'ensemble.

Ces applications dépendent de l'ordre des écritures. La base écrit d'abord l'enregistrement du journal, puis la page de données, et à la reprise elle rejoue le journal pour amener les fichiers de données à un point cohérent. Si la copie du volume du journal sur le site distant est de quelques secondes plus ancienne que la copie du volume de données, le site distant détient des pages de données qui renvoient à des enregistrements de journal qui n'y existent pas. La base voit un état impossible. Au mieux elle se rétablit avec du travail. Au pire elle ne s'ouvre pas.

Quand chaque volume se réplique indépendamment, chaque copie avance à son propre rythme, de sorte que les disques distants ne sont presque jamais au même instant. La réponse est un consistency group : un ensemble de volumes que la baie réplique comme une seule unité, en préservant l'ordre des écritures sur tous. Sur HPE 3PAR, c'est un Remote Copy group. D'autres baies ont leur propre nom pour la même idée. Quel que soit le nom, la règle est la même. Tout ce dont une application a besoin pour démarrer va dans un seul groupe.

Choisir ce qui entre dans un groupe

Partez de l'application, pas de la liste des volumes :

• Listez chaque volume sur lequel l'application écrit, y compris ceux qu'on oublie facilement : le volume qui porte l'archive du binary log ou du write-ahead log, un tablespace temporaire séparé, un disque de configuration.
• Mettez-les tous dans un seul groupe.
• Gardez les applications sans lien entre elles dans des groupes séparés, pour que l'une puisse basculer, être testée ou mise en pause sans toucher à l'autre.

Décidez ensuite à quelle distance la copie suit l'original.

À quelle distance la copie doit-elle être ?

Il existe deux grandes familles de modes de réplication, et le choix tient autant à la physique qu'à la préférence.

Le synchrone garde la copie à jour au prix d'un aller-retour à chaque écriture, faible à distance métropolitaine et mesurable entre pays. L'asynchrone tourne à la vitesse locale et le retard est votre point de reprise.

Aucun des deux n'est juste en général. Un système transactionnel dont la dernière minute de commandes a de la valeur peut justifier la latence d'écriture. Une plateforme de contenu qui peut perdre quelques minutes de modifications, en général non. La bonne réponse vient en demandant ce que la perte de cet écart coûterait à l'entreprise, puis en mesurant si l'application tolère la latence du mode le plus strict.

Gardez la réplication hors du chemin de production

Le trafic de réplication concurrence les I/O des hôtes si vous le laissez faire. Donnez-lui des ports de baie dédiés, gardez ces ports à l'écart de ceux que les hôtes utilisent, et limitez chaque lien de réplication à un seul partenaire. Surveillez le retard de réplication, pas seulement l'état du lien. Un lien actif pendant que la copie prend du retard d'heure en heure est le mode de défaillance qui transforme un plan de disaster recovery en surprise.

Testez le réplica sans le casser

Un réplica qui n'a jamais été démarré est un espoir. La bonne nouvelle est que vous pouvez le tester sans interrompre la réplication :

1. Prenez un snapshot à un instant donné des volumes secondaires du groupe sur la baie distante. Prenez le snapshot de tout le groupe à la fois, pour que la copie de test soit aussi cohérente que le réplica.
2. Présentez les snapshots à un hôte de test isolé sur le site distant. Gardez cet hôte hors du réseau de production, pour que la copie ne puisse pas répondre à du vrai trafic, envoyer de vrais e-mails ou lancer des tâches planifiées contre de vrais systèmes.
3. Démarrez l'application exactement comme vous le feriez lors d'un sinistre, avec votre runbook écrit et rien d'autre.
4. Vérifiez-la au niveau de l'application : la base s'ouvre et passe son propre contrôle de cohérence, les nombres de lignes et les enregistrements les plus récents sont là où le point de reprise dit qu'ils doivent être, et une connexion utilisateur à l'application fonctionne.
5. Chronométrez, de la décision de basculer à la première transaction réussie. Ce chiffre est votre vrai temps de reprise, quoi que dise le plan.
6. Supprimez les snapshots et consignez le résultat, y compris tout ce qui vous a surpris.

Lancez le test après tout changement du groupe, et selon un calendrier régulier même quand rien n'a changé, parce que les applications ajoutent des volumes en silence.

La réplication n'est pas un backup

La réplication copie fidèlement les changements, et cela inclut une table supprimée, un chiffrement par ransomware et un mauvais déploiement. En quelques secondes ou minutes, l'erreur est aux deux endroits. Un réplica vous protège de la perte d'un site. Des backups avec historique vous protègent de vos propres données. Il vous faut les deux, et les backups doivent être tirés par un système que le côté production ne peut pas atteindre.

Comment nous le faisons

Entre nos datacenters d'Athènes et d'Amsterdam, les volumes des clients peuvent se répliquer de baie à baie sur HPE 3PAR, les volumes liés étant placés dans le même Remote Copy group pour rester cohérents entre eux. Le mode de réplication est convenu par service, la réplication tourne sur des ports dédiés, un partenaire par paire de ports, sur notre propre interconnexion privée entre les sites, et les réplicas de données hébergées dans l'UE restent dans notre infrastructure dans l'UE. Au sein de chaque site, les baies sont en fédération, de sorte que les volumes se déplacent aussi entre baies à chaud. Les backups se trouvent à côté, séparés et pull-only.

Si vous n'êtes pas sûr que votre copie distante démarrerait le jour où vous en aurez besoin, cela vaut la peine de le découvrir un jour calme. Nous vous aidons volontiers à concevoir les groupes et le test.

cta: Parler à un ingénieur

Related

• /what-we-do/storage-compute/storage-replication-federation/
• /what-we-do/storage-compute/disaster-recovery/
• /what-we-do/storage-compute/enterprise-san-storage/