Recomendaciones para las direcciones IP flotantes

Esta solución describe alternativas al uso de direcciones IP flotantes cuando se migran aplicaciones a Google Compute Engine desde un entorno de red local. Las IP flotantes, que también se conocen como direcciones IP "compartidas" o "virtuales", a menudo se utilizan para que los entornos de red locales cuenten con alta disponibilidad. Con el uso de IP flotantes, puedes pasar una dirección IP entre varios servidores virtuales o físicos 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 directamente IP flotantes en un entorno de Compute Engine.

IP flotantes en entornos locales

Las IP flotantes se utilizan comúnmente en entornos locales. La siguiente lista describe solo algunos de los casos prácticos relativos a las IP flotantes:

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

Existen varias maneras de implementar 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 mutuamente su estado, y también permite 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 Virtual Router Redundancy Protocol (VRRP), pero también puedes utilizar otros mecanismos similares.

Una vez que se inicia la conmutación por error de la IP, el servidor que toma 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 Open Shortest Path First (OSPF) a veces comunica la dirección IP al router ascendente de la Capa 3.

El siguiente diagrama muestra una configuración típica en un entorno local.

entorno local típico

Utilizas una configuración ligeramente 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 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 a Balanceo de cargas es la ruta de migración preferida.

Desafíos relacionados con la migración de IP flotantes a Compute Engine

Compute Engine utiliza 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 manera 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 utilizar 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 entornos de conmutación por error en un entorno de red nativo de Compute Engine.

Esta solución describe formas de 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

Esta solución describe cuatro opciones de migración diferentes para pasar de 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 utilizan, este conjunto de servidores no se puede reemplazar por balanceo de cargas interno ni por el balanceo de cargas de HTTP. La siguiente figura muestra una descripción general de este caso práctico.

caso práctico de migración

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

Para este caso práctico, las cuatro opciones que se describen en las siguientes secciones son reemplazos locales válidos para las IP flotantes. Para otros casos prácticos, posiblemente más complejos, es probable que existan opciones menos relevantes. Después de describir estas opciones, esta solución 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 con Compute Engine

Esta sección describe varias formas de migrar el entorno local a Compute Engine. Para reducir la complejidad, en lugar de utilizar la coincidencia basada en encabezado que se describió anteriormente, 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 con el uso de un balanceador de cargas interno. En el caso de la configuración de ejemplo, estos backends entregan la configuración predeterminada NGINX.

Para implementar el caso práctico de ejemplo, utiliza un proyecto dedicado para realizar pruebas.

Configurar los backends

En esta sección, vas a configurar 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 para realizar pruebas y establece las reglas de firewall para permitir el tráfico interno, y utiliza el comando ssh para que se comunique 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. Adjunta un balanceador de cargas 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 utiliza el comando ssh para que se conecte a esa instancia, y verifica si puedes llegar a la IP de balanceo de cargas 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

Esta configuración de ejemplo utiliza 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 medir 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 crear instancias sin direcciones IP externas.

Opción 1: Usar el balanceo de cargas interno

Puedes implementar un entorno local en Compute Engine; para ello, coloca los dos servidores HAProxy en un Grupo de instancias administrado detrás del Balanceo de cargas interno y utiliza la IP de balanceo de cargas interno como una IP virtual, tal como se muestra en la figura que sigue a continuación.

opción 1: balanceo de cargas interno

Diferencias en comparación con una configuración local

La IP de balanceo de cargas interno actúa de manera similar a las IP flotantes en el entorno local, con algunas diferencias notables:

  • Distribución del 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 llega únicamente 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

    El uso de keepalived en un entorno local cuando se sincroniza con un ARP injustificado podría fallar en una IP en pocos segundos. En el entorno de Compute Engine, el tiempo de recuperación promedio depende del modo de falla. En caso de que la instancia de máquina virtual (VM) o el servicio de la instancia de VM falle, el tiempo promedio del tráfico de conmutación por error depende de los 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 mediante el ajuste de esos parámetros. En Compute Engine, las conmutaciones por error dentro de las zonas o entre zonas demoran la misma cantidad de tiempo.

  • Verificación de estado

    Cuando se utiliza de manera local y, además, se espera 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 una opción alternativa.

  • Puertos

    En una configuración local, las IP flotantes aceptan todo el tráfico, mientras que el Balanceo de cargas interno limita el reenvío a un máximo de cinco puertos.

Implementar 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 anteriormente:

    gcloud compute instance-groups managed create haproxy \
        --template haproxy --size 2 --zone us-central1-f
    
    gcloud beta compute instance-groups managed set-autohealing \
        haproxy --health-check simple-check --zone us-central1-f
    
  3. Adjunta un balanceador de cargas 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 a HAProxy a través de un balanceo de cargas interno:

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

Después 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: Usar 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 utilizaron 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 interno

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

Ventajas:

  • Distribución del tráfico

    Debido a que solo hay una instancia, todo el tráfico llega a una sola instancia similar a 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 interno.

  • Reacción ante las fallas de zona

    Un grupo de instancias administrado con un tamaño de uno no sobrevive a una falla de zona. Para reaccionar ante las fallas de zona, considera agregar una alerta de Stackdriver Monitoring cuando se produce una falla en el servicio, y crea manualmente un grupo de instancias en otra zona en caso de una falla de zona.

Implementar la opción 2

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

  1. Crea una plantilla de instancias para la instancia de VM de HAProxy:

    gcloud compute instance-templates create haproxy-single \
        --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 administrado de tamaño de uno para la VM de HAProxy y adjunta 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 beta compute instance-groups managed set-autohealing \
        haproxy-single --health-check simple-check --zone us-central1-f
    
  3. Prueba si puedes llegar a HAProxy a través de una IP de balanceo de cargas interno:

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ instance=$(gcloud compute instances list |awk '$1 ~ /^haproxy-single/ { print $1 }')
    
    username@testing:~$ curl $instance
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    Cuando borras la instancia de HAProxy o detienes el proceso de instancia de HAProxy con el uso de la consola, se supone que la instancia se recupera automáticamente 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 manera de habilitar la conmutación por error de tráfico entre dos instancias cuando no puedes usar el balanceo de cargas interno.

En esta sección, puedes crear dos instancias de VM y reemplazarlas por un grupo de instancias administrado de reparación automática con un tamaño estático de uno que habilita el sistema para que se recupere automáticamente.

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 interno

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

  • Distribución del 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 utiliza 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 interno solo se aplica a un conjunto específico de protocolos o puertos, mientras que las rutas se aplican a todo el tráfico de un destino específico.

  • Regionalidad

    El balanceo de cargas interno solo está disponible dentro una región, mientras que las rutas pueden crearse de forma mundial.

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

  • Verificación de estado

    Con la opción 3, no se adjunta ninguna verificación de estado a ninguna de las dos rutas. Las rutas se utilizan independientemente del estado 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 automáticamente. Sin embargo, debido a las verificaciones de estado que faltan, siempre que la instancia esté disponible, todavía es posible utilizar la ruta. Además, detener la instancia lleva tiempo, por lo que el tiempo de la conmutación por error es considerablemente mayor que con el enfoque de balanceo 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. 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.

Implementar la opción 3

Durante la implementación, utilizará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 uno, para las instancias de VM de HAProxy, y adjunta una política de reparación automática a tales grupos:

    gcloud compute instance-groups managed create haproxy-r1 \
        --template haproxy-route --size 1 --zone us-central1-f
    
    gcloud beta compute instance-groups managed set-autohealing \
        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 beta compute instance-groups managed set-autohealing \
        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 hayan iniciado.

    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 la 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 utiliza 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 utilizan las llamadas a la API para agregar una ruta a una instancia en buen estado nueva o quitar una ruta de una instancia en mal estado. Este enfoque es útil en situaciones en las que no puedes utilizar 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 manualmente y las instancias se vuelven a conectar manualmente en línea. Sin embargo, debido a que las VM deben poder registrar todas las fallas y reemplazarse automáticamente a medida que se recuperan, no investigues manualmente las fallas en Compute Engine.

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

Comparar las diferencias de la opción 4: balanceo de cargas interno

A diferencia del uso de balanceo de cargas interno, la opción 4 ofrece estas ventajas:

  • Distribución del 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, utiliza 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 utilizar las verificaciones de estado de Compute Engine.

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

  • Complejidad

    Esta opción debe personalizarse con la API de Compute Engine o las llamadas a gcloud para abandonar y establecer una ruta nueva con el uso de la API de Compute Engine. Compilar esta lógica de una manera confiable a menudo es 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 ligeramente 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.

Implementar la opción 4

Esta implementación utiliza 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á automáticamente la ruta para esta dirección.

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

Crea la opción 4 con los siguientes pasos:

  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 secundario 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 la 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 seguirá funcionando.

Elegir la mejor opción para el 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 interno. Esto se debe a que las instancias de VM están sin estado y pueden funcionar perfectamente 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 opción.

Además de las ventajas y las desventajas mencionadas con anterioridad para cada opción, el siguiente esquema de decisiones puede ayudarte a elegir un plan de implementación.

esquema de decisiones

Las aplicaciones altamente disponibles y confiables se implementan mejor en Compute Engine con el uso de 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 IP flotantes, representa un desafío porque este entorno no puede duplicarse en Compute Engine. Como se señaló anteriormente, mover direcciones IP entre máquinas diferentes en subsegundos con el uso de un ARP injustificado no funciona debido a la naturaleza de la infraestructura de enrutamiento virtual.

El balanceo de cargas interno permite que muchos casos prácticos se transfieran de forma 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.

Pasos siguientes

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

Compute Engine Documentation