Теоретичні основи 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 працює наступним чином. Кожний компонент об'єкта отримує певне число голосів (1 і більше). Кворум досягається і об'єкт вважається «живою» якщо ми маємо повну репліку даних, або доступно більше половини (50%) компонентів об'єкта або його голосів.

Такий механізм обчислення кворуму дозволяє розподілити компоненти об'єкта по кластеру таким чином, що можна обійтися без створення свідка.

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

vSAN datastore доступно всім хостам кластера, незалежно від наявності у хоста локальних носіїв, включених в vSAN. При цьому хостів кластера можуть бути доступні сховища (сховище даних) інших типів: 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 конфігурації.

Вимоги до ОЗУ і ЦПУ
Об'єм пам'яті хоста визначається кількістю і розміром дискових груп. Мінімальний об'єм ОЗП хоста, необхідний для підтримки максимальної конфігурації дискових груп (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ГБ ємності встановленого флеш-носія, тому в таких кластерах недоцільно використовувати кеш-носії об'ємом понад 600-800ГБ, оскільки вільний простір буде простоювати. В all-flash vSAN доцільно використовувати під кеш флеш-носії з більшою швидкістю і часом життя.

Такий підхід до організації кеша в 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. Cn – компоненти об'єкта, Dn – блоки даних, Pn і Qn – блоки парності.



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 здійснюють обчислення контрольних сум для контролю цілісності об'єктів. Обчислення контрольних сум проводиться для кожного файлу, їх перевірка здійснюється як фоновий процес на операціях читання/запису і для даних, що залишаються холодними протягом року. Даний механізм дозволяє виявляти пошкодження даних з програмним і апаратним причин, наприклад, на рівні пам'яті і дисків.

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

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

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

vSAN вимагає включення мультикаст-трафіку в мережі. Якщо в одній підмережі розміщується кілька кластерів 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 були прив'язані до політиків зберігання з відпрацюванням 1 відмови (FTT = 1) і віддзеркаленням (FTM = Mirror). Уточнимо, що вДиск-2 має корисний розмір менше 255ГБ і для нього заданий розмір страйпа за замовчуванням (Number of disk stripes per object = 1). Поетом об'єкт вДиск-2 був розміщений на кластері у вигляді 3х компонент на різних вузлах: дві дзеркальні репліки і свідок (witness).

вДиск-3, в даному випадку, має корисний розмір 500ГБ і для нього заданий розмір страйпа за замовчуванням. Оскільки 500ГБ більше 255ГБ, vSAN автоматично розбиває одну репліку об'єкта вДиск-3 на 2 компоненти (Компонент1-1 і Компонент1-2) і кладе на Хост-1. Їхні репліки (Компонент2-1 і Компонент4-2) розміщуються на хостах 2 і 4, відповідно. В даному випадку свідок відсутня, оскільки алгоритм розрахунку кворуму з використанням голосів дозволяє обійтися без нього. Необхідно відзначити, що vSAN розмістила вДиск-3 на просторі кластера саме таким чином автоматично і на свій розсуд, руками це поставити не вийде. З тим же успіхом вона могла розмістити ці компоненти на вузлах по-іншому, наприклад, одну репліку (Компонент1-1 і Компонент1-2) на Хост-4, другу на Хост-1 (Компонент2-1) і Хост-3 (Компонент4-2). Або могла виділити під репліки 2 хоста (2 компоненти на Хост-1 і 2 компоненти на Хост-3), а на третій розмістити свідка (Хост-4), це вже компонент 5, а не 4.

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

Розміщення вДиск-2 теж могло бути іншим, загальна умова – компоненти різних реплік і свідок (якщо він є) повинні знаходитися на різних хостах, це умова відпрацювання відмови. Так, якщо б вДиск-2 мав розмір трохи менше 1,9 ТБ, то кожна з його реплік складалася б з 8 компонент (одна компонента не більше 255ГБ). Такий об'єкт можна було б розмістити на тих же 3х хостах (8 компонентів 1 репліки на Хості-1, 8 компонентів 2 репліки на Хості-2, свідок на Хості-3. Або vSAN міг би розмістити його без свідка, розподіливши 16 компонентів обох реплік по всім 4 хостів (без перетину різних реплік на одному хості)

Рекомендації по ефективному використанню простору
Просто наводжу таблицю з рекомендацій VMware:



Підтримка режиму Stretched Cluster
vSAN підтримує роботу в режимі Stretched Cluster (розтягнутий кластер) з охопленням 2х географічно рознесених майданчиків (сайтів), при цьому загальний пул зберігання vSAN також розподіляється між сайтами. Обидва сайту є активними, у разі виходу з ладу одного з майданчиків, кластер використовує сховище і обчислювальні потужності залишився сайту для відновлення зруйнованих сервісів.

Докладний розгляд особливостей Stretched Cluster виходить за рамки даної публікації.

Корисні посилання

Документація по vSAN 6.5 на VMware vSphere 6.5 Documentation Center — pubs.vmware.com/vsphere-65/index.jsp#com.vmware.virtualsan_container.doc/GUID-BA963AF2-5D07-488E-939E-7DEAC01BC4A0.html

Керівництво по дизайну і масштабування vSAN 6.2 — www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vsan/virtual-san-6.2-design-and-sizing-guide.pdf

Керівництво по дизайну мережі vSAN 6.2 — www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vsan/vmware-virtual-san-network-design-guide.pdf

Технології оптимізації ємності vSAN 6.2 — www.vmware.com/files/pdf/products/vsan/vmware-vsan-62-space-efficiency-technologies.pdf

Страйпинг в vSAN — blogs.vmware.com/virtualblocks/2016/09/19/vsan-stripes

Блок VMware за vSAN — blogs.vmware.com/virtualblocks/products/virtualsan
Джерело: Хабрахабр

0 коментарів

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