Realocação de bucket

Este documento descreve o serviço de realocação bucket do Cloud Storage, que realoca buckets sem servidor entre locais geográficos. Com a relocação de buckets, é possível mover um bucket de um local para outro sem mudar o nome ou exigir a transferência manual de dados dentro do bucket.

Com base nos seus objetivos e no uso do bucket, é necessário planejar a realocação do bucket com cuidado para minimizar a interrupção e fazer a realocação com sucesso. Para mais informações sobre como realocar buckets, consulte Realocar buckets.

Vantagens

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

• Migração simplificada: é possível realocar buckets com sobrecarga operacional mínima. Não é necessário usar scripts complexos nem processos com várias etapas.

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

• Melhor desempenho: colocar 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 buckets retém os metadados do objeto. A retenção dos metadados do objeto garante a compatibilidade com aplicativos e fluxos de trabalho atuais 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. Preservar a classe de armazenamento garante que sua estrutura de custos permaneça consistente após a mudança.

Casos de uso

Confira a seguir alguns casos de uso que podem ser alcançados com a realocação dos seus intervalos:

• Reduza o custo de transferência de dados: evite custos de transferência de dados ao realocar seu bucket mais perto das cargas de trabalho que acessam os dados dele. Por exemplo, se os dados estiverem armazenados nos Estados Unidos e forem acessados principalmente da Europa, mova o bucket para um local europeu para reduzir os custos de transferência de dados.

• Melhorar a performance: aumente a velocidade e a capacidade de resposta do aplicativo movendo os dados para mais perto das cargas de trabalho 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 e reduzir a latência.

• Aumentar a resiliência: proteja seus dados críticos contra interrupções regionais. Por exemplo, se os dados estiverem armazenados em uma única região, é possível realocá-los para uma região dupla ou multirregional para aumentar a disponibilidade e a recuperação de desastres.

Tipos de realocação

Há dois tipos de realocações de intervalos:

• Realocação de buckets com tempo de inatividade de gravação: nesse tipo de realocação, há um período em que não é possível realizar operações de gravação de objetos durante o processo.

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

Os locais de origem e destino do bucket determinam se uma realocação envolve tempo de inatividade de gravação. A tabela a seguir mostra como o local do bucket afeta o tempo de inatividade de gravação durante uma realocação, incluindo as diferenças entre realocações com e sem tempo de inatividade.

Especificação	Realocação de bucket com tempo de inatividade de gravação	Realocação de bucket sem inatividade de gravação
Local do bucket	A mudança de um bucket entre os seguintes locais causa inatividade: Regiões Regiões duplas Locais multirregionais Multirregiões e birregiões predefinidas Multirregiões e birregiões configuráveis se os dois locais tiverem códigos de multirregião diferentes	A mudança de um bucket entre os seguintes locais não causa tempo de inatividade se os dois locais compartilharem o mesmo código multirregional: Birregiões configuráveis Multirregiões e birregiões configuráveis
Disponibilidade de gravação	Não é possível realizar operações de gravação durante a etapa final de sincronização.	As operações de gravação continuam sem interrupções durante a mudança. Observação: as mudanças na política sem tempo de inatividade de gravação levam pelo menos sete dias para serem concluídas porque precisam aguardar a conclusão dos uploads retomáveis em andamento.
Envolvimento do usuário	É necessário iniciar a etapa de finalização do período de inatividade na gravação.	Não é necessário uma etapa de finalização explícita.
Impacto no desempenho	Não é possível gravar ou atualizar objetos no bucket durante a etapa final de sincronização.	A latência de leitura e gravação de objetos pode aumentar durante a realocação.
Cancelamento da realocação de bucket	Mais rápido que as realocações sem tempo de inatividade de gravação.	O cancelamento não é instantâneo e pode levar mais tempo devido à necessidade de preencher objetos.
Suporte a recursos	Oferece menos suporte a recursos do que realocações sem tempo de inatividade de gravação. Para mais informações sobre os recursos sem suporte, consulte Recursos sem suporte.	Há limitações para recursos como uploads em várias partes, políticas de retenção, Firebase e appspot. Para mais informações sobre essas limitações, consulte Limitações.
Duração mínima da mudança	Nenhum	Sete dias

Entenda o processo de realocação de buckets

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

O diagrama a seguir mostra o fluxo do processo de realocação de buckets:

^* A sincronização final só é necessária para realocações com tempo de inatividade de gravação.

A tabela a seguir lista as três etapas principais e a descrição de cada uma delas:

Etapa	Descrição
Executar uma simulação (opcional)	Simula o processo de realocação do bucket para identificar possíveis problemas antes do início da transferência de dados.
Iniciar a etapa de cópia incremental de dados	Copia dados do bucket de origem para o bucket de destino. Os metadados do bucket são bloqueados para gravação para evitar mudanças que possam afetar o processo de realocação. No entanto, você pode escrever, 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 movimentação de objetos `Rm, objetos/segundo`. Com `N` objetos totais e uma taxa de atualização de `R objetos/segundo`, a duração da etapa de cópia pode ser estimada como `N / (Rm - R)` segundos. 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.
Inicie a etapa final de sincronização (necessário apenas para realocações com tempo de inatividade de gravação)	Depois que você inicia a sincronização final, o bucket é 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. No entanto, você pode continuar lendo do bucket. Quando todos os dados forem transferidos e verificados, e o bucket estiver operacional no novo local, o bloqueio de gravação será removido automaticamente. Em seguida, você pode retomar a gravação e a atualização de objetos no bucket.

Limitações

O serviço de realocação de buckets aceita até cinco realocaçõ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.

Realocação com limitações de tempo de inatividade de gravação

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

Limitações no tratamento de dados

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

• Quebra de tabelas: as tabelas externas do BigLake e as tabelas do BigQuery que usam o Apache Iceberg vão quebrar e precisarão ser recriadas manualmente. A detecção automática de 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 é concluída, o Autoclass é retomado.

  • Os objetos em uma classe Standard Storage são processados da seguinte maneira:

    • Os objetos da classe de armazenamento Standard têm um período de 30 dias sem acesso antes de poderem ser transferidos para uma classe mais fria, como o Nearline Storage. Quando um objeto na classe de armazenamento Standard é 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. Mesmo que um objeto estivesse prestes a ser transferido para o Nearline Storage antes da movimentação, ele precisa esperar mais 30 dias após a conclusão da realocação.

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

    • A realocação de objetos nas classes de armazenamento Nearline, Coldline ou Archive não conta como acesso. Como resultado, o período sem acesso para esses objetos não é afetado.

    • Ao realocar um bucket, se você acessar com frequência objetos em buckets com uma classe de armazenamento que não seja Standard, como Nearline, Coldline ou Archive, o bucket não fará a transição automática para uma classe de armazenamento mais quente. Por exemplo, o bucket não faz a transição automática do Archive Storage para o Coldline Storage ou do Coldline Storage para o Standard Storage, mesmo que os objetos sejam acessados com frequência. Esse comportamento impede as transições automáticas de classe de armazenamento durante a realocação.

    • Se um objeto estiver programado para fazer a transição para uma classe de armazenamento mais fria, como do Nearline Storage para o Coldline Storage, o processo de realocação não vai interferir no cronograma. A transição segue conforme o planejado após a conclusão da mudança.

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

Uploads de várias partes

Os uploads de várias partes não são compatíveis com a realocação de buckets com inatividade de gravação, independentemente do estado (concluído, em andamento ou iniciado durante a realocação). Se você tiver uploads de várias partes concluídos no bucket que quer realocar, faça o upload novamente dos objetos sem usar métodos de várias partes e exclua os uploads de várias partes. Caso contrário, a realocação vai falhar. Se você fizer upload de objetos usando uploads de várias partes durante a realocação do bucket com tempo de inatividade de gravação, um erro FAILED_PRECONDITION vai ocorrer.

Recursos não suportados

Não é possível realocar buckets que usam os seguintes recursos:

• Chaves de criptografia gerenciadas pelo cliente (CMEK) ou chaves de criptografia fornecidas pelo cliente (CSEK).

• Políticas de retenção bloqueadas.

• Objetos com retenções temporárias.

• Buckets com o namespace hierárquico ativado.

• Tags. Não é recomendável adicionar tags durante a mudança, porque isso causa falha no processo.

• Desative o Anywhere Cache. Embora o Anywhere Cache possa ser ativado durante a etapa de cópia incremental de dados, ele impede a conclusão da etapa de sincronização final.

• Buckets do Appspot. Considere migrar o Container Registry para o Artifact Registry como uma solução alternativa para os buckets padrão criados pelo App Engine.

• Buckets do Firebase. Não é possível realocar intervalos associados ao Firebase.

Restrições operacionais

A mudança de local do bucket com tempo de 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 concluídos 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 realocação.

• Aumento gradual da taxa de solicitação: os intervalos realocados estão sujeitos às mesmas diretrizes de aumento gradual da taxa de solicitação que os intervalos recém-criados.

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

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

• Políticas de retenção: todas as políticas de retenção precisam ser desbloqueadas antes da realocação.

• Buckets do Firebase e do Appspot: a mudança não é compatível com buckets associados ao Firebase ou ao Appspot.

• Atualizações de progresso: as atualizações de progresso da mudança podem não ser lineares.

• Uploads de várias partes: somente uploads de várias partes concluídos são compatíveis durante a realocação de buckets. Uploads de várias partes em andamento não são compatíveis com objetos durante a mudança de local do bucket e precisam ser concluídos ou cancelados antes da mudança de local do bucket. É necessário fazer upload novamente dos objetos sem usar métodos de várias partes. Se você fizer upload de objetos usando uploads de várias partes durante a realocação do bucket, um erro FAILED_PRECONDITION vai ocorrer.

Locais sem suporte

A mudança de local do bucket não é compatível com os buckets de origem e destino nos seguintes locais:

Tipo de local	Locais sem suporte
Regiões	ME-CENTRAL1 ME-WEST1
Birregiões predefinidas	EUR5 EUR7 EUR8

Preços

Para detalhes sobre os preços associados à mudança de local do bucket, consulte Preços do Cloud Storage.

A seguir

• Saiba como planejar uma realocação de bucket.
• Saiba como realocar buckets.