Skip to main content
Uma versão mais recente deste produto está disponível.
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Adicionar um objeto a um bucket no StorageGRID com a solicitação S3 PutObject

PDFs

Você pode usar a solicitação S3 PutObject para adicionar um objeto a um bucket.

Resolver conflitos

Solicitações conflitantes de clientes, como dois clientes gravando na mesma chave, são resolvidas com base no princípio "latest-wins". O momento da avaliação do "latest-wins" é determinado quando o sistema StorageGRID conclui uma determinada solicitação, e não quando os clientes S3 iniciam uma operação.

Tamanho do objeto

O tamanho máximo recomendado para uma única operação PutObject é de 5 GiB (5.368.709.120 bytes). Se você tiver objetos maiores que 5 GiB, use "upload multipart" em vez disso.

O tamanho máximo suportado para uma única operação PutObject é de 5 TiB (5.497.558.138.880 bytes).

Observação Se você atualizou do StorageGRID 11.6 ou anterior, o alerta "Tamanho do objeto S3 PUT muito grande" será acionado se você tentar fazer o upload de um objeto que exceda 5 GiB. Se você tiver uma nova instalação do StorageGRID 11.7 ou 11.8, o alerta não será acionado nesse caso. No entanto, para alinhar com o padrão AWS S3, as versões futuras do StorageGRID não suportarão uploads de objetos maiores que 5 GiB.

Tamanho dos metadados do usuário

Amazon S3 limita o tamanho dos metadados definidos pelo usuário em cada cabeçalho de solicitação PUT a 2 KB. StorageGRID limita os metadados do usuário a 24 KiB. O tamanho dos metadados definidos pelo usuário é medido pela soma do número de bytes na codificação UTF-8 de cada chave e valor.

Caracteres UTF-8 nos metadados do usuário

Se uma solicitação incluir valores UTF-8 (sem escape) no nome da chave ou no valor dos metadados definidos pelo usuário, o comportamento do StorageGRID será indefinido.

StorageGRID não analisa nem interpreta caracteres UTF-8 escapados incluídos no nome da chave ou no valor dos metadados definidos pelo usuário. Caracteres UTF-8 escapados são tratados como caracteres ASCII:

  • PutObject, CopyObject, GetObject, e HeadObject as solicitações são bem-sucedidas se os metadados definidos pelo usuário incluírem caracteres UTF-8 escapados.

  • StorageGRID não retorna o x-amz-missing-meta cabeçalho se o valor interpretado do nome ou valor da chave incluir caracteres não imprimíveis.

Limites de tags de objeto

Você pode adicionar tags a novos objetos ao carregá-los ou pode adicioná-las a objetos existentes. Tanto StorageGRID quanto Amazon S3 suportam até 10 tags por objeto. As tags associadas a um objeto devem ter chaves de tag exclusivas. Uma chave de tag pode ter até 128 caracteres Unicode e os valores de tag podem ter até 256 caracteres Unicode. Chaves e valores diferenciam maiúsculas de minúsculas.

Propriedade do objeto

No StorageGRID, todos os objetos pertencem à conta proprietária do bucket, incluindo objetos criados por uma conta que não seja proprietária ou por um usuário anônimo.

Cabeçalhos de solicitação suportados

Os seguintes cabeçalhos de solicitação são suportados:

  • Cache-Control

  • Content-Disposition

  • Content-Encoding

    Ao especificar `aws-chunked`para Content-EncodingStorageGRID, o StorageGRID não verifica os seguintes itens:

    • StorageGRID não verifica o chunk-signature em relação aos dados em blocos.

    • StorageGRID não verifica o valor que você fornece para x-amz-decoded-content-length em relação ao objeto.

  • Content-Language

  • Content-Length

  • Content-MD5

  • Content-Type

  • Expires

  • Transfer-Encoding

    A codificação de transferência em partes é suportada se aws-chunked a assinatura da carga também for usada.

  • x-amz-checksum-sha256

  • x-amz-meta-, seguido por um par nome-valor contendo metadados definidos pelo usuário.

    Ao especificar o par nome-valor para metadados definidos pelo usuário, utilize este formato geral:

    x-amz-meta-name: value

    Se você deseja usar a opção Hora de criação definida pelo usuário como a hora de referência para uma regra ILM, você deve usar creation-time como o nome do metadado que registra quando o objeto foi criado. Por exemplo:

    x-amz-meta-creation-time: 1443399726

    O valor de creation-time é avaliado em segundos desde 1º de janeiro de 1970.

    Observação Uma regra ILM não pode usar simultaneamente um horário de criação definido pelo usuário para o horário de referência e a opção de ingestão balanceada ou estrita. Um erro é retornado quando a regra ILM é criada.

  • x-amz-tagging

  • Cabeçalhos de solicitação de bloqueio de objeto S3

    • x-amz-object-lock-mode

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

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

      Se uma solicitação for feita sem esses cabeçalhos, as configurações de retenção padrão do bucket serão usadas para calcular o modo de versão do objeto e a data de retenção. Consulte "Use a API REST S3 para configurar o S3 Object Lock".

  • Cabeçalhos de solicitação SSE:

Cabeçalhos de solicitação não suportados

Os seguintes cabeçalhos de solicitação não são suportados:

  • If-Match

    O If-Match header é aceito, mas não funcional.

  • If-None-Match

    O If-None-Match header é aceito, mas não funcional.

  • x-amz-acl

  • x-amz-sdk-checksum-algorithm

  • x-amz-trailer

  • x-amz-website-redirect-location

    O x-amz-website-redirect-location`cabeçalho retorna `XNotImplemented.

Opções de classe de armazenamento

O `x-amz-storage-class`cabeçalho da solicitação é compatível. O valor enviado para `x-amz-storage-class`afeta como o StorageGRID protege os dados do objeto durante a ingestão e não quantas cópias persistentes do objeto são armazenadas no sistema StorageGRID (o que é determinado pelo ILM).

Se a regra ILM correspondente a um objeto ingerido usar a opção de ingestão estrita, o x-amz-storage-class cabeçalho não terá efeito.

Os seguintes valores podem ser usados para x-amz-storage-class:

  • STANDARD (Padrão)

    • Confirmação dupla: Se a regra ILM especificar a opção de confirmação dupla para o comportamento de ingestão, assim que um objeto for ingerido, uma segunda cópia desse objeto será criada e distribuída para um nó de armazenamento diferente (confirmação dupla). Quando a ILM é avaliada, o StorageGRID determina se essas cópias intermediárias iniciais atendem às instruções de posicionamento na regra. Se não atenderem, novas cópias do objeto podem precisar ser criadas em locais diferentes e as cópias intermediárias iniciais podem precisar ser excluídas.

    • Balanceado: Se a regra ILM especificar a opção Balanceado e StorageGRID não puder criar imediatamente todas as cópias especificadas na regra, StorageGRID faz duas cópias intermediárias em diferentes nós de armazenamento.

      Se StorageGRID puder criar imediatamente todas as cópias de objetos especificadas na regra ILM (posicionamento síncrono), o x-amz-storage-class cabeçalho não terá efeito.

  • REDUCED_REDUNDANCY

    • Confirmação dupla: Se a regra ILM especificar a opção de confirmação dupla para o comportamento de ingestão, StorageGRID cria uma única cópia intermediária à medida que o objeto é ingerido (confirmação única).

    • Balanceado: Se a regra ILM especificar a opção Balanceado, StorageGRID cria uma única cópia intermediária somente se o sistema não puder criar imediatamente todas as cópias especificadas na regra. Se StorageGRID puder realizar o posicionamento síncrono, este cabeçalho não terá efeito. A REDUCED_REDUNDANCY opção é mais adequada quando a regra ILM correspondente ao objeto cria uma única cópia replicada. Nesse caso, usar REDUCED_REDUNDANCY essa opção elimina a criação e exclusão desnecessárias de uma cópia extra do objeto para cada operação de ingestão.

    O uso da REDUCED_REDUNDANCY`opção não é recomendado em outras circunstâncias. `REDUCED_REDUNDANCY Isso aumenta o risco de perda de dados de objeto durante a ingestão. Por exemplo, você pode perder dados se a cópia única for armazenada inicialmente em um Storage Node que falhe antes que a avaliação do ILM possa ocorrer.

Cuidado Ter apenas uma cópia replicada para qualquer período de tempo coloca os dados em risco de perda permanente. Se existir apenas uma cópia replicada de um objeto, esse objeto é perdido se um Storage Node falhar ou apresentar um erro significativo. Você também perde temporariamente o acesso ao objeto durante procedimentos de manutenção, como upgrades.

A especificação `REDUCED_REDUNDANCY`afeta apenas quantas cópias são criadas quando um objeto é ingerido pela primeira vez. Não afeta quantas cópias do objeto são feitas quando o objeto é avaliado pelas políticas ILM ativas e não resulta no armazenamento de dados em níveis mais baixos de redundância no sistema StorageGRID.

Observação Se você estiver ingerindo um objeto em um bucket com S3 Object Lock ativado, a REDUCED_REDUNDANCY opção será ignorada. Se você estiver ingerindo um objeto em um bucket legado Compliant, a REDUCED_REDUNDANCY opção retornará um erro. StorageGRID sempre realizará uma ingestão com confirmação dupla para garantir que os requisitos de conformidade sejam atendidos.

Cabeçalhos de solicitação para criptografia do lado do servidor

Você pode usar os seguintes cabeçalhos de solicitação para criptografar um objeto com criptografia do lado do servidor. As opções SSE e SSE-C são mutuamente exclusivas.

  • SSE: Use o seguinte cabeçalho se você quiser criptografar o objeto com uma chave exclusiva gerenciada pelo StorageGRID.

  • SSE-C: Utilize todos os três cabeçalhos se você quiser criptografar o objeto com uma chave exclusiva que você fornece e gerencia.

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

    • x-amz-server-side-encryption-customer-key: Especifique sua chave de criptografia para o novo objeto.

    • x-amz-server-side-encryption-customer-key-MD5: Especifique o resumo MD5 da chave de criptografia do novo objeto.

Cuidado As chaves de criptografia fornecidas por você nunca são armazenadas. Se você perder uma chave de criptografia, perderá o objeto correspondente. Antes de usar chaves fornecidas pelo cliente para proteger dados de objetos, revise as considerações para "usando criptografia do lado do servidor".
Observação Se um objeto for criptografado com SSE ou SSE-C, quaisquer configurações de criptografia em nível de bucket ou de grid serão ignoradas.

Controle de versões

Se o versionamento estiver habilitado para um bucket, um identificador único versionId é gerado automaticamente para a versão do objeto armazenado. Esse versionId também é retornado na resposta usando o x-amz-version-id cabeçalho da resposta.

Se o versionamento estiver suspenso, a versão do objeto será armazenada com um valor nulo versionId e, se já existir uma versão nula, ela será sobrescrita.

Cálculos de assinatura para o cabeçalho Authorization

Ao usar o Authorization cabeçalho para autenticar solicitações, StorageGRID difere da AWS das seguintes maneiras:

  • StorageGRID não exige que os host cabeçalhos sejam incluídos em CanonicalHeaders.

  • StorageGRID não precisa Content-Type`ser incluído em `CanonicalHeaders.

  • StorageGRID não exige que os cabeçalhos x-amz-* sejam incluídos em CanonicalHeaders.

Observação Como prática recomendada geral, sempre inclua esses cabeçalhos dentro de CanonicalHeaders para garantir que sejam verificados; no entanto, se você excluir esses cabeçalhos, StorageGRID não retorna um erro.

Para obter detalhes, consulte "Cálculos de assinatura para o cabeçalho de autorização: transferência de carga em um único bloco (AWS Signature Version 4)".

Informações relacionadas