Métodos de Herramientas de redes

MySQL   |  PostgreSQL   |  PostgreSQL a AlloyDB

Descripción general

Para crear una migración en Database Migration Service, se debe establecer la conectividad entre la instancia de origen y la instancia de destino de AlloyDB. Se admiten varios métodos. Elige la que funcione mejor para la carga de trabajo específica.

Método de red	Descripción	Ventajas	Desventajas
Lista de IP de anunciantes permitidos	Este método funciona configurando el servidor de base de datos de origen para que acepte conexiones desde la IP saliente de la instancia de Cloud SQL. Si eliges este método, Database Migration Service te guía durante el proceso de configuración durante la creación de la migración.	Es fácil de configurar. No requiere ninguna configuración personalizada del firewall. Se recomienda para situaciones de migración de corta duración (POC o migraciones de bases de datos pequeñas).	El tráfico de red se produce a través de la Internet pública. Menos segura. Disminución del rendimiento
Proxy a través de VM alojada en la nube: túnel SSH inverso	Establece la conectividad del destino a la fuente a través de un túnel SSH inverso seguro. Requiere una VM de host de bastión en el proyecto de la plataforma de Google Cloud , así como una máquina (por ejemplo, una laptop en la red) que tenga conectividad con la fuente. Database Migration Service recopila la información necesaria en el momento de la creación de la migración y genera automáticamente la secuencia de comandos para configurar todo.	Es fácil de configurar. No requiere ninguna configuración personalizada del firewall. Se recomienda para situaciones de migración de corta duración (POC o migraciones de bases de datos pequeñas).	Tú eres el propietario y administrador de la VM de bastión, y es posible que se generen costos adicionales.
Proxy a través de VM alojada en la nube: TCP	Establece la conectividad del destino a la fuente con un proxy TCP a través de una VM alojada en la nube. Database Migration Service recopila la información necesaria en el momento de la creación de la migración y genera automáticamente la secuencia de comandos para configurar todo. Es relevante en las migraciones de AlloyDB en las que la fuente está en la arquitectura de red anterior.	Es fácil de configurar. No requiere ninguna configuración personalizada del firewall.	Tú eres el propietario y administrador de la VM de bastión, y es posible que se generen costos adicionales.
Intercambio de tráfico entre VPC	Este método funciona configurando las VPC para que se comuniquen entre sí.	Solución nativa de Google Cloud . Es fácil de configurar. Tiene un ancho de banda alto. Se recomienda para migraciones de larga duración o de alto volumen.	Se aplica si las bases de datos de origen y destino se alojan en Google Cloud, o si la fuente está conectada a la VPC de destino con una VPN (alojado en la nube o local) o Cloud Interconnect.

Limitaciones de conectividad

La conectividad de PostgreSQL a AlloyDB tiene las siguientes limitaciones:

• AlloyDB admite conectividad privada con el acceso privado a servicios. No se admite asignar una dirección IP pública a un clúster.
• No puedes cambiar la VPC con la que se establece el intercambio de tráfico entre el clúster de AlloyDB después de crearlo.
• Debido a que AlloyDB usa el acceso a servicios privados que, de forma interna, usa el intercambio de tráfico de VPC, no se admite el intercambio de tráfico transitivo. Tu clúster de AlloyDB solo puede alcanzar direcciones IP internas en la misma VPC con la que se establece la vinculación. Para llegar a otras VPC, debes usar un proxy intermediario. Para obtener más detalles, consulta la siguiente sección.

Situaciones y soluciones de conectividad comunes

Cómo migrar desde una instancia de Cloud SQL en la arquitectura de red de productor anterior

Figura 1. Una conexión privada facilitada por la VM de proxy de TCP (haz clic para ampliar)

Para migrar desde una instancia de Cloud SQL para PostgreSQL en la arquitectura de red de productor antigua, debes establecer la conectividad con un proxy intermediario. Esto se debe a que no es posible tener conectividad directa entre la instancia de Cloud SQL de origen y el destino de AlloyDB. Puedes configurar tu propia solución de proxy, aunque te recomendamos que configures la VM de proxy de TCP con la secuencia de comandos generada automáticamente que proporciona Database Migration Service. Consulta el método de conectividad del proxy TCP.

Migra desde una fuente en el mismo proyecto de Google Cloud , pero en un VPC diferente

Debido a que la VPC en la que reside el clúster de AlloyDB no se puede cambiar después de crearlo, tienes las siguientes opciones:

• La opción recomendada es cambiar la VPC de la instancia de origen para que coincida con la VPC de la instancia de destino. Por ejemplo, si deseas migrar una instancia de Cloud SQL a AlloyDB, actualiza la VPC de Cloud SQL para que coincida con la VPC de AlloyDB.

  Precaución: Configurar una dirección IP privada para una instancia de Cloud SQL existente hace que la instancia se reinicie, lo que causa un tiempo de inactividad.

• Si no es posible cambiar la VPC de la instancia de origen para que coincida con la VPC de la instancia de destino, usa una máquina virtual (VM) intermedia como proxy. Puedes configurar tu propia solución de proxy, aunque te recomendamos que uses el método de conectividad de proxy TCP. Después de que el servicio de migración de bases de datos genere tu secuencia de comandos en la consola de Google Cloud , agrega otra interfaz de red al comando para crear una instancia de proxy TCP y configúrala para que coincida con la VPC de la instancia de origen. De esta manera, el proxy tiene conectividad con las VPC de origen y destino.

  Para agregar otra interfaz de red, agrega --network-interface network=SOURCE_NETWORK_NAME al comando gcloud compute instances create-with-container que aparece en la secuencia de comandos.

  Nota: En el caso de las redes de VPC de modo personalizado, debes especificar la subred de forma explícita. El argumento que debes agregar es --network-interface network=SOURCE_NETWORK_NAME,subnet=SOURCE_SUBNET_NAME.

  Comando de ejemplo para crear el proxy:

    gcloud compute instances create-with-container … \
    --network-interface subnet=DESTINATION-SUBNET-NAME \
    --network-interface network=SOURCE-NETWORK-NAME

  Reemplaza lo siguiente:

  • DESTINATION-SUBNET-NAME: Es el nombre de la subred de destino.
  • SOURCE-NETWORK-NAME: Es el nombre de la red de origen.

Para obtener más información, consulta Crea instancias de VM con interfaces de red múltiples.

Cómo migrar a través de la Internet pública

Este método se recomienda cuando se migra desde una instancia local o desde otros proveedores de servicios en la nube, en los que no hay una conexión de VPN o de Interconnect existente a Google Cloud. Para usar este método, debes configurar tu clúster de AlloyDB de destino para que use una dirección IP pública saliente.

Migra desde una fuente en un proyecto de Google Cloud diferente

Para migrar desde una fuente en un proyecto de Google Cloud diferente, debes migrar a través de Internet o, para la conectividad interna de Google Cloud , usar una VPC compartida. Selecciona una de las siguientes opciones:

• Usa una VPC compartida sin un proxy. Si deseas que tu clúster de AlloyDB resida en una VPC compartida, simplemente selecciona la VPC en la que reside tu fuente cuando crees el clúster. De esta manera, la fuente y el destino tienen conectividad directa.

• Usa una VPC compartida con un proxy. Si no quieres que tu clúster de AlloyDB resida en una VPC compartida, debes usar un proxy intermediario. Puedes configurar tu propia solución de proxy, pero te recomendamos que uses el método de conectividad de proxy TCP. Sigue estos lineamientos para crear un proxy TCP con una interfaz de red adicional en una VPC compartida.

Migrar sin permitir que el destino llegue a la red de la fuente

Este método se recomienda cuando se migra desde una red local, en la que existe la preocupación de abrir el firewall de la red al tráfico entrante de Google Cloud . En este caso, puedes configurar un proxy inverso con una instancia de Compute Engine como proxy intermediario. Te recomendamos que uses el método de conectividad SSH inversa.