Depurar conetividade

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Depure a conetividade

Configurou a conetividade entre as bases de dados de origem e de destino, mas como sabe se estão associadas? Quando as comunicações entre eles falham, como pode descobrir o que correu mal e onde?

As ferramentas mais básicas são ping e traceroute.

Tchim-tchim

Ping realiza um teste básico para determinar se o destino ("anfitrião remoto") está disponível a partir da origem. Ping envia um pacote ICMP Echo Request para um anfitrião remoto e espera um ICMP Echo Reply em troca. Se ping não tiver êxito, não existe um trajeto da origem para o destino. No entanto, o sucesso não significa que os seus pacotes consigam passar, apenas que, em geral, é possível alcançar o anfitrião remoto.

Embora o ping possa determinar se um anfitrião está ativo e a responder, não é garantido que seja fiável. Alguns fornecedores de rede bloqueiam o ICMP como uma precaução de segurança, o que pode dificultar a depuração da conetividade.

Traceroute

Traceroute testa o percurso completo que os pacotes de rede fazem de um anfitrião para outro. Mostra todos os passos ("saltos") que o pacote dá ao longo do caminho e quanto tempo demora cada passo. Se o pacote não chegar ao destino, o traceroute não é concluído, mas termina com uma série de asteriscos. Neste caso, procure o último endereço IP que foi alcançado com êxito ao longo do caminho. Foi aqui que a conetividade foi interrompida.

Traceroute pode expirar. Também pode falhar se um gateway ao longo do caminho não estiver configurado corretamente para transmitir o pacote ao próximo salto.

Quando a traceroute não é concluída, pode conseguir descobrir onde parou. Encontre o último endereço IP apresentado no resultado traceroute e faça uma pesquisa no navegador por who owns [IP_ADDRESS]. Os resultados podem ou não mostrar o proprietário da morada, mas vale a pena tentar.

mtr

A ferramenta mtr é uma forma de traceroute que permanece ativa e é atualizada continuamente, de forma semelhante ao funcionamento do comando top para processos locais.

Localize o seu endereço IP local

Se não souber o endereço local do seu anfitrião, execute o comando ip -br address show. No Linux, isto mostra a interface de rede, o estado da interface, o IP local e os endereços MAC. Por exemplo: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64.

Em alternativa, pode executar ipconfig ou ifconfig para ver o estado das suas interfaces de rede.

Localize o endereço IP de saída

Se não souber o endereço IP que as bases de dados de origem e de destino usam para comunicar entre si (o endereço IP de saída), conclua os seguintes passos:

1. Aceda à página Clusters do AlloyDB no Google Cloud console.

   Aceda à página Clusters do AlloyDB

2. Localize o cluster associado à tarefa de migração que está a depurar.

3. O IP de saída deve aparecer junto ao nome da instância principal do cluster.

Abra portas locais

Para verificar se o seu anfitrião está a ouvir nas portas que pensa que está, execute o comando ss -tunlp4. Isto indica que portas estão abertas e a escutar. Por exemplo, se tiver uma base de dados PostgreSQL em execução, a porta 5432 deve estar em funcionamento e a ouvir. Para o SSH, deve ver a porta 22.

Toda a atividade da porta local

Use o comando netstat para ver toda a atividade da porta local. Por exemplo, netstat -lt mostra todas as portas atualmente ativas.

Ligue-se ao anfitrião remoto através do telnet

Para verificar se consegue estabelecer ligação ao anfitrião remoto através do TCP, execute o comando telnet. O Telnet tenta estabelecer ligação ao endereço IP e à porta que lhe indicar.

Se o seu anfitrião remoto estiver a executar uma base de dados PostgreSQL, por exemplo, deve conseguir estabelecer ligação por telnet à mesma na porta 5432: telnet 35.193.198.159 5432.

Se tiver êxito, vê o seguinte:

Trying 35.193.198.159...

Connected to 35.193.198.159. .

Em caso de falha, o telnet deixa de responder até forçar o encerramento da tentativa:

Trying 35.193.198.159...

^C. .

Autenticação do cliente

A autenticação do cliente é controlada por um ficheiro de configuração denominado pg_hba.conf (HBA significa autenticação baseada no anfitrião).

Certifique-se de que a secção de ligações de replicação do ficheiro pg_hba.conf na base de dados de origem é atualizada para aceitar ligações do intervalo de endereços IP da VPC do AlloyDB.

Cloud Logging

O Database Migration Service e o AlloyDB usam o Cloud Logging. Consulte a documentação do Cloud Logging para ver informações completas e reveja as consultas de exemplo do Cloud SQL.

Ver registos

Pode ver registos de instâncias do AlloyDB e outros Google Cloud projetos, como instâncias do Cloud VPN ou do Compute Engine. Para ver os registos das entradas de registo da sua instância do AlloyDB:

Consola

1. Aceda ao Explorador de registos
2. Selecione um projeto do AlloyDB existente na parte superior da página.
3. No criador de consultas, adicione o seguinte:
• Recurso: selecione Base de dados do AlloyDB. Na caixa de diálogo, selecione uma instância do AlloyDB.
• Nomes dos registos: desloque a página até à secção do AlloyDB e selecione os ficheiros de registo adequados para a sua instância. Por exemplo:
  • alloydb.googlapis.com/postgres.log
• Gravidade: selecione um nível de registo.
• Intervalo de tempo: selecione uma predefinição ou crie um intervalo personalizado.

gcloud

Use o comando gcloud logging para ver as entradas do registo. No exemplo abaixo, substitua PROJECT_ID. A flag limit é um parâmetro opcional que indica o número máximo de entradas a devolver.

gcloud logging read "projects/[PROJECT_ID]/logs/alloydb.googleapis.com/postgres.log" --limit=10

Resolução de problemas da VPN

Consulte a página de Google Cloud resolução de problemas da VPN na nuvem.

Resolva problemas de erros de proxy TCP

A forma como o proxy TCP está configurado também pode gerar erros. Para resolver um problema de proxy TCP, consulte os seguintes exemplos de problemas e como podem ser resolvidos:

Falha ao iniciar a máquina virtual (VM)

É apresentada a seguinte mensagem quando inicia a instância de VM no Compute Engine:

You do not currently have an active account selected.

Coisas a experimentar

Execute um dos seguintes comandos para configurar uma conta ativa:

• Para obter novas credenciais, execute o seguinte comando:

  gcloud auth login
  

• Para selecionar uma conta já autenticada, execute o seguinte comando:

  gcloud config set account ACCOUNT
  

  Substitua ACCOUNT pelo nome da conta que quer configurar.

Falha ao estabelecer ligação à instância da base de dados de origem

É apresentada a seguinte mensagem de erro quando testa a tarefa de migração:

Failure connecting to the source database. Make sure the connectivity information on the connection profile is correct and the source database is reachable.

Coisas a experimentar

Itere os seguintes passos para compreender onde pode estar o problema:

1. Verifique se a VM que aloja o contentor do proxy TCP está em execução:

   1. Na consola, aceda à página Instâncias de VM do Compute Engine.

      Aceder às instâncias de VM

   2. Pesquise a VM que foi criada como parte do processo de configuração do proxy. Se não estiver listado ou não estiver em execução, configure o proxy TCP de raiz e atualize as definições da instância de origem na tarefa de migração com o endereço IP correto.

2. Se a VM estiver em execução, verifique se não ocorreu nenhum erro ao transferir a imagem do contentor do proxy TCP:

   1. Selecione a VM criada como parte do processo de configuração do proxy TCP. Em Registos, clique em Porta de série 1 (consola).

   2. Se não conseguir ver a entrada Launching user container 'gcr.io/dms-images/tcp-proxy' nos registos, o problema pode ser que a sua instância não conseguiu obter a imagem do Container Registry. Para verificar se é este o caso, ligue-se à VM e tente extrair manualmente a imagem do Container Registry através do seguinte comando:

      docker pull gcr.io/dms-images/tcp-proxy

      Se vir o seguinte erro: Error response from daemon: Get "https://gcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers), significa que a sua VM não conseguiu estabelecer ligação ao Container Registry. Se a sua VM tiver apenas um endereço IP privado, tem de ativar o acesso privado à Google na sub-rede da qual o endereço IP faz parte. Caso contrário, a VM não tem acesso às APIs Google Enterprise, como o Container Registry.

3. Verifique se o contentor consegue estabelecer ligação à instância de origem:

   1. Selecione a VM que foi criada como parte do processo de configuração do proxy. Em Registos, clique em Cloud Logging.

   2. Se vir a seguinte mensagem: Connection refused, please verify that the machine you are using to run the script can connect to the source database at, significa que o contentor do proxy TCP não conseguiu estabelecer ligação à instância da base de dados de origem. Existem vários motivos para que isto aconteça:

      • O endereço IP da instância de origem está incorreto.
      • Existe uma política de firewall que recusa ligações do proxy TCP à instância de origem.
      • A instância de origem está numa rede da nuvem virtual privada (VPC) diferente da VM que aloja o proxy TCP.

   Pode depurar o problema de conetividade através dos testes de conetividade do Google Cloudpara se certificar de que existe conetividade entre a base de dados de destino e a VM que aloja o proxy TCP:

   1. Na consola, aceda à página Testes de conetividade.

      Aceda a Testes de conetividade

   2. Clique em Criar teste de conetividade.

   3. Introduza um nome para o teste.

   4. Selecione TCP como o protocolo.

   5. Selecione Endereço IP na lista Ponto final de origem. Introduza o endereço IP público do proxy TCP recém-criado se a base de dados de origem for acessível através de um endereço IP público; caso contrário, introduza o endereço IP privado do proxy TCP.

   6. Selecione Endereço IP na lista Ponto final de destino e introduza o endereço IP da base de dados de origem.

   7. Introduza o número da porta usado para estabelecer ligação à base de dados de origem no campo Porta de destino.

   8. Clique em Criar.

   Execute o teste de conetividade e resolva quaisquer problemas de conetividade que surjam. Depois de corrigir o problema de conetividade, verifique se o proxy TCP consegue estabelecer ligação à instância de origem:

   1. Aceda a Instâncias de VM no Compute Engine.

      Aceder às instâncias de VM

   2. Selecione a VM que foi criada como parte do processo de configuração do proxy. Em Registos, clique em Cloud Logging.

   3. Se vir a entrada de registo Connection to source DB verified, significa que o proxy TCP já pode estabelecer ligação à instância de origem.

4. Verifique se o teste de migração não está a falhar devido a problemas de ligação.

Falha ao estabelecer ligação à instância da base de dados de destino

Se o contentor do proxy TCP conseguir estabelecer ligação à instância de origem, mas o teste de migração continuar a falhar devido a problemas de ligação, o problema pode estar na conetividade entre a instância de destino e a VM que aloja o contentor do proxy TCP.

Corrija o problema

Para depurar o problema, pode usar os testes de conetividade do Google Cloudpara se certificar de que existe conetividade entre a base de dados de destino e a VM que aloja o proxy TCP:

1. Na consola, aceda à página Testes de conetividade.

   Aceda a Testes de conetividade

2. Clique em Criar teste de conetividade.

3. Defina os seguintes parâmetros para o teste:

   1. Introduza um nome para o teste.
   2. Selecione TCP como o protocolo.
   3. Selecione Endereço IP na lista Ponto final de origem e introduza o endereço IP do cluster do AlloyDB recém-criado.
   4. Selecione Endereço IP na lista Ponto final de destino e introduza o endereço IP privado do proxy TCP.
   5. Introduza 5432 no campo Porta de destino.

4. Clique em Criar.

5. Execute o teste de conetividade e resolva quaisquer problemas de conetividade que surjam.

Causas possíveis

Existe uma regra de firewall que nega a comunicação entre a instância de destino e a VM de proxy TCP.

Coisas a experimentar

Adicione uma regra de firewall que permita à instância de destino comunicar com o proxy TCP através da porta 5432.

Causas possíveis

Existe uma incompatibilidade de VPC entre a instância de destino e a VM que executa o contentor de proxy TCP.

Coisas a experimentar

Selecione a mesma VPC para a instância de destino.

Resolução de problemas de túnel SSH inverso

O túnel SSH é um método para encaminhar algumas comunicações com base numa ligação SSH. Os túneis SSH inversos permitem configurar um túnel SSH, mas mantendo que a rede de destino é a que inicia a ligação do túnel. Isto é útil quando não quer abrir uma porta na sua própria rede para fins de segurança.

O que está a tentar alcançar é configurar o seguinte: AlloyDB DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Embora o serviço de migração de bases de dados migre dados de uma origem para um destino, deve ativar a conetividade do destino para a origem.

Presume-se que:

• O AlloyDB destination pode aceder ao Compute Engine VM bastion.

• O source network bastion pode aceder ao source DB (isto é conseguido através da interligação da rede do AlloyDB com a rede da VM do Compute Engine).

Em seguida, configura um túnel SSH do source network bastion para o Compute Engine VM bastion, que encaminha todas as ligações recebidas para alguma porta no Compute Engine VM bastion através do túnel para o source DB.

Cada link no cenário acima pode ser configurado incorretamente e impedir que todo o fluxo funcione. Resolva os problemas de cada link, um de cada vez:

source network bastion ---> source DB

1. Estabeleça ligação ao source network bastion através de SSH ou a partir do terminal, se for a máquina local.
2. Teste a conetividade à base de dados de origem através de um dos seguintes métodos:
   • telnet [source_db_host_or_ip] [source_db_port]: espere ver as strings de ligação do telnet, que terminam com Connected to x.x.x.x.
   • [db_client] -h[source_db_host_or_ip] -P[source_db_port] - expect to see access denied

Se isto falhar, tem de verificar se ativou o acesso a partir deste bastion à base de dados de origem.

Compute Engine VM bastion ---> source DB

1. SSH para o Compute Engine VM bastion (usando gcloud compute ssh VM_INSTANCE_NAME)
2. Teste a conetividade à base de dados de origem através de um dos seguintes métodos:
   • telnet 127.0.0.1 [tunnel_port]: espere ver as strings de ligação telnet, que terminam com Connected to x.x.x.x.
   • [db_client] -h127.0.0.1 -P[tunnel_port] – Vai ver que o acesso foi recusado

Se esta ação falhar, tem de verificar se o túnel está a funcionar corretamente. A execução de sudo netstat -tupln mostra todos os processos de escuta nesta VM e deve ver sshd listening on the tunnel_port.

AlloyDB DB ---> source DB

A melhor forma de testar esta opção é através da testing the migration job do Database Migration Service. Se esta ação falhar, significa que existe um problema com o intercâmbio da VPC ou o encaminhamento entre a rede do AlloyDB e a rede Compute Engine VM bastion.

A firewall do servidor da base de dados de origem tem de ser configurada para permitir todo o intervalo de IP interno atribuído para a ligação de serviço privado da rede VPC que a instância de destino do AlloyDB vai usar como o campo privateNetwork das respetivas definições de ipConfiguration.

Para encontrar o intervalo de IPs internos na consola:

1. Aceda à página Redes VPC na Google Cloud consola.

2. Selecione a rede de VPC que quer usar.

3. Selecione Acesso a serviços privados > Intervalos de IP atribuídos para serviços.

4. Encontre o intervalo de IPs internos associado à ligação criada por servicenetworking-googleapis-com.

Também pode ver o tráfego entre a instância do AlloyDB e a instância da VM do Compute Engine na consola do Cloud Logging no projeto Cloud VPN gateway. Nos registos de VMs do Compute Engine, procure tráfego proveniente da instância do AlloyDB. Nos registos da instância do AlloyDB, procure tráfego da VM do Compute Engine.