Категорії
VMware: Гайди з розгортання та налаштування

Інсталяція vSphere 8.0 з нуля

vSphere – це база баз для будь-якого віртуалізатора, що прагне працювати з продуктами VMware. Навіть не так: це літосферна плита, на якій усе тримається, яка задає концептуальні засади й без глибоких, ґрунтовних знань якої говорити про успішність впровадження SDDC марно.

Кілька місяців тому VMware випустила чергове мажорне оновлення vSphere, і якщо ви хочете користуватися найсвіжішою версією нашого середовища, доведеться вчитися вже «вісімці». Про головні зміни в ній ми нещодавно писали в «Що змінилося в VMware vSphere 8.0?», а сьогодні будемо вчитися інсталювати з нуля усі компоненти vSphere 8.0 й робити початкові налаштування. Що ж стосується питань адміністрування та оновлення з попередніх версій до цієї, гадаємо, опублікуємо окремі гайди незабаром.

Що ж, план дій в нас є, анонси на майбутнє зробили, саме час безпосередньо переходити до справи. Тож, не барімося, бо розмова очікується довга.

Архітектура, компоненти та поняття

Якщо це ваша перша зустріч з vSphere, не зайвим буде, по-перше, визначитися з основними термінами й поняттями, якими надалі будемо постійно оперувати, а також поговорити про складники й головні механізми нашого середовища.

Глосарій

Віртуалізація – процес створення програмного представлення фізичної одиниці (сервера, десктопа, мережі або пристрою зберігання даних). Відповідно, вона буває серверною, мережевою, віртуалізацією сховища або робочого стола користувачів.

SDDC (Software-Defined Data Center) – дата-центр, в якому уся інфраструктура віртуалізована, а його контроль автоматизований програмним забезпеченням. vSphere, як технологія, є фундаментом SDDC:

Гіпервізор – спеціальна операційна система, призначена для запуску віртуальних машин та віртуальних appliance.

Хост – фізичний комп’ютер, що надає ресурси для гіпервізора (в нашому випадку ESXi).

Віртуальна машина (ВМ) – спеціальний застосунок, що абстрагує апаратні ресурси в програмне забезпечення. Вона включає наступні компоненти:

  • гостьову операційну систему,
  • VMware Tools,
  • віртуальні ресурси (CPU та пам’ять, мережеві адаптери, диски та контролери, GPU).

Операційна система (ОС) – ПО, розроблене для виділення фізичних ресурсів застосункам.

Гостьова ОС – операційна система, що запущена на ВМ.

Кластер – група ESXi-хостів, чиї ресурси спільно використовуються віртуальними машинами.

Архітектура та компоненти

Перед тим, як зануритися у вивчення нашого віртуального середовища, зупинимось на хвилинку на поняттях, що є наріжними для SDDC, і без яких розуміння архітектури та компонентів vSphere, а також їх взаємодії не досягти. Його фізична інфраструктура виглядає схематично так:

А віртуальна ось так:

З чого логічним чином випливає означення самої vSphere: це платформа віртуалізації, що включає два ключових адміністративних компоненти для запуску віртуальних машин – гіпервізор (в нашому випадку ESXi, його визначення наводилось вище) та vCenter (центральна адміністративна платформа для ESXi-хостів, віртуальних машин, сховища та мережевого з’єднання):

Якщо більш розгорнуто, ESXi – це bare-metal гіпервізор, ліцензований як частина vSphere. Він має наступні особливості:

  • Високий рівень безпеки (фаєрвол на основі хоста, посилення пам’яті, цілісність модуля ядра, Trusted Platform Module (TPM 2.0), безпечне завантаження UEFI, зашифровані дампи ядра);
  • Малий розмір диску;
  • Швидке завантаження для прискореного патчування та оновлень;
  • Інсталюється на жорстких дисках, SAN LUN, SSD, SATADOM та бездискових хостах.

Важливо! Можна використовувати завантажувальні пристрої на базі USB, проте VMware радить користатися замість них SSD для підвищення надійності.

vCenter дозволяє об’єднувати в пул ресурси кількох хостів та керувати ними. Він запускається як appliance (ВМ на Linux), що має Photon OS, БД PostgreSQL та запакований з низкою сервісів, таких як:

  • vCenter Server,
  • vSphere Client,
  • сервіс ліцензування,
  • Content Library,
  • vSphere Lifecycle Manager Extension та vCenter Lifecycle Manager.

Також на борту вбудовані можливості автентифікації та сертифікації (vCenter Single Sign-On, Lookup Service, VMware Certificate Authority), vSphere Auto Deploy, про який дуже докладно будемо говорити нижче та vSphere ESXi Dump Collector. Повний список можна побачити отут:

Архітектура vCenter спирається на такі компоненти:

  • vSphere Client (зручний інтерфейс, що підключається до vCenter та централізовано керує ESXi-хостами);
  • БД vCenter (критично важливий компонент, що зберігає об’єкти інвентаря, ролі безпеки, дані продуктивності та багато чого іншого);
  • Керовані хости (з vCenter можна керувати ESXi-хостами та ВМ, запущеними на ESXi-хостах):

У процесі розгортання обирається розмір appliance vCenter Server для запланованого середовища vSphere та розмір сховища за вимогами БД, що будується.

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

Сервіси аутентифікації vCenter

vCenter Single Sign-On дозволяє компонентам vSphere комунікуювати між собою за безпечним механізмом токенів. Він може автентифікувати користувачів через вбудовані чи зовнішні провайдери ідентифікації. До вбудованих належать домен vsphere.local, що, за замовчуванням, vCenter використовується як джерело ідентифікації, а також Active Directory, яким, за бажанням, можна користуватися як джерелом ідентифікації (LDAP, LDAPS, OpenLDAP чи OpenLDAPS). Зовнішні провайдери ідентифікації використовують федеративну автентифікацію – vSphere підтримує Active Directory Federation Services (AD FS).

Автентифікаваним користувачам можуть призначатися основані на рішенні зареєстровані дозволи чи ролі у середовищі vSphere.

Спілкування з вбудованим провайдером ідентифікації виглядає наступним чином:

  1. Користувач заходить в клієнт vSphere;
  2. vCenter Single Sign-On автентифікує дані облікового запису за сервісом каталогу (наприклад, AD);
  3. SAML-токен надсилається назад до браузера користувача;
  4. SAML-токен посилається на vCenter й користувачеві надається доступ:

vCenter Single Sign-On має бути зареєстрованим з vCenter Server.

З огляду на використання домену vCenter Single Sign-On, варто зауважити, що у Enhanced linked mode можна заходити в клієнт vSphere й керувати інвентарями усіх інстансів vCenter у групі – до 15 таких інстансів можуть бути в одному vCenter Single Sign-On:

Й при цьому на всі пов’язані інстанси vCenter можна заходити одночасно з єдиним іменем користувача та паролем, усі операції з ними відбуваються в одному клієнті vSphere, й дуже зручно можна репліціювати ролі, дозволи, ліцензії, теги та політики по всім таким інстансам. Серед інших функцій рішення: спрощений процес НА, нівелюючий необхідність в балансировщиках навантаження, дуже зручне бекапування та відновлення. До речі, таку групу можна створити протягом розгортання vCenter Server Appliance, або вже потім перемістивши чи перевизначивши новий інстанс  vCenter, дуже просто: під’єднав їх до одного домену vCenter Single Sign-On – про це поговоримо нижче у відповідному розділі. Причому, усе це доступно ще з Standard-рівня ліцензії.

Сервіс ліцензіювання

Цей сервіс пропонує загальний інвентар ліцензій та керування можливостями для усіх систем vCenter Server в домені Single Sign-On. Нижче розповімо про пакетне ліцензіювання у рамцях розмови про vSphere Auto Deploy, а згодом, в новій статті по адмініструванню продукта, обговоримо за цією темою вже абсолютно усі нюанси.

VMware Certificate Authority

VMware Certificate Authority (VMCA) надає кожен хост ESXi з підписаним сертифікатом, що має VMCA як кореневу авторизацію сертифікату, за дефолтом. Надання відбувається, коли ESXi-хост додається до vCenter Server напряму, чи як частина інсталяційного процесу. Усі такі сертифікати зберігаються локально на хості.

Сервіс vSphere ESXi Dump Collector

Можна налаштувати ESXi на зберігання пам’яті VMkernel на сервері у мережі, а не на диску, коли система стикається з критичним збоєм. vSphere ESXi Dump Collector збирає такі дампи пам’яті через мережу і є інструментом підтримки vCenter.

Сервіси керування життєвим циклом

vCenter Lifecycle Manager автоматизує процеси ВМ та видалення них з сервісу у визначений час. Він може автоматично розміщати сервери, спираючись на їх розташування, середовище, рівень сервісу чи продуктивності. І коли знаходиться рішення для набору критеріїв, машина автоматично розгортається. vSphere Lifecycle Manager – це чудовий, масштабний та дуже корисний інструмент, що дозволяє централізовану автоматизацію процесів патчування та керування версіями для VMware vSphere, а також підтримує ESXi-хости, ВМ та віртуальні застосунки.

Цілком природньо, з огляду на все вищезгадане, буде передбачити, що далі, коли перейдемо безпосередньо до підготовки до інсталяції та неї самої, казатимемо саме про установку ESXi та vCenter.

Зауваження. У сучасній офіційній документації VMware можна зустріти назву «vSphere+» – цей термін введено спеціально на позначення комплексного продукту і з on-premises компонентами (звичайна «сфера»), і з хмарними. При цьому on-premises робочими навантаженнями можна керувати з хмарної консолі, з одночасним доступом до хмарних сервісів:

Щодо керування середовищем ми можемо працювати з наступними інтерфейсами користувача у vSphere:

  • vSphere Client,
  • PowerCLI,
  • VMware Host Client,
  • vSphere ESXi Shell,
  • ESXCLI:

Віртуалізація ресурсів

Наш ESXi в своїй роботі не може без взаємодії з ресурсами (CPU, пам’ять, мережі, сховище, GPU). Вони виділяються на хост, завдяки чому на створеній на ньому ВМ (гостьовій) можна запускати будь-який застосунок у будь-якій підтримуваній ОС. Множина ВМ, запущена на фізичному хості, користується обчислювальними ресурсами, пам’яттю, мережевим господарством та можливостями сховищ(а) хоста:

У фізичному середовищі операційна система бере на себе право власності на усі фізичні процесори в системі та на усю пам’ять. А от рівень віртуалізації виконує інструкції лише тоді, коли це необхідно, щоб віртуальні машини працювали так, ніби вони діють безпосередньо на фізичній машині.

Важливо! Віртуалізація процесора не є емуляцією. За допомогою програмного емулятора програми можуть існувати в комп’ютерній системі, відмінній від тієї, для якої вони були спочатку написані. Емуляція забезпечує портуємість, але може негативно вплинути на продуктивність. Віртуалізація ЦП не є емуляцією, оскільки підтримувані гостьові операційні системи розроблені для процесорів x64.

Використовуючи гіпервізор, ОС можуть працювати на фізичних процесорах x64 хостів. Коли багато віртуальних ВМ запущено на хості ESXi, вони можуть конкурувати за ресурси ЦП. Якщо це відбувається, час хосту ESXi розділяє фізичні процесори на всі віртуальні машини, щоб кожна діяла так, ніби вона має певну кількість віртуальних процесорів.

Майже той самий принцип застосовується щодо пам’яті. Коли програма запускається, вона використовує інтерфейси, надані ОС, для виділення або звільнення сторінок віртуальної пам’яті під час виконання. Віртуальна пам’ять – це стара техніка, яка використовується в більшості ОС загального призначення. ОС використовують віртуальну пам’ять, щоб надати застосункам більше пам’яті, ніж та, до якої вони мають фізичний доступ. Майже всі сучасні процесори мають апаратне забезпечення для підтримки віртуальної пам’яті. Віртуальна пам’ять створює єдиний віртуальний адресний простір для програм. За допомогою ОС та апаратного забезпечення віртуальна пам’ять може обробляти трансляцію адрес між віртуальним адресним простором і фізичним адресним простором. Техніка адаптує середовище виконання для підтримки великих адресних просторів, захисту процесів, відображення файлів і обміну в сучасних комп’ютерних системах. У віртуалізованому середовищі рівень віртуалізації VMware створює безперервний адресний простір пам’яті для віртуальної машини під час її запуску. Виділений простір пам’яті налаштовується під час створення ВМ та має ті самі властивості, що й віртуальний адресний простір. Завдяки цій конфігурації гіпервізор може запускати кілька ВМ одночасно, захищаючи пам’ять кожної від доступу інших.

Щодо віртуалізації мережі, ВМ можна налаштувати за допомогою одного або кількох віртуальних адаптерів Ethernet. ВМ використовують віртуальні комутатори одному й тому ж хості ESXi для зв’язку одна з одною за допомогою тих самих протоколів, які використовуються через фізичні комутатори, без необхідності додаткових апаратних пристроїв. Віртуальні комутатори також підтримують VLAN, які сумісні зі стандартними реалізаціями VLAN від інших постачальників мережевого обладнання. Завдяки віртуальній мережі VMware можна зв’язувати локальні ВМ між собою і підключати їх до зовнішньої мережі через віртуальний комутатор. Останній, як і фізичний комутатор Ethernet, пересилає фрейми на рівень data link. Хост ESXi може містити кілька віртуальних комутаторів, і до зовнішньої мережі вони можуть підключатися через вихідні адаптери Ethernet, які називаються vmnics. Віртуальний комутатор може об’єднати кілька vmnic разом, як NIC teaming на традиційному сервері, пропонуючи більшу доступність і пропускну здатність для ВМ. Віртуальні комутатори багато в чому схожі на сучасні фізичні Ethernet. Як і фізичний комутатор, кожен віртуальний ізольований і має власну таблицю переадресації. Будь-який пункт призначення, який шукає комутатор, може збігатися лише з портами на тому самому віртуальному комутаторі, з якого виник фрейм. Ця функція покращує безпеку та ускладнює злам ізоляції віртуального комутатора. Віртуальні комутатори також підтримують сегментацію VLAN на рівні порту, так що кожен порт можна налаштувати як порт доступу, чи магістральний, забезпечуючи доступ до однієї або кількох VLAN. Однак, на відміну від фізичних комутаторів, віртуальним не потрібен протокол STP, оскільки застосовується однорівнева топологія мережі. Кілька віртуальних комутаторів не можуть бути з’єднані між собою, і мережевий трафік не здатен перетікати безпосередньо від одного віртуального комутатора до іншого на тому самому хості. Віртуальні комутатори забезпечують усі необхідні порти в одному комутаторі й не потребують каскадного підключення, оскільки не мають спільних фізичних адаптерів Ethernet, і між ними не виникає витоків.

Ще треба зупинитися на віртуалізації ресурсів сховища. Для зберігання віртуальних дисків ESXi використовує сховища даних, які є логічними контейнерами, які приховують особливості фізичного сховища від ВМ і забезпечують уніфіковану модель для зберігання їх файлів. vSphere підтримує такі типи сховищ даних:

  • VMFS (VMware Virtual Machine File System) – файлова система віртуальної машини кластерного типу, яка забезпечує віртуалізацію сховищ, оптимізовану для ВМ. Кілька хостів ESXi можуть читати та записувати в те саме сховище даних VMFS одночасно.
  • NFS (Network File System) – мережева файлова система, протокол обміну файлами, який хости ESXi використовують для зв’язку з пристроєм зберігання даних, підключеним до мережі (NAS).
  • vSAN — це програмно-визначене рішення для зберігання, яке забезпечує спільне сховище для ВМ. vSAN віртуалізує локальне фізичне сховище у вигляді пристроїв HDD або SSD на хостах ESXi у кластері, перетворюючи їх на єдине сховище даних.
  • vSphere Virtual Volumes – віртуальні томи vSphere. Сховище даних віртуалізує пристрої SAN і NAS шляхом абстрагування фізичних апаратних ресурсів до логічних пулів ємності. Масиви зберігання або сервери призначені для керування всіма аспектами сховищ даних віртуальних томів vSphere, а хости ESXi не мають прямого доступу до таких сховищ.

І нарешті, наостанок, віртуалізація GPU. Графічні пристрої GPU оптимізують складні графічні операції, що можуть виконуватися з високою продуктивністю без перевантаження ЦП. Віртуальні GPU можна додавати до ВМ у таких випадках:

  • Насичена 2D і 3D графіка;
  • Використання віртуальних десктопів VMware Horizon;
  • Графічні інтенсивні програми;
  • Наукові обчислення;
  • Робочі навантаження штучного інтелекту (AI) і machine learning.

GPU можуть використовуватися розробниками серверних додатків. Хоча сервери, зазвичай, не мають моніторів, підтримка GPU є важливою та актуальною для віртуалізації серверів. Можна налаштувати ВМ з чотирма пристроями vGPU, щоб охопити випадки використання, які потребують кількох акселераторів GPU. VMware підтримує відеокарти AMD і NVIDIA.

У VMware є спеціальна технологія – vSphere Bitfusion, що віртуалізує апаратні акселератори (GPU), щоб забезпечити пул спільних доступних у мережі ресурсів, з підтримкою робочих навантаженнь AI та ML. Завдячуючи їй, графічні процесори на одному хості можуть використовуватися ВМ, що працюють на інших хостах:

Вимоги та сумісність

Щоб зрозуміти, з якими іншими продуктами VMware наша нова vSphere буде товаришувати, а які вважатиме остаточно застарілими (тими, що вимагають попереднього апгрейду до встановлення взаємозв’язків із версією 8.0 середовища), варто скористатися інструментом VMware Product Interoperability Matrix:

І треба пам’ятати, що останній vCenter Server appliance може встановитися лише на хостах ESXi версії 6.7, або свіжішій, чи на ESXi-хост або DRS-кластер з інвентаря інстансу vCenter Server версії 6.7 і більш новій.

Так як сьогодні ми приділяємо максимум уваги саме greenfield-інсталяції, усієї проблематики співіснування, необхідних супутніх апгрейдів та іншого торкнемося докладно у окремому матеріалі про оновлення vSphere до версії 8.0.

Всі інші питання сумісності (процесори, пристрої сховища, SAN-масиви, I/O-пристрої, інші пристрої тощо) вендор рекомендує задавати в цій всеохоплюючій табличці: VMware Compatibility Guide. Лише зауважимо, що максимальне ресурсне охоплення ВМ, а також робота з деякими технологіями (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.

Конфігураційні ліміти

Щоб наше середовище було працездатним, і взагалі дозволило себе створити саме в такому вигляді, як нам потрібно, у його розрахунку спиратися треба не лише на наше бачення функціоналу системи і її можливостей, а й на визначені VMware максимуми конфігурації. Ознайомитись з ними можна в зручному інструменті VMware Configuration Maximus. Щодо 8-ї версії vSphere він виглядає так. Там можна знайти усі ліміти, починаючи з базових (максимуми для ВМ, vCenter Server, vSAN й взагалі всього, що стосується сховищ, мережі, ESXi Host тощо), й аж до співпраці з Kubernetes та Cloud. Якщо ви вже мали справу з vSphere, навіть з «сімкою», можете переконатися лишень на декількох наведених у таблиці нижче прикладах, наскільки суттєво зросли можливі параметри нашого середовища:

Конфігураційний параметр Максимальне значення
Віртуальні машини (на одну)
  • vCPU
768
  • пам’ять
24ТБ
  • об’єм віртуального диску
62ТБ
  • віртуальних NIC
10
  • підключених USB-пристроїв
20
  • паралельних підключень до віддаленої консолі
40
  • політик сховища
1024
  • графічної пам’яті
4ГБ
vCenter Server
  • користувачів та груп
1 000 000
  • затримка між зв’язаними vCenter Server
150мс
  • затримка між клієнтом vSphere та vCenter Server
100мс
  • груп AD чи OpenLDAP на користувача
1015
  • хостів на vCenter Server
2500
  • увімкнених ВМ на vCenter Server
40 000
  • зареєстрованих ВМ на vCenter Server
45 000
  • пов’язаних vCenter Server
15
  • МАС-адрес на vCenter Server
65 536
  • хостів на vCenter Server керованих vLCM
1000
  • vMotion-операцій на хост (при 1Гбіт/с мережі / 10Гбіт/с)
4 / 8
  • vMotion-операцій на датастор
128
  • бібліотека контенту (кількість об’єктів на VC / розмір об’єкту / кількість бібліотек на VC)
2000 / 1ТБ / 1000
  • профілів хоста (створених / прикріплених)
500 / 500
ESXi (на хост)
  • пам’яті
24ТБ
  • віртуальних дисків
2048
  • фізичних NIC (1Гбіт/с / 10Гбіт/с / 20Гбіт/с)
32 / 16 / 16
  • розподілених світчів (на хост / на VC)
16 / 128
  • графічної пам’яті
16

Також у конфігураційних максимумах, звичайно, багато уваги приділяється кластерізації, але до них звернемося, коли конкретно до неї дійдемо.

Вимоги до рівня системного сховища

Компонування системного сховища ESXi складається з 4 партицій:

Партиція Використання Тип
System Boot Зберігає завантажувач і модулі EFI FAT16
Boot-bank 0 Системне місце для зберігання завантажувальних модулів ESXi FAT16
Boot-bank 1 Системне місце для зберігання завантажувальних модулів ESXi FAT16
ESX-OSData Діє як спільна локація для зберігання додаткових модулів. Не використовується для завантаження та ВМ. Консолідує застарілий розділ /scratch, locker-партицію для VMware Tools, і призначення основного дампа. VMFS-L

Важливо! У випадку, коли медіа установки – то є USB чи SD-карта, за best practice треба створити партиції ESX-OSData на пристрої постійного сховища, яке не використовується спільно декількома ESXi-хостами.

Том ESX-OSData поділений на дві категорії даних високого рівня: постійну й непостійну. Перші містять дані, що записуються рідко (VMware Tools, ISO, конфігурації та дампи ядра). До непостійних же відносяться ті, що записуються часто: журнали логів, глобальні траси VMFS, дані vSAN Entry Persistence Daemon (EPD), траси vSAN та БД у реальному часі:

Розміри партицій, за винятком розділу завантаження системи, можуть змінюватися залежно від розміру завантажувального медіа. Якщо, наприклад, воно ємністю 142 Гб й більше, датастор VMFS створюється автоматично для зберігання даних ВМ.

Щоб обмежити розмір системних партицій сховища на завантажувальному медіа, можна скористатися завантажувальною опцією ESXi-інсталятора «systemMediaSize», що запропонує наступні варіанти:

  • min (32 ГБ, для одного диска або вбудованих серверів),
  • small (64 ГБ, для серверів з не менше 512 ГБ оперативної пам’яті),
  • default (128 ГБ),
  • max (споживає весь доступний простір для багатотерабайтних серверів).

Вимоги до «заліза», мережі та сховища

Відповідно, мінімальними базовими значеннями ресурсів для ESXi 8.0 VMware визначила наступні:

  • підтримувана серверна платформа,
  • 2 ядра CPU,
  • 8 Гб RAM (12Гб для продуктиву),
  • 1+ гігабітний чи швидший Ethernet-контролер,
  • завантажувальний диск на 32Гб постійного сховища.

Для максимальної продуктивності ESXi 8.0 бажано забезпечити пристрої з, щонайменше, 100Мб/с швидкістю послідовного запису, а для запобігання падіння пристрою він повинен бути RAID 1 mirrored.

Якщо використовується Auto Deploy метод інсталляції, або директорія логів відрізняється від дефолтної локації в scratch-директорії на томі VMFS, може знадобитися зміна розміру журналу логів та параметрів обертів, щоб мати впевненість, що їм вистачить місця. Дефолтні значення об’єму логів залежать від наявного місця на сховищі й того, як саме налаштована система логування. Хости з Auto Deploy зберігають логи на RAM диску, тобто, простір для них виділяється доволі маленький. У цьому випадку краще перенаправляти логи мережею за допомогою віддаленого колектора, або ж на NAS чи NFS-сховище. Мінімальний розмір та конфігурація ротації для логів hostd, vpxa і fdm:

Тип логів Максимальний розмір файла логів, МБ Кількість обертів для збереження Мінімальний потрібний об’єм диску, МБ
Management Agent (hostd) 10 10 100
VirtualCenter Agent (vpxa) 5 10 50
Агент vSphere HA (Fault Domain Manager, fdm) 5 10 50

Для успішного розгортання vCenter Server Appliance нам, в свою чергу, буде потрібно:

Розмір середовища vSphere К-сть vCPU Пам’ять, Гб
Tiny (до 10 хостів або до 100 ВМ) 2 14
Small (до 100 хостів чи 1 000 ВМ) 4 21
Medium (до 400 хостів або 4 000 ВМ) 8 30
Large (до 1 000 хостів або 10 000 ВМ) 16 39
X-Large (до 2 000 хостів або до 35 000 ВМ) 24 58

Важливо! Якщо на меті додати ESXi-хост з більш ніж 512 LUN та 2 048 шляхами до інвентаря vCenter Server, розгортати треба, виключно, vCenter Server appliance для Large або X-Large середовища.

Щодо сховища, в залежності від розміру середовища й відштовхуючись від потреб БД, рекомендується наступне (у Гб):

Розмір середовища vSphere Дефолтний розмір сховища Розмір сховища Large Розмір сховища X-Large
Tiny (до 10 хостів або до 100 ВМ) 579 2 019 4 279
Small (до 100 хостів чи 1 000 ВМ) 694 2 044 4 304
Medium (до 400 хостів або 4 000 ВМ) 908 2 208 4 468
Large (до 1 000 хостів або 10 000 ВМ) 1 358 2 258 4 518
X-Large (до 2 000 хостів або до 35 000 ВМ) 2 283 2 383 4 643

Вимоги до браузера та ОС

Браузер, що використовується, має підтримувати VMware Host Client. У розрізі ОС клієнтом хоста підтримуються наступні версії браузера:

Браузер, версія Mac OS Windows Linux
Google Chrome 89+ 89+ 75+
Mozilla Firefox 80+ 80+ 60+
Microsoft Edge 90+ 90+

Інсталяція vCenter Server наразі працює з такими ОС:

ОС Версія Мінімальна конфігурація апаратного забезпечення
Windows
  • Windows 10, 11
  • Windows 2016 x64 bit
  • Windows 2019 x64 bit
  • Windows 2022 x64 bit
4 GB RAM, 2 CPU з 4 ядрами 2.3 GHz, 32 GB хард-диск, 1 NIC
Linux
  • SUSE 15
  • Ubuntu 18.04, 20.04, 21.10
4 GB RAM, 1 CPU з 2 ядрами 2.3 GHz, 16 GB хард-диск, 1 NIC
Mac
  • macOS 10.15, 11, 12
  • macOS Catalina, Big Sur, Monterey
8 GB RAM, 1 CPU з 4 ядрами 2.4 GHz, 150 GB хард-диск, 1 NIC

Зауваження. Клієнтські машини на Mac 10.15+ не підтримують паралельні розгортання декількох appliances через GUI. Тільки послідовні.

Важливо! Бібліотеки Visual C++ потрібно інсталювати, щоб запустити інсталятор CLI у версіях Windows, старіших за Windows 10. Інсталятори Microsoft для цих бібліотек знаходяться в каталозі vcsa-cli-installer/win32/vcredist.

І, нарешті, останнє зауваження: Якщо плануєте розгортатися через GUI, прослідкуйте, щоб ваш монітор був з не меншою за 1024×768 роздільною здатністю.

Ліцензування

«Вісімка» вимагає ліцензування на кожні 32 фізичні ядра.

Порівняння особливостей усіх існуючих на даний момент типів ліцензій vSphere 8.0 наведено у цьому документі. Усі задачі ліцензування розглянемо в запланованій окремій статті про адміністрування vSphere 8.0.

Підготовка до розгортання vSphere 8.0

Якщо нами виконані всі вимоги щодо сумісності, придбані відповідні ліцензії (можна поки на evaluation-режимі в 60 днів – таким чином й встановлюється спочатку, а ввести їх потім. Чи взагалі без них, якщо ставимо на пісочницю найелементарнішу версію для тестування й огляду), то переходимо до безпосередньої підготовки до розгортання vSphere 8.0.

Розпочати її варто зі скачування відповідних OVA з розділу завантажень офіційного сайту VMware. Наразі жодних патчів для ESXi vSphere 8.0 ще не виходило, тому робочим є білд 20513097):

а от для vCenter Server пропонується вже версія 8.0.0а – 20519528):

Це для ліцензій класу Standard, а інші образи можна знайти за посиланням. Там же, до речі, й нові VMware Tools 12.1.5 та інші пов’язані компоненти.

Інсталятор ESXi можна завантажувати трьома способами: з CD/DVD, з USB-пристрою, що пасує, та через PXE-завантаження по мережі. Для vCenter Server треба буде підмонтувати ISO-образ до клієнтської машини, з якої плануємо розгортати, чи робити інші операції з ним.

Порти та протоколи

У рамцях підготовки до інсталяції попередньо треба потурбуватися про відкриття необхідних портів. Чудовий інструмент щодо цього створений вендором на спеціальному ресурсі – там в фільтрах версії просто вводите «8» і маєте увесь необхідний список, за яким йдете відповідно до того, що саме вам в результаті буде потрібно в системі.

Підготовка необхідної інформації

Рекомендується попередньо підготувати своєрідні worksheet і по ESXi (незважаючи на те, чи робите ви вводи в процесі інтерактиву, чи самостійно пишете інсталяційний скріпт), і по vCenter з усією необхідною інформацією щодо потрібних в процесі вводів та даних. По ESXi запишіть таке:

  • VLAN ID (опціонально, діапазон від 0 до 4094),
  • IP address – IP-адресу (опціонально, по дефолту DHCP – можна дозволити DHCP налаштувати мережу в процесі інсталяції. Потім все це можна поміняти),
  • Subnet mask – маску підмережі (опціонально, розраховується з IP-адреси),
  • Gateway – шлюз (опціонально, спирається на налаштовану IP-адресу та маску підмережі),
  • Primary DNS (опціонально, спирається на налаштовану IP-адресу та маску підмережі),
  • Secondary DNS ( опціонально),
  • Host name – ім’я хоста (потрібно для налаштування статичного IP – клієнт «сфери» може користуватися як іменем хоста, так і IP-адресою для доступу до ESXi-хоста),
  • Install location (має бути, мінімум, 5Гб місця, якщо інсталюєте компоненти на один диск),
  • Root password (придумати від 8 до 40 символів, малі та великі літери, цифри, спецсимволи – будь-яка комбінація, не можна цілком слова, їх частини, імена користувачів й т.і.).

А по vCenter Server Appliance – наступне:

  • FQDN і IP-адреса цільового серверу (ESXi-хоста чи інстанса vCenter Server), на якому розгортаємо appliance,
  • HTTPS-порт цільового серверу – 443,
  • ім’я користувача з привілеями адміністратора на цільовому сервері (для ESXi-хоста – root, для інстанса vCenter Server – «user_name@your_domain_name») та пароль,
  • дата-центр з інвентаря vCenter Server, де розгортається appliance. Цільовий сервер має бути інстансом vCenter Server. Опціонально, можна надати папку дата-центру,
  • ESXi-хост чи DRS-кластер з інвентаря дата-центру, на якому розгортається appliance,
  • ім’я ВМ для appliance (не має містити символи «%», «\», «/», менше 80 знаків),
  • пароль користувача root для операційної системи appliance (8-20 символів ASCII без пробілів з, мінімум, однією великою та однією маленькою літерою, однією цифрою, одним спецсимволом),
  • розмір розгортання (дефолтне – Tiny),
  • розмір сховища vCenter Server appliance, враховуючи середовище (дефолтне – Default),
  • ім’я датастора, на якому бажано зберігати конфігураційні файли і віртуальні диски appliance (покаже доступні для цільового серверу датастори),
  • Thin Disk Mode – Enable/disable (за дефолтом – Disabled),
  • ім’я мережі, до якої підключається appliance (продемонструє меню, що випадає) – вона має бути доступна з клієнтської машини, з якої відбувається усе розгортання,
  • IP-версія адреси appliance – IPv4/IPv6 (за дефолтом IPv4),
  • IP-призначення для адреси appliance – static/DHCP (за дефолтом static),
  • FQDN (якщо static з попереднього пункту) – щоб використовувати в якості імені системи (або IP-адреса),
  • IP-адреса,
  • для IPv4-мереж можна використовувати або маску підмережі, або префікс мережі. Для IPv6-мереж – префікс мережі,
  • дефолтний шлюз,
  • DNS-сервери, відділені комами,
  • ім’я системи (FQDN) – тільки якщо в вас DHCP з IPv4 і Dynamic DNS (DDNS) сервер, доступний в середовищі,
  • параметри синхронізації часу (дефолтне – Synchronize time with NTP servers). Якщо використовується більше одного NTP-серверу, надаються їх IP-адреси чи FQDN, через кому,
  • включити чи виключити доступ по SSH (за дефолтом – Disabled),
  • ім’я для нового vCenter Single Sign-On домену,
  • пароль для акаунта адміністратора («administrator@your_domain_name» – вимоги див. вище),
  • пароль користувача адміністратор vCenter Single Sign On для домену,
  • Join or do not participate in the VMware Customer Experience Improvement Program (CEIP) (дефолтне – Join the CEIP) – програма покращення досвіду користувача, вирішуємо, чи хочемо приєднатися.

Важливо! При використанні FQDN треба переконатися, що клієнтська машина, з якої відбувається розгортання appliance, і мережа, на якій він розгортається, користуються тим же самим DNS-сервером.

Підготовка до інсталяції хостів ESXi

У цьому розділі приділимо увагу підготовці до усіх трьох варіантів інсталяції ESXi (інтерактивному, через скрипти та vSphere Auto Deploy), а також кастомізації образів ESXi за допомогою vSphere ESXi Image Builder.

Кастомізація інсталяцій за допомогою vSphere ESXi Image Builder

Одразу зауважимо, що усе, що стосується vSphere ESXi Image Builder вимагає доступу до клієнту vSphere, наявності хоча одного vCenter Server та, відповідно, хоча б одного базового хоста, на якому наш vCenter розгортався. Це не метод побудови з нуля – це зручний функціонал для подальшого розширення можливостей й автоматизації процесів розгортання хостів в системі.

VMware vSphere® ESXi™ Image Builder CLI працює зі створенням інсталяційних образів ESXi з індивідуальним набором оновлень, патчів та драйверів. Він використовується з vSphere Client чи PowerCLI, і додатково може включати в образ драйвери сторонніх мереж чи сховищ, що видавалися поміж релізами vSphere:

Розгортається така кастомізація за допомогою запису її на інсталяційний DVD або через vCenter Server (функція Auto Deploy). Командлети vSphere ESXi Image Builder беруть профілі образів та VIB за вводи та формують різноманітні виводи, що можуть експортуватися у вигляді ISO-образів або ZIP-файлу офлайн-сховища. Профілі образів визначають набір VIB, які використовує інсталяція ESXi чи процес апдейту. Вони застосовуються до ESXi-хостів, наданих через vSphere Auto Deploy та мають відповідати наступним вимогам:

  • Унікальне ім’я та комбінація вендорів;
  • Рівень прийняття (Image Builder буде перевіряти, чи співпадає VIB з рівнем прийняття, визначеним у профілі);
  • Якщо якісь VIB потрібні іншим VIB, видалити їх не можна;
  • Дві версії одного й того ж самого VIB не можна включати в один профіль образу (нова версія замістить існуючу).

Важливо! Рівень прийняття кожного VIB на хості має бути, щонайменше, таким самим, як рівень прийняття хоста.

Важливим моментом в житті профіля образу є валідація. Щоб пройти її успішно, він має:

  • Складатися, мінімум, з одного базового VIB та одного завантажувального модуля ядра;
  • Якщо два VIB пов’язані – обидва мають бути включені в профіль образу;
  • VIB не повинні конфліктувати одне з одним;
  • Не можна додавати два однаково названі VIB, навіть різних версій (відбувається заміщення старшого свіжішим);
  • Немає ніяких проблем з рівнем прийняття.

Кожен раз, коли змінюється профіль образу, vSphere ESXi Image Builder перевіряє, чи це не скасовує валідність профілю.

Рівень прийняття (acceptance level) та його зміна

Рівень прийняття – важлива характеристика кожного VIB та профілю образу. Вона позначає шлях, яким вони були протестовані та яким підтримуються. Загалом варто перелічити наступні існуючі рівні:

  • VMwareCertified (найсуворіші вимоги, ретельне тестування, служба підтримки VMware приймає за ним звернення в повному обсязі. Наразі лише програмні драйвери I/O Vendor Program (IOVP) належать до нього);
  • VMwareAccepted (перевірочне тестування партнером, але не повне для кожної функції ПО, а VMware перевіряє результат. Звернення в службу підтримки VMware перенаправляються до партнера. Приклади: провайдери CIM та плагіни PSA);
  • PartnerSupported (опубліковані партнером, якому VMware довіряє, ним же протестовані, але VMware не перевірені. Звернення – також до партнера. Приклад: технології драйверів ATAoE, SSD, інші нестандартні драйвери апаратного забезпечення);
  • CommunitySupported (створені особами чи компаніями за межами партнерських програм VMware, нетестовані схваленим VMware чином, не підтримуються ані VMware, ані партнерами).

Дефолтним для VIB є рівень «PartnerSupported». Його можна змінити командами ESXCLI (cmdlet «Set-EsxImageProfile» для профілю образу) за наступною процедурою:

  1. Заходимо в сесію PowerCLI та запускаємо cmdlet «Add-EsxSoftwareDepot», для кожного сховища, з яким хочемо працювати:

Add-EsxSoftwareDepot –DepotUrl <depot_url> – віддалене сховище,

або завантажуємо ZIP-файл в локальну файлову систему і запускаємо

Add-EsxSoftwareDepot -DepotUrl C:\<file_path>\<offline-bundle>.zip  

Командлет поверне один або більше SoftwareDepot об’єктів.

  1. Отримуємо рівень прийняття профілю образу:

Get-EsxImageProfile -Name string

  1. Встановлюємо рівень прийняття профілю образу:

Set-EsxImageProfile -Name string -AcceptanceLevel level

А змінити рівень прийняття хоста можна так:

  1. Викликаємо рівень прийняття для профілю образу чи VIB командами:

esxcli –server=server_name software sources vib list –depot=depot_URL – проглянути інформацію по всім VIB

esxcli –server=server_name software sources vib list –viburl=vib_URL – проглянути інформацію по вказаному VIB

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 – проглянути інформацію по вказаному профілю образу

  1. Перевіряємо рівень прийняття хоста:

esxcli –server=server_name software acceptance get

  1. Змінюємо рівень прийняття хоста:

esxcli –server=server_name software acceptance set –level=acceptance_level , де значення «acceptance_level» – то є «VMwareCertified», «VMwareAccepted», «PartnerSupported» чи «CommunitySupported». Значення чутливі до регістру.

Налаштування vSphere ESXi Image Builder

Перед тим, як вдатися до налаштування vSphere ESXi Image Builder, треба пересвідчитися, чи достатньо сховища для репозиторія vSphere Auto Deploy (сервер vSphere Auto Deploy користується ним, щоб зберігати потрібні йому дані, включно з правилами та наборами правил, які створюються для VIB та профілів образів, що вказуються до тих правил). По best practice це має бути 2Гб (кожен профіль образу займає, приблизно, 400Мб). Далі:

  1. Проходимо в клієнті vSphere в Home > Auto Deploy;
  2. На сторінці Auto Deploy обираємо потрібний vCenter Server з розкривного меню нагорі;
  3. Клікаємо на Enable Image Builder задля активації сервісу – з’явиться вкладка Software Depots;
  4. Додаємо сховище ПО (одне чи декілька) в інвентар vSphere ESXi Image Builder: клікаємо на New – з’явиться вікно Add Software Depot, де обираємо тип сховища (Online Depot/Custom Depot). Для першого вводимо ім’я сховища в інвентарі та URL онлайн-сховища, а для другого – лише ім’я. Натискаємо Add;
  5. Опціонально, заходимо на вкладку Software Packages, щоб побачити вміст обраного сховища та додаткову інформацію про пакети;
  6. Опціонально, для «Online depot» можна отримати найсвіжіші пакети сховища, натиснувши Check for Updates, або додаткову інформацію про сховище, клікнув на More info;
  7. Якщо працюєте з офлайн-сховищем в локальній файловій системі, можна імпортувати ZIP-файл у інвентар vSphere ESXi Image Builder. На тій самій вкладці Software Depots клікаємо на Import, вводимо ім’я сховища в інвентарі, опісля натискаємо на Browse та обираємо ZIP-файл з локальної системи і клікаємо Upload.
Операції з профілем образу

Профілі образу можна створювати нові, клонувати вже існуючі, редагувати, порівнювати між собою, переміщати у інше сховище ПО, експортувати готові в ISO чи Offline Bundle ZIP, регенерувати.

Щоб створити новий профіль образу:

  1. Проходимо в Home > Auto Deploy;
  2. З розкривного меню Software depot обираємо, в якому користувацькому сховищі хочемо додати новий профіль;
  3. На вкладці Image Profiles клікаємо New Image Profile;
  4. Вводимо унікальне ім’я, вендора та опис, натискаємо Next – з’явиться вікно Select software packages;
  5. З розкривного меню обираємо рівень прийняття для профіля образу;
  6. Обираємо VIB, які хочемо додати в профіль образу і знімаємо вибір з тих, які не потрібні, після чого натискаємо на Next;

Важливо! Профіль образу має містити завантажуваний образ ESXi, щоб бути валідним.

  1. На сторінці Ready to complete проглядаємо підсумкову інформацію про новий профіль образу. Клікаємо Finish.

Щоб клонувати вже існуючий профіль образу:

  1. Проходимо в Home > Auto Deploy;
  2. З розкривного меню Software depot обираємо, в якому сховищі є профіль образу, що треба клонувати;
  3. Зі списку профілів образів в сховищі обираємо той, що має бути клонованим, та натискаємо Clone;
  4. Вводимо унікальне ім’я профілю образу, вендора й опис;
  5. З розкривного меню Software depot обираємо користувацьке сховище, в яке хочемо додати новий профіль образу, клікаємо Next – з’явиться сторінка Select software packages;
  6. З розкривного меню обираємо рівень прийняття для профіля образу;
  7. Обираємо VIB, які хочемо додати до профіля образу та знімаємо вибір з тих, що не потрібні. Натискаємо Next;
  8. На сторінці Ready to complete проглядаємо підсумкову інформацію про новостворений профіль образу, після чого клікаємо Finish.

Щоб відредагувати існуючий профіль образу:

  1. Проходимо в Home > Auto Deploy;
  2. З розкривного меню Software depot обираємо, в якому сховищі є профіль образу, що треба відредагувати;
  3. На вкладці Image Profiles обираємо потрібний профіль образу та клікаємо на Edit – з’явиться помічник Edit Image Profile;
  4. Опціонально, можна змінити ім’я, вендора та опис;
  5. Клікаємо Next – з’явиться сторінка Select software packages;
  6. З розкривного меню обираємо рівень прийняття профіля образу;
  7. Обираємо VIB, що хочемо додати, і знімаємо вибір з тих, що не потрібні;
  8. На сторінці Ready to complete проглядаємо підсумкову інформацію та клікаємо Finish.

Щоб порівняти два профіля образів (чи однаковий в них список VIB, версія, рівень прийняття тощо):

  1. Проходимо в Home > Auto Deploy;
  2. З розкривного меню Software depot обираємо, в якому сховищі є профілі образів, що треба порівняти;
  3. На вкладці Image Profiles обираємо профіль образу та клікаємо Compare To – з’явиться помічник Compare Image Profile;
  4. Натискаємо Change, щоб обрати другий профіль образу – з’явиться сторінка Select Image Profile;
  5. Обираємо сховище ПО з розкривного меню і натискаємо на другий профіль образу;
  6. На сторінці Compare Image Profile обираємо опцію порівняння з розкривного меню Software packages: лівий бік списку продемонструє подробиці про VIB, що містяться у першому обраному профілі образу, а правий – те, що стосується другого профілю образу. Однакові VIB будуть помарковані як «Same», ті, що є в одному профілі, але відсутні у другому – як «Missing».

Щоб перемістити профіль образу в інше сховище ПО:

  1. Проходимо в Home > Auto Deploy;
  2. З розкривного меню Software depot обираємо, в якому сховищі є профіль образу, що треба перемістити;
  3. На вкладці Image Profiles обираємо профіль та клікаємо Move to;
  4. З розкривного меню обираємо користувацьке сховище, в яке хочемо перемістити профіль образу та натискаємо на OK.

Щоб експортувати профіль образу в ISO чи Offline Bundle ZIP:

  1. Проходимо в Home > Auto Deploy;
  2. З розкривного меню Software depot обираємо, в якому сховищі є профіль образу, з яким хочемо попрацювати;
  3. На вкладці Image Profiles обираємо профіль образу та клікаємо на Export – з’явиться вікно Export Image Profile;
  4. Обираємо тип експортованого файлу (ISO/ZIP);
  5. Опціонально, якщо воліємо пропустити верифікацію рівня прийняття, обираємо Skip acceptance level checking;
  6. Клікаємо ОК – посилання Download почне генерувати колонку «Download Image Profiles» обраного профілю образу;
  7. Коли процес завершиться, клікаємо на Download, щоб зберегти експортований файл.

Щоб регенерувати профіль образу (інколи треба, щоб переконатися, що всі хости мають однакову специфікацію софту, бо якщо специфікація образу була змінена в vSphere Lifecycle Manager, обов’язково необхідно вручну проапдейтити PXE-образ):

  1. Проходимо в Home > Auto Deploy;
  2. На вкладці Deploy Rules обираємо бажане правило (те, що відповідає ESXi-хостам у кластері, керованим образом);
  3. Якщо правило активне, спершу деактивуємо його: клікаємо на вкладку Activate/Deactive Rules, в діалоговому вікні обираємо правило – Deactivate та натискаємо на OK;
  4. Обираємо Reacreate Image Profile і в діалоговому вікні підтвердження клікаємо Recreate;
  5. Опціонально, активуємо правило знову – робимо те саме, що в 3 кроці, але тиснемо на Activate.

На тому, як працювати з правилами розгортання стосовно профілів образів зупинимось докладно нижче в розділі про підготовку до розгортання ESXi за допомогою vSphere Auto Deploy.

Підготовка до скриптованої інсталяції ESXi-хостів

Інколи дефолтний скрипт, про який мова буде йти нижче, в розділі «Інсталяція ESXi за допомогою скрипта» не влаштовує адміністратора. Щоб змодифікувати інсталяційний скрипт, користуємось наступним переліком підтримуваних команд (обов’язково має бути присутня команда «install», що створює дефолтні партиції, включно з VMFS-датастором, який займає увесь вільний простір, що залишиться після створення інших партицій):

accepteula / vmaccepteula (вимагається) – приймає ліцензійну угоду ESXi.

clearpart (опціонально) – очищує будь-які існуючі партиції на диску. Вимагає вказання команди install. Обережно редагуйте команду clearpart у існуючих скриптах!

  • –drives= (видаляє партиції на вказаних дисках)
  • –alldrives (ігнорує вимогу drives= й дозволяє очищати партиції на кожному дискові)
  • –ignoredrives= (видаляє партиції на всіх дисках, за виключенням вказаних. Потрібно, якщо не встановлено прапорець на –drives= чи –alldrives)
  • –overwritevmfs (дозволяє перезапис VMFS-партицій на вказаних дисках. За дефолтом, перезапис VMFS-партицій не дозволений)
  • –firstdisk=

disk-type1

[disk-type2,…]

Важливо! Якщо у системі є DPU, також вказується PCI-слот.

(Розбиває перший знайдений придатний диск. За замовчуванням доступні диски встановлені в наступному порядку:

    1. локально під’єднане сховище,
    2. мережеве сховище (віддалене).

Порядок дисків можна змінити, використовуючи доданий до аргументу список, де диски розділені комами. Якщо надається список фільтрів, дефолтні параметри перевизначаються. Можна комбінувати фільтри, щоб вказати окремий диск, включно з esx для першого диску зі встановленим на ньому ESXi, модель та інформацію про вендора або назву драйверу пристрою VMkernel. Наприклад, щоб віддати перевагу диску з назвою моделі ST3120814A і будь-якому дискові, що використовує драйвер mptsas, а не звичайному локальному дискові, аргумент буде:

–firstdisk=ST3120814A,mptsas,local

Можна використовувати localesx для локального сховища, що містить образ ESXi чи remoteesx для віддаленого сховища з ним)

dryrun (опціонально) – парсить та перевіряє інсталяційний скрипт. Не інсталює безпосередньо.

install – вказує, що це свіжа інсталяція. Команда install вимагає визначення, на котрому дискові буде проінстальовано ESXi.

  • –disk= чи drive= (Вказує диск для розбиття. В команді disk=diskname значення diskname може бути ім’ям диску чи цілим шляхом диску у файловій системі ESXi. Наприклад,

для імені диску: –disk=naa.6d09466044143600247aee55ca2a6405

для шляху пристрою: disk=/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0

  • –firstdisk=

disk-type1,

[disk-type2,…]

Важливо! Якщо в системі є DPU, також вказується й PCI-слот:

install –firstdisk –overwritevmfs –dpuPciSlots=

(Розбиває перший знайдений придатний диск. За замовчуванням доступні диски встановлені в наступному порядку:

a. локально під’єднане сховище,

b. мережеве сховище (віддалене).

Порядок дисків можна змінити, використовуючи доданий до аргументу список, де диски розділені комами. Якщо надається список фільтрів, дефолтні параметри перевизначаються. Можна комбінувати фільтри, щоб вказати окремий диск, включно з esx для першого диску зі встановленим на ньому ESXi, модель та інформацію про вендора або назву драйверу пристрою VMkernel. Наприклад, щоб віддати перевагу диску з назвою моделі ST3120814A і будь-якому дискові, що використовує драйвер mptsas, а не звичайному локальному дискові, аргумент буде:

–firstdisk=ST3120814A,mptsas,local

Можна використовувати localesx для локального сховища, що містить образ ESXi чи remoteesx для віддаленого сховища з ним)

  • –ignoressd (Включає жорсткі диски, придатні для розбиття. Ця опція може використовуватися з командою install і параметром –firstdisk. Вона має приоритет над firstdisk. Є недійсною з опціями –drive чи –disk і з командами upgrade та installorupgrade.
  • –overwritevsan (Використовується, коли інсталюється ESXi на диск SSD чи HDD (магнітний), що є в дисковій групі vSAN. При використанні цієї опції і якщо немає жодної партиції vSAN на обраному диску, інсталяція не піде. При інсталяції ESXi на диску з дискової групи vSAN, результат залежить від обраного диску. Якщо це SSD, обнуляться SSD та всі підлеглі HDD з цієї ж групи. Якщо це HDD, а розмір дискової групи перевищує 2, лише обраний HDD буде очищено. Якщо ж обрано HDD, але розмір дискової групи менший або рівний 2, і SSD, і обраний HDD будуть очищені.
  • –overwritevmfs (потрібно для перезапису існуючого датастора VMFS на диску перед інсталяцією)
  • –preservevmfs (зберігає наявне сховище даних VMFS на диску перед інсталяцією)
  • –novmfsondisk (Запобігає створенню на цьому дискові партицій VMFS. Має використовуватися з overwritevmfs, якщо на диску є партиції VMFS)
  • –systemdisk (При використанні USB чи SD пристрою systemDisk вказує локальний постійний диск для інсталяції партиції ESX-OSData. Наприклад,

install –firstdisk = usb –systemDisk=<diskID>

В результаті партиції boot bank поміщаються на USB-пристрій, в той час як партиція OSData є на диску, вказаному в параметрі systemDisk)

  • –repartitionsystemdisk (якщо використовується USB чи SD-пристрій, а локальний диск, вказаний в параметрі systemDisk, непорожній чи містить датастор, можна використовувати цю опцію задля впевненості, що постійний диск буде перерозбитий перед використанням)

Важливо! Якщо локальний постійний диск недоступний, чи його розмір менший за 32Гб, з’явиться попередження, хоча інсталяція не перерветься.

  • — forceunsupportedinstall (блокує інсталяцію застарілих CPU)

keyboard (опціонально) – встановлює тип клавіатури для системи.

  • keyboardType (Визначає схему клавіатури для обраного її типу. Має бути однією з наступних: бельгійською, бразильською, хорватською, чехословацькою, данською, естонською, фінською, французькою, німецькою, грецькою, ісландською, італійською, японською, латиноамериканською, норвезькою, польською, португальською, російською, словенською, іспанською, шведською, швейцарською французькою, швейцарською німецькою, турецькою, українською, британською, американською за замовчуванням, американською

serialnum чи vmserialnum (опціонально) – команда підтримується, починаючи з ESXi 5.1. Конфігурує ліцензування. Якщо не включити, ESXi буде проінстальовано в evaluation режимі.

  • –esx= (Вказує на ліцензійний ключ, що має використовуватися. Формат: XXXXX-XXXXX-XXXXX-XXXXX-XXXXX).

network (опціонально) – вказує мережеві адреси для системи.

  • –bootproto=[dhcp| static] (вказує, чи потрібно отримувати мережеві налаштування від DHCP, чи вводити їх вручну)
  • –device= (Вказує або MAC-адресу мережевої карти, або назву пристрою у формі vmnicNN, як у vmnic Цей варіант стосується аплінк-пристроїв для віртуального комутатора)
  • –ip= (Надає IP-адресу для інстальованої машини у форматі xxx.xxx.xxx.xxx. Потрібна з опцією bootproto=static, інакше ігнорується)
  • –gateway= (Призначає шлюз за замовчуванням як IP-адресу в форматі xxx.xxx.xxx.xxx. Використовується з опцією bootproto=static)
  • –nameserver= (Призначає основний сервер імен як IP-адресу. Використовується з опцією bootproto=static. Пропустіть цей параметр, якщо не збираєтеся використовувати DNS. Він може приймати дві IP-адреси. Наприклад,

–nameserver=”10.126.87.104[,10.126.87.120]” )

  • –netmask= (Вказує маску підмережі для інстальованої системи в форматі 255.xxx.xxx.xxx. Використовується з опцією bootproto=static)
  • –hostname= (вказує ім’я хоста для інстальованої системи)
  • –vlanid= vlanid (Визначає, до якої VLAN підключена система. Використовується або з bootproto=dhcp, або з bootproto=static опцією. Значення – ціле число від 1 до 4096)
  • –addvmportgroup=(0|1) (Вказує, чи додавати VM Network port group, що використовується віртуальними машинами. Дефолтне значення – 1)

paranoid (опціонально) – змушує попереджувальні сповіщення переривати інсталяцію. Якщо на неї не зважати, попереджувальні сповіщення будуть просто збережені в логах.

part чи partition (опціонально) – створює додаткове сховище даних VMFS на системі. Створюється лише одне сховище на диск. Не може використовуватися на тому ж диску як інсталяційна команда. Тільки одна партиція може бути вказана на диск і це має бути виключно VMFS-партиція.

  • datastore name (вказує, де партиція має бути підмонтованою)
  • –ondisk= чи ondrive= (вказує диск чи пристрій, де створюється партиція)
  • –firstdisk=

disk-type1,

[disk-type2,…]

Важливо! Якщо в системі є DPU, також вказується й PCI-слот:

install –firstdisk –overwritevmfs –dpuPciSlots=

(Розбиває перший знайдений придатний диск. За замовчуванням доступні диски встановлені в наступному порядку:

a. локально під’єднане сховище,

b. мережеве сховище (віддалене).

Порядок дисків можна змінити, використовуючи доданий до аргументу список, де диски розділені комами. Якщо надається список фільтрів, дефолтні параметри перевизначаються. Можна комбінувати фільтри, щоб вказати окремий диск, включно з esx для першого диску зі встановленим на ньому ESXi, модель та інформацію про вендора або назву драйверу пристрою VMkernel. Наприклад, щоб віддати перевагу диску з назвою моделі ST3120814A і будь-якому дискові, що використовує драйвер mptsas, а не звичайному локальному дискові, аргумент буде:

–firstdisk=ST3120814A,mptsas,local

Можна використовувати localesx для локального сховища, що містить образ ESXi чи remoteesx для віддаленого сховища з ним)

reboot (опціонально) – перевантажує машину після завершення скриптованої інсталяції.

  • <–noeject> (CD не виймається після інсталяції)

rootpw (вимагається) – встановлює пароль root для системи.

  • –iscrypted (вказує, що пароль зашифровано)
  • password (вказує значення паролю)

%include чи include (опціонально) – вказує на інший інсталяційний скрипт для аналізу. Ця команда обробляється так само, як багаторядкова, проте приймає лише один аргумент.

  • filename (Наприклад, %include part.cfg )

%pre (опціонально) – вказує скрипт, який треба запустити до оцінки конфігурації kickstart. Наприклад, цим можна скористатися, щоб сгенерувати файли, які має включити в себе kickstart.

  • –interpreter

=[python|busybox] (Визначає інтерпретатор для використання. Дефолтним є busybox)

%post (опціонально) – запускає вказаний скрипт після завершення пакетної інсталяції. Якщо вказати декілька секцій %post, вони запустяться в порядку, в якому вони з’явилися в інсталяційному скрипті.

  • –interpreter

=[python|busybox] (Визначає інтерпретатор для використання. Дефолтним є busybox)

  • –timeout=secs (Визначає таймаут для запуску скрипта. Якщо скрипт ще не завершив свою роботу на момент, коли таймаут вийшов, скрипт буде зупинено силоміць)
  • –ignorefailure =[true|false] (Якщо true, інсталяція буде ваважатися успішною, навіть якщо скрипт %post зупиниться з помилкою)

%firstboot – створює init скрипт, що запускається лишень при першому завантаженні. Не впливає жодним чином на послідовні завантаження. Якщо вказані декілька секцій %firstboot, вони запустяться в порядку, в якому вони з’явилися у файлі kickstart.

Важливо! Семантика скриптів %firstboot не може бути перевірена, допоки система не завантажиться вперше. Скрипт %firstboot може містити потенційно катастрофічні помилки, що не проявлять себе до завершення установки.

Важливо! Скрипт %firstboot не запускається, якщо на ESXi-хості увімкнене захищене завантаження.

  • –interpreter

=[python|busybox] (Визначає інтерпретатора для використання. Дефолтним є busybox).

Підготовка до скриптованої інсталяції ESXi з мережевим завантаженням інсталятора

Можна використовувати preboot execution environment (PXE) для завантаження ESXi-хоста з мережевого пристрою, якщо хост використовує застарілий BIOS чи UEFI. Альтернативно, якщо хост підтримує нативний UEFI HTTP, можна скористатися hypertext transfer protocol (HTTP) для завантаження хоста з мережевого пристрою – витягти файли інсталятора й завантажити їх по мережевому інтерфейсу.

PXE використовує Dynamic Host Configuration Protocol (DHCP) та Trivial File Transfer Protocol (TFTP) для завантаження ОС мережею. PXE-завантаження вимагає певної мережевої інфраструктури та машини з PXE-сумісним мережевим адаптером. Більшість машин, що здатні запускати ESXi, мають мережеві адаптери, спроможні на PXE-завантаження.

Нативні UEFI HTTP використовують DHCP та HTTP для завантаження по мережі, вимагають мережевої інфраструктури, версії мікропрограми UEFI на хості ESXi, яка включає функцію завантаження HTTP та мережевого адаптера, що підтримує роботу в мережі UEFI. Завантаження по HTTP є швидшим та надійнішим, порівняно з TFTP, через можливості протоколу TCP, що лежить в основі HTTP, як-от вбудована потокова передача та відновлення втрачених пакетів. Якщо хости ESXi не підтримують нативний UEFI HTTP, можна використовувати iPXE HTTP для процесу завантаження.

Важливо! Мережеве завантаження з застарілим BIOS можливе лише по IPv4. Мережеве завантаження з UEFI BIOS можливе як по IPv4, так і по IPv6.

Для того, щоб інсталяція пішла, спочатку завантажується цільовий хост, він взаємодіє з різними серверами в середовищі, щоб отримати мережевий адаптер, завантажувач, ядро, IP-адресу для ядра і, нарешті, інсталяційний скрипт:

Взаємодія ESXi-хоста з іншими серверами відбувається наступним чином:

  1. Користувач завантажує цільовий ESXi-хост;
  2. Цільовий ESXi-хост робить DHCP-запит;
  3. DHCP-сервер відповідає з IP-інформацією, локацією TFTP/HTTP-сервера, іменем файла чи URL початкового мережевого завантажувача;
  4. ESXi-хост контактує з TFTP/HTTP-сервером і запитує ім’я файлу чи URL, вказані DHCP-сервером;
  5. TFTP/HTTP-сервер надсилає мережевий завантажувач, і ESXi-хост його запускає. Початковий завантажувач може підвантажити додаткові компоненти з серверу;
  6. Завантажувач шукає конфігураційний файл на TFTP/HTTP-сервері, завантажує ядро та інші компоненти ESXi, що вказані в конфігураційному файлі, і завантажує ядро на ESXi-хост;
  7. Інсталятор запускається інтерактивно чи з використанням скрипту kickstart – так, як вказано в конфігураційному файлі.

Зауваження. Трошки зупинимося на теорії щодо згаданих протоколів, служб та технологій – глибоке розуміння процесів мережевого завантаження стане в нагоді в майбутньому, коли будете займатися траблшутінгом. Звичайно, якщо те, про що далі піде мова, для вас не надто знайоме.

TFTP Server. Trivial File Transfer Protocol (TFTP) схожий на FTP-сервіс, і зазвичай використовується тільки для систем мережевого завантаження чи завантаження мікропрограм на мережевих пристроях, наприклад, на роутерах. Доступний на Linux та Windows.

SYSLINUX та PXELINUX. При використанні PXE в застарілому BIOS-середовищі потрібно розуміти різні середовища завантаження. SYSLINUX – це open-source середовище завантаження для машин з застарілим BIOS. Завантажувач ESXi для BIOS-систем («mboot.c32»)  запускається як плагін SYSLINUX. Можна налаштувати SYSLINUX для завантаження з різних типів медіа, включно з диском, ISO-образом та мережею. Завантажити можна звідси. PXELINUX – це конфігурація SYSXLINUX для завантаження з TFTP-сервера, відповідно до PXE-стандарту. При використанні PXELINUX для завантаження ESXi-інсталятора бінарний файл «pxelinux.0», «mboot.c32», конфігураційний файл, ядро та інші файли переносяться за допомогою TFTP.

iPXE. iPXE – це open-source ПО, що надає імплементацію HTTP. Може використовуватися для початкового завантаження. Більше почитати про нього можна отут. До речі, VMware включила iPXE як частину Auto Deploy (будемо розглядати нижче у відповідному розділі про інсталяцію хоста через Auto Deploy).

UEFI PXE та UEFI HTTP. Більшість мікропрограм UEFI нативно містять підтримку PXE, яка дозволяє завантаження з TFTP-сервера. Мікро-ПО можна напряму завантажувати завантажувач ESXi для UEFI («mboot.efi»). Додаткове ПО, на кшталт PXELINUX, не потрібне. Деякі мікропрограми UEFI підтримують нативне завантаження UEFI HTTP (починаючи з версії 2.5). Це ПО може завантажити завантажувач ESXi з HTTP-сервера, не вимагаючи додаткового софта, на кшталт iPXE.

Альтернативно, дістатися до різного завантажувального мережевого ПО на різних хостах можна через:

  • Налаштування DHCP-сервера для надання різноманітних початкових імен файлів завантажувачів різним хостам, залежно від MAC-адреси чи інших критеріїв. Подробиці можна знайти в документації по DCHP-серверам.
  • Шлях використання iPXE як початкового завантажувача з файлом конфігурації iPXE, який обирає наступного завантажувача, спираючись на MAC-адресу або інший критерій.

Якщо плануємо використовувати TFTP-сервер для PXE-завантаження інсталятора ESXi, процедура буде відрізнятися, в залежності від того, чи працюємо з UEFI, чи з застарілим BIOS. В другому випадку один і той самий початковий завантажувач для всіх цільових машин «pxelinux.0» використовується для завантаження множини різних версій ESXi-інсталятора. Але потенційно різні конфігураційні файли PXELINUX залежать від MAC-адреси цільової машини. Для UEFI-машин процедура підтримує різноманітні версії інсталятора ESXi шляхом використання однакового початкового завантажувача «mboot.efi» для всіх цільових машин, але потенційно різні файли «boot.cfg» залежать від MAC-адреси цільової машини.

До того, як розпочати завантаження потрібно підготувати:

  • ISO-образ інсталятора ESXi,
  • цільовий хост з конфігурацією апаратної частини, що підтримується версією ESXi,
  • мережевий адаптер з PXE-підтримкою на цільовому хості ESXi,
  • DHCP-сервер, щоб можна було налаштувати PXE-завантаження,
  • TFTP-сервер,
  • політики мережевої безпеки, що дозволяють TFTP-трафік (UDP порт 69),
  • інсталяційний скрипт (файл kickstart).

Важливо! Використовуйте нативні VLAN в більшості випадків. Якщо прагнете вказати VLAN ID, щоб використовувався в PXE-завантаженні, перевірте, чи підтримує ваш NIC специфікацію VLAN ID.

Сама процедура виглядає так:

  1. У випадку BIOS, отримуємо та налаштовуємо PXELINUX. Отримуємо SYSLINUX86, розпаковуємо та копіюємо файл «pxelinux.0» на верхній рівень директорії «tftpboot» на TFTP-сервері. Створюємо конфігураційний файл PXELINUX за такою моделлю коду:

DEFAULT install

NOHALT 1

LABEL install

KERNEL ESXi-8.x.x-XXXXXX/mboot.c32

APPEND -c ESXi-8.x.x-XXXXXX/boot.cfg

IPAPPEND 2

де «ESXi-8.x.x-XXXXXX» – ім’я піддиректорії TFTP, що містить файли інсталятора ESXi

Зберігаємо файл PXELINUX в директорії «/tftpboot/pxelinux.cfg» на TFTP-сервері з ім’ям, що визначить, чи всі хости завантажать цей інсталятор за замовчуванням. Рекомендується вживати «default», якщо всі хости мають користуватися цим інсталятором, або називати його за MAC-адресою цільової машини хоста, якщо хочемо, щоб конкретний хост завантажував цей файл («01- mac_address_of_target_ESXi_host»).

  1. За наявністю UEFI, копіюємо файл «efi/boot/bootxefi» з ISO-образу ESXi-інсталятора в папку «/tftpboot» на TFTP-сервері й перейменовуємо його на «mboot.efi»;
  2. Налаштовуємо DHCP-сервер;
  3. Створюємо піддиректорію директорії верхнього рівня «/tftpboot» на TFTP-сервері й називаємо її за версією ESXi (наприклад, «/tftpboot/ESXi-8.x.x-xxxxx»);
  4. Копіюємо вміст образу ESXi-інсталятора в новостворену директорію;
  5. Редагуємо файл «boot.cfg». Додаємо строку:

prefix=ESXi-8.x.x-xxxxxx

де «ESXi-8.x.x-xxxxxx» – то є шлях до інсталяційних файлів відносно кореневого каталога сервера TFTP.

Якщо імена файлів в рядках «kernel=» та «modules=» починаються з символа «/», видаляємо цей символ.

Якщо рядок «kernelopt=» містить строку «cdromBoot», видаляємо її;

  1. Якщо будемо працювати зі скриптованою інсталяцією, у файлі «boot.cfg» додаємо параметр «kernelopt» до рядка після команди ядра, щоб вказати локацію інсталяційного скрипта, вигляду:

kernelopt=ks=http://XXX.XXX.XXX.XXX/esxi_ksFiles/ks.cfg

де «XXX.XXX.XXX.XXX» – IP-адреса сервера, де розташований інсталяційний скрипт, а «esxi_ksFiles» – директорія, в якій міститься файл «ks.cfg»;

  1. Для хостів ESXi з UEFI вказуємо, чи хочемо, щоб усі хости завантажували однаковий інсталятор. Якщо так, то копіюємо чи лінкуємо файл «boot.cfg» в «/tftpboot/boot.cfg». Якщо різні хости мають користатися різними інсталяторами, поміщаємо копію (чи посилання) на файл хоста «boot.cfg» в ту директорію, наприклад, «/tftpboot/01-23-45-67-89-0a-bc/boot.cfg».

Якщо плануємо завантаження ESXi-інсталятора за допомогою iPXE та HTTP, підготовчі дії, окрім всього того, що стосується TFTP-сервера для PXE-завантаження, мають включати такі кроки:

  • перевірку, чи доступний HTTP-сервер з цільових ESXi-хостів,
  • отримання пакету SYSLINUX версії 3.86, якщо ESXi-хост запускається на застарілому BIOS.

Далі порядок дій:

  1. Отримуємо на налаштовуємо iPXE – на сторінці завантаження iPXE будуть інструкції, за якими йдемо, проте, в разі BIOS запускаємо «make bin/undionly.kpxe», а для UEFI – «make bin-x86_64-efi/snponly.efi». Копіюємо файл «undionly.kpxe» чи «snponly.efi» в каталог «/tftpboot» на TFTP-сервері;
  2. Якщо BIOS, отримуємо та налаштовуємо PXELINUX. Отримуємо SYSLINUX версії 3.86 і копіюємо файл «pxelinux.0» в каталог «/tftpboot» на TFTP-сервері. Створюємо конфігураційний файл наступного вигляду:

DEFAULT install

NOHALT 1

LABEL install

KERNEL ESXi-8.x.x-XXXXXX/mboot.c32

APPEND -c ESXi-8.x.x-XXXXXX/boot.cfg

IPAPPEND 2

де «ESXi-8.x.x-XXXXXX» – це ім’я піддиректорії TFTP, що містить файли інсталятора ESXi. Зберігаємо цей файл в директорії «/tftpboot/pxelinux.cfg» на TFTP-сервері. Ім’я файлу має позначати, чи всі хости будуть його використовувати за замовчуванням (називаємо «default», якщо так, якщо ж тільки вказані хости – то «01- mac_address_of_target_ESXi_host», за МАС-адресою відповідного хоста).

  1. Для UEFI копіюємо файл «efi/boot/bootxefi» з образу інсталятора в папку «/tftpboot» на TFTP-сервері і перейменовуємо його на «mboot.efi»;
  2. Налаштовуємо DHCP-сервер;
  3. Створюємо директорію на HTTP-сервері з таким самим ім’ям як версія ESXi у ній:

/var/www/html/ESXi-8.x.x-XXXXXX

  1. Копіюємо вміст образу в новостворену директорію;
  2. Редагуємо файл «boot.cfg». Додаємо строку:

prefix=http://XXX.XXX.XXX.XXX/ESXi-8.x.x-XXXXXX

де «http://XXX.XXX.XXX.XXX/ESXi-8.x.x-XXXXXX» – це локація, де знаходяться файли інсталятора на HTTP-сервері.

Якщо імена файлів в рядках «kernel=» та «modules=» починаються зі «/», видаляємо цей символ. Якщо рядок «kernelopt=» містить строку «cdromBoot», видаляємо її;

  1. Для скриптованої інсталяції в файлі «boot.cfg» додаємо параметр «kernelopt» в рядок після команди ядра, щоб вказати локацію інсталяційного скрипта, вигляду:

kernelopt=ks=http://XXX.XXX.XXX.XXX/esxi_ksFiles/ks.cfg

де «XXX.XXX.XXX.XXX» – це ІР-адреса сервера, де знаходиться інсталяційний скрипт, а «esxi_ksFiles» – то є каталог, що містить файл «ks.cfg».

  1. Для UEFI вказуємо, чи хочемо, щоб усі хости завантажували один і той самий інсталятор. Якщо так, копіюємо чи лінкуємо файл «boot.cfg» у «/tftpboot/boot.cfg». Якщо ні, створюємо піддиректорію «/tftpboot», названу за МАС-адресою цільової машини хоста (01-mac_address_of_target_ESXi_host), а потім копіюємо чи лінкуємо файл хоста «boot.cfg» в цю директорію, наприклад, «/tftpboot/01-23-45-67-89-0a-bc/boot.cfg».

Якщо плануємо завантаження за допомогою нативного UEFI HTTP, підготовчі роботи виглядають так само, як для TFTP. Сама ж процедура при цьому:

  1. Копіюємо файл «efi/boot/bootxefi» з образу інсталятора в директорію на HTTP-сервері та перейменовуємо його на «mboot.efi»;
  2. Налаштовуємо DHCP-сервер;
  3. Створюємо директорію на HTTP-сервері з ім’ям, що співпадає з версією ESXi, яку він містить. Наприклад, «http://www.example.com/esxi/ESXi-8.x.x-XXXXXX»;
  4. Копіюємо вміст образу інсталятора в новостворену директорію;
  5. Редагуємо файл «boot.cfg». Додаємо строку з URL новоствореної директорії:

prefix=http://www.example.com/esxi/ESXi-8.x.x-XXXXXX

Якщо імена файлів в рядках «kernel=» та «modules=» починаються з «/», видаляємо цей символ. Якщо рядок «kernelopt=» містить строку «cdromBoot», видаляємо її;

  1. Для скриптованої інсталяції у файлі «boot.cfg» додаємо параметр «kernelopt» до рядка після команди ядра, щоб вказати локацію інсталяційного скрипта. Наприклад,

kernelopt=ks=http://www.example.com/esxi_ksFiles/ks.cfg

  1. Опціонально, можна користуватися конфігураційними параметрами ВМ «networkBootProtocol» та «networkBootUri», щоб вказати, звідки ВМ може завантажуватися. Перший параметр вказує на протокол завантаження, наприклад, «IPv4» чи «IPv6». Другий вказує HTTP URL для завантажувача ESXi («bootxefi»). Наприклад, «networkBootUri = http://xxx.xxx.xx.x/ esxi80uc1/efi/boot/bootx64.efi».
  2. Вказуємо, чи хочемо, щоб усі хости завантажувалися з одного й того ж інсталятора. Якщо так, додаємо файл «boot.cfg» до тієї ж директорії, де є «mboot.efi». Наприклад, до «http://www.example.com/esxi/boot.cfg». Якщо ні, створюємо піддиректорію директорії, що містить файл «mboot.efi». Називатися вона має за МАС-адресою машини цільового хоста («01-mac_address_of_target_ESXi_host»), і додаємо власний файл «boot.cfg» в директорію, наприклад, «http://www.example.com/esxi/01-23-45-67-89-0a-bc/boot.cfg».

Приклади конфігурування DHCP для різних сценаріїв завантаження по мережі ми наводили в статті «Обновляем ESXi до версии 7.0U2» – можете сміливо ними користуватися, з тих часів нічого не змінилося в цьому сенсі.

Підготовка до інсталяції ESXi через vSphere Auto Deploy

vSphere Auto Deploy дозволяє готувати сотні фізичних хостів з софтом ESXi, вказавши образ, що має розгорнутися. У цьому випадку хости завантажуються по мережі з центрального сервера Auto Deploy (стан не зберігається на самому хості – сервер Auto Deploy керує інформацією про стан для кожного хоста), але опціонально вони можуть налаштовуватися за профілем хоста, про створення якого ми говорили вище, а також розгортатися за призначеним пакетом скрипта для кожного хоста. Після підвантаження та налаштування такі хости керуються vCenter Server аналогічно іншим ESXi-хостам.

Важливо! Auto Deploy вимагає безпечного розділу production-мережі та керуючої, або мережі розгортання.

Інформація для ESXi-хостів, що готуються, яку зберігає vSphere Auto Deploy, – це місцезнаходження профілів образів, профілів хостів чи кластерів, що керуються одним образом, або конфігурації на рівні кластера, і початково вона вказана в правилах, що співставляють машини профілям образів та профілям хостів. Архітектура vSphere Auto Deploy:

Правила та набори правил визначають поведінку сервера Auto Deploy. Механізм правил перевіряє шаблони хостів, щоби вирішити, з якими об’єктами (профіль образу, профіль хосту, локація vCenter Server, скриптований об’єкт) має надаватися хост. Для хостів, що ще не додані в систему vCenter Server, сервер vSphere Auto Deploy перевіряє механізм правил до обслуговування профілів образів, профілів хостів та інформації щодо локації. Для хостів, що управляються системою vCenter Server, ці об’єкти зберігаються на vCenter Server. Якщо в правила вносяться зміни, за допомогою vSphere Client або cmdlet vSphere Auto Deploy в сесії PowerCLI можна протестувати та виправити відповідність правил. При цьому призначення профілю образу хоста та профіль хоста оновляться. У правилах можна визначати наступні параметри:

Параметр Опис
Name Ім’я правила, позначається з параметром «-Name»
Item Один або більше об’єктів з параметром «Item», які є профілем образу, профілем хоста, локацією інвентаря vCenter Server (датацентр, папка, кластер) для цільового хоста, чи користувацьким скриптом. Множина об’єктів відділяється комами
Template Вказує на хост чи групу хостів, для яких діють правила:

vendor (ім’я вендора машини)

model (назва моделі машини)

serial (серійний номер машини)

hostname (ім’я хоста)

domain (ім’я домену)

ipv4 (IPv4-адреса машини)

ipv6 (IPv6-адреса машини. Якщо в нас PXE-завантаження з BIOS – тільки IPv4. Якщо з UEFI – можна або те, або те)

mac (завантаження MAC-адреси NIC)

asset (тег об’єкту машини)

oemstring (специфічні рядки OEM у SMBIOS)

Зауваження. Якщо в шаблоні вказати «-AllHosts», об’єкт(и) буде застосовуватися до всіх хостів.

Щодо наборів правил існують два поняття: активні та робочі. Активні набори перевіряються сервером vSphere Auto Deploy на предмет співпадіння, коли вперше запущений хост контактує з сервером vSphere Auto Deploy шляхом запиту на профіль образу. Якщо правилами співставлено більше одного об’єкту спільного типу, сервер vSphere Auto Deploy застосовує перший об’єкт в наборі правил. Робочі ж набори правил дозволяють протестувати зміни до правил до того, як вони стануть активними. Щоб створити такий набор правил, треба додати правило з параметром «NoActivate».

Порядок дій з правилами та наборами правил:

  1. Робимо зміни в робочий набор правил;
  2. Тестуємо його щодо хоста, щоб впевнитися, що все працює коректно;
  3. Вдосконалюємо та повторно тестуємо правила в робочому наборі правил;
  4. Активуємо правила в робочому наборі.

Докладно операції з правилами розглянемо трохи нижче.

Інсталяція та налаштування vSphere Auto Deploy

Перед інсталяцією vSphere Auto Deploy треба зробити певну підготовку:

  • Увімкнути та запустити сервіс vSphere Auto Deploy на системі vCenter Server;
  • Підготувати сховище таким чином, щоб воно могло виявити LUN (мати список цільових IP-адрес та інформацію про цільовий том для NFS чи iSCSI). Сховище має бути не меншим 2Гб;
  • Записати інформацію щодо хоста (список цільових IP-адрес та інформацію про цільовий том для NFS чи iSCSI, дефолтний маршрут, маску мережі, IP-адреси первинного та вторинного DNS-серверу, IP-адреси та маску мережі для первинної керуючої мережі VMkernel, IP-адреси та маску мережі для інших мереж VMkernel – сховища, vSphere FT чи VMware vMotion тощо)

Важливо! vSphere Auto Deploy за замовчуванням не перезаписує існуючі партиції.

  • Проінсталювати PowerCLI (якщо будемо працювати не через клієнт vSphere), що включає cmdlet vSphere Auto Deploy та vSphere ESXi Image Builder;
  • Записати місцезнаходження сховища ПО ESXi (URL з веб-сайту VMware), або завантажити ZIP-файл для роботи з локальним сховищем. Сам образ ESXi завантажувати не треба!
  • Підготувати TFTP, DHCP та DNS сервери (останній з доданими записами і в пряму (A Record), і в зворотну (PTR Record) зони для кожного цільового хоста), й переконатися, що до всіх серверів є мережеве підключення. Замінити ім’я файлу «gpxelinux.0» на «snponlyefi.vmw-hardwired» для UEFI, чи на «undionly.kpxe.vmw-hardwired» для BIOS на DHCP;

Важливо! Переконайтесь, що окрім потрібних нам, інших серверів DHCP, DNS чи TFTP в їх підмережі не існує.

  • Підготувати дані щодо привілеїв адміністратора для ключових серверів середовища;
  • Встановити віддалений Syslog-сервер. Налаштувати перший завантажуваний хост на його використання та застосувати профіль цього хоста для всіх інших цільових хостів. Опціонально можна проінсталювати vSphere Syslog Collector;
  • Проінсталювати ESXi Dump Collector, налаштувати перший хост таким чином, щоб всі дампи ядра спрямовувалися на нього, та застосувати профіль хоста до всіх інших хостів.

Сама ж інсталяція vSphere Auto Deploy виглядає так:

  1. Проходимо в Home > Auto Deploy;
  2. На сторінці Auto Deploy обираємо наш vCenter Server з розкривного меню зверху;
  3. Клікаємо на Enable Auto Deploy and Image Builder, щоб активувати сервіс. Якщо сервіс Image Builder вже є активним, обираємо вкладку Configure та натискаємо Enable Auto Deploy Service – з’явиться сторінка Software Depot;
  4. Налаштовуємо TFTP-сервер: клікаємо на вкладку Configure, а потім – на Download TFTP Boot Zip, щоб завантажити конфігураційний файл та розпакувати його в директорію, де зберігає файли TFTP-сервер, далі, якщо хочемо використовувати проксі-сервер, на панелі Auto Deploy Runtime Summary тиснемо на Add та вводимо URL проксі-серверу в текстове поле. Зауважте, що використання зворотних проксі-серверів може розвантажити запити, що робить сервер vSphere Auto Deploy;
  5. Налаштовуємо DHCP-сервер, щоб він вказував на TFTP-сервер: вказуємо IP-адресу TFTP-серверу в опції 66 (часто називають «наступний сервер») DHCP, та вказуємо ім’я файлу завантажувача («snponlyefi.vmw-hardwired» для UEFI чи «undionly.kpxe.vmw-hardwired» для BIOS) в опції 67 DHCP (часто знана як «bootfilename»);
  6. Налаштовуємо кожен хост, який хочемо розгорнути з vSphere Auto Deploy, на мережеве завантаження чи PXE-завантаження, користуючись інструкціями виробника;
  7. Опціонально, можна налаштувати наше середовище на використання режиму відтиску (Thumbprint mode), і тоді можна скористатися власним Certificate Authority (CA), замістив OpenSSL сертифікат «rbd-ca.crt» та OpenSSL приватний ключ «rbd-ca.key» власними. Файли можна знайти в «/etc/vmware-rbd/ssl/». За дефолтом, vCenter Server використовує VMware Certificate Authority (VMCA).

Далі вже можна змінювати дефолтну конфігурацію Auto Deploy Service, конфігураційні властивості, за замовчуванням, Image Builder Service (розповідали вище), визначатися з правилами, що будуть назначатися профілю образу та, опціонально, профілю хоста, з його локацією чи пакетом скрипта для нього. Також, за бажанням, можна налаштувати перший хост, який плануємо представляти в якості референсного, далі профіль хоста і т. д.

Використання cmdlet vSphere Auto Deploy

vSphere Auto Deploy використовує cmdlet так само, як й інші cmdlet PowerShell. Досвідчені користувачі оболонки можуть пересвідчитися у всіх перевагах цього методу роботи з vSphere Auto Deploy, проте, слід зазначити, що у колах віртуалізаторів це вважається фігурою вищого пілотування. Але незважаючи на рівень володіння, не зайвим буде нагадати перед тим, як перейдемо до практики налаштування та використання vSphere Auto Deploy з cmdlet, деякі важливі загальні поради й моменти:

  • Підказку за будь-яким cmdlet можна отримати, запустивши:

Get-Help cmdlet_name

  • Для PowerShell байдужий регістр літер;
  • Використовуйте завершення табуляції для імен командлетів та імен параметрів;
  • Форматуйте будь-яку змінну та вивід cmdlet за допомогою «Format-List» чи «Format-Table», або інших коротких форм «fl» чи «ft». Допомогу з форматування можна отримати, запустивши cmdlet:

Get-Help Format-List

Загалом, cmdlet PowerCLI керують vSphere Auto Deploy, допомагаючи створювати правила, що асоціюють хости з профілями образів, профілями хостів, користувацькими скриптами та локаціями на цілі vCenter Server. З ними також можна оновлювати хости шляхом тестування відповідності правил та виправляти проблеми невідповідності.

Перед тим, як розглянути конкретику операцій, нагадаємо, що список підготовчих кроків з «Інсталяції та налаштування vSphere Auto Deploy», наведений вище, є актуальним, звісно ж, і тут. І запускаємо сесію PowerCLI, підключившись до системи vCenter Server, з якою зареєстрований vSphere Auto Deploy.

Написання правила за допомогою командлетів PowerCLI для vSphere Auto Deploy

Підготовка правил передує їх призначенню профілям образів та профілям хостів, і, власне, безпосередньому розгортанню хостів ESXi за допомогою vSphere Auto Deploy. Для них використовуються наступні cmdlet:

Get-DeployCommand – повертає список командлетів vSphere Auto Deploy

New-DeployRule – створює нове правило з вказаними об’єктами та шаблонами

Set-DeployRule – оновлює існуюче правило з вказаними об’єктами і шаблонами. Не можна оновлювати правило, що є частиною набору правил

Get-DeployRule – повертає правила з вказаними іменами

Copy-DeployRule – клонує та оновлює існуюче правило

Add-DeployRule – додає одне чи більше правил до робочого набору правил і, за замовчуванням, також до активного набору правил. Якщо треба додати правило лише до робочого набору, використовуйте параметр «NoActivate»

Remove-DeployRule – видаляє одне або більше правил з робочого набору правил та з активного набору. Щоб повністю знищити правило, запустіть цю команду з параметром «Delete»

Set-DeployRuleset – явно встановлює список правил в набір робочих правил

Get-DeployRuleset – повертає поточний робочий набір правил чи поточний активний набір правил

Switch-ActiveDeployRuleset  – активує набір правил, щоб будь-які нові запити оцінювалися через нього

Get-VMHostMatchingRules – повертає правила, що відповідають шаблонові. Використовується, здебільшого, для дебаггінгу

Test-DeployRulesetCompliance – перевіряє, чи демонструють об’єкти, асоційовані з вказаним хостом, відповідність до активного набору правил

Repair-DeployRulesetCompliance – дає вивід Test-DeployRulesetCompliance, цей cmdlet оновлює профіль образу, профіль хосту та локацію для кожного хоста в інвентарі vCenter Server. Цей cmdlet може застосовуватися до профілів образів, профілів хосту чи переміщати хости до наперед вказаних папок чи кластерів у системі vCenter Server

Apply-EsxImageProfile – асоціює вказаний профіль образу з вказаним хостом

Get-VMHostImageProfile – повертає профіль образу, що використовується вказаним хостом. Цей cmdlet відрізняється від Get-EsxImageProfile cmdlet у vSphere ESXi Image Builder

Repair-DeployImageCache – використовуйте цей cmdlet тільки, якщо кеш образу vSphere Auto Deploy був випадково видалений

Get-VMHostAttributes – повертає атрибути для хоста, що використовується, коли vSphere Auto Deploy server оцінює правила

Get-DeployMachineIdentity – повертає значення рядку, яке vSphere Auto Deploy використовує, щоб локально зв’язати ESXi-хост в vCenter Server з фізичною машиною

Set-DeployMachineIdentity – логічним чином зв’язує об’єкт хоста в БД vCenter Server з фізичною машиною. Використовується для додавання хостів без вказаних правил

Get-DeployOption – повертає глобальні параметри конфігурації vSphere Auto Deploy. Цей cmdlet в даний час підтримує параметр vlan-id, що вказує дефолтний VLAN ID для ESXi Management Network хоста, підготовленого vSphere Auto Deploy. vSphere Auto Deploy використовує значення, тільки якщо хост завантажується без профілю хоста

Set-DeployOption – встановлює значення глобального параметра конфігурації. На даний момент підтримує параметр vlan-id для встановлення дефолтного VLAN ID для ESXi Management Network

Add-ProxyServer – додає проксі-сервер до БД vSphere Auto Deploy. Команда запускається з параметром «-Address», щоб вказати IPv4 чи IPv6 адресу. Адреса може включати номер порту

List-ProxyServer – виводить список проксі-серверів, що у цей час є зареєстрованими з vSphere Auto Deploy

Delete-ProxyServer – видаляє один або більше проксі-серверів зі списку проксі-серверів, що є зареєстрованими з vSphere Auto Deploy. Можна запускати команду з параметром «-id» зі списком проксі-серверів чи з параметром «-Address» шляхом вказання IPv4 чи IPv6 адреси проксі-сервера, який бажаємо видалити

Add-ScriptBundle – додає один або більше пакетів скриптів до сервера vSphere Auto Deploy

Get-ScriptBundle – повертає список пакетів скриптів, доступних на сервері vSphere Auto Deploy, та скриптів, що містяться в них

Remove-ScriptBundle – видаляє пакет скрипта з vSphere Auto Deploy. Працює для vSphere 6.7 й свіжіших

Get-CustomCertificate – повертає користувацький сертифікат хоста, підвантажений в AutoDeploy. Потрібно запускати команду з параметром «HostId [MAC_Address | BIOS_UUID]». Коли ми вперше додаємо користувацькі сертифікати, ми не бачимо жодних повернених цим командлетом сертифікатів

List-CustomCertificates – повертає інформацію про всі користувацькі сертифікати хоста, що використовуються Auto Deploy. Список надає дані щодо імені сертифікату, Host ID та Associated Host Name, що відображає ім’я vCenter Server для серверу AutoDeploy

Add-CustomCertificate – додає користувацький сертифікат до VMware Endpoint Certificate Store й асоціює його з хостом ESXi. Сертифікат стає активним після перезавантаження хоста. Можна скористатися Get-CustomCertificate cmdlet для повернення користувацького ключа сертифікату хоста. Можна запускати команду з параметром «HostId [MAC_Address | BIOS_UUID]», щоб асоціювати сертифікат з хостом, вказавши «Key [file:///path/to/key.key]» та «Cert [file:///path/to/cert.crt]». Використання цього cmdlet вимагає привілеїв AutoDeploy.Rule.Create на кореневій папці vCenter Server.

Remove-CustomCertificate – видаляє набір користувацьких сертифікатів хоста з Auto Deploy. Записи сертифіката видаляються з БД й файли сертифікатів видаляються з файлового сховища. Хости, що вже були завантажені з користувацьким сертифікатом, мають перезавантажитися, щоб отримати новий сертифікат. Потрібно надати, мінімум, один з параметрів «-Cert» чи «HostId». Використання цього cmdlet вимагає привілеїв AutoDeploy.Rule.Create на кореневій папці vCenter Server.

Написання правила і призначення профілю образа хостам

До того, як вдатися до безпосереднього надання хоста, нам потрібно, обов’язково, створити правила й призначити їх профілю образу – для кожного хоста, що має готуватися за допомогою vSphere Auto Deploy.

Зауваження. Правила розширення vSphere Auto Deploy змушують VIB рівня CommunitySupported містити лише файли з певних попередньо визначених місць, таких як шлях плагіна ESXCLI, шлях плагіна jumpstart тощо. Якщо до профілю образу додається VIB з іншої локації, побачимо попередження. Його можна скасувати примусово. Якщо викликається командлет New-DeployRule на профілі образу, що містить VIB з рівня CommunitySupported, що порушує правило, можна прописати «$DeployNoSignatureCheck = $true» до того, як додається профіль образу. Тоді система буде ігнорувати перевірку підпису та не вдасться до перевірки правил розширення. Проте, треба пам’ятати, що такі VIB, у будь-якому випадку, не підтримуються продуктивами.

На практиці наші дії виглядатимуть так:

  1. В сесії PowerCLI, щоб підключитися до системи vCenter Server, з якою зареєстрований наш vSphere Auto Deploy, запускаємо:

Connect-VIServer ipv4_or_ipv6_address

Cmdlet може повернути попередження сервера сертифікатів;

  1. Визначаємось з місцем публічного сховища софта, чи визначаємо користувацький профіль образу за участю vSphere ESXi Image Builder (див. вище);
  2. Якщо в нас профіль образу міститься у віддаленому сховищі, вводимо:

Add-EsxSoftwareDepot depot_url

Якщо це ZIP-файл, завантажуємо його, записуємо його локальний шлях й вводимо:

Add-EsxSoftwareDepot C:\file_path\my_offline_depot.zip

  1. У сховищі знаходимо профіль образу, який хочемо використовувати, запустивши cmdlet «EsxImageProfile». За замовчуванням, ESXi-сховище включає один базований профіль образу, що містить VMware tools та має строку «standard» у своєму імені, та один базований профіль образу, що не містить VMware tools;
  2. Визначаємо правило, в якому хости з певними атрибутами, наприклад, з діапазоном IP-адрес, призначаються профілю образу:

New-DeployRule -Name “testrule” -Item “My Profile25” -Pattern “vendor=Acme,Zven”, “ipv4=192.XXX.1.10-192.XXX.1.20”

Подвійні лапки вимагаються, якщо ім’я містить пробіли, необов’язкові в іншому випадку. Вказуємо «AllHosts» замість шаблону, щоб застосувати об’єкт до всіх хостів. Cmdlet створить правило, назване «testrule». Воно буде призначене профілям образу, названим My Profile25, всім хостам з вендором Acme чи Zven, що також мають IP-адреси з визначеного діапазону – як прописано в команді;

  1. Додаємо правило в набір правил:

Add-DeployRule testrule

За замовчуванням правило додане і до робочого набору правил, і до активного. Якщо застосувати параметр «NoActivate», робочий набір не стане активним.

Написання правила та призначення профілю хоста хостам

vSphere Auto Deploy може призначати профіль хоста одному й більшій кількості хостів. Профіль хоста має включати інформацію щодо конфігурації сховища, мережевої конфігурації, чи інші характеристики хоста. Коли хост додається до кластеру, застосовується профіль хоста кластера. Проте, в багатьох випадках зручніше призначити хост кластеру, аніж вказувати напряму профіль хоста. Спробуємо написати правило та призначити профіль хоста хостам:

  1. В сесії PowerCLI запускаємо командлет для підключення до системи vCenter Server, з якою зареєстрований vSphere Auto Deploy:

Connect-VIServer ipv4_or_ipv6_address

Cmdlet може повернути попередження щодо сертифікату сервера;

  1. Через клієнт vSphere встановлюємо хост з налаштуваннями, які хочемо, щоб застосовувалися до створення профілю хоста з цього хоста;
  2. Знаходимо ім’я профілю хоста, запустивши cmdlet «Get-VMhostProfile», передаючи у хості ESXi, на якому створюється профіль хоста;
  3. Визначаємо правило, в якому профілі хоста призначаються хостам з певними атрибутами, наприклад, діапазоном IP-адрес:

New-DeployRule -Name “testrule2” -Item my_host_profile -Pattern “vendor=Acme,Zven”, “ipv4=192.XXX.1.10-192.XXX.1.20”

Вказаний об’єкт призначено усім хостам з вказаними атрибутами. Цей приклад створює правило з іменем «testrule2», що назначає вказаний профіль хоста «my_host_profile» всім хостам з IP-адресами з діапазону та з виробником Acme чи Zven;

  1. Додаємо правило до набору правил:

Add-DeployRule testrule2

За замовчуванням, робочий набір правил стає активним, і будь-які зміни в наборі правил стають активними, коли ми додаємо правило. При використанні параметру «NoActivate» робочий набір не стане активним.

Написання правила та призначення хоста папці чи кластеру

vSphere Auto Deploy може призначити хост папці або кластеру. Коли хост завантажується, vSphere Auto Deploy додає його до вказаної локації на vCenter Server. Хости, призначені кластеру, успадковують профіль хоста кластера. Перед тим, як вдатися безпосередньо до написання правила та призначення хоста папці чи кластеру, треба пересвідчитися, що обрана папка міститься в дата-центрі чи в кластері. Призначити хост незалежній папці верхнього рівня неможливо. Далі:

  1. В сеансі PowerCLI запускаємо для підключення до системи vCenter Server, з якою зареєстрований vSphere Auto Deploy:

Connect-VIServer ipv4_or_ipv6_address

Cmdlet може повернути попередження сертифікату сервера;

  1. Визначаємо правило, за яким хости з певними атрибутами, наприклад, з діапазоном IP-адрес, призначені папці чи кластеру:

New-DeployRule -Name testrule3 -Item “my folder” -Pattern “vendor=Acme,Zven”, “ipv4=192.XXX.1.10-192.XXX.1.20”

Приклад передає в папці за іменем. Замість цього можна передавати в папці, кластері чи дата-центрі об’єкт, який отримано за командлетами «Get-Folder», «Get-Cluster» чи «Get-Datacenter»;

  1. Додаємо правило до набору правил:

Add-DeployRule testrule3

За замовчуванням, робочий набір правил стає активним, і будь-які зміни до набору правил стають активними, коли додаємо правило. Якщо застосувати параметр «NoActivate», робочий набір правил не стане активним.

Тестування та відновлення відповідності правила після його модифікації

Коли ми додаємо правило до набору правил vSphere Auto Deploy, чи змінюємо одне або більше з них, хости автоматично не оновлюються. vSphere Auto Deploy застосовує нові правила тільки, коли ми тестуємо їх відповідність та виконуємо виправлення. Розглянемо, як це робиться:

  1. В сесії PowerCLI запускаємо для підключення до системи vCenter Server, з якою зареєстрований наш vSphere Auto Deploy:

Connect-VIServer ipv4_or_ipv6_address

Cmdlet може повернути попередження сертифікату серверу;

  1. Перевіряємо, котрі з правил vSphere Auto Deploy наразі доступні:

Get-DeployRule

Система поверне правила та асоційовані з ними об’єкти та шаблони;

  1. Змінюємо одне або більше правил. Наприклад, міняємо профіль образу та ім’я правила:

Copy-DeployRule -DeployRule testrule -ReplaceItem MyNewProfile

Якщо правило вже додане до активного набору правил, редагувати його не можна. Натомість, можна скопіювати його та замістити об’єкт або шаблон у ньому так, як треба;

  1. Перевіряємо, чи маємо доступ до хоста, на якому хочемо протестувати відповідність набору правил:

Get-VMHost -Name MyEsxi42

  1. Запускаємо cmdlet, що тестує відповідність набору правил для хоста, та прив’язуємо значення, що повернулося, до змінної для подальшого використання:

$tr = Test-DeployRuleSetCompliance MyEsxi42

  1. Досліджуємо різницю між вмістом набору правил та конфігурацією хоста:

$tr.itemlist

Якщо хост відповідає активному набору правил, система поверне таблицю поточних та очікуваних об’єктів:

CurrentItem        ExpectedItem

———–               ————

My Profile 25      MyNewProfile

  1. Відновлюємо хост, щоб наступного разу, коли він завантажиться, використовував вже переглянутий набір правил:

Repair-DeployRuleSetCompliance $tr

Пакетне ліцензування через vSphere Auto Deploy у PowerCLI

Ліцензійні ключі можна назначати хостові при доданні його до системи vCenter Server, або в процесі керування хостом цією системою за допомогою vSphere Client. Коли ми говоримо про поодинокі випадки, це виправдана схема, проте, якщо в нас безліч хостів в системі, адекватніше було б розглядати використання пакетного ліцензування. Воно працює, насправді, для будь-яких хостів ESXi, проте найчастіше зустрічається у випадку надання хостів за допомогою vSphere Auto Deploy.

Як підготуватися до роботи з vSphere Auto Deploy та розгортати з нею купу хостів згадувалося вище у відповідних розділах.

Загалом, певний набір ліцензійних ключів може бути доданим до набору хостів. Самі ключі додаються в БД vCenter Server, і кожного разу, коли хост додається до системи чи перепідключається до неї, йому назначається ліцензійний ключ. Призначений через PowerCLI ліцензійний ключ вважається дефолтним, і коли неліцензований досі хост додається або перепідключається, йому призначається саме дефолтний ключ. Якщо ж хост ліцензований, він зберігає власний ключ.

Перед тим, як перейти безпосередньо до процедури пакетного ліцензування, треба буде ще дещо проробити:

  1. У сесії PowerCLI підключаємось до системи vCenter Server та прив’язуємо асоційований менеджер ліцензування до змінної:

Connect-VIServer -Server 192.XXX.X.XX -User username -Password password

$licenseDataManager = Get-LicenseDataManager

  1. Запускаємо cmdlet, що отримує дата-центр, в якому знаходяться хости, до яких хочемо застосувати функцію пакетного ліцензування:

$hostContainer = Get-Datacenter -Name Datacenter-X

Також можна запускати cmdlet, що отримує кластер (для ліцензування усіх хостів в кластері), чи папку з аналогічною метою;

  1. Створюємо об’єкт «LicenseData» та «LicenseKeyEntry», з асоційованим ID типу та ліцензійним ключем:

$licenseData = New-Object VMware.VimAutomation.License.Types.LicenseData

$licenseKeyEntry = New-Object Vmware.VimAutomation.License.Types.LicenseKeyEntry

$licenseKeyEntry.TypeId = “vmware-vsphere

$licenseKeyEntry.LicenseKey = “XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

  1. Асоціюємо атрибут «LicenseKeys» об’єкту «LicenseData» з об’єктом «LicenseKeyEntry»:

$licenseData.LicenseKeys += $licenseKeyEntry

  1. Оновлюємо дату ліцензії для дата-центра з об’єктом «LicenseData» та перевіряємо, чи асоційована ліцензія з контейнером хоста:

$licenseDataManager.UpdateAssociatedLicenseData($hostContainer.Uid, $licenseData)

$licenseDataManager.QueryAssociatedLicenseData($hostContainer.Uid)

  1. Готуємо один або більше хостів з vSphere Auto Deploy та назначаємо їм дата-центр чи кластер, яким призначили дату ліцензії.

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

Використання vSphere Client у підготовчих до роботи з vSphere Auto Deploy процесах

Користуватися клієнтом vSphere у всіх передуючих безпосередньому розгортанню хостів акціях за допомогою vSphere Auto Deploy значно простіше, аніж те, що ми тільки-но робили з командлетами. І саме такий шлях рекомендований тим, хто вперше стикається з такою необхідністю.

Створення правила розгортання та операції з ним з vSphere Client

У клієнті vSphere:

  1. Проходимо в Home > Auto Deploy;
  2. На вкладці Deploy Rules клікаємо New Deploy Rule – з’явиться помічник New Deploy Rule;
  3. На сторінці Name and hosts вводимо ім’я нового правила;
  4. Обираємо, чи хочемо застосувати правило до всіх хостів в інвентарі, чи тільки до тих, що відповідають певному шаблонові (можна обирати більше одного шаблону);
  5. На сторінці Configuration, опціонально, включаємо об’єкти до правила (кожен додасть нову сторінку до помічника): Host Location (додає хости, що відповідають критерію правила до вказаної локації), Image Profile (назначає профіль образу хостам, що відповідають критерію правила), Host Profile (назначають профіль хоста хостам, що відповідають критерію правила), Script Bundle (назначають пакет скрипта хосту, що відповідає критерію правила). Якщо ми це зробили:
    • На сторінці помічника Select host location обираємо дата-центр, папку чи кластер як локацію хоста для хостів, що відповідають правилу;
    • На сторінці Select image profile, скориставшись розкривним меню, обираємо сховище софта та профіль образу зі списку. Якщо бажаємо пропустити верифікацію рівня прийняття профілю образу, ставимо галочку в Skip image profile signature check;
    • На сторінці Select host profile обираємо профіль хоста зі списку;
    • На сторінці Select script bundle обираємо пакет скрипта зі списку;
  1. На сторінці Ready to complete перевіряємо підсумкову інформацію нового правила.

Усі новостворені правила будуть виведені списком на вкладці Deploy Rules. Їх можна редагувати, клонувати, активувати/деактивувати, змінювати порядок тощо.

Якщо нам потрібно створити ще декілька правил, найлегше буде склонувати вже існуюче правило, сконфігурувавши його, як потрібно:

  1. Проходимо в Home > Auto Deploy;
  2. На вкладці Deploy Rules обираємо правило зі списку та клікаємо Clone – з’явиться помічник Clone Deploy Rule;
  3. На сторінці Name and hosts вводимо ім’я нового правила;
  4. Обираємо, чи хочемо, щоб правило застосовувалося до всіх хостів в інвентарі, чи тільки до тих, що відповідають певному шаблону (можна обирати більше одного шаблона);
  5. На сторінці Configuration, опціонально, включаємо об’єкти до правила (перелік див. вище в процедурі створення нового правила);
  6. Якщо в нас є сторінка Select host location, можемо обрати локацію хостів, що відповідає правилу. Ставимо галочку в Same Host location, якщо хочемо зберегти поточну локацію хоста для склонованого правила. Або ставимо галочку в Browse for Host location, обираємо дата-центр, папку чи кластер локації хоста та клікаємо Next, якщо бажаємо обрати нову;
  7. Якщо в нас є сторінка Select image profile, можемо обрати профіль образу. Ставимо галочку в Same image profile, якщо не хочемо міняти профіль образу. Або ставимо галочку в Browse for Image Profile, обираємо сховище софта з розкривного меню, обираємо профіль образу зі списку (опціонально, якщо хочемо пропустити верифікацію рівня прийняття профілю образу, ставимо галочку в Skip image profile signature check), якщо хочемо призначити новий профіль образу обраним хостам;
  8. Якщо в нас є сторінка Select host profile, можемо обрати профіль хоста. Ставимо галочку в Same Host profile, якщо хочемо зберегти профіль хоста в склонованому правилі. Або ставимо галочку в Browse for Host Profile та обираємо профіль хоста зі списку, після чого клікаємо Next, якщо хочемо призначити новий профіль хоста обраним хостам;
  9. Якщо в нас є сторінка Select script bundle, можемо обрати пакет скрипта зі списку;
  10. На сторінці Ready to complete проглядаємо підсумкову інформацію для нового правила.

Відредагувати існуюче правило можна наступним чином:

  1. У Home > Auto Deploy на вкладці Deploy Rules обираємо правило, яке хочемо змінити, та натискаємо Edit – з’явиться діалогове вікно Edit Deploy Rule;
  2. Усе аналогічно п. 3 – 10 процедури клонування (див. вище).

Щодо операцій активації/деактивації правил, спершу зауважимо, що новостворене правило завжди спочатку буде в неактивному стані – щоб воно почало діяти, його, звісно ж, треба активувати (за наведеною нижче процедурою робиться також й деактивація або зміна порядку правил у списку):

  1. Проходимо в Home > Auto Deploy;
  2. На вкладці Deploy Rules клікаємо на Activate/Deactivate rules – з’явиться помічник Activate and Reorder;
  3. Зі списку неактивних правил обираємо ті, що хочемо активувати, й тиснемо кнопку Activate. Якщо якісь правила потрібно деактивувати – кнопку Deactivate;
  4. Якщо потрібно змінити порядок правил у списку активних (важливо, з огляду на пріоритет їх застосування), обираємо правило, яке хочемо перемістити вище або нижче у списку й клікаємо на Move up чи Move down зверху списку активних правил;
  5. Натискаємо на ОК.

До того, як зробити правило активним, рекомендується протестувати його, клікнув на Test rules before activation. Далі обираємо хост зі списку та натискаємо на Check Compliance, щоб продивитися поточний статус хоста та зміни, що очікуються після активації правила. Якщо в результаті хост показаний як «compliant», відновлювати його після активації правила не треба. В іншому разі треба поставити галочку в Remediate all host associations after rule activation, або увімкнути відповідну кнопку – усі хости будуть відновлені.

До речі, статус активації/дезактивації правил показаний у спеціальній колонці прямо в списку правил на вкладці Deploy Rules.

Додавання хоста до інвентаря vSphere Auto Deploy з vSphere Client

Якщо хост не відповідає жодному правилу vSphere Auto Deploy, його можна вручну додати до інвентаря vSphere Auto Deploy (у разі, коли не хочемо конкретно під нього створювати нове правило, чи редагувати старе):

  1. Проходимо в Home > Auto Deploy;
  2. На вкладці Discovered Hosts обираємо один або більше хостів, що хочемо надати з відповідною локацією, профілем образу та профілем хоста;
  3. Обираємо Add to Inventory (якщо натиснути Remove, можна прибрати хост з вкладки Discovered Hosts) – з’явиться помічник Add to Inventory;
  4. На сторінці Select host location обираємо дата-центр, папку чи кластер у якості локації хоста;
  5. На сторінці Select image profile з розкривного меню обираємо сховище ПО та обираємо профіль образу зі списку;
  6. На сторінці Select host profile використовуємо Filter, щоб відшукати профілі хоста у списку, або можна поставити галочку в Do not include a host profile, щоб не додавати профіль хоста;
  7. На сторінці Select script bundle обираємо пакет скрипта зі списку;
  8. На сторінці Ready to complete переглядаємо обрані асоціації хоста.
Робота з пакетами скриптів з vSphere Client

Для додаткового налаштування після розгортання хостів можна додавати користувацький скрипт – він запуститься одразу після завершення надання ESXi-хоста через Auto Deploy. Це допомагає, коли треба, наприклад, створити користувацьке правило фаєрвола та інші налаштування, недоступні з профілями хостів. У загальному вигляді потрібно зробити наступне:

  1. Проходимо в Home > Auto Deploy;
  2. Обираємо вкладку Script Bundles та тиснемо на Upload;
  3. Знаходимо пакет скрипта та обираємо Upload – скрипт з’явиться у списку Script Bundles;

Якщо пакет треба видалити зі списку, клікаємо на нього та обираємо Remove з підтвердженням нашого рішення.

Підготовка до розгортання vCenter Server

Вище, коли ми в загальних вказівках щодо підготовки казали про етап завантаження образів нашого гіпервізора та vCenter, згадували, що образ appliance vCenter Server потребує підмонтування. Трошки пояснимо для тих, хто з таким ще не стикався, що мається на увазі.

Підмонтування відбувається на клієнтській машині – потім саме з неї буде відбуватися розгортання, можливі майбутні апгрейди, міграції та відновлення нашого appliance.

Важливо! ПО підмонтування ISO, що не дозволяє більш ніж 8 рівнів каталогу (наприклад, MagicISO Maker на Windows) не підтримується. Аналогічно, для Linux OS і Mac OS не підтримується Archive Manager.

Рекомендовано для підмонтування використовувати:

  • Mac OS: DiskImageMounter,
  • Ubuntu 14.04: Disk Image Mounter,
  • SUSE 12: термінал

наступним чином:

$ sudo mkdir mount_dir

$ sudo mount -o loop VMware-vCSA-all-version_number-build_number.iso mount_dir

Далі, перед тим, як безпосередньо перейти до розгортання vCenter Server, обов’язково треба добитися синхронізації часу між усіма вже проінстальованими компонентами vSphere – тому, чому це важливо, й як саме це зробити, ми приділили максимум уваги в окремому підрозділі «Початкових налаштувань», де можна знайти все, що вас може зацікавити щодо синхронізації часу.

І, нарешті, обов’язково пересвідчуємося, що ESXi-хост, на якому плануємо розгортати appliance, не в lockdown-режимі чи режимі техобслуговування, та не є частиною повністю автоматизованого DRS-кластера. Якщо ж ми хочемо розгорнути наш appliance на DRS-кластері інвентаря інстансу vCenter Server (не перший vCenter Server у нашій системі), треба пересвідчитися, що у кластері міститься, щонайменше, один ESXi-хост, що не в локдауні чи maintenance-режимі.

Підготовка конфігураційного JSON-файлу для CLI-методу розгортання appliance vCenter Server

В рамцях підготовки конфігураційного JSON-шаблону можна редагувати пресетні значення, видаляти параметри та додавати їх для створення власного користувацького бачення, як саме має бути налаштований й як розгорнутий наш vCenter Server. Але, зауважте, що для цього методу ви маєте добре знати синтаксис JSON.

Допомогу по роботі з шаблоном можна отримати в підкаталозі інсталятора для конкретної ОС, запустивши файл «vcsa-deploy install –template-help». А взагалі підготовка цього файлу виглядає так, покроково:

  1. У інсталяторі vCenter Server проходимо в директорію «vcsa-cli-installer» й відкриваємо підкаталог «templates»;
  2. Копіюємо шаблон звідти десь на своє робоче місце;
  3. В текстовому редакторі відкриваємо його (рекомендується саме редактор JSON!);
  4. Заповнюємо значення конфігураційних параметрів, що вимагаються, та, опціонально, додаємо свої параметри зі значеннями. Наприклад, якщо хочемо використовувати IPv4 DHCP призначення для мережі appliance, у підсекції «network» змінюємо значення параметру «mode» на «dhcp» і видаляємо дефолтні налаштування для статики:

“network”: {

“ip_family”: “ipv4”,

“mode”: “dhcp”

},

Важливо! Рядки значень, з паролями, включно, мають містити лише ASCII-символи (розширені не підтримуються!). Щоб призначити значення, що містить «\» чи «», перед символом має стояти символ бекслешу («\»). Наприклад,

“password“:”my\”password

Встановлює пароль як «my“password», а ось

“image“:”G:\\vcsa\\VMwarevCenter-Server-Appliance-8.0.0.XXXX-YYYYYYY_OVF10.ova

то є шлях «G:\vcsa\VMwarevCenter-Server-Appliance-8.0.0.XXXX-YYYYYYY_OVF10.ova».

  1. Опціонально, у самому редакторі JSON можна запустити валідацію відредагованого файлу;
  2. Зберігаємо файл в форматі UTF-8 та закриваємо його.

Загалом, у інсталяторі vCenter Server ви знайдете декілька шаблонів (у згаданому вище підкаталозі) з мінімумом конфігураційних параметрів для усіх видів розгортань:

embedded_vCSA_on_ESXi.json – для розгортання vCenter Server appliance на ESXi-хості.

vCSA_with_cluster_on_ESXi.json – з однією нодою vSAN та кластером, що керується vLCM на ESXi-хості.

embedded_vCSA_on_VC.json – на інстансі vCenter Server.

embedded_vCSA_replication_on_ESXi.json – як реплікаційного партнера на інший вбудований vCenter Server на ESXi-хості.

embedded_vCSA_replication_on_VC.json – як реплікаційного партнера для іншого vCenter Server appliance на інстансі vCenter Server.

Список конфігураційних параметрів, що зустрічаються у цих шаблонах:

Секція Підсекція Опис Параметр Тип Опис
new_vcsa (опис appliance, що розгортається, обирається тільки одна з підсекцій esxi чи vc, та тільки один варіант щодо еsxi – або з vSAN і vLCM Managed Cluster, або без них) еsxi (з vSAN і vLCM Managed Cluster) При розгортанні безпосередньо на ESXi-хості hostname string IP-адреса чи FQDN цільового ESXi-хоста
username string Ім’я користувача з привілеями адміністратора на цільовому ESXi-хості
password string Його пароль
deployment_network string Ім’я мережі, до якої підключається appliance (доступної з ESXi-хоста). Якщо тільки одна мережа для цільового хоста, ігнорується
datacenter string Вказаний дата-центр, де створюємось
cluster string Ім’я vSAN чи vLCM керованого кластера
compression_only Boolean True, щоб увімкнути компресію на кластері vSAN. Якщо true, то параметр deduplication_and_compression має бути false
deduplication_and_compression Boolean True, щоб увімкнути компресію та дедуплікацію на кластері vSAN. Якщо true, то параметр compression_only має бути false
cache_disk Список UUID чи канонічних імен дисків, що використовуються для кешу. Вказуються тільки SSD
capacity_disk Список UUID чи канонічних імен дисків, що використовуються для сховища. Вказуються або SSD, або HDD
enable_vlcm Boolean Якщо true, буде створено керований vLCM кластер
enable_vsan_esa Boolean Якщо true, буде створено vSAN-кластер з увімкненим vSAN ESA
single_tier Array Список UUID чи канонічних імен дисків, які хочемо додати до пулу сховища vSAN. Використовується тільки, якщо enable_vsan_esa встановлено на true
vsan_hcl_database_path string Локальний шлях до БД vSAN HCL. Якщо присутня база застаріла, інсталятор завантажить й замінить її на новішу. Вимагається лише, коли enable_vsan_esa встановлено на true
datastore string Ім’я датастора, де будуть зберігатися конфігураційні файли та віртуальні диски appliance (має бути доступним з ESXi-хоста)
port integer Зворотня проксі HTTPS цільового ESXi-хоста (дефолтний 443). Використовується тільки, якщо у цільового хоста користувацький HTTPS-порт зворотньої проксі
еsxi (без vSAN і vLCM Managed Cluster) hostname string IP-адреса чи FQDN цільового ESXi-хоста
username string Ім’я користувача з привілеями адміністратора на цільовому ESXi-хості
password string Його пароль
deployment_network string Ім’я мережі, до якої підключається appliance (доступної з ESXi-хоста). Якщо тільки одна мережа для цільового хоста, ігнорується
datastore string Ім’я датастора, де будуть зберігатися конфігураційні файли та віртуальні диски appliance (має бути доступним з ESXi-хоста)
port integer Зворотня проксі HTTPS цільового ESXi-хоста (дефолтний 443). Використовується тільки, якщо у цільового хоста користувацікий HTTPS-порт зворотньої проксі
vc При розгортанні appliance в інвентарі інстанса vCenter Server hostname string IP-адреса чи FQDN цільового інстанса vCenter Server, на якому розгортається appliance
username string Ім’я адміністратора vCenter Single Sign-On на цільовому інстансі vCenter Server
password string Його пароль
deployment_network string Ім’я мережі, до якої буде підключатися appliance (має бути доступна з ESXi-хоста чи DRS-кластера, на якому розгортається appliance). Ігнорується, якщо цільовий ESXi-хост чи DRS-кластер мають тільки одну мережу
datacenter array Дата-центр vCenter Server, що містить цільовий ESXi-хост чи DRS-кластер (значення чутливе до регістру)
datastore string Ім’я датастора, на якому хочемо зберігати конфігураційні файли та віртуальні диски appliance (має бути доступним з цільового ESXi-хоста чи DRS-кластера)
port integer Порт HTTPS зворотньої проксі цільового інстанса vCenter Server (дефолтний 443). Використовується тільки, якщо цільовий інстанс vCenter Server має користувацький порт HTTPS зворотньої проксі
target array Цільовий ESXi-хост чи DRS-кластер, на якому розгортається appliance (ім’я, що відображається в інвентарі vCenter Server). Значення чутливе до регістру
vm_folder string Опціонально. Ім’я папки ВМ, де розгортається appliance
appliance Опис appliance thin_disk_mode Boolean Встановити на true, щоб розгорнути appliance з тонкими віртуальними дисками
deployment_option string Розмір appliance (Значення: tiny / tiny-lstorage / tiny-xlstorage small / small-lstorage  / small-xlstorage / medium / medium-lstorage / medium-xlstorage / large / large-lstorage / large-xlstorage / xlarge / xlarge-lstorage / xlarge-xlstorage – пояснення щодо розміру – вище в розділі «Підготовки…»)
image string Опціонально. Локальний шлях до файлу чи URL інсталяційного пакету vCenter Server appliance (за дефолтом використовується пакет, що включено в ISO-файл в папці «vcsa»)
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-серверів, відокремлених комами
prefix string Довжина префіксу мережі. Тільки якщо параметр mode встановлено на static. Якщо dhcp, параметр видалити
gateway string IP-адреса дефолтного шлюза. Для IPv6 значення default
ports string Опціонально. Номери портів, що vCenter Server appliance використовує для прямих HTTP-підключень.
system_name string Первинний ідентифікатор мережі (IP-адреса чи FQDN, бажано FQDN). Після розгортання цей параметр змінити буде неможливо
os Опис операційної системи для appliance password string Пароль користувача root для ОС appliance
ntp_servers string чи array Опціонально. Імена хостів чи IP-адреси одного або декількох NTP-серверів для синхронізації часу, розділених комами
ssh_enable Boolean Значення true, щоб увімкнути можливість адміністратору заходити в appliance по SSH. Якщо робимо НА – обов’язково
time_tools_sync Boolean Опціонально. Значення на true, щоб розгорнути appliance з синхронізацією часу VMware Tools. Ігнорувати, якщо задавали NTP-сервери (параметр ntp.servers)
sso Опис налаштувань vCenter Single SignOn для appliance password string Пароль адміністратора vCenter Single Sign-On
domain_name string Доменне ім’я vCenter Single Sign-On
replication_partner_hostname string Системне ім’я партнера vCenter Server. Вимагається, тільки якщо розгортається реплікаційний партнер у вже існуючому домені vCenter Single Sign-On
sso_port integer HTTPS-порт зворотньої проксі партнера vCenter Server (дефолтний 443). Використовується лише, якщо партнер має користувацький порт HTTPS зворотньої проксі
ovftool_ arguments Опціональна підсекція для додавання довільних аргументів та їхніх значень до OVF Tool command, що генеруються інсталятором. Не валідується інсталятором – якщо OVF Tool не зможе розпізнати, що ви задали, розгортання дасть збій
сeip settings опис приєднання до VMware Customer Experience Improvement Program (CEIP) ceip_enabled Boolean True, якщо хочемо приєднатися до CEIP на цьому appliance. Якщо значення «true», команда CLI-розгортання має запускатися з аргументом «acknowledge-ceip»

Список аргументів:

–accept-eula – приймає ліцензійну угоду кінцевого користувача. Вимагається для виконання команди розгортання.

–acknowledge-ceip – підтверджує згоду на приєднання до VMware Customer Experience Improvement Program (CEIP). Вимагається, якщо параметр ceip.enabled встановлено на true в шаблоні.

-v, –verbose – додає інформацію про дебаг до виводу консолі.

-t, –terse – приховує вивід консолі. Показує лише сповіщення попередження та про помилки.

–log-dir LOG_DIR – встановлює локацію логу та інших файлів виводу.

–skip-ovftool-verification – виконує базовану верифікацію конфігураційних параметрів в JSON-файлі та розгортає appliance. Не виконує верифікацію параметрів OVF Tool.

–no-esx-ssl-verify – пропускає SSL-верифікацію підключень ESXi.

Важливо! Уникайте використання цієї опції, так як це може призвести до проблем в процесі розгортання чи після нього, адже ідентифікація цільового ESXi-хоста буде невалідованою.

–no-ssl-certificate-verification – пропускає верифікацію сертифікату безпеки для всіх серверних підключень.

–operation-id OPERATION_ID – надає операційний ID для відстеження інсталяційних активностей.

–pause-on-warnings – ставить на паузу та чекає до погодження з попередженнями.

–verify-template-only – виконує базовану верифікацію конфігураційних параметрів шаблону в JSON-файлі. Не розгортає appliance.

–precheck-only – виконує лише базовану верифікацію шаблону та параметру OVF Tool. Не розгортає appliance.

–sso-ssl-thumbprint SSL-SHA1-THUMBPRINT – перевіряє сертифікат серевра на відповідність наданому відбитку SHA1.

-h, –help – показує підказку допомоги для інсталяційної команди vcsa-deploy.

–template-help – показує підказку допомоги щодо використання конфігураційних параметрів в файлі розгортання JSON.

Після виконання параметрів команд можна отримати код виходу з команди:

0 – команда відпрацювала успішно

1 – помилка в процесі роботи

2 – помилка перевірки

3 – помилка шаблону

Процедура інсталяції vSphere 8.0

Загалом, у процесі інсталяції нам важливо дотримуватися наступного порядку дій:

  1. Проінсталювати та налаштувати ESXi-хости;
  2. Розгорнути та налаштувати vCenter;
  3. Зробити початкове налаштування, що виходить за межі інсталяційних робіт.

Відповідно, спочатку проробимо все, що вимагає інсталяція ESXi-хостів, а потім те, що стосується нашого vCenter:

Інсталяція ESXi

Установка ESXi може бути:

  • інтерактивною (рекомендована для маленьких розгортань з п’ятьма або менше хостами),
  • скриптованою,
  • за допомогою vSphere Auto Deploy.

Важливо! Спосіб vSphere Auto Deploy має на увазі, що vSphere Auto Deploy інсталюється разом з vCenter Server. Отже, щоб надати ESXi-хости, ви маєте встановити vCenter Server.

Усі розглянемо по черзі в свій час.

Інтерактивний спосіб інсталяції ESXi

Найлегший та найдоступніший спосіб. Лишень треба завантажити ESXi-інсталятор та слідувати вказівкам його помічника (установка піде на локальний диск хоста). Інсталятор відформатує та розіб’є на потрібні партиції цільовий диск і встановить завантажувальний образ ESXi (це якщо на диску раніше не було ESXi. Якщо ж був, інсталятор запропонує провести апгрейд).

Зауваження. Якщо ваша система підтримує DPU, починаючи з vSphere 8.0, ви можете одночасно встановити, переставити чи проапгрейдити ESXi-хост на DPU. Для цього потрібно буде обрати DPU, що пасує, натиснути Enter – з’явиться вікно DPU Details, що продемонструє властивості DPU-пристрою.

Порядок дій:

  1. Запускається вітальна сторінка:

Тиснемо на ній Enter, щоб продовжити, і погоджуємось з EULA;

  1. Далі буде віконце, в якому треба обрати диск:

Якщо хочемо продивитися по ньому інформацію, тиснемо F1. Погоджуємось з вибором Enter. (Якщо на диску були дані, з’явиться вікно Confirm Disk Selection);

  1. Обираємо тип клавіатури для хоста (з консолі після інсталяції це можна буде змінити);
  2. Вводимо за запитом пароль root з підтвердженням (пароль також можна буде замінити потім):

  1. У наступному тиснемо на F11, що запустить процес інсталяції, по завершенню якого можна буде виймати інсталяційний пристрій;
  2. Клікаємо Enter, щоб перезавантажити хост.

Описаний інтерактивний спосіб працює з завантажувачем образу як з CD/DVD або USB-флешки, так і з мережевим завантаженням. Насправді, в останньому випадку збоку користувача відбувається все так само, як описано вище, незалежно від способу завантаження носія. Теорія щодо мережевого завантаження докладно описана нижче в розділі «Скриптована інсталяція ESXi з мережевим завантаженням інсталятора».

Первинне налаштування ESXi-хоста при інтерактивній інсталяції

При інсталяції ESXi хосту дається призначена DHCP IP-адреса. Й далі (обов’язково до того, як хост почне свою роботу) потрібно скориставшись DCUI (текстовим користувацьким інтерфейсом з клавіатурним вводом) ESXi-хоста налаштувати певні параметри, наприклад, такі як мережеві налаштування хоста:

Таким чином задаються:

  • мережевий адаптер,
  • VLAN ID,
  • конфігурація IPv4/IPv6 (IP-адреса, маска підмережі, дефолтний шлюз),
  • ім’я хоста,
  • DNS-сервери та суфікси:

Після цього виконується перезавантаження керуючої мережі (без перезавантаження системи), вона тестується (за допомогою пінгування та запитів DNS). Також буде можливість відновити початкову конфігурацію мережі (щоб можна було все перезадати, якщо зробили помилку).

Також цей інтерфейс допоможе адміністраторові налаштувати параметри доступу:

  • Змінити пароль root;
  • Активувати/деактивувати режим lockdown (щоб обмежити керування хостом vCenter):

Важливо! Активація/деактивація режиму lockdown можлива лише для хостів, що керуються інстансом vCenter.

Крім цього, в DCUI можна змінити розкладку клавіатури, переглянути інформацію щодо підтримки (серійний номер ліцензії хоста тощо) та дивитися системні логи. За дефолтом розкладка клавіатури U.S. English. Також можна скористатися параметрами усунення несправностей (за замовчуванням вимкнено). Щоб увімкнути цю службу, треба в Troubleshooting options обрати Enable ESXi Shell для локального траблшутінгу або Enable SSH – для віддаленого виправлення помилок через SSH-клієнт (наприклад, PuTTY):

Далі обов’язково треба буде зайнятися синхронізацією часу для ESXi-хоста – про те, як це зробити, докладно поговоримо нижче, в розділі «Початкове налаштування» – «Синхронізація часу у мережі vSphere».

Інсталяція ESXi за допомогою скрипта

Інсталяційний скрипт – то є текстовий файл (наприклад, «ks.cfg»), що містить підтримувані команди, які представляють собою інсталяційні опції ESXi у відповідній секції. Ця секція обов’язкова й має бути розташована першою в скрипті. Запуск скрипта ефективний у разі розгортання багатьох хостів без безпосередньої необхідності адміністратору слідкувати за процесом й спрямовувати його, роблячи відповідні вводи та вибори.

Інсталяційний скрипт має зберігатися в локації, до якої у хоста є доступ по HTTP, HTTPS, FTP, NFS, CDROM, чи USB. Можна користатися PXE-завантаженням або завантажувати його з CD/DVD чи USB-пристрою:

Таким чином ESXi можна проінсталювати на багатьох машинах, використовуючи один скрипт для них всіх, або окремі скрипти для кожної. Скрипт інсталяції можна запустити, ввівши параметри завантаження (натиснувши Shift+O в завантажувачі) в командний рядок завантаження інсталятора ESXi. Під час завантаження може знадобитися вказати параметри доступу до файлу «kickstart».  Для PXE-завантаження параметри передаються через рядок kernelopts файла «boot.cfg». Щоб вказати локацію інсталяційного скрипта встановіть параметр ks=filepath, де filepath вказує на розташування файлу «kickstart». Без цього скриптована інсталяція не стартує – запуститься звичайний текстовий інсталятор.

На практиці це виглядає таким чином:

  1. Запускаємо хост;
  2. Коли з’явиться отаке вікно:

тиснемо Shift+O, щоб відредагувати опції завантаження;

  1. У командному рядку runweasel вводимо:

ks=location of installation script plus boot command-line options

Підтримувані параметри завантаження:

Опція завантаження Опис
BOOTIF=hwtype-MAC address Те саме, що й опція «netdevice» (див. нижче), за винятком формату PXELINUX (пояснення на syslinux.org в SYSLINUX, опція «IPAPPEND»)
gateway=ip address Встановлює мережевий шлюз у якості дефолтного для завантаження інсталяційного скрипта з пристроїв
ip=ip address Встановлює статичну IP-адресу для завантаження інсталяційного скрипта з пристроїв. Для цієї опції формат PXELINUX підтримується також
ks=cdrom:/path Шлях до скрипта з інсталяцією на CD в CD-ROM (подмонтується й перевіриться у процесі пошуку файлу)
ks=file://path Шлях до скрипта
ks=protocol://serverpath Шлях до скрипта в мережі на даному URL. «protocol» – це «http», «https», «ftp», «nfs»
ks=usb Шлях до скрипта на USB (буде шукати скрипт з ім’ям «ks.cfg», має бути розташований обов’язково в должен быть расположен обязательно в кореневій директорії диску). Якщо під’єднано багато USB, пошук буде здійснюватися доти, доки не буде знайдено перший файл з таким ім’ям. Підтримуються лише файлові системи FAT16/FAT32
ks=usb:/path Шлях до скрипта на USB у вказаному місцезнаходженні
ksdevice=device Спробує використати мережевий адаптер «device» при пошуці скрипта на пристрої. Вказується як МАС-адреса, або ім’я vmnicNN. Якщо нічого не вказати, інсталятор відшукає перший під’єднаний мережевий адаптер й вийде в мережу через нього
nameserver=ip address Вказує доменне ім’я сервера, що використовується для завантаження інсталяційного скрипта
netdevice=device Спробує використати мережевий адаптер «device» при пошуці скрипта на пристрої. Вказується як МАС-адреса, або ім’я vmnicNN. Якщо нічого не вказати, інсталятор відшукає перший під’єднаний мережевий адаптер й вийде в мережу через нього
netmask=subnet mask Вказує маску підмережі для мережевого інтерфейсу, котрий буде завантажувати інсталятор
vlanid=vlanid Налаштовує мережеву карту для представленя в якості вказаного VLAN
systemMediaSize=small Обмежує розмір партицій системного сховища на завантажувальному медіа. Можливі значення:

·         min (32 Гб, для єдиного диску чи вбудованих серверів),

·         small (64 Гб, для серверів з, щонайменше, 512 Гб RAM),

·         default (128 Гб)

·         max (споживає увесь доступний простір, для мульти-терабайтних серверів)

Можна користуватися дефолтним інсталяційним скриптом «ks.cfg» – він обов’язково є в самому інсталяторі ESXi, розташований на початковому RAM-диску в «/etc/vmware/weasel/ ks.cfg». Саме його розташування можна вказати в завантажувальній опції, про що ми згадували вище. Для цього скрипта дефолтним паролем для root є myp@ssw0rd. Змодифікувати його за власним бажанням, але не за першої ж інсталяції і не на інсталяційному медіа – коли вона завершиться, можна буде за допомогою vSphere Client: зайти на vCenter Server, що керує нашим хостом, і вже тоді редагувати. Як саме, про це ми писали вище, в розділі «Підготовка до скриптованої інсталяції ESXi-хостів»

Важливо! Якщо ваша система підтримує DPU у vSphere 8.0, скрипт «ks.cfg» можна використовувати для інсталяції ESXi на DPU.

Дефолтний скрипт «ks.cfg» містить наступні команди:

#

# Sample scripted installation file

#

# Accept the VMware End User License Agreement

vmaccepteula

# Set the root password for the DCUI and Tech Support Mode

rootpw myp@ssw0rd

# Install on the first local disk available on machine

install –firstdisk –overwritevmfs

In case you system has DPUs, you also specify a PCI slot:

install –firstdisk –overwritevmfs –dpuPciSlots=

# Set the network to DHCP on the first network adapter

network –bootproto=dhcp –device=vmnic0

# A sample post-install script

%post –interpreter=python –ignorefailure=true

import time

stampFile = open(‘/finished.stamp’, mode=’w’)

stampFile.write( time.asctime() )

Декілька слів треба сказати й про файл конфігурації завантажувача «boot.cfg». Він вказує ядро, параметри ядра та завантажувальні модулі, які використовує завантажувач «mboot.c32» або «mboot.efi». Файл «boot.cfg» надається інсталятором ESXi. Можна відредагувати рядок kernelopt в ньому, щоб вказати локацію інсталяційного скрипта чи передати інші параметри завантаження. Цей файл використовує такий синтаксис:

# boot.cfg — mboot configuration file

#

# Any line preceded with ‘#’ is a comment.

title=STRING

prefix=DIRPATH

kernel=FILEPATH

kernelopt=STRING

modules=FILEPATH1 — FILEPATH2… — FILEPATHn

# Any other line must remain unchanged.

Ці команди конфігурують завантажувач, а саме:

Команда Опис
title=STRING Встановлює назву завантажувача як STRING
prefix=STRING Опціональна. Додає DIRPATH/ попереду кожного FILEPATH в командах kernel= та modules=, що, зазвичай, не стартують з / чи http://
kernel=FILEPATH Встановлює шлях ядра як FILEPATH
kernelopt=STRING Додає STRING до параметрів завантаження ядра
modules=FILEPATH1 — FILEPATH2… — FILEPATHn Виводить перелік модулів, що потрібно завантажити (розділяються трьома дефісами)

Шлях до інсталяційного скрипту ESXi вказується таким чином:

ks=http://XXX.XXX.XXX.XXX/kickstart/KS.CFG

де XXX.XXX.XXX.XXX – IP-адреса машини, де розташований скрипт.

Як підготувати носій з інсталятором ESXi, ми розглядали вище, в розділі про «Підготовку…» до установки. Коли він готовий, в принципі, подальші дії не залежать від того, чи обрали CD/DVD, чи USB-пристрій у якості носія. Конкретно ж, скриптована інсталяція ESXi з CD/DVD або з USB флеш-пристрою виглядає таким чином:

  1. Завантажуємо ESXi-інсталятор з локального пристрою CD-ROM/DVD-ROM, або вставляємо флешку, і чекаємо, поки не з’явиться вікно вигляду: *27*
  2. Швиденько тиснемо Shift+O, щоб відредагувати опції завантаження;
  3. Вводимо параметр завантаження, що викликає дефолтний скрипт, або створений вами власноруч (розглядали цей варіант вище, в розділі «Підготовка до скриптованої інсталяції ESXi-хостів»). Цей параметр має вигляд «ks=». Після чого тиснемо Enter і процес інсталяції запуститься.

А усе, що потрібно проробити, щоб підготуватися до скриптованої інсталяції з використанням завантаження через мережу ми розглядали вище, у підрозділі «Підготовка до скриптованої інсталяції ESXi з мережевим завантаженням інсталятора». Саме ж завантаження починається автоматично, якогось специфічного втручання в процес не вимагається.

Інсталяція хостів через vSphere Auto Deploy

Насправді, як і у випадку зі скриптованою інсталяцію, vSphere Auto Deploy повністю автоматизує процес інсталяції та налаштування хостів за обраними профілями. Так, йому передує дуже масштабний, послідовний процес підготовки, створення усіх необхідних правил, профілів образів та хостів та інші дії, докладно описані нами вище в підрозділі «Підготовка до інсталяції ESXi через vSphere Auto Deploy», проте, коли це все є, робота адміністратора звужується, в буквальному сенсі, до натискання декількох кнопок:

  1. Включаємо хости, що плануємо підготувати;
  2. Вони самостійно розгортаються в автоматичному режимі згідно заданих правил, використовуючи референсний профіль, створений за готовим профілем хоста;
  3. Тестуємо та відновлюємо відповідність для виправлення хостів (як розписано у вище згаданому підрозділі);
  4. Остаточно перевіряємо, чи кожен хост підключений до системи vCenter Server, чи вони не в режимі техобслуговування, чи не мають вони збоїв з відповідності, та чи дійсно вони використовують профілі хоста з найсвіжішою, потрібною нам інформацією.

Розгортання vCenter Server

Щодо vCenter Server appliance, його можна розгортати на ESXi-хості чи інстансі vCenter Server. Метод при цьому можна обрати інтерактивний через GUI, або CLI (silent-режим) – обидва відповідні інсталятори містяться в ISO-образі нашого appliance. Про них буде йтися нижче окремо. Доступна інсталяція чи розгортання інстансів vCenter Server, з’єднаних в конфігурації Enhanced Linked Mode, шляхом їх реєстрації в спільному домені Single Sign-On (про це поговоримо в окремому підрозділі «Початкових налаштувань» нижче).

Розгортання appliance vCenter Server за допомогою GUI

Інтерактивне розгортання appliance vCenter Server – надзвичайно зручний та доступний метод, рідний для Windows, Linux та macOS, протягом якого завантажений інсталятор на клієнтську машину у мережі запускає з неї помічника, що проходить крізь два глобальні етапи: розгортання OVA та налаштування appliance:

Усі необхідні попередні перевірки та валідації він проходить самостійно, без нашого втручання. Альтернативно, якщо маємо доступ до vSphere Client, можемо розгортати OVA-файл через нього. Але цей варіант зупиниться на першій стадії – задля старту другого етапу потрібно буде зайти в vCenter Server Management Interface нашого нового appliance (увівши «https:// FQDN_or_IP_address:5480»), щоб виконати потрібні подальші налаштування.

Протягом первинного розгортання OVA нам запропонують обрати тип розгортання та налаштування appliance. Наступний етап полягає в заданні синхронізації часу та vCenter Single Sign-On, після чого початкове базоване налаштування можна буде вважати завершеним, а усі сервіси тільки-но розгорнутого appliance запустяться.

Щоб запустити інсталятор, проходимо в директорію «vcsa-ui-installer» й обираємо підкаталог, що відповідає нашій ОС:

Запускаємо файл (для Windows підкаталог «win32», файл – «installer.exe»; для Linux підкаталог «lin64», файл – «installer»; для Mac підкаталог «mac», файл – «Installer.app») інсталятора, після чого побачимо наступне вітальне вікно з вибором декількох можливостей:

Нас цікавитиме перша опція – Install. Три інші (Upgrade – для оновлення існуючого інстанса vCenter Server Appliance, Migrate – для міграції з існуючого Windows-інстанса vCenter, а Restore – для відновлення з попереднього бекапа vCenter Server Appliance) будемо розглядати в запланованій іншій статті про адміністрування vSphere 8.0. Ось що запропонує нам помічник й що нам потрібно буде в ньому задавати:

  1. Вітальне вікно познайомить з віхами розгортання, а бічне меню зліва покаже пункти нашого помічника, якими будемо йти. Тиснемо Next:

  1. Погоджуємося з ліцензійною угодою (EULA). Next;
  2. У пункті «vCenter Server deployment target» підключаємося до цільового ESXi-хоста чи системи vCenter. Для ESXi-хоста шляхом вводу його:
    • FQDN чи IP-адреси,
    • HTTPS-порта,
    • імені користувача з привілеями адміністратора на ESXi-хості та пароля.

Після цього треба клікнути Next, продемонструється попередження щодо сертифікатів, що покаже SHA1 відтиск SSL-сертифікату, проінстальованого на цільовому ESXi-хості – тиснемо там Yes, щоб його прийняти.

У випадку не першого розгортання vCenter Server, можна підключитися до інстансу vCenter Server та знайти в інвентарі ESXi-хост чи кластер DRS, де хочемо розгорнути appliance. Для цього випадку вводимо в помічникові дані по існуючому інстансу vCenter Server:

    • FQDN чи IP-адресу,
    • HTTPS-порта,
    • імені користувача та пароля з привілеями адміністратора vCenter Single Sign-On на інстансі vCenter Server.

Після цього клікаємо Next. Продемонструється попередження щодо сертифікатів, що покаже SHA1 відтиск SSL-сертифікату, проінстальованого на цільовому ESXi-хості – тиснемо там Yes, щоб його прийняти. Далі буде вибір дата-центру чи папки дата-центру, що містить ESXi-хост чи DRS-кластер, на якому розгортаємо appliance. Натискаємо Next, і після цього буде вибір самого ESXi-хоста чи DRS-кластера. Знову Next;

  1. «Set up vCenter Server VM». Вводимо ім’я appliance vCenter Server (не має містити %,\,/, менше 80 символів у довжину), встановлюємо пароль для користувача root (вимоги до паролів писали вище у «Підготовці…») та клікаємо Next;
  2. «Select deployment size». Рекомендації щодо вибору розміру розгортання наводились вище, в розділі «Підготовка…»
  3. «Select datastore». Обираємо розмір сховища для vCenter Server appliance та його місцезнаходження. Доступні варіанти:
    • Install on an existing datastore accessible from the target host – обираємо датастор зі списку сумісних;
    • Install on a new vSAN cluster containing the target host – вказуємо необхідну інформацію для створення нового кластера vSAN чи кластера vSAN Express Storage Architecture (vSAN ESA), що буде зберігати vCenter Server appliance;
    • Install on an existing vSAN datastore and claim additional disks – Вказуємо дані, щоб створити кластер на датасторі vSAN. Ця опція доступна лише у випадку, коли середовище містить сховище vSAN;

Щоб дозволити тонке надання, обираємо Enable Thin Disk Mode. NFS-сховища надаються в тонкому форматі, за дефолтом. Клікаємо Next;

  1. «Configure network settings». Тут задаємо налаштування мережі:
    • Network – обираємо мережу з розкривного меню, до якої підключиться appliance. Залежить від мережевих налаштувань цільового серверу. Якщо appliance розгортається на ESXi-хості, пам’ятайте, що неефемерні розподілені віртуальні порт-групи не підтримуються й не відобразяться в розкривному меню;
    • IP version – обираємо версію IP-адреси appliance;
    • IP assignment – обираємо, як саме виділити IP-адресу appliance (static – помічник запропонує ввести IP-адресу та параметри мережі, або DHCP – якщо DHCP-сервер є в середовищі, можна ввести бажане FQDN для appliance);
    • Common Ports – можна кастомізувати HTTP та HTTPS порти (опціонально). Якщо вказується користувацький номер порту, треба пересвідчитися, чи не використовується вже вживаний vCenter Server номер порту, або дефолтні порти 80 та 443;
  1. «Ready to complete stage 1». Переглядаємо усі налаштування розгортання для нашого appliance та клікаємо Finish, після чого розпочнеться сам процес.

Дочекавшись його закінчення зможемо клікнути Continue, щоб перейти до другого етапу. Якщо на цьому кроці раптом натиснете Close, нічого страшного – просто далі зайдете в vCenter Server Management Interface, щоб закінчити усі необхідні налаштування.

На другому етапі наш помічник виглядатиме отак:

Спочатку, традиційно, буде сторінка Introduction, на якій просто тиснемо Next. Далі:

  1. «vCenter Server Configuration». Тут налаштовуємо параметри часу для appliance (Synchronize time with the ESXi host – включає періодичну синхронізацію часу, VMware Tools встановлять час гостьової ОС таким самим, як час на ESXi-хості; Synchronize time with NTP servers – використання NTP-серверів для синхронізації часу, треба буде ввести їх IP-адреси через кому), опціонально можемо увімкнути віддалений доступ по SSH. Клікаємо Next;
  2. «SSO Configuration». Створюємо новий домен vCenter Single Sign-On, або приєднуємось до вже існуючого. У першому випадку обираємо опцію Create a new SSO domain:
    • Вводимо ім’я домену (наприклад, vsphere.local), не має містити великих літер!
    • Встановлюємо пароль для акаунта адміністратора;
    • Підтверджуємо пароль та клікаємо Next.

Якщо приєднуємось до вже існуючого домену (до речі, саме це треба зробити, якщо хочемо декілька наших vCenter розгорнути в Enhanced Linked Mode):

    • Вводимо FQDN чи IP-адресу серверу vCenter Single Sign-On;
    • Вводимо HTTPS-порт, що буде використовуватися для комунікації з сервером vCenter Single Sign-On;
    • Вводимо дані облікового запису для акаунта адміністратора vCenter Single Sign-On;

Клікаємо Next. Саме цей крок продемонстровано на наведеному вище скріншоті;

  1. «Configure CEIP». Можемо приєднатися до програми;
  2. «Ready to complete». Переглядаємо параметри налаштування та клікаємо Finish, а потім – OK, щоб завершити другу стадію процесу розгортання. Виходимо з помічника по Close.

Тепер нас спрямує на сторінку Getting Started нашого appliance vCenter Server. Далі можемо зайти через клієнт vSphere, набравши в браузері «https://<vCenter_FQDN_or_IP_address>/ui», та керувати інвентарем vCenter:

Як це робити, налаштовувати vCenter, користуватися vCenter Management Interface, працювати з мульти-хоумінгом та багато чого іншого розглянемо в майбутній статті з адміністрування vSphere.

Розгортання appliance vCenter Server через CLI

CLI-інсталятор виконує «тихе» розгортання appliance vCenter Server на ESXi-хості чи інстансі vCenter Server. Воно полягає у запуску підготованого нами раніше (підрозділ «Підготовка конфігураційного JSON-файлу для CLI-методу розгортання appliance vCenter Server» розділу «Підготовка…» вище) JSON-файлу шляхом вводу декількох команд у CLI. А саме:

  1. Проходимо в піддиректорію «vcsa-cli-installer», залежно від типу ОС («win32»/«lin64»/«mac»);
  2. Опціонально можемо запустити перевірку без безпосереднього розгортання appliance, щоб пересвідчитися, що шаблон підготовлено правильно:

vcsa-deploy install –precheck-only path_to_the_json_file

  1. Запускаємо команду розгортання:

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

Використовуємо спеціальні аргументи, про які докладно розмовляли у згаданому вище підрозділі (через пробіл), щоб задати додаткові параметри виконання команди розгортання. Наприклад, якщо хочемо вказати місцезнаходження логів та інших файлів виводу, що генерує інсталятор:

vcsa-deploy install –accept-eula –acknowledge-ceip –log-dir=path_to_the_location path_to_the_json_file

Розгортання декількох vCenter Server Appliance за допомогою CLI

Можна розгортати декілька інстансів vCenter Server appliance одночасно (у пакетному режимі) за допомогою інсталятора CLI. Для цього потрібно підготувати JSON-шаблони для всіх інстансів vCenter Server в середовищі.

Важливо! Інсталятор CLI бачить топологію розгортання й визначає порядок, в якому потрібно працювати. Саме через це обов’язковою умовою є використання JSON-шаблонами статичних IP-адрес для всіх залежних одне від одного інстансів vCenter Server в розгортанні.

Усі підготовлені шаблони (про це казали вище у відповідному підрозділі «Підготовки…») треба помістити в одну директорію (бажано назвати її якось змістовно, наприклад, «MyWorkspace/BatchDeploy»). А далі:

  1. Проходимо в піддиректорію «vcsa-cli-installer», залежно від типу ОС («win32»/«lin64»/«mac»);
  2. Опціонально, можна запустити перевірку перед розгортанням без розгортання самого appliance, щоб впевнитися, що шаблони правильні:

vcsa-deploy install –precheck-only MyWorkspace/BatchDeploy

  1. Запускаємо команду розгортання:

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

Використовуємо спеціальні аргументи, про які докладно розмовляли у згаданому вище підрозділі (через пробіл), щоб задати додаткові параметри виконання команди розгортання. Наприклад, якщо хочемо вказати місцезнаходження логів та інших файлів виводу, що генерує інсталятор:

vcsa-deploy install –accept-eula –acknowledge-ceip –log-dir=path_to_the_location MyWorkspace/BatchDeploy

Початкове налаштування

Припустимо, прогулянка попереднім розділом для нас завершилась цілковитим успіхом – наше середовище може похизуватися наданою певною потрібною кількістю хостів ESXi, розгорнувся vCenter Server. Але час для перепочинку ще не настав, адже наразі вкрай важливо якомога швидше вдатися до початкового налаштування. Розглянемо мінімальний перелік необхідних акцій щодо цього, а от глибоких налаштувань та усіх питаннь адміністрування нашої vSphere 8.0 торкнемося в майбутньому запланованому матеріалі нашого блогу.

Синхронізація часу у мережі vSphere

Зауваження. Зайнятися синхронізацією часу рекомендується одразу, як тільки-но з’явилися повністю готові й налаштовані хости.

Усі компоненти мережі vSphere мають бути синхронізовані за часом, бо інакше чутливі до нього SSL-сертифікати та SAML-токени не будуть розпізнаватися валідними в комунікаціях між машинами мережі. Це призведе до проблем з автентифікацією, фейлів інсталяцій або заборони стартувати сервісу vmware-vpxd vCenter Server, завадить акуратному відображенню графіків продуктивності, у логах не буде точного маркування таймінгу, що ускладнює траблшутінг. Щоб цього не сталося попередньо перевіряємо:

  • Чи синхронізований з NTP або PTP цільовий ESXi-хост, на якому має розгорнутися vCenter Server?
  • Чи синхронізований з NTP або PTP хост ESXi, що містить джерело vCenter Server?

Щоб встановити безпечне TLS-підключення до vCenter Server (серверу), система, де запускаємо CLI-інсталятор (клієнт) має бути засинхронізована по годиннику з сервером у певному, так званому, проміжку толерантності (Clock Tolerance):

Сценарій розгортання Толерантний часовий проміжок
Зв’язування одного vCenter Server з іншим 10 хв.
Інсталяція appliance vCenter Server з допомогою контейнера vCenter Server через шаблон *._on_vc.json 8г. 20 хв.

Синхронізацію можна налаштувати через VMware Host Client або vSphere Client. NTP (Network Time Protocol) дає точність часу в мілісекундах, а PTP (Precision Time Protocol) – у мікросекундах. NTP чи PTP можна налаштувати за допомогою VMware Host Client або vSphere Client. Одночасно вони працювати не можуть (як і з можливістю вручну виставити час):

ESXi-хост може бути налаштований як NTP-клієнт і синхронізувати час з NTP-сервером в інтернеті чи з корпоративним NTP-сервером. NTP-клієнт використовує порт UDP 123:

Це налаштування виглядає досить просто:

  1. На домашній сторінці vSphere Client проходимо в Home > Hosts and Clusters і обираємо хост;
  2. На вкладці Configure обираємо System > Time Configuration;
  3. Клікаємо на Add Service та обираємо Network Time Protocol з розкривного меню;
  4. В діалоговому вікні Network Time Protocol редагуємо налаштування протоколу: якщо хочемо бачити усі події в середовищі vSphere, обираємо Enable monitoring events, а в текстовому полі NTP Servers вводимо IP-адресу чи імена хостів NTP-серверів, які хочемо використовувати (за best practice їх має бути, щонайменше, три);
  5. Натискаємо ОК.

РТР надає апаратну мітку часу для ВМ і хостів в мережі. Клієнт РТР використовує порт UDP 319 і 320. Якщо служба РТР не працює, NTP може підключитися у якості резервного варіанту.

Процедура налаштування РТР:

  1. На домашній сторінці vSphere Client проходимо в Home > Hosts and Clusters й обираємо хост;
  2. На вкладці Configure обираємо System > Time Configuration;
  3. Клікаємо на Add Service та обираємо Precision Time Protocol з розкривного меню;
  4. В діалоговому вікні Precision Time Protocol редагуємо параметри: щоб налаштувати мітки часу, треба обрати з розкривного меню тип мережевого адаптера як «PCI passthrough», чи для мітки часу ПО – «VMkernel Adapter» у якості типу мережевого адаптера:
  5. Опціонально, створюємо механізм відкату у випадку збою РТР-синхронізації, клікнув на Enable fallback, але це можна зробити, тільки якщо поставити галочку в Enable monitoring events, щоб спостерігати за подіями в vSphere. В діалоговому вікні NTP Servers вводимо IP-адресу чи імена хостів NTP-серверів, які хочемо використовувати (за best practice їх має бути, щонайменше, три);
  6. Натискаємо ОК.

Щоб протестувати, чи правильно функціонують сервіси синхронізації, можна натиснути Test Services – з’явиться діалогове вікно Time Synchronization Services test, де буде потрібна інформація.

Якщо за якоїсь причини не плануємо, принаймні зараз, працювати з NTP чи PTP синхронізацією часу, а розбіжність між хостом та рештою компонентів vSphere присутня, й значна, можна вручну встановити правильний час та дату на хості. Для цього:

  1. На домашній сторінці vSphere Client проходимо в Home > Hosts and Clusters й обираємо хост;
  2. На вкладці Configure обираємо System > Time Configuration;
  3. Клікаємо на Manual Set-Up – з’явиться діалогове вікно, в якому вводимо потрібні дату й час, після чого підтверджуємо все кнопкою ОК.

Важливо! ESXi-хости використовують UTC (Coordinated Universal Time) і не підтримують зміну часових зон. В клієнті vSphere ви бачите локальний час як поточний для конкретного хоста.

Початкові налаштування ESXi

Коли ESXi-хост завантажується вперше або після збросу дефолтів, він вступає в фазу автоконфігурації, що налаштовує мережу системи та пристрої сховища з параметрами за замовчуванням. За дефолтом, DHCP налаштовує IP, а усі видимі порожні внутрішні диски форматуються з VMFS, щоб ВМ могли зберігатися на дисках.

Керувати ESXi-хостами можна за допомогою VMware Host Client, vSphere Client та vCenter Server.

Також для траблшутінга, початкового конфігурування та встановлення адміністративного доступу можна використовувати прямий консольний інтерфейс – він з’явиться на екрані, як тільки-но завершиться фаза автоконфігурування хоста. Гарячі клавіші навігації прямою консоллю:

F2 – перегляд та зміна конфігурації

F4 – перехід користувацького інтерфейсу на висококонтрасний режим

F12 – вимкнення чи перезапуск хоста

Alt+F12 – перегляд логів VMkernel

Alt+F1 – пермкнутися на консоль оболонки

Alt+F2 – перемкнутися на інтерфейс прямої користувацької консолі

Arrow keys – пересування вибору між полями

Enter – обрання об’єкту меню

Spacebar – перемикання значення

F11 – підтвердження чутливих команд, наприклад, зкидання конфігурації за замовчуванням

Enter – зберегти й війти

Esc – вийти без збереження

q – вийти з системних логів

Щоб налаштувати розкладку клавіатури для прямої консолі:

  1. З прямої консолі обираємо Configure Keyboard та натискаємо Enter;
  2. Обираємо розкладку клавіатури – тиснемо пробіл, щоб перемикати вибори на on/off;
  3. Клікаємо Enter.

Щоб встановити банер безпеки, що буде демонструватися на Welcome-екрані прямої консолі, потрібно:

  1. З vSphere Client підключаємося до vCenter Server;
  2. Обираємо хост в інвентарі;
  3. Клікаємо на вкладку Configure;
  4. Під System обираємо Advanced System Settings;
  5. Обираємо WelcomeMessage;
  6. Клікаємо іконку Edit;
  7. Вводимо сповіщення з безпеки.

Щоб перенаправити пряму консоль на послідовний порт (для віддаленого керування консоллю), можна скористатися налаштуванням вручну чи інтерфейсом vSphere Client.

Важливо! Послідовний порт не має використовуватися для послідовного логування та дебаггінга.

У першому випадку:

  1. Запускаємо хост;
  2. Коли з’явиться вікно завантаження гіпервізора, тиснемо на Shift+O, щоб відредагувати опції завантаження;
  3. Деактивуємо logPort та gdbPort на com1, та встановлюємо tty2Port на com1, увівши таке:

“gdbPort=none logPort=none tty2Port=com1”;

Щоб замість цього використовувати com2, у виразі робимо відповідні зміни.

А в другому:

  1. З vSphere Client підключаємось до vCenter Server;
  2. Обираємо хост в інвентарі;
  3. Клікаємо на вкладку Configure;
  4. Під System обираємо Advanced System Settings;
  5. Впевнюємось, що поля VMkernel.Boot.logPort та VMkernel.Boot.gdbPort не встановлені на використання com-порту, на який хочемо перенаправити пряму консоль;
  6. Встановлюємо VMkernel.Boot.tty2Port на послідовний порт, щоб перенаправити пряму консоль на com1 чи com2;
  7. Перезавантажуємо хост.

Увімкнення ESXi Shell та SSH Access через користувацький інтерфейс прямої консолі

  1. На прямій консолі тиснемо F2, щоб зайти в меню System Customization;
  2. Обираємо Troubleshooting Options та тиснемо Enter;
  3. З меню, що з’явилося, обираємо сервіс, який потрібно увімкнути – Enable ESXi Shell / Enable SSH й тиснемо Enter;
  4. Опціонально, можна встановити тайм-аут для ESXi Shell (за дефолтом – 0): з меню Troubleshooting Mode Options обираємо Modify ESXi Shell and SSH timeouts та тиснемо Enter, вводимо значення у хвилинах, знов натискаємо Enter та вводимо тайм-аут простою;
  5. Тиснемо Esc, поки не повернемося в головне меню.

Встановлення паролю для акаунта адміністратора (ім’я користувача – root)

За замовчуванням, пароль адміністратора не встановлений. Щоб його налаштувати, треба:

  1. З прямої консолі обираємо Configure Password;
  2. Опціонально, якщо пароль вже є, можна ввести новий в рядок Old Password та натиснути Enter;
  3. В рядку New Password вводимо новий пароль та тиснемо Enter;
  4. Знову вводимо новий пароль і ще раз Enter.

Налаштування параметрів завантаження BIOS

Якщо на сервері багато пристроїв, доведеться налаштувати параметри BIOS, що, загалом, відповідають за те, як саме сервер буде завантажуватися.

Важливо! Якщо ви використовуєте ESXi Embedded, конфігурація завантаження BIOS визначає, чи ваш сервер завантажується на завантажувальний пристрій ESXi або інший завантажувальний пристрій. Як правило, флеш-пристрій USB зазначений першим у налаштуваннях завантаження BIOS на машині, на якій розміщено ESXi. Коли ви встановлюєте або оновлюєте ESXi в режимі UEFI, інсталятор створює параметр завантаження UEFI під назвою VMware ESXi і робить його параметром завантаження за замовчуванням, тому вам не потрібно змінювати порядок завантаження.

Параметри завантаження можна змінювати, шляхом налаштування його порядку в BIOS протягом первинного запуску чи обравши завантажувальний пристрій з меню обрання пристрою. В першому випадку після цих змін нові налаштування будуть застосовуватися до всіх послідовних перезавантажень. Якщо ж напряму обрати – застосується тільки для поточного завантаження. Для зміни цих параметрів в BIOS для ESXi потрібно:

  1. Хост ESXi має бути увімкненим, щоб натиснути клавішу, що потрібна для входу в налаштування BIOS хоста (залежить від апаратного забезпечення серверу, іноді це Delete);
  2. Обираємо налаштування завантаження BIOS:
    • If you are using the installable version of ESXi – обираємо диск, на якому проінстальовано ПО ESXi та переміщаємо його на першу позицію у списку;
    • If you are using ESXi Embedded – обираємо пристрій USB та переміщаємо його на першу позицію у списку.

Також можна налаштувати параметри завантаження для віртуального медіа. Це корисно, коли використовуєте ПО віддаленого керування для установки ESXi. Віртуальне медіа допомагає підключитися до віддаленого медіа-сховища, наприклад, CD-ROM, USB, ISO-образу, флоппі-диску на цільовому сервері. Для цього:

  1. Підключаємо медіа до віртуального пристрою. Наприклад, якщо в нас сервер Dell, заходимо в Dell Remote Access Controller (DRAC) чи інший подібний інтерфейс та обираємо фізичний флоппі чи пристрій CD-ROM, або надаємо шлях до образу флоппі / образу CD-ROM;
  2. Перезавантажуємо сервер;
  3. Коли сервер увімкнеться, заходимо в меню вибору пристрою (в залежності від апаратного забезпечення серверу це може бути функціональна клавіша чи Delete);
  4. Йдемо за вказівками та обираємо віртуальний пристрій.

Налаштування параметрів мережі та тестування її підключень

Щоб обрати мережеві адаптери для management-мережі:

  1. З прямої консолі обираємо Configure Management Network та тиснемо Enter;
  2. Обираємо Network Adapters та натискаємо Enter;
  3. Обираємо мережевий адаптер та тиснемо Enter.

Щоб встановити VLAN ID ESXi-хоста:

  1. З прямої консолі обираємо Configure Management Network та тиснемо Enter;
  2. Обираємо VLAN та натискаємо Enter;
  3. Вводимо VLAN ID (число від 1 до 4094).

Щоб налаштувати IP-параметри для ESXi:

  1. Обираємо з прямої консолі Configure Management Network та тиснемо Enter;
  2. Обираємо IP Configuration та натискаємо Enter;
  3. Обираємо Set static IP address and network configuration;
  4. Вводимо IP-адресу, маску підмережі та дефолтний шлюз, після чого тиснемо Enter.

Аналогічного результату можна досягти й з клієнта vSphere (корисно, коли немає фізичного доступу до хосту):

  1. Заходимо на vCenter Server з vSphere Client;
  2. Обираємо хост в інвентарі;
  3. На вкладці Configure розкриваємо Networking;
  4. Обираємо VMkernel adapters;
  5. Обираємо vmk0 Management Network та клікаємо на іконку редагування;
  6. Обираємо IPv4 settings;
  7. Обираємо Use static IPv4 settings;
  8. Вводимо чи змінюємо налаштування статичної IPv4-адреси (те саме можна, якщо потрібно, зробити й для IPv6-адреси);
  9. Клікаємо на OK.

Щоб налаштувати DNS для ESXi, можна, по-перше, обрати чи вручну, чи автоматичним чином буде відбуватися конфігурація DNS хоста ESXi. За дефолтом маємо автоматику (обов’язково вимагає наявності DHCP та DNS серверів). Але подекуди автоматичний DNS не є доступним, чи є небажаним, і тоді можна налаштувати статичну DNS-інформацію, включно з іменем хоста, іменами первинного та вторинного серверів, DNS-суфіксами. Для цього з прямої консолі:

  1. Обираємо Configure Management Network та тиснемо Enter;
  2. Обираємо DNS Configuration та натискаємо Enter;
  3. Обираємо Use the following DNS server addresses and hostname;
  4. Вводимо первинний сервер, альтернативний (опціонально), та ім’я хоста;
  5. Повертаємось у Configure Management Network;
  6. Обираємо Custom DNS Suffixes та тиснемо Enter;
  7. Вводимо нові DNS-суфікси.

Після усіх налаштувань обов’язково треба протестувати мережеве підключення. З прямої консолі можна це зробити шляхом пінгування:

  • дефолтного шлюза,
  • первинного сервера DNS-імен;
  • вторинного сервера DNS-імен;
  • вирішення (Resolve) налаштованого ім’я хоста.

Для цього обираємо Test Management Network та тиснемо Enter, і ще раз Enter, щоб розпочати тест, після введення адрес, які потрібно пропінгувати чи іншого DNS-імені хоста, яке треба відрезолвіти.

Також ще однією дуже корисною й часто вживаною операцією є перезавантаження management-мережі (щоб відновити мережеве підключення чи оновити оренду DHCP). Це теж можна зробити з прямої консолі, обравши Restart Management Network і натиснувши Enter, а потім – F11, щоб підтвердити перезапуск.

І, нарешті, завершуючи розмову про налаштування підключень і мережі, поговоримо про відновлення стандартного світча (vSphere Distributed Switch у подробицях розглянемо у статті про адміністрування vSphere 8.0). Це може знадобитися:

  • Коли Distributed Switch не потрібен, або з якоїсь причини не працює;
  • Коли він вимагає відновлення, але на цей час хости мають лишатися доступними;
  • Коли нам не треба, щоб хост керувався vCenter Server (в останньому випадку пам’ятайте, що більшість функцій vSphere Distributed Switch для хоста стануть недоступними).

Щоб перемкнутися таким чином, потрібно: обрати Restore Standard Switch з прямої консолі та натиснути Enter, а потім на F11 для підтвердження.

Початкові налаштування vCenter Server

В принципі, більшість налаштувань тільки-но розгорнутого нами vCenter Server можна спокійно здійснити згодом – з його керуючого інтерфейсу, чи з клієнту vSphere. І усі ці операції, в усіх подробицях, ми обов’язково розглянемо в майбутній статті по адмініструванню нашої «сфери». Але, якщо наша задача в послідовному розгортанні декількох інстансів vCenter Server, обов’язково слід розглянути можливість їх організації в Enhanced Linked Mode – і з ось у цьому випадку зволікати з налаштуваннями в нас ажніяк не вийде.

Приєднання до домену vCenter в Enhanced Linked Mode

Appliance vCenter Server можна під’єднати до іншої ноди протягом її розгортання (чи пізніше – шляхом переміщення, перепризначення тощо) у Enhanced Linked Mode групі. На практиці в UI-інсталяторі це виглядає так:

  1. Розгортаємо перший appliance vCenter Server як інстанс на першому хості ESXi;
  2. Розгортаємо другий appliance vCenter Server як інстанс на тому ж першому хості. На другому етапі розгортання (stage 2) обираємо приєднання до серверу vCenter Single Sign-On розгорнутого першого appliance.

Важливо! Синхронізацію часу, про яку йшлося вище у окремому підрозділі, для хосту ESXi, на якому розгорнуто наш перший vCenter Server appliance, з appliance vCenter Server треба провести до того, як почнемо працювати з другим appliance vCenter Server. Більш того, для другого appliance синхронізація має пройти з першим хостом першого appliance vCenter Server.

Якщо хочемо зробити це через CLI:

  1. Налаштовуємо конфігураційний JSON-шаблон «embedded_vCSA_on_VC.json» (чи «embedded_vCSA_on_ESXi.json») для першого appliance як інстанса на першому хості ESXi;
  2. Розгортаємо перший appliance, запустивши:

vcsa-cli-installer

  1. Налаштовуємо конфігураційний JSON-шаблон «json» (чи «embedded_vCSA_replication_on_ESXi.json») для другого appliance як інстанса на першому хості ESXi. Вводимо ім’я хоста першої вбудованої ноди в полі «replication_partner_hostname» секції «sso»;
  2. Розгортаємо другий appliance, запустивши:

vcsa-cli-installer

що використовує файл «embedded_vCSA_replication_on_VC.json» (чи «embedded_vCSA_replication_on_ESXi.json»).

А про інші операції, включно з налаштуванням й роботою з журналами логів, ліцензуванням, роботою з інвентарем vCenter за допомогою vSphere Client, призначенням ролей користувачам, створенням та налаштуванням віртуальних мереж та сховищ даних, а також віртуальних машин, кластерів, з керуванням життєвим циклом нашого віртуального середовища, та багато про що ще поговоримо в нашій наступній статті з циклу по vSphere 8.0, присвяченій адмініструванню у всій його багатогранності. Також вийде й окремий матеріал щодо оновлення vSphere до 8-ї мажорної версії – його, певні, з нетерпінням чекають усі власники «сімки» та ще більш старих релізів.