Теоретичні основи VMware Virtual SAN 6.5

Теоретичні основи VMware Virtual SAN 6.5

У цій статті я намагався розкрити призначення VMware Virtual SAN, принципи її роботи, вимоги, можливості та обмеження даної системи, основні рекомендації щодо її проектування.


Концепція Virtual SAN

VMware Virtual SAN (далі vSAN) є розподіленою програмною СГД (SDS) для організації гіпер-конвергентної інфраструктури (HCI) на базі vSphere. vSAN вбудований в гіпервізор ESXi і не вимагає розгортання додаткових сервісів і службових ВМ. vSAN дозволяє об'єднати локальні носії хостів в єдиний пул зберігання, що забезпечує заданий рівень відмовостійкості і надає свій простір для всіх хостів і ВМ кластера. Таким чином, ми отримуємо централізоване сховище, необхідне для розкриття всіх можливостей віртуалізації (технології vSphere), без необхідності впровадження і супроводу виділеної (традиційної) СГД.

vSAN запускається на рівні кластера vSphere, достатньо запустити відповідний сервіс в управлінні кластером і надати йому локальні носії хостів кластера - в ручному або автоматичному режимі. vSAN вбудований в vSphere і жорстко прив'язаний до неї, як самостійний продукт SDS, здатний працювати поза інфраструктури VMware, існувати не може.

Аналогами і конкурентами vSAN є: Nutanix DSF (розподілене сховище Нутанікс), Dell EMC ScaleIO, Datacore Hyper-converged Virtual SAN, HPE StoreVirtual. Всі ці рішення сумісні ні тільки з VMware vSphere, але і з MS Hyper-V (деякі і з KVM), вони припускають установку і запуск на кожному хості HCI службової ВМ, необхідної для функціонування SDS, в гіпервізор вони не вбудовуються.

Важливою властивістю будь-якої HCI, в т. ч. VMware vSphere + vSAN, є горизонтальна масштабованість і модульність архітектури. HCI будується і розширюється на базі ідентичних серверних блоків (хостів або вузлів), що об'єднують обчислювальні ресурси, ресурси зберігання (локальні носії) і мережеві інтерфейси. Це може бути commodity-обладнання (сервери x86, в т. ч. брендові), що поставляється окремо, або вже готові еплаєнси (наприклад, Nutanix, vxRail, Simplivity). Комплексне ПЗ (наприклад, vSphere + vSAN + засоби _ оркестрування _ VMware) дозволяє створити на базі цих блоків програмно-визначуваний ЦОД (SDDS), що включає середовище віртуалізації, SDN (програмно-визначувана мережа), SDS, засоби централізованого управління та автоматизації/оркестрування. Звичайно, не можна забувати про необхідність виділеного фізичного мережевого обладнання (комутатори), без якого неможлива взаємодія між хостами HCI. При цьому для організації мережі доцільно використовувати leaf-spine архітектуру, оптимальну для ЦОД.

vSAN піднімається на рівні кластера хостів ESXi під управлінням vCenter і надає розподілене централізоване сховище хостам даного кластера. Кластер vSAN може бути реалізований в 2х варіантах:

  • Гібридний - флеш-накопичувачі використовуються як кеш (cache layer), HDD забезпечують основну місткість сховища (capacity layer).
  • All-flash - флеш-накопичувачі використовуються на обох рівнях: cache и capacity.

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

Порівнюючи vSAN з традиційними зовнішніми СГД слід зазначити, що:

  • vSAN не вимагає організації зовнішнього сховища та виділеної мережі зберігання;
  • vSAN не вимагає нарізки LUN-ів і файлових куль, презентування їх хостам і пов'язаної з цим налаштування мережевої взаємодії; після активації vSAN відразу стає доступною всім хостам кластера;
  • передача даних vSAN здійснюється за власним пропрієтарним протоколом; стандартні протоколи SAN/NAS (FC, iSCSI, NFS) для організації та роботи vSAN не потрібні;
  • адміністрування vSAN здійснюється тільки з консолі vSphere; окремі засоби адміністрування або спеціальні плагіни для vSphere не потрібні;
  • не потрібен виділений адміністратор СГД; налаштування та супровід vSAN здійснюється адміністратором vSphere.

Носії і дискові групи

На кожному хості кластера vSAN має бути мінімум по одному кеш-носію і носію даних (capacity або data disk). Дані носії всередині кожного хосту об'єднуються в одну або кілька дискових груп. Кожна дискова група включає тільки один кеш-носій і один або кілька носіїв даних для постійного зберігання.

Носій, відданий vSAN і доданий до дискової групи, утилізується повністю, його не можна використовувати для інших завдань або в декількох дискових групах. Це стосується як кеш-носія, так і capacity дисків.

vSAN підтримує тільки локальні носії, або диски, з'єднані з DAS. Включення в пул зберігання vSAN сховищ, підключених за SAN/NAS, не підтримується.

Об'єктне сховище

vSAN - це об'єктне сховище, дані в ньому зберігаються у вигляді «гнучких» (flexible) контейнерів, званих об'єктами. Об'єкт зберігає всередині себе дані або мета-дані, розподілені по кластеру. Нижче перелічено основні різновиди об'єктів vSAN (створюються окремо для кожної ВМ):

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

Керування зберіганням даних на vSAN здійснюється за допомогою механізму SPBM (Storage Policy Based Management), під впливом якого знаходяться всі сховища vSphere починаючи з версії 6. Політика зберігання визначає кількість допустимих відмов (Number of failures to tolerate), метод забезпечення відмовостійкості (реплікація або erasure coding) і кількість страйпів для об'єкта (Number of disk stripes per object). Задана політикою кількість страйпів визначає кількість носіїв даних (capacity), за якими буде розмазаний об'єкт.

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

vSAN допускає зміну політики зберігання для об'єктів на-гарячу, без зупинки роботи ВМ. При цьому в фоні запускаються процеси реконфігурації об'єктів.

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

Witness і кворум

Свідок (witness) - це службовий компонент, який не містить корисних даних (тільки метадані), його розмір дорівнює 2-4МБ. Він виконує роль тайбрейкера при визначенні живих компонентів об'єкта в разі відмови.

Механізм обчислення кворуму в vSAN працює наступним чином: Кожен компонент об'єкта отримує певну кількість голосів (votes) - 1 і більше. Кворум досягається і об'єкт вважається «живим» якщо доступна його повна репліка і більше половини його голосів.

Такий механізм обчислення кворуму дозволяє розподілити компоненти об'єкта по кластеру таким чином, що в деяких випадках можна обійтися без створення свідка. Наприклад, під час використання RAID-5/6 або страйпінгу на RAID-1.

Virtual SAN datastore

Після включення сервісу vSAN в кластері vSphere з'являється однойменне сховище (datastore), на весь кластер vSAN воно може бути тільки єдиним. Завдяки механізму SPBM, описаному вище, в рамках єдиного сховища vSAN кожна ВМ або її диск може отримати необхідний її рівень сервісу (відмовостійкість і продуктивність) шляхом прив'язки до потрібної політики зберігання.

vSAN datastore доступне всім вузлам кластера, незалежно від наявності у хоста локальних носіїв, включених в vSAN. При цьому хостам кластера можуть бути доступні сховища (datastore) інших типів: VVol, VMFS, NFS.

vSAN datastore підтримує Storage vMotion (гаряча міграція дисків ВМ) зі сховищами VMFS/NFS.

У рамках одного сервера vCenter можна створювати кілька кластерів vSAN. Підтримується Storage vMotion між кластерами vSAN. При цьому кожен хост може бути учасником тільки одного кластера vSAN.

Сумісність vSAN з іншими технологіями VMware

vSAN сумісна і підтримує більшість технологій VMware, в т. ч. потребують загального сховища, зокрема: vMotion, Storage vMotion, HA, DRS, SRM, vSphere Replication, снапшоти, клони, VADP, Horizon View.

vSAN не підтримує: DPM, SIOC, SCSI reservations, RDM, VMFS.

Апаратні вимоги vSAN

Вимоги до пристроїв зберігання

Носії, контролери, а також драйвери і firmware повинні бути сертифіковані під vSAN і відображатися у відповідному аркуші сумісності VMware (секція Virtual SAN в VMware Compatibility Guide).

Як storage-контролер може використовуватися SAS/SATA HBA або RAID-контролер, вони повинні функціонувати в режимі passthrough (диски віддаються контролером як є, без створення raid-масиву) або raid-0.

Як кеш-носії можуть використовуватися SAS/SATA/PCIe -SSD і NVMe носії.

Як носії даних можуть використовуватися SAS/SATA HDD для гібридної конфігурації і всі перелічені вище типи флешу (SAS/SATA/PCIe -SSD і NVMe) для all-flash конфігурації.

Вимоги до ОЗУ та ЦПУ

Обсяг пам'яті вузла визначається кількістю і розміром дискових груп.

Мінімальний обсяг ОЗП хосту для участі в кластері vSAN - 8ГБ.

Мінімальний обсяг ОЗП хосту, необхідний для підтримки максимальної конфігурації дискових груп (5 дискових груп по 7 носіїв даних), дорівнює 32ГБ.

vSAN утилізує близько 10% ресурсів процесора.

Вимоги до мережі

Вибраний адаптер 1Гбіт/с для гібридної конфігурації

Вибраний або спільно використовуваний адаптер 10Гбіт/с для all-flash конфігурації

Слід дозволити трафік мультикаст у підмережі vSAN

Завантажувальні носії

Для завантаження вузлів з vSAN можуть використовуватися локальні USB або SD-носії, а також SATADOM. Перші 2 типи носіїв не зберігають логи і трейси після перезавантаження, оскільки їх запис здійснюється на RAM-диск, а останній зберігає, тому рекомендується використовувати SATADOM-носії SLC-класу, що володіють більшою живучістю і продуктивністю.

Параметри налаштувань vSAN 6.5

Максимум 64 хости на кластер vSAN (і для гібриду і для all-flash)

Максимум 5 дискових груп на вузол

Максимум 7 capacity-носіїв на дискову групу

Не більше 200 ВМ на хост і не більше 6000 ВМ на кластер

Не більше 9000 компонентів на вузол

Максимальний розмір диска ВМ - 62ТБ

Максимальна кількість носіїв у страйпі на об'єкт - 12

Технологічні особливості VMware Virtual SAN

Планування складу кластера vSAN

Мінімальна кількість хостів кластера vSAN визначається числом допустимих відмов (параметр Number of failures to tolerate в політиці зберігання) і визначається за формулою: 2*number_of_failures_to_tolerate + 1.

За умови відпрацювання 1 відмови vSAN допускає створення 2х- і 3х- вузлових кластерів. Об'єкт і його репліка розміщуються на 2х хостах, на 3м розміщується свідок. При цьому з'являються такі обмеження:

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

Це обумовлено тим, що ребилдити або мігрувати дані просто нікуди, немає додаткового вільного хосту. Тому оптимально якщо в кластері vSAN використовується від 4х хостів.

Правило 2 * number _ of _ failures _ to _ tolerate + 1 застосовне тільки для використання дзеркалювання для забезпечення відмовостійкості. При використанні Erasure Coding воно не працює, докладно це описано нижче в розділі «Забезпечення відмовостійкості».

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

Незбалансований кластер (різна конфігурація дискових груп хостів) підтримується, але змушує миритися з наступними недоліками:

  • неоптимальна продуктивність кластера;
  • нерівномірна утилізація ємності хостів;
  • відмінності в процедурах супроводу хостів.

Допускається розміщення ВМ з сервером vCenter на vSAN датасторі, однак це призводить до ризиків, пов'язаних з управлінням інфраструктурою при проблемах з vSAN.

Планування кешу vSAN

Рекомендується планувати розмір кешу з запасом для можливості розширення capacity рівня.

У гібридній конфігурації 30% кешу виділяється на запис і 70% на читання. All-flash конфігурація vSAN використовує всю ємність кеш-носіїв на запис, кешу на читання не передбачено.

Рекомендований розмір кешу повинен бути не менше 10% від реальної ємності ВМ до реплікації, тобто враховується корисний простір, а не реально зайнятий (з урахуванням реплікації).

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

У all-flash налаштування дискова група не може використовувати більш 600ГБ ємності встановленого флеш-носія, при цьому решта простору не буде простоювати, оскільки кешовані дані будуть записуватися по всьому обсягу носія циклічно. В all-flash vSAN доцільно використовувати під кеш флеш-носії з більшою швидкістю і часом життя порівняно з capacity-носіями. Використання під кеш носіїв обсягом більш 600ГБ не вплине на продуктивність, проте продовжить термін служби даних носіїв.

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

Забезпечення відмовостійкості

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

  • Number of failures to tolerate - кількість допустимих відмов, визначає кількість хостів кластера відмову яких зможе пережити ВМ.
  • Failure tolerance method - метод забезпечення відмовостійкості.

vSAN пропонує 2 методи забезпечення відмовостійкості:

  • RAID-1 (Mirroring) - повна реплікація (дзеркалювання) об'єкта з розміщенням реплік на різних хостах, аналог мережевого raid-1. Дозволяє пережити кластеру до 3-х відмов (хостів, дисків, дискових груп або мережевих проблем). Якщо Number of failures to tolerate = 1, створюється 1 репліка (2 екземпляри об'єкта), простір, що реально займається ВМ або її диском на кластері, в 2 рази більше її корисної ємності. Якщо Number of failures to tolerate = 2, маємо 2 репліки (3 екземпляри), реально займаний обсяг в 3 рази більше корисного. Для Number of failures to tolerate = 3, маємо 3 репліки, займаємо простір в 4 рази більше корисного. Цей метод відмовостійкості неефективно використовує простір, проте надає максимальну продуктивність. Можна використовувати для гібридної та all-flash конфігурації кластера. Мінімально необхідна кількість хостів 2-3 (для відпрацювання 1 відмови), рекомендований мінімум - 4 хости, дає можливість ребилда при відмові.
  • RAID-5/6 (Erasure Coding) - при розміщенні об'єктів проводиться обчислення блоків чітності, аналог мережевого raid-5 або -6. Підтримується тільки all-flash конфігурація кластера. Дозволяє кластеру відпрацювати 1 (аналог raid-5) або 2 відмови (аналог raid-6). Мінімальна кількість хостів для відпрацювання 1 відмови дорівнює 4, для відпрацювання 2-х відмов дорівнює 6, рекомендовані мінімуми 5 і 7, відповідно, для можливості ребилда. Даний метод дозволяє досягти значної економії простору кластера в порівнянні з RAID-1, проте призводить до втрати продуктивності, яка може виявитися цілком прийнятною для багатьох завдань, враховуючи швидкість all-flash. Так, у випадку 4-х хостів і допуску 1 відмови корисний простір, що займається об'єктом при використанні Erasure Coding, буде становити 75% від його повного обсягу (для RAID-1 маємо 50% корисного простору). У разі 6-ти хостів і допуску 2-х відмов корисний простір, що займається об'єктом при використанні Erasure Coding, буде становити 67% від його повного обсягу (для RAID-1 маємо 33% корисного простору). Таким чином, RAID-5/6 в даних прикладах виявляється ефективніше RAID-1 з використання місткості кластера в 1,5 і 2 рази, відповідно.

Нижче представлено розподіл даних на рівні компонент кластера vSAN при використанні RAID-5 і RAID-6. C1-С6 (перший рядок) - компоненти об'єкта, A1-D4 (кольорові блоки) - блоки даних, P1-Р4 і Q1-Q4 (сірі блоки) - блоки парності.

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

Нижче наведено таблицю з мінімальною і рекомендованою кількістю вузлів або доменів відмови для різних варіантів FTM/FTT:

Домени відмови

vSAN вводить поняття доменів відмови (fault domain) для захисту кластера від відмов на рівні серверних стійок або кошиків, які логічно групуються в ці домени. Включення цього механізму призводить до розподілу даних для забезпечення їх відмовостійкості не на рівні окремих вузлів, а на рівні доменів, що дозволить пережити відмову цілого домену - всіх згрупованих в ньому вузлів (наприклад, серверної стійки), оскільки репліки об'єктів будуть обов'язково розміщуватися на вузлах з різних доменів відмови.

Кількість доменів відмови обчислюється за формулою: number of fault domains = 2 * number of failures to tolerate + 1. vSAN мінімально вимагає 2 домену відмови, в кожному по 1 або кілька хостів, проте рекомендована кількість дорівнює 4, оскільки допускає можливість ребилда в разі відмови (2-3 домена не дають можливість ребилда, нікуди). Таким чином, метод підрахунку числа доменів відмови аналогічний, методу підрахунку кількості хостів для відпрацювання потрібного числа відмов.

В ідеалі в кожному домені відмови, має бути однакова кількість хостів, хости повинні мати ідентичну конфігурацію, простір одного домену рекомендується залишати порожнім для можливості ребилда (наприклад, 4 домену з відпрацюванням 1 відмови).

Механізм доменів відмови працює не тільки при Дзеркалюванні (RAID-1), але і для Erasure Coding, в цьому випадку кожен компонент об'єкта повинен розміщуватися в різних доменах відмови і формула розрахунку числа доменів відмовляється: мінімум 4 домени для RAID-5 і 6 доменів для RAID-6 (аналогічно розрахунку числа хостів для Erasure Coding).

Дедупликація і стиснення

Механізми дедупликації і стиснення (ДіС) підтримуються тільки в all-flash конфігурації і можуть бути включені тільки на кластер vSAN в цілому, вибіркове включення для окремих ВМ або дисків за допомогою політик не підтримується. Використовувати тільки одну з цих технологій теж не вийде, тільки обидві відразу.

Увімкнення ДіС змушує об'єкти автоматично страйпитися на всі диски в дисковій групі, це дозволяє уникнути ребалансування компонентів і виявляти збіги блоків даних з різних компонент на кожному диску в дисковій групі. При цьому зберігається можливість задати старайпінг об'єктів вручну на рівні політик зберігання, в т. ч. за межі дискової групи. При включенні ДіС недоцільно на рівні політики резервувати простір під об'єкти (параметр Object Space Reservation, товсті диски), оскільки це не дасть приросту продуктивності і негативно позначиться на економії простору.

ДіС проводиться після підтвердження операції запису. Дедупликація проводиться до вивантаження даних з кешу над однаковими блоками 4К всередині кожної дискової групи, між дисковими групами дедупликація не проводиться. Після дедупликації і перед вивантаженням даних з кешу проводиться їх компресія: якщо реально стиснути 4K до 2К або менше, то компресія проводиться, якщо ні, то блок залишається незжатим, щоб уникнути невиправданих накладних витрат.

У дедуплікованому і стислому вигляді дані знаходяться тільки на рівні зберігання (capacity), це приблизно 90% обсягу даних кластеру. При цьому накладні витрати на ДіС становлять близько 5% загальної місткості кластера (зберігання метаданих, хешів). У кеші дані знаходяться в звичайному стані, оскільки запис в кеш здійснюється набагато частіше, ніж в постійне сховище, відповідно накладні витрати і деградація продуктивності від ДіС в кеші були б значно більше, ніж бонус від оптимізації його відносно малої ємності.

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

Простір, що займається ланцюжками снапшотів, також оптимізується за рахунок ДіС.

Страйпінг об'єктів і кількість компонентів

Параметр політики зберігання Number of disk stripes per object визначає кількість окремих capacity-носіїв, за якими будуть розподілені компоненти однієї репліки об'єкта (диска ВМ). Максимальне значення цього параметра, а значить максимальна довга страйпа, яку підтримує vSAN, дорівнює 12, в цьому випадку репліка об'єкта розподіляється на 12 носіїв. Якщо вказана довжина страйпу перевищує кількість носіїв дискової групи, значить репліка об'єкта буде розтягнута на кілька дискових груп (швидше за все всередині 1 хосту). Якщо вказана довжина страйпу перевищує кількість носіїв хосту, значить репліка об'єкта буде розтягнута на кілька хостів (наприклад, всі носії 1 хосту і частина носіїв іншого).

За замовчуванням, довжина страйпу задається рівною 1, це означає, що страйпінг не проводиться і репліка (при розмірі до 255ГБ) розміщується на 1 носії у вигляді 1 компоненти.

Теоретично страйпінг може дати приріст продуктивності за рахунок розпаралелювання в/в, якщо носії на які страйпиться об'єкт не перевантажені. Страйпінг об'єкта на кілька дискових груп, дозволяє розпараллелити навантаження не тільки за capacity-носіям, а й утилізувати ресурси кеш носіїв залучених дискових груп. VMware рекомендує залишати «число страйпів на об'єкт» рівним 1, як вказано за замовчуванням, і не страйпити об'єкти, за винятком тих випадків, коли страйпінг допустимий, необхідний і реально дозволить підвищити продуктивність. У загальному випадку вважається, що страйпінг відчутного приросту продуктивності дати не зможе. У гібридних конфігураціях ефект від страйпінгу може бути позитивним, особливо при інтенсивному читанні, коли виникають проблеми з потраплянням в кеш. Потоковий запис також може бути прискорений за рахунок страйпінгу, в т. ч. в all-flash конфігурації, оскільки можуть утилізуватися кілька кеш-носіїв і розпаралелюється витіснення даних на постійні носії.

Слід враховувати, що страйпінг призводить до значного зростання кількості компонент кластера. Це важливо для кластерів з великою кількістю ВМ і об'єктів, коли ліміт компонент на кластер (9000) може бути вичерпаний.

Слід враховувати, що максимальний розмір 1 компонента об'єкта дорівнює 255ГБ, це означає, що якщо об'єкт має великий розмір, його репліка буде автоматично розбита на число компонентів, кратне 255. У такому випадку, незалежно від політики страйпінгу компоненти репліки будуть рознесені по декількох носіях, якщо їх дуже багато (більше, ніж носіїв на хості або в кластері, наприклад, створюємо диск 62ТБ), то на носій може потрапити по кілька компонент одного об'єкта.

Планування місткості кластера vSAN

При плануванні розміру сховища кластера vSAN необхідно враховувати, що реально займане простір з урахуванням використовуваних методів відмовостійкості (дзеркало або EC) і кількості допустимих відмов (від 1 до 3х) може значно перевищувати корисну місткість кластера. Також необхідно враховувати вплив методів оптимізації використання простору (EC і ДіС).

Слід враховувати виділення простору під swap-файли (розмір ОЗП кожної ВМ) і зберігання снапшотів.

При заповненні ємності vSAN на 80% починається ребалансування кластру - це фоновий процес, що перерозподіляє дані по кластеру і викликає значне навантаження, краще не допускати його настання. Близько 1% простору йде при форматуванні носіїв кластера під файлову систему vSAN (VSAN-FS). Невелика частка простору йде на метадані ДіС (5%). Тому VMware рекомендує проектувати кластер vSAN із запасом ємності 30%, для того щоб не доводити до ребалансування.

Вибір storage-контролера

vSAN рекомендує і підтримує використання декількох storage-контролерів на одному хості. Це дозволяє збільшити продуктивність, місткість і відмовність на рівні окремих вузлів. При цьому жодна vSAN ready node не містить більше 1 storage-контролера.

Рекомендується вибирати контролери з максимально великою довжиною черги (не менше 256. Рекомендується використовувати контролери в режимі pass-through, коли диски безпосередньо презентуються гіпервізору. vSAN підтримує використання контролерів в режимі raid-0, однак їх застосування призводить до додаткових маніпуляцій при супроводі (наприклад, при заміні носія). Внутрішній кеш контролера рекомендується відключати, якщо неможливо, то налаштувати 100% на читання; фірмові режими акселерації контролерів також необхідно відключати.

Відпрацювання відмов

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

Відмова кеш-носія призводить до ребилда його дискової групи цілком. Ребилд може бути вироблений на той же хост (якщо на ньому є ще дискові групи і вільне місце) або на інші хости.

На випадок відмови хосту для ребилда краще передбачити як мінімум 1 вільний хост, якщо потрібно відпрацювати кілька відмов, то і вільних хостів має бути кілька.

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

Якщо компонент (втрата мережі, відмова мережевої карти, відключення хосту, відключення диска) відсутнє (тимчасове відключення з можливістю відновлення), то vSAN починає його ребілдити відкладено (за замовчуванням, через 60 хв).

Природно, умовою ребилда є наявність вільного місця в кластері.

Після відмови (носія, дискової групи, хосту, втрати мережі) vSAN зупиняє в/в на 5-7 секунд поки оцінює доступність втраченого об'єкта. Якщо об'єкт знаходиться, в/в відновлюється.

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

Контрольні суми

Типово vSAN здійснює підрахунок контрольних сум для контролю цілісності об "єктів на рівні політик зберігання. Обчислення контрольних сум проводиться для кожного блоку даних (4KB), їх перевірка здійснюється як фоновий процес на операціях читання і для даних, що залишаються холодними протягом року (scrubber). Цей механізм дозволяє виявляти пошкодження даних з програмних і апаратних причин, наприклад, на рівні пам'яті і дисків.

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

Обчислення контрольних сум можна відключити на рівні політик зберігання. Частоту запуску scrubber-а (перевірка блоків до яких не було звернень) при бажанні можна змінити в додаткових налаштуваннях (параметр VSAN.ObjectScrubsPerYear) і виконувати таку перевірку частіше, ніж 1 раз на рік (хоч раз на тиждень, але виникне допнавантаження).

Планування мережі vSAN

vSAN підтримує nic-teaming з агрегуванням портів і балансуванням навантаження.

До версії 6.5 включно vSAN вимагає підтримки мультикаст-трафіку у своїй мережі. Якщо в одній підмережі розміщується кілька кластерів vSAN, необхідно призначити їх хостам різні мультикаст-адреси, для поділу їх трафіку. Починаючи з версії 6.6 vSAN не використовує мультикаст.

Під час проектування мережі vSAN рекомендується закладати leaf-spine архітектуру.

vSAN підтримує NIOC для виділення гарантованої смуги пропускання під свій трафік. NIOC може бути запущений тільки на distributed vSwitch, vSAN дає можливість їх використання в будь-якій редакції vSphere (вони входять в ліцензію vSAN).

vSAN підтримує використання Jumbo-фреймів, однак VMware вважає приріст продуктивності від їх використання незначним, тому дає такі рекомендації: якщо мережа їх вже підтримує - можна використовувати, якщо ні, то для vSAN вони зовсім необов'язкові, можна обійтися без них.

Приклад розміщення об'єктів у кластері vSAN

Вище були описані склад, структура і принципи розміщення об'єктів і компонентів в кластері vSAN, методи забезпечення відмовостійкості, використання політик зберігання.

Тепер розгляньмо, як це працює на простому прикладі. У нашому розпорядженні кластер vSAN з 4-х хостів в all-flash конфігурації. На зображенні нижче умовно представлено, як у цьому кластері будуть розміщуватися 3 диски ВМ (Диски).

ВДиск-1 був прив'язаний до політики зберігання з відпрацюванням 1 відмови (Failure To Tolerate (FTT) = 1) і використанням Erasure Coding (Fault Tolerance Method (FTM) = EC). Таким чином, об'єкт вДиск-1 був розподілений в системі у вигляді 4 компонент, по 1 на хост. Дані (data) Диска всередині цих компонент записано разом з обчисленими значеннями чіткостей (parity), фактично це мережевий RAID-5.

Вдиск-2 і вДиск-3 були прив'язані до політ

Image