Métodos de rede

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Visão geral

Para criar uma migração no Database Migration Service, é preciso estabelecer conectividade entre a instância de origem e a de destino do AlloyDB. Há vários métodos compatíveis. Escolha a opção que funciona melhor para a carga de trabalho específica.

Método de rede	Descrição	Vantagens	Desvantagens
Lista de permissões de IP	Esse método funciona configurando o servidor de banco de dados de origem para aceitar conexões do IP de saída da instância do Cloud SQL. Se você escolher esse método, o Database Migration Service vai orientar você pelo processo de configuração durante a criação da migração.	Fácil de configurar. Não requer nenhuma configuração personalizada de firewall.	O tráfego de rede ocorre pela Internet pública. Menos seguro. Desempenho reduzido.
Proxy por VM hospedada na nuvem: túnel SSH reverso	Estabelece a conectividade do destino com a origem por um túnel SSH reverso seguro. Exige uma VM Bastion Host no projeto da plataforma Google Cloud , bem como uma máquina (por exemplo, um laptop na rede) com conectividade à origem. O Database Migration Service coleta as informações necessárias no momento da criação da migração e gera automaticamente o script para configurar tudo.	Fácil de configurar. Não requer nenhuma configuração personalizada de firewall. Recomendado para cenários de migração de curta duração (POC ou migrações de banco de dados pequenos).	A VM bastion é de sua propriedade e gerenciamento, e pode gerar custos adicionais.
Proxy por VM hospedada na nuvem: TCP	Estabelece a conectividade do destino à origem usando um proxy TCP por uma VM hospedada na nuvem. O Database Migration Service coleta as informações necessárias no momento da criação da migração e gera automaticamente o script para configurar tudo. Relevante em migrações do AlloyDB em que a origem está na arquitetura de rede antiga.	Fácil de configurar. Não requer nenhuma configuração personalizada de firewall.	A VM bastion é de sua propriedade e gerenciamento, e pode gerar custos adicionais.
Peering de VPC	Esse método funciona configurando as VPCs para se comunicarem entre si.	Solução Google Cloud nativa. Fácil de configurar. Alta largura de banda. Recomendado para migrações de longa duração ou de alto volume.	Aplicável se os bancos de dados de origem e destino estiverem hospedados em Google Cloudou se a origem estiver conectada à VPC de destino usando uma VPN (hospedada na nuvem ou local) ou o Cloud Interconnect.
Interfaces do Private Service Connect	As interfaces do Private Service Connect permitem que sua instância de destino do AlloyDB para PostgreSQL inicie conexões com o IP particular do banco de dados de origem sem consumir a cota de peering. Em vez disso, esse método de conectividade usa anexos de rede criados na VPC.	Estabelece conexões com seu IP particular de origem usando um anexo de rede. Esse método não consome a cota de peering na sua VPC. O método mais fácil de configurar a conectividade particular de origem.	Esse método de conectividade só está disponível quando você migra para uma instância atual. Requer a configuração de um anexo de rede e o ajuste das regras de firewall. Não é possível modificar o anexo de rede depois de estabelecer a conexão. Para mais informações sobre o acesso a serviços particulares e o Private Service Connect no AlloyDB para PostgreSQL, consulte Visão geral do IP particular na documentação do AlloyDB para PostgreSQL.

Limitações de conectividade

A conectividade do PostgreSQL com o AlloyDB tem as seguintes limitações:

• O AlloyDB oferece suporte à conectividade particular usando o acesso a serviços particulares. Não é possível atribuir um endereço IP público a um cluster.
• Não é possível mudar a VPC com que o cluster do AlloyDB tem peering depois que ele é criado.
• Como o AlloyDB usa o acesso a serviços particulares, que internamente usa o peering de VPC, o peering transitivo não é compatível. Seu cluster do AlloyDB só pode alcançar endereços IP internos na mesma VPC em que está pareado. Para acessar outras VPCs, use um proxy intermediário. Confira mais detalhes na seção a seguir.

Cenários e soluções comuns de conectividade

Migrar de uma instância do Cloud SQL na arquitetura de rede antiga do produtor

Figura 1. Uma conexão particular facilitada pela VM de proxy TCP (clique para ampliar)

Para migrar de uma instância do Cloud SQL para PostgreSQL na arquitetura de rede do produtor antiga, é necessário estabelecer conectividade usando um proxy intermediário. Isso acontece porque não é possível ter conectividade direta entre a instância de origem do Cloud SQL e o destino do AlloyDB. É possível configurar sua própria solução de proxy, mas recomendamos configurar a VM de proxy TCP com o script gerado automaticamente fornecido pelo Database Migration Service. Consulte Método de conectividade do proxy TCP.

Migrar de uma origem no mesmo projeto Google Cloud , mas em uma VPC diferente

Como não é possível mudar a VPC em que o cluster do AlloyDB reside depois que ele é criado, você tem as seguintes opções:

• A opção recomendada é mudar a VPC da instância de origem para corresponder à VPC da instância de destino. Por exemplo, se você quiser migrar uma instância do Cloud SQL para o AlloyDB, atualize a VPC do Cloud SQL para corresponder à VPC do AlloyDB.

  Atenção: configurar um endereço IP privado para uma instância do Cloud SQL faz com que ela seja reiniciada, resultando em tempo de inatividade.

• Se não for possível mudar a VPC da instância de origem para corresponder à VPC da instância de destino, use uma máquina virtual (VM) intermediária como proxy. É possível configurar sua própria solução de proxy, mas recomendamos usar o método de conectividade de proxy TCP. Depois que o Database Migration Service gerar o script no console Google Cloud , adicione outra interface de rede ao comando para criar uma instância de proxy TCP e configure-a para corresponder à VPC da instância de origem. Assim, o proxy tem conectividade com as VPCs de origem e destino.

  Para adicionar outra interface de rede, adicione --network-interface network=SOURCE_NETWORK_NAME ao comando gcloud compute instances create-with-container que aparece no script.

  Observação: para redes VPC de modo personalizado, é necessário especificar explicitamente a sub-rede. O argumento que você precisa adicionar é --network-interface network=SOURCE_NETWORK_NAME,subnet=SOURCE_SUBNET_NAME.

  Um exemplo de comando para criar o proxy:

    gcloud compute instances create-with-container … \
    --network-interface subnet=DESTINATION-SUBNET-NAME \
    --network-interface network=SOURCE-NETWORK-NAME

  Substitua:

  • DESTINATION-SUBNET-NAME: o nome da sub-rede de destino.
  • SOURCE-NETWORK-NAME: o nome da rede de origem.

Para mais informações, consulte Criar instâncias de VM com várias interfaces de rede.

Migrar pela Internet pública

Esse método é recomendado ao migrar de uma instância local ou de outros provedores de nuvem, em que não há uma conexão VPN ou Interconnect com Google Cloud. Para usar esse método, configure o cluster do AlloyDB de destino para usar um endereço IP público de saída.

Migrar de uma origem em um projeto Google Cloud diferente

Para migrar de uma origem em um projeto Google Cloud diferente, migre pela Internet ou, para conectividade Google Cloud interna, use uma VPC compartilhada. Selecione uma das seguintes opções:

• Use uma VPC compartilhada sem um proxy. Se você quiser que o cluster do AlloyDB fique em uma VPC compartilhada, basta selecionar a VPC em que a origem está localizada ao criar o cluster. Assim, a origem e o destino têm conectividade direta.

• Use uma VPC compartilhada com um proxy. Se você não quiser que o cluster do AlloyDB fique em uma VPC compartilhada, use um proxy intermediário. É possível configurar sua própria solução de proxy, mas recomendamos usar o método de conectividade de proxy TCP. Siga estas diretrizes para criar um proxy TCP com uma interface de rede adicional em uma VPC compartilhada.

Migrar sem permitir que o destino alcance a rede da origem

Esse método é recomendado ao migrar de uma rede local, em que há preocupação em abrir o firewall da rede para o tráfego Google Cloud de entrada. Para esse cenário, configure um proxy reverso usando uma instância do Compute Engine como um proxy intermediário. Recomendamos usar o método de conectividade SSH reversa.