Tài liệu này dành cho các kiến ​​trúc sư và những người làm việc trong các nhóm điều hành và hành chính. Tài liệu mô tả một mẫu mẫu mà bạn có thể sử dụng cho các triển khai của riêng mình trong Google Cloud

Trong mẫu này, Cloud DNS hướng lưu lượng truy cập đến các phiên bản Compute Engine trong các nhóm phiên bản được quản lý phục vụ nội dung. Khi ngừng hoạt động, bạn cập nhật vùng Cloud DNS và chuyển sang một trang web tĩnh trong Cloud Storage

Để hoàn thành hướng dẫn này, bạn cần có một tên miền đã đăng ký mà bạn kiểm soát và muốn sử dụng với tài liệu này

Trong các triển khai sản xuất, trang web của bạn có thể bao gồm nhiều tệp và mã ứng dụng bổ sung trên các máy ảo (VM) nhóm phiên bản được quản lý của bạn so với những gì được hiển thị trong tài liệu này. Lưu trữ đám mây sau đó lưu trữ một phiên bản tĩnh hạn chế hơn cung cấp chức năng tối thiểu. Trong trường hợp chuyển đổi dự phòng ấm, người dùng sẽ thấy trang web giới hạn này cho đến khi các nhóm phiên bản được quản lý khôi phục và có thể phân phối lưu lượng truy cập cho trải nghiệm trang web đầy đủ

Trong hướng dẫn này, bạn triển khai các tài nguyên để tạo một môi trường như trong hình sau:
Khi cần chuyển đổi dự phòng, bạn cập nhật cấu hình Cloud DNS để hướng lưu lượng truy cập đến Cloud Storage, như thể hiện trong hình ảnh sau:
Mẫu chuyển đổi dự phòng ấm áp này cân bằng chi phí chạy một nhóm phiên bản được quản lý khác ở một khu vực khác mà bạn chỉ sử dụng khi khu vực chính bị lỗi. Chi phí của một trang web tĩnh sử dụng Cloud Storage thấp hơn so với việc chạy một nhóm phiên bản được quản lý khác, nhưng sẽ có một khoảng thời gian ngắn khi bạn cập nhật Cloud DNS giữa các tùy chọn lưu trữ. Trải nghiệm trang web hạn chế trong Cloud Storage tốt hơn một trang web hoàn toàn không có sẵn và trải nghiệm khách hàng kém

Để biết cách tiếp cận khác sử dụng Cân bằng tải HTTP(S) bên ngoài thay vì Cloud DNS để kiểm soát quá trình chuyển đổi dự phòng, hãy xem Triển khai máy chủ web có thể phục hồi ấm với Compute Engine và Cloud Storage. Mẫu này hữu ích nếu bạn không có hoặc không muốn sử dụng Cloud DNS

Để chạy các ứng dụng đáng tin cậy trong Google Cloud, chúng tôi khuyên bạn nên thiết kế cơ sở hạ tầng ứng dụng của mình để xử lý sự cố ngừng hoạt động. Tùy thuộc vào ứng dụng và nhu cầu kinh doanh của bạn, bạn có thể cần một mẫu chuyển đổi dự phòng nguội, chuyển đổi dự phòng nóng hoặc chuyển đổi dự phòng nóng. Để biết thêm thông tin về cách xác định phương pháp tốt nhất cho các ứng dụng của riêng bạn, hãy xem hướng dẫn Lập kế hoạch khắc phục thảm họa

Tài liệu này sử dụng máy chủ web Apache cơ bản, nhưng cách tiếp cận triển khai cơ sở hạ tầng tương tự áp dụng cho các môi trường ứng dụng khác mà bạn cần tạo

## Mục tiêu

- Tạo các nhóm phiên bản được quản lý theo khu vực với hình ảnh VM tùy chỉnh

- Tạo nhóm Lưu trữ đám mây

- Tạo và định cấu hình vùng Cloud DNS

- Kiểm tra chuyển đổi dự phòng máy chủ web ấm với các bản ghi Cloud DNS được cập nhật

- Kiểm tra khả năng khôi phục và dự phòng với các bản ghi Cloud DNS được cập nhật

## Chi phí
Hướng dẫn này sử dụng các thành phần có thể thanh toán sau của Google Cloud:
Để tạo ước tính chi phí dựa trên mức sử dụng dự kiến ​​của bạn,
sử dụng máy tính giá

## Trước khi bắt đầu
Một số bước trong tài liệu này có thể không hoạt động chính xác nếu tổ chức của bạn áp dụng các ràng buộc cho môi trường Google Cloud của bạn. Trong trường hợp đó, bạn có thể không hoàn thành được các tác vụ như tạo địa chỉ IP công cộng hoặc khóa tài khoản dịch vụ. Nếu bạn đưa ra yêu cầu trả về lỗi về các ràng buộc, hãy xem cách Phát triển ứng dụng trong môi trường Google Cloud bị ràng buộc

- Đăng nhập vào tài khoản Google Cloud của bạn. Nếu bạn mới sử dụng Google Cloud, hãy tạo một tài khoản để đánh giá hiệu quả hoạt động của các sản phẩm của chúng tôi trong các tình huống thực tế. Khách hàng mới cũng nhận được 300 đô la tín dụng miễn phí để chạy, thử nghiệm và triển khai khối lượng công việc

-
Trong bảng điều khiển Google Cloud, trên trang bộ chọn dự án, hãy chọn hoặc tạo một dự án Google Cloud

-
Đảm bảo rằng thanh toán được bật cho dự án Đám mây của bạn. Tìm hiểu cách kiểm tra xem thanh toán có được bật trên một dự án hay không

-
Kích hoạt API Máy tính

- Cài đặt và khởi tạo Google Cloud CLI

-
Trong bảng điều khiển Google Cloud, trên trang bộ chọn dự án, hãy chọn hoặc tạo một dự án Google Cloud

-
Đảm bảo rằng thanh toán được bật cho dự án Đám mây của bạn. Tìm hiểu cách kiểm tra xem thanh toán có được bật trên một dự án hay không

-
Kích hoạt API Máy tính

- Cài đặt và khởi tạo Google Cloud CLI

Bạn có thể chạy Google Cloud CLI trong bảng điều khiển Google Cloud mà không cần cài đặt Google Cloud CLI. Để chạy gcloud CLI trong bảng điều khiển Google Cloud, hãy sử dụng Cloud Shell

## Chuẩn bị môi trường
Trong phần này, bạn xác định một số biến cho tên tài nguyên và vị trí của mình. Các biến này được các lệnh Google Cloud CLI sử dụng khi bạn triển khai tài nguyên

Trong suốt hướng dẫn này, trừ khi có ghi chú khác, bạn nhập tất cả các lệnh trong Cloud Shell hoặc môi trường phát triển cục bộ của bạn

Thay thế
với ID dự án của riêng bạn. Nếu muốn, hãy cung cấp hậu tố tên riêng của bạn cho các tài nguyên để giúp tìm kiếm và xác định chúng, chẳng hạn như
DỰ ÁN_ID


ứng dụng
Chỉ định hai vùng, chẳng hạn như
và
mỹ-tây1
, và một khu vực trong một trong những khu vực đó, chẳng hạn như
chúng tôi-tây2
. Vùng này xác định nơi tạo VM cơ sở ban đầu được sử dụng để tạo hình ảnh cho nhóm phiên bản được quản lý

chúng tôi-tây1-a
Cuối cùng, đặt tên miền được sử dụng cho trang web tĩnh của bạn, chẳng hạn như
ví dụ.com
DỰ ÁN_ID=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## Tạo VPC và mạng con
Để cung cấp quyền truy cập mạng cho máy ảo, bạn tạo Virtual Private Cloud (VPC) và mạng con. Vì bạn cần các nhóm phiên bản được quản lý ở hai khu vực, nên bạn tạo một mạng con ở mỗi khu vực. Để biết thêm thông tin về các ưu điểm của chế độ mạng con tùy chỉnh để quản lý dải địa chỉ IP được sử dụng trong môi trường của bạn, hãy xem Sử dụng mạng VPC ở chế độ tùy chỉnh

Tạo VPC với chế độ mạng con tùy chỉnh:
mạng điện toán gcloud tạo mạng-$NAME_SUFFIX --subnet-mode=custom
Bây giờ hãy tạo hai mạng con trong VPC mới, mỗi mạng con cho một vùng. Xác định phạm vi địa chỉ của riêng bạn, chẳng hạn như
và
10.1.0.0/20
, phù hợp với phạm vi mạng của bạn:
10.2.0.0/20
mạng con mạng điện toán gcloud tạo \ subnet-$NAME_SUFFIX-$REGION1 \ --network=network-$NAME_SUFFIX \ --range=
10.1.0.0/20\ --region=$REGION1 mạng con mạng điện toán gcloud tạo \ subnet-$NAME_SUFFIX-$REGION2 \ --network=network-$NAME_SUFFIX \ --range= 10.2.0.0/20\ --region=$ KHU VỰC2
## Tạo quy tắc tường lửa
Để cho lưu lượng truy cập mạng chính xác trong VPC, hãy sử dụng các quy tắc tường lửa

Tạo các quy tắc tường lửa để cho phép lưu lượng truy cập web và kiểm tra tình trạng cho bộ cân bằng tải và các nhóm phiên bản được quản lý:
quy tắc tường lửa điện toán gcloud tạo 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 tính toán quy tắc tường lửa tạo 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
Quy tắc HTTP cho phép lưu lượng truy cập đến bất kỳ VM nào mà
http-servertag được áp dụng và từ bất kỳ nguồn nào bằng cách sử dụng
0.0.0.0/0phạm vi. Đối với quy tắc kiểm tra tình trạng, phạm vi mặc định cho Google Cloud được đặt để cho phép nền tảng kiểm tra chính xác tình trạng của tài nguyên

Để cho phép lưu lượng SSH cho cấu hình ban đầu của hình ảnh VM cơ sở, hãy đặt quy tắc tường lửa cho môi trường của bạn bằng cách sử dụng
--tham số phạm vi nguồn. Bạn có thể cần làm việc với nhóm mạng của mình để xác định phạm vi nguồn mà tổ chức của bạn sử dụng

Thay thế
với phạm vi địa chỉ IP của riêng bạn:
IP_ADDRESS_SCOPE
quy tắc tường lửa điện toán gcloud tạo allow-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:22 \ -- phạm vi nguồn =
IP_ADDRESS_SCOPE
Sau khi bạn tạo quy tắc tường lửa, hãy xác minh rằng ba quy tắc đã được thêm vào:
danh sách quy tắc tường lửa điện toán gcloud \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"Đầu ra ví dụ sau đây cho thấy ba quy tắc đã được tạo chính xác:
TÊN HƯỚNG MẠNG ƯU TIÊN CHO PHÉP 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
## Tạo và cấu hình ảnh máy ảo cơ sở
Để tạo các máy ảo giống hệt nhau mà bạn triển khai mà không cần cấu hình bổ sung, bạn sử dụng một hình ảnh máy ảo tùy chỉnh. Hình ảnh này ghi lại cấu hình HĐH và Apache và được sử dụng để tạo từng máy ảo trong nhóm phiên bản được quản lý trong các bước tiếp theo

Trên VM, bạn tạo một cơ sở
tệp index.html trên đĩa liên tục và
gắn nó vào
/var/www/example.com. Một tệp cấu hình Apache tại
/etc/apache2/sites-available/example.com.conf phục vụ nội dung web từ
gắn vị trí đĩa liên tục

Sơ đồ sau đây cho thấy trang HTML cơ bản do Apache cung cấp được lưu trữ trên đĩa liên tục:
Bạn xây dựng môi trường này theo các bước sau

Tạo một VM cơ sở với một đĩa liên tục được đính kèm:
các phiên bản điện toán gcloud tạo 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
Bạn sử dụng các tham số được xác định ở phần đầu của tài liệu này để đặt tên cho VM và kết nối với đúng mạng con. Tên cũng được gán từ các tham số cho đĩa khởi động và đĩa dữ liệu

Để cài đặt và định cấu hình trang web đơn giản, trước tiên hãy kết nối với máy ảo cơ sở bằng SSH:
tính toán gcloud ssh vm-base-$NAME_SUFFIX --zone=$ZONE
Trong phiên SSH tới máy ảo của bạn, hãy tạo tập lệnh để định cấu hình máy ảo trong trình chỉnh sửa bạn chọn. Ví dụ sau sử dụng Nano làm trình chỉnh sửa:
cấu hình nano-vm.
Dán tập lệnh cấu hình sau vào tệp:
bin/bash NAME_SUFFIX=
app# Tạo thư mục cho các tệp trang web cơ bản sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # Tìm tên đĩa, sau đó định dạng và gắn nó 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,discard $DISK_PATH Sudo mount -o discard,defaults $DISK_PATH /var/www/example.com # Cài đặt Apache sudo apt-get update&& sudo apt-get -y install apache2 # Viết một tệp HTML cơ bản vào đĩa liên tục được gắn sudo tee -a /var/ www/example.com/index.html >/dev/null EOF'    Ví dụ về HA / DR   
Chào mừng bạn đến với trang web Compute Engine với tính năng chuyển đổi dự phòng ấm áp sang 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 # Bật tệp cấu hình Apache và tải lại dịch vụ sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2
cập nhật các
biến để khớp với giá trị được đặt ở đầu tài liệu này, chẳng hạn như
ứng dụng NAME_SUFFIX

Viết ra tệp và thoát khỏi trình chỉnh sửa của bạn. Ví dụ, trong Nano bạn sử dụng
Ctrl-Ođể ghi ra tệp, sau đó thoát bằng
Ctrl-X

Làm cho tập lệnh cấu hình có thể thực thi được, sau đó chạy nó:
chmod +x configure-vm../configure-vm.
Thoát phiên SSH sang VM:
lối ra
Lấy địa chỉ IP của VM và sử dụng
curlđể xem trang web cơ bản:
curl $(các phiên bản điện toán gcloud mô tả vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP
Trang web cơ bản được trả về, như thể hiện trong đầu ra ví dụ sau:
    Ví dụ về HA / DR   
Chào mừng bạn đến với trang web Compute Engine với tính năng chuyển đổi dự phòng ấm áp sang Cloud Storagep>

# Tạo hình ảnh VM cơ sở Hình ảnh điện toán gcloud tạo hình ảnh-$NAME_SUFFIX \ --source-disk=vm-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE Hình ảnh điện toán gcloud tạo hình ảnh-đĩa-$NAME_SUFFIX \ - -source-disk=disk-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE # Tạo mẫu phiên bản gcloud compute instance-templates tạo mẫu-$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\ value\ /dev/sdb /var/www/example.com\ ext4\ discard,defaults,nofail\ 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\ discard,defaults ,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount\ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes # Tạo kiểm tra tình trạng cho các phiên bản VM kiểm tra sức khỏe điện toán gcloud tạo http http http-basic-check-$NAME_SUFFIX \ --port 80 # Tạo các nhóm phiên bản được quản lý gcloud compute instance-groups Managed tạo instance-group-$NAME_SUFFIX-$REGION1 \ --template=template-$NAME_SUFFIX-$REGION1 \ --size=2 \ --region=$REGION1 \ --health-check=http-basic-check-$NAME_SUFFIX nhóm phiên bản điện toán gcloud được quản lý tạo nhóm phiên bản -$NAME_SUFFIX-$REGION2 \ --template=template-$NAME_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
## Tạo và định cấu hình bộ cân bằng tải
Để người dùng truy cập trang web của bạn, bạn cần cho phép lưu lượng truy cập đến các máy ảo chạy trong các nhóm phiên bản được quản lý. Bạn cũng muốn tự động chuyển hướng lưu lượng truy cập sang máy ảo mới nếu xảy ra lỗi vùng trong nhóm phiên bản được quản lý

Trong phần sau, bạn tạo bộ cân bằng tải HTTPS bên ngoài với dịch vụ phụ trợ cho lưu lượng HTTP trên cổng 80, sử dụng kiểm tra tình trạng được tạo ở các bước trước và ánh xạ địa chỉ IP bên ngoài tới dịch vụ phụ trợ

Để biết thêm thông tin, hãy xem Cách thiết lập bộ cân bằng tải HTTP bên ngoài đơn giản

Tạo và định cấu hình bộ cân bằng tải cho ứng dụng của bạn:
# Định cấu hình quy tắc cổng cho cổng HTTP 80 nhóm cá thể điện toán gcloud set-named-ports \ instance-group-$NAME_SUFFIX-$REGION1 \ --named-ports http:80 \ --region $REGION1 bộ nhóm cá thể điện toán gcloud- tên-cổng \ instance-group-$NAME_SUFFIX-$REGION2 \ --named-ports http:80 \ --region $REGION2 # Tạo một dịch vụ phụ trợ và thêm các nhóm cá thể được quản lý vào dịch vụ đó tạo dịch vụ phụ trợ điện toán gcloud \ web- dịch vụ phụ trợ-$NAME_SUFFIX \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check-$NAME_SUFFIX \ --global tính toán gcloud phụ trợ phần bổ sung phụ trợ của dịch vụ phụ trợ \ web- dịch vụ phụ trợ-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION1 \ --instance-group-region=$REGION1 \ --global gcloud compute dịch vụ phụ trợ phần bổ trợ phụ trợ \ web-backend- service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \ --instance-group-region=$REGION2 \ --global # Tạo bản đồ URL cho dịch vụ phụ trợ tạo bản đồ url điện toán gcloud bản đồ web-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # Định cấu hình chuyển tiếp cho lưu lượng HTTP gcloud compute đích-http-proxies tạo \ http-lb-proxy-$NAME_SUFFIX \ --url-map web-map-http- $NAME_SUFFIX quy tắc chuyển tiếp điện toán gcloud tạo \ http-content-rule-$NAME_SUFFIX \ --global \ --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \ --ports=80
Nhận địa chỉ IP của quy tắc chuyển tiếp cho lưu lượng truy cập web:
IP_ADDRESSgquy tắc chuyển tiếp điện toán đám mây mô tả http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress
Sử dụng
cuộn tròn hoặc mở trình duyệt web của bạn để xem trang web bằng địa chỉ IP của bộ cân bằng tải từ bước trước:
cuộn tròn $IP_ADDRESS
Phải mất vài phút để bộ cân bằng tải triển khai xong và hướng lưu lượng truy cập chính xác đến chương trình phụ trợ của bạn. Lỗi HTTP 404 được trả về nếu bộ cân bằng tải vẫn đang triển khai. Nếu cần, hãy đợi vài phút và thử truy cập lại trang web

Trang web cơ bản được trả về, như thể hiện trong đầu ra ví dụ sau:
    Ví dụ về HA / DR   
Chào mừng bạn đến với trang web Compute Engine với tính năng chuyển đổi dự phòng ấm áp sang 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.