[Документация Yandex Cloud](../index.md) > [Архитектурные решения](index.md) > Отказоустойчивость > Рекомендации по отказоустойчивости в Yandex Cloud # Рекомендации по отказоустойчивости в Yandex Cloud Отказоустойчивость — это способность системы продолжать работать при отказе одного или нескольких компонентов. Отказы могут быть как полными, так и частичными. Частичный отказ является промежуточным состоянием между состоянием исправности и полного отказа и выражается в частичной (неполной) потере способности системы выполнять свои функции. Пример: 50-процентная потеря сетевых пакетов при передаче по каналам связи является частичным отказом. Далее приведены рекомендации по проектированию отказоустойчивой инфраструктуры в Yandex Cloud. ## Введение {#introduction} Инфраструктура Yandex Cloud разделена на [регионы](../overview/concepts/region.md) и [зоны доступности](../overview/concepts/geo-scope.md). Зона доступности — это изолированная часть инфраструктуры, которая защищена от сбоев в других зонах. Зоны доступности организованы по территориальному признаку и расположены на расстоянии около 300 км друг от друга. На данный момент в Yandex Cloud доступны следующие регионы: * **Россия** (ru-central1): зоны доступности `ru-central1-a`, `ru-central1-b`, `ru-central1-d` и `ru-central1-e`; * **Казахстан** (kz1): зона доступности `kz1-a`. Внутри региона обеспечивается прямая сетевая (IP) связность между зонами доступности, общие [API](../overview/api.md), [SLA](../overview/sla.md) и единые [тарифы](https://yandex.cloud/ru-kz/prices) на облачные услуги. Возможные варианты отказов, для которых даются рекомендации по восстановлению в этом документе: 1. Кратковременный (часы) полный или частичный выход **одной** зоны доступности из строя. 1. Кратковременный частичный отказ API сервисов. Для построения отказоустойчивых сервисов в Yandex Cloud необходимо учитывать архитектурные особенности платформы: наличие зон доступности и особенности облачных инструментов построения отказоустойчивых систем. ## Инструменты обеспечения отказоустойчивости {#ha-tools} * Балансировщики нагрузки: * [Сетевой балансировщик нагрузки (Network Load Balancer)](../network-load-balancer/concepts/index.md); * [Балансировщик нагрузки уровня приложения (Application Load Balancer)](../application-load-balancer/concepts/index.md); * Платформенные сервисы: * управляемые базы данных (MDB); * [Managed Service for Kubernetes](../managed-kubernetes/index.md) в отказоустойчивой конфигурации; * Нативно отказоустойчивые облачные сервисы: * [Object Storage](../storage/index.md); * [Container Registry](../container-registry/index.md); * [Serverless Functions](../functions/index.md); * [Egress NAT](../vpc/concepts/gateways.md); * Средства автоматического масштабирования: * [Группы виртуальных машин](../compute/concepts/instance-groups/index.md) * [Группы узлов Kubernetes](../managed-kubernetes/concepts/node-group/cluster-autoscaler.md). ## Балансировщики нагрузки (Network Load Balancer, Application Load Balancer) {#load-balancers} ### Сетевой балансировщик нагрузки (Network Load Balancer) {#nlb} Основным средством для построения отказоустойчивых решений в Yandex Cloud является [сетевой балансировщик нагрузки (Network Load Balancer)](../network-load-balancer/concepts/index.md). Network Load Balancer распределяет TCP-соединения между целевыми ресурсами. Он может быть внешним для обработки трафика из интернета (обработчик с публичным IP-адресом) и внутренним (обработчик с приватным IP-адресом) для обработки внутреннего сетевого трафика. Health Checks используются для проверки готовности целевых ресурсов. Проверки готовности целевых ресурсов рекомендуется делать достаточно часто, с интервалом не более 3 секунд. Пороги срабатывания проверок должны быть строго больше 1. Для того чтобы проверки не приводили к повышенной нагрузке, на целевых ресурсах, реализация проверок не должна требовать много ресурсов для генерации ответа. Пример плохой практики: использовать в качестве проверки запрос корневой страницы сайта. Пример хорошей практики: отдельный URI для проверки состояния подключений к необходимым ресурсам (например, базам данных) и общей работоспособности. ### Балансировщик нагрузки уровня приложения (Application Load Balancer) {#alb} [Application Load Balancer](../application-load-balancer/index.md) является более интеллектуальным, но вместе с тем и более затратным инструментом балансировки. Сервис архитектурно представляет собой сетевой балансировщик нагрузки Network Load Balancer, который распределяет сетевой трафик между [ресурсными единицами](../application-load-balancer/concepts/application-load-balancer.md#lcu-scaling) — внутренними виртуальными машинами, выполняющими функции [обратных прокси](https://ru.wikipedia.org/wiki/Обратный_прокси), которые, в свою очередь, распределяют трафик далее между целевыми ресурсами заказчика. В отличие от 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](../smartwebsecurity/index.md), [ARL](../smartwebsecurity/concepts/arl.md), [WAF](../smartwebsecurity/concepts/waf.md), и [SmartCaptcha](../smartcaptcha/index.md). ## Отказоустойчивость платформенных сервисов {#platform-services-ha} ### Высокая доступность управляемых баз данных (MDB) {#mdb-ha} В случае отказа мастера БД автоматика сервиса инициирует переключение на другой хост. В ряде случаев во время отказа автоматика сервиса БД не может инициировать переключение мастера. В такой ситуации переключение необходимо выполнить вручную, например, с помощью команды `yc`. Пример для кластера PostgreSQL: ```bash yc managed-postgresql cluster start-failover <имя_кластера> --host <имя_хоста> ``` Для того чтобы клиент имел возможность всегда подключаться к текущему мастеру БД, не обращаясь к API за состоянием кластера, в Yandex Cloud существует механизм [особых FQDN](../managed-postgresql/operations/connect/fqdn.md#special-fqdns). Подключение через [особый FQDN](../managed-postgresql/operations/connect/fqdn.md#special-fqdns) упрощает написание приложений, но не гарантирует быстрое переключение на новый мастер в случае его смены. Для быстрого переключения на новый мастер необходима реализация на стороне приложения отслеживания события смены мастера и переподключения к нему. На текущий момент в Yandex Cloud нет сервиса, который автоматически балансирует читающую нагрузку между узлами кластера БД. Способы такой балансировки подробно обсуждаются на вебинаре [Охотимся на микросекунды: оптимизация работы сервисов в облаке](https://yandex.cloud/ru/events/935). ### Отказоустойчивость Managed Service for Kubernetes {#mk8s-ha} Для максимальной отказоустойчивости используйте несколько кластеров с балансировкой трафика между ними. Кроме отказоустойчивости, такая конфигурация позволяет обновлять версии кластеров без прерывания работы, решать задачу локализации трафика и проводить A/B тестирование. Для построения отказоустойчивой инфраструктуры в многокластерной конфигурации необходимо: * Обеспечить идентичную конфигурацию кластеров и размещенных в них приложений. * Настроить балансировку запросов между кластерами с помощью Application Load Balancer. Чтобы минимизировать влияние отказа узлов кластера, необходимо обеспечить равномерное распределение нагрузки. Чтобы предотвратить размещение подов на одном узле, рекомендуется использовать механизм `podAntiAffinity`. Для снижения времени недоступности сервиса во время обновлений кластера необходимо настроить политики `podDisruptionBudget`. ## Средства автоматического масштабирования {#auto-scaling} Основной инструмент масштабирования в Yandex Cloud — это [группы виртуальных машин](../compute/concepts/instance-groups/index.md). Группа виртуальных машин включает: * Шаблон виртуальной машины; * Политику масштабирования (ручную или автоматическую); * Механизм масштабирования. [Пример](../tutorials/infrastructure-management/vm-autoscale/index.md) развертывания группы ВМ с политикой автоматического масштабирования при превышении допустимой нагрузки. Для автоматического масштабирования, помимо базового параметра — нагрузки на CPU, можно использовать любой параметр из Yandex Cloud Monitoring. ## Отказоустойчивость клиентских сервисов {#client-service-ha} Для обеспечения отказоустойчивости и скорости отработки отказов приложений в Managed Service for Kubernetes необходимо: 1. Выделить сервису достаточное количество ресурсов (CPU, RAM); 1. Минимизировать или исключить переподписку ресурсов на рабочих узлах кластера Managed Service for Kubernetes, особенно RAM; 1. Настроить корректные Health Checks; 1. Использовать политику повторных попыток (retry policy) к сервисам провайдера; 1. Настроить автомасштабирование рабочих узлов кластера для автоматического перераспределения ресурсов в случае неожиданного повышения нагрузки или отказа одной из зон доступности. ## Мониторинг и эскалация {#monitoring-escalation} Ключевым инструментом обеспечения отказоустойчивости являются [мониторинг](../monitoring/concepts/index.md) и [система предупреждений (alerts)](../monitoring/concepts/alerting/alert.md). Помимо базовых средств мониторинга, которые предоставляются вместе с сервисами облака, важно настроить мониторинг бизнес-метрик. Например, отслеживание количества пользователей сервиса за последние минуты позволяет выявить проблемы на высоком уровне, даже если их источник в инфраструктуре не отслеживается. Для оперативного оповещения о проблемах в дополнение к сервису мониторинга необходимо настроить [политику эскалации](../monitoring/concepts/alerting/escalations.md) (в настоящее время находится на стадии [Preview](../overview/concepts/launch-stages.md)). ## План действий {#action-plan} Для быстрого восстановления сервиса необходимо иметь заранее подготовленные планы действий на случай отказов, такие как ручное переключение мастера БД или отключение зоны доступности. ## Тестирование отказоустойчивости {#ha-testing} Любые решения по обеспечению отказоустойчивости требуют регулярного тестирования в различных сценариях отказов. Подробнее о тестировании отказоустойчивости в облаке можно узнать из вебинара: [Отключаем ЦОД, или как тестировать отказоустойчивость в облаке](https://yandex.cloud/ru/events/841). #### Смотрите также {#see-also} * [Настройка отказоустойчивой архитектуры в Yandex Cloud](../tutorials/infrastructure-management/fault-tolerance.md) * [Высокая доступность кластера Yandex Managed Service for ClickHouse®](../managed-clickhouse/concepts/high-availability.md) * [Высокая доступность кластера Yandex MPP Analytics for PostgreSQL](../managed-greenplum/concepts/high-availability.md) * [Высокая доступность кластера Managed Service for Apache Kafka®](../managed-kafka/concepts/ha-cluster.md) * [Высокая доступность кластера Managed Service for PostgreSQL](../managed-postgresql/concepts/high-availability.md) * [Высокая доступность кластера Managed Service for MySQL®](../managed-mysql/concepts/high-availability.md) * [Высокая доступность кластера Managed Service for OpenSearch](../managed-opensearch/concepts/high-availability.md)