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

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

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

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

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

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

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

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

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

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

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

Размещение ресурсовРазмещение ресурсов

Для обеспечения отказоустойчивости сервисы должны быть развернуты в нескольких зонах доступности. Оптимальным является размещение в трех зонах, что обеспечивает работу кворумных алгоритмов, используемых в таких сервисах, как управляемые базы данных (MDB) и Managed Service for Kubernetes (mK8s).

Схемы резервированияСхемы резервирования

В зависимости от требований ко времени восстановления после сбоя, существует две основные схемы резервирования:

1. Холодный резерв (Active-Passive):

   • Основная нагрузка обрабатывается в одной зоне;
   • В другой зоне размещается минимальный набор ресурсов (например, реплики БД) для быстрого запуска в случае отказа основной зоны;
   • Простота и более низкая стоимость, так как не требует постоянного дублирования всех ресурсов;
   • Не обеспечивает гарантию непрерывного предоставления сервиса из-за существенного времени переключения на резервную инфраструктуру.

2. Распределение нагрузки (Active-Active):

   • Нагрузка распределяется между несколькими зонами (см. схему далее);
   • Требует адаптации ПО и решения проблемы минимизации сетевых задержек между зонами (например, локализация трафика);
   • Высокая отказоустойчивость и минимальное время восстановления.

   Тема минимизации задержек подробно обсуждается в вебинаре Охотимся на микросекунды: оптимизация работы сервисов в облаке.

Обработка отказовОбработка отказов

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

• Обработчика — элемента, принимающего трафик и распределяющего его между целевыми ресурсами;
• Целевых ресурсов — группы ресурсов, принимающих трафик от обработчика.

Для обеих схем резервирования, рассмотренных выше, минимальное время обработки отказа может быть обеспечено только автоматикой, которая отслеживает состояние целевых ресурсов и перенаправляет запросы пользователей от обработчика только в те целевые ресурсы, которые готовы эти запросы обработать. Готовность целевого ресурса принимать запросы определяется с помощью механизма Health Check. Основная трудность настройки заключается в подборе релевантных значений проверок и корректной реализации проверок готовности на стороне целевого ресурса.

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

Для минимизации времени обработки отказов, особенно в случае отказов API, важно обеспечить запас вычислительных ресурсов в каждой зоне. Это позволит в случае выхода одной зоны доступности из строя использовать мощности оставшихся исправных зон для обслуживания расчетной нагрузки. Рекомендуется иметь запас минимум +50% от расчетной нагрузки по ресурсам в каждой зоне (см. схему ниже).

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

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

  • Сетевой балансировщик нагрузки (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 используются для проверки готовности целевых ресурсов. В настоящее время Network Load Balancer не поддерживает отключение трафика в конкретной зоне.

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

Пример создания отказоустойчивого сайта с балансировкой нагрузки через Network Load Balancer между двумя зонами доступности, защищенный от сбоев в одной зоне.

Балансировщик нагрузки уровня приложения (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 есть возможность ручного отключения доставки клиентского трафика в проблемную зону.

Для снижения времени восстановления работоспособности системы рекомендуется держать ресурсные единицы во всех зонах доступности и резервировать достаточное количество ресурсных единиц в каждой зоне. Это обеспечит запас производительности на случай выхода из строя одной из зон. Указать минимальное количество ресурсных единиц для зоны доступности можно с помощью параметра --min-zone-size.

Для надежной работы механизмов отказоустойчивости необходимо обеспечить Application Load Balancer информацией о зоне доступности, в которой находятся целевые ресурсы. В случае использования механизма интеграции с группами виртуальных машин это делается автоматически, в остальных случаях необходимо указывать идентификатор подсети, в которой размещается целевой ресурс. Подробности см. в документации.

Для достижения минимальных задержек при обработке запросов необходимо обеспечить локализацию трафика: запрос попавший на ресурсную единицу в одной зоне доступности далее должен обрабатываться в той же зоне доступности. Для этого установите в 100% значение параметра локализация трафика (locality_aware_routing_percent) для группы бэкендов. Это включит механизм приоритетной доставки трафика в текущую зону доступности, при этом оставляя возможность передавать запросы в другие зоны доступности, в случае отсутствия доступных целевых ресурсов. Не рекомендуется включать параметр Строгая локализация, так как он останавливает обработку запросов попавших в зону доступности без доступных целевых ресурсов.

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

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

Пример создания отказоустойчивого сайта с балансировкой нагрузки через Application Load Balancer между тремя зонами доступности, защищенный от сбоев в одной зоне.

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

Размещение хостов платформенных сервисов в разных зонах доступности является основным способом достижения отказоустойчивости.

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

Согласно SLA, отказоустойчивой считается конфигурация Кластера БД, состоящего из двух или более Хостов БД, расположенных в различных зонах доступности. Оптимальным является размещение узлов кластера БД в трех зонах доступности, так как для обеспечения отказоустойчивости используются системы на базе кворумных алгоритмов.

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

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

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

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

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

Кластеры Kubernetes, согласно SLA считаются отказоустойчивыми только в том случае, когда Мастер с настройками отказоустойчивости в трех зонах доступности (в каждой зоне по одному хосту).

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

• Разместить рабочие узлы кластера в нескольких зонах доступности;
• Распределить служебные сервисы (например, CoreDNS) и сервисы приложения также по нескольким зонам доступности.

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

• topologySpreadConstraints — для распределения подов по зонам доступности;
• podAntiAffinity — для предотвращения размещения подов на одном узле.

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

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

В случае отказа одной из зон доступности необходимо перераспределить нагрузку на оставшиеся зоны. Если отказоустойчивость организована по принципу Холодный резерв (Active-Passive), время восстановления работоспособности можно сократить за счет автоматизации масштабирования ресурсов.

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

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

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

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

Рекомендации по обеспечению устойчивости к отказам зон:

1. Используйте отдельные группы виртуальных машин для каждой зоны доступности. Не рекомендуется использовать одну группу виртуальных машин для создания виртуальных машин в разных зонах доступности, так как это может затруднить управление при отказе одной из зон.
2. Для масштабирования групп узлов кластера Kubernetes применяется аналогичная механика, основанная на механике групп виртуальных машин.

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

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

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

Как уводить нагрузку из зоны доступностиКак уводить нагрузку из зоны доступности

Для Application Load Balancer существует возможность вручную отключить трафик в конкретной зоне.
Для Network Load Balancer убрать трафик из зоны можно только путем отключения проверок доступности (Health Checks) для целевых ресурсов в проблемной зоне. Это можно сделать одним из следующих способов:

• На уровне инфраструктуры — заблокировать проверки на уровне сетевых групп безопасности;
• Отключить виртуальные машины, которые обрабатывают запросы в проблемной зоне;
• На уровне операционной системы — закрыть доступ к проверкам с помощью межсетевого экрана;
• На уровне приложения — настроить приложение так, чтобы оно не отвечало на проверки доступности.

Рекомендуемый способ — использование сетевых групп безопасности. Для этого необходимо настроить отдельные разрешающие правила для прохождения проверок доступности до целевых ресурсов в каждой зоне доступности. Удаление соответствующего правила позволяет отключить трафик в определенной зоне. Такая конфигурация также позволяет использовать сетевые группы безопасности для тестирования отказоустойчивости.

Остальные способы следует учитывать на случай недоступности API Yandex Cloud.

Тестирование приложения на отказ одной из зон доступностиТестирование приложения на отказ одной из зон доступности

Для оценки отказоустойчивости приложения (способности обрабатывать трафик при отказе одной из зон доступности) можно воспользоваться подготовленным для этого сценарием, в котором веб-приложение развертывается за балансировщиком нагрузки Network Load Balancer и методикой проверки приложения на отказоустойчивость путем отключения определенной части приложения от балансировщика нагрузки.

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

Маркировка NLB для отключения зоны доступностиМаркировка NLB для отключения зоны доступности

Для улучшения качества обработки инцидентов с частичным отказом мы внедряем механизм NLB Zone Shift.

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

Для маркировки балансировщика нагрузки NLB флагом, который допускает отключение одной из зон доступности от балансировщика, необходимо воспользоваться следующей командой YC CLI:

yc load-balancer network-load-balancer update <nlb-id> --allow-zonal-shift

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

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

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

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

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

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

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

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