Ранее в «Надёжность, устойчивость, доступность» провели введение в терминологию надежности. В этой статье рассмотрим типовые модели отказоустойчивого кластера. Речь пойдет про модели ОтказоУстойчивости (FT, Fault Tolerance), хотя в большинстве систем это будет в названии (разделов в описании) как High Availability (HA). Да, чаще всего будет написано мнение, что вот «HA допускает минимальное время простоя на перезапуск, а вот FT обеспечивает непрерывную работу системы без простоя», но мы ранее иначе классифицировали «х-устойчивость»: HA (доступность как НагрузкоУстойчивость) – это не про Устойчивость к поломкам \ отказам (т.е. FT), а про превышение нагрузки (HighLoad).
К сожалению, в текущих публикациях ИТ-изданий с заголовками «надежность, отказоустойчивость, доступность» и т.п. не встречал ни моделей надежности, ни расчетов этих самых (показателей) «надежность, отказоустойчивость, доступность», а только качественные критерии: «более надежный», «очень отказоустойчивый» и т.п. Инженерная надёжность (например, «Надежность в технике») из научной (инженерной) дисциплины в публикациях ИТ-журналов (хабр и т.п.) превратилась в некую менеджерскую дисциплину пусть и с техническими подробностями \ описаниями, например, механизмов переключения резерва, но без математического аппарата (теории вероятности \ теории надежности). С целью популяризации расчетов надежности отказоустойчивых резервируемых структур вычислительной и сетевой инфраструктур ниже предлагается несколько базовых подходов \ моделей \ надежностных схем.
Моделирование FT-кластера «последовательно – параллельными структурами» не позволит проектировать сложные конфигурации, модели (сложные системы), поэтому в большинстве случаев используют марковские цепи, точнее Непрерывную цепь Маркова (CTMC).
1 Типы отказов и резервов
1.1 Отказы
1.1.1 Отказ vs сбой
Постоянный отказ (или просто отказ), Permanent fault (постоянная/устойчивая неисправность) — это отказ, который не исчезает сам и остаётся до устранения, т.е. ремонта, замены компонента и т. п.
Сбой (он же временный отказ), Transient fault — временный сбой – самоустраняющийся, например, само-собой, перезагрузкой и т.п., т.е. не требует ремонта.
Периодические (перемежающиеся, прерывистые) сбои, Intermittent Faults — тип неисправностей, которые возникают периодически, например, однажды возникшая неисправность исчезает (пропадает без ремонта), а затем появляется снова. Примером периодического сбоя является периодическое зависание работающего компьютера. Причинами могут быть переполнение очередей, кэша (памяти) и т.п., которые очищаются при перезагрузке (завершение «сломанных» процессов, стартовая инициализация и т.п.).
1.1.2 Обнаруженный vs необнаруженный
Система или сама выявляет отказ и, например, переключает на резерв (Обнаруженный отказ) или находится в состоянии необнаруженного отказа, при условии, что он произошел или наоборот, считает что произошел отказ (и отключает нагрузку), при условии, что отказа нет (ложный отказ, ложное срабатывание защиты).
1.2 Резервы
Нагруженный резерв — резервный элемент работает в том же режиме, что и основной, принимает нагрузку. Синоним Горячий резерв — резерв всегда готов к работе.
Ненагруженный резерв — резервный элемент не нагружен до момента включения (обычно выключен). Синоним Холодный резерв — перед вводом в работу может требоваться подготовка (прогрев, загрузка, инициализация), из‑за чего появляется задержка.
В расчетах надежности обычно интенсивность отказов Холодного резерва принимается нулю, якобы, когда он выключен и лежит на складе, то не может отказать, — хотя это не так (об этом говорили в первой части), т.е. ненулевая интенсивность отказов в дежурном режиме или вероятность неуспешного запуска при включении \ переключении.
На практике часто добавляют Тёплый (облегчённый, частично нагруженный) резерв — промежуточный вариант: элемент включён, но работает на пониженной нагрузке. Или задает в расчете надежности отличную от нуля интенсивность отказа во время складского хранения, сгорания в момент включения \ выключения, повреждения при транспортировке и др.
Тут больше внимание уделяем Холодный \ Горячий с позиции отражения в модели надежности (надёжностной схеме), но те же термины используются и для отражения переключений и режимов эксплуатации, например.
Со схожим смыслом могут быть использованы термины: активный \ пассивный, например, комбинации: «Active – Active» Failover, Active-Passive (Hot \ Warm \ Cold Standby) и другие.
Вообще, терминология часто вводится (меняется) применительно к какому-либо конкретному решению (нет устоявшейся и разных вендоров FT терминология может расходиться).
2 Два узла. Простейшая модель
На рис. 1 показана Простейшая модель отказоустойчивого кластера из двух узлов (дублированная группа) с параметрами: Нагруженный (горячий) резерв и одна ремонтная бригада. Состояния цепи:
— Состояние 2 = Исправное состояние, два (все 2) узла работают. Normal state, no failure (ClusterOK);
— Состояние 1 = Работоспособное состояние, один (1) узел работает. State with a failure (ClusterOK);
— Состояние 0 = Неработоспособное состояние, 0 узлов работает (все сломаны, выделено красным, ClusterFail)
НеРаботоспособное состояние кластера (ClusterFail) на схеме выделено красным. Переходы из состояния в состояние заданы интенсивностями:
— интенсивность отказов λ = 1/MTBF, где Mean Time Between Failures — среднее время между отказами;
— интенсивность восстановления µ = 1/MTTR, где Mean Time To Repair / Mean Time To Recovery — среднее время ремонта. Мы для обоих Repair / Recovery будем использовать µ, но с дополнительным обозначением.
Деградация системы (кластера) показаны черными стрелками, восстановление (Repair / Recovery) – синими.
Так как Нагруженный (горячий) резерв, то переход из состояния 2 в 1 имеет 2*λ (каждый узел по λ). Если был бы Холодный резерв, то «как бы» второй узел отказать не может и переход из состояния 2 в 1 имел бы λ.
Так как одна ремонтная бригада, то переход из состояния 0 в 1 имеет µ: одна бригада ремонтирует только один узел. Только после этого бригада (единственная) начинает ремонтировать второй узел (сервер), см. переход из состояния 1 в 2, который тоже имеет интенсивность µ. Если было бы две ремонтные бригады, то восстановление двух неисправных узлов проходило бы одновременно, т.е. переход из состояния 1 в 2 был бы задан 2*µ.
Таким образом, для двухузлового кластера (дублированной группы, резервированной группы из двух узлов) имеем четыре комбинации:
— нагруженный резерв, одна ремонтная бригада (см. рис 1)
— Ненагруженный резерв, одна ремонтная бригада (интенсивность перехода «2» -> «1» будет λ вместо 2* λ)
— нагруженный резерв, две ремонтные бригады (интенсивность перехода «0» -> «1» будет 2*µ вместо µ)
— Ненагруженный резерв, две ремонтные бригады
Аналогичная надёжностная схема рисунку 1 показа в [2], также там приведен расчет марковской цепи и формула Кг (стационарного коэффициента готовности) для каждой комбинации.
3 Transparent vs nontransparent
Усложним рассмотренную выше (рис. 1) Простейшая модель отказоустойчивого кластера из двух узлов (дублированная группа). Для этого введем режимы (варианты):
— Transparent recovery, transparent repair
— Transparent recovery, nontransparent repair
— Nontransparent recovery, transparent repair
— Nontransparent recovery, nontransparent repair
Это режимы, которые «делят» восстановление на два этапа: восстановление сервиса – как переключение на резерв (подключение резервного узла) и ремонт узла.
Recovery (Восстановление сервиса) показывает как система (кластер) реагирует в момент отказа (сбоя) одного из элементов. Если восстановление прозрачное (transparent), система продолжает работать без прерывания функций для пользователя (failover происходит мгновенно). Если непрозрачное (nontransparent) — происходит кратковременный отказ (ClusterFail), деградация или перезагрузка, заметная пользователю.
Repair (Ремонт / Замена компонента) показывает как происходит возврат поврежденного компонента в строй. Если ремонт прозрачный, компонент чинится/заменяется «на лету» (hot-swap) и возвращается в систему без остановки сервиса. Если непрозрачный — чтобы вернуть отремонтированный элемент в работу, требуется плановая остановка, ручное переключение или перезагрузка всей системы (offline синхронизация данных и т.п.).
3.1 Failover vs Failback
Failover (аварийное переключение) – функция (процедура, операция), позволяющая временно переключать систему из исправного состояние в работоспособное, в общем случае в режим деградации (на ступень \ уровень деградации ниже).
Failback – функция (процедура, операция), возвращающая систему из режима полной деградации (ClusterFail) в работоспособное состояние или из работоспособного в исправное состояние (т.е. восстановление на уровень выше), т.е. failback (возврат на основной узел) — это возврат системы на основной (первичный) узел после того, как она работала на резервном (т.е. после переключения failover).
Для закрепления: Failover — это переход на резерв при отказе, а failback — возврат с резерва на основной узел (сервис) после восстановления. Failover — переключение с основной машины (сервиса) на резервную при отказе, а failback — обратное переключение, когда основная нода (узел, сервер) «вернулась в строй».
В моделях надёжности failover связывают с интенсивностью отказов λ, а failback с интенсивностью восстановления μ (временем, которое нужно, чтобы вернуть систему / нагрузку на основной узел).
Будем расширять модель, показанную на Рис. 1, т.е. «нагруженный резерв, одна ремонтная бригада». Аналогично могут быть расширены остальные варианты: Ненагруженный резерв, одна ремонтная бригада; нагруженный резерв, две ремонтные бригады; Ненагруженный резерв, две ремонтные бригады.
Возвратимся к transparent recovery \ transparent repair. Из [1]:
Влияние процесса восстановления на пользовательские приложения может быть прозрачным или непрозрачным. Например, если функция автоматического восстановления (AR) при сбое процессора реализуется путем перезагрузки системы, то процесс восстановления не является прозрачным для пользователя.
При (условно) мгновенном failover происходит незаметный для пользователя переход из исправного состояния (все работает) в работоспособное (что-то отказало, но в целом работает). Точнее, быстрый \ небыстрый, заметный \ незаметный, transparent \ nontransparent (failover & failback) определяются в критерии отказа (там можно вводить необходимые допущения).
При этом могут быть гибридные модели, где с такой-то вероятностью будет быстрое переключение на резерв (failover), т.е. в рамках SLA, а с такой-то через состояние отказа (с превышением допустимого времени).
Режим Transparent recovery, transparent repair – это когда переключение на резерв и возврат происходят незаметно для пользователя (незаметные – «нулевые» failover & failback) и это позволяет использовать без изменения Простейшую модель надежности отказоустойчивого кластера из двух узлов, показанную на Рис. 1.
При моделировании режима Transparent recovery, nontransparent repair необходимо показать состояние, отражающее состояние отказа после завершения ремонта узла и восстановления кластера (системы), т.е. «проблемный» failback.
При моделировании режима Nontransparent recovery, transparent repair необходимо показать состояние, отражающее состояние отказа при переключении на резервный узел (failback через промежуточное состояние отказа).
Видимо можно было бы использовать что-то одно recovery \ repair или failover \ failback, но для лучшего понимания будем использовать предложенный вариант.
Наиболее проблематичный случай при режиме Nontransparent recovery, nontransparent repair, его мы и рассмотрим подробнее на рис. 2.
На рис. 2 выделено три состояния отказа 1a (ClusterFail-failover), 1b (ClusterFail-failback), 0 (ClusterFail) и два состояния (2 и 1), когда сервисы доступны (кластер работает, ClusterOK). Когда выше говорили про гибридный режим (модель), то в модели нужно показать отдельно интенсивность перехода из состояния 2 в состояние 1, т.е. failover в рамках SLA.
Состояния 1a и 1b выделяются как «транзитные» / «промежуточные» (short-term failure states),
Иногда добавляют еще состояние SPF — когда failover (Recovery) неуспешен и возникло single-point failure condition. Когда проблема в единой точке отказа, то происходит переход в состояние SPF (ClusterFail), см. Приложение 1.
4 Необнаруженный отказ
Выше мы добавили к Простейшей модели кластера еще одно измерение failover \ failback. Однако для более адекватной модели надежности реальной ситуации (поведению системы в реальном мире) необходимо далее усложнять модель.
Одним из путей является формализация состояния «необнаруженного отказа», точнее отказа, необнаруженного собственной (встроенной) системой управления кластера. Подробно проблема и модель «необнаруженного отказа» показана в [2] и [3]:
кластер представляет собой дублированную структуру с непрерывным неполным контролем (внутренними средствами кластера), заданным η, и периодическим – внешним полным контролем работоспособности узлов, заданным θ, причем отказ узла с вероятностью η обнаруживается мгновенно, а отказ с вероятностью 1-η – с задержкой на время 1/θ. Таким образом, время задержки обнаружения скрытых отказов имеет экспоненциальное распределение с параметром θ.
Для такого случая надежностная схема дополнительно к рис. 1 включает дополнительный узел — состояние Необнаруженного отказа. Конечно рано или поздно «необнаруженный отказ» все равно обнаруживается даже если система управления кластером его «не видит», например, «залип keepalive», система управления кластером дала сбой и т.п. Keepalive, «Пока жив» –сигналы, которыми обмениваются узлы кластера для мониторинга состояния «напарника».
Подразумевается, что есть внешний контроль, который позволяет определить «необнаруженный отказ». Примером может случить сообщения пользователей в службу поддержку, а если даже повисла и вся ip-телефония компании (клиенты не дозвонятся), то системы типа контроля числа (отношения) текущих рабочих операций к ожидаемому (плановому) числу операций за тот же период в рамках конкретного технологического процесса (см. 850-П). Падение отношения текущих операций к плановому показателю является сигналом к фиксации «инцидента операционной надежности» даже если в системе мониторинга «все горит зеленым» (не фиксирует отказ) вплоть до передачи специальных сообщений в специальный орган регулятора (СТО БР БФБО-1.5-2023).
Важный вывод в [2] и [3]: увеличение кратности резервирования может снижать надежность, что продемонстрирована в [2] графиком «Зависимость Кг от кратности резервирования при θ≤0,999», а также:
Важнейшим фактором, ограничивающим рост надежности при избыточном резервировании, является неполный охват контролем средств переключения и появление скрытых отказов в резервных модулях.
Приложение 1. Сравнение с моделью из [1]
Ниже показан рисунок из [1] Figure 4. Markov Model Type 3, отражающий режим — Nontransparent recovery, transparent repair (с настоящей статье оба Nontransparent).
Если сравнивать с предложенным в статье [1] моделью, то состояние AR1 соответствует состоянию «1а» (failover).
Нижняя цифра в названии состояния обозначает:
1 – рабочее
2 – отказ (ClusterFail)
Если случился обнаруженный отказ, то на Figure 4. Markov Model Type 3 будет выполнен следующий сценарий:
Ok (оба узла работают) → AR1 (отказ кластера на время automatic recovery) → PF1 (один узел в ремонте, второй работает) → Ok
Или иначе:
1 Ok — исправное состояние кластера
1.1 обнаружен отказ
2 AR1 (failover) – состояние отказа кластера (т.к. Nontransparent recovery), неработоспособное
2.1 automatic recovery завершен
3 PF1 – работоспособное (неисправное) состояние
3.1 восстановление отказавшего узла завершено
4 Ok — исправное состояние кластера (ClusterFail failback нет, т.к. transparent repair)
Модели [1] отражают обнаруженные \ необнаруженные отказы, а также сбои.
Используемые источники
1 Automatic generation of availability models in RAScad
3 Резервный центр обработки данных. Оценка надежности. Электроника НТБ. Выпуск 4/20
ссылка на оригинал статьи https://habr.com/ru/articles/1075024/