Conectividad de depuración

Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Conectividad de depuración

Ha configurado la conectividad entre sus bases de datos de origen y de destino, pero ¿cómo sabe que están conectadas? Cuando fallan las comunicaciones entre ellos, ¿cómo puedes saber qué salió mal y dónde?

Las herramientas más básicas son ping y traceroute .

Silbido

Ping realiza una prueba básica para determinar si el destino ("host remoto") está disponible desde el origen. Ping envía un paquete ICMP Echo Request a un host remoto y espera a cambio una ICMP Echo Reply . Si ping no tiene éxito, entonces no hay ruta desde el origen al destino. Sin embargo, el éxito no significa que sus paquetes puedan pasar, sólo que, en general, se puede alcanzar el host remoto.

Si bien ping puede indicar si un host está activo y respondiendo, no se garantiza que sea confiable. Algunos proveedores de red bloquean ICMP como medida de seguridad, lo que puede dificultar la depuración de la conectividad.

ruta de seguimiento

Traceroute prueba la ruta completa que toman los paquetes de red de un host a otro. Muestra todos los pasos ("saltos") que realiza el paquete a lo largo del camino y cuánto tiempo lleva cada paso. Si el paquete no llega hasta el destino, traceroute no se completa, sino que termina con una serie de asteriscos. En este caso, busque la última dirección IP a la que se llegó con éxito en el camino. Aquí es donde se rompió la conectividad.

Traceroute puede expirar. También puede no completarse si una puerta de enlace en el camino no está configurada correctamente para pasar el paquete al siguiente salto.

Cuando traceroute no se completa, es posible que puedas averiguar dónde se detuvo. Encuentre la última dirección IP que aparece en la salida traceroute y realice una búsqueda en el navegador para saber who owns [IP_ADDRESS] . Los resultados pueden mostrar o no al propietario de la dirección, pero vale la pena intentarlo.

metro

La herramienta mtr es una forma de traceroute que permanece activa y actualizada continuamente, de forma similar a cómo funciona el comando top para procesos locales.

Localice su dirección IP local

Si no conoce la dirección local de su host, ejecute el comando ip -br address show . En Linux, esto muestra la interfaz de red, el estado de la interfaz, las direcciones IP y MAC locales. Por ejemplo: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64 .

Alternativamente, puede ejecutar ipconfig o ifconfig para ver el estado de sus interfaces de red.

Localice la dirección IP saliente

Si no conoce la dirección IP que utilizan las bases de datos de origen y de destino para comunicarse entre sí (la dirección IP saliente), complete los siguientes pasos:

1. Vaya a la página de clústeres de AlloyDB en el Google Cloud console.

   Vaya a la página de clústeres de AlloyDB

2. Localice el clúster asociado con el trabajo de migración que está depurando.

3. La IP saliente debería aparecer junto al nombre de la instancia principal del clúster.

Abrir puertos locales

Para verificar que su host esté escuchando en los puertos que cree, ejecute el comando ss -tunlp4 . Esto le indica qué puertos están abiertos y escuchando. Por ejemplo, si tiene una base de datos PostgreSQL en ejecución, entonces el puerto 5432 debería estar activo y escuchando. Para SSH, debería ver el puerto 22.

Toda la actividad portuaria local

Utilice el comando netstat para ver toda la actividad del puerto local. Por ejemplo, netstat -lt muestra todos los puertos actualmente activos.

Conéctese al host remoto usando telnet

Para verificar que puede conectarse al host remoto mediante TCP , ejecute el comando telnet . Telnet intenta conectarse a la dirección IP y al puerto que usted le proporciona.

Si tiene éxito, verá lo siguiente: Intentando 35.193.198.159...

Conectado al 35.193.198.159. .

En caso de error, verá que telnet deja de responder hasta que fuerce el cierre del intento: Intentando 35.193.198.159...

^C. .

Autenticación de cliente

La autenticación del cliente está controlada por un archivo de configuración llamado pg_hba.conf (HBA significa autenticación basada en host).

Asegúrese de que la sección de conexiones de replicación del archivo pg_hba.conf en la base de datos de origen esté actualizada para aceptar conexiones del rango de direcciones IP de AlloyDB VPC.

Registro en la nube

Ver registros

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

Solución de problemas de VPN

Ver elGoogle Cloud Página de solución de problemas de Cloud VPN .

Solucionar errores de proxy TCP

La forma en que está configurado el proxy TCP también puede generar errores. Para solucionar un error de proxy TCP, consulte los siguientes ejemplos de problemas y cómo se pueden resolver:

Error al iniciar la máquina virtual (VM)

Verá el siguiente mensaje al iniciar la instancia de VM en Compute Engine:

You do not currently have an active account selected.

Cosas para probar

Ejecute uno de los siguientes comandos para configurar una cuenta activa:

• Para obtener nuevas credenciales, ejecute el siguiente comando:

  gcloud auth login
  

• Para seleccionar una cuenta ya autenticada, ejecute el siguiente comando:

  gcloud config set account ACCOUNT
  

  Reemplace ACCOUNT con el nombre de la cuenta que desea configurar.

Error al conectarse a la instancia de la base de datos de origen

Verá el siguiente mensaje de error al probar el trabajo de migración:

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

Cosas para probar

Repita los siguientes pasos para comprender dónde podría estar el problema:

1. Compruebe si la VM que aloja el contenedor de proxy TCP se está ejecutando:

   1. En la consola, ve a la página de instancias de VM de Compute Engine.

      Ir a instancias de VM

   2. Busque la máquina virtual que se creó como parte del proceso de configuración del proxy. Si no aparece en la lista o no se está ejecutando, configure su proxy TCP desde cero y actualice la configuración de la instancia de origen en el trabajo de migración con la dirección IP correcta.

2. Si la VM se está ejecutando, verifique que no hubo ningún error al descargar la imagen del contenedor del proxy TCP:

   1. Seleccione la máquina virtual que se creó como parte del proceso de configuración del proxy TCP. En Registros , haga clic en Puerto serie 1 (consola) .

   2. Si no puede ver la entrada Launching user container 'gcr.io/dms-images/tcp-proxy' en los registros, el problema podría ser que su instancia no pudo extraer la imagen de Container Registry . Para verificar si este es el caso, conéctese a la VM e intente extraer manualmente la imagen de Container Registry usando el siguiente comando:

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

      Si ve el siguiente error: 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 su VM no pudo conectarse a Container Registry. Si su VM solo tiene una dirección IP privada, debe habilitar el acceso privado a Google en la subred de la que forma parte la dirección IP; de lo contrario, la VM no tendrá acceso a las API de Google Enterprise , como Container Registry.

3. Verifique que el contenedor pueda conectarse a la instancia de origen:

   1. Seleccione la VM que se creó como parte del proceso de configuración del proxy. En Registros , haga clic en Registro en la nube .

   2. Si ve el siguiente mensaje: Connection refused, please verify that the machine you are using to run the script can connect to the source database at , significa que el contenedor proxy TCP no pudo conectarse a la instancia de la base de datos de origen. Puede haber varias razones para que esto suceda:

      • La dirección IP de la instancia de origen es incorrecta.
      • Existe una política de firewall que rechaza las conexiones desde el proxy TCP a la instancia de origen.
      • La instancia de origen está en una red de nube privada virtual (VPC) diferente a la de la máquina virtual que aloja el proxy TCP.

   Puede depurar el problema de conectividad usando Google CloudPruebas de conectividad para asegurarse de que haya conectividad entre la base de datos de destino y la máquina virtual que aloja el proxy TCP:

   1. En la consola, vaya a la página Pruebas de conectividad .

      Ir a Pruebas de Conectividad

   2. Haga clic en Crear prueba de conectividad .

   3. Introduzca un nombre para la prueba.

   4. Seleccione TCP como protocolo.

   5. Seleccione la dirección IP de la lista Punto final de origen . Ingrese la dirección IP pública del proxy TCP recién creado si se puede acceder a la base de datos de origen mediante una dirección IP pública; de lo contrario, ingrese la dirección IP privada del proxy TCP.

   6. Seleccione la dirección IP de la lista Punto final de destino e ingrese la dirección IP de la base de datos de origen.

   7. Ingrese el número de puerto utilizado para conectarse a la base de datos de origen en el campo Puerto de destino .

   8. Haga clic en Crear .

   Ejecute la prueba de conectividad y solucione cualquier problema de conectividad que surja. Después de solucionar el problema de conectividad, verifique que el proxy TCP pueda conectarse a la instancia de origen:

   1. Vaya a instancias de VM en Compute Engine .

      Ir a instancias de VM

   2. Seleccione la VM que se creó como parte del proceso de configuración del proxy. En Registros , haga clic en Registro en la nube .

   3. Si ve la entrada de registro Connection to source DB verified , significa que el proxy TCP ahora puede conectarse a la instancia de origen.

4. Verifique que la prueba de migración no falle por problemas de conexión.

Error al conectarse a la instancia de la base de datos de destino

Si el contenedor de proxy TCP puede conectarse a la instancia de origen, pero la prueba de migración aún falla debido a problemas de conexión, el problema podría ser la conectividad entre la instancia de destino y la máquina virtual que aloja el contenedor de proxy TCP.

Depurar el problema

Para depurar el problema, puede utilizar Google CloudPruebas de conectividad para asegurarse de que haya conectividad entre la base de datos de destino y la máquina virtual que aloja el proxy TCP:

1. En la consola, vaya a la página Pruebas de conectividad .

   Ir a Pruebas de Conectividad

2. Haga clic en Crear prueba de conectividad .

3. Establezca los siguientes parámetros para su prueba:

   1. Introduzca un nombre para la prueba.
   2. Seleccione TCP como protocolo.
   3. Seleccione la dirección IP de la lista Punto final de origen e ingrese la dirección IP del clúster AlloyDB recién creado.
   4. Seleccione la dirección IP de la lista Punto final de destino e ingrese la dirección IP privada del proxy TCP.
   5. Ingrese 5432 en el campo Puerto de destino .

4. Haga clic en Crear .

5. Ejecute la prueba de conectividad y solucione cualquier problema de conectividad que surja.

Posibles causas

Existe una regla de firewall que deniega la comunicación entre la instancia de destino y la VM del proxy TCP.

Cosas para probar

Agregue una regla de firewall que permita que la instancia de destino se comunique con el proxy TCP mediante el puerto 5432.

Posibles causas

Hay una discrepancia de VPC entre la instancia de destino y la VM que ejecuta el contenedor de proxy TCP.

Cosas para probar

Seleccione la misma VPC para la instancia de destino.

Solución de problemas del túnel SSH inverso

El túnel SSH es un método para reenviar alguna comunicación sobre una conexión SSH. El túnel SSH inverso permite configurar un túnel SSH, pero manteniendo que la red de destino es la que inicia la conexión del túnel. Esto es útil cuando no desea abrir un puerto en su propia red por motivos de seguridad.

Lo que está tratando de lograr es configurar lo siguiente: AlloyDB DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Se supone que:

• El AlloyDB destination puede acceder al Compute Engine VM bastion .

• El source network bastion puede acceder a la source DB (esto se logra conectando la red AlloyDB a la red de VM de Compute Engine).

Luego, configura un túnel SSH desde el source network bastion hasta el Compute Engine VM bastion , que enruta cualquier conexión entrante a algún puerto en el Compute Engine VM bastion a través del túnel hasta la source DB .

Cada enlace en el escenario anterior se puede configurar incorrectamente e impedir que funcione todo el flujo. Solucione los problemas de cada enlace, uno por uno:

source network bastion ---> source DB

1. Conéctese al source network bastion mediante SSH, o desde la terminal si es la máquina local.
2. Pruebe la conectividad con la base de datos de origen utilizando uno de los siguientes métodos:
   • telnet [source_db_host_or_ip] [source_db_port] - espere ver las cadenas de conexión de telnet, que terminan en Connected to xxxx .
   • [db_client] -h[source_db_host_or_ip] -P[source_db_port] - espera ver acceso denegado

Si esto falla, entonces deberá verificar que haya habilitado el acceso desde este bastión a la base de datos de origen.

Compute Engine VM bastion ---> source DB

1. SSH al Compute Engine VM bastion (usando gcloud compute ssh VM_INSTANCE_NAME )
2. Pruebe la conectividad con la base de datos de origen utilizando uno de los siguientes métodos:
   • telnet 127.0.0.1 [tunnel_port] : espere ver las cadenas de conexión de telnet, que terminan en Connected to xxxx .
   • [db_client] -h127.0.0.1 -P[tunnel_port] - espera ver acceso denegado

Si esto falla, entonces deberá verificar que el túnel esté funcionando correctamente. La ejecución sudo netstat -tupln muestra todos los procesos de escucha en esta máquina virtual y debería ver sshd listening on the tunnel_port .

AlloyDB DB ---> source DB

Esto se prueba mejor testing the migration job desde el Servicio de migración de bases de datos. Si esto falla, significa que hay algún problema con el emparejamiento o el enrutamiento de VPC entre la red AlloyDB y la red Compute Engine VM bastion .

El firewall del servidor de la base de datos de origen debe configurarse para permitir todo el rango de IP interno asignado para la conexión de servicio privado de la red VPC que la instancia de destino de AlloyDB va a utilizar como el campo privateNetwork de su configuración de ipConfiguration .

Para encontrar el rango de IP interno en la consola:

1. Vaya a la página de redes VPC en el Google Cloud consola.

2. Seleccione la red VPC que desea utilizar.

3. Seleccione la pestaña CONEXIÓN DE SERVICIO PRIVADO .

También puedes ver el tráfico entre la instancia de AlloyDB y la instancia de VM de Compute Engine en la consola de Cloud Logging en el proyecto Cloud VPN gateway . En los registros de Compute Engine VM, busque el tráfico proveniente de la instancia de AlloyDB. En los registros de la instancia de AlloyDB, busque el tráfico de la VM de Compute Engine.

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