Высокая доступность

Высокая доступность является свойством устойчивости сети — способности «обеспечивать и поддерживать приемлемый уровень сервиса при возникновении отказов и внештатных ситуаций»^[3]. Угрозы и вызовы могут варьироваться от ошибок конфигурации до природных катастроф и целевых атак^[4]; поэтому вопросы устойчивости сетей затрагивают широкий круг тем. Для повышения устойчивости коммуникационной сети необходимо выявить потенциальные угрозы и риски, а также определить соответствующие метрики устойчивости для защищаемых сервисов^[5].

Значение устойчивости сетей растёт, так как они становятся ключевым элементом критических инфраструктур^[6]. В связи с этим всё больше исследований посвящено трактовке и улучшению устойчивости сетей и вычислительных систем применительно к критическим объектам инфраструктуры^[7]. Например, целью устойчивости может быть не только сохранение самих сетевых сервисов, но и обеспечение работы приложений поверх сети, что требует согласованных действий со стороны и сетевой инфраструктуры, и сервисов поверх неё^[8].

К этим сервисам относятся:

• поддержка распределённой обработки
• поддержка сетевого хранения данных
• обеспечение работоспособности сервисов коммуникации — таких как
  • видеоконференция
  • мгновенные сообщения
  • онлайн-совместная работа
• доступ к приложениям и данным по мере необходимости

В зависимости от контекста исследования термины устойчивость и живучесть могут использоваться как синонимы^[9].

Согласно инженерии надёжности выделяется три принципа проектирования систем для достижения высокой доступности.

1. Исключение единственных точек отказа. Это достигается путём введения избыточности, чтобы сбой отдельного компонента не приводил к отказу всей системы.
2. Надёжное переключение. В резервируемых системах сам механизм переключения часто становится единственной точкой отказа; отказоустойчивая система должна обеспечивать надёжность функционала переключения.
3. Выявление отказов по мере их возникновения. Даже если выполнены два предыдущих принципа и пользователь не замечает сбоев, система должна своевременно фиксировать и устранять неисправности — для технического обслуживания.

Можно выделить плановые и внеплановые интервалы простоя. Обычно плановое время простоя возникает вследствие технического обслуживания, требующего остановки системы, и не может быть устранено при существующей архитектуре. Примеры плановых остановок — установка обновлений системного ПО, требующая перезагрузки, либо изменения конфигурации, вступающие в силу только после перезапуска. В общем случае плановое время простоя связано с управленческим решением. Внеплановые простои — как правило, следствие аппаратных или программных сбоев либо внешних воздействий (отказ оборудования, сбои питания, выход из строя CPU или RAM, перегрев, разрывы сети, атаки, сбои приложений, операционной системы и пр.).

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

Многие организации исключают плановое время простоя из вычислений показателя доступности, предполагая, что для пользователей он не критичен. Это позволяет заявлять о феноменально высокой доступности, создавая иллюзию непрерывной работы. Реально непрерывную доступность обеспечивают лишь специализированные и дорогие системы, где исключены любые единственные точки отказа и допустимы горячие (без остановки) обновления/замены аппаратуры, ПО, приложений и др. Для некоторых систем плановый простой незначителен.

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

Термины время безотказной работы и доступность иногда ошибочно используются как синонимы. Например, система может «работать» с технической точки зрения, но быть «недоступной» для пользователей из-за сбоя сети. Или во время обслуживания администратор может работать с системой, но пользователи не видят сервис. Поэтому важно уточнять, о каком уровне (аппаратном, сервисном, приложенческом) идёт речь.

Существует простое правило: «пять девяток» соответствуют примерно 5 минутам недоступности в год. Аналогично, «четыре девятки» — 50 минут, «три девятки» — 500 минут. Чем больше девяток, тем жёстче требования: «шесть девяток» — всего 30 секунд простоя в год.

Для оценки длительности простоя при «n девятках» можно воспользоваться формулой: ${\displaystyle 8{,}64\times 10^{4-n}}$ секунд простоя в сутки.

Проценты высокой доступности часто называют по числу девяток в числе (например, 99,999% — «пять девяток»); термин используется при обсуждении, к примеру, работы мейнфреймов^[10] или серверных платформ большой нагрузки, особенно в рамках SLA. Проценты, оканчивающиеся на 5, традиционно именуют «девятки и пять»^[11][12]. Иногда встречается определение «три с половиной девятки», однако оно не вполне корректно, поскольку разница между 0,1% и 0,05% куда меньше, чем между 0,05% и 0,01%^[13].

В целом, выражение доступности через количество девяток — скорее маркетинговый термин; для точного моделирования инженеры пользуются вероятностями отказа или временем простоя в год. Сложность применения «девяток» отмечалась в профильной литературе^[14].

Иногда встречается ироничное выражение «девять пятёрок» (55,5555555%) — как антипод «пяти девяток» (99,999%) для ситуации с крайне низкой надёжностью^[15][16][17].

Оценка доступности всегда зависит от интерпретации. Например, если система непрерывно работает 365 дней в году, но из-за сбоя сети была недоступна 9 часов в течение пикового периода, администратор может утверждать о 100% времени работы, однако пользователи посчитают иначе. По строгому определению коэффициент доступности составит около 99,9% («три девятки»).

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

Альтернативной метрикой является среднее время между отказами.

Понятия время восстановления (или плановое время ремонта, ETR), целевое время восстановления (RTO), а также среднее время восстановления (MTTR) тесно связаны с доступностью — они характеризуют продолжительность восстановления после сбоев или плановых остановок. Некоторые системы, напр. при пожаре, могут теоретически иметь бесконечное время восстановления, если нет резервных дата-центров.

Родственный термин доступность данных — в какой мере БД и другие хранилища корректно записывают и выдают транзакции. Гарантии минимизации потери данных часто определяют отдельные показатели точки восстановления.

Формализация требований по доступности и её измерению закрепляется в соглашении об уровне сервиса (SLA).

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

Добавление дополнительных компонентов может снижать реальную надёжность, поскольку усложняет архитектуру и увеличивает число потенциальных точек отказа. Иногда наивысшую доступность демонстрируют простые системы с качественной аппаратной избыточностью, но такие решения требуют полной остановки на время обновления или патча ОС. Более развитые архитектуры позволяют обновлять/патчить систему без прерывания сервиса. Высокая доступность требует минимизации влияния человеческого фактора, так как ошибки операторов — одна из ключевых причин простоев^[18].

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

При параллельной избыточности (компоненты работают независимо в разных ЦОДах/узлах) общая доступность резко возрастает — при X-доступности одного элемента и N независимых экземплярах вероятность одновременного отказа вычисляется по формуле:^[19][20]

Доступность = 1 − (1 − X)^N

Например, если каждый из компонентов доступен лишь в 50% времени, при 10 параллельно работающих вероятность недоступности всей системы составит менее 0,1% (доступность ≈ 99,9%).

Различают пассивную и активную избыточность.

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

Активная избыточность реализует безотказность без деградации производительности за счёт включения нескольких одинаковых компонентов, между которыми автоматически перераспределяется нагрузка и прозрачно устраняются сбои (в том числе с помощью схем голосования). Данный подход применяется в распределённых вычислениях и маршрутизации — в частности, наработки Бирмана и Джозефа лежат в основе современных сетевых протоколов. Однако при сложных схемах активной избыточности могут возникать новые сбои.

Архитектуры с нулевым временем простоя (zero downtime) допускают, что время между отказами превышает цикл обслуживания/обновления или срок службы системы. Такие подходы нужны для авиации и спутниковой связи, например GPS — пример с нулевым временем простоя.

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

Моделирование и симуляция применяются для расчёта вариантов архитектуры и поиска уязвимых точек по схемам N-x (N — число элементов, x — количество одновременно отключённых элементов).

По данным опроса экспертов по доступности ИТ-систем (2010), основные причины обусловлены нарушением best practices в следующих областях^[21] (в порядке важности):

1. Мониторинг ключевых компонентов
2. Требования и закупки
3. Эксплуатация
4. Предотвращение сетевых сбоев
5. Устранение внутренних отказов приложений
6. Избежание зависимостей от ненадёжных внешних сервисов
7. Физические условия эксплуатации
8. Сетевая избыточность
9. Резервное копирование (техническая реализация)
10. Резервное копирование (организация процесса)
11. Физическое размещение
12. Избыточность инфраструктуры
13. Избыточность архитектуры хранения данных

Детальный анализ изложен в специальной книге^[22].

Согласно отчёту IBM Global Services (1998), потери американских компаний от недоступности систем в 1996 году оценивались в $4,54 млрд (потерянная выручка и производительность)^[23].