Planejar a realocação do bucket

Para realocar buckets, defina seus objetivos e entenda o seu uso do bucket antes de iniciar uma realocação de bucket. As seções a seguir descrevem as principais 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 de sincronização final em que não é possível atualizar ou fazer upload de novos objetos. Além disso, não é possível mudar a configuração do bucket durante o processo de realocação. Para determinar se a sua 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 oferecem suporte à realocação de buckets e as configurações que exigem ação para oferecer suporte à realocação de buckets. Se o bucket usar configurações não compatíveis que não podem ser modificadas ou se a origem ou o destino for um local não compatível, você deve 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 do bucket
Namespace hierárquico Indisponível para realocações de buckets 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 Indisponí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 Indisponível. Não é possível realocar buckets do Firebase.
Retenções de objetos Indisponível.
Não é possível realocar buckets que contenham objetos com retenções.
Para usar a realocação de buckets, remova as retenções de objetos.
Pastas gerenciadas Indisponível.
Não é possível realocar buckets que contenham pastas gerenciadas.
Para usar a realocação de buckets, exclua as pastas gerenciadas.
Chaves de criptografia gerenciadas pelo cliente (CMEK) ou chaves de criptografia fornecidas pelo cliente (CSEK) Indisponível para realocações com inatividade de gravação. Para usar a realocação de buckets, 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 Há suporte para realocações de buckets sem inatividade de gravação e suporte parcial para realocações de buckets com inatividade de gravação. Para realocar buckets com inatividade de gravação, desative o Rapid Cache antes da etapa de sincronização final.
Bloqueio de buckets Indisponível quando as políticas de retenção estão bloqueadas. Desbloqueie as políticas de retenção.
Tags Indisponível para realocações com inatividade de gravação.

É necessário desanexar as tags que estão anexadas diretamente ao bucket.

Se alguma das tags que estão sendo desanexadas 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 fazer isso, siga estas etapas:

  1. Copie a configuração de tags para consultar ao configurar os papéis do IAM. Depois de verificar as configurações do IAM, você poderá excluir a cópia.
  2. Configure as permissões do IAM para corresponder às regras de controle de acesso atuais.
  3. Desanexe as tags atuais do bucket de origem.
Configurações de relatórios de inventário As configurações de relatórios de inventário atuais não são preservadas durante o processo de realocação. Salve as configurações de relatórios de inventário atuais manualmente antes de iniciar o processo de realocação para que você possa recriá-las após a conclusão do processo de realocação. 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 ao realocar um bucket. O comportamento pode variar dependendo do 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 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 exigem recriação manual. A detecção automática de tabelas afetadas não está disponível. Há suporte.
Limite de tamanho do objeto O limite de 2 TB se aplica aos tamanhos de 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 ao iniciar uma realocação de bucket:
  • Novos uploads de várias partes: indisponível.
    Iniciar um upload de várias partes após o início da realocação não é compatível, o que leva a uma falha ao iniciar o upload. A tentativa de upload de várias partes falha com um erro FAILED_PRECONDITION.
  • Uploads de várias partes em andamento:indisponível.
    Os uploads de várias partes em andamento que não são concluídos antes da etapa de sincronização final bloqueiam a finalização da realocação. Depois de concluir ou cancelar o upload de várias partes em andamento, você poderá tentar novamente a etapa de finalização.
  • Uploads de várias partes concluídos:há suporte.
    Se um upload de várias partes for iniciado antes do início da realocação do bucket e concluído antes da etapa de sincronização final, os objetos enviados serão realocados sem exigir um novo upload.
A compatibilidade e o comportamento dos uploads de várias partes dependem do status do upload ao iniciar uma realocação de bucket:
  • Novos uploads de várias partes: indisponível.
    Iniciar um upload de várias partes após o início da realocação não é compatível, o que leva a uma falha ao iniciar o upload. A tentativa de upload de várias partes falha com um erro FAILED_PRECONDITION.
  • Uploads de várias partes em andamento:indisponível.
    É necessário concluir ou cancelar todos os uploads de várias partes em andamento antes de iniciar a realocação do bucket.
  • Uploads de várias partes concluídos:há suporte.
Uploads recuperáveis Indisponível.
Os uploads recuperáveis em andamento precisam ser finalizados antes da etapa de sincronização final do processo de realocação do bucket para evitar a perda de dados.
Há suporte.
Realocação entre projetos Indisponível.
Não é possível realocar buckets entre projetos.
Há suporte.
Atualizações de metadados Indisponível.
Não é possível atualizar os metadados de um bucket durante realocação.
Há suporte.
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 do 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: a replicação do 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 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 quão ocupado o bucket está, 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 registros de armazenamento.

  • Operações de gravação de bucket: operações de gravação de bucket frequentes 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 movimentos 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.

Definir metas de realocação

Com base na análise das características do bucket, identifique os motivos para mover o bucket. A seguir, confira as metas comuns para realocar um bucket:

  • Gerenciamento de custos: reduza os custos de armazenamento movendo para uma região de custo mais baixo ou minimize os custos de transferência de dados movendo os dados para mais perto do local de acesso. É necessário calcular os custos de transferência de dados e do Cloud Storage e compará-los aos custos potenciais em locais diferentes. Para mais detalhes sobre como calcular os custos do Cloud Storage, consulte Preços do Cloud Storage.

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

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

Decidir sobre o local do bucket

Com base na análise e nas metas, escolha o local de armazenamento mais adequado para o bucket que você está realocando nas 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 mais alto nível 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 entendê-los pode ajudar a estimar o tempo necessário. Embora esses fatores ofereçam um ponto de partida útil para planejar e programar a realocação, os tempos de realocação reais podem ser maiores ou menores do que o tempo estimado. Portanto, ao programar a realocação, adicione um tempo de buffer 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 taxa de solicitação alta acelera a migração. Se você tiver apenas alguns arquivos grandes, esse fator terá menos impacto.

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

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

Largura de banda máxima por objeto único

8 MBps Essa é a velocidade máxima em que é possível transferir um único objeto.

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

Número máximo de realocações simultâneas por projeto

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

Limite de time to live (TTL) da realocação

Para ajudar no uso de recursos e evitar que as realocações sejam executadas indefinidamente, um limite de tempo de vida (TTL, na sigla em inglês) se aplica a todas as realocações de buckets. O TTL se refere 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 falhará.

Atividade contínua do 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 aumentarão 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

A realocação de buckets exige que você ative a exclusão reversível no bucket e defina a duração da retenção para pelo menos sete dias. A duração da retenção é o período de tempo em que a exclusão reversível mantém os objetos excluídos antes de excluí-los permanentemente. Para informações sobre como configurar a duração da retenção da exclusão reversível, consulte Usar a exclusão reversível.

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