Realocação de bucket

Esta página oferece uma visão geral da realocação de bucket, os benefícios, os casos de uso, como funciona e as limitações.

Visão geral

A mudança de bucket do Cloud Storage permite a migração sem servidor de buckets entre localizações geográficas. Com a realocação de bucket, é possível fazer o seguinte:

  • Mova um bucket de um local para outro sem mudar o nome ou exigir a transferência manual de dados dentro do bucket.

  • Melhore a performance e a eficiência de custos alinhando a configuração do Cloud Storage da sua carga de trabalho com o Compute Engine.

Vantagens

Os benefícios da realocação de bucket são os seguintes:

  • Migração simplificada: é possível realocar buckets com o mínimo de sobrecarga operacional. Não são necessários scripts complexos ou processos com várias etapas.

  • Operação contínua: seus aplicativos permanecem acessíveis durante todo o processo de realocação, sem tempo de inatividade para operações de leitura e com tempo de inatividade mínimo para operações de gravação.

  • Melhoria no desempenho: a colocalização de recursos do Compute Engine e do Cloud Storage na mesma região pode reduzir a latência e melhorar o desempenho.

  • Preservação de metadados: o processo de realocação de bucket retém os metadados do objeto. A retenção dos metadados do objeto garante compatibilidade com aplicativos e fluxos de trabalho existentes após a movimentação do bucket.

  • Configurações de classe de armazenamento: é possível manter as configurações atuais da classe do Cloud Storage, incluindo a classe automática. A preservação da classe de armazenamento garante que sua estrutura de custos permaneça consistente após a mudança.

Por que usar a realocação de bucket?

Confira alguns casos de uso para realocar seus buckets:

  • Reduzir o custo de transferência de dados: se os dados forem acessados com frequência de um local distante de onde estão armazenados, você poderá realocar o bucket para um local próximo de onde ele é acessado, resultando na redução do custo de transferência de dados. Por exemplo, se os dados forem acessados principalmente na Europa, mas armazenados nos Estados Unidos, você poderá mover o bucket para um local na Europa para reduzir custos.

  • Melhorar a performance: é possível melhorar a velocidade e a resposta do aplicativo movendo os dados para mais perto do Compute Engine. Por exemplo, se o aplicativo for executado em us-central1, mas os dados estiverem em asia-east1, você poderá realocar o bucket para us-central1 para reduzir a latência.

  • Melhorar a resiliência: é possível proteger seus dados importantes contra interrupções regionais. Por exemplo, se os dados estiverem armazenados em uma única região, você poderá relocalizá-los para locais duplos ou multirregionais para aumentar a disponibilidade e a recuperação de desastres.

Tipos de recolocação

A realocação de um bucket envolve inatividade de gravação dependendo dos locais de origem e destino do bucket. Para saber como o local afeta o tipo de realocação, consulte Determinar o tipo de realocação do seu bucket. Os dois tipos de realocação de intervalo são os seguintes:

  • Relocalização de bucket com inatividade de gravação: na relocalização de bucket com inatividade de gravação, há um período em que não é possível realizar operações de gravação de objetos durante o processo de relocalização de bucket.

  • Relocalização de bucket sem inatividade de gravação: na relocalização de bucket sem inatividade de gravação, é possível continuar realizando operações de gravação de objetos sem interrupção enquanto a relocalização de bucket acontece em segundo plano.

A tabela a seguir descreve as diferenças importantes entre os tipos de realocação de inatividade de gravação e sem inatividade de gravação:

Especificação Realocação de bucket com tempo de inatividade de gravação Realocação de bucket sem inatividade de gravação
Disponibilidade de gravação Não foi possível realizar operações de gravação durante a etapa final de sincronização. Sem interrupção das operações de gravação.
Envolvimento do usuário O usuário precisa iniciar a etapa de finalização do período de inatividade na gravação. Nenhuma etapa de finalização explícita é necessária.
Impacto no desempenho Não foi possível gravar ou atualizar objetos no bucket durante a etapa final de sincronização. Possível aumento da latência de leitura e gravação de objetos durante a realocação.
Cancelamento da realocação de bucket Mais rápido do que as mudanças sem tempo de inatividade de gravação. O cancelamento não é instantâneo. Pode demorar mais devido à necessidade de preencher objetos.
Suporte a recursos O suporte a recursos é menor do que o de movimentos sem tempo de inatividade de gravação. Limitações em recursos como envios em várias partes, políticas de retenção, Firebase e appspot. Para mais informações sobre essas limitações, consulte Limitações.

Determinar o tipo de realocação do bucket

Os locais de origem e destino do bucket determinam o tipo de realocação.

Ao realocar um bucket entre regiões, regiões duplas ou multirregionais, você enfrenta um período de inatividade em que não é possível gravar no bucket. No entanto, é possível recolocar um bucket sem tempo de inatividade nos seguintes casos:

  • Reloque de uma multirregião para uma birregião configurável se os dois locais compartilham o mesmo código de multirregião.

  • Reloque entre birregiões configuráveis se os dois locais compartilharem o mesmo código multirregional.

  • Reloque de uma birregião configurável para uma multirregião se os dois locais compartilham o mesmo código multirregional.

Entender o processo de realocação de buckets

O realocamento de bucket ajuda a mover seus dados de um bucket de origem para um bucket de destino. O bucket de origem contém os dados que você quer mover, e o bucket de destino é onde você quer mover os dados.

O diagrama a seguir mostra o fluxo do processo de realocação de bucket.

Fluxo do processo de realocação de bucket.
Figura 1. Fluxo do processo de realocação de bucket (clique para ampliar).

As etapas numeradas se referem aos números no diagrama. O diagrama mostra as seguintes etapas:

  1. Cópia incremental de dados: a etapa de cópia incremental de dados copia dados do bucket de origem para o bucket de destino. Os metadados do bucket estão bloqueados para gravação para evitar qualquer mudança no bucket que possa afetar o processo de realocação. No entanto, você pode gravar, modificar e excluir objetos no bucket. Os fatores que influenciam a duração são os seguintes:

    • A frequência de atualizações, exclusões ou adições de objetos no bucket afeta diretamente a duração da cópia. Uma taxa de mudança mais alta exige mais tempo. Há uma taxa máxima de movimento de objeto Rm, objects/second. Com N objetos no total e uma taxa de atualização de R objects/second, a duração da etapa de cópia pode ser estimada em N / (Rm - R) segundos.

    • Os buckets grandes exigem mais tempo de realocação devido à largura de banda finita.

    • O tamanho dos objetos individuais afeta o tempo de cópia. Objetos maiores que 10 GB levam mais tempo para serem transferidos do que objetos com menos de 10 GB devido a restrições de largura de banda. Por exemplo, um objeto de 1 TB leva um dia para ser copiado. Recomendamos que você divida objetos grandes em objetos menores de 0,1 a 1 GB.

    Para mais informações sobre como iniciar a cópia incremental de dados, consulte Iniciar a etapa de cópia incremental de dados.

  2. Monitorar a cópia incremental de dados: para conferir o status da etapa de cópia incremental de dados, verifique regularmente a lista de operações de longa duração. Para saber como verificar o status da etapa de cópia de dados incrementais, consulte Monitorar a etapa de cópia de dados incrementais.

  3. Sincronização final: para relocalizações com tempo de inatividade de gravação, depois que a cópia incremental de dados for concluída, você vai precisar acionar a etapa final de sincronização. A etapa final de sincronização inclui um período em que não é possível gravar no bucket para garantir a consistência dos dados. A etapa final de sincronização inclui as seguintes ações:

    1. O bucket está temporariamente bloqueado para gravação. Como resultado, não é possível gravar ou atualizar objetos no bucket durante esse período, o que evita inconsistências de dados.

    2. Todas as mudanças feitas nos dados de um bucket desde a etapa de cópia incremental são copiadas para o bucket de destino, garantindo que o bucket realocado tenha os dados mais atualizados. Quando a cópia do objeto é concluída, uma comparação é realizada para garantir a paridade de dados entre os buckets de origem e destino. Após a comparação de dados, o local do bucket é atualizado, e todas as solicitações são redirecionadas para o novo local.

    3. Depois que todos os dados forem transferidos, verificados e o bucket estiver operacional no novo local, o bloqueio de gravação será removido. Em seguida, você pode retomar a gravação e a atualização de objetos no bucket.

    Para saber como iniciar a etapa final de sincronização, consulte Iniciar a etapa final de sincronização.

Limitações

O serviço de realocação de bucket oferece suporte a até cinco reacomodações simultâneas do mesmo local em um projeto.

As seções a seguir descrevem as limitações que se aplicam a realocações com e sem tempo de inatividade de gravação.

Relocalização com limitações de inatividade de gravação

A realocação com tempo de inatividade de gravação tem as limitações listadas nas seções a seguir.

Limitações de processamento de dados

Confira a seguir as limitações ao processar dados durante a mudança:

  • Quebra de tabela: as tabelas externas do BigLake e do BigQuery que usam o Apache Iceberg vão quebrar e precisarão ser recriadas manualmente. A detecção automática das tabelas afetadas não está disponível.

  • Processamento de objetos da classe automática: a classe automática usa padrões de acesso para determinar quando fazer a transição de objetos para classes de armazenamento de acesso raro. Durante a sincronização final do processo de realocação do bucket, a classe automática é pausada e os objetos não são transferidos para classes de armazenamento de acesso raro. Quando a sincronização final for concluída, a Autoclass será retomada.

    • Os objetos em uma classe de armazenamento padrão são processados da seguinte maneira:

      • Os objetos da classe de armazenamento padrão têm um período de 30 dias sem acesso antes de fazer a transição para uma classe mais fria, como o Nearline Storage. Quando um objeto na classe de armazenamento padrão é movido durante a realocação, ele é tratado como se tivesse sido acessado. Como resultado, o processo de realocação redefine o período sem acesso, e mesmo que um objeto estivesse prestes a fazer a transição para o Nearline Storage antes da mudança, ele precisa esperar mais 30 dias após a conclusão da realocação.

    • Os objetos em uma classe de armazenamento não padrão são processados da seguinte maneira:

      • Recolocar objetos nas classes de armazenamento Nearline, Coldline ou Archive não é considerado acesso a eles. Como resultado, o período sem acesso a esses objetos não é afetado.

      • Se você ler ou gravar um objeto em um bucket de classe de armazenamento não padrão durante a realocação, ele não será atualizado automaticamente para uma classe mais quente, como o Armazenamento padrão. Isso ajuda a evitar transições desnecessárias de classe de armazenamento durante o processo de realocação.

      • Se um objeto estiver programado para ser rebaixado para uma classe de armazenamento mais fria, como de Nearline Storage para Coldline Storage, o processo de realocação não vai interferir na programação. O downgrade será concluído conforme planejado após a conclusão da mudança.

  • Limite de tamanho de objeto: um limite de 2 TB se aplica aos tamanhos de objetos para realocação.

Recursos não suportados

Os buckets que usam os seguintes recursos não podem ser realocados:

Restrições operacionais

A realocação de bucket com inatividade de gravação tem as seguintes restrições operacionais:

  • Restrição de projeto: não é possível realocar buckets entre projetos.
  • Uploads retomáveis: os uploads retomáveis em andamento precisam ser finalizados antes da etapa final de sincronização para evitar a perda de dados.
  • Atualizações de metadados: não é possível atualizar os metadados de um bucket durante a relocação.
  • Aumento gradual da taxa de solicitações: os buckets realocados estão sujeitos às mesmas diretrizes de aumento gradual da taxa de solicitações que os buckets recém-criados.

Relocalização sem limitações de inatividade de gravação

A realocação de bucket sem tempo de inatividade de gravação tem as seguintes limitações:

  • Uploads de várias partes: não há suporte para uploads de várias partes incompletos, que precisam ser concluídos ou cancelados antes da realocação. Novos uploads de várias partes são bloqueados durante a transferência.
  • Políticas de retenção: todas as políticas de retenção precisam ser desbloqueadas antes da mudança.
  • Buckets do Firebase e do Appspot: não é possível realocar buckets associados ao Firebase ou ao Appspot.
  • Atualizações de progresso: as atualizações de progresso da realocação podem não ser lineares.

Região sem suporte

A realocação de bucket não está disponível na região me-central1 para buckets de origem ou de destino.

A seguir