Настройка отказоустойчивой архитектуры в Yandex.Cloud
С помощью этой инструкции вы настроите отказоустойчивую архитектуру в Yandex.Cloud и проверите ее работу на различных тестовых сценариях.
Отказоустойчивость — это свойство системы сохранять свою работоспособность после отказа одной или нескольких ее составных частей.
Чтобы настроить и протестировать архитектуру:
Если созданные ресурсы вам больше не нужны, удалите их.
Подготовьте облако к работе
Перед тем, как разворачивать сервер, нужно зарегистрироваться в Yandex.Cloud и создать платежный аккаунт:
- Перейдите в консоль управления, затем войдите в Yandex.Cloud или зарегистрируйтесь, если вы еще не зарегистрированы.
- На странице биллинга убедитесь, что у вас подключен платежный аккаунт, и он находится в статусе
ACTIVE
илиTRIAL_ACTIVE
. Если платежного аккаунта нет, создайте его.
Если у вас есть активный платежный аккаунт, вы можете создать или выбрать каталог, в котором будет работать ваша виртуальная машина, на странице облака.
Подробнее об облаках и каталогах.
Необходимые платные ресурсы
В стоимость поддержки отказоустойчивой архитектуры Yandex.Cloud входит:
- Плата за диски и постоянно запущенные виртуальные машины (см. тарифы Yandex Compute Cloud).
- Плата за постоянно запущенный кластер Managed Service for PostgreSQL (см. тарифы Yandex Managed Service for PostgreSQL).
- Плата за использование динамического или статического внешнего IP-адреса (см. тарифы Yandex Virtual Private Cloud).
Настройте тестовый стенд
Описание тестового стенда
Описание тестового стенда:
-
Приложение упаковано в Docker-образ и загружено в Container Registry.
Docker-образы развернуты на четырех виртуальных машинах на основе Container Optimized Image. Машины объединены в группу и расположены в двух различных зонах доступности.
-
Кластер баз данных работает под управлением сервиса Managed Service for PostgreSQL и состоит из двух хостов, расположенных в различных зонах доступности.
-
Нагрузка генерируется приложением Яндекс.Танк и подается на Load Balancer. Балансировщик нагрузки распределяет трафик по виртуальным машинам.
Подготовьте контейнеры приложения TodoList
Чтобы подготовить приложение для запуска в Yandex.Cloud:
-
Аутентифицируйтесь в Container Registry:
yc container registry configure-docker
-
Создайте реестр:
yc container registry create --name todo-registry
-
Соберите Docker-образ с тегом
v1
:docker build . --tag cr.yandex/<registry_id>/todo-demo:v1
-
Соберите Docker-образ с тегом
v2
(для проверки сценария обновления приложения):docker build . --build-arg COLOR_SCHEME=dark --tag cr.yandex/<registry_id>/todo-demo:v2
-
Загрузите Docker-образы в Container Registry:
docker push cr.yandex/<registry_id>/todo-demo:v1 docker push cr.yandex/<registry_id>/todo-demo:v2
Разверните инфраструктуру
Чтобы подготовить окружение для запуска приложения в Yandex.Cloud:
-
Установите terraform.
-
Скачайте репозиторий с исходным кодом демо-приложения, terraform-спецификациями и скриптом для имитации сбоя приложения.
-
Перейдите в директорию со спецификацией окружения:
cd app
-
Инициализируйте Terraform в директории со спецификацией:
terraform init
-
В файле
app/todo-service.tf
укажите путь к публичному SSH-ключу (значение по умолчанию~/.ssh/id_rsa.pub
). -
Разверните и запустите приложение:
terraform apply -var yc_folder=<folder_id> -var yc_token=<yc_token> -var user=$USER
Где:
folder_id
— каталог, в котором будет развернуто приложение.yc_token
— OAuth-токен пользователя, от имени которого будет развернуто приложение.
Будут созданы следующие ресурсы:
- Сеть VPC с тремя подсетями во всех зонах доступности.
- Два сервисных аккаунта:
- Сервисный аккаунт для управления группой ВМ с ролью
editor
. - Сервисный аккаунт для скачивания Docker-образа на ВМ с ролью
container-registry.images.puller
.
- Сервисный аккаунт для управления группой ВМ с ролью
- Группа ВМ из четырех виртуальных машин на базе Container Optimized Image в зонах доступности
ru-central1-b
иru-central1-c
. - Кластер Managed Service for PostgreSQL с двумя хостами в зонах доступности
ru-central1-b
иru-central1-c
. - Балансировщик нагрузки для распределения трафика по машинам группы ВМ.
Для доступа к приложению перейдите по адресу lb_address
, полученному в результате выполнения terraform apply
.
Подготовьте и запустите приложение Яндекс.Танк
Важно
Перед созданием Танка подготовьте контейнеры приложения TodoList и разверните инфраструктуру.
-
Перейдите в директорию со спецификацией Танка:
cd tank
-
Инициализируйте Terraform в директории со спецификацией Танка:
terraform init
-
В файле
tank/main.tf
укажите путь к публичному и приватному SSH-ключам (значения по умолчанию~/.ssh/id_rsa.pub
и~/.ssh/id_rsa
). -
Разверните и запустите ВМ:
terraform apply -var yc_folder=<folder_id> -var yc_token=<yc_token> -var user=$USER -var overload_token=<overload_token>
Где:
folder_id
— каталог, в котором будет развернут Танк.yc_token
- OAuth-токен пользователя, от имени которого будет развернут Танк.overload_token
— токен для подключения к<overload.yandex.net>
. Для получения токена надо аутентифицироваться, после чего нажать справа вверху на свой профиль и в выпадающем меню выбрать My api token.
-
Подключитесь к созданной ВМ по SSH. Адрес для подключения указан в выводе команды
terraform apply
. -
Запустите Танк:
sudo yandex-tank -c load.yaml
-
Перейдите в
<overload.yandex.net>
и найдите там запущенную стрельбу: Public tests -> show my tests only.
Выполнение сценариев
Сбой ВМ
Как проявляется сбой: недоступна виртуальная машина с приложением.
Возможные причины:
- Падение физического хоста, на котором была запущена ВМ.
- По ошибке удалена ВМ с приложением.
Для имитации сбоя удалите одну из виртуальных машин группы.
Реакция тестового стенда:
- Балансировщик нагрузки и Instance Groups получают информацию о сбое машины и выводят ее из балансировки — трафик перестает поступать на эту машину и распределяется между оставшимися ВМ в группе.
- Instance Groups автоматически восстанавливается:
- Удаляет недоступную машину (в этом сценарии машина уже удалена, шаг будет пропущен).
- Создает новую машину.
- Ожидает запуска приложения на созданной машине.
- Добавляет машину в балансировку.
Балансировщику нагрузки и Instance Groups требуется некоторое время, чтобы обнаружить проблему и отключить подачу трафика на неисправную машину. Из-за этого возможно появление ошибок Connection Timeout (HTTP-код 0
на графиках Quantities и HTTP codes в мониторинге Танка).
После выведения недоступной машины из балансировки пользовательская нагрузка обрабатывается корректно.
Сбой приложения
Как проявляется сбой: приложение не отвечает вовремя или работает некорректно с точки зрения пользователя.
Возможные причины:
- Утечка памяти привела к падению приложения.
- Приложение не может продолжить работу из-за потери связности с БД.
- Приложение не успевает обрабатывать запросы из-за большой нагрузки.
В соответствии с настройками проверки состояния Instance Groups опрашивает машины группы по HTTP-протоколу. При нормальной работе обращение к конечной точке /healthy
возвращается HTTP-код 200
. Иначе Instance Groups запускает процедуру восстановления.
Для имитации сбоя запустите скрипт:
fail_random_host.sh <group_id>
Случайная машина из группы начнет возвращать HTTP-код 503
.
Реакция тестового стенда:
- Instance Groups получает информацию о сбое приложения и выводит машину из балансировки — трафик перестает поступать на эту машину и распределяется между оставшимися ВМ в группе.
- Instance Groups автоматически восстанавливается:
- Перезагружает неисправную машину.
- Ожидает запуска приложения на созданной машине.
- Добавляет машину в балансировку.
Instance Groups несколько раз опрашивает машину прежде чем отключить трафик и запустить восстановление. Из-за этого возможно появление ошибок Service Unavailable (HTTP-код 503
на графиках Quantities и HTTP codes в мониторинге Танка).
После выведения неисправной машины из балансировки пользовательская нагрузка обрабатывается корректно.
Отключение зоны доступности
Как проявляется сбой: недоступны несколько виртуальных машин в одной зоне.
Возможные причины:
- Перебои в работе дата-центра.
- Плановые технические работы в дата-центре.
Чтобы перенести ресурсы в другой дата-центр:
- В консоли управления выберите каталог с вашей группой виртуальных машин.
- В списке сервисов выберите Compute Cloud.
- Нажмите Группы виртуальных машин.
- Выберите группу
todo-ig
. - Нажмите кнопку Изменить.
- В блоке Распределение снимите галочку с зоны доступности
ru-central1-с
. - Нажмите кнопку Сохранить изменения.
Реакция тестового стенда:
- Instance Groups выводит из балансировки машины в зоне доступности
ru-central1-с
. - Выведенные машины удаляются, одновременно с этим создаются машины в зоне
ru-central1-b
. - Instance Groups добавляет созданные машины в балансировку.
Количество одновременно создаваемых и удаляемых машин определяется политикой развертывания.
Во время выведения машин из балансировки возможно появление ошибок Connection Timeout (HTTP-код 0
на графиках Quantities и HTTP codes в мониторинге Танка).
После выведения машин из балансировки пользовательская нагрузка обрабатывается корректно.
Обновление приложения
Чтобы обновить приложение:
- В консоли управления выберите каталог с вашей Группой виртуальных машин.
- В списке сервисов выберите Compute Cloud.
- Нажмите Группы виртуальных машин.
- Выберите группу
todo-ig
. - Нажмите кнопку Изменить.
- В блоке Шаблон виртуальной машины нажмите и выберите Изменить.
- На вкладке Container Solution выберите необходимый Docker-контейнер.
- В открывшемся окне в поле Docker-образ укажите имя Docker-образа с новой версией приложения.
- Нажмите кнопку Применить.
- Нажмите кнопку Сохранить.
- Нажмите кнопку Сохранить изменения.
Реакция тестового стенда:
- Instance Groups выводит из балансировки две машины с устаревшей версией приложения (статус таких машин
RUNNING_OUTDATED
). - Удаляет выведенные машины, одновременно с этим создает машины с новой версией приложения.
- Добавляет созданные машины в балансировку.
- Действия повторяются для оставшихся двух машин с устаревшей версией приложения.
Обновите страницу приложения. Если балансировщик отправит ваш запрос на уже обновленную машину, то вы увидите версию приложения с темной цветовой схемой.
Количество одновременно создаваемых и удаляемых машин определяется политикой развертывания.
Во время выведения машин из балансировки возможно появление ошибок Connection Timeout (HTTP-код 0
на графиках Quantities и HTTP codes в мониторинге Танка).
После выведения машин из балансировки пользовательская нагрузка обрабатывается корректно.
Масштабирование конфигурации БД
Масштабирование БД может потребоваться, если:
- Производительности хостов в кластере не хватает для обработки запросов.
- Для данных требуется хранилище большего объема.
Чтобы масштабировать конфигурацию:
- В консоли управления выберите каталог с вашим кластером БД.
- В списке сервисов выберите Managed Service for PostgreSQL.
- Выберите кластер
todo-postgresql
. - Нажмите Изменить кластер.
- В блоке Класс хоста выберите s2.medium.
- Нажмите кнопку Сохранить изменения.
Managed Service for PostgreSQL запустит операцию изменения кластера.
При переключении между мастером и репликой (в начале и в конце процесса изменения) возможно появление ошибок Internal Server Error (HTTP-код 500
на графиках Quantities и HTTP codes в мониторинге Танка).
После переключения пользовательская нагрузка обрабатывается корректно.
Удаление приложений и окружения
Важно
Если создана ВМ с Танком, необходимо сначала удалить ее, иначе удаление VPC завершится с ошибкой.
Чтобы удалить приложение Танк, перейдите в каталог tank
и выполните следующую команду:
terraform destroy -var yc_folder=<folder_id> -var yc_token=<yc_token> -var user=$USER -var overload_token=not-used
Чтобы удалить приложение TodoList, перейдите в каталог app
и выполните следующую команду:
terraform destroy -var yc_folder=<folder_id> -var yc_token=<yc_token> -var user=$USER