найцікавіше з арсеналу vSphere 6



Сьогодні ми торкнемося шосту версію сімейства продуктів VMware vSphere для серверної віртуалізації. У цьому релізі компанії не тільки вдалося збільшити кількісні показники віртуальних машин (пам'ять, процесори), але і додати інші цікаві новини.

Почнемо ми з змін, які торкнулися технології Fault Tolerance (FT), яка позиціонувалася як посилена версія vSphere High Availability для бізнес-критичних серверів. Ідея була в тому, щоб в мить ока забезпечити перемикання на резервну ВМ при неполадках з основною машиною.

Щоб домогтися бажаного результату, VMware реалізувала постійну реплікацію процесорних інструкцій і вмісту пам'яті віртуальних машин, об'єднаних в FT. Такий кластер дуже сильно допомагає при збоях віртуальної машини або гіпервізора, однак не захищає від програмних збоїв на рівні гостьової системи.

Покращений механізм Fault Tolerance повинен вирішити і цю проблему. Тепер підтримується 4 процесора і до 64 ГБ пам'яті на машину. Збільшення числа vCPU зажадало перегляду синхронізації процесорів і пам'яті. Якщо раніше використовувався механізм повторення інструкцій на резервній ВМ, то тепер була впроваджена нова схема Fast Checkpointing, яка виконує інструкції одночасно на обох віртуальних машинах.

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

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

Раніше не можна було перенести віртуальну машину на інший керуючий сервер vCenter, тепер же така можливість з'явилася, при цьому додатково відбудеться коректна передача метаданих (налаштування HA, правила DRS і т. д.).

Також з'явилася можливість переносити машину між віртуальними комутаторами vSS (Standard switch) і vDS (Distributed switch) в різних комбінаціях. Винятком тут буде лише варіант переходу від vDS до vSS – vDS містить додаткові метадані, які стандартним комутатором просто не будуть сприйматися.

Ще було неможливо здійснити перенесення віртуальної машини в значно віддалений дата-центр. Зараз можна, оскільки підтримуються маршрутизовані канали із затримками до 100 мс. Правда доведеться вручну змінити IP-адреси переміщуються машин, якщо в цільовому дата-центрі інша адресація.

Що стосується бібліотеки дистрибутивів, то вона стала глобальною. У шостій версії vSphere нам запропоновано досить цікавий інструмент Content Library. Ідея проста: об'єднати між усіма vCenter репозиторії потрібних дистрибутивів. Таким чином, повністю відпадає необхідність шукати десь забутий образ ОС або шаблон для нового стенду.

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

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

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

Коли в якості сховища використовуються колективні зовнішні пристрої, datastore практично завжди будується з одного великого LUN. При цьому такий великий розділ є найменшим логічним елементом у СГД. На невиртуализированных системах деталізація на рівні LUN була цілком прийнятною, так як на кожен том припадав лише один сервер.

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

Подібна архітектура продемонструвала цілий ряд проблем. QoS і інші політики обслуговування могли бути застосовані лише на рівні дискового тому. Таким чином, будь-яке переміщення «гарячих» даних відбувалося б для всіх віртуальних машин на цьому сховищі. До недавнього часу користувачам VMware доводилося вдаватися до опцій на зразок DRS, щоб якось розподіляти навантаження на системи зберігання.

Для вирішення проблеми VMware змінила підхід до роботи з дисками, реалізувавши технологію віртуальних томів. В першу чергу, на нових томах інакше зберігається сама віртуальна машина. Кожен диск розміщується в невидимому для адміністратора логічному каталозі на СГД. Причому не просто файл на розділі VMFS – для кожного віртуального диска VMDK створюється щось на зразок власного ЛУН.



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

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

Залишається відкритим питання: як связаны VAAI API для блокових пристроїв, який покращував продуктивність VMFS, делегуючи частину операцій дискового масиву, і VVol? При роботі з віртуальними томами хост ESXi контролює не тільки потік даних, але і керуючий канал до масиву. Таким чином, VVol виглядає як більш просунуте розширення інтерфейсу VAAI NAS.

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

Завдяки VVol системи зберігання тепер знають про наявність віртуальних дисків і можуть створювати знімки, клони і занулять певні VMDK.
Що стосується VAAI NAS і VVol, то, на відміну від блочного варіанти, всі функції VAAI NAS надаються через виклики RPC з допомогою плагіна від виробника СГД. VVol розширює цю модель набором VASA API, що дозволяє передати сховища управління всіма операціями vSphere.

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

Резюмуємо, які нові функції надала VMware в продукті vSphere:

  • Був поліпшений механізм Fault Tolerance: з'явилася нова схема Fast Checkpointing, а також додані технології миттєвих знімків ВМ і нормального бекапа через інтерфейс VADP.
  • Поліпшення в інструменті vMotion: з'явилася можливість перенесення машини між віртуальними комутаторами і на інший керуючий сервер vCenter.
  • Поява інструменту Content Library, що об'єднує між усіма vCenter репозиторії потрібних в роботі дистрибутивів.
  • Технологія VVol, яка змінила підхід до розміщення віртуальних машин.
  • У новій версії свого флагманського продукту VMware додала чимало серйозних нововведень і зробила значний крок на шляху до віртуалізації критичних додатків.
P. S. Інші матеріали з нашого блогу на Хабре:



Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.