Architecture de reprise d’activité d’un serveur physique vers Azure – Modernisée

Cet article décrit l’architecture et les processus modernes utilisés quand vous répliquez, basculez et récupérez des serveurs physiques Windows et Linux entre un site local et Azure, à l’aide du service Azure Site Recovery.

Note

Assurez-vous de créer un nouveau coffre Recovery Services pour configurer l’appliance de réplication ASR. N’utilisez pas un coffre existant.

Composants architecturaux

Le tableau et le graphique suivants présentent une vue générale des composants utilisés pour la récupération d'urgence de machine physique sur Azure.

Composant	Prérequis	Détails
Microsoft Azure	Un abonnement Azure, un compte de Stockage Azure pour le cache, un disque managé et un réseau Azure.	Les données répliquées à partir de machines locales sont stockées dans le Stockage Azure. Les machines virtuelles Azure sont créées avec les données répliquées quand vous exécutez un basculement depuis le site local vers Azure. Les machines virtuelles Azure se connectent au réseau virtuel Azure lors de leur création.
Appliance de réplication Azure Site Recovery	C’est le bloc de construction de base de toute l’infrastructure Azure Site Recovery locale. Tous les composants de l’appliance se coordonnent avec l’appliance de réplication. Ce service supervise toutes les activités de Site Recovery de bout en bout, notamment la surveillance de l’intégrité des machines protégées, la réplication des données, les mises à jour automatiques, etc.	L’appliance héberge différents composants cruciaux tels que : Serveur proxy : ce composant joue le rôle de canal proxy entre l’agent de mobilité et les services Site Recovery dans le cloud. Cela garantit qu’aucune connectivité Internet supplémentaire n’est requise pour les charges de travail de production afin de générer des points de récupération. Éléments découverts : ce composant recueille des informations sur vCenter et les coordonnées avec le service de gestion Azure Site Recovery dans le cloud. Serveur de reprotection : ce composant est coordonné entre Azure et les machines locales lors des opérations de reprotection et de restauration automatique. Serveur de traitement : ce composant est utilisé pour la mise en cache et la compression des données avant leur envoi à Azure. En savoir plus sur les appliances de réplication et sur l’utilisation de plusieurs appliances de réplication. Agent Recovery Service : ce composant est utilisé pour la configuration/l’inscription auprès des services Site Recovery et pour le monitoring de l’intégrité de tous les composants. Fournisseur de Site Recovery : Ce composant est utilisé pour faciliter la réactivation de la protection. Il identifie la reprotection d’un autre emplacement et la reprotection de l’emplacement d’origine pour un ordinateur source. Service de réplication : ce composant est utilisé pour répliquer des données à partir de l’emplacement source vers Azure.
Machines répliquées	Le service Mobilité est installé sur chaque serveur physique que vous répliquez.	Nous vous recommandons d’autoriser l’installation automatique du service Mobility. Vous pouvez également installer le service manuellement.

Configurer la connectivité réseau sortante

Pour que Site Recovery fonctionne comme prévu, vous devez modifier la connectivité réseau sortante pour permettre au réseau d’effectuer la réplication.

Note

Site Recovery ne prend pas en charge l’utilisation d’un proxy d’authentification pour contrôler la connectivité réseau.

Connectivité sortante pour les URL

Si vous utilisez un proxy de pare-feu basé sur des URL pour contrôler la connectivité sortante, autorisez l’accès à ces URL :

URL	Détails
portal.azure.com	Accédez au portail Azure.
*.windows.net *.msftauth.net *.msauth.net *.microsoft.com *.live.com *.office.com	Pour vous connecter à votre abonnement Azure.
*.microsoftonline.com	Créez des applications Microsoft Entra pour que l’appliance communique avec Azure Site Recovery.
management.azure.com	Créez des applications Microsoft Entra pour que l’appliance communique avec le service Azure Site Recovery.
*.services.visualstudio.com	Téléchargez les journaux de l’application utilisés à des fins de surveillance interne.
*.vault.azure.net	Gérez les secrets dans Azure Key Vault. Remarque : Vérifiez que les machines à répliquer y ont accès.
aka.ms	Autorisez l’accès à des liens aka.ms. Utilisé pour les mises à jour de l’appliance Azure Site Recovery.
download.microsoft.com/download	Autoriser les téléchargements à partir du Centre de téléchargement Microsoft.
*.servicebus.windows.net	Communication entre l’appliance et le service Azure Site Recovery.
*.discoverysrv.windowsazure.com	Se connecter à l’URL du service de découverte Azure Site Recovery.
*.hypervrecoverymanager.windowsazure.com	Se connecter aux URL du micro-service Azure Site Recovery
*.blob.core.windows.net	Télécharger des données vers le stockage Azure qui est utilisé pour créer des disques cibles
*.backup.windowsazure.com	URL du service de protection : microservice utilisé par Azure Site Recovery pour le traitement et la création de disques répliqués dans Azure

Processus de réplication

1. Lorsque vous activez la réplication pour un système, la réplication initiale vers Stockage Azure commence, conformément à la stratégie de réplication spécifiée. Notez ce qui suit :

   • Pour les machines physiques, la réplication se fait au niveau du bloc, presque en continu, à l’aide de l’agent du service Mobility en cours d’exécution sur le système.
   • Tous les paramètres de la stratégie de réplication sont appliqués :
     • Seuil de RPO. Ce paramètre n’affecte pas la réplication. Il aide à la supervision. Un événement est déclenché, et un e-mail peut être envoyé, si le RPO en cours dépasse le seuil spécifié.
     • Rétention des points de récupération. Ce paramètre spécifie le moment auquel vous souhaitez revenir lors d’une interruption. La durée de conservation maximale est de 15 jours.
     • Instantanés cohérents au niveau de l’application. Un instantané cohérent avec l’application peut être effectué à intervalles de 1 à 12 heures, selon les besoins de votre application. Les instantanés sont des instantanés standard de blobs Azure. L’agent Mobility s’exécutant sur une machine physique demande un instantané VSS selon ce paramètre et marque ce point dans le temps comme un point cohérent avec l’application dans le flux de réplication.

     Note

     Une longue période de conservation des points de récupération peut avoir une incidence sur les coûts de stockage, car davantage de points de récupération devront peut-être être conservés.

2. Le trafic est répliqué vers les points de terminaison publics du stockage Azure sur Internet. L’autre solution consiste à utiliser Azure ExpressRoute avec peering Microsoft. La réplication du trafic à partir d’un site local vers Azure via un réseau VPN de site à site n’est pas prise en charge.

3. L’opération de réplication initiale garantit que toutes les données présentes sur l’ordinateur au moment de l’activation de la réplication sont envoyées à Azure. La réplication des modifications delta dans Azure commence à l’issue de la réplication initiale. Le suivi des modifications d’une machine est envoyé au serveur de traitement.

4. La communication s’effectue comme suit :

   • Les machines communiquent avec l’appliance locale sur le port HTTPS 443 entrant, pour la gestion de la réplication.
   • L’appliance orchestre la réplication avec Azure sur le port HTTPS 443 sortant.
   • Les machines envoient des données de réplication au serveur de traitement sur le port HTTPS 9443 entrant. Ce port peut être modifié.
   • Le serveur de traitement reçoit les données de réplication, les optimise et les chiffre, puis les envoie au stockage Azure via le port 443 sortant.

5. Les journaux de données de réplication sont d’abord placés dans un compte de stockage cache dans Azure. Ces journaux sont traités et les données sont stockées dans un disque managé Azure (appelé asrseeddisk). Les points de récupération sont créés sur ce disque.

Processus de basculement et de restauration automatique

Après avoir configuré la réplication et exécuté un test de reprise après sinistre (test de basculement) pour vérifier que tout fonctionne comme prévu, vous pouvez passer au basculement si nécessaire.

Note

Pour les serveurs physiques, la restauration automatique n’est pas prise en charge

1. Vous pouvez effectuer un basculement pour une seule machine ou créer un plan de reprise permettant de basculer simultanément plusieurs serveurs. Les avantages d’un plan de reprise plutôt que du basculement d’une machine unique sont les suivants :
   • Vous pouvez modéliser des dépendances d’application en incluant tous les serveurs sur l’application dans un seul plan de récupération.
   • Vous pouvez ajouter des scripts, des runbooks Azure et mettre en pause pour effectuer des actions manuelles.
2. Après avoir déclenché le basculement initial, validez-le pour commencer à accéder à la charge de travail depuis la machine virtuelle Azure.

Processus de resynchronisation

1. Parfois, pendant la réplication initiale ou lors du transfert de changements d’ordre différentiel, il peut y avoir des problèmes de connectivité réseau entre la machine source et le serveur de traitement ou entre le serveur de traitement et Azure. L’un ou l’autre de ces problèmes peut momentanément entraîner des échecs de transfert de données vers Azure.
2. Pour éviter les problèmes d’intégrité des données et réduire les coûts de transfert de données, Site Recovery marque un ordinateur pour la resynchronisation.
3. Une machine peut également être marquée pour la resynchronisation dans des situations comme celles qui suivent pour maintenir la cohérence entre la machine source et les données stockées dans Azure
   • Si une machine subit un arrêt forcé
   • Si une machine subit des changements de configuration comme le redimensionnement de disque (en modifiant la taille du disque de 2 à 4 To)
4. La resynchronisation envoie uniquement les données delta à Azure. Le transfert de données entre un site local et Azure est réduit en calculant les sommes de contrôle de données entre la machine source et les données stockées dans Azure.
5. Par défaut, la resynchronisation est planifiée pour s’exécuter automatiquement en dehors des heures de bureau. Si vous ne souhaitez pas attendre la resynchronisation par défaut en dehors des heures de bureau, vous pouvez resynchroniser un système manuellement. Pour ce faire, accédez au portail Azure, sélectionnez la machine physique >Resynchroniser.
6. Si la resynchronisation par défaut échoue en dehors des heures de bureau et qu’une intervention manuelle est nécessaire, une erreur est générée sur la machine spécifique dans le portail Azure. Vous pouvez résoudre l’erreur et déclencher la resynchronisation manuellement.
7. Une fois la resynchronisation terminée, la réplication des modifications différentielles reprend.

Stratégie de réplication

Par défaut, lorsque vous activez la réplication de machines virtuelles Azure, Site Recovery crée une stratégie de réplication avec les paramètres par défaut qui sont répertoriés dans le tableau.

Paramètre de stratégie	Détails	Par défaut
Conservation des points de récupération	Spécifie la durée pendant laquelle Site Recovery conserve les points de récupération.	1 jour
Fréquence des instantanés cohérents au niveau de l’application	Fréquence à laquelle Site Recovery prend un instantané cohérent avec les applications	Désactivé

Captures instantanées et points de récupération

Les points de récupération sont créés à partir de captures instantanées des disques des machines qui sont prises à un moment précis dans le temps. Lorsque vous effectuez le basculement d’un système, vous utilisez un point de récupération pour restaurer la machine physique sous forme de machine virtuelle à l’emplacement cible.

Lorsque nous effectuons un basculement, nous souhaitons garantir que la machine virtuelle démarre sans perte ni altération des données, et que les données soient cohérentes à la fois sur le système d’exploitation et dans les applications qui s’exécutent sur la machine virtuelle. Cela dépend du type des captures instantanées qui sont prises.

Site Recovery prend des captures instantanées de la façon suivante :

1. Par défaut, Site Recovery prend des instantanés cohérents après panne des données, ainsi que des instantanés cohérents au niveau des applications si vous en spécifiez la fréquence.
2. Les points de récupération sont créés à partir des instantanés et sont stockés conformément aux paramètres de conservation de la stratégie de réplication.

Cohérence

Le tableau suivant explique les différents types de cohérence.

Cohérence en cas d’incident

Description	Détails	Recommandation
Un instantané de cohérence en cas d’incident capture les données qui se trouvaient sur le disque lorsque l’instantané a été pris. Il n’ajoute aucune donnée en mémoire. Elle contient l’équivalent des données qui seraient présentes sur le disque en cas d’incident du système ou si le cordon d’alimentation était retiré du serveur au cours de la capture de l’instantané. La cohérence avec les incidents ne garantit pas la cohérence des données sur le système d’exploitation ou dans les applications présentes sur la machine.	Par défaut, Site Recovery crée des points de récupération cohérents en cas de panne toutes les cinq minutes. Ce paramètre ne peut pas être modifié.	Aujourd’hui, la plupart des applications peuvent se rétablir correctement à partir de points cohérents après incident. Les points de récupération cohérents après incident sont généralement suffisants pour la réplication des systèmes d’exploitation et des applications comme les serveurs DHCP et les serveurs d’impression.

Cohérent avec l’application

Description	Détails	Recommandation
Les points de récupération cohérents au niveau de l’application sont créés à partir d’instantanés cohérents au niveau de l’application. Un instantané cohérent avec l’application contient toutes les informations d’un instantané cohérent après incident, ainsi que toutes les données en mémoire et les transactions en cours.	Les instantanés cohérents au niveau de l’application utilisent le service VSS (Volume Shadow Copy Service) : 1) Azure Site Recovery utilise la méthode Sauvegarde de copie uniquement (VSS_BT_COPY), qui ne change pas l’heure et le numéro de séquence de sauvegarde du journal des transactions de Microsoft SQL 2) Quand une capture instantanée démarre, VSS effectue une opération de copie sur écriture (COW) sur le volume. 3) Avant d’effectuer l’opération de copy-on-write (COW), le service VSS informe chaque application sur la machine qu’elle doit vider sur disque les données qu’elle conserve en mémoire. 4) VSS permet ensuite à l’application de sauvegarde/de reprise après sinistre (ici, Site Recovery) de lire les données de l’instantané et de procéder.	Les captures instantanées cohérentes avec l’application sont prises à la fréquence que vous spécifiez. Cette fréquence doit toujours être inférieure à celle que vous définissez pour conserver les points de récupération. Par exemple, si vous conservez les points de récupération à l’aide du paramètre par défaut (24 heures), vous devez définir une fréquence inférieure à 24 heures. Ils sont plus complexes et prennent plus de temps à créer que les instantanés cohérents après panne. Ils affectent les performances des applications qui s’exécutent sur un système où la réplication est activée.

Étapes suivantes

Suivez ce tutoriel pour savoir comment activer la réplication d’une machine physique et VMware vers Azure.