Рекомендации по отказоустойчивости в Yandex Cloud

Отказоустойчивость — это способность системы продолжать работать при отказе одного или нескольких компонентов.
Отказы могут быть как полными, так и частичными. Частичный отказ является промежуточным состоянием между состоянием исправности и полного отказа и выражается в частичной (неполной) потере способности системы выполнять свои функции. Пример: 50-процентная потеря сетевых пакетов при передаче по каналам связи является частичным отказом.

Далее приведены рекомендации по проектированию отказоустойчивой инфраструктуры в Yandex Cloud.

ВведениеВведение

Инфраструктура Yandex Cloud разделена на регионы и зоны доступности. Зона доступности — это изолированная часть инфраструктуры, которая защищена от сбоев в других зонах. Зоны доступности организованы по территориальному признаку и расположены на расстоянии около 300 км друг от друга.

На данный момент в Yandex Cloud доступны следующие регионы:

• Россия (ru-central1): зоны доступности ru-central1-a, ru-central1-b, ru-central1-d и ru-central1-e;
• Казахстан (kz1): зона доступности kz1-a.

Внутри региона обеспечивается прямая сетевая (IP) связность между зонами доступности, общие API, SLA и единые тарифы на облачные услуги.

Возможные варианты отказов, для которых даются рекомендации по восстановлению в этом документе:

1. Кратковременный (часы) полный или частичный выход одной зоны доступности из строя.
2. Кратковременный частичный отказ API сервисов.

Для построения отказоустойчивых сервисов в Yandex Cloud необходимо учитывать архитектурные особенности платформы: наличие зон доступности и особенности облачных инструментов построения отказоустойчивых систем.

Инструменты обеспечения отказоустойчивостиИнструменты обеспечения отказоустойчивости

• Балансировщики нагрузки:

  • Сетевой балансировщик нагрузки (Network Load Balancer);
  • Балансировщик нагрузки уровня приложения (Application Load Balancer);

• Платформенные сервисы:

  • управляемые базы данных (MDB);
  • Managed Service for Kubernetes в отказоустойчивой конфигурации;

• Нативно отказоустойчивые облачные сервисы:

  • Object Storage;
  • Container Registry;
  • Serverless Functions;
  • Egress NAT;

• Средства автоматического масштабирования:

  • Группы виртуальных машин
  • Группы узлов Kubernetes.

Балансировщики нагрузки (Network Load Balancer, Application Load Balancer)Балансировщики нагрузки (Network Load Balancer, Application Load Balancer)

Сетевой балансировщик нагрузки (Network Load Balancer)Сетевой балансировщик нагрузки (Network Load Balancer)

Основным средством для построения отказоустойчивых решений в Yandex Cloud является сетевой балансировщик нагрузки (Network Load Balancer). Network Load Balancer распределяет TCP-соединения между целевыми ресурсами. Он может быть внешним для обработки трафика из интернета (обработчик с публичным IP-адресом) и внутренним (обработчик с приватным IP-адресом) для обработки внутреннего сетевого трафика. Health Checks используются для проверки готовности целевых ресурсов.

Проверки готовности целевых ресурсов рекомендуется делать достаточно часто, с интервалом не более 3 секунд. Пороги срабатывания проверок должны быть строго больше 1. Для того чтобы проверки не приводили к повышенной нагрузке, на целевых ресурсах, реализация проверок не должна требовать много ресурсов для генерации ответа. Пример плохой практики: использовать в качестве проверки запрос корневой страницы сайта. Пример хорошей практики: отдельный URI для проверки состояния подключений к необходимым ресурсам (например, базам данных) и общей работоспособности.

Балансировщик нагрузки уровня приложения (Application Load Balancer)Балансировщик нагрузки уровня приложения (Application Load Balancer)

Application Load Balancer является более интеллектуальным, но вместе с тем и более затратным инструментом балансировки. Сервис архитектурно представляет собой сетевой балансировщик нагрузки Network Load Balancer, который распределяет сетевой трафик между ресурсными единицами — внутренними виртуальными машинами, выполняющими функции обратных прокси, которые, в свою очередь, распределяют трафик далее между целевыми ресурсами заказчика. В отличие от Network Load Balancer, целевыми ресурсами которого могут быть только сетевые интерфейсы виртуальных машин, Application Load Balancer может распределять трафик на произвольные приватные IP-адреса, например, на IP-адреса за пределами облачной сети, на IP-адреса обработчиков Network Load Balancer и другие.

Рекомендации по организации проверок доступности целевых ресурсов Application Load Balancer такие же, как и для Network Load Balancer.

Дополнительная устойчивость Application Load Balancer к отказам, связанным с вредоносной деятельностью, может быть достигнута с помощью подключения к Application Load Balancer сервисов защиты веб-приложений, таких как Smart Web Security, ARL, WAF, и SmartCaptcha.

Отказоустойчивость платформенных сервисовОтказоустойчивость платформенных сервисов

Высокая доступность управляемых баз данных (MDB)Высокая доступность управляемых баз данных (MDB)

В случае отказа мастера БД автоматика сервиса инициирует переключение на другой хост. В ряде случаев во время отказа автоматика сервиса БД не может инициировать переключение мастера. В такой ситуации переключение необходимо выполнить вручную, например, с помощью команды yc. Пример для кластера PostgreSQL:

yc managed-postgresql cluster start-failover <имя_кластера> --host <имя_хоста>

Для того чтобы клиент имел возможность всегда подключаться к текущему мастеру БД, не обращаясь к API за состоянием кластера, в Yandex Cloud существует механизм особых FQDN. Подключение через особый FQDN упрощает написание приложений, но не гарантирует быстрое переключение на новый мастер в случае его смены. Для быстрого переключения на новый мастер необходима реализация на стороне приложения отслеживания события смены мастера и переподключения к нему.

На текущий момент в Yandex Cloud нет сервиса, который автоматически балансирует читающую нагрузку между узлами кластера БД. Способы такой балансировки подробно обсуждаются на вебинаре Охотимся на микросекунды: оптимизация работы сервисов в облаке.

Отказоустойчивость Managed Service for KubernetesОтказоустойчивость Managed Service for Kubernetes

Для максимальной отказоустойчивости используйте несколько кластеров с балансировкой трафика между ними. Кроме отказоустойчивости, такая конфигурация позволяет обновлять версии кластеров без прерывания работы, решать задачу локализации трафика и проводить A/B тестирование.

Для построения отказоустойчивой инфраструктуры в многокластерной конфигурации необходимо:

• Обеспечить идентичную конфигурацию кластеров и размещенных в них приложений.
• Настроить балансировку запросов между кластерами с помощью Application Load Balancer.

Чтобы минимизировать влияние отказа узлов кластера, необходимо обеспечить равномерное распределение нагрузки. Чтобы предотвратить размещение подов на одном узле, рекомендуется использовать механизм podAntiAffinity.

Для снижения времени недоступности сервиса во время обновлений кластера необходимо настроить политики podDisruptionBudget.

Средства автоматического масштабированияСредства автоматического масштабирования

Основной инструмент масштабирования в Yandex Cloud — это группы виртуальных машин. Группа виртуальных машин включает:

• Шаблон виртуальной машины;
• Политику масштабирования (ручную или автоматическую);
• Механизм масштабирования.

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

Для автоматического масштабирования, помимо базового параметра — нагрузки на CPU, можно использовать любой параметр из Yandex Cloud Monitoring.

Отказоустойчивость клиентских сервисовОтказоустойчивость клиентских сервисов

Для обеспечения отказоустойчивости и скорости отработки отказов приложений в Managed Service for Kubernetes необходимо:

1. Выделить сервису достаточное количество ресурсов (CPU, RAM);
2. Минимизировать или исключить переподписку ресурсов на рабочих узлах кластера Managed Service for Kubernetes, особенно RAM;
3. Настроить корректные Health Checks;
4. Использовать политику повторных попыток (retry policy) к сервисам провайдера;
5. Настроить автомасштабирование рабочих узлов кластера для автоматического перераспределения ресурсов в случае неожиданного повышения нагрузки или отказа одной из зон доступности.

Мониторинг и эскалацияМониторинг и эскалация

Ключевым инструментом обеспечения отказоустойчивости являются мониторинг и система предупреждений (alerts). Помимо базовых средств мониторинга, которые предоставляются вместе с сервисами облака, важно настроить мониторинг бизнес-метрик. Например, отслеживание количества пользователей сервиса за последние минуты позволяет выявить проблемы на высоком уровне, даже если их источник в инфраструктуре не отслеживается.
Для оперативного оповещения о проблемах в дополнение к сервису мониторинга необходимо настроить политику эскалации (в настоящее время находится на стадии Preview).

План действийПлан действий

Для быстрого восстановления сервиса необходимо иметь заранее подготовленные планы действий на случай отказов, такие как ручное переключение мастера БД или отключение зоны доступности.

Тестирование отказоустойчивостиТестирование отказоустойчивости

Любые решения по обеспечению отказоустойчивости требуют регулярного тестирования в различных сценариях отказов. Подробнее о тестировании отказоустойчивости в облаке можно узнать из вебинара: Отключаем ЦОД, или как тестировать отказоустойчивость в облаке.

Смотрите такжеСмотрите также

• Настройка отказоустойчивой архитектуры в Yandex Cloud.
• Высокая доступность кластера Yandex Managed Service for ClickHouse®
• Высокая доступность кластера Yandex MPP Analytics for PostgreSQL
• Высокая доступность кластера Managed Service for Apache Kafka®
• Высокая доступность кластера Managed Service for PostgreSQL.
• Высокая доступность кластера Managed Service for MySQL®.
• Высокая доступность кластера Managed Service for OpenSearch.