Puedes configurar un balanceador de cargas de transferencia interno 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 internos. Asegúrate de estar familiarizado con la información conceptual en los siguientes artículos antes de configurar la conmutación por error para los balanceadores de cargas de red de transferencia internos:
- Descripción general del balanceador de cargas de red de transferencia interna
- 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 red de transferencia interno.
De forma predeterminada, cuando agregas un backend al servicio de backend de un balanceador de cargas de red de transferencia interno, 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.
Grupos de instancias compatibles
Los grupos de instancias administrados y no administrados son compatibles 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 hacer que el grupo activo realice conmutaciones por error y por recuperación de forma repetida entre los backends principales y los 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 simple, se muestra un balanceador de cargas de red de transferencia interno 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 interno 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 no administrados en los balanceadores de cargas de red de transferencia internos 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 no administrados son los principales de forma predeterminada.
Puedes configurar varios backends principales y de conmutación por error en un único balanceador de cargas de red de transferencia interno si los agregas 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 en mal estado que activa la conmutación por error es un porcentaje configurable.
Límites
VM: Puedes tener hasta 250 VM en el grupo activo. En otras palabras, los grupos de instancias de backend principales pueden tener un total de hasta 250 VM principales, y los grupos de instancias de backend de conmutación por error pueden tener un total de hasta 250 VM de copia de seguridad.
Grupos de instancias no administrados. Puedes tener hasta 50 grupos de instancias de backend principales y hasta 50 grupos de instancias de backend de conmutación por error.
Como ejemplo, una implementación máxima puede tener 5 backends principales y 5 backends de conmutación por error, con cada grupo de instancias que contiene 50 VM.
Grupo activo
El grupo activo es el conjunto de VMs de backend a las que un balanceador de cargas de red de transferencia interno 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 Índice 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 interno tiene una política de conmutación por error con varias opciones de configuración:
- Índice 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 interno 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 VM principales y de copia de seguridad están en mal estado, Google Cloud distribuye las conexiones nuevas solo entre las VM principales. Lo hace como último recurso. Las VMs de copia de seguridad se excluyen de esta distribución de conexiones de último recurso.
Si lo prefieres, puedes configurar tu balanceador de cargas de red de transferencia interno 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
El desvío de conexiones permite que las sesiones TCP existentes permanezcan activas durante un período configurable incluso después de que las VM de backend estén en mal estado. 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 TCP existentes pueden conservarse en una VM de backend por hasta 300 segundos (5 minutos), incluso si la VM de backend está en mal estado o 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:
Aplicar 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 VM 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 principal sea el destino de todas las conexiones, inhabilita el vaciado de conexiones para que el cambio de 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 interno en varias zonas 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 interno que usa la conmutación por error, consulta Configura la conmutación por error para balanceadores de cargas de red de transferencia internos.
- Para configurar y probar un balanceador de cargas de red de transferencia interno, consulta Configura un balanceador de cargas de red de transferencia interno.
- Para solucionar problemas con el balanceador de cargas de red de transferencia interno, consulta Soluciona problemas del balanceador de cargas de red de transferencia interno.