Serveur physique sur l’architecture de reprise d’activité Azure - Moderne
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.
Pour plus d’informations sur les exigences du serveur de configuration dans les versions Classiques, consultez Serveur physique sur l’architecture de reprise d’activité Azure.
Notes
Assurez-vous de créer un 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 reprotection. 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.
Notes
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 |
Chargez les journaux d’applications utilisés pour la supervision 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 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
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 d’objectif de point de récupération. 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 de cohérence d’application. Un instantané de cohérence des applications peut être pris toutes les 1 à 12 heures, en fonction de vos besoins en applications. Les instantanés sont des instantanés d’objet blob Azure standard. L’agent Mobility en cours d’exécution sur une machine physique demande un instantané VSS conformément à ce paramètre, et insère un signet à ce point dans le temps pour en faire un point de cohérence avec l’application dans le flux de réplication.
Remarque
Une période de rétention élevée du point de récupération peut avoir une incidence sur le coût du stockage, car d’autres points de récupération peuvent avoir à être enregistrés.
Le trafic est répliqué sur des points de terminaison publics de stockage Azure via 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.
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.
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.
Les données de réplication se trouvent tout d’abord dans un compte de stockage de 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é une simulation de récupération d'urgence (test de basculement) pour vérifier que tout fonctionne comme prévu, vous pouvez exécuter un basculement en fonction de vos besoins.
Remarque
Pour les serveurs physiques, la restauration automatique n’est pas prise en charge
- Vous pouvez exécuter le basculement pour une seule machine ou créer un plan de récupération pour basculer simultanément plusieurs serveurs. Utiliser un plan de récupération plutôt que de basculer un seul ordinateur présente les avantages 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.
- Après avoir déclenché le basculement initial, validez-le pour accéder à la charge de travail à partir de la machine virtuelle Azure.
Processus de resynchronisation
- 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.
- 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.
- 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)
- La resynchronisation envoie uniquement les données différentielles à 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.
- 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.
- 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.
- 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 de cohérence des applications | Fréquence à laquelle Site Recovery prend un instantané de cohérence des 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 basculez un système, vous utilisez un point de récupération pour restaurer la machine physique en tant que 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 :
- Par défaut, Site Recovery prend des instantanés de cohérence en cas d’incident à partir des données ainsi que des instantanés de cohérence des applications si vous spécifiez une fréquence pour ces instantanés.
- 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 ni dans les applications présentes sur la machine. |
Par défaut, Site Recovery crée des points de récupération de cohérence en cas d’incident toutes les cinq minutes. Ce paramètre ne peut pas être modifié. |
Aujourd’hui, la plupart des applications peuvent récupérer correctement à partir de points de cohérence en cas d’incident. Les points de récupération de cohérence en cas d’incident sont généralement suffisants pour la réplication des systèmes d’exploitation et des applications telles que les serveurs DHCP et les serveurs d’impression. |
Cohérence des applications
| Description | Détails | Recommandation |
|---|---|---|
| Les points de récupération de cohérence des applications sont créés à partir d’instantanés de cohérence des applications. Un instantané de cohérence des applications contient toutes les informations d’un instantané de cohérence en cas d’incident ainsi que toutes les données en mémoire et les transactions en cours. |
Les instantanés de cohérence des applications utilisent le service de cliché instantané de volume (VSS) : 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 copie pour écriture, le service VSS informe chaque application de l’ordinateur qu’il a besoin de vider ses données résidant en mémoire sur le disque. 4) VSS permet ensuite à l’application de sauvegarde ou de récupération d’urgence (ici, Site Recovery) de lire les données d’instantanés et de poursuivre. |
Les instantanés de cohérence des applications sont réalisés selon la fréquence que vous avez spécifiée. 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. Ces instantanés sont plus complexes et plus longs à réaliser que les instantanés de cohérence en cas d’incident. 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.