Como depurar a conectividade

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Depurar a conectividade

Você configurou a conectividade entre os bancos de dados de origem e de destino, mas como saber se eles estão conectados? Quando as comunicações falham entre eles, como descobrir o que deu errado e onde?

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

Ping

Ping realiza um teste básico para determinar se o destino ("host remoto") está disponível na origem. Ping envia um pacote ICMP Echo Request para um host remoto e espera um ICMP Echo Reply em troca. Se ping não tiver êxito, isso significa que não há rota da origem até o destino. O caso de êxito, no entanto, não significa que os pacotes podem ser enviados, mas que, em geral, o host remoto pode ser alcançado.

Embora ping possa dizer se um host está ativo e respondendo, não é garantido que ele seja confiável. Alguns provedores de rede bloqueiam ICMP por medida de segurança, o que pode dificultar a depuração da conectividade.

Traceroute

Traceroute testa a rota completa que pacotes de rede usam de um host para outro. Ele mostra todas as etapas ("saltos") que o pacote percorre ao longo do tempo e quanto tempo cada etapa leva. Se o pacote não for até o destino, traceroute não será concluído, mas terminará com uma série de asteriscos. Nesse caso, procure o último endereço IP que foi alcançado ao longo do caminho. Ele será onde a conectividade caiu.

Traceroute pode expirar. Ele também não será concluído se um gateway no caminho não estiver configurado corretamente para transmitir o pacote para o próximo salto.

Quando o traceroute não for concluído, é possível descobrir onde ele parou. Encontre o último endereço IP listado na saída traceroute e faça uma pesquisa por who owns [IP_ADDRESS] com o navegador. Os resultados podem ou não mostrar o proprietário do endereço, mas vale a pena tentar.

mtr

A ferramenta mtr é uma forma de traceroute que permanece ativa e atualizada continuamente, da mesma forma que o comando top funciona para processos locais.

Localizar o endereço IP local

Se você não souber o endereço local do host, execute o comando ip -br address show. No Linux, isso mostra a interface de rede, o status 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.

Se preferir, execute ipconfig ou ifconfig para ver o status das interfaces de rede.

Localizar o endereço IP de saída

Se você não souber o endereço IP que os bancos de dados de origem e de destino usam para se comunicar (o endereço IP de saída), siga estas etapas:

1. Acesse a página de clusters do AlloyDB no Google Cloud console.

   Acessar a página de clusters do AlloyDB

2. Localize o cluster associado ao job de migração que você está depurando.

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

Abrir portas locais

Para verificar se o host está detectando nas portas que você acredita que estejam, execute o comando ss -tunlp4. Isso informa quais portas estão abertas e detectando. Por exemplo, se você tiver um banco de dados PostgreSQL em execução, a porta 5432 estará ativa e detectando. Para o SSH, será a porta 22.

Atividade de todas as portas locais

Use o comando netstat para ver a atividade de todas as portas locais. Por exemplo, netstat -lt mostra todas as portas ativas no momento.

Conectar-se ao host remoto usando o telnet

Para verificar se é possível se conectar ao host remoto usando TCP, execute o comando telnet. O telnet tenta se conectar ao endereço IP e à porta fornecidos por você.

Se o host remoto estiver executando um banco de dados PostgreSQL, por exemplo, será possível usar o telnet nele na porta 5432: telnet 35.193.198.159 5432.

Se o processo for bem-sucedido, você verá o seguinte:

Trying 35.193.198.159...

Connected to 35.193.198.159. .

Em caso de falha, você vê telnet para de responder até que você force o fechamento da tentativa:

Trying 35.193.198.159...

^C. .

Autenticação do cliente

A autenticação do cliente é controlada por um arquivo de configuração, chamado pg_hba.conf (HBA significa autenticação baseada em host).

Verifique se a seção de conexões de replicação do arquivo pg_hba.conf no banco de dados de origem está atualizada para aceitar conexõ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 informações completas e revise as consultas de amostra do Cloud SQL.

Ver registros

É possível ver os registros das instâncias do AlloyDB e de outros Google Cloud projetos, como as instâncias do Cloud VPN ou do Compute Engine. Para ver os registros das entradas de registro da instância do AlloyDB:

Console

1. Acesse a Análise de registros
2. Selecione um projeto do AlloyDB na parte de cima da página.
3. No criador de consultas, adicione o seguinte:
• Recurso: selecione Banco de dados do AlloyDB. Na caixa de diálogo, selecione uma instância do AlloyDB.
• Nomes de registros: vá até a seção do AlloyDB e selecione os arquivos de registro correspondentes à instância. Exemplo:
  • alloydb.googlapis.com/postgres.log
• Gravidade: selecione um nível de registro.
• Período: selecione um valor predefinido ou crie um período personalizado.

gcloud

Use o comando gcloud logging para visualizar as entradas de registro. No exemplo abaixo, substitua PROJECT_ID. A limit sinalização é um parâmetro opcional que indica o número máximo de entradas a serem retornadas.

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

Solução de problemas de VPN

Consulte a página Google Cloud Solução de problemas do Cloud VPN.

Resolver problemas de proxy TCP

A maneira como o proxy TCP é configurado também pode gerar erros. Para resolver um erro de proxy TCP, consulte os exemplos de problemas e como eles podem ser resolvidos:

Falha ao iniciar a máquina virtual (VM)

A seguinte mensagem aparece ao iniciar a instância de VM no Compute Engine:

You do not currently have an active account selected.

O que tentar

Execute um dos comandos a seguir para configurar uma conta ativa:

• Para receber 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 você quer configurar.

Falha ao se conectar à instância do banco de dados de origem

A seguinte mensagem de erro aparece ao testar o job 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.

O que tentar

Repita as etapas a seguir para entender onde o problema pode estar:

1. Verifique se a VM que hospeda o contêiner de proxy TCP está em execução:

   1. No console, acesse a página Instâncias de VM do Compute Engine.

      Acessar instâncias de VM

   2. Pesquise a VM criada como parte do processo de configuração do proxy. Se ela não estiver listada ou não estiver em execução, configure o proxy TCP do zero e atualize as configurações da instância de origem no job de migração com o endereço IP correto.

2. Se a VM estiver em execução, verifique se não houve erro ao fazer o download da imagem do contêiner de proxy TCP:

   1. Selecione a VM criada como parte do processo de configuração do proxy TCP. Em Registros, clique em Porta serial 1 (console).

   2. Se você não encontrar a entrada Launching user container 'gcr.io/dms-images/tcp-proxy' nos registros, o problema pode ser que a instância não conseguiu extrair a imagem do Container Registry. Para verificar se é esse o caso, conecte-se à VM e tente extrair a imagem do Container Registry manualmente usando o seguinte comando:

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

      Se você receber 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), isso significa que a VM não conseguiu se conectar ao Container Registry. Se a VM tiver apenas um endereço IP particular, você precisa ativar o Acesso privado do Google na sub-rede a que o endereço IP pertence. Caso contrário, a VM não terá acesso às APIs do Google Enterprise, como o Container Registry.

3. Verifique se o contêiner pode se conectar à instância de origem:

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

   2. Se você receber a seguinte mensagem: Connection refused, please verify that the machine you are using to run the script can connect to the source database at, isso significa que o contêiner de proxy TCP não conseguiu se conectar à instância do banco de dados de origem. Há vários motivos para isso acontecer:

      • O endereço IP da instância de origem está incorreto.
      • Há uma política de firewall que recusa conexões do proxy TCP com a instância de origem.
      • A instância de origem está em uma rede de nuvem privada virtual (VPC) diferente da VM que hospeda o proxy TCP.

   É possível depurar o problema de conectividade usando Google Cloudos testes de conectividade do para garantir que haja conectividade entre o banco de dados de destino e a VM que hospeda o proxy TCP:

   1. No console do Cloud, acesse a página Testes de conectividade.

      Acesse Testes de conectividade

   2. Clique em Criar teste de conectividade.

   3. Insira um nome para o teste.

   4. Selecione TCP como o protocolo.

   5. Selecione Endereço IP na lista Endpoint de origem. Insira o endereço IP público do proxy TCP recém-criado se o banco de dados de origem puder ser acessado usando um endereço IP público. Caso contrário, insira o endereço IP particular do proxy TCP.

   6. Selecione Endereço IP na lista Endpoint de destino e insira o endereço IP do banco de dados de origem.

   7. Insira o número da porta usada para se conectar ao banco de dados de origem no campo Porta de destino.

   8. Clique em Criar.

   Execute o teste de conectividade e resolva os problemas de conectividade que surgirem. Depois de corrigir o problema de conectividade, verifique se o proxy TCP pode se conectar à instância de origem:

   1. Acesse Instâncias de VM no Compute Engine.

      Acessar instâncias de VM

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

   3. Se você encontrar a entrada de registro Connection to source DB verified, isso significa que o proxy TCP agora pode se conectar à instância de origem.

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

Falha ao se conectar à instância do banco de dados de destino

Se o contêiner de proxy TCP puder se conectar à instância de origem, mas o teste de migração ainda estiver falhando devido a problemas de conexão, o problema poderá ser a conectividade entre a instância de destino e a VM que hospeda o contêiner de proxy TCP.

Depurar o problema

Para depurar o problema, use Google Cloudos testes de conectividade do para garantir que haja conectividade entre o banco de dados de destino e a VM que hospeda o proxy TCP:

1. No console do Cloud, acesse a página Testes de conectividade.

   Acesse Testes de conectividade

2. Clique em Criar teste de conectividade.

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

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

4. Clique em Criar.

5. Execute o teste de conectividade e resolva os problemas de conectividade que surgirem.

Possíveis causas

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

O que tentar

Adicione uma regra de firewall que permita que a instância de destino se comunique com o proxy TCP usando a porta 5432.

Possíveis causas

Há uma incompatibilidade de VPC entre a instância de destino e a VM que executa o contêiner de proxy TCP.

O que tentar

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

Resolver problemas de túnel SSH reverso

O tunelamento SSH é um método para encaminhar algumas comunicações em uma conexão SSH. O tunelamento SSH reverso permite configurar um túnel SSH, mas mantendo a rede de destino como a que inicia a conexão do túnel. Isso é útil quando você não quer abrir uma porta na sua própria rede por motivos de segurança.

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

Embora o Database Migration Service migre dados de uma origem para um destino, é necessário ativar a conectividade do destino para a origem.

É presumido que:

• O AlloyDB destination pode acessar o Compute Engine VM bastion.

• O source network bastion pode acessar o source DB. Isso é feito pelo peering da rede do AlloyDB com a rede da VM do Compute Engine.

Em seguida, configure um túnel SSH do source network bastion para o Compute Engine VM bastion, que encaminha todas as conexões recebidas para alguma porta no Compute Engine VM bastion pelo túnel para o source DB.

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

source network bastion ---> source DB

1. Conecte-se ao source network bastion usando SSH ou pelo terminal, se for a máquina local.
2. Teste a conectividade com o banco de dados de origem usando um dos seguintes métodos:
   • telnet [source_db_host_or_ip] [source_db_port] - espere ver as strings de conexão telnet, terminando com Connected to x.x.x.x.
   • [db_client] -h[source_db_host_or_ip] -P[source_db_port] - espere ver o acesso negado

Se isso falhar, será necessário verificar se você ativou o acesso desse bastion ao banco 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 conectividade com o banco de dados de origem usando um dos seguintes métodos:
   • telnet 127.0.0.1 [tunnel_port] - espere ver as strings de conexão telnet, terminando com Connected to x.x.x.x.
   • [db_client] -h127.0.0.1 -P[tunnel_port] - espere ver o acesso negado

Se isso falhar, será necessário verificar se o túnel está funcionando corretamente. A execução de sudo netstat -tupln mostra todos os processos de detecção em essa VM, e você verá sshd listening on the tunnel_port.

AlloyDB DB ---> source DB

A melhor maneira de testar isso é testing the migration job do Database Migration Service. Se isso falhar, significa que há algum problema com o peering ou o roteamento de VPC entre a rede do AlloyDB e a Compute Engine VM bastion rede.

O firewall do servidor de banco de dados de origem precisa ser configurado para permitir todo o intervalo de IPs interno alocado para a conexão de serviço particular da rede VPC que a instância de destino do AlloyDB vai usar como o campo privateNetwork das configurações de ipConfiguration.

Para encontrar o intervalo de IP interno no console do Google Cloud:

1. Acesse a página de redes VPC no Google Cloud console do Cloud.

2. Selecione a rede VPC que você quer usar.

3. Selecione Acesso a serviços particulares > Intervalos de IP alocados para serviços.

4. Encontre o intervalo de IP interno associado à conexão criada por servicenetworking-googleapis-com.

Também é possível visualizar o tráfego entre a instância do AlloyDB e a instância da VM do Compute Engine em o console do Cloud Logging no Cloud VPN gateway projeto. Nos registros da VM do Compute Engine, procure o tráfego da instância do AlloyDB. Nos registros da instância do AlloyDB, procure o tráfego da VM do Compute Engine.