Обновляем vCenter Server до версии 7.0U2

9 марта 2021 года прилетел второй серьезный апдейт нашей «семерки», и, несомненно, многие уже сгорают от нетерпения протестировать на практике его новые функции в своей «песочнице», а кого-то настойчиво подгоняет политика компании, заставляющая использовать только самые современные и совместимые с последними решениями выбранного вендора версии. Тем более что изменений и улучшений масса, включая кое-какие косметические и функциональные новшества в самом клиенте vSphere, существенное расширение пользы и возможностей vLCM и новые опции CLI-разворота vCenter Server, о котором, обязательно, мы сегодня еще поговорим.

Все, заслуживающее внимание в vCenter Server 7.0U2, подробнейшим образом перечислялось в опубликованном нами недавно релизе «VMware vCenter Server 7.0 Update 2 Release Notes», а об имеющихся проблемах и ошибках, актуальных и на сегодняшний день, говорилось в статье «Troubleshooting VMware vCenter Server 7.0U2». Кстати, последний материал перед началом ознакомления с нижеследующим крайне рекомендуется прочесть, так как там, как раз, и приведены несколько касающихся именно процедур обновления неприятностей с путями их обхода.

Пожалуй, если вас заинтересовал вопрос непосредственного апгрейда vCenter Server до версии 7.0U2, базовую теорию, его касающуюся, приводить здесь смысла нет – все это в деталях рассматривалось в нашем старом материале «Инсталляция и разворот VMware vSphere 7.0». И, к слову, что касается «зеленого» разворота компонентов vSphere с нуля, по большому счету, базовые принципы с момента выхода мажорной версии кардинально не поменялись, поэтому с легкостью можно пользоваться его механизмами. Однако, по требованиям и совместимости появились некоторые замечания – ниже на них, конечно же, остановимся самым подробным образом. И поговорим обо всем, что нужно для успешного обновления нашего vCenter Server.

Требования и совместимость

vCenter Server – штука, поистине, вездесущая. Без него не получится нормально организовать ни виртуальные сети, ни VDI-решения, ни гибридную облачную среду или же системы аварийной миграции и восстановления данных VMware. Все компоненты членов семейства vRealize, так здорово облегчающие жизнь рядового виртуализатора, аналогично без vCenter Server не существуют. Подсмотреть, будут ли с его последней версией совместимы используемые решения и продукты можно в PIM. А совместимость хостов с партнерскими продуктами, версиями ОС, «железом» и прочим, как всегда, – в VCG.

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

Поддерживаемые пути апгрейда vCenter Server

vCenter Server можно обновлять с версии на версию согласно выложенной здесь матрице. Учтите, что до 7.0.х это можно делать напрямую, только, если у вас предыдущая версия не древнее 6.5.0, плюс несколько исключений:

В остальных случаях, вначале придется довести до нее, а уж затем – обновляться до последней.

Системные требования

vCenter Server Appliance (включая vLCM, работающий как сервис на Аppliance) нуждается в такой спецификации вычислительного оборудования, в разрезе типов разворота:

Тип разворота	CPU, шт.	Память, ГБ
Tiny	2	12
Small	4	19
Medium	8	28
Large	16	37
X-Large	24	56

Ресурсы хранилища для vCenter Server Appliance:

Тип разворота	Default, ГБ	Large, ГБ	X-Large, ГБ
Tiny	415	1490	3245
Small	480	1535	3295
Medium	700	1700	3460
Large	1065	1765	3525
X-Large	1805	1905	3665

Новые конфигурационные лимиты изложены, традиционно, в специальной базе-инструменте по ссылке.

Версионность хостов

vCenter Server 7.0.х может управлять ESXi-хостами из одного кластера комбинации 6.5 и 7.0 версий, однако 6.0 и старше не поддерживает. Если в наличии 6.0 и более древние хосты, вначале рекомендуется их проапгрейдить до 6.5 и свежее, и только после этого приступать к обновлению vCenter Server.

Требования к сети

Для vCenter Server важно добиться беспрепятственной пересылки данных на каждый управляемый хост и получения данных из клиента vSphere. Доступ предоставляется через предопределенные TCP и UDP порты. Если управление компонентами сети осуществляется с внешней стороны файервола, придется перенастроить файервол так, чтобы доступ к соответствующим портам был разрешен. Со списком необходимых для открытия портов можно ознакомиться здесь.

При развороте нового vCenter Server Appliance во временных настройках сети можно назначить статический IP-адрес. После апгрейда Appliance освободит этот статический айпишник и получит сетевые настройки от старого Appliance. Если используется DHCP вместо статического IP, следует убедиться после разворота, что имя Appliance проапдейтилось на DNS (попробовать пропинговать).

Важно! Если используете FQDN, следует убедиться, что клиентская машина, с которой осуществляется разворот Appliance vCenter Server, и сеть, где он разворачивается, используют один и тот же DNS-сервер. И FQDN должно быть расположено в прямой и обратной DNS-зоне, и, если это возможно, реплицировано для имени хоста vCenter Server. Проверить можно командой:

nslookup -nosearch -nodefname FQDN_or_IP_address

Апгрейд и миграция с vCenter Server 6.5/6.7 на 7.0.х поддерживается для чистых IPv4, либо же чистых IPv6-сетей. Если изначально конфигурация была представлена в смешанном режиме сред IPv4 и IPv6, произойдет трансфер конфигурации, опираясь на исходную конфигурацию разворота. А именно:

Исходная конфигурация	Конфигурация после трансфера в процессе обновления или миграции	Не поддерживается апгрейдом или миграцией (трансфериться не будет)
DHCPv6 and AUTOv6	DHCPv6	AUTOv6
DHCPv4 and DHCPv6	DHCPv4	DHCPv6
DHCPv4 and AUTOv6	DHCPv4	AUTOv6
DHCPv4 and Static IPv6	Static IPv6	DHCPv4
Static IPv4 and AUTOv6	Static IPv4	AUTOv6
Static IPv4 and DHCPv6	Static IPv4	DHCPv6
Static IPv4 and Static IPv6	Static IPv4 and Static IPv6	–

По вопросу, что делать в таких случаях, обращайтесь к сертифицированным консультантам или в саппорт VMware.

Важно! При развороте vCenter Server Аppliance непосредственно на хосте ESXi non-ephemeral распределенные группы виртуальных портов не отображаются и не поддерживаются. После обновления можно вручную подключить Аppliance к исходной non-ephemeral распределенной группе виртуальных портов.

Поддерживаемые клиентом vSphere гостевые ОС

VMware гарантирует поддержку гостевых операционных систем на Windows 32-bit/64-bit и Mac OS.

Требования к браузеру

Так как мы все делаем теперь через веб-клиент vSphere, озаботиться наличием поддерживаемой версии браузера крайне важно. Сейчас это:

• Google Chrome 75,
• Mozilla Firefox 60,
• Microsoft Edge 79

или свежее. Однако, учтите, что более новые версии браузеров, скорее всего, будут работать, однако VMware их еще не тестировала и за результат не ручается.

Подготовка к обновлению vCenter Server

В качестве подготовки к апгрейду vCenter Server до версии 7.0U2 нам нужно проделать следующее:

1. Сделать бэкап своей конфигурации;
2. Проверить, удовлетворяет ли наша система требованиям и замечаниям по совместимости из раздела «Требования и совместимость» выше;
3. Удалить все неподдерживаемые топологии разворотов или смигрировать их на поддерживаемые. К неподдерживаемым, в частности, относится Platform Services Controller, встроенный или внешний, который еще встречается в vCenter Server 6.5/6.7. Старый вариант в сравнении с современным:

Замечание: Никаких специальных действий по старому PSC от администратора не требуется – разве что при преобразовании его в vCenter Server Аppliance указать управляющую ноду для использования SSO-доменом разворота. В доменах с несколькими инстансами vCenter Server нужно указать партнера по репликации SSO, который будет использоваться для каждого последующего vCenter Server. В остальном, все произойдет автоматически, единственное что – в конце нужно декомиссовать PSC, если он был внешним.

Далее нужно будет скачать новую версию vCenter Server отсюда:

Инсталлятор vCenter Server содержит выполняемые файлы, как для GUI-метода обновления, так и для CLI, о которых поговорим ниже.

Важно! vCenter Server – это всегда первое, что мы обновляем в нашей виртуальной среде. Порядок такой: сначала vCenter Server, потом гипервизоры, потом – ВМ и все остальное.

vCenter Server использует встроенную БД PostgreSQL и в процессе апгрейда нужно выбрать размер хранилища для нового Аppliance, подходящий размеру базы данных. Также vCenter Server 7.0.х использует встроенную службу vSphere Lifecycle Manager, позволяющую централизованно и весьма несложно выполнять операции по управлению жизненным циклом кластеров с хостами ESXi. В т. ч. и действия по обновлению и пропатчиванию, а также апгрейд «железа» ВМ и VMware Tools.

Подготовка к апгрейду в НА-средах

Помимо всего, оговоренного выше, в генеральных шагах по подготовке одиночного vCenter Server, если имеем дело с НА-средой, нужно проверить следующее:

• Работоспособны ли все три Appliance vCenter Server (активная, пассивная и нода-свидетель), составляют ли они кластер, и настроена ли активная нода как НА-нода vCenter и является ли она частью кластера;
• Прошел ли НА-кластер vCenter проверку здоровья успешно, все обнаруженные проблемы нужно исправить до обновления. Находится ли он в режиме «enabled»;
• Управляются ли контейнером vCenter Server хосты, на которых предусмотрены ВМ vCenter Server (не «standalone»);
• Размещен ли целевой vCenter Server там же, где и исходный;
• Все ли диски vCenter Server, на котором организован НА-vCenter, находятся в одном датасторе?

Процесс апгрейда vCenter Server до версии 7.0U2

Правильный порядок действий при обновлении vCenter Server наглядно описывается диаграммой:

Именно он и ляжет в основу нашего ТЗ. Мы сегодня рассмотрим наиболее простой для понимания сути процесса вариант с апгрейдом vCenter Server Appliance, и в качестве исходных данных предположим, что у нас в наличии его работающая версия 6.7 с дата-центром и кластером vSAN на борту, в котором всего три хоста с тремя ВМ.

Вообще же, существует два генеральных метода обновления:

• Через GUI инсталлер (двух-этапный, первый этап – разворот нового Appliance, второй – использует vCenter Server Management GUI для конфигурирования нового Appliance с данными источника разворота);
• С помощью Command Line Interface (CLI).

Обновление vCenter Server через GUI

Рассмотрим первый способ апгрейда – самый доступный, простой и понятный, с помощью GUI. Кстати, во многом все осталось почти идентичным предыдущим 6.5 и 6.7, а если грейдитесь и вовсе с 7.0 – процесс будет до боли вам знаком. Разве что визуально интерфейсы несколько сменились, да придется привыкать к новым изображениям иконок… На будущее, когда будете перескакивать с версии на версию в рамках одной мажорной (с 7.0U2, к примеру, на ожидаемую 7.1 и т.д.), вообще можно пользоваться менеджмент-консолью, в левом боковом меню которой есть специальный пункт «Update»:

Но, вернемся к предмету нашего разговора. Как уже упоминалось, процедура состоит из двух этапов. А теперь, пробежимся по ним, по порядку.

Этап 1

На первом этапе нам нужно развернуть новый инстанс vCSA, куда на второй стадии продублируется старый, но уже в новой версии. Находим предварительно скаченный нами новый пакет vCSA, в нем запускаемое приложение «installer», после чего откроется визард Easy Installer, в котором нас интересует именно второй блок – «Upgrade»:

И последовательно проходим все его пункты:

• «Introduction». Здесь нам вкратце расскажут, что нас ждет по ходу прохождения визарда и к какому результату мы придем. «Next»:

• «End user license agreement». Традиционное лицензионное соглашение, не забываем ставить галочку и снова «Next»:

• «Connect to source appliance». Так как это у нас не гринфилд-разворот, здесь нам надо задать способ подключения к исходному Аppliance устаревшей версии – задаем его FQDN и порт подключения:

Нажимаем на кнопку «Connect to source», чтобы проверить подключение и можно было дальше работать с дублированием нашего Аppliance, после чего в этом пункте список настроек дополнится еще несколькими полями для заполнения:

Здесь вписываем данные учетной записи администратора и адрес ESXi-хоста, на котором был развернут наш vCenter Server, его порт, пользовательские логин и пароль. После нажатия на «Next» вылетит предупреждение об отпечатке, соглашаемся с ним кнопкой «Yes»:

• «vCenter Server deployment target». Пункт, в котором мы рассказываем о нашем будущем обновленном инстансе vCSA (целевом) – вбиваем адрес его хоста, порт и данные учетной записи рута. «Next»:

Снова покажется предупреждение о сертификате, соглашаемся по «Yes»:

• «Set up target vCenter Server VM». Называем нашу будущую виртуалку и устанавливаем для нее пароли root. «Next»:

• «Select deployment size». Выбираем размер разворота (в нашей демонстрации хватит и минималки с дефолтным размером стораджа). «Next»:

• «Select datastore». Разумно поставить галочку в «Show only compatible datastores» – особенно, в крупных системах со множеством хранилищ, и галочку в «Enable Thin Disk Mode» для максимальной экономии места и ресурсов. «Next»:

• «Configure network settings». Здесь задаем сетевые настройки нового экземпляра vCSA (сеть размещения, версию протокола, статическое или динамическое назначение адреса – грамотнее, конечно, статика, – даем ему временный IP, указываем маску подсети, дефолтный шлюз и адрес DNS-сервера). «Next»:

• «Ready to complete stage 1». Проверяем, все ли верно задали, и запускаем разворот кнопкой «Finish»:

Какое-то время на экране зависнет бар прогресса:

А затем высветится сообщение об успешном завершении первого этапа, где можно перейти сразу ко второму кнопкой «Continue», что мы и сделаем:

Этап 2

На этом этапе установочный визард попросит выбрать типы данных для трансфера со старого Appliance на новый, пока еще со временными сетевыми настройками. Когда перенос данных закончится, новый Appliance употребит сетевую конфигурацию старого, на нем запустятся все сервисы, а старая версия отключится. Визард второго этапа выглядит менее объемно:

• «Introduction». Здесь снова нам расскажут, что будет происходить и к чему мы придем. Просто жмем «Next»:

• «Connect to source vCenter Server». Вписываем FQDN исходного vCSA, его порт и данные учетной записи администратора, а ниже – адрес его хоста, порт, логин и пароль рута. «Next»:

Может выскочить системное предупреждение, информацию которого нужно принять к сведению, и закрыть кнопкой «Close»:

• «Select upgrade data». Здесь нужно поставить флажок, выбрав, что именно хотим скопировать (конфигурацию и инвентарь/конфигурацию, инвентарь, задачи и события/конфигурацию, инвентарь, задачи, события и метрики производительности). «Next»:

• «Configure CEIP». Предложение присоединиться к программе CEIP – соглашаемся, если хотим, галочкой. «Next»:

• «Ready to complete». Проверяем, все ли настройки правильны, и ставим галочку на подтверждении, что нами предварительно сделан бэкап, после чего запускаем копирование кнопкой «Finish»:

Важно! Если что-то пойдет не так, старый вариант Appliance у нас все еще в системе и на него всегда можно переключиться. Если же переносом удовлетворены, для экономии места впоследствии старую версию рекомендуется удалить.

Выскочит предупреждение о том, что как только целевой vCSA с уже новой версией поднимется, старый выключится. Жмем здесь «ОК»:

После этого будет окошко для ввода учетных данных рута, где нужно нажать на «Login»:

Снова увидим бар прогресса, где все опорные этапы будут постепенно отмечаться галочками:

Когда все завершится, появится сообщение об успешной установке, закрываем его «Close»:

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

Обновление vCenter Server через CLI

Важно! Обновляться через CLI рекомендуется только в том случае, если вы на короткой ноге с синтаксисом JSON. Если очень хочется ему научиться – добро пожаловать вот сюда.

Инсталлятор vCenter Server включает JSON-шаблоны с минимумом конфигурационных параметров для всех опций разворота. Их можно найти в каталоге «vcsa-cli-installer/templates/install». Каждой опции разворота отвечает по одному шаблону – для Appliance на ESXi-хосте, и еще один – для разворота Appliance на инстансе vCenter Server. Вот список всех шаблонов, включенных в инсталлятор, с описанием их содержимого (минимальных параметров конфигурации):

embedded_vCSA_on_ESXi.json – для развертывания vCenter Server Appliance на хосте ESXi;

vCSA_with_cluster_on_ESXi.json – для разворота vCenter Server Appliance с одной нодой vSAN и кластером, управляемым vLCM, на ESXi-хосте;

embedded_vCSA_on_VC.json – для разворота vCSA на инстансе vCenter Server;

embedded_vCSA_replication_on_ESXi.json – для разворота vCenter Server Appliance как партнера по репликации на другой встроенный vCenter Server на ESXi-хосте;

embedded_vCSA_replication_on_VC.json – для разворота vCenter Server Appliance как партнера по репликации на другой vCenter Server Appliance на инстансе vCenter Server.

Полный список конфигурационных параметров и их описаний можно получить, если пройти в поддиректорию инсталлятора и запустить команду: «vcsa-deploy install –template-help».

Подготовка JSON-шаблонов к развороту

После загрузки и монтировки инсталлятора проходим в папку «templates» директории «vcsa-cli-installer» и копируем шаблоны из ее подпапки «install» в свое рабочее пространство.

Важно! Учтите, что путь к конфигурационным файлам JSON должен состоять исключительно из ASCII-символов. Расширенные ASCII не поддерживаются.

Далее делаем следующее:

1. В текстовом редакторе открываем файл шаблона выбранной спецификации (лучше использовать редактор JSON);
2. Заполняем значения для требуемых конфигурационных параметров и, опционально, вводим другие дополнительные параметры и их значения по своему усмотрению (например, если для сети Appliance нужно использовать IPv4-назначение DHCP, в подсекции «network» меняем значение параметра «mode» на «dhcp» и удаляем дефолтные конфигурационные параметры для статического назначения:

“network”: {

            “ip_family”: “ipv4”,

            “mode”: “dhcp”

        },

3. Проверяем валидность сделанных настроек средствами редактора JSON;
4. Сохраняем файл в формате UTF-8 и закрываем его.

Полный список секций и подсекций конфигурационных параметров в файлах развертывания JSON:

Секция	Подсекция	Описание	Параметры	Тип	Описание
new_vcsa	esxi	Используется в развертывании Appliance напрямую на ESXi-хосте	hostname	string	IP-адрес или FQDN целевого ESXi-хоста
			username	string	Имя администратора целевого хоста
			password	string	Пароль администратора целевого хоста
			deployment_network	string	Имя сети, к которой подключается Appliance
			datacenter	string	Дата-центр, который хотим создать
			cluster	string	Имя кластера vSAN или управляемого vLCM
			compression_only	Boolean	Включение компрессии на кластере vSAN
			deduplication_and_compression	Boolean	Включение компрессии и дедупликации на кластере vSAN
			cache_disk		Список UUID или канонических имен дисков для кэша (только SSD)
			capacity_disk		Список UUID или канонических имен дисков для стораджа (SSD/HDD)
			enable_vlcm	Boolean	Значение «true» создаст кластер под управлением vLCM
			datastore	string	Имя хранилища данных, где будут храниться конфигурационные файлы и виртуальные диски Аppliance
			port	integer	Порт HTTPS обратной прокси целевого ESXi-хоста (по дефолту – 443)
	vc	Используется в развертывании Appliance в инвентаре инстанса vCenter Server	hostname	string	IP-адрес или FQDN целевого инстанса vCenter Server
			username	string	Имя администратора vCenter SSO на целевом инстансе vCenter Server
			password	string	Пароль администратора vCenter SSO на целевом инстансе vCenter Server
			deployment_network	string	Имя сети, к которой подключается Appliance
			datacenter	array	Дата-центр, содержащий ESXi-хост или DRS-кластер, на котором будет разворачиваться Appliance
			datastore	string	Имя хранилища данных, где будут храниться конфигурационные файлы и виртуальные диски Аppliance
			port	integer	Порт HTTPS обратной прокси целевого инстанса vCenter Server  (по дефолту – 443)
			target	array	Целевой ESXi-хост или DRS-кластер, на котром будет разворачиваться Appliance
			vm_folder	string	Опционально, имя папки ВМ, где разворачивается Appliance
	appliance	Параметры Appliance	thin_disk_mode	Boolean	Если хочется работать с Appliance с тонкими виртуальными дисками, выставляем значение «true»
			deployment_option	string	Размер Appliance (см. ниже расшифровку в «Важно!…»)
			image	string	Опционально, локальный путь или URL инсталляционного пакета Appliance
			name	string	Имя ВМ для Appliance
			ovftool_path	string	Опционально, локальный путь к файлу или выполняемый файл OVF Tool (по дефолту используется инстанс OVF Tool, включенный в ISO в папке «vcsa/ovftool»)
	network	Параметры сети для Appliance	ip_family	string	IP-версия сети Appliance («ipv4»/«ipv6»)
			mode	string	IP-назначение сети Appliance («static»/«dhcp»)
			ip	string	IP-адрес Appliance (только если по «mode» выбрано «static»)
			dns_servers	string или array	IP-адрес одного или нескольких DNS-серверов (не поддерживается, если по «mode» значение «DHCP»)
			prefix	string	Длина префикса сети (только если по «mode» выбрано «static», 0-32 для IPv4 или 0-128 для IPv6)
			gateway	string	IP-адрес дефолтного шлюза (если IPv6, значение просто «default»)
			ports	string	Опционально, номера портов, которые vCenter Server Аppliance использует для прямых HTTP-подключений
			system_name	string	Первичная сетевая идентификация (IP или FQDN, лучше FQDN)
	os	Параметры ОС для Appliance	password	string	Пароль рута для ОС Appliance
			ntp_servers	string или array	Опционально, имена хостов или IP-адреса одного или более NTP-серверов для синхронизации времени
			ssh_enable	Boolean	«true» для включения доступа по SSH. Нужно для НА
			time_tools_sync	Boolean	Опционально, если «true», Appliance будет развернут с синхронизацией времени с VMware Tools
	sso	Параметры SSO для Appliance	password	string	Пароль администратора SSO vCenter («administrator@your_domain_name», где «your_domain_name» – имя домена)
			domain_name	string	Имя домена SSO vCenter (например, «vsphere.local»)
			replication_partner_hostname	string	Системное имя партнера vCenter Server, если разворачивается партнер по репликации в существующем vCenter SSO-домене
			sso_port	integer	Обратный HTTPS-прокси порт партнера vCenter Server (дефолтный – 443). Только если у партнера есть пользовательский обратный порт прокси
	ovftool_arguments	Опциональная подсекция для добавления произвольных аргументов и их значений в команду OVF Tool, генерируемую установщиком
ceip	settings	Присоединение к CEIP	ceip_enabled	Boolean	Если «true», то соглашаемся с присоединением

Важно! Некоторые важные замечания по приведенной таблице:

• Заполняется либо «esxi», либо «vc» подсекция, в зависимости от того, какой именно тип разворота необходим (см. выше);

• Любые вводимые пароли должны быть на 8-20 символов, минимум одна большая буква, одна маленькая, одна цифра, один спецсимвол. Все символ должны быть ASCII, без пробелов;

• Параметры из «ovftool_arguments» инсталлятором vCenter Server не валидируются. Если OVF Tool не распознает эти аргументы, разворот может дать сбой;

• Можно выбрать только что-то одно из двух: или параметру «compression_only» назначить «true», или «deduplication_and_compression»;

• Хранилище данных должно быть доступно с ESXi-хоста. При использовании режима тонкого диска, его размер должен быть не меньшим 25 ГБ;

• Если дата-центр находится в папке или структуре папок, значение по «datacenter» нужно указывать как разделенный запятыми список строк. Например: «[“parent_folder”, “child_folder”, “datacenter_name”]». Значение чувствительно к регистру;

• В «target» должно указываться имя, показываемое в инвентаре vCenter Server (если там IP-адрес, то и значение – IP-адрес, если FQDN – то FQDN). Если целевой хост ESXi или DRS-кластер находятся в папке или структуре папок, следует указывать значение как список строк, разделенных запятыми. Например: «[“parent_folder”, “child_folder”, “esxi-host.domain.com”]». Если целевой ESXi-хост является частью кластера, путь нужно указывать как список разделенных запятыми строк (например, «[“cluster_name”, “esxi-host.domain.com”]»). Значение чувствительно к регистру;

• По «thin_disk_mode» в подсекции «appliance» выставляется:

  • «tiny» – до 10 хостов и 100 ВМ (2 CPU, 12 ГБ памяти и 315 ГБ хранилища);

  • «tiny-lstorage» – до 10 хостов и 100 ВМ (2 CPU, 12 ГБ памяти и 1390 ГБ хранилища);

  • «tiny-xlstorage» – до 10 хостов и 100 ВМ (2 CPU, 12 ГБ памяти и 3145 ГБ хранилища);

  • «small» – до 100 хостов и 1000 ВМ (4 CPU, 19 ГБ памяти и 380 ГБ хранилища);

  • «small-lstorage» – до 100 хостов и 1000 ВМ (4 CPU, 19 ГБ памяти и 1435 ГБ хранилища);

  • «small-xlstorage» – до 100 хостов и 1000 ВМ (4 CPU, 19 ГБ памяти и 3195 ГБ хранилища);

  • «medium» – до 400 хостов и 4000 ВМ (8 CPU, 28 ГБ памяти и 600 ГБ хранилища);

  • «medium-lstorage» – до 400 хостов и 4000 ВМ (8 CPU, 28 ГБ памяти и 1600 ГБ хранилища);

  • «medium-xlstorage» – до 400 хостов и 4000 ВМ (8 CPU, 28 ГБ памяти и 3360 ГБ хранилища);

  • «large» – до 400 хостов и 4000 ВМ (16 CPU, 37 ГБ памяти и 965 ГБ хранилища);

  • «large-lstorage» – до 400 хостов и 4000 ВМ (16 CPU, 37 ГБ памяти и 1665 ГБ хранилища);

  • «large-xlstorage» – до 400 хостов и 4000 ВМ (16 CPU, 37 ГБ памяти и 3425 ГБ хранилища);

  • «xlarge» – до 2000 хостов и 35000 ВМ (24 CPU, 56 ГБ памяти и 1705 ГБ хранилища);

  • «xlarge-lstorage» – до 2000 хостов и 35000 ВМ (24 CPU, 56 ГБ памяти и 1805 ГБ хранилища);

  • «xlarge-xlstorage» – до 2000 хостов и 35000 ВМ (24 CPU, 56 ГБ памяти и 3565 ГБ хранилища);

• Если указывается больше одного DNS-сервера в «dns_servers» подсекции «network», список их строк разделяется запятыми. Например: «[“x.y.z.a”, “x.y.z.b”]» или «”x.y.z.a, x.y.z.b”»;

• Если хочется настроить HTTP и HTTPS-порты для vCenter Server (не дефолтные 80 или 443), в «ports» подсекции «network» выставляем значение «”rhttpproxy.ext.port1″:”port_number”» для HTTP-порта и «”ext.port2:”port_number“» – для HTTPS, где «port_number» – конкретный номер порта;

• Чтобы задать более одного NTP-сервера в «ntp_servers» подсекции «os», вписываем их список строк через запятую. Например: «[“x.y.z.a”, “x.y.z.b”]» или «”x.y.z.a, x.y.z.b”»;

• Если в подсекции «os» по «ntp_servers» перечислялись соответствующие сервера, в «time_tools_sync» ничего не ставим;

• Если значение «ceip_enabled» подсекции «settings» секции «ceip» выставлено на «true», команда разворота должна содержать аргумент «–acknowledge-ceip».

Разворот одиночного vCenter Server

После того, как мы отредактировали наши JSON-шаблоны нужным образом, проходим в поддиректорию «vcsa-cli-installer» в зависимости от типа ОС:

• В «vcsa-cli-installer\win32», если у нас Windows;
• В «vcsa-cli-installer/lin64», если Linux;
• В «vcsa-cli-installer/mac», если Mac OS.

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

vcsa-deploy install –precheck-only path_to_the_json_file

где «path_to_the_json_file» – это путь к нашему JSON-файлу.

Сам разворот после этого запускается командой:

vcsa-deploy install –accept-eula –acknowledge-ceip optional_arguments path_to_the_json_file

где «path_to_the_json_file» – это путь к нашему JSON-файлу, «—acknowledge-ceip» (см. выше) проставляется, если хотим присоединиться к CEIP, а «optional_arguments» – опциональные аргументы, если таковые необходимы.

Пакетный разворот vCenter Server

Если нам нужно развернуть несколько Appliance vCenter Server, создаем JSON-шаблоны для всех инстансов vCenter Server нашего разворота. Инсталлятор CLI произведет оценку его топологии с использованием подготовленных шаблонов и определит порядок действий.

Важно! В этом случае обязательно назначить всем инстансам vCenter Server статические IP, зависящие друг от друга.

Доступен пакетный разворот, для которого нужно поместить JSON-шаблоны в одну директорию, для чего в рабочем пространстве создаем с ними папку, а далее проходим в субдиректорию инсталлятора, в зависимости от типа ОС (см. выше для одиночного разворота), запускаем опционально пре-чек, указав путь к этой папке со всеми шаблонами, и далее – сам разворот аналогичной командой:

vcsa-deploy install –accept-eula –acknowledge-ceip optional_arguments MyWorkspace/BatchDeploy

где «MyWorkspace/BatchDeploy» – путь к папке с пакетом шаблонов, а все остальное – как и в сольном развертывании.

Операции пост-апгрейда

В первую очередь, после миграции нашего vCenter Server временно данный ему IP-адрес изменится на тот, который использовался старым Appliance, как, впрочем, и имя хоста – после окончания работы со старым Appliance и его отключения. Временный адрес при этом высвобождается. Все это происходит автоматически, поэтому администратору специально на этот счет никаких действий предпринимать не требуется.

Если ранее использовался внешний инстанс Update Manager, работающий на Windows, после обновления он смигрирует на встроенный расширенный сервис vSphere Lifecycle Manager в Appliance vCenter Server. Аналогично со встроенным старым инстансом Update Manager. Однако, во втором случае, так как он использовал встроенную БД PostgreSQL, перед апгрейдом следует запустить Migration Assistant на исходном инстансе.

Выше, в подразделе «Требования к сети», мы упоминали о проблемах (частичной миграции) в смешанных средах IPv4 и IPv6. И, если у вас именно такая ситуация, по завершению обновления нужно будет все вернуть на свои места. То же самое с прямой установкой Appliance vCenter Server на ESXi-хост и присутствием non-ephemeral распределенных виртуальных порт-групп – после апгрейда придется вручную подключать Appliance к исходной.

Помимо этого, необходимо:

• Завершить все необходимые реконфигурации компонентов, исходя из изменений в процессе апгрейда (проверить, правилен ли IP-адрес, сетевая регистрация, домен);
• Проверить, все ли хорошо с процессами аутентификации, не изменилась ли AD-регистрация, если используется;
• Опционально, но рекомендовано, обновить все ESXi-хосты в инвентаре vCenter Server до той же версии, что и vCenter Server. Инструкции по этому вопросу – в нашем материале «Обновляем ESXi до версии 7.0U2» ();
• Проверить, валидны ли сертификаты, и, если нужно, их обновить;
• Убедиться, что все данные инвентаря корректно смигрированы (история событий, диаграммы производительности, пользователи, разрешения и роли).

Если что-то не так, выполняем траблшутинг и исправляем найденное.

Большинство вышеуказанных проверок потребуют первоначального входа в vCenter Server через клиент vSphere, используя URL инстанса vCenter Server («https://<IP-адрес или FQDN vCenter Server>») и выбрав «Launch vSphere Client (HTML5)», или же введя в браузере URL клиента vSphere. После ввода данных учетной записи может появиться предупреждение о не доверенном SSL-сертификате (в зависимости от линии политики в этом отношении, либо игнорируем, в принципе, либо закрываем и инсталлируем дефолтный, либо устанавливаем подписанный сертификат).

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

На самом деле, больше рассказывать об обновлении vCenter Server до версии 7.0U2 особо нечего. Напоследок, рекомендуем ознакомиться с нашей второй статьей из цикла обновления компонентов vSphere до актуальной версии – «Обновляем ESXi до версии 7.0U2». Если же на практике будут какие-то проблемы, добро пожаловать в нашу секцию траблшутинга по соответствующим темам, либо же пишите в саппорт VMware, консультируйтесь с квалифицированными специалистами сферы.