Vue d’ensemble d’Azure Site Recovery

Effectué

Azure Site Recovery est bien plus qu’un simple outil destiné vous aider à récupérer de pannes du système. Azure Site Recovery réplique les charges de travail entre un site principal et un site secondaire. Site Recovery peut également être utilisé pour migrer des machines virtuelles depuis une infrastructure locale vers Azure.

Votre première tâche pour protéger vos charges de travail, par exemple des séismes, consiste à examiner le plan actuel de continuité d’activité et de reprise d’activité (BCDR) de l’entreprise. Vous devez identifier les différents objectifs de récupération et l’étendue des systèmes à protéger.

Cette unité explique comment Azure Site Recovery peut aider à atteindre ces objectifs, et rendre possibles le basculement et la récupération des ressources en cas de sinistre.

Continuité d’activité et reprise d’activité (BCDR)

Une perte de service peut perturber les activités de votre personnel et de vos utilisateurs. Chaque seconde d’indisponibilité des systèmes peut entraîner une perte de revenus pour votre entreprise. Votre entreprise peut également devoir faire face à des pénalités financières pour le non-respect de contrats établissant la disponibilité des services que vous fournissez.

Les plans de continuité d’activité et de reprise d’activité sont des documents formels élaborés par les organisations, qui couvrent l’étendue et les actions à entreprendre en cas de sinistre ou de panne de grande ampleur. Chaque panne est évaluée individuellement. Par exemple, un plan BCDR entre en jeu quand tout un centre de données n’est plus alimenté en électricité.

Dans cet exemple de scénario, un tremblement de terre s’est produit et les dégâts des lignes de communication ont rendu le centre de données inutilisable et nécessitant des réparations. Un sinistre de cette ampleur peut entraîner une perturbation des services pendant une période se comptant en jours plutôt qu’en heures : un plan complet de continuité d’activité et de reprise d’activité doit donc être mis en œuvre pour remettre les services en ligne.

Dans le cadre de votre plan de continuité des activités et de reprise d’activité, déterminez les objectifs de délai de récupération (RTO) et les objectifs de point de récupération (RPO) pour vos applications. Ensemble, ces deux objectifs vous permettent d’identifier le nombre maximal d’heures pendant lesquelles votre organisation peut se passer des services spécifiés et le type de processus de récupération des données à mettre en place. Examinons-les chacun de plus près.

An illustration showing the duration, in hours, of the recovery point objective and recovery time objective from the time of the disaster.

Objectif de délai de récupération

Un RTO est une mesure de la durée maximale pendant laquelle votre entreprise peut survivre après un sinistre jusqu’à ce que le service normal doive être restauré afin d’éviter des conséquences inacceptables associées à une interruption de la continuité. Supposons que votre objectif de délai de récupération est de 12 heures : cela signifie que les opérations peuvent continuer pendant 12 heures sans que les services de base fonctionnent. Si le temps d’arrêt est plus long, votre entreprise subira un préjudice important.

Objectif de point de récupération

Un RPO est une mesure indiquant la quantité maximale de perte de données acceptable après un sinistre. Une entreprise peut généralement décider d’effectuer une sauvegarde toutes les 24 heures, toutes les 12 heures ou même en temps réel. En cas de sinistre, il y a toujours une perte de données.

Par exemple, si votre sauvegarde a lieu toutes les 24 heures à minuit et qu’un sinistre se produit à 9h du matin, neuf heures de données sont perdues. Si l’objectif de point de récupération de votre entreprise était de 12 heures, ce serait acceptable, car seulement neuf heures se seraient écoulées. Si l’objectif de point de récupération était de 4 heures, il y aurait un problème et cela occasionnerait un préjudice pour l’entreprise.

Qu’est-ce qu’Azure Site Recovery ?

Azure Site Recovery peut contribuer à votre plan BCDR, car il peut répliquer des charges de travail d’un site principal sur un site secondaire. Si un problème se produit dans le site principal, Site Recovery peut être appelé automatiquement pour répliquer les machines virtuelles protégées sur un autre emplacement. Le basculement peut se faire d’un emplacement local vers Azure ou d’une région Azure vers une autre.

Voici certaines des fonctionnalités remarquables d’Azure Site Recovery :

  • Gestion centralisée : La réplication peut être configurée et gérée, et le basculement et la restauration automatique peuvent être appelés à partir du portail Azure.
  • Réplication de machines virtuelles locales : Les machines virtuelles locales peuvent être répliquées si nécessaire vers Azure ou vers un centre de données local secondaire.
  • Réplication de machines virtuelles Azure : Les machines virtuelles Azure peuvent être répliquées d’une région vers une autre.
  • Cohérence des applications pendant le basculement : avec les points de récupération et les instantanés de cohérence des applications, les machines virtuelles sont toujours conservées dans un état cohérent pendant la réplication.
  • Basculement flexible : Les basculements peuvent être effectués à la demande en guise de test ou bien déclenchés lors d’un sinistre réel. Vous pouvez effectuer des tests pour simuler un scénario de reprise d’activité sans interruption de votre service actif.
  • Intégration réseau : Site Recovery peut prendre en charge la gestion du réseau pendant un scénario de réplication et de reprise d’activité. Les adresses IP réservées et les équilibreurs de charge sont inclus, afin que les machines virtuelles puissent fonctionner au nouvel emplacement.

Configurer Azure Site Recovery

Diagram showing the Azure Site Recovery architecture.

Plusieurs composants doivent être configurés pour activer Azure Site Recovery :

  • Réseau : Un réseau virtuel Azure valide est nécessaire pour les machines virtuelles répliquées à utiliser.
  • Coffre Recovery Services : Un coffre dans votre abonnement Azure stocke les machines virtuelles migrées quand un basculement est effectué. Le coffre contient également la stratégie de réplication ainsi que les emplacements source et cible pour la réplication et le basculement.
  • Informations d’identification : Les informations d’identification que vous utilisez pour Azure doivent avoir les rôles Contributeur de machines virtuelles et Collaborateur Site Recovery pour pouvoir autoriser la modification tant de la machine virtuelle que le stockage auxquels Site Recovery est connecté.
  • Serveur de configuration : Un serveur VMware local remplit plusieurs rôles pendant le processus de basculement et de réplication. Il est obtenu à partir du portail Azure sous la forme d’une appliance de machine virtuelle ouverte (OVA) pour faciliter le déploiement. Le serveur de configuration comprend les composants suivants :
    • Serveur de processus : Ce serveur joue le rôle de passerelle pour le trafic de réplication. Il met en cache, compresse et chiffre le trafic avant de l’envoyer via le WAN à Azure. Le serveur de processus installe également le service Mobilité sur toutes les machines physiques et virtuelles ciblées pour le basculement et la réplication.
    • Serveur cible maître : Cette machine gère le processus de réplication lors d’une restauration automatique à partir d’Azure.

Important

Pour restaurer automatiquement depuis Azure vers un environnement local, VMware vCenter avec un serveur de configuration doit être disponible, même si vous ne faites que répliquer des machines physiques vers Azure. Vous ne pouvez pas restaurer automatiquement vers des serveurs physiques.

Processus de réplication

Azure Site Recovery architecture.

Une fois les tâches prérequises configurées, la réplication des machines peut commencer. Elles sont répliquées en fonction de la stratégie de réplication en place. Au cours des phases initiales de la première copie, les données du serveur sont répliquée sur Stockage Azure. Quand la réplication initiale se termine, une deuxième réplication se produit. Cette fois, les modifications d’ordre différentiel de la machine virtuelle sont répliquées sur Azure.

Tester et superviser un basculement

Une fois votre environnement configuré pour la reprise d’activité, testez-le pour vérifier qu’il est correctement configuré et que tout fonctionne comme prévu. Testez la configuration en procédant à un exercice de reprise d’activité sur une machine virtuelle isolée. Une bonne pratique est d’utiliser un réseau isolé pour le test, afin que les services actifs ne soient pas interrompus.

La première tâche à effectuer quand vous faites un exercice de récupération est de vérifier les propriétés de votre machine virtuelle de test dans la section Éléments protégés du portail Azure. Les derniers points de récupération sont affichés dans le volet Élément répliqué. Dans la section Calcul et réseau, le nom de la machine virtuelle, le groupe de ressources, la taille cible, le groupe à haute disponibilité et les paramètres du disque peuvent être ajustés si nécessaire.

Les exercices de récupération peuvent être lancés à partir de la section Paramètres>Éléments répliqués du portail Azure. Sélectionnez la machine virtuelle cible, puis l’élément de menu Test de basculement pour le dernier point de récupération traité. Sélectionnez le réseau Azure dans le même menu. Pour démarrer le travail de récupération, sélectionnez OK sur l’écran de sélection du réseau.

L’état de la tâche de récupération et celui de la machine virtuelle répliquée sont accessibles via la section Vue d’ensemble du coffre Recovery Services. Les éléments répliqués ont l’un des états suivants :

  • Sain : La réplication fonctionne normalement.
  • Avertissement : Il existe un problème pouvant avoir un impact sur la réplication.
  • Critique: Une erreur de réplication critique a été détectée.

Si tout se passe bien, l’état de la machine virtuelle répliquée est défini sur Effectué. Si aucun test n’a été effectué, l’état est défini sur Test recommandé. L’état de la machine virtuelle est également Test recommandé s’il plus de six mois se sont écoulés depuis le dernier test.

Vérifiez vos connaissances

1.

Quelles sont les étapes clés nécessaires pour configurer Azure Site Recovery afin de protéger vos machines virtuelles locales ?

2.

Comment tester le déploiement d’Azure Site Recovery ?