У рамках подій першого дня конференції VMware Explore 2022 було анонсовано платформу віртуалізації VMware vSphere 8. Цю подію дуже чекали багато адміністраторів і менеджерів датацентрів, адже з моменту релізу минулої мажорної версії платформи VMware vSphere 7 минуло вже два з половиною роки.
Давайте подивимось, що нового у VMware vSphere 8. Нововведення зосереджені в 4 основних областях:
- отримання переваг хмарних навантажень для онпремізної інфраструктури;
- суттєве поліпшення продуктивності;
- покращення операційних інструментів;
- нова функціональність для співробітників DevOps, що прискорює розгортання та обслуговування додатків.
Отже, всі нові можливості по порядку:
1. Движок vSphere Distributed Services Engine
Уже протягом досить довгого часу вендори апаратного забезпечення намагаються зробити вивільнення деяких функцій CPU, передавши їх відповідним компонентам сервера (модуль vGPU, мережева карта з підтримкою offload-функцій тощо), максимально ізолювавши їх у рамках необхідностей. Але вся ця нова апаратна архітектура не буде добре працювати без змін у програмній платформі.
У vSphere 8 з’явилася нова функціональність vSphere Distributed Services Engine, що раніше мала назву Project Monterey. Project Monterey – це і є переробка архітектури vSphere Cloud Foundation таким чином, щоб з’явилася нативна інтеграція нових апаратних можливостей і програмних компонентів. Наприклад, нова апаратна технологія SmartNIC дає змогу забезпечити високу продуктивність, безпеку за моделлю zero-trust і просту експлуатацію в середовищі VCF. За рахунок технології SmartNIC інфраструктура VCF буде підтримувати операційні системи і додатки, що виконуються на “голому залізі” (тобто без гіпервізора і окремо від нього).
За допомогою модулів Data Processing Units (DPU), що існують вже сьогодні в PCIe-пристроях, таких як NIC або GPU, можна реалізовувати дану технологію з управління хостами і сховищами на рівні гіпервізора ESXi.
У vShphere 8 гіпервізор ESXi встановлюється безпосередньо в Data Processing Unit, що дає змогу оперувати функціями пристроїв, використовуючи їхні ресурси безпосередньо і забезпечуючи максимальну продуктивність.
Під час релізу vSphere 8 підтримуватимуться чисті установки на DPU, які забезпечують offload функціональності NSX на мережеві пристрої. Життєвий цикл vSphere Distributed Services Engine керується засобом vSphere Lifecycle Manager. На хостах, де є встановлений у DPU гіпервізор ESXi, завжди підтримуватиметься його актуальна версія.
З використанням vSphere Distributed Switch 8.0 і рішення NSX мережеві сервіси будуть виконуватися безпосередньо на DPU, не задіюючи ресурси x86-процесора, покращуючи пряму видимість мережевого трафіку, безпеку систем і їхню ізоляцію – все те, що ви очікуєте від NSX.
2. Покращення vSphere with Tanzu
Тут є такі основні поняття, які допоможуть зрозуміти нову функціональність платформи vSphere 8 щодо роботи з кластерами Kubernetes:
- Tanzu Kubernetes Grid on vSphere 8 – засіб консолідації рішень Tanzu Kubernetes в одному виконуваному середовищі від VMware.
- Workload Availability Zones – засоби для ізоляції робочих навантажень у межах кластерів vSphere. Supervisor-кластери та кластери Tanzu Kubernetes можуть розміщуватися в різних зонах, щоб підвищити доступність кластерів, де вузли не використовуються в одних кластерах vSphere.
- ClusterClass – спосіб визначити конфігурацію кластера через специфікацію ClusterAPI.
- PhotonOS и Ubuntu – базові образи, які можна кастомізувати і зберегти в бібліотеці контенту (content library) для використання в середовищі Tanzu Kubernetes.
- Pinniped Integration – рішення з автентифікації для кластерів Tanzu Kubernetes, яке підтримує протоколи LDAP і OIDC. Ви можете визначати identity-провайдерів, які будуть використовуватися для supervisor-кластерів і кластерів Tanzu Kubernetes.
Стабільність і доступність у межах Workload Availability Zones для Supervisor-кластерів і кластерів Tanzu Kubernetes забезпечується завдяки розтягуванню робочих навантажень між кластерами vSphere, водночас повністю підтримується механіка vSphere Namespaces.
Три зони Workload Availability Zones потрібні для забезпечення високої доступності. Під час активації Workload Management ви можете вибрати варіант розгортання між Workload Availability Zones, або в межах одного кластера. У першій версії цього механізму відносини vSphere cluster <> Availability Zone побудовані як 1:1.
ClusterClass дає змогу декларативно визначити конфігурацію кластера Tanzu Kubernetes і пакети, що встановлюються за замовчуванням. Ці рішення приймає команда DevOps. Вони можуть містити пакети для мережевої комунікації, сховищ, хмарних провайдерів, механізми автентифікації та збору метрик. Тобто ClusterClass – це специфікація кластера Tanzu Kubernetes на базі ClusterAPI, яким керують з боку supervisor-кластера.
Після розгортання кластера розробники та фахівці DevOps можуть додавати опціональні пакети через Tanzu Standard Package Repository. Ці пакети можуть містити засоби Contour, утиліти управління сертифікатами, логування, спостереження за трафіком (такі як Prometheus), візуалізацію Grafana, а також зовнішні DNS-сервіси. Усе це керується через інтерфейс Tanzu CLI.
У vSphere 7 автентифікація працювала через механізм інтеграції з vCenter Single Sign-On. Тепер ви можете продовжити його використовувати, але з’явився ще один метод – Pinniped integration. Тепер кластери Tanzu Kubernetes і supervisor-кластер мають прямий доступ через OIDC або LDAP до Identity Provider (IDP) без використання vCenter Single Sign-On. Контейнери Pinniped автоматично розгортаються в кластерах для повної готовності до інтеграції.
- DevOps використовують Tanzu CLI login для автентифікації в кластерах Supervisor і TKC;
- Інтеграція Pinniped федерує доступ через IDP;
- IDP повертає посилання логіна або показує вікно автентифікації;
- Користувач DevOps вводить параметри облікового запису IDP;
- Після автентифікація в IDP відбувається перенаправлення в Pinniped;
- Tanzu CLI будує файл kubeconfig, який потрібен для доступу до кластерів Supervisor і TK.
3. Засоби управління життєвим циклом
Як було сказано вище, vSphere 8 має підтримку DPU в vSphere Lifecycle Manager для автоматичного оновлення гіпервізорів ESXi в цих пристроях. Водночас підтримується стейджинг апдейтів і апгрейдів, паралельне накочування оновлень і робота зі standalone-хостами, щоб забезпечити повну ідентичність функцій vLCM і застарілого Update Manager. Standalone-хости можуть управлятися через API.
Технічне прев’ю vSphere Configuration Profiles є новим поколінням інструментів для управління конфігураціями кластерів і в майбутньому замінить наявну функціональність Host Profiles.
Механізм Baseline lifecycle management, раніше відомий як продукт vSphere Update Manager, уже виводять з експлуатації у vSphere 8. Його ще підтримують, але це останній реліз vSphere, де він присутній.
vSphere Lifecycle Manager може відправляти апдейти на стейджинг заздалегідь для подальшого накочування у виробничому середовищі. Стейджинг апдейтів можна зробити, не переводячи хости в режим обслуговування (maintenance mode). Оновлення мікрокоду (Firmware) також можна відправляти на стейджинг завдяки інтеграції з Hardware Support Manager.
vSphere Lifecycle Manager може оновлювати хости ESXi в паралельному режимі, зменшуючи загальний час, потрібний на оновлення кластера. Адміністратор може визначити, чи потрібно оновлювати всі хости, які зараз перебувають у режимі обслуговування, або визначити максимальну кількість одночасних завдань з апдейтів.
Також у vSphere 8 доступне прев’ю технології vSphere Configuration Profiles, яка замінить Host Profiles:
Бажана конфігурація визначається на рівні об’єкта кластера і застосовується до всіх його хостів. Усі хости повинні мати єдину консистентну конфігурацію. Відхилення від рівня конфігурації моніторяться, і про них повідомляють адміністратора, який за кліком може усунути ці відмінності.
Поки ця функціональність перебуває в статусі Tech Preview, користувачі можуть застосовувати стандартний механізм Host Profiles.
Також тепер vCenter зберігає стан кластера після відновлення себе з бекапа. Це доступно тому, що хости ESXi зберігають у собі розподілене сховище типу key-value, що визначає стан кластера.
4. Покращення для AI та ML навантажень
Тепер доступні засоби уніфікованого управління для AI/ML Hardware Accelerators. Групи пристроїв (Device Groups) дають змогу організувати віртуальним машинам більш просте та зручне споживання апаратних ресурсів типу NIC і GPU, які взаємодіють між собою. NVIDIA буде першим партнером VMware, який підтримує Device Groups з усіма необхідними сумісними драйверами.
Група складається з двох або більше пристроїв, на одному PCIe-комутаторі, або з’єднаних між собою безпосередньо. Для платформи vSphere 8 ці пристрої представляється як єдиний модуль групи.
Device Groups додаються до віртуальних машин через робочий процес Add New PCI Device. Механізми vSphere DRS і vSphere HA підтримують ці групи пристроїв і забезпечуватимуть знаходження ВМ таким чином, щоб вони мали доступ до своєї групи.
Функції Device Virtualization Extensions, побудовані на базі технології Dynamic DirectPath I/O, надають новий фреймворк і API для сторонніх вендорів, щоб вони могли будувати віртуальні пристрої, що мають зв’язок з обладнанням. Це дає змогу краще підтримувати механізми vSphere vMotion, Suspend/Resume, а також механіку снапшотів пам’яті та диска.
5. Гостьові ОС і віртуальні машини
Оновилася версія “віртуального заліза” – тепер для віртуальних машин доступна Virtual Hardware Version 20. Основні нововведення наступного покоління наведено на зображенні:
Тут ми бачимо багато чого з того, про що йшлося вище.
Також тепер з’явилася політика TPM Provision Policy. Як багато хто знає, у Windows 11 потрібні пристрої vTPM, які мають бути у віртуальних машинах. Клонування машини з vTPM може становити загрозу, оскільки параметри TPM також клонуються.
Для усунення цієї проблеми можна замінити пристрій vTPM на створюваній ВМ:
Також є політика vpxd.clone.tpmProvisionPolicy, що визначає поведінку за замовчуванням при клонуванні машин з vTPM.
Деякі програми не можуть пережити навіть мікрозатримки під час vSphere vMotion. У цьому випадку VMware дає механізм для написання migration aware додатків, які можуть інтегруватися з vMotion. Тобто застосунок може підготуватися до події міграції за рахунок зупинки якихось сервісів або перемикання на резервну копію кластеризованого застосунку. У цьому разі застосунок може за налаштованим таймаутом відкласти міграцію vMotion до завершення своїх процесів з підготовки до міграції (але відхилити її не зможе).
Навантаження у сфері телекому вимагають поліпшеної підтримки додатків, вимогливих до затримок (latency). Функції High Latency Sensitivity with Hyper-threading розроблені для підтримки цих завдань і дають поліпшену продуктивність. У цьому разі vCPU машини виконується на тому самому фізичному CPU-ядрі в режимі hyper-threading, зокрема після міграції.
Налаштування High Latency Sensitivity with Hyper-threading вимагають hardware version 20 і доступні в розділі Advanced settings для ВМ:
У vSphere 8 + hardware version 20 тепер доступне просте конфігурування vNUMA-топології для віртуальних машин:
Також тепер для віртуальної машини доступна інформаційна панелька CPU Topology з конфігурацією vNUMA:
Функції vSphere DataSets дають можливість обмінюватися малими об’ємами даних, що рідко змінюються, між засобами управління vSphere і гостьовою операційною системою, де встановлені VMware Tools. Наприклад, там може зберігатися статус гостьової ОС та її агента, інформація про інвентар та інше. Об’єкт vSphere DataSets переміщується разом із ВМ, навіть коли вона змінює інстанс vCenter Server.
6. Керування ресурсами віртуального середовища
У VMware vSphere 7.0 Update 3 з’явилися функції vSphere Memory Monitoring and Remediation (vMMR). За допомогою vMMR можна стежити за роботою пам’яті в режимі Intel PMem Memory Mode і отримувати алерти, коли ESXi вичерпує пам’ять DRAM, що може призвести до падіння продуктивності сервера. У vSphere 8 продуктивність DRS істотно покращилася в разі, коли на хості є пам’ять PMEM, завдяки використанню статистики з пам’яті, що дає змогу ухвалити найкращі рішення з розміщення ВМ і уникнути ситуацій, у яких відбудеться втрата продуктивності, пов’язана з пам’яттю.
Також у vSphere 8 з’явилися Green Metrics, які відображають споживання енергії віртуальними машинами з точки зору енергоефективності віртуального датацентру.
Вони включають у себе:
power.capacity.usageSystem— як багато енергії витрачає хост на системні активності, що не належать до віртуальних машин.power.capacity.usageSystem— споживання енергії на режим простою (хост нічого не робить, просто ввімкнений).power.capacity.usageVm— скільки енергії хост витрачає безпосередньо на виконання віртуальних машин.
7. Безпека та комплаєнс
Тут з’явилися такі нововведення:
- Запобігання запуску недовірених бінарних файлів за замовчуванням, які не встановлені як VIB (налаштування execInstalledOnly).
- vSphere 8 не підтримує протоколи TLS 1.0 і TLS 1.1. Раніше в vSphere 7 їх було просто відключено, а тепер їх просто немає – все переведено на TLS 1.2.
- SSH Automatic Timeout – за замовчуванням сесія SSH відвалюється за таймаутом.
- Sandboxed Daemons – демони і процеси тепер працюють у пісочниці, де вони мають мінімум необхідних їм привілеїв для виконання своїх завдань.
Під час спроби встановити Trusted Platform Module (TPM) 1.2 сервер ESXi 8.0 відображає попередження під час встановлення або апгрейда, але не перешкоджає їм.
Детальніше про VMware vSphere 8 ви можете почитати за цим лінком. Також просто зараз уже доступна лабораторна робота VMware vSphere Distributed Services Engine Overview Hands-on Lab. Офіційний прес-реліз від VMware.
Доступність для скачування продуктів VMware Cloud Foundation+, VMware vSphere 8, VMware vSAN 8 і VMware Edge Compute Stack 2 очікується до 28 жовтня 2022 року.
Бажаєте використовувати інноваційні та сучасні технології? Зв’яжіться з нашими експертами вже сьогодні. Зателефонуйте нам за номером +38 (044) 277-23-23 або надішліть нам листа за адресою info@wiseit.com.ua, і ми детальніше розповімо вам про рішення VMware, так їх переваги.