Обновление VMware vCenter путем его замены

mr_orangeV прислал статью о своём опыте замены VMware vCenter.  С небольшой редактурой публикую. Юмор автора местами сохранён.

В последнее время читаю много однотипных историй «у нас ESXi 5.1/5.5 /6 – как нам жить дальше или  на что-то переехать?» Расскажу свою историю, может кому-то поможет.
Нам достался подряд на обследование и модернизацию инфрастуктуры одной организации. Беглый осмотр показал следующее:

  • десяток разных серверов (с разными процессорами) на ESXi 6.0/6.5/6.7;
  • некая СХД, работающая по протоколам NFS/iSCSI;
  • невнятная сеть почти без деления (лучше бы было совсем без деления, так как я такого ужаса еще не видел).
  • VMware vCenter 6.5 на Windows, обновленный последний раз очень давно;
  • полное отсутствие документации «что, где, куда и почему»;
  • под сотню виртуальных машин, которые, конечно же, все очень важные и нужные. И тоже без обновлений! Настоящие админы до второго сервис пака не обновляют, но с Windows Server 2016/2019 есть проблема при таком подходе.
  • cостояние резервного копирования неочевидно.

Для ликвидация хаоса были предприняты следующие шаги:

Шаг 1. Детальная инвентаризация железа

Проблема с инвентаризацией путем ручного прощелкивания хостов в vCenter –очевидна. Это долго, это неудобно. На помощь, как всегда, приходит VMware PowerCLI – это модуль для Powershell (PS) с готовым набором командлетов для продуктов VMware. Для понимания скриптов в статье необходимы базовые знания работы PS (способность сделать $a | Get-Member, $a[0] | Format-List и $a | ft, знакомство с циклами (foreeach) и фильтрами (Where-object)).
Сначала была проведена поверхностная инвентаризация. Это просто — берем в руки powershell, ставим PowerCLI:

  • Запускаем интегрированную среду сценариев PS через ярлык либо Пуск – Выполнить –powershell ise.
    Совет: лучше использовать vscode, но powershell ise идет в комплекте с Windows.
  • Запускаем командлеты в PS:



Из названия командлета неочевидно, но Connect-VIServer работает как с отдельными хостами, так и с vCenter целиком, отличается только набор доступных команд для хоста, поэтому заводим сразу и vCenter, и какой-нибудь host:

Как обычно,  получаем ошибку:

Выглядит это страшно и ужасно, картинки тут, поэтому добавляем в наш скрипт перед подключением:

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

При необходимости добавляем нужные поля. Сразу же копируем данные в любую таблицу – хоть Excel, хоть Calc. Тут же можно сделать get-vm и посмотреть на список VM.

Шаг 2 Детализация и проверка совместимости

Идем на Intel ark и уточняем спецификации используемых процессоров. Записываем в нашу таблицу.

На VMware HCL ищем наши процессоры (точнее, выбираем CPU в выпадающем списке, а затем series), выписываем последний возможный уровень ESXi. В частности, для много лет любимого Intel Xeon 56xx Series Supported Releases — 6.5. Знающие люди говорят, что возможно и 6.7 (проверено сообществом), и 7.0 (не стоит оно того), но официально предел 6.5, дальше «не проверено производителем».

Если с процессором все хорошо, то аналогично проверяем сетевые карты, FC-, RAID-контроллеры и так далее.

Если железо от HPE, Lenovo, Dell или другой фирменной сборки, то проверяем сервер целиком.

Связана такая проверка с тем, что в ESXi 7.0 поменяли работу с драйверами:

Deprecation of VMKLinux

In vSphere 7.0, VMKLinux driver compatibility has been deprecated and removed. vSphere 7.0 will not contain support for VMKLinux APIs and associated VMKLinux drivers. Custom ISO will not be able to have any VMKLinux async drivers. All drivers contained in an ISO must be native drivers. All currently supported devices which are not supported by native drivers will not function and will not be recognized during installation or upgrade. VCG will not show any devices not supported by a native driver as supported in vSphere 7.0. VMware vSphere 7.0 Release Notes

Ещё недавно вышел пакет Community Networking Driver for ESXi (раз, два) — тоже проверяйте.

Совет: Крайне желательно выделить свободный сервер и пробовать новые версии ПО на нем, а не на боевой среде.

Совет: Для проверки можно воспользоваться автоматическим скриптом на Python – ESXi Compatibility Checker.

Шаг 3. Сбор данных с имеющейся инфраструктуры

В первую очередь нам нужны данные по сетям с точки зрения VMware. Для этого у нас есть командлет Get-VirtualPortGroup:

(В следующей серии статей: злой брат близнец New-VirtualPortGroup и классы).

Затем стоит собрать данные по правам (хотя в таких запутанных инфраструктурах проще будет махнуть шашкой по заветам Александра Македонского – собрать права с нуля, учитывая классические ошибки – заведение прав «на пользователя», с его последующим увольнением, гранулярные кривые права на отдельные VM и так далее) и собрать информацию о системе резервного копирования (СРК), (которая, скорее, всего тоже будет модернизироваться). Смотрите лист совместимости для СРК, не все системы официально работают с vSphere 7.0.

Шаг 4. Глубины понимания

Для проверки совместимости продуктов VMware между собой нам нужна VMware Product Interoperability Matrices, где видно, что VMware vCenter Server 7.0 U1 поддерживает весь 6.5, а 6.7 U3 — до 6.0. Не пренебрегайте чекбоксом Hide unsupported releases — для версий типа 5.5.

После обдумывания ситуации получаем решение: что на что переставляем, обновляем и докупаем, а что проще списать по старости. Отсюда же может возникнуть вопрос, что купить и в каком объеме, начиная от памяти в сервера, заканчивая новой СРК.

Докупаем. Лицензируемся.

Важные вопросы для самостоятельного изучения:

  • можно ли поставить  vCenter 7.0u1 на ESXi 6.5/6.7?
  • можно ли оставить  ESXi 6.5 , но введя туда хосты 7.0/7.0u1?

Ответы предполагается получить самостоятельно.

Шаг 5. Построение новой архитектуры

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

С другой стороны, научитесь с сетями – научитесь и с остальным, в частности с хранением данных – политиками MPIO и использованием ANO. Напоминаю, что не все типы хранения поддерживают MPIO (вопрос про MPIO NFS3 и NFS4 предлагается разобрать самостоятельно).

Отдельно надо заметить непреходящую любовь сетевиков к построению LACP / LAG / MLAG до vswitch.

Дадим слово другой стороне:

Let me clarify the “logical link can utilize all the available bandwidth” feature: LACP is using IP Hashing for its load balancing algoritme, which means that a single network flow cannot exceed the bandwidth of a single physical connection.

 So why do some customer still use LACP you might ask? Usually it is because of the a lack of (VMware-) knowledge and add up the good experiences with LACP from the past by network admins.

 LACP between switches and bare-metal servers are still a very good option, but VMWare offers some enhancement which neglect the use of LACP for vSphere environments.

LACP and vSphere (ESXi) hosts: not a very good marriage

Делать или не делать LACP – выбор исключительно ваш, особенно учитывая риски нахватать проблем со стороны сети. Например:

Cisco Bug: CSCur07262 – N7K LACP PO do not recover after system switchover

Для упрощения работы с сетями необходимо ознакомиться с простой и давно известной в PS вещи – классами.

Пример кода для понимания

Делаем табличку вида:

Добавление на хост:

Шаг 6. Обновление FW хостов в ходе миграции

Если вы внимательно делали шаг 2, то увидели прошивки (firmware) и версии драйверов.

Зачастую для ESXi 7 нужно обновить прошивки оборудования.

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

На относительно свежие сервера HPE уже не выпускается Service Pack for Proliant (SPP). Кроме того, лет 5 назад SPP был доступен бесплатно, сейчас – только по подписке.

У всех вендоров встречаются свои странности в работе IPMI – например, на HPE имеется HTML5 клиент, но он не работает с ISO, связь рвется через пару минут –  используйте Java. Плюс для массового обновления HPE надо отдельно разворачивать OpenView или oneview (или вручную, привет SPP). У HPE есть Lights-Out Standalone Remote Console for Windows, который я пока так и не проверил. Dell/Lenovo идут со своими чудесами. На IBM (старых, еще IBM) – IPMI крайне чувствителен к версии Java, порой до того, что надо ставить точно такую и именно такую. Архивы Java тут.

У Supermicro обновления надо искать каким-то очень специфическим образом.

У Huawei отличная утилита Smartkit (SmartKit_V2R7C00RC6SPC300.zip) из состава Fusion tools , но путь до страницы Intelligent Servers неочевиден, как и недавнее обновление Enterprise сайта в попытке сделать лучше. Теперь надо не забывать нажимать справа Большую Красную Кнопку pre-version. Впрочем, кнопка есть.

Обязательное условие для любого вендора и любых обновлений: наличие действующей поддержки от вендора. Очень желательно проведение предварительной консультации и анализа сервера, особенно старого. Особенно необходима проверка Intel Fault Diagnosis and Management (FDM).

Обратите внимание, что у VMware есть ванильная версия ESXi и вендорские (от перечисленных выше производителей). HPE сделали умнее всех, и у них теперь две вендорские версии – для серверов поновее, и для серверов постарее. На версии постарее можно поймать фиолетовый экран просто так, от какого-то более нового драйвера, так что может оказаться, что надо ставить ванильную версию. У DELL свои веселые шутки за сто.

 Шаг 7. Перенос VM

После того, как параллельная инфраструктура построена, проверена и работает, система резервного копирования (СРК) заведена и новый disaster recovery plan (DRP) в наличии  — начинаем перенос хостов и виртуальных машин. Разумеется, перед переносом:

  • Надо сделать (и проверить) хоть какой-то disaster recovery plan (DRP) — план восстановления, если что-то пойдет не так.
  • Надо получить список виртуальных машин и как-то их отсортировать в порядке значимости. Можно (и нужно) сделать 1-2 тестовые виртуальные машины, только под проверку работы переноса.

Одновременно с переносом хостов желательно проводить и обновление самих хостов, хоть через VUM, хоть через ручное обновление путем закачки zip. Ничего сложного в процедуре нет, главное не забывать ОТКЛЮЧАТЬ LUN на время обновлений (если вы обновляете автоматически и между версиями).

При обновлении (U2-U3 например) надо обновляться до последней версии и все равно быть готовым к сюрпризам. Например, пару лет назад в свежем патче была проблема «-1», заканчивавшаяся остановкой vCenter. Читать: 503 Service Unavailable” error on the vSphere Web Client when logging in or accessing the vCenter Server (67818) – ESXi 6.7 Update 3 build 14320388–503 Service Unavailable и Excessive Hardware health alarms being triggered for “Sensor -1 type” on ESXi hosts running vSphere 6.7 U3 (74607)

До недавнего времени выбор метода переноса VM был не очень широк. Можно было переносить с перезагрузкой, а именно — выключаем VM, удаляем из инвентаря, добавляем на новом инвентаре, включаем. Перенос VM вместе с хостом — попробуйте, удивитесь, особенно при наличии EVC (примечание: читайте ссылки в рекомендованной литературе).

Относительно недавно появилась утилита Cross vCenter Workload Migration Utility, а теперь её добавили в сам vCenter — vSphere 7.0 U1c you can use The Advanced Cross vCenter Server vMotion (XVM) capability, в котором нас интересует раздел The Importing VMs Option. Дополнительные статьи тут и тут

Можно переносить и средствами резервного копирования — например, Veeam BR Quick Migration

В процессе переноса уточняете, что это за виртуальные машины, чьи они, нужны ли они, кто владелец.

Поля Notes помогут – если они заполнены.

Рекомендованная литература

Как построить ракетный ускоритель для скриптов PowerCLI

Переход на VMware vSphere 6.7


How to move ESXi/ESX host from one vCenter Server to another (1004775)
Cannot add an ESX/ESXi host with running virtual machines to an EVC enabled Cluster (1009571)
vSphere 6.7: hot migrate VMs to different clusters with vMotion

Moving ESX Hosts between Clusters

Leave a Reply

Your email address will not be published. Required fields are marked *