Basculement et restauration automatique
Azure Site Recovery vous offre la flexibilité nécessaire pour basculer vers Azure en cas de sinistre et pour restaurer sur des machines locales une fois l’incident terminé.
Vous voulez maintenant effectuer un basculement complet pour le reste de l’environnement protégé vers Azure. Vous effectuez un basculement complet une fois que vous avez correctement exécuté un exercice de basculement sur une seule machine virtuelle de test. Vous allez ensuite effectuer la restauration automatique une fois le basculement correctement effectué.
Dans cette unité, vous allez explorer les différences entre le basculement et la restauration automatique. Vous allez aussi découvrir comment obtenir une stratégie de restauration automatique créée automatiquement après avoir configuré une stratégie de réplication sur Azure.
Basculement et restauration automatique
Un basculement est le processus qui se produit lorsque la décision est prise d’appeler le plan BCDR pour l’entreprise. Un basculement se produit quand l’environnement actif actuel protégé avec Site Recovery est déplacé vers l’environnement de réplica. Cet environnement de réplica cible prend donc la place de l’environnement actif et devient l’infrastructure principale.
Une restauration automatique est l’inverse d’un basculement. L’environnement actif précédent (qui est maintenant l’environnement de réplica, car un basculement a eu lieu) reprend son rôle d’origine et redevient l’environnement actif. Une fois le basculement effectué dans la première instance, une phase de reprotection doit se produire. Au cours de cette phase, vous remettez l’environnement d’origine en synchronisation avec le nouvel environnement actif. Ce processus permet au basculement et à la restauration automatique de se produire sans perte de données. La phase de reprotection est probablement un processus long, car vous devez vérifier que l’ancien environnement actif fonctionne correctement après le sinistre.
Les quatre phases d’un cycle de basculement et de restauration automatique sont les suivantes :
- Basculer vers Azure : Si le site principal local tombe en panne, la décision de basculer vers Azure (ou vers votre site secondaire) est prise, ce qui a pour effet de créer des machines virtuelles à partir des données répliquées principales.
- Reprotéger les machines virtuelles Azure : Après le basculement, les machines virtuelles Azure doivent être reprotégées afin de pouvoir répliquer les modifications apportées à l’environnement local une fois le sinistre réparé. Les machines virtuelles sont éteintes pour garantir la cohérence des données.
- Restaurer automatiquement sur un site local : Quand le site local est à nouveau opérationnel, il est possible de rebasculer vers cet environnement. Il redevient alors l’environnement actif. Vous ne pouvez pas restaurer automatiquement vers des serveurs physiques. Tous les systèmes doivent être restaurés sur des machines virtuelles.
- Reprotéger les machines virtuelles locales : La reprotection des machines virtuelles locales est effectuée afin que la réplication de celles-ci sur Azure commence une fois la restauration automatique correctement effectuée.
Stratégies de restauration automatique
Quand vous créez une stratégie de réplication locale pour copier vos machines locales vers Azure, une stratégie de restauration automatique associée est automatiquement créée pour vous. La stratégie a des attributs fixes qui ne peuvent pas être modifiés. Ces attributs sont :
- Elle peut seulement répliquer en retour sur votre serveur de configuration local.
- L’objectif de point de récupération est défini sur 15 minutes.
- La conservation du point de récupération est définie sur 24 heures.
- Des instantanés de cohérence des applications sont pris toutes les heures.
L’exécution de la restauration automatique arrête les machines virtuelles Azure. Une fois la réplication terminée, démarrez votre machine virtuelle locale pour qu’elle reprenne les charges de travail. Le service est interrompu : planifiez donc la restauration automatique à un moment qui n’affecte pas votre activité.
Plans de continuité d’activité et reprise d’activité
Les plans BCDR dans Site Recovery permettent la personnalisation et le séquencement du basculement et de la restauration automatique des machines virtuelles et applications qui s’exécutent sur celles-ci. Les machines sont regroupées et les actions de récupération peuvent être automatisées à l’aide de scripts exécutés lors du basculement ou de la restauration. Vous pouvez aussi ajouter si nécessaire des étapes manuelles pour certaines actions. Si vous testez le plan de continuité d’activité et de reprise d’activité (BCDR) avant qu’un sinistre se produise, vous pouvez être plus sûr d’obtenir un résultat positif. Pour vous conformer à l’objectif de délai de récupération de l’entreprise, vous devez faire en sorte que votre infrastructure soit rapidement opérationnelle sur le site secondaire.
Basculements flexibles
Avec cette flexibilité, Site Recovery peut exécuter des basculements à la demande à des fins de test. L’isolation de ces tests permet de ne pas interrompre les services en cours d’exécution. Cette flexibilité permet également d’exécuter un basculement lors d’une indisponibilité planifiée du service actif. La panne n’interrompt pas les utilisateurs du système, car ils sont basculés automatiquement sur l’environnement répliqué. La flexibilité fonctionne également dans l’autre sens. La restauration automatique à la demande peut se faire dans le cadre d’un test planifié ou dans le cadre d’un scénario de reprise d’activité entièrement appelé.