Администраторы платформы виртуализации VMware vSphere в рамках ежедневной рутины занимаются процессами обновлений виртуальной инфраструктуры и ее компонентов путем накатывания патчей или проведения апгрейдов (в том числе наиболее сложных - на новые мажорные версии). Наиболее удобный способ делать это - использовать решение vSphere Lifecycle Manager (vLCM), который автоматизирует этот процесс. Это следующее поколение продукта vSphere Update Manager (VUM), который ранее использовался для планирования и накатывания обновлений. С помощью него можно обновлять не только гипервизор ESXi, но и драйверы и микрокод, а сами обновления проходят по модели desired-state конфигураций.
Сегодня мы поговорим о процессе патчинга/апгрейда самой платформы VMware vSphere, а точнее о проблемах которые могут возникнуть и лучших практиках, которые нужно имплементировать в вашей организации, чтобы все проходило быстро и без проблем.
Подготовка к обновлению виртуальной среды
Сначала убедитесь в доступности учетных записей администратора vCenter Server Appliance и SSO Administrator (administrator@vsphere.local). По умолчанию, учетная запись VCSA root блокируется после 90 дней неактивности, что может иногда создать проблемы. Обратите внимание, что для восстановления пароля может потребоваться перезапуск сервера vCenter. Также иногда рекомендуется обновлять пароли после технического обслуживания компонентов инфраструктуры.
Нужно обеспечить прямой доступ к хосту ESXi для создания снимков vCenter и компонентов Platform Services Controllers в выключенном состоянии (это требуется в vSphere 6.7 и более ранних версиях) и в целях диагностики. Убедитесь, что у вас работает доступ к хостам с правами администратора.
Если что-то раньше шло не так - дважды проверьте сервисы DNS. Убедитесь, что записи A (прямой) и PTR (обратный) DNS для vCenter Server, ESXi и других устройств корректно разрешаются. Эта простая проверка занимает секунды, но предотвратит проблемы во время патчей и обновлений. Также проверьте и службу NTP - убедитесь в правильности настроек для всех компонентов виртуальной среды, включая ESXi, vCenter Server, SDDC Manager, устройства, хранилища и коммутаторы. Многие необъяснимые на первый взгляд проблемы возникают именно из-за некорректной синхронизации времени.
Проверьте алармы, которые есть на серверах vCenter и ESXi. Проверьте и устраните предупреждения проверок vSAN Health Checks, которые могут помешать автоматизированному патчингу через Lifecycle Manager.
Еще раз проверьте правила сетевого экрана для временного IP-адреса обновления (Reduced Downtime Upgrade temporary IP address), если вы используете эту функцию, присутствующую в vCenter Server 8.0.2 и более новых версиях.
Используйте правила DRS, чтобы держать vCenter Server и ключевые виртуальные машины (такие как KMS, DNS и AD) на выделенном хосте ESXi. Лучше использовать правило "should" (для более гибкой конфигурации). Это позволит быстро найти и починить хост VCSA с помощью клиента Host Client при прямом доступе к ESXi.
Помните, что нужно создавать резервные копии сервера vCenter с помощью функции файлового резервного копирования и восстановления, которая доступна через интерфейс VAMI (Virtual Appliance Management Interface). Если у вас нет резервной копии, используйте кнопку "Backup Now", чтобы сделать бэкап прямо сейчас:
Также экспортируйте конфигурацию распределенных коммутаторов, чтобы у вас была свежая копия конфигурации. Храните эту резервную копию в доступном месте.
Скачайте апдейты vCenter и ESXi локально перед их накатыванием в производственной среде. Это уменьшит риск сбоев операций обновления из-за прерываний сети.
Отключите vCenter HA - это должно быть сделано перед обновлением самого сервера vCenter.
Ну и помните, что для больших апгрейдов (например, мажорные версии vSphere) у вас заранее должен быть подготовлен план тестирования виртуальной инфраструктуры после обновления, чтобы убедиться, что оно прошло успешно. Также вы должны понимать условия, при наступлении которых вам придется откатиться к предыдущей версии.
Проведение обновлений
Сначала перезагрузите сервер vCenter и связанные компоненты, если они работали в течение длительного времени. Это позволит понять "здоровье" сервера перед крупными апгрейдами и определить, есть ли проблемы до самого апгрейда. Это вызовет дополнительный небольшой простой, зато ускорит восстановление сервиса в случае возникновения проблем.
Непосредственно перед выполнением обновления создайте снапшот vCenter и всех связанных контроллеров PSC в выключенном состоянии. Вам придется использовать ESXi Host Client после того, как вы правильно выключите vCenter. Это обеспечивает вам точку восстановления в случае проблем во время обновления.
Если у вас несколько сред, подключенных через Enhanced Linked Mode, то нужно выключить все связанные экземпляры серверов vCenter и PSC и в этот момент создать их снимки. Несоблюдение этого приведет к ошибкам репликации и конфликтам. Если вам нужно будет откатиться (например, на одном из нескольких серверов при обновлении возникла ошибка) - нужно будет сделать откат назад на всех серверах. В сложных средах вам, возможно, придется делать несколько серий снапшотов на протяжении комплексного обновления. Например, вы проапгрейдили половину всех vCenter и PSC, после чего можно сделать снапшоты всех хостов снова - и в случае чего можно будет откатиться к этой точке, где половина хостов уже обновлена.
Кроме того, чтобы избежать ошибок и проблем, возникающих в результате обновлений host management agents для хостов ESXi, рассмотрите возможность перевода vSphere DRS в режим "Partially Automated", чтобы миграции не происходили во время обновления серверов vCenter. Потом, конечно, не забудьте включить его обратно. Но! Не отключайте DRS полностью - ведь это приведет к удалению всех пулов ресурсов.
Чтобы избежать ошибок и задержек из-за обновлений хост-агентов ESXi, влекущих за собой выборы в кластере высокой доступности, подумайте об отключении vSphere HA перед обновлением, затем вы сможете снова включить его.
Главное не спешите - не обновляйте несколько серверов vCenter и/или контроллеров PSC одновременно. Это приведет к ошибкам репликации между компонентами и, в итоге, к сбою всего обновления.
Помните правило - сначала обновляем сервер vCenter, затем серверы ESXi.
Если в данный момент доступны только обновления ESXi, накатывайте их, особенно если там есть критичные обновления подсистемы безопасности - не ждите выхода обновлений vCenter. В средах, использующих Enhanced Linked Mode, серверы vCenter и PSC должны быть обновлены до одной и той же версии перед выполнением обновлений ESXi.
Процедуры после обновления
Если у вас есть план проверок после обновления - выполните его и убедитесь, что все функционирует, как вы ожидаете.
Включите DRS и HA - если вы отключили vSphere HA и/или перевели DRS в режим "Partially Automated", восстановите первоначальные настройки. Также если вы отключали vCenter HA - не забудьте включить его снова.
Не забудьте удалить снапшоты! Со временем они могут снизить производительность хранения и вызвать трудности при их удалении. Но делайте это только после того, как проверили работоспособность и синхронизацию всех компонентов.
Очистите кэш вашего браузера, если в vSphere Client во время или после обновления возникает неожиданное поведение. Это часто решает аномалии в vSphere Client и ESXi Host Client.
Также при больших обновлениях можно изменить пароли root на ESXi и VCSA, а также пароль administrator@vsphere.local, сохранив новые пароли в вашем менеджере паролей и/или офлайн.
Ну и если все хорошо - создайте резервные копии vCenter Server на уровне файлов с помощью встроенного решения, либо на уровне виртуальной машины с помощью стороннего продукта для резервного копирования.
Организационные рекомендации
Информируйте пользователей и руководителей о последствиях обновлений - не все могут понимать детали этого процесса (например, что инфраструктура продолжает работать во время обновлений)
Устанавливайте окна технического обслуживания для предсказуемости процесса - это позволит администраторам систем и другим заинтересованным сторонам быть готовым к непредвиденным простоям.
Учитывайте особенность некоторых систем в отношении vMotion - они могут долго мигрировать с хоста ESXi, на котором планируется обновление, особенно если там идет большой поток транзакций в гостевой ОС. vMotion был сильно улучшен в последние годы, а также механизм vMotion Notifications помогает приложениям подготовиться и восстановиться после миграции.
Применяйте определения ITIL для управления изменениями - "стандартные" рутинные изменения не нарушают работу, например, развертывание новой ВМ. "Экстренные" изменения требуют немедленных действий, например, накатывания критических патчей безопасности. Использование рабочих процессов ITIL помогает прояснить значимость задач и способствует их приоритизации, обеспечивая согласованность внутри организации. Всегда обозначайте критические обновления как "экстренные", так как именно вам в случае чего придется иметь дело с последствиями.
Архитектурные рекомендации
Настройте файловое резервное копирование и восстановление сервера vCenter.
Убедитесь, что vSphere HA не использует сервер vCenter в качестве адреса изоляции (das.isolationaddress). Вместо этого используйте несколько адресов (от das.isolationaddress0 до das.isolationaddress9), чтобы предотвратить ненужные переключения HA из-за недоступности одного адреса.
Ограничьте количество плагинов на сервере vCenter, где это возможно. Меньшее количество плагинов также упрощает совместимость и облегчает обновления, делая систему более управляемой и безопасной.
Ограничьте количество VIB на ESXi - для обеспечения безопасности устанавливайте только необходимое программное обеспечение и удаляйте все не-VMware компоненты (за исключением драйверов NIC и HBA от производителей железа), которые абсолютно необходимы для работы вашей среды.
Используйте режим Enhanced Linked Mode (ELM) только если он вам действительно нужен - он усложняет обновления и апгрейды.
Обеспечьте ресурсы кластера N+1 - vMotion и DRS работают лучше всего, когда в кластере достаточно свободных ресурсов для миграции рабочих нагрузок, потому что при обновлении хост переходит в режим обслуживания (Maintenance Mode).
Итоги
Процесс как небольших обновлений, так и больших апгрейдов, требует серьезного подхода. В первую очередь - на организационном уровне. Все участники процесса, которые могут быть затронуты возможными простоями, неправильными конфигурациями и потерей данных, должны быть в курсе действующего режима обновлений. Это позволит заранее спланировать стратегию поведения в случае непредвиденных обстоятельств. Обязательно делайте бэкапы критичных компонентов и снапшоты, чтобы иметь возможность откатиться к исходному состоянию. Ну и главное - не торопитесь, планируйте и не совершайте необратимых действий (таких как, например, отключение DRS в кластере перед обновлением).
RSS
