Технології зберігання даних VMware vSphere 6. Частина 1 – Old School

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

VASA – vSphere API for Storage Awareness / Набір API для відстеження сховищ
VASA це набір API, що надається VMware і призначений для розробки провайдерів сховищ (storage providers) для інфраструктури vSphere. Storage provider-и це програмні компоненти, що надаються vSphere чи розроблювані 3-їй стороною, призначені для інтеграції (відстеження) сховищ (програмних і апаратних СГД) і фільтрів вводу-виводу (VAIO) з інфраструктурою vSphere.

Storage provider (VASA-провайдер) потрібен для того, щоб віртуальна інфраструктура:

  • отримувала інформацію про статус, характеристики і можливості СГД;
  • могла працювати з такими сутностями як Virtual SAN and Virtual Volumes;
  • могла взаємодіяти з фільтри вводу-виводу (VAIO).
Наявність відповідного VASA-провайдера надає зазначені вище можливості і дозволяє використовувати їх в політиках (SPBM). Якщо немає потрібного провайдера зберігання vSphere не бачить характеристик СГД, фільтрів VAIO, не може працювати з vVOL, відсутня можливість створити відповідні правила в політиках.

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

Вбудовані storage provider-и є компонентами vSphere і не вимагають реєстрації. Так, наприклад, провайдер для Virtual SAN автоматично реєструється при її розгортанні.

vSphere допомогою storage provider збирає інформацію про сховищах (характеристики, статус, можливості) і сервісах даних (фільтрах VAIO) у всій інфраструктурі, ця інформація стає доступною для моніторингу та прийняття рішень через vSphere Web Client.

Інформацію, збирану VASA-провайдерами, можна розділити на 3 категорії:

  • Можливості та сервіси сховища. Це як раз те, на основі чого формуються правила Common rules і Rules Based on Storage-Specific Data Services SPBM – можливості та сервіси, що надаються Virtual SAN, vVol і фільтрами вводу-виводу.
  • Стан сховища. Інформація про стан і подіях на боці сховищ, в т. ч. тривожні події, зміни конфігурації.
  • Інформація Storage DRS. Дана інформація дозволяє враховувати внутрішні процеси управління сховищами в роботі механізму Storage DRS.
Розробка VASA-провайдера для інтеграції продукту (3-й боку), зокрема СГД, з vSphere лягає на плечі вендора. Такі storage provider-и можуть бути встановлені практично на будь-якому вузлі інфраструктури за винятком сервера vCenter. Як правило, сторонні VASA-провайдери встановлюються на контролер СГД або виділений сервер.

До одного storage provider-одночасно можуть звертатися кілька серверів vCenter. Один vCenter може одночасно взаємодіяти з безліччю storage provider-ів (кілька масивів і фільтрів вводу-виводу).

VAAI — vSphere API for Array Integration / Набір API для інтеграції масиву
API даного типу можна розділити на 2 категорії:

  • Hardware Acceleration APIs. Призначені для прозорого перенесення навантажень по виконанню окремих операцій пов'язаних із зберіганням з гіпервізора на СГД.
  • Array Thin Provisioning APIs. Призначені для моніторингу простору на «тонких» розділах масивів для запобігання ситуацій з браком місця і виконання відкликання (невикористаного) простору.
Storage Hardware Acceleration (VAAI для Hardware Acceleration)
Даний функціонал забезпечує інтеграцію хостів ESXi і сумісних СГД, дозволяє перенести виконання окремих операцій з супроводу ВМ і сховища з гіпервізора (хоста ESXi) на масив (СГД), завдяки чому збільшується швидкість виконання даних операцій, при цьому знижується навантаження на процесор і пам'ять хоста, а також на мережу зберігання даних.

Storage Hardware Acceleration підтримується для блочних (FC, iSCSI) і файлових (NAS) СГД. Для роботи технології необхідно, щоб блочний пристрій підтримувало стандарт T10 SCSI або мало VAAI-плагін. Якщо блоковий масив підтримує стандарт T10 SCSI, то VAAI-плагін для підтримки Hardware Acceleration не потрібен, все запрацює безпосередньо. Файлові сховища вимагають наявності окремого VAAI-плагіна. Розробка VAAI-плагінів лягає на плечі виробника СГД.

В цілому VAAI для Hardware Acceleration дозволяють оптимізувати і перекласти на масив наступні процеси:

  • Міграція ВМ допомогою Storage vMotion.
  • Розгортання ВМ з шаблону.
  • Клонування ВМ або шаблонів ВМ.
  • Блокування VMFS та операції з метаданими для ВМ.
  • Робота з «товстими» дисками (блочний і файловий доступ, eager-zero диски).
Для блокових пристроїв Hardware Acceleration оптимізує операції:

  • Full copy (clone blocks або copy offload). Дозволяє масиву робити повну копію даних, уникаючи операцій читання-запису хостом. Дана операція скорочує час і мережеву навантаження при клонуванні, розгортанні із шаблону або міграції (переміщення диска) ВМ.
  • Block zeroing (write same). Дозволяє масиву обнуляти велика кількість блоків, що значно оптимізує створення дисків типу «eager zero thick» для ВМ.
  • Hardware assisted locking (atomic test and set — ATS). Дозволяє уникнути блокування LUN-а з VMFS (немає необхідності використовувати команду SCSI reservation) завдяки підтримці вибіркової блокування окремих блоків. Виключається втрата (знижується ймовірність втрати) продуктивності сховища при внесенні гіпервізором змін до метадані LUN з VMFS.
Пояснення
VMFS є кластерної ФС (файлова система) і підтримує паралельну роботу декількох хостів ESXi (гіпервізора) з одним LUN-ом (який під неї відформатований). На LUN-е з VMFS може размешаться безліч файлів ВМ, а також метадані. У звичайному режимі, поки не вносяться зміни в метадані, все працює паралельно, безліч хостів звертається в VMFS, ніхто нікому не заважає, немає ніяких блокувань.

Якщо Hardware Acceleration (VAAI) не підтримуються блоковим пристроєм, то для внесення змін в метадані VMFS яким-небудь хостом доводиться використовувати команду SCSI reservation, LUN при цьому передається в монопольне використання даного хосту, для інших хостів на момент внесення змін до метадані цей LUN стає недоступний, що може викликати відчутну втрату продуктивності.

Метадані містять інформацію про самому розділі VMFS та файли ВМ. Зміни метаданих відбуваються у разі: включення/вимикання ВМ, створення файлів ВМ (створення ВМ, клонування, міграція, додавання диска, створення снапшота), видалення файлів (видалення ВМ або дисків ВМ), зміна власника файлу ВМ, збільшення розділу VMFS, зміна розміру файлів ВМ (якщо у ВМ «тонкі» диски або використовуються снапшоти – це відбувається постійно).
Hardware Acceleration для VMFS не відпрацює і навантаження ляже на хост якщо:

  • VMFS розділи джерела і призначення мають різні розміри блоку
  • Файл джерело має формат RDM, файл призначення не-RDM
  • Вихідний файл «eager-zeroed-thick», файл «тонкий»
  • ВМ має снапшоти
  • VMFS розтягнута на кілька масивів
Для файлових СГД Hardware Acceleration оптимізує операції:

  • Full File Clone. Дозволяє клонувати файли ВМ на рівні пристрою NAS.
  • Reserve Space. Дозволяє резервувати простір для ВМ з «товстими» дисками (за замовчуванням NFS не лишає простір і не дозволяє робити «товсті» диски).
  • Native Snapshot Support. Підтримка створення снапшотов ВМ на рівні масиву.
  • Extended Statistics. Дає можливість побачити використання простору на масиві.


Multipathing Storage APIs — Pluggable Storage Architecture (PSA) / Набір API для мультипафинга
Для управління мультипафингом гіпервізор ESXi використовує окремий набір Storage APIs званий Pluggable Storage Architecture (PSA). PSA – відкритий модульний каркас (framework), що координує одночасну роботу безлічі плагінів мультипафинга (multipathing plugins – MPPs). PSA дозволяє виробникам розробляти (інтегрувати) власні технології мультипафинга (балансування навантаження і відновлення після збою) для підключення своїх СГД до vSphere.

PSA виконує наступні завдання:

  • Завантажує і вивантажує плагіни мультипафинга
  • Приховує від ВМ специфіку роботи плагінів мультипафинга
  • Направляє запити вводу-виводу MPP
  • Обробляє черзі вводу-виводу
  • Розподіляє смугу пропускання між ВМ
  • Виконує виявлення і видалення фізичних шляхів
  • Збирає статистику вводу-виводу
За замовчуванням ESXi використовує вбудований плагін мультипафинга VMware — Native Multipathing Plug-In (NMP). В цілому, NMP підтримує всі типи і моделі СГД сумісні з vSphere і вибирає алгоритм мультипафинга за замовчуванням в залежності від конкретної моделі.

NMP в свою чергу також є розширюваним модулем, який керує двома наборами модулів: Storage Type Array Plugins (SATPs), and Path Selection Plugins (Гаес). SATPs та Гаес можуть бути вбудованими плагінами VMware або розробками сторонніх виробників. При необхідності розробник СГД може створити власний MPP для використання в доповнення або замість NMP.

SATP відповідає за відновлення шляху пості збою (failover): моніторинг стану фізичних шляхів, інформування про зміну їх стану, перемикання з збійного шляху на робочий. NMP надає SATPs для всіх можливих моделей масивів, підтримуваних vSphere, і здійснює вибір відповідного SATP.

PSP відповідає за вибір фізичної шляху передачі даних. NMP пропонує 3 вбудованих варіанту PSP: Most Recently Used, Fixed, Round Robin. Базуючись на обраному для масиву SATP, модуль NMP робить вибір варіанту PSP за замовчуванням. При цьому vSphere Web Client дає можливість вибрати варіант PSP вручну.

Принцип роботи варіантів PSP:

  • Most Recently Used (MRU) – хост вибирає шлях який використовувався останнім (нещодавно). Якщо цей шлях стає недоступний, то хост переходить на альтернативний шлях. Повернення до первісного шляху після його відновлення не відбувається. Можливість завдання бажаного шляху відсутня. MRU – варіант за замовчуванням для більшості active-passive масивів.

  • Fixed – хост використовує бажаний шлях, який може бути заданий вручну, або вибирає перший робочий шлях, виявлений при завантаженні системи. Вручну заданий бажаний шлях зберігає свій статус навіть будучи недоступним, тому після його відновлення хост переключиться на нього назад. Якщо бажаний шлях явно не задано вручну і був обраний автоматично, то в разі недоступності переважним призначається дублюючий шлях і повернення до первісного шляху після його відновлення не буде. Fixed – варіант за замовчуванням для більшості active-active масивів.

  • Round Robin (RR) – хост використовує автоматичний алгоритм вибору шляху виконуючи ротацію активних шляхів для active-passive масивів, або ротацію всіх шляхів для active-active масивів. Як видно, RR може використовуватися для обох типів масивів і дозволяє виконувати балансування навантаження по шляхах для різних LUNов.
Спасибі за увагу, продовження слід.
Джерело: Хабрахабр

0 коментарів

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