Debug della connettività

MySQL   |  PostgreSQL   |  PostgreSQL ad AlloyDB

Eseguire il debug della connettività

Hai configurato la connettività tra i database di origine e di destinazione, ma come fai a sapere che sono collegati? Quando le comunicazioni tra i due dispositivi non vanno a buon fine, come puoi scoprire cosa non va e dove?

Gli strumenti di base sono ping e traceroute.

Dindin

Ping esegue un test di base per determinare se la destinazione ("host remoto") è disponibile dall'origine. Ping invia un pacchetto ICMP Echo Request a un host remoto e si aspetta un ICMP Echo Reply in risposta. Se ping non va a buon fine, non esiste un percorso dall'origine alla destinazione. Tuttavia, il successo non significa che i pacchetti possono passare, ma solo che in generale l'host remoto può essere raggiunto.

Sebbene ping possa indicare se un host è attivo e risponde, non è garantito che sia affidabile. Alcuni fornitori di servizi di rete bloccano ICMP come misura di sicurezza, il che può rendere più difficile il debug della connettività.

Traceroute

Traceroute testa il percorso completo dei pacchetti di rete da un host a un altro. Mostra tutti i passaggi ("hop") che il pacchetto compie nel percorso e la durata di ogni passaggio. Se il pacchetto non arriva fino alla destinazione, traceroute non viene completato, ma termina con una serie di asterischi. In questo caso, cerca l'ultimo indirizzo IP raggiunto correttamente lungo il percorso. Qui si è interrotta la connettività.

Traceroute può scadere. Inoltre, la procedura potrebbe non essere completata se un gateway lungo il percorso non è configurato correttamente per trasmettere il pacchetto all'hop successivo.

Quando traceroute non riesce a completare l'operazione, potresti riuscire a capire dove si è interrotta. Individua l'ultimo indirizzo IP elencato nell'traceroute output e cerca who owns [IP_ADDRESS] nel browser. Nei risultati potrebbe o meno essere visualizzato il proprietario dell'indirizzo, ma vale la pena provare.

mtr

Lo strumento mtr è una forma di traceroute che rimane attiva e aggiornata continuamente, in modo simile al funzionamento del comando top per i processi locali.

Individuare l'indirizzo IP locale

Se non conosci l'indirizzo locale del tuo host, esegui il comandoip -br address show. Su Linux vengono mostrati l'interfaccia di rete, lo stato dell'interfaccia, l'IP locale e gli indirizzi MAC. Ad esempio: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64.

In alternativa, puoi eseguire ipconfig o ifconfig per visualizzare lo stato delle interfacce di rete.

Individua l'indirizzo IP in uscita

Se non conosci l'indirizzo IP utilizzato dai database di origine e di destinazione per comunicare tra loro (l'indirizzo IP in uscita), svolgi i seguenti passaggi:

1. Vai alla pagina Cluster AlloyDB nella console Google Cloud.

   Vai alla pagina dei cluster AlloyDB

2. Individua il cluster associato al job di migrazione di cui stai eseguendo il debug.

3. L'indirizzo IP in uscita dovrebbe essere visualizzato accanto al nome dell'istanza principale del cluster.

Aprire le porte locali

Per verificare che l'host ascolti sulle porte che ritieni, esegui il comando ss -tunlp4. Questo ti dice quali porte sono aperte e in ascolto. Ad esempio, se hai un database PostgreSQL in esecuzione, la porta 5432 dovrebbe essere attiva e in ascolto. Per SSH, dovresti vedere la porta 22.

Tutta l'attività della porta locale

Utilizza il comando netstat per visualizzare tutta l'attività della porta locale. Ad esempio, netstat -lt mostra tutte le porte attualmente attive.

Connettiti all'host remoto utilizzando telnet

Per verificare di poter connetterti all'host remoto utilizzando TCP, esegui il comando telnet. Telnet tenta di connettersi all'indirizzo IP e alla porta che specifichi.

Ad esempio, se l'host remoto esegue un database PostgreSQL, dovresti essere in grado di connetterti tramite telnet alla porta 5432:telnet 35.193.198.159 5432.

In caso di esito positivo, viene visualizzato quanto segue:

Trying 35.193.198.159...

Connected to 35.193.198.159. .

In caso di errore, viene visualizzato il messaggio telnet smette di rispondere finché non chiudi forzatamente il tentativo:

Trying 35.193.198.159...

^C. .

Autenticazione client

L'autenticazione client è controllata da un file di configurazione denominatopg_hba.conf (HBA sta per autenticazione basata sull'host).

Assicurati che la sezione delle connessioni di replica del file pg_hba.conf sul database di origine sia aggiornata in modo da accettare connessioni dall'intervallo di indirizzi IP del VPC di AlloyDB.

Cloud Logging

Database Migration Service e AlloyDB utilizzano Cloud Logging. Consulta la documentazione di Cloud Logging per informazioni complete e consulta le query di esempio di Cloud SQL.

Visualizza i log

Puoi visualizzare i log per le istanze AlloyDB e per altri progetti Google Cloudcome le istanze Cloud VPN o Compute Engine. Per visualizzare i log per le voci di log delle istanze AlloyDB:

Console

1. Vai a Esplora log
2. Seleziona un progetto AlloyDB esistente nella parte superiore della pagina.
3. In Query Builder, aggiungi quanto segue:
• Risorsa: seleziona Database AlloyDB. Nella finestra di dialogo, seleziona un'istanza AlloyDB.
• Nomi log: scorri fino alla sezione AlloyDB e seleziona i file di log appropriati per la tua istanza. Ad esempio:
  • alloydb.googlapis.com/postgres.log
• Gravità: seleziona un livello di log.
• Intervallo di tempo: seleziona un'impostazione predefinita o crea un intervallo personalizzato.

gcloud

Utilizza il comando gcloud logging per visualizzare le voci di log. Nell'esempio seguente, sostituisci PROJECT_ID. Il flag limit è un parametro facoltativo che indica il numero massimo di voci da restituire.

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

Risoluzione dei problemi relativi alla VPN

Consulta la pagina Google Cloud Risoluzione dei problemi relativi alla VPN Cloud.

Risolvere gli errori del proxy TCP

Anche il modo in cui è configurato il proxy TCP potrebbe comportare errori. Per risolvere un errore del proxy TCP, consulta i seguenti esempi di problemi e come risolverli:

Impossibile avviare la macchina virtuale (VM)

Quando avvii l'istanza VM in Compute Engine, viene visualizzato il seguente messaggio:

You do not currently have an active account selected.

Cose da provare

Esegui uno dei seguenti comandi per configurare un account attivo:

• Per ottenere nuove credenziali, esegui il seguente comando:

  gcloud auth login
  

• Per selezionare un account già autenticato, esegui il seguente comando:

  gcloud config set account ACCOUNT
  

  Sostituisci ACCOUNT con il nome dell'account da configurare.

Connessione non riuscita all'istanza del database di origine

Quando testi il job di migrazione, viene visualizzato il seguente messaggio di errore:

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

Cose da provare

Esegui i seguenti passaggi per capire dove potrebbe risiedere il problema:

1. Verifica se la VM che ospita il container proxy TCP è in esecuzione:

   1. Nella console, vai alla pagina Istanze VM di Compute Engine.

      Vai a Istanze VM

   2. Cerca la VM creata durante la procedura di configurazione del proxy. Se non è presente nell'elenco o non è in esecuzione, configura il proxy TCP da zero e aggiorna le impostazioni dell'istanza di origine nel job di migrazione con l'indirizzo IP corretto.

2. Se la VM è in esecuzione, verifica che non sia stato rilevato alcun errore durante il download dell'immagine del contenitore del proxy TCP:

   1. Seleziona la VM creata durante la procedura di configurazione del proxy TCP. In Log, fai clic su Porta seriale 1 (console).

   2. Se non riesci a vedere la voce Launching user container 'gcr.io/dms-images/tcp-proxy' nei log, il problema potrebbe essere che l'istanza non è riuscita a estrarre l'immagine da Container Registry. Per verificare se è così, connettiti alla VM e prova a estrarre manualmente l'immagine da Container Registry utilizzando il seguente comando:

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

      Se visualizzi il seguente errore: Error response from daemon: Get "https://gcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers), significa che la VM non è riuscita a connettersi a Container Registry. Se la VM ha solo un indirizzo IP privato, devi abilitare l'accesso privato Google nella subnet di cui fa parte l'indirizzo IP; in caso contrario, la VM non avrà accesso alle API Google Enterprise, come Container Registry.

3. Verifica che il contenitore possa connettersi all'istanza di origine:

   1. Seleziona la VM creata durante la procedura di configurazione del proxy. In Log, fai clic su Cloud Logging.

   2. Se viene visualizzato il seguente messaggio: Connection refused, please verify that the machine you are using to run the script can connect to the source database at, significa che il contenitore del proxy TCP non è riuscito a connettersi all'istanza del database di origine. Ciò può accadere per diversi motivi:

      • L'indirizzo IP dell'istanza di origine non è corretto.
      • Esiste un criterio del firewall che rifiuta le connessioni dal proxy TCP all'istanza di origine.
      • L'istanza di origine si trova in una rete Virtual Private Cloud (VPC) diversa da quella della VM che ospita il proxy TCP.

   Puoi eseguire il debug del problema di connettività utilizzando i test di connettività di Google Cloudper assicurarti che esista connettività tra il database di destinazione e la VM che ospita il proxy TCP:

   1. Nella console, vai alla pagina Test di connettività.

      Vai a Connectivity Tests

   2. Fai clic su Crea test di connettività.

   3. Inserisci un nome per il test.

   4. Seleziona TCP come protocollo.

   5. Seleziona Indirizzo IP dall'elenco Endpoint di origine. Inserisci l'indirizzo IP pubblico del proxy TCP appena creato se il database di origine è accessibile utilizzando un indirizzo IP pubblico; in caso contrario, inserisci l'indirizzo IP privato del proxy TCP.

   6. Seleziona Indirizzo IP dall'elenco Endpoint di destinazione e inserisci l'indirizzo IP del database di origine.

   7. Inserisci il numero di porta utilizzato per connetterti al database di origine nel campo Porta di destinazione.

   8. Fai clic su Crea.

   Esegui il test di connettività e risolvi eventuali problemi di connettività. Dopo aver risolto il problema di connettività, verifica che il proxy TCP possa connettersi all'istanza di origine:

   1. Vai a Istanze VM in Compute Engine.

      Vai a Istanze VM

   2. Seleziona la VM creata durante la procedura di configurazione del proxy. In Log, fai clic su Cloud Logging.

   3. Se vedi la voce di log Connection to source DB verified, significa che il proxy TCP ora può connettersi all'istanza di origine.

4. Verifica che il test di migrazione non abbia esito negativo a causa di problemi di connessione.

Connessione all'istanza del database di destinazione non riuscita

Se il contenitore proxy TCP può connettersi all'istanza di origine, ma il test di migrazione continua a non riuscire a causa di problemi di connessione, il problema potrebbe riguardare la connettività tra l'istanza di destinazione e la VM che ospita il contenitore proxy TCP.

Eseguire il debug del problema

Per eseguire il debug del problema, puoi utilizzare i test di connettività di Google Cloudper assicurarti che esista connettività tra il database di destinazione e la VM che ospita il proxy TCP:

1. Nella console, vai alla pagina Test di connettività.

   Vai a Connectivity Tests

2. Fai clic su Crea test di connettività.

3. Imposta i seguenti parametri per il test:

   1. Inserisci un nome per il test.
   2. Seleziona TCP come protocollo.
   3. Seleziona Indirizzo IP dall'elenco Endpoint di origine e inserisci l'indirizzo IP del cluster AlloyDB appena creato.
   4. Seleziona Indirizzo IP dall'elenco Endpoint di destinazione e inserisci l'indirizzo IP privato del proxy TCP.
   5. Inserisci 5432 nel campo Porta di destinazione.

4. Fai clic su Crea.

5. Esegui il test di connettività e risolvi eventuali problemi.

Possibili cause

Esiste una regola firewall che nega la comunicazione tra l'istanza di destinazione e la VM proxy TCP.

Cose da provare

Aggiungi una regola firewall che consenta all'istanza di destinazione di comunicare con il proxy TCP utilizzando la porta 5432.

Possibili cause

Esiste una mancata corrispondenza del VPC tra l'istanza di destinazione e la VM che esegue il contenitore del proxy TCP.

Cose da provare

Seleziona lo stesso VPC per l'istanza di destinazione.

Risolvere i problemi relativi al tunnel SSH inverso

Il tunneling SSH è un metodo per inoltrare alcune comunicazioni su una connessione SSH. Il tunneling SSH inverso consente di configurare un tunnel SSH, mantenendo la rete di destinazione come quella che avvia la connessione del tunnel. Questa opzione è utile se non vuoi aprire una porta nella tua rete per motivi di sicurezza.

Stai cercando di configurare quanto segue: AlloyDB DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Sebbene Database Migration Service esegui la migrazione dei dati da un'origine a una destinazione, devi attivare la connettività dalla destinazione all'origine.

Si presume che:

• AlloyDB destination può accedere a Compute Engine VM bastion.

• source network bastion può accedere a source DB (questo viene ottenuto collegando in peering la rete AlloyDB alla rete della VM Compute Engine).

Poi configuri un tunnel SSH dal source network bastion al Compute Engine VM bastion, che inoltra le connessioni in arrivo a qualche porta sul Compute Engine VM bastion tramite il tunnel al source DB.

Ogni link nello scenario precedente può essere configurato in modo errato e impedire il funzionamento dell'intero flusso. Risolvi i problemi relativi a ogni link, uno alla volta:

source network bastion ---> source DB

1. Connettiti a source network bastion tramite SSH o dal terminale se si tratta della macchina locale.
2. Verifica la connettività al database di origine utilizzando uno dei seguenti metodi:
   • telnet [source_db_host_or_ip] [source_db_port]: dovresti vedere le stringhe di connessione telnet, che terminano con Connected to x.x.x.x.
   • [db_client] -h[source_db_host_or_ip] -P[source_db_port] - dovrebbe essere visualizzato Accesso negato

Se la verifica non va a buon fine, devi verificare di aver attivato l'accesso da questo bastione al DB di origine.

Compute Engine VM bastion ---> source DB

1. Accedi tramite SSH a Compute Engine VM bastion (utilizzando gcloud compute ssh VM_INSTANCE_NAME)
2. Verifica la connettività al database di origine utilizzando uno dei seguenti metodi:
   • telnet 127.0.0.1 [tunnel_port]: dovresti visualizzare le stringhe di connessione telnet, che terminano con Connected to x.x.x.x.
   • [db_client] -h127.0.0.1 -P[tunnel_port]: dovresti visualizzare accesso denied

Se l'operazione non va a buon fine, devi verificare che il tunnel sia attivo e in esecuzione correttamente. L'esecuzione di sudo netstat -tupln mostra tutti i processi di ascolto su questa VM e dovresti vedere sshd listening on the tunnel_port.

AlloyDB DB ---> source DB

Questo test è meglio eseguito da testing the migration job di Database Migration Service. Se l'operazione non va a buon fine, significa che c'è un problema con il peering o il routing VPC tra la rete AlloyDB e la rete Compute Engine VM bastion.

Il firewall del server di database di origine deve essere configurato in modo da consentire l'intero intervallo IP interno allocato per la connessione al servizio privato della rete VPC che l'istanza di destinazione AlloyDB utilizzerà come campo privateNetwork delle impostazioni ipConfiguration.

Per trovare l'intervallo IP interno nella console:

1. Vai alla pagina Reti VPC nella console Google Cloud .

2. Seleziona la rete VPC che vuoi utilizzare.

3. Seleziona la scheda CONNESSIONE A SERVIZI PRIVATI.

Puoi anche visualizzare il traffico tra l'istanza AlloyDB e l'istanza VM Compute Engine nella console Cloud Logging del progetto Cloud VPN gateway. Nei log della VM Compute Engine, cerca il traffico proveniente dall'istanza AlloyDB. Nei log dell'istanza AlloyDB, cerca il traffico proveniente dalla VM Compute Engine.