Évaluer les options de redondance des données pour Stockage Azure

  • 7 minutes

La disponibilité des données est vitale pour la plupart des organisations.

Supposons que vos clients ont rencontré en de rares occasions des problèmes pour accéder à la musique en streaming. En faisant des recherches, vous avez constaté que ces problèmes se produisaient lors de pannes qui affectaient la totalité de la région. Ces occasions étaient rares, mais avaient un impact important.

Pour améliorer la disponibilité des données de votre entreprise, vous décidez d’examiner les options de réplication disponibles pour Stockage Azure.

Ici, vous allez découvrir les différentes options de réplication pour Stockage Azure. Vous allez découvrir comment elles fonctionnent et quand les utiliser. Vous apprendrez également à basculer et migrer vos données entre elles.

Options de réplication pour Stockage Azure

Dans Stockage Azure, vous disposez de plusieurs options pour la réplication. Le choix que vous effectuez dépend du niveau de résilience dont vous avez besoin.

Stockage localement redondant

Illustration that shows three copies of blob data stored in the same datacenter with LRS.

Le stockage localement redondant (LRS) copie vos données trois fois sur des racks de matériel distincts dans un centre de données, à l’intérieur d’une région. Même en cas de défaillance matérielle ou si un travail de maintenance se déroule dans le centre de données, ce type de réplication garantit que les données sont disponibles pour utilisation.

LRS ne vous protège pas contre une panne au niveau du centre de données. Si le centre de données tombe en panne, vous risquez de perdre vos données.

Stockage géographiquement redondant

Illustration that shows blob data copied three times to two different datacenters with GRS.

Avec le stockage géographiquement redondant (GRS), vos données sont copiées trois fois dans une région et trois fois dans une région secondaire associée. De cette façon, si votre région primaire subit une panne, votre région secondaire peut être utilisée.

Stockage géo-redondant avec accès en lecture

Avec GRS, votre région secondaire n’est pas disponible pour l’accès en lecture tant que la région primaire n’échoue pas. Si vous souhaitez lire à partir de la région secondaire, même si la région primaire n’a pas échoué, utilisez le stockage géo-redondant avec accès en lecture (RA-GRS) comme type de réplication.

Stockage redondant interzone

Illustration of data copied to three storage clusters in separate availability zones with ZRS.

Le stockage redondant interzone (ZRS) copie vos données dans trois clusters de stockage dans une seule région. Chaque cluster se trouve dans un emplacement physique différent et est considéré comme une seule et même zone de disponibilité. Chaque cluster utilise ses propres utilitaires distincts pour des tâches comme la mise en réseau et l’alimentation. Si un centre de données subit une panne, vos données restent accessibles à partir d’une autre zone de disponibilité dans la même région Azure.

Étant donné que toutes les zones de disponibilité se trouvent dans une seule région, ZRS ne peut pas protéger vos données contre une panne au niveau régional.

Stockage géoredondant interzone

Le stockage géoredondant interzone (GZRS) combine les avantages de haute disponibilité de ZRS avec GRS. Avec ce type de réplication, vos données sont copiées dans trois zones de disponibilité dans une région. Les données sont également répliquées trois fois dans une autre région secondaire associée. De cette façon, vos données redondantes interzones sont également sécurisées en cas de panne au niveau régional.

Stockage géoredondant interzone avec accès en lecture

Le stockage géoredondant interzone avec accès en lecture (RA-GZRS) utilise la même méthode de réplication que GZRS, mais il vous permet de lire à partir de la région secondaire. Si vous souhaitez lire les données répliquées dans la région secondaire, même si votre région primaire n’est pas confrontée à un temps d’arrêt, utilisez RA-GZRS comme type de réplication.

GZRS et RA-GZRS sont disponibles dans les régions suivantes :

  • Afrique du Sud Nord
  • Australie Est
  • Asie Est
  • Japon Est
  • Centre de la Corée
  • Asie Sud-Est
  • Inde centrale
  • France Centre
  • Allemagne Centre-Ouest
  • Europe Nord
  • Norvège Est
  • Suède Centre
  • Suisse Nord
  • Sud du Royaume-Uni
  • Europe Ouest
  • Centre du Canada
  • USA Centre
  • USA Est
  • USA Est 2
  • États-Unis - partie centrale méridionale
  • USA Ouest 2
  • USA Ouest 3
  • US Gov Virginie
  • Brésil Sud

Régions jumelées

Une région associée est l’endroit où une région Azure est jumelée à une autre dans le même emplacement géographique pour une protection contre les pannes régionales. Les régions associées sont utilisées avec les types de réplication GRS et GZRS.

Illustration that shows a hierarchy of geography, regional pair, region, and datacenters.

Voici une liste indiquant certaines des régions qui sont associées. Vous pouvez obtenir la liste complète dans Régions jumelées Azure.

Région Région
Asie Asie Est Asie Sud-Est
Australie Australie Est Australie Sud-Est
Canada Centre du Canada Est du Canada
Chine Chine du Nord Chine orientale
Europe Europe Nord (Irlande) Europe Ouest (Pays-Bas)
Japon Japon Est OuJapon Est
Amérique du Nord USA Est USA Ouest
Afrique du Sud Afrique du Sud Nord Afrique du Sud Ouest
Royaume-Uni Ouest du Royaume-Uni Sud du Royaume-Uni

Cas d’usage pour chaque type de réplication

Le tableau suivant récapitule le nombre de copies que vous obtenez avec chaque type de réplication et le moment où vous devez l’utiliser.

Type de réplication Copies Cas d’utilisation
LRS 3 Les données restent hautement disponibles mais, pour des raisons de conformité, ne sont pas autorisées à quitter le centre de données local.
GRS 6 L’application a accès aux données, même en cas de panne d’une région entière.
RA-GRS 6 Comme l’application lit à partir de plusieurs emplacements géographiques, vous pouvez servir les utilisateurs à partir d’une position plus proche d’eux.
ZRS 3 Nécessité d’une redondance à plusieurs emplacements physiques mais, pour des raisons de conformité, les données ne sont pas autorisées à quitter une région.
GZRS 6 L’application peut accéder aux données, même si la région primaire a échoué et que votre région secondaire a un centre de données en panne, mais vous ne devez pas lire dans la région secondaire, sauf si la région primaire est en panne.
RA-GZRS 6 Lisez régulièrement les données à partir de votre région secondaire, peut-être pour servir les utilisateurs à partir d’un endroit plus proche d’eux, même si un centre de données est en service dans votre région primaire.

Changer les stratégies de réplication

Vous pouvez changer votre stratégie de réplication pour n’importe quel compte de stockage. Le processus que vous utilisez dépend de la stratégie de réplication actuelle pour votre compte. Par exemple, si vous souhaitez migrer à partir d’un compte de stockage avec LRS, vous avez deux options :

  • Déplacez ou copiez manuellement vos données vers un nouveau compte avec GZRS.
  • Commencez par changer le type de réplication en GRS/RA-GRS, puis créez une demande auprès du support Azure pour une migration dynamique vers GZRS.

Convertir un compte

Si vous utilisez un compte ZRS, vous pouvez le convertir pour utiliser GZRS. Vous convertissez un compte avec le portail Azure, l’interface Azure CLI ou Azure PowerShell.

Par exemple, pour convertir votre compte en GZRS à l’aide d’Azure PowerShell, vous devez utiliser la commande suivante :

Set-AzStorageAccount -ResourceGroupName <resource-group> -AccountName <storage-account> -SkuName "Standard_GZRS"

Changer le type de réplication dans le portail Azure

Vous pouvez également changer le type de réplication de votre compte dans le portail Azure. Par exemple, pour passer de ZRS à GZRS, accédez à votre compte de stockage, sélectionnez Redondance, puis modifiez le type de réplication.

Screenshot of the storage account configuration, where you can change the replication type from ZRS to GZRS.

Migration dynamique

Vous pouvez également utiliser la migration dynamique pour migrer vos données vers un compte qui utilise ZRS, GZRS ou RA-GZRS. Utilisez la migration dynamique pour éviter les temps d’arrêt ou la perte de données. La durée de votre migration dynamique dépend généralement de la quantité de données dans votre compte.

Vous pouvez effectuer une migration dynamique en créant une demande de support Azure dans le portail Azure.

Screenshot of an example Azure support ticket where you can request the service: storage account management, problem type: data migration, and problem subtype: migrate to ZRS, GRS, or RA-GZRS.

Vous serez ensuite contacté par un représentant du support technique au sujet de votre demande de migration dynamique.

Il existe certaines limites à la migration dynamique. Exemple :

  • Contrairement à une migration manuelle, vous ne savez pas exactement quand une migration dynamique sera terminée.
  • Les données peuvent uniquement être migrées vers la même région.
  • La migration dynamique est uniquement prise en charge pour les données conservées dans les types de comptes de stockage standard.
  • Si votre compte contient un partage de fichiers volumineux, la migration dynamique vers GZRS n’est pas prise en charge.

Migration manuelle

La migration manuelle est plus flexible que la migration dynamique. Par exemple, étant donné que vous contrôlez le minutage, vous pouvez utiliser la migration manuelle si vous avez besoin d’une fin à une date fixe.

Pour effectuer une migration manuelle, vous pouvez utiliser l’utilitaire AzCopy ou l’un des différents outils tiers disponibles.

Par exemple, via AzCopy, vous pouvez exécuter la commande suivante dans votre terminal, qui copie tous les objets blob, les répertoires et les conteneurs de votre compte de stockage vers un autre.

azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/?<your-SAS-token>'
'https://<destination-storage-account-name>.blob.core.windows.net/' --recursive