VENTES: 1-800-867-1389

Aide de référence technique pour la continuité des activités Azure

Mis à jour: juin 2014

Dernière mise à jour : mai 2014

Première date de publication : mars 2012

Auteur : Patrick Wickline, Jason Roth

Contributeurs et relecteurs : Luis Carlos Vargas Herring, Drew McDaniel, David Magar, Ganesh Srinivasan, Milan Gada, Nir Mashkowski ,Harsh Mittal, Sasha Nosov, Selcin Turkarslan, Cephas Lin, Cheryl McGuire, Bill Mathers, Mandi Ohlinger, Sidney Higa, Michael Green, Heidi Steen, Matt Winkler, Shayne Burgess, Larry Franks, Brad Severtson, Yavor Georgiev, Glenn Gailey, Tim Ammann, Ruppert Koch, Seth Manheim, Abhinav Gupta, Steve Danielson, Corey Sanders, John Deutscher

Pour respecter les exigences en matière de haute disponibilité et de récupération d'urgence, deux types de connaissances sont nécessaires : 1) compréhension technique détaillée des fonctionnalités de la plateforme cloud et 2) savoir générer correctement l'architecture d'un service distribué. Ce document traite des fonctionnalités et des limitations de la plateforme Azure par rapport à la continuité des activités de l'entreprise. Bien qu'il touche également les modèles d'architecture et de conception, ils n'en font pas l'objet. Pour obtenir des instructions de conception, consultez la documentation indiquée dans la section Ressources supplémentaires.

Ce document comprend les sections suivantes :

  • 1. Récupération après défaillances locales  : le matériel physique (par exemple, les lecteurs, les serveurs et les périphériques réseau) peuvent rencontrer une erreur et les ressources peuvent être utilisées intégralement lorsque des pics de charge se produisent. Cette section décrit les fonctionnalités fournies par Azure pour assurer une haute disponibilité dans ces conditions.

  • 2. Récupération après la perte d'une région Azure : les défaillances étendues sont rares, mais possibles. Des régions entières peuvent être isolées en raison de défaillances réseau, ou être endommagées physiquement en raison de catastrophes naturelles. Cette section explique comment utiliser les fonctionnalités de Azure pour créer des applications qui couvrent diverses régions géographiques.

  • 3. Récupération du site vers Azure : le cloud modifie de manière significative la dimension économique de la récupération d'urgence, et permet aux organisations d'utiliser Azure pour créer un deuxième site de récupération. Cela peut être effectué à un coût très inférieur à celui de création et de gestion d'un centre de données secondaire. Cette section présente les fonctionnalités fournies par Azure pour étendre un centre de données au cloud.

  • 4. Récupération de données endommagées ou de suppression par erreur : les applications peuvent avoir des bogues qui endommagent les données et les opérateurs peuvent supprimer des données importantes par erreur. Cette section présente les fonctionnalités fournies par Azure pour la sauvegarde et la restauration des données à une date et heure précédentes.

  • 5. Ressources supplémentaires : autres ressources importantes couvrant la disponibilité et la récupération d'urgence dans Azure.

Il existe deux menaces principales à la disponibilité des applications : la défaillance des périphériques, tels que les lecteurs et les serveurs, et l'insuffisance des ressources critiques, telles que les ressources de calcul dans des conditions de charge maximale. Azure fournit une combinaison de gestion des ressources, d'élasticité, d'équilibrage de charge et de partitionnement pour assurer une haute disponibilité dans ces conditions. Certaines de ces fonctionnalités sont exécutées automatiquement pour tous les services de cloud computing ; toutefois, dans certains cas, le développeur d'applications doit effectuer un travail supplémentaire pour en tirer parti.

Tous les services de cloud computing hébergés par Azure sont des collections d'un ou plusieurs rôles Web ou de travail. Une ou plusieurs instances d'un rôle donné peuvent fonctionner simultanément. Le nombre d'instances est déterminé par la configuration. Les instances de rôle sont surveillées et gérées avec un composant appelé contrôleur de structure. Le contrôleur de structure détecte et répond aux défaillances logicielles et matérielles automatiquement.

  • Chaque instance de rôle s'exécute dans sa propre machine virtuelle et communique avec son contrôleur de structure via un agent invité. L'agent invité collecte les métriques de ressource et de nœud, notamment l'utilisation de la machine virtuelle, l'état, les journaux, l'utilisation des ressources, les exceptions et les conditions d'échec. Le contrôleur de structure interroge l'agent invité à intervalles configurables, et redémarre la machine virtuelle si l'agent invité ne répond pas.

  • En cas de défaillance matérielle, le contrôleur de structure associé déplace toutes les instances de rôle affectées vers un nouveau nœud de matériel et reconfigure le réseau de façon à acheminer le trafic vers cet emplacement.

Pour tirer parti de ces fonctionnalités, les développeurs doivent veiller à ce que tous les rôles de service évitent de stocker l'état sur les instances de rôle. Au lieu de cela, toutes les données persistantes doivent être accessibles à partir d'un stockage durable, tel que les services de stockage Azure ou Base de données SQL Azure. Cela permet aux demandes d'être traitées par tous les rôles. Cela signifie également que les instances de rôle peuvent être hors service à tout moment sans créer d'incohérences dans l'état transitoire ou persistant du service.

Le stockage de l'état en externe dans les rôles comporte plusieurs implications. Il implique, notamment, que toutes les modifications associées à une table de stockage Azure soient apportées dans une seule transaction de groupe d'entités, si possible. Naturellement, il n'est pas toujours possible d'effectuer toutes les modifications dans une même transaction. Un soin particulier doit être apporté pour garantir que les défaillances d'instance de rôle ne posent pas de problèmes quand elles interrompent des opérations longues qui couvrent au moins deux mises à jour vers l'état persistant du service. Si un autre rôle effectue une nouvelle tentative de cette opération, il doit anticiper et gérer le cas où le travail a été partiellement effectué.

Par exemple, pour un service qui partitionne des données entre plusieurs magasins, si un rôle de travail connaît une défaillance lors du déplacement d'une partition, le déplacement de la partition risque de ne pas se terminer, ou peut être répété depuis le début par un autre rôle de travail, ce qui risque d'entraîner des données orphelines ou des données endommagées. Pour éviter les problèmes, les opérations longues doivent être idempotentes (c.-à-d., répétables sans effet secondaire) et/ou redémarrables de façon incrémentielle (c.-à-d., capables de continuer à partir du point d'échec le plus récent).

  • Pour être idempotente, une opération longue doit avoir le même effet quel que soit le nombre de fois où elle est exécutée, même lorsqu'elle est interrompue lors de l'exécution.

  • Pour être redémarrable de façon incrémentielle, une opération longue doit comprendre une séquence de plus petites opérations atomiques, et elle doit enregistrer la progression dans un stockage durable, afin que chaque appel suivant reprenne là où son prédécesseur a cessé.

Enfin, toutes les opérations longues doivent être appelées de façon répétée jusqu'à ce qu'elles réussissent. Par exemple, une opération de déploiement peut être placée dans une file d'attente Azure, et être retirée de la file d'attente par un rôle de travail uniquement lorsqu'elle réussit. Le garbage collection peut être nécessaire pour nettoyer des données créées par des opérations interrompues.

Le nombre initial d'instances en cours d'exécution pour chaque rôle est déterminé dans la configuration de chaque rôle. Les administrateurs doivent initialement configurer chacun des rôles de façon à ce qu'ils s'exécutent avec au moins deux instances selon la charge attendue. Cependant, les instances de rôle peuvent facilement être mises à l'échelle à mesure que les modèles d'utilisation évoluent. Cela peut être effectué avec le portail Azure, Windows PowerShell, l'API de gestion des services ou des outils tiers. Le contrôleur de structure configure automatiquement toutes les nouvelles instances et les insère dans le programme d'équilibrage de charge pour ce rôle.

Grâce à la mise à l'échelle automatique Azure (aperçu), Azure met automatiquement à l'échelle vos rôles en fonction de la charge. La mise à l'échelle automatique peut également être intégrée et configurée par programme pour un service cloud avec une infrastructure telle que le bloc de mise à l'échelle automatique des applications (wasabi).

Les contrôleurs de structure utilisent deux types de partitions : domaines de mise à niveau et domaines d'erreur

  • Un domaine de mise à niveau est utilisé pour mettre à niveau les instances de rôle d'un service dans des groupes. Azure déploie les instances de service dans plusieurs domaines de mise à niveau. Pour une mise à niveau sur place, le contrôleur de structure regroupe toutes les instances dans un domaine de mise à niveau, les met à niveau, puis les redémarre avant de passer au domaine de mise à niveau suivant. Cette approche empêche l'ensemble du service d'être indisponible pendant la mise à niveau.

  • Un domaine d'erreur définit les points potentiels de défaillance matérielle ou réseau. Pour les rôles dotés de plusieurs instances, le contrôleur de structure garantit que les instances sont réparties sur plusieurs domaines d'erreur, afin d'éviter que des défaillances matérielles isolées interrompent le service. L'exposition à une défaillance du serveur et du cluster dans Azure est régie par les domaines d'erreur.

Conformément au Contrat de niveau de service (SLA) Azure, si vous déployez au moins deux instances de rôle Web dans différents domaines d'erreur et de mise à niveau, nous garantissons qu'elles disposeront d'une connectivité durant au moins 99,95 % du temps. Contrairement aux domaines de mise à jour, il n'existe aucun moyen de contrôler le nombre de domaines d'erreur. Azure alloue automatiquement des domaines d'erreur et distribue les instances de rôle entre eux. Au moins les deux premières instances de chaque rôle sont placées dans différents domaines d'erreur et de mise à niveau afin de garantir que les rôles dotés d'au moins deux instances satisferont le contrat SLA. Le diagramme suivant illustre ce concept.

Tout le trafic entrant vers un rôle Web passe par un programme d'équilibrage de charge sans état, qui distribue les requêtes des clients entre les instances de rôle. Les instances de rôle n'ont pas d'adresses IP publiques et ne sont pas directement adressables à partir d'Internet. Les rôles Web sont sans état, afin que toute demande du client puisse être routée vers une instance de rôle. Un événement StatusCheck est déclenché toutes les 15 secondes. Il peut être utilisé pour indiquer si le rôle est prêt à accepter le trafic, ou est occupé et doit être extrait de la rotation du programme d'équilibrage de charge.

Les machines virtuelles Azure sont différentes des rôles de calcul PaaS à plusieurs égards en ce qui concerne la haute disponibilité. Parfois, vous devez effectuer un travail supplémentaire pour assurer une haute disponibilité.

Contrairement aux instances de rôle PaaS, les données stockées sur les lecteurs de machine virtuelle sont persistantes même lorsque la machine virtuelle est déplacée. Les machines virtuelles Azure utilisent des disques de machine virtuelle qui existent en tant qu'objets blob dans le stockage Azure. En raison des caractéristiques de disponibilité du stockage Azure, les données stockées sur les lecteurs d'une machine virtuelle sont également hautement disponibles. Notez que le lecteur D: est l'exception à la règle. Il correspond au stockage physique sur le serveur monté en rack qui héberge la machine virtuelle, et ses données seront perdues si la machine virtuelle est recyclée. Ce lecteur est destiné au stockage temporaire uniquement.

Azure comprend naturellement les couches d'une application PaaS (rôle Web et rôle de travail) et peut donc les distribuer correctement entre les domaines d'erreur et de mise à jour. En revanche, les couches des applications IaaS doivent être définies manuellement à l'aide de groupes à haute disponibilité. Des groupes à haute disponibilité sont nécessaires pour un contrat SLA sous IaaS.

Dans le diagramme ci-dessus, la couche IIS et la couche SQL sont affectées à différents groupes à haute disponibilité. Cela garantit que toutes les instances de chaque couche disposent de la redondance matérielle en les distribuant entre les domaines d'erreur, et ne sont pas mises hors service pendant une mise à jour. Pour plus d'informations sur la configuration des groupes à haute disponibilité, consultez Gérer la disponibilité des machines virtuelles.

Si le trafic doit être réparti entre les machines virtuelles, vous devez regrouper les machines virtuelles dans un service cloud et équilibrer la charge entre un point de terminaison TCP ou UDP spécifique. Pour plus d'informations, consultez Équilibrage de charge des machines virtuelles. Si les machines virtuelles reçoivent l'entrée d'une autre source (par exemple, un mécanisme de mise en file d'attente), aucun programme d'équilibrage de charge n'est requis. Le programme d'équilibrage de charge utilise un contrôle d'intégrité de base pour déterminer si le trafic est envoyé au nœud. Il est également possible de créer vos propres sondes pour implémenter des métriques d'intégrité spécifiques à l'application qui déterminent si la machine virtuelle reçoit le trafic.

Le stockage Azure est le service de données durables de base pour Azure. Il fournit un espace de stockage pour les objets blob, les files d'attente, les tables et les disques de machine virtuelle. Il utilise une combinaison de gestion de la réplication et des ressources pour fournir une haute disponibilité dans un centre de données. Le contrat SLA de disponibilité du stockage Azure garantit qu'au moins 99,9 % des demandes d'ajout, de mise à jour, de lecture et de suppression de données correctement mises en forme seront traitées correctement, et que les comptes de stockage pourront se connecter à la passerelle Internet.

La durabilité des données pour le stockage Azure est facilité par la gestion de plusieurs copies de toutes les données sur des lecteurs différents situés dans des sous-systèmes de stockage physique entièrement indépendants dans la région. Les données sont répliquées de façon synchrone et toutes les copies sont validées avant acceptation de l'écriture. Le stockage Azure est fortement cohérent, ce qui signifie que les lectures sont garanties refléter les écritures les plus récentes. En outre, des copies des données sont analysées en continu pour détecter et corriger une altération binaire, une menace souvent négligée en matière d'intégrité des données stockées. Les services tirent parti de la réplication à l'aide du stockage Azure. Aucun travail supplémentaire n'est requis par le développeur de service pour la récupération après un échec local.

Les comptes de stockage créés après le 7 juin 2012 peuvent croître jusqu'à une taille de 200 To (la taille maximale précédente était de 100 To). Si de l'espace supplémentaire est nécessaire, les applications doivent être conçues pour exploiter plusieurs comptes de stockage.

Un disque de machine virtuelle est stocké en tant qu'objet blob de pages dans le stockage Azure. Cela lui confère les mêmes propriétés de durabilité et d'évolutivité que le stockage d'objets blob. Cette conception rend les données persistantes sur un disque de machine virtuelle, même en cas d'échec du serveur qui exécute la machine virtuelle et même si la machine virtuelle doit être redémarrée sur un autre serveur.

Base de données SQL Microsoft Azure fournit la base de données en tant que service, ce qui permet aux applications de rapidement mettre en service les bases de données relationnelles, d'y insérer des données et de les interroger. Elle fournit plusieurs des fonctionnalités SQL Server traditionnelles, tout en faisant abstraction de la charge du matériel, de la configuration, de la mise à jour corrective et de la résilience.

noteRemarque
Base de données SQL Azure ne fournit pas exactement les mêmes fonctionnalités que SQL Server, et est conçue pour répondre à un ensemble de conditions requises différentes spécialement adaptées aux applications de cloud (évolution élastique, base de données en tant que service pour réduire les coûts de maintenance, etc.). Pour plus d'informations, consultez Séries de données : SQL Server dans une machine virtuelle Azure et Base de données SQL.

Base de données SQL Azure fournit la résilience intégrée pour les défaillances au niveau du nœud. Toutes les écritures dans une base de données sont automatiquement répliquées vers plusieurs nœuds en arrière-plan à l'aide d'une technique de validation de quorum (le nœud principal et au moins un nœud secondaire doivent confirmer que l'activité est consignée dans le journal des transactions avant que la transaction soit considérée comme réussie et envoie un résultat). En cas de défaillance du nœud, la base de données bascule automatiquement vers l'un des réplicas secondaires. Cela provoque une interruption temporaire de connexion pour les applications clientes. C'est pourquoi, tous les clients Base de données SQL Microsoft Azure doivent implémenter une certaine forme de gestion des erreurs temporaires de connexion. Pour plus d'informations, consultez Utilisation du bloc d'applications de gestion d'erreurs transitoires avec SQL Azure.

Chaque base de données, lors de sa création, est configurée avec une limite de taille supérieure. La taille maximale actuellement disponible est de 150 Go. Lorsqu'une base de données atteint sa limite de taille supérieure, elle rejette les commandes INSERT ou UPDATE supplémentaires (les demandes et suppressions de données restent possibles).

Dans une base de données, Base de données SQL Microsoft Azure utilise une structure pour gérer les ressources. Toutefois, au lieu d'un contrôleur de structure, il utilise une topologie en anneau pour détecter les défaillances. Chaque réplica dans un cluster a deux voisins, et est chargé de détecter leur mise hors service. Lorsqu'un réplica est hors service, ses voisins déclenchent un agent de reconfiguration pour le recréer sur un autre ordinateur. La limitation du moteur est fournie pour assurer qu'un serveur logique n'utilise pas trop de ressources sur un ordinateur, ou n'atteint pas les limites physiques de l'ordinateur.

Si l'application nécessite plus que la limite de base de données de 150 Go, elle doit implémenter une approche avec montée en puissance parallèle. La montée en puissance parallèle avec Base de données SQL Microsoft Azure s'effectue par partitionnement manuel, ou sharding, des données entre plusieurs Base de données SQL Azure. Cette approche avec montée en puissance parallèle permet de bénéficier d'une croissance des coûts quasi linéaire avec la mise à l'échelle. La croissance élastique ou la capacité à la demande peut augmenter avec des coûts incrémentiels, car les bases de données sont facturées en fonction de la taille réelle moyenne utilisée par jour, et non pas de la taille possible maximale.

En installant SQL Server 2012 sur des machines virtuelles Azure (IaaS), vous tirez parti des fonctionnalités de disponibilité traditionnelles de SQL Server, telles que les groupes de disponibilité AlwaysOn ou la mise en miroir de bases de données. Notez que les machines virtuelles Azure, le stockage et le réseau ont des caractéristiques opérationnelles différentes par rapport à celles d'une infrastructure informatique non virtualisée sur site. Pour une implémentation réussie d'une solution SQL Server HADR dans Azure, vous devez comprendre ces différences et concevoir votre solution de façon à les gérer.

Lorsque vous implémentez une solution haute disponibilité dans Azure, le groupe à haute disponibilité dans Azure vous permet de placer les nœuds haute disponibilité dans des domaines d'erreur et des domaines de mise à niveau distincts. En clair, le groupe à haute disponibilité est un concept Azure. Pour plus d'informations, consultez Gérer la disponibilité des machines virtuelles. Vous devez suivre cette meilleure pratique pour vous assurer que vos bases de données sont hautement disponibles, si vous utilisez des groupes de disponibilité AlwaysOn, la mise en miroir de bases de données, ou autre. Si vous ne suivez pas cette meilleure pratique, vous pouvez supposer à tort que votre système est hautement disponible, mais en réalité vos nœuds peuvent tous échouer simultanément, car ils sont placés dans le même domaine de défaillance du centre de données Azure. Cette recommandation ne s'applique pas à la copie des journaux de transaction, car en tant que fonctionnalité de récupération d'urgence, vous devez vous assurer que les serveurs s'exécutent dans des emplacements de centre de données Azure distincts (régions). Ces emplacements de centres de données sont par définition des domaines d'erreur distincts.

Pour les machines virtuelles Azure que vous devez placer dans le même groupe à haute disponibilité, vous devez les déployer dans le même service cloud. Seuls les nœuds du même service cloud peuvent faire partie du même groupe à haute disponibilité. En outre, les machines virtuelles doivent être dans le même réseau virtuel. Cela garantit qu'elles conservent leur adresse IP même après la réparation du service, ce qui évite les temps de mise à jour DNS.

Disposez d'une solution haute disponibilité pour vos bases de données SQL Server dans Azure à l'aide des groupes de disponibilité AlwaysOn ou de la mise en miroir de bases de données.

Le diagramme suivant illustre l'architecture des groupes de disponibilité AlwaysOn exécutés dans des machines virtuelles Azure. Ce diagramme a été tiré d'un article plus approfondi à ce sujet, Haute disponibilité et récupération d'urgence pour SQL Server sur des machines virtuelles Azure.

Le diagramme suivant illustre l'utilisation de la mise en miroir de bases de données sur des machines virtuelles Azure. Il a également été tiré de la rubrique plus approfondie à ce sujet, Haute disponibilité et récupération d'urgence pour SQL Server sur des machines virtuelles Azure.

noteRemarque
Notez que dans les deux architectures un contrôleur de domaine est nécessaire. Toutefois, avec la mise en miroir de bases de données, il est possible d'utiliser des certificats de serveur pour supprimer la nécessité d'un contrôleur de domaine.

Les services de cloud computing Azure reposent sur Azure. Ils tirent donc parti des fonctionnalités de plateforme décrites précédemment pour récupérer après des échecs locaux. Dans certains cas, il existe des mesures spécifiques à prendre pour augmenter la disponibilité de votre scénario particulier.

Le service Access Control (ACS) 2.0 effectue la sauvegarde de tous les espaces de noms une fois par jour et les stocke dans un lieu hors site sécurisé. Lorsque le personnel d'ACS détermine qu'une perte irrécupérable de données s'est produite dans l'un des centres de données régionaux d'ACS, ACS peut tenter de récupérer les abonnements des clients en restaurant la sauvegarde la plus récente. En raison de la fréquence des sauvegardes, une perte de données pouvant s'étaler sur 24 heures au maximum peut survenir. Pour plus d'informations, consultez Service Access Control (récupération d'urgence).

Pour atténuer l'impact d'une panne temporaire de Service Bus de Azure, envisagez de créer une file d'attente durable côté client. Cela permet d'utilise temporairement un autre mécanisme de stockage local pour stocker les messages qui ne peuvent pas être ajoutés à la file d'attente Service Bus. L'application décide comment traiter les messages temporairement stockés après que le service est restauré. Pour plus d'informations, consultez Isolation des applications Service Bus contre les pannes et les incidents de Service Bus. Pour plus d'informations, consultez Service Bus (récupération d'urgence).

Il existe deux points à prendre en compte concernant la disponibilité des Services mobiles Azure. Premièrement, sauvegardez régulièrement la Base de données SQL Azure associée à votre service mobile. Sauvegardez également les scripts du service mobile. Pour plus d'informations, consultez Récupérer votre service mobile en cas de sinistre. Si les Services mobiles rencontrent une panne temporaire, vous devrez peut-être temporairement utiliser un autre centre de données Azure. Pour plus d'informations, consultez Services mobiles (récupération d'urgence).

Les données associées à HDInsight sont stockées par défaut dans le stockage d'objets blob Azure, qui possède les propriétés de haute disponibilité et de durabilité spécifiées par le stockage Azure. Le traitement de plusieurs nœuds associés à des travaux Hadoop MapReduce s'effectue sur un système de fichiers distribués temporaire Hadoop (HDFS) configuré le cas échéant par HDInsight. Les résultats d'une tâche MapReduce sont également enregistrés par défaut dans le stockage d'objets blob Azure, afin que les données traitées soient durables et restent hautement disponibles après l'annulation du déploiement du cluster Hadoop. Pour plus d'informations, consultez HDInsight (récupération d'urgence).

 

Service/zone Liste de contrôle

Calcul (PaaS)

  • Configurez au moins deux instances pour chaque rôle.

  • Rendez l'état persistant dans le stockage durable, et non pas sur les instances de rôle.

  • Gérez correctement l'événement StatusCheck.

  • Encapsulez les modifications associées dans des transactions si possible.

  • Vérifiez que les tâches du rôle de travail sont idempotentes et redémarrables.

  • Continuez d'appeler les opérations jusqu'à ce qu'elles réussissent.

  • Envisagez d'utiliser des stratégies de mise à l'échelle automatique.

Machines virtuelles (IaaS)

  • N'utilisez pas le lecteur D: pour le stockage persistant.

  • Regroupez les ordinateurs d'une couche de service dans un groupe à haute disponibilité.

  • Configurez l'équilibrage de charge et des sondes facultatives.

Stockage

  • Utilisez plusieurs comptes de stockage lorsque les données ou la bande passante dépassent les quotas.

Base de données SQL

  • Implémentez une stratégie de nouvelle tentative pour gérer les erreurs temporaires.

  • Utilisez le partitionnement/sharding comme stratégie de montée en puissance parallèle.

SQL Server 2012 sur des machines virtuelles (IaaS)

  • Suivez les instructions précédentes pour les machines virtuelles.

  • Utilisez les fonctionnalités haute disponibilité de SQL Server, telles que AlwaysOn.

Service Access Control (disponibilité)

  • Aucune étape de disponibilité supplémentaire n'est nécessaire pour les échecs locaux.

Service Bus (disponibilité)

  • Envisagez de créer une file d'attente durable côté client comme sauvegarde.

Services mobiles (disponibilité)

  • Sauvegardez régulièrement la Base de données SQL Azure associée à vos services mobiles.

  • Sauvegardez les scripts des services mobiles.

HDInsight (disponibilité)

  • Aucune étape de disponibilité supplémentaire n'est nécessaire pour les échecs locaux.

Azure est divisé physiquement et logiquement en unités appelées régions. Une région comprend un ou plusieurs centres de données à proximité. Au moment de la rédaction de ce document, Azure a huit régions (4 en Amérique du Nord, 2 en Asie et 2 en Europe).

Dans de rares circonstances, les installations d'une région entière deviennent inaccessibles, par exemple, en raison de défaillances réseau, ou sont perdues, en raison de catastrophes naturelles. Cette section présente les fonctionnalités de Azure pour créer des applications qui sont réparties entre les régions. Les régions sont conçues pour réduire la possibilité qu'une défaillance dans une région puisse affecter d'autres régions.

Il est possible de répartir les instances de calcul entre les régions en créant un service cloud distinct dans chacune des régions cible et en exécutant le package de déploiement dans chaque service cloud. Toutefois, notez que la répartition du trafic entre les services de cloud computing dans différentes régions doit être implémentée par le développeur d'applications ou avec un service de gestion du trafic.

Déterminer le nombre d'instances de rôle de rechange à déployer à l'avance pour la récupération d'urgence constitue un aspect important de la planification de capacité. Le fait de disposer d'un déploiement secondaire complet garantit que la capacité est déjà disponible au moment voulu ; toutefois, cela double le coût. Un modèle commun consiste à disposer d'un petit déploiement secondaire suffisamment grand pour exécuter les services critiques. Nous vous recommandons de créer au moins un petit déploiement secondaire, à la fois pour réserver la capacité et tester la configuration de l'environnement secondaire.

noteRemarque
le quota d'abonnement n'est pas une garantie de capacité. Il s'agit simplement d'une limite de crédit. Pour garantir la capacité, le nombre nécessaire de rôles doit être défini dans le modèle de service et les rôles doivent être déployés.

Pour répartir le trafic entre les régions, vous devez utiliser une solution de gestion du trafic. Azure fournit Azure Traffic Manager (désormais dans la version CTP). Tirez également parti des services tiers qui fournissent des fonctionnalités similaires de gestion du trafic.

De nombreuses autres stratégies sont disponibles pour implémenter le calcul distribué entre les régions. Celles-ci doivent être adaptées aux besoins de l'entreprise et aux conditions spécifiques à l'application. De façon générale, les approches peuvent être divisées en trois catégories :

  • Redéploiement en cas de sinistre : dans cette approche, l'application est redéployée de toutes pièces lors d'un incident. Cela convient pour les applications non critiques qui n'ont pas besoin d'un temps de récupération garanti.

  • Rechange semi-automatique (actif/passif) : un service hébergé secondaire est créé dans une autre région, et les rôles sont déployés pour assurer la capacité minimale ; toutefois, les rôles n'acceptent pas le trafic de production. Cette approche est utile pour les applications qui n'ont pas été conçues pour répartir le trafic entre les régions.

  • Rechange à chaud (actif/actif) : l'application est conçue pour recevoir la charge de production dans plusieurs régions. Les services de cloud computing dans chaque région peuvent être configurés pour une capacité plus élevée que nécessaire à des fins de récupération d'urgence. Sinon, des services de cloud computing peuvent monter en puissance parallèle lors d'un incident et du basculement. Cette approche nécessite un investissement conséquent dans la conception d'applications, mais présente des avantages importants, notamment un temps de récupération garanti et faible, le test continu de tous les emplacements de récupération et l'utilisation efficace de la capacité.

Une discussion approfondie sur la conception distribuée dépasse l'objectif de ce document. Les documents suivants fournissent des instructions détaillées sur ces scénarios.

La récupération des machines virtuelles IaaS est semblable à la récupération de calcul PaaS à bien des égards. Toutefois, il existe des différences importantes attribuables au fait qu'une machine virtuelle IaaS se compose de la machine virtuelle et du disque de machine virtuelle.

  • Utilisez l'API de copie d'objets blob pour dupliquer des disques de machine virtuelle : pour créer des machines virtuelles dans plusieurs régions, le disque de machine virtuelle doit être copié vers une autre région. Les disques de machine virtuelle étant simplement des objets blob, cela peut être effectué à l'aide de l'API de copie d'objets blob standard.

  • Séparez le disque de données du disque de système d'exploitation : une considération importante pour les machines virtuelles IaaS est que vous ne pouvez pas modifier le disque de 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 consiste à redéployer après un sinistre. Toutefois, cela peut poser problème si vous utilisez l'approche de rechange semi-automatique pour réserver la capacité. Pour implémenter cela correctement, vous devez avoir le disque correct de système d'exploitation déployé dans les emplacements principal et secondaire et les données d'application doivent être stockées sur un lecteur distinct. Si possible, utilisez une configuration standard de système d'exploitation qui peut être fournie sur les deux emplacements. Après un basculement, vous devez attacher le lecteur de données à vos machines virtuelles IaaS existantes dans le contrôleur de domaine secondaire. Utilisez l'API CopyBlob pour copier des instantanés des disques de données sur un site distant.

  • Problèmes potentiels de cohérence après un basculement géographique de plusieurs disques de machine virtuelle : les disques de machine virtuelle sont implémentés en tant qu'objets blob de stockage Azure, et ont les mêmes caractéristiques de géo-réplication (voir ci-dessous). Les disques de machine virtuelle sont garantis dans un état d'incident cohérent après un basculement géographique ; toutefois, il n'existe aucune garantie de cohérence entre les disques, car la géoréplication est asynchrone et réplique indépendamment. Cela peut poser des problèmes dans certains cas (par exemple, en cas d'agrégation de disques). Un travail supplémentaire peut s'avérer nécessaire pour restaurer la cohérence après un basculement géographique dans ce cas. Pour garantir l'exactitude des sauvegardes, un produit de sauvegarde, tel que Data Protection Manager, doit être utilisé pour sauvegarder et restaurer les données d'application.

Dans Azure, les objets blob, les tables, les files d'attente et les disques de machine virtuelle sont géorépliqués par défaut. On parle alors de « stockage géo-redondant » (GRS). Le stockage géo-redondant réplique les données de stockage dans un centre de données associé situé à des centaines de kilomètres dans une région géographique spécifique. Il est conçu pour ajouter une durabilité supplémentaire au cas où un problème majeur surviendrait au niveau d'un centre de données. Microsoft décide du moment du basculement, et le basculement proprement dit est limité aux sinistres majeurs dans lesquels l'emplacement principal d'origine est considéré comme irrécupérable dans un délai raisonnable. Dans certains scénarios, cela peut prendre plusieurs jours. Les données sont généralement répliquées en l'espace de quelques minutes, bien que l'intervalle de synchronisation ne soit pas encore couvert par un contrat de qualité de service.

En cas de basculement géographique, il n'y a aucune modification de l'accès au compte (l'URL et la clé du compte ne sont pas modifiées) ; toutefois, le compte de stockage sera dans une autre région après le basculement, ce qui 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 et les coûts de bande passante peuvent être une raison de déplacer temporairement le trafic vers la région de basculement. Ceci doit être pris en compte dans une stratégie de récupération d'urgence.

Outre le basculement automatique fourni par le stockage géo-redondant, Azure offre un service qui assure également un accès en lecture à la copie de vos données dans l'emplacement de stockage secondaire. On parle alors de stockage géo-redondant avec accès en lecture (RA-GRS).

Pour plus d'informations sur les versions Preview du stockage géo-redondant avec accès en lecture et du stockage géo-redondant, consultez le billet de blog Options de redondance du stockage Azure et stockage géo-redondant avec accès en lecture.

Il est important de savoir où vos données sont répliquées afin de déterminer où déployer les autres instances de vos données qui nécessitent une affinité régionale avec votre stockage. Le tableau suivant montre les appariements d'emplacements primaires et secondaires :

 

Primaire Secondaire

Nord du centre des États-Unis

Centre-Sud des États-Unis

Centre-Sud des États-Unis

Nord du centre des États-Unis

États-Unis de l'Est

États-Unis de l'Ouest

États-Unis de l'Ouest

États-Unis de l'Est

Europe du Nord

Europe de l'Ouest

Europe de l'Ouest

Europe du Nord

Asie du Sud-Est

Asie orientale

Asie orientale

Asie du Sud-Est

Est de la Chine

Nord de la Chine

Nord de la Chine

Est de la Chine

Sud du Brésil

Centre-Sud des États-Unis

La géo-réplication est incluse dans le prix actuel du stockage Azure. Cela est appelé stockage géo-redondant. Si vous ne souhaitez pas que vos données soient géorépliquées, désactivez la géoréplication pour votre compte. Cela est appelé stockage localement redondant, et est facturé à un prix escompté par rapport au stockage géorépliqué. Pour plus d'informations sur le stockage localement redondant (LRS), consultez cette page.

Si un basculement géographique se produit, il est publié dans le Tableau de bord d'intégrité de service Azure ; toutefois, les applications peuvent implémenter des moyens automatisés de détecter cela en analysant la géoréplication de leur compte de stockage. Cela peut être utilisé pour déclencher d'autres opérations de récupération, telles que l'activation des ressources de calcul dans la zone dans laquelle leur stockage est déplacé. L'API de gestion des services permet d'exécuter cette requête en utilisant Obtenir les propriétés du compte de stockage. Les propriétés appropriées sont :

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

  • Comme nous l'avons évoqué dans la section sur les disques de machine virtuelle, il n'existe aucune garantie de cohérence des données entre des disques de machine virtuelle après un basculement. Pour garantir l'exactitude des sauvegardes, un produit de sauvegarde, tel que Data Protection Manager, doit être utilisé pour sauvegarder et restaurer les données d'application.

La récupération des Base de données SQL Azure Azure peut être obtenue en exportant la base de données vers un objet blob de stockage Azure à l'aide du service d'importation/exportation Base de données SQL Azure Azure. Cette opération peut être implémentée de trois manières :

  • Exportation vers un objet blob à l'aide d'un compte de stockage dans un autre centre de données.

  • Exportation vers un objet blob à l'aide d'un compte de stockage dans le même centre de données (et utilisation de la géoréplication du service de stockage Azure dans l'autre centre de données).

  • Importation sur votre serveur SQL Server sur site.

Pour plus d'informations sur l'implémentation, consultez l'article MSDN Continuité des activités de l'entreprise dans Base de données SQL Azure.

Il existe deux options pour récupérer une base de données SQL Server sur IaaS dans un autre centre de données Azure : mise en miroir de bases de données ou sauvegarde et restauration avec des objets blob de stockage. Notez que les groupes à haute disponibilité SQL Server 2012 ne sont pas pris en charge dans les centres de données Azure, car les réseaux virtuels entre les centres de données ne sont pas pris en charge dans Azure, et un domaine Active Directory ne peut pas couvrir plusieurs centres de données Azure.

Lorsque vous utilisez la mise en miroir pour la récupération d'urgence, les serveurs principal et miroir doivent s'exécuter dans des centres de données Azure différents. Cela signifie que vous devez déployer à l'aide de certificats de serveur, car un domaine Active Directory ne peut pas couvrir plusieurs centres de données Azure sans acheminer le trafic via un réseau local. Ce diagramme illustre cette configuration.

L'autre option consiste à utiliser la sauvegarde et la restauration standard avec des objets blob de stockage Azure.

Pour plus d'informations, consultez Haute disponibilité et récupération d'urgence pour SQL Server sur des machines virtuelles 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 supposent que vous utilisez le même service Azure dans un autre centre de données Azure. Cela implique des tâches de configuration et de réplication des données.

Notez que dans certains cas, ces étapes permettent d'atténuer l'impact d'une panne spécifique au service plutôt qu'un événement dans le centre de données entier. Du point de vue de l'application, une panne spécifique au service peut avoir un impact tout autant restrictif et nécessiterait la migration temporaire du service vers une autre région Azure.

Le service Access Control (ACS) utilise un espace de noms unique qui ne couvre pas les régions Azure. ACS 2.0 effectue la sauvegarde de tous les espaces de noms une fois par jour et les stocke dans un lieu hors site sécurisé. En cas de sinistre, le personnel ACS peut tenter de récupérer les abonnements des clients dans la région distante Azure à l'aide de la sauvegarde la plus récente. En raison de la fréquence des sauvegardes, une perte de données pouvant s'étaler sur 24 heures au maximum peut survenir. Il n'existe pas de contrat de niveau de service (SLA) pour le basculement régional et le temps de récupération peut être de plusieurs jours selon le scénario.

Pour utiliser ACS dans une autre région, les clients doivent configurer un espace de noms ACS dans cette région. Les clients d'ACS 2.0 préoccupés par le risque potentiel de perte de données sont encouragés à consulter Service de gestion ACS 2.0. Cette interface permet aux administrateurs de gérer leurs espaces de noms et d'importer et d'extraire toutes les données appropriées. Grâce à cette interface, les clients d'ACS ont la possibilité de développer des solutions de sauvegarde et de restauration personnalisées afin de parvenir à un niveau plus élevé de cohérence des données par rapport à celui actuellement proposé par ACS. Pour d'autres considérations sur la disponibilité, consultez Service Access Control (disponibilité).

Comme ACS, Service Bus utilise un espace de noms unique qui ne couvre pas les régions Azure. Ainsi, la première exigence consiste à configurer les espaces de noms Service Bus nécessaires dans l'autre région. Toutefois, il existe également des considérations relatives à la durabilité des messages en file d'attente. Il existe plusieurs stratégies pour répliquer les 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 Isolation des applications Service Bus contre les pannes et les incidents. Pour d'autres considérations sur la disponibilité, consultez Service Bus (disponibilité).

Pour migrer un site Web Azure vers une région Azure secondaire, vous devez avoir une sauvegarde du site Web disponible pour la publication. Si la panne ne concerne pas le centre de données Azure entier, il peut être possible d'utiliser FTP pour télécharger une sauvegarde récente du contenu du site. Créez ensuite un site Web dans autre région, sauf si vous avez précédemment effectué cette opération pour réserver la capacité. Publiez le site dans la nouvelle région, et effectuez toutes les modifications de configuration nécessaires. 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 CNAME DNS afin que le nom de domaine personnalisé pointe vers l'URL du site Web Azure redéployé.

Dans la région Azure secondaire, créez un service mobile de sauvegarde pour votre application. Restaurez également la Base de données SQL Azure dans l'autre région. Utilisez ensuite les outils en ligne de commande Azure pour déplacer le service mobile vers l'autre région. Configurez ensuite le service mobile de façon à utiliser la base de données restaurée. Pour plus d'informations sur cette procédure, consultez Récupérer votre service mobile en cas de sinistre. Pour d'autres considérations sur la disponibilité, consultez Services mobiles (disponibilité).

Les données associées à HDInsight sont stockées par défaut dans le stockage d'objets blob Azure. HDInsight nécessite qu'un cluster Hadoop traitant les tâches MapReduce soit colocalisé dans la même région que le compte de stockage qui contient les données analysées. Si vous utilisez la fonctionnalité de géoréplication disponible dans le stockage Azure, vous accédez à vos données dans la région secondaire où les données ont été répliquées (si pour une raison quelconque la région principale n'est plus disponible). Créez un nouveau cluster Hadoop dans la région où les données ont été répliquées et continuez de les traiter. Pour d'autres considérations sur la disponibilité, consultez HDInsight (disponibilité).

Pour l'instant, la récupération après perte d'une région Azure requiert plusieurs instances SQL Reporting dans différentes régions Azure. Ces instances de SQL Reporting doivent accéder aux mêmes données, et ces données doivent disposer de leur propre plan de récupération en cas de sinistre. Conservez également des copies de sauvegarde externes du fichier RDL pour chaque rapport.

Le Service de média Azure a une approche différente de récupération de l'encodage et de la diffusion en continu. En général, la diffusion en continu est plus critique pendant une panne régionale. Pour vous préparer à cela, vous devez avoir un compte de service de média dans deux régions différentes Azure. Le contenu codé doit être situé dans les deux régions. Pendant un échec, vous redirigez le trafic de diffusion en continu vers une autre région. L'encodage peut être exécuté dans n'importe quelle région Azure. Si l'encodage est basé sur le temps, par exemple pendant le traitement d'événements en direct, vous devez être prêt à envoyer des travaux à un autre centre de données lors des défaillances.

Les fichiers de configuration constituent le moyen le plus rapide de configurer un réseau virtuel dans autre région Azure. Après avoir configuré le réseau virtuel dans la région principale Azure, exportez les paramètres du réseau virtuel pour le réseau actuel dans un fichier de configuration réseau. En cas de panne dans la région principale, restaurez le réseau virtuel depuis le fichier de configuration stocké. Configurez ensuite d'autres services de cloud computing, machines virtuelles ou paramètres intersite pour utiliser le nouveau réseau virtuel.

 

Service/zone Liste de contrôle

Calcul (PaaS)

  • Créez une stratégie de récupération d'urgence entre les régions.

  • Comprenez les avantages et les inconvénients liés à la réservation de capacité dans d'autres régions.

  • Utilisez des outils d'acheminement du trafic, tels que Azure Traffic Manager (CTP).

Machines virtuelles (IaaS)

  • Copiez les ressources disque de machine virtuelle d'objets blob vers un autre centre de données.

  • Effectuez des sauvegardes périodiques du disque de machine virtuelle ou du contenu du disque.

Stockage

  • Ne désactivez pas la géoréplication des ressources de stockage.

  • Comprenez l'autre région pour la géoréplication en cas de basculement.

  • Créez des stratégies de sauvegarde personnalisées pour les stratégies de basculement contrôlées par l'utilisateur.

Base de données SQL (Récupération d'urgence)

  • Exportez la Base de données SQL Azure dans le stockage d'objets blob.

  • Créez un plan de récupération d'urgence basé sur des considérations de stockage précédentes.

SQL Server sur des machines virtuelles (récupération d'urgence)

  • Utilisez la mise en miroir de bases de données entre régions.

  • Utilisez également la sauvegarde et la restauration dans le stockage d'objets blob.

Service Access Control (récupération d'urgence)

  • Configurez un espace de noms ACS dans autre région.

  • Utilisez le Service de gestion ACS 2.0 pour créer des solutions de sauvegarde personnalisées.

Service Bus (récupération d'urgence)

  • Configurez un espace de noms Service Bus dans autre région.

  • Considérez les stratégies personnalisées de réplication pour les messages entre les régions.

Sites Web (récupération d'urgence)

  • Conservez les sauvegardes de site Web en dehors de la région principale.

  • Si une panne est partielle, tentez de récupérer le site actuel avec FTP.

  • Planifiez le déploiement du site Web vers un site Web nouveau ou existant dans autre région.

  • Planifiez les modifications de configuration de l'application et des enregistrements CNAME DNS.

Services mobiles (récupération d'urgence)

  • Créez un service mobile de sauvegarde dans autre région.

  • Gérez les sauvegardes de la Base de données SQL Azure associée à restaurer pendant le basculement.

  • Utilisez les outils en ligne de commande Azure pour déplacer le service mobile.

HDInsight (récupération d'urgence)

  • Créez un cluster Hadoop dans la région avec des données répliquées.

SQL Reporting (récupération d'urgence)

  • Conservez une autre instance de SQL Reporting dans une autre région.

  • Conservez un plan distinct pour répliquer la cible dans cette région.

Service de média (récupération d'urgence)

  • Créez un compte de service de média dans autre région.

  • Encodez le même contenu dans les deux régions pour prendre en charge le basculement de diffusion.

  • Envoyez des tâches de codage à une autre région en cas de panne.

Réseau virtuel (récupération d'urgence)

  • Utilisez les paramètres exportés de réseau virtuel pour le recréer dans autre région.

Azure fournit un ensemble de services complet pour activer l'extension d'un centre de données local vers Azure à des fins de haute disponibilité et de récupération d'urgence :

  • Mise en réseau : avec le réseau privé virtuel, vous étendez en toute sécurité votre réseau local vers le cloud.

  • Compute : les clients qui utilisent Hyper-V en local peuvent déplacer les machines virtuelles existantes dans Azure

  • Stockage : StorSimple étend votre système de fichiers au stockage Azure. Le service Sauvegarde Azure fournit la sauvegarde des fichiers et des Base de données SQL Azure au stockage Azure.

  • Réplication de base de données : les groupes à haute disponibilité SQL Server 2012 vous permettent d'implémenter la haute disponibilité et la récupération d'urgence pour vos données locales.

Le réseau virtuel Azure vous permet de créer une section isolée logiquement dans Azure et la connexion sécurisée à votre centre de données local ou à un seul ordinateur client utilisant une connexion IPsec. Le réseau virtuel permet de tirer facilement parti de l'infrastructure évolutive à la demande de Azure tout en fournissant la connectivité aux données et aux applications locales, y compris aux systèmes exécutés sur Windows Server, grands systèmes et UNIX. Pour plus d'informations, consultez cet article.

Les clients qui utilisent Hyper-V sur site peuvent déplacer les machines virtuelles existantes vers Azure et des fournisseurs de services exécutant Windows Server 2012, sans apporter de modifications à la machine virtuelle ou convertir les formats de machine virtuelle. Pour plus d'informations, consultez Gérer des disques et des images.

Il existe plusieurs options pour l'utilisation de Azure comme site de sauvegarde des données locales.

StorSimple intègre de façon transparente et sécurisée le stockage du cloud pour les applications locales et propose un seul appareil qui fournit un stockage de cloud et local hautes performances, l'archivage direct, la protection des données informatiques et la récupération d'urgence. Pour plus d'informations, consultez StorSimple -- Cloud-integrated Storage -- What & Why.

Le service Sauvegarde Azure permet les sauvegardes en cloud avec des outils de sauvegarde familiers dans Windows Server 2012, Windows Server 2012 Essentials et le composant System Center 2012 Data Protection Manager. Ces outils fournissent un flux de travail pour la gestion de sauvegarde qui est indépendant de l'emplacement de stockage des sauvegardes, qu'il s'agisse d'un disque local ou d'un stockage Azure. Une fois les données sauvegardées dans le cloud, les utilisateurs autorisés peuvent facilement récupérer les sauvegardes sur un serveur.

Avec les sauvegardes incrémentielles, seules les modifications des fichiers sont transférées dans le cloud. Cela permet d'utiliser efficacement l'espace de stockage, de réduire la consommation de la bande passante et d'assurer la récupération à tout moment des différentes versions de données. Vous pouvez également choisir d'utiliser des fonctionnalités supplémentaires, telles que les stratégies de rétention des données, la compression des données et la limitation du transfert des données. L'utilisation de Azure comme emplacement de sauvegarde présente l'avantage évident que les sauvegardes sont automatiquement effectuées « hors site ». Cela supprime les conditions supplémentaires visant à sécuriser et protéger le support de sauvegarde sur site. Pour plus d'informations, consultez Présentation de sauvegarde Azure et Utilisation de Data Protection Manager avec sauvegarde Azure.

Disposez d'une solution de récupération d'urgence pour vos bases de données SQL Server dans un environnement informatique hybride utilisant des groupes de disponibilité AlwaysOn, la mise en miroir de bases de données, la copie des journaux de transaction et la sauvegarde et la restauration avec le stockage d'objets blob Azure. Toutes ces solutions utilisent SQL Server exécuté sur des machines virtuelles Azure.

Les groupes à haute disponibilité AlwaysOn peuvent être utilisés dans un environnement informatique hybride où il existe des réplicas de base de données locaux et dans le cloud. Ce diagramme, tiré d'une rubrique plus approfondie à ce sujet, Haute disponibilité et récupération d'urgence pour SQL Server sur des machines virtuelles Azure, illustre ce concept.

La mise en miroir de bases de données peut également couvrir les serveurs sur site et le cloud dans une installation basée sur des certificats. Ce diagramme illustre ce concept.

La copie des journaux de transaction peut être utilisée pour synchroniser une base de données locale avec une base de données SQL Server dans une machine virtuelle Azure.

Enfin, sauvegardez une base de données locale directement dans le stockage d'objets blob Azure.

Pour plus d'informations, consultez Haute disponibilité et récupération d'urgence pour SQL Server sur des machines virtuelles Azure et Sauvegarde et restauration pour SQL Server sur des machines virtuelles Azure.

 

Service/zone Liste de contrôle

Mise en réseau

  • Utilisez un réseau virtuel pour connecter le site en toute sécurité au cloud.

Calculer

  • Déplacez des machines virtuelles entre Hyper-V et Azure.

Stockage

  • Tirez parti des services StorSimple pour l'utilisation du stockage dans le cloud.

  • Utilisez le service Sauvegarde Azure.

Base de données

  • Envisagez d'utiliser SQL Server sur des machines virtuelles Azure en tant que sauvegarde.

  • Configurez des groupes de disponibilité AlwaysOn.

  • Configurez la mise en miroir de bases de données à l'aide de certificats.

  • Utilisez la copie des journaux de transaction.

  • Sauvegardez une base données locale dans le stockage d'objets blob Azure.

Ce scénario traite de la récupération de données endommagées ou supprimées par erreur en raison d'erreurs de l'application ou d'une erreur de l'opérateur.

Notez que bien que le stockage Azure fournisse la résilience de données via les réplicas automatisés, cela n'empêche pas le code de l'application (ou les développeurs/utilisateurs) d'endommager les données via une suppression ou mise à jour accidentelle ou involontaire, etc. La conservation de l'intégrité des données en dépit d'une erreur de l'application ou de l'utilisateur nécessite des techniques avancées, telles que la copie de données dans un emplacement de stockage secondaire avec un journal d'audit. Les développeurs peuvent tirer parti de la fonction instantané d'objet blob, qui crée des instantanés dans le temps en lecture seule du contenu d'objet blob. Cela peut être utilisé comme base d'une solution de fidélité des données pour les objets blob.

Alors que les objets blob et les tables présentent une haute durabilité, ils représentent toujours l'état actuel des données. La récupération suite à une modification non souhaitée ou une suppression des données peut nécessiter la restauration des données à partir d'un état antérieur. Pour y parvenir, il suffit de tirer parti des fonctionnalités fournies par Azure pour stocker et conserver des copies dans le temps.

Pour ce qui est des objets blob Azure, vous pouvez effectuer des sauvegardes dans le temps à l'aide de la fonctionnalité d'instantanés d'objets blob. Pour chaque instantané, vous êtes uniquement facturé pour le stockage requis pour stocker les différences qu'il existe au niveau de l'objet blob depuis le dernier état d'instantané. Les instantanés dépendent de l'existence de l'objet blob d'origine sur lequel ils sont basés ; il est recommandé d'effectuer une opération de copie vers un autre objet blob ou même vers un autre compte de stockage pour s'assurer que les données de sauvegarde sont correctement protégées face à une suppression accidentelle. Concernant les tables de Azure, vous pouvez effectuer des copies dans le temps vers une autre table ou vers des objets blob Azure. Vous trouverez des instructions détaillées et des exemples de sauvegardes au niveau de l'application de tables et d'objets blob ici :

Il existe plusieurs options de continuité des activités (sauvegarde, restauration) disponibles pour la Base de données SQL Azure. Les bases de données peuvent être copiées via la fonctionnalité de copie d'une base de données ou le service d'importation/exportation DAC. La fonctionnalité de copie de base de données fournit des résultats transactionnels cohérents, ce qui n'est pas le cas du fichier bacpac (via le service d'importation/exportation). Ces deux options s'exécutent en tant que services basés sur les files d'attente dans le centre de données, et ne fournissent pas de contrat SLA de durée d'exécution pour le moment.

noteRemarque
Notez que la copie de base de données et le service d'importation/exportation appliquent une charge considérable sur la base de données source, et peuvent déclencher des événements de contention ou de limitations des ressources (décrits dans la section Ressources partagées et limitation).

Les sauvegardes dans le temps de Base de données SQL Microsoft Azure sont réalisées avec la commande de copie de Base de données SQL Azure. Vous pouvez utiliser cette commande pour créer une copie transactionnellement cohérente d'une base de données sur le même serveur de base de données logique ou sur un serveur différent. Dans l'un et l'autre cas, la copie de base de données est entièrement fonctionnelle et complètement indépendante de la base de données source. Chaque copie que vous créez représente une option de récupération dans le temps. Vous pouvez récupérer l'état de la base de données entièrement en renommant la nouvelle base de données avec le nom de la base de données source. Sinon, vous pouvez récupérer un sous-ensemble spécifique de données à partir de la nouvelle base de données au moyen de requêtes Transact-SQL. Pour plus d'informations sur la Base de données SQL, consultez Continuité des activités de l'entreprise dans Base de données SQL Azure.

Pour SQL Server sur IaaS, il existe deux options : sauvegardes traditionnelles et copie des journaux de transaction. L'utilisation des sauvegardes traditionnelles vous permet de restaurer à un moment spécifique, mais le processus de récupération est lent. La restauration de sauvegardes traditionnelles requiert une sauvegarde initiale complète, puis l'application des sauvegardes successives. La seconde option consiste à configurer une session de copie des journaux de transaction pour retarder la restauration des sauvegardes de fichiers journaux (par exemple, de deux heures). Cela fournit une fenêtre pour corriger les erreurs sur la base de données principale.

Certains services de plateforme Azure stockent des informations dans un compte de stockage dépendant de l'utilisateur ou Base de données SQL Azure. Si le compte ou la ressource de stockage est supprimé ou endommagé, cela peut entraîner des erreurs graves dans le service. Dans ce cas, il est important de conserver des sauvegardes qui vous permettront de recréer ces ressources en cas de suppression ou de corruption.

Pour les Sites Web Azure et les Services mobiles Azure, vous devez sauvegarder et gérer les bases de données associées. En ce qui concerne le service de média et les machines virtuelles Azure, vous devez gérer le compte de stockage Azure associé et toutes les ressources dans ce compte. Par exemple, pour les machines virtuelles, vous devez sauvegarder et gérer les disques de machine virtuelle dans le stockage d'objets blob Azure.

 

Service/zone Liste de contrôle

Stockage

  • Sauvegardez régulièrement les ressources de stockage critiques.

  • Envisagez d'utiliser la fonctionnalité d'instantané des objets blob.

Base de données

  • Créez des sauvegardes dans le temps à l'aide de la commande Copier une base de données.

Sauvegarde SQL Server sur des machines virtuelles (IaaS)

  • Utilisez les techniques traditionnelles de sauvegarde et de restauration.

  • Créez une session retardée de copie des journaux de transaction.

Sites Web

  • Sauvegardez et gérez la base de données associée, le cas échéant.

Services mobiles

  • Sauvegardez et gérez la base de données associée.

Services de média

  • Sauvegardez et gérez les ressources de stockage associées.

Machines virtuelles

  • Sauvegardez et gérez les disques de machine virtuelle dans le stockage d'objets blob.

Prévention de défaillance : Aide sur les architectures résilientes du cloud : aide pour la création d'architectures résilientes de cloud, instructions pour l'implémentation de ces architectures sur des technologies Microsoft et recettes pour implémenter les architectures pour des scénarios spécifiques.

Récupération d'urgence et haute disponibilité pour les applications Azure : présentation détaillée de la disponibilité et de la récupération d'urgence. Aborde le problème de la réplication manuelle des données de référence et transactionnelles. Les sections finales fournissent des résumés de différents types de topologies de récupération d'urgence qui couvrent les centres de données Azure pour le plus haut niveau de disponibilité.

Continuité des activités de l'entreprise dans la Base de données SQL Azure : met exclusivement l'accent sur les techniques de Base de données SQL Azure Azure pour la disponibilité, et porte principalement sur les stratégies de sauvegarde et de restauration. Si vous utilisez Base de données SQL Azure dans votre service cloud, consultez ce document et ses ressources connexes.

Haute disponibilité et récupération d'urgence pour SQL Server sur des machines virtuelles Azure : présente les options de disponibilité lorsque vous utilisez IaaS pour héberger vos services de base de données. Présente les groupes de disponibilité AlwaysOn, la mise en miroir de bases de données, la copie des journaux de transaction et la sauvegarde/restauration. Notez qu'il existe également plusieurs didacticiels dans la même section qui expliquent comment utiliser ces techniques.

Meilleures pratiques pour la création de services à grande échelle sur les services cloud d'Azure : axé sur le développement des architectures de cloud hautement évolutives. Nombre des techniques que vous utilisez pour améliorer l'évolutivité améliorent également la disponibilité. De plus, si votre application ne peut pas être mise à l'échelle lors de l'augmentation de la charge, l'évolutivité devient un problème de disponibilité.

Sauvegarde et restauration de SQL Server dans les machines virtuelles Azure

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft