Planejar a realocação do bucket

Antes de realocar um bucket, verifique o uso dele e planeje possíveis períodos de inatividade. Planejar a realocação também ajuda a manter a compatibilidade dos dados e controlar os custos de armazenamento.

As seções a seguir descrevem as etapas de planejamento.

Determinar o tipo de realocação de bucket

Ao realocar o bucket, é importante entender que pode haver um período de inatividade de gravação durante a etapa final de sincronização, em que não é possível atualizar ou fazer upload de novos objetos. Além disso, não será possível mudar a configuração do bucket durante o processo de realocação. Para determinar se a realocação envolve inatividade, consulte Tipos de realocação.

Analisar os recursos não compatíveis e os requisitos de compatibilidade

Identifique as configurações no bucket de origem que não são compatíveis com a realocação de bucket e as configurações que exigem ação para serem compatíveis com a realocação de bucket. Se o bucket usar configurações incompatíveis que não podem ser modificadas ou se a origem ou o destino for um local incompatível, você precisará copiar manualmente os objetos para um bucket diferente no local de destino, em vez de realocar o bucket com os objetos. Para mais detalhes, consulte Mover dados entre buckets.

As seções a seguir descrevem os recursos não compatíveis e os requisitos de compatibilidade.

Recursos não suportados

A tabela a seguir descreve os recursos que não são compatíveis com a realocação de buckets. Em alguns casos, é possível reconfigurar um recurso para oferecer suporte à realocação de buckets:

Recurso Status de compatibilidade Ação necessária antes de iniciar a realocação de bucket
Namespace hierárquico Não há suporte para realocações de bucket com inatividade de gravação. Se um bucket tiver o namespace hierárquico ativado, só será possível realocá-lo se o processo não envolver inatividade de gravação.
Buckets do Appspot Incompatível. Não é possível realocar buckets do Appspot. Considere migrar o Container Registry para o Artifact Registry como uma solução alternativa para buckets padrão criados pelo App Engine.
Buckets do Firebase Incompatível. Não é possível realocar buckets do Firebase.
Retenções de objetos Incompatível.
Não é possível realocar buckets que contêm objetos com retenções.
Para usar a realocação de bucket, remova as retenções de objeto.
Pastas gerenciadas Incompatível.
Não é possível realocar buckets que contêm pastas gerenciadas.
Para usar a realocação de bucket, exclua as pastas gerenciadas.
Chaves de criptografia gerenciadas pelo cliente (CMEK) ou chaves de criptografia fornecidas pelo cliente (CSEK) Não há suporte para realocações com inatividade de gravação. Para usar a realocação de bucket, remova as chaves de criptografia gerenciadas pelo cliente ou as chaves de criptografia fornecidas pelo cliente. Após a remoção, o Cloud Storage protege automaticamente seus dados usando a criptografia padrão do Cloud Storage.
Rapid Cache Não há suporte para realocações de bucket sem inatividade de gravação, e há suporte parcial para realocações de bucket com inatividade de gravação. Para realocar buckets sem inatividade de gravação, desative o Rapid Cache antes de iniciar a realocação. Para realocar buckets com inatividade de gravação, desative o Rapid Cache antes da etapa de sincronização final.
Bloqueio de bucket Não há suporte para buckets com uma política de retenção ativa. Se a política de retenção estiver bloqueada (o Bloqueio de Bucket está ativado), ela será irreversível. Por isso, o Cloud Storage não permite realocar o bucket. Se a política de retenção estiver desbloqueada, remova-a antes de prosseguir com a realocação.
Bloqueio de retenção de objetos Incompatível. Depois que o Bloqueio de Retenção de Objetos é ativado, não é possível desativá-lo. Não é possível realocar buckets que têm o Bloqueio de Retenção de Objetos ativado.
Tags Não há suporte para realocações com inatividade de gravação.

É preciso remover as tags que estão anexadas diretamente ao bucket.

Se alguma das tags que estão sendo removidas do bucket de origem for usada para controle de acesso, use um método alternativo para configurar os papéis do IAM para proteger os dados no bucket. Para isso, siga estas etapas:

  1. Copie a configuração da tag para consultar enquanto configura os papéis do IAM. Depois de verificar as configurações do IAM, você pode excluir a cópia.
  2. Configure as permissões do IAM para corresponder às regras de controle de acesso atuais.
  3. Remova as tags do bucket de origem.
Configurações do relatório de inventário As configurações atuais do relatório de inventário não são preservadas durante o processo de realocação. Salve as configurações de relatório de inventário atuais manualmente antes de iniciar o processo de realocação para que seja possível recriá-las após a conclusão do processo. Para informações sobre como gerenciar configurações de relatórios de inventário, consulte Criar e gerenciar configurações de relatórios de inventário.

Compatibilidade de recursos durante a realocação de buckets

A tabela a seguir descreve como outros recursos do Cloud Storage funcionam quando você realoca um bucket. O comportamento pode variar de acordo com o modo de realocação:

Recurso Realocação com inatividade de gravação Realocação sem inatividade de gravação
Comportamento da classe automática A classe automática é pausada temporariamente durante a etapa de sincronização final. A pausa pode atrasar a movimentação de objetos para classes de armazenamento de acesso mais raro. Para mais detalhes, consulte Transições de objetos da classe automática ao realocar buckets. O comportamento da classe automática não é afetado.
Tabelas do BigQuery e do BigLake As tabelas externas do BigLake e as tabelas do BigQuery que usam o Apache Iceberg ficam inacessíveis após uma realocação e precisam ser recriadas manualmente. A detecção automática de tabelas afetadas não está disponível. Compatível.
Limite de tamanho do objeto O limite de 2 TB se aplica aos tamanhos dos objetos. Sem limite de tamanho.
Uploads de várias partes A compatibilidade e o comportamento dos uploads de várias partes dependem do status do upload quando você inicia uma realocação de bucket:
  • Novos uploads de várias partes: não compatível.
    Não é possível iniciar um upload em várias partes depois que a realocação é iniciada, o que resulta em uma falha ao iniciar o upload. A tentativa de upload em várias partes falha com um erro FAILED_PRECONDITION.
  • Uploads em várias partes em andamento:não são compatíveis.
    Os uploads em várias partes em andamento que não forem concluídos antes da etapa de sincronização final vão bloquear a finalização da realocação. Depois de concluir ou cancelar o upload em várias partes em andamento, tente novamente a etapa de finalização.
  • Uploads de várias partes concluídos:compatível.
    Se um upload de várias partes for iniciado antes da realocação de bucket e concluído antes da etapa de sincronização final, os objetos enviados serão realocados sem precisar de um novo upload.
A compatibilidade e o comportamento dos uploads em várias partes dependem do status do upload quando você inicia uma realocação de bucket:
  • Novos uploads de várias partes: não compatível.
    Não é possível iniciar um upload em diversas partes depois que a realocação é iniciada, o que resulta em uma falha ao iniciar o upload. A tentativa de upload em várias partes falha com um erro FAILED_PRECONDITION.
  • Uploads em várias partes em andamento:não são compatíveis.
    É preciso concluir ou cancelar todos os uploads em várias partes em andamento antes de iniciar a realocação do bucket.
  • Uploads de várias partes concluídos:compatível.
Uploads retomáveis Incompatível.
Os uploads retomáveis em andamento precisam ser finalizados antes da etapa de sincronização final do processo de realocação de bucket para evitar a perda de dados.
Compatível.
Realocação entre projetos Incompatível.
Não é possível realocar buckets entre projetos.
Compatível.
Atualizações de metadados Incompatível.
Não é possível atualizar os metadados de um bucket durante a realocação.
Compatível.
Aumento da taxa de solicitação Os buckets realocados estão sujeitos às mesmas diretrizes de aumento da taxa de solicitação que os buckets recém-criados. Não relevante.

Analisar as características do bucket

Para estimar o tempo de realocação de bucket, analise as características e o uso dele, considerando os seguintes fatores:

  • Bytes em repouso: a quantidade total de dados armazenados no bucket afeta os custos de armazenamento e o tempo de transferência.

  • Replicação: replicar o bucket para outras regiões, de forma síncrona ou assíncrona, afeta a disponibilidade, a durabilidade e o custo dos dados. Para mais detalhes, consulte Disponibilidade e durabilidade dos dados.

  • Transferência de dados: a quantidade de dados transferidos para fora do bucket durante a realocação afeta os cálculos de custo de transferência de dados. Para calcular os custos de transferência de dados do bucket, consulte Preços do Cloud Storage.

  • Padrões de uso: entender os níveis de atividade do bucket ou o nível de ocupação dele por meio de padrões de uso ajuda a evitar conflitos inesperados durante a realocação. Para entender os padrões de uso do bucket, analise os registros. Para mais detalhes, consulte Registros de uso e de armazenamento.

  • Operações de gravação de bucket: operações frequentes de gravação de bucket durante o processo de realocação aumentam o custo e a duração. O progresso da realocação é não linear e imprevisível. Não use a duração de migrações menores para estimar o tempo necessário para realocações maiores. Para monitorar a frequência com que os objetos são gravados no bucket, consulte Visão geral do monitoramento no Cloud Storage.

Defina suas metas de realocação

Com base na análise das características do bucket, identifique os motivos para movê-lo. Estes são os objetivos comuns para realocar um bucket:

  • Gerenciamento de custos: reduza os custos de armazenamento migrando para uma região mais barata ou minimize os custos de transferência de dados aproximando os dados do local de acesso. Você precisará calcular os custos do Cloud Storage e de transferência de dados e compará-los com os custos em diferentes locais. Para detalhes sobre como calcular os custos do Cloud Storage, consulte Preços do Cloud Storage.

  • Melhoria de desempenho: melhore a velocidade de acesso aos dados e o desempenho do aplicativo ao realocar o bucket para mais perto dos usuários ou aplicativos. Para isso, identifique as regiões geográficas em que o desempenho é crítico e realoque os buckets.

  • Melhoria da confiabilidade: aumente a durabilidade dos dados e os recursos de recuperação de desastres usando configurações birregionais ou multirregionais.

Decidir o local do bucket

Com base na sua análise e nas suas metas, escolha o local de armazenamento mais adequado para o bucket que você está realocando entre as seguintes opções:

  • Região única: armazene dados em uma única região que seja econômica para aplicativos com usuários concentrados em uma área geográfica.

  • Birregional: mantenha duas cópias dos dados em duas regiões no mesmo continente, oferecendo maior disponibilidade e recursos de recuperação de desastres em uma área geográfica específica.

  • Multirregional: distribua dados em várias regiões, oferecendo o nível mais alto de disponibilidade e durabilidade.

Para saber mais sobre como escolher um local, consulte Considerações para escolher um local.

Entender os fatores que afetam o tempo de realocação

Vários fatores afetam o tempo de realocação, e entender esses fatores pode ajudar a estimar o tempo necessário. Embora esses fatores ofereçam um ponto de partida útil para planejar e programar sua realocação, os tempos reais de realocação podem ser mais longos ou mais curtos do que o tempo estimado. Portanto, ao programar a realocação, adicione um tempo de intervalo para considerar possíveis atrasos. As seções a seguir descrevem os fatores que afetam o tempo de realocação.

Limites do serviço de realocação

A tabela a seguir descreve os limites que afetam o tempo de realocação:

Fator Valor Descrição
Taxa máxima de solicitações por job 10.000 objetos por segundo Esse é o número de solicitações de cópia que o serviço pode processar por segundo.

Uma taxa de solicitação mais alta significa que mais arquivos podem ser movidos simultaneamente. Se o bucket tiver muitos arquivos pequenos, uma alta taxa de solicitação vai acelerar a migração. Se você tiver apenas alguns arquivos grandes, esse fator terá menos impacto.

Largura de banda geral máxima por projeto 10 GBps Essa é a velocidade ou largura de banda máxima para transferir dados de um único projeto em um local de origem. Se você estiver movendo vários buckets no mesmo projeto, eles vão compartilhar a largura de banda.

Uma largura de banda maior significa que mais dados podem ser transferidos de uma só vez. Mesmo com uma alta taxa de solicitação, se a largura de banda for pequena, a transferência geral será lenta.

Largura de banda máxima por objeto

8 MBps Essa é a velocidade máxima em que você pode transferir um único objeto.

Uma largura de banda maior por objeto significa que é possível transferir os objetos em uma taxa mais rápida. Esse é o limite de velocidade para mover um objeto por vez. Mesmo com uma alta taxa de solicitação e uma alta largura de banda por bucket, se os objetos individuais tiverem um limite de velocidade, eles poderão levar mais tempo para serem transferidos.

Máximo de realocações simultâneas por projeto

30 realocações O serviço de realocação de bucket aceita até 30 realocações simultâneas do mesmo local em um projeto.

Limite de time to live da realocação

Para ajudar na utilização de recursos e evitar que as realocações sejam executadas indefinidamente, um limite de tempo de vida (TTL) se aplica a todas as realocações de bucket. TTL refere-se ao tempo máximo permitido para que todo o processo de realocação seja concluído.

O tempo máximo permitido para concluir uma realocação de bucket é de 28 dias e inclui todas as fases do processo de realocação, como a cópia inicial, as atualizações incrementais e a sincronização final.

Se o processo de realocação exceder o limite de TTL de 28 dias, a operação de realocação vai falhar.

Atividade em andamento no bucket

Se você continuar gravando novos objetos, excluindo os atuais ou atualizando objetos no bucket durante a realocação, essas operações vão competir por recursos com as solicitações de cópia e poderão desacelerar o processo de realocação.

Regras de ciclo de vida

Se você tiver regras de ciclo de vida configuradas para o bucket, como excluir ou arquivar objetos automaticamente após um período específico, essas ações vão aumentar o tempo geral de realocação.

Configurar o Storage Intelligence

É necessário configurar o Storage Intelligence para os locais de origem e destino. É possível configurar o Storage Intelligence em diferentes níveis da hierarquia de recursos do Google Cloud. Também é possível usar filtros de inclusão e exclusão para incluir buckets relevantes na configuração do Storage Intelligence. Para mais detalhes, consulte Configurar o Storage Intelligence.

Ativar a exclusão reversível para realocações com inatividade de gravação

Se a realocação de bucket envolver tempo de inatividade de gravação, ative a exclusão reversível no bucket e defina a duração da retenção como pelo menos sete dias. A duração da retenção é o período em que a exclusão reversível mantém os objetos excluídos antes de excluí-los permanentemente. Para saber como configurar a duração da retenção da exclusão reversível, consulte Usar a exclusão reversível. Para determinar se a realocação envolve inatividade, consulte Tipos de realocação.

Verificar cotas e limites

As cotas e as avaliações de capacidade da nuvem estão vinculadas a regiões ou zonas específicas. Como resultado, ao mover um bucket para um novo local, é necessário verificar se o novo local tem cotas suficientes para acomodar os dados do bucket. Para mais informações sobre o assunto, consulte Cotas e limites.

A seguir