DR pour les services PaaS

La récupération d’urgence pour les services IaaS (VMs) implique généralement Azure Site Recovery, qui réplique l’ensemble du système d’exploitation et des disques de données vers une région secondaire. Les services PaaS utilisent des modèles DR différents, car l’infrastructure sous-jacente est gérée par Microsoft. Pour le PaaS, la DR est généralement configurée au niveau de la couche de données : les données sont répliquées vers une région secondaire tandis que la plateforme démarre automatiquement.

Azure SQL Database fournit une haute disponibilité intégrée au niveau des zones au sein d’une même région. Pour la DR interrégionale, il propose deux fonctionnalités essentielles : la géoréplication active (bases de données secondaires accessibles en lecture dans jusqu’à quatre autres régions) et les groupes de basculement automatique (basculement automatisé avec un point de terminaison d’écoute unique). Ces fonctionnalités sont configurées au niveau de la base de données ou du serveur, sans nécessiter Azure Site Recovery.

Les groupes de basculement automatique ajoutent une automatisation et un point de terminaison de connexion unique par-dessus la géoréplication. Vous configurez un groupe sur le serveur primaire, ajoutez le serveur secondaire et définissez une période de grâce — le délai pendant lequel Azure attend la récupération du serveur primaire avant de déclencher le basculement automatique. Les applications se connectent au point de terminaison d’écoute (par exemple, mygroup.database.windows.net) et sont automatiquement redirigées après le basculement, sans modification des chaînes de connexion.

La géoréplication d’Azure SQL Database est asynchrone : les transactions sont validées sur le serveur primaire, puis répliquées sur le serveur secondaire. Cela entraîne un léger décalage de réplication, généralement inférieur à 5 secondes dans des conditions normales. Le RPO de la géoréplication SQL est donc d’environ 5 secondes dans la plupart des scénarios, ce qui la rend adaptée aux charges de travail de niveaux 1 et 2 nécessitant une perte de données très faible.

Tous les niveaux d’Azure SQL Database incluent des sauvegardes automatisées : sauvegardes complètes chaque semaine, sauvegardes différentielles toutes les 12 heures et sauvegardes du journal des transactions toutes les 5 à 12 minutes. Cela permet la restauration à un instant donné (PITR) — restaurer la base de données à n’importe quelle seconde de la période de rétention (7 à 35 jours pour Standard/General Purpose, jusqu’à 35 jours pour Business Critical). La PITR est utile pour récupérer des données supprimées ou corrompues accidentellement.

Azure Cosmos DB avec des écritures multirégions fournit un RPO presque nul pour les applications mondiales. Toutes les régions configurées peuvent accepter simultanément les opérations d’écriture, et Cosmos DB synchronise automatiquement les données à l’aide de son protocole de réplication propriétaire. En cas de défaillance d’une région, le trafic est automatiquement acheminé vers les régions saines restantes, sans nécessiter de basculement manuel, ce qui permet d’atteindre un RTO et un RPO proches de zéro.

Azure App Service est lui-même sans état (le code de l’application est déployé depuis un système de contrôle de version ou un fichier ZIP). Pour la DR, l’attention porte sur la couche de données (base de données et stockage d’objets blob). App Service peut être redéployé rapidement dans une région secondaire via un pipeline CI/CD. Toutefois, vous devez vous assurer que votre domaine personnalisé, vos certificats TLS et vos paramètres d’application sont répliqués ou scriptés afin de pouvoir être recréés rapidement dans la région secondaire.

Azure Blob Storage avec Geo-Redundant Storage (GRS) réplique automatiquement les données vers une région secondaire située à plusieurs centaines de kilomètres. Les données sont répliquées de manière asynchrone (RPO généralement inférieur à 15 minutes). Read-Access GRS (RA-GRS) permet de lire les données depuis le point de terminaison secondaire même avant le déclenchement du basculement, ce qui est utile pour les charges de travail d’analyse et de création de rapports lors d’une panne de la région primaire.

Azure Functions sont sans état par conception, ce qui les rend faciles à redéployer. Pour la DR, déployez la même application de fonctions dans une région secondaire et utilisez Traffic Manager pour acheminer les déclencheurs HTTP entre les régions. Pour les déclencheurs non HTTP (Service Bus, Event Grid), configurez la source des messages pour les distribuer vers les deux régions, ou demandez à la région secondaire d’interroger la même source. L’état des fonctions dans Durable Functions est stocké dans Azure Storage : assurez-vous donc que ce stockage utilise GRS.

Utilisez la géoréplication active lorsque vous avez besoin d'un contrôle précis — par exemple pour diriger le trafic de lecture vers un réplica secondaire afin d'améliorer les performances, ou pour gérer indépendamment plusieurs réplicas secondaires dans différentes régions. Utilisez les groupes de basculement automatique lorsque vous privilégiez la simplicité : un point de terminaison d'écoute unique, un basculement automatique déclenché par un minuteur et une orchestration intégrée du processus de basculement, sans intervention manuelle.

La reprise après sinistre avec PaaS est souvent moins coûteuse que celle fondée sur des VM, pour plusieurs raisons. La géoréplication de SQL Database facture uniquement le stockage et le calcul du réplica secondaire ; vous ne payez pas la licence d'un système d'exploitation de VM complet. Azure Cosmos DB facture les unités de requête provisionnées dans chaque région. Azure Storage GRS augmente le coût du stockage d'environ 2 fois. En revanche, les VM répliquées par ASR nécessitent de prendre en charge l'intégralité des coûts de calcul, de stockage et de licences dans la région secondaire.

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris que la reprise après sinistre avec PaaS se concentre sur la couche de données plutôt que sur la réplication des VM ; que les groupes de basculement automatique d'Azure SQL fournissent un point de terminaison d'écoute unique avec un basculement automatisé ; et que les écritures multirégions de Cosmos DB offrent un RTO et un RPO presque nuls pour les applications internationales. Nous allons maintenant découvrir les cadres de conformité Azure et le modèle de responsabilité partagée.