Задачі адміністрування vSphere 8.0

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

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

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

Користувацькі інтерфейси vSphere

Для взаємодії з нашим середовищем можемо користуватися такими інтерфейсами:

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

Головну увагу сьогодні приділимо GUI клієнта самої «сфери», хоста, а деякі операції вимагатимуть від нас роботи з інтерфейсом vCenter Server Management. Інші методи взаємодії з середовищем епізодично будуть використовуватися в деяких задачах нижче, якщо вони краще пасуватимуть, чи будуть єдино можливими, але окремо виділяти їх не будемо.

GUI vSphere Client

Зайти в клієнт «сфери» можна, ввівши у рядку браузера «https://<vCenter_FQDN_or_IP_address>/ui»:

Нас попросить надати дані облікового запису адміністратора, після чого попадемо в сам GUI. Біля назви є головне меню («три горизонтальні рисочки»), користуючись яким можна керувати інвентарем системи vCenter, середовищем інфраструктури та виконувати різноманітні задачі з адміністрування:

Навігаційна панель роботи з інвентарем vCenter розташована зліва:

У цьому бічному меню наявні чотири вкладки:

1. Хости та кластери (Hosts and Clusters):
2. Віртуальні машини та шаблони (VMs and Templates):
3. Сховища (інформація щодо датасторів в дата-центрі) (Storage):
4. Мережі (усі порт-групи на стандартних та розподілених світчах) (Networking):

Зауваження. Об’єкти з усіх чотирьох вкладок (будь-який напрямок інвентаря) можна організовувати у папки та підкаталоги для зручності:

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

У робочій частині інтерфейсу правіше розташоване меню вкладок та власне бічне меню – для кожного типу об’єкта інвентаря (див. вище) своє. Зазвичай, на цих вкладках можна знайти, наприклад, Summary (загальна інформація щодо об’єкту, статус, конфігурація), Monitor (елементи моніторингу, сповіщення й попередження тощо), Configure (можливості налаштування), Permissions (керування дозволами, доступна лише користувачам з привілеями адміністратора), Updates (сумісність та інформація щодо наявних оновлень) та інші, специфічні для пов’язаних об’єктів.

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

Контроль віддаленого доступу до ESXi-хосту

За допомогою vSphere Client можна налаштувати необхідні параметри безпеки, що контролюють віддалений доступ до ESXi-хоста (як взагалі його увімкнути, ми розглядали ось тут).

Фаєрвол ESXi активовано за дефолтом – він блокує вхідний та вихідний трафік, за виключенням того, що активований у налаштуваннях фаєрволу хоста:

Важливо! Такі ключові й фундаментальні для безпеки сервіси, як NTP та SSH клієнти, керуються користувачем з привілеями адміністратора (щодо акаунтів користувачів поговоримо нижче у відповідному підрозділі).

Режим Lockdown запобігає віддаленому доступові користувачів до входу на хост напряму – хост доступний лише через DCUI чи з vCenter. Ще можна використовувати START, STOP та RESTART, щоб змінити статус сервісу тимчасово. Альтернативно, можна змінити політику запуску, щоб служба запускалася з використанням хоста чи порта. Для деяких служб можна вказувати ІР-адреси, їх діапазони або цілі підмережі, з яких дозволено з’єднання.

Робиться це все на вкладці Configure під System у Firewall та інших розділах нижче, присвячених безпеці.

Налаштування вхідного повідомлення

До сторінки входу в vSphere Client можна додати повідомлення, що буде демонструватися користувачеві. Для цього:

1. З меню Home обираємо Administration і під Single Sign On клікаємо на Configuration;
2. Проходимо на вкладку Login Message;
3. Тиснемо на Edit та вмикаємо Show login message, щоб дозволити його показ;
4. У полі Login message задаємо заголовок повідомлення (якщо в полі Consent checkbox – розташоване нижче – стоїть галочка, то дефолтний текст повідомлення буде «I agree to Terms and Conditions» і за бажанням фразу «Terms and Conditions» можна буде змінити на свою. Якщо ж галочки там нема з’явиться «Login message» замість якого просто пишемо власний варіант);
5. У Consent checkbox ставимо галочку, якщо хочемо, щоб при кожному вході користувач мав поставити позначку у чекбоксі, погоджуючись з нашим повідомленням (без цього вибору повідомлення показуватися теж буде, проте взаємодії з користувачем не вимагатиме);
6. У Details of login message пишемо «тіло» нашого повідомлення;
7. Зберігаємо налаштування кнопкою Save.

Налаштування таймауту клієнта vSphere

За замовчуванням, vSphere Client закривається через 120 хвилин простою і користувачеві доводиться знову робити вхід, щоб клієнт відновив роботу. Відредагувати це значення можна як безпосередньо у файлі «webclient.properties», так і в самому клієнті.

В першому випадку проходимо в папку «/etc/vmware/vsphere-ui» і відкриваємо на редагування файл «webclient.properties». Знаходимо там рядок session.timeout = <custom_value>, де <custom_value> – то є значення у хвилинах (якщо це – перша зміна таймауту, то будуть стояти 120). Якщо хочемо, щоб клієнт ніколи не відключався, ставимо значення 0 або від’ємне. Зберігаємо файл й перезапускаємо клієнт.

Якщо міняємо в самому vSphere Client:

1. Проходимо в Home > Administration і під Deployment обираємо Client Configuration;
2. На панелі, що відкриється, клікаємо Edit – з’явиться діалогове вікно Edit client configuration;
3. Вводимо бажане значення у хвилинах в текстове поле;
4. Зберігаємось по Save та перезапускаємо клієнт.

Керування клієнтськими плагінами

У vSphere Client клієнтські плагіни можна побачити в панелі Recent Tasks чи Task Console (прогрес активностей, розгортання, збої, оновлення, інсталяції та деінсталяції тощо) та в Administration > Solutions > Client Plugins. В останній панелі з плагінами можна робити усілякі дії, включно з додаванням нових та видаленням. Додавання відбувається після натискання тут на Add – з’явиться помічник Install new solution:

1. У пункті Select an OVF template вказуємо локацію, звідки брати OVF плагіна (URL чи Local file, у другому випадку доведеться клікнути на Upload files, щоб обрати потрібні). Next;
2. У пункті Select a name and folder вводимо унікальне ім’я ВМ та локацію розгортання, Next;
3. У пункті Select a compute resource обираємо ресурс, де буде запускатися наш клієнтський плагін, Next;
4. На сторінці Review details проглядаємо зроблені налаштування та клікаємо Next;
5. На сторінці License agreement ставимо галочку й тиснемо Next;
6. На сторінці Select storage обираємо, де й як буде зберігатися наш плагін. Можна обрати політику та, опціонально, поставити галочку в Disable Storage DRS for this virtual machine, якщо не хочемо, щоб для цієї ВМ працював Storage DRS;
7. На сторінці Select networks обираємо вихідну мережу та співставляємо її з мережею призначення, Next;
8. Опціонально, на сторінці Customize template можемо проглянути налаштування у режимі тільки для читання та клікнути Next;
9. На сторінці Associate vCenter Servers обираємо інстанси vCenter Server, на яких буде розгортатися плагін, Next;
10. На Ready to complete остаточно переглядаємо усе задане та запускаємо розгортання кнопкою Finish.

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

Запуск, зупинка та перезапуск сервісів у vSphere Client

Нижче, коли будемо вчитися працювати з vCenter Server Management Interface, розглянемо як виконувати дії безпосередньо з нього щодо різноманітних сервісів середовища. Проте, це можна зробити й з клієнта vSphere, якщо пройти в Administration > System Configuration та клікнути на відповідну ноду зі списку. У верхньому меню при цьому побачимо дії Restart, Start та Stop для перезапуску, запуску чи зупинки сервісів, відповідно.

Прикріплення файлів до запиту сервісу

Якщо ми формуємо запит до VMware Service Requests (сталася проблема, яку не можемо розв’язати власними силами, наприклад), можемо прикріпити до нього файли – скріншоти чи файли логів тощо. Для цього на боковій панелі vSphere Client клікаємо на Administration та під Support – на Upload File to Service Request і ще раз на однойменну кнопку. Далі вводимо Service Request ID, клікаємо на Browse та обираємо потрібний файл, і остаточно на Upload.

Внесення задач у розклад

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

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

• Додавання хоста до вказаного дата-центру чи кластеру,
• Зміна стану живлення ВМ (рower on, power off, suspend, reset),
• Зміна параметрів живлення кластеру (активувати чи деактивувати DPM для хостів у кластері),
• Зміна параметрів ресурсів ресурс-пулу чи ВМ (для CPU та Memory – Shares, Reservation, Limit),
• Перевірка відповідності профіля (чи співпадає конфігурація хоста з конфігурацією профіля хоста),
• Клонування ВМ з розміщенням у вказаному хості чи кластері,
• Створення нової ВМ на вказаному хості,
• Розгортання ВМ з шаблону на вказаному хості чи кластері,
• Міграція ВМ на вказаний хост чи датастор з vMotion чи без нього,
• Снепшотування ВМ,
• Сканування на доступні оновлення шаблонів, ВМ, хостів (за наявності vSphere Lifecycle Manager),
• Виправлення шляхом інсталювання пропущених патчів (за наявності vSphere Lifecycle Manager).

У панель розкладу задач можна потрапити, якщо встати на потрібному об’єктові у клієнті vSphere та на вкладці Configure обрати Scheduled Tasks. Щоб внести нову задачу у розклад, тицяємо на New Scheduled Task і:

1. З розкривного меню New Scheduled Task обираємо задачу, яку хочемо внести до розкладу – відкриється відповідний помічник;
2. Вводимо ім’я та опис задачі;
3. Обираємо частоту її виконання: Once (запустити раз в обраний час і все), After vCenter startup (кожного разу після запуску vCenter Server через вказаний проміжок часу у хвилинах), Hourly (вводимо частоту, дату початку й кінця), Daily (вводимо частоту, дату початку й кінця), Weekly (день тижня, вводимо частоту, дату початку й кінця), Monthly (вводимо частоту, і або конкретний день місяця й кількість місяців, або обираємо first, second, third, fourth чи last та день тижня й кількість місяців);
4. Клікаємо на Schedule the task.

До вже створеного розкладу можна внести зміни, якщо у Scheduled Tasks встати на шукану задачу зі списку зліва та обрати Edit, відредагувати бажаним чином та клікнути на Save. Видалити внесену у розклад задачу можна, якщо там же обрати задачу та клікнути на Remove.

Налаштування хостів з клієнта vSphere

У розділах нижче будемо вчитися задавати налаштування хоста з VMware Host Client, а дещо з цієї теми навіть розглядалося у розрізі користування DCUI у неодноразово тут згадуваній статті про greenfield-інсталяцію. Але деяку конфігурацію можна влаштувати й з vSphere Client – прямісінько з його розділу інвентаря Hosts and Clusters.

Наприклад, якщо ми хочемо налаштувати завантажувальний пристрій на ESXi-хості, обираємо потрібний хост в інвентарі та клікаємо на вкладку Configure. Під Hardware обираємо Overview та натискаємо на кнопку Boot Options, й визначаємо завантажувальний пристрій з розкривного меню. Якщо хочемо, щоб хост одразу ж перезавантажився зі вказаного нами пристрою, обираємо Apply and Reboot on OK. Як цього не зробити, налаштування застосується за наступного перезавантаження хоста. Тиснемо на ОК, щоб зберегти нову конфігурацію.

GUI VMware Host Client

Зауваження. VMware Host Client – інтерфейс, що керує поодинокими хостами. Він зручний у надзвичайних ситуаціях, коли vCenter Server недоступний, працює з адміністративними задачами та базовим траблшутінгом.

VMware Host Client дуже відрізняється від клієнта vSphere. Проте щодо єдиного хоста ESXi має досить вичерпний функціонал:

• Базові операції віртуалізації, включно з розгортанням та налаштуванням ВМ різної складності;
• Створення та керування мережами і сховищами даних;
• Має розширене налаштування параметрів рівня хоста для покращення продуктивності.

Щоб зайти в VMware Host Client, у веб-браузері вводимо ім’я або ІР-адресу цільового хоста у форматі: «https://host-name/ui» або «https://host-IP-address/ui». На екрані логіну вводимо ім’я користувача та пароль і клікаємо на Login – з’явиться сторінка VMware Customer Experience Improvement Program (CEIP), щоб можна було визначитися, чи хочемо приєднатися до програми, де тиснемо ОК.

У vSphere 8.0 з’явилися деякі опції кастомізації й брендування VMware Host Client UI та налаштування способу показу контенту. Зокрема, можна обрати одну з трьох тем – light, dark і classic, наступним чином: у панелі інструментів клікаємо на Help й на About, з розкривного меню UI Preferences Theme обираємо бажану тему. Якщо хочемо більш гранульованого налаштування, тиснемо на кнопку Customize:

В полі Theme name вводимо ім’я нашої нової теми, а після усіх зроблених виборів тиснемо на Enable. Якщо хочемо повернутися до дефолтної палітри – на Reset.

Зауваження. Щоб перемкнутися з VMware Host Client на vSphere Client, отримати повний спектр можливостей та функцій траблшутінгу ESXi-хоста, якщо він не має залишитися standalone-об’єктом і ми не проти його приєднання до товариства, потрібно зробити наступне у VMware Host Client:

1. ПКМ на Host у інвентарі та обираємо з розкривного меню Manage with vCenter Server – відкриється сторінка логіну до vCenter Server у новому вікні;
2. Вводимо дані свого облікового запису та клікаємо на Login.

Аналогічним чином можна відключитися від системи vCenter Server за необхідності (буває корисно, коли вона дала збій, а потрібно зробити певні екстренні дії з хостом):

1. ПКМ на Host у інвентарі VMware Host Client і обираємо Disconnect from vCenter Server з меню, що показалося;
2. Клікаємо на Disconnect from vCenter Server.

Налаштування банеру логіна в VMware Host Client UI

Можна налаштувати банер на екрані логіну задля демонстрації якихось попереджень, анонсів тощо. Для цього редагуємо файл /etc/vmware/welcome прямо на хості. Синтаксис:

• Кожен новий рядок починаємо з # (від 1 до 6 – задає рівень заголовка), якщо це має бути заголовок;
• Починаючи новий рядок вводимо мінімум 3 тире – генерує тег правила <hr /> у HTML, виглядає як суцільна горизонтальна риска;
• Новий рядок починаємо з трьох одиночних зворотніх галочок ` і таким же знаком закриваємо блок – покаже неформатований простий текст між цими знаками:

“`

My content – – –

*Login Secure* >_

Read the policy

“`

• Щоб написати щось жирним, поміщаємо текст у ** вигляду:

**important message**

• Щоб написати щось курсивом, поміщаємо текст у * вигляду:

*A named document*

• Вставка посилання:

[My link](https://www.example.com?search=virtual)

Підтримувані змінні:

{hostname} – FQDN чи IP-адрес

{esxversion} – версія ESXi через крапочки (8.0.0)

{esxproduct} – повне ім’я ESXi з версією та білдом (VMware ESXi 7.0.0 build-16324942)

{client-current-date} – поточна дата для машини користувача (Tuesday, August 30, 2022)

{client-current-time} – поточний час для машини користувача (08:00 AM)

Приклад банеру:

## Warning: Authorized Users Only

Керування параметрами системи у VMware Host Client

У VMware Host Client можемо змінити налаштування хоста таким чином:

1. Клікаємо на Manage в інвентарі, після чого на System;
2. Тиснемо на Advanced settings;
3. ПКМ на шуканий об’єкт у списку і обираємо Edit option з розкривного меню – з’явиться відповідне діалогове вікно;
4. Редагуємо значення і клікаємо Save, щоб застосувати зміни.

За бажанням можемо повернутися до початкових налаштувань, ПКМ на шуканий об’єкт та обравши Reset to default.

Створення привітання у Direct Console User Interface та VMware Host Client

Клікаємо на Manage у інвентарі та на Advanced Settings. А далі для:

• Вітального повідомлення до логіну у DCUI і VMware Host Client: у текстове поле Search вводимо WelcomeMessage і тиснемо на іконку пошуку, ПКМ на Annotations.WelcomeMessage та обираємо з розкривного меню Edit option – з’явиться діалогове вікно, де в текстовому полі New value вводимо текст вітання, клікаємо Save;
• Вітального повідомлення після входу в VMware Host Client: у текстове поле Search вводимо HostClientWelcomeMessage та клікаємо на іконку пошуку, ПКМ на UserVars.HostClientWelcomeMessageта обираємо Edit option з розкривного меню – з’явиться діалогове вікно, де в текстовому полі New value вводимо свій текст, клікаємо Save.

Щоб активувати наше повідомлення шукаємо за аналогією до дій вище UserVars.HostClientEnableMOTDNotification і в полі значення вписуємо 1. Якщо поставити 0 повідомлення деактивується. Також можна повернутися до дефолтних значень, обравши дію Reset to default.

Налаштування таймауту користувацького сеансу VMware Host Client

За замовчуванням сеанс користувача VMware Host Client закривається через 15 хвилин (900с) за неактивності. Це значення можна змінити двома способами.

З Advanced Settings:

1. Клікаємо на Manage в інвентарі та на Advanced Settings;
2. Вводимо в текстове поле Search – HostClientSessionTimeout та клікаємо на іконку пошуку;
3. ПКМ на HostClientSessionTimeout та обираємо Edit option з розкривного меню – з’явиться діалогове вікно;
4. В текстовому полі New value вводимо своє значення в секундах;
5. Клікаємо Save.

Щоб відновити дефолтне значення, обираємо Reset to default.

З розкривного меню User Settings:

1. Клікаємо на ім’я користувача зверху та обираємо Settings > Application timeout;
2. Обираємо час. Щоб деактивувати вихід з сеансу за неактивності обираємо Off.

Налаштування якості паролів та політики блокування акаунту в VMware Host Client

Далі до всіх налаштувань щодо паролів та блокування акаунту будемо діставатися через Manage – Advanced Settings у інвентарі клієнта, увівши в текстове поле Search потрібну характеристику та натиснувши на іконку пошуку, а далі ПКМ на цю опцію та обираємо Edit option з розкривного меню – відкриється діалогове вікно, в якому в полі New value вводимо бажане значення і клікаємо Save. Доступні опції для налаштування:

• Вимог щодо довжини пароля, класу знаків та дозволу на фрази паролю: PasswordQualityControl
• Кількості паролів для запам’ятовування на кожного користувача: PasswordHistory
• Кількість днів, після якої пароль зміниться: PasswordMaxDays
• Кількість неправильних спроб ввести пароль до блокування акаунту: AccountLockFailures
• Час, після якого акаунт користувача буде розблоковано: AccountUnlockTime

Зауваження. Блокування акаунту після певної кількості невдалих спроб ввести пароль за дефолтом стається за 5 спроб поспіль – через 3 хвилини з автоматичним розблокуванням через 15.

Налаштування розширених опцій TLS/SSL ключа

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

1. Клікаємо на Manage у інвентарі та на Advanced Settings;
2. Вводимо в текстовому полі Search шуканий ключ безпеки (див. перелік нижче) та натискаємо на іконку пошуку;
3. ПКМ на ключ та обираємо Edit option з розкривного меню – з’явиться діалогове вікно;
4. В полі New value вводимо значення та клікаємо на Save.

Список доступних ключів безпеки:

• ESXiVPsAllowedCiphers (дефолтне значення – !aNULL:kECDH+AESGCM:ECDH+AESGCM:RSA+AESGCM:kECDH+AES:ECDH+AES:RSA+AES) – дефолтний контрольний рядок шифру
• HostAgent.ssl.keyStore.allowAny (дефолтне значення – False) – можна додати будь-який сертифікат до ESXi CA trust store
• HostAgent.ssl.keyStore.allowSelfSigned (дефолтне значення – False) – можна додати не CA самоподпісні сертифікати до ESXi CA trust store
• HostAgent.ssl.keyStore.discardLeaf (дефолтне значення – True) – відкидає кінцеві сертифікати, додані до ESXi CA trust store.

Налаштування обнулення пам’яті

У VMware Host Client можна скористатися розширеною опцією Mem.MemEagerZero, щоб визначити, як обнуляються сторінки для ВМ та застосунків простору користувача. Щоб обнулити усі виділені ВМ та застосункам простору користувача сторінки, треба виставити її значення на 1. Якщо пам’ять повторно не використовується, цей параметр запобігає розкриттю інформації з ВМ чи застосунків іншим клієнтам, зберігаючи попередній контент в пам’яті. Поки опція встановлена на 1, сторінки обнуляються, поки існує застосунок простору користувача.

Для ВМ такі сторінки обнулюються, якщо ВМ вимкнена, сторінки ВМ змігровані, ESXi відновлює пам’ять ВМ. Щоб налаштувати це, робимо так само через Manage – Advanced Settings, а у рядку пошуку вбиваємо Mem.MemEagerZero. Викликаємо по ньому Edit option і виставляємо бажане значення (дефолтне – 0). Потім зберігаємо налаштування кнопкою Save.

Налаштування опцій автозапуску в VMware Host Client

Щоб встановити, коли хост має запускатися чи зупинятися, робимо таке:

1. Клікаємо на Manage в інвентарі і на System;
2. Клікаємо на Autostart – Edit settings;
3. Обираємо Yes, щоб дозволити зміну конфігурації автостарту і виставляємо бажані значення за наступними опціями:

Start delay – після того, як запуститься хост ESXi, він почне вмикати ВМ, налаштовані на автоматичний запуск. Коли він увімкне першу ВМ, хост чекає вказаний час затримки до увімкнення наступної.

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

Stop action – обирається дія вимкнення, яка буде застосована до ВМ машин на хості, коли хост вимикається:

• System default
• Power off
• Suspend
• Shut down

Wait for heartbeat – обираємо Yes. Цей параметр може використовуватися, якщо в гостьовій ОС ВМ встановлено VMware Tools. Після того, як хост ESXi увімкне першу ВМ, він негайно вмикає наступну. Порядок запуску, у якому вмикаються ВМ, продовжується після того, як ВМ отримає перший heartbeat.

Керування сервісами в VMware Host Client

У клієнті хоста можемо запускати, зупиняти чи перезапускати сервіси на хості та налаштовувати його сервісну політику. Це робиться таким чином:

1. Клікаємо на Manage в інвентарі та на Services;
2. Зі списку сервісів обираємо потрібний;
3. З розкривного меню Actions обираємо дію: Restart, Start чи Stop;
4. Опціонально, з розкривного меню Actions можемо обрати Policy та опцію для сервісу з меню: Start and stop with firewall ports / Start and stop with host / Start and stop manually.

GUI vCenter Server Management Interface

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

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

Щоб зайти в цей GUI, маємо вбити в браузері https://appliance-IP-address-or-FQDN:5480 та ввести дані облікового запису root (дефолтний пароль – то є той, що задавали, коли розгортали vCenter Server).

Виключити чи перезавантажити vCenter Server можемо, якщо клікнемо в GUI на Summary і з верхнього меню розкриємо меню Actions, де оберемо дію Shutdown чи Reboot, відповідно. У діалоговому вікні підтвердження клікаємо на Yes.

Увімкнути чи вимкнути доступ за SSH та vCenter Server Bash оболонкою можна, якщо у GUI клікнути на Access, а потім на Edit, де будуть наступні налаштування: Enable SSH login, Enable DCUI, Enable Console CLI, Enable Bash Shell. Після чого тиснемо на ОК, щоб зберегти їх.

Змінити пароль користувача root та дату його спливання можна так:

1. Клікаємо на Administration;
2. У секції Password тиснемо Change;
3. Вводимо поточний пароль та новий й клікаємо Save;
4. Переходимо у секцію Password expiration settings, клікаємо на Edit та обираємо політику спливання строку дії пароля: Yes (потрібно буде зазначити Root password validity (days) – к-сть днів строку дії пароля та Email for expiration warning – електронну адресу, на яку надіслати попередження про наближення дати спливу) або No (ніколи не спливе);
5. Клікаємо Save для збереження.

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

У статті «Інсталяція vSphere 8.0 з нуля» в останніх розділах, присвячених первинним налаштуванням нашого нововстановленого середовища, ми розглядали, як за допомогою клієнта хоста встановити синхронізацію часу між хостами. Але дещо в цьому напрямку обов’язково треба зробити й у інтерфейсі керування нашим vCenter. А саме:

1. Клікаємо в GUI на Time;
2. В панелі Time zoneклікаємо на Edit і з розкривного меню Time zone обираємо локацію чи часову зону, після чого зберігаємо налаштування кнопкою Save;
3. У панелі Time synchronization клікаємо на Edit і з розкривного меню Mode обираємо метод синхронізації часу: Disabled (без синхронізації часу – використовуватиметься системна часова зона), Host (вмикає синхронізацію часу VMware Tools – синхронізуватиметься з часом ESXi-хоста), NTP (вмикає NTP-синхронізацію – треба ввести ІР-адресу чи FQDN одного або більше NTP-серверів);
4. Зберігаємось по Save.

Запуск, зупинка та перезапуск служб vCenter Server 

З vCenter Server Management Interface можемо спостерігати за статусом компонентів vCenter Server та робити з ними різні дії. Для цього нам треба пройти на Services – продемонструє сторінку з проінстальованими службами, відсортованими за іменем, типом запуску, працездатністю та статусом. Тут просто обираємо потрібний сервіс і можемо:

• Для налаштування автоматичного або мануального запуску тиснемо на SET STARTUP TYPE – Manual/Automatic;
• Для запуску сервісу – клікаємо на START;
• Для зупинки – на STOP;
• Для перезапуску – на RESTART,

і підтверджуємо свою дію кнопкою ОК.

Налаштування оновлень

Як безпосередньо оновлюватись, ми розглядали у підрозділі «Процедура оновлення vCenter Server» статті «Оновлення VMware vSphere до версії 8.0». Але щоб на майбутнє зручно налаштувати процеси патчування та ознайомлення з доступністю нових версій, а також самих оновлень, у vCenter Server Management Interface можна пройти в Update і обрати Settings, де:

• Поставити галочку в відповідний чекбокс, щоб здійснювало автоматичну перевірку на апдейти;
• Обрати дефолтний чи користувацький репозиторій, звідки можна забирати оновлення (у другому випадку обов’язково вводимо відповідний URL та, опціонально, ім’я користувача з паролем, щоб цією функцією не зміг скористатися ніхто, окрім нас).

Усі налаштування зберігаються кнопочкою Save.

До речі, тут же можна в будь-який момент і вручну перевірити наявність оновлень, клікнув на Check Updates з розкривного меню, та обравши CD-ROM чи CD-ROM + URL.

Налаштування мережі у vCenter Server Management Interface

Коли ми минулого разу розгортали appliance нашого vCenter, ми задавали первинні налаштування мережі, і тоді казали, що потім до конфігурування можна буде повернутися згодом – за допомогою vCenter Server Management Interface. Для цього в відповідному GUI є ціла спеціальна панель – Networking, на якій, якщо натиснути на Edit, можна:

• Налаштувати DNS – розкриваємо секцію Hostname and DNS, можемо обрати Obtain DNS settings automatically, щоб отримувати налаштування DNS з мережі автоматично, або Enter DNS settings manually – в цьому випадку доведеться вручну ввести IP-адресу бажаного DNS-сервера та, опціонально, альтернативного;
• Налаштувати шлюз – розкриваємо секцію NIC0;
• Відредагувати параметри IPv4-адреси – Enable or Disable IPv4 settings, Obtain IPv4 settings automatically чи Enter IPv4 settings manually (автоматично отримувати IPv4-адресу для appliance з мережі чи вручну її вводити, надавши IP-адресу, довжину префіксу підмережі та дефолтний шлюз);
• Відредагувати параметри IPv6-адреси – Enable or Disable IPv6 settings, Obtain IPv6 settings automatically through DHCP чи Obtain IPv6 settings automatically through router advertisement (отримувати IPv6-адреси для appliance автоматично з мережі через DHCP або за поданням роутера), а також можна задати Use static IPv6 addresses – для ручного вводу статичної IPv6-адреси після відмітки галочкою відповідного блоку;
• Налаштувати проксі-сервер у секції Proxy Settings кнопкою Edit – тут включаємо потрібну опцію: HTTPS, FTP чи HTTP.

І, нарешті, можемо ввести ім’я хоста для сервера чи IP-адресу, порт та, опціонально, ім’я користувача та пароль. Після чого вся змінена конфігурація зберігається кнопкою Save.

У панелі Networking дією Edit ще можемо змінити FQDN, IP чи PNID керуючої мережі vCenter Server. Зауваження. Системне ім’я використовується як первинний мережевий ідентифікатор (PNID). Якщо при первинній інсталяції ми колись ідентифікували наш vCenter Server за IP-адресою, згодом можемо змінити PNID на FQDN.

Важливо! Якщо в нас вже є працюючий vCenter High Availability (HA), перед зміною PNID його треба вимкнути.

Отже:

1. Проходимо в потрібну NIC та клікаємо на Next;
2. На пункті Edit Settings міняємо ім’я хоста та надаємо нову IP-адресу. Next;
3. У пункті SSO Credentials зазначаємо дані облікового запису адміністратора SSO (administrator@<domain_name>);
4. У пункті Ready to Complete проглядаємо налаштування та ставимо галочку в тому, що обізнані з необхідністю зробити бекап, після чого клікаємо на Finish.

Тепер на Networking побачимо нове ім’я хоста та нову IP-адресу.

Налаштування фаєрволу

У vCenter Server Management Interface можемо редагувати параметри фаєрволу vCenter Server та створювати його правила, щоб, наприклад, дозволяти чи блокувати трафік між vCenter Server та певними серверами, хостами чи ВМ. Проте, зауважте, що блочимо ми саме весь трафік – не вказані порти!

У GUI проходимо в Firewall і:

• Щоб створити правило фаєрволу, клікаємо на Add (обираємо мережевий інтерфейс ВМ, вводимо IP-адресу мережі, до якої треба застосувати це правило, довжину префіксу підмережі, а з розкривного меню Action обираємо потрібну дію – Accept, Ignore, Reject чи Return). Зберігаємо налаштування кнопкою Save;
• Щоб відредагувати існуюче правило – обираємо правило, що цікавить, й тиснемо на Edit, міняємо налаштування та зберігаємось по Save;
• Щоб видалити правило – обираємо його в списку та клікаємо на Delete. І ще раз у вікні підтвердження;
• Щоб змінити порядок застосування правил – обираємо потрібне правило й клікаємо на Reorder, у відповідній панелі обираємо правило й клікаємо на Move Upчи Move Down, щоб перемістити його вище або нижче за списком. Зберігаємось кнопкою Save.

Управління об’єктами інвентаря vCenter

Великі середовища vSphere можуть містити декілька віртуальних дата-центрів зі складним упорядкуванням хостів, кластерів, пулів ресурсів та мереж. Причому таких систем vCenter може бути набагато більше одної. Тому дуже важливо прискіпливо й комплексно підходити до задач організації та заповнення інвентаря. У загальному випадку вони виглядають так:

1. Створюємо дата-центри;
2. Створюємо кластери задля консолідації ресурсів багатьох хостів та ВМ;
3. Додаємо хости до кластерів чи до дата-центрів;
4. Організуємо об’єкти інвентаря в папки;
5. Налаштовуємо мережу, використовуючи стандартні світчі vSphere чи vSphere distributed switch;
6. Налаштовуємо системи сховищ та створюємо об’єкти інвентаря датастора, щоб надавати логічні контейнери для пристроїв сховища у інвентарі.

Об’єкти – то є сутності, з якими можуть виконуватися певні дії. Вони включають дата-центри, папки, кластери, хости, датастори, мережі та ВМ.

Робота з дата-центрами та папками

Дата-центр – це логічна організація усіх об’єктів інвентаря. Задля організації наборів середовищ можна створювати декілька дата-центрів. Кожен з них може мати свої власні хости, віртуальні машини, шаблони, сховища даних та мережі.

Папки, як ми вже зауважували вище, дозволяють групувати об’єкти однакового типу задля полегшення керування.

Створення дата-центру та папок

Щоб додати дата-центр або папку потрібно у клієнті vSphere ПКМ на існуючу систему vCenter та в діях обрати відповідний крок:

Можна створити папку і у існуючому дата-центрі – так само ПКМ на нього в інвентарі і обираємо дію New Folder:

Обидві дії можна робити на будь-якому об’єкті vCenter Server, проте з дата-центрами працюємо на вкладці Hosts and Clusters, а от папки можна створювати і у Network, і у Storage, а також у VM and Template.

Додавання хоста до папки чи дата-центру

Щоб додати хост ESXi до системи vCenter, потрібно ПКМ на папку (якщо є) або напряму на дата-центр та обрати в діях Add Host, після чого пробігтися простеньким помічником, як показано на скріншоті:

Створення категорій тегів та тегів для об’єктів інвентаря

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

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

1. Проходимо в Tags & Custom Attributes з головного меню клієнта;
2. Клікаємо на вкладку Tags і на Categories та обираємо потрібну дію: або клікаємо на New і тоді будемо створювати нову категорію, або на Edit, обравши потрібну категорію, щоб відредагувати вже існуючу;
3. Задаємо ім’я категорії (унікальне для обраної системи vCenter Server), опис, обираємо потрібне в Tags Per Object (якщо обрати One Tag, можна буде застосовувати тільки один тег з цієї категорії до об’єкту, а якщо Many tags – більше одного).

Важливо! Після обрання Tags Per Object можна міняти One Tag на Many Tags, але не навпаки.

В Associable Object Types обираємо, чи хочемо, щоб теги з цієї категорії застосовувалися до всіх об’єктів чи тільки до вказаного типу об’єктів.

Важливо! Якщо обрали один тип об’єктів, пізніше можна змінити застосування на «до всіх», але якщо від початку обрали «до всіх», обмеження задати надалі буде неможливо.

4. Клікаємо на Create чи Save, в залежності від того, створюємо нову категорію, чи редагуємо існуючу.

Щоб видалити існуючу категорію на нашій вкладці Categories обираємо категорію зі списку та клікаємо на Delete – відкриється діалогове вікно Delete Category, де тиснемо на Delete.

Щоб створити новий чи відредагувати старий тег, проходимо у Tags & Custom Attributes – вкладка Tags та клікаємо на Tags, і далі:

1. Якщо хочемо створити новий тег, клікаємо на New, якщо відредагувати – обираємо відповідний й на Edit;
2. У діалоговому вікні вводимо ім’я тегу (до 256 знаків);
3. Вводимо опис;
4. Вказуємо категорію, якщо створюємо новий, обравши існуючу з розкривного меню Category, або клікаємо на Create New Category – пророблюємо усе, про що йшлося вище, і потім обираємо тут вже її;
5. Тиснемо на Createабо Save, залежно від того, чи створюємо, чи редагуємо.

Видалити непотрібний тег можна там же, якщо обрати його зі списку (можна одразу декілька) й натиснути на Delete, а потім ще раз на Delete у вікні підтвердження.

Призначити тег об’єкту з інвентаря можна, ПКМ на нього й у діях обравши пункт Tags&Custom Attributes:

Дозволи для роботи з тегами та категоріями тегів

Процедура надання дозволів користувачам для роботи з тегами та категоріями тегів ідентична. До неї можна вдатися як на етапі створення тегу/категорії, так і пізніше, відредагувавши відповідне. Робиться це на вкладці Tags в Tags & Custom Attributes, де тиснемо Tags чи Categories, залежно від того, до чого хочемо додати дозвіл. У списку обираємо потрібний об’єкт та клікаємо на Add Permission – з’явиться діалогове вікно, в якому обираємо домен з розкривного меню і далі користувача чи групу, і, нарешті, роль з розкривного меню. Якщо хочемо поширити дозвіл на дочірні об’єкти, ставимо галочку в Propagate to children. Зберігаємо налаштування кнопкою ОК.

Керування хостами ESXi через VMware Host Client

Усі базові операції з ESXi-хостами можна робити через VMware Host Client. Це актуально не тільки для «одиноких» хостів поза системою vCenter, а й для тих, що керуються ним, адже не завжди ми маємо доступ до клієнту vSphere з певних причин, з недоступністю vCenter Server включно. Розберемо їх найвживаніші примірники.

Занурення хоста в режим maintenance

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

Важливо! Усі ВМ до входження хоста в режим техобслуговування потрібно або перемістити на інші хости, або вимкнути (допомогти у цьому може DRS, про який в подробицях будемо говорити нижче у відповідному підрозділі).

Для здійснення операції просто ПКМ на шуканий хост та обираємо Enter maintenance mode. Щоб вийти з режиму maintenance, робимо те саме, тільки обираємо Exit maintenance mode.

Перезапуск чи вимкнення ESXi-хоста

Для перезавантаження чи вимкнення хоста потрібні привілеї Host.Configuration.Maintenance та Global.Log event.

Важливо! До вимкнення чи перезапуску хоста обов’язково вимкніть усі ВМ на ньому та помістіть його в режим maintenance.

Робиться це дуже просто:

1. ПКМ на хост та обираємо Shut down hostчи Reboot host, залежно від потрібної дії;
2. Клікаємо на Shut downчи Reboot для запуску процедури.

Керування хостами ESXi через vSphere Client

Вище ми вчилися виконувати базові операції з хостами через VMware Host Client, але якщо вони не standalone та є доступ до нашого vCenter Server, звичайно, зручніше й простіше усе з ними робити через звичний клієнт vSphere. Пробіжимося цими операціями швиденько.

Відключення, перепідключення, перезавантаження та вимкнення хоста

Щоб відключити хост, що керується vCenter Server, йдемо в інвентарі на вкладку Hosts and Clusters, шукаємо потрібний хост, ПКМ на нього та обираємо Connection > Disconnect з меню, що спливло. З’явиться вікно підтвердження, де тиснемо на ОК.

Щоб знову підключити хост, робимо те саме, але в меню, що з’явилося, замість Disconnect обираємо, звичайно, Connect.

Щоб перезавантажити чи вимкнути хост, у Hosts and Clusters обираємо його і з меню Actions тиснемо на Power, а далі на потрібну операцію – або Reboot, або Shut Down, відповідно. Тиснемо ОК після надання причини, через що до цього вдалися.

Переміщення хоста

Щоб перемістити хост в іншу локацію в інвентарі vSphere:

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

1. Проходимо в Hosts and Clusters та обираємо потрібний хост. Якщо він є частиною кластеру, занурюємо його в режим техобслуговування – ПКМ на нього та обираємо Maintenance Mode > Enter Maintenance Mode. Опціонально, якщо хост є частиною DRS-кластеру, евакуюємо чи позначаємо як suspended ВМ, поставивши галочку в Move powered-off and suspended virtual machines to other hosts in the cluster. Підтверджуємо наш намір у діалоговому вікні, клікнув на ОК;
2. Затискаємо мишею наш хост в інвентарі й перетаскуємо його в нову локацію;
3. ПКМ на хост та обираємо Maintenance Mode > Exit Maintenance Mode;
4. Опціонально, можна увімкнути вимкнені ВМ.

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

Видалення хоста з vCenter Server

Щоб видалити керований vCenter Server хост з його системи та зупинити його моніторинг та керування, потрібно:

1. У Hosts and Clusters обираємо потрібний хост та, опціонально, уводимо його в режим maintenance (див. операцію вище);
2. ПКМ на хост та обираємо Remove from Inventory з меню, що спливло;
3. У вікні підтвердження тиснемо на Yes.

Зауваження. Разом з хостом з vCenter Server видаляться й усі асоційовані з ним ВМ. Асоційований процесор та ліцензії міграції повернуться у статус доступних.

Управління акаунтами користувачів

Акаунти користувачів необхідні для доступу до ESXi-хостів чи систем vCenter. З точки зору безпеки при їх призначенні слід враховувати наступні поради:

• Суворо контролюйте доступ root до хостів ESXi;
• Створюйте надійні паролі облікових записів root, з щонайменше вісьмома знаками, враховуючи спецсимволи, літери як великі, так і маленькі, цифри. Періодично змінюйте їх;
• Керуйте хостами ESXi централізовано через vCenter Server за допомогою клієнта vSphere;
• Зведіть до мінімуму використання локальних користувачів на хостах ESXi. Найліпше буде додати хости ESXi до домену та увести відповідних адміністраторів до групи домену ESX Admins. Користувачі в групі домену мають привілеї root на хостах ESXi.

Використання системи контролю доступу користувачів до об’єктів інвентаря vCenter дозволяє адміністраторові визначати, кому надавати відповідні привілеї та окреслювати горизонт задач, що можуть виконуватися на об’єкті:

Привілеї – це дії, що можуть бути вчинені.

Роль – то є набір привілеїв.

Користувач/група користувачів – індикація особи/осіб, що може виконувати дію.

Дозвіл – надання користувачеві/групі користувачів ролі (набору привілеїв) для обраного об’єкта.

Наприклад, якщо групі користувачів потрібно надати дозвіл на налаштування пам’яті для хоста, обираємо хост та додаємо дозвіл, що надає цій групі роль з  привілеєм Host.Configuration.Memory Configuration.

Робота з ролями

У головному меню клієнта vSphere («три рисочки», лівий верхній кут інтерфейсу) у блоці Access Control є пункт Roles. Якщо встати на нього в робочій панелі з’явиться список існуючих ролей з чотирма функціональними кнопками зверху: NEW, CLONE, EDIT та DELETE. Якщо клікнемо по якійсь ролі, справа будуть показані три вкладки з інформацією по цій ролі (DESCRIPTION, USAGE, PRIVILEDGES):

Вкладка USAGE показує, які користувачі призначені обраній ролі щодо конкретного об’єкта:

Декілька ролей є системними й міняти їх заборонено. Це:

• Administrator (повні дозволи на об’єкт з усіма діями та переглядом),
• Read-only (тільки перегляд статусу та інформації щодо об’єкту),
• No access (заборонено перегляд та дії щодо об’єкту),
• No cryptography administrator (те саме, що Administrator, але без операцій категорії Cryptographic).

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

При створенні нової ролі рекомендується називати її вичерпно інформативно.

Усі ролі є незалежними одна від одної, не існує ієрархії ролей чи спадковості між ними.

Важливо! Для покращення безпеки та контролю над середовищем, визначення ролі має містити найменшу можливу кількість привілеїв.

Робота з дозволами

Якщо встати на будь-який об’єкт інвентаря, серед вкладок правої робочої частини буде Permissions, що показує, які користувачі чи їх групи та ролі є асоційованими з обраним об’єктом:

Щоб призначити дозволи якомусь об’єкту, потрібно натиснути нижче вкладок кнопку ADD і у вікні, що з’явиться, обрати домен (Domain), користувача/групу (User/Group) та роль (Role):

Опціонально, можна поставити галочку у Propagate to children, щоб поширити дозвіл на дочірні об’єкти. Якщо її не поставити, дозвіл зачепить лише вказаний об’єкт. Щодо застосування дозволів, на практиці, можливі декілька сценаріїв:

1. Ми поширили дозвіл з вищого об’єкту в ієрархії інвентаря, але на певному нижчому об’єктові перезаписали дозволи так, щоб вони відрізнялись (наприклад, по всьому дата-центру у користувача дозвіл Read-only, а от на одній з віртуалок в ньому – Administrator);
2. Ми призначили об’єднання привілеїв групі для певного об’єкту, але користувач є членом декількох груп з дозволами на цьому об’єктові (наприклад, якщо один користувач є членом Group1 та Group2, він зможе робити усі відмічені в ролі дії для всіх об’єктів дата-центру, коли дата-центру призначені обидва дозволи);
3. Ми застосували однакові дозволи до кожного об’єкта, на який група має дозволи, таким чином, як безпосередньо б надали їх користувачеві, що входить до кількох груп з дозволами на різні об’єкти (наприклад, якщо ми Group1 призначаємо роль Administrator на дата-центрі, а Group2 – Read-only на певній одній машині, а дозвіл для Group1 налаштували так, щоб він поширювався і на дочірні об’єкти, то користувач-член обох груп матиме роль Administrator для всього дата-центру, за винятком отієї ВМ);
4. Ми визначаємо дозволи явно для користувача на об’єкті, що має пріоритет над всіма груповими дозволами на цьому об’єктові, незалежно від того, що користувач є членом тих груп. Тобто користувачеві/групі надається тільки одна роль для будь-якого даного об’єкту.

Глобальні дозволи

Глобальні дозволи підтримують призначення привілеїв по всім рішенням (усім інстансам vCenter, vRealize Orchestrator тощо) з глобального кореневого об’єкту. В результаті користувач чи їх група матимуть привілеї повного перегляду та повного переліку дій щодо усіх об’єктів у всіх ієрархіях vCenter:

Доступ до глобальних дозволів отримуємо з того ж головного меню vSphere Client: у Access Control другим пунктом йде Global Permissions.

Керування користувачами та безпекою для хоста ESXi за допомогою VMware Host Client

Коли ми напряму підключаємось до ESXi-хоста через VMware Host Client, акаунти root і vpxuser мають однакові права доступу, як будь-який користувач з роллю Administrator для всіх об’єктів. Усі інші користувачі не мають жодних дозволів при першому контакті з середовищем, тобто не можуть робити ніяких дій з об’єктами, але Administrator може надати їм дозволи для того, щоб почати налаштовувати та розбудовувати систему.

Призначення дозволів користувачеві для ESXi-хоста

1. ПКМ на Hostу інвентарі VMware Host Client та клікаємо на Permissions – з’явиться вікно Manage Permissions;
2. Клікаємо на Add user;
3. З текстового поля Select a user обираємо потрібного користувача;
4. Клікаємо на стрілочку поряд з текстовим полем Select a role та обираємо роль зі списку;
5. Опціонально, можна обрати Propagate to all children(щоб роль поширилася на усі дочірні об’єкти) чи Add as group;
6. Клікаємо на Add user, а потім на Close.

Видалення дозволу користувача для ESXi-хоста

1. ПКМ на Hostу інвентарі VMware Host Client та на Permissions – відкриється вікно Manage permissions;
2. Обираємо потрібного користувача зі списку та клікаємо на Remove user;
3. Натискаємо Close.

Призначення дозволів користувачеві для ВМ

1. Клікаємо Virtual Machines в інвентарі VMware Host Client;
2. ПКМ на ВМ зі списку та обираємо Permissions – з’явиться вікно Manage permissions;
3. Клікаємо на Add user;
4. Тиснемо на стрілочку поряд з текстовим полем Select a user і обираємо користувача;
5. Клікаємо на стрілочку поряд з текстовим полем Select a role і обираємо роль зі списку;
6. Опціонально, можна обрати Propagate to all children, щоб дозвіл поширився на дата-центри, папки, кластери, хости, ВМ та схожі об’єкті у інстансі vCenter Server;
7. Клікаємо на Add user, а потім на Close.

Видалення дозволів користувача для ВМ

1. Клікаємо на Virtual Machinesв інвентарі VMware Host Client;
2. ПКМ на ВМ зі списку та обираємо Permissions – відкриється вікно Manage permissions;
3. Обираємо користувача зі списку та клікаємо Remove user;
4. Клікаємо на Close.

Автентифікація у vSphere

Необхідні теоретичні знання щодо технологій автентифікації у vSphere можна узяти з підрозділу «Сервіси аутентифікації vCenter» згадуваного нами матеріалу. А зараз пробіжимося головними операціями, які нам доведеться вчиняти як адміністратору середовища щодо керування сертифікатами та vCenter Single Sign-On.

Операції з сертифікатами безпеки vSphere

Керувати сертифікатами безпеки vSphere можна з клієнта vSphere, за допомогою vSphere Automation API, утиліти Certificate Management (інструмент командного рядка, що підтримує генерацію Certificate Signing Request (CSR) та заміщення сертифікатів) та CLI. Далі працювати будемо з GUI та CLI як найдоступнішими та найнаочнішими навіть для новачків.

Керування сертифікатами vCenter за допомогою vSphere Client

З клієнта vSphere заходимо на vCenter Server як користувач з привілеями адміністратора в локальному домені vCenter Single Sign-On (дефолтний домен – vsphere.local). Якщо у Administration під Certificates клікнути на Certificate Management, відкриється панель керування сертифікатами, де можна виконувати з ними різні дії, оновлювати SSL-сертифікати машин, додавати сертифікат Trusted Root тощо. Тут можна проглянути інформацію щодо усіх сертифікатів, що містяться в певному сховищі, та деталі кожного, якщо обрати його в списку і клікнути на View Details.

По кожному сертифікатові доступне меню Actions, що допоможе оновити чи замістити його, видалити і т. д. Розглянемо приклади декількох часто вживаних операцій.

По-перше, дуже корисним буде встановити поріг, на якому система почне нас засипати попередженнями щодо збігу строку того чи іншого сертифікату. Це робиться по об’єкту vCenter Server:

1. Заходимо на Configure і клікаємо на Advanced Settings;
2. Натискаємо Edit Settings і фільтруємо вивід за «threshold»;
3. Міняємо значення cert.threshold на бажане та клікаємо на Save.

Оновити VMCA-підписані сертифікати означає замістити VMCA-підписаний сертифікат аналогічним новим. Для цього (треба зайти під адміністратором з групи vCenter Single Sign-On):

1. Як описано вище проходимо на Certificate Management;
2. Вводимо дані облікового запису, якщо система попросить;
3. З блоку Machine SSL Certificate клікаємо на Actions > Renew;
4. Вказуємо в днях строк дії сертифікату;
5. Клікаємо на Renew.

Сервіси vCenter Server перезапустяться автоматично, після чого можна буде повторно входити в систему й працювати далі.

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

• Генерація запиту на підпис сертифікату для машинного SSL-сертифікату. Під плашкою Machine SSL Certificate клікаємо на Actions > Generate Certificate Signing Request (CSR), вводимо інформацію про наш сертифікат й клікаємо Next, копіюємо чи завантажуємо CSR, тиснемо на Finish та представляємо новий CSR нашому СА.
• Додавання довіреного кореневого сертифікату до сховища сертифікатів. Під Trusted Root Certificates клікаємо на Add, потім – на Browse, щоб обрати місцезнаходження ланцюжка сертифікату (можна скористатися файлами типу CER, PEM чи CRT), далі клікаємо на Add.
• Додавання користувацьких сертифікатів. Під плашкою Machine SSL Certificate клікаємо на Actions > Import and Replace Certificate, і обираємо одну з трьох опцій, що пасує до нашого випадку (Replace with VMCA – створити сгенерований VMCA CSR для заміщення поточного / Replace with certificate generated from vCenter Server – використати створений vCenter Server / Replace with external CA certificate (requires private key) – зовнішнім СА-підписаним), вводимо інформацію CSR чи завантажуємо відповідний сертифікат та тиснемо на Replace.

Керування сертифікатами vCenter через CLI

Щодо методу через CLI, ось перелік команд, що стосуються роботи з сертифікатами та доменом SSO (до речі, він справиться з задачами, що не підтримуються GUI клієнта, а також з ними можна створювати задля зручності й автоматизації рутинних справ власні скрипти для середовища):

• сertool – створити та керувати сертифікатами й ключами. Частина VMware Certificate Authority (VMCA). Команда генерації Certificate Signing Request (CSR) – PKCS10–файлу та приватного ключа може мати вигляд:

certool –gencsr –privkey=<filename> –pubkey=<filename> –csrfile=<filename>

де –-gencsr вимагається для генерації CSR, –privkey <key_file> – ім’я файлу приватного ключа, —pubkey <key_file> – ім’я файлу публічного ключа, а –csrfile <csr_file> – ім’я файлу для файлу CSR для надсилання CA-провайдеру. Ще може бути опція –config <config_file> – опціональне ім’я для конфігураційного файлу (дефолтне – certool.cfg).

Для створення самопідписаного сертифікату та надання VMCA-серверу з самопідписаним кореневим СА можна написати щось на кшталт такого:

machine-70-59:/usr/lib/vmware-vmca/bin # ./certool –predate=2280  –selfca –server= 192.0.2.24 –srp-upn=administrator@vsphere.local

де –-selfca – вимагається для генерації самопідписаного сертифікату, –predate <number_of_minutes> дозволяє встановлювати поле Valid Not Before кореневого сертифікату до вказаної к-сті хвилин до поточного часу (корисно задля вирішення потенційних проблем з часовими зонами, максимум – 3 дні), –config <config_file> – опціональне ім’я для конфігураційного файлу (дефолтне – certool.cfg), –server <server> – опціональне ім’я для серверу VMCA (за дефолтом користується localhost).

Для імпорту кореневого сертифікату використовується команда certool –-rootca, наприклад, отак:

certool –rootca –cert=root.cert –privkey=privatekey.pem

де опція –-rootca якраз і відповідає за імпорт, –cert <certfile> – то є ім’я файла сертифікату, –privkey <key_file> – ім’я файлу приватного ключа (у PEM-закодованому форматі), а –server <server> – опціональне ім’я VMCA-серверу (дефолтне – localhost).

Повертає дефолтне доменне ім’я, що використовується vmdir команда certool –-getdc (опціонально можна додати –server <server> та –port <port_num> для імені VMCA-серверу та номеру порта, дефолтний – 389).

Також можна попросити систему зачекати, поки VMware Directory Service працює, чи VMCA-сервіс, що корисно задля внесення у розклад задач, командами

certool –waitVMDIR –wait 5

або

certool –waitVMCA –selfca

І, нарешті, команда certool –publish-roots силоміць оновлює кореневі сертифікати (привілеї адміністратора), і до неї опціонально можна додати ім’я VMCA-сервера: certool –publish-roots

Також корисними будуть команди:

• • Генерація приватного та публічного ключів (certool –-genkey):

certool –genkey –privkey=<filename> –pubkey=<filename>

• • Генерація сертифікату з VMCA-серверу (certool –gencert):

certool –gencert –privkey=<filename> –cert=<filename>

• • Вивести на друк поточний СА-сертифікат у читабельному для людини форматі (certool –getrootca) – вивід не придатний до сертифікату:

certool –getrootca –server=remoteserver

• • Роздрукувати усі поля сертифікату в читабельному форматі (certool –viewcert):

certool –viewcert –cert=<filename>

• • Вивести списком усі сертифікати, про які знає VMCA-сервер, можна ввести опцію фільтру, щоб задати all чи active (certool –enumcert):

certool –enumcert –filter=active

• • Послати вказаний сертифікат на VMCA-сервер, щоб перевірити, чи анульований сертифікат (certool –status). Вивід міститиме «Certificate: REVOKED» чи «Certificate: ACTIVE»:

certool –status –cert=<filename>

• • Згенерувати самопідписаний сертифікат, спираючись на значення конфігураційного файлу (створює на 3 дні раніше, щоб уникнути проблем з часовими зонами) (certool –genselfcacert):

certool –genselfcert –privkey=<filename> –cert=<filename>

• vecs-cli – керує інстансами VMware Certificate Store (VECS). Разом з certool (див. вище) і dir-cli (далі буде) дає повний спектр дій для керування інфраструктурою сертифікатів та сервісів автентифікації. Команди цього сімейства:
  • Створити сховище сертифікатів (vecs-cli store create), можна з опцією –server <server-name>, якщо треба вказати ім’я серверу при підключенні до віддаленого інстансу VECS):

vecs-cli store create –name <store>

• • Видалити сховище сертифікатів (vecs-cli store delete):

vecs-cli store delete –name <store>

• • Вивести список сховищ сертифікатів:

vecs-cli store list

• • Надає чи скасовує дозволи до сховища сертифікатів в залежності від додавання опції –grantчи –-revoke, відповідно (vecs-cli store permissions):

vecs-cli get-permissions –name <store-name>

і щоб дати дозволи певному користувачеві додаємо опцію –user <username> і –grant [read|write] – саме на читання чи на запис

• • Щоб отримати поточні налаштування дозволів для сховища:

vecs-cli store get-permissions

• • Створити запис у VECS – використовується для додання приватного ключа чи сертифікату до сховища:

vecs-cli entry create

використовується з опціями: –store <NameOfStore>, –cert <certificate_file_path>, –key <key-file-path>, –password <password> (опціонально), –server <server-name> та –upn <user-name>

• • Виводить списком усі записи у вказаному сховищі:

vecs-cli entry list

• • Отримує сертифікат з VECS – можна послати його на файл виводу чи показати як читабельний текст:

vecs-cli entry getcert

з опціями –store <NameOfStore>, –output <output_file_path> (вивід у файл), –text (вивід у читабельний текст), –server <server-name>, –upn <user-name>

• • Отримує ключ, що зберігається у VECS – можна послати в файл чи показати як читабельний текст:

vecs-cli entry getkey

• • Видалити запис в сховищі сертифікатів:

vecs-cli entry delete

• • Силоміць оновити VECS:

vecs-cli force-refresh

• dir-cli – підтримує створення та оновлення користувачів рішення, керування акаунтами та керування сертифікатами й паролями в VMware Directory Service (vmdir). Корисні команди:
  • Вивід списком усіх систем vCenter Server, підключених у enhanced linked mode:

dir-cli nodes list

з опціями –login <admin_user_id>, –password <admin_password> та –server <psc_ip_or_fqdn> (для підключення до іншого vCenter Server, щоб побачити його партнерів по реплікації)

• • Скинути пароль машинного акаунту в домені:

dir-cli computer password-reset

з опціями –login <admin_user_id>, –password <admin_password> та –live-dc-hostname <server name> (поточне ім’я інстансу vCenter Server)

• • Створити користувача рішення:

dir-cli service create

з опціями –name <name>, –cert <cert file>, –ssogroups <comma-separated-groupnames> (зробити генерованого користувача членом вказаних груп), –wstrustrole <ActAsUser> (членом вбудованої групи адміністраторів чи користувачів – чи буде він мати привілеї адміністратора), –ssoadminrole <Administrator/User> (простим користувачем), –login <admin_user_id>, –password <admin_password>

• • Вивід списком користувачів рішення (з заданням логіну та паролю адміністратора SSO):

dir-cli service list

• • Видалити користувача рішення в vmdir (з вказанням -–name та облікових даних адміністратора):

dir-cli service delete

• • Оновити сертифікат для вказаного користувача рішення (після цієї команди треба запустити vecs-cli entry create, щоб оновити запис сертифікату у VECS):

dir-cli service update

• • Створити звичайного користувача всередині vmdir:

dir-cli user create

з опціями –account <name>, –user-password <password>, –first-name <name>, –last-name <name>, дані облікового запису адміністратора

• • Змінити вказаного користувача усередині vmdir:

dir-cli user modify

з опціями –account <name>, –password-never-expires чи –password-expires та даними облікового запису адміністратора

• • Видалити вказаного користувача всередині vmdir:

dir-cli user delete

• • Знайти користувача всередині vmdir за іменем. Вказується –level <info level 0|1|2>, де Level 0 – акаунт та UPN, Level 1 – те, що в level 0 + прізвище з ім’ям, Level 2 – це level 0 + прапорці у Account deactivated, Account locked, Password never expires, password expired та password expiry. Дефолтний рівень – 0:

dir-cli user find-by-name

• • Додати користувача чи групу до існуючої групи:

dir-cli group modify

з опціями –name <name>, –add <user_or_group_name> та даними облікового запису адміністратора

• • Вивід списком вказаної групи vmdir:

dir-cli group list

• • Створити групу усередині локального домену (дефолтний – local):

dir-cli ssogroup create

з опціями –name <name>, –description <description> та даними облікового запису адміністратора

• • Опублікувати довірений кореневий сертифікат до vmdir (VECS підхопить зміни через хвилину, чи можна його примусово оновити, як показували вище):

dir-cli trustedcert publish

з опціями –cert <file> (шлях до файлу сертифікату) та обліковими даними адміністратора SSO

• • Скасувати публікацію довіреного кореневого сертифікату:

dir-cli trustedcert unpublish

• • Вивести списком довірені кореневі сертифікати та їхні відповідні ID:

dir-cli trustedcert list

• • Отримати довірений кореневий сертифікат з vmdir та записати його у вказаний файл:

dir-cli trustedcert get

з опціями –id <cert_ID>, –outcert <path> (шлях до файлу, куди треба записати), облікові дані адміна

• • Створити довільний пароль, що задовольняє вимогам:

dir-cli password create

• • Скинути пароль користувача. Якщо це робить адміністратор, то вводимо команду:

dir-cli password reset

якщо користувач без привілеїв адміністратора, то dir-cli password change, з опціями –account, –new (новий пароль) та обліковими даними адміністратора (для першого випадку), і в другому випадку перед новим паролем треба буде зазначити -–current – поточний.

• sso-config – оновлює сертифікати Security Token Service (STS), нижче про неї поговоримо.
• service-control – команда для запуску, зупинки та виводу списком сервісів. Її треба запускати перед тим, запускати інші команди CLI.

Керування автентифікацією за допомогою vCenter Single Sign-On

Навчитися працювати з SSO вкрай важливо, проте тема ця майже неосяжна, тому спробуємо дуже стисло нею пробігтися, звернувши увагу на головні алгоритми дій та найпоширеніші операції. Якщо в вас виникне якесь питання, відповіді на яке нижче не знайдете, будь-ласка, звертайтеся до офіційної документації вендора.

Додавання джерел ідентифікації до домену

Щоб додати джерело автентифікації Active Directory до vCenter Server, потрібно приєднати vCenter Server до домену Active Directory. Для цього:

1. З клієнту vSphere заходимо на vCenter Server під адміністратором у локальному домені vCenter Single Sign-On (vsphere.local за замовчуванням);
2. Обираємо Administration;
3. Розкриваємо Single Sign On та клікаємо на Configuration;
4. Під вкладкою Identity Provider клікаємо на Active Directory Domain;
5. Натискаємо Join AD, вводимо домен, опціонально організаційний юніт, ім’я користувача та пароль и клікаємо на Join;
6. Перезавантажуємо vCenter Server.

Тепер додаємо джерело ідентифікації vCenter Single Sign-On (там же потім можна буде й редагувати за необхідності):

1. На вкладці Identity Provider (див. алгоритм перед цим) клікаємо на Identity Sources і на Add;
2. Обираємо джерело ідентифікації та вводимо його параметри (Active Directory (Integrated Windows Authentication) / Active Directory over LDAP / OpenLDAP);
3. Тиснемо на Add.

Зауважте, що у випадку Active Directory over LDAP та OpenLDAP нам потрібно буде ввести наступні параметри сервера:

• Name – ім’я,
• Base DN for users – базове DN (Distinguished Name) для користувачів (приклад: cn=Users,dc=myCorp,dc=com),
• Base DN for groups – базове DN для груп (наприклад,  cn=Groups,dc=myCorp,dc=com),
• Domain name – ім’я домену,
• Domain alias – псевдо домену,
• User name – ім’я користувача (ID користувача домену з мінімум на читання привілеями до базового DN для користувачів і груп; може бути в форматі UPN (user@domain.com), NetBIOS (DOMAIN\user), DN (cn=user,cn=Users,dc=domain,dc=com)),
• Password – пароль,
• Connect to – домен-контролер, до якого маємо підключитися,
• Primary Server URL – первинний LDAP-сервер домен-контролеру для домену (ім’я хоста чи ІР-адреса, наприклад, ldap://hostname_or_IPaddress:port чи ldaps://hostname_or_IPaddress:port, 389 порт в першому випадку і 636, зазвичай, для другого),
• Secondary server URL – адреса вторинного домен-контролера LDAP-сервера, яка використовується, коли первинний недоступний,
• Certificates (for LDAPS) – тут можна натиснути на Browse, щоб обрати сертифікат, що був експортований з домен-контролеру, вказаного в LDAPS URL, якщо хочемо використовувати LDAPS з нашим Active Directory LDAP Server чи джерелом ідентифікації OpenLDAP Server.

А для Active Directory (Integrated Windows Authentication):

• Domain name – FQDN імені домену (наприклад, com – не ІР-адреса!). Має бути розв’язуваним з DNS системою vCenter Server,
• Use machine account – ставимо галочку, щоб використовувати локальний акаунт машини як SPN (якщо не плануємо перейменовувати машину в майбутньому – інші опції пропадуть автоматично, задаємо в такому випадку лише ім’я домену),

Use Service Principal Name (SPN) – обираємо цю опцію, якщо машина буде потім мати інше ім’я. При цьому доведеться ввести далі Service Principal Name (SPN) та User Principal Name (UPN) з паролем. SPN допомагає Kerberos ідентифікувати сервіс Active Directory. Включаємо домен у ім’я, наприклад, STS/example.com.

vCenter Server Identity Provider Federation

Коли ми вдаємося до налаштування vCenter Server Identity Provider Federation, тобто до інтеграції AD FS з нашим vCenter Server, ми, йдемо за таким планом:

А саме (з розбиттям за зонами відповідальності):

1. Адміністратор AD FS налаштовує AD FS OAuth Application для vCenter Server;
2. Адміністратор vCenter Server заходить на vCenter Server через клієнт vSphere та додає провайдера ідентифікації (як саме – див. вище алгоритм) й інформацію щодо домену Active Directory;
3. Адміністратор vCenter Server налаштовує дозволи авторизації у vCenter Server для користувачів AD FS;
4. AD FS Provider запитує VcIdentityProviders API, щоб отримати інформацію щодо підключення LDAP для джерела Active Directory та шукає Active Directory для поданих користувачів та груп задля завершення конфігурації авторизації.

Перед, власне, налаштуванням, потрібно, щоб був розгорнутий AD FS for Windows Server 2016 чи свіжіший й підключений до Active Directory, у AD FS має бути створена Application Group для vCenter Server (см. КБ), та група адміністраторів vCenter Server в AD FS, що містить користувачів з привілеями адміністратора й до vCenter Server теж. І, нарешті, нам треба додати сертифікат серверу AD FS (або CA, або проміжний), до Trusted Root Certificates Store. Швиденько розкажемо, як зробити останнє, перед тим, як перейти безпосередньо до інтеграції.

Для цього заходимо в клієнті vSphere на vCenter Server, і далі – у Administration > Certificates > Certificate Management, поряд з Trusted Root Certificates клікаємо на Add, шукаємо потрібний кореневий сертифікат AD FS та тиснемо Add. Тепер цей сертифікат можна буде побачити в панелі під Trusted Root Certificates.

А тепер обираємо в меню Home – Administration і під Single Sign On клікаємо на Configuration. Далі:

1. На вкладці Identity Provider отримуємо Redirect URI, клікнувши на інформаційну іконку «i» поряд з посиланням Change identity provider – у спливаючому банері покажуться два Redirect URI. Копіюємо обидва до файлу чи просто записуємо, та закриваємо банер;
2. Створюємо конфігурацію OpenID Connect у AD FS та налаштовуємо її для vCenter Server (як це зробити розповідається отут);
3. Створюємо провайдера ідентифікації на vCenter Server. Повертаємось на вкладку Identity Provider, клікаємо на посилання Change identity provider – з’явиться помічник Configure Main Identity Provider. Обираємо в ньому Microsoft ADFS та клікаємо Next, вводимо у текстових полях інформацію щодо ідентифікатора клієнта, Shared Secret, адресу OpenID сервера AD FS, знову Next. Вводимо інформацію щодо користувача та групи для підключення Active Directory over LDAP задля пошуку користувачів та груп (див. підрозділ вище щодо LDAP), тиснемо Next, проглядаємо інформацію і остаточно тиснемо на Finish, щоб завершити роботу з цим помічником;
4. Повертаємось до Home-меню – обираємо Administration і під Single Sign On клікаємо на Users and Groups;
5. Налаштовуємо членство у групі vCenter Server для AD FS авторизації. Клікаємо на вкладку Groups, далі – на групу Administrators та на Add Members. Обираємо домен з розкривного меню, у текстовому полі під ним вводимо перші символи групи AD FS, яку хочемо додати – з’явиться розкривна підказка, з якої обираємо потрібну групу та клікаємо на Save.

Остаточно залишилось перевірити, чи здійснюється вхід до vCenter Server користувачем Active Directory.

Керування користувачами, групами й політиками

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

Політики vCenter Single Sign-On

Політики vCenter Single Sign-On застосовують правила безпеки для локальних акаунтів та токенів, загалом. Можна проглядати та редагувати дефолтні політики щодо паролювання, блокування та токенів.

Редагування політики паролювання (визначення формату паролю та його спливання – за дефолтом, це 90 днів, – застосовується тільки до користувачів у домені vCenter Single Sign-On – vsphere.local):

1. Заходимо на vCenter Server у клієнті vSphere під користувачем з правами адміністратора vCenter Single Sign-On;
2. Проходимо з меню Home в Administration і далі під Single Sign On – на Configuration;
3. Проходимо на вкладку Local Accounts та клікаємо на Edit за рядком Password Policy;
4. Редагуємо бажаним чином опції Description (опис), Maximum lifetime (к-сть днів існування до зміни, значення «0» – ніколи не сплине, значення 999999999 – максимальне), Restrict reuse (к-сть попередніх паролів, що не можна використовувати знов – як введемо, наприклад, 6, останні шість паролів не можна вважати за поточні), Maximum length, Minimum length, Character requirements (мінімальна к-сть різних типів символів, можна вказати к-сть по кожному типові – спецсимволи, абетка, великі літери, маленькі літери, цифри, Identical Adjacent);
5. Клікаємо на Save.

Редагування політики блокування (заблокувати акаунт через певну кількість зроблених користувачем невдалих спроб ввести пароль – потім автоматично розблоковується за певних обставин, що теж налаштовується):

1. Проходимо на ту саму вкладку Local Accounts (див. вище щодо паролів) та клікаємо на Edit за рядком Lockout Policy (щоб побачити його скролимо униз);
2. Редагуємо параметри: Description (опис), Maximum number of failed login attempts (к-сть неправильних спроб введення паролю до блокування), Time interval between failures (час, через який фейл викличе блок), Unlock time (час, який акаунт має лишатися заблокованим до автоматичного розблокування; якщо ввести 0, то розблокувати можна буде тільки вручну адміністраторові);
3. Клікаємо на Save.

Редагування політики токенів (вказуються властивості токенів, наприклад, часова толерантність, кількість поновлень тощо):

1. На тій самій вкладці Local Accounts (див. вище, як до неї дістатися) клікаємо Editза рядком Token Trustworthiness;
2. Редагуємо параметри, а саме: Clock Tolerance (різниця в часі, яку толерує vCenter Single Sign-On між клієнтським годинником та годинником домен-контролера, якщо вказане значення буде перевищено, vCenter Single Sign-On вважатиме токен невалідним), Maximum Token Renewal Count (максимальна кількість дозволених поновлень токена – за перевищення вказаного вимагатиметься новий токен безпеки), Maximum Token Delegation Count (токени власника ключа можна делегувати службам у vSphere; значення вказує, скільки разів можна делегувати один токен), Maximum Bearer Token Lifetime (тривалість життя токена-носія до того, як токен потрібно буде випустити повторно), Maximum Holder-of-Key Token Lifetime (час життя токена власника ключа до того, як він буде позначений недійсним);
3. Клікаємо на Save.

Користувачі та групи в vCenter Single Sign-On

Для усіх перелічених нижче операцій нам, спочатку, знадобиться обрати в меню Home – Administration і під Single Sign On клікнути на Users and Groups, а далі, щоб…

Додати користувачів vCenter Single Sign-On:

1. Якщо в панелі поточний обраний домен не vsphere.local, то з розкривного меню переобираємо потрібний (до інших доменів користувачів додавати заборонено!);
2. На вкладці Users клікаємо на Add;
3. Вводимо ім’я та пароль нового користувача (максимальна довжина імені – 300 знаків);
4. Опціонально, вводимо прізвище та ім’я, електронну адресу та опис користувача;
5. Клікаємо на Add.

Активувати/деактивувати користувачів vCenter Single Sign-On:

1. Обираємо потрібне ім’я у списку та клікаємо на More;
2. Якщо потрібно деактивувати обираємо Disable, якщо навпаки – Enable;
3. Тиснемо ОК.

Видалити користувача vCenter Single Sign-On:

1. На вкладці Users обираємо домен vsphere.local з розкривного меню;
2. Обираємо користувача зі списку;
3. Клікаємо на Delete, чекаємо виконання;
4. Тиснемо Remove.

Відредагувати користувача vCenter Single Sign-On:

1. На вкладці Users обираємо потрібного користувача та тиснемо Edit;
2. Міняємо налаштування, як треба (ім’я змінити не можна!);
3. Клікаємо на Save.

Додати групу vCenter Single Sign-On:

1. На вкладці Groups клікаємо на Add;
2. Вводимо ім’я (максимально 300 знаків) та опис групи;
3. З розкривного меню Add Members обираємо джерело ідентифікації, що містить членів, яких треба додати до групи. Якщо налаштований зовнішній провайдер ідентифікації як AD FS, його домен також буде доступний в цьому розкривному меню;
4. Вводимо термін для пошуку;
5. Обираємо члена – можна більше одного;
6. Клікаємо на Add.

Додати членів до групи vCenter Single Sign-On:

1. На вкладці Groupsклікаємо на потрібну групу;
2. З розкривного меню Add Members обираємо джерело ідентифікації, що містить членів, яких хочемо додати до групи (за налаштованого AD FS його домен також буде в цьому розкривному меню);
3. Вводимо термін для пошуку;
4. Обираємо члена (можна більше одного);
5. Клікаємо на Save.

Видалити членів з групи vCenter Single Sign-On (видаляється з групи, проте не з системи!):

1. На вкладці Groups клікаємо на потрібну групу;
2. У списку її членів обираємо шуканого користувача та клікаємо на іконку «вертикальних крапочок»;
3. Обираємо Remove Member;
4. Тиснемо на Remove.

Двофакторна ідентифікація

Все більшої поширеності набуває, так звана, ідентифікація смарт-картами. Трошки поговоримо про те, як її реалізувати в нашому середовищі на базовому рівні.

Для неї треба буде під’єднати кард-рідер під пластикові картки з інтегрованим чіпом (наприклад, Common Access Card (CAC)) до комп’ютера. Зазвичай, здатні до такого машини вже мають попередньо проінстальовані драйвери, що керують смарт-картами. Сам же процес входу при цьому виглядатиме так:

1. Користувач вставляє смарт-карту в рідер, браузер зчитує сертифікати на карті;
2. Браузер пропонує користувачеві обрати сертифікат, а потім – увести PIN для нього;
3. vCenter Single Sign-On перевіряє, чи знає про цей сертифікат зі смарт-карти, а потім – чи немає скасування щодо нього;
4. Якщо все добре, користувач автентифікується та може виконувати свої задачі, для яких в нього є дозволи.

Щоб усе це запрацювало, зробимо деякі налаштування. Спочатку сконфігуруємо vCenter Server, щоб запитував клієнтські сертифікати (використовуватиме порт 3128 – встановлюється та відкривається автоматично на vCenter Server):

1. Заходимо в оболонку vCenter Server як root;
2. Створюємо довірене сховище клієнтських СА на vCenter Server, використовуючи точний шлях та PEM-ім’я (/usr/lib/vmware-sso/vmware-sts/conf/clienttrustCA.pem): переходимо в директорію /usr/lib/vmware-sso/:

cd /usr/lib/vmware-sso/

Створюємо сховище довірених клієнтських СА:

openssl x509 -inform PEM -in xyzCompanySmartCardSigningCA.cer > /usr/lib/vmware-sso/vmware-sts/conf/clienttrustCA.pem

Результатом буде створення файлу «clienttrustCA.pem» з довіреного підписаного сертифікату xyzCompanySmartCardSigningCA.cer. Якщо запустимо цю команду ще раз з «>>», зможемо додати додатковий сертифікат;

3. Валідуємо, чи контент файлу clienttrustCA.pem містить довірені СА, що підписали сертифікати смарт-карти, командою:

keytool -printcert -file /usr/lib/vmware-sso/vmware-sts/conf/clienttrustCA.pem | grep -i “owner\|sha1\|issuer:\|valid”

4. Перевіряємо, чи імена СА відповідають Smart Card User Certificate Chain командою:

sso-config.sh -get_authn_policy -t vsphere.local | grep trusted

5. Перезапускаємо сервіс STS:

service-control –restart sts

Далі маємо активувати конфігурацію смарт-карти та налаштувати перевірку анулювання сертифікату. Активувати автентифікацію смарт-картою можна як за допомогою vSphere Client, так і CLI. В обох випадках попередньо треба пересвідчитись, що в нас встановлений корпоративний Public Key Infrastructure (PKI) та User Principal Name (UPN) відповідає акаунту Active Directory у розширенні Subject Alternative Name (SAN), а сам сертифікат вказує Client Authentication у полі Application Policy чи Extended Key Usage чи браузер не показує сертифікат. Далі отримуємо сертифікати й копіюємо їх у папку, яку бачить утиліта sso-config, за допомогою консолі vCenter Server чи напряму через SSH, деактивувавши оболонку:

shell

chsh -s “/bin/bash” root

csh -s “bin/appliance/sh” root

І скориставшись WinSCP чи схожою утилітою, копіюємо сертифікати в директорію /usr/lib/vmware-sso/vmware-sts/conf на vCenter Server. Після цього, з клієнтом vSphere:

1. Заходимо на vCenter Server з адміністративними привілеями;
2. Проходимо з меню Home у Administration і під Single Sign On клікаємо на Configuration;
3. На вкладці Identity Provider клікаємо на Smart Card Authentication та на Edit;
4. Обираємо чи знімаємо вибори з методів автентифікації, після чого тиснемо на Save – з’явиться Trusted CA certificates;
5. На вкладці Trusted CA certificates клікаємо на Add і на Browse;
6. Обираємо усі сертифікати з довірених СА, після чого остаточно тиснемо на Add.

Якщо віддаємо перевагу командному рядкові, активуємо автентифікацію смарт-картою:

sso-config.sh -set_authn_policy -certAuthn true -cacerts first_trusted_cert.cer,second_trusted_cert.cer  -t tenant

Як в нас декілька сертифікатів, відокремлюємо їх в команді комами, проте не пробілами!

Щоб активувати чи деактивувати інші методи автентифікації:

sso-config.sh -set_authn_policy -pwdAuthn false -t vsphere.local

sso-config.sh -set_authn_policy -winAuthn false -t vsphere.local

sso-config.sh -set_authn_policy -securIDAuthn false -t vsphere.local

Опціонально, можемо встановити список дозволів щодо політик сертифікатів:

sso-config.sh -set_authn_policy -certPolicies policies

як в нас декілька політик, відокремлюємо їх комами, без пробілів.

Опціонально, можемо увімкнути й налаштувати перевірку скасування за допомогою OCSP:

sso-config.sh  -set_authn_policy -t tenantName  -useOcsp true

Опціонально, можемо вивести конфігураційну інформацію:

sso-config.sh -get_authn_policy -t tenantName

І, нарешті, нам потрібно встановити політики скасування для автентифікації смарт-картою. Для цього:

1. З меню Home обираємо Administration і під Single Sign On клікаємо на Configuration;
2. На вкладці Identity Provider клікаємо на Smart Card Authentication;
3. Клікаємо на Certificate revocation – Edit, щоб активувати чи деактивувати перевірку на скасування.

Якщо політики сертифікатів діють в нашому середовищі, можемо додати політику в панелі Certificate policies.

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

Порівняння функціоналу існуючих на зараз ліцензій vSphere можна знайти отут.

Трошки про сервіс ліцензування у vSphere ми згадували в підрозділі «Сервіс ліцензування» статті «Інсталяція vSphere 8.0 з нуля». Давайте цей момент обговоримо більш докладно.

vSphere License Service працює на vCenter та пропонує наступні функції:

• Надання централізованого керування ліцензіями;
• Утримання інвентаря ліцензій;
• Керування призначенням ліцензій продуктам, інтегрованим з vSphere. У тому числі ESXi-хостам, системам vCenter та кластерам з активованим vSAN.

У інтерфейсі керування vCenter ми можемо контролювати працездатність цього сервісу та спостерігати за його статусом.

Створення нової ліцензії

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

1. Проходимо в Menu > Administration;
2. Розкриваємо Licensing та клікаємо на Licenses;
3. На вкладці Licenses клікаємо на Add New Licenses;
4. На сторінці Enter licenses keys вводимо по одному ключу (25-символьний рядок літер та цифр у форматі XXXXX-XXXXX-XXXXX-XXXXX-XXXXX) на кожен рядок та клікаємо Next;
5. На сторінці Edit license names переназиваємо нові ліцензії, як хочемо, та тиснемо Next;
6. На сторінці Ready to complete проглядаємо налаштування та клікаємо на Finish.

Додавання ліцензійних ключів до vCenter

Коли ми вперше ставимо vCenter, він за замовчуванням починає працювати з 60-денним ознайомлювальним періодом. До його закінчення ми маємо призначити ліцензію нашому vCenter (25-значний ключ).

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

Для цього у головному меню vSphere Client обираємо Administration > Licenses – відкриється перша вкладка Licenses, де тиснемо на ADD і в новому вікні вводимо усі дані згідно підказок міні-помічника:

Переглядати інформацію про ліцензію можна за:

• Продуктом (ліцензія на використання програмного компонента або функції vSphere. Приклад: «vSphere Enterprise Plus»);
• Ліцензійним ключем (серійний номер, що відповідає продукту);
• Об’єктом (компонентом, якому призначено ліцензію на продукт. Щоб об’єкт міг легально запускати певне ПО, він повинен мати ліцензію).

Призначення ліцензії компоненту vSphere

Певному об’єкту можна призначити ліцензію, якщо у клієнті vSphere під Administration > Licenses пройти на вкладку Asset – побачимо декілька змістовних груп компонентів. Наприклад, нам потрібно уже існуючий ліцензійний ключ призначити нашому інстансу vCenter. Для цього клікаємо на VCENTER SERVER SYSTEMS – відкриється табличка відповідних об’єктів, ставимо галочку на потрібний і клікаємо вище таблички на ASSIGN LICENSE. Відкриється вікно у якому можна обрати або вже існуючу ліцензію, або додати нову:

Призначення ліцензії декільком активам

Активи у vSphere, як ми знаємо, це, загалом, наші системи vCenter Server, ESXi-хости, кластери vSAN, Supervisor та інші інтегровані зі «сферою» продукти. Іноді дуже тяжко працювати з ліцензуванням кожного окремо, і тоді в нагоді стає функція пакетного призначення ліцензій багатьом активам одразу.

Для цього:

1. Проходимо в Menu> Administration;
2. Розкриваємо Licensing та клікаємо на Licenses;
3. Обираємо вкладку Assets та клікаємо на вкладку vCenter Server systems, Hosts, vSAN Clusters, Supervisor Clusters чиSolutions;
4. Обираємо актив для ліцензування (клік з Shift для обрання декількох одразу);
5. Тиснемо на Assign License;
6. В діалоговому вікні Assign License обираємо задачу: або Select an existing license (обрати ліцензію зі списку та клікнути ОК), або Select a newly created license (якщо те, що ми робили вище в підрозділі «Створення нової ліцензії», пропустили – з’явиться вікно створення нової ліцензії, заповнюємо його відповідним чином і знов тиснемо на ОК).

Видалення ліцензій

Усі непризначені ліцензії (ті, що не використовуються через поділ, об’єднання чи оновлення в Customer Connect) за best practice потрібно своєчасно видаляти з інвентаря. Для цього проходимо на нашу вкладку Licenses, як розповідалось вище, користуємось фільтрами для зручності вибору непризначених ліцензій (клікаємо на іконку фільтра у колонці State – покажеться текстове поле, де обираємо unassigned), обираємо конкретну ліцензію, чи з Ctrl+A виділяємо всі, та клікаємо на Remove Licenses. З’явиться повідомлення підтвердження, в якому тиснемо на Yes.

Перегляд функцій ліцензії

Окрім операцій по додаванню й призначенню ліцензій у клієнті vSphere, можна керувати ними та відповідними функціями прямо з інвентаря vCenter. Для цього стаємо на потрібний об’єкт у бічному правому меню, у лівій частині екрану переходимо на вкладку Configure і під System клікаємо на Licensing:

Відповідна панель продемонструє тип ліцензії, термін її закінчення та доступні функції.

Також можна експортувати інформацію щодо ліцензій. Для цього обираємо об’єкт для експорту (з вкладки Licenses, Products чи Assets, залежно від того, що саме хочемо експортувати – самі ліцензії, продукт чи актив у вигляді інстансів vCenter Server, хостів, кластерів або рішень, чиє ліцензування нас цікавить). Як нічого не обрати – експортується геть усе. Далі клікаємо на Export та обираємо Selected Rows чи All Rows, залежно від попереднього вибору, чи взагалі нічого не вказуємо, якщо не обирали до цього жодних об’єктів. Інформацію буде вивантажено в файл CSV, який система запропонує нам десь зберегти після завершення його підготовки.

Ліцензування ESXi-хостів у VMware Host Client

ESXi-хости ліцензуються ліцензіями vSphere, і кожна з них має певну ємність, що може застосовуватися до декількох фізичних CPU на хостах ESXi. Коли ліцензія призначається хостові, об’єм спожитої ємності визначається кількістю фізичних CPU на хості та кількістю ядер на кожному фізичному CPU. Як і у випадку vCenter, маємо evaluation-період, після якого (або раніше) ліцензію треба призначити. Також до цього обов’язково треба вдатися після оновлення наших хостів, якщо перейшли на нову мажорну версію.

Продивитися доступні ліцензії з датами збігу їх строку, ліцензійним ключем та різними функціями, а також доступними продуктами та об’єктами можна, якщо клікнути на Manage в інвентарі VMware Host Client, а далі – на Licensing.

Призначення ліцензії хосту

Через VMware Host Client можна призначати існуючий чи новий ліцензійний ключ ESXi-хосту.

Важливо! Для роботи з ліцензіями у VMware Host Client потрібні привілеї Global.Licenses.

Для цього:

1. Клікаємо на Manage в інвентарі та на Licensing;
2. Клікаємо на Assign license, вводимо ліцензійний ключ у форматі «XXXXX-XXXXX-XXXXX-XXXXX-XXXXX» та тиснемо Check license;
3. Клікаємо на Assign license, щоб зберегти зміни.

Видалення ліцензії з ESXi-хоста

Для дотримання відповідності ліцензійній моделі продуктів, що використовуються з vSphere, доброю практикою вважається видалення непризначених ліцензій з інвентаря. Для цього клікаємо на Manage у інвентарі VMware Host Client та на Licensing, обираємо потрібне й клікаємо на Remove license, а потім – на ОК.

Управління ресурсами vSphere

Щодо віртуалізації ресурсів багато було пояснено у матеріалі «Інсталяція vSphere 8.0 з нуля». Тепер розберемось на практиці, як ними керувати у нашому середовищі, та які є техніки для контролю над ними та оптимізації.

Технології покращення роботи пам’яті, CPU та дисків

Щодо пам’яті ВМ найпоширенішою та найзначнішою проблемою можна назвати перевикористання пам’яті. Це відбувається, коли сумарний налаштований обсяг пам’яті усіх увімкнених ВМ перевищує розмір пам’яті хоста. Як відомо, загальний сконфігурований обсяг пам’яті усіх ВМ може перевищувати доступний обсяг фізичної на хості, і це ще не катастрофа, адже проблеми починаються тоді, коли саме робоча пам’ять машин стає більшою цього значення. Як це стається, то машини не завжди зможуть використовувати усі виділену для них пам’ять, і навіть якщо на увімкнені ВМ це не вплине, нова включитися не зможе.

Щоб покращити використання пам’яті, хост ESXi вивільняє пам’ять у неактивних ВМ для розподілу між тими, що потребують більше. Її можна замінити на файл підкачки «.vswp», а накладні витрати пам’яті – на файл підкачки «vmx-*.vswp»:

ESXi-хост використовує наступні техніки перевикористання пам’яті задля можливості уникнення цих проблем (працює з ними VMkernel):

• Прозорий спільний доступ до сторінок пам’яті. При цьому усуваються зайві копії сторінок, так як сторінки з ідентичним вмістом кладуться на зберігання лише раз.
• Балунінг (Ballooning). Використовується драйвер balloon VMware Tools для зняття виділення пам’яті з ВМ. Назва дуже промовиста: роздуття застосовується ESXi-хостом для зменшення вимог до пам’яті ВМ, що наблизилась до цільової пам’яті при досить малому залишкові пам’яті хоста. При цьому модуль vmmemctl, що встановлюється в гостьову ОС як частина VMware Tools, змушує ОС відмовитися від сторінок пам’яті, які вважаються найменш цінними. Балунінг забезпечує продуктивність, майже таку ж саму, як і нативної системи за аналогічних обмежень пам’яті. Для його використання система має бути налаштована з достатнім простором свопу.
• Стиснення пам’яті. Зменшує кількість сторінок пам’яті, які потрібно викачати. Оскільки затримка декомпресії набагато менша за затримку підкачки, стиснення має значно менший вплив на продуктивність, аніж заміна сторінок. Фактично, відбувається перехід до зберігання пам’яті в стисненому форматі.
• SSD-свопінг на рівні хоста. Перехід до кешу хоста – це додаткова техніка відновлення пам’яті, що використовує локальне флеш-сховище для кешування сторінок пам’яті ВМ. Використовуючи локальне флеш-сховище машина уникає затримки, пов’язаної з мережею сховища, якою можна скористатися, якщо змінені сторінки пам’яті на віртуальний своп-файл (.vswp).
• Підкачка пам’яті ВМ на диск. Регулярна підкачка пам’яті на рівні хоста спрацьовує, коли навантаження на пам’ять стає сильним і гіпервізор має замінити її сторінки на диск, тоді він перемикається на кеш підкачки хоста, а не на файл «.vswp». Коли на хості закінчується місце в кеші, кеш-пам’ять ВМ переноситься до звичайного файлу «.vswp» ВМ. Для кожного хоста потрібно налаштовувати власний кеш свопу. Це, так би мовити, останній бастіон, адже продуктивність цієї техніки надзвичайно низька.

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

Першою з них варто згадати мультиядерні ВМ. Справа в тому, що кількість vCPU, налаштована для ВМ, залежить не лише від фізичної конфігурації хоста, а й від гостьової ОС, потреб та обмежень масштабування застосунків і конкретного способу використання самої ВМ. У VMkernel є планувальник CPU, що динамічно планує vCPU на фізичних CPU системи хоста. Він враховує топологію сокет-ядро-потік під час прийняття своїх рішень. Процесори Intel і AMD комбінують кілька ядер процесора в одну інтегральну схему, що зветься сокетом. Сокет – то є окремий пакет з одним чи декількома фізичними CPU. Кожне ядро має одне чи більше логічних CPU (LCPU) чи потоків. З LCPU ядро може планувати один потік виконання. Коли vCPU з одно-vCPU чи мульти-vCPU ВМ має бути поставленим у розклад, VMkernel зіставляє vCPU з доступним логічним процесором:

Друга цікава технологія – Hyperthreading. З гіперпотоковістю ядро може виконувати два потоки чи набір інструкцій одночасно. Вона дає більше логічних CPU, на яких можуть бути заплановані vCPU, та активована за замовчуванням, якщо система хоста підтримує цю технологію, в BIOS (зверніться до вендора hardware, чи підтримується – у декого цей параметр називається Logical Processor, у інших – Enable Hyperthreading), і явно увімкнена на хості (переконатися можна в клієнті vSphere, вкладка Summary, де треба вибрати CPUs під Hardware):

Недоліком гіперпотоковості є те, що вона не подвоює потужність ядра, тому, якщо обидва потоки виконання потребують однакових ресурсів на чіпі одночасно, один з них повинен зачекати. Але все одно у системах з нею спостерігається збільшення продуктивності. Хост з гіперпотоковістю поводиться майже так само, як і стандартна система. Логічні процесори на одному ядрі пронумеровані за порядком: на першому ядрі логічні процесори 0 і 1, на другому – 2 і 3 і т. д.

Балансування навантаження CPU. VMkernel балансує процесорний час, щоб гарантувати плавний розподіл навантаження між його ядрами в системі. Планувальник CPU може використовувати кожен логічний процесор незалежно від використання ВМ, забезпечуючи можливості, подібні до традиційних симетричних багатопроцесорних систем (SMP). Кожні 2-40мс (в залежності від топології сокет-ядро-потік) VMkernel намагається перенести vCPU з одного логічного процесору на інший, щоб зберегти баланс навантаження. Він робить усе можливе задля планування ВМ з кількома vCPU на двох різних ядрах, а не на двох логічних процесорах на одному ядрі. Але за необхідності, VMkernel може зіставити два vCPU з однієї й тієї ж машини до потоків на тому самому ядрі.

Якщо логічний процесор не працює, він переходить у стан зупинки (halted). Ця дія вивільняє ресурси виконання, і ВМ, що працює на іншому логічному процесорі на тому ж ядрі, може використовувати всі ресурси виконання ядра. Оскільки планувальник VMkernel враховує цей час зупинки, ВМ, що працює з повними ресурсами ядра, має вартість, дорожчу за ту, що працює на половині. Такий підхід до керування процесором гарантує, що сервер не порушить правила розподілу ресурсів ESXi:

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

Контроль над ресурсами: резервування, обмеження та спільне користування

Окрім безпосереднього налаштування для ВМ CPU та пам’яті можна застосовувати параметри виділення ресурсів ВМ задля контролю над їх кількістю, так як ресурси хоста машинами використовуються одночасно, отже, може виникнути конкуренція за них:

• Резервування. Визначення гарантованого мінімального виділення для ВМ;
• Лімітування. Визначення верхньої межі CPU та пам’яті, які можуть бути виділені ВМ;
• Спільне користування. Визначення відносного пріоритету чи важливості доступу ВМ до даного ресурсу.

Усе це конфігурується в налаштуваннях ВМ, вкладка Virtual Hardware:

Продивитися параметри виділення ресурсів ВМ (резервування, обмеження та спільне користування) можна для усіх ВМ у кластері на вкладці Monitor під Resource Allocation бічного меню робочої частини, обравши цікавий для вас саме зараз конкретний ресурс:

Резервування ресурсів ВМ

Резервування виділення RAM, гарантує, що ця пам’ять ніколи не зазнає свопу чи балунінгу. Якщо ESXi-хост не має достатньо незарезервованої пам’яті для підтримки ВМ з резервуванням, ВМ не ввімкнеться:

Крім того йому потрібен й деякий обсяг службової пам’яті для увімкнення машин. Наприклад, ВМ з 4ГБ RAM та двома vCPU запросить 53МБ додаткової пам’яті. Резервування рекомендується налаштовувати для критичних ВМ, для яких конче важливо підтримувати найвищий рівень продуктивності.

Зауваження. Під час резервування пам’яті можна поставити галочку у Reserve all guest memory (All locked), щоб уся пам’ять ВМ була зарезервована, навіть якщо буде змінено загальний обсяг пам’яті для машини. Резервування пам’яті негайно регулюється, коли змінюється конфігурація пам’яті ВМ.

Резервування виділення CPU полягає в тому, що зарезервований для певної ВМ CPU гарантовано буде одразу запланований на фізичних ядрах – машина ніколи не буде поставлена в стан готовності процесора. Якщо хост ESXi не має достатньо незарезервованих CPU для підтримки ВМ з резервуванням, ВМ не ввімкнеться.

Обмеження ресурсів ВМ

За обмеження RAM ВМ ніколи не споживатимуть більше фізичної пам’яті, ніж визначено обмеженням (те саме стосовно обмеження за CPU). Якщо гостьова ОС намагатиметься спожити більше оперативної пам’яті, ніж визначено обмеженням, ВМ скористаються механізмом підкачки (.vswp).

При обмеженні CPU його потоки поміщаються у стан готовності, якщо гостьова ОС намагається запланувати їх швидше, ніж дозволяє обмеження:

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

Використання обмежень має такі переваги та недоліки:

• Призначення лімітів корисне, коли ви починаєте з кількох ВМ і хочете керувати очікуваннями користувачів. Чим більше додається машин, тим гірше стає продуктивність, і тоді можна імітувати наявність меншої кількості ВМ, вказавши обмеження;
• При обмеженні можна втрачати неактивні ресурси. Система не дозволить ВМ скористатися більшою їх кількістю, аніж вказано в ліміті, навіть якщо вона використовується зовсім не повністю і неактивні ресурси наявні.

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

Спільне користування визначає відповідну важливість ВМ. Якщо в машини вдвічі більше спільних ресурсів, ніж у іншої, вона матиме право споживати вдвічі більше цього ресурсу, коли обидві вони конкурують за нього. Проте, якщо ESXi-хост зазнає конкуренції за ресурс, значення спільного використання не застосовуються. Можна встановити значення спільного користування на високий, нормальний чи низький рівень (high/normal/low):

Параметр	Значення спільного користування CPU, на vCPU	Значення спільного користування пам’яттю, на МБ налаштованої пам’яті ВМ
High	2 000	20
Normal	1 000	10
Low	500	5

Також можна обрати спеціальне налаштування, щоб призначити певну кількість спільних ресурсів для кожної ВМ. Параметри high/normal/low представляють значення спільного користування зі співвідношенням 4:2:1. Користувацьке визначення значення спільного користування назначає вказане число спільних користувань (що виражає пропорційну вагу) кожній ВМ.

Керування апаратним забезпеченням ESXi-хоста за допомогою VMware Host Client

За допомогою VMware Host Client можна керувати PCI-пристроями та налаштовувати параметри управління живленням.

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

Список політик керування живленням CPU:

• High Performance – не використовувати жодних функцій керування живленням,
• Balanced (Default) – зменшити споживання енергії з мінімальним компромісом для продуктивності,
• Low Power – зменшити споживання енергії з ризиком для мінімальної продуктивності,
• Custom – визначається користувачем (стає можливим задати бажане в розширених налаштуваннях).

Змінити політику керування живленням можна так:

1. Клікаємо на Manage в інвентарі VMware Host Client та на Hardware;
2. Клікаємо Power Management – Change policy – покаже доступні політики керування;
3. Обираємо потрібну політику та тиснемо ОК.

Зміна мітки hardware у VMware Host Client

Можна змінити мітку апаратного забезпечення усіх доступних пристроїв проходження PCI на ВМ. Використовуються апаратні мітки, щоб обмежити розміщення ВМ вказаними інстансами hardware. До ВМ можна додати усі доступні пристрої з однаковою міткою апаратного забезпечення або з порожньою.

Для цього:

1. Клікаємо на Manage у інвентарі VMware Host Client;
2. На вкладці Hardware клікаємо на Hardware label (має бути активним для обраного пристрою) – з’явиться діалогове вікно Edit Hardware Label;
3. Редагуємо мітку й зберігаємо налаштування кнопкою Save.

Нова мітка апаратного забезпечення з’явиться у відповідній колонці.

Керування ресурсами CPU за допомогою VMware Host Client

При підключенні за допомогою VMware Host Client до ESXi-хоста отримуємо доступ до обмеженої кількості опцій керування ресурсами. Наприклад, можна переглядати інформацію про CPU (тип фізичних процесорів та кількість логічних), якщо клікнути на хост в інвентарі VMware Host Client, розкрити Hardware, а потім – CPU.

Також можна призначати ВМ вказаному CPU (при вимкненій ВМ!):

1. ПКМ на ВМ в інвентарі VMware Host Client та обираємо Edit settings;
2. Під Virtual Hardware розкриваємоCPU;
3. Під Scheduling Affinity обираємо affinity фізичного процесора для ВМ (використовуємо дефіс для позначення діапазонів та розділяємо значення комами);
4. Клікаємо на Save для збереження змін.

Решту рекомендацій щодо планування, керування та спостереження за виділенням та використанням ресурсів наведемо нижче в розділі «Моніторинг…».

Налаштування мережі vSphere

Грамотне налаштування мережі ESXi дозволяє віртуальним машинам спілкуватися з іншими машинами, як фізичними, так і віртуальними. А крім того VMkernel зможе ефективно оперувати віддаленим керуванням хостом та сховищем на базі IP.

За підключення ВМ до фізичної мережі, між машинами на одному хості чи на різних відповідають віртуальні світчі. При цьому забезпечується підтримка служб VMkernel, зокрема, міграція vSphere vMotion, iSCSI, NFS та доступ до management-мережі. У кожного віртуального світча виділяють декілька специфічних типів підключень:

• порти ВМ,
• порти VMkernel (ІР-сховища, міграції vMotion, vSphere Fault Tolerance, vSAN, vSphere Replication та management-мережі ESXi),
• порти аплінків.

Перші два типи існують в порт-групах:

Порт-групи створюються, щоб налаштовувати віртуальні світчі. Порт-група – це шаблон, що містить конфігураційну інформацію, необхідну для створення портів віртуальних світчів на віртуальному світчі.

Важливо! Порт-групи (мережі) можуть співіснувати на одному й тому самому віртуальному світчі, або на окремих. Вибір частково спирається на компонування фізичної мережі. Наприклад, може не вистачати мережевих адаптерів, щоб створити віртуальний світч для кожної мережі. Але в цьому випадку можна усі мережеві адаптери помістити в одному віртуальному світчі, а ізоляції досягти за допомогою VLAN, що забезпечує логічне групування портів світча. Усі ВМ або порти у VLAN спілкуються так, ніби вони знаходяться в одному фізичному сегменті. VLAN – це широкомовний домен, налаштований програмним забезпеченням. Переваги використання VLAN:

• Створення логічних мереж, що не базуються на фізичній топології;
• Економія коштів за рахунок розділення мережі без накладних витрат на розгортання нових маршрутизаторів.

ESXi надає підтримку VLAN шляхом призначення VLAN ID порт-групі та працює з 802.1Q VLAN-тегуванням. Тегування віртуального світча є однією з підтримуваних політик тегування:

• Фрейми з ВМ тегуються як тільки-но виходять з віртуального світча;
• Теговані фрейми приходять на віртуальний світч й тегування знімається до того, як вони надішлються на ВМ призначення – цим займається VMkernel;
• Мінімальний вплив на продуктивність завдяки обмеженню широкомовного трафіку підмножиною портів світча.

При цьому порти фізичних світчів мають бути налаштовані як статичні транк-порти. Транк-порт – це порт на фізичному світчі Ethernet, налаштований на надсилання та отримання пакетів, позначених VLAN ID. На ВМ конфігурувати VLAN не потрібно – вона взагалі не усвідомлює, що підключена до VLAN:

Порти ВМ та VMkernel підключаються до зовнішнього світу через фізичні Ethernet-адаптери, під’єднані до портів аплінків віртуальних світчів.

Важливо! Оскільки фізичні NIC призначаються на рівні віртуального світча, усі порти й порт-групи, визначені для конкретного світча, мають користуватися однаковим апаратним забезпеченням.

Порт management-мережі ESXi – це VMkernel-порт, що підключається до мережі чи віддалених сервісів, з vpxd на vCenter та VMware Host Client, включно.

Кожен порт має налаштовуватися зі своєю власною ІР-адресою, маскою підмережі та шлюзом.

У vSphere використовуються два типи віртуальних світчів:

• vSphere Standard Switch,
• vSphere Distributed Switch,

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

Standard Switch – це віртуальний світч, налаштований для єдиного хоста.

Distributed switch – віртуальний світч, налаштований для усього дата-центру, що може приєднати до себе до 2 000 хостів, забезпечуючи стійкість конфігурації. Проте, в цьому випадку вимагається рівень ліцензування Enterprise Plus або хости мають належати кластеру vSAN. Він централізує адміністрування віртуальної мережі та спрощує адміністрування дата-центру, загалом. Порти розподіленого світча статично призначаються vCenter та забезпечують більш гранульований контроль над мережевою статистикою та політиками:

Робота зі Standard Switch

Якщо у клієнті vSphere на вкладці Configure по обраному елементу інвентаря обрати Virtual Switches в блоці Networking бічного меню робочого поля, можемо побачити конфігурацію стандартного світча:

За дефолтом, інсталяція ESXi створює порт-групу ВМ, названу VM Network, та порт-групу з ім’ям Management Network, що містить порт VMkernel для management-трафіка. Ми можемо створювати додаткові порт-групи для ВМ та портів VMkernel. Наприклад, порт-групу IP Storage, що буде містити порт VMkernel для доступу до сховища iSCSI.

Важливо! Для максимізації безпеки та продуктивності треба видалити порт-групу віртуальної машини VM Network та тримати мережі ВМ та management відокремленими на різних фізичних мережах чи VLAN.

Додавання Standard Switch

Новий Standard Switch можна додати до ESXi-хоста, чи переналаштувати існуючий, користуючись vSphere Client або VMware Host Client. Для цього:

1. Обираємо в інвентарі потрібний об’єкт;
2. У правій частині інтерфейсу проходимо на вкладку Configure;
3. У бічному меню робочого поля під Networking клікаємо на Virtual Switches;
4. Зверху тиснемо на функціональний напис ADD NETWORKING – відкриється міні-помічник, всіма пунктами якого проходимо послідовно, задаючи потрібні налаштування:

Відповідно, якщо потрібно відредагувати конфігурацію існуючого світча, тиснемо на EDIT.

Властивості VMkernel Adapter

Другий пункт бічного меню робочого поля у Networking (на шуканий елемент інвентаря – вкладка Configure) називається VMkernel adapters, і показує інформацію щодо інтерфейсів VMkernel (його ім’я, світч, на якому він розташований, IP-адресу та увімкнені сервіси):

На сервісах зупинимось докладніше, адже це дуже корисний і важливий момент. Їх повний перелік:

• vMotion – дозволяє VMkernel адаптеру повідомляти про себе як про мережеве підключення іншому хостові, куди посланий трафік vSphere vMotion;
• Provisioning – обробляє дані, перетрансферені для клонування, холодної міграції та міграції снепшота;
• Fault Tolerance logging – активує журналювання логів Fault Tolerance на хості;
• Management – активує management-трафік для хоста та vCenter
• vSphere Replication – обробляє вихідні дані реплікації, послані з джерела ESXi-хоста на сервер vSphere Replication;
• vSphere Replication NFC – обробляє вхідні дані реплікації на цільовому сайті реплікації;
• vSAN – активує vSAN-трафік на хості;
• vSphere Backup NFC – налаштування порту VMkernel для пов’язаного трафіку бекапування NFC;
• NVMe over TCP – налаштування порту VMkernel для пов’язаного трафіку сховища NVMe по TCP. Трафік сховища NVMe по TCP йде через VMkernel Adapter, коли увімкнений адаптер NVMe over TCP;
• NVMe over RDMA – налаштування порту VMkernel для пов’язаного трафіку сховища NVMe по RDMA. Трафік сховища NVMe по RDMA йде через VMkernel Adapter, коли увімкнений адаптер NVMe over RDMA.

Додати потрібні сервіси можна у відповідному віконці редагуванням адаптеру:

Властивості фізичного адаптеру

На панель Physical adapters можна попасти з клієнту vSphere на тій самій вкладці Configure під Networking:

Вона демонструє інформацію щодо швидкості, дуплексу та мережам.

Важливо! Налаштування швидкості та дуплексу за best practice рекомендується лишати незмінними, незважаючи на те, що вони здатні редагуватися. Проте, у деяких випадках це доречно, коли треба досягти відповідності передачі даних з швидкістю трафіку.

Мережеві політики віртуального світча

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

Тип віртуального світча	Дефолтна політика встановлюється на рівні…	Перезапис дефолтної політики на рівні…
vSphere Standard Switch	Стандартного світча	Порт-групи
vSphere Distributed Switch	Distributed порт-групи	Індивідуального порта

Політика мережевої безпеки забезпечує захист від підміни МАС-адреса та небажаного сканування портів. Політика шейпування трафіку корисна, коли потрібно обмежити обсяг трафіку до ВМ або групи ВМ. Політика тімінгу та відновлення після відмови відповідає на наступні питання:

• Як мережевий трафік ВМ та VMkernel адаптерів, підключених до світча розподіляється між фізичними адаптерами?
• Як слід перенаправляти трафік у разі збою адаптера?

Налаштування політик безпеки

Політики безпеки можна визначати й на рівні стандартного світча, й на рівні порт-групи. Робиться це у карточці шуканого віртуального світча (див. вище, як до нього потрапити), якщо натиснути на «три крапочки» у ній – з’явиться вікно EDIT SETTINGS, пункт меню Security. Доступні такі налаштування:

• Promiscuous mode – дозволяти чи не дозволяти усьому трафіку пересилатися, незалежно від призначення;
• MAC address changes – Прийняти чи відкинути вхідний трафік, коли МАС-адреса змінена гостем;
• Forged transmits – Прийняти чи відкинути вихідний трафік, коли МАС-адреса змінена гостем:

Для більшості випадків рекомендовано залишити дефолтне значення Reject. Але, наприклад, у випадку, коли треба використовувати застосунок у ВМ, що аналізує чи сніфить пакети, такий як мережеву систему виявлення вторгнень, треба виставити  Promiscuous mode на Accept. Або коли ваші застосунки міняють співставлені МАС-адреси, як, наприклад, роблять деякі файєрволи гостьових ОС, то MAC address changes і Forged transmits теж треба виставити на Accept.

Налаштування політик шейпування трафіку

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

Параметри застосовуються до кожної віртуальної NIC на стандартному світчі. Якщо ми говоримо про стандартний світч, шейпування трафіку контролює лише вихідний трафік, що прямує з ВМ до віртуального світча та назовні на фізичну мережу. Налаштовується воно у тій же карточці шуканого віртуального світча (див. вище, як до нього потрапити), якщо натиснути на «три крапочки» у ній – з’явиться вікно EDIT SETTINGS, пункт меню Traffic shaping:

Зауваження. Щоб контролювати вхідний трафік, треба використовувати систему балансування навантажень чи увімкнути функцію обмеження швидкості на фізичному маршрутизаторі.

Налаштування NIC-тімінгу та поведінки в разі відмови

Останній пункт налаштувань віртуального світча – Teaming and Failover (карточка шуканого віртуального світча (див. вище, як до нього потрапити) – «три крапочки» – вікно EDIT SETTINGS) – виглядає отак:

NIC-тімінг збільшує мережеву пропускну здатність світча та забезпечує резервування. До групи включаються два або більше NIC.

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

Порядок відновлення після відмови (failover) визначає, які лінки активні під час звичайних операцій, а які – у разі відмови. Можна налаштовувати наступні адаптери у списку порядку відновлення після відмови:

• Active – NIC з цієї групи будуть використовуватися щоразу, коли NIC-підключення підняте й активне;
• Standby – NIC з цієї групи будуть використовуватися, якщо один з NIC впаде;
• Unused – ці NIC не будуть використовуватися ніколи. Поміщаються в цю групу, щоб зарезервувати їх для надзвичайної ситуації. Звідси їх у будь-який час можна перенести до Active, за потреби.

Налаштування виявлення та усунення збою мережі

Збій мережі відслідковується та виявляється VMkernel (помилки конфігурації не відслідковуються!). VMkernel здійснює моніторинг стану лінків та виконує перевірку маяків (дивлячись що обрано) з одно секундними інтервалами, щоб пересвідчитися, що мережа працює безперебійно. Налаштувати цю поведінку можна у згаданому вище в підрозділі «Налаштування NIC-тімінгу та поведінки в разі відмови» пункті налаштувань віртуального світча Teaming and failover у блоці Network failure detection, якщо обрати Beacon probing (другий варіант):

Зауваження. Перевірка маяків полягає у надсиланні пробного пакету (62 байти) на кожен фізичний NIC, що є членом групи. Така техніка виявляє проблеми, які навіть моніторинг статусу зв’язку не здатен зробити самотужки. Щоб подібне зондування на маяках запрацювало, необхідна певна топологія мережі. Проконсультуйтесь з вашим вендором світча, щоб дізнатися, чи вона підтримується у вашому середовищі. Більше почитати про це можна у КБ.

Якщо VMkernel визначить мережевий збій, він сповістить фізичні світчі про зміни у фізичному розташуванні МАС-адреси (виставляється у Notify switches – Yes/No). Загалом, зазначити тут Yes є корисною практикою, бо інакше ВМ потерпатимуть від більших затримок у разі відновлення після відмови операцій vSphere vMotion.

Важливо! Не робіть налаштування Yes у Notify switches, якщо підключені до порт-групи ВМ запускають Microsoft Network Load Balancing (NLB) в одноадресному режимі. Більше дізнатися про цей випадок можна в КБ.

Імплементований VMkernel порядок перемикання за відмови спирається на параметри, які можна налаштувати (див. скріншот вище):

• Failback – визначається, як фізичний адаптер повертається до активного чергування після відновлення у разі збою (значення Yes/No). Якщо Yes – як тільки адаптер повернеться до роботи, він замінить адаптер у стані очікування (Standby), що зайняв його місце в момент падіння). Якщо No, адаптер після відновлення своєї працездатності не стане активним – тільки коли інший поточний адаптер впаде, він займе його місце;
• Load-balancing – рекомендується вживати Use explicit failover order.

Важливо! Завжди використовуйте аплінк vmnic на самісінькій верхівці списку активних адаптерів.

Робота з vSphere Distributed Switch

Розподілений світч переміщає компоненти керування мережею на рівень дата-центру. Його архітектура складається з рівня контролю та рівня вводу/виводу. Рівень контролю знаходиться на vCenter й налаштовує розподілені світчі, розподілені порт-групи, розподілені порти, аплінки, NIC-тімінг тощо. Він до того ж координує міграцію портів та відповідає за налаштування світча. Рівень вводу/виводу (I/O) запроваджений як прихований віртуальний світч у VMkernel кожного хоста ESXi, й керує пристроями вводу/виводу на хості та відповідає за пересилку пакетів. vCenter контролює створення цих прихованих віртуальних світчів. Архітектура Distributed Switch:

Кожен розподілений світч містить розподілені порти. Можна підключати будь-яку мережеву сутність, як-от ВМ чи інтерфейс VMkernel, до розподіленого порта. vCenter зберігає стан розподілених портів у своїй базі даних. Розподілена порт-група дозволяє логічно групувати розподілені порти для спрощення налаштування. Вона вказує опції конфігурації портів для кожного свого члена на розподіленому світчі. Порти також можуть мати власну унікальну конфігурацію. Аплінки – це абстракція vmnics з багатьох хостів до єдиного розподіленого світча. Для розподіленго світча вони – те саме, що й vmnic для стандартного. Дві ВМ на різних хостах можуть спілкуватися між собою лише, коли обидві мають аплінки в одному широкомовному домені.

Так само як і Standard Switch, Distributed Switches має VLAN-сегментацію та 802.1Q тегування, підтримує як IPv4, так і IPv6, є функція NIC-тімінгу та шейпування вихідного трафіку. А ось список того, що Distributed Switches вміє, а стандартний – ні:

• Шейпування вхідного трафіку,
• Бекапування та відновлення конфігурації,
• Приватні VLAN,
• Link Aggregation Control Protocol,
• Міграція vSphere vMotion стану мережі,
• Network I/O Control,
• Налаштування політики по кожному портові,
• Моніторинг стану порта,
• NetFlow,
• Порт-міррорінг,
• Підтримка NSX.

Конфігурацію розподіленого світча можна побачити по дата-центру на вкладці Configure під Settings у пункті Topology:

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

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

• Cisco Discovery Protocol (CDP) – для стандартних або розподілених світчів vSphere, під’єднаних до фізичних світчів Cisco,
• Link Layer Discovery Protocol (LLDP) – нейтральний до вендора протокол лишень для розподілених світчів.

Як бачимо, Standard switch може бути налаштований на використання лише CDP, а от Distributed switch – або CDP, або LLDP.

Налаштування CDP або LLDP відбувається у карточці розподіленого світча (див. скріншот попереднього підрозділу), якщо натиснути на «три крапочки» зверху біля ACTIONS – Edit Settings, на вкладці Advanced віконця, що відкриється, у блоці Discovery protocol:

Там можна обрати тип протоколу (CDP/LLDP) та режими дії:

• Listen – (за дефолтом) інформація отримується з фізичних світчів (інформація щодо віртуального світча не доступна адміністратору фізичного світча),
• Advertise – інформація посилається на фізичні світчі (навпаки, надається інформація щодо віртуального світча адміністратору фізичного, проте немає даних про фізичний світч),
• Both – інформація і отримується, і надсилається на фізичні світчі.

Налаштування розподіленої порт-групи

Робиться у карточці порт-групи (див. передостанній скріншот, Topology), якщо натиснути на «три крапочки» по ній.

Налаштування Port Binding

Port Binding визначає, коли й як віртуальна NIC ВМ назначається порту віртуального світча. Він налаштовується на рівні розподіленої порт-групи, у пункті бічного меню General, й доступні для вибору такі опції:

• Static binding (дефолтна) – vCenter назначає постійний порт для інтерфейсу VMkernel чи ВМ;
• Ephemeral – ESXi (не vCenter!) назначає порт ВМ. Призначений порт змінюється, коли машина перезавантажується.

Також можна налаштувати варіанти розміщення порту для статичної прив’язки:

• Elastic (дефолтний) – коли усі порти призначені, створюється новий набір з восьми портів;
• Fixed – жодні додаткові порти не створюються, коли усі порти призначені:

Коли віртуальна машина підключається до порт-групи зі статичною прив’язкою, порт негайно призначається та резервується для такої ВМ, завдяки чому маємо постійне підключення. Відключиться порт лише тоді, коли ВМ буде видалена з порт-групи. Саме таке налаштування рекомендоване для загальних випадків використання.

А от якщо в нас тимчасова прив’язка, порт створюється та призначається, коли ВМ увімкнена і її NIC підключена. Відповідно, коли машина вимикається, а NIC від’єднується, порт видаляється. Тимчасові порти корисні, коли vCenter не працює, а треба змінювати мережеві підключення ВМ. Проте, падіння vCenter не впливає на мережевий трафік, незалежно від типу прив’язки. Тому, Ephemeral-порти рекомендується використовувати лише з метою відновлення, якщо потрібно надати порти безпосередньо на ESXi-хості, минаючи vCenter, і тільки в такому випадку.

Налаштування шейпування трафіку

Розподілені світчі підтримують шейпування вхідного та вихідного трафіку. Ці налаштування доступні в пункті Traffic shaping бічного меню конфігурації розподіленої порт-групи:

Ingress (вихідному) трафіку присвячений верхній блок робочого поля налаштувань, а Egress (вхідному) – нижній. Причому, функція шейпування доступна для першого лишень для розподілених світчів, а другого – й для стандартних, й для розподілених. У відповідних блоках, як показано на скріншоті, можна включати чи виключати функцію шейпування та задавати середню й пікову пропускну здатність (Кбіт/с), а також граничний розмір пакету.

Налаштування NIC-тімінгу та поведінки при перемиканні у разі відмови

У пункті меню Teaming and failover можна задавати метод балансування навантажень як завантаження фізичної NIC, для чого у пункті Load balancing робочого поля з розкривного меню треба обрати Route based on physical NIC load:

Цей метод підтримується лише розподіленими світчами та є рекомендованою політикою для розподілених порт-груп. Балансування навантаження на завантаженні фізичної NIC гарантує оптимізацію ємності цієї фізичної NIC у групі NIC. Функція працює так:

• Потоки вводів/виводів переміщаються між аплінками;
• Потік переміщається лише тоді, коли середнє використання надсилання чи отримання аплінку досягає 75% ємності протягом 30-секундного періоду.

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

Важливо! Недоліком вибору Route based on physical NIC load вважається те, що пропускна здатність, доступна ВМ, лімітована аплінками, підключеними до розподіленого світча.

Політика фільтрації та маркування трафіку

Політика фільтрації та маркування трафіку для vSphere distributed switch захищає віртуальну мережу від небажаного трафіку та атак, допомагає керувати мережевим трафіком з SLA-метою. Функції цієї політики:

• Дозвіл чи заборона вказаних типів трафіку;
• Застосування тегів QoS для маркування певного типу трафіку.

Це такий собі еквівалент функції списку контроля доступу на фізичних світчах.

Для її реалізації потрібно створити правила мережевого трафіку, пов’язаного з ВМ чи фізичними адаптерами:

Відповідно до ілюстрації, в Action можемо обирати Allow/Drop/Tag, а у полі Traffic direction – Ingress, Egress чи Ingress/Egress. Нижче, в блоці Traffic Qualifiers, перемикаємось потрібними вкладками й задаємо конкретику трафіку, наприклад, отак:

Маркування трафіку не менш важливе, ніж можливість дозволити чи заборонити певний його тип. Можна, наприклад, призначати теги пріоритету для підвищених потреб мережі у пропускній здатності, зниження затримки, щоб взагалі не скидувались її пакети при конкуренції тощо. На L2 маркуємо Class of Service (CoS), а на L3 – Differentiated Serviced Code Point (DSCP).

Використання Network I/O Control в розподілених світчах

Network I/O Control – інструмент для виділення пропускної здатності для різноманітних типів системного трафіку й ВМ, бізнес-критичних застосунків. Цікава методика, що допомагає покращити продуктивність, в цілому:

Це відбувається завдяки використанню ресурс-пулів мережі для ВМ та системного трафіку. Пропускна здатність системного трафіку та трафіку ВМ резервується, спираючись на ємність фізичних адаптерів на хості. Ці обмеження можна встановлювати задля визначення максимальної пропускної здатності, що може споживати конкретний тип трафіку на адаптері. Якщо надлишкову пропускну здатність ніхто не використовує, лімітований тип трафіку також не може її спожити. Увесь деталізований контроль ресурсів відбувається на рівні мережевого адаптера ВМ. Функція дуже схожа на модель, яку ми використовуємо для виділення ресурсів CPU і пам’яті (див. вище у відповідному розділі). Тут також доступні резервування, обмеження та спільне використання.

Подивитися, як саме використовується функція  Network I/O Control для системного трафіку (ВМ, Management, vSphere vMotion, NFS, vSphere Fault Tolerance, iSCSI, vSphere Replication, vSAN, vSphere Data Protection) можна отут (по дата-центру вкладка Configure, під Resource Allocation – System traffic):

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

• Low (25),
• Normal (50),
• High (100),
• Custom (користувацьке значення від 1 до 100).

Обмеження пропускної здатності – це максимальна пропускна здатність у Мбіт/с чи Гбіт/с, яку може спожити тип системного трафіка на одному фізичному адаптері.

Резервування пропускної здатності – це мінімальна пропускна здатність у Мбіт/с, що гарантовано виділяється одному фізичному адаптерові. Зарезервувати можна не більше 75% пропускної здатності фізичного мережевого адаптера:

Зауваження. Загальне резервування пропускної здатності для ВМ на хості не повинна перевищувати зарезервовану пропускну здатність, що налаштована для системного трафіку ВМ:

Мережеві ресурс-пули

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

Щоб використовувати Network I/O Control для ввімкнення виділення пропускної здатності для ВМ, треба налаштувати системний трафік ВМ. Резервування пропускної здатності для ВМ також використовується в admission control: коли ми включаємо ВМ, admission control перевіряє, чи доступно достатньо пропускної здатності.

Після того, як ми налаштували резервування для типу трафіку ВМ, можна створювати мережеві ресурс-пули. Робиться це по картці розподіленого світча, вкладка Configure, у Network resource pools, якщо натиснути на кнопку ADD:

Бекапування та відновлення конфігурації мережевих компонентів

Можна створити резервну копію та відновити, за необхідності, відкотитися на попередні налаштування, скасувавши зміни, створювати нові світчі та порт-групи з бекапу чи розшарити конфігурацію розподіленого світча, розподілених порт-груп та порт-груп аплінків. Ці операції можливі завдяки функціям експорту, імпорту та відновлення для розподілених світчів.

Експорт конфігурацій розподілених світчів

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

Стануть у нагоді такі командлети:

Export-VDSwitch (експортує конфігурацію вказаного розподіленого світча до ZIP-файлу)

Export-VDPortGroup (експортує конфігурацію вказаної розподіленої порт-групи до ZIP-файлу).

Відновлення та імпорт конфігурацій розподіленого світча

Відновлення скидає конфігурацію поточного розподіленого світча та заміщує її експортованою з ZIP-файлу. Імпорт створює розподілений світч (новий!) з експортованого конфігураційного файлу. Перше корисне, коли треба вернути до нормального стану пошкоджений vDS, а друге допомагає створити новий з такими самими налаштуваннями, наприклад, в іншій системі vCenter.

Відкат та відновлення керуючої мережі хоста

Відкат у разі неправильної конфігурації мережі керування може здійснюватися таким чином:

• Автоматичний,
• Із застосуванням DCUI.

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

Зауваження. За дефолтом, автоматичний відкот увімкнено.

У другому випадку, якщо з якоїсь причини, наприклад, автоматику було вимкнено раніше, по кожному хостові потрібно буде зробити наступне:

1. Тиснемо F2 у DCUI, якщо попросить, вводимо потрібні дані облікового запису;
2. Стрілочками скролимось до Network Restore Options й тиснемо Enter;
3. Під Network Restore Options обираємо Restore vDS, щоб ініціювати відкот (тут можна або відновити дефолтні заблоковані параметри, або політику тімінгу за замовчуванням – обираємо потрібне й тиснемо Enter).

Мульти-хоумінг у vCenter Server Appliance

Multi-homing дозволяє налаштувати декілька NIC з метою керування мережевим трафіком:

Функція підтримує до 4 NIC. Налаштування будуть зберігатися впродовж майбутніх апгрейдів, створення резервних копій чи процесів відновлення.

Налаштування сховища vSphere

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

Що треба знати про сховища даних?

Датастор (сховище даних) – це, в загальному сенсі, контейнер, що тримає файли та об’єкти. У vSphere – це логічне сховище, що може користуватися одним або більшою кількістю пристроїв фізичного сховища. Це, такий собі, аналог файлової системи, що пропонує уніфіковану модель зберігання файлів віртуальних машин, шаблонів та ISO-образів.

vSphere підтримує такі типи датасторів:

• VMFS,
• NFS,
• vSAN,
• vSphere Virtual Volumes.

Нижче буде про кожен з них докладно. Можна вивести усі доступні на хості датастори та проаналізувати їх властивості.

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

• Сховище на основі блоків. Зберігають дані як блоки – послідовність байтів, притаманні локальним сховищам, використовуються у Storage Area Networks (SANs) та доступ до них відбувається через iSCSI або Fibre Channel. Саме до такого типу належать датастори VMFS, vSAN та vSphere Virtual Volumes;
• Сховище на основі файлів. Зберігають дані ієрархічно у файлах та папках, притаманні приєднаним до мережі сховищам (NAS). До цього типу належить NFS і vSphere Virtual Volumes.

В залежності від типу сховища, його вміст може зберігатися у форм-факторі файлів чи об’єктів:

• Датастори на базі файлів. У таких сховищах ВМ складаються з набору файлів, кожна має свою власну директорію. І от, наприклад, VMFS та NFS тримають саме файли;
• Датастори на базі об’єктів. Тут ВМ складається з набору контейнерів даних, що називаються об’єктами. До цього типу належать vSAN та vSphere Virtual Volumes.

В залежності від бажаного типу сховища, датастори можуть бути форматовані з VMFS чи NFS.

ESXi-хости можна налаштувати зі спільним доступом до датасторів:

І вони підтримують наступні відомі технології зберігання:

• Напряму прикріплене сховище (DAS) – внутрішні або зовнішні диски чи масиви, підключені до хоста через пряме з’єднання замість мережевого;
• Fibre Channel (FC) – високошвидкісний транспортний протокол, що використовує SAN. Інкапсулює команди SCSI, що передаються між нодами Fibre Channel. Загалом, нода Fibre Channel – це сервер, система зберігання чи стрічковий накопичувач. Світч Fibre Channel з’єднує між собою декілька нод, утворюючи структуру своєї мережі;
• FCoE – трафік Fibre Channel інкапсулюється у фрейми Fibre Channel over Ethernet (FCoE). Ці фрейми конвергуються з іншими типами трафіку в мережі Ethernet;
• iSCSI – транспортний протокол SCSI, що забезпечує доступ до пристроїв зберігання даних та кабельне підключення через стандартні мережі TCP/IP. iSCSI відображає блочне сховище SCSI через TCP/IP. Ініціатори, такі як адаптер шини хоста iSCSI (HBA) у хості ESXi, посилають команди SCSI до цілей, розташованих у системах зберігання iSCSI;
• NAS – сховище, що використовується через стандартні мережі TCP/IP на рівні файлової системи. Сховище NAS використовується, щоб тримати датастори NFS. Протокол NFS не підтримує команди SCSI.

iSCSI, NAS і FCoE можуть працювати у високошвидкісних мережах, забезпечуючи високий рівень продуктивності та достатню пропускну здатність. За належної пропускної здатності, в одній мережі можуть співіснувати декілька типів трафіку протоколу.

Ось зручна порівняльна таблиця протоколів сховища:

Тип датастору	Протокол сховища	Підтримка завантаження з SAN	Підтримка vSphere vMotion	Підтримка vSphere HA	Підтримка vSphere DRS
VMFS	Fibre Channel	+	+	+	+
	FCoE	+	+	+	+
	iSCSI	+	+	+	+
	iSER/NVMe-oF (RDMA)	–	+	+	+
	DAS (SAS, SATA, NVMe)	N/A	+*	–	–
NFS	NFS	–	+	+	+
vSphere Virtual Volumes	FC/Ethernet (iSCSI, NFS)	–	+	+	+
vSAN Datastore	vSAN	–	+	+	+

*Зауваження. DAS підтримує vSphere vMotion, коли комбіноване з vSphere Storage vMotion.

DAS і SAN-сховища

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

Що ж до SAN-сховища, його LUN розповсюджуються й знаходяться у спільному використанні усіх ESXi-хостів, що мають до нього доступ. Для такого спільного сховища можна користуватися vSphere vMotion, vSphere HA, vSphere DRS, воно створює центральний репозиторій для файлів ВМ та шаблонів, дозволяє кластеризацію ВМ по усіх ESXi-хостах й може розміщати великі об’єми у терабайтах.

iSCSI

iSCSI SAN складається з системи зберігання iSCSI, що містить LUN та процесори сховища. Зв’язок між хостом та масивом сховища відбувається за мережею Ethernet:

У цьому випадку ESXi-хост налаштовується як ініціатор iSCSI, що може базуватися на апаратному забезпеченні, де він – то є iSCSI HBA, або на програмному. Цей ініціатор передає команди SCSI IP-мережею, а ціль їх таким самим чином, відповідно, отримує. При цьому ціль знаходиться на масиві сховища, що підтримується  ESXi-хостом. Мережа iSCSI може включати багато ініціаторів та цілей. Щоб обмежити доступ з хостів до цілей, масиви iSCSI користуються багатьма механізмами, включно з ІР-адресами, підмережами та вимогами до автентифікації.

Адресація iSCSI:

Виявлення цілей iSCSI адаптером – це процес знаходження ресурсів сховища у мережі та визначення, які з них наразі є доступними. Це може бути статичне або динамічне (SendTargets) виявлення. При статичному методі ініціатор не має виконувати виявлення самотужки – він заздалегідь знає усі цілі, з якими може контактувати, та використовує їхні ІР-адреси та доменні імена для зв’язку. А от при динамічному ініціатор кожного разу робить запит SendTargets на вказаний сервер iSCSI, і відповідь останнього повертає IQN та усі доступні IP-адреси, що у клієнті vSphere відображаються як статичні цілі. Можна вручну видалити статичну ціль, що додана динамічним виявленням, проте, при повторному скануванні, вона може повернутися до списку, або коли хост перезавантажується чи скидається HBA:

Мережева конфігурація для iSCSI

До включення програмного ініціатора iSCSI треба створити відповідний VMkernel порт на віртуальному світчі.

Важливо! Для оптимізації мережі vSphere рекомендується розділити мережі iSCSI і мережі NAS або NFS. Перевага має надаватися фізичному розділенню, але якщо подібне недоступне, можна скористатися VLAN.

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

Активація програмного адаптеру iSCSI

Для того, щоб ESXi-хост міг працювати зі сховищем iSCSI, потрібно встановити ПО чи апаратне забезпечення iSCSI адаптерів:

Щоб додати програмний iSCSI-адаптер:

1. Обираємо хост та клікаємо на вкладку Configure;
2. Обираємо Storage Adapters у секції Storage та клікаємо на розкривне меню зверху зліва ADD SOFTWARE ADAPTER і обираємо Add iSCSI adapter:

Безпека iSCSI й використання CHAP

Ініціатори iSCSI використовують CHAP для автентифікації, але за замовчуванням CHAP не налаштований. Це може бути як односпрямована, так і двонаправлена автентифікація, чи взагалі по кожній цілі окремо. Налаштувати це можна отут:

Прив’язка VMkernel портів до ініціатора iSCSI

При застосуванні порт-біндінгу, кожен VMkernel порт, підключений до окремої NIC, стає іншим шляхом, яким може користуватися стек сховища iSCSI. Про те, як налаштовувати прив’язку, ми говорили вище, у розділі про мережі. З боку адаптерів сховища конфігурація виглядає так:

Розширення iSCSI для RDMA (iSER)

iSCSI Extensions for RDMA (iSER) надають високопродуктивне підключення iSCSI для стандартних RDMA NIC, підтримуване ESXi, починаючи з vSphere 7.0. При цьому вимагається наявність пристроїв з ввімкненим RoCE, а цільовий масив має підтримувати iSER на RoCE.

За налаштування iSER на ESXi-хості, фреймворк iSCSI на хості зможе використовувати транспортний протокол Remote Direct Memory Access (RDMA) замість TCP/IP. Щоб це сконфігурувати:

1. Включаємо адаптер VMware iSER за допомогою команд esxcli:

esxcli rdma iser add

2. Змінюємо загальні властивості для адаптерів iSCSI чи iSER (можна навіть дефолтне ім’я та alias);
3. Налаштовуємо прив’язку порту для iSCSI чи iSER (треба створити мережеві підключення для прив’язки механізму iSER та сумісного з RDMA мережевого адаптера);
4. Налаштовуємо динамічне чи статичне відкриття для iSCSI та iSER (динамічне відкриття означає, що кожного разу, коли ініціатор контактуватиме з вказаною системою сховища iSER, він надсилатиме запит SendTargets до системи. Зі статичним відкриттям доведеться вручну вводити інформацію по цілям);
5. Встановлюємо CHAP для iSCSI чи iSER (необхідно лише за використання вашим середовищем CHAP);
6. Включаємо джамбо-фрейми для мережі (якщо підтримується).

Важливо! iSER не підтримує NIC-тімінг. При конфігуруванні порт-біндінгу використовуйте лише один RDMA-адаптер на кожен віртуальний світч.

Fibre Channel

Fibre Channel SAN – це спеціальна високошвидкісна мережа, що підключає хости до високопродуктивних пристроїв зберігання. Щоб під’єднатися до цієї мережі, на хості мають бути Fibre Channel (HBA). Можна використовувати пряме підключення Fibre Channel до сховища, чи тримати світчі Fibre Channel для маршрутизації трафіку сховища. Якщо у хоста є FCoE-адаптер, до спільних пристроїв Fibre Channel можна підключитися через мережу Ethernet. При цьому хост підключиться до фабрики SAN, що складається з світчів Fibre Channel та масивів сховища, за допомогою адаптера Fibre Channel. LUN з масиву сховища стануть доступні на хості, і тоді можна буде створювати датастори для потреб власного сховища, що будуть використовувати VMFS-формат. Альтернативно, можна отримати доступ до масива сховища, що підтримує vSphere Virtual Volumes, і створити датастори vSphere Virtual Volumes на контейнерах масиву сховища. Компоненти Fibre Channel SAN та їх взаємозв’язки:

Адресація Fibre Channel та контроль доступу:

У Fibre Channel може бути реалізовано мультипасинг:

Він забезпечує рух від хоста до LUN за більш ніж одним шляхом, завдяки чому, навіть, якщо вийде з ладу апаратне забезпечення, доступ до SAN LUN буде й далі, та запроваджене балансування навантаження.

vSphere Virtual Volumes

vSphere Virtual Volumes віртуалізує пристрої SAN та NAS шляхом абстрагування ресурсів фізичного апаратного забезпечення до логічних пулів ємності. З ним вартість зберігання є нижчою, як і витрати на керування сховищем, масштабованість вражає, і взагалі це рішення чудово відповідає на вимоги аналітики та доступу до даних:

Функції vSphere Virtual Volumes:

• Нативне відображення VMDK на SAN/NAS – ніякого керування томами чи LUN;
• Працює з існуючими SAN/NAS-системами;
• Новий шлях керування операціями з даними на рівні ВМ та VMDK;
• Снепшоти, реплікації та інші операції на рівні ВМ на зовнішньому сховищі;
• Автоматизує контроль рівнів сервісів по кожній ВМ за допомогою політик зберігання;
• Стандартний доступ до сховища через vSphere API для кінцевої точки протоколу Storage Awareness;
• Контейнери сховища, що охоплюють цілий масив.

Архітектура vSphere Virtual Volumes це фреймворк інтеграції та керування, що віртуалізує масиви сховища, надаючи більш ефективну операційну модель, оптимізовану для віртуалізованих середовищ, що концентрується на застосунках замість інфраструктури.  У неї входять (що таке провайдери – розберемо нижче у спеціальному підрозділі):

• Провайдери сховища vSphere Virtual Volumes,
• Кінцеві точки протоколу (потрібні для встановлення шляхів даних за вимогою від ВМ до їх відповідних віртуальних томів, налаштовуються у системі сховища, можуть включати один або більше контейнерів сховища, підтримують SCSI (iSCSI/FC/FCoE) та NFS):
• Контейнери сховища (місце, де знаходяться віртуальні томи – логічні конструкції, що можуть охоплювати аж до усієї ємності масиву сховища, та логічно групують віртуальні томи, спираючись на потреби в керуванні та адмініструванні):
• Датастори Virtual Volumes;
• Віртуальні томи (об’єкти, що нативно зберігаються в системі сховища, підключаючись через Ethernet чи Fibre Channel мережу, інкапсуляція файлів ВМ, віртуальних дисків та їх деривативів, ідентифікуються за унікальним GUID та прив’язані до певної кінцевої точки протоколу, але одна точка протоколу може підключатися до багатьох віртуальних томів).

Система зберігання створює віртуальні томи (відповідають кожному файлу віртуального диска «-flat.vmdk») для основних елементів, які складають ВМ:

• Конфігурації віртуальних томів, що представляють віртуальні диски;
• Віртуальні томи даних, що містять файли конфігурації ВМ.

Подібно до файлів віртуальних дисків у традиційних сховищах даних, віртуальні томи представлені ВМ як диски SCSI, vSATA або vNVME. Віртуальний том конфігурації або домашній каталог являє собою невеликий каталог, який містить файли метаданих для ВМ. Файли метаданих включають файл VMX, файли дескрипторів для віртуальних дисків, файли журналу логів тощо. Конфігураційний віртуальний том відформатовано за допомогою файлової системи. Коли ESXi використовує протокол SCSI для підключення до сховища, конфігураційні віртуальні томи форматуються за допомогою VMFS. За допомогою протоколу NFS віртуальні томи конфігурації представлені як каталог NFS.

Додаткові віртуальні томи можна створювати для інших компонентів ВМ, таких як снепшоти та файли свопу. vSphere Virtual Volumes відображає об’єкти безпосередньо на віртуальні томи. Потім vSphere може перевантажити інтенсивні операції зберігання, такі як створення снепшотів, клонування та реплікація, на систему зберігання.

Реплікація vSphere Virtual Volumes

vSphere Virtual Volumes підтримує реплікацію, за допомогою якої можна розвантажити реплікацію ВМ на масив сховища та використовувати можливості реплікації масиву цілковито:

Звісно ж, для цього потрібно, щоб масив сховища підтримував реплікацію, хости ESXi мали версію 6.5 або новішу та були доступні vSphere API for Storage Awareness 3.0.

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

• Масиви зберігання, що використовуються для реплікації, мають бути сумісними з віртуальними томами vSphere та інтегровані з версією 3.0 або пізнішою VASA, сумісною з реплікацією віртуальних томів vSphere.
• Масиви зберігання мають бути здатні до реплікації та налаштовані на використання наданих вендором механізмів реплікації. Типові конфігурації зазвичай включають одну або дві цілі реплікації. Будь-які необхідні конфігурації, такі як об’єднання реплікованого сайту та цільового, також мають виконуватися системою зберігання.
• За можливості, групи реплікації та домени збоїв для віртуальних томів повинні бути попередньо налаштовані системою зберігання.

VMFS

Хости ESXi підтримують VMFS5 та VMFS6. Обидві файлові системи підтримують паралельний доступ до спільного сховища, динамічне розширення та блокування на диску. Але остання версія, до того ж, ще й нативні 4К пристрої сховища, автоматичне відновлення простору та цілих 128 хостів на один датастор.

Зауваження. Прямий апгрейд з VMFS5 на VMFS6 неможливий. Як змігрувати дані з однієї версії сховища на іншу докладно розглянуто у цьому КБ.

Взагалі ж, VMFS – це високопродуктивна кластеризована файлова система, де багацько ESXi-хостів можуть одночасно читати та записувати на один і той самий пристрій зберігання, що водночас слугує репозиторієм для файлів ВМ, шаблонів та ISO-образів:

Доступні функції:

• Міграція запущених ВМ з одного хоста на інший без простоїв;
• Автоматичний перезапуск несправної ВМ на окремому хості;
• Кластеризація ВМ на різних фізичних серверах.

До того ж, стан ВМ зберігається в центральному місці, забезпечується підтримка файлів віртуальних дисків (один такий файл може бути до 62 ТБ розміром), використовується адресація підблоків для ефективного використання сховища для невеликих файлів. А розподілене блокування на рівні блоків гарантує, що одна й та ж ВМ не буде увімкнена на декількох серверах одночасно. Якщо ж хост падає, блокування на диску для кожної ВМ знімається, й її можна перезапустити на інших хостах. VMFS можна розгорнути на DAS та сховищах Fibre Channel і iSCSI. Віртуальний диск, що зберігається у VMFS, відображається на ВМ як підмонтований пристрій SCSI, і при цьому фізичний рівень зберігання приховується від ОС ВМ. В результаті ОС бачить тільки власну файлову систему.

Створення VMFS-датастора

На будь-якому пристрої сховища, що розпізнається хостом, як сказано вище, можна створити VMFS-сховище даних. Робиться це у лівій бічній панелі на вкладці сховищ (третя зліва) – в Actions по шуканому дата-центру є пункт меню Storage , клацнувши на який можна обрати New Datastore:

З’явиться простенький помічник, у пунктах котрого задаємо усе, що він попросить.

Перегляд вмісту датастора

Контент сховища даних можна переглянути, якщо у лівій бічній панелі перейдемо на вкладку сховищ (третя зліва) й по дата-центру встати на вкладку Files:

Панель покаже список датасторів, що наразі налаштовані для усіх керованих ESXi-хостів. Він поданий у вигляді папок, що містять файли для ВМ чи шаблони.

Збільшення розміру VMFS-датастора

Однією з досить популярних задач по адмініструванню нашого середовища є збільшення розміру існуючих VMFS-сховищ даних – задля того, щоб забезпечити більше місця на ньому чи, можливо, покращити продуктивність. Загалом, перед тим як вдатися до змін у розподілі сховища, потрібно:

• Виконати ресканування, щоб впевнитися, що усі хости бачать найновіше сховище;
• Записати унікальний ідентифікатор тома, який хочемо розширити.

Динамічне розширення розміру VMFS-датастора може піти двома шляхами:

• Додавання LUN;
• Розширення сховища даних у рамцях его вмісту:

Важливо! Сховище даних може охоплювати кілька рівнів, загалом, до 32.

Режим техобслуговування для датастору

Перед тим, як вивести сховище даних з експлуатації, його треба помістити в режим технічного обслуговування. До цього маємо перемістити усі ВМ (й увімкнені, і вимкнені) та шаблони в інший датастор. Робиться це там же по шуканому датастору, де в Actions обираємо пункт Maintenance – Mode Enter Maintenance Mode:

З’явиться віконце попередження, в якому можна поставити галочку в Let me migrate storage for all virtual machines and continue entering maintenance mode after migration. Якщо це зробити, коли прямо зараз почне свою роботу помічник міграції, буде надана можливість перемістити ВМ на інший датастор. За наявності шаблонів, при цьому можна перетворити їх на ВМ, змігрувати ВМ, а потім знов конвертувати ВМ у шаблони.

Важливо! Maintenance Mode сховища – функція vSphere Storage DRS, але цей режим можна використовувати без активації vSphere Storage DRS. А от якщо vSphere Storage DRS налаштована й повністю автоматизована, міграції ВМ відбуватимуться автоматично.

Видалення або демонтування датастора VMFS

Якщо в нас відпала необхідність в якомусь датасторі, його можна демонтувати чи видалити – у клієнті vSphere по шуканому сховищу даних в Actions обираємо Unmount Datastore або Delete Datastore:

Демонтування зберігає файли на датасторі, але робить його недоступним для ESXi-хоста.

Важливо! Не можна робити ніякі конфігураційні операції, що можуть призвести до I/O на сховищі даних, коли демонтування ще знаходиться в процесі.

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

Важливо! До того, як розпочнете демонтування або видалення датастора, обов’язково вимкніть усі ВМ, чиї диски розміщені на ньому (інакше стикнетеся з помилкою, що ресурс зайнятий).

Важливо! До демонтування VMFS-сховища обов’язково треба пересвідчитися за допомогою клієнта vSphere, що:

• Жодні ВМ не розміщені на датасторі;
• Датастор не є частиною кластера датасторів;
• Датастор не керується vSphere Storage DRS;
• Деактивовано vSphere Storage I/O Control;
• Сховище не використовується vSphere HA heartbeat.

Щоб зберегти свої дані, рекомендується зробити бекап контенту усіх VMFS-сховищ, до того як розпочати видалення або демонтування.

Налаштування балансування навантаження для сховищ

Pluggable Storage Architecture – це рівень VMkernel, відповідальний за керування декількома шляхами зберігання та забезпечення балансування навантаження. ESXi-хост можна під’єднати до масивів зберігання з active-active чи active-passive налаштуваннями процесора сховища. У VMware є нативні механізми відновлення після відмови та балансування навантаження, що працюють завдяки спеціальним політикам: Round Robin, Most Recently Used (MRU) та Fixed. Але можуть використовуватися й рішення сторонніх вендорів.

Конфігурація цих можливостей відбувається по шуканому датастору, якщо в правій частині інтерфейсу встати на вкладку Configure в пункті бічного меню вкладки Connectivity and Multipathing:

Де обираємо потрібний датастор, і внизу у його картці у Actions треба натиснути Edit Multipathing – з’явиться вікно, в якому у Path selection policy обрати один з наступних варіантів:

• Most Recently Used (VMware). Хост обирає перший працюючий шлях, виявлений під час завантаження системи. Коли шлях стає недоступним, він переходить на альтернативний, і навіть коли той перший шлях знову стане доступним, хост до нього не повернеться. Це політика за замовчуванням для активних і пасивних пристроїв сховища даних і є обов’язковою для них.
• Round Robin (VMware). На додачу до перемикання шляхів після падіння, ця політика підтримує балансування навантаження між шляхами. За замовчуванням на хості активовано механізм затримки, він враховує пропускну здатність введення-виведення, щоб обрати для нього оптимальний шлях. З цим механізмом Round Robin дуже якісно співпрацює, динамічно обираючи шлях і досягаючи кращих результатів балансування навантаження. Але, ця політика доступна не для всіх пристроїв зберігання – консультуйтесь з вендором.
• Fixed (VMware). Хост завжди використовує бажаний шлях для диска, якщо такий шлях є доступним. Коли хост не може отримати доступ до диска через бажаний шлях, він піде альтернативним. Політика є політикою за замовчуванням для active-active пристроїв зберігання.

Відновлення простору сховища

Дані видаляються з датастору VMFS тільки, якщо або вони видаляються з гостьової ОС, або файл VMDK видаляється зі сховища даних. Інакше простір на масиві не вивільняється й його часто зовуть «мертвим» або «брудним». Отже, масив не може повторно використати цей простір до тих пір, поки ми не скажемо йому це зробити, наприклад, командою SCSI UNMAP. У VMFS5 ми вручну посилаємо відповідну esxcli-команду, а в VMFS6 ESXi-хост автоматично її надсилає на масив сховища.

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

esxcli storage vmfs unmap

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

-l | –volume-label=volume_label (Мітка тому VMFS, яку потрібно скасувати. Обов’язковий аргумент. Використовується або –l, або –u, ніколи разом)

-u | –volume-uuid=volume_uuid (UUID тому VMFS, який потрібно скасувати. Обов’язковий аргумент. Використовується або –l, або –u, ніколи разом)

-n | –reclaim-unit=number (Кількість блоків VMFS для скасування за ітерацію. Опціональний аргумент. Дефолтне значення – 200)

А для налаштування автоматичного вивільнення простору на VMFS6-датасторі, у процесі його створення в пункті помічника Partition configuration є поля Space Reclamation Granularity (визначає розмр юніту для команди UNMAP, за дефолтом – 1МБ) і Space Reclamation Priority (контролює швидкість, з якою видалені чи скасовані блоки відновлюються на LUN, що підтримує сховище даних, значення за замовчуванням – Low, що відповідає швидкості скасування у 25Мбіт/с):

Також можна налаштувати фіксовану швидкість автоматичного скасування для датастору – швидкість, з якою команди автоматичного UNMAP будуть виконуватися. Це робиться отут:

І, нарешті, залишилось згадати, що і VMFS5, і VMFS6 сховища даних підтримують команду unmap, що походить з гостьової ОС (якщо остання має таку можливість). І ось у цьому випадку для VMFS5 з’являється ще один (окрім скрипта) варіант налаштування автоматичного відновлення простору.

Важливо! Для надсилання команд unmap з гостьової ОС на масив сховища ВМ має задовільняти таким умовам:

• Віртуальний диск має бути thin-provisioned;
• Гостьова ОС має бути здатна ідентифікувати віртуальний диск як тонкий;
• У розширених налаштуваннях ESXi-хоста EnableBlockDelete має бути виставлене на 1:

Зауваження. Щодо VMFS6 при використанні налаштування Space Reclamation Priority опція EnableBlockDelete ігнорується. І треба пам’ятати, що запити unmap з гостьової ОС обробляються, тільки якщо цей простір дорівнює 1 МБ або є множиною таких клаптиків по 1 МБ.

Щодо конкретики налаштувань автоматичного скасування простору з метою його відновлення з гостьової ОС, що його підтримує, звертайтесь до документації її вендора.

NFS

NFS (мережева файлова система) – це протокол спільного використання файлів, який хости ESXi використовують для комунікації з приєднаним до мережі пристроєм сховища (NAS). NFS підтримує NFS 3 та 4.1 через TCP/IP. Таке сховище схоже на VMFS тим, що може тримати файли ВМ, шаблони, ISO-образи, томи NFS дозволяють міграцію vSphere vMotion машин, чиї файли розташовані в ньому:

У третій версії NFS VMware надає власний протокол підтримки блокування файлів, а от NFS 4.1 вже користується стандартним загальним протоколом Network Lock Manager (NLM) на стороні сервера. Через це різні версії NFS не можуть використовуватися для монтування одного сховища даних на кількох хостах. Порівняння доступності деяких технологій vSphere для цих версій мережевої файлової системи:

Технологія	NFS 3	NFS 4.1
vSphere vMotion і vSphere Storage vMotion	+	+
vSphere HA і vSphere Fault Tolerance	+	+
vSphere DRS і vSphere DPM	+	–
Stateless ESXi і Host Profiles	+	частково
vSphere Storage DRS і Storage I/O Control	+	+
Site Recovery Manager	+	+
vSphere Virtual Volumes і vSphere Replication	+	+
vRealize Operations Manager	+	+
Host Profiles	+	+

Конфігурування NFS-датастора

Щоб сконфігурувати потрібне нам сховище даних NFS, ми повинні зробити наступне, покроково:

1. Створюємо порт VMkernel (для кращої продуктивності рекомендується відділити мережу NFS від мережі iSCSI);
2. Створюємо NFS-датастор, увівши інформацію щодо:

• версії NFS (3/4.1),
• імені сховища,
• імен серверів NFS чи ІР-адрес,
• папки на NFS-сервері (матиме вигляд «/templates» чи «/nfs_share»),
• чи треба підмонтовувати файлову систему як дозволену тільки для читання,
• хостів, що монтують цей датастор,
• даних автентифікації.

Щоб використовувати Kerberos-автентифікацію, ми маємо додати кожен ESXi-хост до домену Active Directory, а потім налаштувати дані облікового запису NFS Kerberos:

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

Підготовка хостів до використання Kerberos полягає в налаштуванні параметрів клієнта NTP відповідно до загального NTP-сервера (чи домен-контролеру, якщо це можливо).

Важливо! NFS 3 та 4.1 використовують різні облікові дані автентифікації, що призводить до несумісності UID і GID на файлах. Крім того, враховуйте, що використання різних користувачів Active Directory на різних хостах, що мають доступ до того самого спільного NFS, може призвести до збою міграції vSphere vMotion.

Конфігурація NFS Kerberos може бути автоматизована за допомогою профілів хоста для зменшення її конфліктів.

Активація автентифікації Kerberos відбувається при створенні кожного датастору NFS 4.1 у відповідному помічникові під 4 його пунктом – Kerberos authentication:

Там є три варіанти вибору (не використовувати Kerberos взагалі, користуватися Kerberos тільки для автентифікації (krb5) чи для автентифікації та цілісності даних (krb5i)). Цінність KRB5i у забезпеченні виявлення атак типу «man-in-the-middle», що змінюють дані. Перша версія на це не здатна.

Демонтування NFS-датастора

Як і у випадку VMFS, демонтування NFS-сховища призводить до недоступності файлів на ньому для обраних ESXi-хостів.

Важливо! До демонтування NFS-датастора необхідно вимкнути усі ВМ, чиї диски розміщені на ньому.

Робиться це, традиційно, у Actions по сховищу, де є пункт Unmount Datastore:

Налаштування Multipathing для NFS 4.1

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

• Конфігурація одного VMkernel-порта;
• Прикріплення NIC до того ж фізичного світча, щоб налаштувати NIC-тімінг (групи NIC мають бути налаштовані на окремих зовнішніх світчах, причому кожна пара NIC сконфігурована як група на відповідному зовнішньому світчі);
• Конфігурування NFS-серверу з декількома ІР-адресами (навіть з однієї підмережі);
• Налаштування груп NIC з політикою IP hash load-balancing задля кращого використання декількох з’єднань.

В ідеалі, тільки один активний шлях має бути доступним для зв’язку між хостом ESXi та єдиною ціллю сховища (LUN чи точкою монтування), адже пропускна здатність єдиного сховища та базового обмежена тим, що дає лише одне з’єднання. Але альтернативні підключення мають місце для забезпечення відновлення після відмови. Щоб користатися більшою пропускною здатністю, ESXi-хосту треба дати декілька підключень до цільових сховищ – реалізація цього вимагає налаштування декількох датасторів, кожне з яких використовує окремі з’єднання між сховищем і хостом ESXi.

Щоб налаштувати мультипасинг для NFS 4.1 (ця версія сховища підтримує нативний мультипасинг та транкінг сеансу. Якщо транкінг доступний, можна користуватися декількома ІР-адресами для доступу до одного тому NFS. Транкінг Client ID не підтримується), потрібно при створенні нового датастору ввести декілька ІР-адрес сервера:

NVMe

Non-Volatile Memory Express (NVMe) – це стандартизований протокол для для високопродуктивного багаточергового зв’язку з пристроями NVM. ESXi підтримує протокол NVMe для підключення до локальних і мережевих пристроїв зберігання даних.

Починаючи з vSphere 7 впроваджені такі функції підтримки NVMe:

• Стек Pluggable Storage Architecture (PSA) із High-Performance Plug-In (HPP) з мультипасінгом. PSA — це відкрита модульна структура. Він координує програмні модулі, які відповідають за багатошляхові операції. Модулі включають загальні мультипасингові модулі (MPP) від VMware, наприклад, Native Multipathing Plug-In (NMP) і High Performance Plug-in (HPP), а також MPP сторонніх виробників;
• Додавання та видалення NVM-пристроїв на гарячу за підтримки цього сервером;
• Підтримка мережевих пристроїв NVMe, підключених через Fibre Channel або RDMA;

Щодо підтримуваних топологій NVMe слід відзначити, що сховище NVMe може бути напряму прикріплене до хоста з опосередкованою допомогою різних транспортних мереж, відомих як Shared NVMe over Fabrics, чи просто NVMe-oF. А саме:

Транспортний протокол NVMe	Підтримка у ESXi 7 і більш свіжих версіях
NVMe over PCIe	Локальне сховище
NVMe over RDMA	Спільного користування NVMe-oF сховище
NVMe over Fibre Channel (FC-NVMe)	Спільного користування NVMe-oF сховище
NVMe over TCP	Спільного користування NVMe-oF сховище

Для прикладу наведемо схему віддаленого доступу до NVMe-oF, що включає і FC-NVMe, і NVMe over RDMA топології:

FC-NVMe – це технологія, що дозволяє відобразити NVMe на протокол Fibre Channel. З нею дані й команди можуть переміщатися між комп’ютером хоста та цільовим пристроєм сховища. Для доступу до сховища FC-NVMe потрібно установити адаптер сховища Fibre Channel, що підтримує NVMe на ESXi-хості. Контролер, власне, налаштовувати не потрібно: після інсталяції потрібного апаратного забезпечення воно автоматично підключиться до всіх цілей та контролерів, до яких зможе дотягтися.

Сформулюємо вимоги, необхідні для реалізації FC-NVMe:

• Масив сховища Fibre Channel, що підтримує NVMe;
• NVMe-контролер на масиві сховища;
• ESXi 7+;
• Адаптер Hardware NVMe на ESXi-хості (типово, це HBA Fibre Channel, що підтримує NVMe).

Наразі актуальні такі конфігураційні максимуми для NVMe-oF: 256 просторів імен, 2048 шляхів, 4 шляхи на кожен простір імен на кожен хост.

Технологія NVMe over RDMA (RoCE v2) використовує RDMA для переміщення між двома системами в мережі. Обмін даними відбувається в головній пам’яті, оминаючи ОС та процесор обох систем. Її підтримка з включенням RDMA через мережу Ethernet забезпечена у ESXi 7 і більш новітніх версіях. Щоб отримати доступ до сховища, ESXi-хост використовує мережевий адаптер RDMA, проінстальований на хості, та програмний адаптер NVMe over RDMA.

Вимоги для NVMe over RDMA (RoCE v2):

• Масив сховища NVMe з транспортною підтримкою NVMe over RDMA (RoCE v2);
• NVMe-контролер на масиві сховища;
• ESXi 7+;
• Світчі Ethernet з підтримкою безвтратної мережі;
• Мережевий адаптер на ESXi-хості, що підтримує RoCE v2;
• Програмний адаптер NVMe over RDMA, увімкнений на ESXi-хостах.

У цьому разі конфігураційні максимуми становлять: 32 простори імен, 128 шляхів та по 4 шляхи на простір імені по кожному хостові.

Щоб налаштувати ESXi для NVMe over RDMA (RoCE v2):

1. Інсталюємо мережевий інтерфейс на ESXi-хості, що підтримує RDMA (RoCE v2):
2. У клієнті vSphere пересвідчуємось, що RDMA-адаптер знайдений хостом;
3. Налаштовуємо прив’язку VMkernel для адаптера RDMA:
4. Перевіряємо конфігурацію прив’язки VMkernel для адаптера RDMA;
5. Виявляємо NVMe-контролери на масиві (автоматично чи вручну) – ставимо прапорець в Add software NVMe over RDMA adapter та обираємо з розкривного меню відповідний адаптер:
6. Повторно скануємо сховище, щоб знайти простір імен NVMe;
7. Створюємо власні сховища даних.

А от за vSAN у подробицях ми поговоримо якось іншим разом – у запланованому на найближче майбутнє присвяченому йому циклі статей, як одному з найулюбленіших й найцікавіших продуктів VMware.

Провайдер сховища та vSphere Storage APIs for Storage Awareness та vSphere APIs for I/O Filtering (VASA і VAIO)

vSphere API for Storage Awareness (VASA) допомагає вендору сховища розробити програмний компонент, названий провайдером сховища для його масивів. Через ці API провайдер сховища отримує інформацію про доступну топологію сховища, можливості та статус, слідкує за здоров’ям LUN. Також це дуже допомагає у налаштуванні політик зберігання ВМ з правильним сховищем у сенсі простору, продуктивності та вимог SLA.

vCenter підключається до провайдера сховища і інформація з такого провайдера з’являється в клієнті vSphere – її можна побачити, якщо пройти у vCenter на вкладку Configure – Storage Providers:

Провайдери сховищ бувають таких типів за принципом роботи:

• Постійні – керують абстракціями масивів та сховища, надають сервіси даних, наприклад, реплікацію на базі масивів (vSAN storage provider, vSphere Virtual Volumes storage provider);
• Data Service Providers – провайдери I/O фільтрації сховища чи провайдери сервісу даних (кешування на базі хоста, компресія, шифрування).

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

• Вбудовані – запропоновані VMware, зазвичай, не потребують реєстрації (провайдери сховищ, що підтримують vSAN чи I/O фільтрацію);
• Сторонні – запропоновані стороннім вендором та, типово, вимагаючі реєстрації (vSphere Virtual Volumes storage provider, vSphere APIs for Storage Awareness storage provider).

Щоб зареєструвати нового провайдера сховища, у клієнті vSphere проходимо в Configure – Storage Providers:

vSphere APIs for I/O Filtering (VAIO) надає фреймворк для створення та впровадження фільтрів I/O у потік даних ВМ. Фільтри вводу-виводу перехоплюють і змінюють I/O диску ВМ у VMkernel до того, як дані будуть передані у/з фізичного сховища, і залежать від топології зберігання. VAIO також дуже корисна для створення VMware та сторонніми вендорами сервісів даних, наприклад, кешування та реплікації.

Зауваження. I/O-фільтри підтримуються у всіх типах датасторів (VMFS, NFS 3, NFS 4.1, vSphere Virtual Volumes, vSAN).

Типи I/O фільтрів:

• Replication (реплікація) – реплікує усі записані операції вводу-виводу на зовнішню цільову локацію, наприклад, на інший хост чи кластер;
• Encryption (шифрування) – надає механізм шифрування для ВМ;
• Caching (кешування) – впроваджує кешування даних віртуального диску;
• Storage I/O Control – пріоритезує вводи-виводи сховища, виділені для ВМ протягом періодів конкуренції I/O.

І саме у такому порядку застосовуються фільтри в процесі роботи фреймворку:

Деякі з цих типів фільтрів вже проінстальовані на хостах ESXi. На додачу, партнери VMware можуть створювати власні варіанти через програму розробки vSphere APIs for I/O Filtering.

Інформацію щодо провайдера I/O фільтрації по кожному хосту можна продивитися, обравши об’єкт у інвентарі та пройшовши на вкладку Configure – Storage Providers:

Керування сховищем за допомогою політик

Storage policy based management (SPBM) гарантує, що ВМ використовуватиме сховище зі вказаним рівнем ємності, продуктивності, доступності, надлишком тощо. Фактично, воно абстрагує сервіси сховища та даних, запропоновані vSAN, vSphere Virtual Volumes, I/O фільтрами чи традиційними службами:

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

Політика сховища ВМ контролює, який саме тип сховища надається для ВМ й як вона розміщена в ньому, а також які сервіси даних можуть використовуватися. З нею легко категоризувати датастори, спираючись на рівень сервісу. Політики сховища ВМ фіксують характеристики зберігання, необхідні для домашніх файлів/об’єктів ВМ та віртуальних дисків для запуску програм на ній. Ці характеристики сховища визначені в наборі правил.

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

• Правила розміщення на основі можливостей – вказівка конкретної вимоги сховища для ВМ, що визначає її розміщення (наприклад, RAID level, Number of failures to tolerate);
• Правила розміщення на основі тегів – посилання на теги сховища для визначення розміщення ВМ (наприклад, Gold Tier tag, Silver Tier tag, Bronze Tier tag);
• Правила сервісів даних – активує вказані сервіси даних для ВМ, але не визначає розміщення у сховищі та вимоги до нього для ВМ (кешування, реплікація).

Коли створюється політика сховища, можна обирати одне або більше правил:

Кожна політика сховища може включати один або декілька повторно використовуваних та взаємозамінних будівельних блоків, які називаються компонентами політики сховища, за допомогою сервісів VAIO (див. вище). Кожен такий компонент описує один тип сервісу від провайдера сховища та їх різномаїття залежить від цього провайдеру (зазвичай, або реплікація, або шифрування, кешування чи Storage I/O Control). Ось ілюстрація цього твердження:

Налаштування сховища для використання політик сховища

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

Компонент політики сховища створюється так:

А сама політика отак:

Розберемо пункти помічника її створення:

1. Name and description. Обираємо систему vCenter Server, називаємо нашу нову політику та даємо їй опис:
2. Policy Structure. Обираємо або Host based services (визначає правила для дозволу та налаштування сервісів даних, наданих хостом через VAIO), або Datastore specific rules (описує вимоги чи сервіси для типу сховища через VASA та методи тегування):
3. Tag based placement. Цей пункт з’являється, якщо в попередньому зупинились на другому варіанті й поставили галочку в Enable tag based placement rules (наприклад, коли створюємо політику сховища Silver Tier). Тут обираємо категорію тега, а сам тег можна знайти, якщо натиснути на кнопку Browse tags і у вікні, що відкрилося, поставити галочку на шуканий:
4. Storage compatibility. Тут на вкладці Compatible продемонструються сховища, що є сумісними:
5. Review and finish. Переглядаємо зроблені налаштування й завершуємо створення нової політики.

Далі, коли будемо вчитися створювати ВМ, можна буде призначити створену політику (коли її оберемо, покажуться сумісні датастори, які треба буде обрати прапорцем):

Перевірка сумісності для політики зберігання ВМ

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

Політики зберігання для vSphere Virtual Volumes

ВМ, що запущена на віртуальних томах датастора вимагає політики зберігання ВМ. Якщо не буде створено політику зберігання ВМ, сумісну зі сховищем віртуальних томів, система використовуватиме дефолтну політику No Requirements, через що не буде задано жодних правил або специфікацій зберігання, і масиви зможуть визначати власноруч оптимальне розміщення для об’єктів ВМ:

Створити політику сховища Virtual Volumes можна, вказавши в другому пункті помічника, Policy structure, відповідну галочку в полі, що відповідає за VVOL:

Тоді з’явиться специфічний для цього випадку третій пункт помічника (назва буде характерною для існуючого вендора) – наприклад, EMC.UNITY.VVOL rules – де обираємо потрібні правила:

Застосування політик Storage I/O Control

Storage I/O Control розширює поняття спільного користування, обмежень та резервування до обробки ресурсів вводу-виводу. Це пропорційний планувальник операцій I/O (IOPS), що при наявності конкуренції регулює IOPS. Завдяки ньому можна регулювати обсяг вводів-виводів сховища, виділених ВМ, у періоди конкуренції. Контроль над I/O сховища гарантує, що більш важливі ВМ отримають перевагу над менш важливими у сенсі виділення ресурсів вводу-виводу:

Спільне користування I/O сховища ідентичне тому, що ми розглядали вище, коли говорили за виділення ресурсів пам’яті та CPU. Спільне користування може позначатися, зазвичай, як High, Normal чи Low і їх значення співвідносяться як 4:2:1. Можна також обрати Custom, щоб призначити бажане число спільних користувань для кожної ВМ. Тоді ВМ з вищим значенням спільного користування матимуть більший доступ до масиву сховища.

Також, коли виділяємо ресурси вводу-виводу сховища, можемо обмежити дозволені ВМ IOPS. За замовчуванням вони не лімітовані.

За дефолтом, Storage I/O Control вимкнено. Щоб скористатися його перевагами, доведеться увімкнути цю функцію на датасторі, і тоді усі ВМ на ньому матимуть дефолтні 1 000 спільних користувань дисками, жодного обмеження IOPS та ніякого резервування. Але, всі ці параметри можна відконфігурувати, як бажано шляхом застосування відповідної політики сховища.

Зауваження. При ввімкненні Storage I/O Control, ESXi стежить за затримкою датастору та регулює навантаження вводу-виводу, якщо середня затримка перевищує порогове значення, збирає статистику продуктивності та використовує всі ці знання задля покращення поведінки vSphere Storage DRS. Поріг, до речі, визначається автоматично (дефолтні 30мс), проте його можна змінити за бажанням, встановивши конкретне значення затримки. Майте на увазі, що дефолтне значення може підійти до деяких пристроїв зберігання, але інші можуть досягти свого порогового значення затримки задовго до або після досягнення параметра за замовчуванням.

Вимоги Storage I/O Control:

• Підтримується тільки на сховищах, що керуються єдиною системою vCenter;
• Підтримуються на Fibre Channel, iSCSI, VMFS і NFS3 сховищах, проте vSAN та virtual volumes датастори не підтримуються, як і пряме підключення до СХД;
• Не підтримуються сховища з декількома розширеннями;
• Якщо датастори розташовані на масивах з можливістю автоматизації рівня зберігання, масив має бути сертифікованим як сумісний з Storage I/O Control.

Налаштування Storage I/O Control

Насправді, говорячи про технолгію Storage I/O Control ми маємо на увазі впровадження фільтрації вводів-виводів. Вбудовані компоненти політики зберігання визначають можливості Storage I/O Control:

І цей компонент можна використовувати, як є, у Storage I/O Control, або створити користувацький, що буде визначати обмеження IOPS, резервування та спільне користування. Цей компонент застосується у політиці зберігання, а потім цю політику зможемо призначити ВМ:

Storage I/O Control і vSphere Storage DRS

Як ми вже згадували, Storage I/O Control збирає для vSphere Storage DRS статистику затримки по ESXi-хосту, посилає її у vCenter та зберігає в його БД. Завдяки цій статистиці vSphere Storage DRS знає, коли треба змігрувати ВМ на інший датастор. За допомогою Storage I/O Control можна збалансувати навантаження вводів-виводів у кластері сховища даних, на якому ввімкнено vSphere Storage DRS. Робиться це отут:

Робота з віртуальними машинами

Віртуальні машини мають декілька переваг у порівнянні з фізичними:

• Полегшене переміщення чи копіювання;
• Незалежність від фізичного апаратного забезпечення, адже ВМ інкапсульовані у файли;
• Ізольованість від інших ВМ, запущених на тому самому фізичному hardware;
• Захищеність від змін фізичного обладнання:

Будь-який застосунок в будь-якій підтримуваній ОС може запускатися на ВМ (гості) та використовувати CPU, пам’ять, диск та мережу з базованих на хості ресурсів:

Декілька ВМ, запущені на фізичному хості спільно користуються його обчислювальними, пам’яттю, мережею та ресурсами сховища.

А взагалі, як ми вже казали у статті «Інсталяція vSphere 8.0 з нуля», кожна ВМ зберігається у вигляді колекції файлів чи об’єктів (відповідна директорія з файлами буде на VMFS чи NFS датасторі, або це будуть об’єкти у сховищі даних vSAN чи vSphere Virtual Volumes). При цьому один віртуальний диск інкапсулюється у єдиний файл чи об’єкт:

За виключенням файлів логів, ім’я кожного файлу ВМ міститиме її назву. У папці ВМ будуть такі файли:

• конфігураційний файл (якщо ВМ була перетворена на шаблон, то замість нього буде конфігураційний файл шаблону),
• своп-файли, що використовуються для відновлення пам’яті у періоди конфліктів,
• файл з BIOS чи EFI параметрами для ВМ,
• поточний лог-файл та набір файлів, що використовуються для архівації старих записів журналів логів – до 6 таких архівацій можуть підтримуватися одночасно (коли запишеться сьомий, він замістить 1-й, 1-й замінить 2-й і т. д., аж поки 6-й не видалиться),
• файл з описом диску та файл з даними диску (якщо дисків більше одного, стільки ж і відповідних файлів утвориться, з цифровою індикацією у назві),
• файл статусу Suspend.

Цей перелік загальний, але не вичерпний.

Вміння працювати з ними полягає у змозі їх створювати, клонувати, керувати ними та шаблонами та оновленні шаблонів.

Надання віртуальних машин

Через vSphere Client чи VMware Host Client можна створювати ВМ декількома методами:

Метод	vSphere Client	VMware Host Client
Помічник New Virtual Machine	+	+
З існуючих шаблонів чи клонів	+	–
З OVF-шаблонів	+	+

Вибір оптимального методу спирається на розмір і тип інфраструктури та мету, яку перед собою ставите. Перший метод актуальний для підготовки машин з унікальними характеристиками, якщо жодна в середовищі її не нагадує. Клонування з шаблонів (створюєте одну та інсталюєте ОС на ній) дуже пришвидшує процес надання нових однотипних машин. Розгортання з Open Virtual Machine Format (OVF) доступне з локальних файлових систем (дисків тощо), знімних носіїв (CD/USB), спільних мережевих дисків чи URL.

Створення ВМ через помічник New Virtual Machine

У клієнті vSphere, в інвентарі стаємо на хост і в Actions прямо найпершим пунктом йде New Virtual Machine:

Відкриється відповідний помічник, у першому кроці якого (Select a creation type) обираємо Create a new virtual machine, як показано на скріншоті. Далі йдемо його пунктами:

1. Select a name and folder. Даємо ім’я нашій новій ВМ та обираємо для неї папку розташування:
2. Select a compute resource. Обираємо хост, на чиїх ресурсах буде запускатися ВМ:
3. Select a storage. Обираємо політику зберігання з розкривного списку, датастор, де ВМ буде тримати свої файли (ставимо прапорець у той, що пасує за своїм розміром, швидкістю, доступністю та іншими властивостями – всі характеристики наведені у списку):

Якщо хочемо не використовувати Storage DRS, ставимо галочку під політикою;

4. Select compatibility. Обираємо версію ESXi, з якою ВМ буде сумісною:
5. Select a guest OS. Обираємо, яку гостьову ОС хочемо проінсталювати на ВМ (сімейство, версія):
6. Customize hardware. Налаштовуємо віртуальне апаратне забезпечення для машини. Одразу покаже дефолтні значення, що були визначені, спираючись на обрану вище гостьову ОС:

Також саме тут можна підмонтувати ISO-образ, що містить інсталяційні файли гостьової ОС. Тему налаштувань апаратного забезпечення докладно наведемо нижче (корисно, якщо конфігурація за замовчуванням не влаштовує);

7. Ready to complete. Переглядаємо усі зроблені налаштування та тиснемо Finish, щоб розпочати створення ВМ.

Далі побачимо, як інсталюється гостьова операційна система – те саме, що нам добре знайоме із звичайних інсталяцій системи на фізичних комп’ютерах:

Налаштування hardware ВМ

Наша гостьова ОС отримує доступ до пристроїв апаратного забезпечення, причому, вона не знає, що вони віртуальні, а не фізичні. Ось усе, що потрібно для функціонування ВМ:

Щодо цієї ілюстрації потрібно зробити декілька важливих зауважень.

Зауваження. У всіх ВМ уніфіковане апаратне забезпечення (за деякими винятками з волі системного адміністратора) для забезпечення їх портуємості між платформами віртуалізації VMware.

Зауваження. Не усі пристрої можна додавати та налаштовувати під час створення ВМ. Наприклад, додавати не можна відео-пристрої, проте, якщо є доступні відео-пристрої та відео-карти, їх можна сконфігурувати.

Зауваження. USB-пристрої доступні лише для однієї ВМ в один момент часу. Якщо його видалити на одній машині, він стає доступним для вибору на інших, що є на хості.

Віртуальне hardware має версію (про це згадували, коли говорили про сумісність і вимоги у матеріалі про «Інсталяцію…»), яку ще іноді називають рівнем сумісності – він визначає функції ОС, які підтримує ВМ.

Важливо! Версія апаратного забезпечення не може бути вищою за ту, яка є актуальною для тієї чи іншої генерації нашого гіпервізора. Але може бути навпаки. Ось табличка, що ілюструє таку сумісність:

Версія гіпервізора	Версія Hardware
ESXi 8.0	20
ESXi 7.0 U2 +	19
ESXi 7.0 U1 +	18
ESXi 7.0 +	17
ESXi 6.7 U2 +	15
ESXi 6.7 +	14

16-а версія апаратного забезпечення є специфічною для Workstation і Fusion Pro.

Коли ми обирали у помічнику New Virtual Machine у підрозділі вище сумісність (версію ESXi, Select compatibility), нам там показували, яка версія апаратного забезпечення буде оптимальною для нашого сетапу.

Взагалі, доступне додавання, зміна чи налаштування ресурсів CPU та пам’яті у пункті Customize hardware згаданого помічника задля покращення продуктивності ВМ. Максимальні конфігураційні значення цих ресурсів наводилися у підрозділі «Конфігураційні ліміти» статті про інсталяцію vSphere 8.0. Ці налаштування, до речі, можна змінити й по вже існуючій ВМ, якщо відредагувати її параметри, проте, обов’язково перед тим її треба вимкнути – як редагувати машинку розглянемо нижче у відповідному підрозділі.

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

• Thick Provisioned (використовує увесь визначений дисковий простір при створенні віртуального диску, незалежно від того, чи дійсно він використовується файловою системою гостьової ОС),
• Thin Provisioned (ВМ використовує дисковий простір за потреби. Диски користуються лише ємністю, що потрібна для зберігання поточних файлів, проте машина завжди бачить увесь виділений розмір диску).

Для Thick provisioning відомі два підтипи: Lazy-Zeroed та Eager-Zeroed. У першому блок заповнюється нулями до того моменту, коли дані будуть записані уперше. Другий же варіант означає, що кожен блок буде попередньо заповнений нулями.

Тонке надання надає сигнали тривоги та звіти, що відстежують розподіл порівняно з поточним використанням ємності сховища. Завдяки їх властивостям, користувачі можуть оптимально, проте безпечно отримувати доступний дисковий простір. Команда «unmap» допомагає вивільняти невикористаний простір з віртуальних дисків (вище в розділі про ресурси ми про неї розповідали). Коли повна ємність тонких віртуальних дисків перевищує загальну ємність сховища даних, воно переповнюється, і тоді клієнт vSphere запропонує нам надати більше місця у базовому сховищі VMFS. ВМ на цей час призупиняться, якщо спробують щось записати на сховище. Можна налаштувати сигнали тривоги з цього приводу (використання ВМ диску/перевиділення диску сховища даних), щоб вчасно зреагувати на проблему шляхом збільшення розміру датастора. Також, як варіант, розглянути використання vSphere Storage vMotion – міграція здійсниться шляхом зміни віртуальних дисків товстого формату тонкими у цільовому датасторі. Про усі ці можливості нижче згодом поговоримо.

Обидва формати, Thick і Thin, можна міксувати у середовищі.

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

• тип мережевого адаптеру з розкривного списку (Аdapter type),
• порт-група, до якої підключаємось (прямо навпроти Network adapter 1, коло галочки у Connected),
• статус мережевого підключення (Status),
• вказівка, чи підключатися до мережі, коли ВМ увімкнені.

Типи мережевих адаптерів (NIC) можна вказувати у налаштуваннях, коли їх додаємо. Рекомендовано, якщо вкрай не необхідне інше, використовувати завжди VMXNET3. Проте, пам’ятайте, що йдуть вони лишень у комплекті з використанням VMware Tools. Інші типи, для довідки:

• E1000-E1000E (емульована версія Intel Gigabit Ethernet NIC з драйверами, доступними у найновіших гостьових ОС),
• Flexible (може функціонувати і як Vlance, і як VMXNET адаптер),
• PVRDMA (паравіртуалізований пристрій, що забезпечує покращену продуктивність віртуального пристрою, з інтерфейсом, схожим на RDMA для гостей vSphere),
• SR-IOV pass-through (дозволяє ВМ та фізичному адаптеру обмінюватися даними без використання VMkernel як посередника).

Також у налаштуваннях апаратного забезпечення, як ми бачимо на скріншоті вище, можна додавати різноманітні віртуальні пристрої, що надають ВМ зростання корисності. Це, зокрема, пристрої CD/DVD (для підключення до відповідних приводів чи ISO-образу), USB 3.0/3.1, флоппі, додаткові SCSI-адаптери, vGPU, кріптопроцесор vTPM 2.0 для безпекових функцій на базі hardware та інші.

Розгортання OVF-шаблонів

Віртуальний appliance – це попередньо налаштована ВМ, що зазвичай містить попередньо встановлену гостьову ОС та інше необхідне ПО. Його можна додати або імпортувати до інвентаря системи vCenter Server чи інвентаря ESXi з VMware Marketplace. Віртуальні appliance розгортаються як шаблон OVF, що є незалежним від платформи, ефективним, масштабованим та для якого характерний відкритий формат упаковки та розповсюдження ВМ. Файли OVF стискаються задля пришвидшення завантаження.

Щоб розгорнути OVF-шаблон за допомогою клієнта vSphere, клікаємо на об’єкт, що пасує (хост ESXi, дата-центр тощо) та обираємо Deploy OVF Template – з’явиться відповідний помічник:

На першому його кроці Select an OVF template натискаємо кнопку UPLOAD FILES, як показано на скріншоті, щоб обрати потрібний файл. vSphere Client валідує OVF-файл перед імпортом та гарантує його сумісність з сервером призначення. Несумісні з хостом файли не імпортуються.

А далі йдемо кроками помічника – майже такими самими, що й у випадку створення ВМ через помічник New Virtual Machine, розглянутий підрозділом вище.

Видалення ВМ

Видалення ВМ зробити можна кількома шляхами:

• Видалити з інвентаря (знімається реєстрація ВМ з ESXi-хоста та vCenter, її файли лишаються на диску і її можна буде пізніше повторно додати до інвентаря);
• Видалити з диску (усі файли ВМ перманентно видаляться з датастору, знімається реєстрація ВМ з ESXi-хоста та vCenter).

Для цього в другій вкладці головного бічного меню стаємо на потрібну машину і в Actions обираємо одну з вищезгаданих опцій (Remove from inventory/Delete from Disk):

VMware Tools

VMware Tools гідні того, щоб їм присвятити цілий окремий підрозділ (раніше щодо колишніх версій vSphere ми навіть відводили на них персональну статтю). VMware Tools – це набір функцій, що покращують продуктивність гостьової ОС ВМ, замінюючи загальні драйвери ОМ драйверами VMware, що спеціально прилаштовані для віртуального апаратного забезпечення, а саме мають і забезпечують:

• Драйвери пристроїв (дисплей SVGA, VMXNET/VMXNET3, драйвер Balloon driver для керування пам’яттю, драйвер синхронізації для заспокоєння I/O, паравіртуальний SCSI контролер);
• Збільшення продуктивності графіки;
• Загальний доступ до папок у системі хоста та гостьової файлової;
• Копіювання та вставка тексту, графіки та файлів між ВМ та хостом чи десктопом клієнта;
• Покращення продуктивності миші;
• Сервіс heartbeat для гостьової ОС;
• Синхронізація часу;
• Скриптування, що допомагає автоматизувати операції гостьової ОС;
• Вміння вимикати ВМ віддалено.

VMware Tools інсталюються в гостьову ОС разом з:

• службою VMware Tools (синхронізує час у гостьовій ОС з часом у головній ОС),
• набором драйверів пристроїв VMware з додатковими опціями моніторингу Perfmon,
• набором скриптів, що допомагають автоматизувати операції гостьової ОС (можна налаштувати виконання скриптів при зміні статусу живлення ВМ).

Зауваження. Гостьова ОС може працювати, взагалі-то, й без VMware Tools, але багато функцій VMware при цьому будуть недоступні. Наприклад, опції вимкнення чи перезапуску з панелі інструментів – тільки опції живлення.

Інсталяція VMware Tools

Важливо! Треба переконатися, що обрана версія VMware Tools є найсвіжішою для вашої гостьової ОС.

Поточна версія VMware Tools завжди пакується разом з vSphere 8 – знайти її можна на сторінці завантажень відповідно до рівня ліцензії:

Відповідно, там проходимо в GO TO DOWNLOADS й завантажуємо наші VMware Tools. Метод їх інсталяції залежить від типу обраної гостьової ОС:

Тип гостьової ОС	Метод інсталяції VMware Tools
Microsoft Windows	З «windows.iso» для Vista й більш нових гостів
Linux	Одне з двох: •       Або з «linux.iso»; •       Або для більш свіжих дистрибуцій Linux  використовуємо open-vm-tools, доступні у різноманітних management-пакунках Linux-систем package management, наприклад, «yum», «apt» чи «rpm».

Центральний репозиторій для VMware Tools

Використання центрального репозиторію (іноді можна стріти назву «product locker») для VMware Tools має безліч переваг:

• Оптимізація оновлення та встановлення VMware Tools в середовищі;
• Єдина локація для VMware Tools, що значно спрощує процес оновлення до останньої версії;
• Для будь-якого хоста ESXi, що має доступ до спільного сховища, можна вказати центральне сховище для апдейту VMware Tools;
• Стандартизація версії ISO VMware Tools на кількох хостах;
• Більш швидке споживання останніх версій VMware Tools;
• Ширше охоплення різноманітних гостьових ОС.

Щоб запровадити такий центральний репозиторій:

1. Копіюємо потрібні пакети софта VMware Tools у папку на існуючому або новому спільному сховищі;
2. Оновлюємо UserVars.ProductLockerLocation на кожному хості ESXi. Для цього у клієнті vSphere в Advanced System Settings по ESXi вписуємо нове розташування:

Або за допомогою ESXi Shell:

3. Перевантажуємо чи вручну включаємо змінену конфігурацію, видаливши символічне посилання (symlink) та повторно створивши його в vCenter MOB, щоб вказати на видобутий каталог у датасторі. Задля цього спочатку викликаємо API за допомогою vCenter Managed Object Browser (MOB), куди увійти можна з обліковим записом administrator@vsphere.local account. Там проходимо в content > rootFolder > childEntity > hostFolder:

Або відкриваємо АРІ напряму за допомогою Host ID, обравши хост в клієнті vSphere з URL, що включає ідентифікатор хоста (наприклад, «https://<vcenter_fqdn>/mob/?moid=host-4007&method=updateProductLockerLocation»):

Консоль віртуальної машини

Контролювати ВМ можна за допомогою її консолі, де функціонують миша, клавіатура та дисплей. Вона може бути Web-консоллю (окрема вкладка браузера) чи віддаленою (для неї треба завантажити VMware Remote Console (VMRC) – окремий застосунок, що дозволяє підключатися до клієнтських пристроїв та запускати консолі ВМ на віддалених хостах):

Відкривається консоль ВМ з клієнта vSphere, і з неї можна отримати доступ до BIOS чи EFI машини, інсталяції ОС, увімкнення/вимкнення живлення та до її перезапуску. Зазвичай, для щоденних завдань вона не використовується – краще це робити через підключення до віддаленого робочого стола, підключення до віртуальної мережі або інше.

Модифікація віртуальних машин

На вже існуючій ВМ можна відредагувати її налаштування задля зміни конфігурації шляхом:

• Додавання/видалення віртуального апаратного забезпечення. Перше можливе й при увімкненій машині, друге – лише у вимкненому стані;
• Налаштування опцій ВМ;
• Контролю над ресурсами пам’яті та CPU:

Редагування віртуального апаратного забезпечення ВМ

Для додавання пристрою, наприклад, ми заходимо на першу вкладку редагування параметрів ВМ (Virtual Hardware) й справа скраю буде розкривне меню ADD NEW DEVICE, як показано на скріншоті, де обираємо шуканий пристрій.

Щодо CPU та пам’яті, при підтримуваній гостьовій ОС, ми можемо додавати ресурси до запущеної машини – галочку в Enable по CPU Hot Plug або Memory Hot Plug у відповідних блоках налаштувань. Також підключення «на гарячу» можна організувати за такими пристроями, як USB-контролери, Ethernet-адаптери та пристрої жорстких дисків.

Важливо! Функція hot-plug працює лишень за встановлених VMware Tools 11+ версії.

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

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

Робиться це отут:

Крім того можна підвищити диски тонкого надання до товстого формату (eager/zeroed) двома способами: або обранням thick-provisioned при використанні vSphere Storage vMotion для міграції ВМ на інший датастор, або обранням файла ВМ з розширенням «.vmdk» (коли стоїмо на цій машині в інвентарі датастора, вкладка Files) та натисненням на функціональний напис Inflate у верхньому меню:

Редагування VM Options

Друга вкладка редагування ВМ присвячена загальним властивостям, на кшталт імені, типу ОС, конфігураційного файлу, директорії, у якій має працювати ВМ тощо:

Там же є блок для VMware Tools, де можна кастомізувати кнопки живлення для ВМ, налаштувати перевірку, чи є оновлення VMware Tools (галочка в Check and upgrade VMware Tools before each power on), синхронізацію часу (Synchronize guest time with host) та характер роботи зі скриптами:

І, нарешті, параметри завантаження ВМ (Boot Options):

Справа в тому, що коли ВМ створюється та обирається гостьова ОС, BIOS чи EFI обирається автоматично, залежно від вбудованого firmware, підтримуваного ОС. Якщо ОС підтримує і те, й інше, за бажанням, можна змінити опцію завантаження. Проте, зробити це треба до інсталяції гостьової ОС. Для UEFI можна поставити галочку в Secure Boot, і тоді кожна частина завантажувального софта буде підписуватися, включно з завантажувачем, ядром ОС та її драйверами. У цьому випадку завантажувати в таку ВМ можна буде лише підписані драйвери. У Boot Delay ми виставляємо час затримки між увімкненням ВМ та завантаженням ОС. Також можна змінити налаштування BIOS чи EFI поставивши галочку в примусовому завантаженні (Force EFI/BIOS setup) – силовий вхід в сетап firmware є навіть легшим, ніж увімкнення ВМ, відкриття консолі і намагання якомога швидше натиснути F2. І, нарешті, опція Failed Boot Recovery налаштовує машину на повторну спробу запуску кожні n секунд (обирається), дефолтне значення 10, якщо вона не спроможна одразу знайти завантажувальний пристрій.

Клонування ВМ

Клонування ВМ створить машинку, що буде точною копією оригіналу. Це альтернатива розгортанню ВМ з шаблону (розглянемо нижче у відповідному підрозділі). При цьому байдуже, увімкнена машина чи ні. Для клонування ВМ маємо бути підключеними до vCenter (не з VMware Host Client!).

Для цього встаємо на ВМ-джерело, в Actions – Clone – Clone to Virtual Machine:

Щоб вибрати, що для вас краще – склонувати працюючу ВМ, чи запустити розгортання за шаблоном, врахуйте наступне:

• Розгортання ВМ з шаблону змусить їх усіх починатися з одного й того самого базового образу, а якщо ви декілька машин спробуєте склонувати при увімкненому стані джерела, усі клони можуть не вийти ідентичними – залежить від активностей на ВМ в процесі;
• Розгортання з шаблонів значно пришвидшує процес надання нових машин, на відміну від клонування запущеної, якщо робимо з неї багато одночасно;
• Шаблони ВМ використовують дисковий простір – плануйте вимоги до нього відповідно.

Робота з шаблонами ВМ

Template (шаблон) – це статичний образ віртуальної машини, що, зазвичай, включає:

• Гостьову ОС,
• Один чи більше застосунків,
• Специфічну конфігурацію VM hardware,
• VMware Tools.

Для використання шаблонів треба бути підключеним до vCenter (не VMware Host Client!), а виглядають вкладки з інформацією про них отак:

Створення шаблонів робить надання ВМ набагато швидшим і менш схильним до помилок, аніж їх створення за допомогою помічника New Virtual Machine (розглянутого вище). Шаблони можна знайти там же, де і ВМ – в інвентарі. Можна організовувати колекції ВМ та шаблонів у довільних папках та застосовувати дозволи до них. ВМ можна конвертувати у шаблони без необхідності робити повну копію їх файлів і створення об’єкту. Розгортання ВМ за допомогою шаблону додає її до папки, яка була обрана під час його створення.

Створення нових шаблонів

Створювати шаблони можна різними способами: клонуванням ВМ у шаблон, конвертацією ВМ у шаблон, клонуванням існуючого шаблона тощо. Розглянемо їх усі, по черзі.

Клонування ВМ у шаблон

ВМ може бути увімкненою чи вимкненою, байдуже. Робиться це отак: встаємо на шукану машину в інвентарі, у Actions обираємо опцію Clone і далі Clone to Template:

При цьому нам запропонують обрати тип формату зберігання віртуальних дисків ВМ:

• Same format as source (такий самий, як у джерела),
• Thin-provisioned format,
• Thick-provisioned lazy-zeroed format,
• Thick-provisioned eager-zeroed format.

Конвертація ВМ у шаблон

У цьому випадку машину обов’язково треба вимкнути. Потрібно:

1. Обрати ВМ-джерело у інвентарі;
2. ПКМ по ній – Actions – обираємо Template, і далі – Convert to Template:

Формат диску змінити буде не можна. Конфігураційний файл «.vmx» заміниться на конфігураційний файл шаблону «.vmtx».

Клонування шаблону

Якщо в нас вже є шаблон, створити інший можна його клонуванням. Для цього стаємо на шаблон і в Actions обираємо Clone to Template:

Оновлення шаблонів

Щоб включити у шаблон нові патчі, додати чи видалити віртуальне апаратне забезпечення, оновити VMware Tools чи версію hardware, проінсталювати нові застосунки, нам не потрібно заново створювати шаблон, можна просто йти за алгоритмом:

1. Конвертувати шаблон у ВМ;
2. Помістити ВМ у ізольовану мережу для запобігання доступу користувача;
3. Зробити у машині потрібні зміни;
4. Сконвертувати ВМ знов у шаблон.

На першому кроці нам потрібно встати на шаблон в інвентарі та в Actions обрати Convert to Virtual Machine:

Далі усе, як описувалось у порадах вище для інших операцій.

Розгортання ВМ з шаблону

Щоб розгорнути ВМ з шаблону, нам потрібно (як і у випадку створення нової, з нуля) дати їй ім’я, вказати місцезнаходження інвентаря, хост, датастор та дані налаштування гостьової ОС. Якщо ми встанемо на потрібний шаблон і в Actions оберемо New VM from This Template, з’явиться помічник, дуже схожий на той, що ми вивчали на створенні нової машини, з притаманним пунктом Select clone options:

Важливо! Кастомізація гостьової ОС запобігає конфліктам, що можуть виникнути, коли розгортається ВМ та клон з ідентичними налаштуваннями гостьової ОС. Якщо цього не зробити, ВМ успадкує ім’я хоста, ІР-адресу й інше ВМ-джерела чи шаблону. У процесі кастомізації можна змінити:

• ім’я комп’ютеру,
• налаштування мережі,
• параметри ліцензії,
• часову зону,
• пароль адміністратора чи root,
• Windows Security Identifier.

Кастомізація гостьової ОС

Для підготовки гостьової ОС можна створити кастомізацію специфікації, що буде зберігатися у базі даних vCenter, й підтримувати як Windows, так і Linux. Проглядати існуючі специфікації та робити з ними операції можна у Policies and Profiles головного меню:

Кастомізація корисна, коли ми клонуємо ВМ чи розгортаємо її з шаблону, і обирається у цих процесах вона у власному пункті помічника розгортання з шаблону (Customize guest OS), якщо у попередньому пункті (Select clone options) поставили галочку в Customize the operation system:

Важливо! На гостьовій ОС, яку хочемо кастомізувати, мають бути встановлені VMware Tools, і вона повинна бути проінстальована на диску, прикріпленому до SCSI ноди 0:0 в конфігурації ВМ.

Щоб кожного разу, коли відбувається кастомізація гостьової ОС, не вводити імена комп’ютера та ІР-адреси для віртуальних NIC, можна створити користувацький застосунок (знадобиться Perl на vCenter Server) та налаштувати його за аналогією, як vCenter Server генерує імена та адреси. Це може бути довільний виконуваний двійковий файл чи скрипт, що відповідає ОС, в якій запущений vCenter Server. Після створення цього застосунку й реєстрації його в vCenter Server, кожного разу, коли будемо ініціювати кастомізацію гостьової ОС, vCenter Server буде його запускати. Рекомендації щодо написання цього застосунку  можна знайти в КБ, й зберегти його потрібно буде на системному локальному дискові vCenter Server. А далі:

1. Обираємо інстанс vCenter Server у інвентарі та проходимо на вкладку Configure;
2. Клікаємо на Settings – Advanced Settings;
3. Тиснемо на Edit Settings і вводимо дані нашого скрипта:

• • В текстовому полі Name вводимо guestcust.name-ip-generator.arg1
  • В текстовому полі Value вводимо c:\sample-generate-name-ip.pl та клікаємо Add
  • В текстовому полі Name вводимо guestcust.name-ip-generator.arg2
  • В текстовому полі Value вводимо c:\sample-generate-name-ip.pl – шлях до нашого файлу, та клікаємо Add
  • В текстовому полі Name вводимо guestcust.name-ip-generator.program
  • В текстовому полі Value вводимо c:\perl\bin\perl.exe та клікаємо Add

4. Клікаємо на Save.

Розпишемо покроково, як виглядає кастомізація при клонуванні чи розгортанні нової машини:

1. ПКМ на об’єкт інвентаря, що є валідним батьківським об’єктом для ВМ (дата-центр, кластер, vApp, ресурс-пул, хост) та обираємо New Virtual Machine;
2. На сторінці Select a creation page обираємо Clone an existing virtual machineчи Deploy from template. Next;
3. Йдемо звично помічником аж до пункту Select clone options, де ставимо галочку в Customize the operating system. Next;
4. На сторінці Customize guest OSобираємо одну з опцій: Select an existing specification (щоб обрати специфікацію кастомізації зі списку) чи Override (щоб змінити кастомізацію специфікації конкретно для цього розгортання – з’явиться помічник Override VM Customization Specification, йдемо ним й по завершенню клікаємо на ОК);
5. На сторінці User settings вказуємо параметри ВМ;
6. На сторінці Ready to complete переглядаємо налаштування й запускаємо клонування кнопкою Finish.

А щоб застосувати кастомізацію до вже існуючої ВМ, потрібно:

1. ПКМ на ВМ в інвентарі vSphere і обираємо Guest OS> Customize Guest OS – з’явиться діалогове вікно Customize Guest OS;
2. Обираємо специфікацію кастомізіції зі списку та клікаємо ОК.

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

Бібліотека контенту і шаблони

Content library (бібліотека контенту) – це репозиторій OVF-шаблонів та інших типів файлів, до яких реалізований спільний доступ та впроваджена синхронізація по всіх системах vCenter глобально. При цьому доступне розподілене керування файлами, ISO підмонтовувати можна прямо з бібліотеки контенту, а версії шаблонів ВМ підтримуються різні. Такі бібліотеки контенту можуть бути різних типів:

• Локальна – контент контролюється адміністратором;
• Опублікована – локальна бібліотека, що доступна за підпискою;
• За підпискою – бібліотека, що синхронізується з іншою опублікованою бібліотекою.

Остання не може бути опублікована, і користувачі у ній не можуть змінювати контент. А в локальній чи опублікованій адміністратори контент змінювати можуть.

Для бібліотек контенту в клієнті vSphere є спеціальний розділ у головному меню – Content Libraries, де можна створювати власні бібліотеки та керувати ними:

Створення нової бібліотеки контенту

Щоб створити нову бібліотеку, на сторінці Content Libraries правої робочої зони тиснемо на функціональний напис Create, після чого з’явиться помічник, пунктами його звично йдемо:

До речі, у другому його пункті доведеться зробити вибір, якого саме типу буде бібліотека (локальна, за підпискою тощо).

Нащо ми розмовляємо про бібліотеки контенту саме в темі про шаблони й про ВМ, загалом? Тому що таку бібліотеку можна заповнювати наступними типами файлів:

• шаблонами ВМ (зберігатися можуть на будь-якого типу датасторі, за виключенням NFS, у дефолтному дисковому форматі, асоційовані з хостом та видимі у інвентарі vCenter),
• OVF-шаблонами (мають зберігатися у будь-якому типові датастора, асоційованому з бібліотекою контенту, лише у форматі thin-provisioned, не є асоційованими з хостом та не з’являються у інвентарі vCenter).

Додавання шаблону ВМ чи OVF до бібліотеки контенту.

Пам’ятаєте, вище ми вчилися клонувати ВМ, зокрема у шаблон? Так от, під пунктом Clone to Template є пункт Clone to Template to Library, якщо натиснути на який, зможемо у відповідному помічникові обрати, чи хочемо створити шаблон ВМ, чи OVF-шаблон:

Це щодо шаблонів ВМ. Якщо ж хочемо додати OVF-шаблон до бібліотеки контенту, можемо склонувати шаблон з інвентаря vCenter у шаблон в бібліотеці контенту – для цього, аналогічно, у Actions під Clone to Template (ми вище з таким варіантом вже працювали) обираємо Clone to Library:

Перегляд об’єктів бібліотеки контенту та підмонтування ISO

Панель бібліотеки контенту (вкладка Templates) виглядає таким чином:

Контент тут поділений на категорії:

• шаблони:
  • шаблони ВМ,
  • OVF-шаблони,
• інші типи (наприклад, ISO-образи).

І перемикатися між ними можна відповідними вкладками, нижче головного верхнього меню вкладок.

Вище ми натякали, що ISO-файлами можна користуватися безпосередньо з бібліотеки контенту, а саме підмонтовувати їх, що, погодьтеся, дуже й дуже цікаво. Для цього нам лише потрібно підключити CD/DVD до ISO-файлу у бібліотеці.

Важливо! ISO-файли доступні тільки для машин, що зареєстровані на ESXi-хості, який має доступ до датастору, де розташована бібліотека контенту.

Розгортання ВМ з бібліотеки контенту

У розгортанні машини з шаблону нам знову допоможе помічник New Virtual Machine, який викликаємо однойменним пунктом у Actions. У першому його пункті обираємо Deploy from template, а у другому, перемикаючись між верхніми вкладками, Content Library та Data Center, зможемо або побачити список OVF-шаблонів, або шаблонів ВМ, відповідно:

Публікація бібліотеки контенту

Щоб до нашої бібліотеки забезпечити доступ користувачам, можемо її опублікувати, шляхом редагування її налаштувань. Для цього стаємо на потрібну бібліотеку в панелі Content Libraries та по Actions викликаємо пункт Edit Settings:

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

Тепер цю бібліотеку можна побачити у табличці панелі Content Libraries, де буде відображатися її тип, та відмітка про те, чи вона опублікована:

Підписка бібліотеки на іншу опубліковану та синхронізація контенту

У підрозділі вище ми отримали URL для доступу до опублікованої бібліотеки. Щоб наша підписувана бібліотека його мала, потрібно у помічникові її створення обрати прапорцем другий блок Subscribed content library і у пункті Subscription URL вставити шукане посилання:

Нижче можна увімкнути автентифікацію, за потреби, та обрати, яким чином буде завантажуватися контент – або одразу (immediately) отримати увесь контент на вашу локацію зберігання, або завантажити тільки метадані для об’єктів, поки вони використовуються (when needed). Другий варіант зекономить місце.

У панелі OVF & OVA Templates (вкладка другого ряду) по бібліотеці з підпискою виводить списком наші OVF-шаблони. Періодично ці дані, звичайно, застарівають, і щоб оновити цей список можемо обрати у ACTIONS дію Synchronize.

Важливо! Під синхронізацію підпадають лише OVF-шаблони. Ті шаблони, що мають міститися на вкладці VM Templates, можуть оновитися тільки у такому випадку: спочатку створюємо та публікуємо підписку в опублікованій бібліотеці – щоб підштовхнути шаблони ВМ до бібліотеки з підпискою.

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

Щоб опублікувати шаблони ВМ, потрібно створити підписку:

1. З панелі опублікованої бібліотеки обираємо вверху в ACTIONS пункт New Subscription;
2. У помічникові Create Subscription, що з’явився, у першому кроці Select subscription type ставимо прапорець у Create a new subscription to an existing Subscriber library:
3. Проходимо далі помічник до кінця аж до успішного створення нової підписки;
4. Коли підписка з’явиться у списку, обираємо її та клікаємо на PUBLISH.

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

Для більш гранульованого налаштування зберігання контенту бібліотекою, процесів її синхронізації, тощо, можна скористатися кнопкою Advanced на панелі бібліотек контенту (справа від Create, яку ми бачили, коли вчилися створювати нову бібліотеку вище), що відкриє віконце Advanced Configuration:

Керування шаблонами в бібліотеці контенту

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

Керування версійністю шаблонів, загалом, виглядає так:

1. Вилучаємо ВМ з шаблону;
2. Вносимо до неї зміни;
3. Вносимо ВМ у шаблон.

Щоб вилучити ВМ з шаблону, користуємося вкладкою Versioning по шуканому шаблону, де тиснемо кнопку CHECK OUT VM FROM THIS TEMPLATE, з’явиться невеличкий помічник:

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

Далі вносимо потрібні зміни до ВМ, наприклад, реконфігуруємо її апаратне забезпечення чи робимо щось з софтом, й при цьому шаблон продовжує бути доступним для розгортань. Використовується технологія linked clone, щоб склонувати шаблон при виконанні вилучення. На цьому клоні ми й міняємо те, що хочемо, і коли завершимо, він знову об’єднається з шаблоном ВМ, склонована ВМ знищиться, а шаблон ВМ оновиться. Проте, якщо зміни зберігати не хочемо, або задля уникання створення нових версій, можемо скасувати вилучену ВМ, натиснувши «три крапочки» коло вилученої ВМ та клікнув на Discard Checked Out VM:

А якщо хочемо зберегти зміни й оновити шаблон, клікаємо на кнопку CHECK IN VM TO TEMPLATE – з’явиться віконце, що покаже деталі змін, яке підтверджуємо кнопкою CHECK IN. В результаті створиться нова версія шаблону з оновленим станом ВМ.

Різні варіанти шаблону ВМ у своєрідному хронологічному дереві із зазначенням автора та часу внесення змін показуються на вкладці Versioning – див. попередній скріншот. І користуючись «трьома крапочками» по кожній версії можна або видалити її, або повернутися до неї:

Міграція vSphere vMotion та vSphere Storage vMotion

Міграція – переміщення ВМ з хоста, датастора чи інстанса vCenter на інший хост, датастор чи інстанс vCenter.

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

Міграція буває декількох типів, залежно від статусу живлення ВМ, і обираємо ми конкретний у помічникові Migrate, викликати який можна у Actions – Migrate:

• Change сompute resource only. Переміщаємо ВМ, але не її сховище на інший хост (для гарячої міграції користуємося vSphere vMotion),
• Change storage only. Переміщаємо файли чи об’єкти ВМ на інший датастор (для гарячої міграції користуємося vSphere Storage vMotion),
• Change both compute resource and storage. Переміщаємо ВМ на інший хост та датастор (для гарячої міграції користуємося vSphere vMotion і vSphere Storage vMotion),
• Cross vCenter Server export. Переміщаємо ВМ на хост та датастор, що керуються іншим інстансом vCenter, що не пов’язаний з поточним SSO-доменом.

vSphere vMotion – Функція, яка підтримує міграцію увімкнених віртуальних машин з хоста на хост без перерви в роботі служби. Але вона, на відміну від холодної міграції, оголошує деякі вимоги до апаратного забезпечення. Серед позитивних властивостей vSphere vMotion треба відзначити покращення, в цілому, використання апаратного забезпечення, можливість уникнути перерв в оперуванні ВМ під час простоїв хоста за розкладом, а vSphere DRS допоможе збалансувати ВМ поміж хостами.

Найважливіше в налаштуванні vSphere vMotion – конфігурування відповідним чином мереж в сенсі налаштувань адаптерів VMkernel на хості-джерелі та цілі:

Міграція vSphere vMotion проходить крізь наступні етапи:

1. Створюється тіньова ВМ на хості призначення;
2. Стан пам’яті ВМ копіюється по мережі vSphere vMotion з хоста-джерела на цільовий хост. Але при цьому користувач, потенційно, може мати доступ до ВМ та оновлювати сторінки в пам’яті. Список змодифікованих сторінок зберігається в бітовому зображенні пам’яті (bitmap) на хості-джерелі;
3. Після завершення першої стадії копіювання стану пам’яті, починається друга, під час якої копіюються будь-які сторінки, що зазнали змін протягом останньої ітерації. Подібне ітераційне копіювання відбувається доти, доки кількість змінених сторінок не дозволить здійснювати копіювання решти за 500мс;
4. ВМ занурюється в стан спокою й жодної активності щодо себе не сприймає. При цьому vSphere vMotion переносить стан пристроїв та bitmap пам’яті на хост призначення. Одразу при вході в стан спокою на хості-джерелі, ВМ запускається на цільовому хості, а її файли розблоковуються на хості-джерелі та заблоковуються на хості-цілі;
5. Користувачі продовжують користуватися ВМ на цільовому хості замість хоста-джерела;
6. Сторінки пам’яті, що використовувалися ВМ на хості-джерелі помічаються як вивільнені.

Вимоги до ВМ для vSphere vMotion Migration:

• Якщо ВМ користується RDM-диском, RDM-файл та LUN, з якими вона співставляється, мають бути доступними на хості призначення;
• Не повинно бути підключення до віртуального пристрою, на кшталт CD/DVD чи флоппі, з підмонтованими локально для хоста образами. Але з прикріпленими фізичними дисками чи образом диску можна.

Вимоги до хоста (й джерела, й цілі) для vSphere vMotion Migration:

• Доступ до всіх сховищ ВМ (на один датастор максимально можливі 128 паралельних міграцій);

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

• Активовано порт VMkernel з vSphere vMotion;
• Відповідність сім’ї ІР-адрес management-мережі (IPv4/IPv6) між хостами джерелом та ціллю;
• Кількість паралельних активних задач vSphere vMotion є функцією швидкості мережі vSphere vMotion (кожен активний процес вимагає, мінімум, пропускної здатності в 250 Мбіт/с; одночасно мігрувати в гігабітній мережі можна лише чотири ВМ, а в 10 Гбіт/с або швидшій – 8);

Зауваження. Для зростання продуктивності виділіть принаймні дві порт-групи VMkernel для трафіку vSphere vMotion.

• Сумісність CPU (мережі функцій CPU на хості-джерелі та цілі мають бути сумісними).

Зауваження. Деякі функції CPU можна приховати за допомогою Enhanced vMotion Compatibility чи масок сумісності.

Запуск міграції vSphere vMotion

На передостанньому скріншоті було показано, як запустити помічник Migrate та обрати потрібний тип міграції. Далі:

1. Select a compute resource. Обираємо хост чи кластер, й запуститься перевірка, чи задовольняє він вимогам (див. вище):

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

2. Select networks. Налаштовуємо мережу згідно рекомендацій, даних вище;
3. Select vMotion priority.
4. Ready to complete. Перевіряємо усі вводи, і як все гаразд, запускаємо міграцію відповідною кнопкою.

Міграція зашифрованих ВМ

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

Зауваження. Encrypted vSphere Storage vMotion не підтримується.

Міграція зашифрованих ВМ автоматично вдається до використання зашифрованого vSphere vMotion. Побачити, налаштування шифрування vMotion можна в налаштуваннях ВМ, вкладка VM Options: якщо зайти в Edit Settings блок Encryption, у полі Encrypted vMotion буде розкривне меню, де обирається одне з:

• Disabled (вимкнено),
• Opportunistic (за замовчуванням, Encrypted vSphere vMotion використовується, якщо хости джерела й призначення його підтримують),
• Required (вимагається Encrypted vSphere vMotion, але якщо хост-джерело чи ціль його не підтримують, міграція сфейлиться):

Конфігурування Enhanced vMotion Compatibility

Enhanced vMotion Compatibility – це кластерна функція, що дозволяє міграції vSphere vMotion між хостами з неідентичними наборами функцій. Вона використовує базові параметри CPU для налаштування всіх процесорів в кластері, які активовано для Enhanced vMotion Compatibility:

Навіть якщо в нас різні покоління CPU, з EVC міграція буде успішною. Але, хости, що не можуть бути налаштовані відповідно до цієї бази, до такого кластеру приєднатися не зможуть.

Вимоги до хостів з кластеру EVC щодо CPU:

• Одновендорність всіх CPU (Intel/AMD);
• Активація для віртуалізації апаратного забезпечення (AMD-V/Intel VT);
• Активація для технолгії вимкнення виконання (AMD No eXecute (NX)/Intel eXecute Disable (XD));
• Налаштування міграції vSphere vMotion.

Зауваження. Застосунки в ВМ мають бути сумісними за CPU ID.

Режим EVC на існуючому кластері можна налаштувати так:

1. Стаємо на шуканий кластер в інвентарі;
2. На вкладці Configure обираємо в лівому бічному меню робочої панелі VMware EVC – побачимо, що воно поки вимкнене, – тиснемо на кнопку EDIT в правому верхньому кутку;
3. Відкриється вікно Change EVC Mode, де треба поставити зверху прапорець на Enable EVC for <марка процесора> Hosts:

Важливо! Перед налаштуванням EVC на існуючому вже кластері, усі його хости треба занурити в режим техобслуговування, а їх ВМ мають бути вимкнені або переведені в статус suspend. Щоб не було при цьому простоїв у роботі, рекомендується замислитися над потребою в EVC ще в момент створення нового, порожнього кластеру.

EVC може працювати більш гранульовано – по кожній ВМ чи їх сукупності(ям). Мається на увазі, що ми можемо його застосувати до деяких, чи усіх машин в кластері. На рівні ВМ EVC полегшує їх міграцію за межі кластеру та між системами vCenter й дата-центрами. Режим VM EVC, що цікаво, незалежний від режиму EVC, що визначений на рівні кластера. Він стає атрибутом ВМ, а не конкретного покоління процесорів, на якому вона завантажується в кластері. Функція гарантує плавну міграцію між двома дата-центрами з різними процесорами. Ба більше, вона зберігається для кожної ВМ та губить режим EVC під час міграції між кластерами чи протягом циклів живлення. Ось ця схема ілюструє, як EVC може бути не налаштований на кластері, проте він працює для деяких ВМ:

Що цікаво, EVC також може визначати загальну базу наборів функцій GPU в кластері (ті функції, що не входять до бази, маскуються та не доступні для ВМ). Enhanced vMotion Compatibility для vSGA підтримується апаратними графічними процесорами, а також програмними рендерами GPU. EVC для vSGA GPU налаштовується на рівні кластеру ESXi. Вимоги до кластеру EVC для режиму графіки:

• Усі хости ESXi мають задовольняти вимогам GPU визначеної бази;
• Додаткові хости не можуть приєднатися до кластеру, якщо вони не задовольняють базовим вимогам.

Зауваження. Кластер з суміші ESXi 6.7 і ESXi 7.0 хостів підтримується при використанні Enhanced vMotion Compatibility на рівні кластера.

Також EVC для vSGA GPU можна налаштувати на рівні віртуальної машини. При цьому вимагається:

• Сумісність ВМ для ESXi0U1 (версія hardware 18+);
• ВМ, що використовують GPU Enhanced vMotion Compatibility на рівні ВМ, мають запускатися на ESXi0U1.

Налаштовується EVC Graphics Mode на існуючому кластері отут:

А на рівні ВМ отут:

Міграція ВМ з vSphere Storage vMotion

vSphere Storage vMotion – інструмент для міграції увімкнених ВМ з одного датастору на інший, незалежно від його типу. Це дуже зручно, коли треба перемістити машини з масивів для техобслуговування чи оновлення, змінити тип надання диску, змінити файли ВМ на датасторі призначення для відповідності імені інвентаря ВМ, збалансувати трафік поміж шляхами сховища та зменшити затримки, перерозподілити ВМ чи віртуальні диски на інші томи сховища задля балансування ємності чи покращення продуктивності.

Міграція vSphere Storage vMotion проходить крізь наступні етапи:

1. Запускаємо міграцію сховища;
2. Використовуємо засіб переміщення даних VMkernel чи vSphere Storage API – Array Integration для копіювання даних;
3. Запускаємо процес нової ВМ;
4. Віддзеркалюємо виклики I/O до блоків файлів, які вже скопійовано на віртуальний диск цільового сховища даних;
5. Переходимо до процесу цільової ВМ, щоб отримати доступ до копії віртуального диску.

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

Перед тим, як перейти до практики міграції сховищ, зробимо одне зауваження щодо vSphere Storage API – Array Integration. Дуже важливо в процесі ідентифікувати масиви сховища, що підтримують такі API, адже саме це є шляхом до прискорення апаратного забезпечення при міграції сховища, і для успіху потрібна їх підтримка масивом, а також розміщення обох датасторів на одному масиві сховища. Дізнатися, чи підтримують масиви сховища апаратне прискорення, можна через клієнт vSphere:

Важливо! Для запуску vSphere Storage vMotion потрібно, щоб незалежні віртуальні диски машини були в persistent mode. Рекомендується проводити міграції сховища у непікові години.

Власне, процедуру запуску самої міграції описувати немає сенсу, адже вона повністю ідентична тому, що ми робили вище конкретно для vSphere vMotion, з тією лиш різницею, що на самому початку, коли у помічникові обираємо тип міграції, потрібно поставити прапорець у Change storage only.

Міграції між vCenter

vSphere vMotion допомагає мігрувати ВМ між інстансами vCenter, незалежно від того, чи є вони в одній групі Enhanced Linked Mode (за цей режим та його активацію докладно говорили в підрозділі «Приєднання до домену vCenter в Enhanced Linked Mode» статті «Інсталяція vSphere 8.0 з нуля»). Крос-vCenter міграції допомагають, коли треба:

• Збалансувати робочі навантаження по всім кластерам та інстансам vCenter, що містяться в одному сайті, чи в іншій географічній локації;
• Перемістити ВМ між середовищами з різними цілями, наприклад, з середовища розробки на середовище продуктиву;
• Перемістити ВМ для досягання інших рівнів угод по сервісу (SLA) для простору сховища, продуктивності тощо;
• Перемістити ВМ з on-premises дата-центру vSphere в іншу публічну хмару, таку як VMware Cloud on AWS.

Вимоги до міграції поміж vCenter:

• Хости мають бути засинхронізовані за часом;
• Обидва інстанси vCenter мають бути в одному чи різних доменах vCenter Single Sign-On;
• Для міграції тільки обчислювальних ресурсів обидва інстанси vCenter мають бути підключені до спільного сховища, на якому розташована ВМ:

Зауваження. Можлива міграція між інстансами vCenter різних версій. Підтримувані версії можна знайти в цьому КБ.

Міграція між vCenter в одному SSO-домені

Якщо виконуємо крос-vCenter vMotion в одному SSO-домені, її процес починається так само, як ми розглядали вище для обчислювальних ресурсів та сховища – тільки в першому пункті помічника Migrate – Select a migration type – ставимо прапорець в Changе Both Compute Resource and Storage, а далі в Select a compute resource обираємо обчислювальні ресурси на інстансі vCenter призначення:

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

Міграція між vCenter в різних доменах SSO

У нашому помічникові Migrate на першому пункті Select a migration type обираємо Cross vCenter Server export:

Далі у Select a source vCenter Server потрібно буде вказати FQDN або IP-адресу цільового інстансу vCenter та дані облікового запису до нього:

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

Long-Distance vSphere vMotion Migration

Міграція Long-Distance vSphere vMotion є розширенням крос-vCenter міграції й вона корисна, коли інстанси vCenter сильно рознесені географічно та існує досить значна затримка між сайтами. Use cases:

• Перманентні міграції;
• Уникнення катастрофи;
• Тестування Site Recovery Manager та уникнення катастрофи;
• Балансування навантажень поміж сайтами;
• Підтримка сценарію «Follow-the-sun» (Коли одна команда підтримки закінчує робочий день, а інша у відмінній часовій зоні його починає, зручніше перемістити ВМ так, щоб друга команда могла з ними працювати у своїх географічній локації. Інший варіант: іноді вартість, наприклад, електроенергії навіть в рамцях однієї країни має нічний та денний тарифи, що суттєво відрізняються, й тоді вигідно ганяти машини з нічного тарифу на одному кінці країни/світу на такий самий в іншому).

Вимоги та підготовка до Long-Distance vSphere vMotion полягають у наступному:

• Забезпечення у мережі ВМ L2-підключення, доступності тієї ж ІР-адреси ВМ у пункті призначення;
• Забезпечення у мережі vSphere vMotion L3-підключення, 250Мбіт/с на кожну операцію міграції, часу передачі між хостами не більшого за 150мс.

Робота зі снепшотами

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

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

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

Взяти снепшот можна з увімкненої, вимкненої чи переведеної в статус suspend машини. Він захопить наступні об’єкти:

• конфігурацію ВМ,
• стан пам’яті ВМ (опціонально, тільки при увімкненій машині, якщо поставити галочку в Include virtual machine memory, обрана за замовчуванням – див. скріншот нижче),
• віртуальні диски (без Independent віртуальних дисків, persistent чи nonpersistent):

Для того, щоб взяти снепшот, треба по шуканій ВМ в Actions обрати пункт Snapshots – Take Snapshot.

При взятті снепшотів можна призупинити гостьову ОС, шляхом призупинки файлової системи, але тільки, якщо не захоплюємо стан пам’яті.

Коли ми беремо снепшот, створюється дельта чи дочірній диск, і це буде sparse-диск на датасторі. Дельта-диски використовують різні спарс-формати, в залежності від типу датастора:

Тип снепшота	Тип датастора	Ім’я файлу	Розмір блоку
VMFSsparse	VMFS5 з віртуальними дисками, меншими за 2ТБ	#-delta.vmdk	512 байт
SEsparse	•       VMFS6 •       VMFS5 з віртуальними дисками, більшими за  2ТБ •       З ефективністю простора (thin provisioned) •       Підтримуючі вивільнення диску (unmap)	#-sesparse.vmdk	4КБ
vsanSparse	vSAN	Дельта-об’єкт	4МБ

Снепшот складається з набору файлів:

• -Snapshot#.vmsn – стан конфігурації,
• -Snapshot#.vmem – стан пам’яті (опціонально),
• -00000#.vmdk – опис диску,
• -00000#-delta.vmdk – VMFS5 дельта,
• -00000#-sesparse.vmdk – VMFS6 дельта,
• .vmsd – зберігає імена, описи та взаємозв’язки для всіх снепшотів ВМ:

Керування снепшотами

У клієнті vSphere для обраної ВМ ми можемо проглядати снепшоти та робити з ними різні операції: редагувати (кнопка Edit, міняти ім’я та опис), видаляти (один (DELETE) чи усі (DELETE ALL), якщо один, то при видаленні певного, файли снепшота консолідуються до батьківського диску снепшота та об’єднуються з базовим диском ВМ) та повертатися до нього (коли повертаємось до снепшота (Revert), він стає поточним, і всі об’єкти повернуться до стану, що був актуальним на момент його взяття):

Відповідні кнопки знайдемо вище дерева снепшотів.

Консолідація снепшотів – це метод підключення ланцюжка дельта-дисків до базових дисків, коли Snapshot Manager показує, що знімків немає, але файли дельта-диска лишаються в сховищі даних. Вона бореться з ситуаціями, коли файл дескриптора зафіксований правильно, а вікно Snapshot показує, що всі снепшоти видалені, коли файли снепшота (-delta.vmdk чи -sesparse.vmdk) все ще існують у папці ВМ на датасторі, коли файли снепшотів продовжують розширюватися, доки вони не досягнуть розміру файлу -flat.vmdk, чи поки в датасторі не вичерпається місце. Консолідація снепшотів – то є шлях до очищення сховища даних від непотрібних дельта-дисків.

Як ми дізнаємось, коли потрібна консолідація дисків? Якщо встати на потрібну машину та пройти на вкладку Monitor у правій робочій частині інтерфейсу, у її меню під Issues and Alarms буде пункт All Issues – там будуть зібрані усі сповіщення про попередження щодо необхідності консолідації:

Сама ж операція викликається дуже просто: стоячи на шуканій ВМ в Actions обираємо пункт Snapshots і далі – Consolidate:

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

Більше дізнатися про усі best practice щодо керування снепшотами у середовищі vSphere можна у цьому КБ).

Бекапування та відновлення ВМ

У бекапуванні ВМ можна використовувати vSphere Storage APIs – Data Protection – спеціальний фреймворк, що створює резервну копію з центральної системи бекапування (фізичної чи віртуальної). Він не вимагає агентів бекапування або будь-яких процесів, що мають виконуватися усередині гостьової ОС, усе відбувається централізовано, ефективно, незалежно від хоста та LAN:

Зауваження. Обробка резервного копіювання розвантажується з хоста ESXi. На додачу можливості снепшотів vSphere використовуються для підтримки бекапів в мережі SAN без простою ВМ. Завдяки цьому до нього можна вдаватися у будь-який час доби, не потребуючи розширених вікон резервного копіювання.

Зауваження. Бекапування ВМ може додати затримки сховищу даних. За допомогою клієнта vSphere можна внести у розклад задачу деактивації поведінки vSphere Storage DRS протягом резервного копіювання:

Робота з кластерами vSphere

Кластер у vSphere використовується для спільного користування фізичних ресурсів групою ESXi-хостів. vCenter керує ресурсами кластеру як єдиним пулом ресурсів. Можна створювати один чи більше кластерів, спираючись на мету їх заповнення, наприклад, окремі кластери для керування, продакшена чи обчислень. В одному кластері може бути до 96 ESXi-хостів і в інвентарі клієнта vSphere вони виглядають, приблизно, отак:

Створення vSphere-кластера

Створення кластера на практиці виглядає як найменування його та включення бажаних служб. Робиться це з клієнта vSphere, де стоячи на потрібному дата-центрі, обираємо дію по ньому в Actions – New Cluster – з’явиться невеличкий помічник, у першому пункті якого якраз і обираємо ім’я для нового кластера, сервіси та робимо інші потрібні налаштування, на кшталт, вказівки (ставимо галочки у відповідних полях), чи повинні усі хости в ньому керуватися єдиним образом (прапорці в чи створити новий образ, імпортувати з існуючого хоста в інвентарі vCenter, чи імпортувати образ з нового хоста), чи керувати конфігурацією на рівні кластера:

Зауваження. Якщо поставити галочку в Manage all hosts in the cluster with a single image, vSphere Lifecycle Manager зможе оновлювати усі хости кластера разом, використовуючи вказаний образ ESXi. Про це чудово розписали у розділі «Оновлення ESXi-хостів з vSphere Lifecycle Manager» статті «Оновлення VMware vSphere до версії 8.0».

Служби, які можна активувати на кластері vSphere:

• vSphere HA для високодоступності,
• vSphere DRS для розміщення ВМ та балансування навантаження,
• vSAN.

vSphere HA – функція кластера, яка захищає від збоїв апаратного забезпечення хоста шляхом перезапуску віртуальних машин на хостах, які працюють нормально.

vSphere DRS – функція кластера, яка використовує vSphere vMotion для розміщення віртуальних машин на хостах і гарантує, що кожна ВМ отримує необхідні їй ресурси.

Далі про обидва сервіси поговоримо детально у окремих персональних підрозділах.

Після початкової ініціації кластера можна за допомогою Cluster Quickstart налаштувати його. Для цього, стоячи на нашому новоствореному кластері в інвентарі, у правій робочій частині проходимо на вкладку Configure і в бічному меню під Configuration шукаємо пункт Quickstart:

Можливості Cluster Quickstart:

• Налаштування служб (vSphere HA, vSphere DRS, vSAN);
• Перевірка сумісності апаратного та програмного забезпечення;
• Розгортання vSphere Distributed Switch;
• Налаштування мережевих параметрів для vSphere vMotion і vSAN;
• Створення розтягнутого кластера vSAN чи доменів збою vSAN;
• Досягнення впевненості, що NTP-конфігурація постійна по всьому кластерові.

Цей вбудований помічник не тільки налаштовує початкову конфігурацію кластера, а й може додавати хости до нього як частину майбутнього розширення. У першому його етапі (Cluster basics) перевіряємо, чи правильно обрали служби кластеру (можна увімкнути чи вимкнути), а також можемо відредагувати, за необхідності, ім’я та обрати образ для керування хостами через vSphere Lifecycle Manager:

На другому етапі (Add hosts) додаємо нові чи існуючи хости до кластеру:

Як показано на скріншоті, після натиснення на кнопку ADD з’являється помічник, у якому зверху є дві глобальні вкладки: New hosts та Existing hosts. Після вибору потрібної, або вводимо новий хост (якщо декілька – послідовно), або обираємо з таблички доступних галочками ті, що цікавлять. Після додання хостів робочий процес помічника продемонструє, скільки хостів наразі присутні у кластері та проведе валідацію їх працездатності.

На третьому етапі після натискання кнопки CONFIGURE можемо налаштовувати мережу та кастомізувати служби кластеру під себе:

Зауваження. Якщо у процесі (чи одразу) натиснули кнопку SKIP QUICKSTART зверху справа, нічого страшного – можемо повернутися до редагування кластеру прямо з меню клієнта vSphere. Проте, пам’ятайте, що Cluster Quickstart доступний для кожного кластеру лише одного разу.

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

мережу для vSphere vMotion (якщо в нас ІР-інформація щодо усіх хостів однакова, можемо вписати лише для першого та натиснути на AUTOFILL збоку):

та мінімум один фізичний адаптер. Далі у цьому помічникові будуть Advanced Options, у яких можна більш гранульовано налаштувати служби кластеру НА та Distributed Resource Scheduler Enhanced vMotion Compatibility і параметри хоста (наприклад, ввімкнути чи вимкнути режим локдауну, задати NTP-сервер тощо):

Керування кластером vSphere

Коли наш кластер буде створений та початково налаштований, інформацію по ньому, включно з його споживачами та ресурсами, зможемо побачити на вкладці Summary:

Вкладка Monitor покаже дані по виділенню пам’яті, накладним її витратам, ємності сховища, ємності, зарезервованої ВМ, та тої, що лишається доступною, і CPU (перемикаємось бічним меню робочої частини під Resource Allocation):

На вкладці VMs показуються до трьох ВМ vSphere Cluster Service по кожному кластеру (зверху вкладка Virtual Machines). Вони розгортаються під час створення кластера та після додавання у нього хостів, і потрібні для підтримання служб кластеру у працездатному та доступному стані:

Така ВМ розгортається з OVA з мінімальним встановленим профілем Photon OS. vSphere Cluster Services Manager – це служба vCenter, що керує ресурсами, станом живлення та доступністю цих машин.

Важливо! Будь-який вплив на стан живлення або ресурси ВМ vSphere Cluster Services може погіршити працездатність служби та призвести до припинення роботи vSphere DRS.

Важливо! У клієнті vSphere ВМ vSphere Cluster Services не відображаються в інвентарі Hosts and Clusters. Вони доступні лише на вкладці VMs кластеру.

Кластер vSphere показує попередження, якщо працездатні ВМ vSphere Cluster Service недоступні у кластері. Якщо їх вручну вимкнути, вони автоматично ввімкнуться vCenter.

vSphere Distributed Resource Scheduler

vSphere Distributed Resource Scheduler (DRS) допомагає покращити виділення ресурсів по усім хостам в кластері, об’єднуючи обчислювальні потужності набору серверів у логічні пули ресурсів, й використовується для початкового розміщення, коли ВМ увімкнені, балансування навантаження та міграції ВМ при зануренні ESXi-хостів у режим техобслуговування.

Якщо vSphere DRS у повністю автоматичному режимі (Fully Automated), він поміщає ВМ на хост з найбільшою кількістю доступних ресурсів, а якщо у частково автоматичному чи ручному режимі (Partially Automated чи Manual) – робить рекомендації щодо виділення ресурсів, при ввімкненні ВМ у кластері. Тандем vSphere DRS та vSphere vMotion – просто чудовий, адже дві ці технології, працюючи разом над автоматичними міграціями ВМ, максимально оптимізують використання ресурсів у кластері.

Побачити, наскільки добре ВМ дотримуються вимог до ресурсів, можна у лічильнику DRS (це на вкладці Summary), і його оцінки тлумачаться наступним чином:

• Якщо оцінка близька 0% – боротьба за ресурси йде неабияка;
• Якщо оцінка близька 100% – конкуренція помірна або відсутня, взагалі:

Лічильник DRS враховує показники CPU кожної машини, пам’яті та мережеві метрики, і виконується щохвилини. Він є останнім результатом запущеного DRS і заноситься за період вибірки до однієї з п’яти доріжок, які уявляють собою 20%-діапазони (див. скріншот вище).

Нижче у картці лічильника є функціональний напис VIEW DRS SETTINGS, натиснувши на який побачимо поточний рівень автоматизації та поріг міграції для кластеру:

Про ці параметри поговоримо нижче докладно.

Іще лічильнику DRS виділена окрема сторінка на вкладці Monitor, де в бічному меню під vSphere DRS шукаємо пункт VM DRS Score. Окрім самої оцінки, там показані активні CPU та ті, що використовуються, а також у стані готовності, надана пам’ять, своп та балунінг:

Для демонстрації подробиць утилізації нижче в бічному меню є пункти CPU Utilization, Memory Utilization і Network Utilization, що наводять діаграми використання відповідних ресурсів:

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

Вимоги до кластеру vSphere DRS

Щоб хости можна було додати до кластеру DRS, вони мають задовольняти певним вимогам. По-перше, усі керовані хости повинні користуватися спільним сховищем даних. По-друге, щоб запрацювало балансування навантаження, усі хости кластеру мають бути частиною мережі vSphere vMotion. І взагалі, усі вимоги, що ми наводили вище до vSphere vMotion, якнайкраще стосуються й vSphere DRS – максимальна продуктивність і повноцінність функціоналу при цьому будуть гарантованими.

Рівень автоматизації vSphere DRS

Рівень автоматизації vSphere DRS каже, чи будуть ВМ розміщені на хостах автоматично, чи технологія лише дасть рекомендації щодо цього. Власне, ці рівні (коли ВМ вмикається):

• Manual – vSphere DRS покаже список рекомендованих хостів, куди краще помістити машинки. Це потрібно буде зробити вручну,
• Partially automated – vSphere DRS розміщає ВМ на хості, що найкраще пасує, і для росту свого лічильника, покаже рекомендації щодо ручної міграції ВМ,
• Fully automated – vSphere DRS поміщає ВМ на найліпшому хості, і далі буде автоматично її мігрувати між хостами задля покращення лічильника:

Задати рівень автоматизації можна, якщо пройти на вкладку Configure шуканого кластеру, і в лівому меню робочої зони під Services обрати пункт vSphere DRS і справа зверху натиснути на крайню кнопку EDIT, як показано на скріншоті. Перша вкладка вікна, що відкриється (Automation) прямо спочатку запропонує розкривне меню, де будуть всі типи рівнів.

Рівень автоматизації можна задати й по конкретній ВМ у кластері, щоб взяти пріоритет над налаштуваннями кластеру загалом. Це корисно для критичних машин. Типи рівнів автоматизації тут такі самі, звісно ж, а налаштовуються вони на вкладці Configure, де в бічному меню робочої частини під Configuration обираємо VM Overrides, тиснемо функціональний напис уверху зліва ADD – відкриється маленький помічник, у другому пункті якого, Add a VM Override, найперший блок саме і призначений вибору автоматизації DRS (або вимикаємо взагалі, або обираємо потрібний рівень):

Налаштування vSphere DRS

Окрім рівня автоматизації, про який тільки-но говорили, на тій самій вкладці вікна редагування параметрів нашого vSphere DRS нижче є пункт Migration Threshold. Він визначає, наскільки агресивно vSphere DRS обирає ВМ для міграції:

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

1. Консервативний. Застосовує тільки рекомендації першого пріоритету. vCenter застосовує лише рекомендації, які необхідно виконувати, щоб задовольнити вимоги ВМ, як-от правила affinity та техобслуговування хоста;
2. Застосовує лише рекомендації 1 та 2 пріоритету. vCenter застосовує рекомендації, що обіцяють значне покращення лічильника DRS;
3. За замовчуванням. Застосовуються рекомендації 1, 2 і 3 пріоритетів. vCenter застосовує рекомендації, що обіцяють добре покращення лічильника DRS;
4. Застосовує рекомендації 1, 2, 3 і 4 пріоритету. vCenter застосовує рекомендації, що обіцяють помірне покращення лічильника DRS;
5. Агресивний. Усі рекомендації застосовуються, навіть ті, що ведуть лише до незначного покращення лічильника.

Нижче порога міграції маємо галочку для, так званого, Predictive DRS:

Прогностична DRS використовується для передбачення майбутніх вимог та визначення, коли й де станеться підвищення утилізації ресурсів. Задля цього колектор даних vSphere DRS збирає статистику використання ресурсів з ESXi-хостів та прогнозовану статистику використання з серверу VMware Aria Operations (якщо використовується). Для чого це потрібно? Щоб завчасно перемістити ВМ до того, як їх лічильник DRS впаде, та до того, як почнеться конкуренція за ресурси хоста.

Налаштування параметрів виконання vSphere Storage DRS

Якщо налаштувати поріг vSphere Storage DRS, можна визначити, коли мають виконуватися чи рекомендуватися міграції. Для цього при створенні кластеру датастора, у третьому пункті помічника Storage DRS Runtime Settings ставимо галочку в Enable I/O metric for SDRS recommendations, щоб активувати використання IOPS-метрик у автоматичних міграціях чи рекомендаціях (щодо IOPS-метрик ми говорили вище, у відповідному підрозділі про політики сховища):

Правила спорідненості для ВМ

Правила affinity вказують, чи можуть бути обрані ВМ поміщені на той самий хост, чи на різні. Правила affinity призначені для ВМ, що інтенсивно спілкуються між собою, а аnti-affinity корисні, якщо важлива високодоступність для ВМ чи балансування навантажень.

Створювати ці правила можна після того, як кластер vSphere DRS з’явився. Для цього на вкладці Configure у бічному меню під Configuration шукаємо VM/Host Rules, тиснемо кнопку ADD зверху зліва, і у вікні, що відкрилося, там де поле Type з розкривного меню обираємо потрібне:

Важливо! Якщо два правила конфліктують, заборонено активувати жодне.

Взагалі, правила бувають двох видів: правилами переваги та обов’язковими. Правила переваги (preferential) застосовуються м’яко та за необхідності ними можна знехтувати. Обов’язкові правила (required) суворо дотримуються у будь-якому випадку й порушені бути не можуть.

Групи DRS

Групи ВМ чи хостів використовуються у визначенні правил affinity. Групи, відповідно бувають двох типів: для ВМ з однією або більше машиною та хостів – з одним чи більше ESXi-хостом. Одна машина може належати декількома групам, як і один хост. Щоб створити таку групу на вкладці Configure у бічному меню під Configuration шукаємо VM/Host Groups, тиснемо ADD зверху зліва, і у вікні, що відкрилося, там де поле Type з розкривного меню обираємо потрібне:

Правила affinity ВМ-хост

Правило ВМ-хост affinity (чи анті-афініті) визначає взаємозв’язок між групою ВМ та групою хостів. Воно є правилом переваги і каже нам, наскільки безапеляційно повинно воно запускатися на хостах у групі: категорично повинно, бажано, категорично не повинно, не бажано (відповідні фрази з «Must…» та «Should…»):

Важливо! Правила спорідненості базуються на кластері й застосовуються до всіх ВМ чи хостів з нього. Якщо ВМ вилучена з кластеру, вона втрачає членство групи, навіть якщо її пізніше повернути назад.

Рекомендації vSphere DRS

Вище неодноразово згадували про те, що vSphere DRS любить давати рекомендації – побачити їх можна на спеціальній вкладці (Monitor – vSphere DRS – Recomendations):

Звісно ж, вони там будуть, тільки якщо в нас кластер Manual чи Partially Automated.

Щоб оновити табличку, запускаємо кнопку у верхньому правому кутку RUN DRS NOW. Щоб застосувати усі наявні рекомендації, клікаємо на функціональний напис SELECT ALL (з’являться галочки по всіх рекомендаціях) зверху таблички та натискаємо на APPLY RECOMMENDATIONS правіше. Якщо потрібно застосувати тільки деякі, відповідно, обираємо галочками й тиснемо на APPLY…

Нижче рекомендацій у бічному меню є пункт Faults, щоб переглянути помилки, що виникли під час застосування рекомендацій. А ще нижче – History, що покаже усі дії vSphere DRS.

Maintenance та Standby режими і vSphere DRS

Неодноразово згадані вище режими maintenance і standby, насправді означають, в першому випадку, що хост виводиться в режим обслуговування і його ресурсами не можна скористатися, а другий використовується vSphere DPM для оптимізації живлення (попросту хост вимикається):

Занурення та вихід з режиму техобслуговування відбувається за запитом користувача. ВМ з такого хоста потрібно вимкнути, призупинити чи перенести на інший хост (автоматично завдяки vSphere DRS чи вручну), причому аж поки для усіх машин це не здійсниться, хост буде показувати задачу Enter Maintenance Mode.

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