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.

Saiba mais sobre replicação entre grids no StorageGRID

A replicação entre grades é a replicação automática de objetos entre buckets S3 selecionados em dois sistemas StorageGRID conectados em uma "conexão de federação de grid". "Clonagem de conta"é necessário para a replicação entre grades.

Fluxo de trabalho para replicação entre grids

O diagrama de fluxo de trabalho resume as etapas para configurar a replicação entre buckets em duas grids.

Fluxo de trabalho de replicação entre grids

Requisitos para replicação entre grids

Se uma conta de locatário tiver a permissão Usar conexão de federação de grade para usar uma ou mais "conexões de federação de grid" grades, um usuário de locatário com permissão de acesso root pode criar buckets nas contas de locatário correspondentes em cada grade. Esses buckets:

  • Podem ter nomes diferentes entre si

  • Pode ter regiões diferentes

  • É necessário ter o versionamento ativado

  • Deve estar vazio

Após a criação de ambos os buckets, a replicação entre grades pode ser configurada para um ou ambos os buckets.

Como funciona a replicação entre grades

Você pode configurar a replicação entre grades para ocorrer em uma direção ou em ambas as direções.

Replicação em uma direção

Se você habilitar a replicação entre grades para um bucket em apenas uma grade, os objetos adicionados a esse bucket (o bucket de origem) serão replicados para o bucket correspondente na outra grade (o bucket de destino). No entanto, os objetos adicionados ao bucket de destino não são replicados de volta para a origem. Na figura, a replicação entre grades está habilitada my-bucket da Grid 1 para a Grid 2, mas não está habilitada na direção oposta.

Imagem mostrando a conexão da federação de grid em uma direção

Replicação em ambas as direções

Se você habilitar a replicação entre grades para o mesmo bucket em ambas as grades, os objetos adicionados a qualquer um dos buckets serão replicados para a outra grade. Na figura, a replicação entre grades está habilitada para my-bucket em ambas as direções.

Imagem mostrando a replicação em uma direção em comparação com a replicação em ambas as direções

O que acontece quando objetos são ingeridos?

Quando um cliente S3 adiciona um objeto a um bucket com replicação entre grades habilitada, ocorre o seguinte:

  1. StorageGRID replica automaticamente o objeto do bucket de origem para o bucket de destino. O tempo necessário para executar essa operação de replicação em segundo plano depende de vários fatores, incluindo o número de outras operações de replicação pendentes.

    O cliente S3 pode verificar o status de replicação de um objeto emitindo uma solicitação GetObject ou HeadObject. A resposta inclui um cabeçalho de resposta específico do StorageGRID x-ntap-sg-cgr-replication-status, que possui um dos seguintes valores:

    Grid Status de replicação

    Fonte

    • CONCLUÍDO: A replicação foi bem-sucedida para todas as conexões do grid.

    • PENDENTE: O objeto ainda não foi replicado para pelo menos uma conexão de grid.

    • FALHA: A replicação não está pendente para nenhuma conexão de grid e pelo menos uma falhou com uma falha permanente. Você deve resolver o erro.

    Destino

    RÉPLICA: O objeto foi replicado da grid de origem.

    Observação StorageGRID não suporta o x-amz-replication-status cabeçalho.
  2. StorageGRID utiliza as políticas ILM ativas de cada grid para gerenciar os objetos, da mesma forma que faria com qualquer outro objeto. Por exemplo, o Objeto A no Grid 1 pode ser armazenado como duas cópias replicadas e mantido indefinidamente, enquanto a cópia do Objeto A que foi replicada para o Grid 2 pode ser armazenada usando codificação de apagamento 2+1 e excluída após três anos.

O que acontece quando os objetos são excluídos?

Conforme descrito em "Excluir fluxo de dados", StorageGRID pode excluir um objeto por qualquer um destes motivos:

  • O cliente S3 emite uma solicitação de exclusão.

  • Um usuário do Tenant Manager seleciona a opção "Excluir objetos no bucket" para remover todos os objetos de um bucket.

  • O bucket possui uma configuração de ciclo de vida, que expira.

  • O último período de tempo na regra ILM para o objeto termina e não há mais posicionamentos especificados.

Quando StorageGRID exclui um objeto devido a uma operação de exclusão de objetos no bucket, expiração do ciclo de vida do bucket ou expiração do posicionamento ILM, o objeto replicado nunca é excluído do outro grid em uma conexão de federação de grids. No entanto, marcadores de exclusão adicionados ao bucket de origem por exclusões do cliente S3 podem, opcionalmente, ser replicados para o bucket de destino.

Para entender o que acontece quando um cliente S3 exclui objetos de um bucket com replicação entre grades habilitada, revise como os clientes S3 excluem objetos de buckets com versionamento habilitado, conforme descrito a seguir:

  • Se um cliente S3 emitir uma solicitação de exclusão que inclua um ID de versão, essa versão do objeto será removida permanentemente. Nenhum marcador de exclusão é adicionado ao bucket.

  • Se um cliente S3 emitir uma solicitação de exclusão que não inclua um ID de versão, StorageGRID não exclui nenhuma versão do objeto. Em vez disso, ele adiciona um marcador de exclusão ao bucket. O marcador de exclusão faz com que o StorageGRID aja como se o objeto tivesse sido excluído:

    • Uma solicitação GetObject sem um ID de versão falha com 404 No Object Found

    • Uma solicitação GetObject com um ID de versão válido é bem-sucedida e retorna a versão do objeto solicitada.

Quando um cliente S3 exclui um objeto de um bucket que possui replicação entre grades habilitada, StorageGRID determina se deve replicar a solicitação de exclusão para o destino, da seguinte forma:

  • Se a solicitação de exclusão incluir um ID de versão, essa versão do objeto será removida permanentemente da grid de origem. No entanto, StorageGRID não replica solicitações de exclusão que incluem um ID de versão, portanto, a mesma versão do objeto não é excluída do destino.

  • Se a solicitação de exclusão não incluir um ID de versão, StorageGRID pode, opcionalmente, replicar o marcador de exclusão, dependendo de como a replicação entre grids está configurada para o bucket:

    • Se você optar por replicar os marcadores de exclusão (padrão), um marcador de exclusão será adicionado ao bucket de origem e replicado para o bucket de destino. Na prática, o objeto parecerá ter sido excluído em ambas as grids.

    • Se você optar por não replicar os marcadores de exclusão, um marcador de exclusão será adicionado ao bucket de origem, mas não será replicado para o bucket de destino. Na prática, os objetos excluídos na grid de origem não serão excluídos na grid de destino.

Na figura, Replicar marcadores de exclusão foi definido como Sim quando "A replicação entre grades foi ativada". As solicitações de exclusão para o bucket de origem que incluem um ID de versão não excluem objetos do bucket de destino. As solicitações de exclusão para o bucket de origem que não incluem um ID de versão parecem excluir objetos no bucket de destino.

imagem mostrando a exclusão de cliente replicado em ambas as grades

Observação Se você deseja manter as exclusões de objetos sincronizadas entre as grades, crie "Configurações de ciclo de vida S3" correspondentes para os buckets em ambas as grades.

Como os objetos criptografados são replicados

Ao usar a replicação entre grades para replicar objetos entre grades, você pode criptografar objetos individuais, usar a criptografia padrão do bucket ou configurar a criptografia em toda a grade. Você pode adicionar, modificar ou remover as configurações de criptografia padrão do bucket ou da grade antes ou depois de habilitar a replicação entre grades para um bucket.

Para criptografar objetos individuais, você pode usar SSE (criptografia do lado do servidor com chaves gerenciadas pelo StorageGRID) ao adicionar os objetos ao bucket de origem. Use o x-amz-server-side-encryption cabeçalho da solicitação e especifique AES256. Consulte "Use criptografia do lado do servidor".

Observação O uso de SSE-C (criptografia do lado do servidor com chaves fornecidas pelo cliente) não é compatível com a replicação entre grids. A operação de ingestão falhará.

Para usar a criptografia padrão para um bucket, use uma solicitação PutBucketEncryption e defina o parâmetro SSEAlgorithm como AES256. A criptografia no nível do bucket se aplica a quaisquer objetos ingeridos sem o cabeçalho x-amz-server-side-encryption da solicitação. Consulte "Operações em buckets".

Para usar a criptografia em nível de grid, defina a opção Criptografia de objeto armazenado como AES-256. A criptografia em nível de grid se aplica a quaisquer objetos que não estejam criptografados no nível do bucket ou que sejam ingeridos sem o cabeçalho de solicitação x-amz-server-side-encryption. Consulte "Configurar as opções de rede e de objeto".

Observação O SSE não suporta AES-128. Se a opção Criptografia de objeto armazenado estiver habilitada para o grid de origem usando a opção AES-128, o uso do algoritmo AES-128 não é propagado para o objeto replicado. Em vez disso, o objeto replicado usa a configuração de criptografia padrão do bucket ou do grid de destino, se disponível.

Ao determinar como criptografar objetos de origem, StorageGRID aplica estas regras:

  1. Use o `x-amz-server-side-encryption`cabeçalho de ingestão, se presente.

  2. Caso não haja um cabeçalho de ingestão, utilize a configuração de criptografia padrão do bucket, se configurada.

  3. Se uma configuração de bucket não estiver definida, use a configuração de criptografia de toda a grade, se estiver configurada.

  4. Se não houver uma configuração para toda a grade, não criptografe o objeto de origem.

Ao determinar como criptografar objetos replicados, StorageGRID aplica estas regras nesta ordem:

  1. Use a mesma criptografia do objeto de origem, a menos que esse objeto use criptografia AES-128.

  2. Se o objeto de origem não estiver criptografado ou usar AES-128, use a configuração de criptografia padrão do bucket de destino, se configurada.

  3. Se o bucket de destino não tiver uma configuração de criptografia, use a configuração de criptografia de toda a grid de destino, se configurada.

  4. Se não houver uma configuração para toda a grid, não criptografe o objeto de destino.

Replicação entre grades com S3 Object Lock

Você pode configurar a replicação entre grids entre buckets do StorageGRID com o S3 Object Lock ativado nas seguintes circunstâncias.

Quando o S3 Object Lock no bucket de origem está…​ E o S3 Object Lock no bucket de destino é…​

Habilitado

Habilitado

Desabilitado

Habilitado

Quando o S3 Object Lock no bucket de origem estiver ativado:

  • Os objetos são bloqueados com configurações de retenção no destino nesta ordem:

    1. Os valores do cabeçalho de retenção do objeto de origem para:

      x-amz-object-lock-mode

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

    2. A retenção padrão do bucket de origem, se definida.

    3. A retenção padrão do bucket de destino, se definida.

    A configuração de retenção padrão do bucket de destino não substitui as configurações de retenção replicadas do objeto de origem.

  • Você pode definir o status de guarda legal para o objeto de destino usando x-amz-object-lock-legal-hold ao fazer o upload do objeto.

  • Ocorre um erro se o locatário ou bucket de destino não for compatível com as configurações de S3 Object Lock do objeto de origem. Consulte "Alertas e erros de replicação entre grids."

Quando o bloqueio de objeto S3 no bucket de origem está desativado:

  • Você pode configurar a retenção padrão no bucket de destino para aplicar as configurações de retenção do S3 Object Lock ao objeto de destino.

  • O objeto de destino não pode definir um status de guarda legal.

PutObjectTagging e DeleteObjectTagging não são suportados

PutObjectTagging e DeleteObjectTagging solicitações não são suportadas para objetos em buckets que tenham replicação entre grades ativada.

Se um cliente S3 emitir uma solicitação PutObjectTagging ou DeleteObjectTagging, 501 Not Implemented é retornado. A mensagem é Put(Delete) ObjectTagging isn't available for buckets that have cross-grid replication configured.

PutObjectRetention e PutObjectLegalHold não são suportados

PutObjectRetention e PutObjectLegalHold solicitações não são totalmente compatíveis com objetos em buckets que têm replicação entre grids ativada.

Se um cliente S3 emitir uma solicitação PutObjectRetention ou PutObjectLegalHold, as configurações do objeto de origem serão modificadas, mas as alterações não serão aplicadas ao destino.

Como os objetos segmentados são replicados

O tamanho máximo do segmento da grid de origem se aplica aos objetos replicados para a grid de destino. Quando os objetos são replicados para outra grid, a configuração Tamanho Máximo do Segmento (Configuração > Sistema > Opções de armazenamento) da grid de origem é usada em ambas as grids. Por exemplo, suponha que o tamanho máximo do segmento para a grid de origem seja 1 GB, enquanto o tamanho máximo do segmento da grid de destino seja 50 MB. Se você ingerir um objeto de 2 GB na grid de origem, esse objeto será salvo como dois segmentos de 1 GB. Ele também é replicado para a grid de destino como dois segmentos de 1 GB, mesmo que o tamanho máximo do segmento dessa grid seja 50 MB.