Opérations des API REST StorageGRID S3
Des opérations sont ajoutées à l'API REST S3 qui sont spécifiques à un système StorageGRID.
DEMANDE de cohérence des compartiments
La demande D'obtention de cohérence de godet vous permet de déterminer le niveau de cohérence appliqué à un compartiment particulier.
Les contrôles de cohérence par défaut garantissent la lecture après écriture des nouveaux objets.
Pour effectuer cette opération, vous devez disposer de l'autorisation s3:GetBucketConsistency, ou être root de compte.
Exemple de demande
GET /bucket?x-ntap-sg-consistency HTTP/1.1
Date: date
Authorization: authorization string
Host: host
Réponse
Dans le XML de réponse, <Consistency>
renvoie l'une des valeurs suivantes :
Contrôle de cohérence | Description |
---|---|
tous |
Tous les nœuds reçoivent les données immédiatement, sinon la requête échoue. |
forte croissance mondiale |
Garantit une cohérence de lecture après écriture pour toutes les demandes client sur tous les sites. |
site fort |
Garantit la cohérence de lecture après écriture pour toutes les demandes client dans un site. |
lecture-après-nouvelle-écriture |
(Valeur par défaut) assure la cohérence en lecture après écriture des nouveaux objets et la cohérence des mises à jour des objets. Offre une haute disponibilité et une protection des données garanties. Correspondance avec les garanties de cohérence Amazon S3. Remarque : si votre application utilise des demandes HEAD sur des objets qui n'existent pas, vous pouvez recevoir un nombre élevé de 500 erreurs de serveur interne si un ou plusieurs nœuds de stockage ne sont pas disponibles. Pour éviter ces erreurs, définissez le contrôle de cohérence sur « disponible », sauf si vous avez besoin de garanties de cohérence similaires à Amazon S3. |
Disponible (cohérence possible pour les opérations DE TÊTE) |
Se comporte de la même manière que le niveau de cohérence « entre la date et la nouvelle écriture », mais n'assure qu'une cohérence éventuelle pour les opérations DE TÊTE. Niveaux de disponibilité supérieurs à ceux de la « nouvelle écriture » en cas d'indisponibilité des nœuds de stockage Diffère des garanties de cohérence Amazon S3 pour les opérations HEAD uniquement. |
Exemple de réponse
HTTP/1.1 200 OK Date: Fri, 18 Sep 2020 01:02:18 GMT Connection: CLOSE Server: StorageGRID/11.5.0 x-amz-request-id: 12345 Content-Length: 127 Content-Type: application/xml <?xml version="1.0" encoding="UTF-8"?> <Consistency xmlns="http://s3.storagegrid.com/doc/2015-02-01/">read-after-new-write</Consistency>
PUT Bucket Consistency demandée
La demande de cohérence PUT bucket permet de spécifier le niveau de cohérence à appliquer aux opérations effectuées dans un compartiment.
Les contrôles de cohérence par défaut garantissent la lecture après écriture des nouveaux objets.
Pour effectuer cette opération, vous devez disposer de l'autorisation s3:PutBuckeConsistency, ou être root de compte.
Demande
Le x-ntap-sg-consistency
le paramètre doit contenir l'une des valeurs suivantes :
Contrôle de cohérence | Description |
---|---|
tous |
Tous les nœuds reçoivent les données immédiatement, sinon la requête échoue. |
forte croissance mondiale |
Garantit une cohérence de lecture après écriture pour toutes les demandes client sur tous les sites. |
site fort |
Garantit la cohérence de lecture après écriture pour toutes les demandes client dans un site. |
lecture-après-nouvelle-écriture |
(Valeur par défaut) assure la cohérence en lecture après écriture des nouveaux objets et la cohérence des mises à jour des objets. Offre une haute disponibilité et une protection des données garanties. Correspondance avec les garanties de cohérence Amazon S3. Remarque : si votre application utilise des demandes HEAD sur des objets qui n'existent pas, vous pouvez recevoir un nombre élevé de 500 erreurs de serveur interne si un ou plusieurs nœuds de stockage ne sont pas disponibles. Pour éviter ces erreurs, définissez le contrôle de cohérence sur « disponible », sauf si vous avez besoin de garanties de cohérence similaires à Amazon S3. |
Disponible (cohérence possible pour les opérations DE TÊTE) |
Se comporte de la même manière que le niveau de cohérence « entre la date et la nouvelle écriture », mais n'assure qu'une cohérence éventuelle pour les opérations DE TÊTE. Niveaux de disponibilité supérieurs à ceux de la « nouvelle écriture » en cas d'indisponibilité des nœuds de stockage Diffère des garanties de cohérence Amazon S3 pour les opérations HEAD uniquement. |
Remarque: en général, vous devez utiliser la valeur de contrôle de cohérence "entre les nouvelles écritures". Si les demandes ne fonctionnent pas correctement, modifiez le comportement du client de l'application si possible. Ou configurez le client afin de spécifier le contrôle de cohérence pour chaque requête d'API. Réglez le contrôle de cohérence au niveau du godet uniquement en dernier recours.
Exemple de demande
PUT /bucket?x-ntap-sg-consistency=strong-global HTTP/1.1
Date: date
Authorization: authorization string
Host: host
DEMANDE DE dernier accès au compartiment
La demande D'heure de dernier accès À GET Bucket vous permet de déterminer si les dernières mises à jour de temps d'accès sont activées ou désactivées pour les compartiments individuels.
Pour effectuer cette opération, vous devez disposer de l'autorisation s3:GetBucketLastAccessTime, ou être root de compte.
Exemple de demande
GET /bucket?x-ntap-sg-lastaccesstime HTTP/1.1
Date: date
Authorization: authorization string
Host: host
Exemple de réponse
Cet exemple montre que les mises à jour du temps de dernier accès sont activées pour le compartiment.
HTTP/1.1 200 OK Date: Sat, 29 Nov 2015 01:02:18 GMT Connection: CLOSE Server: StorageGRID/10.3.0 x-amz-request-id: 12345 Content-Length: 127 Content-Type: application/xml <?xml version="1.0" encoding="UTF-8"?> <LastAccessTime xmlns="http://s3.storagegrid.com/doc/2015-02-01/">enabled </LastAccessTime>
DEMANDE de temps de dernier accès au compartiment
La demande d'heure de dernier accès AU compartiment PERMET d'activer ou de désactiver les mises à jour des temps de dernier accès pour chaque compartiment. La désactivation des mises à jour du temps d'accès précédent améliore les performances. Il s'agit du paramètre par défaut pour tous les compartiments créés avec la version 10.3.0, ou ultérieure.
Pour effectuer cette opération, vous devez disposer de l'autorisation s3:PutBuckLastAccessTime pour un compartiment ou être un compte root.
À partir de StorageGRID version 10.3, les mises à jour de l'heure du dernier accès sont désactivées par défaut pour tous les nouveaux compartiments. Si des compartiments ont été créés à l'aide d'une version antérieure de StorageGRID et que vous souhaitez faire correspondre le nouveau comportement par défaut, vous devez désactiver explicitement les mises à jour de la dernière heure d'accès pour chacune de ces rubriques précédentes. Vous pouvez activer ou désactiver les mises à jour de l'heure du dernier accès à l'aide de la demande D'heure du dernier accès AU compartiment, la case à cocher S3 > seaux > Modifier le dernier paramètre d'accès dans le Gestionnaire de locataires ou l'API de gestion des locataires. |
Si les dernières mises à jour de temps d'accès sont désactivées pour un compartiment, les opérations suivantes sont appliquées sur le compartiment :
-
LES demandes GET Object, GET Object ACL, GET Object Tagging et HEAD Object ne mettent pas à jour l'heure du dernier accès. L'objet n'est pas ajouté aux files d'attente pour l'évaluation de la gestion du cycle de vie des informations (ILM).
-
PUT Object : les demandes de copie et DE BALISAGE d'objets QUI mettent à jour uniquement les métadonnées mettent également à jour l'heure du dernier accès. L'objet est ajouté aux files d'attente pour l'évaluation ILM.
-
Si les mises à jour de l'heure du dernier accès sont désactivées pour le compartiment source, PLACER l'objet - les demandes de copie ne mettent pas à jour l'heure du dernier accès pour le compartiment source. L'objet copié n'est pas ajouté aux files d'attente pour l'évaluation ILM du compartiment source. Cependant, pour la destination, PLACER l'objet - demandes de copie toujours mettre à jour l'heure du dernier accès. La copie de l'objet est ajoutée aux files d'attente pour l'évaluation ILM.
-
Terminer les demandes de téléchargement de pièces multiples mises à jour de l'heure de dernier accès. L'objet terminé est ajouté aux files d'attente pour l'évaluation ILM.
Exemples de demandes
Cet exemple permet d'activer le temps du dernier accès pour un compartiment.
PUT /bucket?x-ntap-sg-lastaccesstime=enabled HTTP/1.1
Date: date
Authorization: authorization string
Host: host
Cet exemple désactive l'heure du dernier accès pour un compartiment.
PUT /bucket?x-ntap-sg-lastaccesstime=disabled HTTP/1.1
Date: date
Authorization: authorization string
Host: host
SUPPRIME la demande de configuration de notification des métadonnées de compartiment
La demande de configuration DE notification DE métadonnées DELETE Bucket vous permet de désactiver le service d'intégration de recherche pour les compartiments individuels en supprimant le XML de configuration.
Pour effectuer cette opération, vous devez disposer de l'autorisation s3:DeleteBuceMeteatanotification pour un compartiment, ou être un compte root.
Exemple de demande
Cet exemple montre la désactivation du service d'intégration de recherche pour un compartiment.
DELETE /test1?x-ntap-sg-metadata-notification HTTP/1.1
Date: date
Authorization: authorization string
Host: host
LIRE la demande de configuration de notification des métadonnées de compartiment
La demande de configuration DE notification DE métadonnées GET Bucket vous permet de récupérer le XML de configuration utilisé pour configurer l'intégration de la recherche pour chaque compartiment.
Pour effectuer cette opération, vous devez disposer de l'autorisation s3:GetBuckeMetadanotification, ou être root de compte.
Exemple de demande
Cette demande récupère la configuration de notification des métadonnées pour le compartiment nommé bucket
.
GET /bucket?x-ntap-sg-metadata-notification HTTP/1.1
Date: date
Authorization: authorization string
Host: host
Réponse
L'organe de réponse inclut la configuration de notification des métadonnées pour le compartiment. La configuration de notification des métadonnées vous permet de déterminer la configuration du compartiment pour l'intégration de la recherche. En d'autres termes, il vous permet de déterminer les objets à indexer et à quels terminaux leurs métadonnées d'objet sont envoyées.
<MetadataNotificationConfiguration> <Rule> <ID>Rule-1</ID> <Status>rule-status</Status> <Prefix>key-prefix</Prefix> <Destination> <Urn>arn:aws:es:_region:account-ID_:domain/_mydomain/myindex/mytype_</Urn> </Destination> </Rule> <Rule> <ID>Rule-2</ID> ... </Rule> ... </MetadataNotificationConfiguration>
Chaque configuration de notification de métadonnées comprend une ou plusieurs règles. Chaque règle indique les objets qu'elle s'applique ainsi que la destination à laquelle StorageGRID doit envoyer les métadonnées d'objet. Les destinations doivent être spécifiées à l'aide de l'URN d'un terminal StorageGRID.
Nom | Description | Obligatoire |
---|---|---|
Configuration de la MetadaNotificationConfiguration |
Balise de conteneur pour les règles utilisées pour spécifier les objets et la destination des notifications de métadonnées. Contient un ou plusieurs éléments de règle. |
Oui. |
Règle |
Balise de conteneur d'une règle qui identifie les objets dont les métadonnées doivent être ajoutées à un index spécifié. Les règles avec des préfixes qui se chevauchent sont rejetées. Inclus dans l'élément MetadaNotificationConfiguration. |
Oui. |
ID |
Identifiant unique de la règle. Inclus dans l'élément règle. |
Non |
État |
L'état peut être « activé » ou « désactivé ». Aucune action n'est prise pour les règles désactivées. Inclus dans l'élément règle. |
Oui. |
Préfixe |
Les objets qui correspondent au préfixe sont affectés par la règle et leurs métadonnées sont envoyées à la destination spécifiée. Pour faire correspondre tous les objets, spécifiez un préfixe vide. Inclus dans l'élément règle. |
Oui. |
Destination |
Balise de conteneur pour la destination d'une règle. Inclus dans l'élément règle. |
Oui. |
Urne |
URN de la destination où les métadonnées d'objet sont envoyées. Doit être l'URN d'un terminal StorageGRID avec les propriétés suivantes :
Les terminaux sont configurés à l'aide du Gestionnaire de locataires ou de l'API de gestion des locataires. Ils se présentent sous la forme suivante :
Le noeud final doit être configuré avant la soumission du XML de configuration, ou la configuration échouera avec une erreur 404. L'urne est incluse dans l'élément destination. |
Oui. |
Exemple de réponse
XML inclus entre le <MetadataNotificationConfiguration></MetadataNotificationConfiguration>
les balises indiquent comment l'intégration avec un terminal d'intégration de la recherche est configurée pour le compartiment. Dans cet exemple, les métadonnées d'objet sont envoyées à un index Elasticsearch nommé current
et le type nommé 2017
Hébergé dans un domaine AWS nommé records
.
HTTP/1.1 200 OK Date: Thu, 20 Jul 2017 18:24:05 GMT Connection: KEEP-ALIVE Server: StorageGRID/11.0.0 x-amz-request-id: 3832973499 Content-Length: 264 Content-Type: application/xml <MetadataNotificationConfiguration> <Rule> <ID>Rule-1</ID> <Status>Enabled</Status> <Prefix>2017</Prefix> <Destination> <Urn>arn:aws:es:us-east-1:3333333:domain/records/current/2017</Urn> </Destination> </Rule> </MetadataNotificationConfiguration>
PUT Bucket metadata notification configuration
La demande de configuration DE notification DE métadonnées PUT compartiments vous permet d'activer le service d'intégration de la recherche pour chaque compartiment. Le XML de configuration de notification de métadonnées que vous fournissez dans le corps de la requête spécifie les objets dont les métadonnées sont envoyées à l'index de recherche de destination.
Pour effectuer cette opération, vous devez disposer de l'autorisation s3:PutBuckeMetadanotification pour un compartiment ou être un compte root.
Demande
La demande doit inclure la configuration de notification de métadonnées dans l'organisme de demande. Chaque configuration de notification de métadonnées comprend une ou plusieurs règles. Chaque règle spécifie les objets à lesquels elle s'applique, ainsi que la destination vers laquelle StorageGRID doit envoyer les métadonnées d'objet.
Les objets peuvent être filtrés sur le préfixe du nom de l'objet. Par exemple, vous pouvez envoyer les métadonnées pour les objets avec le préfixe /images
à une destination et à des objets avec le préfixe /videos
à un autre.
Les configurations dont les préfixes se chevauchent ne sont pas valides et sont rejetées lors de leur envoi. Par exemple, une configuration comprenant une règle pour les objets avec le préfixe test
et une seconde règle pour les objets avec le préfixe test2
ne serait pas autorisé.
Les destinations doivent être spécifiées à l'aide de l'URN d'un terminal StorageGRID. Le noeud final doit exister lorsque la configuration de notification de métadonnées est soumise, ou que la demande échoue en tant que 400 Bad Request
. Le message d'erreur indique : Unable to save the metadata notification (search) policy. The specified endpoint URN does not exist: URN.
<MetadataNotificationConfiguration> <Rule> <ID>Rule-1</ID> <Status>rule-status</Status> <Prefix>key-prefix</Prefix> <Destination> <Urn>arn:aws:es:region:account-ID:domain/mydomain/myindex/mytype</Urn> </Destination> </Rule> <Rule> <ID>Rule-2</ID> ... </Rule> ... </MetadataNotificationConfiguration>
Le tableau décrit les éléments du XML de configuration de notification des métadonnées.
Nom | Description | Obligatoire |
---|---|---|
Configuration de la MetadaNotificationConfiguration |
Balise de conteneur pour les règles utilisées pour spécifier les objets et la destination des notifications de métadonnées. Contient un ou plusieurs éléments de règle. |
Oui. |
Règle |
Balise de conteneur d'une règle qui identifie les objets dont les métadonnées doivent être ajoutées à un index spécifié. Les règles avec des préfixes qui se chevauchent sont rejetées. Inclus dans l'élément MetadaNotificationConfiguration. |
Oui. |
ID |
Identifiant unique de la règle. Inclus dans l'élément règle. |
Non |
État |
L'état peut être « activé » ou « désactivé ». Aucune action n'est prise pour les règles désactivées. Inclus dans l'élément règle. |
Oui. |
Préfixe |
Les objets qui correspondent au préfixe sont affectés par la règle et leurs métadonnées sont envoyées à la destination spécifiée. Pour faire correspondre tous les objets, spécifiez un préfixe vide. Inclus dans l'élément règle. |
Oui. |
Destination |
Balise de conteneur pour la destination d'une règle. Inclus dans l'élément règle. |
Oui. |
Urne |
URN de la destination où les métadonnées d'objet sont envoyées. Doit être l'URN d'un terminal StorageGRID avec les propriétés suivantes :
Les terminaux sont configurés à l'aide du Gestionnaire de locataires ou de l'API de gestion des locataires. Ils se présentent sous la forme suivante :
Le noeud final doit être configuré avant la soumission du XML de configuration, ou la configuration échouera avec une erreur 404. L'urne est incluse dans l'élément destination. |
Oui. |
Exemples de demandes
Cet exemple montre l'activation de l'intégration de la recherche pour un compartiment. Dans cet exemple, les métadonnées d'objet de tous les objets sont envoyées vers la même destination.
PUT /test1?x-ntap-sg-metadata-notification HTTP/1.1
Date: date
Authorization: authorization string
Host: host
<MetadataNotificationConfiguration>
<Rule>
<ID>Rule-1</ID>
<Status>Enabled</Status>
<Prefix></Prefix>
<Destination>
<Urn>urn:sgws:es:::sgws-notifications/test1/all</Urn>
</Destination>
</Rule>
</MetadataNotificationConfiguration>
Dans cet exemple, les métadonnées d'objet pour les objets qui correspondent au préfixe /images
est envoyée à une destination, tandis que les métadonnées d'objet correspondent au préfixe /videos
est envoyé à une seconde destination.
PUT /graphics?x-ntap-sg-metadata-notification HTTP/1.1
Date: date
Authorization: authorization string
Host: host
<MetadataNotificationConfiguration>
<Rule>
<ID>Images-rule</ID>
<Status>Enabled</Status>
<Prefix>/images</Prefix>
<Destination>
<Urn>arn:aws:es:us-east-1:3333333:domain/es-domain/graphics/imagetype</Urn>
</Destination>
</Rule>
<Rule>
<ID>Videos-rule</ID>
<Status>Enabled</Status>
<Prefix>/videos</Prefix>
<Destination>
<Urn>arn:aws:es:us-west-1:22222222:domain/es-domain/graphics/videotype</Urn>
</Destination>
</Rule>
</MetadataNotificationConfiguration>
JSON généré par le service d'intégration de la recherche
Lorsque vous activez le service d'intégration de la recherche pour un compartiment, un document JSON est généré et envoyé au terminal de destination à chaque ajout, mise à jour ou suppression de métadonnées d'objet.
Cet exemple montre un exemple de fichier JSON qui peut être généré lorsqu'un objet doté de la clé est associé SGWS/Tagging.txt
est créé dans un compartiment nommé test
. Le test
le compartiment n'est pas multiversion versionId
l'étiquette est vide.
{ "bucket": "test", "key": "SGWS/Tagging.txt", "versionId": "", "accountId": "86928401983529626822", "size": 38, "md5": "3d6c7634a85436eee06d43415012855", "region":"us-east-1" "metadata": { "age": "25" }, "tags": { "color": "yellow" } }
Métadonnées d'objet incluses dans les notifications de métadonnées
Le tableau répertorie tous les champs inclus dans le document JSON qui est envoyé au noeud final de destination lorsque l'intégration de la recherche est activée.
Le nom du document inclut le nom du compartiment, le nom de l'objet et l'ID de version, le cas échéant.
Type | Nom de l'élément | Description |
---|---|---|
Informations sur les compartiments et les objets |
godet |
Nom du compartiment |
Informations sur les compartiments et les objets |
clé |
Nom de clé d'objet |
Informations sur les compartiments et les objets |
ID de version |
Version d'objet, pour les objets dans les compartiments multiversion |
Informations sur les compartiments et les objets |
région |
Zone de godet, par exemple |
Métadonnées de système |
taille |
Taille de l'objet (en octets) visible par un client HTTP |
Métadonnées de système |
md5 |
Hachage d'objets |
Métadonnées d'utilisateur |
les métadonnées
|
Toutes les métadonnées utilisateur pour l'objet, comme paires de clé-valeur |
Étiquettes |
balises
|
Toutes les balises d'objet définies pour l'objet, en tant que paires clé-valeur |
Remarque : pour les balises et les métadonnées d'utilisateur, StorageGRID transmet les dates et les chiffres à Elasticsearch sous forme de chaînes ou de notifications d'événement S3. Pour configurer Elasticsearch afin d'interpréter ces chaînes comme des dates ou des chiffres, suivez les instructions Elasticsearch pour un mappage dynamique des champs et un mappage des formats de date. Vous devez activer les mappages de champs dynamiques sur l'index avant de configurer le service d'intégration de la recherche. Une fois qu'un document est indexé, vous ne pouvez pas modifier les types de champ du document dans l'index.
DEMANDE d'utilisation du stockage
La demande GET Storage usage vous indique la quantité totale de stockage utilisée par un compte et pour chaque compartiment associé au compte.
Le volume de stockage utilisé par un compte et ses compartiments peut être obtenu à l'aide d'une demande GET Service modifiée avec le x-ntap-sg-usage
paramètre de requête. L'utilisation du stockage par compartiment est suivie séparément des demandes DE PUT et DELETE traitées par le système. Il peut y avoir un certain délai avant que les valeurs d'utilisation correspondent aux valeurs attendues en fonction du traitement des demandes, en particulier si le système est soumis à une charge importante.
Par défaut, StorageGRID tente de récupérer les informations d'utilisation à l'aide d'une cohérence globale forte. Si la cohérence globale forte ne peut pas être atteinte, StorageGRID tente de récupérer les informations d'utilisation avec une cohérence site élevée.
Pour effectuer cette opération, vous devez disposer de l'autorisation s3:ListAllMyseaux ou être root de compte.
Exemple de demande
GET /?x-ntap-sg-usage HTTP/1.1
Date: date
Authorization: authorization string
Host: host
Exemple de réponse
Cet exemple montre un compte qui contient quatre objets et 12 octets de données dans deux compartiments. Chaque compartiment contient deux objets et six octets de données.
HTTP/1.1 200 OK Date: Sat, 29 Nov 2015 00:49:05 GMT Connection: KEEP-ALIVE Server: StorageGRID/10.2.0 x-amz-request-id: 727237123 Content-Length: 427 Content-Type: application/xml <?xml version="1.0" encoding="UTF-8"?> <UsageResult xmlns="http://s3.storagegrid.com/doc/2015-02-01"> <CalculationTime>2014-11-19T05:30:11.000000Z</CalculationTime> <ObjectCount>4</ObjectCount> <DataBytes>12</DataBytes> <Buckets> <Bucket> <Name>bucket1</Name> <ObjectCount>2</ObjectCount> <DataBytes>6</DataBytes> </Bucket> <Bucket> <Name>bucket2</Name> <ObjectCount>2</ObjectCount> <DataBytes>6</DataBytes> </Bucket> </Buckets> </UsageResult>
Gestion des versions
Chaque version d'objet stockée contribuera à la ObjectCount
et DataBytes
valeurs dans la réponse. Les marqueurs de suppression ne sont pas ajoutés au ObjectCount
total.
Demandes de compartiment obsolètes pour la conformité des anciennes
Vous devrez peut-être utiliser l'API REST StorageGRID S3 pour gérer les compartiments qui ont été créés à l'aide de la fonctionnalité de conformité héritée.
Fonction de conformité obsolète
La fonctionnalité de conformité StorageGRID disponible dans les versions précédentes d'StorageGRID est obsolète et a été remplacée par le verrouillage d'objet S3.
Si vous avez précédemment activé le paramètre de conformité globale, le paramètre de verrouillage d'objet S3 global est automatiquement activé lorsque vous effectuez une mise à niveau vers StorageGRID 11.5. Vous ne pouvez plus créer de compartiments avec la conformité activée. Toutefois, si nécessaire, vous pouvez utiliser l'API REST StorageGRID S3 pour gérer tous les compartiments conformes existants.
Obsolète : METTEZ les modifications de la demande de compartiment à des fins de conformité
L'élément XML SGCompliance est obsolète. Auparavant, vous pouviez inclure cet élément personnalisé StorageGRID dans le corps de demande XML facultatif de requêtes Put Bucket pour créer un compartiment conforme.
La fonctionnalité de conformité StorageGRID disponible dans les versions précédentes d'StorageGRID est obsolète et a été remplacée par le verrouillage d'objet S3. |
Vous ne pouvez plus créer de compartiments avec la fonctionnalité conformité activée. Le message d'erreur suivant s'affiche si vous tentez d'utiliser les modifications de demande DE MISE en godet pour la conformité afin de créer un nouveau compartiment conforme :
The Compliance feature is deprecated. Contact your StorageGRID administrator if you need to create new Compliant buckets.
Obsolète : RÉCUPÉRER la demande de conformité du compartiment
La demande DE conformité DE GET Bucket est obsolète. Cependant, vous pouvez continuer à utiliser cette demande pour déterminer les paramètres de conformité actuellement en vigueur pour un compartiment compatible existant.
La fonctionnalité de conformité StorageGRID disponible dans les versions précédentes d'StorageGRID est obsolète et a été remplacée par le verrouillage d'objet S3. |
Pour effectuer cette opération, vous devez disposer de l'autorisation s3:GetBucketCompliance ou être root de compte.
Exemple de demande
Cet exemple de demande vous permet de déterminer les paramètres de conformité pour le compartiment nommé mybucket
.
GET /mybucket/?x-ntap-sg-compliance HTTP/1.1
Date: date
Authorization: authorization string
Host: host
Exemple de réponse
Dans le XML de réponse, <SGCompliance>
le répertorie les paramètres de conformité utilisés pour le compartiment. Cet exemple de réponse montre les paramètres de conformité d'un compartiment dans lequel chaque objet sera conservé pendant un an (525,600 minutes), à partir de l'ingestion de l'objet dans la grille. Il n'y a actuellement aucune retenue légale sur ce godet. Chaque objet sera automatiquement supprimé après un an.
HTTP/1.1 200 OK
Date: date
Connection: connection
Server: StorageGRID/11.1.0
x-amz-request-id: request ID
Content-Length: length
Content-Type: application/xml
<SGCompliance>
<RetentionPeriodMinutes>525600</RetentionPeriodMinutes>
<LegalHold>false</LegalHold>
<AutoDelete>true</AutoDelete>
</SGCompliance>
Nom | Description |
---|---|
RetentionPeriodMinutes |
Durée de conservation des objets ajoutés à ce compartiment, en minutes. La période de conservation commence lorsque l'objet est ingéré dans la grille. |
LegalHold |
|
Suppression automatique |
|
Réponses d'erreur
Si le compartiment n'a pas été créé pour être conforme, le code d'état HTTP de la réponse est 404 Not Found
, Avec un code d'erreur S3 de XNoSuchBucketCompliance
.
Obsolète : PUT Bucket Compliance request
La demande de conformité PUT Bucket est obsolète. Cependant, vous pouvez continuer à utiliser cette demande pour modifier les paramètres de conformité d'un compartiment conforme existant. Par exemple, vous pouvez placer un compartiment existant en attente légale ou augmenter sa période de conservation.
La fonctionnalité de conformité StorageGRID disponible dans les versions précédentes d'StorageGRID est obsolète et a été remplacée par le verrouillage d'objet S3. |
Pour effectuer cette opération, vous devez disposer de l'autorisation s3:PutBuckCompliance, ou être root de compte.
Vous devez spécifier une valeur pour chaque champ des paramètres de conformité lors de l'émission d'une demande de conformité PUT Bucket.
Exemple de demande
Cet exemple de demande modifie les paramètres de conformité du compartiment nommé mybucket
. Dans cet exemple, objets dans mybucket
sera maintenant conservé pendant deux ans (1,051,200 minutes) au lieu d'un an, à partir de l'ingestion de l'objet dans le grid. Il n'y a pas de retenue légale sur ce godet. Chaque objet sera automatiquement supprimé après deux ans.
PUT /mybucket/?x-ntap-sg-compliance HTTP/1.1
Date: date
Authorization: authorization name
Host: host
Content-Length: 152
<SGCompliance>
<RetentionPeriodMinutes>1051200</RetentionPeriodMinutes>
<LegalHold>false</LegalHold>
<AutoDelete>true</AutoDelete>
</SGCompliance>
Nom | Description |
---|---|
RetentionPeriodMinutes |
Durée de conservation des objets ajoutés à ce compartiment, en minutes. La période de conservation commence lorsque l'objet est ingéré dans la grille. Attention: lorsque vous spécifiez une nouvelle valeur pour RetentionPeriodMinutes, vous devez spécifier une valeur égale ou supérieure à la période de rétention actuelle du godet. Une fois la période de rétention du godet définie, vous ne pouvez pas la réduire ; vous pouvez uniquement l'augmenter. |
LegalHold |
|
Suppression automatique |
|
Niveau de cohérence des paramètres de conformité
Lorsque vous mettez à jour les paramètres de conformité d'un compartiment S3 avec une demande DE conformité PUT bucket, StorageGRID tente de mettre à jour les métadonnées du compartiment dans la grille. Par défaut, StorageGRID utilise le niveau de cohérence Strong-global pour garantir que tous les sites de data Center et tous les nœuds de stockage contenant des métadonnées de compartiment sont cohérents en lecture après écriture pour les paramètres de conformité modifiés.
Si StorageGRID ne peut pas atteindre le niveau de cohérence Strong-global car un site de centre de données ou plusieurs nœuds de stockage sur un site ne sont pas disponibles, le code d'état HTTP de la réponse est 503 Service Unavailable.
Si vous recevez cette réponse, vous devez contacter l'administrateur du grid pour vous assurer que les services de stockage requis sont disponibles dans les plus brefs délais. Si l'administrateur de la grille ne parvient pas à mettre suffisamment de nœuds de stockage sur chaque site, le support technique vous demandera peut-être de relancer la demande échouée en forçant le niveau de cohérence site fort.
Ne forcez jamais le niveau de cohérence site fort pour la conformité DU godet DE MISE à moins que vous n'ayez été invité à le faire par le support technique et à moins que vous compreniez les conséquences possibles de l'utilisation de ce niveau. |
Lorsque le niveau de cohérence est réduit à strong-site, StorageGRID garantit que les paramètres de conformité mis à jour auront une cohérence lecture-après-écriture uniquement pour les requêtes client au sein d'un site. Il est donc possible que le système StorageGRID dispose de plusieurs paramètres incohérents pour ce compartiment jusqu'à ce que tous les sites et nœuds de stockage soient disponibles. Les paramètres incohérents peuvent entraîner un comportement inattendu et indésirable. Par exemple, si vous placez un compartiment sous une obligation légale et que vous forcez un niveau de cohérence inférieur, les paramètres de conformité précédents du compartiment (c'est-à-dire la conservation légale) peuvent continuer à être en vigueur sur certains sites de data Center. Par conséquent, les objets qui, selon vous, sont en attente légale peuvent être supprimés à l'expiration de leur période de conservation, soit par l'utilisateur, soit par AutoDelete, si cette option est activée.
Pour forcer l'utilisation du niveau de cohérence site fort, réémettez la demande de conformité Put et incluez le Consistency-Control
En-tête de requête HTTP, comme suit :
PUT /mybucket/?x-ntap-sg-compliance HTTP/1.1 Consistency-Control: strong-site
Réponses d'erreur
-
Si le compartiment n'a pas été créé pour être conforme, le code d'état HTTP de la réponse est
404 Not Found
. -
Si
RetentionPeriodMinutes
Dans la demande est inférieure à la période de conservation actuelle du compartiment, le code d'état HTTP est400 Bad Request
.
"Obsolète : METTEZ les modifications de la demande de compartiment à des fins de conformité"