Многие администраторы виртуальной инфраструктуры VMware vSphere при планировании апгрейда не выясняют важных моментов, касающихся совместимости продуктов и так называемых "upgrade paths", то есть поддерживаемых производителем рабочих процессов обновления платформы.
В этой статье мы расскажем о том, что нужно выяснить перед апгрейдом, чтобы он прошел безболезненно и не пришлось делать экстренных откатов назад. Многие аспекты рассмотренного ниже процесса применимы не только к VMware vSphere, но и к любым другим продуктам виртуального датацентра.
1. Выясняем совместимость продуктов в датацентре (Interoperability)
Этот момент нужно выяснить одним из первых - что будет с другими продуктами, когда вы обновите платформу на следующую версию? Будут ли ее поддерживать другие продукты, и смогут ли они исполнять необходимые функции. Это называется Interoperability, а у VMware есть специальный ресурс VMware Product Interoperability Matrices, который позволяет вам определить совместимость конкретной версии продукта с выбранными версиями других продуктов виртуальном датацентре.
Например, выбрав VMware vCenter 6.7 Update 2, мы видим, что он совместим с версиями VMware ESXi 6.5 Update 2 и 6.0 Update 3, но не с ESXi 5.5 Update 3:
Помимо определения совместимости для продуктов VMware следует подумать и о совместимости стороннего ПО и прочих компонентов - например, средств резервного копирования, различных фреймворков и API, а также используемых в инфраструктуре скриптов. Нужно быть уверенным, что после апгрейда все это продолжит работать. Тут уже поможет только документация производителей.
2. Определяем пути апгрейда
На том же ресурсе VMware Product Interoperability Matrices есть вкладка Upgrade Path, которая позволяет вам понять, сможете ли вы сделать апгрейд напрямую на новую версию платформы или придется делать промежуточное обновление.
Вот здесь, например, мы видим возможные пути апгрейда VMware vCenter Server на новые версии:
Из таблицы видно, что vCenter 5.5 Update 2 нельзя напрямую обновить на vCenter 6.7 и более поздние версии. Причина в данном случае проста - код продукта слишком старый, и дорабатывать продукт для обеспечения возможности обновления с древних версий уже не было смысла.
Но если вы посмотрите на картинку выше, то обратите внимание, есть еще одна особенность апгрейда, когда версии не так уж и отличаются. Например, мы видим, что vCenter 6.5 Update 2 не обновляется на vCenter 6.7.
Причина тут такая - это так называемый Back-in-time Upgrade: версия vCenter 6.5 Update 2 вышла позже, чем vCenter 6.7, а значит новая база кода обновляется на старую. Об этом мы расскажем в следующем пункте.
Тут обязательно надо добавить еще один важный момент - многие администраторы предпочитают делать чистую установку новых мажорных версий ПО, чтобы не рисковать получить ошибки, связанные именно с апгрейдом с прошлой версии. Безусловно, это не всегда возможно ввиду наличия исторических данных, трудносоздаваемых конфигураций и прочего, но если у вас есть простой путь поставить новую версию продукта заново - это самый лучший и надежный способ.
Как мы уже сказали выше, обновление более нового кода на старый (как в случае vCenter 6.5 Update 2 и vCenter 6.7) называется Back-in-time Upgrade. Это может привести к возникновению "регрессионных ошибок" (regression bugs) после апгрейда. Например, в базу vCenter 6.5 Update 2 было добавлено новое поле или удалено старое, а vCenter 6.7 об этом еще не знает, так как был выпущен раньше, хоть и версия у него выше.
В то же время, VMware допускает некоторые такие ситуации, но предупреждает об определенных рисках возникновения регрессионных ошибок. Например, вы можете обновить VMware vSphere 6.5 Update 2d (выпущен 29 ноября 2018) на vSphere 6.7 Update 1 (выпущен 16 Октября 2018).
Чтобы понимать такие ситуации с определенными номерами билдов, есть статья базы знаний VMware KB 67077, где приведены матрицы поддержки таких апгрейдов, используя которые вы сможете выяснить поддерживается ли в вашей ситуации Back-in-time Upgrade.
В этих матрицах мы видим конкретные номера и даты релизов, включая минорные обновления для апдейтов vCenter и ESXi, такие как, например, 6.5.0 Update 3f (билд 15259038):
4. Проверяем, что оборудование серверов VMware ESXi находится в списке совместимости
Перед любым апгрейдом вашей виртуальной инфраструктуры стандартной процедурой является проверка совместимости оборудования серверов VMware ESXi в списке VMware Compatibility Guide (ранее он назывался HCL - Hardware Compatibility List), на которых вы будете делать обновление платформы.
Надо понимать, что если вы установите ESXi на неподдерживаемый сервер, то последствия могут быть самые разные. Например, у вас будет работать только один сетевой адаптер из двух, и вы не будете понимать почему. А дело будет в том, что из состава дистрибутивов ESXi постепенно изымаются драйверы устаревших устройств и добавляются драйверы последних моделей оборудования разных вендоров.
Также не забывайте о том, что если вы используете серверы таких производителей, как HP, Dell и прочие big names, то для них всегда лучше использовать кастомизированные образы. Вот, например, таковые для серверов HPE.
5. Планируем рабочий процесс апгрейда
После того, как вы поняли, что нужный путь апгрейда вам подходит, нужно разработать внутренний регламент обновления, который предусматривает не только основные шаги непосредственно по апгрейду, но и порядок действий на случай, если что-то пойдет не так (о процедуре отката обновления vCenter рассказано тут). Нельзя забывать также и о создании резервной копии вашей конфигурации перед обновлением.
Помните, что делая апгрейд VMware vSphere, мы сначала обновляем управляющие серверы vCenter, а только потом хосты ESXi. Апгрейд vCenter нужно начать с прочтения вот этого раздела документации VMware, а сама схема выглядит следующим образом:
Если у вас сервер vCenter на базе Windows, то нужно использовать утилиты Migration Assistant и Migration Tool, которые проведут вас по шагам переезда на виртуальный модуль vCenter Server Appliance (vCSA). VMware рекомендует выполнить 2 основных шага для миграции с vCenter на vCSA:
Migration Assistant - консольная утилита, которую нужно выполнить до мастера миграции vCenter. Она выясняет соответствие требованиям к миграции и показывает дальнейшие шаги.
Migration Tool - это мастер миграции, который доступен из основного дистрибутива vCenter.
В общем случае алгоритм апгрейда vCenter выглядит следующим образом (подробнее описано тут):
Не забудьте про апгрейд виртуальных машин (Virtual Hardware) после миграции!
Сам апгрейд VMware ESXi можно сделать одним из трех способов:
Ручная установка ESXi через графический интерфейс, с помощью CLI или сценариев
Апгрейд хостов с помощью механизма Auto Deploy
Обновление с использованием vSphere Lifecycle Manager (он пришел на смену Update Manager)
6. Выполняем основные процедуры после апгрейда
Если вы успешно обновили компоненты инфраструктуры VMware vSphere, то не стоит думать, что почти вся работа закончена, нужно выполнить еще post-upgrade procedures. Для сервера vCenter они включают в себя (см. вот этот раздел документации):
Проверьте, что миграция прошла успешно (подробнее тут).
Залогиньтесь в vCenter с использованием vSphere Client (подробнее тут).
Выведите из эксплуатации старый Platform Services Controller (подробнее тут).
Выполните реконфигурацию компонентов, которая требуется после апгрейда.
Убедитесь, что процесс идентификации и аутентификации работает корректно.
Если вы смигрировали vCenter Server on Windows на vCSA, то потребуется пересоздать локальных пользователей ОС в vCenter Single Sign-On и назначить им требуемые права доступа. Также прочитайте вот это руководство.
Не забудьте проверить и обновить все дополнительные модули и плагины, которые вы используете в vCenter (подробнее тут).
Посмотрите исторические данные процедуры миграции, если это необходимо (подробнее тут).
Для VMware ESXi процедуры после апгрейда выглядят так (документация находится вот тут):
Посмотрите логи апгрейда, выгрузить их можно через vSphere Client.
После апгрейда хост нужно повторно подключить в vCenter, выбрав пункт "Connect" из контекстного меню хоста ESXi.
Назначьте лицензию VMware ESXi. Загрузить ее можно с портала My VMware.
Устройства host sdX должны быть переконфигурированы после апгрейда. Также обратите внимание на скрипты, использующие номера этих устройств - эти номера будут изменены.
Обновите виртуальные машин в плане аппаратного обеспечения (Virtual Hardware Version) через vSphere Client или Lifecycle Manager.
Настройте службу vSphere Authentication Proxy (прошлые версии этой службы не совместимы с VMware vSphere 7.0). Подробнее об этом написано тут.
RSS
