Тупик масштабирования: как расширить кластер виртуализации без остановки бизнес‑сервисов

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

Добавить дополнительный хост? В теории — просто. На практике выясняется, что свободных портов для его подключения на СХД больше нет, SAN-схема проектировалась «на потом», и любое движение в этой конфигурации несёт реальный риск уронить прод.

В статье разбираем:

• как выйти из этого тупика без остановки сервисов и ночных инцидентов в субботу;
• реальный сценарий из нашей практики;
• математику отказоустойчивой архитектуры: ёмкость, деньги, риски;
• подводные камни, которые чаще всего ломают идею «без даунтайма» — особенно на отечественных платформах виртуализации, где часть функций и документации может вести себя… иначе, чем мы привыкли в мире VMware. 

История из практики: как «быстро и дёшево» обернулось проблемами через два года

Несколько лет назад мы запускали кластер виртуализации для регионального контура в энергетике. Заказчик — субъект КИИ, требования к непрерывности высокие, бюджет ограниченный, сроки — «вчера».

Сделали быстро: FC-подключение СХД напрямую к хостам, без FC-коммутаторов. Схема рабочая, для запуска в продакшен этого хватило.

Через два года картина изменилась:

• Кластер заполнили «под завязку» — запаса под N+1 и плановые работы нет.
• Потребовалось увеличение вычислительной мощности кластера путём добавления дополнительного хоста.
• Оказалось, что портов на СХД больше нет. Расширение упирается в переделку SAN-схемы: докупку FC-коммутаторов, изменение схемы FC-коммутации.

Переделывать SAN на живом проде возможно, но только по плану, с запасом, с откатом и с пониманием каждого шага.

Проблема не «экзотическая»: мы и ранее наблюдали ситуации, когда FC‑связность и вообще совместимость «российское железо + российская виртуализация» ведут себя неожиданно. Иногда решение упирается в изменение архитектуры (когда сервера не видят СХД, подключенную по FC point-to-point, и возникает необходимость  использования FC‑коммутаторов). 

Что должно быть правдой, чтобы расширение проходило без инцидента

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

Инженерные условия

Есть запас ёмкости
Нет запаса — нет бесшовности. Живая миграция упирается в физику: виртуальные машины (ВМ) должны куда-то уехать. Если остальные хосты не могут принять нагрузку, расширение без простоя невозможно.

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

Зонинг и SAN настроены по best practice
«Одна большая зона» удобна ровно до первого инцидента. IBM подчёркивает: зонинг по WWPN лучше, чем по WWNN — иначе возникают лишние пути и проблемы с мультипасингом.

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

Организационные условия

Есть RACI и зона ответственности 
Даже если вы расширяете кластер своими силами, вам нужен «контур принятия решений»: кто владелец сервиса, кто утверждает риски, кто даёт окно, кто коммуницирует с пользователями. Без этого даже технически идеальная операция может превратиться в инцидент, потому что кто-то «не знал» или «не согласовал».

Например, в нашей сервисной модели мы чётко фиксируем: CORTEL отвечает за эксплуатацию платформ, сетей, бэкапы, мониторинг и изменения по RFC; а заказчик — за политики доступа, бизнес-приоритеты и сами данные

Выстроен процесс изменений
Смысл процесса — оценивать влияние и риск изменений, сверяя их с бизнес‑приоритетами. Расширение кластера чаще всего затрагивает общую платформу, поэтому риск здесь мультисервисный.

Есть мониторинг и критерии готовности
Подход «пошли делать, а там посмотрим» — это полёт вслепую. Мониторинг 24/7, контроль работоспособности, обновления и масштабирование должны быть обязательными элементами эксплуатации. 

Инженерная математика: как объяснить бизнесу вложения в ИТ

Считаем стоимость часа простоя. Не все компоненты легко оценить, но даже грубая оценка дисциплинирует.

Стоимость простоя = потерянная выручка + простой людей + штрафы по SLA + восстановление + репутация

Условный пример:

• 400 сотрудников зависят от кластера, из них 250 реально не смогут работать при сбое.
• Стоимость часа сотрудника для компании — 1 200 ₽.
• Штрафы и потери по SLA — 300 000 ₽ в час.
• «Технический хвост» после инцидента (ручные операции, разбор) — 150 000 ₽ единоразово.

Простой на 2 часа:

• Люди: 250 × 1 200 × 2 = 600 000 ₽
• SLA: 300 000 × 2 = 600 000 ₽
• Хвост: 150 000 ₽

Итого — ≈ 1,35 млн ₽ за 2 часа (без учёта репутационных потерь).

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

Модель «запас ёмкости» для бесшовных работ

В своей практике мы используем двухуровневую модель запаса::

• N+1 — можно потерять один хост, и кластер продолжит жить.
• Запас под изменения — отдельный небольшой буфер на плановые работы, миграции, тяжёлые ВМ, всплески нагрузки.

Сколько нужно запаса для N+1

Пример: 4 хоста по 512 ГБ RAM, реальное потребление — 1 850 ГБ.

Чтобы пережить отказ одного хоста, рабочая ёмкость должна составлять 3 × 512 = 1 536 ГБ. А потребление уже 1 850. Вывод очевиден: N+1 не выполняется, любой вывод хоста — это риск.

Добавляем 5-й хост (ещё 512 ГБ):

• Суммарно: 2 560 ГБ.
• Рабочая ёмкость при N+1: 4 × 512 = 2 048 ГБ.
• Запас: 2 048 − 1 850 = 198 ГБ (около 10%).

Это уже «можно дышать», но для спокойной работы лучше целиться в 15–20% — особенно если в кластере живут базы данных или тяжёлые монолиты.

Дорожная карта расширения кластера без остановки сервисов

Логика универсальна для VMware, oVirt, KVM и других платформ: сначала создаём управляемость, потом меняем архитектуру, затем добавляем ресурсы.

Шаг 1. Аудит перед тем, как что-то делать

Расширение без простоя начинается с понимания, что сейчас есть. В экспресс-аудит входит:

• Инвентаризация хостов, ВМ, сетей, СХД.
• Фактические метрики нагрузки: CPU, RAM, пики, тренды — смотрим не на то, сколько ресурсов выделено, а сколько реально потребляется.
• Латентность и IOPS хранения, заполнение пулов.
• Карта зависимостей: какие ВМ держат критические контуры.
• Состояние бэкапов и тест восстановления — без этого откат остаётся на бумаге.
• Точки отказа: одиночные коммутаторы, аплинки.

Шаг 2. Проектирование целевой схемы

В нашем кейсе с энергетиками целевое решение выглядело так:

• Вводим FC-коммутаторы, строим dual-fabric.
• Переводим хосты и СХД на зонинг по best practice.
• Добавляем вычислительный узел (или несколько) так, чтобы вернуть запас N+1 и получить возможность спокойно выводить хосты в обслуживание по очереди.

Шаг 3. Создание запаса ёмкости

Если кластер перегружен, выход один из двух (иногда требуются оба):

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

Живая миграция работает только тогда, когда есть куда ехать.

Шаг 4. Работы по принципу «одно изменение за раз»

• Разворачиваем FC-коммутаторы без влияния на прод. Коммутаторы включены, прошивки обновлены, но в прод пока не включены.
• Настраиваем зонинг и алиасы. Готовим целевые группы путей. Алиасы упрощают управление и помогают балансировать нагрузку на порты СХД.
• Переводим один пилотный хост на новую схему. Главное правило: никогда не выключать последний рабочий путь. Сначала добавляем новый путь через коммутатор, убеждаемся в его стабильности — и только потом убираем старый.
• Проверяем, что живая миграция реально работает в контуре. Важно: делаем это до, а не во время.
• Идём хост за хостом.
  1. Переводим хост в сервисный режим, ВМ уезжают на другие узлы.
  2. Перекоммутируем/переконфигурируем SAN-связность этого хоста.
  3. Проверяем доступность LUN, ошибки.
  4. Возвращаем хост в строй.
  5. Берём следующий.

Шаг 5. Новые проверки и фиксация результата

• Обновить схему коммутации — актуальная документация это часть отказоустойчивости.
• Обновить CMDB и инвентаризацию.
• Зафиксировать лимиты: какую долю ёмкости можно занимать, что считается «красной зоной».
• Включить алерты на заполнение ёмкости.

Типичные ошибки и проблемы при «бесшовном» расширении

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

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

SAN без дисциплины. Оставить «одну большую зону» для экономии времени — решение, которое кажется удобным ровно до первого инцидента с потерей путей к СХД.

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

Бэкапы без теста восстановления. Правило 3-2-1 (три копии, два типа носителей, одна вне площадки) — базовая страховка. Но без реального теста восстановления фраза «У нас есть бэкапы» — это лишь самоуспокоение.

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

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