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.

Cabeçalhos e opções de solicitação S3 CreateMultipartUpload no StorageGRID

PDFs

A operação CreateMultipartUpload (anteriormente chamada de Initiate Multipart Upload) inicia um upload multipart para um objeto e retorna um ID de upload.

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 o Strict "opção de ingestão", o cabeçalho x-amz-storage-class 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 ingestão de confirmação dupla, assim que um objeto for ingerido, uma segunda cópia desse objeto será criada e distribuída para um Storage Node 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, 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 suportados

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

  • Content-Type

  • x-amz-checksum-algorithm

    Atualmente, apenas o valor SHA256 para x-amz-checksum-algorithm é suportado.

  • 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 Adicionar creation-time como metadados definidos pelo usuário não é permitido se você estiver adicionando um objeto a um bucket com a Compliance legada ativada. Um erro será retornado.

  • Cabeçalhos da solicitação S3 Object Lock:

    • 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 a data de retenção da versão do objeto.

    "Use a API REST S3 para configurar o S3 Object Lock"

  • Cabeçalhos de solicitação SSE:

    Observação Para obter informações sobre como StorageGRID lida com caracteres UTF-8, consulte "PutObject".

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 multipart com criptografia do lado do servidor. As opções SSE e SSE-C são mutuamente exclusivas.

  • SSE: Utilize o seguinte cabeçalho na solicitação CreateMultipartUpload se você quiser criptografar o objeto com uma chave exclusiva gerenciada pelo StorageGRID. Não especifique este cabeçalho em nenhuma das solicitações UploadPart.

    • x-amz-server-side-encryption

  • SSE-C: Utilize todos os três cabeçalhos na solicitação CreateMultipartUpload (e em cada solicitação UploadPart subsequente) 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".

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

O seguinte cabeçalho de solicitação não é compatível:

  • x-amz-website-redirect-location

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

Controle de versões

O upload multipart consiste em operações separadas para iniciar o upload, listar os uploads, enviar as partes, montar as partes enviadas e concluir o upload. Os objetos são criados (e versionados, se aplicável) quando a operação CompleteMultipartUpload é realizada.