Puedes configurar un balanceador de cargas de red de transferencia basado en servicios de backend para distribuir conexiones entre instancias de máquina virtual (VM) en backends principales y, si es necesario, cambiar a backends de conmutación por error. La conmutación por error proporciona un método para aumentar la disponibilidad y, también, te brinda un mayor control sobre cómo administrar la carga de trabajo cuando las VMs de backend principales no están en buen estado.
En esta página, se describen conceptos y requisitos específicos para la conmutación por error de balanceadores de cargas de red de transferencia externos. Asegúrate de estar familiarizado con la información conceptual de los siguientes artículos antes de configurar la conmutación por error para balanceadores de cargas de red de transferencia externos:
- Descripción general del balanceador de cargas de red de transferencia externo
- Descripción general de las verificaciones de estado
Es importante comprender estos conceptos porque la configuración de la conmutación por error modifica el algoritmo de distribución de tráfico estándar del balanceador de cargas.
De forma predeterminada, cuando agregas un backend al servicio de backend de un balanceador de cargas de red de transferencia externo, ese backend es el principal. Puedes designar un backend para que sea de conmutación por error cuando lo agregues al servicio de backend del balanceador de cargas o si editas el servicio de backend más adelante. Los backends de conmutación por error solo reciben conexiones del balanceador de cargas después de que una proporción configurable de VM principales no apruebe las verificaciones de estado.
Backends compatibles
Los grupos de instancias (administrados y no administrados) y los NEG zonales (con extremos GCE_VM_IP) se admiten como backends. En los ejemplos de esta página, se muestran grupos de instancias no administrados para una mayor simplicidad.
El uso de grupos de instancias administrados con ajuste de escala automático y conmutación por error puede provocar que el grupo activo realice conmutaciones por error y por recuperación de forma repetida entre el backend principal y el de conmutación por error. Google Cloud no te impide configurar la conmutación por error con grupos de instancias administrados, ya que la implementación podría beneficiarse con esta configuración.
Arquitectura
En el siguiente ejemplo, se muestra un balanceador de cargas de red de transferencia externo de transferencia con un backend principal y uno de conmutación por error.
- El backend principal es un grupo de instancias no administrado en
us-west1-a. - El backend de conmutación por error es un grupo de instancias no administrado diferente en
us-west1-c.
En el siguiente ejemplo, se muestra un balanceador de cargas de red de transferencia externo con dos backends principales y dos de conmutación por error, distribuidos entre dos zonas de la región us-west1. Esta configuración aumenta la confiabilidad porque no depende de una sola zona para todos los backends principales o los de conmutación por error.
- Los backends principales son grupos de instancias no administrados
ig-ayig-d. - Los backends de conmutación por error son grupos de instancias no administrados
ig-byig-c.
Durante la conmutación por error, los dos backends principales quedarán inactivos, mientras que las VMs en buen estado de ambos backends de conmutación por error se activarán. Para obtener una explicación completa de cómo funciona la conmutación por error en este ejemplo, consulta Ejemplo de conmutación por error.
VMs y grupos de instancias de backend
Los grupos de instancias en los balanceadores de cargas de red de transferencia externos son backends principales o de conmutación por error. Puedes designar un backend como backend de conmutación por error cuando lo agregas al servicio de backend o si lo editas después de agregarlo. De lo contrario, los grupos de instancias son los principales de forma predeterminada.
Puedes configurar varios backends principales y varios de conmutación por error en un balanceador de cargas de red de transferencia externo único agregándolos al servicio de backend del balanceador de cargas.
Una VM principal es un miembro de un grupo de instancias que se define como un backend principal. Las VM de un backend principal participan en el grupo activo del balanceador de cargas (descrito en la siguiente sección), a menos que el balanceador de cargas pase a usar los backends de conmutación por error.
Una VM de copia de seguridad es un miembro de un grupo de instancias que definiste como un backend de conmutación por error. Las VM en un backend de conmutación por error participan en el grupo activo del balanceador de cargas cuando las VM principales están en mal estado. La cantidad de VM principales en mal estado que activa la conmutación por error es un porcentaje configurable.
Límites
- Grupos de instancias: Puedes tener hasta 50 grupos de instancias de backend principales y 50 grupos de instancias de backend de conmutación por error.
Grupo activo
El grupo activo es el conjunto de VMs de backend a las que un balanceador de cargas de red de transferencia externo envía conexiones nuevas. La membresía de las VMs de backend en el grupo activo se procesa de forma automática en función de qué backends están en buen estado y las condiciones que puedes especificar, como se describe en Política de conmutación por error.
El grupo activo nunca combina VM principales y VM de copia de seguridad. En los siguientes ejemplos, se aclaran las posibilidades de membresía. Durante la conmutación por error, el grupo activo solo contiene las VM de copia de seguridad. Durante el funcionamiento normal (conmutación por recuperación), el grupo activo solo contiene las VM principales.
Conmutación por error y por recuperación
La conmutación por error y la conmutación por recuperación son los procesos automáticos que agregan las VM de backend al grupo activo del balanceador de cargas o las sacan de él. Cuando Google Cloud quita las VM principales del grupo activo y agrega las VM de conmutación por error en buen estado, el proceso se denomina conmutación por error. Cuando Google Cloud revierte esto, el proceso se denomina conmutación por recuperación.
Política de conmutación por error
Una política de conmutación por error es un conjunto de parámetros que Google Cloud usa para la conmutación por error y por recuperación. Cada balanceador de cargas de red de transferencia externo tiene una política de conmutación por error con varias opciones de configuración:
- Proporción de conmutación por error
- Abandono del tráfico cuando todas las VMs de backend están en mal estado
- Vaciado de conexiones en conmutación por error y recuperación
Índice de conmutación por error
Un índice de conmutación por error configurable determina en qué momento Google Cloud realiza una conmutación por error o por recuperación, y cambia la membresía en el grupo activo. El índice puede ser de 0.0 a 1.0, inclusive.
Si no especificas un índice de conmutación por error, Google Cloud usa un valor predeterminado de 0.0. Se recomienda configurar el índice de conmutación por error en un número adecuado para tu caso de uso, en lugar de basarse en este valor predeterminado.
| Condiciones | VM en el grupo activo |
|---|---|
|
Todas las VM principales en buen estado |
Si al menos una VM de copia de seguridad está en buen estado y:
|
Todas las VM de copia de seguridad en buen estado |
| Cuando todas las VM principales y de copia de seguridad están en mal estado, y no configuraste el balanceador de cargas para abandonar tráfico durante esta situación. | Todas las VM principales, como último recurso |
En los siguientes ejemplos, se aclara la membresía en el grupo activo. Para obtener un ejemplo con los cálculos, consulta Ejemplo de conmutación por error.
- Un índice de conmutación por error de
1.0requiere que todas las VM principales estén en buen estado. Cuando al menos una VM principal está en mal estado, Google Cloud realiza una conmutación por error y traslada las VM de copia de seguridad al grupo activo. - Un índice de conmutación por error de
0.1requiere que al menos el 10% de las VM principales esté en buen estado. De lo contrario, Google Cloud realizará una conmutación por error. - Un índice de conmutación por error de
0.0indica que Google Cloud realizará una conmutación por error solo cuando todas las VM principales estén en mal estado. La conmutación por error no ocurre si al menos una VM principal está en buen estado.
Un balanceador de cargas de red de transferencia externa distribuye las conexiones entre las VMs en el grupo activo de acuerdo con el algoritmo de distribución de tráfico.
Abandono del 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 están en mal estado, Google Cloud distribuye las conexiones nuevas entre todas las VMs principales. Lo hace como último recurso.
Si lo prefieres, puedes configurar tu balanceador de cargas de red de transferencia externo para dejar de establecer conexiones nuevas cuando todas las VMs principales y de copia de seguridad estén en mal estado.
Vaciado de conexiones en conmutación por error y recuperación
Cuando el vaciado de conexiones está habilitado para la política de conmutación por error, las conexiones establecidas a las instancias en los grupos de instancias principales o de conmutación por error continúan enviando a las instancias con las que se establecieron, incluso después de la conmutación por error o por recuperación, lo que evita la interrupción de la conexión. Cuando el vaciado de conexiones está inhabilitado para la política de conmutación por error, las conexiones existentes finalizan de inmediato durante la conmutación por error o por recuperación.
Si el protocolo para el balanceador de cargas es TCP, se cumple lo siguiente:
De forma predeterminada, el vaciado de conexiones está habilitado. Las sesiones de TCP existentes se pueden mantener en las VM de backend actuales, incluso si la VM de backend no está en el grupo activo del balanceador de cargas.
Puedes inhabilitar el vaciado de conexiones durante los eventos de conmutación por error y por recuperación. Inhabilitar el desvío de conexiones durante la conmutación por error y por recuperación garantiza que todas las sesiones TCP, incluidas las establecidas, se finalicen con rapidez. Las conexiones a las VM de backend pueden cerrarse con un paquete de restablecimiento de TCP.
Inhabilitar el vaciado de conexiones en la conmutación por error y por recuperación es útil para situaciones como las siguientes:
Aplica un parche a las VM de backend. Antes de aplicar el parche, configura las VM principales para que fallen las verificaciones de estado, de modo que el balanceador de cargas realice una conmutación por error. Inhabilitar el vaciado de conexiones garantiza que todas las conexiones se muevan a las VM de copia de seguridad de forma planificada y rápida. Esto te permite instalar actualizaciones y reiniciar las VMs principales sin que se conserven las conexiones existentes. Después de la aplicación del parche, Google Cloud puede realizar una conmutación por recuperación cuando una cantidad suficiente de VM principales (según lo indica el índice de conmutación por error) aprueba sus verificaciones de estado.
VM de backend única para la coherencia de datos. Si necesitas asegurarte de que solo una VM sea el destino de todas las conexiones, inhabilita el vaciado de conexiones para que cambiar una VM principal a una de copia de seguridad no permita que las conexiones existentes se conserven en ambas. Esto reduce la posibilidad de incoherencia de datos si se mantiene activa una sola VM de backend en cualquier momento.
Ejemplo de conmutación por error
En el siguiente ejemplo, se describe el comportamiento de la conmutación por error para el ejemplo del balanceador de cargas de red de transferencia externa multizona que se presenta en la sección Arquitectura.
Los backends principales para este balanceador de cargas son los grupos de instancias no administrados ig-a en us-west1-a y ig-d en us-west1-c. Cada grupo de instancias contiene dos VM. Las cuatro VM de los dos grupos de instancias son VM principales:
vm-a1enig-avm-a2enig-avm-d1enig-dvm-d2enig-d
Los backends de conmutación por error para este balanceador de cargas son los grupos de instancias no administrados ig-b en us-west1-a y ig-c en us-west1-c. Cada grupo de instancias contiene dos VM. Las cuatro VM de los dos grupos de instancias son VM de copia de seguridad:
vm-b1enig-bvm-b2enig-bvm-c1enig-cvm-c2enig-c
Supongamos que deseas configurar una política de conmutación por error para este balanceador de cargas de modo tal que las conexiones nuevas se entreguen a las VM de copia de seguridad cuando la cantidad de VM principales en buen estado sea inferior a dos. Para lograrlo, establece el índice de conmutación por error en 0.5 (50%). Google Cloud usa el índice de conmutación por error para calcular la cantidad mínima de VM principales que deben estar en buen estado mediante la multiplicación del índice de conmutación por error por la cantidad de VM principales: 4 × 0.5 = 2
Cuando las cuatro VM principales están en buen estado, Google Cloud distribuye las conexiones nuevas a todas ellas. Cuando las VM principales fallan las verificaciones de estado, ocurre lo siguiente:
Si
vm-a1yvm-d1no están en buen estado, Google Cloud distribuye las conexiones nuevas entre las dos VM principales restantes que se encuentran en buen estado,vm-a2yvm-d2, porque la cantidad de VM principales en buen estado es al menos la mínima.Si
vm-a2también falla en las verificaciones de estado y solo queda una VM principal en buen estado,vm-d2, Google Cloud reconoce que la cantidad de VM principales en buen estado es inferior a la mínima, por lo que realiza una conmutación por error. El grupo activo se establece en las cuatro VM de copia de seguridad en buen estado, y las conexiones nuevas se distribuyen entre ellas (en los grupos de instanciasig-byig-c). Aunquevm-d2se mantiene en buen estado, se quita del grupo activo y no recibe conexiones nuevas.Si
vm-a2se recupera y pasa su verificación de estado, Google Cloud reconoce que la cantidad de VM principales en buen estado es al menos la mínima de dos, por lo que realiza una conmutación por recuperación. El grupo activo se establece en las dos VM principales en buen estado,vm-a2yvm-d2, y las conexiones nuevas se distribuyen entre ellas. Todas las VM de copia de seguridad se quitan del grupo activo.A medida que otras VM principales se recuperan y pasan sus verificaciones de estado, Google Cloud las agrega al grupo activo. Por ejemplo, si
vm-a1se recupera, Google Cloud establece el grupo activo en las tres VM principales en buen estado,vm-a1,vm-a2yvm-d2, y distribuye las conexiones nuevas entre ellas.
¿Qué sigue?
- Para configurar y probar un balanceador de cargas de red de transferencia externo que usa conmutación por error, consulta Configura la conmutación por error para balanceadores de cargas de red de transferencia externos.
- Para configurar y probar un balanceador de cargas de red de transferencia externo con un servicio de backend, consulta Configura un balanceador de cargas de red de transferencia externo.