Обновление аппаратной части — неизбежная задача в рамках управления жизненным циклом дата-центра. В существующих кластерах vSAN могут работать серверы, приближающиеся к окончанию срока поддержки со стороны производителя, либо просто переставшие соответствовать техническим требованиям организации.
Самая распространённая стратегия замены серверов — развернуть полностью новый кластер и перенести нагрузки с одного кластера на другой средствами vMotion. Однако иногда возникает потребность заменить старое оборудование новым, сохранив при этом сам кластер, чтобы не потерять его настройки или сервисы данных. В этом случае встаёт вопрос: «Следует ли добавлять и выводить серверы из кластера по одному, или же нужно сначала добавить все новые серверы, а затем вывести из эксплуатации старые?»
Варианты обновления серверов внутри кластера vSAN
vSAN предоставляет широкие возможности для аппаратного обновления практически любого типа. Когда устаревающие серверы заменяются новыми с сохранением существующего кластера, доступные варианты в целом делятся на три категории.
Массовое добавление и поэтапный вывод. Все новые серверы последовательно добавляются в существующий кластер, а старые хосты выводятся из эксплуатации по одному.
Поэтапное добавление и поэтапный вывод с повторением цикла. В существующий кластер добавляется один новый сервер, после чего выводится один старый хост. Процесс повторяется до полного завершения.
Групповое добавление и поэтапный вывод с повторением цикла. В существующий кластер добавляется группа новых серверов, после чего по одному выводится столько же старых хостов, сколько было добавлено. Цикл повторяется до завершения обновления.
Под выводом из эксплуатации здесь понимается перевод одного из старых хостов в режим обслуживания с принудительным пересозданием данных в другом месте, чтобы восстановить заданный уровень отказоустойчивости. После завершения этой операции хост удаляется из кластера нажатием «Remove from inventory» в vSphere Client.
Какой подход оптимален? Ответ зависит от особенностей конкретной среды, поэтому стоит рассмотреть каждый из вариантов подробнее.
Как vSAN распределяет данные по кластеру
Прежде чем детально разбирать варианты, полезно вспомнить, каким образом vSAN обеспечивает отказоустойчивое распределение данных по кластеру. В приведённых примерах предполагается стандартный односайтовый кластер vSAN.
Менеджер объектов vSAN определяет размещение данных при развёртывании, эвакуации и ребалансировке, опираясь на следующие критерии:
Хосты, пригодные для размещения данных. vSAN применяет логику anti-affinity для избыточных данных, гарантируя, что компоненты объекта, обеспечивающие отказоустойчивость (зеркалированные данные или данные чётности при использовании кода коррекции ошибок), никогда не окажутся на одном и том же хосте.
Доступная ёмкость хоста внутри кластера vSAN. vSAN отдаёт предпочтение хостам с большим объёмом свободного пространства перед хостами, где его меньше.
Как показано на рисунке 1, логика анти-аффинности vSAN не допускает размещения на одном хосте компонентов, обеспечивающих отказоустойчивость объекта с политикой RAID-6. При эвакуации хоста vSAN разместит большую часть переносимых данных на новом, относительно пустом хосте. Но по мере выравнивания заполненности между хостами vSAN может разместить часть эвакуируемых компонентов на других подходящих хостах, которые ещё предстоит вывести из эксплуатации. Именно поэтому добавление всего одного хоста с последующим удалением старого иногда порождает избыточный трафик ресинхронизации при дальнейшем выводе серверов. Добавление двух и более хостов за раз снижает вероятность такого сценария.
Рисунок 1. Принцип перераспределения данных в vSAN при выводе хоста из эксплуатации.
Эти критерии и сопровождающий их пример помогают лучше понять, как разные подходы влияют на размещение и перемещение данных в процессе обновления оборудования.
Вариант 1: массовое добавление и поэтапный вывод
В этом сценарии все новые серверы добавляются в кластер до того, как старые хосты начинают выводиться из эксплуатации по одному.
Преимущества. Такой подход работает при наличии свободных физических ресурсов. Правила размещения данных vSAN обрабатывают эту ситуацию максимально просто. При окончательном выводе хоста данные будут пересозданы на одном из новых хостов, поскольку: 1) новые хосты подходят для приёма мигрирующих данных, так как это не нарушает правил анти-аффинности и сохраняет отказоустойчивость и доступность; 2) новые хосты обладают большим объёмом свободной ёмкости, чем старые. Это снижает вероятность повторного перемещения уже перенесённых данных при выводе следующих хостов.
Недостатки. Такой сценарий сложно реализовать в крупных кластерах, где одновременное добавление всех новых хостов может превысить доступное место в стойках, количество сетевых портов или лимиты по электропитанию. Возможно даже превышение максимально допустимого числа хостов для конкретной топологии кластера (64 хоста для стандартного кластера и 40 хостов для растянутого).
Когда применять. Из-за перечисленных требований этот вариант малопригоден для чего-либо, кроме обновления небольших кластеров при наличии достаточного свободного места в стойках, запаса по питанию и сетевой ёмкости.
Вариант 2: поэтапное добавление и поэтапный вывод
В этом сценарии после добавления в кластер одного нового хоста из него выводится один старый. Цикл повторяется до завершения обновления.
Преимущества. Этот вариант позволяет обновить кластер в условиях жёстких физических ограничений — например, при нехватке места в стойках для установки новых серверов или при дефиците свободных портов на коммутаторах ToR.
Недостатки. В зависимости от обстоятельств такой подход может повысить вероятность повторного перемещения уже перенесённых данных при выводе следующих хостов, как показано на рисунке 1. vSAN перераспределяет данные автоматически, но добавление и удаление по одному хосту за раз способно породить дополнительный объём перемещений.
Когда применять. Для сред с жёсткими физическими ограничениями это может быть единственным или наилучшим доступным вариантом. Потенциальная неэффективность в части перемещения данных делает его менее предпочтительным в обычных условиях.
Вариант 3: групповое добавление и поэтапный вывод
Этот подход сочетает два предыдущих: в кластер добавляется группа хостов (два или более — в зависимости от общего числа хостов в кластере), после чего выводится столько же старых хостов, сколько было добавлено новых. Цикл повторяется до завершения обновления.
Преимущества. Добавление группы хостов даёт выводимому из эксплуатации хосту несколько новых целевых площадок с достаточным запасом свободной ёмкости и при этом соблюдает логику анти-аффинности, обеспечивающую отказоустойчивость данных. Это сводит к минимуму вероятность вторичного перемещения данных при выводе последующих хостов.
Недостатки. Потребуется больше физических ресурсов (места в стойках, электропитания и сетевых портов), чем при варианте 2, но существенно меньше, чем при варианте 1.
Когда применять. Это оптимальный вариант для большинства сред. Он сочетает достоинства массового добавления хостов, не требуя при этом соответствующего объёма физических ресурсов. Кроме того, он минимизирует риск того, что перенесённые данные окажутся на старых хостах, которые впоследствии придётся эвакуировать повторно.
Рекомендации
Независимо от выбранного подхода, приведённые ниже рекомендации помогут сделать процесс плавным и предсказуемым.
1. Добавляйте от двух до шести хостов за раз перед выводом старых. Для небольших кластеров, состоящих, например, всего из трёх хостов, следует добавить два хоста до вывода любого из старых. Для кластеров с включённым Auto-RAID это позволит сохранить использование кода коррекции ошибок RAID-5 вместо автоматической (но временной) переконфигурации в RAID-6 на время обновления. Для кластеров из шести и более хостов добавление двух-трёх хостов перед выводом старых становится эффективным способом минимизировать лишнее перетасовывание данных при обновлении остальной части кластера. Добавление шести хостов за раз позволит операциям развёртывания — созданию новых виртуальных машин или постоянных томов — размещать объект целиком на новых хостах, а не частично на тех, которые ещё предстоит вывести.
2. Учитывайте поведение Auto-RAID в небольших кластерах. При работе Auto-RAID в vSAN для VMware Cloud Foundation (VCF) 9.1 добавление хостов в небольшой кластер, использующий код коррекции ошибок RAID-5, может увеличить число хостов до значения, при котором данные в итоге переконфигурируются под RAID-6 (например, при добавлении двух хостов в кластер из четырёх). В этой ситуации следует просто продолжать по плану и выводить старые хосты после добавления новых. В зависимости от обстоятельств можно либо добавлять новые хосты небольшими порциями, либо предоставить vSAN выполнить переконфигурацию автоматически.
3. Продумывайте физическое размещение новых хостов. Не стоит произвольно распределять хосты кластера vSAN по нескольким стойкам — это способно породить больший объём сетевого трафика, чем требуется. Подробнее об этом рассказано в материале «vSAN Networking – Optimal Placement of Hosts in Racks».
4. Временно отключите функцию «Automatic Rebalance» в vSAN. Если она включена (по умолчанию она отключена), на время обновления её стоит временно деактивировать, чтобы предотвратить преждевременное перемещение данных. Функцию Automatic Rebalance можно снова включить после завершения обновления.
5. Распознавайте сценарии, где вывод хоста должен предшествовать добавлению новых. Изменение порядка шагов, при котором один или несколько хостов удаляются из инвентаря до добавления новых, применимо для кластеров в стойках, где нет свободного места или сетевых ресурсов. Это сработает только в том случае, если уровень заполнения достаточно низок, чтобы выдержать временное сокращение ёмкости, и может вызвать больший объём перемещения данных, чем описанные выше варианты. Кроме того, такой порядок может оказаться неоптимальным для кластеров из шести и более хостов, поскольку способен временно изменить уровень отказоустойчивости, автоматически назначаемый механизмом Auto-RAID.
6. Используйте режим «Full data migration» при выводе хостов. При переводе хоста в режим обслуживания следует выбирать «Full data migration», чтобы данные были пересозданы немедленно и отказоустойчивость сохранялась. Вариант «Ensure accessibility» тоже работоспособен, однако пересоздание данных в этом случае обычно откладывается на час.
7. Действуйте последовательно при выводе хостов. Прежде чем выводить следующий хост, необходимо дождаться завершения всех операций ресинхронизации. Это ограничит объём одновременно синхронизируемых данных.
8, Если вы всё ещё используете vSAN OSA, воспользуйтесь возможностью перейти на ESA. Аппаратное обновление — идеальный момент для перехода с vSAN OSA на ESA, однако переход на ESA потребует развёртывания нового кластера и переноса нагрузок стандартными методами, такими как vMotion. При этом отсутствие нового оборудования не должно становиться препятствием для перехода на vSAN ESA: многие серверы с более старыми версиями vSphere легко перепрофилируются под хосты vSAN ESA — достаточно добавить накопители NVMe. Подробности приведены в материалах «Repurposing ESX Servers for VMware vSAN» и «The 2026 Structural Supply Crisis: Why VMware Cloud Foundation Is The Answer to the 2026 Hardware Crunch».
Заключение
В большинстве случаев создание нового кластера vSAN для ввода новых серверов в эксплуатацию остаётся простым и предсказуемым путём аппаратного обновления. Но бывают ситуации, когда замена серверов внутри существующего кластера оказывается оправданной. Теперь у администраторов есть информация и перечень вариантов, позволяющих принять верное решение для своей среды.
RSS
