Patrones para usar direcciones IP flotantes en Compute Engine

Last reviewed 2025-02-03 UTC

En este documento se describe cómo usar patrones de implementación de direcciones IP flotantes al migrar aplicaciones a Compute Engine desde un entorno de red local. Este documento está dirigido a ingenieros de redes, administradores de sistemas e ingenieros de operaciones que estén migrando aplicaciones aGoogle Cloud.

Las direcciones IP flotantes, también denominadas direcciones IP compartidas o virtuales, se suelen usar para que los entornos de red locales tengan una alta disponibilidad. Con las direcciones IP flotantes, puedes transferir una dirección IP entre varios servidores físicos o virtuales configurados de forma idéntica. Esta práctica permite la conmutación por error o la actualización del software de producción. Sin embargo, no puedes implementar directamente direcciones IP flotantes en un entorno de Compute Engine sin cambiar la arquitectura a uno de los patrones descritos en este documento.

El repositorio de GitHub que acompaña a este documento incluye implementaciones de ejemplo para cada patrón que puedes implementar automáticamente con Terraform.

Direcciones IP flotantes en entornos locales

Las direcciones IP flotantes se suelen usar en entornos locales. Estos son algunos ejemplos de casos prácticos:

Hay varias formas de implementar direcciones IP flotantes en un entorno local. Los servidores que comparten direcciones IP flotantes también suelen compartir información de estado a través de un mecanismo de latido. Este mecanismo permite que los servidores comuniquen su estado entre sí y que el servidor secundario tome el control de la dirección IP flotante después de que falle el servidor principal. Este esquema se suele implementar mediante el protocolo de redundancia de router virtual, pero también puedes usar otros mecanismos similares.

Una vez que se inicia la conmutación por error de una dirección IP, el servidor que se hace cargo de la dirección IP flotante añade la dirección a su interfaz de red. El servidor anuncia esta toma de control a otros dispositivos mediante la capa 2 enviando un marco de protocolo de resolución de direcciones (ARP) gratuito. También puede ocurrir que un protocolo de enrutamiento como Open Shortest Path First (OSPF) anuncie la dirección IP al router de capa 3 superior.

En el siguiente diagrama se muestra una configuración habitual en un entorno local.

Entorno local típico.

En el diagrama anterior se muestra cómo un servidor principal y un servidor secundario conectados al mismo conmutador intercambian información de respuesta mediante un mecanismo de latido. Si falla el servidor principal, el servidor secundario envía un marco ARP gratuito al conmutador para hacerse cargo de la dirección IP flotante.

Utilizas una configuración ligeramente diferente con soluciones de balanceo de carga on-premise, como el balanceo de carga de red de Windows o el balanceo de carga de Linux con respuesta directa del servidor, como IPVS. En estos casos, el servicio también envía tramas ARP gratuitas, pero con la dirección MAC de otro servidor como origen de la trama ARP gratuita. Esta acción falsifica los marcos ARP y toma el control de la dirección IP de origen de otro servidor.

Esta acción se lleva a cabo para distribuir la carga de una dirección IP entre diferentes servidores. Sin embargo, este tipo de configuración no se trata en este documento. En casi todos los casos en los que se usan direcciones IP flotantes para el balanceo de carga local, se recomienda migrar a Cloud Load Balancing.

Problemas al migrar direcciones IP flotantes a Compute Engine

Compute Engine usa una pila de red virtualizada en una red de nube privada virtual (VPC), por lo que los mecanismos de implementación habituales no funcionan sin cambios enGoogle Cloud. Por ejemplo, la red de VPC gestiona las solicitudes ARP en la red definida por software e ignora los marcos ARP gratuitos. Además, no se puede modificar directamente la tabla de enrutamiento de la red VPC con protocolos de enrutamiento estándar, como OSPF o el protocolo de pasarela fronteriza (BGP). Los mecanismos habituales de las direcciones IP flotantes se basan en que la infraestructura de conmutación gestione las solicitudes ARP o en redes programables mediante OSPF o BGP. Por lo tanto, las direcciones IP no conmutan por error mediante estos mecanismos enGoogle Cloud. Si migras una imagen de máquina virtual mediante una dirección IP flotante local, la dirección IP flotante no puede conmutar por error sin cambiar la aplicación.

Puedes usar una red superpuesta para crear una configuración que permita la comunicación completa de la capa 2 y la adquisición de IP mediante solicitudes ARP. Sin embargo, configurar una red superpuesta es complejo y dificulta la gestión de los recursos de red de Compute Engine. Este enfoque también está fuera del ámbito de este documento. En su lugar, en este documento se describen patrones para implementar escenarios de conmutación por error en un entorno de red de Compute Engine sin crear redes superpuestas.

Para implementar aplicaciones fiables y de alta disponibilidad en Compute Engine, utiliza arquitecturas de escalado horizontal. Este tipo de arquitectura minimiza el efecto de un fallo en un solo nodo.

En este documento se describen varios patrones para migrar una aplicación que ya tengas y que use direcciones IP flotantes desde un entorno on-premise a Compute Engine. Entre ellos, se incluyen los siguientes:

No se recomienda usar direcciones IP de alias que se muevan entre instancias de VM como mecanismo de conmutación por error porque no cumplen los requisitos de alta disponibilidad. En determinadas situaciones de error, como un evento de error zonal, es posible que no puedas quitar una dirección IP de alias de una instancia. Por lo tanto, es posible que no puedas añadirlo a otra instancia, lo que imposibilitaría la conmutación por error.

Seleccionar un patrón para tu caso práctico

En función de tus requisitos, puede que te resulte útil implementar direcciones IP flotantes en un entorno local con uno o varios de los patrones descritos en esta solución.

A la hora de decidir qué patrón te permite usar una aplicación de la mejor forma posible, ten en cuenta los siguientes factores:

  • Dirección IP interna o externa flotante: la mayoría de las aplicaciones que requieren direcciones IP flotantes usan direcciones IP internas flotantes. Pocas aplicaciones usan direcciones IP externas flotantes, ya que normalmente el tráfico a aplicaciones externas debe balancearse.

    En la tabla que se muestra más adelante en esta sección se recomiendan patrones que puede usar para las direcciones IP internas flotantes y para las direcciones IP externas flotantes. En los casos prácticos que dependen de direcciones IP internas flotantes, cualquiera de estos patrones puede ser adecuado para tus necesidades. Sin embargo, recomendamos que los casos prácticos que dependan de direcciones IP externas flotantes se migren a uno de los patrones que usan el balanceo de carga.

  • Protocolos de aplicación: si tu máquina virtual solo usa TCP y UDP, puedes usar todos los patrones de la tabla. Si usa otros protocolos además de IPv4 para conectarse, solo son adecuados algunos patrones.

  • Compatibilidad con la implementación activa-activa: algunas aplicaciones, aunque usen direcciones IP flotantes en las instalaciones locales, pueden funcionar en un modo de implementación activa-activa. Esto significa que no es necesario que se produzca una conmutación por error del servidor principal al secundario. Tienes más opciones de patrones para migrar este tipo de aplicaciones a Compute Engine. Las aplicaciones que solo requieren un servidor de aplicaciones para recibir tráfico en cualquier momento no son compatibles con la implementación activa-activa. Solo puedes implementar estas aplicaciones con algunos patrones de la siguiente tabla.

  • Comportamiento de la restauración tras la recuperación de la VM principal: cuando la VM principal original se recupera después de una conmutación por error, el tráfico hace una de estas dos cosas, en función del patrón utilizado. Vuelve inmediatamente a la VM principal original o permanece en la nueva VM principal hasta que se inicie manualmente la conmutación por recuperación o hasta que falle la nueva VM principal. En todos los casos, solo se vuelve a la conexión alternativa si se inicia una conexión nueva. Las conexiones ya establecidas se mantienen en la nueva VM principal hasta que se cierran.

  • Compatibilidad con las comprobaciones del estado: si no puedes comprobar si tu aplicación responde mediante las comprobaciones del estado de Compute Engine sin dificultad, no podrás usar algunos de los patrones descritos en la siguiente tabla.

  • Grupos de instancias: cualquier patrón con compatibilidad de comprobación del estado también es compatible con los grupos de instancias. Para volver a crear automáticamente las instancias fallidas, puedes usar un grupo de instancias gestionado con reparación automática. Si tus VMs conservan el estado, puedes usar un grupo de instancias gestionado con estado. Si tus VMs no se pueden volver a crear automáticamente o necesitas una conmutación por error manual, usa un grupo de instancias no gestionado y vuelve a crear las VMs manualmente durante la conmutación por error.

  • Mecanismos de latido existentes: si la configuración de alta disponibilidad de tu aplicación ya usa un mecanismo de latido para activar la conmutación por error, como Heartbeat, Pacemaker o Keepalived, puedes usar algunos patrones descritos en la siguiente tabla.

En la siguiente tabla se enumeran las funciones de los patrones. Cada patrón se describe en las siguientes secciones:

Nombre del patrón Dirección IP Protocolos admitidos Modo de implementación Failback Se requiere compatibilidad con la comprobación del estado de la aplicación Puede integrar el mecanismo de latido
Patrones que usan el balanceo de carga
Balanceo de carga activo-activo Interno o externo Solo TCP/UDP Activo-activo N/A Sí No
Balanceo de carga con conmutación por error y comprobaciones de estado expuestas a la aplicación Interno o externo Solo TCP/UDP Activo-pasivo Inmediata (excepto las conexiones existentes) Sí No
Balanceo de carga con conmutación por error y comprobaciones del estado expuestas por latido Interno o externo Solo TCP/UDP Activo-pasivo Se pueden configurar. No Sí
Patrones que usan Google Cloud rutas
Usar rutas ECMP Interno Todos los protocolos IP Activo-activo N/A Sí No
Usar rutas de prioridad diferentes Interno Todos los protocolos IP Activo-pasivo Inmediata (excepto las conexiones existentes) Sí No
Usar un mecanismo de latido para cambiar el siguiente salto de la ruta Interno Todos los protocolos IP Activo-pasivo Se pueden configurar. No Sí
Patrón que usa la reparación automática
Usar una sola instancia con recuperación automática Interno Todos los protocolos IP N/A N/A Sí No

Decidir qué patrón usar en tu caso práctico puede depender de varios factores. El siguiente árbol de decisiones puede ayudarte a acotar tus opciones hasta encontrar la más adecuada.

Un árbol de decisión que te ayuda a elegir un balanceador de carga.

En el diagrama anterior se describen los siguientes pasos:

  1. ¿Una sola instancia de reparación automática proporciona una disponibilidad suficiente para tus necesidades?
    1. Si es así, consulta la sección Usar una instancia única con recuperación automática más adelante en este documento. La reparación automática usa un mecanismo en un grupo de instancias de VM para sustituir automáticamente una instancia de VM defectuosa.
    2. Si no es así, ve al siguiente punto de decisión.
  2. ¿Tu aplicación necesita protocolos además de TCP y UDP sobre IPv4?
    1. Si es así, ve al siguiente punto de decisión.
    2. Si no es así, ve al siguiente punto de decisión.
  3. ¿Puede funcionar tu aplicación en modo activo-activo?
    1. Si es así y necesita protocolos además de TCP y UDP en IPv4, consulte la sección Usar rutas de multipath de igual coste (ECMP) más adelante en este documento. Las rutas ECMP distribuyen el tráfico entre los siguientes saltos de todas las rutas candidatas.
    2. Si es así y no necesita protocolos además de IPv4 que no sean TCP y UDP, consulta la sección Balanceo de carga activo-activo más adelante en este documento. El balanceo de carga activo-activo usa tus VMs como backends de un balanceador de carga TCP/UDP interno.
    3. Si no es así, en ambos casos, ve al siguiente punto de decisión.
  4. ¿Puede tu aplicación exponer Google Cloud comprobaciones de estado?
    1. Si es así y necesita protocolos además de IPv4 que no sean TCP y UDP, consulte la sección Balanceo de carga con conmutación por error y comprobaciones de estado expuestas por la aplicación más adelante en este documento. El balanceo de carga con conmutación por error y comprobaciones de estado expuestas a la aplicación usa tus VMs como backends de un balanceador de carga TCP/UDP interno. También usa la dirección IP del balanceo de carga TCP/UDP interno como dirección IP virtual.
    2. Si es así y no necesita protocolos además de IPv4 que no sean TCP y UDP, consulta Usar rutas de prioridad diferentes más adelante en este documento. Usar rutas de prioridad diferentes ayuda a asegurar que el tráfico siempre fluya a una instancia principal, a menos que esa instancia falle.
    3. Si no es así y necesita protocolos sobre IPv4 que no sean TCP ni UDP, consulte la sección Balanceo de carga con conmutación por error y comprobaciones de estado con latido expuesto más adelante en este documento. En el patrón de balanceo de carga con conmutación por error y comprobaciones de estado expuestas por latido, las comprobaciones de estado no las expone la aplicación en sí, sino un mecanismo de latido que se ejecuta entre ambas VMs.
    4. Si no es así y NO NECESITA protocolos además de IPv4 que no sean TCP y UDP, consulta la sección Usar un mecanismo de latido para cambiar el siguiente salto de una ruta más adelante en este documento. Si se usa un mecanismo de latido para cambiar el siguiente salto de una ruta, se utiliza una sola ruta estática con el siguiente salto que apunta a la instancia de VM principal.

Patrones que usan el balanceo de carga

Normalmente, puedes migrar tu aplicación mediante direcciones IP flotantes a una arquitectura en Google Cloud que utilice Cloud Load Balancing. Puedes usar un balanceador de carga de red de paso a través interno, ya que esta opción se adapta a la mayoría de los casos prácticos en los que el servicio migrado local solo se expone internamente. Esta opción de balanceo de carga se usa en todos los ejemplos de esta sección y en los despliegues de ejemplo de GitHub. Si tienes clientes que acceden a la dirección IP flotante desde otras regiones, selecciona la opción de acceso global.

Si tu aplicación se comunica mediante protocolos basados en IPv4 que no son TCP ni UDP, debes elegir un patrón que no use el balanceo de carga. Estos patrones se describen más adelante en este documento.

Si tu aplicación usa HTTP(S), puedes usar un balanceador de carga de aplicaciones interno para implementar el patrón activo-activo.

Si el servicio que quieres migrar está disponible externamente, puedes implementar todos los patrones que se describen en esta sección mediante un balanceador de carga de red de paso a través externo. En las implementaciones activo-activo, también puedes usar un balanceador de carga de aplicaciones externo, un proxy TCP o un proxy SSL si tu aplicación usa protocolos y puertos compatibles con esas opciones de balanceo de carga.

Tenga en cuenta las siguientes diferencias entre las implementaciones locales basadas en direcciones IP flotantes y todos los patrones basados en el balanceo de carga:

  • Tiempo de conmutación por error: si se empareja Keepalived con ARP gratuito en un entorno local, es posible que se produzca una conmutación por error de una dirección IP en unos segundos. En el entorno de Compute Engine, el tiempo medio de recuperación tras un fallo depende de los parámetros que definas. Si falla la instancia de máquina virtual (VM) o el servicio de instancia de VM, el tiempo medio hasta la conmutación por error del tráfico depende de los parámetros de comprobación del estado, como Check Interval y Unhealthy Threshold. Si estos parámetros tienen sus valores predeterminados, la conmutación por error suele tardar entre 15 y 20 segundos. Puedes reducir el tiempo disminuyendo los valores de esos parámetros.

    En Compute Engine, las conmutaciones por error dentro de las zonas o entre zonas tardan el mismo tiempo.

  • Protocolos y puertos: en una configuración local, las direcciones IP flotantes aceptan todo el tráfico. Elige una de las siguientes especificaciones de puerto en la regla de reenvío interna del balanceador de carga de red de paso a través interno:

    • Especifica entre uno y cinco puertos por número.
    • Especifica ALL para reenviar el tráfico de todos los puertos de TCP o UDP.
    • Usa varias reglas de reenvío con la misma dirección IP para reenviar una combinación de tráfico TCP y UDP, o bien para usar más de cinco puertos con una sola dirección IP:
      • Solo TCP o UDP y de 1 a 5 puertos: usa una regla de reenvío.
      • TCP y UDP y de 1 a 5 puertos: usa varias reglas de reenvío.
      • 6 puertos o más y TCP o UDP: usa varias reglas de reenvío.

  • Comprobación del estado: en las instalaciones, puedes comprobar la capacidad de respuesta de las aplicaciones en un equipo de las siguientes formas:

Balanceo de carga activo-activo

En el patrón de balanceo de carga activo-activo, las VMs son back-ends de un balanceador de carga de red de paso a través interno. Usa la dirección IP del balanceador de carga de red de paso a través interno como dirección IP virtual. El tráfico se distribuye por igual entre las dos instancias de backend. El tráfico que pertenece a la misma sesión se dirige a la misma instancia de backend, tal como se define en la configuración de afinidad de sesión.

Usa el patrón de balanceo de carga activo-activo si tu aplicación solo usa protocolos basados en TCP y UDP, y no requiere conmutación por error entre máquinas. Usa el patrón en un caso en el que las aplicaciones puedan responder a las solicitudes en función del contenido de la solicitud en sí. Si hay un estado de la máquina que no se sincroniza constantemente, no uses el patrón (por ejemplo, en una base de datos principal o secundaria).

En el siguiente diagrama se muestra una implementación del patrón de equilibrio de carga activo-activo:

Cómo navega un cliente interno por el patrón de balanceo de carga activo-activo.

En el diagrama anterior se muestra cómo accede un cliente interno a un servicio que se ejecuta en dos VMs a través de un balanceador de carga de red de paso a través interno. Ambas VMs forman parte de un grupo de instancias.

El patrón de balanceo de carga activo-activo requiere que tu servicio exponga comprobaciones del estado mediante uno de los protocolos de comprobación del estado admitidos para asegurarse de que solo las VMs que responden reciban tráfico.

Para ver una implementación de ejemplo completa de este patrón, consulta el ejemplo de implementación con Terraform en GitHub.

Balanceo de carga con conmutación por error y comprobaciones de estado expuestas a la aplicación

Al igual que el patrón activo-activo, el balanceo de carga mediante la conmutación por error y el patrón de comprobaciones de estado expuestas a la aplicación usan tus VMs como backends de un balanceador de carga de red interno de transferencia. También usa la dirección IP del balanceador de carga de red de paso a través interno como dirección IP virtual. Para asegurarse de que solo una VM recibe tráfico a la vez, este patrón se aplica a la conmutación por error de los balanceadores de carga de red con paso a través internos.

Este patrón se recomienda si tu aplicación solo tiene tráfico TCP o UDP, pero no admite una implementación activa-activa. Cuando aplicas este patrón, todo el tráfico se dirige a la VM principal o a la de conmutación por error.

En el siguiente diagrama se muestra una implementación del balanceo de carga con conmutación por error y comprobaciones del estado expuestas por la aplicación:

Cómo navega un cliente interno por un servicio que está detrás de un balanceador de carga de red de paso a través interno.

El diagrama anterior muestra cómo accede un cliente interno a un servicio situado detrás de un balanceador de carga de red de paso a través interno. Dos VMs están en grupos de instancias independientes. Un grupo de instancias se define como backend principal. El otro grupo de instancias se define como backend de conmutación por error para un balanceador de carga de red de paso a través interno.

Si el servicio de la VM principal deja de responder, el tráfico se redirige al grupo de instancias de conmutación por error. Cuando la VM principal vuelva a responder, el tráfico volverá automáticamente al servicio de backend principal.

Para ver una implementación de ejemplo completa de este patrón, consulta el ejemplo de implementación con Terraform en GitHub.

Balanceo de carga con conmutación por error y comprobaciones del estado expuestas por latido

El balanceo de carga con conmutación por error y comprobaciones del estado expuestas por latido es el mismo que en el patrón anterior. La diferencia es que las comprobaciones de estado no las expone la aplicación en sí, sino un mecanismo de latido que se ejecuta entre ambas VMs.

En el siguiente diagrama se muestra una implementación del balanceo de carga con el patrón de comprobaciones de estado de conmutación por error y de latido expuestas:

Cómo accede un cliente interno a un servicio que se encuentra detrás de un balanceador de carga interno con dos VMs en grupos de instancias independientes.

En este diagrama se muestra cómo accede un cliente interno a un servicio que está detrás de un balanceador de carga interno. Dos VMs están en grupos de instancias independientes. Un grupo de instancias se define como backend principal. El otro grupo de instancias se define como backend de conmutación por error para un balanceador de carga de red de paso a través interno. Keepalived se usa como mecanismo de latido entre los nodos de la VM.

Los nodos de la VM intercambian información sobre el estado del servicio mediante el mecanismo de latido elegido. Cada nodo de VM comprueba su propio estado y lo comunica al nodo remoto. En función del estado del nodo local y del estado recibido por el nodo remoto, se elige un nodo como nodo principal y otro como nodo de copia de seguridad. Puede usar esta información de estado para exponer un resultado de comprobación de estado que asegure que el nodo considerado principal en el mecanismo de latido también recibe tráfico del balanceador de carga de red interno de tipo pasarela.

Por ejemplo, con Keepalived puedes invocar secuencias de comandos mediante las notify_master, notify_backup y notify_fault variables de configuración que cambian el estado de la comprobación de estado. Cuando se pasa al estado principal (en Keepalived, este estado se llama master), puedes iniciar una aplicación que escuche en un puerto TCP personalizado. Cuando se pasa a un estado de copia de seguridad o de error, puedes detener esta aplicación. La comprobación del estado puede ser una comprobación del estado TCP que se realice correctamente si este puerto TCP personalizado está abierto.

Este patrón es más complejo que el que usa la conmutación por error con comprobaciones del estado expuestas por la aplicación. Sin embargo, te ofrece más control. Por ejemplo, puedes configurarlo para que vuelva a la versión anterior inmediatamente o de forma manual como parte de la implementación del mecanismo de latido.

Para ver una implementación de ejemplo completa de este patrón que usa Keepalived, consulta la implementación de ejemplo con Terraform en GitHub.

Patrones que usan rutas Google Cloud

En los casos en los que tu aplicación utilice protocolos distintos de TCP o UDP sobre IPv4, puedes migrar tu dirección IP flotante a un patrón basado en rutas.

En esta sección, las menciones de rutas siempre hacen referencia a las Google Cloud rutas que forman parte de una red de VPC. Las referencias a rutas estáticas siempre se refieren a las rutas estáticas de Google Cloud.

Con uno de estos patrones, puedes definir varias rutas estáticas para una dirección IP específica con las diferentes instancias como saltos siguientes. Esta dirección IP se convierte en la dirección IP flotante que usan todos los clientes. Debe estar fuera de todos los intervalos de direcciones IP de subred de VPC, ya que las rutas estáticas no pueden anular las rutas de subred. Debes activar el reenvío de direcciones IP en las instancias de destino. Si habilitas el reenvío de direcciones IP, podrás aceptar tráfico para direcciones IP que no estén asignadas a las instancias (en este caso, la dirección IP flotante).

Si quieres que las rutas de direcciones IP flotantes estén disponibles en las redes de VPC emparejadas, exporta las rutas personalizadas para que las rutas de direcciones IP flotantes se propaguen a todas las redes de VPC emparejadas.

Para tener conectividad desde una red on-premise conectada a través de Cloud Interconnect o Cloud VPN, debes usar anuncios de ruta de dirección IP personalizada para que la dirección IP flotante se anuncie en la red on-premise.

Los patrones basados en rutas tienen las siguientes ventajas con respecto a los patrones basados en balanceo de carga:

  • Protocolos y puertos: los patrones basados en rutas se aplican a todo el tráfico enviado a un destino específico. Los patrones basados en el balanceo de carga solo permiten el tráfico TCP y UDP.

Los patrones basados en rutas tienen las siguientes desventajas con respecto a los patrones basados en balanceo de carga:

  • Comprobación del estado: las comprobaciones del estado no se pueden asociar a rutasGoogle Cloud . Las rutas se usan independientemente del estado de los servicios de VM subyacentes. Siempre que la VM esté en ejecución, las rutas dirigen el tráfico a las instancias aunque el servicio no esté en buen estado. Si adjuntas una política de recuperación automática a esas instancias, se sustituirán las instancias después de un periodo de tiempo en mal estado que especifiques. Sin embargo, una vez que se reinician esas instancias, el tráfico se reanuda inmediatamente, incluso antes de que el servicio esté activo. Este vacío en el servicio puede provocar errores en el servicio cuando las instancias no están en buen estado y siguen sirviendo tráfico o se están reiniciando.
  • Tiempo de conmutación por error: después de eliminar o detener una instancia de máquina virtual, Compute Engine ignora cualquier ruta estática que apunte a esta instancia. Sin embargo, como no hay comprobaciones del estado en las rutas, Compute Engine sigue usando la ruta estática mientras la instancia esté disponible. Además, detener la instancia lleva tiempo, por lo que el tiempo de conmutación por error es considerablemente mayor que con los patrones basados en el balanceo de carga.
  • Solo direcciones IP flotantes internas: aunque puedes implementar patrones mediante el balanceo de carga con un balanceador de carga de red de paso a través externo para crear una dirección IP flotante externa, los patrones basados en rutas solo funcionan con direcciones IP flotantes internas.
  • Selección de direcciones IP flotantes: solo puedes definir rutas para direcciones IP flotantes internas que no formen parte de ninguna subred. Las rutas de subred no se pueden sobrescribir en Google Cloud. Haz un seguimiento de estas direcciones IP flotantes para no asignarlas por error a otra red.
  • Accesibilidad de las rutas: para que se pueda acceder a las direcciones IP flotantes internas desde redes locales o redes emparejadas, debe distribuir esas rutas estáticas tal como se ha descrito anteriormente.

Usar rutas de multipath de igual coste (ECMP)

El patrón de rutas de multipath de igual coste (ECMP) es similar al patrón de balanceo de carga activo-activo: el tráfico se distribuye por igual entre las dos instancias de backend. Cuando usas rutas estáticas, ECMP distribuye el tráfico entre los siguientes saltos de todas las rutas candidatas mediante un hash de cinco tuplas para la afinidad.

Para implementar este patrón, crea dos rutas estáticas con la misma prioridad y con las instancias de Compute Engine como saltos siguientes.

En el siguiente diagrama se muestra una implementación del patrón de rutas ECMP:

Cómo accede un cliente interno a un servicio mediante una de las dos rutas ECMP.

En el diagrama anterior se muestra cómo accede un cliente interno a un servicio mediante una de las dos rutas, cuyo siguiente salto apunta a las instancias de VM que implementan el servicio.

Si el servicio de una VM deja de responder, la reparación automática intenta volver a crear la instancia que no responde. Una vez que la reparación automática elimina la instancia, la ruta que apunta a la instancia se inactiva antes de que se cree la nueva instancia. Una vez que exista la nueva instancia, la ruta que apunta a ella se usará automáticamente de inmediato y el tráfico se distribuirá por igual entre las instancias.

El patrón de rutas ECMP requiere que tu servicio exponga comprobaciones del estado mediante protocolos admitidos para que la reparación automática pueda sustituir automáticamente las VMs que no responden.

Puedes encontrar una implementación de ejemplo de este patrón con Terraform en el repositorio de GitHub asociado a este documento.

Usar rutas de prioridad diferentes

El patrón de rutas de prioridad diferente es similar al anterior, con la diferencia de que usa rutas estáticas de prioridad diferente para que el tráfico siempre fluya a una instancia principal, a menos que esa instancia falle.

Para implementar este patrón, sigue los mismos pasos que en el patrón de rutas ECMP. Al crear las rutas estáticas, asigna a la ruta con el salto siguiente que apunta a la instancia principal un valor de prioridad más bajo (ruta principal). Asigna a la instancia con el siguiente salto que apunta a la instancia secundaria un valor de prioridad más alto (ruta secundaria).

En el siguiente diagrama se muestra una implementación del patrón de rutas de prioridad diferente: Cómo usa un cliente interno que accede a un servicio una ruta principal o secundaria en función de las circunstancias de la red.

En el diagrama anterior se muestra cómo un cliente interno que accede a un servicio utiliza una ruta principal con un valor de prioridad de 500 que apunta a la VM 1 como salto siguiente en circunstancias normales. Hay una segunda ruta con un valor de prioridad de 1000 que apunta a la VM 2, la VM secundaria, como siguiente salto.

Si el servicio de la VM principal deja de responder, la reparación automática intenta volver a crear la instancia. Una vez que la reparación automática elimina la instancia y antes de que se cree la nueva instancia, la ruta principal, con la instancia principal como salto siguiente, se inactiva. A continuación, el patrón usa la ruta con la instancia secundaria como siguiente salto. Una vez que la nueva instancia principal se pone en marcha, la ruta principal vuelve a estar activa y todo el tráfico se dirige a la instancia principal.

Al igual que en el patrón anterior, el patrón de ruta de prioridad diferente requiere que tu servicio exponga comprobaciones de estado mediante protocolos admitidos para que la reparación automática pueda sustituir automáticamente las VMs que no responden.

Puedes encontrar una implementación de ejemplo de este patrón con Terraform en el repositorio de GitHub que acompaña a este documento.

Usar un mecanismo de latido para cambiar el siguiente salto de una ruta

Si tu aplicación implementa un mecanismo de latido, como Keepalived, para monitorizar la capacidad de respuesta de la aplicación, puedes aplicar el patrón del mecanismo de latido para cambiar el siguiente salto de la ruta estática. En este caso, solo se usa una ruta estática con el siguiente salto que apunta a la instancia de VM principal. En caso de failover, el mecanismo de latido apunta el siguiente salto de la ruta a la máquina virtual secundaria.

En el siguiente diagrama se muestra una implementación del mecanismo de latido para cambiar el patrón del siguiente salto de una ruta:

Cómo accede un cliente interno a un servicio en el que la máquina virtual principal y la secundaria intercambian información de latido.

En el diagrama anterior se muestra cómo accede un cliente interno a un servicio mediante una ruta con el siguiente salto que apunta a la VM principal. La VM principal intercambia información de latido con la VM secundaria a través de Keepalived. En caso de conmutación por error, Keepalived llama a una función de Cloud Run que usa llamadas a la API para dirigir el siguiente salto a la VM secundaria.

Los nodos usan el mecanismo de latido elegido para intercambiar información entre sí sobre el estado del servicio. Cada nodo de VM comprueba su propio estado y se lo comunica al nodo de VM remoto. En función del estado del nodo de VM local y del estado recibido por el nodo remoto, se elige un nodo de VM como nodo principal y otro como nodo de copia de seguridad. Una vez que un nodo se convierte en principal, apunta el siguiente salto de la ruta de la dirección IP flotante a sí mismo. Si usas Keepalived, puedes invocar una secuencia de comandos mediante la notify_master variable de configuración que sustituye la ruta estática mediante una llamada a la API o la CLI de Google Cloud.

El mecanismo de latido para cambiar el patrón de siguiente salto de una ruta no requiere que las VMs formen parte de un grupo de instancias. Si quieres que las VMs se sustituyan automáticamente en caso de fallo, puedes colocarlas en un grupo de instancias con reparación automática. También puedes reparar y recrear manualmente las VMs que no responden.

Si invocas el siguiente procedimiento en caso de conmutación por error, te asegurarás de que el tiempo de conmutación por error se minimice, ya que el tráfico se conmuta por error después de que se complete una sola llamada a la API en el paso 1:

  1. Crea una ruta estática con la dirección IP flotante como destino y la nueva instancia principal como siguiente salto. La nueva ruta debe tener un nombre diferente y una prioridad inferior (por ejemplo, 400) a la de la ruta original.
  2. Elimina la ruta original a la VM principal antigua.
  3. Crea una ruta con el mismo nombre y prioridad que la ruta que acabas de eliminar. Dirígelo a la nueva VM principal como el siguiente salto.
  4. Elimina la nueva ruta estática que has creado. No es necesario para asegurarse de que el tráfico se dirija a la nueva VM principal.

Como la ruta original se sustituye, solo debe haber una ruta activa a la vez, incluso cuando haya una red dividida.

Si usas el mecanismo de latido para cambiar el patrón de prioridad de la ruta en lugar de otros patrones basados en rutas, puedes reducir el tiempo de conmutación por error. No tienes que eliminar y sustituir las VMs mediante la reparación automática para la conmutación por error. También te ofrece más control sobre cuándo volver al servidor principal original después de que vuelva a responder.

Una de las desventajas del patrón es que tienes que gestionar el mecanismo de latido tú mismo. Gestionar el mecanismo puede aumentar la complejidad. Otra desventaja es que tienes que dar privilegios para cambiar la tabla de enrutamiento global a las VMs que ejecutan el proceso de latido o a una función sin servidor a la que se llama desde el proceso de latido. Cambiar la tabla de enrutamiento global a una función sin servidor es más seguro, ya que puede reducir el ámbito de los privilegios concedidos a las VMs. Sin embargo, este enfoque es más complejo de implementar.

Para ver una implementación de ejemplo completa de este patrón con Keepalived, consulta el ejemplo de implementación con Terraform en GitHub.

Patrón con reparación automática

En función de los requisitos de tiempo de recuperación, migrar a una sola instancia de VM puede ser una opción viable al usar Compute Engine. Esta opción es verdadera aunque se hayan usado varios servidores con una dirección IP flotante en las instalaciones. El motivo por el que este patrón se puede usar a veces a pesar de que se haya reducido el número de VMs es que puedes crear una instancia de Compute Engine en segundos o minutos, mientras que los fallos locales suelen tardar horas o incluso días en solucionarse.

Usar una sola instancia con recuperación automática

Con este patrón, se utiliza el mecanismo de reparación automática de un grupo de instancias de VM para sustituir automáticamente una instancia de VM defectuosa. La aplicación expone una comprobación del estado y, cuando la aplicación no está en buen estado, la reparación automática sustituye automáticamente la VM.

En el siguiente diagrama se muestra una implementación del patrón de instancia única de reparación automática:

Cómo se conecta un cliente interno directamente a una instancia de Compute Engine.

En el diagrama anterior se muestra cómo se conecta un cliente interno directamente a una instancia de Compute Engine colocada en un grupo de instancias gestionado con un tamaño de 1 y con la reparación automática activada.

En comparación con los patrones que usan el balanceo de carga, el patrón de instancia única con reparación automática tiene las siguientes ventajas:

  • Distribución del tráfico: solo hay una instancia, por lo que siempre recibe todo el tráfico.
  • Facilidad de uso: como solo hay una instancia, este patrón es el menos complicado de implementar.
  • Ahorro de costes: si usas una sola instancia de VM en lugar de dos, el coste de la implementación se reduce a la mitad.

Sin embargo, el patrón tiene las siguientes desventajas:

  • Tiempo de conmutación por error: este proceso es mucho más lento que los patrones basados en el balanceo de carga. Cuando las comprobaciones de estado detectan un fallo en una máquina, se tarda al menos un minuto en eliminar y volver a crear la instancia con errores, pero a menudo se tarda más. Este patrón no es habitual en entornos de producción. Sin embargo, el tiempo de conmutación por error puede ser suficiente para algunos servicios internos o experimentales.
  • Reacción ante fallos de zona: un grupo de instancias gestionado con un tamaño de 1 no sobrevive a un fallo de zona. Para reaccionar ante los fallos de zona, considera la posibilidad de añadir una alerta de Cloud Monitoring cuando falle el servicio y crear un grupo de instancias en otra zona en caso de que se produzca un fallo en una zona. Como no puedes usar la misma dirección IP en este caso, utiliza una zona privada de Cloud DNS para acceder a la VM y cambia el nombre DNS a la nueva dirección IP.

Puedes encontrar una implementación de ejemplo de este patrón con Terraform en el repositorio de GitHub.

Siguientes pasos