Métodos de trabalho em rede

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Vista geral

Para criar uma migração no serviço de migração de bases de dados, tem de estabelecer a conetividade entre a instância de origem e a instância de destino do AlloyDB. Existem vários métodos suportados. Escolha o que funciona melhor para a carga de trabalho específica.

Método de rede	Descrição	Vantagens	Desvantagens
Lista de autorizações de IPs	Este método funciona configurando o servidor da base de dados de origem para aceitar ligações do IP de saída da instância do Cloud SQL. Se escolher este método, o serviço de migração de bases de dados oferece-lhe instruções durante o processo de configuração da criação da migração.	Fácil de configurar. Não requer nenhuma configuração personalizada da firewall.	O tráfego de rede ocorre através da Internet pública. Menos seguro. Diminuição do desempenho.
Proxy através de VM alojada na nuvem: túnel SSH inverso	Estabelece a conetividade do destino à origem através de um túnel SSH inverso seguro. Requer uma VM de anfitrião de bastião no Google Cloud projeto da plataforma, bem como uma máquina (por exemplo, um portátil na rede) que tenha conetividade à origem. O serviço de migração de bases de dados recolhe 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 da firewall. Recomendado para cenários de migração de curta duração (POC ou migrações de bases de dados pequenas).	A VM bastion é detida e gerida por si e pode incorrer em custos adicionais.
Proxy através de VM alojada na nuvem – TCP	Estabelece a conetividade da origem ao destino através de um proxy TCP através de uma VM alojada na nuvem. O serviço de migração de bases de dados recolhe 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 da firewall.	A VM bastion é detida e gerida por si e pode incorrer em custos adicionais.
Intercâmbio da VPC	Este método funciona configurando as VPCs para comunicarem entre si.	Solução Google Cloud nativa. Fácil de configurar. Largura de banda elevada. Recomendado para migrações de longa duração ou de grande volume.	Aplicável se as bases de dados de origem e de destino estiverem alojadas no Google Cloudou se a origem estiver ligada à VPC de destino através de uma VPN (alojada na nuvem ou nas instalações) ou do Cloud Interconnect.
Interfaces do Private Service Connect	As interfaces do Private Service Connect permitem que a base de dados de destino inicie ligações ao IP privado da base de dados de origem sem consumir a quota de peering. Em alternativa, este método de conetividade usa associações de rede que cria na sua VPC.	Estabelece ligações ao IP privado de origem através de uma associação de rede. Este método não consome a quota de intercâmbio na sua VPC. O método de conetividade privada de origem mais fácil de configurar.	Este método de conetividade só está disponível quando migra para uma instância existente. Requer a configuração de uma associação de rede e o ajuste das regras de firewall. Não pode modificar a associação de rede depois de estabelecer a ligação. Para mais informações sobre o acesso a serviços privados e o Private Service Connect no AlloyDB para PostgreSQL, consulte a vista geral do IP privado na documentação do AlloyDB para PostgreSQL.

Limitações de conetividade

A conetividade do PostgreSQL ao AlloyDB tem as seguintes limitações:

• O AlloyDB suporta a conetividade privada através do acesso a serviços privados. A atribuição de um endereço IP público a um cluster não é suportada.
• Não é possível alterar a VPC com a qual o cluster do AlloyDB está interligado após a criação do cluster.
• Uma vez que o AlloyDB usa o acesso a serviços privados, que usa internamente o intercâmbio de VPC, o intercâmbio transitivo não é suportado. O cluster do AlloyDB só pode alcançar endereços IP internos na mesma VPC com a qual está em peering. Para alcançar outras VPCs, tem de usar um proxy intermediário. Para mais detalhes, consulte a secção seguinte.

Cenários e soluções de conetividade comuns

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

Figura 1. Uma ligação privada facilitada pela VM de proxy TCP (clique para aumentar)

Para migrar de uma instância do Cloud SQL para PostgreSQL na arquitetura de rede do produtor antigo, tem de estabelecer a conetividade através de um proxy intermediário. Isto deve-se ao facto de não ser possível ter conetividade direta entre a instância do Cloud SQL de origem e o destino do AlloyDB. Pode configurar a sua própria solução de proxy, embora recomendemos que configure a VM de proxy TCP com o script gerado automaticamente fornecido pelo serviço de migração de bases de dados. Consulte o método de conetividade do proxy TCP.

Migre de uma origem no mesmo Google Cloud projeto, mas numa VPC diferente

Uma vez que não é possível alterar a VPC na qual o cluster do AlloyDB reside após a criação do cluster, tem as seguintes opções:

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

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

• Se não for possível alterar 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. Pode configurar a sua própria solução de proxy, embora recomendemos que use o método de conetividade de proxy TCP. Depois de o serviço de migração de bases de dados gerar o script na Google Cloud consola, 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. Desta forma, o proxy tem conetividade com as VPCs de origem e de 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.

  Nota: para redes VPC no modo personalizado, tem de especificar explicitamente a sub-rede. O argumento que tem de acrescentar é --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 o seguinte:

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

Para mais informações, consulte o artigo Crie instâncias de VMs com várias interfaces de rede.

Migre através da Internet pública

Este método é recomendado quando migra de uma instância nas instalações ou de outros fornecedores de nuvem, onde não existe uma ligação VPN ou Interconnect a Google Cloud. Para usar este método, tem de configurar o cluster do AlloyDB de destino para usar um endereço IP público de saída.

Migre de uma origem num Google Cloud projeto diferente

Para migrar a partir de uma origem num Google Cloud projeto diferente, tem de migrar através da Internet ou, para a conetividade Google Cloud interna, usar uma VPC partilhada. Selecione uma das seguintes opções:

• Use uma VPC partilhada sem um proxy. Se quiser que o cluster do AlloyDB resida numa VPC partilhada, basta selecionar a VPC onde a origem reside quando criar o cluster. Desta forma, a origem e o destino têm conetividade direta.

• Use uma VPC partilhada com um proxy. Se não quiser que o cluster do AlloyDB resida numa VPC partilhada, tem de usar um proxy intermediário. Pode configurar a sua própria solução de proxy, mas recomendamos que use o método de conetividade de proxy TCP. Siga estas diretrizes para criar um proxy TCP com uma interface de rede adicional numa VPC partilhada.

Migre sem permitir que o destino alcance a rede da origem

Este método é recomendado quando migra de uma rede no local, em que existe uma preocupação em abrir a firewall da rede ao tráfego Google Cloud recebido. Para este cenário, pode configurar um proxy inverso através de uma instância do Compute Engine como proxy intermediário. Recomendamos que use o método de conetividade SSH inversa.