Partager via


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 :

Stockage Azure

Pour mettre en œuvre la géoréplication dans des régions non appairées :

  • Pour le stockage d’objets 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 :

    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.

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.

Étapes suivantes