`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Будуємо NVMe-сховища Storage Spaces

+22
голоса

Для того, щоби створити продуктивне сховище у окремому сервері, не потрібні апаратні RAID-контролери. Зокрема, базова технологія Microsoft Storage Spaces дозволяє ефективно і «безкоштовно» скористатися перевагами NVMe у Windows-серверах.

Будуємо NVMe-сховища Storage Spaces | entry

Storage Spaces – технологія Microsoft керування просторами зберігання даних, основа віртуалізації сховищ її ОС. Абстрагування охоплює три основних об’єкти: фізичні носії, пули зберігання, віртуальні диски - які, власне, і є просторами зберігання (storage spaces).

Накопичувачі збирають у пули. Ті забезпечують агрегацію сховищ, еластичне розширення ємності та делеговане адміністрування. З пулів створюють простори зберігання. Для Windows простір зберігання виглядає як звичайний диск, якому призначається розмір і тип відмовостійкості.

Будуємо NVMe-сховища Storage Spaces | entry

Створюють сховища за допомогою графічного інтерфейсу GUI або командного рядку PowerShell. Останній дає відчуття свободи налаштувань та розуміння їх впливу на продуктивність зберігання даних.

Типи просторів зберігання

Спочатку формують пул з набору фізичних носіїв. Підтримуються накопичувачі і сховища всіх відомих інтерфейсів: SATA, SAS, NVME, iSCSI, FC. Творчі люди можуть зібрати пул навіть з USB-флешек або заміксувати в одному пулі диски різної продуктивності.

Будуємо NVMe-сховища Storage Spaces | entry

Щойно пул створено, питання «а на якому саме диску розміщено мій файл?» стає недоречним -  абстракція пулу поглинула і розмила у собі фізичні носії. Доступну ємність пулу ділять між віртуальними дисками (просторами зберігання). Дані у сховищах зберігаються згідно з призначеним типом захисту. Простір зберігання не є томом RAID і не розміщується на окремому диску. Натомість по носіям розподіляються нарізані по 256 мегабайт фрагменти даних, так звані «плитки» (slabs).

Віртуальні дискі бувають трьох типів:

  • Simple. Служить підвищенню продуктивності, без захисту файлів від збою диска. Дані розподіляються по дисках пулу, швидкість послідовних і випадкових робочих навантажень росте з кількістю дисків. Оскільки він не забезпечує стійкості до відмов носіїв, його доля – обслуговувати тимчасові дані, які можна легко відтворити - наприклад, проміжні файли рендерингу відео або кешів.
  • Mirror. Використовується для підвищення продуктивності та захисту файлів від збою диска шляхом збереження кількох копій. Дані розподіляються на фізичних дисках. Подвійне дзеркало (two-way mirror) створює дві копії файлів і допускає збій одного диска, потрійне дзеркало (three-way mirror) допускає втрату двох дисків. Для подвійного дзеркала потрібно принаймні два диски, а для потрійного — не менше п’яти. Дзеркальні віртуальні диски забезпечують найкращу продуктивність і стійкість для робочих навантажень Hyper-V.
  • Parity. Цей тип відмовостійкості зберігає копії даних разом із інформацією про парність. Дані та парності розподіляються по фізичних дисках пулу. Потрібні принаймні три носії, щоб захистити дані від відмови одного диска (single parity) і сім - пережити відмову двох дисків (dual parity). Простори з парністю підходять для послідовних робочих навантажень, таких як резервне копіювання, архівування, зберігання потокового мультимедіа, наприклад музики та відео. Не варто користуватись ними для навантажень випадкового доступу – сильно страждає продуктивність запису.

Приклад створення віртуального диску Simple з PowerShell:

Будуємо NVMe-сховища Storage Spaces | entry

Магія PowerShell

Графічний інтерфейс GUI дозволяє зібрати носії у пул і вибрати тип віртуального диска. Решта параметрів призначаються за замовченням, у режимі «давай зробимо це по-швидкому». Натомість, PowerShell дає розуміння причинно-наслідкового зв'язку налаштувань з продуктивністю. Як працює «параметричне  лібертаріанство», пояснимо на прикладі NumberOfColumns та Interleave.

NumberOfColumns це кількість cтовпців, фізичних дисків, по яким розподіляється запис, рівними смугами (stripes). Interleave або чергування ширина смуги запису даних, які зберігатимуться на кожному диску. Чим більше стовпців призначено простору зберігання, тим вища продуктивність послідовного запису/відтворення.

Очевидно, що NumberOfColumns не може бути більшим за кількість дисків у пулі (може бути меншим). «Автопілот» GUI сам масштабує кількість стовпців, після створення віртуального диска її змінити не можна. Налаштовується цей параметр лише за допомогою PowerShell.

Будуємо NVMe-сховища Storage Spaces | entry

Будуємо NVMe-сховища Storage Spaces | entry

При розширенні пула потрібно враховувати не тільки мінімально необхідну кількість дисків, але й кількість стовпців. Наприклад, Simple диск із чотирма стовпцями можна розширити мінімум чотирма дисками, а подвійне (two-way) дзеркало із чотирма стовпцями – вісьмома дисками (кількість стовпців множиться на кількість копій даних).   

За замовченням Interleave дорівнює 256 кілобайт. Тобто, у кожному стовпці Storage Spaces зберігає 256K даних. Якщо, наприклад, у вас є вісім дисків у пулі зберігання і ви хочете записати 4 мегабайти даних, кожен диск отримує дві смуги по 256K (4M / 256K (смуга) / 8 стовпців = 2 смуги по 256K на стовпець).

Підлаштування під робочі навантаження

Підсистема зберігання обробляє I/O прикладного ПЗ із властивим тому розміром блоку даних. Наприклад, Microsoft SQL Server і Microsoft Exchange використовують відносно невеликі блоки (8K-32K). Послідовні робочі навантаження (як у медійних програмах або резервуванні даних) оперують блоками значно більших розмірів (512K-1 М). Загалом, IOPs, пропускна здатність і розмір блоку даних пов’язані: малий розмір блоку дає високі IOPs з низькою пропускною здатністю, тоді як великий розмір блоку призводить до високої пропускної здатності з низьким IOPS.

З точки зору продуктивності значення Interleave, яке використовується простором зберігання, має бути принаймні таким же великим, як типовий I/O робочого навантаження. Операції, які перевищують цей розмір, розбиваються на кілька смуг, перетворюючи один запис на кілька записів. Це знижує продуктивність.

PowerShell – створити Parity віртуальний з Interleave 128KB і NumberOfColumns 3

New-VirtualDisk -StoragePoolFriendlyName "pool" -ProvisioningType Thin -Interleave 128KB -FriendlyName "TestParity" -Size 4TB -ResiliencySettingName Parity -NumberOfColumns 3

Allocation Unit Size

Наведені міркування справедливі у сферичному вакуумі Storage Spaces. У реальному житті доведеться працювати з розділом NTFS, з його власними уявленнями про прекрасне і про те, на скільки частин і якого розміру кришити дані. Ані простір зберігання, ані пул не мають уявлення про «фізичну» природу запису даних. Про це має подбати «постачальник» тома, а над томом знаходиться розділ.

Будуємо NVMe-сховища Storage Spaces | entry

Allocation Unit Size (AUS) — це мінімальний розмір кожного запису у розділ NTFS. AUS за замовчуванням встановлюється як 4К для дисків менше 16 ТБ і 8К для дисків 16 ТБ і більше.

Форматування дисків з розміром блоку 4К (а не, скажімо, 512K) є компромісом між швидкістю та ефективністю зберігання. При AUS 512К тисяча мікро-файлів розміром 1К займатимуть на диску 512 мегабайт - замість очікуваного одного мегабайту. З іншого боку, якщо зберігати лише мультимедійні файли, такі як фотографії та відео, розмір одиниці розподілу NTFS вплине набагато менше, ніж якщо у вас є безліч невеликих файлів.

При Interleave 256К і AUS 4K кожен запит на запис має виділяти простір на розділі шматками по 4K, потім це має бути перетворено на фрагменти розміром 256K. Зрозуміло, що варто зберігати симетрію між NumberOfColumns, Interleave та AUS. Краще дотримуватись рівності AUS = NumberOfColumns (з даними) * Interleave. Для віртуальних дисків Single Parity формула набуває вигляду AUS = (NumberOfColumns-1) * Interleave, оскільки в один з стовпців обчислюється та записується контрольна сума.

Прояснивши природу налаштувань просторів зберігання, перейдемо до матеріалістичного світу.

NVMe у серверах

Вибір носіїв суттєво впливає на продуктивність сервера. Найвищий потенціал продуктивності мають NVMe SSD - завдяки прямому підключенню до шини PCIe та центральних процесорів, без контролерів-посередників. За менших затримок звернення та вищої  швидкості передачі даних, технологія  NVMe ще й масштабована. Вона покладається на лінії PCIe, а не інтерфейс контролера, а з кожним поколінням PCIe показники поліпшуються. NVMe SSD завжди буде швидше, ніж SATA SSD, незважаючи на те, що обидва використовують пам’ять NAND для зберігання даних.

Серверні платформи з підтримкою одного-двох десятків NVMe SSD стають буденністю. Самі накопичувачі зрівнялись за ціною з SATA SSD. Для шукачів продуктивності вибір носіїв очевидний. Дослідимо особливості різних типів сховищ Storage Spaces, побудованих на NVMe SSD.

Тестова платформа

Основний корпоративний стандарт NVMe SSD - це U.2/U.3 (2.5” NVMe). У типову сучасну платформу 1U вміщується до 12 накопичувачів з гарячою заміною, у 2U – до 24. До кожного мають бути  підведені чотири законні лінії PCIe. Просторам зберігання Storage Spaces не потрібні ніякі контролери на шині, джерела обмежень продуктивності.

Конфігурація нашого тестового стенду:

ASUS RS700-E10-RS12 / 2 х CPU Intel Xeon Gold 6326 / 16 x 16ГБ DDR4-3200 RDIMM Micron / 480GB M.2 NVMe SSD Micron 7450 Pro / 4 x 3.2ТБ U.3 Micron 7450 Max / Windows Server Standard

Будуємо NVMe-сховища Storage Spaces | entry

 

Будуємо NVMe-сховища Storage Spaces | entry

Використовувалась FIO (версія fio-3.36-x64) – еталонна утиліта вимірювання продуктивності дискового вводу-виводу, що генерує безліч варіантів профілів запитів і опцій для точного налаштування параметрів.

Читання/запис з довільним доступом тестувались з розміром блоку 4K, послідовні – з блоком 1M. Диски NVMe можуть обробляти велику кількість операцій I/O, тож запускали 32 завдання (потоки) – відповідно до числа фізичних ядер у тестовому сервері. Встановлювалась глибина черги QD=64 для тестів з довільним доступом і QD=32 для послідовних операцій.

Що тестували

Досліджувалась продуктивність таких просторів зберігання:

  • Два NVMe SSD у подвійному дзеркалі (two-way mirror)
  • Чотири NVMe SSD у подвійному дзеркалі (two-way mirror)
  • Чотири NVMe SSD у просторі з парністю (parity) з налаштуваннями GUI за замовченням  -  їх позначено default parity на діаграмах нижче
  • Чотири NVMe SSD у просторі з парністю (parity) з налаштуваннями вручну («оптимальними») - з оптимізацією взаємозв'язку AUS, NumberOfColumns та Interleave, позначено optimal parity на діаграмах.

Вимірювались IOPs та Latency з наступними налаштуваннями FIO

IOPS

  • FIO: 4k block size 100% random reads

fio --name=4krandomreads --rw=randread --direct=1 --ioengine=windowsaio --bs=4k --numjobs=32 --iodepth=64 --size=4G --runtime=600 --group_reporting >> 4krandomreads.txt

  • FIO: 4k block size 100% random writes

fio --name=4krandomwrites --rw=randwrite --direct=1 --ioengine=windowsaio --bs=4k --numjobs=32 --iodepth=64 --size=4G --runtime=600 --group_reporting >> 4krandomwrites.txt

  • FIO: 1M block size 100% sequential reads

fio --name=1Mseqreads --rw=read --direct=1 --ioengine=windowsaio --bs=1M --numjobs=32 --iodepth=32 --size=4G --runtime=600 --group_reporting >> 1Mseqreads.txt

  • FIO: 1M block size 100% sequential writes

fio --name=1Mseqwrites --rw=write --direct=1 --ioengine=windowsaio --bs=1M --numjobs=32 --iodepth=32 --size=4G --runtime=600 --group_reporting >> 1Mseqwrites.txt

Latency

  • FIO: 4k block size 100% random reads

fio --name=4krandomreads --rw=randread --direct=1 --ioengine=windowsaio --bs=4k --numjobs=32 --iodepth=1 --size=4G --runtime=600 --group_reporting >> 4kLrandomreads.txt

  • FIO: 4k block size 100% random writes

fio --name=4krandomwrites --rw=randwrite --direct=1 --ioengine=windowsaio --bs=4k --numjobs=32 --iodepth=1 --size=4G --runtime=600 --group_reporting >> 4kLrandomwrites.txt

  • FIO: 1M block size 100% sequential reads

fio --name=1Mseqreads --rw=read --direct=1 --ioengine=windowsaio --bs=1M --numjobs=32 --iodepth=1 --size=4G --runtime=600 --group_reporting >> 1MLseqreads.txt

  • FIO: 1M block size 100% sequential writes

fio --name=1Mseqwrites --rw=write --direct=1 --ioengine=windowsaio --bs=1M --numjobs=32 --iodepth=1 --size=4G --runtime=600 --group_reporting >> 1MLseqwrites.txt

Результати

Для початку ми протестували одиночний диск – переконатися, що показники корелюють з паспортними параметрами Micron 7450. Перевірка коректності інструменту і параметрів тестування не завадить.

Перевірили, що продуктивність простору зберігання Simple росте з додаванням накопичувачів:

Будуємо NVMe-сховища Storage Spaces | entry

 

Будуємо NVMe-сховища Storage Spaces | entry

 

Продуктивність у довільному доступі коротким блоком 4К на чотирьох типах просторів зберігання:

Будуємо NVMe-сховища Storage Spaces | entry

 

Будуємо NVMe-сховища Storage Spaces | entry

 

Продуктивність послідовних операцій блоком 1М:

Будуємо NVMe-сховища Storage Spaces | entry

 

Будуємо NVMe-сховища Storage Spaces | entry

 

Затримки звернення коротким блоком 4К:

Будуємо NVMe-сховища Storage Spaces | entry

 

Будуємо NVMe-сховища Storage Spaces | entry

 

Затримки звернення у послідовному доступі блоком 1М:

Будуємо NVMe-сховища Storage Spaces | entry

 

Будуємо NVMe-сховища Storage Spaces | entry

 

Тестування дзеркала c NumberOfColumns=2 (аналог RAID10) порівняно з NumberOfColumns=1 (аналогом RAID1) не показало суттєвого приросту швидкості:

Будуємо NVMe-сховища Storage Spaces | entry

Короткі висновки

  • Очевидна висока ефективність та практична доцільність дзеркальних логічних дисків Storage Space;
  • При збільшенні кількості дисків у пулі росте показник IOPS і зменшуються затримки;
  • Логічні диски Single Parity мають катастрофічно низькі показники довільного запису;
  • Оптимізація взаємозв'язку AUS, NumberOfColumns та Interleave (optimal parity на діаграмах) підвищує продуктивність Single Parity за замовчуванням (default parity на діаграмах) хіба що в задачах лінійного запису;
  • Якщо лінійну швидкість запису правильним підбором параметрів ще можна врятувати, то випадковиму запису нічого не допоможе. Тому Single Parity від Storage Space на практиці не застосовується.

Життєздатне поєднання

NVMe-сховища під керуванням Storage Spaces у автономних Windows-серверах - доступний та дієвий варіант продуктивного зберігання даних. Знаєш природу своїх даних, можеш розібратися в налаштуваннях - отримаєш гарні результати малою кров'ю.

 

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+22
голоса

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT