Conmutación por error multirregional mediante las políticas de enrutamiento de Cloud DNS y las verificaciones de estado para el balanceador de cargas TCP/UDP interno

1. Introducción

Última actualización: 22/09/2022

¿Qué es una política de enrutamiento de DNS?

Las políticas de enrutamiento de Cloud DNS permiten que los usuarios configuren el direccionamiento del tráfico basado en DNS según criterios específicos, como el peso, la ubicación geográfica o las verificaciones de estado.

Cloud DNS admite las siguientes políticas de enrutamiento:

• Política de enrutamiento de round robin ponderado
• Política de enrutamiento de ubicación geográfica
• Política de enrutamiento con geovallado
• Política de enrutamiento de conmutación por error

En este lab, configurarás y probarás la política de enrutamiento de conmutación por error.

Nota: Al momento de escribir este lab, tanto la política de conmutación por error como la compatibilidad con las verificaciones de estado se encuentran en versión preliminar pública.

Política de enrutamiento de conmutación por error

Cloud DNS admite verificaciones de estado para los balanceadores de cargas TCP/UDP internos que tienen habilitado el acceso global. Con una política de enrutamiento de conmutación por error, puedes configurar IPs principales y de copia de seguridad para un registro de recursos. En condiciones normales, Cloud DNS responderá a las consultas con las direcciones IP aprovisionadas en el conjunto principal. Cuando todas las direcciones IP del conjunto principal fallan (el estado de salud cambia a en mal estado), Cloud DNS comienza a entregar las direcciones IP del conjunto de copia de seguridad.

Nota: Para que Cloud DNS funcione según lo esperado con las verificaciones de estado, se debe habilitar el acceso global en el balanceador de cargas. Los usuarios podrán crear políticas de enrutamiento para los ILB que tengan inhabilitado el acceso global, pero la conmutación por error de Cloud DNS no funcionará.

Verificaciones de estado

La política de enrutamiento de DNS dependerá de las verificaciones de estado unificadas(UHC) nativas del balanceador de cargas interno. Un balanceador de cargas interno se considera en buen estado si el 20% (o más) de los backends están en buen estado. Las verificaciones de estado para los balanceadores de cargas de TCP/UDP internos y HTTP(S) internos proporcionan información diferente. En el caso de un balanceador de cargas HTTP(S) interno, UHC proporciona el estado de salud de todos los proxies de Envoy, pero, en el caso de un balanceador de cargas TCP/UDP interno, Cloud DNS recibe indicadores de salud directos de las instancias de backend individuales. Puedes encontrar los detalles de las verificaciones de estado aquí .

Qué compilarás

En este codelab, compilarás un sitio web que se ejecuta en 2 regiones y le asociarás una política de enrutamiento de DNS de conmutación por error. La configuración tendrá lo siguiente:

Recursos activos:

• Balanceador de cargas interno L4 en REGION_1
• Una VM que ejecuta el servidor web Apache en REGION_1

Recursos de copia de seguridad:

• Balanceador de cargas interno L4 en REGION_2
• Una VM que ejecuta el servidor web Apache en REGION_2

La configuración se muestra a continuación:

Nota: Para simplificar este codelab, tendremos un solo balanceador de cargas en cada una de las regiones configuradas como el conjunto activo y de copia de seguridad de la política de enrutamiento de conmutación por error.

Qué aprenderás

• Cómo crear una política de enrutamiento de conmutación por error
• Cómo activar la conmutación por error de DNS
• Cómo distribuir el tráfico al conjunto de copias de seguridad

Requisitos

• Conocimientos básicos de DNS
• Conocimiento básico de Google Compute Engine
• Conocimientos básicos del balanceador de cargas interno L4

2. Configuración y requisitos

1. Accede a Google Cloud Console 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.

• El Nombre del proyecto es el nombre visible de los participantes de este proyecto. Es una cadena de caracteres que no se utiliza en las APIs de Google. Puedes actualizarla en cualquier momento.
• El ID del proyecto debe ser único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar después de configurarlo). La consola de Cloud genera automáticamente una cadena única. Por lo general, no importa cuál sea. En la mayoría de los codelabs, deberás hacer referencia al ID del proyecto (suele identificarse como PROJECT_ID). Si no te gusta el ID que se generó, podrías generar otro aleatorio. También puedes probar uno propio y ver si está disponible. No se puede cambiar después de este paso y se usará el mismo durante todo el proyecto.
• Recuerda que hay un tercer valor, un número de proyecto, que usan algunas APIs. Obtén más información sobre estos tres valores en la documentación.

Precaución: El ID de un proyecto debe ser único a nivel global y ninguna otra persona puede usarlo después de seleccionarlo. Eres el único usuario de ese ID. Incluso si se borra un proyecto, no se puede volver a usar el ID.

Nota: Si usas una cuenta de Gmail, puedes configurar la ubicación predeterminada como Sin organización. Si usas una cuenta de Google Workspace, elige una ubicación adecuada para tu organización.

2. A continuación, deberás habilitar la facturación en la consola de Cloud para usar las APIs o los recursos de Cloud. Ejecutar este codelab no debería costar mucho, tal vez nada. Para cerrar recursos y evitar que se generen cobros más allá de este instructivo, puedes borrar los recursos que creaste o borrar todo el proyecto. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de USD 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 Google Cloud Console, haz clic en el ícono de Cloud Shell en la barra de herramientas en la parte superior derecha:

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:

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. Todo tu trabajo en este codelab se puede hacer en un navegador. No es necesario que instales nada.

3. Versión del SDK de Google Cloud

En el momento de la redacción, 401.0.0 es la versión más reciente del SDK de Google Cloud. Todos los comandos de este lab se probaron con la versión más reciente del SDK de Google Cloud. Antes de continuar, asegúrate de que Cloud Shell use la versión más reciente del SDK.

Cómo verificar la versión del SDK

Usa el comando gcloud version para verificar la versión del SDK. Ejecuta los siguientes comandos en Cloud Shell:

Comando

gcloud version | grep "Google Cloud SDK"

Ejemplo de resultado

Google Cloud SDK 401.0.0

Próximos pasos

Precaución: Selecciona la opción 1 o 2 según el resultado del comando gcloud version.

1. Si la versión del SDK es 401.0.0 o posterior, pasa a la siguiente sección.
2. Si la versión del SDK es inferior a 401.0.0, ejecuta el siguiente comando para actualizar el SDK.

Comando opcional

sudo apt-get update && sudo apt-get install google-cloud-sdk

4. Antes de comenzar

Antes de comenzar a implementar la arquitectura que explicamos anteriormente, asegúrate de que Cloud Shell esté configurado correctamente y de que todas las APIs necesarias estén habilitadas.

Configura el ID del proyecto

En Cloud Shell, asegúrate de que tu ID del proyecto esté configurado. Si el mensaje de Cloud Shell se parece al siguiente resultado y no planeas cambiar el ID del proyecto, puedes pasar al siguiente paso (Configura variables de entorno).

USER@cloudshell:~ (PROJECT_ID)$

Si aún quieres cambiar el ID del proyecto, usa el siguiente comando. El mensaje de Cloud Shell cambiará de (PROJECT_ID) a (YOUR-PROJECT-ID).

Comando opcional

gcloud config set project [YOUR-PROJECT-ID]

Ejemplo de resultado

Updated property [core/project].
USER@cloudshell:~ (YOUR-PROJECT-ID)$

Configura las variables de entorno

Configura las variables de entorno

Usaremos el comando export para establecer las variables de entorno. Ejecuta los siguientes comandos en Cloud Shell:

Comandos

export REGION_1=us-west1

export REGION_1_ZONE=us-west1-a

export REGION_2=us-east4

export REGION_2_ZONE=us-east4-a

Nota: En este lab, usamos las regiones us-west1 y us-east4. La capacidad de procesamiento puede estar limitada en una zona. Si ves algún error de capacidad mientras creas las VMs, usa otra región o zona. Aquí encontrarás una lista de las regiones y zonas disponibles.

Verificar

Ahora que se configuraron las variables de entorno, verifiquemos con el comando echo. El resultado de cada comando debe ser el valor que configuramos anteriormente con el comando export. Ejecuta los siguientes comandos en Cloud Shell:

Comandos

echo $REGION_1

echo $REGION_1_ZONE

echo $REGION_2

echo $REGION_2_ZONE

Habilita todos los servicios necesarios

Usa el comando gcloud services enable para habilitar las APIs de Compute y DNS. Ejecuta los siguientes comandos en Cloud Shell:

Habilita la API de Compute

Comando

gcloud services enable compute.googleapis.com

Habilita la API de DNS

Comando

gcloud services enable dns.googleapis.com

Verificar

Ahora que los servicios están habilitados, verifiquemos con el comando gcloud services list para enumerar todas las APIs habilitadas.

Comando

gcloud services list | grep -E 'compute|dns'

Ejemplo de resultado

NAME: compute.googleapis.com
NAME: dns.googleapis.com

5. Crea una red de VPC, subredes y reglas de firewall

En esta sección, crearemos la red de VPC, dos subredes (una en cada región) y las reglas de firewall necesarias.

Crea una red de VPC

Usa el comando gcloud compute networks create para crear la red de VPC. Estableceremos el modo de subred como personalizado porque crearemos nuestras propias subredes en el siguiente paso. Ejecuta los siguientes comandos en Cloud Shell.

Comando

gcloud compute networks create my-vpc --subnet-mode custom

Crear subredes

Usa el comando gcloud compute networks subnets create para crear dos subredes, una en REGION_1 y otra en REGION_2. Ejecuta los siguientes comandos en Cloud Shell:

Subred de REGION_1

Comando

gcloud compute networks subnets create ${REGION_1}-subnet \
--network my-vpc \
--range 10.1.0.0/24 \
--region $REGION_1

Subred de REGION_2

Comando

gcloud compute networks subnets create ${REGION_2}-subnet \
--network my-vpc \
--range 10.2.0.0/24 \
--region $REGION_2

Crea reglas de firewall

Debes permitir el tráfico en el puerto 80 desde las subredes de la VPC y desde los rangos de IP de verificación de estado del balanceador de cargas.

Además, también debes crear una regla de firewall para permitir el tráfico SSH en las VMs de cliente.

Usa el comando gcloud compute firewall-rules create para crear las reglas de firewall. Ejecuta los siguientes comandos en Cloud Shell:

Permitir tráfico en el puerto 80

Comando

gcloud compute firewall-rules create allow-http-lb-hc \
--allow tcp:80 --network my-vpc \
--source-ranges 10.1.0.0/24,10.2.0.0/24,35.191.0.0/16,130.211.0.0/22 \
--target-tags=allow-http

Permite el tráfico SSH en la VM del cliente

Comando

gcloud compute firewall-rules create allow-ssh \
--allow tcp:22 --network my-vpc \
--source-ranges 0.0.0.0/0 \
--target-tags=allow-ssh

6. Crea Cloud NAT

Necesitas puertas de enlace de Cloud NAT en ambas regiones para que las VMs privadas puedan descargar e instalar paquetes desde Internet.

• Nuestras VMs de servidor web deberán descargar e instalar el servidor web Apache.
• La VM cliente deberá descargar e instalar el paquete dnsutils que usaremos para nuestras pruebas.

Cada puerta de enlace de Cloud NAT está asociada con una sola red de VPC, una región y un Cloud Router. Por lo tanto, antes de crear las puertas de enlace de NAT, debemos crear Cloud Routers en cada región.

Crea Cloud Routers

Usa el comando gcloud compute routers create para crear Cloud Routers en las regiones us-west1 y us-east4. Ejecuta los siguientes comandos en Cloud Shell.

Cloud Router de region_1

Comandos

gcloud compute routers create "${REGION_1}-cloudrouter" \
--region $REGION_1 --network=my-vpc --asn=65501

Cloud Router de region_2

Comandos

gcloud compute routers create "${REGION_2}-cloudrouter" \
--region $REGION_2 --network=my-vpc --asn=65501

Crea las puertas de enlace NAT

Usa el comando gcloud compute routers nat create para crear las puertas de enlace de NAT en las regiones us-west1 y us-east4. Ejecuta los siguientes comandos en Cloud Shell.

Puerta de enlace NAT de region_1

Comandos

gcloud compute routers nats create "${REGION_1}-nat-gw" \
--router="${REGION_1}-cloudrouter" \
--router-region=$REGION_1 \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

Puerta de enlace NAT de Region_2

Comandos

gcloud compute routers nats create "${REGION_2}-nat-gw" \
--router="${REGION_2}-cloudrouter" \
--router-region=$REGION_2 \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

7. Crea VMs de Compute Engine

En esta sección, crearás los servidores web, los grupos de instancias no administrados para los servidores web y la VM del cliente.

Nota: En este lab, usamos las regiones us-west1 y us-east4. La capacidad de procesamiento puede estar limitada en una zona. Si ves algún error de capacidad mientras creas las VMs, usa otra región o zona. Aquí encontrarás una lista de las regiones y zonas disponibles.

Crea VMs de servidor web

Usa el comando gcloud compute instances create para crear los servidores web. Debemos crear dos servidores web, uno en REGION_1 y otro en REGION_2. Usamos secuencias de comandos de inicio para instalar y configurar Apache en los servidores web.

Servidor web de REGION_1

Ejecuta el siguiente comando en Cloud Shell.

Comando

gcloud compute instances create "${REGION_1}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-http \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Servidor web de REGION_2

Ejecuta el siguiente comando en Cloud Shell.

Comando

gcloud compute instances create "${REGION_2}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_2_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_2}-subnet,no-address \
--tags=allow-http \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Crea grupos de instancias no administrados

En esta sección, crearemos dos grupos de instancias no administrados. Usaremos estos grupos de instancias en la siguiente sección para configurar los servicios de backend del ILB. Una vez que se creen los grupos de instancias, agregaremos las VMs del servidor web a estos grupos.

Crea los grupos de instancias no administrados

Usa el comando gcloud compute instance-groups unmanaged create para crear dos grupos de instancias no administrados, uno para el servidor web us-west1 y otro para el servidor web us-east4.

Grupo de instancias de region_1

Comandos

gcloud compute instance-groups unmanaged create \
"${REGION_1}-instance-group" --zone=$REGION_1_ZONE

Grupo de instancias de region_2

Comandos

gcloud compute instance-groups unmanaged create \
"${REGION_2}-instance-group" --zone=$REGION_2_ZONE

Agrega VMs a los grupos de instancias

Usa el comando gcloud compute instance-groups unmanaged add-instances para agregar las instancias a los grupos de instancias que acabamos de crear. Agrega el servidor web de REGION_1 al grupo de instancias de REGION_1 y el servidor web de REGION_2 al grupo de instancias de REGION_2.

Grupo de instancias de region_1

Comandos

gcloud compute instance-groups unmanaged add-instances \
"${REGION_1}-instance-group" --instances $REGION_1-instance \
--zone=$REGION_1_ZONE

Grupo de instancias de region_2

Comandos

gcloud compute instance-groups unmanaged add-instances \
"${REGION_2}-instance-group" --instances $REGION_2-instance \
--zone=$REGION_2_ZONE

Crea una VM cliente

Usaremos esta VM para ejecutar pruebas y verificar nuestra configuración de DNS. Usamos una secuencia de comandos de inicio para instalar el paquete dnsutils. Ejecuta los siguientes comandos en Cloud Shell.

Comando

gcloud compute instances create client-instance --image-family=debian-11 \
--image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-ssh \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'

8. Crea balanceadores de cargas internos L4

Para crear el ILB de L4, debemos crear una verificación de estado, un servicio de backend y una regla de reenvío.

Crear verificación de estado

Usa el comando gcloud compute health-checks create para crear la verificación de estado. Estamos creando una verificación de estado HTTP básica y el puerto de destino es el puerto 80. Ejecuta los siguientes comandos en Cloud Shell:

Comando

gcloud compute health-checks create http http-hc --port 80

Configura servicios de backend

Usa el comando gcloud compute backend-services create para crear el servicio de backend. Una vez que se creen los servicios de backend, agregaremos los grupos de instancias no administrados a los servicios de backend con el comando gcloud compute backend-services add-backend. Ejecuta los siguientes comandos en Cloud Shell.

Create Backend Service

Comandos

gcloud compute backend-services create $REGION_1-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_1

gcloud compute backend-services create $REGION_2-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_2

Agregar backend

Comando

gcloud compute backend-services add-backend $REGION_1-backend-service \
--instance-group=$REGION_1-instance-group \
--region=$REGION_1 \
--instance-group-zone=$REGION_1_ZONE

gcloud compute backend-services add-backend $REGION_2-backend-service \
--instance-group=$REGION_2-instance-group \
--region=$REGION_2 \
--instance-group-zone=$REGION_2_ZONE

Crea reglas de reenvío

Usa el comando gcloud compute forwarding-rules create para crear las reglas de reenvío en ambas regiones. Ejecuta los siguientes comandos en Cloud Shell:

Regla de reenvío de REGION_1

Comandos

gcloud compute forwarding-rules create $REGION_1-ilb \
    --region=$REGION_1 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_1-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_1-backend-service \
    --backend-service-region=$REGION_1 \
    --allow-global-access

Regla de reenvío de REGION_2

gcloud compute forwarding-rules create $REGION_2-ilb \
    --region=$REGION_2 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_2-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_2-backend-service \
    --backend-service-region=$REGION_2 \
    --allow-global-access

9. Configura un DNS

En esta sección, crearemos la zona privada y un conjunto de registros DNS con la política de enrutamiento de conmutación por error.

Crea una zona de DNS privada

Usa el comando gcloud dns managed-zones create para crear una zona privada para example.com. Usaremos esta zona para crear un conjunto de registros de recursos con una política de enrutamiento de conmutación por error. Ejecuta el siguiente comando en Cloud Shell.

Comandos

gcloud dns managed-zones create example-com \
--dns-name example.com. --description="My private zone" \
--visibility=private --networks my-vpc 

Crea un registro de DNS con una política de enrutamiento por conmutación por error

Usa el comando gcloud dns record-sets create para crear un registro DNS con la política de enrutamiento de conmutación por error. El destino principal es el balanceador de cargas en REGION_1. Cloud DNS solo admite destinos de copias de seguridad basados en la ubicación geográfica. El conjunto de copias de seguridad es una política de ubicación geográfica con el balanceador de cargas REGION_2 como destino para REGION_1 y REGION_2. Ejecuta los siguientes comandos en Cloud Shell:

Comando

gcloud dns record-sets create failover.example.com --ttl 5 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com \
--enable-health-checking

Ejemplo de resultado

NAME: failover.example.com.
TYPE: A
TTL: 5
DATA: Primary: "10.1.0.4, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-west1, regionalL4ilb" Backup: us-west1: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb";us-east4: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb"

10. Prueba la resolución de DNS

Antes de probar nuestra configuración de conmutación por error, anotemos las direcciones IP de ambos balanceadores de cargas internos. Ejecuta los siguientes comandos en Cloud Shell.

Comando

gcloud compute forwarding-rules list --filter="name:($REGION_1-ilb $REGION_2-ilb)"

Ejemplo de resultado

En este ejemplo, us-west1-ilb tiene la dirección IP 10.1.0.4 y us-east4-ilb tiene la dirección IP 10.2.0.3.

NAME: us-west1-ilb
REGION: us-west1
IP_ADDRESS: 10.1.0.4
IP_PROTOCOL: TCP
TARGET: us-west1/backendServices/us-west1-backend-service

NAME: us-east4-ilb
REGION: us-east4
IP_ADDRESS: 10.2.0.3
IP_PROTOCOL: TCP
TARGET: us-east4/backendServices/us-east4-backend-service

Ahora accederemos a la instancia del cliente y probaremos la resolución de DNS. En la consola web, navega a "Compute Engine | Instancias de VM".

Haz clic en el botón SSH para acceder a client-instance desde la consola.

Ahora que estamos en la VM del cliente, usa el comando dig para resolver el nombre de dominio failover.example.com.

El bucle está configurado para ejecutar el comando diez veces con un temporizador de apagado de 6 segundos.

Comando

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

Debido a que el TTL del registro DNS está establecido en 5 segundos, se agregó un temporizador de apagado de 6 segundos. El temporizador de apagado garantizará que recibas una respuesta DNS no almacenada en caché para cada solicitud de DNS. Este comando tardará aproximadamente un minuto en ejecutarse.

En el resultado, verás la dirección IP del balanceador de cargas en el conjunto principal del registro de recursos. En nuestra configuración, esta será la IP del balanceador de cargas en la región us-west1.

11. Prueba la conmutación por error

Simularemos una conmutación por error quitando la etiqueta de red de la VM de REGION_1. Esto bloqueará el acceso al puerto 80 y, como resultado, las verificaciones de estado comenzarán a fallar.

Cómo quitar la etiqueta de red

Usa el comando gcloud compute instances remove-tags para quitar la etiqueta de red de la VM. Ejecuta el siguiente comando en Cloud Shell.

Comando

gcloud compute instances remove-tags $REGION_1-instance \
--zone=$REGION_1_ZONE --tags=allow-http

La verificación de estado fallará en 10 segundos. Vuelve a ejecutar la prueba de resolución de DNS.

Resolución de DNS

Desde la instancia del cliente, ejecuta el siguiente comando:

Comando

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

En el resultado, verás la dirección IP del balanceador de cargas en el conjunto de copias de seguridad del registro de recursos. En nuestra configuración, esta será la IP del balanceador de cargas en la región us-east4.

12. Prueba la distribución gradual del tráfico

De forma predeterminada, la política de conmutación por error devuelve la IP del extremo principal para todas las solicitudes de DNS y solo devuelve las IPs de copia de seguridad si el extremo principal no supera las verificaciones de estado. Cloud DNS permite que los usuarios configuren el parámetro Trickle Ratio, que permite que Cloud DNS envíe una parte del tráfico a los destinos de copia de seguridad, incluso cuando los destinos principales están en buen estado. La proporción debe ser un valor entre 0 y 1. El valor predeterminado es 0

Para probar esto, volvamos a agregar la etiqueta de red al servidor web REGION_1.

Agregar etiqueta de red

Vuelve a agregar la etiqueta a la VM del servidor web para permitir el tráfico HTTP a la VM de la región principal. Ejecuta el siguiente comando en Cloud Shell.

Comando

gcloud compute instances add-tags $REGION_1-instance \
--zone $REGION_1_ZONE --tags allow-http

Las verificaciones de estado se aprobarán en 10 segundos.

Verifica que la resolución de DNS apunte al balanceador de cargas principal. En nuestra configuración, esta será la dirección IP del balanceador de cargas en la región us-west1.

Desde la instancia del cliente, ejecuta el siguiente comando:

Comando

dig +short failover.example.com

Actualiza el registro DNS

Ahora, modificaremos el registro DNS de failover.example.com para que se filtre el 30% del tráfico al conjunto de copias de seguridad, incluso cuando el principal esté en buen estado. Ejecuta el siguiente comando en Cloud Shell.

Comando

gcloud dns record-sets update failover.example.com --ttl 30 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com --enable-health-checking \
--backup-data-trickle-ratio=0.3

Resolución de DNS

Ejecuta el siguiente comando desde la VM del cliente. Observarás que el registro DNS failover.example.com se resolverá en la IP del balanceador de cargas principal aproximadamente el 70% del tiempo y en la IP del balanceador de cargas de copia de seguridad aproximadamente el 30% del tiempo.

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

13. Pasos para la limpieza

Para limpiar los recursos que se usaron en este lab, ejecuta los siguientes comandos desde Cloud Shell:

gcloud dns record-sets delete failover.example.com --type=A \
--zone=example-com --quiet

gcloud dns managed-zones delete example-com --quiet

gcloud compute forwarding-rules delete $REGION_1-ilb \
--region=$REGION_1 --quiet

gcloud compute forwarding-rules delete $REGION_2-ilb \
--region=$REGION_2 --quiet

gcloud compute backend-services delete $REGION_1-backend-service \
--region=$REGION_1 --quiet

gcloud compute backend-services delete $REGION_2-backend-service \
--region=$REGION_2 --quiet

gcloud compute health-checks delete http-hc --quiet

gcloud compute instances delete client-instance --zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_1-instance-group \
--zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_2-instance-group \
--zone=$REGION_2_ZONE --quiet

gcloud compute instances delete $REGION_1-instance \
--zone=$REGION_1_ZONE --quiet

gcloud compute instances delete $REGION_2-instance \
--zone=$REGION_2_ZONE --quiet

gcloud compute routers nats delete $REGION_1-nat-gw \
--router=$REGION_1-cloudrouter --region=$REGION_1 --quiet

gcloud compute routers nats delete $REGION_2-nat-gw \
--router=$REGION_2-cloudrouter --region=$REGION_2 --quiet

gcloud compute routers delete $REGION_1-cloudrouter \
--region=$REGION_1 --quiet

gcloud compute routers delete $REGION_2-cloudrouter \
--region=$REGION_2 --quiet

gcloud compute firewall-rules delete allow-ssh allow-http-lb-hc --quiet

gcloud compute networks subnets delete $REGION_1-subnet \
--region=$REGION_1 --quiet

gcloud compute networks subnets delete $REGION_2-subnet \
--region=$REGION_2 --quiet

gcloud compute networks delete my-vpc --quiet

14. Felicitaciones

Felicitaciones. Implementaste y probaste correctamente la política de enrutamiento de conmutación por error de Cloud DNS.

Temas abordados

• Cómo configurar la política de enrutamiento de conmutación por error de Cloud DNS
• Prueba la conmutación por error de DNS
• Cómo distribuir el tráfico al conjunto de copias de seguridad

¿Qué sigue?

• Intenta configurar varias IPs para los conjuntos activos y de copia de seguridad
• Intenta agregar varias VMs de backend a tus grupos de instancias no administrados
• Intenta configurar varios balanceadores de cargas en diferentes regiones para la política de ubicación geográfica en el conjunto de copias de seguridad.

Más información

https://cloud.google.com/dns/docs/zones/manage-routing-policies