Prácticas recomendadas para las direcciones IP flotantes

En esta solución, se describen alternativas al uso de direcciones IP flotantes cuando se migran aplicaciones a Compute Engine desde un entorno de red local. Las direcciones IP flotantes, también conocidas como direcciones IP “compartidas” o “virtuales”, se usan a menudo para 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, lo que 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.

Direcciones IP flotantes en entornos locales

Las direcciones IP flotantes se suelen usar en entornos locales. En la siguiente lista, se describen algunos de los casos prácticos de las direcciones IP flotantes:

  • Los dispositivos físicos con alta disponibilidad, como un conjunto de cortafuegos o balanceadores de cargas, a menudo usan direcciones IP flotantes para las conmutaciones por error.
  • Por lo general, los servidores que requieren alta disponibilidad suelen usar direcciones IP flotantes, por ejemplo, bases de datos relacionales principales/secundarias como Microsoft SQL Server mediante grupos de disponibilidad Always On.
  • Los entornos de Linux que implementan balanceadores de cargas o proxies inversos usan direcciones IP flotantes, como IPVS, HAProxy o NGINX. Para detectar fallas de nodos y mover direcciones IP flotantes entre instancias, estos entornos usan daemons como heartbeat, pacemaker o keepalived.
  • Las direcciones IP flotantes permiten una alta disponibilidad con los servicios de Windows mediante el agrupamiento en clústeres de conmutación por error de Windows Server.

Existen varias formas de implementar direcciones IP flotantes en un entorno local. En todos los casos, los servidores que comparten la dirección IP también deben compartir el estado de cada uno 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í y que el servidor secundario tome la dirección IP flotante después de que falle el servidor vinculado. Con frecuencia, este esquema se implementa mediante el Protocolo de redundancia de router virtual (VRRP), pero también puedes usar otros mecanismos similares.

Una vez que se inicia la conmutación por error de la 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 el uso de la Capa 2; para ello, envía un marco injustificado del Protocolo de resolución de direcciones (ARP). Como enfoque alternativo, un protocolo de enrutamiento, como el protocolo Abrir primero la ruta más corta (OSPF), a veces comunica 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

Se usa 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, por ejemplo, el Servidor virtual de IP (IPVS). En estos casos, el servicio también envía marcos ARP injustificados, pero con una dirección MAC de otro servidor como la fuente ARP gratuita, lo que permite básicamente falsificar la identidad de los marcos ARP y tomar la dirección de origen de otro servidor. Este tipo de configuración queda fuera del alcance de la solución. En casi todos los casos, la migración al balanceo de cargas es la ruta de migración preferida.

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 típicos de implementación no funcionan de forma inmediata. Por ejemplo, la red de VPC maneja las solicitudes ARP según la tipología de enrutamiento configurada 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).

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 esta solución. En su lugar, esta solución ofrece enfoques alternativos para implementar situaciones de conmutación por error en un entorno de red nativo de Compute Engine.

En esta solución, se describen formas para migrar la mayoría de los casos prácticos descritos a Compute Engine.

Las siguientes guías paso a paso ya existen para casos prácticos más específicos:

Caso práctico de ejemplo para la migración

En esta solución, se describen cuatro opciones de migración diferentes para pasar de direcciones IP flotantes locales a Compute Engine.

El caso práctico implica la migración de dos servidores HAProxy internos que enrutan el tráfico a backends diferentes según el reemplazo y la coincidencia compleja del encabezado de Capa 7. Debido a las reglas complejas que se usan, este conjunto de servidores no se puede reemplazar por el balanceo de cargas TCP/UDP interno o incluso el balanceo de cargas de HTTP. En la siguiente figura, se muestra una descripción general de este caso práctico.

caso práctico de migración

Los servidores HAProxy usan el software keepalived local para verificar la disponibilidad mediante una conexión cruzada independiente y pasar las direcciones IP flotantes entre los dos servidores.

Para este caso práctico, las cuatro opciones que se describen en las siguientes secciones son reemplazos locales válidos para direcciones IP flotantes. Para otros casos prácticos, que podrían ser más complejos, es probable que existan menos opciones relevantes. Después de describir las opciones, en esta solución se proporciona asesoramiento sobre las opciones preferidas según casos prácticos específicos.

En la próxima sección, se analiza cómo migrar este caso práctico a Compute Engine.

Implementación mediante Compute Engine

En esta sección, se describen varias formas de migrar el entorno local a Compute Engine. Para reducir la complejidad, en lugar de usar la coincidencia basada en encabezados que se describió antes, todas las solicitudes se reenvían a un solo grupo de backends NGINX con una configuración de backend mínima.

Para todos los ejemplos, el tráfico se enruta desde HAProxy a un grupo de backends de Compute Engine ubicado en un grupo de instancias de ajuste de escala automático. Se accede a esos backends mediante un balanceador de cargas TCP/UDP interno. En el caso de la configuración de ejemplo, estos backends entregan la configuración predeterminada NGINX.

A fin de implementar el caso práctico de ejemplo, usa un proyecto dedicado a realizar pruebas.

Configura los backends

En esta sección, configurarás los backends NGINX a los que van a tener acceso los nodos HAProxy. Como recomendación, puedes crear esos backends en una VPC dedicada a esta implementación en lugar de la red predeterminada.

Para configurar los backends, sigue estos pasos:

  1. Configura la zona predeterminada, por ejemplo:

    gcloud config set compute/zone us-central1-f
    
  2. Configura una red a fin de realizar pruebas, establece reglas de firewall para permitir el tráfico interno y usa el comando ssh a fin de establecer la comunicación con la red:

    gcloud compute networks create ip-failover
    
    gcloud compute firewall-rules create failover-internal \
        --network ip-failover --allow all --source-ranges 10.128.0.0/11
    
    gcloud compute firewall-rules create failover-ssh \
        --network ip-failover --allow tcp:22 --source-ranges 0.0.0.0/0
    
  3. Crea una plantilla de instancias para los backends NGINX:

    gcloud compute instance-templates create www \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata startup-script="apt-get -y install nginx"
    
  4. Crea un grupo de instancias administrado zonal de ajuste de escala automático según la plantilla:

    gcloud compute instance-groups managed create www \
        --template www --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed set-autoscaling www \
        --max-num-replicas 10 --min-num-replicas 1 \
        --target-cpu-utilization 0.8 --zone us-central1-f
    
  5. Conecta un balanceador de cargas TCP/UDP interno con una dirección IP fija (10.128.2.2) a este grupo de instancias:

    gcloud compute health-checks create http simple-check
    
    gcloud compute backend-services create www-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks simple-check \
        --protocol tcp
    
    gcloud compute backend-services add-backend www-lb\
        --instance-group www \
        --instance-group-zone us-central1-f \
        --region us-central1
    
    gcloud compute forwarding-rules create www-rule \
        --load-balancing-scheme internal \
        --ports 80 \
        --network ip-failover \
        --region us-central1 \
        --address 10.128.2.2 \
        --backend-service www-lb
    
  6. Crea una instancia para realizar pruebas y usa el comando ssh a fin de conectarte a ella y verificar si puedes llegar a la dirección IP de balanceo de cargas TCP/UDP interno:

    gcloud compute instances create testing \
        --machine-type n1-standard-1 --zone us-central1-f \
        --network ip-failover --scopes compute-ro
    
    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.128.2.2
    <!DOCTYPE html> [...]
    username@testing:~$ exit

En esta configuración de ejemplo, se usan instancias n1-standard-1, que están limitadas por la capacidad de procesamiento de la red de dos gigabytes por segundo, por instancia. Para realizar una implementación real, deberías ajustar el tamaño de las instancias de acuerdo con tus necesidades.

Además, las instancias se crean con direcciones IP externas para que puedan descargar los paquetes necesarios mediante las secuencias de comandos de inicio. En una configuración de producción, deberías crear imágenes personalizadas y las instancias sin direcciones IP externas.

Opción 1: Usa el balanceo de cargas TCP/UDP interno

Para implementar la situación local en Compute Engine, coloca los dos servidores HAProxy en un grupo de instancias administrado detrás del balanceo de cargas TCP/UDP interno y usa la dirección IP de balanceo de cargas TCP/UDP interno como una dirección IP virtual, tal como se muestra en la figura que está a continuación.

Opción 1: Balanceo de cargas TCP/UDP interno

Se supone que el servicio migrado local solo se expone de forma interna. Si el servicio que intentas migrar está disponible de manera externa, puedes implementar este entorno de una forma similar mediante el balanceo de cargas HTTP(S), el proxy TCP, el proxy SSL o el balanceo de cargas de red.

También están disponibles las siguientes opciones solo en versión Beta:

Diferencias en comparación con una configuración local

La dirección IP de balanceo de cargas TCP/UDP interno actúa de manera similar a las direcciones IP flotantes en el entorno local, con algunas diferencias notables:

  • Distribución de tráfico

    La diferencia más notable es que el tráfico se comparte entre dos nodos, mientras que en la configuración original, el tráfico solo llega a un nodo a la vez. Este enfoque es adecuado para un entorno en el que se enruta el tráfico según el contenido de la solicitud en sí, pero no funciona si existe un estado de la máquina que no se sincroniza de manera constante, por ejemplo, una base de datos principal/secundaria.

  • Tiempo de la conmutación por error

    Usar keepalived en un entorno local cuando se vincula con un ARP injustificado podría conmutar una dirección IP en pocos segundos. En el entorno de Compute Engine, el tiempo medio de recuperación depende del modo de falla. 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, pero puede reducirse si se ajustan esos parámetros. En Compute Engine, las conmutaciones por error dentro de las zonas o entre zonas demoran la misma cantidad de tiempo.

  • Verificaciones de estado

    Cuando se usa de manera local, además de esperar una señal de activación, keepalived puede verificar el estado de la máquina host de diferentes maneras, como supervisar la disponibilidad del proceso HAProxy. En Compute Engine, se debe acceder a la verificación de estado desde fuera del host con un puerto HTTP/HTTPS/TCP o SSL. Si se deben verificar los detalles del host, tienes que instalar un servicio simple en la instancia para exponer esos detalles o elegir otra opción.

  • Puertos

    En una configuración local, las direcciones IP flotantes aceptan todo el tráfico. Para el balanceador de cargas TCP/UDP interno, debes elegir una de las siguientes especificaciones de puerto en la regla de reenvío interno:

    • Especifica al menos un puerto (hasta cinco) por número
    • Especifica ALL para reenviar el tráfico a todos los puertos.

Implementa la opción 1

Para implementar esta solución, sigue los pasos que se indican a continuación:

  1. Crea una plantilla de instancias para los servidores HAProxy que reenvían las solicitudes:

    gcloud compute instance-templates create haproxy \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    sudo apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    service haproxy restart"
    
  2. Crea un grupo de instancias zonal según las plantillas de instancias con un tamaño estático de dos. Adjunta una política de reparación automática a las instancias con la verificación de estado que creaste antes:

    gcloud compute instance-groups managed create haproxy \
        --template haproxy --size 2 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy --health-check simple-check --zone us-central1-f
    
  3. Conecta un balanceador de cargas TCP/UDP interno a los servidores HAProxy con una verificación de estado:

    gcloud compute backend-services create haproxy-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks simple-check \
        --protocol tcp
    gcloud compute backend-services add-backend haproxy-lb\
        --instance-group haproxy \
        --instance-group-zone us-central1-f \
        --region us-central1
    
    gcloud compute forwarding-rules create haproxy-rule \
        --load-balancing-scheme internal \
        --ports 80 \
        --network ip-failover \
        --region us-central1 \
        --address 10.128.1.1 \
        --backend-service haproxy-lb
    
  4. Prueba si puedes llegar al HAProxy a través del balanceo de cargas TCP/UDP interno:

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.128.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

Luego de borrar una de las instancias HAProxy a través de la consola o detener el proceso HAProxy en una de las instancias, curl seguirá funcionando de manera correcta después de un período breve de conmutación por error.

Opción 2: Usa una sola instancia administrada

Según los requisitos de tiempo de recuperación, es probable que la migración con una sola instancia de VM sea una opción viable de Compute Engine incluso si se usaron varios servidores de manera local. La razón es que puedes iniciar una instancia nueva de Compute Engine en minutos, mientras que las fallas locales, por lo general, requieren horas o incluso días para rectificarse.

Opción 2: Una sola instancia administrada

Comparación entre la opción 2 y la opción 1: Balanceo de cargas TCP/UDP interno

La opción 2 incluye las principales ventajas y desventajas en comparación con la opción 1.

Ventajas:

  • Distribución de tráfico

    Debido a que solo hay una instancia, todo el tráfico llega a una sola instancia, similar a lo que sucede en un entorno principal/secundario local.

  • 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.

  • Simplicidad

    Esta solución es fácil de implementar y viene con poca sobrecarga.

Desventajas:

  • Tiempo de la conmutación por error

    Después de que las verificaciones de estado detectan una falla de la máquina, borrar y volver a crear la instancia con error llevará al menos un minuto, pero a menudo mucho más. Este proceso es mucho más lento que quitar una instancia del balanceo de cargas TCP/UDP interno.

  • 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 crea un grupo de instancias en otra zona de forma manual ante una falla de zona.

Implementa la opción 2

Completa los siguientes pasos para implementar la opción 2:

  1. Crea una plantilla de instancias con una dirección IP interna estática para tu instancia de VM de HAProxy:

    gcloud compute instance-templates create haproxy-single \
        --machine-type n1-standard-1 --network ip-failover \
        --private-network-ip=10.128.3.3 \
        --metadata "startup-script=
    sudo apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    service haproxy restart"
    
  2. Crea un grupo de instancias administrado de tamaño 1 para la VM de HAProxy y conecta una política de reparación automática:

    gcloud compute instance-groups managed create haproxy-single \
        --template haproxy-single --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy-single --health-check simple-check --zone us-central1-f
    
  3. Prueba si puedes acceder a HAProxy a través de la dirección IP del balanceo de cargas TCP/UDP interno:

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.128.3.3
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    Cuando borras la instancia de HAProxy o detienes el proceso de la instancia de HAProxy mediante la consola, la instancia se recupera de forma automática después de un retraso con la misma dirección IP y el mismo nombre de instancia.

Opción 3: Conmutación por error con rutas de prioridad diferentes

Dos rutas de Compute Engine con prioridades diferentes proporcionan otra forma de habilitar la conmutación por error entre dos instancias cuando no puedes usar el balanceo de cargas TCP/UDP interno.

En esta sección, crearás dos instancias de VM y las reemplazarás por un grupo de instancias administrado de reparación automática con un tamaño estático de 1 que habilita el sistema para que se recupere de forma automática.

Debes habilitar el reenvío de IP en ambas instancias. Luego, después de crear las instancias, desvía todo el tráfico de IP flotante a estas dos instancias; para ello, configura dos rutas con prioridades diferentes a fin de manejar el tráfico.

Opción 3: Rutas de prioridad diferentes

Comparación entre la opción 3 y la opción 1: Balanceo de cargas de TCP/UDP interno

Con la opción 3, puedes migrar casos prácticos en los que no se puede usar el balanceo de cargas TCP/UDP interno con facilidad. Esta opción tiene las siguientes ventajas:

  • Distribución de tráfico

    El tráfico siempre fluye a la instancia de VM con la prioridad más baja. Cuando esta instancia de VM no está disponible, el tráfico usa la siguiente mejor ruta. Esta arquitectura se asemeja al entorno local en donde solo un servidor está activo en un momento dado.

  • Protocolos

    El balanceo de cargas TCP/UDP interno se aplica solo a un conjunto específico de protocolos o puertos, mientras que las rutas se aplican a todo el tráfico a un destino específico.

  • Regionalidad

    El balanceo de cargas TCP/UDP interno solo está disponible dentro de una región, mientras que las rutas pueden crearse de manera global.

La opción 3 tiene desventajas en comparación con la opción 1, que usa el balanceo de cargas TCP/UDP interno.

  • Verificaciones de estado

    Con la opción 3, no se adjunta ninguna verificación de estado a ninguna de las dos rutas. Las rutas se usan más allá de la salud de los servicios de VM subyacentes. El tráfico se dirige a las instancias, incluso si el servicio está en mal estado. Adjuntar una política de reparación automática a esas instancias produce la eliminación de tales instancias después de un período específico de mal estado, pero una vez que esas instancias se reinician, el tráfico se reanuda incluso antes de que el servicio esté activo, lo que puede dar lugar a posibles errores de servicio durante el período cuando las instancias en mal estado aún entregan el tráfico o están en el proceso de reinicio.

  • Tiempo de la conmutación por error

    Después de borrar o detener una instancia de VM, la ruta se abandona de forma automática. Sin embargo, debido a las verificaciones de estado que faltan, siempre que la instancia esté disponible, todavía es posible usar la ruta. Además, detener la instancia lleva tiempo, por lo que el tiempo de la conmutación por error es mucho mayor que con el enfoque de balanceo de cargas TCP/UDP interno.

  • Selección de la dirección IP flotante

    Puedes establecer rutas solo para las direcciones IP que no son parte de ninguna subred. La dirección IP flotante debe elegirse fuera de todos los rangos de subredes existentes.

  • Intercambio de tráfico entre redes de VPC

    Las instancias de VM solo pueden usar rutas de su propia red de VPC y no de otras redes de VPC de intercambio de tráfico.

Implementa la opción 3

Durante la implementación, usarás la dirección IP 10.191.1.1, que está fuera de todas las subredes activas en la red ip-failover. Realiza los pasos que se indican a continuación:

  1. Crea una plantilla de instancias para los servidores HAProxy que reenvían las solicitudes:

    gcloud compute instance-templates create haproxy-route \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    apt-get update
    apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.191.1.1
        netmask 255.255.255.255
    EOF
    service haproxy restart
    service networking restart" --can-ip-forward
    
  2. Crea dos grupos de instancias administrados, ambos de tamaño de 1, para las instancias de VM de HAProxy, y adjunta una política de reparación automática a esos grupos:

    gcloud compute instance-groups managed create haproxy-r1 \
        --template haproxy-route --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy-r1 --health-check simple-check --zone us-central1-f
    
    gcloud compute instance-groups managed create haproxy-r2 \
        --template haproxy-route --size 1 --zone us-central1-b
    
    gcloud compute instance-groups managed update \
        haproxy-r2 --health-check simple-check --zone us-central1-b
    
  3. Crea una ruta principal y otra de respaldo para estas instancias de VM después de que se inicien.

    haproxy1=$(gcloud compute instances list |awk '$1 \
        ~ /^haproxy-r1/ { print $1 }')
        #save the instance name of the first HAproxy instance
    
    haproxy2=$(gcloud compute instances list |awk '$1 \
        ~ /^haproxy-r2/ { print $1 }')
        #save the instance name of the second HAproxy instance
    
    gcloud compute routes create haproxy-route1 \
        --destination-range 10.191.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-f \
        --next-hop-instance $haproxy1
    
    gcloud compute routes create haproxy-route2 \
        --destination-range 10.191.1.1/32 --network ip-failover \
        --priority 600 --next-hop-instance-zone us-central1-b \
        --next-hop-instance $haproxy2
    
  4. Prueba si puedes llegar a HAProxy a través de esta ruta:

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.191.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    Cuando borras la instancia principal de HAProxy a través de la consola, se supone que la ruta a la instancia secundaria se usará cuando la instancia deje de funcionar por completo.

Opción 4: conmutación por error mediante las rutas de llamadas a la API

Al igual que la opción 3, la opción 4 también usa rutas, pero se diferencia en varios aspectos importantes. En lugar de la reparación automática y la recreación de instancias, otras secuencias de comandos o keepalived usan las llamadas a la API para agregar una ruta a una nueva instancia en buen estado o quitar una ruta de una instancia en mal estado. Este enfoque es útil en situaciones en las que no puedes usar las verificaciones de estado de Compute Engine para seguir el estado de la aplicación o determinar qué máquina virtual es la principal. Cualquier lógica de aplicación puede activar la reprogramación dinámica de las rutas.

El uso de llamadas a la API de rutas como método de conmutación por error también es útil cuando las fallas de la aplicación se investigan de forma manual y las instancias vuelven a estar en línea de la misma manera. Sin embargo, debido a que las VM deben poder registrar todas las fallas y reemplazarse de manera automática a medida que se recuperan, no investigues las fallas en Compute Engine de forma manual.

Opción 4: conmutación por error mediante las rutas de llamadas a la API

Comparación entre las diferencias de la opción 4: Balanceo de cargas de TCP/UDP interno

A diferencia del balanceo de cargas TCP/UDP interno, la opción 4 ofrece las siguientes ventajas:

  • Distribución de tráfico

    Al igual que con las opciones 2 y 3, el tráfico solo llega a una instancia de VM a la vez.

  • Sin dependencia de las verificaciones de estado de Compute Engine

    Cualquier lógica de aplicación personalizada puede activar la conmutación por error. Con la opción 4, usas una secuencia de comandos para administrar las reacciones de keepalived ante las fallas de comunicación entre los HAProxies principales y secundarios. Esta es la única opción que funciona cuando no puedes o no quieres usar las verificaciones de estado de Compute Engine.

La opción 4 también tiene grandes desventajas:

  • Complejidad

    Esta opción se debe personalizar mediante la API de Compute Engine o las llamadas a gcloud a fin de abandonar y establecer una nueva ruta mediante la API de Compute Engine. Compilar esta lógica de manera confiable suele ser complejo.

  • Tiempo de la conmutación por error

    Debido a que requiere al menos dos llamadas a la API de Compute Engine a través de una secuencia de comandos personalizada para abandonar y crear una ruta nueva en Compute Engine, la conmutación por error es un poco más lenta que con un balanceador de cargas interno.

  • Selección de la dirección IP flotante

    Puedes establecer rutas solo para las direcciones IP que no son parte de ninguna subred. Las direcciones IP flotantes deben elegirse fuera de todos los rangos de subredes existentes.

  • Intercambio de tráfico entre redes de VPC

    Las instancias de VM solo pueden usar rutas de su propia red de VPC y no de otras redes de VPC de intercambio de tráfico.

Implementa la opción 4

Esta implementación usa la dirección IP 10.190.1.1, que está fuera de todas las subredes activas en la red ip-failover. Keepalived creará y borrará de forma automática la ruta para esta dirección.

Primero, crea dos instancias de HAProxy mediante las direcciones IP internas estáticas para ambas instancias, con haproxy y keepalived instalados. También debes habilitar el reenvío de IP para poder finalizar la ruta y solicitar acceso a la API de Compute Engine. A fin de mantener la simplicidad, no usarás plantillas ni grupos de instancias en este ejemplo.

Sigue estos pasos para crear la opción 4:

  1. Crea la instancia principal con una dirección IP estática de 10.128.4.100:

    gcloud compute instances create haproxy-a \
        --machine-type n1-standard-1 --network ip-failover \
        --can-ip-forward --private-network-ip=10.128.4.100 \
        --scopes compute-rw --zone us-central1-f \
        --metadata 'startup-script=
    apt-get update
    apt-get install -y haproxy keepalived
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.190.1.1
        netmask 255.255.255.255
    EOF
    cat << EOF >> /etc/keepalived/keepalived.conf
    vrrp_script haproxy {
        script "/bin/pidof haproxy"
        interval 2
    }
    
    vrrp_instance floating_ip {
        state MASTER
        interface eth0
        track_script {
            haproxy
        }
        unicast_src_ip 10.128.4.100
        unicast_peer {
            10.128.4.200
        }
        virtual_router_id 50
        priority 100
        authentication {
            auth_type PASS
            auth_pass yourpassword
        }
        notify_master /etc/keepalived/takeover.sh
    }
    EOF
    cat << EOF >> /etc/keepalived/takeover.sh
    #!/bin/bash
    gcloud compute routes delete floating --quiet
    gcloud compute routes create floating \
        --destination-range 10.190.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-f \
        --next-hop-instance haproxy-a --quiet
    EOF
    chmod +x /etc/keepalived/takeover.sh
    service haproxy restart
    service networking restart
    service keepalived start'
    
  2. Crea la instancia secundaria con una dirección IP estática de 10.128.4.200:

    gcloud compute instances create haproxy-b \
        --machine-type n1-standard-1 --network ip-failover \
        --can-ip-forward --private-network-ip=10.128.4.200 \
        --scopes compute-rw --zone us-central1-c \
        --metadata 'startup-script=
    apt-get update
    apt-get install -y haproxy keepalived
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.190.1.1
        netmask 255.255.255.255
    EOF
    cat << EOF >> /etc/keepalived/keepalived.conf
    vrrp_script haproxy {
        script "/bin/pidof haproxy"
        interval 2
    }
    
    vrrp_instance floating_ip {
        state BACKUP
        interface eth0
        track_script {
            haproxy
        }
        unicast_src_ip 10.128.4.200
        unicast_peer {
            10.128.4.100
        }
        virtual_router_id 50
        priority 50
        authentication {
            auth_type PASS
            auth_pass yourpassword
        }
        notify_master /etc/keepalived/takeover.sh
    }
    EOF
    cat << EOF >> /etc/keepalived/takeover.sh
    #!/bin/bash
    gcloud compute routes delete floating --quiet
    gcloud compute routes create floating \
        --destination-range 10.190.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-c \
        --next-hop-instance haproxy-b --quiet
    EOF
    chmod +x /etc/keepalived/takeover.sh
    service haproxy restart
    service networking restart
    service keepalived start'
    
  3. Prueba si puedes llegar a HAProxy a través de esta ruta:

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.190.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    Cuando se elimina HAProxy en la instancia haproxy-a o la instancia se bloquea, faltarán las señales de monitoreo de funcionamiento de VRRP y la instancia haproxy-b invoca la secuencia de comandos takeover.sh. Esta secuencia de comandos mueve la ruta para 10.190.1.1 de haproxy-a a haproxy-b, y la prueba igual funcionará.

Elige la mejor opción para tu caso práctico

Para los casos prácticos de ejemplo que involucran un conjunto de nodos HAProxy que toman decisiones de enrutamiento complejas, la implementación preferida de Compute Engine es la Opción 1: Balanceo de cargas TCP/UDP interno. Esto se debe a que las instancias de VM están sin estado y pueden funcionar a la perfección en un entorno de activo a activo. Además, se pueden usar las verificaciones de estado de Compute Engine. Con otros casos prácticos, es posible que la opción 1 no sea la mejor.

Además de las ventajas y las desventajas antes mencionadas para cada opción, el siguiente árbol de decisión puede ayudarte a elegir un plan de implementación.

árbol de decisión

Las aplicaciones confiables con alta disponibilidad se implementan mejor en Compute Engine mediante arquitecturas de escalamiento horizontal, lo que minimiza el impacto de una falla de nodo único. La migración de un entorno local típico, como dos servidores con direcciones IP flotantes, es un desafío porque este entorno no puede duplicarse en Compute Engine. Como se indicó antes, mover direcciones IP entre máquinas diferentes en subsegundos mediante un ARP injustificado no funciona debido a la naturaleza de la infraestructura de enrutamiento virtual.

El balanceo de cargas TCP/UDP interno permite que muchos casos prácticos se transfieran de manera simple y confiable a Compute Engine. Para los casos en los que no puedes usar el balanceador de cargas interno, puedes implementar otras opciones que no requieren mecanismos complejos de enrutamiento de superposición.

Próximos pasos