Подключиться
Сценарии использования

Настройка отказоустойчивой архитектуры в Yandex.Cloud

Статья создана

С помощью этой инструкции вы настроите отказоустойчивую архитектуру в Yandex.Cloud и проверите ее работу на различных тестовых сценариях.

Отказоустойчивость — это свойство системы сохранять свою работоспособность после отказа одной или нескольких ее составных частей.

Чтобы настроить и протестировать архитектуру:

  1. Подготовьте облако к работе.
  2. Настройте тестовый стенд:
  3. Выполните тестовые сценарии:

Если созданные ресурсы вам больше не нужны, удалите их.

Подготовьте облако к работе

Перед тем, как разворачивать сервер, нужно зарегистрироваться в Yandex.Cloud и создать платежный аккаунт:

  1. Перейдите в консоль управления, затем войдите в Yandex.Cloud или зарегистрируйтесь, если вы еще не зарегистрированы.
  2. На странице биллинга убедитесь, что у вас подключен платежный аккаунт, и он находится в статусе ACTIVE или TRIAL_ACTIVE. Если платежного аккаунта нет, создайте его.

Если у вас есть активный платежный аккаунт, вы можете создать или выбрать каталог, в котором будет работать ваша виртуальная машина, на странице облака.

Подробнее об облаках и каталогах.

В стоимость поддержки отказоустойчивой архитектуры Yandex.Cloud входит:

Настройте тестовый стенд

Описание тестового стенда

Описание тестового стенда:

  • Приложение упаковано в Docker-образ и загружено в Container Registry.

    Docker-образы развернуты на четырех виртуальных машинах на основе Container Optimized Image. Машины объединены в группу и расположены в двух различных зонах доступности.

  • Кластер баз данных работает под управлением сервиса Managed Service for PostgreSQL и состоит из двух хостов, расположенных в различных зонах доступности.

  • Нагрузка генерируется приложением Яндекс.Танк и подается на Network Load Balancer. Сетевой балансировщик нагрузки распределяет трафик по виртуальным машинам.

Подготовьте контейнеры приложения TodoList

Чтобы подготовить приложение для запуска в Yandex.Cloud:

  1. Аутентифицируйтесь в Container Registry:

    yc container registry configure-docker

  2. Создайте реестр:

    yc container registry create --name todo-registry

  3. Соберите Docker-образ с тегом v1:

    docker build . --tag cr.yandex/<registry_id>/todo-demo:v1

  4. Соберите Docker-образ с тегом v2 (для проверки сценария обновления приложения):

    docker build . --build-arg COLOR_SCHEME=dark --tag cr.yandex/<registry_id>/todo-demo:v2

  5. Загрузите Docker-образы в Container Registry:

    docker push cr.yandex/<registry_id>/todo-demo:v1
docker push cr.yandex/<registry_id>/todo-demo:v2

Разверните инфраструктуру

Чтобы подготовить окружение для запуска приложения в Yandex.Cloud:

  1. Установите terraform.

  2. Скачайте репозиторий с исходным кодом демо-приложения, terraform-спецификациями и скриптом для имитации сбоя приложения.

  3. Перейдите в директорию со спецификацией окружения:

    cd app

  4. Инициализируйте Terraform в директории со спецификацией:

    terraform init

  5. В файле app/todo-service.tf укажите путь к публичному SSH-ключу (значение по умолчанию ~/.ssh/id_rsa.pub).

  6. Разверните и запустите приложение:

    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 и разверните инфраструктуру.

  1. Перейдите в директорию со спецификацией Танка:

    cd tank

  2. Инициализируйте Terraform в директории со спецификацией Танка:

    terraform init

  3. В файле tank/main.tf укажите путь к публичному и приватному SSH-ключам (значения по умолчанию ~/.ssh/id_rsa.pub и ~/.ssh/id_rsa).

  4. Разверните и запустите ВМ:

    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.

  5. Подключитесь к созданной ВМ по SSH. Адрес для подключения указан в выводе команды terraform apply.

  6. Запустите Танк:

    sudo yandex-tank -c load.yaml

  7. Перейдите в <overload.yandex.net> и найдите там запущенную стрельбу: Public tests -> show my tests only.

Выполнение сценариев

Сбой ВМ

Как проявляется сбой: недоступна виртуальная машина с приложением.

Возможные причины:

  • Падение физического хоста, на котором была запущена ВМ.
  • По ошибке удалена ВМ с приложением.

Для имитации сбоя удалите одну из виртуальных машин группы.

Реакция тестового стенда:

  1. Сетевой балансировщик нагрузки и Instance Groups получают информацию о сбое машины и выводят ее из балансировки — трафик перестает поступать на эту машину и распределяется между оставшимися ВМ в группе.
  2. Instance Groups автоматически восстанавливается:
    1. Удаляет недоступную машину (в этом сценарии машина уже удалена, шаг будет пропущен).
    2. Создает новую машину.
    3. Ожидает запуска приложения на созданной машине.
    4. Добавляет машину в балансировку.

Балансировщику нагрузки и 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.

Реакция тестового стенда:

  1. Instance Groups получает информацию о сбое приложения и выводит машину из балансировки — трафик перестает поступать на эту машину и распределяется между оставшимися ВМ в группе.
  2. Instance Groups автоматически восстанавливается:
    1. Перезагружает неисправную машину.
    2. Ожидает запуска приложения на созданной машине.
    3. Добавляет машину в балансировку.

Instance Groups несколько раз опрашивает машину прежде чем отключить трафик и запустить восстановление. Из-за этого возможно появление ошибок Service Unavailable (HTTP-код 503 на графиках Quantities и HTTP codes в мониторинге Танка).

После выведения неисправной машины из балансировки пользовательская нагрузка обрабатывается корректно.

Отключение зоны доступности

Как проявляется сбой: недоступны несколько виртуальных машин в одной зоне.

Возможные причины:

  • Перебои в работе дата-центра.
  • Плановые технические работы в дата-центре.

Чтобы перенести ресурсы в другой дата-центр:

  1. В консоли управления выберите каталог с вашей группой виртуальных машин.
  2. В списке сервисов выберите Compute Cloud.
  3. Нажмите Группы виртуальных машин.
  4. Выберите группу todo-ig.
  5. Нажмите кнопку Изменить.
  6. В блоке Распределение снимите галочку с зоны доступности ru-central1-с.
  7. Нажмите кнопку Сохранить изменения.

Реакция тестового стенда:

  1. Instance Groups выводит из балансировки машины в зоне доступности ru-central1-с.
  2. Выведенные машины удаляются, одновременно с этим создаются машины в зоне ru-central1-b.
  3. Instance Groups добавляет созданные машины в балансировку.

Количество одновременно создаваемых и удаляемых машин определяется политикой развертывания.

Во время выведения машин из балансировки возможно появление ошибок Connection Timeout (HTTP-код 0 на графиках Quantities и HTTP codes в мониторинге Танка).

После выведения машин из балансировки пользовательская нагрузка обрабатывается корректно.

Обновление приложения

Чтобы обновить приложение:

  1. В консоли управления выберите каталог с вашей Группой виртуальных машин.
  2. В списке сервисов выберите Compute Cloud.
  3. Нажмите Группы виртуальных машин.
  4. Выберите группу todo-ig.
  5. Нажмите кнопку Изменить.
  6. В блоке Шаблон виртуальной машины нажмите и выберите Изменить.
  7. На вкладке Container Solution выберите необходимый Docker-контейнер.
  8. В открывшемся окне в поле Docker-образ укажите имя Docker-образа с новой версией приложения.
  9. Нажмите кнопку Применить.
  10. Нажмите кнопку Сохранить.
  11. Нажмите кнопку Сохранить изменения.

Реакция тестового стенда:

  1. Instance Groups выводит из балансировки две машины с устаревшей версией приложения (статус таких машин RUNNING_OUTDATED).
  2. Удаляет выведенные машины, одновременно с этим создает машины с новой версией приложения.
  3. Добавляет созданные машины в балансировку.
  4. Действия повторяются для оставшихся двух машин с устаревшей версией приложения.

Обновите страницу приложения. Если сетевой балансировщик отправит ваш запрос на уже обновленную машину, то вы увидите версию приложения с темной цветовой схемой.

Количество одновременно создаваемых и удаляемых машин определяется политикой развертывания.

Во время выведения машин из балансировки возможно появление ошибок Connection Timeout (HTTP-код 0 на графиках Quantities и HTTP codes в мониторинге Танка).

После выведения машин из балансировки пользовательская нагрузка обрабатывается корректно.

Масштабирование конфигурации БД

Масштабирование БД может потребоваться, если:

  • Производительности хостов в кластере не хватает для обработки запросов.
  • Для данных требуется хранилище большего объема.

Чтобы масштабировать конфигурацию:

  1. В консоли управления выберите каталог с вашим кластером БД.
  2. В списке сервисов выберите Managed Service for PostgreSQL.
  3. Выберите кластер todo-postgresql.
  4. Нажмите Изменить кластер.
  5. В блоке Класс хоста выберите s2.medium.
  6. Нажмите кнопку Сохранить изменения.

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
В этой статье: