Skip to main content
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Qu'est-ce que la réplication inter-grid ?

Contributeurs netapp-pcarriga netapp-lhalbert
PDF

La réplication inter-grid est la réplication automatique des objets entre des compartiments S3 sélectionnés dans deux systèmes StorageGRID connectés dans un "connexion de fédération de grille". "Clone de compte" est nécessaire pour la réplication entre les grilles.

Flux de production pour la réplication entre les grilles

Le diagramme de flux de travail résume les étapes de configuration de la réplication inter-grille entre les buckets sur deux grilles.

Flux de production de réplication entre les grilles

Conditions requises pour la réplication entre les grilles

Si un compte locataire dispose de l'autorisation Utiliser la connexion à la fédération de grille pour utiliser une ou plusieurs"connexions de fédération de grille" , un utilisateur locataire avec l'autorisation d'accès root peut créer des buckets dans les comptes locataires correspondants sur chaque grille. Ces seaux :

  • Peuvent avoir des noms différents les uns des autres

  • Peut avoir différentes régions

  • La gestion des versions doit être activée

  • Doit être vide

Une fois les deux compartiments créés, la réplication inter-grid peut être configurée pour l'un ou l'autre des compartiments, ou pour les deux.

En savoir plus >>

"Gérer la réplication entre les grilles"

Fonctionnement de la réplication entre les grilles

Vous pouvez configurer la réplication inter-grille pour qu'elle se produise dans un sens ou dans les deux sens.

Réplication dans une direction

Si vous activez la réplication inter-grille pour un bucket sur une seule grille, les objets ajoutés à ce bucket (le bucket source) sont répliqués vers le bucket correspondant sur l'autre grille (le bucket de destination). Cependant, les objets ajoutés au bucket de destination ne sont pas répliqués vers la source. Dans la figure, la réplication inter-grille est activée pour my-bucket de la grille 1 à la grille 2, mais ce n'est pas activé dans l'autre sens.

image montrant la connexion de fédération de grille dans une direction

Réplication dans les deux sens

Si vous activez la réplication inter-grid pour le même compartiment sur les deux grilles, les objets ajoutés à l'un des compartiments sont répliqués sur l'autre grille. Dans la figure, la réplication inter-grille est activée pour my-bucket dans les deux sens.

image montrant la réplication dans une direction par rapport à la réplication dans les deux directions

Que se passe-t-il lorsque des objets sont ingérés ?

Lorsqu'un client S3 ajoute un objet à un compartiment pour lequel la réplication inter-grid est activée, les événements suivants se produisent :

  1. StorageGRID réplique automatiquement l'objet depuis le compartiment source vers le compartiment de destination. Le temps nécessaire pour effectuer cette opération de réplication en arrière-plan dépend de plusieurs facteurs, dont le nombre d'autres opérations de réplication en attente.

    Le client S3 peut vérifier l'état de réplication d'un objet en émettant une requête GetObject ou HeadObject. La réponse inclut un StorageGRID spécifique x-ntap-sg-cgr-replication-status en-tête de réponse, qui a l'une des valeurs suivantes :

    Grille État de la réplication

    Source

    • TERMINÉ : la réplication a réussi pour toutes les connexions de grille.

    • EN ATTENTE : l'objet n'a pas été répliqué vers au moins une connexion de grille.

    • ÉCHEC : La réplication n'est en attente pour aucune connexion au réseau et au moins une a échoué avec une panne permanente. Un utilisateur doit résoudre l’erreur.

    Destination

    RÉPLIQUE : l'objet a été répliqué à partir de la grille source.
    Remarque StorageGRID ne prend pas en charge le x-amz-replication-status en-tête.

  2. StorageGRID utilise les règles ILM actives de chaque grille pour gérer les objets, comme n'importe quel autre objet. Par exemple, l'objet A sur la grille 1 peut être stocké sous forme de deux copies répliquées et conservé indéfiniment, tandis que la copie de l'objet A répliqué sur la grille 2 peut être stockée avec un code d'effacement 2+1 et supprimée après trois ans.

Que se passe-t-il lorsque des objets sont supprimés ?

Comme décrit dans "Supprimer le flux de données", StorageGRID peut supprimer un objet pour l'une des raisons suivantes :

  • Le client S3 émet une demande de suppression.

  • Un utilisateur tenant Manager sélectionne l'"Supprime les objets du compartiment"option de suppression de tous les objets d'un compartiment.

  • Le compartiment dispose d'une configuration en cycle de vie, qui expire.

  • La dernière période de la règle ILM pour l'objet se termine et aucun autre placement n'est spécifié.

Lorsque StorageGRID supprime un objet en raison d'une opération de suppression d'objets dans un compartiment, d'expiration du cycle de vie du compartiment ou d'expiration du placement ILM, l'objet répliqué n'est jamais supprimé d'une autre grille d'une connexion de fédération de grid. Toutefois, les marqueurs de suppression ajoutés au compartiment source par les suppressions du client S3 peuvent éventuellement être répliqués dans le compartiment de destination.

Pour comprendre ce qui se passe lorsqu'un client S3 supprime des objets d'un compartiment dans lequel la réplication inter-grid est activée, vérifiez comment les clients S3 suppriment des objets des compartiments pour lesquels la gestion de version est activée, comme suit :

  • Si un client S3 émet une demande de suppression qui inclut un ID de version, cette version de l'objet est définitivement supprimée. Aucun marqueur de suppression n'est ajouté au godet.

  • Si un client S3 émet une demande de suppression qui n'inclut pas d'ID de version, StorageGRID ne supprime aucune version d'objet. Au lieu de cela, il ajoute un marqueur de suppression au bucket. Le marqueur de suppression oblige StorageGRID à agir comme si l'objet avait été supprimé :

    • Une requête GetObject sans ID de version échoue avec 404 No Object Found

    • Une demande GetObject avec un ID de version valide réussit et renvoie la version de l'objet demandée.

Lorsqu'un client S3 supprime un objet d'un compartiment pour lequel la réplication inter-grid est activée, StorageGRID détermine s'il faut répliquer la demande de suppression vers la destination, comme suit :

  • Si la demande de suppression inclut un ID de version, cette version d'objet est définitivement supprimée de la grille source. Cependant, StorageGRID ne réplique pas les demandes de suppression qui incluent un ID de version, de sorte que la même version d'objet n'est pas supprimée de la destination.

  • Si la demande de suppression n'inclut pas d'ID de version, StorageGRID peut éventuellement répliquer le marqueur de suppression, en fonction de la configuration de la réplication inter-grille pour le bucket :

    • Si vous choisissez de répliquer les marqueurs de suppression (par défaut), un marqueur de suppression est ajouté au compartiment source et répliqué vers le compartiment de destination. En effet, l'objet semble être supprimé sur les deux grilles.

    • Si vous choisissez de ne pas répliquer les marqueurs de suppression, un marqueur de suppression est ajouté au bucket source mais n'est pas répliqué dans le bucket de destination. En effet, les objets supprimés sur la grille source ne sont pas supprimés sur la grille de destination.

Dans la figure, Répliquer les marqueurs de suppression était défini sur Oui lorsque"la réplication inter-grid a été activée" . Les demandes de suppression pour le bucket source qui incluent un ID de version ne suppriment pas les objets du bucket de destination. Les demandes de suppression pour le bucket source qui n'incluent pas d'ID de version semblent supprimer des objets dans le bucket de destination.

image montrant la suppression du client répliqué sur les deux grilles
Remarque Si vous souhaitez que les suppressions d'objets restent synchronisées entre les grilles, créez les compartiments correspondants "Configurations de cycle de vie S3"sur les deux grilles.

Mode de réplication des objets chiffrés

Lorsque vous répliquez les objets entre les grilles à l'aide de la réplication multigrille, vous pouvez chiffrer des objets individuels, utiliser le chiffrement de compartiment par défaut ou configurer le chiffrement au niveau de la grille. Vous pouvez ajouter, modifier ou supprimer les paramètres de chiffrement de compartiment ou de grille par défaut avant ou après l'activation de la réplication entre plusieurs grilles pour un compartiment.

Pour chiffrer des objets individuels, vous pouvez utiliser SSE (chiffrement côté serveur avec des clés gérées par StorageGRID) lors de l'ajout des objets au compartiment source. Utilisez l' x-amz-server-side-encryption`en-tête de la requête et spécifiez `AES256. Voir "Utilisez le cryptage côté serveur".

Remarque L'utilisation de SSE-C (chiffrement côté serveur avec clés fournies par le client) n'est pas prise en charge pour la réplication inter-grille. L'opération d'ingestion échouera.

Pour utiliser le cryptage par défaut pour un compartiment, utilisez une requête PutBucketEncryption et définissez le SSEAlgorithm paramètre sur AES256. Le chiffrement au niveau du compartiment s'applique à tous les objets ingérés sans l' `x-amz-server-side-encryption`en-tête de la demande. Voir "Opérations sur les compartiments".

Pour utiliser le cryptage au niveau de la grille, définissez l'option Stored object Encryption sur AES-256. Le chiffrement au niveau du grid s'applique aux objets qui ne sont pas chiffrés au niveau du compartiment ou qui sont ingérés sans l'en-tête de la x-amz-server-side-encryption demande. Voir "Configurez les options réseau et objet".

Remarque SSE ne prend pas en charge AES-128. Si l'option Cryptage d'objet stocké est activée pour la grille source à l'aide de l'option AES-128, l'utilisation de l'algorithme AES-128 n'est pas propagée à l'objet répliqué. Au lieu de cela, l'objet répliqué utilise le bucket par défaut de la destination ou le paramètre de chiffrement au niveau de la grille, s'il est disponible.

Lors de la détermination du mode de chiffrement des objets source, StorageGRID applique les règles suivantes :

  1. Utilisez l' `x-amz-server-side-encryption`en-tête d'ingestion, le cas échéant.

  2. Si aucun en-tête d'ingestion n'est présent, utilisez le paramètre de chiffrement par défaut du bucket, s'il est configuré.

  3. Si aucun paramètre de bucket n'est configuré, utilisez le paramètre de chiffrement à l'échelle de la grille, s'il est configuré.

  4. Si un paramètre à l’échelle de la grille n’est pas présent, ne cryptez pas l’objet source.

Pour déterminer comment chiffrer les objets répliqués, StorageGRID applique les règles suivantes dans l'ordre suivant :

  1. Utilisez le même chiffrement que l'objet source, sauf si cet objet utilise le chiffrement AES-128.

  2. Si l'objet source n'est pas chiffré ou s'il utilise AES-128, utilisez le paramètre de chiffrement par défaut du bucket de destination, s'il est configuré.

  3. Si le bucket de destination ne dispose pas de paramètre de chiffrement, utilisez le paramètre de chiffrement à l'échelle de la grille de destination, s'il est configuré.

  4. Si un paramètre à l’échelle de la grille n’est pas présent, ne cryptez pas l’objet de destination.

Réplication inter-grille avec S3 Object Lock

Vous pouvez configurer la réplication inter-grille entre les buckets StorageGRID avec S3 Object Lock activé dans les circonstances suivantes.

Lorsque le verrouillage d'objet S3 sur le bucket source est…​ Et le verrouillage de l'objet S3 sur le bucket de destination est…​

Activé

Activé

Désactivées

Activé

Lorsque le verrouillage d’objet S3 sur le bucket source est activé :

  • Les objets sont verrouillés avec des paramètres de rétention à la destination dans cet ordre :

    1. Les valeurs d'en-tête de rétention de l'objet source pour :

      x-amz-object-lock-mode

      x-amz-object-lock-retain-until-date

    2. La rétention par défaut du bucket source, si elle est définie.

    3. La rétention par défaut du bucket de destination, si elle est définie.

    La rétention par défaut du bucket de destination ne remplace pas les paramètres de rétention répliqués à partir de l'objet source.

  • Vous pouvez définir le statut de conservation légale pour l'objet de destination en utilisant x-amz-object-lock-legal-hold lors du téléchargement de l'objet.

  • Une erreur se produit si le locataire ou le bucket de destination ne prend pas en charge les paramètres de verrouillage d'objet S3 de l'objet source. Consultez "Alertes et erreurs de réplication inter-grille."

Lorsque le verrouillage d’objet S3 sur le bucket source est désactivé :

  • Vous pouvez configurer la rétention par défaut sur le bucket de destination pour appliquer les paramètres de rétention S3 Object Lock à l'objet de destination.

  • L'objet de destination ne peut pas définir un statut de conservation légale.

PutObjectTagging et DeleteObjectTagging ne sont pas pris en charge

Les requêtes PutObjectTagging et DeleteObjectTagging ne sont pas prises en charge pour les objets dans les compartiments pour lesquels la réplication inter-grid est activée.

Si un client S3 émet une requête PutObjectTagging ou DeleteObjectTagging, 501 Not Implemented est retourné. Le message est Put(Delete) ObjectTagging isn't available for buckets that have cross-grid replication configured .

PutObjectRetention et PutObjectLegalHold ne sont pas pris en charge

Les requêtes PutObjectRetention et PutObjectLegalHold ne sont pas entièrement prises en charge pour les objets dans les buckets pour lesquels la réplication inter-grille est activée.

Si un client S3 émet une demande PutObjectRetention ou PutObjectLegalHold, les paramètres de l'objet source sont modifiés, mais les modifications ne sont pas appliquées à la destination.

Comment les objets segmentés sont répliqués

La taille de segment maximale de la grille source s'applique aux objets répliqués sur la grille de destination. Lorsque des objets sont répliqués sur une autre grille, le paramètre Taille maximale du segment (Configuration > Système > Options de stockage) de la grille source est utilisé sur les deux grilles. Par exemple, supposons que la taille maximale du segment pour la grille source soit de 1 Go, tandis que la taille maximale du segment de la grille de destination soit de 50 Mo. Si vous ingérez un objet de 2 Go sur la grille source, cet objet est enregistré sous forme de deux segments de 1 Go. Il est également répliqué sur la grille de destination sous forme de deux segments de 1 Go, même si la taille de segment maximale de cette grille est de 50 Mo.