Простой IT-инфраструктуры редко ограничивается неудобством для пользователей. Для бизнеса это недоступные сервисы, остановка внутренних процессов, потери в выручке и рост операционных рисков. Чем сильнее компания зависит от цифровых систем, тем дороже обходится даже короткий сбой.
Именно поэтому в инфраструктуре всё чаще закладывают не просто резерв, а высокую доступность — архитектурный подход, при котором сервис продолжает работать даже после отказа отдельного узла, диска или части площадки.
Отказоустойчивый кластер — это группа серверов, объединенных в одну систему так, чтобы нагрузка не зависела от одного физического узла. Если один компонент выходит из строя, его задачи автоматически берут на себя остальные. Для бизнеса это означает не «идеальную систему без сбоев», а инфраструктуру, в которой сбой одного элемента не превращается в остановку сервиса.
Что такое отказоустойчивый кластер
Отказоустойчивый кластер — это архитектура, в которой несколько узлов работают совместно и подменяют друг друга при аварии. В отличие от обычного кластера, который часто собирают ради масштабирования или распределения нагрузки, кластер высокой доступности в первую очередь нужен для непрерывности работы.
Здесь важно не путать два близких, но разных понятия. Производительный кластер помогает обрабатывать больше запросов. HA-кластер помогает не потерять сервис, когда что-то сломалось.
Обычно такие решения оценивают через показатель доступности. Например, 99,9% допускает заметный годовой простой, 99,99% — уже существенно меньше. Но сама цифра ещё не гарантирует результат. Важнее то, как устроена инфраструктура: есть ли резерв по узлам, как устроено хранение, что происходит при потере связи между компонентами и насколько быстро система умеет восстановиться после сбоя. В ТЗ отдельно заложен акцент именно на downtime, коэффициент готовности и объяснение, зачем отказоустойчивый кластер нужен бизнесу.
На практике HA cluster используют там, где простой критичен:
- для баз данных и бизнес-приложений;
- для ERP- и CRM-систем;
- для веб-сервисов и клиентских кабинетов;
- для виртуальной инфраструктуры;
- для сервисов, которые должны работать круглосуточно.
Принцип работы отказоустойчивого кластера
В основе high availability cluster лежит довольно понятная логика: ресурсы распределены между несколькими узлами, а состояние системы постоянно контролируется. Когда один узел перестаёт отвечать, кластерная логика исключает его из работы и переносит его функции на доступные ресурсы.
Типовая архитектура включает:
- узлы кластера;
- сеть взаимодействия между ними;
- подсистему хранения;
- механизм контроля состояния и аварийного переключения.
В инфраструктуре vStack физические серверы объединяются в кластер, а каждый сервер в составе кластера становится узлом. При выходе узла из строя его ресурсы резервируются за счёт остальных узлов, а сам узел изолируется. Процедура failover выполняется кластерным фреймворком автоматически, без ручного вмешательства. Виртуальные машины продолжают работу на другом узле. Минимальное количество узлов в кластере — 4, а минимальный объём RAM на узел — 384 ГБ.
Именно так и работает failover cluster на практике. Пока все узлы доступны, нагрузка распределена штатно. Когда один узел перестаёт отвечать, система:
- фиксирует сбой;
- исключает проблемный узел из кластера;
- переносит его активные ресурсы;
- восстанавливает доступность сервиса на рабочих узлах.
Для пользователя это выглядит не как «падение всей системы», а как кратковременная деградация или короткая пауза в работе конкретного сервиса.
Схемы построения отказоустойчивых кластеров
Единой универсальной схемы нет. Выбор зависит от нагрузки, бюджета, требований к доступности и особенностей приложений.
Active-Passive
В схеме Active-Passive один узел обслуживает нагрузку, второй остаётся в резерве и ждёт аварийного переключения. Это самый понятный сценарий: резерв не участвует в работе постоянно, зато логика отказоустойчивости проще и предсказуемее.
Такую схему обычно выбирают там, где важнее надёжный резерв, чем максимальная утилизация железа. Например, для отдельных критичных сервисов, внутренних баз данных или систем, где важна понятная модель восстановления.
Минус здесь очевиден: часть ресурсов простаивает до момента сбоя.
Active-Active
В схеме Active-Active несколько узлов одновременно участвуют в обработке нагрузки. Это даёт более эффективное использование ресурсов и лучше подходит для масштабируемых сервисов.
Но цена этой гибкости — более высокие требования к архитектуре приложения и к согласованности данных. Если приложение плохо переносит параллельную работу на нескольких узлах, сама схема не решит проблему.
Такой подход чаще выбирают для сервисов с переменной или высокой нагрузкой, где нужно одновременно и распределение трафика, и отказоустойчивость.
N+1 и N+M резервирование
Эта модель особенно важна для масштабируемой инфраструктуры. Есть рабочая группа из N узлов и есть резерв — один или несколько дополнительных узлов. При отказе одного элемента кластер сохраняет работоспособность за счёт избыточности.
Во внутренней документации vStack избыточность описана как один из ключевых атрибутов кластера. Поддерживаются модели N+1, N+2 и N+3, а для промышленных инсталляций рекомендуется использовать избыточность N+2 и выше. При этом в кластере из 4 узлов возможна только схема N+1; N+2 начинается с 5 узлов.
Это важный практический момент. Если инфраструктура должна не просто «пережить один сбой», а сохранять запас устойчивости под обслуживание, деградацию железа и повторные аварии, проектировать кластер стоит сразу с нужным уровнем избыточности.
Требования к архитектуре приложений для HA-кластера
Даже правильно собранный HA-кластер не решает автоматически все проблемы приложения. Чтобы сервис действительно переживал сбои без заметной потери функциональности, сама прикладная архитектура должна быть к этому готова.
Проще всего живут stateless-приложения, где состояние пользователя не жёстко привязано к одному узлу. Их легче переносить между серверами и масштабировать горизонтально.
Со stateful-приложениями сложнее. Если приложение хранит состояние локально, жёстко привязано к конкретному хранилищу или не умеет корректно переживать перезапуск, одной кластерной логики мало. Нужно отдельно продумывать:
- как синхронизируются данные между узлами;
- где хранятся сессии;
- как работает база данных при переключении;
- как приложение ведёт себя после рестарта;
- какие сценарии отказа проверяются заранее.
Одна из типичных ошибок — считать, что отказоустойчивость заканчивается на уровне серверов. На практике сбой часто возникает не в железе, а в приложении, логике репликации или сетевом взаимодействии между компонентами. Поэтому тестирование отказоустойчивости — не формальность, а обязательная часть внедрения.
Ключевые компоненты и технологии
У любого HA-кластера есть несколько базовых слоёв:
- кластерная логика, которая следит за состоянием узлов;
- сеть для обмена служебной информацией;
- хранение данных с избыточностью;
- механизм переноса сервисов;
- средства мониторинга и управления.
В vStack каждый узел участвует сразу во всех основных ролях: вычисления, сеть и хранение объединены в одной платформе, а резервирование происходит на уровне всей инфраструктуры. При отказе узла кластер автоматически выполняет аварийное переключение, а ресурсы продолжают работу на других узлах. Такой подход упрощает архитектуру и снимает зависимость от отдельного слоя хранения как самостоятельной точки отказа.
Для растянутых кластеров требования жёстче: нужна устойчивая связь между площадками, минимальная задержка и контроль split-brain-сценариев. Во внутренней документации vStack такой сценарий описан отдельно: для stretched cluster используется quorum-сервер, а запись выполняется синхронно на обеих площадках.
Как создать отказоустойчивый кластер
Построение отказоустойчивого кластера начинается не с настройки узлов, а с проектирования.
Сначала определяют, какие сервисы действительно критичны, какой простой допустим, сколько данных можно потерять при аварии и какая схема резервирования нужна. Затем под это подбирают конфигурацию кластера, сетевую схему, требования к хранению и модель масштабирования.
Рабочая последовательность обычно выглядит так:
- определить требования к доступности и восстановлению;
- выбрать схему построения;
- заложить достаточную избыточность по узлам;
- спроектировать сеть и хранение;
- настроить логику failover;
- провести тесты аварийных сценариев под реальной нагрузкой.
Двухнодовая конфигурация
В vStack поддерживается работа кластера из двух узлов (2-node).
В такой конфигурации данные хранятся зеркально на обоих узлах, и при отказе одного из них нагрузка переключается на второй.
Этот вариант используется как базовый сценарий для небольших инсталляций или отдельных площадок.
При необходимости инфраструктура может быть расширена до многоузлового кластера.
Преимущества и ограничения HA-кластеров
Главный плюс отказоустойчивого кластера очевиден: он снижает вероятность полной остановки сервиса. Но есть и менее заметные эффекты.
Во-первых, обслуживание инфраструктуры становится безопаснее. Когда в системе есть запас по узлам и корректно настроен failover, часть работ можно выполнять без остановки сервиса.
Во-вторых, инфраструктура лучше переносит локальные аварии. Сбой одного сервера уже не превращается в инцидент масштаба всей площадки.
В-третьих, появляется более предсказуемая модель роста. Вместо постоянной борьбы с единичными точками отказа компания строит систему, в которой резерв заложен на уровне архитектуры.
Но ограничения тоже есть. Отказоустойчивый кластер:
- требует более тщательного проектирования;
- обходится дороже, чем одиночный сервер;
- предъявляет требования к сети, хранению и приложениям;
- не защищает от логических ошибок, багов в коде и некорректных изменений.
То есть HA — это не «магия против любых проблем», а способ убрать из архитектуры наиболее опасные сценарии отказа.
Отказоустойчивые кластеры в vStack
Для vStack эту тему логично раскрывать не как абстрактную теорию, а как практический способ построения отказоустойчивой ИТ-инфраструктуры. По внутренним вводным именно так платформу и рекомендуется позиционировать.
vStack объединяет узлы в единый кластер, в котором ресурсы серверов используются совместно. При отказе одного узла его ресурсы резервируются за счёт других, сам узел выводится из кластера, а виртуальные машины продолжают работу на другом узле. При этом минимальная конфигурация начинается с 4 узлов, а минимальный объём оперативной памяти составляет 384 ГБ на узел.
Для бизнеса это означает более простую модель внедрения отказоустойчивости:
- без сложной разрозненной инфраструктуры;
- с автоматическим failover;
- с централизованным управлением;
- с возможностью масштабировать кластер по мере роста нагрузки.
Отдельно важно, что в текущих внутренних рекомендациях для текстов о vStack нежелательно уводить рассказ в перечисление сторонних решений и технологической базы. Сильнее работает объяснение самой механики: как система ведёт себя при сбое, как распределяются ресурсы и за счёт чего сервис не останавливается.
Если задача — не просто описать HA на бумаге, а проверить, как такая архитектура будет работать на вашей нагрузке, логичный следующий шаг — пилот и тестирование сценариев отказа на платформе vStack.
Заключение
Отказоустойчивый кластер нужен не «крупным компаниям вообще», а любой инфраструктуре, где стоимость простоя выше стоимости правильной архитектуры. Если сервис критичен для выручки, клиентского опыта или внутренних процессов, high availability перестаёт быть опцией и становится базовым требованием.
При выборе схемы всё упирается в задачу. Для простых сценариев подойдёт Active-Passive. Для масштабируемых сервисов — Active-Active или модели N+1/N+M. Для производственной среды особенно важно закладывать не минимально возможную, а разумную избыточность с запасом.
Telegram
Facebook
Instagram
Twitter