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

Mettre l'objet

10/01/2025

Vous pouvez utiliser la requête S3 PutObject pour ajouter un objet à un bucket.

Résoudre les conflits

Les demandes client conflictuelles, telles que deux clients écrivant sur la même clé, sont résolues sur la base des « derniers gagnants ». Le moment de l'évaluation des « dernières victoires » est basé sur le moment où le système StorageGRID termine une demande donnée, et non sur le moment où les clients S3 commencent une opération.

Taille de l'objet

La taille maximale recommandée pour une seule opération PutObject est de 5 Gio (5 368 709 120 octets). Si vous avez des objets dont la taille est supérieure à 5 Gio, utilisez"téléchargement en plusieurs parties" plutôt.

La taille maximale prise en charge pour une seule opération PutObject est de 5 Tio (5 497 558 138 880 octets).

Si vous avez effectué une mise à niveau à partir de StorageGRID 11.6 ou d'une version antérieure, l'alerte S3 PUT La taille de l'objet est trop grande sera déclenchée si vous tentez de télécharger un objet dépassant 5 Gio. Si vous disposez d'une nouvelle installation de StorageGRID 11.7 ou 11.8, l'alerte ne sera pas déclenchée dans ce cas. Cependant, pour s'aligner sur la norme AWS S3, les futures versions de StorageGRID ne prendront pas en charge les téléchargements d'objets supérieurs à 5 Gio.

Taille des métadonnées utilisateur

Amazon S3 limite la taille des métadonnées définies par l'utilisateur dans chaque en-tête de requête PUT à 2 Ko. StorageGRID limite les métadonnées utilisateur à 24 Ko. La taille des métadonnées définies par l'utilisateur est mesurée en prenant la somme du nombre d'octets dans l'encodage UTF-8 de chaque clé et valeur.

Caractères UTF-8 dans les métadonnées utilisateur

Si une demande inclut des valeurs UTF-8 (non échappées) dans le nom de clé ou la valeur des métadonnées définies par l'utilisateur, le comportement de StorageGRID n'est pas défini.

StorageGRID n'analyse ni n'interprète les caractères UTF-8 échappés inclus dans le nom de clé ou la valeur des métadonnées définies par l'utilisateur. Les caractères UTF-8 échappés sont traités comme des caractères ASCII :

Les requêtes PutObject, CopyObject, GetObject et HeadObject réussissent si les métadonnées définies par l'utilisateur incluent des caractères UTF-8 échappés.
StorageGRID ne renvoie pas le x-amz-missing-meta en-tête si la valeur interprétée du nom ou de la valeur de la clé inclut des caractères non imprimables.

Limites des balises d'objet

Vous pouvez ajouter des balises aux nouveaux objets lorsque vous les téléchargez, ou vous pouvez les ajouter aux objets existants. StorageGRID et Amazon S3 prennent en charge jusqu'à 10 balises pour chaque objet. Les balises associées à un objet doivent avoir des clés de balise uniques. Une clé de balise peut contenir jusqu'à 128 caractères Unicode et les valeurs de balise peuvent contenir jusqu'à 256 caractères Unicode. La clé et les valeurs sont sensibles à la casse.

Propriété de l'objet

Dans StorageGRID, tous les objets appartiennent au compte propriétaire du bucket, y compris les objets créés par un compte non propriétaire ou un utilisateur anonyme.

En-têtes de requête pris en charge

Les en-têtes de requête suivants sont pris en charge :

Cache-Control
Content-Disposition
Content-Encoding

Lorsque vous spécifiez aws-chunked pourContent-Encoding StorageGRID ne vérifie pas les éléments suivants :
- StorageGRID ne vérifie pas le chunk-signature par rapport aux données du bloc.
- StorageGRID ne vérifie pas la valeur que vous fournissez pour x-amz-decoded-content-length contre l'objet.
Content-Language
Content-Length
Content-MD5
Content-Type
Expires
Transfer-Encoding

L'encodage de transfert fragmenté est pris en charge si aws-chunked la signature de la charge utile est également utilisée.
x-amz-checksum-sha256

x-amz-meta-, suivi d'une paire nom-valeur contenant des métadonnées définies par l'utilisateur.

Lors de la spécification de la paire nom-valeur pour les métadonnées définies par l'utilisateur, utilisez ce format général :

x-amz-meta-name: value

Si vous souhaitez utiliser l'option Heure de création définie par l'utilisateur comme heure de référence pour une règle ILM, vous devez utiliser creation-time comme le nom des métadonnées qui enregistrent quand l'objet a été créé. Par exemple:

x-amz-meta-creation-time: 1443399726

La valeur pour creation-time est évalué en secondes depuis le 1er janvier 1970.

Une règle ILM ne peut pas utiliser à la fois une heure de création définie par l'utilisateur pour l'heure de référence et l'option d'ingestion équilibrée ou stricte. Une erreur est renvoyée lors de la création de la règle ILM.

x-amz-tagging
En-têtes de demande de verrouillage d'objet S3
- x-amz-object-lock-mode
- x-amz-object-lock-retain-until-date
- x-amz-object-lock-legal-hold
  
  Si une demande est effectuée sans ces en-têtes, les paramètres de conservation par défaut du bucket sont utilisés pour calculer le mode de version de l'objet et la date de conservation. Voir "Utiliser l'API REST S3 pour configurer le verrouillage d'objet S3" .
En-têtes de requête SSE :
- x-amz-server-side-encryption
- x-amz-server-side-encryption-customer-key-MD5
- x-amz-server-side-encryption-customer-key
- x-amz-server-side-encryption-customer-algorithm
  
  VoirEn-têtes de requête pour le chiffrement côté serveur

En-têtes de requête non pris en charge

Les en-têtes de requête suivants ne sont pas pris en charge :

x-amz-acl
x-amz-sdk-checksum-algorithm
x-amz-trailer
x-amz-website-redirect-location

Le x-amz-website-redirect-location retours d'en-tête XNotImplemented .

Options de classe de stockage

Le x-amz-storage-class l'en-tête de requête est pris en charge. La valeur soumise pour x-amz-storage-class affecte la manière dont StorageGRID protège les données de l'objet pendant l'ingestion et non le nombre de copies persistantes de l'objet stockées dans le système StorageGRID (qui est déterminé par ILM).

Si la règle ILM correspondant à un objet ingéré utilise l'option d'ingestion stricte, le x-amz-storage-class l'en-tête n'a aucun effet.

Les valeurs suivantes peuvent être utilisées pour x-amz-storage-class :

STANDARD(Défaut)
- Double validation : si la règle ILM spécifie l'option Double validation pour le comportement d'ingestion, dès qu'un objet est ingéré, une deuxième copie de cet objet est créée et distribuée à un autre nœud de stockage (double validation). Lorsque l’ILM est évalué, StorageGRID détermine si ces copies intermédiaires initiales satisfont aux instructions de placement de la règle. Si ce n’est pas le cas, de nouvelles copies d’objets devront peut-être être réalisées à des emplacements différents et les copies intermédiaires initiales devront peut-être être supprimées.
- Équilibré : si la règle ILM spécifie l'option Équilibré et que StorageGRID ne peut pas effectuer immédiatement toutes les copies spécifiées dans la règle, StorageGRID effectue deux copies intermédiaires sur différents nœuds de stockage.
  
  Si StorageGRID peut créer immédiatement toutes les copies d'objets spécifiées dans la règle ILM (placement synchrone), le x-amz-storage-class l'en-tête n'a aucun effet.
REDUCED_REDUNDANCY
- * Double validation * : si la règle ILM spécifie l'option Double validation pour le comportement d'ingestion, StorageGRID crée une copie intermédiaire unique lorsque l'objet est ingéré (validation unique).
- Équilibré : si la règle ILM spécifie l'option Équilibré, StorageGRID effectue une seule copie intermédiaire uniquement si le système ne peut pas effectuer immédiatement toutes les copies spécifiées dans la règle. Si StorageGRID peut effectuer un placement synchrone, cet en-tête n'a aucun effet. Le REDUCED_REDUNDANCY L'option est mieux utilisée lorsque la règle ILM qui correspond à l'objet crée une seule copie répliquée. Dans ce cas, en utilisant REDUCED_REDUNDANCY élimine la création et la suppression inutiles d'une copie d'objet supplémentaire pour chaque opération d'ingestion.
En utilisant le REDUCED_REDUNDANCY Cette option n'est pas recommandée dans d'autres circonstances. REDUCED_REDUNDANCY augmente le risque de perte de données d'objet lors de l'ingestion. Par exemple, vous risquez de perdre des données si la copie unique est initialement stockée sur un nœud de stockage qui échoue avant que l'évaluation ILM puisse avoir lieu.

Le fait de n'avoir qu'une seule copie répliquée pendant une période donnée expose les données à un risque de perte permanente. Si une seule copie répliquée d’un objet existe, cet objet est perdu si un nœud de stockage échoue ou présente une erreur importante. Vous perdez également temporairement l’accès à l’objet pendant les procédures de maintenance telles que les mises à niveau.

Spécification REDUCED_REDUNDANCY affecte uniquement le nombre de copies créées lorsqu'un objet est ingéré pour la première fois. Cela n'affecte pas le nombre de copies de l'objet effectuées lorsque l'objet est évalué par les stratégies ILM actives et n'entraîne pas le stockage des données à des niveaux de redondance inférieurs dans le système StorageGRID .

Si vous ingérez un objet dans un bucket avec le verrouillage d'objet S3 activé, le REDUCED_REDUNDANCY l'option est ignorée. Si vous ingérez un objet dans un bucket conforme hérité, le REDUCED_REDUNDANCY l'option renvoie une erreur. StorageGRID effectuera toujours une ingestion à double validation pour garantir que les exigences de conformité sont satisfaites.

En-têtes de requête pour le chiffrement côté serveur

Vous pouvez utiliser les en-têtes de requête suivants pour crypter un objet avec un cryptage côté serveur. Les options SSE et SSE-C s'excluent mutuellement.

SSE : utilisez l’en-tête suivant si vous souhaitez chiffrer l’objet avec une clé unique gérée par StorageGRID.
- x-amz-server-side-encryption
  
  Quand le x-amz-server-side-encryption l'en-tête n'est pas inclus dans la requête PutObject, la grille entière"paramètre de cryptage des objets stockés" est omis de la réponse PutObject.
SSE-C : utilisez ces trois en-têtes si vous souhaitez chiffrer l’objet avec une clé unique que vous fournissez et gérez.
- x-amz-server-side-encryption-customer-algorithm: Préciser AES256 .
- x-amz-server-side-encryption-customer-key:Spécifiez votre clé de chiffrement pour le nouvel objet.
- x-amz-server-side-encryption-customer-key-MD5: Spécifiez le condensé MD5 de la clé de chiffrement du nouvel objet.

Les clés de chiffrement que vous fournissez ne sont jamais stockées. Si vous perdez une clé de chiffrement, vous perdez l'objet correspondant. Avant d'utiliser les clés fournies par le client pour sécuriser les données d'objet, examinez les considérations relatives"en utilisant le cryptage côté serveur" .

Si un objet est chiffré avec SSE ou SSE-C, tous les paramètres de chiffrement au niveau du bucket ou de la grille sont ignorés.

Gestion des versions

Si le contrôle de version est activé pour un bucket, un versionId est généré automatiquement pour la version de l'objet stocké. Ce versionId est également renvoyé dans la réponse en utilisant le x-amz-version-id en-tête de réponse.

Si le contrôle de version est suspendu, la version de l'objet est stockée avec une valeur nulle versionId et si une version nulle existe déjà, elle sera écrasée.

Calculs de signature pour l'en-tête d'autorisation

Lors de l'utilisation du Authorization en-tête pour authentifier les requêtes, StorageGRID diffère d'AWS des manières suivantes :

StorageGRID ne nécessite pas host en-têtes à inclure dans CanonicalHeaders .
StorageGRID ne nécessite pas Content-Type à inclure dans CanonicalHeaders .
StorageGRID ne nécessite pas x-amz-* en-têtes à inclure dans CanonicalHeaders .

En règle générale, incluez toujours ces en-têtes dans CanonicalHeaders pour garantir qu'ils sont vérifiés ; cependant, si vous excluez ces en-têtes, StorageGRID ne renvoie pas d'erreur.

Pour plus de détails, reportez-vous à "Calculs de signature pour l'en-tête d'autorisation : transfert de charge utile en un seul bloc (AWS Signature Version 4)" .

Informations connexes