Solutions de réplication inter-région pour des régions non appairées
Certains services Azure prennent en charge la réplication interrégionale pour assurer la continuité d’activité et la protection contre la perte de données. Ces services utilisent une autre région secondaire qui s’appuie sur la réplication interrégionale. Les régions primaire et secondaire forment à elles deux une paire de régions.
Cependant, certaines régions ne sont pas appairées et nécessitent donc d’autres méthodes pour mettre en œuvre la géoréplication.
Ce document présente divers services et solutions permettant de mettre en œuvre des méthodes de géoréplication sans avoir besoin de régions jumelées.
Gestion des API Azure
Gestion des API Azure ne fournit pas de fonctionnalité de réplication inter-région réelle. Cependant, vous pouvez utiliser sa fonctionnalité de sauvegarde et de restauration pour exporter la configuration d’une instance du service Gestion des API dans une région et l’importer dans une autre région. Tant que le compte de stockage utilisé pour la sauvegarde est accessible depuis la région cible, il n’existe pas de dépendance de la région appairée. Une aide opérationnelle est fournie dans cet article.
Azure App Service
Pour App Service, les sauvegardes personnalisées sont stockées sur un compte de stockage sélectionné. Par conséquent, la restauration interrégionale dépend des régions GRS et jumelées. Pour le type de sauvegarde automatique, vous ne pouvez pas effectuer de sauvegarde ni de restauration interrégionale. Pour contourner ce problème, vous pouvez mettre en place un mécanisme de copie de fichiers personnalisé pour le jeu de données enregistré permettant de copier manuellement des données entre des régions non appairées et différents comptes de stockage.
Cache Azure pour Redis
Azure Cache pour Redis fournit deux options distinctes de réplication inter-régions qui sont la géoréplication active et la géoréplication passive. Dans les deux cas, il n’existe pas de dépendance explicite sur les paires de régions.
Azure Container Registry
La géoréplication permet à un registre de conteneurs Azure Container Registry de fonctionner comme un seul registre, en prenant en charge plusieurs régions avec des registres régionaux primaires multiples. Il n’existe pas de restrictions dictées par les paires de régions pour cette fonctionnalité. Pour plus d’informations, consultez Géoréplication dans Azure Container Registry.
Azure Cosmos DB
Si votre solution nécessite une durée de bon fonctionnement continue lors de pannes régionales, vous pouvez configurer Azure Cosmos DB pour répliquer vos données entre plusieurs régions et basculer si nécessaire de façon transparente vers des régions opérationnelles. Azure Cosmos DB prend en charge les écritures multirégions et peut distribuer vos données globalement pour fournir un accès à latence faible à vos données depuis n’importe quelle région, sans aucune restriction d’appairage.
Azure Database pour MySQL
Choisissez les régions Azure Database pour MySQL disponibles pour la rotation de vos réplicas en lecture.
Azure Database pour PostgreSQL
Pour la géoréplication dans des régions non appairées avec Azure Database pour PostgreSQL, vous pouvez utiliser :
Service géré avec géoréplication : le service géré Azure PostgreSQL prend en charge la géoréplication active pour créer un réplica secondaire accessible en lecture continue de votre serveur principal. Le réplica secondaire accessible en lecture peut être situé dans la même région Azure que la base de données primaire, ou, plus communément, dans une autre région. Ce type de réplica secondaire accessible en lecture est également appelé géoréplica.
Vous pouvez aussi utiliser une des deux méthodes de migration de données gérées par le client listées pour répliquer les données vers une région non appairée.
Azure Data Factory.
Pour la géoréplication dans des régions non appairées, Azure Data Factory (ADF) prend en charge l’approvisionnement IaC (Infrastructure en tant que code) de pipelines ADF combiné avec le contrôle de code source pour ADF.
Azure Event Grid
Pour la géoréplication de rubriques Event Grid dans des régions non appairées, vous pouvez implémenter le basculement côté client.
Azure IoT Hub
Pour la géoréplication dans des régions non appairées, utilisez le modèle concierge pour le routage vers un hub IoT secondaire.
Azure Kubernetes Service (AKS)
Sauvegarde Azure peut fournir une protection pour les clusters AKS, y compris une fonctionnalité de restauration interrégionale actuellement disponible en préversion, et prend uniquement en charge les disques Azure. Bien que la fonctionnalité de restauration interrégionale repose sur des réplicas de régions GRS jumelées, il est possible d’éviter toute dépendance vis-à-vis de la restauration interrégionale si le cluster AKS stocke les données uniquement dans le stockage externe, évitant ainsi l’utilisation de solutions « en cluster ».
Journaux Azure Monitor
Les espaces de travail Log Analytics dans les journaux Azure Monitor n’utilisent pas de régions jumelées. Pour garantir la continuité d’activité et la protection contre la perte de données, activez la réplication interrégionale des espaces de travail. Pour plus d’informations, consultez Améliorer la résilience en répliquant votre espace de travail Log Analytics entre différentes régions.
Azure Service Bus
Azure Service Bus peut fournir une résilience régionale, sans dépendance vis-à-vis de paires de régions, en utilisant les fonctionnalités de géoréplication ou de géo-reprise d’activité après sinistre.
Azure SQL Database
Pour la géoréplication dans des régions non appairées avec Azure SQL Database, vous pouvez utiliser :
La fonctionnalité de groupe de basculement qui est répliquée dans n’importe quelle combinaison de régions Azure sans dépendance avec le stockage GRS sous-jacent.
La fonctionnalité de géoréplication active pour créer une base de données secondaire synchronisée lisible en permanence pour une base de données primaire. La base de données secondaire accessible en lecture peut être dans la même région Azure que la base de données primaire ou, plus communément, dans une autre région. Ce type de base de données secondaire accessible en lecture est également appelé géosecondaire ou géoréplica.
Azure SQL Managed Instance
Pour la géoréplication dans des régions non appairées avec Azure SQL Managed Instance, vous pouvez utiliser :
- La fonctionnalité de groupe de basculement qui est répliquée dans n’importe quelle combinaison de régions Azure sans dépendance avec le stockage GRS sous-jacent.
Stockage Azure
Pour mettre en œuvre la géoréplication dans des régions non appairées :
Pour le stockage d’objets Azure :
Pour le stockage blob et Azure Data Lake Storage, vous pouvez utiliser des outils tels que AZCopy ou Azure Data Factory.
Pour les comptes de stockage v2 universels et les comptes d’objets blob de blocs Premium, vous pouvez utiliser la réplication d’objets Stockage Azure.
Remarque
La réplication d’objets n’est pas prise en charge pour Azure Data Lake Storage.
Pour Azure NetApp Files (ANF), vous pouvez effectuer la réplication sur un ensemble de paires non standard en plus des paires de régions Azure. Reportez-vous à la rubrique Réplication interrégionale Azure NetApp Files.
Pour Azure Files :
Pour copier vos fichiers vers un autre compte de stockage dans une région différente, vous pouvez notamment utiliser les outils suivants :
Pour obtenir un exemple de script, consultez Procéder à la synchronisation entre deux partages de fichiers Azure pour la sauvegarde et la récupération d’urgence.
Pour synchroniser votre partage de fichiers Azure (point de terminaison cloud), un serveur de fichiers Windows local et un partage de fichiers monté s’exécutant sur une machine virtuelle dans une autre région Azure (le point de terminaison de votre serveur à des fins de récupération d’urgence), utilisez Azure File Sync.
Important
Vous devez désactiver la hiérarchisation cloud pour vous assurer que toutes les données sont présentes localement et approvisionner suffisamment de stockage sur la machine virtuelle Azure pour contenir l’intégralité du jeu de données. Pour s’assurer que les modifications sont répliquées rapidement dans la région secondaire, les fichiers ne doivent être accessibles et modifiés que sur le point de terminaison du serveur plutôt que dans Azure.
Azure Virtual Desktop
Pour la géoréplication dans des régions non appairées pour Azure Virtual Desktop, vous devez considérer le stockage et les machines virtuelles d’hôte de la session pour les profils utilisateur, les applications et les données. Microsoft gère le plan de contrôle Azure Virtual Desktop qui est globalement distribué et hautement disponible.
Pour les hôtes de la session, vous pouvez déployer des machines virtuelles dans plusieurs régions dans un scénario actif-actif ou les répliquer dans l’ensemble des régions en utilisant Azure Site Recovery dans un scénario actif-passif.
Pour le stockage, consultez Stockage Azure.
Pour découvrir plus d’informations, consultez Continuité d'activité et reprise d'activité (BCDR) multirégion pour Azure Virtual Desktop et Architecture et résilience du service Azure Virtual Desktop.
Machines virtuelles Azure
Pour mettre en œuvre la géoréplication dans des régions non appairées, utilisez le service Azure Site Recovery. Azure Site Recovery est le service de récupération d’urgence d’Azure conçu pour assurer la continuité d’activité et la reprise d’activité en répliquant les charges de travail de l’emplacement principal vers un emplacement secondaire. L’emplacement secondaire peut être une région non appairée si elle est prise en charge par Azure Site Recovery.