Высокая доступность и отказоустойчивость

High Availability (HT) & Fault Tolerance (FT). А ещё есть Disaster Recovery (DR). В работе пришлось столкнуться с тем. что не все понимают разницу и необходимость их использования в том или ином случае. Разберём:

• базовые понятия: избыточность, отказ, ошибка, сбой;
• классическую теорию высокой доступности (девятки, кластеры, формулы);
• концепцию отказоустойчивости (модели отказов, репликация, кворум, разнообразие)
• корпоративные уровни доступности с практическими примерами
• сравнительный анализ HA и FT по множеству критериев
• рекомендации по выбору стратегии для различных классов систем

О DRP:

План аварийного восстановления — DRP (Disaster Recovery Plan)

Введение: почему доступность стала главной валютой цифрового мира

С развитием компьютерных сетей и облачных вычислений сетевые сервисы стали неотъемлемой частью повседневной жизни. Онлайн-банкинг, электронная коммерция, телекоммуникации, системы бронирования, потоковое видео, удалённая медицина — пользователи ожидают доступа к этим сервисам "всегда и везде", без выходных и перерывов. Даже несколько минут недоступности могут привести к прямым финансовым потерям, репутационному ущербу и юридическим последствиям.

В ответ на это провайдеры заключают соглашения об уровне обслуживания (SLA), где фиксируют минимальный гарантированный процент доступности. Для выполнения этих обязательств применяются методы резервирования, восстановления после сбоев и непрерывной работы.

Однако, хотя эти понятия тесно связаны, отказоустойчивость (fault tolerance) и высокая доступность (high availability) — не одно и то же. Более того, в корпоративной практике выделяют четыре основных уровня доступности: от обычной (Office Production) до постоянной (Continuous Availability). Выбор правильного уровня требует понимания не только технических различий, но и бизнес-контекста, бюджета и допустимых потерь.

Базовые понятия: избыточность, отказы и метрики

Ключевой механизм — избыточность (redundancy)

Прежде чем говорить о различиях, необходимо понять фундаментальный принцип, на котором строятся и высокая доступность, и отказоустойчивость — избыточность.

Избыточность — это практика развертывания дополнительных копий компонентов системы (оборудования, программного обеспечения, сетевых соединений, источников питания, каналов связи). Сами по себе эти копии не нужны для обычной работы системы. Однако они становятся критически важными в момент отказа: именно они позволяют обнаружить сбой, переключить нагрузку, продолжить вычисления и минимизировать последствия.

Избыточность может быть реализована на разных уровнях:

• аппаратная избыточность: резервные серверы, дисковые массивы RAID, сетевые интерфейсы, источники бесперебойного питания
• программная избыточность: резервные копии приложений, балансировщики нагрузки, кластеры
• информационная избыточность: дублирование баз данных, репликация, распределённые файловые системы
• сетевая избыточность: множественные маршрутизаторы, коммутаторы, провайдеры связи

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

Отказ, ошибка, сбой

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

• Отказ (fault) — это неисправность компонента, его внутреннее состояние, при котором он начинает вести себя не так, как ожидается. Отказ может существовать скрыто, не проявляясь внешне.
• Ошибка (error) — это проявление отказа. Когда отказавший компонент выполняет какое-либо действие и выдаёт некорректный результат, это ошибка.
• Сбой (failure) — это событие, при котором ошибка приводит к прекращению или искажению работы всей системы или её части с точки зрения внешнего наблюдателя.

Пример: у сервера повреждён модуль памяти (отказ). При выполнении расчёта он возвращает неверное значение (ошибка). Если это значение приводит к неверной транзакции в банковской системе — происходит сбой.

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

Высокая доступность (High Availability, HA): теория и практика

Определение и цель

Высокая доступность — это подход к проектированию систем, направленный на максимальное сокращение времени простоя. Главная цель HA — поддерживать сервис в рабочем состоянии как можно большую долю времени. При этом допускаются кратковременные прерывания — обычно на время, необходимое для обнаружения отказа и переключения на резервный компонент.

Важнейшее отличие HA от FT состоит в том, что HA не стремится к нулевому времени простоя. Вместо этого HA признаёт, что отказы неизбежны, но старается свести их последствия к приемлемому минимуму.

Классические "девятки": классы доступности

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

• одна девятка 90% 36,53 д Тестовые системы, не критичные к простоям.
• две девятки 99% 3,65 д (87,6 ч) Небольшие интернет-магазины.
• три девятки 99,9% 8,77 ч Корпоративные CRM. Крупные web-сайты.
• четыре девятки 99,99% 52,6 мин Платёжные шлюзы, биржевые терминалы, критичные бизнес-системы.
• пять девяток 99,999% 5,26 мин Телекоммуникационные сети (E911), авиадиспетчерские системы.
• шесть девяток 99,9999% 31,56 с Ядерные реакторы, системы управления ракетами (специфические сценарии).

Формула для расчёта доступности:

Availability_% = (Elapsed_time - Inoperative_time) / Elapsed_time * 100%Копировать

Где Elapsed_time — общее время в периоде (например, год = 365 дней × 24 часа = 8760 часов), а Inoperative_time — суммарное время простоев.

Чем выше требуемый класс доступности, тем больше по экспоненте растут затраты. Переход с 99,9% на 99,99% может потребовать внедрения полной гео-резервации и автоматического переключения, а переход на 99,999% — отказоустойчивых кластеров с синхронной репликацией и многопутными сетевыми соединениями.

Как реализуется высокая доступность: кластеры

Типичная архитектура HA строится на основе высокодоступных кластеров (HA clusters). Кластер — это группа независимых серверов (узлов), которые объединены в единую систему с общими ресурсами: дисковыми массивами, конфигурационными файлами, IP-адресами, именами в DNS.

Основные компоненты HA-кластера:

• Активный узел (primary, active) — основной сервер, который обрабатывает запросы в штатном режиме.
• Резервный узел (standby, passive, replica) — один или несколько серверов, которые получают те же данные, что и активный, но не обрабатывают запросы (или обрабатывают, но результат не возвращается клиенту). В простейшем случае резерв находится в горячем режиме ожидания.
• Сердечник кластера (cluster heartbeat) — канал связи между узлами, по которому они периодически обмениваются сигналами "я жив".
• Менеджер ресурсов (resource manager) — ПО, которое отслеживает состояние узлов и при отказе активного узла инициирует переключение (failover).

Схема переключения (failover):

1. Резервный узел перестаёт получать heartbeat от активного.
2. По истечении таймаута (например, 3–5 секунд) резервный узел берёт на себя IP-адрес, монтирует общие диски и запускает сервисы.
3. Время простоя составляет от нескольких секунд до пары минут — это и есть время простоя Inoperative_time, которое влияет на класс доступности.

Преимущества и ограничения HA

Преимущества:

• Относительно невысокая стоимость по сравнению с отказоустойчивостью.
• Простота масштабирования: можно добавлять новые узлы без остановки сервиса.
• Естественная балансировка нагрузки (в актив-активных конфигурациях).

Ограничения и риски:

• Есть простои (хотя и небольшие). Для некоторых систем даже 5 минут простоя неприемлемы.
• Потенциальная потеря данных: если сбой произошёл до того, как изменения были синхронизированы с резервным узлом (особенно в асинхронной репликации).
• Проблема split-brain: если канал heartbeat разорван, оба узла могут решить, что другой мёртв, и попытаться стать активными — это приведёт к конфликтам.

Отказоустойчивость (Fault Tolerance, FT): работа без прерывания

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

Ключевое отличие от HA: отказоустойчивая система не имеет простоев (zero downtime). Она не переключается с активного узла на резервный с потерей нескольких секунд — все узлы работают одновременно, и клиент даже не замечает, что какой-то из компонентов отказал.

Модели отказов

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

• Fail-stop (остановка с сигналом)   
  Компонент перестаёт работать и либо явно сообщает об этом, либо просто замолкает. Это самая простая модель: если компонент не отвечает, считается, что он отказал. Пример: сервер выключился из-за потери питания.
• Fail-silent (молчаливый отказ, omission faults)   
  Компонент не отвечает на запросы, но при этом не факт, что он полностью остановился. Он может висеть, не обрабатывая новые запросы, или пропускать некоторые сообщения. Более сложная модель, так как сложно отличить "компонент умер" от "компонент очень медленно работает".
• Византийская (Byzantine faults)   
  Самая общая и сложная модель. Отказавший компонент может вести себя произвольно: отправлять противоречивые или вредоносные сообщения, иногда работать правильно, иногда — нет, в разных подсистемах давать разные результаты. Названа в честь "Византийской проблемы генералов", где несколько генералов должны согласовать атаку при наличии предателей. Пример: сервер с повреждённой памятью, который иногда выдаёт неверные результаты вычислений, но не крашится.

Требования к отказоустойчивости формулируются так: "Система устойчива к N отказам типа fail-stop" или "Система устойчива к N византийским отказам".

Реализация: активная репликация и кворум

В отличие от HA, где резервные узлы обычно ждут в стороне, в отказоустойчивой системе применяется активная репликация (active replication). Все реплики работают одновременно и независимо.

Схема работы:

1. Клиент отправляет запрос всем репликам (или фронтенд-прокси рассылает запрос).
2. Каждая реплика обрабатывает запрос и выдаёт результат.
3. Специальный компонент (сборщик голосов, voter) сравнивает полученные результаты.
4. Результат, полученный от большинства (кворума), считается правильным и возвращается клиенту.

Количество реплик:

• Для модели fail-stop: минимальное количество реплик для терпимости к N отказам: n = 2N + 1. Например, для допуска одного отказа (N=1) нужно 3 реплики.
• Для византийской модели: n = 3N + 1. Для допуска одного византийского отказа нужно 4 реплики.

Почему именно так? Потому что система должна иметь возможность отличить правильно работающую реплику от отказавшей. Если у вас три реплики и одна отказала, две оставшиеся образуют большинство. Если бы их было две, и одна отказала — осталась одна, и невозможно определить, её ли результат правильный.

Дополнительный механизм: разнообразие (diversity)

Помимо избыточности, отказоустойчивые системы активно применяют разнообразие. Идея проста: если все реплики используют одну и ту же операционную систему, одну версию библиотеки и одно и то же приложение, то ошибка в этом общем коде проявится одновременно на всех репликах. Разнообразие предотвращает этот эффект.

Примеры разнообразия:

• Разные версии компилятора для сборки компонентов.
• Разные реализации одного алгоритма на разных языках программирования.
• Использование различных гипервизоров.
• Разные модели сетевых коммутаторов от разных производителей.

Преимущества и недостатки FT

Преимущества:

• Нулевое прерывание — клиент не замечает отказа.
• Отсутствие потери данных — так как все реплики синхронны, ни одна операция не теряется.
• Прозрачность — приложение может не знать, что работает в отказоустойчивом окружении.

Недостатки:

• Чрезвычайно высокая стоимость — нужно 3–4 реплики вместо 2.
• Сложность управления — синхронизация реплик, обработка византийских отказов, сбор голосов.
• Снижение производительности — операция считается завершённой только после того, как её подтвердит большинство реплик.
• Требования к синхронности — для некоторых моделей нужны синхронные каналы связи с гарантированной задержкой.

Корпоративные уровни доступности: от обычной до постоянной

В реальной практике IT-инфраструктуры выделяют четыре основных уровня доступности, которые объединяют элементы HA, FT и DR. Эти уровни привязаны к бизнес-статусу систем и времени восстановления.

Уровень 1: Постоянная доступность (Continuous Availability)

Самый высокий уровень. Инфраструктура готова к любым запланированным (обслуживание, обновления, замена оборудования) и незапланированным простоям. Система работает 24/7 годами без единого перерыва. Даже во время обновления программного обеспечения или замены сервера сервис продолжает работу — за счёт поочерёдного отключения узлов.

Требования к восстановлению:

Полное восстановление после любой аварии — в течение минут (часто 5–15 минут).

Статус IT-системы: Mission Critical.

Меры обеспечения:

• Всестороннее резервирование (N+1 или N+N): каждый компонент имеет как минимум один горячий резерв.
• Геораспределение: узлы в разных дата-центрах, в разных сейсмических зонах, с разными провайдерами связи.
• Режим постоянного дежурства: инженеры 24/7 на связи, автоматическая эскалация.
• Синхронная репликация данных между географическими площадками.
• Автоматическое переключение без участия человека (no human-in-the-loop).

Примеры:

• Электронное движение капитала (системы брокерского учёта, расчётно-клиринговые палаты).
• Системы обработки платежей Visa/Mastercard в режиме онлайн.
• Ядерные реакторы (в сочетании с отказоустойчивостью).

Уровень 2: Непрерывный режим работы (Continuous Operations)

Чуть менее строгий уровень, чем постоянная доступность. Система также работает 24/7 годами в штатном режиме, но не готова к авариям на всех узлах одновременно. Например, если откажет целая зона доступности (AZ) в облаке, система может остановиться, но если откажет один сервер — переключение произойдёт без остановки.

Требования к восстановлению:

Восстановление после крупной аварии (выход из строя целого дата-центра) — 1–2 часа.

Статус IT-системы: Business Critical.

Меры обеспечения:

• Частичное резервирование: резервируются только наиболее критичные точки отказа (хранилища данных, сетевые ядра, серверы БД).
• Геораспределение на важных точках отказа (обычно два дата-центра в одном регионе или два Availability Zone в облаке).
• Режим непрерывной готовности: инженеры в рабочее время, on-call вне рабочего времени.
• Асинхронная репликация (с допустимой задержкой до нескольких секунд).

Примеры:

• Корпоративные ERP-системы (SAP, Oracle) крупных предприятий.
• Системы диспетчеризации городского транспорта.
• Онлайн-кинотеатры с высокими требованиями к доступности (Netflix, но с учётом их реальной архитектуры — ближе к Continuous Availability для некоторых компонентов).

Уровень 3: Высокая доступность (High Availability)

Этот уровень соответствует классическому определению HA из части 2. Система может периодически останавливаться на плановое обслуживание (например, установка обновлений, замена дисков, перезагрузка узлов) в нерабочие дни или часы с предварительным уведомлением пользователей. В остальное время система работает непрерывно, но при серьёзной аварии возможен простой до нескольких часов. Режим работы определяется графиком организации: 8/5 (только в рабочие дни, с 9 до 18), 8/7, 12/5, 12/7, 24/7 с плановыми окнами обслуживания.

Требования к восстановлению:

Полное восстановление после аварии — 4–6 часов.

Статус IT-системы: Business Operational.

Меры обеспечения:

• Частичное резервирование: сети, данные, электропитание (но не обязательно CPU/память на каждом узле).
• Отсутствие геораспределения (все узлы в одном дата-центре).
• Режим повышенной готовности: реагирование на инциденты в рабочее время.
• Резервное копирование с периодичностью в несколько часов.

Высокая доступность не равноценна DR (Disaster Recovery). HA включает в себя отказоустойчивость отдельных (или всех) узлов IT-инфраструктуры, но не рассчитана на катастрофы. То есть HA готова к отказу магистральной электросети, серверной стойки или интернет-канала, но если что-то серьёзно загорится или взорвётся — высокая доступность закончится.

Примеры:

• Веб-сайты среднего бизнеса с посещаемостью до 1 млн пользователей в месяц.
• Корпоративные порталы, вики, системы управления задачами (Jira, Confluence в небольших инсталляциях).
• Интернет-магазины.

Уровень 4: Обычная доступность (Regular Availability / Office Production)

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

Требования к восстановлению:

Восстановление — от одного до нескольких дней.

Статус IT-системы: Office Production.

Меры обеспечения:

• Резервирование отсутствует или выполняется на самых простых уровнях (например, RAID 1 на дисках, один резервный блок питания).
• Геораспределение не применяется.
• Режим обычной готовности: реагирование на инциденты в порядке очереди.
• Резервное копирование раз в сутки или реже.

Примеры:

• Внутренние офисные файловые серверы.
• Тестовые и разработочные стенды.
• Системы учёта расходных материалов на складе.
• Интранет-порталы с нечасто меняющейся информацией.

Отказоустойчивость vs высокая доступность

Следует подчеркнуть: отказоустойчивая система не обязательно является высокодоступной, и наоборот.

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

Система может быть высокодоступной, но не отказоустойчивой, если она быстро переключается на резерв (малый downtime), но при этом не терпит одновременных отказов нескольких компонентов или не может работать при византийских ошибках.

Однако на практике они хорошо работают вместе: высокодоступная архитектура часто использует элементы отказоустойчивости для наиболее критичных компонентов (например, отказоустойчивая база данных внутри HA-кластера приложений).

Как выбрать стратегию?

Прежде чем выбирать между HA и FT, а также между уровнями доступности, задайте себе следующие вопросы:

Какова цена одного часа простоя?

Если простой стоит миллионы долларов (биржевые сделки, авиация) — нужна FT или Continuous Availability. Если простой стоит тысячи долларов — достаточно HA (99,99%). Если простой стоит сотни долларов — 99,9%.

Допустима ли потеря данных?

Для банковских транзакций — нет. Для кэша веб-страниц — да. Если потеря недопустима, нужна синхронная репликация, а это тянет к FT.

Каковы типичные сценарии отказов?

Только отказы "всё умерло" (fail-stop)? Или возможны "зависания" (fail-silent)? Есть ли риск злонамеренных действий или коррумпированных данных (византийские отказы)?

Каков бюджет?

FT стоит примерно в 3–5 раз дороже HA для той же вычислительной мощности из-за тройной репликации и систем голосования.

Каковы регуляторные требования?

В финансах (PCI DSS), здравоохранении, авиации могут быть явно прописаны требования к классу доступности и отказоустойчивости.

Заключение

Мы рассмотрели два фундаментальных подхода к обеспечению надёжности IT-систем — высокую доступность (HA) и отказоустойчивость (FT).

Высокая доступность минимизирует простои, но допускает кратковременные прерывания. Это практичный и относительно недорогой способ достичь доступности 99,9–99,999% для большинства бизнес-систем. Отказоустойчивость обеспечивает непрерывную работу даже при отказах, без единой остановки. Это самый высокий уровень надёжности, но он требует многократного увеличения затрат и сложности.

В реальной корпоративной практике используются четыре уровня доступности: от Office Production (обычная доступность) до Continuous Availability (постоянная доступность). Каждый уровень имеет свои требования ко времени восстановления (RTO), потерям данных (RPO) и методам резервирования.

HA и FT не эквивалентны. Более того, HA не заменяет Disaster Recovery (DR): HA готова к сбоям отдельных узлов, но не к катастрофам. Для катастроф нужны отдельные стратегии с географически разнесёнными площадками. Выбор между HA и FT, а также между классами доступности — это всегда компромисс между стоимостью, сложностью, допустимым временем простоя и допустимыми потерями данных. Универсального лучшего решения не существует.

С развитием облачных технологий и появлением управляемых сервисов с SLA 99,99% и выше, реализация HA стала доступна даже среднему бизнесу. Полная отказоустойчивость (византийская, с синхронной тройной репликацией) по-прежнему остаётся уделом критической инфраструктуры — но и для неё появляются готовые решения.

Правильный уровень доступности — это не только техническое решение, но и бизнес-решение, которое должно приниматься совместно IT-специалистами, финансовыми директорами и руководителями продуктов.

Источник:

💰 Поддержать проект

Если вам понравилась статья, то ставьте 👍🏻 каналу. Пишите комментарии, задавайте вопросы, подписывайтесь.