Декілька місяців пройшло з того моменту, як оновилася наша «сфера». А це означає, що вже можна безпечно оновлюватися до найсвіжішої версії продукту, не хвилюючись, що він «сирий» й ховає в собі деякі неприємні несподіванки. Ба більше, в 8-му мажорному релізі змінилося досить чимало, й усім віртуалізаторам кортить протестувати ці зміни й нові фішки у всьому їх різноманітті на практиці. vSphere 8.0 у подробицях ми обговорювали в нашій нещодавній новині «Що змінилося в VMware vSphere 8.0?», а новачки на теренах VMware можуть знайти усі необхідні для розгортання цього продукту рекомендації в матеріалі «Інсталяція vSphere 8.0 з нуля». На обидві статті далі будемо багато посилатися зі зрозумілих причин.
Нижче у всіх подробицях торкнемося питань вимог та сумісності нової версії, розповімо, як до її апгрейду потрібно готуватися, а також докладно наведемо процедуру самого оновлення з усіма варіантами й методиками, що можуть застосовуватися. В останньому вищезгаданому матеріалі докладно викладена уся необхідна теорія – зараз на ній зупинятися не будемо задля економії часу. Тому, кому потрібно освіжити знання, будь-ласка, звертайтесь до нього.
Єдине, що залишилось відмітити, перед тим, як безпосередньо перейти до справи: так як продукт vSphere складається з двох глобальних компонентів (гіпервізора ESXi та керуючої платформи vCenter Server), далі говорити про його оновлення будемо саме у розрізі апгрейду цих складників.
Вимоги та сумісність
Загальним і найпершим зауваженням, що має випереджати усю нашу подальшу розмову, є те, що версія vCenter завжди має бути такою самою або свіжішою за версію ESXi.
Важливо! Процес оновлення ESXi блокує VIB, що не мають контрольної суми SHA256 в своїх метаданих (VIB для ESXi, випущених раніше за 6.7). Такі VIB попередньо маємо замістити тими, що стосуються більш свіжих версій.
vSphere 8.0 вже остаточно не сумісна з VMware NSX for vSphere (NSX-V). Якщо у вас саме такий варіант мережевої віртуалізації, варто розглянути варіант міграції на NSX-Т, або доведеться залишатися на старій версії vSphere.
Таблицю сумісності з іншими продуктами VMware ми наводили у підрозділі «Вимоги та сумісність» матеріалу «Інсталяція vSphere 8.0 з нуля». А от з якої на яку версію можна апгрейдіти, власне, компоненти платформи наведемо у наступному підрозділі. У розрізі всіх інших питань сумісності (апаратна частина, драйвери, ОС, KMS, валідовані рішення партнерів та багато чого ще) можна звертатися до такого корисного інструменту, як VMware Compatibility Guide.
Підтримувані шляхи оновлення та версійність хостів
Щоб дізнатися, з яких версій ESXi та vCenter можна дістатися до найсвіжішої в один крок, варто скористатися вкладкою «Upgrade Path» в дуже зручному інструменті VMware Interoperability Matrix. Щодо vCenter Server ця матриця виглядає таким чином (спеціально навели лише з 6-ї мажорної, адже усе, що є більш давнім, зараз у вжитку стріти доволі важко):
А по ESXi отак:
Тобто, як ми бачимо, оновлюватися напряму до «вісімки» можна лише з 6.7 або 7-х версій. При цьому оновлений vCenter Server 8.0 зможе керувати хостами ESXi версій 6.7+.
Зауваження. Прямий апгрейд з 6.5 на 8.0 хостів ESXi не підтримується, через наявність у перших VMKAPI версії 2.4, а у «вісімці» це було прибрано взагалі. Спочатку доведеться оновити хости до 6.7 таким чином, щоб у них не було VIB, що залежать від VMKAPI 2.4. Докладніше у КБ.
Вимоги до апаратної частини, рівня системного сховища, до сховища, мережі та браузера
Зауваження. Починаючи з 8-ї версії, vSphere перестала підтримувати CPU з маркуванням «End of Support» та «End of Life», чиї моделі наведені у цьому КБ.
Важливо! Якщо хост має пристрій, що підтримується драйвером nmlx4_en, або пристрій був видалений у драйвері lpfc, при спробі оновитися можна втратити доступ до сховища чи датасторів, до мережі або попередні конфігурації на хості. Це невідновні проблеми. Щоб їх уникнути, до апгрейду треба замістити відповідні пристрої. Див. КБ з повним переліком більше не підтримуваних пристроїв.
Максимальне ресурсне охоплення ВМ, а також робота з деякими технологіями (Virtual NUMA Topology, Enhanced Direct Path I/O, Virtual Hyperthreading, vMotion App Notification, VM DataSets, OpenGL 4.3, UEFI 2.7A) можливе тільки при застосуванні 20-ї версії віртуального апаратного забезпечення, але, взагалі, можна ставити й на 10-те, за умови, що воно підтримує 64 vCPU на кожну ВМ в ESXi.
Загалом, усі вимоги до апаратної частини, сховища, мережі, рівня системного сховища, ОС та браузера викладені у нещодавній нашій статті «Інсталяція vSphere 8.0 з нуля», тому зараз повторюватися, гадаємо, недоречно. Усе це поки що актуально, а якщо нас спіткають якісь зміни в майбутньому, обов’язково випустимо новину з подробицями за потреби. Єдине що, нагадаємо, що обов’язково треба пересвідчитись у наявності відкритого порту 22 на vCenter Server appliance, який саме маємо оновлювати, а на хості-джерелі ESXi, що містить наш appliance старої версії, відкритий порт 443.
Підготовка до оновлення vSphere
Одним з найважливіших етапів підготовки до апгрейду vSphere є бекапування конфігурації. Окрім цього нижче поговоримо про всі інші нюанси підготовчих робіт, й у розрізі операцій з нашим vCenter, й щодо того, що стосується хостів.
Підготовка до оновлення vCenter Server
Важливо! Перед оновленням декількох vCenter в Enhanced Link Mode (ELM) за best practice вважається зробити паралельні снепшоти усіх вимкнених vCenter Server та Platform Services Controller у домені Single Sign-On, щоб запобігти проблемам з синхронізацією реплікації.
Перше, що ми маємо зробити, це завантажити новий образ vCenter Server Appliance. Наразі актуальною є версія 8.0.0В – білд 21216066:
І підмонтувати його до фізичного серверу, з якого виконується апгрейд, або до ВМ у мережі. (Як це зробити докладно описувалось в підрозділі «Підготовка до розгортання vCenter Server» матеріалу «Інсталяція vSphere 8.0 з нуля»).
Далі потрібно обов’язково пересвідчитися, що на всіх компонентах мережі vSphere синхронізовані годинники. Чому це важливо й як це зробити, ми розповідали в вищезгаданій статті, у розділі «Синхронізація часу у мережі vSphere».
Загалом, існує усього два методи апгрейду нашого vCenter Server:
- Через GUI-інсталятор,
- CLI-метод.
Підготовка до обох має свої особливості. Розглянемо їх по черзі. Але спершу підготуємо цільовий хост ESXi, якщо його версія старіша за 6.7.
Підготовка хостів до апгрейду vCenter Server
Якщо ваші цільові хости старіші за версію 6.7, у випадку оновлення саме на них, а не на інстансі vCenter Server, передусім потрібно проапгрейдіти їх, мінімум, до версії 6.7. Як це зробити для «сімки», можна почитати у цьому нашому матеріалі.
Якщо ваші цільові хости не старіші за 6.7 версію, перед тим, як вдатися до оновлення нашого vCenter Server, обов’язково треба пересвідчитися, що вони не в режимі техобслуговування чи в локдауні, й до того ж що вони не є частиною автоматизованих DRS-кластерів (в останньому випадку треба зайти у налаштування цих хостів й змінити їх Automation Level на Manual чи Partially Automated, інакше прямо в процесі оновлення вони можуть раптово перезавантажитися).
Підготовка до оновлення vCenter Server через GUI
Етапи підготовки через GUI включають у себе й підготовку хостів, що є спільним і для цього методу, і для CLI. Щодо решти обов’язково треба вдатися до бекапування силами графічного інтерфейсу та також дуже бажано заздалегідь виписати усю потрібну в процесі інформацію.
Бекапування vCenter Server
Щодо vCenter Server відомо декілька методів бекапування й відновлення задля захисту даних, в тому числі й при операціях оновлення версії аppliance, з можливістю безпечного шифрування:
- Бекап на основі файлів (за розкладом – ми його, ймовірно, розглянемо в майбутній статті про адміністрування vSphere0; через vCenter Server Appliance Management Interface; через GUI-інсталятор appliance – як невід’ємна частка процесу апгрейду й майбутня можливість відновлення з бекапу);
- Бекап на основі образів (за допомогою vSphere Storage API – Data Protection з використанням стороннього продукту бекапування, процес залежить від вендора продукту, тому описувати його тут немає сенсу).
У GUI керування нашим appliance vCenter Server (vCenter Server Appliance Management Interface) у бічному меню є спеціальний пункт Backup, зайшовши в який побачимо посередині екрану кнопку BACKUP NOW, після натискання якої попадемо в віконце, де треба буде вказати локацію збереження бекапу (використовуємо синтаксис «protocol:<server-address<:port-number>/folder/subfolder»), ввести дані облікового запису для root, й поставити галочку в блоці, який вказує, які саме дані хочемо зберегти: статистику, події та задачі, чи інвентар і конфігурацію.
Коли натиснемо START, процес розпочнеться. Зауважте, що бекап не зберігається на vCenter Server Appliance.
Якщо у процесі оновлення в нас щось піде не так, ми завжди зможемо повернутися до відправної точки, скориставшись опцією вітального вікна інсталятора нашого appliance vCenter Server – його четвертим блоком – Restore:
Одразу, забігаючи наперед, скажемо, що якщо в нас вже є збережений за допомогою vCenter Server Appliance Management Interface бекап, опція Restore дарує нам своєрідне комбо: розгорнеться новий appliance й при цьому він одразу заповниться даними, що зберіглися у створеному нами раніше бекапі.
Підготовка необхідної інформації для оновлення vCenter Server через GUI
У процесі апгрейду vCenter Server до версії 8.0 адміністратору, йдучи пунктами наших стадій інсталятора GUI, потрібно буде робити багато виборів та вводів, отже, розумним буде заздалегідь виписати собі усі необхідні дані. А саме:
- FQDN чи IP-адресу appliance-джерела, яке оновлюємо;
- HTTPS-порт appliance-джерела (дефолтний – 443);
- дані облікового запису адміністратора vCenter Single Sign-On appliance-джерела (дефолтний логін – administrator@vsphere.local);
- пароль користувача root для appliance-джерела;
- FQDN чи IP-адресу сервера-джерела, на якому розташований оновлюваний appliance;
- HTTPS-порт сервера-джерела (дефолтний – 443);
- дані облікового запису (якщо сервер-джерело є ESXi-хостом, користуємось root, якщо сервер-джерело – це інстанс vCenter Server: «user_name@your_domain_name»);
- FQDN чи IP-адресу цільового серверу, на якому будемо розгортати новий appliance (може бути ESXi-хостом або інстансом vCenter Server);
- HTTPS-порт цільового серверу (дефолтний – 443);
- дані облікового запису користувача з привілеями адміністратора (якщо цільовий сервер є ESXi-хостом, користуємось root, якщо цільовий сервер – це інстанс vCenter Server: «user_name@your_domain_name»);
- дата-центр з інвентаря vCenter Server, на якому бажаємо розгорнути новий appliance, якщо розгортаємось на інстансі vCenter Server (опціонально можна надати папку);
- ESXi-хост чи DRS-кластер з інвентаря дата-центру, на якому бажаємо розгорнути новий appliance, якщо розгортаємось на інстансі vCenter Server;
- ім’я ВМ для нового appliance (не має містити «%», «\», «/», менше 80 знаків в довжину, дефолтне – «VMware vCenter Server Appliance»);
- пароль root для ОС appliance (тільки ASCII-символи без пробілів, мінімум 8 знаків, максимум – 20, щонайменше одну велику, одну маленьку літери, одну цифру, один спецсимвол (наприклад, $#@.!));
- обрати розмір розгортання нового appliance (Tiny/Small/Medium/Large/X-Large – міркування щодо вибору наведені в підрозділі «Вимоги до «заліза», мережі та сховища» статті «Інсталяція vSphere 0 з нуля»);
- обрати розмір сховища для нового appliance (Default/Large/X-Large, міркування щодо вибору див. у вищезгаданому підрозділі, дефолтне – Default);
- ім’я датастора, на якому бажаємо зберігати конфігураційні файли та віртуальні диски нового appliance;
- ім’я мережі, до якої має під’єднатися новий appliance (має бути доступною з сервера-джерела та з фізичної клієнтської машини, на якій виконується розгортання);
- обрати ІР-версію тимчасової адреси appliance (IPv4/IPv6, за дефолтом – IPv4);
- обрати ІР-призначення для тимчасової адреси appliance (static/DHCP, за дефолтом – static);
- FQDN чи IP-адреса тимчасового імені системи (якщо static) або FQDN (якщо DHCP);
- тимчасова IP-адреса (якщо static);
- маска підмережі (для IPv4, якщо static) або префікс мережі (для IPv6, число від 0 до 128);
- дефолтний шлюз (якщо static);
- DNS-сервери через кому;
Також заздалегідь бажано визначитися, які саме дані хочете перетрансферити на оновлений appliance vCenter Server. Це може бути лише конфігурація (мінімізує час апгрейду та вимоги до сховища), або на додачу до неї ще й події, задачі та метрики продуктивності.
Підготовка конфігураційного JSON-файлу для оновлення vCenter Server через CLI
Так само, як і для апгрейду силами GUI, нам потрібно буде завантажити інсталятор vCenter Server appliance на фізичний сервер або ВМ у мережі, на якій й хочемо провадити оновлення, й підмонтувати його (див. початок цього розділу), та підготувати конфігураційний JSON-файл з мінімумом параметрів налаштувань, які, аналогічно до того, як ми це робили вище у випадку GUI, треба собі десь записати.
У статті «Інсталяція vSphere 8.0 з нуля» ми докладно торкалися у підрозділі «Підготовка конфігураційного JSON-файлу для CLI-методу розгортання appliance vCenter Server» правил синтаксису (усі зауваження актуальні!), команд допомоги, розшифровки конфігураційних параметрів та аргументів (не всі – про відмінності далі буде), а також наводили перелік наданих вендором шаблонів для різних сценаріїв розгортання/оновлення під CLI-методику. Але між greenfield-інсталяцією та апгрейдом, звісно ж, є деякі відмінності у конфігуруванні відповідного JSON-файлу, які зараз й розберемо.
По-перше, у підкаталозі «templates» директорії «vcsa-cli-installer» для оновлення є спеціальні шаблони в папці «upgrade» – саме з ними будемо працювати, а не з «install», як минулого разу. Шлях до них матиме вигляд «vcsa-cli-installer\templates\upgrade\vcsa\6.7» для версії 6.7 джерела або «vcsa-cli-installer\templates\upgrade\vcsa\7.0» для «сімки».
Зауваження. Якщо мова про 6.7, то в папці буде чотири файли («embedded_vCSA_on_ESXi.json», «embedded_vCSA_on_VC.json», «vCSA_on_ESXi.json» та «vCSA_on_VC.json»), а у 7.0 – лише два («embedded_vCSA_on_ESXi.json» і «embedded_vCSA_on_VC.json»).
Їх потрібно буде скопіювати на своє робоче місце для подальшого редагування. Сам же процес редагування, в цілому, не надто відрізняється від того, що ми робили у відповідному підрозділі статті про інсталяцію. А от у списку конфігураційних параметрів дещо додалося:
| Секція | Підсекція | Опис | Параметр | Тип | Опис |
| source_vc (опис існуючого appliance, який хочемо оновлювати) | managing_esxi_or_vc | Опис джерела (ESXi-хост/інстанс vCenter Server appliance) | hostname | string | IP-адреса чи FQDN джерела ESXi або vCenter Server, де розташований оновлюваний appliance |
| username | string | Ім’я користувача з привілеями адміністратора на джерелі ESXi-хості (root) | |||
| password | string | Його пароль | |||
| port | integer | HTTPS-порт зворотньої проксі джерела ESXi-хоста (дефолтний – 443). Використовується лише, коли джерело ESXi-хост має користувацький HTTPS-порт зворотньої проксі | |||
| vc_vcsa | Опис appliance джерела | hostname | string | IP-адреса чи FQDN appliance- джерела | |
| username | string | Ім’я користувача-адміністратора vCenter Single Sign-On на appliance-джерелі (administrator@ your_domain_name) | |||
| password | string | Його пароль | |||
| root_password | string | Пароль користувача root для ОС на appliance-джерелі | |||
| export_dir | string | Директорія для експорту конфігурації джерела та даних | |||
| source_vum | run_migration_assistant | Опціонально, якщо джерело vCenter Server appliance підключено до інстанса VMware Update Manager, що запущений на Windows ВМ. Використовується тільки, якщо хочемо, щоб Migration Assistant на джерелі інстанса VMware Update Manager запускався автоматично | esxi_hostname | string | IP-адреса чи FQDN ESXi-хоста, що містить інстанс VMware Update Manager джерела |
| esxi_username | string | Ім’я користувача з привілеями адміністратора на ESXi-хості (root) | |||
| esxi_password | string | Його пароль | |||
| esxi_port | string | HTTPS-порт зворотньої проксі ESXi-хоста (дефолтний – 443). Використовується лише, коли ESXi-хост має користувацький HTTPS-порт зворотньої проксі | |||
| vum_hostname | string | IP-адреса чи FQDN Windows ВМ, де запущений інстанс джерела VMware Update Manager | |||
| vum_os_username | string | Ім’я адміністратора Windows ВМ, де запущений інстанс джерела VMware Update Manager | |||
| vum_os_password | string | Його пароль | |||
| export_dir | string | Директорія для експорту конфігурації джерела та даних |
Підготовка до апгрейду vCenter Server у НА-середовищах
Як ми знаємо, реалізація концепції НА (High Availability) має на увазі, що в нас є три appliance vCenter Server (Active, Passive й Witness ноди, де Active-нода сконфігурована як нода vCenter HA, та належить кластеру vCenter HA, а усі диски vCenter HA в одному й тому самому датасторі). Щоб підготуватися до оновлення у такому разі, потрібно:
- Пересвідчитись, що vCenter HA-кластер у працездатному стані (healthy state) та в увімкненому режимі (enabled mode);
- Розташування цільового vCenter Server співпадає з розташуванням джерела vCenter Server.
Далі етапи підготовки, в цілому, співпадають з усім, що є актуальним для звичайного appliance vCenter Server, і вони у подробицях викладені вище.
Підготовка до оновлення ESXi-хостів
З огляду на те, що однією з головних «фішок» сучасної vSphere стала підтримка Data Processing Unit (DPU), одразу зауважимо, що на DPU ESXi можна оновлювати лише vSphere Lifecycle Manager чи ESXCLI. Інтерактивний метод та скриптований не підтримуються. Але сьогодні ми все одно розглянемо усі, адже не всі готові почати працювати з DPU.
Перше, що ми маємо зробити, це завантажити новий образ ESXi. Наразі актуальною є версія 8.0В – білд 21203435:
Загалом, для ESXi-хостів VMware пропонує широкий спектр варіантів апгрейду:
- інтерактивний DCUI (з CD, DVD чи USB),
- скриптований,
- ESXCLI,
- vSphere Auto Deploy,
- через vSphere Lifecycle Manager.
Зауваження. За best practice, перші три методи (DCUI, скриптований та ESXCLI) найкраще застосовувати до standalone-хостів, у мініатюрних демонстративних середовищах – просто аби подивитися на новий функціонал свіжої версії, для апгрейду першого(их) хостів, на яких має оновлюватися наш vCenter Server, у випадку, коли ціллю є саме вони, а не інший інстанс vCenter Server. Метод через вбудований у vCenter Server сервіс vSphere Lifecycle Manager, натомість, вважається, найбезпечнішим й найдосконалішим з точки зору виконання ним усіх необхідних пречеків щодо конфігурації, сумісності, дотримання усіх необхідних вимог тощо.
Зауваження. Метод vSphere Auto Deploy застосовується до хостів ESXi, розгорнутих теж через vSphere Auto Deploy, – це, так званий, процес перенадання хостів. Звісно ж, вже з новою версією ESXi у профілі образу. Але сьогодні про цей метод говорити не бачимо сенсу, адже він, включно з кастомізацією образів за допомогою vSphere ESXi Image Builder, роботою з профілями образів, профілями хостів та правилами, найдокладнішим чином розглядався у підрозділах «Кастомізація інсталяцій за допомогою vSphere ESXi Image Builder», «Підготовка до інсталяції ESXi через vSphere Auto Deploy» та «Інсталяція хостів через vSphere Auto Deploy» статті «Інсталяція vSphere 8.0 з нуля».
Підготовка до кожного з них має свої особливості – трохи згодом розглянемо їх усі, по черзі. За винятком інтерактивного методу оновлення ESXi-хостів – вона повністю ідентична тому, що ми писали в розділі «Підготовка до розгортання vSphere 8.0» статті «Інсталяція vSphere 8.0 з нуля». Але перед цим поговоримо про загальні для усіх методів етапи підготовки, що полягають у бекапуванні хоста – якщо оновлення дасть збій, можна буде його відновити, – а також у перевірці, чи на всіх хостах, що готуються на апгрейд, синхронізовані годинники, та у міграції чи вимкненні усіх ВМ хоста.
Зауваження. Щодо варіативності опцій завантаження інсталятора ESXi-хостів, як їх обирати, міняти й налаштовувати ми в подробицях розповідали у підрозділі «Підготовка до інсталяції хостів ESXi» та «Початкові налаштування ESXi» статті «Інсталяція vSphere 8.0 з нуля».
Важливо! Якщо хост має підтримувані новою версією ESXi користувацькі проінстальовані vSphere Installation Bundles (VIB), наприклад, сторонні драйвери чи management-агенти, вони мігруються, за винятком випадків, коли вони включені в ISO інсталятора. Якщо при цьому виникне конфлікт, апгрейд перерветься відповідним сповіщенням про помилку, і тоді можна:
- Або видалити конфліктний VIB з хоста за допомогою esxcli-команд та перезапустити оновлення;
- Або використати vSphere ESXi Image Builder CLI, щоб створити користувацький образ ISO-інсталятора, що розв’яже цей конфлікт прийнятним для вас чином (посилання на розділ з vSphere ESXi Image Builder наводилось трохи вище).
Бекапування хостів ESXi
Конфігурацію хоста ESXi можна зберегти, вчинивши відповідний бекап, щоб потім її можна було відновити, якщо в процесі апгрейду щось піде не так. Щоб ця акція мала успіх, потрібно досягти двох умов:
- Номер білда призначення хоста відповідає білду, з якого було взято резервну копію;
- UUID хоста лишився тим самим.
Бекап хоста можна створити трьома способами:
- через командний рядок ESXi,
- vSphere CLI,
- vSphere PowerCLI.
Створення резервної копії конфігурації хоста за допомогою командного рядка ESXi
Для створення бекапу ESXi-хоста:
- Синхронізуємо змінену конфігурацію з постійним сховищем:
# vim-cmd hostsvc/firmware/sync_config
- Бекапуємо конфігураційні дані:
# vim-cmd hostsvc/firmware/backup_config
Команда поверне URL («http://<host_fqdn_orIP>/downloads/123456/configBundle-xx.xx.xx.xx.tgz»), з якого можна завантажити файл бекапу;
- З веб-браузеру проходимо на цей URL:
Файл бекапу буде в директорії «/downloads» (дефолтній для браузера чи вказаній іншій) й називатися «configBundle-HostFQDN.tgz».
Щоб відновитися з цієї копії, по-перше, потрібно її перейменувати на «configBundle.tgz», а, по-друге:
- Занурити хост в режим техобслуговування командою:cmd hostsvc/maintenance_mode_enter
- Cкопіювати отриманий нами файл на ESXi-хост чи доступний датастор;
- Перезавантажити хост;
- Перемістити наш файл в «/tmp/configBundle.tgz»;
- Запустити команду:
cmd hostsvc/firmware/restore_config 0
Важливо! Якщо є потреба силоміць перезаписати розбіжність UUID, у кінці команди ставимо «1».
Створення резервної копії конфігурації хоста за допомогою vSphere CLI
Для створення бекапу конфігураційних даних хоста ESXi введіть команду:
# vicfg-cfgbackup –server=ESXi_host_IP_address –username=root -s output_file_name
Щоб відновитися з цієї резервної копії:
- Занурюємо наш хост в режим maintenance;
- Перезавантажуємо хост;
- Заходимо на сервер, де проінстальовано vCLI;
- Запускаємо скрипт «vicfg-cfgbackup» з відміткою «-1», щоб завантажити конфігурацію хоста з вказаного файлу бекапу:
# vicfg-cfgbackup –server=ESXi_host_IP_address –username=root -l backup_file
Створення резервної копії конфігурації хоста за допомогою vSphere PowerCLI
Щоб зробити бекап хоста, вводимо команду:
# Get-VMHostFirmware -VMHost ESXi_host_IP_address -BackupConfiguration -DestinationPath output_directory
де «-DestinationPath» – це директорія, де має зберегтися наш файл.
Вона може виглядати, наприклад, отак:
# Get-VMHostFirmware -VMHost 10.0.0.1 -BackupConfiguration -DestinationPath C:\Downloads
Щоб відновити хост з цієї резервної копії:
- Занурюємо його в режим техобслуговування командою:
# Set-VMHost -VMHost ESXi_host_IP_address -State ‘Maintenance’
- Перезавантажуємо хост:
# Restart-VMHost -VMHost ESXi_host_IP_address -Confirm:$false
- Відновлюємо конфігурацію командою:
# Set-VMHostFirmware -VMHost ESXi_host_IP_address -Restore -SourcePath backup_file -HostUser username -HostPassword password
Наприклад, остання команда може виглядати так:
# Set-VMHostFirmware -VMHost 10.0.0.1 -Restore -SourcePath c:\bundleToRestore.tgz -HostUser root -HostPassword exampleRootPassword
Міграція або вимкнення машин хоста
Міграція ВМ – тема досить масштабна й різноманітна, тому в усіх нюансах, включно з vSphere vMotion, торкнемося її у запланованій статті про адміністрування vSphere 8.0. Зараз же лише коротенько згадаємо один найлегший й найпоширеніший спосіб – через клієнт vSphere. З його допомогою можна робити як холодну міграцію (для вимкнених машин чи переведених в статус suspend), так і гарячу (для увімкнених). Для цього вставши на потрібну машину в інвентарі просто обираємо потрібну дію:
Спеціальний візард нам запропонує ряд міграційних опцій, зокрема, щодо переміщення чогось одного:
- обчислювальних ресурсів,
- сховища,
- обчислювальних ресурсів і сховища,
- переміщення між інстансами vCenter Server, не з одного SSO-домену.
Далі просто рухаємось показаним на скріншоті помічником й робимо усі необхідні вводи та вибори.
Вимкнення ВМ відбувається в тих самих Actions: клікаємо на дію Power, і якщо машина має статус Power On, обираємо Power Off (як вона й так вимкнена, звісно ж, нічого не чіпаємо).
Важливо! У деяких випадках бажаніше, ніж повністю вимкнути машину, залишити її під’єднаною до мережі (ніби поставити на паузу). Цей статус має назву «Suspend» у секції дій Power.
Для зручності, усі статуси (там ще є такі дії, як перезапустити й жорстко вимкнути – корисно, коли кнопка Power Off не відповідає) позначені піктограмками:
Підготовка до скриптованого методу оновлення ESXi-хостів
Цей метод корисний лише у випадку, коли нам потрібно оновити багато хостів з однаковою конфігурацією. Так само, як і за процедурою інсталяції, описаною в багато разів вже згаданому нашому попередньому матеріалі «Підготовка до скриптованої інсталяції ESXi-хостів», нам доведеться зробити певні зміни в інсталяційному скрипті «ks.cfg» – усі наведені там команди та рекомендації актуальні й для нашого випадку. Єдине що, команду «install» усюди замінюємо на «upgrade».
Підготовка до оновлення ESXi-хостів за допомогою ESXCLI
Якщо це ваше перше знайомство з командами керування ESXi-хостами ESXCLI, дуже радимо витратити час на вивчення вичерпного підручника з цієї теми, де є й те, як проінсталювати ESXCLI з інсталяційного пакету, й багато чого іншого, та постійно користуватися коротенькою неймовірно корисною шпаргалкою, спеціально підготованою для нас VMware. А повна підказка по командах міститься отут.
Розглядаючи метод ESXCLI ми будемо користуватися тими самими профілями образів та правилами, з якими вчилися працювати в підрозділі «Підготовка до інсталяції ESXi» постійно згадуваної вище нашої статті. Зараз лише докладно поговоримо, власне, про команди ESXCLI, адже цього метода розгортання там немає.
Перед тим, як розпочати підготовку до оновлення, обов’язково треба розібратися, чи все в порядку з нашими профілями образів і VIB та рівнями прийняття. Отримання інформації по профілю образу чи VIB:
- Вивести списком інформацію по всім VIB:
esxcli –server=<server_name> software sources vib list –depot=<depot_URL>
- Вивести інформацію по конкретному VIB:
esxcli –server=<server_name> software sources vib list –viburl=<vib_URL>
- Вивести списком інформацію по всім профілям образів:
esxcli –server=<server_name> software sources profile list –depot=<depot_URL>
- Вивести інформацію по конкретному профілю образу:
esxcli –server=<server_name> software sources profile get –depot=<depot_URL> –profile=<profile_name>
Отримання рівня прийняття хоста:
esxcli –server=<server_name> software acceptance get
Зміна рівня прийняття VIB (якщо він нижчий за рівень прийняття хоста):
esxcli –server=<server_name> software acceptance set –level=<acceptance_level>
Зауваження. Рівень прийняття може набувати значень: «VMwareCertified», «VMwareAccepted», «PartnerSupported» чи «CommunitySupported».
Зауваження. Можна застосувати опцію «–force» для команд «esxcli software vib» чи «esxcli software profile», щоб силоміць додати VIB або профіль образу з нижчим рівнем прийняття, ніж у хоста. Продемонструється попередження, і далі, в такому випадку, вони будуть з’являтися весь час у процесі будь-яких операцій на хості, адже він втратить свою відповідність.
Далі маємо відмітити, що VIB, які мають здатність інсталюватися наживо, не потребують перезавантаження хоста – лише його занурення у режим техобслуговування. Інші ж у процесі оновлення хоста обов’язково вдадуться до перезавантаження. Коли ми вище запитували інформацію по VIB, у виводі там, зазвичай, присутній параметр «Live-Install-Allowed», значення якого вказане як «true» чи «false». От якщо перший варіант, у рамцях підготовки нам знадобиться вміння занурювати хост в режим maintenance.
Зауваження. Неможливо оновлювати хости без перезавантаження, якщо хост належить vSphere HA кластеру. Спочатку треба деактивувати НА на кластері або ж вивести потребуючий апгрейду хост з нього.
Виведення хоста в режим maintenance за допомогою ESXCLI
Спочатку перевіряємо, чи хост вже не в режимі техобслуговування:
esxcli –server=<server_name> system maintenanceMode get
Далі:
- Отримуємо список усіх запущених на хості ВМ, щоб дізнатися їх World ID:
esxcli –server=<server_name> vm process list
- Вимикаємо кожну ВМ, запущену на цьому хості. Можливі декілька варіантів:
- Вимкнути гостьову ОС, після чого вимкнути ВМ:
esxcli –server=<server_name> vm process kill –type soft –world-id <vm_ID>
-
- Вимкнути ВМ негайно:
esxcli –server=<server_name> vm process kill –type hard –world-id <vm_ID>
-
- Застосувати операцію вимкнення силоміць:
esxcli –server=<server_name> vm process kill –type force –world-id <vm_ID>
Альтернативно, ВМ можна смігрувати на інший хост, щоб їх не вимикати. Дещо, стосовно вимикання ВМ та їх міграції ми розповідали вище, але докладно це питання розглянемо у нашій запланованій на найближче майбутнє статті про адміністрування vSphere 8.0;
- Поміщаємо хост в режим техобслуговування:
esxcli –server=<server_name> system maintenanceMode set –enable true
- Перевіряємо, чи він дійсно пішов у режим maintenance:
esxcli –server=<server_name> system maintenanceMode get
Підготовка до оновлення ESXi-хостів через vSphere Lifecycle Manager
За допомогою vSphere Lifecycle Manager, що є сервісом vCenter Server, ми можемо оновлювати хости, що керуються цим нашим vCenter Server, стандартизуючи образи по всім хостам в кластері (саме це буде розглянуто в процедурі оновлення щодо цього методу нижче у відповідному розділі), а також інсталювати та апдейтити сторонній софт на хостах, драйвери та firmware ESXi, але останнє розглянемо докладно в майбутній статті про адміністрування vSphere.
Переваги використання саме vSphere Lifecycle Manager:
- Перед спробою vSphere Lifecycle Manager занурити хости в режим maintenance ним проводяться деякі перевірки, щоб впевнитися, що вони здатні це зробити, і клієнт vSphere повідомить щодо будь-яких конфігураційних проблем, що можуть завадити цьому;
- Якщо кластер налаштований для vSphere DRS, vSphere Lifecycle Manager з останнім інтегрується автоматично. Коли vSphere Lifecycle Manager поміщає хости в режим техобслуговування, vSphere DRS евакуює кожен хост до моменту патчування;
- Після оновлення та перезавантаження хоста vSphere Lifecycle Manager виведе його з режиму техобслуговування, а vSphere DRS смігрує деякі ВМ назад на хост.
Для того, щоб наш vSphere Lifecycle Manager надав нам увесь необхідний функціонал для апгрейду хостів, потрібно у ньому зробити деякі важливі операції. Дістатися ж до нього можна через головне бічне меню клієнта vSphere:
Налаштування сховища образів та завантаження нових версій в vSphere Lifecycle Manager
Якщо ми зайдемо в vSphere Lifecycle Manager, побачимо декілька вкладок, перша з яких – Image Depot – покаже увесь доступний софт, яким може користуватися vSphere Lifecycle Manager:
Це сховище образів ESXi розташоване в системі vCenter, а також адонів вендора та сторонніх компонентів. Як показано на скріншоті, там наведена версія ESXi з датою релізу для полегшення орієнтації. Щоб образи з’явилися в цьому сховищі, їх треба імпортувати з онлайн-джерел, причому, vSphere Lifecycle Manager це робить регулярно сам, якщо налаштувати імпорт контенту за розкладом, або за потреби процедуру можна ініціювати й вручну, обравши зверху в розкривному меню ACTIONS під Updates – Sync Updates:
Але до цього, щоб наш vSphere Lifecycle Manager знав, звідки тягти версії образів та інші речі, треба налаштувати джерела завантажень. З цією метою на вкладці Settings обираємо з бічного меню Patch Setup і обираємо, додаємо чи міняємо URL – для того зверху таблички є NEW, EDIT, DELETE, ENABLE та DISABLE:
Також можна імпортувати контент й з офлайн-джерел: з розкривного меню Actions зверху обираємо Import Updates – з’явиться віконце, куди можна або ввести URL, або натиснути BROWSE, щоб знайти необхідний ZIP-файл з оновленням:
Керування оновленням хостів кластера за допомогою vSphere Lifecycle Manager
Щоб користуватися vSphere Lifecycle Manager у життєвому циклі наших хостів, нам потрібно додати їх у кластер vSphere Lifecycle Manager – тоді вони зможуть бути керованими єдиним образом. При створенні цього кластеру опція використання єдиного образу обрана за замовчуванням (галочка в Manage all hosts in the cluster with a single image), також можна або встановити цей образ самостійно, або вказати, що потрібно скористатися образом хоста в чи поза поточним інстансом vCenter Server. У цьому допоможе вбудований помічник New Cluster:
Для цього:
- У клієнті vSphere проходимо в інвентар Hosts and Clusters;
- ПКМ на дата-центр та обираємо New Cluster – з’явиться згаданий візард;
- На сторінці Basics вводимо ім’я кластеру та включаємо vSphere DRS, vSphere HA чи vSAN;
- Лишаємо галочку в Manage all hosts in the cluster with a single imageта прапорець у Compose a new image (обрані за дефолтом);
- Опціонально, щоб увімкнути vSphere Configuration Profiles на кластері, обираємо Manage configuration at a cluster level. Тиснемо Next;
- На сторінці Image встановлюємо бажаний образ (обираємо версію ESXi та, опціонально, адон вендора та його версію) та клікаємо Next;
- Якщо обрали vSphere Configuration Profiles, проглядаємо інформацію на Configuration та тиснемо Next;
- На сторінці Review перевіряємо зроблені налаштування та клікаємо Finish, щоб розпочати створення кластеру.
Якщо хочемо, щоб до нашого кластеру застосувався образ певного хоста, робимо те саме до п. 3 включно, галочку в Manage all hosts in the cluster with a single image лишаємо, а от з Compose a new image прапорець знімаємо і обираємо метод створення образу для кластеру:
- Щоб імпортувати образ з хоста в тому ж інвентарі vCenter Server, обираємо Import image from an existing host in vCenter inventory;
- Щоб імпортувати образ з іншого інстанса vCenter Server чи standalone-хоста не з vCenter Server, обираємо Import image from a new host.
П. 5 без змін, а далі, в першому випадку: на сторінці Image обираємо референсний хост та тиснемо Next – далі все так само до закінчення роботи помічника, як і зі створенням нового образу. А в другому: на сторінці Image вводимо дані хоста та клікаємо кнопку Find Host, з’явиться діалогове вікно Security Alert, де треба натиснути Yes, щоб погодитися з підключенням до хоста, а щоб перемістити цей хост в наш кластер, ставимо галочку в Also move selected host to cluster та тиснемо Next, і далі знов все так само, як в п.7-8.
За потреби, в майбутньому, можна буде додавати ще хости до цього кластеру, або видаляти звідти. В останньому випадку видалений хост буде користуватися софтом та firmware, встановленими протягом останнього виправлення стосовно образу кластера.
Полегшити задачу пошуку необхідних актуальних оновлень можна, якщо в бічному меню кластера обрати Image, перейти на вкладку Updates і зверху справа від EDIT натиснути на «…», що є розкривним меню:
vSphere Lifecycle Manager зробить перевірку по компонентам образу, чи немає в ньому пропущених залежностей та конфліктуючих компонентів, й покаже саме той образ, що є найновішим та тим, що найбільш пасує вашому середовищу. Щоб продивитися рекомендовані образи, можна клікнути на Recommendations коло напису Image зверху, чи обрати в загаданому меню під «трьома крапочками» View recommended images:
Редагування образів кластера у vSphere Lifecycle Manager
Образ, згідно якого виправляються хости кластера, після його додання в сховище vSphere Lifecycle Manager можна редагувати, шляхом зміни самого базованого образу або зміни, додавання чи видалення компонентів (версії образу ESXi, адонів вендора, firmware, адонів драйверів та інших):
До його збереження можна пройти процедуру валідації відповідною кнопочкою, щоб переконатися у його повноті, чи немає в ньому втрачених залежностей, та у відсутності конфліктів між компонентами.
Паралельне виправлення хостів в кластері за допомогою vSphere Lifecycle Manager
Нижче у підрозділі про процедуру «Оновлення ESXi-хостів з vSphere Lifecycle Manager» ми покажемо, як відновлювати невідповідні заданому образу хости в кластері. Цікаво, що задля економії часу ми можемо це робити не послідовно, а паралельно, здійснивши деякі налаштування на вкладці Settings під Cluster lifecycle бічного меню у Images:
Там же можна вказати максимальну кількість паралельних виправлень.
Зауваження. Операція паралельного виправлення в кластері доступна лише для хостів в режимі maintenance.
Процедура апгрейду vSphere
Важливо! Спочатку оновлюється завжди vCenter Server, а вже після нього – ESXi.
Взагалі, уся процедура оновлення vSphere має йти за таким планом, схематично:
Й звичайно ж, вдаватися до неї варто лише тоді, коли усі підготовчі процеси згідно наведеного вище розділу «Підготовка до оновлення vSphere» були виконані успішно, системні вимоги дотримані, організація мережі, сховищ та середовища загалом на рівні, підтримуваному поточною версією, і наявне бачення майбутньої топології, місткості та задач щодо нашої оновленої платформи віртуалізації.
Процедура оновлення vCenter Server
Задачі апгрейду vCenter Server, схематично:
Важливо! У середовищах з декількома інстансами vCenter Server appliance не можна вдаватися до паралельних апгрейдів. Кожний інстанс vCenter Server має оновлюватися окремо, бо VMware Directory Services (vmdird) стикається з проблемами реплікації з інформацією про single-sign on та сертифікат.
Як ми вже писали раніше, існує два методи оновлення appliance vCenter Server. Розглянемо їх по черзі.
Апгрейд vCenter Server через GUI-інсталятор
GUI-інсталятор проведе нас через дві глобальні стадії, перша з яких полягає в розгортанні нового віртуального аppliance вже 8-ї версії, а друга – у міграції існуючих даних та налаштуванні усіх його сервісів. Пройдемося ними.
Як тільки-но запустимо інсталятор, що пасує нашій операційній системі:
(директорія «vcsa-ui-installer», для Windows підкаталог «win32», файл – «installer.exe»; для Linux підкаталог «lin64», файл – «installer»; для Mac підкаталог «mac», файл – «Installer.app»), з комп’ютера, який має доступ до старого appliance vCenter Server та до хостів чи інстансу vCenter Server, де буде розгортатися новий, з’явиться вітальне вікно з декількома опціями:
Нас цікавить, відповідно, «Upgrade». Натиснувши її попадемо у вітальне вікно «Іntroduction», що познайомить зі згаданими двома стадіями:
Далі йдемо пунктами бічного меню, після натискання на цій сторінці Next:
- «End user license agreement». Ставимо галочку, що погоджуємось з ліцензійною угодою. Тиснемо Next:
- «Connect to source appliance». Вписуємо дані щодо джерела – FQDN, порт, дані облікового запису акаунту адміністратора та пароль root, а також FQDN хоста чи інстансу vCenter Server, де розгорнутий старий аppliance, і дані облікового запису користувача цього хоста чи інстансу. Тиснемо Next:
Покаже попередження щодо сертифікату – треба підтвердити відтиск (кнопка YES):
- «vCenter Server deployment target». Вводимо дані щодо цілі vCenter Server (хост чи інстанс vCenter Server) – FQDN, порт та дані облікового запису користувача. Тиснемо Next:
Знову попередження сертифікату – погоджуємось кнопкою YES.
- «Select folder». Обираємо дата-центр та папку, де має створитися ВМ vCenter Server. Тиснемо Next:
- «Select compute resource». Обираємо обчислювальні ресурси, клікаємо Next:
- «Set up target vCenter Server VM». Задаємо дані нашої нової ВМ (ім’я, логін/пароль root). Тиснемо Next:
- «Select deployment size». Обираємо розмір розгортання (про це докладно йшлося в статті «Інсталяція vSphere 0 з нуля», підрозділ «Вимоги до «заліза», мережі та сховища»). Тиснемо Next:
- «Select datastore». Обираємо сховище, клікаємо Next:
- «Configure network settings». Задаємо налаштування мережі для нового vCenter Server (назву мережі, ІР-версію – IPv4/IPv6, тип IP-призначення – static/DHCP, IP-адресу, маску підмережі або довжину префіксу, дефолтний шлюз, DNS-сервери). Тиснемо Next:
- «Ready to complete stage 1». Переглядаємо зроблені налаштування, якщо все добре, клікаємо на FINISH:
Розпочнеться процес розгортання нового appliance, по завершенню якого продемонструється повідомлення, що ми успішно пройшли першу стадію. Тут, якщо натиснемо CLOSE, налаштування включно з переносом даних доведеться робити окремо, через клієнт vCenter Server Management Interface. Але ми натиснемо CONTINUE, щоб одразу перейти до другої стадії.
Помічник другої стадії також спочатку привітається з нами сторінкою «Іntroduction», де розповість, що будемо робити далі:
Після того, як натиснемо Next:
- «Connect to source vCenter Server». На цьому кроці помічник перевірить, чи має доступ до джерела vCenter Server appliance, використовуючи налаштування, що ми робили на першій стадії:
Результат пречеку матиме вигляд з деяким переліком попереджень й пропозицій щодо їх усунення (якщо такі будуть). Закриваємо це вікно CLOSE:
Тиснемо Next;
- «Select upgrade data». Обираємо тип даних, які хочемо, щоб були змігровані з джерела vCenter Server (ставимо прапорець – одне з трьох, від найменшого за вмістом й об’ємом до найповнішого). Тиснемо Next:
- «Configure CEIP». Ставимо галочку, якщо хочемо приєднатися до програми поліпшення досвіду клієнтів. Тиснемо Next:
- «Ready to complete». Переглядаємо підсумок зроблених нами налаштувань, ставимо галочку, що зробили бекап (як саме – писали вище, у відповідному підрозділі розділу «Підготовки…»), й тиснемо FINISH:
Вискочить попередження, що джерело vCenter Server appliance вимкнеться, як тільки-но перенесуться мережеві налаштування на нову версію appliance:
Якийсь час будемо спостерігати за прогресом другої стадії, успішне завершення якої продемонструється нам таким чином:
CLI-метод оновлення vCenter Server
Якщо вже маємо відредагований JSON-файл, апгрейд полягає у запуску команди, вигляду:
vcsa-deploy upgrade path_to_the_json_file list_of_arguments
куди обов’язково треба вставити через пробіл аргумент «–accept-eula» й на додачу можна повставляти інші потрібні аргументи, яких ми докладно торкалися у підрозділі «Підготовка конфігураційного JSON-файлу для CLI-методу розгортання appliance vCenter Server» матеріалу «Інсталяція vSphere 8.0 з нуля».
Процедура оновлення ESXi-хостів
Схематично, процес апгрейду ESXi-хостів виглядає так:
Розглянемо кожен з можливих методів.
Інтерактивне оновлення хостів ESXi
Використання DCUI в роботі з ESXi-хостами, здається, найзвичніший й найзнайоміший метод для більшості віртуалізаторів. По-перше, підготовка до нього, як ми в цьому пересвідчилися вище, річ досить невибаглива. По-друге, й сам процес зрозумілий і доступний навіть адміністраторам-початківцям. Ось він:
- Після запуску інсталятора побачимо традиційне вітальне вікно, на якому треба натиснути Enter:
- Приймаємо End User License Agreement (EULA) кнопкою F11:
- Обираємо диск, на якому потрібно виконати інсталяцію/апгрейд, Enter:
- Інсталятор зрозуміє, що в вас вже є попередньо установлена версія ESXi і запропонує або оновити її, або встановити чисту – обираємо Upgrade й тиснемо Enter:
Зауваження. У цьому випадку за замовчуванням існуючий VMFS-датастор буде збережено. Якщо цього не може статися, буде доступний лише вибір інсталяції та перезапису існуючого сховища, чи відміни інсталяції. За таких обставин обов’язково відмовтесь, зробіть попередньо бекап VMFS-датастора, і лише після цього продовжуйте інсталяцію з перезаписом.
- І ще раз F11 у наступному вікні для підтвердження:
- Деякий час будемо спостерігати за прогресом процесу, і якщо все добре, побачимо повідомлення про його закінчення, де треба буде натиснути Enter, щоб вийняти інсталяційний медіа та перезавантажити хост:
Після цього вже завантажиться оновлений хост, в якому, якщо хочемо, можна буде переналаштувати деякі параметри, як розповідалось у статті «Інсталяція vSphere 8.0 з нуля», підрозділ «Початкові налаштування ESXi».
Апгрейд ESXi-хостів за допомогою скриптів
Як і у випадку чистої інсталяції, щоб відредагувати опції завантаження після підготовки відповідного файлу «kickstart», нам потрібно буде запустити хост та інсталятор ESXi, після чого швиденько натиснути Shift+O, поки завантажувальне вікно не зникло:
Про це й про те, що потрібно зробити для шуканого результату докладно описано в підрозділі «Інсталяція ESXi за допомогою скрипта» згаданої статті. Власне, це й є усе, що нам потрібно зробити, щоб процес апгрейду розпочався.
Оновлення ESXi-хостів через ESXCLI
Використовуючи командний рядок, оновити ESXi-хост можна, буквально, парою команд в зручному SSH-клієнті, наприклад, PuTTY:
esxcli network firewall ruleset set -e true -r httpClient
esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-8.0.0-20513097-standard
вказавши потрібний набір правил для застосування та місцезнаходження нового профілю у відповідному сховищі. Усе щодо правил та профілів розглядалося у вищезгаданій статті, в підрозділі «Підготовка до інсталяції хостів ESXi».
За декілька хвилин командний рядок відзвітує, що оновлення відбулося успішно, та продемонструється зауваження «Reboot Required: true»:
Але це далеко не все, адже можна також оновлювати хости індивідуальними VIB, доступними за URL чи в оффлайн ZIP-сховищі. А також VIB чи профілями образів з ZIP-файлу в сховищі.
Оновлення хоста з індивідуальними VIB через ESXCLI та інсталяція окремого ZIP-файлу на хості
ZIP-пакетом для апдейту можна користуватися напряму з сайту VMware, або розташувати його в підтримуваному вендором сховищі, чи взагалі завантажити локально.
Важливо! Команди «esxcli software vib update» та «esxcli software vib install» не підтримуються в операціях оновлення.
При цьому порядок дій буде наступним:
- Визначаємо, які VIB проінстальовані на хості:
esxcli –server=<server_name> software vib list
- Знаходимо, які VIB доступні у сховищі. Якщо в нас сховище доступне за URL:
esxcli –server=<server_name> software sources vib list –depot=http://<web_server>/<depot_name>
Якщо у локальному сховищі:
esxcli –server=<server_name> software sources vib list –depot=<absolute_path_to_depot_zip_file>
- Оновлюємо існуючі VIB, щоб включити VIB, наявні в сховищі, чи щоб проінсталювати нові. Для VIB, доступних за URL:
esxcli –server=<server_name> software vib update –depot=http://<web_server>/<depot_name>
Для VIB з локального сховища:
esxcli –server=<server_name> software vib update –depot=<absolute_path_to_depot_ZIP_file>
Щоб проінсталювати усі VIB з ZIP-файлу з вказаного офлайн-сховища (включно з підтримуваними партнерами):
esxcli –server=<server_name> software vib install –depot <path_to_VMware_vib_ZIP_file>\<VMware_vib_ZIP_file> –depot <path_to_partner_vib_ZIP_file>\<partner_vib_ZIP_file>
Впевнитися, що всі потрібні VIB з’явилися на ESXi-хості можна командою:
esxcli –server=<server_name> software vib list
Проінсталювати окремий ZIP-файл можна командою:
esxcli –server=<server_name> software vib update –depot=/<path_to_vib_ZIP>/<ZIP_file_name>.zip
Опція Dry Run в оновленні через ESXCLI
Опція Dry Run є дуже корисною в роботі з оновленнями за допомогою ESXCLI, адже вона не робить жодних змін в процедуру, проте дозволяє попередньо переглядати результати апгрейду. Додання «–dry-run» до команд звітує щодо операцій на рівні VIB.
Важливо! Оновлюватись до ESXi 8.0 й більш нових версій з використанням опції «–dry-run» можна лише з 7.0U3i версії.
Команда у цьому випадку може виглядати, наприклад, отак:
esxcli –server=<server_name> software vib update –dry-run
або отак:
esxcli –server=<server_name> software profile update –dry-run
Оновлення ESXi-хостів з vSphere Lifecycle Manager
Розглянемо більш загальний випадок оновлення хостів, що керуються vCenter Server та зібрані у кластер. Для цього у клієнті vSphere:
- У властивостях нашого кластеру клікаємо на вкладку Updates, а потім у бічному її меню під Hosts на Image і внизу на кнопкуSetup Image:
- З’явиться вікно налаштування образу, де ми маємо, перш за все, обрати версію з розкривного меню:
Та натиснути на кнопку Save, після чого вискочить попередження, що завершення налаштування образу замістить усі baseline, що були прикріплені до кластера й його хостів, й цей процес незворотній, але отриманий образ зможемо відредагувати будь-коли в майбутньому. Тут треба погодитися кнопкою YES, FINISH IMAGE UP;
- Перевіряємо відповідність на рівні кластера, натиснувши кнопку Check Compliance:
Важливо! Перед тим, як вдатися до виправлення хостів, якщо вони не відповідні, рекомендується запустити перевірку, чи не станеться якихось проблем в процесі виправлення, кнопкою RUN PRE-CHECK.
- Як бачимо, хости невідповідні, отже, треба їх виправити кнопкою Remediate All:
- З’явиться віконце Review Remediation impact, що продемонструє, який саме виправлення матиме ефект – ставимо галочку унизу, погоджуючись з EULA та натискаємо кнопку Start Remediation:
Прогрес процесу зможемо побачити в задачах vCenter Server:
і хости почнуть виправлятися:
Через декілька хвилин побачимо, що ESXi-хости перезавантажилися й завантажилися вже у 8.0-версії, а сторінка конфігурації образів по нашому кластеру продемонструє поточну оновлену версію ESXi, що усі наші хости пройшли перевірку відповідності й виправлення завершилося успіхом:
Операції пост-апгрейду
Коли головні компоненти vSphere успішно оновилися до 8-ї версії, потрібно вдатися до деяких операцій пост-апгрейду, щоб середовище почало працювати без зауважень. А саме:
- Завершити будь-яку реконфігурацію компонентів, яка не увійшла безпосередньо до процедури апгрейду. У тому числі, за бажанням, довести усі хости середовища до найсвіжіших версій;
- Спробувати зайти через vSphere Client на vCenter Server (увівши в браузері «https://vcenter_server_ip_address_or_fqdn/ui») та перевірити, чи:
- коректна IP-адреса,
- не змінилася реєстрація Active Directory,
- правильна реєстрація мережі,
- сертифікати валідні,
- дані інвентаря смігрували коректно (історія подій, графіки продуктивності, користувачі, дозволи та ролі);
- Якщо використовуєте автентифікацію смарт-картами, переконайтеся, що їх порт відкритий у клієнтському середовищі (на vCenter Server, за дефолтом);
- Якщо мали зареєстровані з vCenter Server до апгрейду плагіни та сторонні клієнтські пакети плагінів, після оновлення SSL-сертифікату, можна, за необхідності, їх перереєструвати. Зауважте, що подібні розширення та клієнтські плагіни можуть мати свої особливості щодо переєстрації, тому обов’язково проконсультуйтесь з їх вендором. В загальному випадку для цього треба: пройти в браузері на Managed Object Browser нашого vCenter Server
https://vcenter_server_ip_address_or_fqdn/mob/?moid=ExtensionManager
ввести дані свого облікового запису, на сторінці ManagedObjectReference:ExtensionManager під Methods клікнути на UnregisterExtension, на сторінці void UnregisterExtension в текстовому полі усередині колонки Value ввести значення властивості «key» об’єкту даних «Extension» відповідного розширення vSphere Client. А щоб зняти реєстрацію з розширення натискаємо на Invoke Method.
- Перевірити ліцензії хостів;
- Переналаштувати систему журналів логів за бажанням.
Останні два пункти, як і дещо, що згадувалось вище й не знайшло відповідей у тексті цього матеріалу, обов’язково буде розглянуто в майбутній статті по адмініструванню vSphere 8.0, поряд з іншими найбільш вживаними, корисними та цікавими моментами у налаштуванні й використанні цього продукту.