Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Ajouter un objet à un compartiment dans StorageGRID avec la requête S3 PutObject

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

Résoudre les conflits

Les requêtes clients conflictuelles, comme par exemple deux clients écrivant sur la même clé, sont résolues selon le principe du « latest-wins ». Le moment de l’évaluation du « latest-wins » est déterminé par la date à laquelle le système StorageGRID termine une requête donnée, et non par la date à laquelle 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 de plus de 5 Gio, utilisez plutôt "téléchargement en plusieurs parties".

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

Remarque Si vous avez effectué une mise à niveau depuis StorageGRID 11.6 ou une version antérieure, l'alerte « Taille de l'objet S3 trop volumineux lors de la commande PUT » 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, afin de s'aligner sur la norme AWS S3, les prochaines versions de StorageGRID ne prendront plus en charge le téléchargement d'objets de plus de 5 Gio.

Taille des métadonnées utilisateur

Amazon S3 limite la taille des métadonnées définies par l'utilisateur au sein de chaque en-tête de requête PUT à 2 Ko. StorageGRID limite les métadonnées utilisateur à 24 Kio. La taille des métadonnées définies par l'utilisateur est mesurée en faisant 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 requête 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 est indéfini.

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

  • 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 l' `x-amz-missing-meta`en-tête si la valeur interprétée du nom ou de la valeur de la clé contient des caractères non imprimables.

Limites des balises d'objet

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

Propriété de l'objet

Dans StorageGRID, tous les objets appartiennent au compte propriétaire du compartiment, y compris les objets créés par un compte autre que celui du propriétaire ou par 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 pour Content-EncodingStorageGRID, ce dernier ne vérifie pas les éléments suivants :

    • StorageGRID ne vérifie pas les chunk-signature par rapport aux données du bloc.

    • StorageGRID ne vérifie pas la valeur que vous fournissez x-amz-decoded-content-length par rapport à l’objet.

  • Content-Language

  • Content-Length

  • Content-MD5

  • Content-Type

  • Expires

  • Transfer-Encoding

    Le codage par transfert segmenté est pris en charge si aws-chunked la signature de la charge utile est également utilisée.

  • x-amz-checksum-sha256

  • x-amz-meta-, suivie 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 nom des métadonnées qui enregistrent la date de création de l’objet. Par exemple :

    x-amz-meta-creation-time: 1443399726

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

    Remarque Une règle ILM ne peut pas utiliser simultanément une date de création définie par l'utilisateur comme date 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 requête S3 Object Lock

    • x-amz-object-lock-mode

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

    • x-amz-object-lock-legal-hold

      Si une requête est effectuée sans ces en-têtes, les paramètres de rétention par défaut du compartiment sont utilisés pour calculer le mode de version de l'objet et la date de rétention jusqu'à la date limite. Voir "Utilisez l'API REST S3 pour configurer S3 Object Lock".

  • En-têtes de requête SSE :

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

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

  • If-Match

    Le If-Match header est accepté mais non fonctionnel.

  • If-None-Match

    Le If-None-Match header est accepté mais non fonctionnel.

  • x-amz-acl

  • x-amz-sdk-checksum-algorithm

  • x-amz-trailer

  • x-amz-website-redirect-location

    L' x-amz-website-redirect-location`en-tête renvoie `XNotImplemented.

Options de classe de stockage

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

Si la règle ILM correspondant à un objet ingéré utilise l’option d’ingestion stricte, l’ `x-amz-storage-class`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 seconde copie de cet objet est créée et distribuée sur un nœud de stockage différent (double validation). Lors de l’évaluation de l’ILM, StorageGRID détermine si ces copies intermédiaires initiales respectent les instructions de placement de la règle. Si ce n’est pas le cas, il peut être nécessaire de créer de nouvelles copies de l’objet à d’autres emplacements et de supprimer les copies intermédiaires initiales.

    • Équilibré : Si la règle ILM spécifie l’option Équilibré et 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), l x-amz-storage-class en-tête n'a aucun effet.

  • REDUCED_REDUNDANCY

    • Double validation : Si la règle ILM spécifie l’option de double validation pour le comportement d’ingestion, StorageGRID crée une seule copie intermédiaire lors de l’ingestion de l’objet (validation unique).

    • Équilibré : Si la règle ILM spécifie l’option Équilibré, StorageGRID crée une seule copie intermédiaire uniquement si le système ne peut pas créer immédiatement toutes les copies spécifiées dans la règle. Si StorageGRID peut effectuer un placement synchrone, cet en-tête est sans effet. L’ `REDUCED_REDUNDANCY`option est particulièrement utile lorsque la règle ILM correspondant à l’objet crée une seule copie répliquée. Dans ce cas, utiliser `REDUCED_REDUNDANCY`évite la création et la suppression inutiles d’une copie supplémentaire de l’objet pour chaque opération d’ingestion.

    L'utilisation de l' REDUCED_REDUNDANCY`option est déconseillée dans d'autres circonstances. `REDUCED_REDUNDANCY Elle augmente le risque de perte de données lors de l'ingestion. Par exemple, vous pourriez perdre des données si la copie unique est initialement stockée sur un Storage Node qui tombe en panne avant que l'évaluation ILM puisse avoir lieu.

Avertissement Le fait de ne disposer que d'une seule copie répliquée pour une période donnée expose les données à un risque de perte définitive. Si une seule copie répliquée d'un objet existe, cet objet est perdu en cas de panne ou d'erreur grave d'un Storage Node. Vous perdez également temporairement l'accès à l'objet lors des procédures de maintenance telles que les mises à niveau.

La spécification de REDUCED_REDUNDANCY n'affecte que le nombre de copies créées lors de la première ingestion d'un objet. Elle n'affecte pas le nombre de copies de l'objet créées lors de l'évaluation de l'objet par les politiques ILM actives et n'entraîne pas le stockage des données à des niveaux de redondance inférieurs dans le système StorageGRID.

Remarque Si vous ingérez un objet dans un compartiment avec S3 Object Lock activé, l’ `REDUCED_REDUNDANCY`option est ignorée. Si vous ingérez un objet dans un compartiment Compliant hérité, l’ `REDUCED_REDUNDANCY`option renvoie une erreur. StorageGRID effectuera toujours une double validation à l’ingestion pour garantir le respect des exigences de conformité.

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

Vous pouvez utiliser les en-têtes de requête suivants pour chiffrer un objet avec le chiffrement côté serveur. Les options SSE et SSE-C sont incompatibles.

  • 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

      Lorsque l'en-tête x-amz-server-side-encryption n'est pas inclus dans la requête PutObject, le "paramètre de chiffrement des objets stockés" à l'échelle de la grille est omis de la réponse PutObject.

  • ${post_edited_translations.segment}

    • x-amz-server-side-encryption-customer-algorithm: Précisez 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.

Avertissement 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 des clés fournies par le client pour sécuriser les données d'objet, examinez les considérations pour "utilisation du chiffrement côté serveur".
Remarque Si un objet est chiffré avec SSE ou SSE-C, tous les paramètres de chiffrement au niveau du compartiment ou de la grille sont ignorés.

Versionnage

Si le versionnage est activé pour un compartiment, un identifiant unique versionId est automatiquement généré pour la version de l'objet stocké. Cet identifiant versionId est également renvoyé dans la réponse via l' x-amz-version-id en-tête de réponse.

Si le versionnage 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.

${post_edited_translations.segment}

Lors de l'utilisation de l' `Authorization`en-tête pour authentifier les requêtes, StorageGRID diffère d'AWS de la manière suivante :

  • StorageGRID n'exige pas que les host en-têtes soient inclus dans CanonicalHeaders.

  • StorageGRID n'a pas besoin que Content-Type soit inclus dans CanonicalHeaders.

  • StorageGRID n'exige pas que les x-amz-* en-têtes soient inclus dans CanonicalHeaders.

Remarque En bonne pratique, incluez toujours ces en-têtes CanonicalHeaders afin de garantir leur vérification ; toutefois, si vous les excluez, StorageGRID ne renvoie pas d'erreur.