Descripción general de la conmutación por error para el balanceo de cargas de red

Puedes configurar un balanceador de cargas de red 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 VM 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. Asegúrate de estar familiarizado con la información conceptual en los siguientes artículos antes de configurar la conmutación por error para el balanceo de cargas de red:

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 forma predeterminada, cuando agregas un backend al servicio de backend de un balanceador de cargas de red, ese backend será 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 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.
Ejemplo de conmutación por error simple para el balanceo de cargas de red (haz clic para agrandar)
Ejemplo de conmutación por error simple para el balanceo de cargas de red (haz clic para agrandar)

En el siguiente ejemplo, se muestra un balanceador de cargas de red 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-a y ig-d.
  • Los backends de conmutación por error son grupos de instancias no administrados ig-b y ig-c.
Conmutación por error del balanceo de cargas de red multizona (haz clic para ampliar)
Conmutación por error del balanceo de cargas de red multizona (haz clic para ampliar)

Durante la conmutación por error, los dos backends principales quedarán inactivos, mientras que las VM 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.

VM y grupos de instancias de backend

Los grupos de instancias en el balanceo de cargas de red 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 ú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 VM de backend a las que un balanceador de cargas de red envía conexiones nuevas. La membresía de las VM de backend en el grupo activo se calcula 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 la 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.

Grupo activo durante la conmutación por error y por recuperación (haz clic para ampliar)
Grupo activo durante la conmutación por error y por recuperación (haz clic para ampliar)

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 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 VM de backend están en mal estado
  • Vaciado de conexiones en la conmutación por error y por 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.01.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
  1. El índice de conmutación por error (x) != 0.0.
    El índice de VM principales en buen estado >= x.
  2. El índice de conmutación por error (x) = 0.0.
    La cantidad de VM principales en buen estado > 0.
Todas las VM principales en buen estado
Si al menos una VM de copia de seguridad está en buen estado y:
  1. El índice de conmutación por error (x) != 0.0.
    El índice de VM principales en buen estado  < x.
  2. El índice de conmutación por error = 0.0.
    La cantidad de VM principales en buen estado = 0.
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.0 requiere 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.1 requiere 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.0 indica 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 distribuye las conexiones entre las VM en el grupo activo de acuerdo con el algoritmo de distribución de tráfico.

Abandono del tráfico cuando todas las VM 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 entre todas las VM principales. Lo hace como último recurso.

Si lo prefieres, puedes configurar tu balanceador de cargas de red para dejar de establecer conexiones nuevas cuando todas las VM principales y de copia de seguridad estén en mal estado.

Desvío 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 instancias en los grupos de instancias principales o de conmutación por error se envían a las instancias con las que se establecieron, incluso después de la conmutación por error o por recuperación, lo que impide la interrupción de la conexión. Cuando el vaciado de conexiones está inhabilitado para la política de conmutación por error, todas las conexiones existentes se 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 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 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 en varias zonas que se presenta en la sección Arquitectura.

Conmutación por error del balanceo de cargas de red multizona (haz clic para ampliar)
Conmutación por error del balanceo de cargas de red multizona (haz clic para ampliar)

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-a1 en ig-a
  • vm-a2 en ig-a
  • vm-d1 en ig-d
  • vm-d2 en ig-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-b1 en ig-b
  • vm-b2 en ig-b
  • vm-c1 en ig-c
  • vm-c2 en ig-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-a1 y vm-d1 no están en buen estado, Google Cloud distribuye las conexiones nuevas entre las dos VM principales restantes que se encuentran en buen estado, vm-a2 y vm-d2, porque la cantidad de VM principales en buen estado es al menos la mínima.

  • Si vm-a2 tambié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 instancias ig-b y ig-c). Aunque vm-d2 se mantiene en buen estado, se quita del grupo activo y no recibe conexiones nuevas.

  • Si vm-a2 se 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-a2 y vm-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-a1 se recupera, Google Cloud establece el grupo activo en las tres VM principales en buen estado, vm-a1, vm-a2 y vm-d2, y distribuye las conexiones nuevas entre ellas.

¿Qué sigue?