Жовтень минулого року відзначився суттєвою й, без перебільшення, довгоочікуваною подією: 11 жовтня VMware відзвітувала про вихід у світ нової мажорної версії нашої vSphere. Ще більше співпраці з хмарними технологіями, легка інтеграція з Kubernetes, деякі іновації для DevOps, зростання операційної ефективності та продуктивності робочих навантажень. Загалом, новинок дуже й дуже багато: на головних моментах зупинимось нижче, як і на тому, де дістати актуальний білд, а усього, що стосується підготовки до інсталяції, апгрейду та іншого, торкнемося у відповідних присвячених їй гайдах.
Актуальний білд
Наразі жодних патчів до для ESXi vSphere 8.0 ще не виходило, тому робочим є білд 20513097:
а от для vCenter Server пропонується вже версія 8.0.0а – 20519528:
Це для ліцензій класу Standard, а інші образи можна знайти за посиланням. Там же, до речі, й нові VMware Tools 12.1.5 та інші пов’язані компоненти, але їм спробуємо присвятити в майбутньому окремі матеріали.
Подробиці оновлення
Перш за все треба сказати про докорінну зміну самого підходу до концепції нових релізів vSphere: ця модель IA/GA (Початкова доступність / Загальна доступність) відтепер краще працює з узгодженням випусків хмарних служб, що є складовими vSphere+, а також дає час клієнтові отримати усю інформацію щодо нової версії та підготуватися до її подальшого використання. На практиці це буде виглядати, як спочатку постачання продуктиву з позначкою IA (повністю сертифікована, готова до розгортання та якісна) – цей період запланований протягом 4-6 тижнів. За цей час збирається вся інформація щодо практичного використання продукту на місцях, відгуки клієнтів, проводяться покращення за необхідності. Коли позначка версії з IA зміниться на GA, це означитиме, що продукт набув достатньо широкого поширення і відтепер має додаткову гарантію якості. Завдяки цьому більше не потрібно буде чекати звичайного трохи не піврічного масштабного оновлення – продукт буде динамічно покращуватися в процесі.
Це було загальне зауваження від виробника, щоб ми відтепер не лякалися незрозумілих літер у позначеннях продуктів. А серед інших ключових покращень слід відзначити наступні.
vSphere Distributed Services Engine
- vSphere Distributed Services Engine. Механізм розподілених сервісів vSphere раніше називався Project Monterey. Його оновлення пропонує потужність блоків обробки даних (DPU) для прискореної обробки даних на рівні hardware з метою покращення продуктивності інфраструктури, її убезпечення та спрощення керування життєвим циклом DPU. Додатковий інстанс ESXi встановлюється безпосередньо на блок обробки даних, що дозволяє розвантажити служби ESXi на DPU. Підтримка нових інсталяцій відбувається за допомогою NSX, а життєвий цикл vSphere Distributed Services Engine контролює vSphere Lifecycle Manager. Коли відбувається виправлення хосту з інсталяцією DPU ESXi, версія DPU ESXi завжди виправляється згідно батьківського хосту та зберігається в режимі блокування версії:
- Вихід Data Processing Unit. Блоки обробки даних сьогодні існують на апаратному рівні, так само як пристрої PCIe на кшталт NIC або GPU. Зараз служби мереж, сховищ та керування хостами працюють на інстансі ESXi, що віртуалізує рівень обчислень x86:
- Проста конфігурація задля розвантаження мережі. За допомогою vSphere Distributed Switch 8.0 та NSX мережеві служби розвантажуються на DPU, що дає змогу підвищити продуктивність мережі без перевантажень x86 CPU, покращити видимість мережевого трафіку та безпеки, ізоляцію та захист, на які очікують від NSX:
vSphere з Tanzu
- vSphere з Tanzu. Tanzu Kubernetes Grid на vSphere 8 консолідує пропозиції Tanzu Kubernetes в єдиному уніфікованому середовищі виконання Kubernetes від VMware. Зони доступності робочого навантаження (Workload Availability Zones) використовуються для ізоляції робочого навантаження в кластерах vSphere. Кластери супервізора та кластери Tanzu Kubernetes можна розгортати в різних зонах задля підвищення доступності кластерів, переконавшись, що ноди не використовують однакові кластери vSphere. ClusterClass – це спосіб декларативно вказати конфігурацію кластера за допомогою проекту ClusterAPI з відкритим кодом. Основні образи PhotonOS і Ubuntu можна налаштувати та зберегти в бібліотеці контенту для використання в кластерах Tanzu Kubernetes. Інтеграція Pinniped доступна для кластерів супервізора та кластерів Tanzu Kubernetes. Pinniped підтримує LDAP та OIDC федеративну автентифікацію. Можна визначити постачальників даних ідентифікації, що використовуються для автентифікації користувачів у кластерах супервізора та кластерах Tanzu Kubernetes.
- Покращення стійкості робочих навантажень в сучасних застосунках. Зони доступності робочого навантаження (Workload Availability Zone) дозволяють кластерам супервізора та кластерам Tanzu Kubernetes охоплювати кластери vSphere для підвищення доступності. Простори імен (Namespace) vSphere охоплюють зони доступності робочого навантаження для підтримки розгортання кластерів Tanzu Kubernetes, розгорнутих для підвищення доступності в зонах:
Для доступності потрібні три Workload Availability Zone. При активації Workload Management надається вибір між розгортанням в зонах доступності робочого навантаження та розгортанням в одному кластері. У vSphere 8 GA Workload Availability Zone має співвідношення 1:1 з кластером vSphere.
- ClusterClass. ClusterClass надає декларативний спосіб визначення конфігурації кластера Tanzu Kubernetes, а також пакетів, встановлених за замовчуванням. Команда платформи може визначити інфраструктурні пакети, що мають бути встановленими під час створення кластера. Вони можуть включати провайдерів мереж, механізми автентифікації та збору метрик. Специфікація кластера посилається на ClusterClass:
ClusterClass – це open-source специфікація, що є частиною проекту ClusterAPI. ClusterAPI визначає декларативний спосіб керування життєвим циклом кластерів Kubernetes через наявний кластер керування Kubernetes. В vSphere with Tanzu цей кластер керування є кластером супервізора.
- Гнучке керування пакетами. Після розгортання кластера користувачі Developers чи DevOps можуть додавати додаткові пакети з Tanzu Standard Package Repository. Ці пакети мають включати Contour для входу в кластер, керування сертифікатами, створення журналів логів, можливість спостереження за допомогою Prometheus чи Grafana, чи зовнішнього DNS. Вони керуються як аддони через інтерфейс Tanzu CLI:
- Використання власного провайдера ідентифікації. У vSphere 7 автентифікація відбувається через інтеграцію з vCenter Single Sign-On. Цю практику можна продовжувати й у vSphere 8, але відтепер є й альтернатива. Використовуючи інтеграцію Pinniped, кластер супервізора та кластери Tanzu Kubernetes можуть мати прямий доступ OIDC до провайдера ідентифікаційної інформації (IDP), не покладаючись на vCenter Single Sign-On. Поди Pinniped автоматично розгортаються в кластері супервізора та кластерах Tanzu Kubernetes для полегшення інтеграції:
А саме:
- Користувач DevOps використовує логін Tanzu CLI для автентифікації в Supervisor та/або TKC;
- Інтеграція Pinniped об’єднується з IDP;
- IDP повертає посилання для входу чи вікно;
- Користувач DevOps вводить облікові дані IDP;
- Успішна автентифікація в IDP повертається в Pinniped;
- Tanzu CLI створює файл kubeconfig, необхідний для доступу в Supervisor та/або TKC.
Управління життєвим циклом
- Lifecycle Management. vSphere 8 представляє підтримку DPU для vSphere Lifecycle Manager, щоб автоматично виправляти інсталяцію ESXi на DPU в покроковому режимі згідно версії хоста ESXi. Інсценування корисних навантажень апдейту/апгрейду, паралельне виправлення та підтримка standalone хоста комбінуються задля забезпечення паритету функцій vLCM з Update Manager. Окремими хостами можна керувати за допомогою vSphere Lifecycle Manager через API. VMware Compatibility Guide деталізує, які функції vLCM може підтримувати Hardware Support Manager. Технічний попередній перегляд профілів конфігурації vSphere представляє наступне покоління керування конфігурацією кластера як майбутню заміну профілів хосту.
- Прискорення виправлення за допомогою Stage Cluster Image Updates. vSphere Lifecycle Manager може передати оновлення корисних навантажень на хости перед виправленням. Це може відбуватися не в режимі maintenance. Корисне навантаження вбудованого програмного забезпечення також можна інтегрувати за допомогою підтримуваного Hardware Support Manager:
- Прискорене виправлення кластера. vSphere Lifecycle Manager може виправляти кілька хостів паралельно, що значно економить час виправлення всього кластера. Хости в режимі техобслуговування можуть виправлятися паралельно (і тільки в такому стані!). Адміністратор vSphere може обрати виправлення всіх хостів у режимі maintenance, чи визначити кількість паралельних виправлень для виконання в певний час:
- Управління конфігурацією в масштабі. vSphere 8 представляє перев’ю профілів конфігурації vSphere (vSphere Configuration Profiles) нового покоління управління конфігурацією кластера:
Бажана конфігурація визначається в об’єкті кластера та застосовується до всіх хостів кластера. Усі вони мають узгоджену конфігурацію. Відстежується девіація конфігурації, про що негайно повідомляється, завдяки чому адміністратор vSphere може виправити це відхилення. Нагадуємо, vSphere Configuration Profiles наразі ще активно розробляються, тому в наступних релізах продукту їх підтримку буде розширено й покращено. Не хвилюйтесь, Host Profiles продовжують підтримуватися vSphere 8.
- Покращене відновлення vCenter. vCenter узгоджує стан кластера після відновлення з бекапу. Хости ESXi у кластері містять розподілене сховище ключів стану кластера:
Розподілене сховище ключів є джерелом відповідності для стану кластера. Якщо vCenter відновлено з резервної копії, він узгодить стан і конфігурацію кластера з розподіленим сховищем ключів. У vSphere 8 GA членство в хост-кластері узгоджено з додатковою конфігурацією та станом, запланованим для підтримки в майбутніх релізах.
AI/ML
- Уніфіковане керування апаратними прискорювачами AI/ML. Групи пристроїв (Device Groups) спрощують роботу віртуальних машин із додатковими апаратними пристроями у vSphere 8. Пристрої NIC та GPU підтримуються у vSphere 8 GA. Потрібні сумісні драйвери пристроїв від вендорів. NVIDIA® буде першим партнером, що підтримує Device Groups з очікуваними сумісними драйверами:
Групи пристроїв можуть складатися з двох або більше апаратних пристроїв зі спільним комутатором PCIe, або пристроїв, що напряму з’єднуються між собою. Device Groups виявляються на апаратному рівні та представлені в vSphere як єдиний юніт, що представляє групу.
- Спрощене споживання апаратного обладнання з Device Groups. Групи пристроїв додаються до віртуальних машин за допомогою існуючих робочих процесів «Add New PCI Device». vSphere DRS і vSphere HA поінформовані щодо груп пристроїв та розміщують ВМ відповідно до них:
- Нове покоління віртуальних апаратних пристроїв. Device Virtualization Extensions будується на Dynamic DirectPath I/O і представляє новий фреймворк та API для вендорів для створення віртуальних пристроїв з апаратною підтримкою. Розширення віртуалізації пристроїв забезпечує більшу підтримку функцій віртуалізації, зокрема міграції наживо з vSphere vMotion, призупинення й відновлення ВМ та підтримку снепшотів диску та пам’яті:
На хостах ESXi має бути встановлений сумісний драйвер з відповідним драйвером гостьової ОС для еквівалента віртуального пристрою. Віртуальну машину, що використовує віртуальний пристрій розширення віртуалізації пристрою, можна перенести, користуючись vSphere vMotion, до іншого хоста, що підтримує той самий віртуальний пристрій.
Гостьова ОС та робочі навантаження
- Версія 20 віртуального Hardware. Віртуальне обладнання версії 20 наразі є найсвіжішим. Його тема пропонує інновації віртуального апаратного забезпечення, покращує гостьові сервіси для застосунків, підвищує продуктивність та масштабованість для певних робочих навантажень.
- Масштабоване розгортання Windows 11. Мова про постачання політики TPM. Windows 11 вимагає пристроїв vTPM у віртуальних машинах. Клонування ВМ з віртуальною машиною vTPM може нести загрозу безпеці, адже відбувається клонування секретів TPM:
У vSphere 8 пристрої vTPM можна автоматично замінювати під час операцій клонування чи розгортання. Це дозволяє дотримуватися best practices щодо того, що кожна віртуальна машина містить унікальний пристрій TPM, і покращує підтримку vSphere для масштабованого розгортання Windows 11. vSphere 8.0 також містить розширене налаштування vpxd.clone.tpmProvisionPolicy задля створення дефолтної поведінки клона для vTPM, що заміщуються.
- Зменшення збоїв за допомогою підготовки застосунків для міграції. Деякі застосунки не витримують «оглушення», пов’язані з vSphere vMotion. Ці застосунки можна написати з урахуванням міграції, щоб покращити їх взаємодію з vSphere vMotion. Застосунки можуть підготуватися до події міграції або шляхом обережної зупинки служб, або виконанням відмови на випадок кластеризованого застосунку. Застосунок може відкласти початок міграції до налаштованого часу очікування, але не може відхилити чи запобігти міграції. Варіанти використання включають:
- чутливі до часу застосунки,
- VoIP застосунки,
- кластеризовані застосунки.
- Максимізація продуктивності для чутливих до затримок робочих навантажень. Нові робочі навантаження Telco вимагають посиленої підтримки чутливих до затримки застосунків. Висока чутливість до затримки (High Latency Sensitivity) з Hyper-threading розроблена для підтримки таких навантажень і забезпечує кращу продуктивність. vCPU віртуальної машини внесено у розклад на одному фізичному ядрі з гіперпотоковим процесором:
Для High Latency Sensitivity з гіперпотоковістю потрібне апаратне забезпечення ВМ версії 20, і її можна задати в розширених налаштуваннях віртуальної машини:
- Спрощення віртуальної конфігурації NUMA. vSphere 8 і апаратне забезпечення версії 20 дозволяють користатися клієнтом vSphere для налаштування топології vNUMA для віртуальних машин:
Блок нової топології CPU відображається на вкладці ВМ підсумку, де бачимо поточну топологію:
- vSphere на API та обмін даними між гостями. vSphere DataSets забезпечує простий спосіб розподілу невеликих, не часто змінюваних даних між рівнем керування vSphere та гостьовою операційною системою, запущеною на віртуальній машині з проінстальованими VMware Tools. Варіанти використання можуть включати статус розгортання Guest, конфігурацію його агента чи управління його інвентарем. vSphere DataSets існують разом з об’єктом ВМ та переміщуватимуться з нею, якщо таке відбувається, навіть якщо йдеться про інстанси vCenter Server:
Управління ресурсами
- Покращена продуктивність DRS. У vSphere 7.0U3 з’явилась нова функція vSphere Memory Monitoring and Remediation (vMMR), що допомагає у подоланні потреби в моніторингу, надаючи поточну статистику як на рівні ВМ (пропускна здатність), так і на рівні хоста (пропускна здатність, пропуски). Вона сповіщає за замовчуванням й можна налаштовувати спеціальні сповіщення на основі робочих навантажень, що запущені на ВМ. Збирає дані та дає огляд статистичних даних щодо продуктивності, що допомагає виявити зменшення робочого навантаження застосунку через Memory Mode. У vSphere 8 продуктивність DRS може бути значно покращена за наявності PMEM шляхом використання статистики пам’яті, що допомагає приймати оптимальні рішення щодо розміщення ВМ без впливу на продуктивність і споживання ресурсів:
- Моніторинг енергоспоживання. vSphere Green Metrics представляє нові метрики споживання енергії для хостів та віртуальних машин. Вони допомагають адміністраторам контролювати енергоспоживання інфраструктури vSphere і визначати, чи є вона енергоефективною, з огляду на ті канали, якими користується для свого живлення ЦОД. Ці метрики відстежують:
- capacity.usageSystem – енергоспоживання діяльності системи хоста, скільки енергії споживає хост, незалежно від ВМ;
- capacity.usageIdle – енергоспоживання холостої активності, скільки енергії споживає хост у стані відпочинку, окрім увімкненого;
- capacity.usageVm – енергоспоживання хосту через навантаження ВМ, скільки енергії хост використовує для виконання робочих навантажень ВМ:
Безпека та відповідність
- У vSphere 8 вжито додаткових заходів задля безпечності продукту за замовчуванням. А саме:
Запобігання виконанню ненадійних двійкових файлів. ESXi 8.0 за замовчуванням увімкне опцію execInstalledOnly (щодо файлів, які не є встановленими через VIB).
Автоматичний таймаут SSH. Доступ по SSH дезактивується за замовчуванням, а в vSphere 8 тепер є таймаут за замовчуванням, щоб запобігти зависанню неактивних сеансів SSH.
Демони ізольованого програмного середовища. Демони та процеси ESXi 8.0 працюють у власному домені ізольованого програмного середовища («пісочниці»), де для роботи доступні лише мінімально необхідні дозволи.
Сховище
- NVMeoF vVols. Актуальна нова специфікація vVols, фреймворк VASA/VC – VASA 4.0/vVols 3.0. Серед переваг NVMeoF vVols – налаштування. Під час розгортання при реєстрації VASA базове налаштування проходить у фоновому режимі, а користувачу лиш потрібно створити сховище даних. Усі віртуальні кінцеві точки протоколу (vPE) і з’єднання обробляються VASA, що спрощує налаштування.
- Покращення NVMeoF. Підтримка 256 просторів імен і 2К шляхів з NVMe-TCP та NVMe-FC. NVMe over Fabrics (NVMeoF) матиме вищу пропускну VMDK здатність і вищу продуктивність, порівняно з SCSI чи NFS підключенням. Розширення підтримки команд резервування NVMe для включення таких рішень, як WSFC, дозволить клієнтам використовувати ємність кластеризованого VMDK для використання з Microsoft WSFC зі сховищами NVMeoF. Наразі лише FC.
Також впроваджене автоматичне виявлення підтримки NVMe Discovery в ESXi. ESXi використовуватиме службу mDNS/DNS-SD для отримання IP-адреси та номеру порту активних служб виявлення NVMe-oF у мережі. ESXi посилає багатоадресний запит DNS (mDNS), вимагаючи інформацію від суб’єктів, що надають (NVMe) службу виявлення (DNS-SD). Якщо така сутність активна в мережі, вона відповість (одноадресно) хосту із запитуваною інформацією.
- vVols. Відбулося покращення VM Swap через пришвидшення вмикання/вимикання живлення, зростання продуктивності vMotion, унаслідок змін в тому, як надається/знищується своп vVols. Крім того, можливості налаштування vVol допомагають лишатися на зв’язку, скорочуючи час запитів під час пошуку інформації ВМ. Також слід відзначити кешування різних атрибутів vVol, таких як назва, розмір тощо. config-vvol зберігає домашні дані ВМ. (vmx, nvrams, логи тощо) і, зазвичай, доступні лише під час завантаження чи зміни. Раніше використовувалося те, що називається «лінивим відв’язуванням», відв’язуючи config-vvol, коли він не використовувався. Але іноді потім деякі застосунки періодично звертаються до config-vvol й вимагають нової операції прив’язки. Відтепер збереження прив’язки зменшує затримку під час доступу до домашніх даних ВМ.
- Покращення Unmap Space Reclamation. Мінімальна швидкість повернення знизилася до 10 Мбіт/с. Починаючи з vSphere 6.7, додана функція, яка дозволяє налаштовувати частоту відображення на рівні сховища даних. За допомогою цього вдосконалення клієнти можуть змінювати швидкість відображення відповідно до можливостей їх масиву та рекомендацій вендора. Більш високий рівень unmap сприяв багатьом вендорам масивів, які швидко звільняли простір. Але навіть із найнижчою швидкістю unmap у 25 МБ/с, вона могла бути руйнівною, коли кілька хостів надсилали команди unmap одночасно. Збій міг збільшитися при масштабуванні кількості хостів у кожному сховищі даних. Приклад потенційного перевантаження: 25 МБ/с * 100 сховищ даних * 40 хостів ~ 104 ГБ/с. Відтепер ця проблема щезла:
Крім того слід відзначити створення виділеної черги планування unmap (Unmap Scheduling Queue). Вона дозволяє відокремлювати високопріоритетні метадані VMFS і обслуговувати їх з окремих schedQueues, щоб запобігти їх виснаженню через команди unmap.
- Контейнерне сховище CNS/CSI. Щодо VMFS і vSANDirect Disk Provisioning Storage Policy тепер можна вибирати EZT, LZT чи Thin надання через політику для CNS/Tanzu. Мета полягає в тому, щоб додати можливість SPBM для підтримки створення/модифікації правил політики зберігання, щоб указати параметри розподілу томів. Це також полегшить перевірку відповідності в SPBM щодо правил розподілу томів у політиці зберігання. Для віртуальних дисків підтримуються такі операції: створення, переналаштування, клонування та переміщення. Для FCD підтримуються такі операції: створення, оновлення політики зберігання, клонування та переміщення:
- Покращення NFS. З метою підвищення стійкості сховищ у vSphere 8 додано вдосконалення NFS, що полягає у зростанні стійкості, завдяки службам, перевіркам та підтвердженню дозволів. Наприклад, надання можливості підключити NFS ще раз в разі помилки, а також перевірка монтування NFS.
Інше
- Взаємна автентифікація смарт-карт переїхала на порт 3128.
- VMDK тільки для читання не можна зареєструвати як FCD.
Функції, компоненти, продукти та інше, визнані застарілими або такими, що не підтримуються
Baseline lifecycle management (раніше відомий як vSphere Update Manager) визнаний застарілим (ще підтримується, проте в подальших релізах його остаточно відкинуть).
Припинення підтримки Trusted Platform Module (TPM) 1.2. ESXi 8.0 покаже попередження під час встановлення або оновлення, якщо наявний пристрій TPM 1.2. При цьому інсталяція чи оновлення не будуть заборонені.
Лише TLS 1.2. vSphere 8 не підтримує TLS 1.0 та TLS 1.1. У «сімці» вони вважалися вимкненими, а тепер взагалі видалені геть.
Далі коротенько перелічимо, що ще вже втратило, або гарантовано ось-ось втратить актуальність:
- N-Port ID Virtualization (NPIV)
- Integrated Windows Authentication (IWA)
- Common Information Model (CIM)
- Patch Manager API
- Локальні плагіни
- Підтримка 32-бітних світів користувачів
- VMKAPI v2.4
- Драйвер nmlx4_en
- Незахищені шифри (сертифікати X.509 з алгоритмом підпису SHA-1 й інші)
- Адаптери ПО FCoE
- Підтримка пристроїв введення/виведення, які використовуються драйверами nmlx4_en та lpfc.
Сумісність
Підтримуються віртуальні машини, сумісні з ESXi 3.0 й пізнішими (версія апаратного забезпечення – 4). Усі інші вважаються тими, що не підтримуються.
Щодо операційних систем сумісність варто перевіряти, як завжди, в VMware Compatibility Guide. Тими, що вважаються застарілими, або припиненими у використанні, є системи:
- Windows Vista, Windows 2003 / R2, Windows XP
- Oracle Linux 5.x
- Oracle Linux 4.9
- CentOS 5.x
- Asianux 3.0
- SUSE Linux Enterprise Server 9 SP4
- SUSE Linux Enterprise Server 10 SP4
- SUSE Linux Enterprise Desktop 12
- Ubuntu 12.04, 18.10, 19.04 та 19.10
- Debian 7.x й 8.x
- Debian 6.0
- Photon OS 1.0
- Flatcar Container Linux non-LTS релізи
- Усі релізи OS X і macOS
- FreeBSD 9.x і 10.x
- FreeBSD 7.x і 8.x.
- Solaris 10.x
- Усі релізи eComStation
- Усі релізи SCO
- Усі релізи CoreOS.
Перевірку сумісності пристроїв та апаратного забезпечення вендор радить, знову ж таки, перевіряти у VMware Compatibility Guide, а різних версій ESXi та vCenter Server – у Product Interoperability Matrix. Усіх питань сумісності в подробицях торкнемося у запланованих майбутніх гайдах щодо інсталяції продукту та його оновлення до найсвіжішої версії.
Локалізація
vSphere 8.0 доступна:
- англійською,
- італійською,
- французькою,
- німецькою,
- іспанською,
- японською,
- корейською,
- спрощеною китайською,
- традиційною китайською.