Este documento descreve o serviço de mudança de localização de contentores do Cloud Storage que muda de localização os contentores sem servidor entre localizações geográficas. Com a mudança de localização de contentores, pode mover um contentor existente de uma localização para outra sem alterar o respetivo nome nem exigir a transferência manual de dados no contentor.
Com base nos seus objetivos e na utilização dos depósitos, tem de planear cuidadosamente a mudança de localização dos depósitos para minimizar a interrupção e mudar de localização os depósitos com êxito. Para mais informações sobre como mudar a localização dos contentores, consulte o artigo Mude a localização dos contentores.
Vantagens
Seguem-se as vantagens da mudança de contentor:
Migração simplificada: pode mudar os contentores de localização com custos operacionais mínimos. Não são necessários scripts complexos nem processos de vários passos.
Funcionamento contínuo: as suas aplicações permanecem acessíveis durante todo o processo de mudança, sem tempo de inatividade para operações de leitura e com um tempo de inatividade mínimo para operações de escrita.
Desempenho melhorado: a colocaçã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 mudança de localização do contentor retém os metadados dos objetos. A retenção dos metadados de objetos garante a compatibilidade com as aplicações e os fluxos de trabalho existentes após a mudança do contentor.
Configurações da classe de armazenamento: pode manter as definições existentes da classe do Cloud Storage, incluindo o Autoclass. A preservação da classe de armazenamento garante que a estrutura de custos permanece consistente após a mudança.
Exemplos de utilização
Seguem-se exemplos de utilização que pode alcançar ao mudar os seus contentores:
Reduza o custo de transferência de dados: evite custos de transferência de dados ao mudar o seu contentor para mais perto das cargas de trabalho que acedem aos dados do contentor. Por exemplo, se os seus dados estiverem armazenados nos Estados Unidos e forem acedidos principalmente a partir da Europa, pode mover o seu contentor para uma localização europeia para reduzir os custos de transferência de dados.
Melhore o desempenho: melhore a velocidade e a capacidade de resposta da sua aplicação movendo os dados para mais perto das cargas de trabalho do Compute Engine. Por exemplo, se a sua aplicação for executada no
us-central1, mas os seus dados residirem noasia-east1, pode mudar o seu contentor para ous-central1para reduzir a latência.Melhore a resiliência: salvaguarde os seus dados críticos contra interrupções regionais. Por exemplo, se os seus dados estiverem armazenados numa única região, pode transferi-los para uma região dupla ou multirregião para aumentar a disponibilidade e a recuperação de desastres.
Tipos de mudança de morada
Existem dois tipos de realocações de contentores:
Mudança de localização do contentor com tempo de inatividade de escrita: na mudança de localização do contentor com tempo de inatividade de escrita, existe um período durante o qual não pode realizar operações de escrita de objetos durante o processo de mudança de localização do contentor.
Mudança de localização do contentor sem tempo de inatividade de escrita: na mudança de localização do contentor sem tempo de inatividade de escrita, pode continuar a realizar operações de escrita de objetos sem interrupção enquanto a mudança de localização do contentor ocorre em segundo plano.
As localizações de origem e destino do contentor determinam se a mudança de localização de um contentor envolve tempo de inatividade de gravação. A tabela seguinte mostra como a localização do seu contentor afeta o tempo de inatividade de gravação durante uma mudança de localização, incluindo as diferenças entre mudanças de localização com e sem tempo de inatividade.
| Especificação | Mudança de localização do contentor com tempo de inatividade de gravação | Mudança de localização do contentor sem tempo de inatividade de escrita |
|---|---|---|
| Localização do contentor | A mudança de um contentor entre as seguintes localizações provoca tempo de inatividade:
|
A mudança de um contentor entre as seguintes localizações não causa tempo de inatividade se as duas localizações partilharem o mesmo código de várias regiões:
|
| Escrever disponibilidade | Não pode realizar operações de escrita durante o passo de sincronização final. | As operações de escrita continuam sem interrupções durante a mudança de localização. Nota: as alterações à política sem tempo de inatividade de gravação demoram, pelo menos, sete dias a serem concluídas, porque têm de aguardar que os carregamentos retomáveis em curso terminem primeiro. |
| Participação do utilizador | Tem de iniciar o passo de finalização do tempo de inatividade de gravação. | Não é necessário nenhum passo de finalização explícito. |
| Impacto no desempenho | Não pode escrever nem atualizar objetos no contentor durante o passo de sincronização final. | A latência de leitura e escrita de objetos pode aumentar durante a mudança. |
| Cancelamento da mudança de localização do contentor | Mais rápido do que as mudanças de localização sem tempo de inatividade de escrita. | O cancelamento não é instantâneo e pode demorar mais tempo devido à necessidade de repreencher objetos. |
| Suporte de funcionalidades | Oferece menos suporte de funcionalidades do que as relocações sem tempo de inatividade de escrita. Para mais informações sobre as funcionalidades não suportadas, consulte o artigo Funcionalidades não suportadas. | Existem limitações para funcionalidades como carregamentos multipartes, políticas de retenção, Firebase e appspot. Para mais informações sobre estas limitações, consulte a secção Limitações. |
| Duração mínima da mudança de localização | Nenhum | Sete dias |
Compreenda o processo de mudança de grupo
A mudança de localização do contentor ajuda a mover os seus dados de um contentor de origem para um contentor de destino. O contentor de origem contém os dados que quer mover, e o contentor de destino é onde quer mover os dados.
O diagrama seguinte mostra o fluxo do processo de mudança de localização do contentor:
* A sincronização final só é necessária para realocações com tempo de inatividade de gravação.
A tabela seguinte apresenta os três passos principais e a descrição de cada passo:
| Passo | Descrição |
|---|---|
Faça uma
execução de ensaio | Simula o processo de mudança de localização do contentor para identificar potenciais problemas antes do início da transferência de dados real. |
Copia dados do contentor de origem para o contentor de destino. Os metadados do contentor estão bloqueados para escrita para impedir quaisquer alterações ao contentor que possam afetar o processo de mudança. No entanto, pode escrever, modificar e eliminar objetos no contentor. Os fatores que influenciam a duração são os seguintes:
|
|
Inicie
o passo de sincronização final | Depois de iniciar a sincronização final, o contentor fica bloqueado para escrita. Como resultado, não pode escrever nem atualizar objetos no contentor durante este período, o que evita inconsistências nos dados. No entanto, pode continuar a ler a partir do contentor. Assim que todos os dados forem transferidos, validados e o contentor estiver operacional na nova localização, o bloqueio de escrita é removido automaticamente. Em seguida, pode retomar a escrita e a atualização de objetos no contentor. |
Limitações
O serviço de mudança de localização de contentores suporta até cinco mudanças de localização simultâneas da mesma localização num projeto.
As secções seguintes descrevem as limitações que se aplicam às mudanças de localização com tempo de inatividade de gravação e sem tempo de inatividade de gravação.
Mudança de localização com limitações de tempo de inatividade de gravação
A mudança de localização com tempo de inatividade de gravação tem as limitações indicadas nas secções seguintes.
Limitações de processamento de dados
Seguem-se as limitações ao processar dados durante a mudança:
Falha da tabela: as tabelas externas do BigLake e as tabelas do BigQuery que usam o Apache Iceberg vão falhar e requerem recriação manual. A deteção automática de tabelas afetadas está indisponível.
Processamento de objetos da Autoclass: a Autoclass usa padrões de acesso para determinar quando deve fazer a transição dos objetos para classes de armazenamento mais frias. Durante a sincronização final do processo de mudança de localização do contentor, o Autoclass é pausado e os objetos não são transferidos para classes de armazenamento mais frias. Quando a sincronização final estiver concluída, o Autoclass é retomado.
Os objetos numa classe de armazenamento Standard são processados da seguinte forma:
- 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 mudança de localização, é tratado como se tivesse sido acedido. Como resultado, o processo de mudança repõe o período sem acesso e, mesmo que um objeto estivesse prestes a ser transitado para o armazenamento Nearline antes da mudança, tem de aguardar mais 30 dias após a conclusão da mudança.
Os objetos numa classe de armazenamento não padrão são processados da seguinte forma:
A mudança de localização de objetos nas classes de armazenamento Nearline storage, Coldline storage ou Archive storage não conta como acesso aos mesmos. Como resultado, o período sem acesso para estes objetos não é afetado.
Quando muda um contentor de localização, se aceder frequentemente a objetos em contentores com uma classe de armazenamento não padrão, como o Nearline Storage, o Coldline Storage ou o Archive Storage, o contentor não transita automaticamente para uma classe de armazenamento mais quente. Por exemplo, o contentor não transita automaticamente do armazenamento de arquivo para o armazenamento Coldline nem do armazenamento Coldline para um armazenamento padrão, mesmo que os objetos sejam acedidos com frequência. Este comportamento impede as transições automáticas da classe de armazenamento durante a mudança de localização.
Se um objeto tiver sido agendado para transição para uma classe de armazenamento mais fria, como do Nearline Storage para o Coldline Storage, o processo de mudança de localização não interfere com o agendamento. A transição prossegue conforme planeado após a conclusão da mudança.
Limite de tamanho do objeto: aplica-se um limite de 2 TB aos tamanhos dos objetos para a mudança de localização.
Carregamentos em várias partes
Os carregamentos multipartes não são suportados para a mudança de localização de contentores com tempo de inatividade de escrita, independentemente do respetivo estado, quer tenham sido concluídos, estejam em curso ou tenham sido iniciados durante a mudança de localização. Se tiver concluído carregamentos multipartes no contentor que quer mudar de localização, tem de voltar a carregar os objetos sem usar métodos multipartes e eliminar os carregamentos multipartes. Caso contrário, a mudança de localização falha. Se carregar objetos
usando carregamentos multipartes durante a mudança de localização do contentor com tempo de inatividade de escrita,
ocorre um erro FAILED_PRECONDITION.
Funcionalidades não suportadas
Não é possível mudar a localização dos contentores que usam as seguintes funcionalidades:
Chaves de encriptação geridas pelo cliente (CMEK) ou chaves de encriptação fornecidas pelo cliente (CSEK).
Políticas de retenção bloqueadas.
Objetos com retenções temporárias.
Recipientes com o espaço de nomes hierárquico ativado.
Etiquetas. Não recomendamos a adição de etiquetas durante a mudança, uma vez que faz com que o processo de mudança falhe.
Anywhere Cache. Embora a cache em qualquer lugar possa ser ativada durante o passo de cópia de dados incremental, impede a conclusão do passo de sincronização final.
Contentores do Appspot. Pondere migrar o Container Registry para o Artifact Registry como solução alternativa para os contentores predefinidos criados pelo App Engine.
Recipientes do Firebase. Não é possível mudar a localização dos contentores associados ao Firebase.
Restrições operacionais
A mudança de localização do contentor com tempo de inatividade de gravação tem as seguintes restrições operacionais:
Restrição do projeto: não pode mudar a localização de contentores entre projetos.
Carregamentos retomáveis: os carregamentos retomáveis em curso têm de ser finalizados antes do passo de sincronização final para evitar a perda de dados.
Atualizações de metadados: não pode atualizar os metadados de um contentor durante a mudança de localização.
Aumente a taxa de pedidos: os contentores realocados estão sujeitos às mesmas diretrizes de aumento da taxa de pedidos que os contentores criados recentemente.
Relocação sem limitações de período de descanso de escrita
A mudança de localização do contentor sem tempo de inatividade de gravação tem as seguintes limitações:
Políticas de retenção: todas as políticas de retenção têm de ser desbloqueadas antes da relocação.
Recipientes do Firebase e Appspot: a mudança não é suportada para recipientes associados ao Firebase ou ao Appspot.
Atualizações de progresso: as atualizações de progresso da mudança podem não ser lineares.
Carregamentos multipartes: apenas os carregamentos multipartes concluídos são suportados durante a mudança de localização do contentor. Os carregamentos multipartes em curso não são suportados para objetos durante a mudança de localização do contentor e têm de ser concluídos ou cancelados antes da mudança de localização do contentor. Tem de voltar a carregar os objetos sem usar métodos multipartes. Se carregar objetos através de carregamentos multipartes durante a mudança de localização do contentor, ocorre um erro
FAILED_PRECONDITION.
Localizações não suportadas
A mudança de contentores não é suportada para os contentores de origem e de destino nas seguintes localizações:
| Tipo de localização | Localizações não suportadas |
|---|---|
| Regiões |
|
Preços
Para ver detalhes sobre os preços associados à mudança de localização de contentores, consulte os preços do Cloud Storage.
O que se segue?
- Saiba como planear a mudança de um contentor.
- Saiba como mudar os contentores de localização.