ПР. Сбой виртуальной машины
Кратко:
- Статья представляет собой описание практической работы с использованием Yandex Cloud.
- Рассматривается принцип построения отказоустойчивых систем.
- Описывается создание группы виртуальных машин с использованием балансировщика нагрузки.
- Описывается процесс создания и удаления виртуальной машины.
- Описывается процесс восстановления виртуальной машины после удаления.
- Статья содержит инструкции по созданию и управлению виртуальной машиной.
- Статья может быть полезна для тех, кто хочет научиться использовать Yandex Cloud.
Практическая работа. Сбой виртуальной машины
Давайте посмотрим, как принципы построения отказоустойчивых систем реализованы в Yandex Cloud. В практических работах этой темы вы проверите четыре основных сценария отказов:
- сбой виртуальной машины,
- сбой всей зоны доступности,
- обновление приложения
- сбой приложения.
Вы сымитируете эти отказы и понаблюдаете, как Yandex Cloud обеспечивает доступность приложения и восстанавливает инфраструктуру после сбоев.
Начнем с самого простого сценария — сбоя виртуальной машины.
- Создайте группу из трёх ВМ в трёх зонах доступности под балансировщиком нагрузки. Используйте образ с ОС Ubuntu 18.04 (потом мы обновим его на более свежую версию ОС).
Используйте спецификацию
specification.yaml из практической работы по CLI Yandex Cloud, но адаптируйте её для того, чтобы на ней можно было проверить разные сценарии сбоев.Во-первых, будут задействованы все три зоны доступности, поэтому нужно немного исправить блок
allocation_policy:
allocation_policy:
zones:
- zone_id: ru-central1-a
- zone_id: ru-central1-b
- zone_id: ru-central1-d
Также пропишите подсети для каждой зоны (не забывайте подставлять идентификаторы ваших подсетей):
network_interface_specs:
- network_id: <идентификатор_сети>
subnet_ids:
- <идентификатор_подсети_№1>
- <идентификатор_подсети_№2>
- <идентификатор_подсети_№3>
primary_v4_address_spec: { one_to_one_nat_spec: { ip_version: IPV4 }}
Во-вторых, в секции
#cloud-config укажите пользователя, которого нужно создать для входа в виртуальные машины по SSH (это понадобится позднее, на одной из следующих практических работ):
users:
- name: my-user
groups: sudo
lock_passwd: true
sudo: 'ALL=(ALL) NOPASSWD:ALL'
ssh-authorized-keys:
- ssh-rsa AAAAB3Nza...
Создайте группу по новой спецификации:
yc compute instance-group create --file <путь_к_файлу_specification.yaml>
Если ранее вы удаляли балансировщик нагрузки, создайте его снова и привяжите к целевой группе:
yc load-balancer network-load-balancer create \
--region-id ru-central1 \
--name my-load-balancer \
--listener name=my-listener,external-ip-version=ipv4,port=80 \
--target-group target-group-id=<идентификатор_целевой_группы>,healthcheck-name=test-health-check,healthcheck-interval=2s,healthcheck-timeout=1s,healthcheck-unhealthythreshold=2,healthcheck-healthythreshold=2,healthcheck-http-port=80
В консоли управления убедитесь, что ресурсы созданы. Проверьте вывод по внешнему IP-адресу балансировщика — должна отображаться приветственная страница с идентификатором одной из виртуальных машин группы.
- Начните отслеживать состояние виртуальных машин группы и целевой группы балансировщика:
while true; do \ yc compute instance-group \ --id <идентификатор_группы_ВМ> list-instances; \ yc load-balancer network-load-balancer \ --id <идентификатор_балансировщика> target-states \ --target-group-id <идентификатор_целевой_группы>; \ sleep 5; done
Информация выводится в виде таблиц:
- Сбой виртуальной машины может произойти из-за падения физического хоста, на котором она запущена. Иногда виртуальную машину могут удалить случайно, по ошибке. Чтобы сымитировать сбой, удалим одну из виртуальных машин в группе через консоль управления.
Если бы это была единственная машина, на которую поступает трафик, система стала бы недоступна. Но у нас система развернута на нескольких виртуальных машинах, поэтому трафик будет перенаправлен на две оставшиеся. Через несколько секунд будет обнаружена проблема, и виртуальная машина будет выведена из-под балансировки. Об этом говорит статус
UNHEALTHY.- Далее подсеть перейдет в статус
DRAINING— ресурс удаляется, и с него снимается трафик. Балансировщик перестает передавать трафик этому ресурсу.
- После этого Instance Group начнет пересоздавать удалённую виртуальную машину. Процесс восстановления может занять некоторое время. Понаблюдаем за ним.
Сначала новая виртуальная машина появится в группе в статусе
CREATING_INSTANCE.- Далее виртуальная машина будет открыта для трафика (статус
OPEN_TRAFFIC). Балансировщик начнет процесс включения машины в список доступных машин.
- И в завершение подсеть перейдет в статус
HEALTHY, а машина — в статусRUNNING_ACTUAL, и трафик будет снова разделен между тремя машинами.
Обратите внимание! Эту группу виртуальных машин мы будем использовать и в трех следующих практических работах, не удаляйте её. Если вы будете делать большой перерыв между практическими работами, вы можете остановить группу (чтобы не расходовать средства на балансе), а затем запустить её снова.