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:
Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.
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.
- 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.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
-
Habilita la API de Compute Engine .
- Instala Google Cloud CLI.
-
Para inicializar la CLI de gcloud, ejecuta el siguiente comando:
gcloud init
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
-
Habilita la API de Compute Engine .
- Instala Google Cloud CLI.
-
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.
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, comoapp
.Especifica dos regiones, como
us-west1
yus-west2
, y una zona dentro de una de esas regiones, comous-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.
Crea la VPC con un modo de subred personalizado:
gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom
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
y10.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.
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 rango0.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.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.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
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.
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.
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.
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
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.Escribe el archivo y sal del editor. Por ejemplo, en Nano, usa
Ctrl-O
para escribir el archivo y, luego, sal conCtrl-X
.Haz que la secuencia de comandos de configuración sea ejecutable y, luego, ejecútala:
chmod +x configure-vm.sh ./configure-vm.sh
Salga de la sesión SSH en la VM.
exit
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.
Antes de crear una imagen, debes detener la VM:
gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE
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.
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
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)")
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.
Verifica el dominio que deseas usar con tu bucket de Cloud Storage.
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, comoexample.com
. En este ejemplo, se almacenan los archivos estáticos enstatic-web.example.com
.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
Sube el archivo HTML básico al bucket de Cloud Storage:
gsutil cp index.html gs://static-web.$DOMAIN
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
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.
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, comoexample.com
.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, comons-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.
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.
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.
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 campoc.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.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.
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, comons-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.
Para resolver el registro
www
de tu zona de Cloud DNS con uno de estos servidores de nombres, usa el comandodig
: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 comandodescribe
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
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.
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
Crea un registro
CNAME
parawww
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
Confirma las actualizaciones en la zona de Cloud DNS:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Usa el comando
dig
para confirmar que el registrowww
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 awww.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:
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
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
Confirma las actualizaciones en la zona de Cloud DNS:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Usa el comando
dig
una vez más para confirmar que el registrowww
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.
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
Borra el bucket de Cloud Storage:
gsutil rm -r gs://static-web.$DOMAIN
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
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
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
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
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.