Настройка VMware vSphere: где ломается кластер
Кластер чаще ломается не на этапе установки, а на настройке отказоустойчивости: хост есть, хранилище подключено, виртуальные машины работают — до первого отказа гипервизора. В этот момент выясняется, что приоритеты перезапуска не заданы, а резервный хост либо отсутствует, либо на нём не хватает ресурсов. Простой инфраструктуры тогда измеряется не минутами, а временем до того, как дежурный инженер заметит проблему.
Единая точка отказа почти всегда прячется в одном из четырёх мест. Отдельный хост, который держит нагрузку, но не имеет пары в кластере. Общее хранилище, подключённое одним путём: отказ коммутатора или порта делает тома недоступными сразу для всех узлов. Управляющий узел или служба каталога в единственном экземпляре. И сеть, где трафик управления, миграции и виртуальных машин идёт по одним физическим каналам.
Ручной перезапуск виртуальных машин выглядит безопасным, пока отказов не было. На практике восстановление зависит от человека: ночь, выходные, отпуск — и сервис лежит до утра. Добавьте порядок запуска: база данных должна подняться раньше приложения, иначе приложение уйдёт в цикл перезапусков и добавит к простою ещё полчаса.
И отсутствие проверок отказа. Правила размещения, приоритеты перезапуска, резервирование путей и изоляция сети настраиваются один раз и не тестируются — а реальный отказ гипервизора вскрывает расхождение ожидаемого и фактического поведения. Разбираем, как это закрывается настройкой VMware vSphere: от схемы размещения до учений с принудительным выключением узла.
Что меняется после внедрения: простой, восстановление, отказы
Кластер на VMware vSphere оценивают не по числу настроенных узлов, а по тому, как ведут себя сервисы в момент отказа. Ниже — четыре метрики, которые мы снимаем до и после внедрения и по ним принимаем работу.
Время восстановления сервисов: минуты вместо часов
При отказе физического узла виртуальные машины автоматически поднимаются на оставшихся — сервис возвращается в строй за единицы минут, а не за время, пока дежурный доедет до площадки и вручную перенастроит запуск. Для критичных систем задаётся приоритет перезапуска: сначала поднимается то, от чего зависят остальные.
Устранённый класс отказов оборудования
Уходит целый класс аварий, связанных с одним узлом: выход из строя блока питания, диска, сетевого порта или канала к хранилищу больше не останавливает сервис. Арбитражный узел сохраняет кворум при потере основной площадки — кластер не распадается на две половины и не начинает конкурировать за ресурсы.
Автоматическое переключение без ручных операций
Доля ручных действий дежурного при отказе падает почти до нуля: перезапуск, выбор узла и возврат ресурсов выполняются правилами кластера. Человек остаётся в процессе только там, где нужно решение — например, откатить релиз после неудачного обновления.
Доступность сервисов и нагрузка на дежурного
Доступность считается по факту: доля времени, когда сервис отвечает, растёт за счёт того, что короткие отказы перестают превращаться в простой. Ночные подъёмы по тревоге сокращаются — большинство инцидентов закрывается автоматикой до того, как дежурный откроет телефон.
Режимы отказоустойчивости vSphere: что выбрать
Режим кластера определяют два ограничения: где лежат данные виртуальных машин и насколько далеко друг от друга узлы. Отсюда развилки — локальный диск или общее хранилище, одна площадка или две, один управляющий узел или кворум.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Отдельные узлы на локальных дисках | пилот, тестовый контур, изолированный сервис | миграция вручную, простой до восстановления из резервной копии |
| Кластер высокой доступности на общем хранилище | основной контур от трёх узлов | обязательны общий том и резервирование путей доступа, чувствительность к задержке до массива |
| Кластер высокой доступности и планирование размещения | разнородная нагрузка, разные классы сервисов | совместимые наборы инструкций на всех узлах, правила размещения задаются вручную |
| Растянутый кластер на две площадки | непрерывность при отказе площадки | третья площадка-свидетель, низкая задержка между площадками, синхронная репликация |
Число узлов подчиняется кворуму: в кластер высокой доступности берём не меньше трёх, чтобы потеря хоста не оставляла управляющий контур в неопределённом состоянии. Сеть разделяем на трафик управления и трафик хранилища — при общем томе это убирает конкуренцию за полосу и ложные срабатывания мониторинга.
Совместимость ограничивают четыре проверки до развёртывания: поддержка многопутевого доступа массивом, режим загрузки узлов, драйверы под выбранную ветку платформы и корректный кворум между площадками. Если хотя бы одна не проходит, режим понижается — это лучше выяснить на проектировании, чем при отказе.
Порядок внедрения: от аудита до передачи в эксплуатацию
Кластер не собирается по типовому шаблону: конфигурация зависит от числа хостов, класса хранилища и профиля нагрузки. Поэтому порядок работ фиксируем до старта, и каждый этап заканчивается проверяемым артефактом, а не отчётом о факте выполненных работ.
- Аудит инфраструктуры. Инвентаризируем хосты, сетевые сегменты, массивы и текущие виртуальные машины, снимаем карту зависимостей между сервисами. На выходе — перечень узких мест: перегруженные хранилища, одиночные пути к СХД, отсутствие резервирования на коммутаторах.
- Схема размещения узлов. Распределяем хосты по стойкам, зонам питания и сетевым парам так, чтобы отказ любого одного элемента не ронял кластер. Считаем резерв ресурсов под правило N+1 и правила балансировки.
- Подготовка платформы. Размечаем сети: служебный трафик, миграции, доступ к хранилищам через iSCSI или NFS, отдельные VLAN, согласованный размер кадра. Настраиваем профили хранилищ и политики отказоустойчивости.
- Конфигурирование кластера. Включаем высокую доступность с контролем резерва, задаём heartbeat-хранилища, приоритеты и порядок перезапуска виртуальных машин, изоляцию узла при потере связи.
- Проверка на стенде. Прогоняем тестовые нагрузки, плановые миграции и деградацию хранилища, замеряем время отклика под пиком. Правки вносим до вывода в продуктивную среду.
- Учения по отказу. По очереди выключаем хост, питание стойки, обрываем аплинк и имитируем недоступность массива. Фиксируем фактическое время перезапуска сервисов и потери данных.
- Передача в эксплуатацию. Отдаём регламенты обслуживания, карты восстановления, настроенный мониторинг и пороги оповещений, проводим обучение дежурной смены и согласуем окна работ.
Документация, схемы и политики доступа
Кластер передаётся не как «чёрный ящик»: вместе с работающими узлами вы получаете комплект материалов, по которому его можно обслуживать, расширять и восстанавливать без нас. Ниже — минимум, который мы фиксируем в конце работ.
- Схема размещения. Группы отказоустойчивости, где лежат данные кластера, какой запас ёмкости остаётся при отказе одного узла и как распределены машины по хостам.
- Схемы сетей. Разделение трафика управления, миграции, доступа к хранилищу и гостевого сегмента, резервные пути и агрегация каналов.
- Конфигурации. Выгрузки настроек узлов и общего слоя управления с пометкой, что изменено относительно заводских значений и зачем.
- Роли и права администраторов. Разграничение по зонам ответственности: сеть, запуск машин, чтение журналов. Сервисные задачи идут под отдельными учётными записями.
- Политики доступа. Точки входа в интерфейсы управления, обязательная многофакторная проверка, журналирование действий, отключение простаивающих записей.
- Регламент обслуживания. Периодичность обновлений, проверка дисков и датчиков, ревизия снимков и свободного места, порядок согласования окна работ.
- Регламент восстановления. Очерёдность подъёма, места хранения резервных копий настроек, проверка восстановления на тестовом контуре.
- Контроль состояния. Критичные события и пороги, кому приходят оповещения, типовые действия дежурной смены при отказе узла или пути.
Кейс: кластер выдержал отказ узла в рабочий день
Заказчик — производственная компания, где кластер виртуализации на VMware vSphere из шести узлов обслуживал около 120 виртуальных машин: учётные системы, файловый обмен, аналитику по цехам. Отказ одного хоста до работ означал ручной разбор — дежурный инженер поднимал виртуальные машины на уцелевших узлах, простой в рабочее время доходил до 40 минут, а порядок запуска зависел от того, кто первым заметил проблему.
Кластер пересобрали под автоматическое переключение: включили высокую доступность с приоритетами перезапуска, зарезервировали долю ресурсов под рестарт, чтобы уцелевшие узлы гарантированно приняли нагрузку, и вынесли сигналы доступности в отдельный сегмент сети. Виртуальные машины разложили по группам приоритета — сначала базы данных и контроллеры, затем второстепенные сервисы.
Отказ в середине рабочего дня
Через несколько недель после сдачи узел потерял питание в разгар смены. Кластер переключил машины автоматически: критичный контур был доступен через 2 минуты, остальные сервисы — за 4, порядок запуска выдержался без участия людей.
Метрики до и после: простой критичных сервисов — 40 минут против 2, полное восстановление — полтора часа против 4 минут, доля отказов, отработанных кластером без инженера, — 100%. Плановые работы теперь идут без окна обслуживания: узел выводят из кластера, обновляют и возвращают, а нагрузка едет на остальных.
Чем отличается отказоустойчивый кластер от резервного копирования?
Это два разных механизма с разными задачами, и один не заменяет другой. Отказоустойчивый кластер отвечает за непрерывность работы: при отказе физического сервера его виртуальные машины автоматически поднимаются на живых узлах, и сервис продолжает отвечать. Резервное копирование отвечает за защиту данных — возможность вернуть систему к состоянию на прошлый момент времени.
Кластер работает с текущим состоянием: общий пул ресурсов в VMware vSphere, распределение нагрузки, автоматический перезапуск при отказе. Простой сокращается до времени подъёма виртуальной машины — минуты вместо часов, пока инженеры чинят железо.
Но от логических ошибок кластер не защищает: если база удалена по ошибке, пришло шифрующее заражение или обновление испортило данные, реплика честно повторит это на всех узлах — откатывать будет нечего. Аппаратный отказ и потеря данных — разные классы сбоев, и защита от первого не закрывает второй.
Резервная копия хранится отдельно и фиксирует состояние на момент снятия: её можно развернуть на том же или другом кластере, поднять отдельную копию для проверки, восстановить один файл или систему целиком. Поэтому оба слоя планируем сразу — кластер, снапшоты для коротких операций и копии на независимом хранилище по расписанию.
Сценарии восстановления прописываем и проверяем на учениях: отказ узла, отказ площадки, ошибочное удаление, порча данных. Для каждого — свой источник восстановления и своё время, за которое сервис возвращается в работу.
Технические вопросы, которые задают до начала работ
Перед оценкой мы проходим по четырём вопросам, которые чаще всего меняют схему кластера. Ответы короткие, но именно они определяют, понадобится ли докупать оборудование и сколько окон обслуживания заложить в план подготовки к внедрению.
Подойдёт ли оборудование, которое уже стоит в стойке?
На этапе подготовки снимаем инвентаризацию: поддержка виртуализации в прошивке, объём памяти под нужную плотность машин, отдельные сетевые порты под трафик хранилища и живую миграцию. По результату говорим прямо, какие узлы пойдут в кластер, а какие останутся под тестовый контур.
Можно ли собрать отказоустойчивость без внешней системы хранения?
Да. Локальные диски каждого узла объединяются в отказоустойчивый пул, а данные реплицируются между серверами. При отказе одного узла машины поднимаются на остальных, но свободное место резервируется иначе — это учитываем при планировании ёмкости.
Как проходит плановое обслуживание без простоя?
По одному узлу: переводим виртуальные машины на свободные, выводим узел из кластера, обновляем гипервизор и прошивки, возвращаем обратно. Порядок узлов и окна обслуживания фиксируем заранее, чтобы не попадать в пиковые нагрузки.
Как убедиться, что переключение действительно работает?
Проверяем не по индикаторам, а имитацией отказа: обесточиваем узел или разрываем сеть и смотрим, за какое время поднялись критичные сервисы и не потерялись ли данные. Итог — отчёт с замеренным временем восстановления и списком замечаний.
Обсудим задачу: что нужно для оценки
Чтобы вернуться не с общими словами, а со схемой решения и планом работ, нам нужен срез текущей инфраструктуры. Ниже — минимальный набор; если чего-то нет, скажите сразу, подскажем, как это собрать.
- Состав кластера и нагрузка: число физических хостов, их поколение, размещение по стойкам и зонам, количество и профиль виртуальных машин, пиковые значения по процессору, памяти и диску.
- Хранилища: локальные диски, общая система хранения или программно-определяемая, какие уровни защиты данных настроены и как организованы резервные копии.
- Сеть: схема коммутации, разделение трафика управления, машин, миграции и хранения, наличие избыточных каналов и резервных путей.
- Требования к простоям: допустимое время недоступности сервисов, точки восстановления, что критично, а что можно перезапустить вручную.
- Доступы для обследования: учётные записи с правами только на чтение по хостам и системе управления (VMware vSphere), доступ к интерфейсам хранения и коммутаторов, окно на снятие метрик.
- Целевая задача и ограничения: новое развёртывание, переезд, разделение контуров или обновление платформы; окна работ и правила безопасности, которые нельзя нарушать.
Из этих данных складывается состав кластера, схема размещения и политики отказоустойчивости. Опишите задачу и пришлите то, что уже есть, — вернёмся со схемой решения, планом работ и оценкой.
