Апдейт vSphere – это всегда новость премиум-класса для любого работающего с продуктами VMware виртуализатора. Ждали мы его относительно долго – с середины осени прошлого года, но 9 марта 2021-го вендор порадовал весьма примечательным релизом, который, ожидаемо, и станет предметом нашего внимания сегодня.
О новой версии гипервизора мы уже писали в новости «VMware ESXi 7.0 Update 2 Release Notes», а вероятных с ним проблемах и ошибках – в статье «Возможные ошибки в VMware ESXi 7.0 Update 2». Что ж, теперь очередь нашего обновленного vCenter Server…
Актуальный билд
Скачать билд vCenter Server 7.0U2 за номером 17694817 можно отсюда, выбрав соответствующий уровень лицензии среды. Для Standard, к примеру, страница загрузки будет выглядеть так:
Там же можно найти и актуальный гипервизор, а также напомним, что в комплекте при скачивании вы получаете и vSAN 7.0U2.
Что нового в версии 7.0U2 vCenter Server?
В первую очередь, начиная обстоятельный разговор о текущем обновлении vCenter Server, стоит упомянуть встроенную опцию фидбека в клиенте vSphere, чтобы пользователь мог в режиме реального времени комментировать и оценивать ключевые рабочие процессы и функции продукта. Благодаря этому, ожидается перевод диалога клиента и вендора на совершенно новый по своей продуктивности и оперативности уровень, что, несомненно, самым позитивным образом скажется на последующих патчах к нему и готовящихся следующих апдейтах.
Среди прочего стоит отметить:
- Новый CLI-разворот vCenter Server. Используя шаблон «vCSA_with_cluster_on_ESXi.json» теперь при развертывании vCenter Server на ESXi-хосте можно выполнить загрузку одно-нодового кластера vSAN и включить управление образами кластера vSphere Lifecycle Manager;
- Параллельное восстановление на хостах в кластере, управляемое baseline vLCM. Сделано для сокращения времени при пропатчивании и апгрейде ESXi-хостов в среде. Параллельное восстановление доступно исключительно для ESXi-хостов, погруженных в режим техобслуживания;
- Усовершенствование системы сообщений об ошибках vLCM. Помогает в лучшем понимании коренных причин проблем, таких, к примеру, как пропуск нод в процессе обновления, с совместимостью «железа», установкой и апдейтом ESXi как части операций vLCM;
- Масштабируемость операций VMware vSpherevMotion. Теперь vSphere vMotion автоматически адаптируется к полноценному использованию высокоскоростных сетей, в т. ч. 25 GbE, 40 GbE и 100 GbE, с единого интерфейса vMotion VMkernel. Напомним, в прошлых релизах мы могли иметь дело, максимум, с 10 GbE;
- Увеличена масштабируемость с vLCM. Масштабируемость операций с ESXi-хостами и кластерами подскочила до 400 с 280 при поддержке vLCM;
- Апгрейд и миграция с управляемых NSX-T VDS на vSphere Distributed Switches;
- Создание новых кластеров импортированием желаемой спецификации софта с единственного эталонного хоста. Экономится время и силы в процессе подтверждения наличия всех необходимых компонентов и образов для создания нового кластера в хранилище vSphere Lifecycle Manager, после чего по щелчку выполняется импорт требуемой спецификации ПО с выбранного эталонным хоста. В результате нет нужды каждый раз готовить и проверять новый образ, причем импортировать его можно даже с хоста ESXi, которым vCenter Server не управляет. Также доступно перемещение эталонного хоста в кластер или же использование образа на хосте и передача его в новый кластер, без миграции самого хоста;
- vSphere с Tanzu на управляемых vLCM кластерах. Администратор vSphere может включить vSphere с Tanzu на кластерах vSphere, управляемых единственным образом Затем можно использовать Supervisor Cluster под управлением vLCM;
- Более быстрые апгрейды с vLCM. Можно настроить vSphere Lifecycle Manager обозначать ВМ как suspended по памяти, вместо того, чтобы по факту их мигрировать, выключать или обозначать как suspended по диску;
- Конфиденциальные поды vSphere на Supervisor Cluster в vSphere с Tanzu. Можно запускать конфиденциальные поды vSphere, храня зашифрованной и защищенной гостевую операционную систему от гипервизора на Supervisor Cluster в vSphere с Tanzu. Доступна также и настройка подов vSphere путем добавления Secure Encrypted Virtualization-Encrypted State (SEV-ES) как дополнительного рубежа обороны безопасности.
Вопросы поддержки и планы на ближайшее будущее
Прекратилась поддержка криптографического алгоритма хэширования SHA-1 (удален из дефолтной конфигурации SSHD). И в ближайших планах (вендор обещает чуть ли не в следующем мажорном релизе) окончательно распрощаться с SSPI, CAC и RSA. Это означает, что нам придется конфигурировать и использовать Identity Federation с поддерживаемым Identity Provider для входа в систему vCenter Server вместо Windows Session Authentication (SSPI) как части Enhanced Authentication Plug-in, Smart Card и RSA SecurID.
Также в грядущей версии vSphere будет добавлена поддержка Federal Information Processing Standards (FIPS), включенная по дефолту. Сейчас они доступны, однако по умолчанию не включены. Совместно с этим ожидается встроенная проверка соответствия клиентских подключаемых плагинов FIPS. Следовательно, о локальных плагинах, не отвечающих этим стандартам, скоро придется забыть.
Наконец, вскоре обещают запуск поддержки обновления vSphere Native Key Providers с помощью PowerCLI – следим за ближайшими релизами консоли. И напоследок стоит заметить, что библиотека Python проапдейтилась до версии 3.8.3.
Важно! При включенном шифровании ВМ Site Recovery Manager 8.4 и vSphere Replication 8.4 не поддерживают vSphere 7.0U2.
Решенные проблемы
- Апгрейд vCenter Server через CLI некорректно сохранял конфигурацию Transport Security Layer (TLS) для службы vSphere Authentication Proxy. Если vmcam настроена для использования конкретного TLS-протокола, отличного от дефолтного TLS2, конфигурация сохранялась в процессе апгрейда через CLI. Если приходилось использовать для поддержки продуктов или сервисов протоколы TLS 1.0 и TLS 1.1 (по каким-то причинам с TLS 1.2 они не совместимы), рекомендовалось применять TLS Configurator Utility, чтобы можно было переключаться между разными их версиями.
- Импорт или разворот локальных OVF-файлов, содержащих символы, отличные от ASCII, в имени, завершался ошибкой. Ошибка вида «400 Bad Request Error» или «500 Internal Server Error».
- Выпадающее меню «Actions» не содержало никаких объектов, если язык браузера установлен не как английский. При нажатии кнопки «Switch to New View» со вкладки «Summary» ВМ в инвентаре клиента vSphere, на панели «Guest OS» выпадающее меню «Actions» пустовало.