Nube de GoogleEste documento está dirigido a arquitectos y personas que trabajan en equipos operativos y administrativos. El documento describe un patrón de ejemplo que puede usar para sus propias implementaciones en Google Cloud En este patrón, Cloud DNS dirige el tráfico a las instancias de Compute Engine en grupos de instancias administrados que entregan el contenido. En una interrupción, actualiza la zona de Cloud DNS y realiza la conmutación por error a un sitio estático en Cloud Storage Para completar este tutorial, necesita un nombre de dominio registrado que usted controle y quiera usar con este documento En las implementaciones de producción, es probable que su sitio web incluya muchos más archivos y código de aplicación adicional en sus máquinas virtuales (VM) de grupo de instancias administradas de lo que se muestra en este documento. Luego, Cloud Storage aloja una versión estática más limitada que proporciona una funcionalidad mínima. En un escenario de conmutación por error tibio, los usuarios ven este sitio web limitado hasta que los grupos de instancias administrados se recuperan y pueden atender el tráfico para la experiencia completa del sitio web. En este tutorial, implementará recursos para crear un entorno como se muestra en la siguiente imagen: Cuando necesite una conmutación por error, actualice 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 tibio equilibra el costo de ejecutar otro grupo de instancias administrado en una región diferente que solo usa cuando falla la región principal. El costo de un sitio estático que usa Cloud Storage es más bajo que ejecutar otro grupo de instancias administrado, pero hay un pequeño retraso mientras actualiza Cloud DNS entre las opciones de alojamiento. La experiencia limitada del sitio web en Cloud Storage es mejor que un sitio web completamente no disponible y una mala experiencia del cliente Para conocer un enfoque alternativo que usa el balanceo de cargas HTTP(S) externo en lugar de Cloud DNS para controlar la conmutación por error, consulta Implementar un servidor web recuperable en caliente con Compute Engine y Cloud Storage. Este patrón es útil si no tiene o no quiere usar Cloud DNS Para ejecutar aplicaciones confiables en Google Cloud, le recomendamos que diseñe su infraestructura de aplicaciones para manejar las interrupciones. Según su aplicación y las necesidades comerciales, es posible que necesite un patrón de conmutación por error en frío, conmutación por error en caliente o conmutación por error en caliente. Para obtener más información sobre cómo determinar el mejor enfoque para sus propias aplicaciones, consulte la guía de planificación de recuperación ante desastres. Este documento utiliza un servidor web Apache básico, pero el mismo enfoque para la implementación de la infraestructura se aplica a otros entornos de aplicaciones que necesita crear. ## Objetivos - Cree grupos de instancias administrados regionales con una imagen de VM personalizada - Crear un depósito de almacenamiento en la nube - Crear y configurar una zona de Cloud DNS - Pruebe la conmutación por error del servidor web tibio con registros Cloud DNS actualizados - Pruebe la recuperación y la conmutación por recuperación con registros de Cloud DNS actualizados ## Costos Este instructivo usa los siguientes componentes facturables de Google Cloud: Para generar una estimación de costos basada en su uso proyectado, usa la calculadora de precios ## Antes de que empieces Es posible que algunos de los pasos de este documento no funcionen correctamente si su organización aplica restricciones a su entorno de Google Cloud. En ese caso, es posible que no pueda completar tareas como crear direcciones IP públicas o claves de cuenta de servicio. Si realiza una solicitud que devuelve un error sobre las restricciones, consulte cómo desarrollar aplicaciones en un entorno de Google Cloud restringido. - Inicie sesión en su cuenta de Google Cloud. Si es nuevo en Google Cloud, cree una cuenta para evaluar el rendimiento de nuestros productos en escenarios del mundo real. Los nuevos clientes también obtienen $300 en créditos gratuitos para ejecutar, probar e implementar cargas de trabajo - En la consola de Google Cloud, en la página de selección de proyectos, seleccione o cree un proyecto de Google Cloud - Asegúrate de que la facturación esté habilitada para tu proyecto de Cloud. Más información sobre cómo verificar si la facturación está habilitada en un proyecto - Habilitar la API de Compute Engine - Instalar e inicializar la CLI de Google Cloud - En la consola de Google Cloud, en la página de selección de proyectos, seleccione o cree un proyecto de Google Cloud - Asegúrate de que la facturación esté habilitada para tu proyecto de Cloud. Más información sobre cómo verificar si la facturación está habilitada en un proyecto - Habilitar la API de Compute Engine - Instalar e inicializar la CLI de Google Cloud Puede ejecutar la CLI de Google Cloud en la consola de Google Cloud sin instalar la CLI de Google Cloud. Para ejecutar la CLI de gcloud en la consola de Google Cloud, use Cloud Shell ## Preparar el ambiente En esta sección, define algunas variables para los nombres y ubicaciones de sus recursos. Los comandos de la CLI de Google Cloud utilizan estas variables a medida que implementa los recursos. A lo largo de este instructivo, a menos que se indique lo contrario, ingresa todos los comandos en Cloud Shell o en su entorno de desarrollo local. Reemplazar con su propio ID de proyecto. Si lo desea, proporcione su propio sufijo de nombre para recursos que ayuden a buscarlos e identificarlos, como PROJECTO ID aplicación Especifique dos regiones, como y us-west1 , y una zona dentro de una de esas regiones, como us-west2 . Esta zona define dónde se crea la VM base inicial que se usa para crear una imagen para el grupo de instancias administrado. us-west1-a Finalmente, configure un dominio que se use para su sitio web estático, como ejemplo.com PROYECTO_ID= PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= ejemplo.com ## Crear una VPC y una subred Para proporcionar acceso a la red a las máquinas virtuales, crea una nube privada virtual (VPC) y subredes. Como necesita grupos de instancias administrados en dos regiones, debe crear una subred en cada región. Para obtener más información sobre las ventajas del modo de subred personalizado para administrar rangos de direcciones IP en uso en tu entorno, consulta Usar redes de VPC en modo personalizado Cree la VPC con un modo de subred personalizado: Las redes informáticas de gcloud crean red-$NOMBRE_SUFIJO --subnet-mode=custom Ahora cree dos subredes en la nueva VPC, una para cada región. Defina sus propios intervalos de direcciones, como y 10.1.0.0/20 , que se ajusten a su rango de red: 10.2.0.0/20 Las subredes de redes informáticas de gcloud crean \ subnet-$NAME_SUFFIX-$REGION1 \ --network=network-$NAME_SUFFIX \ --range= 10.1.0.0/20\ --region=$REGION1 gcloud computing redes subredes crear \ subred-$NOMBRE_SUFIJO-$REGION2 \ --network=red-$NOMBRE_SUFIJO \ --range= 10.2.0.0/20\ --region=$ REGIÓN2 ## Crear reglas de cortafuegos Para permitir que el tráfico de red fluya correctamente en la VPC, use reglas de firewall Crea reglas de firewall para permitir el tráfico web y las verificaciones de estado para el 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 donde el se aplica http-servertag, y desde cualquier fuente que utilice el 0.0.0.0/0rango. Para la regla de verificación de estado, se establecen rangos predeterminados para Google Cloud para permitir que la plataforma verifique correctamente el estado de los recursos. Para permitir el tráfico SSH para la configuración inicial de una imagen de máquina virtual base, alcance la regla de firewall a su entorno usando el --fuente-parámetro de rango. Es posible que deba trabajar con su equipo de red para determinar qué rangos de fuentes usa su organización Reemplazar con sus propios ámbitos de dirección IP: ALCANCE_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 \ -- rangos de origen = ALCANCE_DIRECCIÓN_IP Después de crear las reglas del firewall, verifique que se hayan agregado las tres reglas: lista de reglas de firewall de computación de gcloud \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"El siguiente resultado de ejemplo muestra que las tres reglas se han creado correctamente: NOMBRE RED DIRECCIÓN PRIORIDAD PERMITIR 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 ## Crear y configurar una imagen de máquina virtual base Para crear máquinas virtuales idénticas que implemente sin configuración adicional, use una imagen de máquina virtual personalizada. Esta imagen 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 máquina virtual, crea un básico archivo index.html en el disco persistente y montarlo en /var/www/ejemplo.com. Un archivo de configuración de Apache en /etc/apache2/sites-available/example.com.conf sirve contenido web desde el ubicación del disco persistente montado El siguiente diagrama muestra la página HTML básica proporcionada por Apache que está almacenada en el disco persistente: Usted construye este entorno en los siguientes pasos Crea una máquina virtual base con un disco persistente adjunto: Las instancias informáticas de gcloud crean 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 Utilice los parámetros definidos al comienzo de este documento para nombrar la máquina virtual y conectarse a la subred correcta. Los nombres también se asignan a partir de los parámetros para el disco de arranque y el disco de datos. Para instalar y configurar el sitio web simple, primero conéctese a la máquina virtual base mediante SSH: gcloud compute ssh vm-base-$NOMBRE_SUFIJO --zone=$ZONA En su sesión SSH a la VM, cree un script para configurar la VM en un editor de su elección. El siguiente ejemplo usa Nano como editor: nano configure-vm. Pegue el siguiente script de configuración en el archivo: bin/bash NOMBRE_SUFIJO= app# Crea un directorio para los archivos básicos del sitio web sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # Busque el nombre del disco, luego formatéelo y móntelo DISK_NAME="google-disk-base-$NAME_SUFFIX"DISK_PATHfind /dev/disk/by-id -name DISK_NAME}"| xargs -Ireadlink -fsudo mkfs.ext4 -m 0 - E lazy_itable_init=0,lazy_journal_init=0,descartar $DISK_PATH sudo mount -o descartar,predeterminado $DISK_PATH /var/www/example.com # Instalar Apache sudo apt-get update&& sudo apt-get -y install apache2 # Escriba un archivo HTML básico en el disco persistente sudo tee -a /var/www/example.com/index.html >/dev/null EOF'Ejemplo de HA/DR Bienvenido al sitio web de Compute Engine con conmutación por error en caliente a Cloud Storagep>
*: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 EOF # Habilite el archivo de configuración de Apache y vuelva a cargar el servicio sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2 Actualizar el variable para que coincida con el valor establecido al comienzo de este documento, como Aplicación NAME_SUFFIX Escriba el archivo y salga de su editor. Por ejemplo, en Nano usas Ctrl-Opara escribir el archivo, luego salga con Ctrl-X Haga que el script de configuración sea ejecutable, luego ejecútelo: chmod +x configure-vm../configure-vm. Salga de la sesión SSH a la máquina virtual: salida Obtenga la dirección IP de la VM y use curl para ver la página web básica: curl $(las instancias informáticas de gcloud describen vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP Se devuelve el sitio web básico, como se muestra en el siguiente resultado de ejemplo:Ejemplo de HA/DR Bienvenido al sitio web de Compute Engine con conmutación por error en caliente a Cloud Storagep>
# Cree las imágenes base de VM 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 # Crear plantillas de instancias 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 \ --metadatastartup-script /bin/bashn 'echo\ UUIDblkid\ -s\ UUID\ -o\ valor\ /dev/sdb /var/www/example.com\ ext4\ descartar, por defecto, no falla \ 0\ 2 ee\ -a\ /etc/fstabn'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 \ --metadatastartup-script /bin/bashn'echo\ UUIDblkid\ -s\ UUID\ -o\ value\ /dev/sdb /var/www/example.com\ ext4\ descartar, valores predeterminados ,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount\ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes # Cree una verificación de estado para las instancias de VM gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \ --port 80 # Cree los grupos de instancias administrados gcloud compute instance-groups administrados create instance-group-$NAME_SUFFIX-$REGION1 \ --template=template-$NAME_SUFFIX-$REGION1 \ --size=2 \ --region=$REGION1 \ --health-check=http-basic-check-$NAME_SUFFIX grupos de instancias de cálculo de gcloud administrados crear grupo de instancias -$NOMBRE_SUFIJO-$REGIÓN2 \ --template=plantilla-$NOMBRE_SUFIJO-$REGIÓN2 \ --tamaño=2 \ --región=$REGIÓN2 \ --health-check=http-basic-check-$NOMBRE_SUFIJO ## Crear y configurar un balanceador de carga Para que los usuarios accedan a su sitio web, debe permitir el tráfico a través de las VM que se ejecutan en los grupos de instancias administrados. También desea redirigir automáticamente el tráfico a nuevas máquinas virtuales si hay una falla de zona en un grupo de instancias administrado. En la siguiente sección, crea un balanceador de carga HTTPS externo con un servicio de backend para el tráfico HTTP en el puerto 80, usa la verificación de estado creada en los pasos anteriores y asigna una dirección IP externa al servicio de backend Para obtener más información, consulte Cómo configurar un balanceador de carga HTTP externo simple Cree y configure el balanceador de carga para su aplicación: # Configure las reglas de puerto para el puerto HTTP 80 gcloud compute instance-groups set-named-ports \ instance-group-$NAME_SUFFIX-$REGION1 \ --named-ports http:80 \ --region $REGION1 gcloud compute instance-groups set- puertos-nombrados \ grupo-de-instancias-$NAME_SUFFIX-$REGION2 \ --named-ports http:80 \ --region $REGION2 # Crear un servicio de backend y agregarle los grupos de instancias administrados 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 # Crear un mapa de URL para el servicio de backend gcloud compute url-maps create mapa-web-http-$NOMBRE_SUFIJO \ --default-service web-backend-service-$NAME_SUFFIX # Configurar el reenvío para el tráfico HTTP 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 Obtenga la dirección IP de la regla de reenvío para el tráfico web: IP_ADDRESSgcloud calcula las reglas de reenvío describen http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress Usar curl, o abra su navegador web, para ver el sitio web usando la dirección IP del balanceador de carga del paso anterior: curl $DIRECCIÓN_IP El balanceador de carga tarda unos minutos en terminar de implementarse y en dirigir correctamente el tráfico a su backend. Se devuelve un error HTTP 404 si el balanceador de carga aún se está implementando. Si es necesario, espere unos minutos e intente acceder al sitio web nuevamente Se devuelve el sitio web básico, como se muestra en el siguiente resultado de ejemplo:Ejemplo de HA/DR Bienvenido al sitio web de Compute Engine con conmutación por error en caliente a Cloud Storagep>
<index.html HA / DR example Welcome to a test static web server with warm failover from Cloud Storagep>
example.com Get the details of the Cloud DNS zone: gcloud dns managed-zones describe zone-$NAME_SUFFIX The following example output shows the nameServersfor the zone, such as 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 Cloud DNS must be authoritative for your domain. Create nameserver (NS) records with your domain registrar that point to your Cloud DNS zone. Use the nameserver addresses returned in the previous step For more information and an example using Google Domains, see How to update name servers In your Cloud DNS zone, add a record for wwwusing the load balancer IP address obtained in a previous section: 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 This record directs user requests for the website through the load balancer to the managed instance groups. A TTL of 300 seconds is set to reduce the length of time the cached DNS record exists for a user Create a record to be used by the Cloud Storage bucket for the static website: gcloud dns record-sets transaction add c.storage.googleapis.com. \ --name=static-web.$DOMAIN \ --ttl=300 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX This example uses static-webas the subdomain. Leave the c.storage.googleapis.com.Again, a TTL of 300 seconds is set to reduce the length of time the cached DNS record exists for a user Finally,the DNS record additions to the zone: gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX ## Verify and test the DNS zone and records Let's review the resource deployments before simulating a zone failure. All of the resources have been created to support the environment, as shown in the following image: - Cloud DNS zone records direct users to the load balancer for distribution across the managed instance group VMs - A Cloud Storage bucket is configured to host static web pages if there's an outage with the managed instance groups - The Cloud DNS zone is configured to use the static site in Cloud Storage, but doesn't currently resolve requests to the storage bucket To view the DNS records and test resolution, you must resolve addresses against the Cloud DNS servers. In production deployments, make sure you test and verify the addresses resolve correctly, then update your own DNS servers to resolve appropriately. This document doesn't detail the steps to update your own DNS servers, only how to verify traffic flows correctly under normal and failover conditions Get the details of the Cloud DNS zone again: gcloud dns managed-zones describe zone-$NAME_SUFFIX The following example output shows the nameServersfor the zone, such as 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 To resolve the wwwrecord for your Cloud DNS zone against one of these name servers, use the digcommand: dig @ns-cloud-b1.googledomains.com www.$DOMAIN This example uses the ns-cloud-b1.googledomains.comnameserver address returned from the previous describecommand. Provide your own nameserver address shown in the output of the previous command The following example output shows that the record resolves to the IP address of the load balancer. If you used this nameserver to access the address, such as using curland the --resolveparameter with the Cloud DNS nameserver, the default page would be displayed from one of the managed instance groups behind the load balancer ;DiG [email protected] 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 Use the digcommand again to verify the DNS record for the static website in Cloud Storage: dig @ns-cloud-b1.googledomains.com static-web.$DOMAIN The following example output shows that the record resolves to Cloud Storage that can serve the static content from the storage bucket: ;DiG [email protected] 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 ## Fail over to the Cloud Storage bucket In a production environment, you might get an alert using Cloud Monitoring or other monitoring solution when there's a problem with the managed instance groups. This alert prompts a human to understand the scope of the failure before you update the Cloud DNS records to redirect traffic to the Cloud Storage-hosted static website. An alternative approach is to use your monitoring solution to automatically respond to outages with the managed instance groups When you fail over, Cloud DNS resolves traffic to the Cloud Storage-hosted static website, as shown in the following image: When you or your monitoring solution determine the most appropriate action is to update the Cloud DNS records to direct traffic to Cloud Storage, update the existing DNS A record. In this document, you manually update the Cloud DNS records to redirect traffic to the Cloud Storage-hosted static website To fail over the Cloud DNS records, remove the existing Arecord that resolves to the load balancer: 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 Create a CNAMErecord for wwwthat points to the Cloud Storage-hosted content: gcloud dns record-sets transaction add static-web.$DOMAIN \ --name=www.$DOMAIN. \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX the updates to the Cloud DNS zone: gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX Use the digcommand to confirm the wwwrecord now resolves to the address of the Cloud Storage static website: dig @ns-cloud-b1.googledomains.com www.$DOMAIN The following example output shows that the www.example.comrecord resolves to the CNAME record of the Cloud Storage static website. Requests to access www.example.comare redirected to the Cloud Storage bucket, which displays the static website: ;DiG [email protected] 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 ## Fail back to the managed instance groups After issues with the managed instance groups are resolved, you can fail back to serving content from the load-balanced managed instance groups by updating the Cloud DNS records again. Again, a human might make this decision using Cloud Monitoring insights for the health of the managed instance groups. Or, you could use automation to respond to the restored health of the managed instance group. In this document, you manually update the Cloud DNS records When you fail back, Cloud DNS resolves traffic to the managed instance groups again, as shown in the following image: Remove the wwwCNAME record that redirects traffic to the Cloud Storage-hosted content: 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 Add an Arecord to point to the load balancer in front of the managed instance groups again: gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX the updates to the Cloud DNS zone: gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX Use the digcommand one more time to confirm the wwwrecord resolves to the address of the load balancer in front of the managed instance groups again: dig @ns-cloud-b1.googledomains.com www.$DOMAIN The following example output shows that the record resolves to the IP address of the load balancer and traffic would be served from one of the managed instance groups: ;DiG [email protected] 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 ## Clean up To avoid incurring charges to your Google Cloud account for the resources used in this tutorial, either delete the project that contains the resources, or keep the project and delete the individual resources To delete the individual resources created in this document, complete the following steps: Delete the DNS zone and records: 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 Delete the Cloud Storage bucket: gsutil rm -r gsstatic-web.$DOMAIN Delete the load balancer configuration: 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 Delete the managed instance groups and health check: 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 Delete the instance templates, images, base VM, and persistent disks: 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 Delete the firewall rules 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 Delete the subnet and 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 ## What's next - For an alternative approach that uses external HTTP(S) Load Balancing instead of Cloud DNS to control the failover, see Deploy a warm recoverable web server with Compute Engine and Cloud Storage. This pattern is useful if you don't have, or don't want to use, Cloud DNS - To learn how how to determine the best approach for your own applications and which recovery method to use, see the Disaster recovery planning guide - To see other patterns for applications, such as cold and hot failover, see Disaster recovery scenarios for applications - For more ways to handle scale and availability, see the Patterns for scalable and resilient apps - Explore reference architectures, diagrams, tutorials, and best practices about Google Cloud. Take a look at our Cloud Architecture Center.
Implemente un servidor web recuperable tibio mediante Cloud DNS con Compute Engine y Cloud Storage | Centro de arquitectura en la nube | Google Cloud
Obtenga información sobre cómo usar un patrón de conmutación por error tibio para servidores web que usan Cloud DNS y Compute Engine VM y Cloud Storage.
