Puedes configurar un balanceador de carga de red externo de pases basado en servicios de backend para distribuir las conexiones entre instancias de máquinas virtuales (VM) en backends principales y, a continuación, cambiar a backends de conmutación por error si es necesario. La conmutación por error proporciona un método para aumentar la disponibilidad, al tiempo que te ofrece un mayor control sobre cómo gestionar tu carga de trabajo cuando las VMs de backend principales no están en buen estado.
En esta página se describen los conceptos y los requisitos específicos de la conmutación por error de los balanceadores de carga de red externos de tipo pasarela. Antes de configurar la conmutación por error de tu balanceador de carga de red de paso a través externo, familiarízate con la información conceptual de los siguientes artículos:
- Descripción general del balanceador de carga de red de paso a través externo
- Información general sobre las comprobaciones del estado
Es importante entender estos conceptos, ya que la configuración de la conmutación por error modifica el algoritmo de distribución de tráfico estándar del balanceador de carga.
De forma predeterminada, cuando añades un backend al servicio de backend de un balanceador de carga de red de paso a través externo, ese backend es un backend principal. Puede designar un backend como backend de failover cuando lo añada al servicio de backend del balanceador de carga o editando el servicio de backend más adelante. Los backends de conmutación por error solo reciben conexiones del balanceador de carga después de que un porcentaje configurable de VMs principales no supere las comprobaciones del estado.
Back-ends admitidos
Se admiten los grupos de instancias (gestionados y sin gestionar) y los NEGs zonales (con GCE_VM_IPendpoints) como backends. Para simplificar, los ejemplos de esta página muestran grupos de instancias sin gestionar.
Si usas grupos de instancias gestionados con autoescalado y conmutación por error, es posible que el grupo activo se conmute por error y vuelva a la configuración inicial repetidamente entre los back-ends principal y de conmutación por error. Google Cloud No te impide configurar la conmutación por error con grupos de instancias gestionados, ya que tu implementación puede beneficiarse de esta configuración.
Arquitectura
En el siguiente ejemplo se muestra un balanceador de carga de red de paso a través externo con un backend principal y un backend de failover.
- El backend principal es un grupo de instancias sin gestionar en
us-west1-a. - El backend de conmutación por error es otro grupo de instancias sin gestionar en
us-west1-c.
En el siguiente ejemplo se muestra un balanceador de carga de red de paso a través externo con dos back-ends principales y dos back-ends de failover, ambos distribuidos entre dos zonas de la región us-west1. Esta configuración aumenta la fiabilidad porque no depende de una sola zona para todos los back-ends principales o de conmutación por error.
- Los backends principales son grupos de instancias sin gestionar
ig-ayig-d. - Los backends de conmutación por error son grupos de instancias sin gestionar
ig-byig-c.
Durante la conmutación por error, ambos backends principales se desactivan, mientras que las VMs en buen estado de ambos backends de conmutación por error se activan. Para obtener una explicación completa de cómo funciona la conmutación por error en este ejemplo, consulta el ejemplo de conmutación por error.
Grupos de instancias y VMs de backend
Los grupos de instancias de los balanceadores de carga de red de paso a través externos son backends principales o de failover. Puedes designar un backend como backend de failover cuando lo añadas al servicio de backend o editándolo después de añadirlo. De lo contrario, los grupos de instancias son primarios de forma predeterminada.
Puedes configurar varios backends principales y varios de conmutación por error en un único balanceador de carga de red de pases externo añadiéndolos al servicio de backend del balanceador de carga.
Una VM principal es un miembro de un grupo de instancias que has definido como backend principal. Las VMs de un backend principal participan en el grupo activo del balanceador de carga (descrito en la siguiente sección), a menos que el balanceador de carga cambie a sus backends de conmutación por error.
Una VM de copia de seguridad es un miembro de un grupo de instancias que has definido como backend de conmutación por error. Las VMs de un backend de conmutación por error participan en el grupo activo del balanceador de carga cuando las VMs principales dejan de estar en buen estado. El número de VMs principales en mal estado que activa la conmutación por error es un porcentaje configurable.
Límites
- Grupos de instancias. Puede tener hasta 50 grupos de instancias de backend principales y hasta 50 grupos de instancias de backend de conmutación por error.
Grupo activo
El grupo activo es el conjunto de VMs de backend al que un balanceador de carga de red de pases externo envía nuevas conexiones. La pertenencia de las VMs de backend al grupo activo se calcula automáticamente en función de los backends que estén en buen estado y de las condiciones que especifiques, tal como se describe en Política de conmutación por error.
El grupo activo nunca combina máquinas virtuales principales y de reserva. En los siguientes ejemplos se aclaran las posibilidades de suscripción. Durante la conmutación por error, el grupo activo solo contiene VMs de copia de seguridad. Durante el funcionamiento normal (conmutación por recuperación), el grupo activo solo contiene VMs principales.
Conmutación por error y recuperación tras fallos
La conmutación por error y la restauración son los procesos automáticos que activan o desactivan las máquinas virtuales de backend en el grupo activo del balanceador de carga. Cuando Google Cloud elimina las VMs principales del grupo activo y añade VMs de conmutación por error en buen estado al grupo activo, el proceso se denomina conmutación por error. Cuando Google Cloud invierte este proceso, se denomina "failback".
Política de conmutación por error
Una política de conmutación por error es un conjunto de parámetros que Google Cloud se usa para la conmutación por error y la conmutación por recuperación. Cada balanceador de carga de red de paso a través externo tiene una política de conmutación por error con varios ajustes:
- Índice de conmutación por error
- Eliminar el tráfico cuando todas las VMs de backend estén en mal estado
- Desviación de conexiones al producirse una conmutación por error y una conmutación por recuperación
Índice de conmutación por error
Una relación de conmutación por error configurable determina cuándo Google Cloud realiza una conmutación por error o una conmutación por recuperación, lo que cambia la pertenencia al grupo activo. La relación puede ser de 0.0 a 1.0, ambos incluidos.
Si no especificas una proporción de conmutación por error, Google Cloud usa el valor predeterminado 0.0. Te recomendamos que definas la proporción de conmutación por error en un número que se adapte a tu caso práctico en lugar de usar el valor predeterminado.
| Condiciones | VMs en el grupo activo |
|---|---|
|
Todas las VMs principales en buen estado |
Si al menos una VM de copia de seguridad está en buen estado y:
|
Todas las VMs de copia de seguridad en buen estado |
| Cuando todas las VMs principales y todas las VMs de copia de seguridad no están en buen estado y no has configurado tu balanceador de carga para eliminar el tráfico en esta situación | Todas las VMs principales, como último recurso |
En los siguientes ejemplos se aclara la pertenencia al grupo activo. Para ver un ejemplo con cálculos, consulta el ejemplo de conmutación por error.
- Si el índice de conmutación por error es
1.0, todas las VMs principales deben estar en buen estado. Cuando al menos una VM principal deja de estar en buen estado, Google Cloud realiza una conmutación por error y mueve las VMs de copia de seguridad al grupo activo. - Si el índice de conmutación por error es de
0.1, al menos el 10% de las VMs principales deben estar en buen estado. De lo contrario, Google Cloud realizará una conmutación por error. - Un índice de conmutación por error de
0.0significa que Google Cloud solo realiza una conmutación por error cuando todas las VMs principales no están en buen estado. La conmutación por error no se produce si al menos una VM principal está en buen estado.
Un balanceador de carga de red de paso a través externo distribuye las conexiones entre las VMs del grupo activo según el algoritmo de distribución del tráfico.
Eliminar el tráfico cuando todas las VMs de backend estén en mal estado
De forma predeterminada, cuando todas las VMs principales y de copia de seguridad no están en buen estado, Google Cloud distribuye las nuevas conexiones entre todas las VMs principales. Lo hace como último recurso.
Si lo prefieres, puedes configurar tu balanceador de carga de red de pases externo para que rechace las nuevas conexiones cuando todas las VMs principales y de copia de seguridad no estén en buen estado.
Desviación de conexiones al producirse una conmutación por error y una conmutación por recuperación
Cuando el vaciado de conexiones está habilitado en la política de conmutación por error, las conexiones establecidas con instancias de los grupos de instancias principal o de conmutación por error se siguen enviando a las instancias con las que se han establecido, incluso después de la conmutación por error o la conmutación por recuperación, lo que evita que se interrumpan las conexiones. Si el vaciado de conexiones está inhabilitado en la política de conmutación por error, las conexiones existentes se terminarán inmediatamente durante la conmutación por error o la conmutación por recuperación.
Si el protocolo de tu balanceador de carga es TCP, se cumple lo siguiente:
La purga de conexión está habilitada de forma predeterminada. Las sesiones TCP activas pueden mantenerse en sus VMs de backend actuales aunque la VM de backend no esté en el grupo activo del balanceador de carga.
Puedes inhabilitar la desviación de conexiones durante los eventos de conmutación por error y de recuperación tras un fallo. Si se inhabilita el drenaje de conexiones durante la conmutación por error y la restauración, se asegura que todas las sesiones TCP, incluidas las establecidas, se finalicen rápidamente. Las conexiones a las VMs backend se pueden cerrar con un paquete de restablecimiento de TCP.
Inhabilitar la desviación de conexiones al producirse una conmutación por error y una conmutación por recuperación es útil en situaciones como las siguientes:
Aplicación de parches a las VMs de backend. Antes de aplicar el parche, configura tus VMs principales para que no superen las comprobaciones del estado, de forma que el balanceador de carga realice una conmutación por error. Si inhabilitas el drenaje de conexiones, todas las conexiones se moverán a las VMs de copia de seguridad rápidamente y de forma planificada. De esta forma, puedes instalar actualizaciones y reiniciar las VMs principales sin que se mantengan las conexiones. Después de aplicar el parche, Google Cloud puede realizar una conmutación por recuperación cuando un número suficiente de VMs principales (definido por el índice de conmutación por error) superen sus comprobaciones de estado.
Una sola máquina virtual backend para la coherencia de los datos. Si necesitas asegurarte de que solo una VM sea el destino de todas las conexiones, inhabilita el drenaje de conexiones para que, al cambiar de una VM principal a una de copia de seguridad, las conexiones existentes no se mantengan en ambas. De esta forma, se reduce la posibilidad de que haya incoherencias en los datos, ya que solo se mantiene activa una VM de backend en cada momento.
Ejemplo de conmutación por error
En el siguiente ejemplo se describe el comportamiento de la conmutación por error de un balanceador de carga de red externo de transferencia directa multizona, que se muestra en la sección Arquitectura.
Los backends principales de este balanceador de carga son los grupos de instancias sin gestionar ig-a en us-west1-a y ig-d en us-west1-c. Cada grupo de instancias contiene dos VMs. Las cuatro VMs de ambos grupos de instancias son VMs principales:
vm-a1enig-avm-a2enig-avm-d1enig-dvm-d2enig-d
Los backends de conmutación por error de este balanceador de carga son los grupos de instancias no gestionados
ig-b de us-west1-a y ig-c de us-west1-c. Cada grupo de instancias contiene dos VMs. Las cuatro VMs de ambos grupos de instancias son VMs de copia de seguridad:
vm-b1enig-bvm-b2enig-bvm-c1enig-cvm-c2enig-c
Supongamos que quieres configurar una política de conmutación por error para este balanceador de carga de forma que las nuevas conexiones se envíen a las VMs de copia de seguridad cuando el número de VMs principales en buen estado sea inferior a dos. Para ello, define el índice de conmutación por error en 0.5
(50%). Google Cloud usa el índice de conmutación por error para calcular el número mínimo de VMs principales que deben estar en buen estado. Para ello, multiplica el índice de conmutación por error por el número de VMs principales: 4 × 0.5 = 2
Cuando las cuatro VMs principales están en buen estado, Google Cloud distribuye las nuevas conexiones entre todas ellas. Cuando las VMs principales no superan las comprobaciones del estado:
Si
vm-a1yvm-d1dejan de estar en buen estado, Google Cloud distribuye las nuevas conexiones entre las dos VMs principales en buen estado restantes,vm-a2yvm-d2, porque el número de VMs principales en buen estado es al menos el mínimo.Si
vm-a2tampoco supera las comprobaciones del estado y solo queda una VM principal en buen estado,vm-d2, Google Cloud reconoce que el número de VMs principales en buen estado es inferior al mínimo, por lo que realiza una conmutación por error. El grupo activo se asigna a las cuatro VMs de copia de seguridad en buen estado y las nuevas conexiones se distribuyen entre esas cuatro (en los grupos de instanciasig-byig-c). Aunquevm-d2sigue en buen estado, se elimina del grupo activo y no recibe nuevas conexiones.Si
vm-a2se recupera y supera la comprobación del estado, Google Cloud reconoce que el número de VMs principales en buen estado es al menos dos, por lo que realiza una conmutación por recuperación. El grupo activo se asigna a las dos VMs principales en buen estado,vm-a2yvm-d2, y las nuevas conexiones se distribuyen entre ellas. Todas las VMs de copia de seguridad se eliminan del grupo activo.A medida que otras máquinas virtuales principales se recuperan y superan sus comprobaciones de estado, Google Cloud las añade al grupo activo. Por ejemplo, si
vm-a1pasa a estar en buen estado,Google Cloud asigna al grupo activo las tres VMs principales en buen estado (vm-a1,vm-a2yvm-d2) y distribuye las nuevas conexiones entre ellas.
Siguientes pasos
- Para configurar y probar un balanceador de carga de red de paso a través externo que utilice la conmutación por error, consulta Configurar la conmutación por error en balanceadores de carga de red de paso a través externos.
- Para configurar y probar un balanceador de carga de red de paso a través externo con un servicio de backend, consulta Configurar un balanceador de carga de red de paso a través externo.