Redondance de Stockage Azure

Stockage Azure stocke toujours plusieurs copies de vos données afin qu’elles soient protégées contre des événements planifiés ou non, notamment des défaillances matérielles temporaires, des pannes du réseau ou de l’alimentation électrique, et des catastrophes naturelles majeures. La redondance garantit que votre compte de stockage répond à ses objectifs de disponibilité et de durabilité, même en cas de défaillance.

Lorsque vous choisissez l’option de redondance la mieux adaptée à votre scénario, réfléchissez aux compromis possibles entre, d’une part, des coûts réduits et, de l’autre, une disponibilité accrue. Les facteurs déterminant le choix de l’option de redondance sont les suivants :

• Comment vos données sont répliquées dans la région principale.
• Réplication éventuelle de vos données vers une deuxième région géographiquement éloignée de la région primaire, afin d’offrir une protection contre les catastrophes régionales (géoréplication).
• Nécessité ou non pour l’application d’avoir accès en lecture aux données répliquées dans la région secondaire si la région primaire n’est plus disponible pour une raison quelconque (géoréplication avec accès en lecture).

Les services qui composent le stockage Azure sont gérés par le biais d’une ressource Azure commune appelée compte de stockage. Ce compte de stockage représente un pool partagé de stockage qui peut être utilisé pour déployer des ressources de stockage telles que des conteneurs d’objets blob (Stockage blob), des partages de fichiers (Azure Files), des tables (Stockage Table) ou des files d’attente (Stockage File d’attente). Pour plus d’informations sur les comptes de stockage Azure, consultez Vue d’ensemble des comptes de stockage.

Le paramètre de redondance d’un compte de stockage est partagé pour tous les services de stockage exposés par ce compte. Toutes les ressources de stockage déployées dans le même compte de stockage ont le même paramètre de redondance. Vous pouvez isoler différents types de ressources dans des comptes de stockage distincts s’ils ont des exigences de redondance différentes.

Redondance dans la région primaire

Les données d’un compte de stockage Azure sont toujours répliquées trois fois dans la région primaire. Le service Stockage Azure offre deux options pour la réplication de vos données dans la région primaire :

• La réplication par stockage localement redondant (LRS) copie vos données de façon synchrone trois fois au sein d’un même emplacement physique dans la région primaire. L’option LRS est la moins coûteuse mais n’est pas recommandée pour des applications nécessitant haute disponibilité et durabilité.
• La réplication par stockage redondant interzone (ZRS) copie vos données de façon synchrone dans trois zones de disponibilité Azure au sein de la région primaire. Pour les applications nécessitant une haute disponibilité, Microsoft recommande l’utilisation de l’option ZRS dans la région primaire, ainsi que la réplication vers une région secondaire.

Stockage localement redondant

Le stockage localement redondant (LRS) réplique trois fois votre compte de stockage au sein d’un même centre de données dans la région primaire. Le stockage localement redondant offre une durabilité des objets d’au moins 99,999999999 % (11 « neuf ») sur une année donnée.

Le stockage localement redondant est l’option de redondance la moins coûteuse et offrant la durabilité la plus faible en comparaison des autres options. Il protège vos données contre les défaillances de disque et de rack du serveur. Toutefois, si un sinistre tel qu’un incendie ou une inondation se produit à l’intérieur du centre de données, tous les réplicas d’un compte de stockage utilisant un stockage localement redondant risquent d’être perdus ou irrécupérables. Pour atténuer ce risque, Microsoft recommande d’utiliser le stockage redondant interzone (ZRS), le stockage géoredondant (GRS) ou le stockage géoredondant interzone (GZRS).

Une demande d’écriture dans un compte de stockage utilisant une réplication LRS se produit de façon synchrone. L’opération d’écriture ne retourne un indicateur de réussite que lorsque les données ont été écrites sur les trois réplicas.

Le diagramme suivant montre comment vos données sont répliquées dans un centre de données unique à l’aide du LRS :

L’option LRS est un bon choix pour les scénarios suivants :

• En revanche, si votre application stocke des données qui peuvent être recréées facilement en cas de perte, vous pouvez opter pour un stockage LRS.
• Si votre application est limitée à la réplication de données uniquement à l’intérieur d’un pays ou d’une région en raison d’exigences de gouvernance des données, vous pouvez opter pour un stockage localement redondant. Dans certains cas, les régions appairées dans lesquelles les données sont géorépliquées peuvent se trouver dans un autre pays ou une autre région. Pour plus d’informations sur les régions associées, consultez la page Régions Azure.
• Si votre scénario utilise des disques non managés Azure, vous pouvez opter pour LRS. Il est possible de créer un compte de stockage utilisant GRS pour les disques non managés Azure, mais cela n’est pas recommandé en raison de problèmes potentiels relatifs à la cohérence de la géoréplication asynchrone.

Stockage redondant interzone

Un stockage redondant interzone (ZRS) réplique les données de votre compte de stockage de façon synchrone dans trois zones de disponibilité Azure au sein de la région primaire. Chaque zone de disponibilité est un emplacement physique distinct avec une alimentation, un refroidissement et une mise en réseau indépendants. Le stockage ZRS offre une durabilité des ressources de stockage d’au moins 99,9999999999 % (12 neuf) sur une année donnée.

Avec l’option ZRS, vos données restent accessibles pour des opérations de lecture et d’écriture, même si une zone devient indisponible. Si une zone devient indisponible, Azure procède à des mises à jour du réseau, telles que le repointage DNS. Ces mises à jour peuvent affecter votre application si vous accédez aux données avant qu’elles soient terminées. Lors de la conception d’applications pour un stockage redondant interzone, suivez les pratiques de gestion des erreurs temporaires, dont l’implémentation de stratégies de nouvelle tentative avec backoff exponentiel.

Une demande d’écriture dans un compte de stockage utilisant une réplication ZRS se produit de façon synchrone. L’opération d’écriture ne retourne un indicateur de réussite que lorsque les données ont été écrites sur tous les réplicas dans les trois zones de disponibilité. Si une zone de disponibilité est temporairement indisponible, l’opération réussit à nouveau une fois les données écrites dans toutes les zones disponibles.

Microsoft recommande d’utiliser un stockage redondant interzone dans la région primaire pour les scénarios nécessitant une haute disponibilité. Le ZRS est également recommandé pour limiter la réplication des données à un pays ou à une région en particulier afin de répondre aux exigences de gouvernance des données.

Microsoft recommande d’utiliser ZRS pour les charges de travail Azure Files. Si une zone n’est plus disponible, il n’est pas nécessaire de remonter des partages de fichiers Azure à partir des clients connectés.

Le diagramme suivant montre comment vos données sont répliquées entre les zones de disponibilité dans la région primaire à l’aide du ZRS :

Une réplication ZRS offre d’excellentes performances, une faible latence et une résilience pour vos données en cas d’indisponibilité temporaire de celles-ci. En revanche, il se peut que cette option à elle seule ne puisse pas protéger vos données contre un sinistre régional dans le cadre duquel plusieurs zones sont affectées définitivement. Pour assurer la protection contre des catastrophes régionales, Microsoft recommande l’utilisation d’un stockage géo-redondant interzone (GZRS), qui utilise une réplication ZRS dans la région primaire et géoréplique vos données dans une région secondaire.

Le niveau d’archive pour le stockage Blob n’est actuellement pas pris en charge pour les comptes ZRS, GZRS ou RA-GZRS. Les disques non managés ne prennent pas en charge par le stockage ZRS ni GZRS.

Pour plus d’informations sur les régions qui prennent en charge ZRS, consultez la liste des régions Azure avec des zones de disponibilité.

Comptes de stockage standard

ZRS est pris en charge pour tous les services stockage Azure via les comptes de stockage v2 standard, notamment :

• Stockage Blob Azure (blobs de blocs chauds et sporadiques, blobs de pages hors disque)
• Azure Files (tous les niveaux standard : optimisé pour les transactions, chaud et froid)
• Stockage Table Azure
• Stockage File d’attente Azure

Pour obtenir une liste des régions qui prennent en charge le stockage redondant interzone (ZRS) pour les comptes standard, consultez Régions Azure prenant en charge le stockage redondant interzone (ZRS) pour les comptes stockage Standard.

Comptes d'objets blob de blocs Premium

ZRS est pris en charge pour les comptes d’objets blob de blocs Premium. Pour plus d’informations sur les objets blob de blocs Premium, consultez Comptes de stockage d’objets blob de blocs Premium.

Pour obtenir une liste des régions qui prennent en charge le stockage redondant interzone (ZRS) pour les comptes objets blob de blocs Premium, consultez Régions Azure prenant en charge le stockage redondant interzone (ZRS) pour les comptes objets blob de blocs Premium.

Comptes de partage de fichiers Premium

ZRS est pris en charge pour les partages de fichiers Premium (Azure Files) via le type de compte de stockage FileStorage.

Pour obtenir une liste des régions qui prennent en charge le stockage redondant interzone (ZRS) pour les comptes de partage de fichiers Premium, consultez Stockage redondant interzone Azure Files pour les partages de fichiers Premium.

Disques managés

Le stockage redondant interzone est pris en charge pour les disques managés avec les limitations suivantes.

Pour obtenir la liste des régions qui prennent en charge le stockage redondant interzone (ZRS) pour les disques managés, consultez Disponibilité régionale.

Redondance dans une région secondaire

Pour les applications nécessitant une durabilité élevée, vous pouvez choisir de copier en plus les données de votre compte de stockage vers une région secondaire située à des centaines de kilomètres de la région primaire. Si votre compte de stockage est copié vers une région secondaire, vos données restent durables, même en cas de panne ou de catastrophe régionales totales empêchant la récupération de la région primaire.

Lorsque vous créez un compte de stockage, vous sélectionnez la région primaire pour le compte. La région secondaire couplée est déterminée en fonction de la région primaire et n’est pas modifiable. Pour plus d’informations sur les régions prises en charge par Azure, voir Régions Azure.

Le service Stockage Azure offre deux options pour la copie de vos données vers une région secondaire :

• La réplication par stockage géoredondant (GRS) copie vos données de façon synchrone trois fois au sein d’un même emplacement physique dans la région primaire en utilisant une réplication LRS. Elle copie ensuite vos données de façon asynchrone vers un emplacement physique unique dans la région secondaire. Dans la région secondaire, vos données sont copiées de manière synchrone trois fois en utilisant un stockage localement redondant.
• La réplication par stockage géoredondant interzone (GZRS) copie vos données de façon synchrone dans trois zones de disponibilité Azure au sein de la région primaire en utilisant une réplication ZRS. Elle copie ensuite vos données de façon asynchrone vers un emplacement physique unique dans la région secondaire. Dans la région secondaire, vos données sont copiées de manière synchrone trois fois en utilisant un stockage localement redondant.

Avec le stockage GRS ou GZRS, les données de la région secondaire sont disponibles pour l’accès en lecture ou en écriture seulement en cas de basculement vers la région principale. Pour un accès en lecture à la région secondaire, configurez votre compte de stockage pour utiliser un stockage géoredondant avec accès en lecture (RA-GRS) ou un stockage géoredondant interzone avec accès en lecture (RA-GZRS). Pour plus d’informations, voir Accès en lecture aux données dans la région secondaire.

Si la région primaire devient indisponible, vous pouvez choisir de basculer vers la région secondaire. Une fois le basculement terminé, la région secondaire devient la région primaire et vous pouvez de nouveau lire et écrire des données. Pour plus d’informations sur la récupération d’urgence et pour savoir comment basculer vers la région secondaire, voir Récupération d’urgence et basculement de compte de stockage.

Stockage géo-redondant

La réplication par stockage géoredondant (GRS) copie vos données de façon synchrone trois fois au sein d’un même emplacement physique dans la région primaire en utilisant une réplication LRS. Elle copie ensuite vos données de façon asynchrone vers un emplacement physique unique dans une région secondaire qui est éloignée de plusieurs centaines de kilomètres de la région primaire. Le stockage GRS offre une durabilité des ressources de stockage d’au moins 99,99999999999999 % (16 neuf) sur une année donnée.

Une opération d’écriture est d’abord validée dans la région primaire, puis répliquée en utilisant un stockage localement redondant. Elle est ensuite répliquée de manière asynchrone vers la région secondaire. Lors de l’écriture des données dans l’emplacement secondaire, celles-ci sont également répliquées au sein de cet emplacement avec le stockage localement redondant.

Le diagramme suivant montre comment vos données sont répliquées à l’aide du GRS ou du RA-GRS :

Stockage géoredondant interzone

Le stockage géo-redondant interzone (GZRS) combine la haute disponibilité fournie par la redondance entre zones de disponibilité avec la protection contre les pannes régionales assurée par la géo-réplication. Les données d’un compte de stockage GZRS sont répliquées dans trois zones de disponibilité Azure au sein de la région primaire, ainsi que vers une région géographique secondaire pour offrir une protection contre des catastrophes régionales. Microsoft recommande d’utiliser une réplication GZRS pour les applications ayant des besoins élevés en termes de cohérence, de durabilité, de disponibilité, de performances et de résilience pour la récupération d’urgence.

Avec un compte de stockage GZRS, vous pouvez continuer à lire et écrire des données si une zone de disponibilité devient indisponible ou n’est pas récupérable. De plus, vos données sont également durables en cas de panne régionale totale ou d’une catastrophe naturelle empêchant la récupération de la région primaire. Le stockage GZRS est conçu pour fournir une durabilité des objets d’au moins 99,99999999999999 % (16 chiffres 9) sur une année donnée.

Le diagramme suivant montre comment vos données sont répliquées à l’aide du GZRS ou du RA-GZRS :

Seuls les comptes de stockage standard v2 à usage général prennent en charge GZRS. GZRS est pris en charge par tous les services stockage Azure, notamment :

• Stockage Blob Azure (objets blob de blocs chauds et froids, objets blob de pages hors disque)
• Azure Files (tous les niveaux standard : optimisé pour les transactions, chaud et froid)
• Stockage Table Azure
• Stockage File d’attente Azure

Pour obtenir une liste des régions qui prennent en charge le stockage géoredondant interzone (GZRS), consultez Régions Azure prenant en charge le stockage géoredondant interzone (GZRS).

Accès en lecture aux données dans la région secondaire

Le stockage géo-redondant (GRS ou GZRS) réplique vos données vers un autre emplacement physique dans la région secondaire pour offrir une protection contre les pannes régionales. Avec un compte configuré pour GRS ou GZRS, les données de la région secondaire ne sont pas directement accessibles aux utilisateurs ou aux applications, sauf si un basculement se produit. Le processus de basculement met à jour l’entrée DNS fournie par le Stockage Azure afin que le point de terminaison secondaire devienne le nouveau point de terminaison principal pour votre compte de stockage. Pendant le processus de basculement, vos données sont inaccessibles. Une fois le basculement terminé, vous pouvez lire et écrire des données vers la nouvelle région principale. Pour plus d'informations, consultez Fonctionnement du basculement du compte de stockage géré par le client.

Si vos applications nécessitent une haute disponibilité, vous pouvez configurer votre compte de stockage pour l’accès en lecture à la région secondaire. Lorsque vous activez l’accès en lecture à la région secondaire, vos données sont toujours accessibles en lecture à partir de la secondaire, y compris dans la situation où la région primaire devient indisponible. Les configurations de stockage géographiquement redondant avec accès en lecture (RA-GRS) ou le stockage géographiquement redondant interzone avec accès en lecture (RA-GZRS) permettent l’accès en lecture vers la région secondaire.

Concevoir vos applications pour l’accès en lecture à la région secondaire

Si votre compte de stockage est configuré pour l’accès en lecture à la région secondaire, vous pouvez concevoir vos applications pour qu’elles passent en toute transparence à la lecture des données de la région secondaire si la région primaire devient indisponible pour une raison quelconque.

La région secondaire est disponible pour l’accès en lecture une fois que vous avez activé RA-GRS ou RA-GZRS, afin que vous puissiez tester votre application à l’avance pour vous assurer qu’elle sera correctement lue à partir du serveur secondaire en cas de panne. Pour plus d’informations sur la conception de vos applications de manière à tirer parti de la géoredondance, consultez Utiliser la géoredondance pour concevoir des applications hautement disponibles.

Lorsque l’accès en lecture à la base de données secondaire est activé, votre application peut être lue à partir du point de terminaison secondaire, ainsi que du point de terminaison principal. Le point de terminaison secondaire ajoute le suffixe -secondary au nom du compte. Par exemple, si votre point de terminaison primaire pour le stockage d’objets blob est myaccount.blob.core.windows.net, le point de terminaison secondaire est myaccount-secondary.blob.core.windows.net. Les clés d’accès pour votre compte de stockage sont les mêmes pour les points de terminaison primaire et secondaire.

Se préparer à une perte de données

Étant donné que les données sont répliquées de manière asynchrone du serveur principal vers la région secondaire, la région secondaire est généralement derrière la région primaire en termes d’opérations d’écriture. Si un sinistre frappait la région principale, il est probable que certaines données seraient perdues et que les fichiers d'un répertoire ou d'un conteneur ne seraient pas cohérents. Pour plus d'informations sur la façon de planifier une perte de données potentielle, consultez Perte de données et incohérences.

Résumé des options de redondance

Les tableaux des sections suivantes résument les options de redondance disponibles pour le Stockage Azure.

Paramètres de durabilité et de disponibilité

Le tableau suivant décrit les principaux paramètres pour chaque option de redondance :

Pour plus d’informations, consultez le contrat de niveau de service pour les comptes de stockage.

Durabilité et disponibilité par scénario de panne

Le tableau suivant montre la durabilité et la disponibilité de vos données dans un scénario spécifique, en fonction du type de redondance appliqué à votre compte de stockage :

¹ Un basculement de compte est nécessaire pour restaurer la disponibilité en écriture si la région primaire devient indisponible. Pour plus d’informations, consultez Récupération d’urgence et basculement de compte de stockage.

Services Stockage Azure pris en charge

Le tableau suivant indique quelles options de redondance sont prises en charge pour chaque service de Stockage Azure.

¹Les partages de fichiers Standard sont pris en charge sur LRS et ZRS. Les partages de fichiers Standard sont pris en charge sur GRS et GZRS tant qu’ils sont inférieurs ou égaux à 5 Tio.
²Les partages de fichiers Premium sont pris en charge sur LRS et ZRS.
³ Les disques managés ZRS présentent certaines limitations. Pour plus de détails, consultez la section Limites de l’article sur les options de redondance pour les disques managés.

Types de compte de stockage pris en charge

Le tableau suivant indique quelles options de redondance sont prises en charge pour chaque type de compte de stockage. Pour plus d’informations sur les types de comptes de stockage, consultez Vue d’ensemble des comptes de stockage.

¹ Les comptes de ce type avec un espace de noms hiérarchique activé permettent également de prendre en charge l’option de redondance spécifiée.

Toutes les données de tous les comptes de stockage sont copiées du compte principal au compte secondaire en fonction de l’option de redondance définie pour le compte de stockage. Des objets, dont des objets blob de blocs, les objets blob d’ajout, des objets blob de pages, des files d’attente, des tables et des fichiers sont copiés.

Les données de tous les niveaux, y compris le niveau d'archivage, sont toujours copiées du niveau principal vers le niveau secondaire lors de la géo-réplication. Le niveau d'archive pour le stockage Blob est actuellement pris en charge pour les comptes LRS, GRS et RA-GRS, mais pas pour les comptes ZRS, GZRS ou RA-GZRS. Pour plus d’informations sur les niveaux d’objets blob, consultez Niveaux d’accès aux données blob.

Les disques non managés ne prennent pas en charge par le stockage ZRS ni GZRS.

Pour des informations sur les prix des différentes options de redondance, voir Tarification de Stockage Azure.

Les comptes de stockage d’objets blob de blocs prennent en charge le stockage localement redondant (LRS) et le stockage redondant interzone (ZRS) dans certaines régions.

Intégrité des données

Le service Stockage Azure vérifie régulièrement l’intégrité des données stockées à l’aide de contrôles de redondance cycliques (CRC). Si une altération des données est détectée, ces données sont réparées à l’aide de données redondantes. Le service Stockage Azure calcule également des sommes de contrôle sur tout le trafic réseau afin de détecter une altération des paquets de données lors du stockage ou de la récupération des données.

Voir aussi

• Modifier l’option de redondance d’un compte de stockage
• Géoréplication (GRS/GZRS/RA-GRS/RA-GZRS)
  • Vérifier la propriété Heure de la dernière synchronisation pour un compte de stockage
  • Récupération d'urgence et basculement de compte de stockage
• Tarifs
  • Stockage Blob
  • Azure Files
  • Stockage Table
  • Stockage de files d’attente
  • Disques Azure