Implementa un servidor web recuperable en caliente mediante Cloud DNS con Compute Engine y Cloud Storage

Last reviewed 2021-06-28 UTC

---

Este documento está dirigido a arquitectos y personas que trabajan en equipos de operaciones y administrativos. En el documento, se describe un patrón de ejemplo que puedes usar para tus propias implementaciones en Google Cloud.

En esta arquitectura, Cloud DNS dirige el tráfico a las instancias de Compute Engine en los grupos de instancias administrados que entregan el contenido. En una interrupción, actualizas la zona de Cloud DNS y realizas una conmutación por error a un sitio estático en Cloud Storage.

Para implementar esta solución, necesitas un nombre de dominio registrado que controles y que desees usar con este documento.

En las implementaciones de producción, es probable que el sitio web incluya muchos más archivos y códigos de la aplicación adicionales en tus máquinas virtuales (VM) de grupos de instancias administrados que los que se muestran en este documento. Luego, Cloud Storage aloja una versión estática más limitada que proporciona una funcionalidad mínima. En una situación de conmutación por error en caliente, los usuarios ven este sitio web limitado hasta que se recuperen los grupos de instancias administrados y puedan entregar tráfico para la experiencia completa del sitio web.

Arquitectura

En esta arquitectura, implementarás recursos para crear un entorno como se muestra en la siguiente imagen:

Cuando necesites realizar una conmutación por error, actualiza la configuración de Cloud DNS para dirigir el tráfico a Cloud Storage, como se muestra en la siguiente imagen:

Este patrón de conmutación por error en caliente te ayuda a balancear el costo de ejecutar otro grupo de instancias administrado en una región diferente que solo usas cuando la región principal falla. El costo de un sitio estático con Cloud Storage es menor que ejecutar otro grupo de instancias administrado, pero hay una breve demora mientras actualizas Cloud DNS entre las opciones de hosting. La experiencia limitada del sitio web en Cloud Storage es mejor que la falta de un sitio web por completo y una experiencia del cliente deficiente.

Si quieres obtener un enfoque alternativo que use el balanceo de cargas de aplicaciones externo en lugar de Cloud DNS para controlar la conmutación por error, consulta Implementa un servidor web recuperable en caliente con Compute Engine y Cloud Storage. Este patrón es útil si no tienes Cloud DNS, o si no deseas usarlo.

Si quieres ejecutar aplicaciones confiables en Google Cloud, te recomendamos que diseñes la infraestructura de tu aplicación para controlar las interrupciones. Según la aplicación y las necesidades de tu empresa, es posible que necesites una conmutación por error en frío, una conmutación por error templada o un patrón de conmutación por error en caliente. Si deseas obtener más información a fin de determinar el mejor enfoque para tus propias aplicaciones, consulta la guía de planificación de recuperación ante desastres.

En este documento, se usa un Apache Web Server, pero el mismo enfoque de implementación de infraestructura se aplica a otros entornos de aplicaciones que debes crear.

Objetivos

• Crear grupos de instancias administrados regionales con una imagen de VM personalizada.
• Crea un bucket de Cloud Storage
• Crear y configurar una zona de Cloud DNS.
• Probar la conmutación por error en caliente del servidor web con registros actualizados de Cloud DNS.
• Probar la recuperación y la recuperación con registros actualizados de Cloud DNS.

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

• Compute Engine
• Redes
• Cloud DNS
• Cloud Storage

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Antes de comenzar

Es posible que las restricciones de seguridad que define tu organización no te permitan completar los siguientes pasos. Para obtener información sobre la solución de problemas, consulta Desarrolla aplicaciones en un entorno de Google Cloud restringido.

1. Accede a tu cuenta de Google Cloud. Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

2. En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.

   Nota: Si no planeas conservar los recursos que creaste durante este procedimiento, crea un proyecto en lugar de seleccionar uno existente. Cuando termines, puedes borrar el proyecto y quitar todos los recursos asociados con él.

   Ir al selector de proyectos

3. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

4. Habilita la API de Compute Engine .

   Habilita la API

5. Instala Google Cloud CLI.

6. Para inicializar la CLI de gcloud, ejecuta el siguiente comando:

   gcloud init

7. En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.

   Nota: Si no planeas conservar los recursos que creaste durante este procedimiento, crea un proyecto en lugar de seleccionar uno existente. Cuando termines, puedes borrar el proyecto y quitar todos los recursos asociados con él.

   Ir al selector de proyectos

8. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

9. Habilita la API de Compute Engine .

   Habilita la API

10. Instala Google Cloud CLI.

11. Para inicializar la CLI de gcloud, ejecuta el siguiente comando:

    gcloud init

Puedes ejecutar Google Cloud CLI en la consola de Google Cloud sin instalar Google Cloud CLI. Para ejecutar la CLI de gcloud en la consola de Google Cloud, usa Cloud Shell.

Prepare el entorno

En esta sección, defines algunas variables para los nombres y las ubicaciones de tus recursos. Los comandos de la CLI de Google Cloud usan estas variables a medida que implementas los recursos.

En esta implementación, a menos que se indique lo contrario, debes ingresar todos los comandos en Cloud Shell o en tu entorno de desarrollo local.

1. Reemplaza PROJECT_ID con el ID de tu proyecto. Si lo deseas, proporciona tu propio sufijo de nombre para los recursos a fin de facilitar la búsqueda y la identificación, como app.

   Especifica dos regiones, como us-west1 y us-west2, y una zona dentro de una de esas regiones, como us-west1-a. Esta zona define dónde se crea la VM base inicial que se usa a fin de crear una imagen para el grupo de instancias administrado.

   Por último, configura un dominio que se usa para tu sitio web estático, como example.com.

   PROJECT_ID=PROJECT_ID
   NAME_SUFFIX=app
   REGION1=us-west1
   REGION2=us-west2
   ZONE=us-west1-a
   DOMAIN=example.com
   

Crea una VPC y una subred

Para proporcionar a las VM acceso a la red, crea una nube privada virtual (VPC) y subredes. Como necesitas grupos de instancias administrados en dos regiones, creas una subred en cada región. Para obtener más información sobre las ventajas del modo de subred personalizado a fin de administrar los rangos de direcciones IP en uso en tu entorno, consulta Usa redes de VPC en modo personalizado.

1. Crea la VPC con un modo de subred personalizado:

   gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom
   

2. Ahora, crea dos subredes en la VPC nueva, una para cada región. Define tus propios rangos de direcciones, como 10.1.0.0/20 y 10.2.0.0/20, que se ajusten al rango de red:

   gcloud compute networks subnets create \
       subnet-$NAME_SUFFIX-$REGION1 \
       --network=network-$NAME_SUFFIX \
       --range=10.1.0.0/20 \
       --region=$REGION1
   
   gcloud compute networks subnets create \
       subnet-$NAME_SUFFIX-$REGION2 \
       --network=network-$NAME_SUFFIX \
       --range=10.2.0.0/20 \
       --region=$REGION2
   

Crea reglas de firewall

Para permitir que el tráfico de red fluya de forma correcta en la VPC, usa las reglas de firewall.

1. Crea reglas de firewall para permitir el tráfico web y las verificaciones de estado del balanceador de cargas y los grupos de instancias administrados:

   gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:80 \
       --source-ranges=0.0.0.0/0 \
       --target-tags=http-server
   
   gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=allow-health-check \
       --rules=tcp:80
   

   La regla HTTP permite el tráfico a cualquier VM en la que se aplique la etiqueta http-server y desde cualquier fuente que use el rango 0.0.0.0/0. En el caso de la regla de verificación de estado, se establecen rangos predeterminados para Google Cloud a fin de permitir que la plataforma verifique de forma correcta el estado de los recursos.

2. A fin de permitir el tráfico SSH para la configuración inicial de una imagen de VM base, apunta la regla de firewall a tu entorno mediante el parámetro --source-range. Es posible que debas trabajar con tu equipo de red para determinar qué rangos de origen usa tu organización.

   Precaución: No recomendamos usar un rango amplio de 0.0.0.0/0 que permita todo el tráfico. Para definir el tráfico hacia una sola dirección IP, usa una máscara de red /32, como 35.230.62.163/32.

   Reemplaza IP_ADDRESS_SCOPE por tus propios alcances de dirección IP:

   gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:22 \
       --source-ranges=IP_ADDRESS_SCOPE
   

3. Después de crear las reglas de firewall, verifica que se hayan agregado las tres reglas:

   gcloud compute firewall-rules list \
       --project=$PROJECT_ID \
       --filter="NETWORK=network-$NAME_SUFFIX"
   

   El siguiente resultado de ejemplo muestra que las tres reglas se crearon de forma correcta:

   NAME                    NETWORK      DIRECTION  PRIORITY  ALLOW
   allow-health-check-app  network-app  INGRESS    1000      tcp:80
   allow-http-app          network-app  INGRESS    1000      tcp:80
   allow-ssh-app           network-app  INGRESS    1000      tcp:22
   

Crea y configura una imagen de VM base

Para crear VM idénticas que implementes sin configuración adicional, usa una imagen de VM personalizada. En esta imagen, se captura la configuración del SO y Apache y se usa para crear cada VM en el grupo de instancias administrado en los siguientes pasos.

Nota: En este documento, crearás y configurarás la VM y las imágenes base de forma manual. En implementaciones de producción, usa las herramientas de canalización y las canalizaciones existentes para automatizar tanto como sea posible este proceso. Para obtener más información, consulta Administra la infraestructura como código con Terraform, Cloud Build y GitOps.

En la VM, crea un archivo index.html básico en el disco persistente y actívalo en /var/www/example.com. Un archivo de configuración de Apache en /etc/apache2/sites-available/example.com.conf entrega contenido web desde la ubicación del disco persistente activado.

En el siguiente diagrama, se muestra la página HTML básica que entrega Apache que se almacena en el disco persistente:

Debes compilar este entorno en los siguientes pasos.

1. Crea una VM base con un disco persistente conectado:

   gcloud compute instances create vm-base-$NAME_SUFFIX \
       --zone=$ZONE \
       --machine-type=n1-standard-1 \
       --subnet=subnet-$NAME_SUFFIX-$REGION1 \
       --tags=http-server \
       --image=debian-10-buster-v20210420 \
       --image-project=debian-cloud \
       --boot-disk-size=10GB \
       --boot-disk-type=pd-balanced \
       --boot-disk-device-name=vm-base-$NAME_SUFFIX \
       --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
   

   Usa los parámetros definidos al comienzo de este documento para nombrar la VM y conectarte a la subred correcta. Los nombres también se asignan a partir de los parámetros del disco de arranque y el disco de datos.

2. Para instalar y configurar el sitio web simple, primero conéctate a la VM base mediante SSH:

   gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
   

3. En la sesión SSH a la VM, crea una secuencia de comandos para configurar la VM en el editor que elijas. En el siguiente ejemplo, se usa Nano como editor:

   nano configure-vm.sh
   

   Pega la siguiente secuencia de comandos de configuración en el archivo:

   #!/bin/bash
   
   NAME_SUFFIX=app
   
   # Create directory for the basic website files
   sudo mkdir -p /var/www/example.com
   sudo chmod a+w /var/www/example.com
   sudo chown -R www-data: /var/www/example.com
   
   # Find the disk name, then format and mount it
   DISK_NAME="google-disk-base-$NAME_SUFFIX"
   DISK_PATH="$(find /dev/disk/by-id -name "${DISK_NAME}" | xargs -I '{}' readlink -f '{}')"
   
   sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_PATH
   sudo mount -o discard,defaults $DISK_PATH /var/www/example.com
   
   # Install Apache
   sudo apt-get update && sudo apt-get -y install apache2
   
   # Write out a basic HTML file to the mounted persistent disk
   sudo tee -a /var/www/example.com/index.html >/dev/null <<'EOF'
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   EOF
   
   # Write out an Apache configuration file
   sudo tee -a /etc/apache2/sites-available/example.com.conf >/dev/null <<'EOF'
   <VirtualHost *:80>
           ServerName www.example.com
   
           ServerAdmin webmaster@localhost
           DocumentRoot /var/www/example.com
   
           ErrorLog ${APACHE_LOG_DIR}/error.log
           CustomLog ${APACHE_LOG_DIR}/access.log combined
   </VirtualHost>
   EOF
   
   # Enable the Apache configuration file and reload service
   sudo a2dissite 000-default
   sudo a2ensite example.com.conf
   sudo systemctl reload apache2
   

   Actualiza la variable NAME_SUFFIX para que coincida con el valor establecido al comienzo de este documento, como app.

4. Escribe el archivo y sal del editor. Por ejemplo, en Nano, usa Ctrl-O para escribir el archivo y, luego, sal con Ctrl-X.

5. Haz que la secuencia de comandos de configuración sea ejecutable y, luego, ejecútala:

   chmod +x configure-vm.sh
   ./configure-vm.sh
   

6. Salga de la sesión SSH en la VM.

   exit
   

7. Obtén la dirección IP de la VM y usa curl para ver la página web básica:

   curl $(gcloud compute instances describe vm-base-$NAME_SUFFIX \
       --zone $ZONE \
       --format="value(networkInterfaces.accessConfigs.[0].natIP)")
   

   Se muestra el sitio web básico, como se muestra en el siguiente resultado de ejemplo:

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

   Este paso confirma que Apache esté configurado correctamente y que la página se cargue desde el disco persistente conectado. En las siguientes secciones, crearás una imagen con esta VM base y configurarás una plantilla de instancias con una secuencia de comandos de inicio.

Implementa los recursos de Compute Engine

En este patrón de conmutación por error en caliente, se usan grupos de instancias administrados para ejecutar las VM. Los grupos de instancias administrados se ejecutan en dos regiones, y cada grupo supervisa el estado de las VM. Si hay una interrupción y una de las VM falla, el grupo de instancias administrado vuelve a crear la VM. Esta configuración crea una aplicación con alta disponibilidad, incluso sin la conmutación por error en caliente para un sitio estático en Cloud Storage.

1. Antes de crear una imagen, debes detener la VM:

   gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE
   

2. Ejecuta el siguiente conjunto de comandos para crear las imágenes de VM, las plantillas de instancias y los grupos de instancias administrados:

   # Create the base VM images
   gcloud compute images create image-$NAME_SUFFIX \
       --source-disk=vm-base-$NAME_SUFFIX \
       --source-disk-zone=$ZONE
   
   gcloud compute images create image-disk-$NAME_SUFFIX \
       --source-disk=disk-base-$NAME_SUFFIX \
       --source-disk-zone=$ZONE
   
   # Create instance templates
   gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION1 \
       --machine-type=n1-standard-1 \
       --subnet=projects/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 \
       --region=$REGION1 \
       --tags=http-server \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a \
       --image=image-$NAME_SUFFIX \
       --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes
   
   gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 \
       --machine-type=n1-standard-1 \
       --subnet=projects/$PROJECT_ID/regions/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 \
       --region=$REGION2 \
       --tags=http-server \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a \
       --image=image-$NAME_SUFFIX \
       --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes
   
   # Create a health check for VM instances
   gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \
       --port 80
   
   # Create the managed instance groups
   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION1 \
       --template=template-$NAME_SUFFIX-$REGION1 \
       --size=2 \
       --region=$REGION1 \
       --health-check=http-basic-check-$NAME_SUFFIX
   
   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION2 \
       --template=template-$NAME_SUFFIX-$REGION2 \
       --size=2 \
       --region=$REGION2 \
       --health-check=http-basic-check-$NAME_SUFFIX
   

Crea y configura un balanceador de cargas

Para que los usuarios accedan a tu sitio web, debes permitir el tráfico a través de las VM que se ejecutan en los grupos de instancias administrados. También debes redireccionar de manera automática el tráfico a VM nuevas si hay una falla de zona en un grupo de instancias administrado.

En la siguiente sección, crearás un balanceador de cargas HTTPS externo con un servicio de backend para el tráfico HTTP en el puerto 80, usarás la verificación de estado creada en los pasos anteriores, y asignarás una dirección IP externa al servicio de backend.

Para obtener más información, consulta Cómo configurar un balanceador de cargas HTTP externo simple.

1. Crea y configura el balanceador de cargas para tu aplicación:

   # Configure port rules for HTTP port 80
   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$REGION1 \
       --named-ports http:80 \
       --region $REGION1
   
   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$REGION2 \
       --named-ports http:80 \
       --region $REGION2
   
   # Create a backend service and add the managed instance groups to it
   gcloud compute backend-services create \
       web-backend-service-$NAME_SUFFIX \
       --protocol=HTTP \
       --port-name=http \
       --health-checks=http-basic-check-$NAME_SUFFIX \
       --global
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$REGION1 \
       --instance-group-region=$REGION1 \
       --global
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \
       --instance-group-region=$REGION2 \
       --global
   
   # Create a URL map for the backend service
   gcloud compute url-maps create web-map-http-$NAME_SUFFIX \
       --default-service web-backend-service-$NAME_SUFFIX
   
   # Configure forwarding for the HTTP traffic
   gcloud compute target-http-proxies create \
       http-lb-proxy-$NAME_SUFFIX \
       --url-map web-map-http-$NAME_SUFFIX
   
   gcloud compute forwarding-rules create \
       http-content-rule-$NAME_SUFFIX \
       --global \
       --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \
       --ports=80
   

2. Obtén la dirección IP de la regla de reenvío para el tráfico web:

   IP_ADDRESS=$(gcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \
       --global \
       --format="value(IPAddress)")
   

3. Usa curl o abre tu navegador web para ver el sitio web mediante la dirección IP del balanceador de cargas del paso anterior:

   curl $IP_ADDRESS
   

   El balanceador de cargas tarda unos minutos en terminar la implementación y dirigir el tráfico a tu backend de forma correcta. Se muestra un error de HTTP 404 si el balanceador de cargas todavía se está implementando. Si es necesario, espera unos minutos y vuelve a acceder al sitio web.

   Se muestra el sitio web básico, como se muestra en el siguiente resultado de ejemplo:

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p>
   </body>
   </html>
   

Crea y configura un bucket de almacenamiento

Cloud Storage se usa para almacenar archivos estáticos de sitios web. En este ejemplo básico, puedes crear un solo archivo con un texto un poco diferente al de las VM.

En las implementaciones de producción, es probable que el sitio web incluya muchos más archivos y códigos de la aplicación adicionales en tus VM de grupos de instancias administrados que los que se muestran en este documento. La versión estática alojada en Cloud Storage suele ser una versión más limitada que proporciona una funcionalidad mínima. En una situación de conmutación por error en caliente, este sitio web limitado de Cloud Storage se muestra hasta que se recuperen los grupos de instancias administrados y puedan entregar tráfico para la experiencia completa del sitio web.

1. Verifica el dominio que deseas usar con tu bucket de Cloud Storage.

2. Crea un bucket de Cloud Storage para que coincida con el nombre del dominio que te pertenece y que deseas usar:

   gsutil mb gs://static-web.$DOMAIN
   

   Se usa la variable DOMAIN definida al comienzo de este documento, como example.com. En este ejemplo, se almacenan los archivos estáticos en static-web.example.com.

3. Crea un archivo local que copies en el bucket de Cloud Storage en el paso siguiente:

   cat <<EOF > index.html
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test static web server with warm failover from Cloud Storage!</p>
   </body>
   </html>
   EOF
   

4. Sube el archivo HTML básico al bucket de Cloud Storage:

   gsutil cp index.html gs://static-web.$DOMAIN
   

5. Para permitir que los usuarios vean el contenido web estático, configura los permisos adecuados en el bucket de Cloud Storage:

   gsutil iam ch allUsers:objectViewer gs://static-web.$DOMAIN
   

6. Configura el bucket de Cloud Storage para entregar el archivo index.html como la página web predeterminada:

   gsutil web set -m index.html gs://static-web.$DOMAIN
   

Crea una zona de DNS y un registro DNS

Para permitir que el tráfico se dirija al sitio estático en caliente en Cloud Storage cuando hay una interrupción en los grupos de instancias administrados, crea una zona de Cloud DNS. En condiciones normales, esta zona de DNS dirige el tráfico a través del balanceador de cargas externo a los grupos de instancias administrados creados en las secciones anteriores.

Nota: Con un enfoque basado en DNS para realizar una conmutación por error, los usuarios continúan con la resolución de la dirección anterior del balanceador de cargas hasta que venza su registro DNS almacenado en caché. El tiempo que existe para el registro DNS almacenado en caché de un usuario se define con el valor de tiempo de actividad (TTL) cuando creas los registros de Cloud DNS. Como en este documento se describe un patrón de conmutación por error en caliente, se debe esperar cierta cantidad de tiempo de inactividad como parte del saldo de un patrón de conmutación por error en caliente con costos adicionales y complejidad de configuración.

1. Crea una zona de Cloud DNS:

   gcloud dns managed-zones create zone-$NAME_SUFFIX \
       --dns-name=$DOMAIN \
       --description="DNS zone for warm site failover"
   

   Se usa la variable DOMAIN definida al comienzo de este documento, como example.com.

2. Obtén los detalles de la zona de Cloud DNS:

   gcloud dns managed-zones describe zone-$NAME_SUFFIX
   

   En el siguiente resultado de ejemplo, se muestra el nameServers para la zona, como ns-cloud-b1.googledomains.com.

   [...]
   kind: dns#managedZone
   name: zone-app
   nameServers:
   - ns-cloud-b1.googledomains.com.
   - ns-cloud-b2.googledomains.com.
   - ns-cloud-b3.googledomains.com.
   - ns-cloud-b4.googledomains.com.
   

3. Cloud DNS debe estar autorizado para el dominio. Crea registros de Nameserver (NS) con el registrador de dominios que apunten a la zona de Cloud DNS. Usa las direcciones de Nameserver que se muestran en el paso anterior.

   Para obtener más información y un ejemplo con Google Domains, consulta Cómo actualizar los servidores de nombres.

4. En la zona de Cloud DNS, agrega un registro para www con la dirección IP del balanceador de cargas que se obtuvo en una sección anterior:

   gcloud dns record-sets transaction start \
       --zone=zone-$NAME_SUFFIX
   
   gcloud dns record-sets transaction add $IP_ADDRESS \
       --name=www.$DOMAIN \
       --ttl=300 \
       --type=A \
       --zone=zone-$NAME_SUFFIX
   

   Este registro dirige las solicitudes de los usuarios para el sitio web a través del balanceador de cargas a los grupos de instancias administrados. Se establece un TTL de 300 segundos a fin de reducir el tiempo que existe para el registro DNS almacenado en caché de un usuario.

5. Crea un registro que usará el bucket de Cloud Storage para el sitio web estático:

   gcloud dns record-sets transaction add c.storage.googleapis.com. \
       --name=static-web.$DOMAIN \
       --ttl=300 \
       --type=CNAME \
       --zone=zone-$NAME_SUFFIX
   

   En este ejemplo, se usa static-web como subdominio. Deja el campo c.storage.googleapis.com.. Otra vez; se establece un TTL de 300 segundos a fin de reducir el tiempo que existe para el registro DNS almacenado en caché de un usuario.

6. Por último, confirma las adiciones de registro DNS a la zona:

   gcloud dns record-sets transaction execute \
       --zone=zone-$NAME_SUFFIX
   

Verifica y prueba la zona de DNS y los registros de DNS

Revisemos las implementaciones de recursos antes de simular una falla de zona. Todos los recursos se crearon para admitir el entorno, como se muestra en la siguiente imagen:

• Los registros de zona de Cloud DNS dirigen a los usuarios al balanceador de cargas para su distribución entre las VM del grupo de instancias administrado.
• Un bucket de Cloud Storage está configurado para alojar páginas web estáticas si hay una interrupción en los grupos de instancias administrados.
• La zona de Cloud DNS está configurada para usar el sitio estático en Cloud Storage, pero actualmente no resuelve las solicitudes al bucket de almacenamiento.

Para ver los registros DNS y la resolución de prueba, debes resolver las direcciones con los servidores de Cloud DNS. En las implementaciones de producción, asegúrate de probar y verificar que las direcciones se resuelvan de forma correcta y, luego, actualiza tus propios servidores DNS para que se resuelvan de forma adecuada. En este documento, no se detallan los pasos para actualizar tus propios servidores DNS, solo se menciona la forma de verificar los flujos de tráfico de manera correcta en condiciones normales y de conmutación por error.

1. Obtén los detalles de la zona de Cloud DNS de nuevo:

   gcloud dns managed-zones describe zone-$NAME_SUFFIX
   

   En el siguiente resultado de ejemplo, se muestra el nameServers para la zona, como ns-cloud-b1.googledomains.com.

   [...]
   kind: dns#managedZone
   name: zone-app
   nameServers:
   - ns-cloud-b1.googledomains.com.
   - ns-cloud-b2.googledomains.com.
   - ns-cloud-b3.googledomains.com.
   - ns-cloud-b4.googledomains.com.
   

2. Para resolver el registro www de tu zona de Cloud DNS con uno de estos servidores de nombres, usa el comando dig:

   dig @ns-cloud-b1.googledomains.com www.$DOMAIN
   

   En este ejemplo, se usa la dirección de Nameserver ns-cloud-b1.googledomains.com que se muestra en el comando describe anterior. Proporciona tu propia dirección de Nameserver que se muestra en el resultado del comando anterior.

   En el siguiente resultado de ejemplo, se muestra que el registro se resuelve en la dirección IP del balanceador de cargas. Si usaras este Nameserver para acceder a la dirección, como si se usara curl y el parámetro --resolve con el Nameserver de Cloud DNS, la página predeterminada se mostraría desde uno de los grupos de instancias administrados detrás del balanceador de cargas.

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com
   ; (1 server found)
   
   [...]
   
   ;; QUESTION SECTION:
   ;www.example.com.           IN      A
   
   ;; ANSWER SECTION:
   www.example.com.    300     IN      A       35.227.253.90
   

3. Vuelve a usar el comando dig a fin de verificar el registro DNS para el sitio web estático en Cloud Storage:

   dig @ns-cloud-b1.googledomains.com static-web.$DOMAIN
   

   En el siguiente resultado de ejemplo, se muestra que el registro se resuelve en Cloud Storage, que puede entregar el contenido estático del bucket de almacenamiento:

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com static-web.example.com
   ; (1 server found)
   
   [...]
   
   ;; QUESTION SECTION:
   ;static-web.example.com.    IN      A
   
   ;; ANSWER SECTION:
   static-web.example.com. 300 IN      CNAME   c.storage.googleapis.com.
   

Conmuta por error al bucket de Cloud Storage

En un entorno de producción, es posible que recibas una alerta mediante Cloud Monitoring o cualquier otra solución de supervisión cuando haya un problema con los grupos de instancias administrados. Esta alerta solicita a una persona que comprenda el alcance de la falla antes de que actualices los registros de Cloud DNS para redireccionar el tráfico al sitio web estático alojado en Cloud Storage. Un enfoque alternativo es usar la solución de supervisión para responder de forma automática a las interrupciones con los grupos de instancias administrados.

Cuando realizas una conmutación por error, Cloud DNS resuelve el tráfico al sitio web estático alojado en Cloud Storage, como se muestra en la siguiente imagen:

Cuando tú o tu solución de supervisión determinen que la acción más adecuada es actualizar los registros de Cloud DNS para dirigir el tráfico a Cloud Storage, actualiza el registro A de DNS existente. En este documento, actualizarás de forma manual los registros de Cloud DNS para redireccionar el tráfico al sitio web estático alojado en Cloud Storage.

1. Para realizar una conmutación por error en los registros de Cloud DNS, quita el registro A existente que se resuelve en el balanceador de cargas:

   gcloud dns record-sets transaction start \
       --zone=zone-$NAME_SUFFIX
   
   gcloud dns record-sets transaction remove $IP_ADDRESS \
       --name=www.$DOMAIN \
       --ttl=300 \
       --type=A \
       --zone=zone-$NAME_SUFFIX
   

2. Crea un registro CNAME para www que apunte al contenido alojado en Cloud Storage:

   gcloud dns record-sets transaction add static-web.$DOMAIN \
       --name=www.$DOMAIN. \
       --ttl=30 \
       --type=CNAME \
       --zone=zone-$NAME_SUFFIX
   

3. Confirma las actualizaciones en la zona de Cloud DNS:

   gcloud dns record-sets transaction execute \
       --zone=zone-$NAME_SUFFIX
   

4. Usa el comando dig para confirmar que el registro www ahora se resuelva en la dirección del sitio web estático de Cloud Storage:

   dig @ns-cloud-b1.googledomains.com www.$DOMAIN
   

   En el siguiente resultado de ejemplo, se muestra que el registro www.example.com se resuelve en el registro CNAME del sitio web estático de Cloud Storage. Las solicitudes para acceder a www.example.com se redireccionan al depósito de Cloud Storage, que muestra el sitio web estático:

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com
   ; (1 server found)
   
   [...]
   
   ;; QUESTION SECTION:
   ;www.example.com.           IN      A
   
   ;; ANSWER SECTION:
   www.example.com.    30      IN      CNAME   static-web.example.com.
   static-web.example.com. 300 IN      CNAME   c.storage.googleapis.com.
   

Vuelve a los grupos de instancias administrados

Una vez que se resuelven los problemas con los grupos de instancias administrados, puedes volver a entregar el contenido de los grupos de instancias administrados con balanceo de cargas si actualizas de nuevo los registros de Cloud DNS. Una vez más, una persona podría tomar esta decisión mediante estadísticas de Cloud Monitoring para el estado de los grupos de instancias administrados. O bien, puedes usar la automatización para responder al estado restablecido del grupo de instancias administrado. En este documento, actualizarás de forma manual los registros de Cloud DNS.

Cuando realizas una conmutación por recuperación, Cloud DNS resuelve el tráfico a los grupos de instancias administrados de nuevo, como se muestra en la siguiente imagen:

1. Quita el registro CNAME www que redirecciona el tráfico al contenido alojado en Cloud Storage:

   gcloud dns record-sets transaction start \
       --zone=zone-$NAME_SUFFIX
   
   gcloud dns record-sets transaction remove static-web.$DOMAIN \
       --name=www.$DOMAIN \
       --ttl=30 \
       --type=CNAME \
       --zone=zone-$NAME_SUFFIX
   

2. Agrega un registro A para que apunte al balanceador de cargas frente a los grupos de instancias administrados de nuevo:

   gcloud dns record-sets transaction add $IP_ADDRESS \
       --name=www.$DOMAIN \
       --ttl=300 \
       --type=A \
       --zone=zone-$NAME_SUFFIX
   

3. Confirma las actualizaciones en la zona de Cloud DNS:

   gcloud dns record-sets transaction execute \
       --zone=zone-$NAME_SUFFIX
   

4. Usa el comando dig una vez más para confirmar que el registro www se resuelva en la dirección del balanceador de cargas frente a los grupos de instancias administrados de nuevo:

   dig @ns-cloud-b1.googledomains.com www.$DOMAIN
   

   En el siguiente resultado de ejemplo, se muestra que el registro se resuelve en la dirección IP del balanceador de cargas y el tráfico se entregaría desde uno de los grupos de instancias administrados:

   ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com
   ; (1 server found)
   
   [...]
   
   ;; QUESTION SECTION:
   ;www.example.com.           IN      A
   
   ;; ANSWER SECTION:
   www.example.com.    300     IN      A       35.227.253.90
   

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Para borrar los recursos individuales creados en este documento, completa los siguientes pasos.

1. Borra la zona de DNS y los registros:

   touch empty-file
   gcloud dns record-sets import -z zone-$NAME_SUFFIX \
       --delete-all-existing \
       empty-file
   rm empty-file
   
   gcloud dns managed-zones delete zone-$NAME_SUFFIX
   

2. Borra el bucket de Cloud Storage:

   gsutil rm -r gs://static-web.$DOMAIN
   

3. Borra la configuración del balanceador de cargas:

   gcloud compute forwarding-rules delete \
       http-content-rule-$NAME_SUFFIX --global --quiet
   
   gcloud compute target-http-proxies delete \
       http-lb-proxy-$NAME_SUFFIX --quiet
   
   gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet
   
   gcloud compute backend-services delete \
       web-backend-service-$NAME_SUFFIX --global --quiet
   

4. Borra los grupos de instancias administrados y la verificación de estado:

   gcloud compute instance-groups managed delete \
       instance-group-$NAME_SUFFIX-$REGION1 \
       --region=$REGION1 --quiet
   
   gcloud compute instance-groups managed delete \
       instance-group-$NAME_SUFFIX-$REGION2 \
       --region=$REGION2 --quiet
   
   gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
   

5. Borra las plantillas de instancias, las imágenes, la VM base y los discos persistentes:

   gcloud compute instance-templates delete \
       template-$NAME_SUFFIX-$REGION1 --quiet
   
   gcloud compute instance-templates delete \
       template-$NAME_SUFFIX-$REGION2 --quiet
   
   gcloud compute images delete image-$NAME_SUFFIX --quiet
   
   gcloud compute images delete image-disk-$NAME_SUFFIX --quiet
   
   gcloud compute instances delete vm-base-$NAME_SUFFIX \
       --zone=$ZONE --quiet
   

6. Borra las reglas de firewall.

   gcloud compute firewall-rules delete \
       allow-health-check-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete \
       allow-ssh-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete \
       allow-http-$NAME_SUFFIX --quiet
   

7. Borra la subred y la VPC.

   gcloud compute networks subnets delete \
       subnet-$NAME_SUFFIX-$REGION1 --region=$REGION1 --quiet
   
   gcloud compute networks subnets delete \
       subnet-$NAME_SUFFIX-$REGION2 --region=$REGION2 --quiet
   
   gcloud compute networks delete network-$NAME_SUFFIX --quiet
   

¿Qué sigue?

• Si quieres obtener un enfoque alternativo que use el balanceo de cargas de aplicaciones externo en lugar de Cloud DNS para controlar la conmutación por error, consulta Implementa un servidor web recuperable en caliente con Compute Engine y Cloud Storage. Este patrón es útil si no tienes Cloud DNS, o si no deseas usarlo.
• Si deseas obtener información para determinar el mejor enfoque para tus propias aplicaciones y qué método de recuperación usar, consulta la Guía de planificación para la recuperación ante desastres.
• Si deseas ver otros patrones de las aplicaciones, como la conmutación por error en frío y caliente, consulta Situaciones de recuperación ante desastres para aplicaciones.
• Para conocer más formas de manejar el escalamiento y la disponibilidad, consulta los Patrones de apps escalables y resilientes.
• Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.