Transición de un balanceador de cargas de red de grupos de destino a servicios de backend regionales

1. Introducción

En esta guía, se proporcionan instrucciones para realizar la transición de un balanceador de cargas de red existente de un backend de grupo de destino a un servicio de backend regional.

Qué aprenderás

  • Comprende los beneficios de los servicios de backend regionales
  • Crea un balanceador de cargas de red con grupos de destino
  • Realiza la validación del grupo de destino
  • Crea un servicio de backend regional con grupos de instancias no administrados
  • Realiza la migración del grupo de destino al servicio de backend
  • Realiza la validación de los servicios de backend

Requisitos

  • Experiencia con balanceadores de cargas

2. Descripción general de los servicios de backend regionales para el balanceo de cargas de red

Con el balanceo de cargas de red, los clientes de Google Cloud tienen una herramienta potente para distribuir el tráfico externo entre máquinas virtuales en una región de Google Cloud. Para que a nuestros clientes les resulte más fácil administrar el tráfico entrante y controlar cómo se comporta el balanceador de cargas, recientemente agregamos compatibilidad con servicios de backend al balanceo de cargas de red. Esto proporciona mayor escala, velocidad, rendimiento y resiliencia a nuestros clientes en su implementación, todo de una manera fácil de administrar.

Ahora admitimos servicios de backend con balanceo de cargas de red, una mejora significativa con respecto al enfoque anterior, los grupos de destino. Un servicio de backend define cómo nuestros balanceadores de cargas distribuyen el tráfico entrante a los backends adjuntos y proporciona un control detallado sobre cómo se comporta el balanceador de cargas.

3. Beneficios de los servicios de backend regionales

Elegir un servicio de backend regional como balanceador de cargas aporta una serie de ventajas a tu entorno.

267db35a58145be.png

De forma predeterminada, los servicios de backend regionales proporcionan lo siguiente:

  • Verificación de estado de alta fidelidad con verificación de estado unificada: Con los servicios de backend regionales, ahora puedes aprovechar al máximo las funciones de verificación de estado del balanceo de cargas, lo que te libera de las restricciones de las verificaciones de estado HTTP heredadas. Por motivos de cumplimiento, las verificaciones de estado de TCP compatibles con cadenas de solicitud y respuesta personalizadas o HTTPS eran una solicitud común para los clientes de balanceo de cargas de red.
  • Mejor resiliencia con los grupos de conmutación por error: con los grupos de conmutación por error, puedes designar un grupo de instancias como primario y otro como secundario, y conmutar por error el tráfico cuando el estado de las instancias en el grupo activo cae por debajo de cierto umbral. Para obtener más control sobre el mecanismo de conmutación por error, puedes usar un agente como keepalived o pacemaker y exponer una verificación de estado en buen estado o con errores según los cambios de estado de la instancia de backend.
  • Escalabilidad y alta disponibilidad con grupos de instancias administrados: Los servicios de backend regionales admiten grupos de instancias administrados como backends. Ahora puedes especificar una plantilla para tus instancias de máquina virtual de backend y aprovechar el ajuste de escala automático basado en el uso de CPU o en otras métricas de supervisión.

Además de lo anterior, podrás aprovechar el vaciado de conexiones para el protocolo orientado a la conexión (TCP) y un tiempo de programación más rápido para implementaciones grandes.

Topología de red del codelab

En esta guía, se proporcionan instrucciones para realizar la transición de un balanceador de cargas de red existente de un backend de grupo de destino a un servicio de backend regional.

Migrar a un servicio de backend regional te permite aprovechar funciones como las verificaciones de estado no heredadas (para TCP, SSL, HTTP, HTTPS y HTTP/2), los grupos de instancias administrados, el vaciado de conexiones y la política de conmutación por error.

En esta guía, se explica cómo realizar la transición del siguiente balanceador de cargas de red basado en grupos de destino de muestra para usar un servicio de backend regional en su lugar

b2ac8a09e53e27f8.png

Antes: Balanceo de cargas de red con un grupo de destino

La implementación resultante del balanceador de cargas de red basado en servicios de backend se verá de la siguiente manera.

f628fdad64c83af3.png

Después: Balanceo de cargas de red con un servicio de backend regional

En este ejemplo, se supone que tienes un balanceador de cargas de red basado en grupos de destino tradicional con dos instancias en la zona us-central-1a y 2 instancias en la zona us-central-1c.

Los pasos de alto nivel necesarios para dicha transición son los siguientes:

  1. Agrupar las instancias de grupos de destino en grupos de instancias Los servicios de backend solo funcionan con grupos de instancias administrados o no administrados. Ten en cuenta que, si bien no hay límite para la cantidad de instancias que se pueden colocar en un solo grupo de destino, los grupos de instancias tienen un tamaño máximo. Si tu grupo de destino tiene más de esta cantidad de instancias, deberás dividir sus backends en varios grupos de instancias. Si tu implementación existente incluye un grupo de destino de copia de seguridad, crea un grupo de instancias separado para esas instancias. Este grupo de instancias se configurará como un grupo de conmutación por error.
  2. Crea un servicio de backend regional. Si tu implementación incluye un grupo de destino alternativo, deberás especificar una proporción de conmutación por error mientras creas el servicio de backend. Esto debería coincidir con la proporción de conmutación por error configurada previamente para la implementación del grupo de destino.
  3. Agrega grupos de instancias (creados anteriormente) al servicio de backend. Si tu implementación incluye un grupo de destino alternativo, marca el grupo de instancias de conmutación por error correspondiente con la marca de conmutación por error cuando lo agregues al servicio de backend.
  4. Configura una regla de reenvío que apunte al nuevo servicio de backend. Aquí tienes 2 opciones:
  • Actualiza la regla de reenvío existente para que apunte al servicio de backend (recomendado). O
  • Crea una regla de reenvío nueva que apunte al servicio de backend. Esto requiere que crees una nueva dirección IP para el frontend del balanceador de cargas. Luego, modifica tu configuración de DNS para realizar una transición sin problemas de la dirección IP del balanceador de cargas basado en grupos de destino anterior a la nueva dirección IP.

Configuración del entorno de autoaprendizaje

  1. Accede a la consola de Cloud y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.

96a9c957bc475304.png

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.png

Recuerde el ID de proyecto, un nombre único en todos los proyectos de Google Cloud (el nombre anterior ya se encuentra en uso y no lo podrá usar). Se mencionará más adelante en este codelab como PROJECT_ID.

  1. A continuación, deberás habilitar la facturación en la consola de Cloud para usar los recursos de Google Cloud recursos.

Ejecutar este codelab no debería costar mucho, tal vez nada. Asegúrate de seguir las instrucciones de la sección “Realiza una limpieza” en la que se aconseja cómo cerrar recursos para no incurrir en facturación más allá de este instructivo. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de$300.

Inicia Cloud Shell

Si bien Google Cloud y Spanner se pueden operar de manera remota desde tu laptop, en este codelab usarás Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.

En GCP Console, haga clic en el ícono de Cloud Shell en la barra de herramientas superior derecha:

bce75f34b2c53987.png

El aprovisionamiento y la conexión al entorno deberían tomar solo unos minutos. Cuando termine el proceso, debería ver algo como lo siguiente:

f6ef2b5f13479f3a.png

Esta máquina virtual está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Puedes realizar todo tu trabajo en este lab usando simplemente un navegador.

Accede a Cloud Shell y establece el ID de tu proyecto.

gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]

Perform setting your projectID:
projectid=YOUR-PROJECT-ID

echo $projectid

4. Crear red de VPC

Red de VPC

Desde Cloud Shell

gcloud compute networks create network-lb --subnet-mode custom

Crear subred

Desde Cloud Shell

gcloud compute networks subnets create network-lb-subnet \
        --network network-lb --range 10.0.0.0/24 --region us-central1

Crea reglas de firewall

Desde Cloud Shell

gcloud compute --project=$projectid firewall-rules create www-firewall-network-lb --direction=INGRESS --priority=1000 --network=network-lb --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=network-lb-tag

Crea instancias no administradas

Cree instancias de 2 instancias por zona, us-central1-a y us‐central1‐c

En Cloud Shell, crea la instancia 1

gcloud compute instances create www1 \
--subnet network-lb-subnet \
--image-family debian-9 \
--image-project debian-cloud \
--zone us-central1-a \
--tags network-lb-tag \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart
echo '<!doctype html><html><body><h1>www1</h1></body></html>' | tee /var/www/html/index.html"

En Cloud Shell, crea la instancia 2

gcloud compute instances create www2 \
--subnet network-lb-subnet \
--image-family debian-9 \
--image-project debian-cloud \
--zone us-central1-a \
--tags network-lb-tag \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart 
echo '<!doctype html><html><body><h1>www2</h1></body></html>' | tee /var/www/html/index.html"

En Cloud Shell, crea la instancia 3

gcloud compute instances create www3 \
--subnet network-lb-subnet \
--image-family debian-9 \
--image-project debian-cloud \
--zone us-central1-c \
--tags network-lb-tag \
--metadata startup-script="#! /bin/bash
sudo apt-get update 
sudo apt-get install apache2 -y 
sudo service apache2 restart 
echo '<!doctype html><html><body><h1>www3</h1></body></html>' | tee /var/www/html/index.html"

En Cloud Shell, crea la instancia 4

gcloud compute instances create www4 \
--subnet network-lb-subnet \
--image-family debian-9 \
--image-project debian-cloud \
--zone us-central1-c \
--tags network-lb-tag \
--metadata startup-script="#! /bin/bash
sudo apt-get update 
sudo apt-get install apache2 -y 
sudo service apache2 restart
echo '<!doctype html><html><body><h1>www4</h1></body></html>' | tee /var/www/html/index.html"

Crea una regla de firewall para permitir el tráfico externo a estas instancias de VM

Desde Cloud Shell

gcloud compute --project=$projectid firewall-rules create www-firewall-network-lb --direction=INGRESS --priority=1000 --network=network-lb --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=network-lb-tag

Crea una dirección IP externa estática para tu balanceador de cargas

Desde Cloud Shell

gcloud compute addresses create network-lb-ip-1 \
    --region us-central1

Agrega un recurso de verificación de estado HTTP heredado

Desde Cloud Shell

gcloud compute http-health-checks create basic-check

5. Crea una regla de reenvío y un grupo de destino

Crea un grupo de destino

gcloud compute target-pools create www-pool \
            --region us-central1 --http-health-check basic-check

Agrega tus instancias al grupo de destino, us-central1-a

gcloud compute target-pools add-instances www-pool \
--instances www1,www2 \
--instances-zone us-central1-a

Agrega tus instancias al grupo de destino, us-central1-c

gcloud compute target-pools add-instances www-pool \
--instances www3,www4 \
--instances-zone us-central1-c

Agrega una regla de reenvío

gcloud compute forwarding-rules create www-rule \
--region us-central1 \
--ports 80 \
--address network-lb-ip-1 \
--target-pool www-pool

Valida la funcionalidad del grupo de destino

Para identificar la dirección IP de frontend, selecciona Balanceadores de cargas → Frontends (www-rule)

Usa el comando curl desde la terminal de tu estación de trabajo para acceder a la dirección IP externa y observar el balanceo de cargas en las cuatro instancias de destino. Cierra la terminal una vez validada.

while true; do curl -m1 IP_ADDRESS; done

6. Transición del balanceador de cargas de red del grupo de destino al servicio de backend

Crea verificaciones de estado unificadas para tu servicio de backend

gcloud compute health-checks create tcp my-tcp-health-check --port 80 --region us-central1

Crea grupos de instancias a partir de instancias existentes del grupo de destino

gcloud compute --project=$projectid instance-groups unmanaged create www-instance-group-central1a --zone=us-central1-a

gcloud compute --project=$projectid instance-groups unmanaged add-instances www-instance-group-central1a --zone=us-central1-a --instances=www1,www2

Crea grupos de instancias a partir de instancias existentes del grupo de destino

gcloud compute --project=$projectid instance-groups unmanaged create www-instance-group-central1c --zone=us-central1-c

gcloud compute --project=$projectid instance-groups unmanaged add-instances www-instance-group-central1c --zone=us-central1-c --instances=www3,www4

Crear un servicio de backend y asociarlo con las verificaciones de estado recién creadas

gcloud compute backend-services create my-backend-service --region us-central1 --health-checks my-tcp-health-check --health-checks-region us-central1 --load-balancing-scheme external

Configura tu servicio de backend y agrega los grupos de instancias

gcloud compute backend-services add-backend my-backend-service --instance-group www-instance-group-central1a --instance-group-zone us-central1-a --region us-central1

gcloud compute backend-services add-backend my-backend-service --instance-group www-instance-group-central1c --instance-group-zone us-central1-c --region us-central1

Actualiza la regla de reenvío existente para admitir servicios de backend

Anota el nombre de la regla de reenvío “www-rule” y la dirección IP asociada realizando lo siguiente:

Selecciona Balanceador de cargas → Frontends

Además, observa los cuatro grupos de destino

Selecciona Balanceador de cargas → Selecciona "www-pool"

Actualiza la regla de reenvío existente para enrutar el tráfico a los servicios de backend

gcloud compute forwarding-rules set-target www-rule --region=us-central1 --backend-service my-backend-service --region us-central1

Verifica el balanceador de cargas “www-pool” Ya no se configura con el frontend "www-rule" (consulte la captura de pantalla a continuación)

Selecciona Balanceador de cargas → www-pool

9a393b3ca4e0942c.png

Validar la regla de reenvío de frontend ahora está asociada con el balanceador de cargas “my-backend-service”

Selecciona Balanceador de cargas → Frontends

Tome nota del nombre de la regla “www-rule” Se conserva la dirección IP y el balanceador de cargas “my-backend-service” ahora está en uso

Usa el comando curl desde la terminal de tu estación de trabajo para acceder a la dirección IP externa y observar el balanceo de cargas en el nuevo servicio de backend asociado. Cierra la terminal una vez validada.

while true; do curl -m1 IP_ADDRESS; done

7. Pasos de limpieza

gcloud compute forwarding-rules delete www-rule --region=us-central1 --quiet
 
gcloud compute backend-services delete my-backend-service --region us-central1 --quiet
 
gcloud compute target-pools delete www-pool --region us-central1 --quiet
 
gcloud compute addresses delete network-lb-ip-1 --region us-central1 --quiet

gcloud compute firewall-rules delete www-firewall-network-lb --quiet
 
gcloud compute instances delete www4 --zone us-central1-c --quiet
 
gcloud compute instances delete www3 --zone us-central1-c --quiet
 
gcloud compute instances delete www2 --zone us-central1-a --quiet

gcloud compute instances delete www1 --zone us-central1-a --quiet
 
gcloud compute networks subnets delete network-lb-subnet --region us-central1 --quiet

gcloud compute networks delete network-lb --quiet

gcloud compute instance-groups unmanaged delete www-instance-group-central1a --zone us-central1-a --quiet

gcloud compute instance-groups unmanaged delete www-instance-group-central1c --zone us-central1-c --quiet

8. ¡Felicitaciones!

Felicitaciones por completar el codelab.

Temas abordados

  • Comprende los beneficios de los servicios de backend regionales
  • Crea un balanceador de cargas de red con grupos de destino
  • Realiza la validación del grupo de destino
  • Crea un servicio de backend regional con grupos de instancias no administrados
  • Realiza la migración del grupo de destino al servicio de backend
  • Realiza la validación de los servicios de backend