La réplication d'objets dans Azure Blob Storage est un processus asynchrone qui copie des blocs de blobs d'un compte de stockage source vers un compte de stockage de destination. Pour configurer la réplication, vous configurez une stratégie (policy) sur le compte de destination, définissant les comptes source et destination ainsi que les règles pour la réplication. Azure Storage vérifie périodiquement le change feed (flux de modifications) du compte source pour détecter les changements dans les blobs qui correspondent aux règles. Lorsqu'il identifie des changements, tels que de nouveaux blobs ou des modifications, il déclenche la réplication asynchrone de ces blobs vers le compte de destination. Le contenu, les métadonnées, les propriétés et les versions des blobs sont tous copiés.
Quelques-uns des
scénarios pris en charge par la réplication d'objets sont :
Minimiser la
latence : La réplication d'objets réduit la latence des requêtes de lecture en
permettant aux clients de consommer des données à partir d'une région plus
proche physiquement.
Augmenter
l'efficacité pour les charges de travail de calcul : Avec la réplication
d'objets, les charges de travail de calcul peuvent traiter les mêmes ensembles
de blocs de blobs dans différentes régions.
Optimiser la
distribution des données : Vous pouvez traiter ou analyser les données dans un
emplacement unique, puis répliquer uniquement les résultats vers des régions
supplémentaires.
Optimiser les
coûts : Après la réplication des données, vous pouvez réduire les coûts en les
déplaçant vers le niveau d'archivage en utilisant des stratégies de gestion du
cycle de vie.
Voici quelques
points importants liés à la réplication d'objets :
Prérequis : La
réplication d'objets nécessite d'activer le change feed (flux de modifications)
et le versioning (gestion des versions) des blobs sur les comptes source et
destination.
Comptes pris en
charge : La réplication d'objets est prise en charge pour les comptes de
stockage de type général v2 et les comptes de blocs Premium, et elle s'applique
uniquement aux blocs de blobs.
Prise en charge
du chiffrement : La réplication d'objets est prise en charge pour les comptes
chiffrés avec des clés gérées par Microsoft ou par le client, mais pas avec des
clés fournies par le client.
Processus de
réplication : La réplication d'objets copie de manière asynchrone les blocs de
blobs, y compris leurs versions, métadonnées et propriétés, du conteneur source
au conteneur de destination.
Versioning des
blobs : La réplication d'objets nécessite que le versioning des blobs soit
activé. Lorsqu'un blob répliqué est modifié dans le compte source, une nouvelle
version est créée, et les versions actuelle et précédente sont répliquées vers
le compte de destination.
Balises d'index
de blob et instantanés : La réplication d'objets ne copie pas les balises
d'index de blob (blob index tags) ni les instantanés (snapshots) de blob.
Hiérarchisation
des blobs : La réplication d'objets prend en charge les niveaux chaud (hot) et
froid (cool), mais elle échoue si un blob dans le compte source ou de
destination est déplacé vers le niveau d'archivage (archive).
Blobs immuables :
Les stratégies d'immuabilité sur les comptes de destination peuvent affecter la
réplication d'objets.
Stratégies et
règles de réplication : La réplication d'objets est configurée avec des
stratégies (policies) et des règles (rules) de réplication, spécifiant les
conteneurs source et de destination ainsi que les conditions de réplication.
Réplication Tenants Azure : Par défaut, la réplication d'objets entre Tenants (cross-tenant
replication) est autorisée, mais elle peut être interdite en utilisant la
propriété AllowCrossTenantReplication.
État de la
réplication : L'état de la réplication peut être vérifié pour un blob dans le
compte source pour déterminer si la réplication est complète.
Facturation : La
configuration de la réplication d'objets est gratuite, mais des coûts sont
engagés pour les transactions de lecture et d'écriture sur les comptes source
et de destination, les frais d'émission (egress charges) et le traitement du
change feed.
Il est important
de noter que la réplication est asynchrone, donc les comptes source et de
destination ne sont pas immédiatement synchronisés, et il n'y a pas de SLA sur le temps de fin de réplication.
Notes importantes
et explications :
Blob index tags
et les snapshots sont deux fonctionnalités liées à Azure Blob Storage qui offrent
des fonctionnalités supplémentaires pour la gestion et l'organisation des
données.
Blob Index Tags
(Balises d'index de blob) : Blob index tags sont des
paires clé-valeur définies par l'utilisateur qui peuvent être associées à des
blobs individuels. Ces tags fournissent un moyen de catégoriser et d'organiser
des blobs en fonction d'attributs ou de caractéristiques spécifiques. Par
exemple, vous pouvez utiliser des balises d'index pour étiqueter des blobs en
fonction de leur type de contenu, de leur propriétaire, de leur département ou
de toute autre information pertinente.
Les blob index
tags sont utiles dans les scénarios où vous devez appliquer des métadonnées
personnalisées aux blobs, puis utiliser ces métadonnées pour faciliter la
recherche, les rapports et les tâches de gestion. Vous pouvez utiliser Azure
Storage Explorer, Azure PowerShell, Azure CLI ou l'API REST de stockage Azure
pour définir et récupérer des blob index tags.
Il est important
de noter que les blob index tags ne sont pas répliquées dans le cadre du
processus de réplication d'objets. Lorsque vous utilisez la réplication
d'objets, les tags sur le blob source ne sont pas copiés vers le blob de
destination. Si vous comptez sur les blob index tags pour l'organisation ou la
gestion des données, vous devez être conscient de cette limitation lors de
l'utilisation de la réplication d'objets.
Snapshots : Les snapshots dans Azure Blob Storage sont des
copies en lecture seule d'un blob à un moment précis. Ils capturent l'état d'un
blob à un moment donné et vous permettent de conserver le contenu du blob tel
qu'il était à ce moment-là. Les snapshots sont utiles lorsque vous souhaitez
créer une sauvegarde ou un point de contrôle d'un blob avant de le modifier.
Gardez à l'esprit
que les blob index tags et les snapshots (instantanés) offrent des
fonctionnalités précieuses, mais ils servent à des fins différentes. Les blob
index tags aident à l'organisation et à la recherche de métadonnées, tandis que
les snapshots (instantanés) permettent de conserver des versions historiques
des blobs.
Définition de la
politique :
Une définition de politique (policy definition) pour la réplication d'objets est définie au format JSON et contient différentes propriétés pour spécifier le compte de stockage source, le compte de destination et les règles de réplication. Voici un exemple de ce à quoi pourrait ressembler une définition de politique pour la réplication d'objets.
Explication des propriétés :
"policyId" : Un identifiant unique pour la politique de réplication. Vous pouvez choisir un nom significatif pour votre politique.
"sourceAccount" : L'ID de ressource complet du compte de stockage source. Remplacez <subscriptionId>, <resource-group> et <source-storage-account> par votre ID d'abonnement, le nom du groupe de ressources et le nom du compte de stockage source réel.
"destinationAccount"
: L'ID de ressource complet du compte de stockage de destination. Remplacez
<subscriptionId>, <resource-group> et
<destination-storage-account> par votre ID d'abonnement, le nom du groupe
de ressources et le nom du compte de stockage de destination réel.
"rules"
: Un tableau de règles de réplication. Chaque règle définit la manière dont les
blobs sont répliqués d'un conteneur source spécifique à un conteneur de
destination spécifique. Pour chaque règle : "ruleId" : Un identifiant
unique pour la règle de réplication. Vous pouvez attribuer un nom significatif
à la règle.
"sourceContainer"
: Le nom du conteneur source à partir duquel les blobs seront répliqués.
"destinationContainer"
: Le nom du conteneur de destination vers lequel les blobs seront répliqués.
"filters"
: Des filtres facultatifs pour spécifier quels blobs seront répliqués en
fonction de certains critères. Dans l'exemple ci-dessus, la première règle
utilise à la fois la correspondance de préfixe et une heure de création
minimale pour filtrer les blobs à répliquer. La deuxième règle utilise
uniquement la correspondance de préfixe. Une fois que vous avez défini la
politique dans ce format JSON, vous pouvez créer ou mettre à jour la politique
de réplication sur le compte de stockage de destination à l'aide des API du
fournisseur de ressources Azure Storage ou des outils tels qu'Azure PowerShell,
Azure CLI ou le portail Azure.