Цей документ призначений для архітекторів і людей, які працюють у сфері експлуатації та
адміністративні команди. У документі описано приклад шаблону, який можна використовувати
для ваших власних розгортань у Google Cloud.


У цьому шаблоні балансувальник навантаження спрямовує трафік до
Compute Engine
екземпляри в
керовані групи екземплярів
які обслуговують вміст. У разі збою ви оновлюєте
зовнішнє балансування навантаження HTTP(S).
конфігурації та перемикання на статичний сайт у
Хмарне сховище.


Щоб виконати цей підручник, вам потрібне зареєстроване доменне ім’я, яким ви керуєте
і хочете використовувати з цим документом.


У робочих розгортаннях ваш веб-сайт, імовірно, містить набагато більше файлів і
додатковий код програми на віртуальних машинах групи керованих екземплярів
(VM), ніж показано в цьому документі. Потім хмарне сховище розміщує більше
обмежена статична версія, яка забезпечує мінімальну функціональність. У теплому переключенні
сценарії, користувачі бачать цей обмежений веб-сайт, доки не з’являться групи керованих екземплярів
відновити та може обслуговувати трафік для повної роботи веб-сайту.


У цьому підручнику ви розгортаєте ресурси для створення середовища, як показано в
наступне зображення:





Коли вам потрібно виконати відмову, ви оновлюєте конфігурацію балансувальника навантаження до прямої
трафік до Cloud Storage, як показано на наступному зображенні:





Цей теплий шаблон відновлення після відмови врівноважує витрати на роботу іншого керованого
групу екземплярів в іншому регіоні, яку ви використовуєте, лише коли основні регіони
провал. Вартість статичного сайту з використанням Cloud Storage нижча, ніж працюючого
інша керована група екземплярів, але є невелика затримка під час оновлення завантаження
налаштування балансу між параметрами хостингу. Обмежений веб-сайт
досвід використання Хмарного сховища краще, ніж недоступний і поганий веб-сайт
клієнтський досвід.


Для альтернативного підходу, який використовує Cloud DNS замість зовнішнього
Балансування навантаження HTTP(S) для керування відновленням після відмови див
Розгорніть теплий відновлюваний веб-сервер за допомогою Cloud DNS із Compute Engine і Cloud Storage.
Цей шаблон корисний, якщо у вас є або ви хочете використовувати Cloud DNS.


Щоб запускати надійні програми в Google Cloud, ми рекомендуємо розробити
ваша інфраструктура додатків для обробки збоїв. Залежно від вашої програми
і потреби бізнесу, вам може знадобитися холодне або гаряче перемикання після відмови
шаблон відновлення після відмови. Для отримання додаткової інформації про те, як визначити найкращий підхід для
Ваші власні програми див
Керівництво з планування аварійного відновлення.


У цьому документі використовується осн
веб-сервер Apache,
але той самий підхід до розгортання інфраструктури застосовується і до інших
прикладні середовища, які потрібно створити.
## Цілі
 


-

- Створюйте регіональні групи керованих екземплярів із власним образом віртуальної машини.

- Створіть відро Cloud Storage.

- Створення та налаштування зовнішнього балансування навантаження HTTP(S).

— Перевірте відмову гарячого веб-сервера за допомогою оновленого балансувальника навантаження
конфігурація.

- Перевірте відновлення та відновлення після збою за допомогою оновленої конфігурації балансувальника навантаження.

## Витрати
 








 


 

 У цьому посібнику використовуються такі платні компоненти Google Cloud:
 

 


-

- Compute Engine

- Мережа

- Хмарне сховище


 

 
 Щоб створити оцінку вартості на основі прогнозованого використання,
 скористайтеся калькулятором ціноутворення.

## Перед тим як ти почнеш
 





-













-
 
 
 
 Увійдіть у свій обліковий запис Google Cloud. Якщо ви новачок у
 Google Cloud,
 створити обліковий запис, щоб оцінити ефективність наших продуктів
 реальні сценарії. Нові клієнти також отримують 300 доларів США у вигляді безкоштовних кредитів
 запускати, тестувати та розгортати робочі навантаження.
 
 
 
 
 
 

 
 

 
 

 
 
 

 
 










 
 
 

-
 
 

На консолі Google Cloud на сторінці вибору проектів
 виберіть або створіть проект Google Cloud.
 
 
 

 
 
 
 



 
 
 








 

-
 


 Переконайтеся, що виставлення рахунків увімкнено для вашого хмарного проекту. Дізнайтеся, як
 перевірити, чи ввімкнено білінг у проекті.

 
 
 


 
 
 
 











 
 

-
 
 
 


 
 
 
 Увімкніть API Compute Engine.
 
 
 

 



 
 
 
 

 
 









 





 





 

-
 
 Встановіть і ініціалізуйте Google Cloud CLI.

 

 
 
 
 
 
 






 
 
 


-
 
 

На консолі Google Cloud на сторінці вибору проектів
 виберіть або створіть проект Google Cloud.
 
 
 

 
 
 
 



 
 
 








 

-
 


 Переконайтеся, що виставлення рахунків увімкнено для вашого хмарного проекту. Дізнайтеся, як
 перевірити, чи ввімкнено білінг у проекті.

 
 
 


 
 
 
 











 
 

-
 
 
 


 
 
 
 Увімкніть API Compute Engine.
 
 
 

 



 
 
 
 

 
 









 





 





 

-
 
 Встановіть і ініціалізуйте Google Cloud CLI.

 

 
 
 
 
 
 






 
 
 


Ви можете запустити Google Cloud CLI у
консоль без встановлення
Google Cloud CLI. Щоб запустити gcloud CLI у
консолі, використовуйте Cloud Shell

## Підготуйте середовище


У цьому розділі ви визначаєте деякі змінні для імен ваших ресурсів і
локації. Ці змінні використовуються командами Google Cloud CLI, як і ви
розгорнути ресурси.


У цьому документі, якщо не зазначено інше, ви вводите всі команди
Cloud Shell
або ваше місцеве середовище розробки.


-

Замінити


з вашим власним ідентифікатором проекту. При бажанні
надайте власний суфікс імені для ресурсів, щоб допомогти шукати та ідентифікувати
їх, наприклад
PROJECT_ID


додаток
Вкажіть два регіони, наприклад


і

нас-захід1
, а також зону в одному з цих регіонів, наприклад

нас-захід2
. Ця зона визначає, де знаходиться початкова база VM
створюється, який використовується для створення образу для групи керованих екземплярів

us-west1-a
Нарешті, установіть домен, який використовуватиметься для вашого статичного веб-сайту, наприклад




example.com
PROJECT_ID=
PROJECT_ID
NAME_SUFFIX= додаток
РЕГІОН1= сша-захід1
REGION2= us-west2
ЗОНА= us-west1-a
ДОМЕН= example.com
 

## Створіть VPC і підмережу


Щоб забезпечити мережевий доступ до віртуальних машин, ви створюєте віртуальну приватну хмару (VPC)
і підмережі. Оскільки вам потрібні керовані групи екземплярів у двох регіонах, ви створюєте одну
підмережі в кожному регіоні. Для отримання додаткової інформації про переваги звичаю
режим підмережі для керування діапазонами IP-адрес, що використовуються у вашому середовищі, див
Використовуйте власні мережі VPC.


-

Створіть VPC із спеціальним режимом підмережі:

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


Тепер створіть дві підмережі в новому VPC, по одній для кожної
область. Визначте власні діапазони адрес, наприклад


і
10.1.0.0/20
, що
підходить для діапазону вашої мережі:
10.2.0.0/20
gcloud compute networks subnets create n subnet-$NAME_SUFFIX-$REGION1 n --network=network-$NAME_SUFFIX n --range=
10.1.0.0/20n --region=$REGION1

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

## Створення правил брандмауера


Щоб дозволити мережевому трафіку правильно проходити у VPC, використовуйте
правила брандмауера.


-

Створіть правила брандмауера, щоб дозволити веб-трафік і перевірку справності для завантаження
балансувальник і керовані групи екземплярів:



gcloud compute firewall-rules create allow-http-$NAME_SUFFIX n --network=network-$NAME_SUFFIX n --direction=INGRESS n --priority=1000 n --action=ALLOW n --rules=tcp:80 n -- джерело-діапазони=0.0.0.0/0 n --цільові-теги=http-сервер

gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX n --network=network-$NAME_SUFFIX n --action=allow n --direction=ingress n --source-ranges=130.211.0.0/22,35.191. 0,0/16 n --target-tags=allow-health-check n --rules=tcp:80

Правило HTTP дозволяє трафік до будь-якої віртуальної машини, де
застосовано http-servertag,
і з будь-якого джерела за допомогою
0.0.0.0/0 діапазон. Для
правило перевірки стану здоров'я,
діапазони за замовчуванням для Google Cloud налаштовано, щоб дозволити платформі правильно працювати
перевірити справність ресурсів.

Щоб дозволити трафік SSH для початкової конфігурації базового образу віртуальної машини, область
правило брандмауера до вашого середовища за допомогою


--source-rangeparameter.
Можливо, вам знадобиться попрацювати зі своєю мережевою командою, щоб визначити діапазони джерел
використовує ваша організація

Замінити

з вашими власними областями IP-адрес:
IP_ADDRESS_SCOPE
gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX n --network=network-$NAME_SUFFIX n --direction=INGRESS n --priority=1000 n --action=ALLOW n --rules=tcp:22 n -- джерело-діапазони=
IP_ADDRESS_SCOPE
 

Після створення правил брандмауера переконайтеся, що всі три правила виконано
додав:
gcloud compute firewall-rules list n --project=$PROJECT_ID n --filter="NETWORK=network-$NAME_SUFFIX"У наведеному нижче прикладі вихідних даних показано, що три правила були виконані правильно
створено:

НАЗВА НАПРЯМОК МЕРЕЖІ ПРІОРИТЕТ ДОЗВОЛ
enable-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


## Створіть і налаштуйте базовий образ віртуальної машини


Щоб створити ідентичні віртуальні машини, які ви розгортаєте без додаткової конфігурації, ви
використовувати власний образ віртуальної машини. Це зображення фіксує конфігурацію ОС і Apache, а також
використовується для створення кожної віртуальної машини в групі керованих екземплярів у наступних кроках.


На віртуальній машині ви створюєте базову
index.html на постійному диску та
змонтувати його
/var/www/example.com. Файл конфігурації Apache за адресою

/etc/apache2/sites-available/example.com.conf обслуговує веб-вміст із
змонтоване розташування постійного диска

На наступній діаграмі показано збережену базову HTML-сторінку, яку обслуговує Apache
на постійному диску:





Ви створюєте це середовище, виконавши наступні кроки.


-

Створіть базову віртуальну машину з підключеним постійним диском:



екземпляри gcloud compute створюють vm-base-$NAME_SUFFIX n --zone=$ZONE n --machine-type=n1-standard-1 n --subnet=subnet-$NAME_SUFFIX-$REGION1 n --tags=http-server n --image=debian-10-buster-v20210420 n --image-project=debian-cloud n --boot-disk-size=10GB n --boot-disk-type=pd-balanced n --boot-disk- device-name=vm-base-$NAME_SUFFIX n --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX

Ви використовуєте параметри, визначені на початку цього документа, щоб назвати віртуальну машину та
підключитися до правильної підмережі. Імена також призначаються з параметрів для
завантажувальний диск і диск даних.

Щоб установити та налаштувати простий веб-сайт, підключіться до базової віртуальної машини за допомогою
SSH:

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


У вашому сеансі SSH до віртуальної машини створіть сценарій для налаштування віртуальної машини в
редактор на ваш вибір. У наступному прикладі використовується
Нано
як редактор:



nano configure-vm.
Вставте наступний сценарій конфігурації у файл:



bin/bash

NAME_SUFFIX=
додаток

# Створіть каталог для основних файлів веб-сайту
sudo mkdir -p /var/www/example.com
sudo chmod a+w /var/www/example.com
sudo chown -R www-data: /var/www/example.com

# Знайдіть назву диска, відформатуйте та змонтуйте його
DISK_NAME="google-disk-base-$NAME_SUFFIX"DISK_PATHfind /dev/disk/by-id -name DISK_NAME}"| xargs -Ireadlink -f n
sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,відкинути $DISK_PATH
sudo mount -o discard, за замовчуванням $DISK_PATH /var/www/example.com

# Встановити Apache
sudo apt-get update&& sudo apt-get -y встановити apache2

# Записати базовий файл HTML на змонтований постійний диск
sudo tee -a /var/www/example.com/index.html >/dev/null EOF'



 Приклад HA / DR


 
Ласкаво просимо на веб-сайт Compute Engine із теплим переходом після відмови до 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

# Увімкніть файл конфігурації Apache і перезавантажте службу
sudo a2dissite 000-за замовчуванням
sudo a2ensite example.com.conf
sudo systemctl перезавантажити apache2

Оновити
змінна, яка відповідає встановленому значенню
початок цього документа, наприклад

Програма NAME_SUFFIX.

Випишіть файл і вийдіть із редактора. Наприклад, у Nano ви використовуєте

Ctrl-O, щоб виписати файл, а потім вийти за допомогою
Ctrl-X.

Зробіть сценарій налаштування виконуваним, а потім запустіть його:

chmod +x configure-vm../configure-vm.
Вийдіть із сеансу SSH до віртуальної машини:

вихід


Отримайте IP-адресу віртуальної машини та використовуйте

curl, щоб переглянути основну веб-сторінку:


curl $(примірники gcloud compute описують vm-base-$NAME_SUFFIX n --zone $ZONE n --format="value(networkInterfaces.accessConfigs.[0].natIPn)
Повертається основний веб-сайт, як показано в наведеному нижче прикладі вихідних даних:








 Приклад HA / DR


 
Ласкаво просимо на веб-сайт Compute Engine із теплим переходом після відмови до Cloud Storagep>

gcloud compute images create image-disk-$NAME_SUFFIX n --source-disk=disk-base-$NAME_SUFFIX n --source-disk-zone=$ZONE

# Створення шаблонів екземплярів
gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION1 n --machine-type=n1-standard-1 n --subnet=projects/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 n --region=$REGION1 n --tags=http-server n --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 n --image=image-$NAME_SUFFIX n --create-disk=image=image-disk-$NAME_SUFFIX ,auto-delete=так

gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 n --machine-type=n1-standard-1 n --subnet=projects/$PROJECT_ID/regions/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 n --region=$REGION2 n --tags=http-server n --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 n --image=image-$NAME_SUFFIX n --create-disk=image=image-disk-$NAME_SUFFIX ,auto-delete=так

# Створіть перевірку справності для екземплярів віртуальної машини
gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX n --port 80

# Створення керованих груп екземплярів
gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION1 n --template=template-$NAME_SUFFIX-$REGION1 n --size=2 n --region=$REGION1 n --health-check=http- базова перевірка-$NAME_SUFFIX

gcloud compute instance-groups керовано створити групу екземплярів-$NAME_SUFFIX-$REGION2 n --template=template-$NAME_SUFFIX-$REGION2 n --size=2 n --region=$REGION2 n --health-check=http- базова перевірка-$NAME_SUFFIX


## Створіть і налаштуйте балансир навантаження


Щоб користувачі мали доступ до вашого веб-сайту, потрібно дозволити трафік до віртуальних машин
які запускаються в групах керованих екземплярів. Ви також хочете автоматично перенаправляти
трафік до нових віртуальних машин, якщо в керованій групі екземплярів стався збій зони.


У наступному розділі ви створюєте
зовнішній балансир навантаження
із серверною службою для HTTP-трафіку на порту
80, скористайтеся перевіркою справності, створеною на попередніх кроках, і зіставте зовнішню IP-адресу
адресу через серверну службу.


Для отримання додаткової інформації див
Як налаштувати простий зовнішній балансувальник навантаження HTTP.


-

Створіть і налаштуйте балансир навантаження для вашої програми:

# Налаштувати правила порту для порту HTTP 80
gcloud compute instance-groups set-named-ports n instance-group-$NAME_SUFFIX-$REGION1 n --named-ports http:80 n --region $REGION1


gcloud compute instance-groups set-named-ports n instance-group-$NAME_SUFFIX-$REGION2 n --named-ports http:80 n --region $REGION2

# Створіть серверну службу та додайте до неї групи керованих екземплярів
gcloud compute backend-services create n web-backend-service-$NAME_SUFFIX n --protocol=HTTP n --port-name=http n --health-checks=http-basic-check-$NAME_SUFFIX n --global

gcloud compute backend-services add-backend n web-backend-service-$NAME_SUFFIX n --instance-group=instance-group-$NAME_SUFFIX-$REGION1 n --instance-group-region=$REGION1 n --global

gcloud compute backend-services add-backend n web-backend-service-$NAME_SUFFIX n --instance-group=instance-group-$NAME_SUFFIX-$REGION2 n --instance-group-region=$REGION2 n --global

# Створіть карту URL для серверної служби
gcloud compute url-maps create web-map-http-$NAME_SUFFIX n --default-service web-backend-service-$NAME_SUFFIX

# Налаштувати переадресацію для HTTP-трафіку
gcloud compute target-http-proxies create n http-lb-proxy-$NAME_SUFFIX n --url-map web-map-http-$NAME_SUFFIX

gcloud compute forwarding-rules create n http-content-rule-$NAME_SUFFIX n --global n --target-http-proxy=http-lb-proxy-$NAME_SUFFIX n --ports=80


Отримайте IP-адресу правила переадресації для веб-трафіку:

IP_ADDRESSgcloud compute forwarding-rules описують http-content-rule-$NAME_SUFFIX n --global n --format="value(IPAddressn

використання

curl або відкрийте веб-браузер, щоб переглянути веб-сайт за допомогою IP-адреси
адреса балансувальника навантаження з попереднього кроку:


curl $IP_ADDRESS

Потрібно кілька хвилин, щоб балансувальник навантаження завершив розгортання та завершив роботу
правильно спрямовувати трафік на серверну частину. Помилка HTTP 404 повертається, якщо
балансувальник навантаження все ще розгортається. Якщо потрібно, зачекайте кілька хвилин і спробуйте
знову перейдіть на сайт.


Базовий веб-сайт повертається, як показано в наведеному нижче прикладі вихідних даних:




 Приклад HA / DR


 
Ласкаво просимо на веб-сайт Compute Engine із теплим переходом після відмови до Cloud Storagep>

керовані групи екземплярів відновлюються та можуть обслуговувати трафік для повного веб-сайту
досвід.


-

Підтвердьте домен
які ви хочете використовувати з відром Cloud Storage.

Створіть відро хмарного сховища відповідно до імені домену, яким ви володієте
і хочете використовувати:



gsutil mb gsstatic-web.$DOMAIN

The
Використовується змінна DOMAIN, визначена на початку цього документа, наприклад

. У цьому прикладі зберігаються статичні файли за адресою

example.com
static-web.example.com.

Створіть локальний файл, який скопіюйте у відро Cloud Storage у
наступний крок:

cat< index.html




 HA / DR example


 
Welcome to a test static web server with warm failover from Cloud Storagep>





 HA / DR example


 
Welcome to a test static web server with warm failover from Cloud Storagep>


curlagain, or open your web browser, to access the IP address of the
load balancer:


curl $IP_ADDRESS

It might take a few minutes for the load balancer to update the configuration
and to correctly direct traffic back to your managed instance groups. If
needed, wait a few minutes and try to access the website again.


The main website from the managed instance groups is returned, as shown in the
following example output:





 HA / DR example


 p>Welcome to a Compute Engine website with warm failover to Cloud Storagep>




## 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 Cloud Storage bucket:

gsutil rm -r gsstatic-web.$DOMAIN


Delete the load balancer configuration:

gcloud compute forwarding-rules delete n http-content-rule-$NAME_SUFFIX --global --quiet

gcloud compute target-http-proxies delete n http-lb-proxy-$NAME_SUFFIX --quiet

gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet

gcloud compute url-maps delete web-map-http-bucket-$NAME_SUFFIX --quiet

gcloud compute backend-services delete n web-backend-service-$NAME_SUFFIX --global --quiet

gcloud compute backend-buckets delete web-bucket-$NAME_SUFFIX --quiet


Delete the managed instance groups and health check:

gcloud compute instance-groups managed delete n instance-group-$NAME_SUFFIX-$REGION1 n --region=$REGION1 --quiet

gcloud compute instance-groups managed delete n instance-group-$NAME_SUFFIX-$REGION2 n --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 n template-$NAME_SUFFIX-$REGION1 --quiet

gcloud compute instance-templates delete n 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 n --zone=$ZONE --quiet


Delete the firewall rules.

gcloud compute firewall-rules delete n allow-health-check-$NAME_SUFFIX --quiet

gcloud compute firewall-rules delete n allow-ssh-$NAME_SUFFIX --quiet

gcloud compute firewall-rules delete n allow-http-$NAME_SUFFIX --quiet


Delete the subnet and VPC.


gcloud compute networks subnets delete n subnet-$NAME_SUFFIX-$REGION1 --region=$REGION1 --quiet

gcloud compute networks subnets delete n subnet-$NAME_SUFFIX-$REGION2 --region=$REGION2 --quiet

gcloud compute networks delete network-$NAME_SUFFIX --quiet


## What's next
 


- 

- For an alternative approach that uses Cloud DNS instead of external
HTTP(S) Load Balancing to control the failover, see
Deploy a warm recoverable web server using Cloud DNS with Compute Engine and Cloud Storage.
This pattern is useful if you have, or 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.