Conceptos de conmutación por error para el balanceo de cargas TCP/UDP interno

Puedes configurar un balanceador de cargas TCP/UDP 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, a la vez que te brinda un mayor control sobre cómo administrar la carga de trabajo cuando tus 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 TCP/UDP internos. Asegúrate de estar familiarizado con la información conceptual en los siguientes documentos antes de configurar la conmutación por error para el balanceo de cargas TCP/UDP interno:

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 TCP/UDP interno.

Descripción general

De forma predeterminada, cuando agregas un backend al servicio de backend de un balanceador de cargas TCP/UDP interno, ese backend es primario. 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. Para simplificar, los ejemplos en esta página muestran grupos de instancias no administrados.

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. GCP no te impide configurar la conmutación por error con grupos de instancias administrados, ya que la implementación podría beneficiarse de esta configuración.

Arquitectura

El siguiente ejemplo simple muestra un balanceador de cargas TCP/UDP 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 y 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 TCP/UDP interno (haz clic para agrandar)
Ejemplo de conmutación por error simple para el balanceo de cargas TCP/UDP interno (haz clic para agrandar)

En el siguiente ejemplo, se muestra un balanceador de cargas TCP/UDP interno con dos backends principales y dos de conmutación por error, ambos distribuidos entre dos zonas en 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 los grupos de instancias no administrados ig-a y ig-d.
  • Los backends de conmutación por error son los grupos de instancias no administrados ig-b y ig-c.
Conmutación por error del balanceo de cargas TCP/UDP interno multizona (haz clic para ampliar)
Conmutación por error del balanceo de cargas TCP/UDP interno multizona (haz clic para ampliar)

Durante la conmutación por error, los dos backends principales se vuelven inactivos, mientras que las VM en buen estado de ambos backends de conmutación por error se activan. Para obtener una explicación completa sobre cómo funciona la conmutación por error en este ejemplo, consulta el ejemplo de conmutación por error.

Información acerca de los grupos de instancias de backend y las VM

Los grupos de instancias no administrados en el balanceo de cargas TCP/UDP interno son backends primarios o de conmutación por error. Puedes designar un backend para que sea de conmutación por error en el momento en que lo agregues al servicio de backend o si editas el backend después de agregarlo. De lo contrario, los grupos de instancias no administrados son principales de manera predeterminada.

Puedes configurar varios backends principales y varios de conmutación por error en un único balanceador de cargas TCP/UDP 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 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 cambie a sus backends de conmutación por error.

Una VM de copia de seguridad es un miembro de un grupo de instancias que se define 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 una proporción configurable de VM principales deja de estar en buen estado.

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 VM de backend a las que un balanceador de cargas TCP/UDP interno 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 sección Proporción de conmutación por error.

El grupo activo nunca combina VM principales y de copia de seguridad. En los siguientes ejemplos, se aclaran las posibilidades de membresía. Durante la conmutación por error, el grupo activo contiene solo VM de copia de seguridad. Durante el funcionamiento normal (conmutación por recuperación), el grupo activo contiene solo 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 GCP quita VM principales del grupo activo y agrega VM de conmutación por error en buen estado al grupo activo, el proceso se denomina conmutación por error. Cuando GCP 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 GCP usa para la conmutación por error y por recuperación. Cada balanceador de cargas TCP/UDP interno tiene una política de conmutación por error, pero esta tiene varias opciones de configuración:

  • Proporción de conmutación por error
  • Abandono del tráfico cuando todas las VM de backend están en mal estado
  • Desvío de conexiones en conmutación por error y recuperación

Proporción de conmutación por error

Una proporción de conmutación por error configurable determina cuándo GCP realiza una conmutación por error o por recuperación, lo que cambia la membresía en el grupo activo. La proporción puede ser de 0.0 a 1.0, inclusive. Si no especificas una proporción de conmutación por error, GCP usa un valor predeterminado de 0.0. Se recomienda configurar la proporción de conmutación por error como un número que sea adecuado para tu caso práctico, en lugar de depender de este valor predeterminado.

Condiciones VM en el grupo activo
  1. La proporción de conmutación por error (x) != 0.0.
    La proporción de VM principales en buen estado es >= x.
  2. La proporción 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. La proporción de conmutación por error (x) != 0.0.
    La proporción de VM principales en buen estado < x.
  2. La proporción 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 las de copia de seguridad están en mal estado y no configuraste tu balanceador de cargas para dejar de recibir 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. Consulta el ejemplo de conmutación por error para ver un ejemplo con los cálculos.

  • Una proporción 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 no está en buen estado, GCP realiza una conmutación por error y mueve las VM de copia de seguridad al grupo activo.
  • Una proporción de conmutación por error de 0.1 requiere que al menos el 10% de las VM principales estén en buen estado; de lo contrario, GCP realiza una conmutación por error.
  • Una proporción de conmutación por error de 0.0 significa que GCP realiza 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 TCP/UDP interno 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, GCP distribuye las conexiones nuevas entre todas las VM principales. Lo hace como último recurso.

Si lo prefieres, puedes configurar tu balanceador de cargas TCP/UDP interno 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

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 tu balanceador de cargas es TCP, ten en cuenta lo siguiente:

  • De manera predeterminada, el desvío de conexiones está habilitado. Las sesiones TCP existentes pueden conservarse en una VM de backend por hasta 300 segundos (10 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 desvío 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 desvío de conexiones durante la conmutación por error y por recuperación es útil para situaciones como las siguientes:

  • Aplicar parches de VM de backend: antes de aplicar parches, configura tus VM principales para que fallen las verificaciones de estado de modo que el balanceador de cargas realice una conmutación por error. Inhabilitar el desvío de la conexión 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 de parches, GCP puede realizar una conmutación por recuperación cuando una cantidad suficiente de VM principales (según la proporción de la conmutación por error) apruebe sus verificaciones de estado.

  • VM de backend única para la coherencia de los datos: si necesitas asegurarte de que solo una VM primaria sea el destino de todas las conexiones, inhabilita el desvío de conexiones para que cambiar una VM principal por una de copia de seguridad no permita que las conexiones existentes se conserven en ambas. Esto reduce la posibilidad de inconsistencias de datos si se mantiene activa solo una VM de backend en cualquier momento.

Ejemplo de conmutación por error

En el siguiente ejemplo, se describe el comportamiento de conmutación por error para el ejemplo del balanceador de cargas TCP/UDP interno multizona que se presenta en la sección Arquitectura.

Conmutación por error del balanceo de cargas TCP/UDP interno multizona (haz clic para ampliar)
Conmutación por error del balanceo de cargas TCP/UDP interno multizona (haz clic para ampliar)

Los backends principales de 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 ambos grupos de instancias son 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 ambos 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 que se entreguen nuevas conexiones a las VM de copia de seguridad cuando la cantidad de VM principales en buen estado es inferior a dos. Para lograr esto, configura la proporción de conmutación por error como 0.5 (50%). GCP usa la proporción de conmutación por error para calcular la cantidad mínima de VM principales que deben estar en buen estado mediante la multiplicación de la proporción 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, GCP distribuye nuevas conexiones a todas ellas. Cuando las VM principales fallan las verificaciones de estado, ocurre lo siguiente:

  • Si vm-a1 y vm-d1 están en mal estado, GCP distribuye nuevas conexiones entre las dos VM principales en buen estado restantes, 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 deja solo una VM principal en buen estado, vm-d2, GCP reconoce que la cantidad de VM primarias en buen estado es inferior a la mínima, por lo que realiza una conmutación por error. El grupo activo se configura como las cuatro VM de copia de seguridad en buen estado y las nuevas conexiones se distribuyen entre esas cuatro (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 nuevas conexiones.

  • Si vm-a2 se recupera y aprueba su verificación de estado, GCP 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 está configurado como las dos VM principales en buen estado, vm-a2 y vm-d2, y las nuevas conexiones 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 aprueban sus verificaciones de estado, GCP las agrega al grupo activo. Por ejemplo, si vm-a1 está ahora en buen estado, GCP configura el grupo activo como las tres VM principales, vm-a1, vm-a2 y vm-d2, y distribuye nuevas conexiones entre ellas.

Próximos pasos

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

Enviar comentarios sobre…