С выходом TKG Service 3.2.0 в октябре 2024 года VMware объявила об устаревании API Tanzu Kubernetes Cluster (TKC), направляя клиентов на использование Cluster API в качестве поддерживаемого метода для инициализации, настройки и управления кластерами Kubernetes. Ниже описан процесс отказа от использования API TKC в пользу более современной методологии на основе Cluster API.

Далее термины "TKG Service", "TKGS" и "vSphere Kubernetes Service" (VKS) используются взаимозаменяемо. VMware проводит небольшую ребрендинг-кампанию, и в будущих выпусках вы начнете замечать обновленный брендинг.

API TanzuKubernetesCluster долгое время был полезным инструментом для управления кластерами Kubernetes, но по мере развития экосистемы Cluster API стал предлагать более зрелый, функциональный и управляемый по версиям подход к управлению жизненным циклом кластеров. Этот переход гарантирует клиентам стандартизацию, большую гибкость и долгосрочную поддержку. Однако в VMware понимают, что у многих пользователей уже развернуты кластеры, созданные с помощью API Tanzu Kubernetes Cluster. Это создает определенные сложности: необходимо обеспечить возможность корректного отказа от TKC-ресурсов без нарушения существующих рабочих процессов. Общий план по обновлению включает три ключевых этапа:

Начиная с TKG Service 3.2.0, пользователи, работающие с ресурсами TKC, получают предупреждения об устаревании и рекомендации по переходу на Cluster API.

С выпуском TKG Service 3.3.0 был представлен упрощенный процесс вывода ресурсов TKC для существующих кластеров, при этом управление ими продолжается через Cluster API. Подробное описание этого процесса приведено ниже.

В одном из будущих выпусков поддержка API TKC будет полностью прекращена. К этому моменту пользователи должны будут вывести из эксплуатации все ресурсы TKC перед обновлением до новых версий TKG Service/VKS.

Обзор процесса вывода из эксплуатации

Этот процесс позволяет корректно удалить ресурсы TKC, при этом кластеры остаются полностью работоспособными и управляемыми через ресурс Cluster в Cluster API.

При применении метки kubernetes.vmware.com/retire-tkc к кластеру TKC:

• Если кластер соответствует предварительным условиям вывода из эксплуатации, ресурс TKC удаляется, а управление кластером полностью переходит на его ресурс Cluster.
• Если условия не выполнены, валидация заблокирует процесс вывода, и вам будут предоставлены подробные сведения об ошибках, которые помогут устранить проблемы.

Примечание: вывод ресурса TKC из эксплуатации не влияет на сам кластер или его узлы и не вызывает поэтапного обновления (rolling update).

Начало работы

Перед началом убедитесь, что ваш кластер не работает на устаревшей версии Kubernetes. Устаревшие версии совместимы только с vSphere 7.x (и 8.x для обновления) и должны быть обновлены до поддерживаемой версии Kubernetes перед выводом из эксплуатации. Используйте шаги проверки совместимости кластера, чтобы определить и обновить устаревшие версии.

Также убедитесь, что в кластере нет активных обновлений, и что он находится в стабильном состоянии. Важно об управлении через TMC: на данный момент кластеры, управляемые Tanzu Mission Control (TMC), не могут быть выведены из эксплуатации. Эта функциональность пока не поддерживается.

Шаги

Подробное руководство по процессу вывода из эксплуатации можно найти в официальной документации в разделе Retiring Tanzu Kubernetes Cluster resources.

Добавьте метку к ресурсу TKC для кластера, который вы хотите вывести из эксплуатации:

kubectl label tanzukubernetescluster/<cluster-name> kubernetes.vmware.com/retire-tkc="" 

После применения метки webhook выполняется ряд автоматизированных проверок. В частности, проверяются следующие условия:

• Неустаревшая версия Kubernetes: кластер должен работать на поддерживаемой версии Kubernetes (не может быть переопределено).
• Существующий ресурс Cluster: должен существовать соответствующий ресурс Cluster, находящийся в состоянии Ready (можно переопределить — см. документацию).
• Нет активных обновлений: в кластере не должно выполняться обновление (можно переопределить, если версии Kubernetes совпадают).
• Нет других миграций: кластеры, находящиеся в процессе миграции, не могут быть выведены из эксплуатации (не может быть переопределено).
• Кластер не управляется TMC: кластеры, управляемые Tanzu Mission Control, не могут быть выведены из эксплуатации (не может быть переопределено).

Если все проверки пройдены, процесс вывода продолжается. Если какая-либо из проверок не проходит, процесс приостанавливается, и в статусе TKCRetired указывается причина отказа. После устранения проблем процесс можно перезапустить.

Чтобы отслеживать процесс вывода из эксплуатации, используйте команду:

После запуска процесса вывода вы увидите обновления через события:

• RetirementTriggered – событие публикуется при запуске процесса.
• RetirementDone – событие публикуется при удалении ресурса TKC.

Остановка процесса при необходимости

Если нужно приостановить или остановить процесс вывода из эксплуатации, установите значение метки в false, чтобы предотвратить дальнейшие действия:

Результат

При успешном завершении процесса:

• Старый ресурс API TKC будет удален.
• Кластер продолжит работать без перебоев и будет полностью управляться через ресурс Cluster.
• Все операции жизненного цикла, включая обновления и масштабирование, будут выполняться через Cluster API.

Этот процесс обеспечивает чистый и безопасный переход от управления кластерами через TKC к полному управлению с помощью Cluster API.

Недавно мы писали о выходе большого обновления VMware vSphere 8 Update 3, а несколько дней назад пользователи стали сталкиваться с ошибкой при попытке наката обновления. Текст ошибки выглядит так:

Pre-install failed for vmidentity:Expand

Выглядит это как-то так (только вместо vpxd написано vmidentity):

При этом некоторые пользователи могут откатиться (Rollback) к исходному дистрибутиву, а у кого-то этот селектор неактивен (загреен). При обращении в техподдержку VMware пользователям было сказано, что на эту тему готовится KB, а пока можно воспользоваться приведенным ниже воркэраундом.

Проблема связана с некорневым сертификатом с псевдонимом ssoserver. В VMware есть внутренний документ по этой проблеме, но он пока не доступен публично. Вот шаги, которые VMware предоставляет для исправления:

1. Подключитесь по SSH к серверу vCenter

2. Выведите список сертификатов и определите псевдоним некорневого (Non-CA) сертификата с CN=ssoserver

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'

3. Сделайте резервную копию сертификата, который показывает CN=ssoserver
Примечание: замените <Alias> на идентификатор псевдонима, определенный на предыдущем шаге.

/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store TRUSTED_ROOTS --alias <Alias> --output /var/tmp/non_ca_ssoserver.crt

4. Удалите сертификат из хранилища VECS.
Примечание: замените <Alias> на идентификатор псевдонима, определенный на шаге 2

/usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store TRUSTED_ROOTS --alias <Alias> -y

5. Повторно выведите список сертификатов и убедитесь, что сертификат удален

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'

Теперь можно продолжить обновление vCenter.

Правда у некоторых пользователей после удаления сертификата возникает ошибка, и неясно, нужно ли вручную восстанавливать сертификат после наката обновления. Ждем разъяснений VMware на эту тему.

На днях компания VMware в составе Broadcom выпустила очередной пакет обновлений своей флагманской платформы виртуализации - VMware vSphere 8.0 Update 3. vSphere 8 Update 3 улучшает управление жизненным циклом, безопасность и производительность, включая поддержку двойных DPU и улучшенную настройку виртуального оборудования.

Как вы знаете, недавно платформа VMware Fusion стала бесплатной для некоммерческого использования. В том числе, теперь пользоваели Macbook и компьютеров на базе macOS с процессорами архитектуры ARM (Apple Silicon - M1/M2 и другие) могут устанавливать в виртуальной машине релизы Microsoft Windows 11 for ARM (пока в статусе Insider Preview).

Вильям Лам рассказал о том, что у некоторых пользователей при попытке апгрейда их гостевой ОС возникала следующая ошибка:

This PC doesn't currently meet Windows 11 system requirements

Также эта проблема была задокументирована вот тут, она связана с использованием нового механизма TPM и Secure Boot.

Для исправления ситуации нужно выставить следующие значения ключей реестра Windows:

• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\Applicability : BranchName -> CanaryChannel
• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\UI\Selection : UIBranch -> CanaryChannel

После этого обновление пройдет успешно:

Mateusz Romaniuk написал отличный пост о том, что делать, когда вы провели апгрейд решения для создания отказоуйстойчивых хранилищ с версии VMware vSAN 8 Update 1 на Update 2.

VMware vSphere 8.0 U2 вносит множество улучшений, исправляет несколько проблем и повышает стабильность. После обновления с vSphere 8.0 U1 на U2 происходят также некоторые изменения в vSAN. Если кластер vSAN работает в производственной инфраструктуре, вам необходимо проапгрейдить версию диска, когда вы используете самую новую версию vSphere.

В итоге у вас должна быть версия 19 для формата дисков кластера vSAN (Disk format version):

Итак, сам процесс обновления:

1. В клиенте vSphere выберите ваш кластер vSAN. Перейдите на вкладку Configure и в разделе vSAN выберите Disk Management. Если вы проверите один из хостов ESXi, работающих на vSAN, вы увидите, что текущая версия диска - 18.0.

2. Запустите процедуру предварительной проверки Pre-Check Upgrade, чтобы убедиться, что формат дисков может быть обновлен:

3. Если все в порядке, то нажимайте кнопку Upgrade:

4. После этого начнется процесс апгрейда формата дисков, продолжительность которого зависит от размера вашей инфраструктуры и количества дисков:

5. После апгрейда вы получите уведомление об успешном завершении, а в разделе Disk Management вы можете выбрать хост ESXi и нажать View Disks:

6. Там в разделе Disk group вы и увидите нужную вам информацию - Disk format version: 19

Ну а вот и сами диски дисковой группы:

Администраторы платформы виртуализации VMware vSphere в рамках ежедневной рутины занимаются процессами обновлений виртуальной инфраструктуры и ее компонентов путем накатывания патчей или проведения апгрейдов (в том числе наиболее сложных - на новые мажорные версии). Наиболее удобный способ делать это - использовать решение vSphere Lifecycle Manager (vLCM), который автоматизирует этот процесс. Это следующее поколение продукта vSphere Update Manager (VUM), который ранее использовался для планирования и накатывания обновлений...

С выпуском обновления платформы виртуализации VMware vSphere 8 Update 2 компания VMware ввела еще один способ апгрейда сервисов управления виртуальной инфраструктурой vCenter Server Appliance 8.0 до Update 2, который теперь можно сделать методом Switchover. Это подразумевает развертывание нового экземпляра vCSA, на который по окончании апгрейда будет переключено управление виртуальной инфраструктурой vSphere.

Проапгрейдить на Update 2 вы можете vCenter 8 следующих версий (естественно, вы сможете апгрейдить и сам vCSA 8 U2 на последующие релизы в дальнейшем):

• 8.0 GA 8.0 U2
• 8.0 U1 8.0 U2
• 8.0 P02 8.0 U2

Суть нового метода описана в KB 92659, мы приведем здесь лишь основные шаги:

1. Монтируем ISO-образ c vCenter Server Appliance 8.0 до Update 2

2. Делаем бэкап vCenter на уровне файлов (это обязательно)

3. Обновляем плагин vCenter Server Lifecycle Manager в Upgrade Planner

4. Настраиваем новый модуль vCenter Server Appliance 8.0 Update 2 (это можно делать и для минорных апдейтов)

5. Запускаем предварительную фазу апгрейда (Prepare upgrade stage) с установкой временного IP

6. Запускаем процесс Switchover, во время которого произойдет остановка предыдущего виртуального модуля vCenter Server, перебивка IP-адресации и переключение на новый экземпляр vCSA

На днях компания VMware объявила о доступности обновленной версии решения Cloud Provider Lifecycle Manager 1.4 (VCPLCM). Напомним, что этот продукт предназначен для автоматизации рутинных операций жизненного цикла продуктов, для которых можно разрабатывать свои сценарии развертывания, обслуживания и списания систем, что позволяет сотрудникам сервис-провайдеров (VCPP) сосредоточиться на более высокоуровневых операциях. В прошлой версии этого средства появился графический интерфейс, о чем мы писали вот тут.

Основные нововведения Cloud Provider Lifecycle Manager 1.4 сосредоточены в трех областях:

1. Упрощенные операции

Теперь в разделе Environments есть кнопка Register Environment, с помощью которой можно просто импортировать продукт и окружение, после чего он добавится в управляемые системы.

Также в графическом интерфейсе доступны новые Day-2 операции, чтобы выровнять функции API и GUI. Теперь вы можете управлять следующими вещами:

• Апгрейд продуктов
• Управление сертификатами
• Управление узлами

Функция Discover была добавлена для отслеживания изменений и модификаций, которые были сделаны в развернутом продукте, и синхронизации их с репозиторием Lifecycle Manager Repository.

Теперь вы можете обнаружить изменения в развернутом продукте в окружении и в зарегистрированном датацентре. Более подробно об этом рассказано в документации.

2. Уменьшенное время исполнения задач

Наконец-то появилась возможность одновременного исполнения задач - теперь сотрудникам сервис-провайдеров не нужно ждать завершения предыдущей задачи, чтобы стартовать следующую. Это особенно удобно, когда вы делаете апгрейд сразу нескольких окружений. Кроме того, пользователи могут запросить постановку задачи в очередь, и если сейчас не свободного слота для исполнения - задача будет выполнена позже.

Ну и появилась возможность детализированного просмотра продуктов и компонентов. Это улучшение позволяет облачным провайдерам проводить ревью исполняемых продуктов в их окружениях, а также развернутых и зарегистрированных спецификаций продуктов. Для этого надо нажать кнопку Open в карточке продукта:

3. Улучшенный траблшутинг

В VCPLCM 1.4 вы можете получать логи и сообщения об ошибках через GUI или API, просто залогинясь на хост VCPLCM по SSH. Теперь отдельные лог-файлы создаются для каждой задачи с уникальным ID, чтобы упростить решение проблем.

Также появилась опция генерации бандла поддержки (support bundle), чтобы получить все необходимые конфигурационные файлы в архиве через API или GUI.

Кроме того, был упрощен процесс проверки и развертывания пакетов Interop Bundles. Теперь вы можете проверить доступность последнего interop bundle и обновить его через GUI. В разделе Administration доступны опции Check for Interop Bundle Update и Update Interop Bundle:

Также теперь при логине в GUI появляется баннер, который периодически проверяет доступность версий interop bundle и предлагает обновиться, чтобы ваш хост VCPLCM был всегда последней версии. Помните, что для работы функций VCPLCM нужен доступ к VMware Customer Connect.

Ну и появилась автоматизация структуры каталогов репозитория. При первоначальной загрузке начинается автоматическое создание репозиториев под поддерживаемые директории продуктов в этом релизе, поэтому теперь нет необходимости создавать их вручную.

Загрузить VMware Cloud Provider Lifecycle Manager 1.4 можно по этой ссылке. Документация доступна тут.

Как вы знаете, на прошедшей конференции Explore 2022 компания VMware анонсировала новые версии платформы виртуализации vSphere 8 и решения для создания отказоустойчивых хранилищ vSAN 8. Недавно эти решения стали доступны для скачивания как Initial Availability (IA), поэтому сейчас самое время развертывать их в своих тестовых окружениях для проверки перед большим апгрейдом.

Начать можно с виртуальной тестовой лаборатории, то есть инсталляции в рамках одного сервера или рабочей станции, где сервисы ESXi, vCenter и vSAN поднимаются в виртуальных машинах.

Для этой цели известный блоггер и инженер VMware Вильям Ламм создал на PowerCLI специальный сценарий Automated vSphere & vSAN 8 Lab Deployment, который автоматизирует развертывание компонентов виртуальной лаборатории на базе vSphere и vSAN восьмой версии.

Как видно на картинке, скрипт предназначен, чтобы развернуть три виртуальных сервера ESXi, создать на их базе кластер vSAN, а также развернуть виртуальный модуль управления vCenter Server Appliance (vCSA).

Итак для этого вам понадобятся:

• Действующий vCenter Server не ниже седьмой версии
• Компьютер Windows, Mac или Linux с установленным PowerShell Core и фреймворком PowerCLI 12.1 Core
• Виртуальный модуль vCenter Server Appliance 8.0 Build 20519528 OVA
• Виртуальный модуль Nested ESXi 8.0 IA OVA

Перед исполнением сценария вам нужно заполнить все его параметры, относящиеся к вашей текущей инфраструктуре и к создаваемой тестовой лаборатории, а также распаковать содержимое ISO-образа виртуального сервера vCSA.

Пример исполнения сценария показан ниже:

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

Ну и после всего этого в vSphere Client вы увидите вашу созданную виртуальную тестовую лабораторию с тремя хостами ESXi и сервером управления vCenter / vCSA:

Скачать сценарий Automated vSphere & vSAN 8 Lab Deployment можно по этой ссылке, там же есть более подробная информация о том, как его использовать.

На днях компания VMware обновила свое решение vRealize Suite Lifecycle Manager до версии 8.8, входящее в пакет решений vRealize Suite. Напомним, что оно предназначено для развертывания установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений. Он пришел на смену решению VMware Update Manager (VUM), расширив его возможности. О версии 8.6 vRLCM мы писали вот тут.

Давайте посмотрим, что нового в vRLCM 8.8:

1. Управление жизненным циклом vRealize Orchestrator

Теперь Lifecycle Manager поддерживает решение по автоматизации операций vRealize Orchestrator, которое есть в составе пакета vRealize Automation (базовая версия), так и существует в виде отдельного продукта (полнофункциональная версия для производственной среды).

Теперь можно добавить существующий сервер vRealize Orchestrator, развернуть новый в составе vRealize Automation, либо создать отдельный инстанс vRO в рамках установки инфраструктуры vRA:

Помните, что vRealize Orchestrator нельзя установить без наличия в инфраструктуре сервисов vRealize Automation. Импорт существующего инстанса выглядит очень просто:

Для новой инсталляции vRO потребуется чуть больше шагов, но большинство параметров уже будут предзаполнены мастером установки:

После импорта иконка vRealize Orchestrator будет отображаться на карточке виртуального окружения:

Так как vRO ассоциирован с установленным vRA, то действия Day 2 для vRO появятся как подвкладка для продукта vRealize Automation:

Действия Day 2 для управления жизненным циклом доступны из меню в правом верхнем углу:

2. Улучшения для vRealize Automation

Раньше при снятии снапшота инфраструктуры vRealize Automation перед апгрейдом кластера требовалось около 10 минут на правильное выключение всех систем. Теперь это время было уменьшено в рамках улучшений рабочих процессов при создании онлайн-снапшота и откате к нему. Перед апгрейдом vRLCM проверяет нормальное функционирование vRealize Automation.

Второе улучшение в vRealize Automation Cloud - это поддержка развертывания Cloud Extensibility Proxy. Раньше карточка для прокси была, но доступна она была только для стандартных прокси. Теперь при создании нового прокси он будет развернут как extensibility service. На картинке ниже показано отличие от предыдущей версии:

3. Кластеры VMware Identity Manager

При развертывании или масштабировании трехузлового кластера VMware Identity Manager теперь можно развертывать новые узлы в разных датацентрах и кластерах. Это позволяет обеспечить высокую доступность на уровне разных кластеров и площадок.

В прошлых релизах расширенные настройки не позволяли менять инфраструктурные опции. Теперь же можно менять все поля настроек для каждого узла:

Обратите внимание, что все узлы должны использовать одну сеть в рамках серверов vCenter Server.

4. Улучшенные нотификации

Теперь появились нотификации для состояния лицензий и их устаревания:

Это позволяет заранее позаботиться о лицензиях и сертификатах, которые актуальны в вашем окружении и выполнить соответствующее действие в службе Lifecycle Operations перед тем, как ваши лицензии/сертификаты устареют.

Еще одно улучшение - это дополнительный шаг валидации при добавлении webhook URL для Slack и Teams, чтобы сразу убедиться в том, что параметры указаны верно (отсылается тестовое сообщение).

5. Улучшения VMware Cloud Foundation

В этом релизе появилась автоматическая установка менеджмент паков VMware Identity Manager и SDDC Health как части развертывания vRealize Operations. Это нужные паки для мониторинга окружения VMware Cloud Foundation, которые раньше устанавливались вручную.

Начиная с VMware Cloud Foundation 4.4 и vRealize Suite Lifecycle Manager 8.6.2, развертывание продуктов семейства vRealize контролируется vRLCM. Это позволяет пользователям делать апгрейд продуктов, как только выходят их новые версии, без необходимости ждать, пока обновится список поддерживаемых систем VMware Cloud Foundation BOM.

Теперь пользователи могут проводить апгрейды продуктов vRealize в режиме поддержки VMware Cloud Foundation, что сокращает время самого апгрейда. Это поддерживается для продуктов vRealize, начиная с версии 8.1.

Также в этом режиме будет верифицирована совместимость компонентов vCenter Server, ESXi и NSX при любых типах апгрейдов. Это позволит убедиться в том, что вы всегда получаете поддерживаемую конфигурацию.

Еще одно улучшение тут - это обработка изменений пароля vCenter. Теперь SDDC Manager может регулярно менять пароли vCenter Server, которые автоматически обновляются в хранилище Realize Suite Lifecycle Manager.

6. Улучшения Content Management

В этом релизе исправлена ошибка, когда контент не удалялся из источника (например, GitHub) при обновлении.

Подробнее о VMware vRealize Suite Lifecycle Manager 8.8 можно узнать по этой ссылке. Release Notes на русском языке доступны тут.

Многие из вас заметили, что на сайте VMware обновление vSphere 7 Update 3 пока не скачать. При входе на страницу загрузки VMware vSphere показывают красное предупреждение, которое говорит о том, что проблема нового апдейта весьма серьезная:

Скачать VMware vSphere 7 Update 3 и ее компоненты сейчас нельзя.

Ситуация продолжается уже 5 дней, а VMware не дает конкретных сроков устранения проблемы. При этом пользователям, которые уже провели апгрейд до vSphere 7 Update 3, 3a или 3b - неясно пока, что делать. Нам в комментариях уже писали о том, что сталкиваются с серьезными проблемами при апгрейде на U3 и после этого.

Основная информация о возникшей проблеме приведена в KB 86398. Там можно узнать, что вся линейка Update 3 была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281.

Прямо скажем - проблем этих много, и просто удивительно, как все это прошло выходной контроль при выпуске релизов третьего пакета обновлений. Это и выпадение в PSOD, и проблемы апгрейда с прошлых версий, и проблемы со стабильностью vSphere HA, и другое:

Следим за развитием событий, FAQ в KB 86398 не дает никакой ясности по планируемому времени исправления проблемы. Пользователям, обновившимся до vSphere 7 Update 3, не рекомендуют откатываться до предыдущей версии, если они не сталкиваются с серьезными проблемами в функционировании инфраструктуры.

Помните, любое обновление продуктов VMware надо проводить только по прошествии нескольких недель, в течение которых нужно следить за появившимися сообщениями о серьезных багах. Эта ситуация повторяется из релиза в релиз, а опытные пользователи vSphere к такому образу действий уже привыкли.

Дункан Эппинг обратил внимание на довольно частую проблему у пользователей VMware vSphere 7, которые делают апгрейд с Update 1 на Update 2. Если вы используете подключение к хранилищам по iSCSI и рандомные имена IQN для инициаторов, то после апгрейда хранилища могут перестать быть доступными, если вы используете контроль доступа на базе IQN.

Проблема проявляется, только если вы создавали подключения по iSCSI именно в vSphere 7 Update 1 на свежей установке. Причина проста - изменился стандарт случайного именования IQN для iSCSI-инициаторов. Если для Update 1 он выглядит так:

iqn.1998-01.com.vmware:labesx06-4ff17c83

То для Update 2 уже так:

iqn.1998-01.com.vmware:labesx07:38717532:64

Соответственно, после апгрейда имя инициатора у вас изменится. Чтобы сделать хранилища iSCSI вновь доступными, надо пойти на дисковый массив или виртуальный модуль (Virtual Appliance) и вбить туда новое имя инициатора. Либо вы можете сделать имя инициатора вручную и вбить его также и на массиве для нужных LUN.

Кстати, при апгрейде с версии vSphere 6.7 или vSphere 7 сразу на Update 2 проблема не возникает, так как настройки iSCSI корректно переезжают сразу в configstore.

Чтобы изменить имя iSCSI-адаптера, можно использовать вот эту команду, чтобы это имя получить:

$ esxcli iscsi adapter get -A vmhba67

Вывод будет, например, таким:

vmhba67
Name: iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

И потом вот эту команду, чтобы задать новое имя:

$ esxcli iscsi adapter set -A vmhba67 -n iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

Также можно это сделать и с помощью PowerCLI-сценария (подробнее тут):

Get-VMHost |
ForEach-Object -Process {
    $HostHBA = $_ | Get-VMHostHba -Type iScsi | Select-Object Name,IScsiName
    $esxcli = get-esxcli -v2 -vmhost $_
    $CLIARG =  @{
        adapter = $HostHBA.Name
        name = $HostHBA.IScsiName
        skipifsessionactive = $false
        }
    $esxcli.iscsi.adapter.set.Invoke($CLIARG)
write-host "Setting host " $H  "adapter"  $HostHBA.Name "with IQN" $HostHBA.IScsiName
    }

Недавно мы писали о новой службе Virtual Machine Service, которая появилась в последней версии VMware vCenter 7 Update 2a, вышедшей несколько дней назад. Через некоторое время компания VMware обновила и свою основную платформу виртуализации до версии ESXi 7 Update 2a, обновив таким образом оба компонента VMware vSphere 7 до Update 2a.

Основным нововведением ESXi 7 Update 2a (он же билд 17867351) является исправление бага с апгрейдом с прошлых версий vSphere. Пользователи, у которых был настроен кастомный бейслайн vSphere Lifecycle Manager (vLCM), после апгрейда получали вот такую ошибку (для билда 17630552 в комплекте Update 2):

Failed to load crypto64.efi

Теперь старый билд Update 2 был убран из репозитория, а все обновления будут уже до версии 2a.

Также в U2a появилось немало нововведений для VMware vSphere with Tanzu:

• Supervisor Cluster
  • Управление ресурсами Kubernetes через Virtual Machine Service. Об этом мы подробно писали тут.
  • Самостоятельное создание пространств имен со стороны разработчиков (по шаблону, заданному администратором, который определяет лимиты и права доступа).
• Tanzu Kubernetes Grid Service for vSphere
  • Сервер Kubernetes metrics-server включен по умолчанию. Основные параметры узлов и Pod'ов можно смотреть командой kubectl top.
  • Система обработки webhooks теперь поддерживает dry-run mode. Теперь такие популярные утилиты, как, например, Terraform Kubernetes provider можно интегрировать с Tanzu Kubernetes Grid Service.
  • Кастомные классы виртуальных машин (Virtual Machine Classes), которые потребляются через службы VM Service. Это позволяет пользователям выделить различные параметры CPU и памяти, которая выделена виртуальным машинам в кластере Tanzu Kubernetes Cluster.

Обновить инфраструктуру на vSphere 7 Update 2a можно следующими командами в консоли:

esxcli network firewall ruleset set -e true -r httpClient

esxcli software profile update -p ESXi-7.0U2a-17867351-standard \

-d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

esxcli network firewall ruleset set -e false -r httpClient

Скачать VMware vSphere 7 Update 2a можно по этой ссылке. Release notes доступны тут.

Как вы знаете, при обновлении виртуальной инфраструктуры в части хостов ESXi с помощью vSphere Lifecycle Manager (vLCM), в кластере HA/DRS хост переводится в режим обслуживания (Maintenance mode), который предполагает эвакуацию виртуальных машин на другие серверы с помощью vMotion. После обновления хоста он выводится из режима обслуживания, и виртуальные машины с помощью DRS постепенно возвращаются на него. В зависимости от характера нагрузки этот процесс может занять от нескольких минут до нескольких часов, что не всегда соответствует ожиданиям администраторов.

Второй вариант - потушить виртуальные машины, обновить ESXi, а потом включить его - тоже не подходит, так как приводит к длительным простоям сервисов виртуальных машин (нужно не только время на обновление хоста, но и время на выключение и включение ВМ, либо их небыстрый Suspend на диск).

Поэтому VMware придумала технологию Suspend-to-Memory, которая появилась в VMware vSphere 7 Update 2. Суть ее в том, что при обновлении ESXi его виртуальные машины приостанавливаются, сохраняя свое состояние (Suspend) в оперативной памяти. Очевидно, что в таком состоянии перезагружать хост нельзя, поэтому данная техника используется только совместно с ESXi Quick Boot, которая подразумевает обновление гипервизора без перезагрузки сервера.

Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по поддержке этой технологии со стороны серверных систем приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:

• Quick boot on Dell EMC
• Quick Boot on HPE
• Quick Boot on Cisco
• Quick Boot on Fujitsu
• Quick Boot on Lenovo

По умолчанию настройка кластера Cluster Remediation для виртуальных машин выставлена в значение "Do not change power state" для виртуальных машин, что подразумевает их vMotion на другие серверы, поэтому чтобы использовать Suspend to Memory, надо выставить "Suspend to memory", как на картинке выше.

При использовании такого типа обновления vLCM будет пытаться сделать Suspend виртуальных машин в память, а если этого не получится (например, недостаточно памяти), то он просто не будет переходить в режим обслуживания.

Надо сказать, что Suspend-to-Memory поддерживает vSAN и работает с такими продуктами, как vSphere Tanzu и NSX-T.

Ну и вот небольшое демо того, как это работает:

Компания VMware опубликовала полезный FAQ, ссылка на который может в любой момент понадобиться администратору VMware vSphere для понимания различных аспектов системного хранилища серверов VMware ESXi.

Давайте посмотрим, на какие вопросы там можно найти ответы:

• Что изменилось в системном хранилище ESXi 7 по сравнению с прошлыми версиями? Мы об этом подробно писали тут.
• Что случится с разметкой системного хранилища при апгрейде на vSphere 7? Ответ тут и на этой картинке:

• Какое хранилище рекомендуется в качестве системного для ESXi?
• Что насчет устройств USB/SD? Можно ли использовать SD-карту для системного хранилища? (Спойлер: лучше не надо).
• Почему вы можете увидеть ситуацию, что хосты ESXi в "Degraded Mode"?
• Что вообще означает Degraded Mode?
• Можно ли добавлять локальное хранилище после апгрейда на ESXi 7? (Спойлер: да)
• Что делать, если хост в Degraded Mode, а хранилища вообще не видно? (Спойлер: смотреть External Syslog, NetDump Collector или Core Dump Partition)
• Если вы используете vSphere AutoDeploy, то как работает развертывание системного хранилища? Подробнее об этом вот тут

Интересно, что продукты VMware vSphere и VMware vSAN имеют разные списки совместимости оборудования (HCL - Hardware Compatibility Lists). Ronald de Jong в своем блоге описал ситуацию, когда у него драйвер SCSI-контроллера подошел для vSphere, но не подошел для vSAN.

После установки обновления драйвера для VMware vSphere через VMware Lifecycle Manager он получил вот такие ворнинги для vSAN в vSphere Client:

Драйвер smartpqi (70.4000.0.100-4vmw.701.0.0.17325551) уже подходит для vSphere, но еще не провалидирован для решения vSAN. В этом можно убедиться в списке совместимости для vSAN по этой ссылке, где есть только старый драйвер (3vmw):

Если же заглянуть в список совместимости для vSphere, то там будет обозначена поддержка старого и нового драйверов:

Таким образом, нужно провести даунгрейд драйвера, чтобы он подходил и для vSphere, и для vSAN. Сначала идем на Patch Portal и находим там нужное обновление в виде VIB-пакета:

Вот этот драйвер:

После загрузки в консоли ESXi запускаем установщик VIB-пакета командой:

esxcli software vib install -d /vmfs/volumes/vsanDatastore/tmp/VMware-ESXi-7.0U1-16850804-depot.zip -n=smartpqi

После этого все ворнинги по совместимости драйвера исчезнут:

Но в Lifecycle Manager все еще будут висеть предупреждения о необходимости поставить последнюю версию драйвера и проапдейтить ESXi:

Многие администраторы виртуальной инфраструктуры VMware vSphere при планировании апгрейда не выясняют важных моментов, касающихся совместимости продуктов и так называемых upgrade paths, то есть поддерживаемых производителем рабочих процессов обновления платформы. В этой статье мы расскажем о том, что нужно выяснить перед апгрейдом...

Не все администраторы знают, что при апгрейде VMware ESXi на более новую мажорную версию есть возможность сохранить предыдущую конфигурацию гипервизора для возможности отката в случае неудачного обновления. Такая возможность, например, есть при апгрейде ESXi 6.5 на версию 6.7.

Для этого нужно во время установки выбрать пункт "Upgrade ESXi, preserver VMFS datastore". Под датастором тут имеется в виду, что на нем сохранится предыдущая установка ESXi:

Кстати, как видно из скриншота, можно сделать и свежую установку ESXi с возможностью отката к предыдущей версии.

Сделать апгрейд на ESXi 7 с сохранением предыдущей версии платформы не выйдет - в VMware vSphere 7 поменялась структура разделов гипервизора ESXi.

Итак, вы сделали апгрейд ESXi, но что-то пошло не так. Например, ваше железо больше не поддерживается (к примеру, CPU), и вам надо сделать откат к прошлой версии ESXi. Для этого во время загрузки вам нужно нажать комбинацию клавиш Shift + <R>:

После этого можно будет выбрать предыдущую версию ESXi и заменить ей новую установку, полностью откатившись к прошлому гипервизору и его настройкам:

Также можно делать бэкап и восстановление конфигурации VMware ESXi - об этом рассказано в KB 2042141.

Как вы знаете, компания VMware выпустила платформу VMware vSphere 7 в начале апреля этого года после громкого анонса месяцем ранее. В конце апреля VMware опубликовала интересную новость с результатами исследования среди пользователей, которые тестировали бета-версию vSphere 7 и потом прошли опрос, где одним из вопросов был "Почему бы вы хотели обновиться?". Собственно, вот его результаты...

Для платформы VMware vSphere 7 вышло первое обновление - стал доступен для скачивания апдейт управляющего сервера VMware vCenter 7.0 Update 0a.

Цифра 0 в номере апдейта намекает на то, что ничего особо нового в обновлении нет, что соответствует действительности - было исправлено лишь несколько мелких ошибок и одна важная.

Она заключалась в том, что vSphere Lifecycle Manager и службы vSAN File Services не могли быть одновременно включены в кластере. Если вы включали что-то из этого первым, то второй компонент не мог быть включен после этого (они не были совместимы между собой). Теперь это поправили - и они вполне работают вместе.

Скачать VMware vCenter 7.0 Update 0a можно по этой ссылке.

Помимо этого, были обновлены и службы VMware vSphere with Kubernetes, включающие в себя виртуальный модуль Tanzu Kubernetes clusters OVA. Из нового там появилось:

• Службы Tanzu Kubernetes Grid Service for vSphere:
  • Пользователи могут накатывать последовательные обновления rolling upgrades на узлы worker nodes и control plane nodes для Kubernetes Grid Service for vSphere и апгрейдить службы pvCSI, Calico и authsvc. Также для этих компонентов предусмотрены процедуры пре-чеков перед апгрейдом.
  • Последовательные обновления rolling upgrades могут быть использованы для одновременного с апгрейдом изменения класса ваших узлов на больший или меньший по размеру.
• Для Supervisor cluster поддерживаются новые версии Kubernetes с возможностью апгрейда:
  • Kubernetes 1.17.4
  • С версии Kubernetes 1.16.x можно обновиться на 1.17.x

Как все уже знают, в новой версии платформы виртуализации VMware vSphere 7 средство обновления виртуальной инфраструктуры VMware Update Manager (VUM) уступило место новому продукту - VMware Lifecycle Manager.

Ранее администраторы vSphere использовали VUM для обновлений серверов ESXi и драйверов, а утилиты от производителей серверов - для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.

На сайте buildvirtual.net появился обзор процесса апгрейда хост-серверов ESXi на версию 7.0, который мы приводим ниже, чтобы дать понимание того, что сам процесс, в плане накатывания апгрейда, от VUM почти ничем не отличается.

Итак, сначала надо импортировать ISO-образ в Lifecycle Manager. Запускаем его в vSphere Client и переходим в раздел Imported ISOs:

Нажимаем Import ISO и указываем ISO-образ ESXi 7.0, который скачали с сайта VMware:

После этого данный образ появится в списке:

Затем надо создать бейслайн с этим образом. Нажимаем ссылку New Baseline, где далее указываем тип содержимого Upgrade:

Выбираем образ, который мы хотим привязать к бейслайну:

После этого созданный бейслайн нужно привязать к хостам или кластеру. Для этого выбираем пункт Attach Baseline or Baseline Group:

После успешной привязки к кластеру, жмем кнопку Check Compliance, которая запускает проверку соответствия хостов заданному бейслайну. В итоге мы увидим, например, что 4 хоста находятся в статусе non-compliant, то есть им можно накатить апгрейд (в данном случае - с версии 6.7 на 7.0):

Перед запуском апгрейда нужно выполнить Remediation Pre-Check, чтобы проверить, что в кластере нет препятствий для апгрейда хостов на седьмую версию.

Если ничего критичного не нашлось, жмем на кнопку Remediate:

Это, собственно, запустит сам процесс апгрейда. Вам нужно будет лишь согласиться с EULA и запустить процедуру обновления. После успешного апгрейда будет показано, что все хосты были обновлены:

В консоли вы увидите, что ESXi 7.0 установлен:

То же самое будет и в vSphere Client:

Как видно из описаний шагов, процесс апгрейда с помощью Lifecycle Manager практически ничем не отличается от оного с помощью Update Manager.

При развертывании новой версии платформы VMware vSphere 7 в виртуальной машине (вложенные/nested ESXi) на серверах со старыми процессорами вы можете столкнуться с тем, что ваш CPU не поддерживается со стороны платформы:

CPU_SUPPORT ERROR

Такая ситуация, например, произошла у Rajesh Radhakrishnan на сервере HP 380 G7, где он развертывал виртуальный ESXi 7.0 на платформе vSphere 6.0 Update 3:

В этом случае вы все равно можете установить гипервизор ESXi седьмой версии. Для этого вам надо открыть настройки виртуальной машины:

В разделе CPUID Mask нажать ссылку Advanced и далее вбить в регистре eax для Level 1 следующие значения:

• Для процессоров Intel CPU: 0000:0000:0000:0011:0000:0110:1100:0011
• Для процессоров AMD CPU: 0000:0000:0110:0000:0000:1111:0001:0000

После этого включайте ВМ, где будет установлен ESXi 7, и проходите до конца установки:

После этого ваш ESXi 7 спокойно загрузится. Затем нужно откатить маскирование функций CPU к исходной чистой конфигурации, удалив значение регистра eax:

Обратите внимание, что такая конфигурация не поддерживается в производственной среде! Поэтому используйте такие виртуальные ESXi 7 только для тестирования и других некритичных задач.

Мы много писали о том, что нового появилось в обновленной платформе виртуализации VMware vSphere 7, которая недавно стала доступной для загрузки. Сегодня мы поговорим о том, чего больше нет в vSphere, ведь многие администраторы привыкли использовать некоторые средства, поэтому, возможно, подождут с апгрейдом. Об этих запланированных изменениях мы писали еще в 2017 году.

1. Больше нет vSphere Web Client на базе Flash

Об этом говорили давно, долго задерживали снятие с производства тяжеловесного vSphere Web Client, но все откладывали из-за несоответствия функциональности клиенту нового поколения vSphere Client на базе технологии HTML5. Теперь в vSphere 7 этот переход окончательно завершен, и старого Web Client больше нет.

Клиент на HTML5 включает в себя не только все старые рабочие процессы Web Client, но и давно получил новые возможности, такие как, например, упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM).

2. Больше нет внешнего PSC (Platform Services Controller)

Как мы уже рассказывали, Embedded PSC - это теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается. Встроенный PSC имеет все необходимые сервисы для управления доменом vSphere SSO (подробнее описано в KB 60229).

С помощью утилиты Converge Tool, которая появилась в vSphere 6.7 Update 1, можно смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC, используя командный интерфейс vCenter Server CLI или графический клиент vSphere Client:

3. Больше нет VMware vCenter for Windows

Как мы уже писали, vSphere 6.7 - это была последняя версия платформы, где для vCenter еще была версия под Windows. Теперь остался только виртуальный модуль vCenter Server Appliance (vCSA) на базе Photon OS. Многие привыкли к сервисам vCenter на базе Windows, теперь придется отвыкать.

VMware рекомендует выполнить 2 основных шага для миграции с vCenter на vCSA:

• Migration Assistant - консольная утилита, которую нужно выполнить до мастера миграции vCenter. Она выясняет соответствие требованиям к миграции и показывает дальнейшие шаги.
• Migration Tool - это мастер миграции, который доступен из основного дистрибутива vCenter.

4. Больше нет Update Manager Plugin

На протяжении долгого времени это был плагин для vSphere Web Client. Теперь вместо продукта VMware Update Manager (VUM) в vSphere 7 есть более широкое по функциональности решение VMware Lifecycle Manager.

Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.

5. Больше нет VNC-сервера в ESXi

Ранее в ESXi был встроенный VNC-сервер, который был убран в последней версии VMware vSphere 7. Раньше можно было соединиться с консолью виртуальной машины с помощью VNC-клиента, добавив в конфигурацию параметр RemoteDisplay.vnc.enable.

Теперь такой возможности больше нет (ей пользовались администраторы систем, не использующих средства VMware). Для соединения с консолью виртуальной машины используйте vSphere Client, хостовый клиент ESXi Host Client или средство VMware Remote Console.

6. Мелочи, которых или уже больше нет или их не рекомендуется использовать (не будет потом)

В эту категорию попали:

• VMware vSphere 7.0 и протокол TLS Protocol (TLS 1.0 и 1.1 отключены по умолчанию).
• Нет поддержки резервного копирования на уровне образов (Image-Based Backup) для сервера vCenter.
• Интерфейс VMKlinux API уже давно безнадежно устарел, вместо него используется архитектура нативных драйверов под vSphere, начиная еще с ESXi 5.5. vmkLinux - это такая прослойка между VMkernel и Linux-драйверами, которая позволяла транслировать команды от ядра (так как VMkernel - это НЕ Linux) к драйверам и обратно. Но теперь нативных партнерских драйверов устройств для ESXi накопилось достаточно, и старая архитектура Linux-драйверов ушла в прошлое.
• Депрекация поддержки 32-bit Userworld. Ранее партнерам VMware была доступна возможность делать 32-битные драйверы, плагины и другие компоненты в VIB-пакетах. Теперь, начиная со следующих версий vSphere, такой возможности больше не будет.
• Почти убрана поддержка Integrated Windows Authentication. В этой версии IWA еще работает, но в следующей версии уже не будет. Подробнее в KB 78506.
• Депрекация аутентификации DCUI Smart Card Authentication. Пользователям со смарт-картами рекомендовано использовать vCenter, PowerCLI или API-вызовы, ну либо логин и пароль по-старинке.
• Депрекация Core Partition Profile для функциональности Host Profiles. Вместо разделов Coredump Partitions пользователям нужно использовать файлы Coredump Files.

Таги: VMware, vSphere, Update, Upgrade, ESXi, vCenter, VMachines



Особенности апгрейда управляющего сервера VMware vCenter 7 в составе платформы vSphere 7




Недавно мы рассказывали о новых возможностях анонсированной платформы виртуализации VMware vSphere 7. В составе этого решения идет новая версия управляющего сервера VMware vCenter 7, особенности апгрейда на который мы сегодня рассмотрим.

Основные нюансы этого процесса суммаризованы в видео ниже:

Давайте посмотрим на это немного подробнее:

1. Особенности развертывания

Как мы уже рассказывали, Embedded PSC - это теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается. Встроенный PSC имеет все необходимые сервисы для управления доменом vSphere SSO (подробнее описано в KB 60229).

Напомним также, что теперь у вас нет установщика vCenter Server for Windows. Как мы уже писали, vSphere 6.7 - это была последняя версия платформы, где для vCenter еще была версия под Windows. Теперь это только виртуальный модуль vCenter Server Appliance (vCSA) на базе Photon OS.

Ранее мы писали, что с помощью утилиты Converge Tool, которая появилась в vSphere 6.7 Update 1, можно смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC, используя командный интерфейс vCenter Server CLI или графический клиент vSphere Client:



Также установщик vCenter 7 производит апгрейд vCenter и перенос всех сервисов на Embedded PSC в рамках единой задачи, поэтому результат апгрейда будет сразу законченным. Установщик нового vCenter 7 не имеет опции по развертыванию внешнего PSC:



2. Процесс миграции

Если вы проходите путь миграции с vCenter Server for Windows на vCenter Server Appliance (VCSA), то схема будет точно такой же - в итоге вы получите vCenter 7 на vCSA в встроенным PSC:



После того, как внешний PSC будет сконвертирован, он останется в консоли, и его удаление (decomission) - последующая задача администратора vSphere. Сделать это можно с помощью команды CMSSO-UTIL или из графического интерфейса клиента (в разделе System Configuration):



3. Пути апгрейда

Тут все просто. Апгрейд поддерживается согласно вот этой табличке:



Как видно из таблицы, апгрейд поддерживается, начиная с версии vSphere 6.5, но многие администраторы при обновлении виртуальной инфраструктуры предпочитают развертывать сервисы vCenter заново, чтобы не тащить за собой историю возможных багов, которые могут проявиться при апгрейде.

Перед апгрейдом нужно обязательно посмотреть документы VMware Product Interoperability Matrices и VMware Compatibility Guide. Но помните, что до официального выпуска vSphere 7, эти документы не содержат актуальной информации о седьмой версии.


Таги: VMware, vCenter, Upgrade



Диаграмма по логике миграции на VMware vCloud Director 10.0.




Некоторое время назад мы писали о новых возможностях продукта VMware vCloud Director 10.0, которые раскрыл Daniel Paluszek. На днях он сделал еще очень полезную диаграмму, которая раскрывают логику миграции на vCD 10 с предыдущих версий.

Daniel использовал утилиту MindNode для составления данной диаграммы апгрейда на vCD 10. Как видно на картинках, там описаны разные варианты исходной системы, например, вы решите пойти по пути обновления только Linux / External PostgreSQL (PgSQL) с раздельной инсталляцией vCD или сделаете интегрированные виртуальные модули vCloud Director.

Диаграмма доступна как с фоном, так и с прозрачностью PNG-формата:





Для Linux-систем Daniel отмечает следующие моменты:

1. vCD 10.0 поддерживает только PostgreSQL, у него нет больше поддержки Microsoft SQL Server. Oracle уже прекратил поддерживаться ранее, поэтому все пути миграции ведут на PgSQL в данных диаграммах.
2. Использование виртуального модуля vCD позволяет обеспечить высокую доступность PgSQL, но в случае сбоя нужно будет вручную переключаться на реплику.
3. Использование внешнего экземпляра PostgreSQL полностью поддерживается. Но нужно внимательно следить за конфигурацией соединения к БД.
4. VMware будет продолжать поставлять как установщик, так и виртуальный модуль vCD. Поэтому можно использовать оба варианта, в зависимости от нужд вашей команды.

Более подробно о данных диаграммах можно почитать у Daniel Paluszek.


Таги: VMware, vCloud, Director, Upgrade, Blogs, Enterprise, IaaS



Анонсы VMworld 2019 - часть 7. Утилита VMware vSphere Assessment Tool для подготовки апгрейда виртуальной инфраструктуры.




В рамках серии анонсов, представленных на прошедшей конференции VMworld 2019, компания VMware представила интересное средство, которое может оказаться полезным администраторам виртуальной инфраструктуры - vSphere Assessment Tool (vSAT).

Главное назначение этой утилиты - помочь ИТ-специалистам перед миграцией инфраструктуры VMware vSphere на новую версию: заранее понять потенциальные проблемы с виртуальными машинами после апгрейда и проанализировать общую готовность инфраструктуры к обновлению. Также можно выявить возможные трудности в плане поддержки аппаратного обеспечения, что очень важно, когда у вас либо очень старое, либо очень новое оборудование.

Утилита vSAT реализована двумя компонентами:

• Десктопный клиент, который связывается с сервером vCenter и организует передачу данных.
• Онлайн-портал vSphere Assessment Portal, обрабатывающий ваши данный и визуализующий результаты.

Для начала работы просто нажимаете Get Started на первой странице портала:



Десктопный клиент поддерживает ОС Windows, OS X и Linux. В клиенте вы просто добавляете сервер vCenter, который нужно проанализировать. Для этого либо потребуется использовать административный аккаунт, либо создать пользователя с кастомной ролью с привилегиями "Host Settings".



После того, как в вашей инфраструктуре завершен сбор данных, есть 2 способа отправить их в облако:

• Онлайн-отправка на vSphere Assessment portal с использованием vSAT passcode (чтобы его получить, можно использовать опцию клиента "Forgot Your vSAT passcode?").



Также Passcode можно получить из меню аккаунта на vSAT Portal:



• Офлайн-отправка путем скачивания данных в файл и их последующая загрузка на портал в ручном режиме:



Результатом анализа будет дэшборд, на котором представлена сводная информация по имеющимся проблемам для выбранного пути апгрейда. В левой панели можно выбрать нужный хост ESXi (по аналогии с vSphere Client).

В представлении Summary вы найдете список всех версий vSphere, на которые вы можете выполнить миграцию, а также узнать, какие хосты ESXi рискуют оказаться в неподдерживаемой конфигурации. При клике на хост ESXi возникает панель host details, где можно увидеть текущую версию vSphere, модель сервера, сетевые адаптеры и контроллеры хранилищ. Для каждого компонента верифицируется поддержка соответствующей версией vSphere.



В общем, очень полезная штука для админа перед обновлением vSphere на новую версию. Особенно полезно будет запустить ее в большой инфраструктуре, где присутствует различное оборудование и, возможно, разные версии хостов ESXi.

Пользуйтесь!


Таги: VMware, vSphere, Upgrade, Assessment, Tool, ESXi



Как обновлять и апгрейдить инфраструктуру VMware vCenter HA?




Многи администраторы VMware vSphere, особенно в крупных инфраструктурах, развертывают механизм VMware vCenter HA, обеспечивающий отказоустойчивость сервера VMware vCenter (а точнее виртуальной машины vCenter или vCenter Server Appliance, vCSA). Все понимают, что vCenter / vCSA - это важнейшая часть виртуальной инфраструктуры, ведь без нее не работают такие критичные сервисы, как Site Recovery Manager, NSX и Horizon View.

Функции vCenter HA появились еще в VMware vSphere 6.5, но в vSphere 6.7 Update 1 они были существенно доработаны, а сам процесс обновления и апгрейдов vCenter упрощен. При этом управление механизмом vCenter HA полностью перешло в vSphere Client в рамках единого рабочего процесса (раньше были 2 воркфлоу - Basic и Advanced).

Давайте посмотрим, какие пути апгрейда и обновления существуют для конфигурации vCenter HA. Для начала напомним, как это выглядит:



Две машины с vCenter (активный узел и его клон - пассивный узел), а также компонент Witness образуют собой кластер, где Witness защищает от сценария Split Brain в среде vCenter HA (не путайте это с обычным vSphere HA). В случае отказа основного узла, его функции берет на себя резервный, что существенно быстрее по сравнению с восстановлением vCenter средствами стандартного HA (перезапуск на другом сервере). Это в итоге отражается на меньшем времени RTO для таких критичных сервисов, как SRM и NSX, в случае сбоев.

Перед обновлением помните, что для vCenter HA не поддерживается создание снапшотов, а значит нужно обязательно сделать File-Based Backup основного сервера vCenter перед обновлением.

Если у вас VMware vSphere 6.5, то при обновлении вы можете не разбивать кластер vCenter HA, а просто скачать ISO-образ с обновлениями (через VMware Patch Portal), либо ничего не скачивать и сразу инициировать процесс обновления из командной строки, если у вас есть доступ в интернет из компонентов кластера.

Делается все это так:

• Сначала кластер vCenter HA надо перевести в режим обслуживания (maintenance mode), что не прервет репликацию, но предотвратит автоматический запуск процесса восстановления (failover).



• Затем заходим на компонент Witness по SSH и запускаем его обновление из командной строки. Если у вас есть доступ в интернет на этом экземпляре vCenter, то делается это простой командой:

software-packages install --url --acceptEulas

Если же вы скачали ISO-образ с обновлениями, то делается это следующей командой:

software-packages install --iso --acceptEulas

• Далее заходим на пассивный узел vCenter и там делаем то же самое.
• Инициируем вручную процесс восстановления vCenter на пассивный узел (failover).
• Обновляем активный узел vCenter.
• Возвращаем конфигурацию в исходное состояние (failback).
• Отключаем режим обслуживания (maintenance mode).

Если же у вас vCenter 6.7, то опция обновления у вас одна - отключение и удаление конфигурации HA, после чего происходит накат обновления на активном узле и повторное развертывание HA-конфигурации (такая же опция доступна и для vCenter 6.5). Этот рабочий процесс обусловлен изменениями в схеме базы данных, которые происходят в vCenter 6.7.

Начиная с vSphere 6.7 Update 1, установщик vCenter Server Upgrade installer может автоматически обнаружить присутствие кластера vCenter HA:



Далее в процессе обновления он сохранит его конфигурацию, обновит активный узел vCenter, а потом развернет его реплики для пассивного узла и узла Witness.



Надо понимать, что в процессе обновления машины с пассивным узлом и Witness будут удалены, поэтому не забудьте сделать бэкап. И сам процесс лучше проводить в ручном режиме, а не автоматическом, чтобы иметь больший контроль над получающейся итоговой конфигурацией.


Таги: VMware, vCenter, HA, vSphere, Update, Upgrade



Изменение дефолтной конфигурации виртуального модуля VMware vCenter Server Appliance 6.5/6.7.




Многим администраторам знакома такая вещь: сначала для теста устанавливается виртуальная машина VMware vCenter Server Appliance в конфигурации tiny (минимальные аппаратные настройки), а потом она приживается, и хочется сделать из нее полноценную производственную среду управления (конфигурацию large). Только вот не хочется ее переустанавливать.



Для тех, кто столкнулся с такой проблемой, Robert Szymczak написал полезный пост о том, как это сделать (но помните, что это неофициальная и неподдерживаемая процедура).

Установщик vCSA использует фреймворк Electron, настраивая конфигурацию через JSON, и механизм JSON-Schema для установки и валидации параметров. Поэтому в ISO-образе вы сможете найти конфигурацию сервера vCenter по следующему пути:

\vcsa-ui-installer\win32\resources\app\resources\layout.json

Там как раз и находятся данные о типовых конфигурациях vCSA. Например, так выглядит размер xlarge:

"xlarge": {
        "cpu": 24,
        "memory": 49152,
        "host-count": 2000,
        "vm-count": 35000,
        "disk-swap": "50GB",
        "disk-core": "100GB",
        "disk-log": "25GB",
        "disk-db": "50GB",
        "disk-dblog": "25GB",
        "disk-seat": "500GB",
        "disk-netdump": "10GB",
        "disk-autodeploy": "25GB",
        "disk-imagebuilder": "25GB",
        "disk-updatemgr": "100GB",
        "disk-archive": "200GB",
        "required-disk-space": "1180GB",
        "label": "X-Large vCenter Server with Embedded PSC",
        "description": "This will deploy a X-Large VM configured with 24 vCPUs and 48 GB of memory and requires 1180 GB of disk space will be updated for xlarge later. This option contains vCenter Server with an embedded Platform Services Controller for managing up to 2000 hosts and 35,000 VMs."
    }

Таким образом вы поймете, на какие именно конфигурации нужно изменить компоненты виртуальной машины с vCenter. Перед изменением конфигурации сделайте снапшот машины vCSA, который сохранит параметры ее виртуального аппаратного обеспечения.

Теперь переходим, собственно, к изменению самой конфигурации:

1. Увеличение CPU и памяти (RAM).

• Остановите машину.
• Хорошая идея - вывести ее ESXi-хост из кластера DRS.
• Зайдите на ESXi через Host Client, после чего в настройках ВМ измените конфигурацию CPU и памяти, чтобы выставить ее в соответствии с нужной конфигурацией.

2. Увеличение диска ВМ с сервером vCSA.

• Об увеличении дискового пространства сервера vCSA 6.5 мы писали вот в этой статье. С тех пор ничего особо не изменилось. Некоторую дополнительную информацию вы также можете получить в KB 2145603 на случай если что изменится в процедуре vCSA 6.x.
• Диски нужно настраивать не только по размеру, но и по корректной позиции в виртуальном слоте SCSI.

Примерно так это выглядит для vCenter 6.7 Update 2:

Назначение	Позиция в фале JSON	Номер VMDK	Слот SCSI
root / boot	n/a	1	0:0
tmp	n/a	2	0:1
swap	1	3	0:2
core	2	4	0:3
log	3	5	0:4
db	4	6	0:5
dblog	5	7	0:6
seat	6	8	0:8
netdump	7	9	0:9
autodeploy	8	10	0:10
imagebuilder	9	11	0:11
updatemgr	10	12	0:12
archive	11	13	0:13

Помните, что иногда имя VMDK может не соответствовать его позиции в слоте SCSI. Например, встречаются случаи, когда VMDK0 смонтирован в слот SCSI(0:4), а VMDK2 - в слот SCSI(0:0). В этом случае реальным загрузочным диском будет VMDK2, а не VMDK0, несмотря на их названия.

Также обратите внимание, что SCSI слот 0:7 не используется - не ошибитесь.

После изменения этих параметров запустите vCenter и убедитесь, что все в порядке.


Таги: VMware, vCenter, vCSA, Upgrade, Virtual Appliance, Blogs, VMachines



Улучшенный интерфейс управления плагинами в VMware vSphere 6.7 Update 2.




Не так давно мы писали о новых возможностях последней версии платформы виртуализации VMware vSphere 6.7 Update 2. Одним из нововведений стал улучшенный интерфейс управления плагинами (Plugin Management UI), который дает пользователю полный контроль над процессами обновления и развертывания плагинов к vSphere.

Если еще в Update 1 при установке нового плагина или обновлении старого, в случае неудачи процесс просто завершался, и приходилось смотреть в файл журнала, то теперь для этого есть графическое представление с выводом информации о возникших проблемах (например, несовместимость с новой версией платформы).

В подразделе Client Plug-ins раздела Administrator теперь приведены все клиентские зарегистрированные плагины на любом из серверов vCenter в вашем окружении. Также у этих плагинов есть статусы: In Progress, Deployed, Failed или Incompatible.



Статусы Failed и Incompatible являются кликабельными - при нажатии на них всплывет подсказка с возможной причиной возникновения подобных ошибок или причины несовместимости (при возможности будет также приведен участок лога):



В процессе инсталляции плагин проходит через несколько фаз, которые отслеживаются сервером vCenter, также их можно получать через TaskManager API (его могут использовать и сторонние разработчики). Выполняемые задачи отображаются на сервере vCenter в 3 разделах:

• Панель Recent Tasks в нижней части клиента
• Консоль в разделе задач (Task Console)
• Просмотр представления Tasks для выбранного объекта vCenter Server

Задачи создаются и отслеживаются на сервере vCenter, к которому в данный момент подключен vSphere Client. Если же виртуальная среда работает в режиме федерации Enhanced Linked Mode, то задачи по развертыванию плагина создаются на всех подключенных серверах vCenter. Поэтому любой экземпляр vSphere Client будет видеть эти задачи.

Как происходит работа с плагинами

При логине пользователя в vSphere Client, все плагины vCenter загружаются в кэшированную папку самого клиента на сервере vCenter. Для отслеживания этого процесса создается задача "Download plug-in". Если загрузка плагина прошла успешно, то он становится доступным для развертывания, что видно в консоли задач. И это значит, что он был загружен в кэшированную папку.

Следующая фаза - это задача "Deploy plug-in", которая стартует следующей. Если она завершается успешно, это значит, что плагин установлен и доступен для использования со стороны vSphere Client. Кстати, если задача Download plug-in прошла с ошибкой, то и задача Deploy plug-in будет пропущена.

Ошибки плагинов при развертывании теперь детально описаны в консоли:



Также иногда к ошибке прилагается лог развертывания, например, в случае, когда их вызвало стороннее программное обеспечение, отдающее некоторый лог ошибки.

В случае апгрейда плагина этот процесс представляется набором из трех задач: "Download plug-in", "Undeploy plug-in" и "Deploy plug-in". После этого в vSphere Client появляется глобальная нотификация о новой версии развернутого плагина и с просьбой сделать рефреш в браузере, чтобы плагин начал работать.

Один сервер vCenter может работать только с одной версией плагина, но в архитектурах Enhanced Linked Mode и Hybrid Linked Mode может быть несколько серверов vCenter, каждый из которых может содержать свою версию плагина.

В этом случае vSphere Client обрабатывает плагины двумя способами:

• Local plug-in architecture - в этом случае оперирование происходит с самой новой версией плагина, обнаруженной на всех доступных серверах vCenter. При этом все остальные версии плагина игнорируются. Если обнаруживается более новая версия плагина на одном из серверов vCenter - происходит ее апгрейд.
• Remote plug-in architecture - она появилась в vSphere 6.7 Update 1. В этом случае происходит поддержка своей версии плагина на уровне того сервера vCenter, с которым происходит оперирование со стороны vSphere Client. Такое поведение используется, например, в среде Hybrid Linked Mode, где версии плагинов и серверов vCenter могут отличаться очень значительно. В этом случае все версии плагина скачиваются с соответствующих экземпляров vCenter и работа со стороны vSphere Client происходит с каждой версией как с независимым плагином.

Ну и напоследок приведем статусы, которые могут возникать при развертывании и апгрейде плагинов:

In progress

Плагин находится в стадии развертывания.

Deployed

Плагин установлен и доступен для использования через интерфейс vSphere Client.

Failed

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

• Download error
  • Установка из незащищенного места - используется http вместо https.
  • Невозможно получить URL плагина.
  • vSphere Client не авторизован для скачивания плагина.
• Packaging error
  • Поврежден zip-пакет плагина.
  • Отсутствует файл манифеста.
  • Отсутствует папка plugins.
  • Отсутствуют необходимые бандлы в плагине.
• Deployment error
  • Ошибка связей (Dependency error) при развертывании плагина на vSphere Client.
  • Собственная ошибка плагина (Runtime plug-in error).
Incompatible

Показывается когда плагин не поддерживается для данной версии vSphere Client. Возможные причины:

• Плагин добавлен в черный список администратором.
• В плагине прописано, что он поддерживает только конкретные версии vSphere Client (и вашей в списке нет).
• Это плагин на базе флэш-интерфейса под старый клиент vSphere Web Client.

Таги: VMware, vSphere, Plugin, Update, Troubleshooting, Client, Upgrade, vCenter



Обновления, патчи, апгрейды и нумерация версий VMware vCenter на платформе vSphere - как это устроено?




Очень часто администраторы платформы VMware vSphere задаются следующими вопросами о версиях продукта vCenter: какая разница между обновлением vCenter (он же update) и патчем (patch)? в чем отличие апгрейда (upgrade) и миграции (migration)? почему некоторые версии vCenter нумеруются как-то отдельно? Попробуем дать ответы на эти вопросы ниже, используя материал вот этой статьи в блоге VMware.

Первое, что нужно понять - это нумерация версий vCenter. Она подразумевает 2 компонента - номер версии (например, vCenter 6.7 Update 2a) и номер билда (например, 13643870):



Номер версии имеет также и цифровое обозначение. Если вы зайдете в интерфейс VMware Appliance Management Interface (VAMI), то увидите там номер билда (13643870), а также полный номер версии (6.7.0.31000):



Если же вы зайдете в vSphere Client и перейдете там на вкладку Summary для вашего сервера vCenter (в данном случае vCenter Server Appliance, vCSA), то увидите там версию 6.7.0:



В данном случае в поле Build указан номер билда клиента vSphere Client (13639324), и не стоит его путать с номером билда самого vCenter. Все это как-то более-менее соотносится между собой (VAMI дает более полную информацию о цифровом номере версии).

Теперь, чтобы сложить все это в единую картину и соотнести с датой релиза конкретной версии vCenter, существует статья базы знаний KB 2143838, где есть полезная табличка:



Обратите внимание на последнюю колонку - Client/MOB/vpxd.log. Это версия клиента vSphere Client, и именно она появится в лог-файле vpxd.log, поэтому не стоит удивляться, что она отличается от номера билда vCenter.

Теперь перейдем к апдейтам и патчам. vCenter Server Update - это полноценное обновление платформы, которое может включать в себя новый функционал, исправления ошибок или доработки существующей функциональности. Выходит апдейт довольно редко и имеет свое строковое наименование (например, vCenter 6.7 Update 2a). Для апдейта всегда выпускается документ Release Notes, и его можно скачать через my.vmware.com.

Патч - это постоянно выпускаемое небольшое обновление для vCenter, которое поддерживает уровень безопасности, закрывает критические уязвимости, исправляет фатальные ошибки и т.п. Он может относиться к вспомогательным компонентам vCSA, например, Photon OS, базе данных Postgres DB или фреймворку Java.

Для патча нет выделенного документа Reelase Notes, но информация о нововведениях доступна в VMware vCenter Server Appliance Photon OS Security Patches. Патчи нельзя скачать через my.vmware.com, но они загружаются через VMware Patch Portal. Само собой, патчи включаются в апдейты, выпускаемые на какой-то момент времени. Патчи накатываются в рамках одного цифрового обновления. То есть 6.7 Update 1 не патчится напрямую на 6.7 Update 2b, сначала надо накатить апдейт 6.7 Update 2a, а затем уже пропатчиться на 6.7 Update 2b.

Также на VMware Patch Portal вы можете найти ISO-образы vCenter Server, но их не надо использовать для новых развертываний, они нужны только для восстановления вашего vCenter Server Appliance, если вы используете резервное копирование на уровне файлов.

Теперь перейдем к разнице между апгрейдом и миграцией. Апгрейд - это обновление мажорной версии сервера vCenter одного типа развертывания (например, вы делаете апгрейд vCenter Server Appliance 6.5 на vCenter Server Appliance 6.7). Миграция - это когда вы меняете тип развертывания vCenter, переходя, например, с Windows-платформы на Linux (к примеру, vCenter Server 6.5 for Windows мигрируете на vCenter Server Appliance 6.7).

Если вы обновляете vCSA 6.5 на 6.7, то апгрейд идет как бы ненастоящий - развертывается новый виртуальный модуль vCSA 6.7, и на него переезжают все настройки (FQDN, IP, сертификаты и UUID), а также содержимое базы данных vCSA 6.5.

Также надо упомянуть и back-in-time upgrade - это когда вы хотите обновить, например, vSphere 6.5 Update 2d на vSphere 6.7 Update 1. Прямое обновление тут не поддерживается, так как  Update 2d для версии 6.5 вышел позднее, чем Update 1 для версии 6.7. То есть Update 2d содержит код, которого нет в Update 1, а значит это может вызвать потенциальные конфликты.

Поэтому для каждой новой версии vCenter выпускается раздел Upgrade Notes for this Release, где можно найти информацию о возможности апгрейда:




Таги: VMware, vCenter, Update, Upgrade, vSphere



1 | 2 | 3    >   >>