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 "Instâncias do SQL" no console do Google Cloud.
Clique no nome da instância associada ao job de migração que você está depurando.
Role para baixo até que o painel Conectar a esta instância apareça. Nesse painel, o endereço IP de saída aparece.
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 houver um banco de dados MySQL em execução, a porta 3306 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 3306.
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.
Cloud Logging
O Database Migration Service e o Cloud SQL 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 Cloud SQL e de outros projetos do Google Cloud, como as instâncias do Cloud VPN ou do Compute Engine. Para ver as entradas de registro da instância do Cloud SQL, faça o seguinte:Console
- Acesse o Explorador de registros
- Selecione um projeto do Cloud SQL na parte superior da página.
- No criador de consultas, adicione o seguinte:
- Recurso: selecione Banco de dados do Cloud SQL. Na caixa de diálogo, selecione uma instância do Cloud SQL.
- Nomes de registros: vá até a seção do Cloud SQL e selecione
os arquivos de registro correspondentes à instância. Exemplo:
- cloudsql.googlapis.com/mysql-general.log
- cloudsql.googleapis.com/mysql.err
- 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/cloudsql.googleapis.com/mysql-general.log" --limit=10
Endereços IP particulares
As conexões com uma instância do Cloud SQL usando um endereço IP privado são
autorizadas automaticamente para intervalos de endereços
RFC 1918. Os intervalos de endereços não RFC 1918 precisam ser configurados
no Cloud SQL como redes
autorizadas. É necessário atualizar o peering de rede para o Cloud SQL
exportar rotas que não sejam RFC 1918. Exemplo:
gcloud compute networks peerings update cloudsql-mysql-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
O intervalo de IP 172.17.0.0/16 é reservado para a rede de ponte do Docker. Todas as instâncias do Cloud SQL criadas com um IP nesse intervalo ficarão inacessíveis. As conexões vindas de qualquer endereço IP dentro desse intervalo para instâncias do Cloud SQL que usam endereço IP particular falharão.
Solução de problemas de VPN
Consulte a página Google Cloud Solução de problemas da VPN do Cloud.
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: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Supõe-se que:
O Compute Engine VM bastion pode acessar o Cloud SQL DB.
O source network bastion pode acessar o source DB. Isso é feito ao estabelecer o peering da rede do Cloud SQL 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]: espera-se que o prompt de senha do MySQL seja exibido (algo como5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection).[db_client] -h[source_db_host_or_ip] -P[source_db_port]: espere que o acesso seja negado (algo comoERROR 1045 (28000): Access denied for user...).
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 que o prompt de senha do MySQL apareça (algo como5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection).[db_client] -h127.0.0.1 -P[tunnel_port]: o acesso será negado (algo comoERROR 1045 (28000): Access denied for user...).
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.
Cloud SQL 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 o roteamento da VPC
entre a rede do Cloud SQL 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 Cloud SQL 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 Cloud SQL e a instância de VM do Compute Engine no console do Cloud Logging no projeto Cloud VPN gateway. Nos registros de VM do Compute Engine,
procure o tráfego proveniente da instância do Cloud SQL. Nos registros da instância do Cloud SQL, procure o tráfego da VM do Compute Engine.