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

À 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 des plans avec des étapes par défaut pour chaque type d'opération. Les étapes du plan RS peuvent être personnalisées. Les plans intégrés sont configurés comme suit :

Plan de permutation

Lorsqu'une permutation est effectuée, il n'y a aucune interruption, 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 de récupération après sinistre 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 vérifications préalables pour 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 vérifications préalables comprennent les mappages de site ainsi que d'autres éléments critiques, tels que les marqueurs, les listes de sécurité ou les groupes de sécurité de réseau. La vérification préalable à l'inversion de rôle garantit spécifiquement que le boîtier ZFS Storage Appliance dans chaque bâti est à l'état correct.

Lorsque les vérifications préalables 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 l'inversion de rôle peut commencer. En fonction des métadonnées de ressource échangées entre les systèmes appairés et des données répliquées sur le boîtier de stockage ZFS Storage Appliance de secours, le système cible (B) est prêt à assumer le rôle principal des instances dans la configuration de reprise après sinistre. Le processus de réplication est inversé et prêt à utiliser le système source (A) en tant que base de secours dès que la permutation est terminée.

À 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 de récupération après sinistre 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 sont arrêtées.

Pour terminer la permutation, 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 reprise 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ées à la configuration de reprise après sinistre initiale 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 de nouveau en ligne.

Le plan commence par des vérifications préalables pour s'assurer que le système de secours et ZFS Storage Appliance sont à l'état correct pour faire apparaître les ressources couvertes par la configuration de récupération après sinistre. Lorsque les vérifications préalables sont terminées sans erreur, l'annulation du rôle commence.

À l'aide des métadonnées et des ressources 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 de principal. Une configuration de récupération après sinistre identique est créée sur le système B, qui est devenu la configuration principale, avec des mappages de site inversés et des métadonnées collectées à partir des instances nouvellement lancées. En préparation du retour en ligne du système principal d'origine (A), le processus de réplication est inversé et prêt à utiliser le système A comme base de secours.

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

Plan de report

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

Il n'y a aucune vérification préalable dans un plan après basculement. Le système A est de nouveau en ligne après une interruption 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 reprise 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ées à la configuration de reprise après sinistre initiale sont supprimés du système A.

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