Redondance des données Azure Files

Azure Files stocke toujours plusieurs copies de vos données dans le but de les protéger contre des événements prévus ou non, notamment des défaillances matérielles temporaires, des pannes d’électricité ou de réseau ou encore des catastrophes naturelles. 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 :

• Mode de réplication de vos données dans la région primaire.
• Réplication éventuelle de vos données dans une deuxième région géographiquement éloignée de la région primaire dans le but d’offrir une protection contre les défaillances régionales (géoréplication).

Les partages de fichiers Azure sont gérés par l’intermédiaire d’une ressource Azure commune appelée compte de stockage. Le compte de stockage représente un pool de stockage partagé qui peut être utilisé pour déployer des partages de fichiers. Pour plus d’informations sur les comptes de stockage, consultez Vue d’ensemble des comptes de stockage.

Lorsque vous créez un compte de stockage, vous choisissez un paramètre de redondance pour le compte de stockage qui est partagé par tous les services de stockage exposés par ce compte. Par conséquent, tous les partages de fichiers déployés dans le même compte de stockage ont le même paramètre de redondance. Vous pouvez isoler les partages de fichiers dans des comptes de stockage distincts si leurs exigences de redondance sont différentes.

S’applique à

Modèle de gestion	Modèle de facturation	Échelon médiatique	Redondance	PME	Système de fichiers en réseau (NFS)
Microsoft.Storage	V2 approvisionné	HDD (standard)	Local (LRS)
Microsoft.Storage	V2 approvisionné	HDD (standard)	Zone (ZRS)
Microsoft.Storage	V2 approvisionné	HDD (standard)	Géo (GRS)
Microsoft.Storage	V2 approvisionné	HDD (standard)	GeoZone (GZRS)
Microsoft.Storage	V1 approvisionné	SSD (Premium)	Local (LRS)
Microsoft.Storage	V1 approvisionné	SSD (Premium)	Zone (ZRS)
Microsoft.Storage	Paiement à l’utilisation	HDD (standard)	Local (LRS)
Microsoft.Storage	Paiement à l’utilisation	HDD (standard)	Zone (ZRS)
Microsoft.Storage	Paiement à l’utilisation	HDD (standard)	Géo (GRS)
Microsoft.Storage	Paiement à l’utilisation	HDD (standard)	GeoZone (GZRS)

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. Azure Files propose deux options de réplication des 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é.
• Le stockage redondant interzone (ZRS) copie vos données de manière synchrone sur trois zones de disponibilité Azure dans la région primaire. Pour les applications nécessitant une haute disponibilité, nous vous recommandons d’utiliser le stockage géoredondant interzone (GZRS), qui utilise ZRS dans la région primaire et géoréplique vos données dans 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 LRS offre une durabilité d’au moins 99,999999999 % (11 « neuf ») sur une année donnée.

Le stockage redondant localement est la solution de redondance la moins coûteuse, mais offrant la durabilité la plus faible par rapport aux autres options. Il protège vos données contre les défaillances de disque et de rack du serveur. Toutefois, si une catastrophe telle qu’un incendie ou une inondation se produit dans le centre de données, tous les réplicas d’un compte de stockage utilisant LRS peuvent être perdus ou irrécupérables. Pour atténuer ce risque, nous vous recommandons d’utiliser ZRS, GRS ou GZRS.

Une demande d’écriture dans un compte de stockage qui utilise LRS se produit de manière 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 :

• Si votre application stocke des données qui peuvent être facilement reconstruites en cas de perte de données.
• Si votre application est limitée à une réplication de données seulement à l’intérieur d’un pays ou d’une région en raison d’exigences de gouvernance des données. Dans certains cas, les régions jumelées où sont géorépliquées les données peuvent se trouver dans un autre pays ou une autre région. Pour plus d’informations, consultez les paires de régions Azure et les régions non souhaitées.

LRS est pris en charge dans toutes les régions Azure pour les partages de fichiers HDD. Pour obtenir la liste des régions qui prennent en charge LRS pour les partages de fichiers SSD, consultez la prise en charge de LRS pour les partages de fichiers SSD.

Stockage redondant interzone

Le stockage redondant interzone (ZRS) réplique votre compte de stockage de manière synchrone sur trois zones de disponibilité Azure dans 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é 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é.

L’utilisation du stockage ZRS pour les charges de travail Azure Files présente l’avantage qu’en cas d’indisponibilité d’une zone, il n’est pas nécessaire de remonter les partages de fichiers Azure à partir des clients connectés. Nous recommandons d’utiliser ZRS dans la région principale pour les scénarios nécessitant une haute disponibilité. De même, nous recommandons le stockage ZRS 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.

Remarque

Azure File Sync est redondant interzone dans toutes les régions qui prennent en charge les zones de disponibilité à l’exception de US Gov Virginia. Dans la plupart des cas, nous recommandons aux utilisateurs Azure File Sync de configurer des comptes de stockage pour utiliser ZRS ou GZRS.

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, cette option à elle seule risque ne pas protéger vos données contre un sinistre régional si plusieurs zones sont affectées de façon permanente. Pour la protection contre les catastrophes régionales, nous vous recommandons d’utiliser GZRS.

Prise en charge de ZRS par région

Pour comprendre quelles régions prennent en charge ZRS pour les partages de fichiers standard, consultez la liste des régions Azure et reportez-vous à la colonne de prise en charge de la zone de disponibilité. Le stockage ZRS est pris en charge dans les comptes de stockage v2 standard à usage général pour les trois niveaux standard : optimisé pour les transactions, chaud et sporadique.

ZRS est pris en charge pour les partages de fichiers SSD via le type de FileStorage compte de stockage. Pour obtenir la liste des régions qui prennent en charge ZRS pour les comptes de partage de fichiers SSD, consultez la prise en charge de ZRS pour les partages de fichiers SSD.

Redondance dans une région secondaire

Pour les applications qui nécessitent une grande durabilité pour les partages de fichiers SMB, vous pouvez choisir le stockage géoredondant pour copier 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.

Important

Azure Files prend uniquement en charge la géoredondance (GRS ou GZRS) pour les partages de fichiers HDD. Les partages de fichiers SSD doivent utiliser LRS ou ZRS.

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, consultez la liste des régions Azure.

Azure Files propose deux options pour la copie de vos données dans une région secondaire. Actuellement, les options du stockage géoredondant sont disponibles uniquement pour les partages de fichiers SMB standard.

• 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.

La principale différence entre les réplications GRS et GZRS réside dans la manière dont les données sont répliquées dans la région primaire. Dans la région secondaire, les données sont toujours répliquées de manière synchrone trois fois en utilisant un stockage localement redondant. LRS dans la région secondaire protège vos données contre les défaillances matérielles.

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é 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 avec le stockage 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. Nous recommandons l’utilisation du stockage GZRS pour les applications nécessitant un maximum de cohérence, de durabilité et de disponibilité, ainsi que des performances et une résilience d’excellent niveau pour la reprise d’activité.

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 offrir une durabilité d’au moins 99,99999999999999 % (16 « neuf ») sur une année donnée.

Le diagramme suivant montre comment vos données sont répliquées avec le stockage GZRS :

Seuls les comptes de stockage standard v2 à usage général prennent en charge GZRS.

Pour déterminer si une région prend en charge GZRS, consultez la liste des régions Azure. Pour prendre en charge le GZRS, une région doit prendre en charge les zones de disponibilité et avoir une région jumelée.

Fréquence des instantanés et de synchronisation

Pour garantir que les partages de fichiers redondants géo-zone et géozone sont dans un état cohérent lorsqu’un basculement se produit, un instantané système est créé dans la région primaire toutes les 15 minutes et est répliqué dans la région secondaire. Quand un basculement se produit vers la région secondaire, l’état du partage est basé sur la dernière capture instantanée du système dans la région secondaire. En raison du décalage géographique ou d’autres problèmes, le dernier instantané système dans la région secondaire peut être antérieur à 15 minutes.

La propriété Heure de la dernière synchronisation (LST) sur le compte de stockage indique la dernière fois où les données de la région primaire ont été écrites avec succès dans la région secondaire. Pour Azure Files, l’heure de la dernière synchronisation est basée sur le dernier instantané système dans la région secondaire. Vous pouvez utiliser PowerShell ou Azure CLI pour vérifier l’heure de la dernière synchronisation pour un compte de stockage.

Il est important de bien comprendre les points ci-dessous concernant la propriété d’heure de la dernière synchronisation :

• La propriété d’heure de la dernière synchronisation sur le compte de stockage est basée sur le service (Fichiers, Objets blob, Tables, Files d’attente) dans le compte de stockage le plus éloigné.
• L’heure de la dernière synchronisation n’est pas mise à jour si aucune modification n’a été apportée au compte de stockage.
• Le calcul de l’heure de la dernière synchronisation peut expirer si le nombre de partages de fichiers dépasse 100 par compte de stockage. Il est recommandé d’utiliser moins de 100 partages de fichiers par compte de stockage.

Remarques relatives au test de basculement

Avec le stockage GRS ou GZRS, les partages de fichiers ne sont pas accessibles dans la région secondaire, sauf si un basculement se produit. Si la région primaire devient indisponible, vous pouvez choisir de basculer vers la région secondaire. Le processus de basculement met à jour l’entrée DNS fournie par Azure Files 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. 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, consultez Récupération d’urgence et basculement Azure Files.

Important

Azure Files ne prend pas en charge le stockage géoredondant avec accès en lecture (RA-GRS) ni le stockage géoredondant interzone avec accès en lecture (RA-GZRS). Si un compte de stockage est configuré pour utiliser le stockage RA-GRS ou RA-GZRS, les partages de fichiers sont configurés et facturés en tant que stockage GRS ou GZRS.

Les éléments suivants peuvent avoir un impact sur votre capacité à basculer vers la région secondaire :

• Le basculement du compte de stockage est bloqué s’il n’existe pas de capture instantanée du système dans la région secondaire.
• Le basculement du compte de stockage est bloqué si le compte contient plus de 100 000 partages de fichiers. Pour basculer le compte de stockage, ouvrez une demande de support.
• Les handles et les baux de fichiers ne sont pas conservés lors du basculement, et les clients doivent démonter et remonter les partages de fichiers.
• Le quota de partage de fichiers peut changer après le basculement. Le quota de partage de fichiers dans la région secondaire repose sur le quota configuré lors de la création de l’instantané système dans la région primaire.
• Les opérations de copie en cours sont abandonnées quand un basculement se produit. Une fois le basculement vers la région secondaire terminé, réessayez l’opération de copie.

Pour basculer un compte de stockage, consultez lancer un basculement de compte.

Géo-redondance pour les partages de fichiers SSD

Comme mentionné précédemment, les options de géoredondance (GRS et GZRS) ne sont pas prises en charge pour les partages de fichiers SSD. Toutefois, vous pouvez réaliser une géo-redondance par d’autres moyens.

Dans les scénarios Azure File Sync, vous pouvez synchroniser votre partage de fichiers Azure (votre point de terminaison cloud), un serveur de fichiers Windows local et un partage de fichiers monté s’exécutant sur une machine virtuelle dans une autre région Azure (le point de terminaison de votre serveur à des fins de récupération d’urgence). Vous devez désactiver la hiérarchisation cloud pour vous assurer que toutes les données sont présentes localement et approvisionner suffisamment de stockage sur la machine virtuelle Azure pour contenir l’intégralité du jeu de données. Pour s’assurer que les modifications sont répliquées rapidement dans la région secondaire, les fichiers ne doivent être accessibles et modifiés que sur le point de terminaison du serveur plutôt que dans Azure.

Vous pouvez également créer votre propre script pour copier des données vers un compte de stockage dans une région secondaire à l’aide d’outils tels que AzCopy (utilisez la version 10.4 ou ultérieure pour conserver les listes de contrôle d’accès et les timestamps).

Résumé des options de redondance

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

Paramètres de durabilité et de disponibilité

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

Paramètre	LRS	ZRS	GRS (Gymnastique Rythmique et Sportive)	GZRS
Pourcentage de durabilité sur une année donnée	Au moins 99,999999999 % (11 chiffres 9)	Au moins 99,9999999999 % (12 chiffres 9)	Au moins 99,99999999999999 % (16 chiffres 9)	Au moins 99,99999999999999 % (16 chiffres 9)
Disponibilité pour les requêtes de lecture	Au moins 99,9 % (99 % pour le niveau Sporadique)	Au moins 99,9 % (99 % pour le niveau Sporadique)	Au moins 99,9 % (99 % pour le niveau Sporadique)	Au moins 99,9 % (99 % pour le niveau Sporadique)
Disponibilité pour les requêtes d’écriture	Au moins 99,9 % (99 % pour le niveau Sporadique)	Au moins 99,9 % (99 % pour le niveau Sporadique)	Au moins 99,9 % (99 % pour le niveau Sporadique)	Au moins 99,9 % (99 % pour le niveau Sporadique)
Nombre de copies des données conservées sur des nœuds distincts	Trois copies au sein d’une même région	Trois copies dans des zones de disponibilité distinctes au sein d’une même région	Six copies au total, dont trois dans la région primaire et trois dans la région secondaire	Six copies au total, dont trois dans des zones de disponibilité distinctes dans la région primaire et trois copies redondantes localement dans la région secondaire

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 indique si vos données sont durables et disponibles dans un scénario donné, en fonction du type de redondance appliqué à votre compte de stockage. Azure Files ne prend pas en charge l’accès en lecture à la région secondaire si la région primaire devient indisponible, sauf si un basculement se produit.

Scénario de panne	LRS	ZRS	GRS (Gymnastique Rythmique et Sportive)	GZRS
Un nœud au sein d’un centre de données devient indisponible	Oui	Oui	Oui	Oui
Indisponibilité d’un centre de données complet (zonal ou non)	Non	Oui	Oui1	Oui
Une panne à l’échelle de la région se produit dans la région primaire	Non	Non	Oui1	Oui1

¹ Un basculement de compte est nécessaire pour restaurer la disponibilité en écriture si la région primaire devient indisponible.

Pour prendre connaissance du prix de chaque option de redondance, consultez Tarification Azure Files.

Prise en charge des régions en fonction de différents modèles de facturation

Vous pouvez vérifier la prise en charge des régions pour différents modèles de facturation à l’aide des commandes suivantes.

portail

Pour afficher la prise en charge des régions en fonction de différents modèles de facturation, utilisez Azure PowerShell ou Azure CLI.

PowerShell

# Login to Azure account
Connect-AzAccount

# Track down the subscription ID in GUID format
$subscriptionID = "your-subscription-id-number"

# Get Token
$token = Get-AzAccessToken

# Invoke SRP list SKU API, and get the returned SKU list
$result = Invoke-RestMethod -Method Get -Uri "https://management.azure.com/subscriptions/$($subscriptionID)/providers/Microsoft.Storage/skus?api-version=2024-01-01" -Headers @{"Authorization" = "Bearer $($token.Token)"}

# Filter the SKU list to get the required information, customization required here to get the best result.
$filteredResult = $result | `
    Select-Object -ExpandProperty value | `
    Where-Object {
        $_.resourceType -eq "storageAccounts" -and
        # Filter based on your needs. FileStorage kind includes pv2, and pv1 file share, where StorageV2 kind include PayGO file shares.
        $_.kind -in @("FileStorage", "StorageV2") -and
        # Filter based on your needs. "Standard_" for PayGO file share, "StandardV2_" for Pv2 file share, "Premium_" for pv1 file shares.
        # $_.name.StartsWith("StandardV2_") -and
        # Change region based on your need to see if we currently support the region (all small cases, no space in between).
        # $_.locations -eq "italynorth" -and
        $_.name -notin @("Standard_RAGRS", "Standard_RAGZRS")
    }

if ($filteredResult.Count -eq 0) {
    Write-Output "No results found."
} else {
    $filteredResult | `
        Select-Object `
            -Property `
                @{
                    Name = "sku";
                    Expression = { $_.name }
                }, `
                kind, `
                @{
                    Name = "mediaTier";
                    Expression = {
                        if ($_.tier -eq "Premium") {
                            "SSD"
                        } elseif ($_.tier -eq "Standard") {
                            "HDD"
                        } else {
                            "Unknown"
                        }
                    }
                }, `
                @{
                    Name = "billingModel";
                    Expression = {
                        if ($_.name.StartsWith("StandardV2_") -or
                            $_.name.StartsWith("PremiumV2_")
                        ) {
                            "ProvisionedV2"
                        } elseif ($_.name.StartsWith("Premium_")) {
                            "ProvisionedV1"
                        } else {
                            "PayAsYouGo"
                        }
                    }
                }, `
                @{
                    Name = "location";
                    Expression = { $_.locations | Select-Object -First 1 }
                } | ft sku, kind, mediaTier, billingModel, location
}

Azure CLI

Ce script utilise le processeur JSON de ligne de commande jq. Pour le télécharger, visitez https://jqlang.org/download/

# Login to Azure account
Az login

# Track down the subscription ID in GUID format and set subscription ID
subscriptionID="your-subscription-id-number"

# Get Token
token=$(az account get-access-token --query accessToken --output tsv)

# Invoke SRP list SKU API, and get the returned SKU list
result=$(az rest --method get --uri "https://management.azure.com/subscriptions/$subscriptionID/providers/Microsoft.Storage/skus?api-version=2024-01-01" --headers "Authorization=Bearer $token")

# Filter the SKU list to get the required information, customization required here to get the best result.
filteredResult=$(echo $result | jq '.value[] | select(.resourceType == "storageAccounts" and (.kind == "FileStorage" or .kind == "StorageV2") and (.name | test("^(?!Standard_RAGRS|Standard_RAGZRS)")))' )

if [ -z "$filteredResult" ]; then
    echo "No results found."
else
    # Print the table header
    printf "%-30s %-15s %-10s %-20s %-15s\n" "SKU" "Kind" "MediaTier" "BillingModel" "Location"
    # Print the filtered results
    echo $filteredResult | jq -r '. | "\(.name)\t\(.kind)\t\(.tier | if . == "Premium" then "SSD" elif . == "Standard" then "HDD" else "Unknown" end)\t\(.name | if test("^StandardV2_|^PremiumV2_") then "ProvisionedV2" elif test("^Premium_") then "ProvisionedV1" else "PayAsYouGo" end)\t\(.locations)"' | while IFS=$'\t' read -r sku kind mediaTier billingModel location; do
        printf "%-30s %-15s %-10s %-20s %-15s\n" "$sku" "$kind" "$mediaTier" "$billingModel" "$location"
    done
fi

Voir aussi

• Modifier l’option de redondance d’un compte de stockage
• Utilisez la géo-redondance pour concevoir des applications hautement disponibles