Skip to main content
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.

ColocarObjeto

PDFs

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

Resolver conflitos

Solicitações de clientes conflitantes, como dois clientes gravando na mesma chave, são resolvidas com base no princípio de "últimos ganhos". O tempo para a avaliação de "últimas vitórias" é baseado em quando o sistema StorageGRID conclui uma determinada solicitação, e não em quando os clientes S3 iniciam uma operação.

Tamanho do objeto

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

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

Observação Se você atualizou do StorageGRID 11.6 ou anterior, o alerta de tamanho de objeto S3 PUT muito grande será acionado se você tentar carregar 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 neste caso. No entanto, para se alinhar ao padrão AWS S3, versões futuras do StorageGRID não suportarão uploads de objetos maiores que 5 GiB.

Tamanho dos metadados do usuário

O Amazon S3 limita o tamanho dos metadados definidos pelo usuário em cada cabeçalho de solicitação PUT a 2 KB. O 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 em 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.

O StorageGRID não analisa nem interpreta caracteres UTF-8 de escape 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:

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

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

Limites de tags de objeto

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

Propriedade do objeto

No StorageGRID, todos os objetos são de propriedade da conta do proprietário do bucket, incluindo objetos criados por uma conta não proprietária ou 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

    Quando você especifica aws-chunked paraContent-Encoding O StorageGRID não verifica os seguintes itens:

    • O StorageGRID não verifica o chunk-signature contra os dados do bloco.

    • O StorageGRID não verifica o valor que você fornece para x-amz-decoded-content-length contra o objeto.

  • Content-Language

  • Content-Length

  • Content-MD5

  • Content-Type

  • Expires

  • Transfer-Encoding

    A codificação de transferência em blocos é suportada se aws-chunked a assinatura de carga útil também é 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, use este formato geral:

    x-amz-meta-name: value

    Se você quiser usar a opção Tempo de criação definido pelo usuário como o Tempo de referência para uma regra ILM, você deve usar creation-time como o nome dos metadados que registram quando o objeto foi criado. Por exemplo:

    x-amz-meta-creation-time: 1443399726

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

    Observação Uma regra de ILM não pode usar 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 restrita. 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 reter até a data. Ver "Use a API REST do S3 para configurar o bloqueio de objeto do S3" .

  • 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:

  • x-amz-acl

  • x-amz-sdk-checksum-algorithm

  • x-amz-trailer

  • x-amz-website-redirect-location

    O x-amz-website-redirect-location retornos de cabeçalho XNotImplemented .

Opções de classe de armazenamento

O x-amz-storage-class O cabeçalho da solicitação é suportado. O valor submetido 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 tem efeito.

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

  • STANDARD(Padrão)

    • Confirmação dupla: se a regra do ILM especificar a opção 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 o ILM é avaliado, o StorageGRID determina se essas cópias provisórias iniciais atendem às instruções de posicionamento na regra. Caso contrário, talvez seja necessário fazer novas cópias de objetos em locais diferentes e as cópias provisórias iniciais talvez precisem ser excluídas.

    • Balanceado: Se a regra do ILM especificar a opção Balanceado e o StorageGRID não puder fazer imediatamente todas as cópias especificadas na regra, o StorageGRID fará duas cópias provisórias em diferentes Nós de Armazenamento.

      Se o 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 tem efeito.

  • REDUCED_REDUNDANCY

    • Confirmação dupla: se a regra do ILM especificar a opção Confirmação dupla para o comportamento de ingestão, o StorageGRID criará uma única cópia provisória à medida que o objeto for ingerido (confirmação única).

    • Balanceado: Se a regra ILM especificar a opção Balanceado, o StorageGRID fará uma única cópia provisória somente se o sistema não puder fazer imediatamente todas as cópias especificadas na regra. Se o StorageGRID puder executar o posicionamento síncrono, este cabeçalho não terá efeito. O REDUCED_REDUNDANCY A opção é melhor usada quando a regra ILM que corresponde ao objeto cria uma única cópia replicada. Neste caso usando REDUCED_REDUNDANCY elimina a criação e exclusão desnecessárias de uma cópia extra do objeto para cada operação de ingestão.

    Usando o REDUCED_REDUNDANCY opção não é recomendada em outras circunstâncias. REDUCED_REDUNDANCY aumenta o risco de perda de dados do objeto durante a ingestão. Por exemplo, você pode perder dados se a cópia única for armazenada inicialmente em um nó de armazenamento 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 será perdido se um nó de armazenamento falhar ou tiver um erro significativo. Você também perde temporariamente o acesso ao objeto durante procedimentos de manutenção, como atualizações.

Especificando REDUCED_REDUNDANCY afeta apenas quantas cópias são criadas quando um objeto é ingerido pela primeira vez. Isso não afeta quantas cópias do objeto são feitas quando o objeto é avaliado pelas políticas de 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 o S3 Object Lock habilitado, o REDUCED_REDUNDANCY a opção é ignorada. Se você estiver ingerindo um objeto em um bucket compatível legado, o REDUCED_REDUNDANCY opção retorna um erro. O StorageGRID sempre executará uma ingestão de 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 cabeçalho a seguir se quiser criptografar o objeto com uma chave exclusiva gerenciada pelo StorageGRID.

  • SSE-C: Use todos esses três cabeçalhos se 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 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, todas as configurações de criptografia em nível de bucket ou de grade serão ignoradas.

Controle de versão

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

Se o controle de versão for suspenso, a versão do objeto será armazenada com um valor nulo versionId e se uma versão nula já existir, ela será substituída.

Cálculos de assinatura para o cabeçalho de autorização

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

  • StorageGRID não requer host cabeçalhos a serem incluídos dentro CanonicalHeaders .

  • StorageGRID não requer Content-Type para ser incluído dentro CanonicalHeaders .

  • StorageGRID não requer x-amz-* cabeçalhos a serem incluídos dentro CanonicalHeaders .

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

Para mais detalhes, consulte "Cálculos de assinatura para o cabeçalho de autorização: transferindo carga útil em um único bloco (AWS Signature versão 4)" .

Informações relacionadas