Depurando conectividade

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Depurar conectividade

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

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

Pingar

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 uma ICMP Echo Reply em troca. Se ping não for bem-sucedido, não haverá rota da origem até o destino. Sucesso, entretanto, não significa que seus pacotes possam passar, apenas que, em geral, o host remoto pode ser alcançado.

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

Trace rota

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

Traceroute pode expirar. Ele também pode falhar na conclusão se um gateway ao longo do caminho não estiver configurado corretamente para passar o pacote para o próximo salto.

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

metrô

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

Localize seu endereço IP local

Se você não souber o endereço local do seu host, execute o comando ip -br address show . No Linux, 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 .

Alternativamente, você pode executar ipconfig ou ifconfig para ver o status de suas interfaces de rede.

Localize o endereço IP de saída

Se você não souber o endereço IP que os bancos de dados de origem e destino usam para se comunicarem entre si (o endereço IP de saída), conclua as etapas a seguir:

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

   Vá para a página de clusters do AlloyDB

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

3. O IP de saída deve aparecer próximo ao nome da instância primária do cluster.

Abra portas locais

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

Todas as atividades portuárias locais

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

Conecte-se ao host remoto usando telnet

Para verificar se você pode se conectar ao host remoto usando TCP , execute o comando telnet . O Telnet tenta se conectar ao endereço IP e à porta que você forneceu.

Em caso de sucesso, você verá o seguinte: Trying 35.193.198.159...

Conectado a 35.193.198.159. .

Em caso de falha, você verá que telnet para de responder até você forçar o fechamento da tentativa: Trying 35.193.198.159...

^ C. .

Autenticação de cliente

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

Certifique-se de que a seção de conexões de replicação do arquivo pg_hba.conf no banco de dados de origem esteja atualizada para aceitar conexões do intervalo de endereços IP do AlloyDB VPC.

Registro em nuvem

Ver registros

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

Solução de problemas de VPN

Veja oGoogle Cloud Página de solução de problemas do Cloud VPN .

Solucionar erros de proxy TCP

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

Falha ao iniciar a máquina virtual (VM)

Você verá a seguinte mensagem ao iniciar a instância de VM no Compute Engine:

You do not currently have an active account selected.

Coisas para tentar

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 você deseja configurar.

Falha na conexão com a instância do banco de dados de origem

Você verá a seguinte mensagem de erro ao testar o trabalho 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 para 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 de instâncias de VM do Compute Engine.

      Acesse as instâncias de VM

   2. Procure 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 seu proxy TCP do zero e atualize as configurações da instância de origem no trabalho de migração com o endereço IP correto.

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

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

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

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

      Se você 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 sua VM não conseguiu se conectar ao Container Registry. Se sua VM tiver apenas um endereço IP privado, você deverá ativar o Acesso privado do Google na sub-rede da qual o endereço IP faz parte; 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 que foi criada como parte do processo de configuração do proxy. Em Logs , clique em Cloud Logging .

   2. Se você 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 , isso significa que o contêiner do proxy TCP não conseguiu se conectar à instância do banco de dados de origem. Pode haver vários motivos para isso acontecer:

      • O endereço IP da instância de origem está incorreto.
      • Existe 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.

   Você pode depurar o problema de conectividade usando Google CloudTestes 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, acesse a página Testes de conectividade .

      Vá para testes de conectividade

   2. Clique em Criar teste de conectividade .

   3. Insira um nome para o teste.

   4. Selecione TCP como protocolo.

   5. Selecione o 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 estiver acessível usando um endereço IP público; caso contrário, insira o endereço IP privado do proxy TCP.

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

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

   8. Clique em Criar .

   Execute o teste de conectividade e resolva quaisquer 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 .

      Acesse as instâncias de VM

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

   3. Se você vir a entrada de log Connection to source DB verified , 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 na conexão com a 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 falhar 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, você pode usar Google CloudTestes 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, acesse a página Testes de conectividade .

   Vá para testes de conectividade

2. Clique em Criar teste de conectividade .

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

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

4. Clique em Criar .

5. Execute o teste de conectividade e resolva quaisquer 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 do proxy TCP.

Coisas para 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.

Coisas para tentar

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

Solução de problemas de túnel SSH reverso

O tunelamento SSH é um método para encaminhar alguma comunicação sobre uma conexão SSH. O tunelamento SSH reverso permite configurar um túnel SSH, mas mantendo que a rede de destino é aquela que inicia a conexão do túnel. Isto é útil quando você não deseja abrir uma porta em 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

Supõe-se que:

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

• O source network bastion pode acessar o source DB (isso é feito por meio do peering da rede AlloyDB com a rede da VM do Compute Engine).

Em seguida, você configura um túnel SSH do source network bastion para o Compute Engine VM bastion , que roteia todas as conexões de entrada para alguma porta no Compute Engine VM bastion através do túnel até o source DB .

Cada link no cenário acima pode ser configurado incorretamente e impedir o funcionamento de todo o fluxo. Solucione problemas de cada link, um por um:

source network bastion ---> source DB

1. Conecte-se ao source network bastion usando SSH ou a partir do 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 xxxx .
   • [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 deste bastião 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 xxxx .
   • [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 sudo netstat -tupln mostra todos os processos de escuta nesta VM e você deverá ver sshd listening on the tunnel_port .

AlloyDB DB ---> source DB

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

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

Para encontrar o intervalo de IP interno no console:

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

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

3. Selecione a guia CONEXÃO DE SERVIÇO PRIVADO .

Você também pode visualizar o tráfego entre a instância do AlloyDB e a instância da VM do Compute Engine no console do Cloud Logging no projeto Cloud VPN gateway . Nos registros da VM do Compute Engine, procure o tráfego proveniente da instância do AlloyDB. Nos registros da instância do AlloyDB, procure o tráfego da VM do Compute Engine.

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