Reprise après sinistre et sauvegarde
La fonctionnalité de reprise après sinistre (DR) de XenServer vous permet de récupérer des machines virtuelles (VM) et des vApps suite à une défaillance matérielle qui détruit un pool ou un site entier. Pour une protection contre les défaillances d’un seul hôte, consultez (/fr-fr/xenserver/8/high-availability.html).
Remarque :
Vous devez être connecté avec votre compte root ou avoir le rôle d’Opérateur de pool ou un rôle supérieur pour utiliser la fonctionnalité DR.
Comprendre la DR de XenServer®
Remarque :
La DR est le mécanisme de résilience approprié lorsque vos sites sont géographiquement dispersés. Si vos centres de données sont connectés avec une latence aller-retour inférieure à 5 ms et un débit réseau d’au moins 10 Gbit/s — répondant à la (/fr-fr/xenserver/8/reference-architecture#definitions) — ils peuvent fonctionner comme un seul pool de ressources sans nécessiter de DR. Cependant, un pool partagé n’offre pas à lui seul une résilience contre une défaillance complète du centre de données. La nécessité d’une DR dépend également de la topologie de votre pool, de la configuration du stockage et des objectifs de récupération.
La DR de XenServer fonctionne en stockant toutes les informations nécessaires à la récupération de vos machines virtuelles et vApps critiques sur des référentiels de stockage (SR). Les SR sont ensuite répliqués de votre environnement principal (production) vers un environnement de sauvegarde. Lorsqu’un pool protégé de votre site principal tombe en panne, vous pouvez récupérer les machines virtuelles et les vApps de ce pool à partir du stockage répliqué recréé sur un site secondaire (DR) avec un temps d’arrêt minimal de l’application ou de l’utilisateur.
Les paramètres de Reprise après sinistre dans XenCenter® peuvent être utilisés pour interroger le stockage et importer les machines virtuelles et vApps sélectionnées vers un pool de récupération lors d’un sinistre. Lorsque les machines virtuelles s’exécutent dans le pool de récupération, les métadonnées du pool de récupération sont également répliquées. La réplication des métadonnées du pool permet de propager les modifications des paramètres des machines virtuelles vers le pool principal lorsque celui-ci est récupéré. Parfois, les informations pour la même machine virtuelle peuvent se trouver à plusieurs endroits. Par exemple, le stockage du site principal, le stockage du site de reprise après sinistre et également dans le pool vers lequel les données doivent être importées. Si XenCenter constate que les informations de la machine virtuelle sont présentes à deux endroits ou plus, il s’assure d’utiliser uniquement les informations les plus récentes.
La fonctionnalité de reprise après sinistre peut être utilisée avec XenCenter et l’interface de ligne de commande xe. Pour les commandes CLI, consultez (/fr-fr/xenserver/8/command-line-interface.html#disaster-recovery-commands).
Conseil :
Vous pouvez également utiliser les paramètres de reprise après sinistre pour exécuter des basculements de test afin de tester votre système de reprise après sinistre sans interruption. Lors d’un basculement de test, toutes les étapes sont les mêmes que pour un basculement. Cependant, les machines virtuelles et les vApps ne sont pas démarrées après avoir été récupérées sur le site de reprise après sinistre. Une fois le test terminé, un nettoyage est effectué pour supprimer toutes les machines virtuelles, vApps et le stockage recréés sur le site DR.
Les machines virtuelles XenServer se composent de deux éléments :
-
Disques virtuels utilisés par la machine virtuelle, stockés sur des référentiels de stockage (SR) configurés dans le pool où se trouvent les machines virtuelles.
-
Métadonnées décrivant l’environnement de la machine virtuelle. Ces informations sont nécessaires pour recréer la machine virtuelle si la machine virtuelle d’origine est indisponible ou corrompue. La plupart des données de configuration des métadonnées sont écrites lors de la création de la machine virtuelle et ne sont mises à jour que lorsque vous modifiez la configuration de la machine virtuelle. Pour les machines virtuelles d’un pool, une copie de ces métadonnées est stockée sur chaque hôte du pool.
Dans un environnement de reprise après sinistre (DR), les machines virtuelles sont recréées sur un site secondaire en utilisant les métadonnées du pool et les informations de configuration de toutes les machines virtuelles et vApps du pool. Les métadonnées de chaque machine virtuelle incluent son nom, sa description et son identifiant unique universel (UUID), ainsi que sa mémoire, son processeur virtuel et sa configuration réseau et de stockage. Elles incluent également les options de démarrage de la machine virtuelle – ordre de démarrage, intervalle de délai, haute disponibilité et priorité de redémarrage. Les options de démarrage de la machine virtuelle sont utilisées lors du redémarrage de la machine virtuelle dans un environnement de haute disponibilité ou de reprise après sinistre. Par exemple, lors de la récupération de machines virtuelles après un sinistre, les machines virtuelles au sein d’une vApp sont redémarrées dans le pool de reprise après sinistre dans l’ordre spécifié dans les métadonnées de la machine virtuelle, et en utilisant les intervalles de délai spécifiés.
Exigences d’infrastructure de reprise après sinistre
Configurez l’infrastructure de reprise après sinistre appropriée sur les sites principal et secondaire pour utiliser la fonction de reprise après sinistre de XenServer.
-
Le stockage utilisé pour les métadonnées du pool et les disques virtuels utilisés par les machines virtuelles doit être répliqué de l’environnement principal (production) vers un environnement de sauvegarde. La réplication du stockage, telle que l’utilisation de la mise en miroir, varie selon les périphériques. Par conséquent, consultez votre fournisseur de solution de stockage pour gérer la réplication du stockage.
-
Une fois que les machines virtuelles et les vApps que vous avez récupérées dans un pool sur votre site de reprise après sinistre sont opérationnelles, les SR contenant les métadonnées du pool de reprise après sinistre et les disques virtuels doivent être répliqués. La réplication permet de restaurer les machines virtuelles et les vApps récupérées sur le site principal (rebasculement) lorsque le site principal est de nouveau en ligne.
-
L’infrastructure matérielle de votre site de reprise après sinistre n’a pas besoin de correspondre à celle du site principal. Cependant, l’environnement XenServer doit être au même niveau de version et de correctif.
-
Les hôtes et les pools du site secondaire doivent avoir la même édition de licence que ceux du site principal. Ces licences XenServer s’ajoutent à celles attribuées aux hôtes du site principal.
-
Des ressources suffisantes doivent être configurées dans le pool cible pour permettre la recréation et le démarrage de toutes les machines virtuelles basculées.
Avertissement :
Les paramètres de reprise après sinistre ne contrôlent aucune fonctionnalité de baie de stockage.
Les utilisateurs de la fonction de reprise après sinistre doivent s’assurer que le stockage des métadonnées est, d’une manière ou d’une autre, répliqué entre les deux sites. Certaines baies de stockage contiennent des fonctions de « mise en miroir » pour réaliser la réplication automatiquement. Si vous utilisez ces fonctions, vous devez désactiver la fonction de miroir (« miroir cassé ») avant de redémarrer les machines virtuelles sur le site de récupération.
Considérations relatives au déploiement
Passez en revue les étapes suivantes avant d’activer la reprise après sinistre.
Étapes à suivre avant un sinistre
La section suivante décrit les étapes à suivre avant un sinistre.
-
Configurez vos machines virtuelles et vApps.
-
Notez comment vos machines virtuelles et vApps sont mappées aux SR, et les SR aux LUN. Portez une attention particulière à la dénomination des paramètres
name_labeletname_description. La récupération des machines virtuelles et des vApps à partir d’un stockage répliqué est plus facile si les noms des SR indiquent comment les machines virtuelles et les vApps sont mappées aux SR, et les SR aux LUN. -
Organisez la réplication des LUN.
-
Activez la réplication des métadonnées du pool vers un ou plusieurs SR sur ces LUN.
-
Assurez-vous que les SR vers lesquels vous répliquez les métadonnées du pool principal ne sont attachés qu’à un seul pool.
Mesures à prendre après une catastrophe
La section suivante décrit les mesures à prendre après une catastrophe.
-
Rompez tous les miroirs de stockage existants afin que le site de récupération ait un accès en lecture/écriture au stockage partagé.
-
Assurez-vous que les LUN à partir desquels vous souhaitez récupérer les données des machines virtuelles ne sont attachés à aucun autre pool, sinon une corruption pourrait se produire.
-
Si vous souhaitez protéger le site de récupération d’une catastrophe, vous devez activer la réplication des métadonnées du pool vers un ou plusieurs SR sur le site de récupération.
Mesures à prendre après une récupération
La section suivante décrit les mesures à prendre après une récupération réussie des données.
-
Resynchronisez tous les miroirs de stockage.
-
Sur le site de récupération, arrêtez proprement les machines virtuelles ou les vApps que vous souhaitez déplacer vers le site principal.
-
Sur le site principal, suivez la même procédure que pour le basculement dans la section précédente, pour restaurer les machines virtuelles ou vApps sélectionnées vers le site principal.
-
Pour protéger le site principal contre de futures catastrophes, vous devez réactiver la réplication des métadonnées du pool vers un ou plusieurs SR sur les LUN répliqués.