Para realocar buckets com sucesso, defina seus objetivos e entenda o 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 do bucket
Ao realocar seu 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 tempo de inatividade, consulte Tipos de realocação.
Confira 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 bucket e as configurações que exigem ação para oferecer suporte a ela. 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ê 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 sem suporte 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 mudança de local do bucket |
|---|---|---|
| Namespace hierárquico | Não é compatível com realocações de buckets com tempo de 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 tempo de inatividade de gravação. |
| Buckets do Appspot | Incompatível. | Não é possível mudar os buckets do Appspot de lugar. 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 | Incompatível. | Não é possível mudar os buckets do Firebase de lugar. |
| 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 buckets, remova as retenções de objetos. |
| Pastas gerenciadas | Incompatível. Não é possível realocar buckets que contêm 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) | Não é possível usar em realocações com tempo de inatividade de gravação. | Para usar a realocação de buckets, remova as chaves de criptografia gerenciadas ou fornecidas pelo cliente. Após a remoção, o Cloud Storage protege automaticamente seus dados usando a criptografia padrão do Cloud Storage. |
| Anywhere Cache | Compatível com realocações de bucket sem inatividade de gravação e parcialmente compatível com realocações de bucket com inatividade de gravação. | Para realocar buckets com tempo de inatividade de gravação, desative o Anywhere Cache antes da etapa de sincronização final. |
| Bloqueio de bucket | Não é compatível quando as políticas de retenção estão bloqueadas. | Desbloqueie as políticas de retenção. |
| Tags | Não é possível usar em realocações com tempo de inatividade de gravação. |
É necessário desanexar as tags que estão anexadas diretamente ao bucket. Se alguma das tags desvinculadas do bucket de origem for usada para controle de acesso, use um método alternativo para configurar as funções do IAM e proteger os dados no bucket. Para fazer isso, siga estas etapas:
|
| Configurações de 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 manualmente as configurações de relatório de inventário atuais antes de iniciar o processo de realocação para poder recriá-las depois que ele for concluído. 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 outras funcionalidades 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 Autoclass é pausada temporariamente durante a etapa final de sincronização. A pausa pode atrasar a movimentação de objetos para classes de armazenamento de acesso raro. Para 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:
|
A compatibilidade e o comportamento dos uploads de várias partes dependem do status do upload quando você inicia uma realocação de bucket:
|
| Uploads recuperáveis | Incompatível. Os uploads retomá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. |
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 gradual 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 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 seu bucket, consulte Preços do Cloud Storage.
Padrões de uso: entender os níveis de atividade do bucket ou o quanto ele está ocupado com 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 buckets: operações frequentes de gravação de buckets durante o processo de realocação aumentam o custo e a duração. Para entender com que frequência os objetos estão sendo gravados no seu bucket, consulte Visão geral do monitoramento no Cloud Storage.
Defina suas metas de mudança
Com base na sua análise das características do bucket, identifique os motivos para movê-lo. Confira a seguir alguns objetivos comuns para realocar um bucket:
Gerenciamento de custos: reduza os custos de armazenamento movendo para uma região de menor custo ou minimize os custos de transferência de dados movendo os dados para mais perto do local de acesso. Você precisará calcular os custos do Cloud Storage e da transferência de dados e compará-los aos custos potenciais em locais diferentes. Para detalhes sobre como calcular os custos do Cloud Storage, consulte Preços do Cloud Storage.
Melhoria de performance: aumente a velocidade de acesso aos dados e a performance do aplicativo ao realocar o bucket mais perto dos usuários ou aplicativos. Para isso, identifique as regiões geográficas em que a performance é crítica e realoque seus 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.
Região dupla: mantenha duas cópias dos seus 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: distribui 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 mudança
Vários fatores afetam o tempo de mudança, 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 mudança, os tempos reais podem ser maiores ou menores do que o estimado. Portanto, ao agendar sua mudança, adicione um tempo extra para possíveis atrasos. As seções a seguir descrevem os fatores que afetam o tempo de realocação.
Limites do serviço de recolocação
A tabela a seguir descreve os limites que afetam o tempo de mudança:
| Fator | Valor | Descrição |
|---|---|---|
| Taxa máxima de solicitações por job | 10.000 objetos por segundo |
É 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 máxima geral por projeto | 10 GBps |
Essa é a velocidade ou largura de banda máxima em que você pode transferir dados para 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 único | 8 MBps |
Essa é a velocidade máxima em que você pode transferir um único objeto.
Uma largura de banda maior por objeto significa que você pode 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 e uma largura de banda altas 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 mudança de local de buckets aceita até 30 mudanças simultâneas do mesmo local em um projeto. |
Limite de time to live de realocação
Para ajudar no uso de recursos e evitar que as realocações sejam executadas indefinidamente, um limite de Time to Live (TTL) se aplica a todas as realocações de bucket. TTL refere-se ao tempo máximo permitido para a conclusão de todo o processo de realocação.
O tempo máximo permitido para concluir uma realocação de bucket é de 28 dias e inclui todas as fases do processo, como cópia inicial, atualizações incrementais e sincronização final.
Se o processo de mudança exceder o limite de TTL de 28 dias, a operação de mudança vai falhar.
Atividade em andamento no bucket
Se você continuar gravando novos objetos, excluindo os atuais ou atualizando objetos no bucket durante a movimentação, essas operações vão disputar recursos com as solicitações de cópia e poderão diminuir a velocidade do processo.
Regras de ciclo de vida
Se você tiver regras de ciclo de vida configuradas para seu bucket, como exclusão ou arquivamento automático de objetos 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 da Storage Intelligence. Para mais detalhes, consulte Configurar a inteligência de armazenamento.
Ativar a exclusão reversível
Para relocar um bucket, é necessário ativar a exclusão reversível no bucket e definir 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 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. Por isso, ao mover um bucket para um novo local, verifique se ele tem cotas suficientes para acomodar os dados do bucket. Para mais informações sobre cotas e limites, consulte Cotas e limites.
A seguir
- Saiba como realocar buckets.