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 as comunicações entre eles falham, como você pode 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 a um host remoto e espera que um
ICMP Echo Reply seja retornado. Se ping não tiver êxito,
isso significa que não há rota da origem até o destino. O sucesso, 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:
Acesse a página de clusters do AlloyDB no console do Google Cloud.
Localize o cluster associado ao job de migração que você está depurando.
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 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ê.
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, telnet para de responder até que você force o encerramento
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 conferir os registros das instâncias do AlloyDB e de outros projetos do Google Cloud, como as instâncias do Cloud VPN ou do Compute Engine. Para conferir os registros das entradas de registro da instância do AlloyDB:Console
- Acesse o Explorador de registros
- Selecione um projeto do AlloyDB na parte de cima da página.
- 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 registro: role até a seção do AlloyDB e selecione os arquivos de registro apropriados para sua 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 sinalização limit
é 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 da VPN do Cloud.
Resolver erros de proxy TCP
A forma como o proxy TCP é configurado também pode gerar erros. Para resolver um erro de proxy TCP, consulte os exemplos de problemas a seguir 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 loginPara selecionar uma conta já autenticada, execute o seguinte comando:
gcloud config set account ACCOUNTSubstitua ACCOUNT pelo nome da conta que você quer configurar.
Falha ao se conectar à instância do banco de dados de origem
Você vai receber a seguinte mensagem de erro 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
Siga as etapas abaixo para entender onde o problema pode estar:
Verifique se a VM que hospeda o contêiner do proxy TCP está em execução:
No console, acesse a página Instâncias de VM do Compute Engine.
Pesquise a VM que foi criada como parte do processo de configuração do proxy. Se ele não estiver listado 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.
Se a VM estiver em execução, verifique se não houve erros ao fazer o download da imagem do contêiner do proxy TCP:
- Selecione a VM que foi criada como parte do processo de configuração do proxy TCP. Em Registros, clique em Porta serial 1 (console).
Se a entrada
Launching user container 'gcr.io/dms-images/tcp-proxy'não aparecer nos registros, talvez a instância não tenha extraído 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-proxySe 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), significa que a VM não conseguiu se conectar ao Container Registry. Se a VM tiver apenas um endereço IP privado, ative o Acesso privado do Google na sub-rede em que o endereço IP está incluído. Caso contrário, a VM não terá acesso às APIs Enterprise do Google, como o Container Registry.
Verifique se o contêiner pode se conectar à instância de origem:
Selecione a VM que foi criada como parte do processo de configuração do proxy. Em Registros, clique em Cloud Logging.
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, significa que o contêiner de proxy TCP não conseguiu se conectar à instância do banco de dados de origem. Isso pode acontecer por vários motivos:- O endereço IP da instância de origem está incorreto.
- Há uma política de firewall que recusa conexões do proxy TCP para 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 os Testes de conectividade do Google Cloudpara garantir que haja conectividade entre o banco de dados de destino e a VM que hospeda o proxy TCP:
No console, acesse a página Testes de conectividade.
Clique em Criar teste de conectividade.
Insira um nome para o teste.
Selecione TCP como o protocolo.
Selecione Endereço IP na lista Endpoint de origem. Digite 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, digite o endereço IP particular do proxy TCP.
Selecione Endereço IP na lista Endpoint de destino e insira o endereço IP do banco de dados de origem.
Insira o número da porta usada para se conectar ao banco de dados de origem no campo Porta de destino.
Clique em Criar.
Execute o teste de conectividade e resolva os problemas que surgirem. Depois de corrigir o problema de conectividade, verifique se o proxy TCP pode se conectar à instância de origem:
Acesse Instâncias de VM no Compute Engine.
Selecione a VM que foi criada como parte do processo de configuração do proxy. Em Registros, clique em Cloud Logging.
Se você encontrar a entrada de registro
Connection to source DB verified, significa que o proxy TCP agora pode se conectar à instância de origem.
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 conseguir se conectar à instância de origem, mas o teste de migração ainda falhar devido a problemas de conexão, o problema pode 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 os Testes de conectividade do Google Cloudpara garantir que haja conectividade entre o banco de dados de destino e a VM que hospeda o proxy TCP:
No console, acesse a página Testes de conectividade.
Clique em Criar teste de conectividade.
Defina os seguintes parâmetros para o teste:
- Insira um nome para o teste.
- Selecione TCP como o protocolo.
- Selecione Endereço IP na lista Endpoint de origem e insira o endereço IP do cluster do AlloyDB recém-criado.
- Selecione Endereço IP na lista Endpoint de destino e insira o endereço IP particular do proxy TCP.
- Digite 5432 no campo Porta de destino.
Clique em Criar.
Execute o teste de conectividade e resolva os problemas que surgirem.
Possíveis causas
Há uma regra de firewall que nega a comunicação entre a instância de destino e a VM 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 do proxy TCP.
O que tentar
Selecione a mesma VPC para a instância de destino.
Solução de problemas do túnel SSH reverso
O tunelamento de 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 que a rede de destino é 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 fazer é 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 ao estabelecer o peering da rede AlloyDB com a rede de VM do Compute Engine.
Em seguida, você configura um túnel SSH do source network bastion para o Compute Engine VM bastion, que encaminha todas as conexões recebidas para uma 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 os problemas de cada link, um por um:
source network bastion ---> source DB
- Conecte-se ao source network bastion usando SSH ou pelo terminal, se for a máquina local.
- Teste a conectividade com o DB de origem usando um dos seguintes métodos:
telnet [source_db_host_or_ip] [source_db_port]: espere encontrar as strings de conexão do telnet, que terminam comConnected to x.x.x.x.[db_client] -h[source_db_host_or_ip] -P[source_db_port]: espere que o acesso seja negado
Se isso falhar, verifique se você ativou o acesso a partir desse bastion para o DB de origem.
Compute Engine VM bastion ---> source DB
- SSH para o Compute Engine VM bastion (usando
gcloud compute ssh VM_INSTANCE_NAME) - Teste a conectividade com o banco de dados de origem usando um dos seguintes métodos:
telnet 127.0.0.1 [tunnel_port]: espere encontrar as strings de conexão do telnet, que terminam comConnected to x.x.x.x.[db_client] -h127.0.0.1 -P[tunnel_port]: o acesso será negado.
Se isso falhar, verifique se o túnel está ativo e funcionando corretamente.
A execução de sudo netstat -tupln mostra todos os processos de detecção nesta VM, e você vai encontrar sshd listening on the tunnel_port.
AlloyDB DB ---> source DB
O melhor teste é feito com testing the migration job do Database Migration Service.
Se isso falhar, significa que há algum problema com o peering ou roteamento da VPC
entre a rede AlloyDB e a rede Compute Engine VM bastion.
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:
Acesse a página "Redes VPC" no console do Google Cloud .
Selecione a rede VPC que você quer usar.
Selecione a guia CONEXÃO DE SERVIÇO PARTICULAR.
Também é possível conferir o tráfego entre a instância do AlloyDB e a instância de 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.