Patrones para usar direcciones IP flotantes en Compute Engine

Last reviewed 2024-01-29 UTC

En este documento, se describe cómo usar los patrones de implementación de direcciones IP flotantes cuando migras aplicaciones a Compute Engine desde un entorno de red local. Este documento está dirigido a ingenieros de redes, ingenieros de operaciones y administradores del sistema que migran aplicaciones a Google Cloud.

Las direcciones IP flotantes, también conocidas como direcciones IP compartidas o virtuales, a menudo se usan para hacer que los entornos de red locales tengan alta disponibilidad. Mediante las direcciones IP flotantes, puedes pasar 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 direcciones IP flotantes directamente en un entorno de Compute Engine sin cambiar la arquitectura a uno de los patrones que se describen en este documento.

El repositorio de GitHub que acompaña a este documento incluye implementaciones de muestra para cada patrón que puedes implementar de forma automática mediante Terraform.

Direcciones IP flotantes en entornos locales

Las direcciones IP flotantes se suelen usar en entornos locales. Los casos de uso de ejemplo son los siguientes:

Existen varias formas de implementar direcciones IP flotantes en un entorno local. Por lo general, los servidores que comparten direcciones IP flotantes también comparten información de estado a través de un mecanismo de señal de monitoreo de funcionamiento. Este mecanismo permite que los servidores se comuniquen su estado entre sí. También permite que el servidor secundario tome la dirección IP flotante después de que el servidor principal falle. Con frecuencia, este esquema se implementa 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 la dirección IP, el servidor que se apropia de la dirección IP flotante agrega la dirección a su interfaz de red. Este servidor comunica la apropiación a los otros dispositivos con la Capa 2 mediante el envío de un marco injustificado del Protocolo de resolución de direcciones (ARP). Como alternativa, a veces un protocolo de enrutamiento como Abrir la ruta de acceso más corta primero (OSPF) anuncia la dirección IP al router ascendente de la Capa 3.

En el siguiente diagrama, se muestra una configuración típica en un entorno local.

Entorno local típico.

En el diagrama anterior, se muestra cómo un servidor principal y un servidor secundario conectado a la misma información de respuesta de intercambio de interruptores a través de un mecanismo de señal de monitoreo de funcionamiento. Si el servidor principal falla, el servidor secundario envía un marco ARP injustificado al interruptor para tomar la dirección IP flotante.

Debes usar una configuración un poco diferente con las soluciones locales de balanceo de cargas, como el Balanceo de cargas de red de Windows o el Balanceo de cargas de Linux con respuesta directa del servidor, como IPVS. En estos casos, el servicio también envía marcos ARP injustificados, pero con la dirección MAC de otro servidor como la fuente del ARP gratuito. Esta acción falsifica la identidad de los marcos ARP y toma la dirección IP de origen de otro servidor.

Esta acción se realiza para distribuir la carga de una dirección IP entre diferentes servidores. Sin embargo, este tipo de configuración queda fuera del alcance de este documento. En casi todos los casos en los que se usan direcciones IP flotantes para el balanceo de cargas local, se prefiere migrar a Cloud Load Balancing.

Desafíos relacionados con la migración de 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 típicos no funcionan sin cambios en Google Cloud. Por ejemplo, la red de VPC maneja las solicitudes ARP en la red definida por software y, además, ignora los marcos ARP injustificados. Además, es imposible modificar directamente la tabla de enrutamiento de la red de VPC con protocolos de enrutamiento estándares como OSPF o el protocolo de Puerta de Enlace Fronteriza (BGP). Los mecanismos típicos para las direcciones IP flotantes dependen de que las solicitudes ARP se manejen mediante el cambio de infraestructura o se basan en redes programables por OSPF o BGP. Por lo tanto, las direcciones IP no conmutan por error mediante estos mecanismos en Google Cloud. Si migras una imagen de máquina virtual (VM) con una dirección IP flotante local, la dirección IP flotante no puede conmutar por error sin cambiar la aplicación.

Podrías usar una red de superposición para crear una configuración que habilite la comunicación completa de Capa 2 y la apropiación de la IP mediante solicitudes ARP. Sin embargo, la configuración de una red de superposición es compleja y dificulta la administración de los recursos de red de Compute Engine. Ese enfoque también está fuera del alcance de este documento. En su lugar, en este documento se describen patrones para implementar situaciones de conmutación por error en un entorno de red de Compute Engine sin crear redes superpuestas.

Para implementar aplicaciones confiables y con alta disponibilidad en Compute Engine, usa arquitecturas de escalamiento horizontal. Este tipo de arquitectura minimiza el efecto de una falla de nodo único.

En este documento, se describen varios patrones para migrar una aplicación existente mediante direcciones IP flotantes de las instalaciones locales a Compute Engine, lo que incluye lo siguiente:

No se recomienda usar direcciones IP de alias que se muevan entre instancias de VM como un mecanismo de conmutación por error porque no cumple con los requisitos de alta disponibilidad. En ciertas situaciones de falla, como un evento de falla zonal, es posible que no puedas quitar una dirección IP de alias de una instancia. Por lo tanto, es posible que no puedas agregarla a otra instancia, lo que hace imposible la conmutación por error.

Selecciona un patrón para tu caso de uso

Según tus requisitos, uno o más de los patrones descritos en esta solución pueden ser útiles para implementar direcciones IP flotantes en un entorno local.

Ten en cuenta los siguientes factores cuando decidas qué patrón te permitirá usar una aplicación de mejor manera:

  • Dirección IP interna flotante 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, por lo general, el tráfico a las aplicaciones externas debe tener balanceo de cargas.

    La tabla que se muestra más adelante en esta sección recomienda patrones que puedes usar para direcciones IP internas flotantes y direcciones IP externas flotantes. En los casos de uso que dependen de direcciones IP internas flotantes, cualquiera de estos patrones puede ser conveniente para tus necesidades. Sin embargo, recomendamos que los casos de uso que se basan en direcciones IP externas flotantes se migren a uno de los patrones mediante el balanceo de cargas.

  • Protocolos de aplicación: Si tu VM solo usa TCP y UDP, puedes usar todos los patrones de la tabla. Si se usan otros protocolos en IPv4 para conectarse, solo algunos patrones son apropiados.

  • Compatibilidad de implementación activa-activa: Algunas aplicaciones, mientras usan direcciones IP flotantes locales, pueden funcionar en un modo de implementación activa-activa. Esta capacidad significa que no necesariamente requieren conmutación por error del servidor principal al servidor secundario. Tienes más opciones de patrones para mover este tipo de aplicaciones a Compute Engine. Las aplicaciones que requieren que un solo servidor de aplicaciones reciba tráfico en cualquier momento no son compatibles con la implementación activa-activa. Solo puedes implementar estas aplicaciones con algunos patrones en la siguiente tabla.

  • Comportamiento de conmutación por error después de que la VM principal se recupera: Cuando la VM principal original se recupera después de una conmutación por error, según el patrón que se use, el tráfico realiza una de dos acciones. Vuelve a la VM principal original de inmediato o permanece en la VM principal nueva hasta que la conmutación por error se inicie de forma manual o la nueva VM principal falle. En todos los casos, solo las conexiones recién iniciadas conmutan por error. Las conexiones existentes permanecen en la VM principal nueva hasta que se cierran.

  • Compatibilidad de la verificación de estado: Si no puedes verificar si tu aplicación responde mediante las verificaciones de estado de Compute Engine sin problemas, no puedes usar algunos patrones que se describen en la siguiente tabla.

  • Grupos de instancias: Cualquier patrón con compatibilidad de verificación de estado también es compatible con los grupos de instancias. Para volver a crear instancias con errores de forma automática, puedes usar un grupo de instancias administrado con reparación automática. Si las VMs mantienen el estado, puedes usar un grupo de instancias administrado con estado. Si tus VMs no se pueden volver a crear de forma automática o necesitas una conmutación por error manual, usa un grupo de instancias no administrado y vuelve a crear las VMs de forma manual durante la conmutación por error.

  • Mecanismos de señal de monitoreo de funcionamiento existentes: Si la configuración de alta disponibilidad para tu aplicación ya usa un mecanismo de señal de monitoreo de funcionamiento a fin de activar la conmutación por error, como Heartbeat, Pacemaker o Keepalived, puedes usar algunos patrones que se describen en la siguiente tabla.

La siguiente tabla enumera las capacidades 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 Conmutación por recuperación Se requiere compatibilidad con la verificación de estado de la aplicación Puede integrar el mecanismo de señal de monitoreo de funcionamiento
Patrones que usan el balanceo de cargas
Balanceo de cargas activo-activo Interna o externa Solo TCP/UDP Activa-activa N/A Sí No
Balanceo de cargas con conmutación por error y verificaciones de estado expuestas por la aplicación Interna o externa Solo TCP/UDP Activa-pasiva Inmediata (excepto las conexiones existentes) Sí No
Balanceo de cargas con conmutación por error y verificaciones de estado expuestas por la señal de monitoreo de funcionamiento Interna o externa Solo TCP/UDP Activa-pasiva Configurable No Sí
Patrones que usan rutas de Google Cloud
Usar rutas de ECMP Interno Todos los protocolos de IP Activa-activa N/A Sí No
Usar rutas de prioridad diferente Interno Todos los protocolos de IP Activa-pasiva Inmediata (excepto las conexiones existentes) Sí No
Usar un mecanismo de señal de monitoreo de funcionamiento para cambiar el siguiente salto de una ruta Interno Todos los protocolos de IP Activa-pasiva Configurable No Sí
Patrón que usa la reparación automática
Usar una instancia única de reparación automática Interno Todos los protocolos de IP N/A N/A Sí No

Decidir qué patrón usar para tu caso de uso puede depender de varios factores. El siguiente árbol de decisión puede ayudarte a reducir tus opciones para encontrar una opción adecuada.

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

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 Usa una instancia única de reparació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 reemplazar de forma automática una instancia de VM con errores.
    2. De lo contrario, continúa con el siguiente punto de decisión.
  2. ¿Tu aplicación necesita protocolos basados en IPv4 que no sean TCP y UDP?
    1. Si es así, continúa con el siguiente punto de decisión.
    2. De lo contrario, continúa con el siguiente punto de decisión.
  3. ¿Tu aplicación puede funcionar en el modo activo-activo?
    1. Si es así y necesita protocolos basados en IPv4 que no sean TCP ni UDP, consulta Usar rutas de varias rutas de igual costo (ECMP) más adelante en este documento. Las rutas de ECMP distribuyen el tráfico entre los siguientes saltos de todas las opciones de ruta.
    2. Si es así y no necesita protocolos IPv4 distintos de TCP y UDP, consulta Balanceo de cargas activo-activo más adelante en este documento. El balanceo de cargas activo-activo usa tus VM como backends para un balanceador de cargas TCP/UDP interno.
    3. De lo contrario, en cualquier caso, continúa con el siguiente punto de decisión.
  4. ¿Tu aplicación puede exponer las verificaciones de estado de Google Cloud?
    1. Si es así y necesita protocolos basados en IPv4 que no sean TCP ni UDP, consulta Balanceo de cargas con conmutación por error y verificaciones de estado expuestas por la aplicación más adelante en este documento. El balanceo de cargas con conmutación por error y verificaciones de estado expuestas por la aplicación usa tus VM como backends para un balanceador de cargas de TCP/UDP interno. También usa la dirección IP de balanceo de cargas TCP/UDP interno como una dirección IP virtual.
    2. Si es así y no necesita protocolos adicionales a IPv4 distintos de TCP y UDP, consulta Usa rutas de prioridad diferente más adelante en este documento. El uso de rutas de prioridad diferente ayuda a garantizar que el tráfico siempre fluya a una instancia principal, a menos que esa instancia falle.
    3. Si no es así y necesita protocolos basados en IPv4 que no sean TCP ni UDP, consulta Balanceo de cargas con conmutación por error y verificaciones de estado expuestas por la señal de monitoreo de funcionamiento más adelante en este documento. En el de balanceo de cargas con patrón de conmutación por error y verificaciones de estado expuestas por la señal de monitoreo de funcionamiento, las verificaciones de estado no están expuestas por la aplicación en sí, sino por un mecanismo de señal de monitoreo de funcionamiento que se ejecuta entre ambas VM.
    4. Si no es así y NO NECESITA protocolos basados en IPv4 que no sean TCP ni UDP, consulta Usa un mecanismo de señal de monitoreo de funcionamiento para cambiar el siguiente salto de una ruta más adelante en este documento. Mediante un mecanismo de señal de monitoreo de funcionamiento para cambiar el siguiente salto de una ruta, se usa una sola ruta estática y el siguiente salto apunta a la instancia de VM principal.

Patrones que usan el balanceo de cargas

Por lo general, puedes migrar la aplicación mediante direcciones IP flotantes a una arquitectura en Google Cloud que use Cloud Load Balancing. Puedes usar un balanceador de cargas de red de transferencia interno, ya que esta opción se adapta a la mayoría de los casos de uso en los que el servicio migrado local solo se expone de forma interna. Esta opción de balanceo de cargas se usa para todos los ejemplos en esta sección y en las implementaciones de muestra en GitHub. Si tienes clientes que acceden a la dirección IP flotante desde otras regiones, selecciona la opción de acceso global.

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

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

Si el servicio que intentas migrar está disponible de forma externa, puedes implementar todos los patrones que se analizan en esta sección mediante un balanceador de cargas de red. Para implementaciones de tipo activo-activo, también puedes usar un balanceador de cargas 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 cargas.

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

  • Tiempo de conmutación por error: Si vinculas Keepalived con ARP injustificado en un entorno local, podría conmutarse por error una dirección IP en pocos segundos. En el entorno de Compute Engine, el tiempo medio de recuperación desde la conmutación por error depende de los parámetros que establezcas. En caso de que falle la instancia de máquina virtual (VM) o el servicio de instancias de VM, el tráfico de tiempo promedio de conmutación por error depende de parámetros de verificación de estado como Check Interval y Unhealthy Threshold. Cuando estos parámetros se establecen en los valores predeterminados, la conmutación por error suele demorar entre 15 y 20 segundos. Para reducir el tiempo, disminuye los valores de esos parámetros.

    En Compute Engine, las conmutaciones por error dentro de las zonas o entre zonas demoran la misma cantidad de 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 interno para el balanceador de cargas de red de transferencia interno:

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

  • Verificación de estado: De forma local, puedes verificar la capacidad de respuesta de la aplicación en una máquina de las siguientes maneras:

Balanceo de cargas activo-activo

En el patrón de balanceo de cargas activo-activo, tus VMs son backends para un balanceador de cargas de red de transferencia interno. Usa la dirección IP del balanceador de cargas de red de transferencia interno como una dirección IP virtual. El tráfico se distribuye de forma equitativa entre las dos instancias de backend. El tráfico que pertenece a la misma sesión va a la misma instancia de backend, como se define en la configuración de afinidad de sesión.

Usa el patrón de balanceo de cargas 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 una situación en la que las aplicaciones puedan responder solicitudes según el contenido de la solicitud. Si hay un estado de máquina que no se sincroniza de forma constante, 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 balanceo de cargas activo-activo:

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

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

El patrón de balanceo de cargas activo-activo requiere que tu servicio exponga las verificaciones de estado mediante uno de los protocolos de verificación de estado compatibles para garantizar que solo las VMs responsivas reciban tráfico.

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

Balanceo de cargas con conmutación por error y verificaciones de estado expuestas por la aplicación

Al igual que el patrón activo-activo, el balanceo de cargas mediante el patrón de conmutación por error y verificaciones de estado expuestas por la aplicación usa tus VMs como backends para un balanceador de cargas de red de transferencia interno. También usa la dirección IP del balanceador de cargas de red de transferencia interno como una dirección IP virtual. Para garantizar que solo una VM reciba tráfico a la vez, este patrón aplica conmutación por error para los balanceadores de cargas de red de transferencia internos.

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

En el diagrama siguiente, se muestra una implementación del balanceo de cargas con el patrón de conmutación por error y verificaciones de estado expuestas por la aplicación:

Cómo un cliente interno navega por un servicio detrás de un balanceador de cargas de red de transferencia interno.

En el diagrama anterior, se muestra cómo un cliente interno accede a un servicio detrás de un balanceador de cargas de red de transferencia interno. Dos VM se encuentran en grupos de instancias diferentes. Un grupo de instancias se establece como un backend principal. El otro grupo de instancias se establece como un backend de conmutación por error para un balanceador de cargas de red de transferencia interno.

Si el servicio en la VM principal deja de responder, el tráfico cambia al grupo de instancias de conmutación por error. Una vez que la VM principal vuelve a responder, el tráfico vuelve de forma automática al servicio de backend principal.

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

Balanceo de cargas con conmutación por error y verificaciones de estado expuestas por la señal de monitoreo de funcionamiento

El balanceo de cargas con el patrón de conmutación por error y verificaciones de estado expuestas por la señal de monitoreo de funcionamiento es el mismo que el patrón anterior. La diferencia es que la aplicación en sí no expone las verificaciones de estado, sino un mecanismo de señal de monitoreo de funcionamiento que se ejecuta entre ambas VM.

En el siguiente diagrama, se muestra una implementación del balanceo de cargas con el patrón de conmutación por error y verificaciones de estado expuestas por la señal de monitoreo de funcionamiento:

Cómo un cliente interno accede a un servicio detrás de un balanceador de cargas interno con dos VM en grupos de instancias separados.

En este diagrama, se muestra cómo un cliente interno accede a un servicio detrás de un balanceador de cargas interno. Dos VM se encuentran en grupos de instancias diferentes. Un grupo de instancias se establece como un backend principal. El otro grupo de instancias se establece como un backend de conmutación por error para un balanceador de cargas de red de transferencia interno. Keepalived se usa como un mecanismo de señal de monitoreo de funcionamiento entre los nodos de VM.

Los nodos de VM intercambian información sobre el estado del servicio mediante el mecanismo de señal de monitoreo de funcionamiento elegido. Cada nodo de VM verifica su propio estado y lo comunica al nodo remoto. Según el estado del nodo local y el estado que recibe el nodo remoto, se elige un nodo como el principal y otro como nodo de copia de seguridad. Puedes usar esta información de estado para exponer un resultado de verificación de estado que garantiza que el nodo considerado principal en el mecanismo de señal de monitoreo de funcionamiento también reciba tráfico del balanceador de cargas de red de transferencia interno.

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

Este patrón es más complejo que el patrón que usa la conmutación por error con verificaciones de estado expuestas por la aplicación. Sin embargo, te da más control. Por ejemplo, puedes configurarlo para que falle de inmediato o de forma manual como parte de la implementación del mecanismo de señal de monitoreo de funcionamiento.

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

Patrones que usan rutas de Google Cloud

En los casos en los que tu aplicación use protocolos que no sean TCP o UDP en 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 rutas de Google Cloud que forman parte de una red de VPC. Las referencias a rutas estáticas siempre hacen referencia a rutas estáticas en Google Cloud.

Mediante uno de estos patrones, configuras varias rutas estáticas para una dirección IP específica con diferentes instancias como siguientes saltos. Esta dirección IP se convierte en la dirección IP flotante que usan todos los clientes. Debe estar fuera de todos los rangos de direcciones IP de la subred de VPC, porque las rutas estáticas no pueden anular las rutas de subred existentes. Debes activar el reenvío de direcciones IP en las instancias de destino. Habilitar el reenvío de direcciones IP te permite aceptar tráfico para direcciones IP no asignadas a las instancias, en este caso, la dirección IP flotante.

Si deseas que las rutas de direcciones IP flotantes estén disponibles en las redes de VPC de intercambio de tráfico, exporta rutas personalizadas para que las rutas de direcciones IP flotantes se propaguen a todas las redes de VPC de intercambio de tráfico.

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

Los patrones basados en rutas tienen la siguiente ventaja sobre los patrones basados en el balanceo de cargas:

  • 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 cargas solo permiten el tráfico de TCP y UDP.

Los patrones basados en rutas tienen las siguientes desventajas en comparación con los patrones basados en el balanceo de cargas:

  • Verificaciones de estado: Las verificaciones de estado no se pueden adjuntar a las rutas de Google Cloud. Las rutas se usan sin importar el estado de los servicios de VM subyacentes. Cada vez que la VM está en ejecución, enruta el tráfico directo a las instancias, incluso si el servicio está en mal estado. Adjuntar una política de reparación automática a esas instancias reemplaza las instancias después de un período de mal estado que especifiques. Sin embargo, una vez que esas instancias se reinician, el tráfico se reanuda de inmediato, incluso antes de que el servicio esté activo. Esta brecha del servicio puede generar posibles errores de servicio cuando las instancias en mal estado aún entregan tráfico o se están reiniciando.
  • Tiempo de conmutación por error: Después de borrar o detener una instancia de VM, Compute Engine ignora cualquier ruta estática que apunte a esta instancia. Sin embargo, debido a que no hay verificaciones de estado en las rutas, Compute Engine sigue usando la ruta estática siempre que la instancia esté disponible. Además, detener la instancia lleva tiempo, por lo que el tiempo de la conmutación por error es mucho mayor que con los patrones basados en el balanceo de cargas.
  • Solo direcciones IP flotantes internas: Si bien puedes implementar patrones mediante el balanceo de cargas con un balanceador de cargas de red de transferencia externo para crear una dirección IP flotante externa, los patrones basados en rutas solo funcionan con direcciones IP flotantes internas.
  • Selección de la dirección IP flotante: Puedes configurar rutas solo para direcciones IP flotantes internas que no forman parte de ninguna subred; las rutas de subred no se pueden reemplazar en Google Cloud. Realiza un seguimiento de estas direcciones IP flotantes para que no las asignes por accidente a otra red.
  • Accesibilidad de rutas: Para hacer que las direcciones IP flotantes internas sean accesibles desde redes locales o redes con intercambio de tráfico, debes distribuir esas rutas estáticas como se describió antes.

Usar rutas de varias rutas de igual costo (ECMP)

El patrón de rutas de varias rutas de igual costo (ECMP) es similar al patrón de balanceo de cargas activo-activo: el tráfico se distribuye de manera equitativa entre las dos instancias de backend. Cuando usas rutas estáticas de Google Cloud, ECMP distribuye el tráfico entre los siguientes saltos de todos los candidatos de ruta mediante un hash de cinco tuplas para tener afinidad.

Puedes implementar este patrón mediante la creación de dos rutas estáticas de igual prioridad con las instancias de Compute Engine como siguientes saltos.

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

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

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

Si el servicio en una VM deja de responder, la reparación automática intenta recrear la instancia que no responde. Una vez que la reparación automática borra la instancia, la ruta que apunta a la instancia se vuelve inactiva antes de que se cree la instancia nueva. Una vez que existe la instancia nueva, la ruta que se dirige a esta instancia se usa de forma automática y el tráfico se distribuye de forma equitativa entre las instancias.

El patrón de rutas de ECMP requiere que el servicio exponga las verificaciones de estado mediante protocolos compatibles, de modo que la reparación automática pueda reemplazar de forma automática las VM que no responden.

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

Usar rutas de prioridad diferente

El patrón de rutas de prioridad diferente es similar al patrón anterior, excepto 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 en el patrón de rutas de ECMP. Cuando crees las rutas estáticas, otorga a la ruta con el siguiente salto que apunta a la instancia principal un valor de prioridad más bajo (ruta principal). Otorga 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 un cliente interno que accede a un servicio usa una ruta principal o secundaria según las circunstancias de la red.

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

Si el servicio en 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 borra la instancia y antes de que aparezca la nueva instancia que crea, la ruta principal, con la instancia principal como un siguiente salto, se vuelve inactiva. Luego, el patrón usa la ruta con la instancia secundaria como siguiente salto. Una vez que aparece la nueva instancia principal, la ruta principal vuelve a activarse y todo el tráfico fluye a la instancia principal.

Al igual que el patrón anterior, el patrón de ruta de prioridad diferente requiere que tu servicio exponga las verificaciones de estado mediante protocolos compatibles para que la reparación automática pueda reemplazar de forma automática las VM que no responden.

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

Usar un mecanismo de señal de monitoreo de funcionamiento para cambiar el siguiente salto de una ruta

Si tu aplicación implementa un mecanismo de señal de monitoreo de funcionamiento, como Keepalived, para supervisar la capacidad de respuesta de la aplicación, puedes aplicar el patrón de mecanismo de señal de monitoreo de funcionamiento a fin de cambiar el siguiente salto de la ruta estática. En este caso, solo usas una ruta estática única con el siguiente salto que apunta a la instancia de VM principal. En la conmutación por error, el mecanismo de señal de monitoreo de funcionamiento hace que el siguiente salto de la ruta apunte a la VM secundaria.

En el siguiente diagrama, se muestra una implementación del mecanismo de señal de monitoreo de funcionamiento para cambiar el patrón de siguiente salto de una ruta:

Cómo un cliente interno accede a un servicio en el que la VM principal y la secundaria intercambian información de la señal de monitoreo de funcionamiento.

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

Los nodos usan el mecanismo de señal de monitoreo de funcionamiento elegido para intercambiar información entre sí sobre el estado del servicio. Cada nodo de VM verifica su propio estado y lo comunica al nodo de VM remoto. Según el estado del nodo de la VM local y el estado que recibe el nodo remoto, se elige un nodo de VM como el nodo principal y un nodo de VM como el nodo de copia de seguridad. Una vez que un nodo se convierte en el principal, hace que el siguiente salto de la ruta para la dirección IP flotante apunte a sí mismo. Si usas Keepalived, puedes invocar una secuencia de comandos mediante la variable de configuración notify_master que reemplaza la ruta estática mediante una llamada a la API o Google Cloud CLI.

El mecanismo de señal de monitoreo de funcionamiento para cambiar el patrón de siguiente salto de una ruta no requiere que las VM formen parte de un grupo de instancias. Si deseas que las VM se reemplacen de forma automática en caso de error, puedes colocarlas en un grupo de instancias con reparación automática. También puedes reparar y volver a crear manualmente las VM que no responden.

Invocar el siguiente procedimiento en la conmutación por error garantiza que el tiempo de conmutación por error se minimice porque el tráfico se conmuta por error después de que se completa una sola llamada a la API en el paso 1:

  1. Crea una ruta estática nueva con la dirección IP flotante como destino y la instancia principal nueva como el siguiente salto. La ruta nueva debe tener un nombre de ruta diferente y una prioridad de ruta más baja (400, por ejemplo) que la ruta original.
  2. Borra la ruta original a la VM principal anterior.
  3. Crea una ruta con el mismo nombre y la misma prioridad que la ruta que acabas de borrar. Haz que apunte a la nueva VM principal como siguiente salto.
  4. Borra la ruta estática nueva que creaste. No lo necesitas para garantizar que el tráfico fluya a la nueva VM principal.

Dado que se reemplaza la ruta original, solo una ruta debe estar activa a la vez, incluso cuando hay una red dividida.

Usar el mecanismo de señal de monitoreo de funcionamiento para cambiar el patrón de prioridad de ruta en lugar de los otros patrones basados en rutas puede reducir el tiempo de conmutación por error. No es necesario borrar y reemplazar las VM a través de la reparación automática para la conmutación por error. También te brinda más control sobre cuándo conmutar por error al servidor principal original después de que vuelva a responder.

Una desventaja del patrón es que debes administrar el mecanismo de señal de monitoreo de funcionamiento por tu cuenta. Administrar el mecanismo puede generar más complejidad. Otra desventaja es que debes otorgar privilegios para cambiar la tabla de enrutamiento global a las VM que ejecutan el proceso de señal de monitoreo de funcionamiento o a una función sin servidores llamada desde el proceso de señal de monitoreo de funcionamiento. Cambiar la tabla de enrutamiento global a una función sin servidores es más seguro, ya que puede reducir el alcance de los privilegios otorgados a las VM. Sin embargo, este enfoque es más complejo de implementar.

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

Patrón que usa la reparación automática

Según los requisitos de tiempo de recuperación, es probable que la migración a una sola instancia de VM sea una opción posible cuando se usa Compute Engine. Esta opción es verdadera incluso si varios servidores que usan una dirección IP flotante se usaron de forma local. El motivo por el que se puede usar este patrón a veces pese a que se reduce la cantidad de VM es que puedes crear una instancia de Compute Engine nueva en segundos o minutos, mientras que las fallas locales, por lo general, tardan horas o incluso días en solucionarse.

Usar una instancia única de reparación automática

Mediante este patrón, dependes de que el mecanismo de reparación automática en un grupo de instancias de VM reemplace automáticamente una instancia de VM defectuosa. La aplicación expone una verificación de estado y, cuando está en mal estado, la reparación automática reemplaza la VM automáticamente.

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

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

En el diagrama anterior, se muestra cómo un cliente interno se conecta directamente a una instancia de Compute Engine ubicada en un grupo de instancias administrado 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 cargas, el patrón de reparación automática de instancia única tiene las siguientes ventajas:

  • Distribución de tráfico: Solo hay una instancia, por lo que la instancia siempre recibe todo el tráfico.
  • Facilidad de uso: Debido a que solo hay una instancia, este patrón es el menos complicado de implementar.
  • Ahorro de costos: El uso de una sola instancia de VM en lugar de dos puede reducir a la mitad el costo de la implementación.

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 cargas. Después de que las verificaciones de estado detectan una falla de la máquina, borrar y volver a crear la instancia con error lleva al menos un minuto, pero a menudo lleva más tiempo. Este patrón no es común en los entornos de producción. Sin embargo, el tiempo de conmutación por error puede ser lo suficientemente bueno para algunos servicios internos o experimentales
  • Reacción ante las fallas de zona: Un grupo de instancias administrado con un tamaño de 1 no sobrevive a una falla de zona. Para reaccionar a las fallas de zona, considera agregar una alerta de Cloud Monitoring cuando se produce una falla en el servicio y crear un grupo de instancias en otra zona ante una falla de zona. Como no puedes usar la misma dirección IP en este caso, usa una zona privada de Cloud DNS para dirigir la VM y cambiar el nombre de DNS a la nueva dirección IP.

Puedes encontrar una implementación de muestra de este patrón mediante Terraform en el repositorio de GitHub.

¿Qué sigue?