Отказоустойчивость

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

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

В основе отказоустойчивых систем всегда лежит дублирование компонентов системы и исключение единой точки отказа.

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

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

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

Уровень, на котором производится дублирование, определяет степень толерантности к сбоям.

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

Более продвинутый вариант — использование нескольких физических серверов (или облачных VPS) в рамках одного дата‑центра. В этом случае точка отказа — дата‑центр, если он вдруг окажется «отрезан» от мира, то система не будет доступна.

Самый продвинутый способ — использование не менее трёх несвязанных между собой дата‑центров для размещения оборудования. В этом случае можно «застраховаться» от сбоев уровня дата‑центра.

На программном уровне часто используется сервисный подход — в этом случае сбой отдельного сервиса не приводит к сбою системы в целом.

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

Например, в интернет‑магазинах часто есть рекомендательные системы, показывающие блоки «с этим покупают» / «смотрите также». Вполне логично, что при сбое на уровне рекомендательной системы эти блоки можно просто не показывать, но отобразить всё остальное содержание страницы.

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

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

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

Если же система не особо нагружена, то решение делать её отказоустойчивой потребует оценки целесообразности. Нормально настроенное приложение, работающее на одном виртуальном или физическом сервере, обычно имеет аптайм не менее 99.9% — это не более 8 часов простоя в год. Если эти 8 часов простоя в год стоят дороже затрат на дублирование оборудования, более сложную разработку и администрирование, то построение отказоустойчивой системы будет целесообразным.