Utilisation de plans de récupération après sinistre

A propos des opérations de récupération après sinistre et des plans par défaut

Le service de récupération après sinistre natif fournit aux plans des étapes par défaut pour chaque type d'opération. Les étapes de plan de récupération après sinistre peuvent être personnalisées. Les protocoles intégrés sont configurés comme suit :

Plan de permutation

Lorsqu'une permutation est effectuée, il n'y a pas de panne, de sorte que les deux systèmes appairés sont en ligne. L'objectif est de déplacer toutes les ressources couvertes par la configuration DR du système principal (A) vers le système de secours (B). Une fois terminé, le système B devient le système principal et le système A le système de secours pour les ressources en question.

Le plan commence par des prévérifications afin de s'assurer que les deux systèmes répondent aux exigences pour permettre l'arrêt des instances de calcul sur le système principal et le redémarrage sur le système de secours. Les prévérifications incluent les mappages de site ainsi que d'autres éléments critiques, tels que les balises, les listes de sécurité ou les groupes de sécurité réseau. La prévérification de l'inversion de rôle garantit spécifiquement que l'état de ZFS Storage Appliance dans chaque rack est correct.

Lorsque les prévérifications sont terminées sans erreur, la configuration de récupération après sinistre sur le système principal (A) est gelée et ses instances de calcul sont arrêtées, de sorte que la contrepassation du rôle peut commencer. Sur la base des métadonnées de ressource échangées entre les systèmes appairés et des données répliquées sur le système ZFS Storage Appliance de secours, le système cible (B) est prêt à prendre le rôle principal pour les instances dans la configuration de récupération après sinistre. Le processus de réplication est inversé et prêt à utiliser le système source (A) comme système de secours dès que la permutation est terminée.

A l'aide des volumes répliqués, les instances de calcul de la configuration de récupération après sinistre sont lancées sur le système de secours (B). Une configuration DR identique est créée sur le système de secours, toutes les ressources source et cible des mappages de site étant inversées. Les métadonnées des instances nouvellement lancées sont stockées dans la configuration de récupération après sinistre. Sur le système principal (A), un nettoyage est effectué : la configuration de récupération après sinistre est désactivée et ses instances de calcul prennent fin.

Pour terminer la permutation, la réplication de données du nouveau système principal (B) vers le système de secours (A) est démarrée, les plans de récupération après sinistre sont déplacés vers le nouveau système de secours (A), et le projet de stockage et les métadonnées associés à la configuration de récupération après sinistre d'origine sont supprimés du système A.

Plan de basculement

Un basculement est effectué sur le système de secours lorsque l'un des systèmes appairés tombe en panne. L'objectif est de récupérer toutes les ressources couvertes par la configuration de récupération après sinistre sur le système de secours (B), ce qui permet la poursuite du service. Les étapes de basculement sont similaires au plan de permutation, mais aucune des opérations sur le système principal (A) ne peut être effectuée. Le système principal ne peut pas être nettoyé tant qu'il n'est pas remis en ligne.

Le plan commence par des prévérifications afin de s'assurer que le système de secours et ses ZFS Storage Appliance sont dans l'état correct pour afficher les ressources couvertes dans la configuration de récupération après sinistre. Lorsque les prévérifications sont terminées sans erreur, la contrepassation du rôle commence.

A l'aide des ressources et métadonnées répliquées, les instances de calcul de la configuration de récupération après sinistre sont lancées sur le système de secours (B), qui assume le rôle principal. Une configuration de récupération après sinistre identique est créée sur le système B, qui est devenu le système principal, avec des mappages de site inversés et des métadonnées collectées à partir des instances nouvellement lancées. En préparation de la remise en ligne du système principal d'origine (A), le processus de réplication est inversé et prêt à utiliser le système A en tant que système de secours.

Lorsque le système principal d'origine (A) finit par être en ligne, les étapes restantes pour rétablir la configuration de récupération après sinistre à un état de fonctionnement correct sont effectuées en exécutant le plan de post-basculement.

Plan de post-basculement

Un plan post-basculement est effectué après un basculement, lorsque le système qui a subi une panne revient en ligne et que la connexion homologue est restaurée. L'objectif est de nettoyer la configuration de récupération après sinistre sur le système principal en panne (A) et de la configurer en tant que base de secours pour le nouveau système principal (B).

Aucun pré-vérifications n'existe dans un plan de post-basculement. Le système A est de nouveau en ligne après une panne et doit être nettoyé : la configuration de récupération après sinistre est désactivée et ses instances de calcul sont arrêtées. La réplication des données du nouveau système principal (B) vers le système de secours (A) est démarrée, les plans de récupération après sinistre sont déplacés vers le nouveau système de secours (A), et le projet de stockage et les métadonnées associés à la configuration de récupération après sinistre d'origine sont supprimés du système A.

Pour déplacer les ressources initialement hébergées sur le système A du système B, l'administrateur doit effectuer une permutation de B vers A pour les configurations DR appropriées.