Architecture de synchronisation active SnapMirror
Suggérer des modifications
PDF
Grâce à l'architecture de synchronisation active SnapMirror, les charges de travail actives peuvent être traitées simultanément depuis les deux clusters afin de traiter les charges de travail principales. Dans certains pays, la réglementation applicable aux institutions financières exige également la maintenance périodique des entreprises à partir de leurs data centers secondaires. Les déploiements « Tick-Tock » sont également pris en charge par la synchronisation active SnapMirror.
La relation de protection des données à protéger pour la continuité de l'activité est créée entre le système de stockage source et le système de stockage de destination, en ajoutant au groupe de cohérence des LUN spécifiques à l'application provenant de différents volumes d'une machine virtuelle de stockage (SVM). Dans des conditions normales, l'application d'entreprise écrit sur le groupe de cohérence principal, qui réplique ces E/S de manière synchrone sur le groupe de cohérence du miroir.
Bien qu'il existe deux copies distinctes des données dans la relation de protection des données, étant donné que la synchronisation active SnapMirror conserve la même identité de LUN, l'hôte d'application la considère comme un périphérique virtuel partagé avec plusieurs chemins d'accès, alors qu'une seule copie de LUN est en cours d'écriture à la fois. Lorsqu'une panne met le système de stockage principal hors ligne, ONTAP détecte cette défaillance et utilise le médiateur pour la reconfirmation. Si ni ONTAP ni le médiateur ne peuvent envoyer d'requête ping au site principal, ONTAP effectue l'opération de basculement automatique. Ce processus entraîne le basculement d'une application spécifique uniquement, sans intervention manuelle ni script nécessaire auparavant pour le basculement.
Autres points à prendre en compte :
-
Les volumes sans miroir qui sont en dehors de la protection pour la continuité de l'activité sont pris en charge.
-
Une seule autre relation SnapMirror asynchrone est prise en charge pour les volumes protégés pour la continuité de l'activité.
-
Les topologies en cascade ne sont pas prises en charge avec la protection pour la continuité de l'activité.
Médiateur de ONTAP
ONTAP Mediator est installé dans un troisième domaine de défaillance, distinct des deux clusters ONTAP. Son rôle principal est de servir de témoin passif des copies actives de synchronisation SnapMirror. En cas de partition réseau ou d'indisponibilité d'une copie, le système SnapMirror Active Sync utilise Mediator pour déterminer quelle copie continue à transmettre les E/S, tout en interrompt les E/S sur l'autre copie. Cette configuration comprend trois composants clés :
-
Cluster ONTAP principal hébergeant le groupe de cohérence principal de synchronisation active SnapMirror
-
Cluster ONTAP secondaire hébergeant le groupe de cohérence miroir
-
Médiateur de ONTAP
Le médiateur ONTAP joue un rôle crucial dans les configurations de synchronisation active SnapMirror en tant que témoin de quorum passif. Il assure la maintenance du quorum et facilite l'accès aux données en cas de défaillance. Il agit comme un proxy ping pour les contrôleurs afin de déterminer la vivacité des contrôleurs homologues. Bien que le Mediator ne déclenche pas activement les opérations de basculement, il fournit une fonction essentielle en permettant au nœud survivant de vérifier l'état de son partenaire pendant les problèmes de communication réseau. Dans son rôle de témoin de quorum, le médiateur ONTAP fournit un chemin alternatif (servant effectivement de proxy) au cluster homologue.
De plus, il permet aux clusters d'obtenir ces informations dans le cadre du processus de quorum. Il utilise la LIF node management et la LIF cluster management à des fins de communication. Il établit des connexions redondantes via plusieurs chemins afin de différencier les pannes de site et les défaillances de liaison ISL (interswitch Link). Lorsqu'un cluster perd la connexion avec le logiciel ONTAP Mediator et tous ses nœuds en raison d'un événement, il est considéré comme inaccessible. Cela déclenche une alerte et permet un basculement automatique vers le groupe de cohérence du miroir (CG) sur le site secondaire, ce qui garantit une continuité d'E/S pour le client. Le chemin d'accès aux données de réplication repose sur un mécanisme de pulsation. Si un problème de réseau ou un événement persiste au-delà d'une certaine période, cela peut entraîner des défaillances de pulsation, ce qui entraîne une désynchronisation de la relation. Toutefois, la présence de chemins redondants, comme le basculement de LIF vers un autre port, peut maintenir le signal de détection et éviter de telles perturbations.
Pour résumer, le médiateur ONTAP est utilisé aux fins suivantes :
-
Établir un quorum
-
Disponibilité continue via basculement automatique (AUFO)
-
Basculements planifiés (PFO)
|
ONTAP Mediator 1.7 peut gérer dix paires de clusters à des fins de continuité de l'activité. |
|
|
Lorsque le médiateur ONTAP n'est pas disponible, vous ne pouvez pas effectuer de basculements planifiés ou automatisés. La réplication synchrone des données d'application se poursuit sans interruption sur et sans aucune perte de données. |
Exploitation
La figure suivante illustre la conception générale de la synchronisation active SnapMirror.
Le schéma représente une application d'entreprise hébergée sur une machine virtuelle de stockage (SVM) au niveau du data Center principal. La SVM contient cinq volumes, dont trois font partie d'un groupe de cohérence. Les trois volumes du groupe de cohérence sont mis en miroir sur un data Center secondaire. Dans des circonstances normales, toutes les opérations d'écriture sont effectuées sur le data Center principal. Dans les faits, ce data Center sert de source pour les opérations d'E/S, tandis que le data Center secondaire sert de destination.
En cas d'incident au niveau du data Center principal, ONTAP charge le data Center secondaire d'agir comme le data Center principal, et de traiter toutes les opérations d'E/S. Seuls les volumes mis en miroir dans le groupe de cohérence sont gérés. Toutes les opérations relatives aux deux autres volumes du SVM sont affectées par le sinistre.
Symétrie actif-actif
SnapMirror Active Sync offre des solutions asymétriques.
Dans les configurations asymétriques, la copie de stockage primaire expose un chemin optimisé pour le mode actif et traite activement les E/S du client Le site secondaire utilise un chemin distant pour les E/S. Les chemins de stockage du site secondaire sont considérés comme actifs-non optimisés. L'accès à la LUN d'écriture est proxy depuis le site secondaire.
Dans les configurations active/active symétriques, les chemins optimisés pour le mode actif sont exposés sur les deux sites, sont spécifiques à l'hôte et sont configurables. Ainsi, les hôtes de chaque côté peuvent accéder au stockage local pour les E/S actives
Le mode actif-actif symétrique est destiné aux applications en cluster, notamment VMware Metro Storage Cluster, Oracle RAC et Windows Failover Clustering avec SQL.