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 DNS?

Las políticas de enrutamiento de Cloud DNS permiten que los usuarios configuren el direccionamiento del tráfico basado en DNS en función de 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 redactar 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 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 las IP principales y de respaldo para un registro de recursos. En funcionamiento normal, Cloud DNS responderá las consultas con las direcciones IP aprovisionadas en el conjunto principal. Cuando todas las direcciones IP del conjunto principal fallan (el estado 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 como se espera con las verificaciones de estado, el acceso global debe estar habilitado en el balanceador de cargas. Los usuarios podrán crear políticas de enrutamiento para los ILB que tengan el acceso global inhabilitado, 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) del balanceador de cargas interno nativo. 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 de los balanceadores de cargas TCP/UDP y HTTP(S) internos proporcionan información diferente. Para un balanceador de cargas HTTP(S) interno, el UHC proporciona el estado de todos los proxies de Envoy, pero para un balanceador de cargas TCP/UDP interno, Cloud DNS obtiene señales de estado directas de las instancias de backend individuales. Puedes encontrar los detalles de las verificaciones de estado aquí .

Qué compilarás

En este codelab, crearás un sitio web que se ejecute en 2 regiones y le asociarás una política de enrutamiento de DNS de conmutación por error. La configuración tendrá los siguientes elementos:

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 es como 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
• Activar la conmutación por error de DNS
• Cómo filtrar tráfico al conjunto de copia de seguridad

Requisitos

• Conocimientos básicos de DNS
• Conocimiento básico de Google Compute Engine
• Conocimiento básico 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 te importa qué es. En la mayoría de los codelabs, deberás hacer referencia al ID del proyecto (por lo general, se identifica como PROJECT_ID). Si no te gusta el ID generado, puedes generar otro aleatorio. También puedes probar el tuyo propio y ver si está disponible. No se puede cambiar después de este paso y se mantendrá mientras dure el proyecto.
• Para tu información, 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, el ID no se puede volver a usar.

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 te facture 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

Al 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 esté usando 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 salida

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 anterior a 401.0.0, ejecuta el comando que se muestra a continuación 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, asegurémonos de que Cloud Shell esté configurado correctamente y de que estén habilitadas todas las APIs necesarias.

Configura el ID del proyecto

En Cloud Shell, asegúrate de que el ID del proyecto esté configurado. Si el símbolo del sistema de Cloud Shell se parece al resultado que se muestra a continuación y no tienes pensado cambiar el ID del proyecto, puedes continuar con el siguiente paso (Establecer variables de entorno).

USER@cloudshell:~ (PROJECT_ID)$

Si aún quieres cambiar el ID del proyecto, usa el comando que se indica a continuación; el símbolo del sistema de Cloud Shell cambiará de (PROJECT_ID) a (YOUR-PROJECT-ID)

Comando opcional

gcloud config set project [YOUR-PROJECT-ID]

Ejemplo de salida

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

Configura las variables de entorno

Configura las variables de entorno

Usaremos el comando export para configurar 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, usaremos 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 una región o zona diferente. Aquí encontrarás una lista de las regiones y zonas disponibles.

Verificar

Ahora que las variables de entorno están configuradas, realicemos la verificación con el comando echo. El resultado de cada comando debe ser el valor que configuramos antes 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

Habilitar la API de DNS

Comando

gcloud services enable dns.googleapis.com

Verificar

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

Comando

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

Ejemplo de salida

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

5. Crear redes 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.

Crear 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

Crea 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 REGION_1

Comando

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

Subred 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 VPC y desde los rangos de IP de verificación de estado del balanceador de cargas.

Además, debes crear una regla de firewall para permitir el tráfico SSH en las VMs del 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

Cómo permitir 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 del servidor web deberán descargar e instalar el servidor web Apache.
• La VM del 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, región y Cloud Router. Por lo tanto, antes de crear las puertas de enlace 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 región 1

Comandos

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

Cloud Router de región 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 NAT en las regiones us-west1 y us-east4. Ejecuta los siguientes comandos en Cloud Shell.

Puerta de enlace NAT de la región 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 la región 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 y los grupos de instancias no administrados para los servidores web y la VM del cliente.

Nota: En este lab, usaremos 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 una región o zona diferente. Aquí encontrarás una lista de las regiones y zonas disponibles.

Crea VMs del 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. Estamos usando 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. En la siguiente sección, usaremos estos grupos de instancias para configurar los servicios de backend de ILB. Una vez creados los grupos de instancias, agregaremos las VMs del servidor web a estos grupos de instancias.

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 VM 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 REGION_1 al grupo de instancias REGION_1 y el servidor web REGION_2 al grupo de instancias 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 de cliente

Usaremos esta VM para ejecutar pruebas y verificar la configuración de DNS. Estamos usando 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. Crear balanceadores de cargas internos L4

Para crear el ILB 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.

Crear servicio de backend

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 del 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 DNS con una política de enrutamiento de 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 la REGION_1. Cloud DNS solo admite destinos de copia 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 objetivo 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 salida

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 la conmutación por error, tomemos nota de las direcciones IP para 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 salida

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 la instancia del cliente 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á alrededor de 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, 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 REGION_1. Esto bloqueará el acceso al puerto 80 y, como resultado, las verificaciones de estado comenzarán a fallar.

Quita 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 copia de seguridad del registro de recursos. En nuestra configuración, será la IP del balanceador de cargas en la región us-east4.

12. Prueba el goteo de tráfico

De forma predeterminada, la política de conmutación por error devuelve la IP del extremo principal para todas las solicitudes del DNS y solo devuelve las IP de respaldo si la principal falla en las verificaciones de estado. Cloud DNS permite a los usuarios configurar la proporción de goteo, lo 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 probarlo, volvamos a agregar la etiqueta de red al servidor web de REGION_1.

Agregar etiqueta de red

Volver 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 filtrar 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. Notarás que el registro DNS failover.example.com se resolverá en la approx de IP del balanceador de cargas principal. el 70% del tiempo y la IP del balanceador de cargas de copia de seguridad aproximado. el 30% del tiempo.

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

13. Pasos de limpieza

Para limpiar los recursos usados en este lab, ejecuta los siguientes comandos de 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 filtrar tráfico al conjunto de copia de seguridad

¿Qué sigue?

• Intenta configurar varias IP para 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