Skip to main content
Hay disponible una nueva versión de este producto.
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Agrega un objeto a un bucket en StorageGRID con la solicitud S3 PutObject

PDF

Puedes usar la solicitud PutObject de S3 para añadir un objeto a un bucket.

Resolver conflictos

Las solicitudes conflictivas de los clientes, como por ejemplo cuando dos clientes escriben en la misma clave, se resuelven según el principio de "la última gana". El momento en que se evalúa el principio de "la última gana" se basa en cuándo el sistema StorageGRID completa una solicitud determinada, y no en cuándo los clientes S3 inician una operación.

Tamaño del objeto

El tamaño máximo recomendado para una sola operación de PutObject es de 5 GiB (5,368,709,120 bytes). Si tienes objetos que superan los 5 GiB, utiliza "${post_edited_translations.segment}" en su lugar.

El tamaño máximo admitido para una sola operación de PutObject es de 5 TiB (5,497,558,138,880 bytes).

Nota Si has actualizado desde StorageGRID 11.6 o una versión anterior, se activará la alerta «S3 PUT Object size too large» si intentas cargar un objeto que supere los 5 GiB. Si tienes una nueva instalación de StorageGRID 11.7 o 11.8, la alerta no se activará en este caso. Sin embargo, para alinearse con el estándar de AWS S3, las futuras versiones de StorageGRID no admitirán cargas de objetos mayores a 5 GiB.

${post_edited_translations.segment}

Amazon S3 limita el tamaño de los metadatos definidos por el usuario dentro de cada cabecera de solicitud PUT a 2 KB. StorageGRID limita los metadatos del usuario a 24 KiB. El tamaño de los metadatos definidos por el usuario se mide sumando el número de bytes en la codificación UTF-8 de cada clave y valor.

Caracteres UTF-8 en los metadatos de usuario

Si una solicitud incluye valores UTF-8 (sin caracteres de escape) en el nombre de la clave o en el valor de los metadatos definidos por el usuario, el comportamiento de StorageGRID es indefinido.

StorageGRID no analiza ni interpreta los caracteres UTF-8 escapados incluidos en el nombre o el valor de los metadatos definidos por el usuario. Los caracteres UTF-8 escapados se tratan como caracteres ASCII:

  • PutObject, CopyObject, GetObject y HeadObject las solicitudes se procesan correctamente si los metadatos definidos por el usuario incluyen caracteres UTF-8 escapados.

  • StorageGRID no devuelve la cabecera x-amz-missing-meta si el valor interpretado del nombre o del valor de la clave incluye caracteres no imprimibles.

Límites de las etiquetas de objetos

Puedes añadir etiquetas a los objetos nuevos al subirlos, o puedes añadirlas a objetos ya existentes. Tanto StorageGRID como Amazon S3 admiten hasta 10 etiquetas por cada objeto. Las etiquetas asociadas a un objeto deben tener claves de etiqueta únicas. Una clave de etiqueta puede tener hasta 128 caracteres Unicode y los valores de las etiquetas pueden tener hasta 256 caracteres Unicode. Las claves y los valores distinguen mayúsculas de minúsculas.

Propiedad de los objetos

En StorageGRID, todos los objetos son propiedad de la cuenta del propietario del bucket, incluidos los objetos creados por una cuenta que no sea la del propietario o por un usuario anónimo.

Encabezados de solicitud compatibles

Se admiten los siguientes encabezados de solicitud:

  • Cache-Control

  • Content-Disposition

  • Content-Encoding

    Cuando especificas aws-chunked para Content-EncodingStorageGRID no verifica los siguientes elementos:

    • StorageGRID no verifica el chunk-signature con los datos del fragmento.

    • StorageGRID no verifica el valor que proporcionas para x-amz-decoded-content-length con el objeto.

  • Content-Language

  • Content-Length

  • Content-MD5

  • Content-Type

  • Expires

  • Transfer-Encoding

    Se admite la codificación de transferencia fragmentada si aws-chunked también se utiliza la firma de la carga útil.

  • x-amz-checksum-sha256

  • x-amz-meta-, seguido de un par nombre-valor que contiene metadatos definidos por el usuario.

    Al especificar el par nombre-valor para los metadatos definidos por el usuario, utiliza este formato general:

    x-amz-meta-name: value

    Si deseas utilizar la opción Hora de creación definida por el usuario como hora de referencia para una regla de ILM, debes utilizar creation-time como nombre de los metadatos que registran cuándo se creó el objeto. Por ejemplo:

    x-amz-meta-creation-time: 1443399726

    El valor de creation-time se calcula en segundos desde el 1 de enero de 1970.

    Nota Una regla de ILM no puede usar una hora de creación definida por el usuario para la hora de referencia y la opción de ingesta Balanced o Strict al mismo tiempo. Se devuelve un error al crear la regla de ILM.

  • x-amz-tagging

  • ${post_edited_translations.segment}

    • x-amz-object-lock-mode

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

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

      Si haces una solicitud sin estas cabeceras, se usa la configuración de retención predeterminada del bucket para calcular el modo de versión del objeto y la fecha de retención hasta. Consulta "Utiliza la API de REST de S3 para configurar S3 Object Lock".

  • Encabezados de solicitud SSE:

Encabezados de solicitud no compatibles

No se admiten los siguientes encabezados de solicitud:

  • If-Match

    El If-Match header es aceptado pero no funciona.

  • If-None-Match

    El If-None-Match header es aceptado pero no funciona.

  • x-amz-acl

  • x-amz-sdk-checksum-algorithm

  • x-amz-trailer

  • x-amz-website-redirect-location

    La x-amz-website-redirect-location cabecera devuelve XNotImplemented.

Opciones de clase de almacenamiento

Se admite el encabezado de solicitud x-amz-storage-class. El valor enviado para x-amz-storage-class afecta cómo StorageGRID protege los datos del objeto durante la ingesta y no cuántas copias persistentes del objeto se almacenan en el sistema StorageGRID (lo cual lo determina ILM).

Si la regla de ILM que coincide con un objeto ingerido utiliza la opción de ingesta Strict, la cabecera x-amz-storage-class no tiene efecto.

Se pueden usar los siguientes valores para x-amz-storage-class:

  • STANDARD (Por defecto)

    • Dual commit: Si la regla ILM especifica la opción Dual commit para el comportamiento de ingesta, tan pronto como se ingiere un objeto, se crea una segunda copia de ese objeto y se distribuye a un Storage Node diferente (dual commit). Cuando se evalúa el ILM, StorageGRID determina si estas copias provisionales iniciales cumplen las instrucciones de ubicación en la regla. Si no lo hacen, puede que sea necesario crear nuevas copias del objeto en ubicaciones diferentes y eliminar las copias provisionales iniciales.

    • Equilibrado: Si la regla de ILM especifica la opción Balanced y StorageGRID no puede crear de inmediato todas las copias especificadas en la regla, StorageGRID crea dos copias provisionales en distintos Storage Nodes.

      Si StorageGRID puede crear inmediatamente todas las copias de objetos especificadas en la regla de ILM (colocación sincrónica), el encabezado x-amz-storage-class no tiene ningún efecto.

  • REDUCED_REDUNDANCY

    • ${post_edited_translations.segment}

    • Equilibrado: Si la regla ILM especifica la opción Equilibrado, StorageGRID crea una única copia provisional solo si el sistema no puede crear inmediatamente todas las copias especificadas en la regla. Si StorageGRID puede realizar una colocación sincrónica, este encabezado no tiene efecto. La REDUCED_REDUNDANCY opción se usa mejor cuando la regla de ILM que coincide con el objeto crea una sola copia replicada. En este caso, usar REDUCED_REDUNDANCY elimina la creación y eliminación innecesarias de una copia adicional del objeto en cada operación de ingesta.

    No se recomienda utilizar la opción REDUCED_REDUNDANCY en otras circunstancias. REDUCED_REDUNDANCY Aumenta el riesgo de pérdida de datos de objetos durante la ingesta. Por ejemplo, podrías perder datos si la única copia se almacena inicialmente en un Storage Node que falla antes de que pueda ocurrir la evaluación de ILM.

Precaución Disponer de una única copia replicada para cualquier periodo de tiempo pone los datos en riesgo de pérdida permanente. Si solo existe una copia replicada de un objeto, ese objeto se pierde si un Storage Node falla o tiene un error significativo. También pierdes temporalmente el acceso al objeto durante procedimientos de mantenimiento como las actualizaciones.

Especificar REDUCED_REDUNDANCY solo afecta al número de copias que se crean cuando un objeto se incorpora por primera vez. No afecta al número de copias del objeto que se crean cuando el objeto es evaluado por las políticas de ILM activas, ni da lugar a que los datos se almacenen con niveles de redundancia más bajos en el sistema StorageGRID.

Nota Si estás ingiriendo un objeto en un bucket con S3 Object Lock activado, la opción REDUCED_REDUNDANCY se ignora. Si estás ingiriendo un objeto en un bucket Compliant heredado, la opción REDUCED_REDUNDANCY devuelve un error. StorageGRID siempre realizará una ingesta con doble confirmación para garantizar que se cumplan los requisitos de cumplimiento.

Encabezados de solicitud para el cifrado del lado del servidor

Puedes utilizar los siguientes encabezados de solicitud para cifrar un objeto mediante el cifrado del lado del servidor. Las opciones SSE y SSE-C son mutuamente excluyentes.

  • SSE: Utiliza el siguiente encabezado si deseas cifrar el objeto con una clave única gestionada por StorageGRID.

  • SSE-C: Utiliza estos tres encabezados si deseas cifrar el objeto con una clave única que tú mismo proporciones y gestiones.

    • x-amz-server-side-encryption-customer-algorithm: Indica AES256.

    • x-amz-server-side-encryption-customer-key: Indica tu clave de cifrado para el nuevo objeto.

    • x-amz-server-side-encryption-customer-key-MD5: indica el resumen MD5 de la clave de cifrado del nuevo objeto.

Precaución Las claves de cifrado que facilites nunca se almacenan. Si pierdes una clave de cifrado, pierdes el objeto correspondiente. Antes de usar claves proporcionadas por el cliente para proteger los datos de los objetos, revisa las consideraciones para "utilizando el cifrado del lado del servidor".
Nota Si un objeto está cifrado con SSE o SSE-C, se ignoran todas las configuraciones de cifrado a nivel de depósito o de grid.

Control de versiones

Si se ha habilitado el control de versiones para un bucket, se genera automáticamente un versionId único para la versión del objeto que se va a almacenar. Este versionId también se devuelve en la respuesta mediante el encabezado de respuesta x-amz-version-id.

Si se suspende el control de versiones, la versión del objeto se almacena con un null versionId y si ya existe una versión null, se sobrescribirá.

Cálculos de la firma para el encabezado «Authorization»

Al usar la cabecera Authorization para autenticar solicitudes, StorageGRID se diferencia de AWS de las siguientes formas:

  • StorageGRID no requiere que los encabezados host se incluyan dentro de CanonicalHeaders.

  • StorageGRID no requiere que se incluya Content-Type dentro de CanonicalHeaders.

  • StorageGRID no requiere que x-amz-*`las cabeceras se incluyan dentro de `CanonicalHeaders.

Nota Como buena práctica general, incluye siempre estos encabezados dentro de CanonicalHeaders para garantizar que se verifiquen; sin embargo, si los excluyes, StorageGRID no devuelve un error.

Para más detalles, consulta "${post_edited_translations.segment}".

Información relacionada