Récupérer après une interruption de service à l’échelle de la région

Azure est divisé physiquement et logiquement en unités appelées régions. Une région se compose d’un ou plusieurs centres de données très proches les uns des autres. Nombre de régions et produits prennent également en charge les zones de disponibilité, qui peuvent être utilisées pour fournir davantage de résilience contre les pannes dans un centre de données spécifique. Envisagez d’utiliser des régions avec des zones de disponibilité pour améliorer le disponibilité de votre solution.

Exceptionnellement, il est possible que les sites de toute une région ou zone de disponibilité deviennent inaccessibles, par exemple en raison de défaillances au niveau du réseau. Plus encore, les installations peuvent être entièrement perdues, par exemple à la suite d'une catastrophe naturelle. Les fonctionnalités d’Azure permettent de créer des applications distribuées entre les zones et régions. Cette distribution permet de réduire au minimum le risque qu’une défaillance dans une zone ou région spécifique affecte d’autres zones ou régions.

Services cloud

Gestion des ressources

Vous pouvez distribuer des instances de calcul entre les régions en créant un service cloud distinct dans chaque région cible et en publiant le package de déploiement pour chaque service cloud. Toutefois, la répartition du trafic entre les services cloud dans différentes régions doit être effectuée par le développeur de l’application ou par un service de gestion du trafic.

Lors de la planification de la capacité, il est important de déterminer à l’avance le nombre d’instances de rôle de réserve à déployer pour la récupération d’urgence. Un déploiement secondaire à pleine échelle permet de garantir que la capacité est déjà disponible au moment voulu ; toutefois, le coût est alors doublé. Un modèle courant consiste à disposer d’un petit déploiement secondaire suffisamment grand pour exécuter les services critiques. Ce petit déploiement secondaire vous permettra de réserver de la capacité et de tester la configuration de l’environnement secondaire.

Équilibrage de la charge.

Pour équilibrer la charge de trafic entre les régions, il est nécessaire d’utiliser une solution de gestion du trafic. Azure fournit Azure Traffic Manager. Vous pouvez également utiliser des services tiers qui offrent des fonctionnalités de gestion de trafic similaires.

Stratégies

De nombreuses autres stratégies sont disponibles pour implémenter un système de calcul distribué entre les régions. Celles-ci doivent être adaptées aux exigences professionnelles et aux circonstances de la demande. À un niveau élevé, les approches peuvent être divisées selon les catégories suivantes :

• Redéploiement en cas de sinistre : Dans cette approche, l’application est redéployée de toutes pièces au moment de l’incident. Ceci est approprié pour les applications non critiques qui ne nécessitent pas une garantie de délai de récupération.

• Rechange semi-automatique (actif/passif) : un service hébergé secondaire est créé dans une autre région et des rôles sont déployés pour garantir une capacité minimale ; cependant, les rôles ne reçoivent pas de trafic de production. Cette approche est utile pour les applications qui n’ont pas été conçues pour distribuer le trafic entre les régions.

• Échange à chaud (actif/actif) : l’application est conçue pour recevoir la charge de production dans plusieurs régions. Les services cloud de chaque région peuvent être configurés pour une capacité plus élevée que celle nécessaire à la récupération d’urgence. Les services cloud peuvent également effectuer un scale-out selon les besoins au moment de l’incident et du basculement. Cette approche nécessite un investissement important en matière de conception des applications mais elle présente des avantages significatifs, comme par exemple un délai de récupération rapide et garanti, un test continu de tous les emplacements de récupération et une utilisation efficace de la capacité.

Ce document ne fournit pas de description complète de la conception distribuée. Pour plus d’informations, consultez la section Récupération d’urgence et haute disponibilité des applications Azure.

Machines virtuelles

La récupération des machines virtuelles Infrastructure as a Service (IaaS) est similaire à la récupération de calcul Platform as a Service (PaaS) à bien des égards. Il existe toutefois des différences importantes, étant donné qu’une machine virtuelle IaaS est composée de la machine virtuelle et du disque de machine virtuelle.

• Utilisez Azure Backup pour créer des sauvegardes cohérentes des applications dans différentes régions. Azure Backup permet aux clients de créer des sauvegardes cohérentes des applications sur plusieurs disques de machine virtuelle et de prendre en charge la réplication des sauvegardes entre différentes régions. Vous pouvez effectuer cette opération en choisissant de géorépliquer le coffre de sauvegarde au moment de la création. La réplication du coffre de sauvegarde doit être configurée au moment de la création. Elle ne peut pas être définie ultérieurement. Si une région est perdue, Microsoft met les sauvegardes à disposition des clients. Les clients sont en mesure d’effectuer une restauration à partir des points de restauration configurés.

• Séparez le disque de données du disque du système d’exploitation. Pour les machines virtuelles IaaS, il est important de garder en mémoire que vous ne pouvez pas modifier le disque du système d’exploitation sans recréer la machine virtuelle. Ce n’est pas un problème si votre stratégie de récupération après un incident est le redéploiement. En revanche, cette méthode peut poser problème si vous utilisez l’approche de rechange semi-automatique pour réserver de la capacité. Pour implémenter correctement cette stratégie, vous devez disposer du disque du système d’exploitation déployé aux emplacements principaux et secondaires et les données d’application doivent être stockées sur un lecteur distinct. Si possible, utilisez une configuration de système d’exploitation standard qui peut être fournie aux deux emplacements. Après un basculement, vous devez associer le lecteur de données à vos machines virtuelles IaaS existantes dans le contrôleur de domaine secondaire. Utilisez AzCopy pour copier des instantanés du ou des disques de données sur un site distant.

• Ayez conscience des problèmes potentiels de cohérence après un basculement géographique de plusieurs disques de machines virtuelles. Les disques de machine virtuelle sont implémentés en tant qu’objets blob Azure Storage et ont les mêmes caractéristiques de géoréplication. Si Azure Backup n’est pas utilisé, il n’existe aucune garantie de cohérence entre les disques, étant donné que la géoréplication est asynchrone et que la réplication se fait de manière indépendante. Chaque disque de machine virtuelle se trouve dans un état de cohérence en cas d’incident après un basculement géographique, mais cette cohérence n’est pas assurée entre les disques. Dans certains cas, cela peut entraîner des problèmes (par exemple, en cas d’entrelacement de disques).

• Utiliser Azure Site Recovery pour répliquer des applications entre les régions. Grâce à Azure Site Recovery, les clients n’ont pas à se soucier de séparer les disques de données des disques de système d’exploitation ou de problèmes potentiels de cohérence. Azure Site Recovery reproduit les charges de travail exécutées sur des machines physiques et virtuelles à partir d’un site principal (localement ou dans Azure) vers un emplacement secondaire (dans Azure). Lorsqu’une panne se produit sur le site principal du client, un basculement peut être déclenché pour ramener rapidement le client à un état opérationnel. Une fois que l’emplacement principal est rétabli, le client peut alors revenir en arrière. Il peut facilement effectuer une reproduction à l’aide de points de récupération avec des clichés instantanés compatibles avec l’application. Ces clichés instantanés récupèrent les données de disque, l’ensemble des données en mémoire et toutes les transactions en cours de traitement. Azure Site Recovery permet au client de maintenir les objectifs de délai de récupération (RTO) et les objectifs de point de récupération (RPO) dans les limites fixées par l’organisation. Le client peut également exécuter facilement des exercices de récupération d’urgence sans affecter les applications en production. À l’aide de plans de récupération, le client peut séquencer le basculement et la récupération d’applications multiniveaux s’exécutant sur plusieurs machines virtuelles. Il peut regrouper des machines dans un plan de récupération et ajouter éventuellement des scripts et des actions manuelles. Les plans de récupération peuvent être intégrés à des runbooks Azure Automation.

Stockage

Récupération à l’aide du stockage géoredondant des objets blob, des tables, des files d’attente et du stockage sur disque de machine virtuelle

Dans Azure, les objets blob, tables, files d’attente et disques de machine virtuelle sont tous géorépliqués par défaut. Cela s’appelle le stockage géoredondant (GRS). GRS réplique les données de stockage dans un centre de données couplé, situé à des centaines de kilomètres, dans une région géographique donnée. GRS est conçu pour fournir une durabilité supplémentaire en cas d’incident grave dans le centre de données. Microsoft contrôle quand un basculement a lieu et le basculement est réservé aux incidents majeurs pour lesquels on considère qu’il est impossible de restaurer l’emplacement principal d’origine dans un délai raisonnable. Dans certains cas, cela peut prendre plusieurs jours. Les données sont généralement répliquées en quelques minutes, même si l’intervalle de synchronisation n’est pas encore couvert par un contrat de niveau de service.

En cas de basculement géographique, il n’y a aucune modification de l’accès du compte (l’URL et la clé du compte ne sont pas modifiées). Toutefois, le compte de stockage sera dans une région différente après le basculement. Cela peut affecter les applications qui nécessitent une affinité régionale avec leur compte de stockage. Même pour les services et les applications qui n'ont pas besoin d'un compte de stockage dans le même centre de données, la latence entre les centres de données peut être une raison impérieuse de déplacer temporairement le trafic vers la région de basculement. Cela peut jouer un rôle important dans la stratégie globale de récupération d’urgence.

Outre le basculement automatique offert par GRS, Azure propose un service qui vous donne un accès en lecture à la copie de vos données à l’emplacement de stockage secondaire. Il s’agit du stockage géoredondant avec accès en lecture (RA-GRS).

Pour plus d’informations sur le stockage GRS et RA-GRS, consultez Réplication Azure Storage.

Mappages de régions de géoréplication

Il est important de savoir où vos données sont géorépliquées afin de savoir où déployer les autres instances de vos données qui nécessitent une affinité régionale avec votre stockage. Pour plus d’informations, consultez la section Régions jumelées Azure.

Tarification de la géoréplication

La géoréplication est incluse dans le tarif actuel d’Azure Storage. Il s’agit du stockage géoredondant (GRS). Si vous ne souhaitez pas que vos données soient géorépliquées, vous pouvez désactiver la géoréplication pour votre compte. Il s’agit du stockage localement redondant (LRS), qui est facturé à un prix réduit par rapport au GRS.

Déterminer si un géo-basculement s’est produit

Si un basculement géographique se produit, il est publié dans le tableau de bord d’état du service Azure. Toutefois, les applications peuvent implémenter un moyen automatisé pour détecter ces basculements géographiques en analysant la région géographique de leur compte de stockage. Cela peut servir à déclencher d’autres opérations de récupération telles que l’activation des ressources de calcul dans la région géographique vers laquelle leur stockage a été déplacé.

Base de données

SQL Database

Azure SQL Database fournit deux types de restauration : la géorestauration et la géoréplication active.

Géorestauration

La géorestauration est également disponible avec des bases de données De base, Standard et Premium. Elle fournit l’option de récupération par défaut lorsque la base de données est indisponible en raison d’un incident dans la région où la base de données est hébergée. À l’image de la restauration à un instant dans le passé, la géorestauration s’appuie sur les sauvegardes de base de données dans un stockage Azure géoredondant. Elle restaure à partir de la copie de sauvegarde géorépliquée et est par conséquent résistante aux pannes de stockage dans la région primaire. Pour plus d’informations, consultez Restaurer une base de données Azure SQL ou basculer vers une base de données secondaire.

Géoréplication active

La géoréplication active est disponible avec tous les niveaux de bases de données. Elle est conçue pour les applications qui ont des exigences de récupération plus agressives que celles proposées par la géorestauration. À l’aide de la géoréplication active, vous pouvez créer jusqu’à quatre répliques secondaires sur des serveurs dans différentes régions. Vous pouvez lancer le basculement sur n’importe quelle base de données secondaire. En outre, la géoréplication active peut être utilisée pour prendre en charge les scénarios de mise à niveau ou de déplacement d’application, ainsi que l’équilibrage de charge pour les charges de travail en lecture seule. Pour plus de détails, consultez Configurer la géoréplication active pour Azure SQL Database dans le portail Azure et initier le basculement. Pour plus d’informations sur la conception, l’implémentation et la mise à niveau d’applications sans interruption, consultez Conception de services disponibles à l’échelle mondiale à l’aide d’Azure SQL Database et Gestion des mises à niveau propagées des applications cloud à l’aide de la géoréplication active de SQL Database.

SQL Server sur les machines virtuelles Azure

Plusieurs options sont disponibles pour la récupération et la haute disponibilité de SQL Server 2012 (et version ultérieure) sur Azure Virtual Machines. Pour plus d’informations, consultez Haute disponibilité et récupération d’urgence pour SQL Server dans Azure Virtual Machines.

Autres services de plateforme Azure

Lorsque vous tentez d’exécuter votre service cloud dans plusieurs régions Azure, vous devez prendre en compte les implications pour chacune de vos dépendances. Dans les sections suivantes, les instructions spécifiques au service partent du principe que vous devez utiliser le même service Azure dans un autre centre de données Azure. Cela nécessite d’effectuer des tâches de configuration et de réplication des données.

Service Bus

Azure Service Bus utilise un espace de noms unique qui ne couvre pas les régions Azure. La première exigence consiste donc à configurer les espaces de nom du Service Bus nécessaires dans l’autre région. Toutefois, il faut également réfléchir à la durabilité des messages mis en file d’attente. Il existe plusieurs stratégies de réplication des messages entre les régions Azure. Pour plus d’informations sur ces stratégies de réplication et d’autres stratégies de récupération d’urgence, consultez Bonnes pratiques pour protéger les applications contre les pannes de Service Bus et les sinistres.

App Service

Pour migrer une application Azure App Service, comme Web Apps ou Mobile Apps, vers une région Azure secondaire, vous devez disposer d’une sauvegarde du site web disponible pour la publication. Si la panne ne concerne pas l’ensemble du centre de données Azure, vous pouvez utiliser un FTP pour télécharger une sauvegarde récente du contenu du site. Créez ensuite une nouvelle application dans l’autre région, sauf si vous l’avez fait précédemment pour réserver de la capacité. Publiez le site dans la nouvelle région et apportez les modifications nécessaires à la configuration. Ces modifications peuvent inclure des chaînes de connexion de base de données ou d’autres paramètres régionaux. Si nécessaire, ajoutez le certificat SSL du site et modifiez l’enregistrement DNS CNAME afin que le nom de domaine personnalisé pointe vers l’URL de l’application web Azure redéployée.

HDInsight

Par défaut, les données associées à HDInsight sont stockées dans Azure Blob Storage. HDInsight nécessite qu’un cluster Hadoop traitant des tâches MapReduce se trouve dans la même région que le compte de stockage qui contient les données en cours d’analyse. Si vous utilisez la fonctionnalité de géoréplication disponible dans Azure Storage, vous pouvez accéder à vos données dans la région secondaire dans laquelle les données ont été répliquées si pour une raison quelconque la région primaire n’est plus disponible. Vous pouvez créer un nouveau cluster Hadoop dans la région où les données ont été répliquées et poursuivre leur traitement.

SQL Reporting

À ce stade, la récupération après la perte d’une région Azure requiert plusieurs instances SQL Reporting dans différentes régions Azure. Ces instances SQL Reporting doivent accéder aux mêmes données et ces dernières doivent avoir leur propre plan de récupération en cas d’incident. Vous pouvez également conserver des copies de sauvegarde externes du fichier RDL pour chaque rapport.

Media Services

Azure Media Services adopte une approche de récupération différente pour l’encodage et le streaming. En règle générale, le streaming est plus critique pendant une panne régionale. Pour vous préparer à cette éventualité, vous devez disposer d’un compte Media Services dans deux régions Azure différentes. Le contenu encodé doit se trouver dans les deux régions. En cas de panne, vous pouvez rediriger le trafic du streaming vers l’autre région. L’encodage peut être effectué dans n’importe quelle région Azure. Si l’encodage est urgent, par exemple lors du traitement d’événements en direct, vous devez être prêt à envoyer des tâches à un autre centre de données en cas de panne.

Réseau virtuel

Les fichiers de configuration constituent le moyen le plus rapide de configurer un réseau virtuel dans une autre région Azure. Après avoir configuré le réseau virtuel dans la région Azure principale, exportez les paramètres de réseau virtuel pour le réseau actuel dans un fichier de configuration réseau. Si une panne se produit dans la région principale, restaurez le réseau virtuel à partir du fichier de configuration stocké. Configurez ensuite les autres services cloud, les machines virtuelles ou les paramètres entre sites locaux pour utiliser le nouveau réseau virtuel.
Il existe des ressources liées au réseau virtuel à prendre en compte (par exemple NSG, DNS, Tables de routage). La méthode décrite dans Infrastructure en tant que code est un moyen de générer le même environnement systématiquement, ce qui vous permet de le déployer dans une nouvelle région.

Listes de contrôle pour la récupération d’urgence

Liste de contrôle de Cloud Services

1. Consultez la section Services cloud de ce document.
2. Créez une stratégie de récupération d’urgence entre les régions.
3. Maîtrisez les inconvénients de la réservation de capacité dans d’autres régions.
4. Utilisez les outils de routage du trafic, notamment Azure Traffic Manager.

Liste de contrôle de Virtual Machines

1. Consulter la section Machines virtuelles de ce document.
2. Utilisez Azure Backup pour créer des sauvegardes cohérentes des applications dans différentes régions.

Liste de contrôle du stockage

1. Consultez la section Stockage de ce document.
2. Ne désactivez pas la géoréplication des ressources de stockage.
3. Maîtrisez l’autre région pour la géoréplication en cas de basculement.
4. Créez des stratégies de sauvegarde personnalisées pour les stratégies de basculement contrôlées par l’utilisateur.

Liste de contrôle de la Base de données SQL

1. Consultez la section Base de données SQL de ce document.
2. Utilisez la géo-restauration ou la géoréplication en fonction des besoins.

Liste de contrôle de SQL Server sur les machines virtuelles

1. Consultez la section SQL Server sur Virtual Machines de ce document.
2. Utilisez des groupes de disponibilité AlwaysOn entre les régions ou la mise en miroir de bases de données.
3. Ou utilisez la sauvegarde et la restauration dans le stockage d’objets blob.

Liste de contrôle de Service Bus

1. Consultez la section Service Bus de ce document.
2. Configurez un espace de noms Service Bus dans une autre région.
3. Prenez en compte les stratégies de réplication personnalisées pour les messages entre les régions.

Liste de vérification App Service

1. Consultez la section App Service de ce document.
2. Gérez les sauvegardes de sites en dehors de la région principale.
3. Si une panne est partielle, tentez de récupérer le site actuel via FTP.
4. Envisagez de déployer le site sur un nouveau site ou un site existant dans une autre région.
5. Planifiez les modifications de configuration pour les applications et les enregistrements DNS CNAME.

Liste de contrôle de HDInsight

1. Consultez la section HDInsight de ce document.
2. Créez un cluster Hadoop dans la région contenant les données répliquées.

Liste de contrôle de SQL Reporting

1. Consultez la section SQL Reporting de ce document.
2. Conservez une autre instance SQL Reporting dans une région différente.
3. Conservez un plan distinct pour répliquer la cible dans cette région.

Liste de contrôle de Media Services

1. Consultez la section Media Services de ce document.
2. Créez un compte Media Services dans une autre région.
3. Encodez le même contenu dans les deux régions pour prendre en charge le basculement du streaming.
4. Envoyez des travaux d’encodage dans une autre région en cas d’interruption de service.

Liste de contrôle du réseau virtuel

1. Consultez la section Réseau virtuel de ce document.
2. Utilisez les paramètres du réseau virtuel qui ont été exportés pour le recréer dans une autre région.