Métodos de rede

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Visão geral

Para criar uma migração no Database Migration Service, a conectividade precisa ser estabelecida entre a instância de origem e a instância de destino do AlloyDB. Há vários métodos com suporte. Escolha 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ê no processo de configuração durante a criação da migração.	Fácil de configurar. Não requer nenhuma configuração de firewall personalizada.	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 para a origem por um túnel SSH reverso seguro. Requer uma VM de Bastion Host no projeto do Google Cloud Platform, bem como uma máquina (por exemplo, um laptop na rede) que tenha conectividade com a 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 de firewall personalizada. Recomendado para cenários de migração de curta duração (migrações de POC ou de banco de dados pequenos ).	A VM bastion é de sua propriedade e gerenciada por você, e pode gerar custos extras.
Proxy por VM hospedada na nuvem: TCP	Estabelece a conectividade do destino para a 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 de firewall personalizada.	A VM bastion é de sua propriedade e gerenciada por você, e pode gerar custos extras.
Peering de VPC	Esse método funciona configurando as VPCs para se comunicarem entre si.	Solução nativa Google Cloud . 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 Cloud, ou 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 o banco de dados de destino 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 que você cria na VPC.	Estabelece conexões com o IP particular de origem usando um anexo de rede. Esse método não consome a cota de peering na VPC. O método de conectividade particular de origem mais fácil de configurar.	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 para 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 usa o peering de VPC internamente, o peering transitivo não é compatível. O cluster do AlloyDB só pode alcançar endereços IP internos na mesma VPC com que tem peering. Para alcançar outras VPCs, é necessário usar um proxy intermediário. Para mais detalhes, consulte a seção a seguir.

Cenários e soluções de conectividade comuns

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

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 a conectividade usando um proxy intermediário. Isso ocorre porque não é possível ter conectividade direta entre a instância do Cloud SQL de origem e o destino do AlloyDB. É possível configurar sua própria solução de proxy, embora recomendemos 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 Google Cloud projeto, mas em uma VPC diferente

Como a VPC em que o cluster do AlloyDB reside não pode ser alterada depois que o cluster é 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.

  **Cuidado**: configurar um endereço IP particular para uma instância atual 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, embora recomendemos usar o método de conectividade do proxy TCP. Depois que o Database Migration Service gerar o script no Google Cloud console, 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. Dessa forma, o proxy tem conectividade com as VPCs de origem e destino.

  Para adicionar outra interface de rede, anexe --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 anexar é --network-interface network=SOURCE_NETWORK_NAME,subnet=SOURCE_SUBNET_NAME.

  Um comando de exemplo 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 o para Google Cloud. Para usar esse método, é necessário configurar o cluster do AlloyDB de destino para usar um endereço IP público de saída.

Migrar de uma origem em um projeto diferente Google Cloud

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

• Usar uma VPC compartilhada sem um proxy. Se você quiser que o cluster do AlloyDB resida em uma VPC compartilhada, basta selecionar a VPC em que a origem reside ao criar o cluster. Dessa forma, a origem e o destino têm conectividade direta.

• Usar uma VPC compartilhada com um proxy. Se você não quiser que o cluster do AlloyDB resida 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 do 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á uma preocupação em abrir o firewall da rede para o tráfego de entrada Google Cloud . Para esse cenário, é possível configurar um proxy reverso usando uma instância do Compute Engine como um proxy intermediário. Recomendamos o uso do método de conectividade SSH reverso.