Comment mettre en place la réplication matérielle ?

Nous allons explorer les technologies de réplication matérielle (mirroring) d’IBM, puis nous verrons comment mettre en place la réplication matérielle sur un système IBM i, enfin, nous examinerons l’usage des pools de stockage auxiliaires indépendants (independent auxiliary storage pools, IASP) et de Flash Copy comme outils de haute disponibilité (high-availability, HA) et de reprise après sinistre.

Global Mirror et Metro Mirror

IBM offre deux techniques de réplication matérielle pour le stockage externe : Global Mirror et Metro Mirror. Global Mirror, une méthode asynchrone, est probablement la plus fréquente des deux. Avec Global Mirror, un système local attaché à un système de stockage externe voit ses changements envoyés de manière asynchrone à un système à distance, lui aussi attaché à un système de stockage externe. Le système principal n’est pas conscient de ce qui se passe : c’est un échange entre disques externes. Et donc les applications sont isolées du mécanisme de réplication sous-jacent. Les changements sont asynchrones : le disque externe primaire envoie ses changements, puis continue à fonctionner sans attendre aucun accusé de réception.

Comment mettre en place la réplication matérielle ?

Bien entendu, le temps de latence est proportionnel à la distance entre les systèmes. De plus, comme Global Mirror est asynchrone, des changements peuvent se perdre en route. Pour pallier ce risque, une seconde copie du disque se trouve sur le système à distance. Des copies flash périodiques (nous reviendrons sur Flash Copy un peu plus loin) sont faites sur cette seconde copie, pour que le système disque puisse vérifier la cohérence de la copie des données en vue de la reprise après sinistre. En outre, il peut y avoir une autre copie juste pour tester le degré de préparation à la reprise après sinistre (une copie d’exercice).

Ce qui donne la configuration suivante

•    Copie A : production sur le système local
•    Copie B : copie pour reprise après sinistre sur le système à distance
•    Copie C : copie pour vérifier la cohérence sur le système à distance
•    Copie D : copie d’exercice sur le système à distance

Par ailleurs, il y aura probablement une copie B et C (et peut-être même D) sur le système local, de sorte que la réplication se poursuive en cas d’échec sur le système de reprise après sinistre/HA (cela servirait principalement aux tests de reprise après sinistre et de haute disponibilité, car en cas de vraie catastrophe on présume que le système local sera hors service.)

On s’en doute, toutes ces copies consomment beaucoup de disque ! Ainsi, si vous avez des copies A, B, C et D sur les deux systèmes, c’est sept fois l’espace disque de votre seul système de production. Le bon côté est que la ligne de communication entre les deux systèmes ne doit pas être aussi bonne que pour l’option synchrone de Metro Mirror. Par conséquent, elle peut être moins chère et couvrir de plus longues distances entre les systèmes (le maximum de Metro Mirror est généralement estimé inférieur à 300km). Mais si votre dispositif de reprise après sinistre demande que le système de secours se trouve en un lieu géographique différent (par exemple les côtes Est et Ouest des États-Unis), Global Mirror est la seule possibilité.

Metro Mirror et Global Mirror

Avec Metro Mirror et Global Mirror, la copie B n’est pas utilisable en mode production. Contrairement à la réplication logicielle, où vous pouvez accéder au système de reprise après sinistre et même y utiliser les données, ce système est ici « verrouillé ». Vous pouvez vous connecter à ce système (comme nous le verrons plus loin), mais les données qui sont répliquées à partir de la production ne seront disponibles sur ce système qu’après basculement. Lors d’un basculement planifié, vous arrêtez la copie de production et amenez la copie B. Aussitôt, la réplication s’effectue en sens inverse de la copie B vers la copie de production. En cas de panne soudaine, la copie de production est présumée indisponible, et donc B est amené sans réplication (sauf en cas de cibles multiples, c’est-à-dire une copie de production se répliquant sur plus d’une copie B).

Metro Mirror demande moins d’espace disque parce qu’il n’emploie qu’une copie A et B. Les changements apportés au disque sont répliqués en mode synchrone : le disque primaire envoie un changement au système à distance, où il est écrit dans la copie B, et n’engage le changement local qu’après réception d’une confirmation de la part du système secondaire distant.

Selon la distance entre les sites, cette procédure peut améliorer sensiblement les temps de réponse disque. Compte tenu de la manière dont l’IBM i traite les écritures sur disque, cela n’est pas aussi grave qu’il y paraît. Tous les processus sur l’IBM i n’attendent pas une confirmation d’écriture sur disque complète avant de continuer. Cependant, le temps nécessaire pour que le changement parvienne au système à distance et que la confirmation revienne, s’ajoute à chaque opération disque. Le temps d’aller-retour des transactions entre les sites devient partie intégrante du temps de fonctionnement minimum du sous-système disque.

Si la distance entre les sites est suffisamment courte pour permettre Metro Mirror et si vous pouvez vous offrir la ligne de communications dédiée requise, vous bénéficierez alors d’une solution qui aura probablement un bien meilleur point (et temps) de reprise. Plus il y a de secteurs disques synchronisés, moins il faut de temps pour mettre en route le système à distance.