Qu’est-ce que la redondance, la réplication et la sauvegarde ?

Nous considérons souvent le cloud comme un système distribué à l’échelle mondiale et omniprésent. Toutefois, en réalité, le cloud est constitué de matériel s’exécutant dans des centres de données. La résilience nécessite que vous gériez certains des risques associés aux emplacements physiques dans lesquels vos composants hébergés dans le cloud s’exécutent.

Cet article fournit une introduction générale à la redondance, à la réplication et à la sauvegarde, qui sont des méthodes utilisées pour créer des charges de travail résilientes aux risques physiques qui provoquent une interruption de service, une panne ou une perte de données.

La redondance est la possibilité de conserver plusieurs copies identiques d’un composant de service et d’utiliser ces copies d’une manière qui empêche tout composant de devenir un point de défaillance unique.

La réplication ou la redondance des données est la possibilité de conserver plusieurs copies de données, appelées réplicas.

La sauvegarde est la possibilité de conserver une copie horodatée des données qui peuvent être utilisées pour restaurer des données perdues.

Du point de vue de la fiabilité, un moyen important d’atténuer de nombreux risques consiste à inclure une forme de redondance, de réplication ou de sauvegarde dans votre planification de continuité d’activité.

Remarque

Cet article ne fournit pas de conseils de conception ni des informations détaillées sur les services Azure individuels. Pour plus d’informations sur le fonctionnement des services Azure spécifiques du point de vue de la fiabilité, consultez le guide de fiabilité de chaque service.

Redondance

La redondance consiste à déployer plusieurs instances d’un composant. Bien que la redondance soit simple à comprendre, dans certaines situations, elle peut devenir complexe à implémenter.

Lorsque vous commencez à comprendre la redondance, il est plus facile de prendre en compte la redondance par rapport aux composants sans état, qui sont des composants qui ne stockent pas de données. Bien que la plupart des solutions réelles nécessitent une gestion de l’état, dans cette section, nous abordons la redondance en termes d’exemple d’interface de programmation d’application sans état (API). L’exemple d’API accepte l’entrée, fonctionne sur cette entrée, puis retourne une sortie, sans stocker de données. Dans la section suivante, réplication : redondance pour les données, nous allons ajouter des considérations relatives à la redondance avec état.

Scénario : redondance sans état

Dans cet exemple, un composant d’API sans état est déployé sur une machine virtuelle. Pour éviter les temps d’arrêt du composant API en cas de défaillance matérielle sur l’hôte physique, l’exemple implémente une solution redondante qui :

• Déploie plusieurs copies de l’instance d’API.
• Implémente un équilibreur de charge pour distribuer les requêtes entre les instances d’API.

L’équilibreur de charge surveille l’intégrité de chaque instance pour envoyer des requêtes uniquement à des instances saines.

Considérations relatives à la redondance

Lors de l’implémentation de solutions redondantes, comme dans le scénario ci-dessus, il est important de prendre en compte les éléments suivants :

• Coûts des ressources. Par définition, la redondance implique d’avoir plusieurs copies d’un élément, ce qui augmente le coût total pour héberger la solution.

• Rendement. Plus vous distribuez les copies des objets sur une vaste zone géographique, plus vous contribuez à atténuer les risques. Toutefois, les demandes des clients prendront plus de temps pour parcourir des distances plus longues, car elles doivent parcourir davantage d’infrastructure réseau, ce qui augmente la latence du réseau.

  Dans la plupart des situations réelles, la latence du réseau est inconséquente pour de courtes distances, comme dans un centre de données ou même entre les centres de données d’une ville. Toutefois, si vous distribuez des copies sur une longue distance, la latence réseau peut devenir plus importante.

• Cohérence des instances. Il est important de maintenir la cohérence des instances entre elles et d’éviter de configurer des instances individuellement, car vous pouvez introduire accidentellement des différences entre les instances. S’il existe des différences entre les instances, les demandes peuvent être traitées différemment selon l’instance qui les sert. Cela peut entraîner des bogues et des comportements difficiles à diagnostiquer.

• Distribution du travail. Lorsque vous avez plusieurs instances d’un composant, vous devez répartir le travail entre elles. Vous pouvez répartir le travail sur toutes les instances de manière égale, ou vous pouvez envoyer des requêtes à une seule instance principale et utiliser uniquement une instance secondaire si l’instance principale n’est pas disponible.

  Pour les composants qui reçoivent des requêtes entrantes, les équilibreurs de charge sont souvent utilisés pour envoyer ces requêtes à des instances. Toutefois, parfois, les composants fonctionnent indépendamment et ne reçoivent pas de demandes de clients. Par conséquent, dans ces situations, les instances peuvent avoir besoin de coordonner leur travail entre eux.

• Contrôle d'intégrité. L’intégrité de chaque instance détermine si cette instance peut effectuer son travail, et la surveillance de l’intégrité est importante pour permettre une récupération rapide en cas de problème.

  Les équilibreurs de charge effectuent généralement un suivi de l'état de santé. Pour les composants qui n’incluent pas d’équilibreur de charge, vous pouvez avoir un composant externe qui surveille l’intégrité de toutes les instances, ou chaque instance peut surveiller l’intégrité d’autres instances.

Emplacements physiques dans le cloud

La nécessité de redondance est claire lorsque vous comprenez que, même dans un environnement cloud, une instance ou une partie de données est stockée dans un emplacement physique spécifique.

Par exemple:

• Une machine virtuelle s’exécute dans un emplacement physique unique à tout moment.
• Les données sont stockées à un emplacement physique spécifique, par exemple sur un disque SSD ou un disque dur connecté aux serveurs.

Même s’il existe plusieurs copies d’une partie de données ou d’instances d’un composant, chaque copie est liée au matériel physique sur lequel elle est stockée.

L’emplacement physique d’un environnement cloud dans son ensemble peut être organisé en étendues physiques. À chaque étendue physique, il existe des risques potentiels susceptibles de compromettre les composants ou les données dans cette étendue. Voici une liste non exhaustive des risques qui peuvent être définis en termes d’étendue physique :

Étendue physique	Risque possible
Un élément matériel spécifique, tel qu’un disque ou un serveur	Défaillance matérielle
Un rack dans un centre de données	Panne du commutateur réseau top-of-rack
Un centre de données	Problème avec le système de refroidissement du bâtiment
Un groupe de centres de données, qui dans Azure est appelé zone de disponibilité	Tempête électrique à l’échelle de la ville
Zone géographique plus large dans laquelle se trouve le centre de données, tel qu’une ville, qui est une région Azure	Catastrophe naturelle généralisée

Du point de vue de la fiabilité, un moyen important d’atténuer les risques associés à une étendue physique consiste à répartir les instances d’un composant dans différentes étendues physiques. Les services Azure avec redondance intégrée peuvent vous offrir une ou plusieurs des trois façons suivantes de déployer des instances redondantes :

• La redondance locale place les instances dans plusieurs parties d’un centre de données Azure unique et protège contre les défaillances matérielles susceptibles d’affecter une seule instance. La redondance locale offre généralement le coût et la latence les plus bas. Toutefois, une défaillance du centre de données peut signifier que toutes les instances ne sont pas disponibles.

• La redondance de zone répartit les instances entre plusieurs zones de disponibilité dans une seule région Azure. La redondance de zone protège contre les défaillances du centre de données, en plus des défaillances matérielles.

• La géoredondance place les instances dans plusieurs régions Azure et offre une protection contre les pannes régionales à grande échelle. La géoredondance est un coût plus élevé et nécessite une prise en compte de votre conception de solution plus large et de la façon dont vous allez basculer entre les instances de vos composants dans chaque région. Vous devez également prendre en compte la latence, qui est décrite dans la réplication synchrone et asynchrone.

Fonctionnement de la redondance dans Azure : Services de calcul

La redondance est employée dans presque toutes les parties d’Azure. Prenez un exemple de la manière dont Azure implémente la redondance, examinez les services qui exécutent des charges de travail de calcul.

Dans Azure, une machine virtuelle individuelle s’exécute sur un seul hôte physique dans un centre de données Azure. Vous pouvez fournir des instructions à Azure pour vous assurer que la machine virtuelle s’exécute à l’endroit où vous vous attendez, comme la région et la zone de disponibilité, et dans certaines situations, vous souhaiterez peut-être même la placer sur un hôte dédié à vous.

Il est courant d’exécuter plusieurs instances d’une machine virtuelle. Dans ce scénario, vous pouvez choisir de les gérer individuellement ou à l’aide d’un ensemble de machines virtuelles. Lorsque vous utilisez un ensemble de mise à l'échelle, vous pouvez toujours voir les machines virtuelles individuelles qui le sous-tendent, mais l'ensemble de mise à l'échelle fournit une gamme de fonctionnalités pour aider à gérer les machines virtuelles redondantes. Ces fonctionnalités incluent le placement automatique des machines virtuelles en fonction des règles que vous spécifiez, par exemple en les répartissant entre les domaines d’erreur au sein de la région ou de la zone de disponibilité.

Il existe de nombreux autres services de calcul Azure qui s’appuient sur des machines virtuelles pour effectuer des tâches de calcul. Les services de calcul offrent généralement différents paramètres de redondance qui déterminent la façon dont les machines virtuelles sont distribuées. Par exemple, un service peut fournir un paramètre de redondance de zone, que vous pouvez activer pour distribuer automatiquement des machines virtuelles entre des zones de disponibilité et configurer l’équilibrage de charge.

Réplication : redondance pour les données

La redondance, lorsqu’elle est appliquée à l’état (données), est appelée réplication. Avec la réplication, vous pouvez gérer plusieurs copies en temps réel ou quasiment en temps réel de données actives, appelées réplicas. Pour améliorer la résilience aux risques, vous pouvez distribuer des répliques sur différents emplacements. Si un réplica cesse d’être disponible, le système peut effectuer un basculement pour qu’un autre réplica prenne le relais.

Il existe différents types de réplication, et chacun place des priorités différentes sur la cohérence des données, les performances et le coût. Chaque type de réplication affecte deux métriques clés utilisées dans les discussions sur la continuité d’activité : l’objectif de temps de récupération (RTO), qui est la quantité maximale de temps d’arrêt que vous pouvez tolérer dans un scénario d’urgence et l’objectif de point de récupération (RPO), qui est la quantité maximale de perte de données que vous pouvez tolérer dans un scénario de sinistre. Pour en savoir plus sur ces métriques et leur relation avec la continuité d’activité, consultez Qu’est-ce que la continuité d’activité, la haute disponibilité et la reprise d’activité ?.

En raison de l’importance de la réplication pour répondre aux exigences fonctionnelles et de performances, la plupart des systèmes de base de données et d’autres produits et services de stockage de données incluent un type de réplication comme fonctionnalité étroitement intégrée. Les types de réplication qu’ils offrent sont généralement basés sur leur architecture et sur les façons dont ils sont destinés à être utilisés. Pour en savoir plus sur les types de réplication pris en charge par les services Azure, consultez les guides de fiabilité des services Azure.

Important

La réplication n’est pas la même que la sauvegarde. La réplication synchronise toutes les modifications entre plusieurs réplicas et ne conserve pas les anciennes copies de données.

Supposons que vous supprimez accidentellement certaines données. L’opération de suppression est répliquée sur chaque réplica et vos données sont supprimées partout. Dans ce cas, vous devez probablement restaurer les données supprimées d’une sauvegarde. La sauvegarde est décrite plus loin dans cet article.

Réplication synchrone et asynchrone

Lorsque vous répliquez des données, toutes les modifications apportées à ces données doivent être synchronisées entre les réplicas. Il existe quelques défis principaux lors de la tentative de maintien de la cohérence lorsque les données changent :

• Latence. La mise à jour d’une réplique prend du temps, et plus les répliques sont éloignées, plus il faut de temps pour transmettre des données sur la distance entre les répliques et recevoir un accusé de réception.

• Gestion des modifications. Les données peuvent changer pendant que les réplicas sont synchronisés et la gestion de la cohérence des données peut devenir complexe.

Pour relever ces défis, il existe deux façons principales de répliquer les modifications de données et de gérer la cohérence des données :

• La réplication synchrone nécessite la mise à jour sur plusieurs réplicas avant que la mise à jour soit considérée comme terminée. Le diagramme suivant illustre le fonctionnement de la réplication synchrone :

  

  Dans cet exemple, la séquence d’étapes suivante se produit :

  1. Un client modifie les données et la demande est envoyée au réplica 1, qui traite la demande et stocke les données modifiées.
  2. Le réplica 1 envoie les modifications au réplica 2, qui traite la requête et stocke les données modifiées.
  3. Le réplica 2 accuse réception du changement au réplica 1.
  4. Le réplica 1 accuse réception du changement au client.

  La réplication synchrone peut garantir la cohérence, ce qui signifie qu’elle peut prendre en charge un RPO de zéro. Toutefois, cela est lié au coût des performances. Plus vos réplicas sont éloignés géographiquement et plus il y a de tronçons réseau à parcourir, plus la latence sera introduite par le processus de réplication.

• La réplication asynchrone se produit en arrière-plan. Le diagramme suivant illustre le fonctionnement de la réplication asynchrone :

  

  Dans cet exemple, la séquence d’étapes suivante se produit :

  1. Un client modifie les données et la demande est envoyée au réplica 1.
  2. Le réplica 1 traite la requête, stocke les données modifiées et reconnaît immédiatement la modification apportée au client.
  3. À un moment donné ultérieur, la réplique 1 synchronise la modification avec la réplique 2.

  Étant donné que la réplication asynchrone se produit en dehors des flux de transactions, elle supprime la réplication en tant que contrainte sur les performances de l’application. Toutefois, si vous devez effectuer un basculement vers un autre réplica, il est possible que celui-ci ne dispose pas des données les plus récentes. Votre RPO (objectif de point de récupération) doit donc être supérieur à zéro. Le RPO exact que la réplication asynchrone peut prendre en charge dépend de la fréquence de réplication.

Rôles de réplica

Dans de nombreux systèmes de réplication, les réplicas peuvent prendre différents rôles, ce qui permet de coordonner les modifications apportées aux données et de réduire le risque de conflits. Il existe deux types principaux de rôles, actifs et passifs. Il existe deux façons courantes de distribuer des répliques avec ces rôles :

• La réplication active-passive signifie que vous disposez d’un réplica actif, qui est responsable d’agir comme source de vérité. Toutes les modifications apportées aux données doivent être appliquées à ce réplica. Tous les autres réplicas agissent dans un rôle passif , ce qui signifie qu’ils reçoivent des mises à jour des données du réplica actif, mais ils ne traitent pas directement les modifications des clients. Les réplicas passifs ne sont pas utilisés pour le trafic dynamique, sauf si un basculement se produit, et que les rôles des réplicas changent. Le diagramme suivant montre un système actif-passif avec une réplique passive :

  

  Dans un système actif-passif, la durée nécessaire au basculement détermine le RTO. Généralement, le RTO d’un système actif-passif est mesuré en minutes.

  Certaines solutions de réplication prennent également en charge les réplicas en lecture seule, ce qui vous permet de lire des données depuis les réplicas passifs (mais pas d’écrire). Cette approche peut être utile pour obtenir plus d’utilisation de vos réplicas, par exemple lorsque vous devez effectuer des analyses ou créer des rapports sur des données sans affecter le réplica principal que vous utilisez pour le travail transactionnel de votre application. Plusieurs services Azure prennent en charge les réplicas en lecture seule, notamment Azure Storage avec le type de réplication GRS avec accès en lecture (RA-GRS) et la géoréplication active d'Azure SQL Database.

• La réplication active/active permet d’utiliser simultanément plusieurs réplicas actifs pour le trafic dynamique. De plus, tous les réplicas peuvent traiter les requêtes :

  

  La réplication active/active permet un niveau élevé de performances, car le système peut utiliser les ressources de tous les réplicas. La réplication active peut prendre en charge un RTO de zéro dans certaines situations. Toutefois, ces avantages viennent au prix d'une complexité accrue de la cohérence des données, car des modifications simultanées concurrentes sur plusieurs répliques doivent parfois être rapprochées de manière asynchrone.

Les services de données complexes peuvent combiner la réplication active et active-passive. Par exemple, ils peuvent déployer un ensemble de réplicas dans une région Azure et une autre dans une autre région. Dans chaque région, un seul réplica actif traite les requêtes, tandis qu’un ou plusieurs réplicas passifs sont en attente pour le basculement. Pendant ce temps, les deux régions fonctionnent dans un modèle actif-actif, ce qui permet de répartir le trafic entre eux.

Fonctionnement de la réplication dans les services de données Azure

Chaque service Azure qui stocke les données offre une forme de réplication. Toutefois, chaque service peut utiliser une approche différente spécifique à l’architecture du service et les utilisations prévues.

Par exemple, stockage Azure peut fournir une réplication synchrone et asynchrone via un ensemble de fonctionnalités :

• Plusieurs copies de vos données sont répliquées de manière synchrone dans votre région primaire. Vous pouvez choisir de placer des réplicas sur différents matériels physiques dans un seul centre de données dans un stockage localement redondant (LRS) ou de les répartir entre plusieurs zones de disponibilité pour le stockage redondant interzone (ZRS).
• Si votre région primaire est jumelée et que vous activez le stockage géoredondant (GRS), les données sont également répliquées dans la région jumelée. Étant donné que les régions jumelées sont géographiquement distantes, cette réplication se produit de manière asynchrone pour réduire l’impact sur le débit de votre application.
• Vous pouvez choisir d’utiliser simultanément le stockage redondant interzone et le stockage géoredondant à l’aide du niveau de stockage géoredondant interzone (GZRS). Les données de la région sont répliquées de manière synchrone et les données entre les régions sont répliquées de manière asynchrone.

Pour plus d’informations, consultez Redondance de Stockage Azure.

Un autre exemple est Azure Cosmos DB, qui fournit également la réplication. Toutes les bases de données Azure Cosmos DB ont plusieurs répliques. Lorsque vous distribuez des copies à l'échelle mondiale, cela prend en charge les écritures multi-régions, permettant aux clients d'écrire sur une copie dans n'importe quelle région utilisée. Ces opérations d’écriture sont répliquées de manière synchrone au sein de la région, puis répliquées de manière asynchrone dans d’autres régions. Azure Cosmos DB fournit un mécanisme de résolution des conflits lorsque des conflits d’écriture surviennent entre les différentes répliques. Pour en savoir plus, consultez la distribution globale des données avec Azure Cosmos DB , sous le capot.

Si vous utilisez des machines virtuelles, vous pouvez utiliser Azure Site Recovery pour répliquer des machines virtuelles et leurs disques entre des zones de disponibilité ou vers une autre région Azure.

Lorsque vous concevez une solution Azure, consultez les guides de fiabilité de chaque service pour comprendre comment ce service fournit une redondance et une réplication, y compris entre différents emplacements.

Backup (Sauvegarder)

La sauvegarde prend une copie de vos données à un moment précis dans le temps. En cas de problème, vous pouvez restaurer la sauvegarde ultérieurement. Toutefois, les modifications apportées à vos données qui se sont produites une fois la sauvegarde effectuée ne seront pas effectuées dans la sauvegarde et peuvent être perdues.

En utilisant la sauvegarde, vous pouvez fournir des solutions pour sauvegarder et récupérer vos données dans ou dans le cloud Microsoft Azure. La sauvegarde peut vous protéger contre divers risques, notamment :

• Pertes catastrophiques de matériel ou d’autres infrastructures.
• Altération et suppression des données.
• Cyber-attaques, telles que les ransomwares.

Important

Il est essentiel que vous testiez et vérifiez régulièrement vos processus de sauvegarde et de restauration, en même temps que vos autres étapes de récupération. Le test garantit que vos sauvegardes sont complètes et sans erreur, et que vos processus les restaurent correctement. Les tests sont également importants pour vous assurer que votre équipe comprend les processus à suivre. Pour plus d’informations, consultez Tests et exercices.

Impact de la sauvegarde sur vos besoins

Lorsqu’elles sont utilisées dans le cadre d’une stratégie de récupération d’urgence, les sauvegardes prennent généralement en charge un RTO et un RPO mesurés en heures :

• Le RTO est influencé par le temps nécessaire pour lancer et terminer vos processus de récupération, y compris la restauration d’une sauvegarde et la validation que la restauration s’est terminée avec succès. Selon la taille de la sauvegarde et le nombre de fichiers de sauvegarde à lire, il est courant de prendre plusieurs heures ou encore plus pour restaurer entièrement une sauvegarde.

• Le RPO est influencé par la fréquence de votre processus de sauvegarde. Si vous effectuez des sauvegardes plus fréquemment, cela signifie que vous perdez moins de données si vous devez effectuer une restauration à partir d’une sauvegarde. Toutefois, les sauvegardes nécessitent un stockage et, dans certains cas, elles peuvent affecter les performances du service pendant que les sauvegardes sont effectuées. Pour cette raison, vous devez prendre en compte la fréquence de sauvegarde et trouver le bon équilibre pour les exigences de votre organisation. La fréquence de sauvegarde doit être prise en compte dans la planification de la continuité d’activité.

Certains systèmes de sauvegarde prennent en charge des exigences de sauvegarde plus complexes, notamment plusieurs niveaux de sauvegarde avec différentes périodes de rétention, ainsi que des sauvegardes différentielles ou incrémentielles plus rapides pour enregistrer et consommer moins de stockage.

Sauvegarde dans les services Azure

De nombreux services Azure offrent des fonctionnalités de sauvegarde pour vos données.

Sauvegarde Azure est une solution de sauvegarde dédiée pour plusieurs services Azure clés, notamment des machines virtuelles, stockage Azure et Azure Kubernetes Service (AKS).

En outre, de nombreuses bases de données managées fournissent leurs propres fonctionnalités de sauvegarde dans le cadre du service, telles que :

• Azure SQL Database fournit des sauvegardes automatisées.
• Azure Cosmos DB fournit des fonctionnalités de sauvegarde continues et périodiques.
• Azure Key Vault vous permet de télécharger une sauvegarde des données dans votre coffre.
• Azure App Service fournit une sauvegarde automatique et personnalisée pour les applications web et peut également sauvegarder leurs bases de données.

Sauvegarde et réplication

La sauvegarde et la réplication vous protègent contre différents risques, et les deux approches sont complémentaires les unes des autres.

La réplication prend en charge la résilience quotidienne et est couramment utilisée dans une stratégie de haute disponibilité. Certaines approches de réplication nécessitent peu ou pas de temps d’arrêt ni de perte de données et prennent en charge un RTO et un RPO faibles. Toutefois, la réplication ne vous protège pas contre les risques qui entraînent une perte de données ou une altération.

En revanche, la sauvegarde est souvent une dernière ligne de défense contre les risques catastrophiques. Les sauvegardes nécessitent souvent un RTO et un RPO relativement élevés, bien que la façon dont vous configurez les sauvegardes affecte exactement la hauteur à laquelle elles seront. Une restauration totale à partir d’une sauvegarde fait souvent partie d’un plan de récupération d’urgence.

Préparation des composants pour la redondance

Lorsque vous concevez un système qui utilise la redondance dans le cadre de son architecture, il est important d’envisager également comment :

• Dupliquez la configuration des ressources pour assurer la cohérence.
• Gérez la capacité pendant les défaillances d’instance en surapprovisionnement.

Dupliquer la configuration des ressources

Dans les environnements cloud, la configuration de chacune de vos ressources est essentielle. Par exemple, lorsque vous créez un équilibreur de charge réseau, vous configurez divers paramètres qui affectent son fonctionnement ; et lorsque vous déployez une fonction à l’aide d’Azure Functions, vous configurez les paramètres liés à la sécurité, aux performances et aux paramètres de configuration de l’application. Chaque ressource dans Azure a une certaine configuration qui pilote son comportement.

Lorsque vous gérez des copies redondantes de ressources à différents endroits, il est important de contrôler leur configuration. De nombreux paramètres doivent être configurés de la même façon sur chaque copie, afin que les ressources se comportent de la même façon. Toutefois, certains paramètres peuvent être différents entre chaque copie, comme les références au réseau virtuel d’une région spécifique.

Une approche courante pour maintenir la cohérence dans vos ressources consiste à utiliser l’infrastructure en tant que code (IaC), comme Bicep ou Terraform. Ces outils vous permettent de créer des fichiers qui définissent une ressource, et vous pouvez réutiliser ces définitions pour chaque instance de la ressource. En utilisant IaC, vous pouvez réduire le fardeau de la création et de la gestion de plusieurs instances de ressources à des fins de résilience, et il existe également de nombreux autres avantages. Pour plus d’informations, consultez Qu’est-ce que l’infrastructure en tant que code (IaC) et recommandations relatives à l’utilisation de l’infrastructure en tant que code.

Gérer la capacité avec surprovisionnement

En cas d’échec d’une instance, votre capacité système globale peut être différente de la capacité requise pendant les opérations saines. Par exemple, supposons que vous avez généralement six instances d’un serveur web pour traiter votre trafic web entrant, et que ces instances sont réparties de manière égale entre trois zones de disponibilité Azure dans une région :

Si une zone de disponibilité rencontre une panne, vous risquez de perdre temporairement deux instances et d’être laissé avec seulement quatre instances de serveur web. Si votre application est généralement occupée et nécessite que les six instances continuent à suivre votre trafic normal, l’exécution à une capacité réduite peut affecter les performances de votre solution.

Pour vous préparer aux défaillances, vous pouvez surprovisionner la capacité de votre service. Le surapprovisionnement permet à la solution de tolérer un certain degré de perte de capacité et de continuer à fonctionner sans dégradation des performances.

Pour surprovisionner des instances de votre serveur web pour tenir compte de l’échec d’une zone de disponibilité, procédez comme suit :

1. Déterminez le nombre d’instances nécessaires à votre charge de travail maximale.
2. Récupérez le nombre d’instances en surapprovisionnement en multipliant le nombre d’instances de la charge de travail maximale par un facteur de [(zones/(zones-1)].
3. Arrondissez le résultat au nombre entier le plus proche.

Remarque

Le tableau suivant suppose que vous utilisez trois zones de disponibilité et que vous souhaitez tenir compte de la perte de capacité de l’une de ces zones. Si vos besoins sont différents, ajustez la formule en conséquence.

Nombre d’instances de la charge de travail maximale	Facteur de [(zones/(zones-1)]	Formule	Instances à approvisionner (arrondi)
3	3/2 ou 1,5	(3 x 1,5 = 4,5)	5 instances
4	3/2 ou 1,5	(4 x 1,5 = 6)	6 instances
5	3/2 ou 1,5	(5 x 1,5 = 7,5)	8 instances
6	3/2 ou 1,5	(6 x 1,5 = 9)	9 instances
7	3/2 ou 1,5	(7 x 1,5 = 10,5)	11 instances
8	3/2 ou 1,5	(8 x 1,5 = 12)	12 instances
9	3/2 ou 1,5	(9 x 1,5 = 13,5)	14 cas
10	3/2 ou 1,5	(10 x 1,5 = 15)	15 instances

Dans l’exemple précédent, la charge de travail maximale nécessite six instances du serveur web. Par conséquent, le surapprovisionnement nécessite un total de neuf instances :

Étapes suivantes

Découvrez le basculement et la restauration automatique.