Будуємо мicтке продуктивне ZFS-сховище

ZFS - просунута файлова система і менеджер дисків в одній особі, набір інструментів для створення систем зберігання даних і управління ними. Достойність ZFS багаторазово і детально описані.

Пройшовши через корпоративні поглинання, розщеплювання співтовариств і портування на різні платформи, ZFS до цього дня є основою багатодискових топологій. Вона з унікальним охопленням: від програмних складок "для будинку" до монументальних реалізацій ніби Oracle ZFS Storage Appliance. Наш інтерес лежить посередині: силами ПЗ і оптимізацією начинки підвищити продуктивність місткої системи зберігання.

Прикладом комерційної ОС на ZFS може служити Open - E JovianDSS. Запитайте, навіщо платити комусь, якщо є платформи з відкритим початковим кодом? Для того, щоб використати чужий багаторічний досвід вичавлювання продуктивності, спростити налаштування, уникнути залежності від "настроювача" і отримати доступ до розширеної функціональності - як кластеризація зберігання.

Місткість

Коли ZFS створювалася, не було SSD, не було NVMe. Йшлося про надійне зберігання великих об'ємів даних на механічних дисках. Поява твердотілих накопичувачів додала засобів управління продуктивністю, але складують об'ємні дані як і раніше на HDD. Внутрішня топологія сховищ на механічних дисках однакова. Не потрібно сприймати системи зберігання як монолітні пристрої. При усіх відмінностях їх контролерів і зовнішніх інтерфейсів, дискових кошиків і експандерів, сам HDD- масив - це набір дисків, який адресується по SAS. Він може бути частиною моноблочної СХД, а може - автономним контейнером, JBOD, що підключається по SAS до хосту, що управляє.

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

Продуктивність.

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

Ми зупинимося на таких джерелах продуктивності систем зберігання ZFS як оперативна пам'ять і SSD. Дві основні характеристики продуктивності введення/виведення - IOPS і Throughput. Об'єднання HDD в змозі забезпечити високу пропускну спроможність, але великих IOPS від механічних дисків не доб'єшся, інтенсивне навантаження I/O потрібно парирувати SSD. Справа посилюється фрагментацією даних на дисках. ZFS належати до класу систем COW (copy - on - write), нова інформація записується не за старим місцем, а в новий блок, разом з покажчиками. Це дозволяє відстежувати зміни та відкочуватися на минулі стани даних у разі збоїв. Це ж створює певні проблеми: швидкість запису у ZFS прив'язана до запасу вільних суміжних блоків. У міру заповнення пулу залишок тане, дані фрагментуються, а показники IOPS запису довільного доступу стають важливіше за потенційну пропускну спроможність потокового запису.

ARC, L2ARC, ZIL, SLOG

Кешувати читання ARC (Adaptive Replacement Cache) переносить в RAM копії нещодавно прочитаних блоків. На продуктивність запису кеш читання ARC безпосередньо не впливає, хоча швидкодія може трохи вирости через те, що з дисків знімається частина навантаження читання. Другий рівень ARC або L2ARC є розширенням ARC на SSD - вони дешевші за оперативну пам'ять. Що витісняється з ARC файл переміщається в L2ARC.

Усі запити на запис потрапляють в RAM. Є дві основні категорії операцій записи - синхронні (sync) і асинхронні (async). У більшості робочих навантажень запис асинхронний. Файлова система збирає усі звернення, синхронні та асинхронні, в транзакційні групи TXG і порціями скидає на диски, потоком, зменшуючи фрагментацію даних. З точки зору клієнта асинхронний запис - дуже швидкий процес: попадання запиту в швидкісну оперативну пам'ять сервера зберігання рівносильно запису на його диски (хоча насправді дані TXG переносяться в основне сховище із затримкою - за умовчанням, кожні п'ять секунд).

У будь-який момент дані мають бути спроможні. Завжди є ризик, що при аварії по живленню енергозалежна пам'ять втратить агрегат TXG, що спричинить розузгодження даних. На допомогу приходить механізм синхронного запису, хай і коштом додаткових витрат. Синхронні запити пишуться відразу на постійні носії. Коли від клієнта приходить запит на синхронний запис, він потрапляє в TXG разом з асинхронними, але сервер не дасть підтвердження його успішного завершення, поки не запише його в журнал ZIL (ZFS intention Log), разом з метаданими. Під журнал за умовчанням виділяється частина основного пулу в сховищі. Очевидно, тримати ZIL на HDD небажано, через їх повільного відгуку.

ZIL розміщують на окремому від основного облаштуванні зберігання - SLOG (двох SSD в дзеркалі). Вибирають SSD c мінімальними затримками, максимальною продуктивністю довільного доступу і великим ресурсом перезапису. ZFS оперативно вносить синхронні записи в журнал ZIL і залишає їх же в RAM. Звідти, у складі агрегатів TXG вони скидаються в сховище разом із звичайними асинхронними запитами на запис. У нормальному режимі роботи ZIL записується і ніколи більше не читається. Якщо відбувається збій ZFS, дані і метадані прочитуються з ZIL при перезапуску та імпорті пулу, об'єднуються в групи TXG і наново фіксуються в первинному сховищі.

У середовищі з великою кількістю синхронних записів, SLOG побічно прискорює асинхронний запис і   читання яке не кешується - адже вивантаження записів ZIL в окремий пристрій зі швидким відгуком означає меншу конкуренцію за IOPS на основному масиві.

Часовий проміжок між скиданнями даних TXG в основне сховище невеликий, отже, під ZIL/SLOG потрібні зовсім невеликі SSD. Зате вони - важливий об'єкт гонитви за продуктивністю.

Стисло про головне

Скільки ставити оперативній пам'яті в сервер, що управляє, залежить від загального об'єму зберігання, плану кешування, (не) використання дедупликації. Без неї нормою вважається 1-2gb оперативній пам'яті на 1tb даних. З нею - удвічі більше. Під L2ARC радять виділяти приблизно п'ятикратний об'єм RAM, наприклад, 256gb LARC2 при 64gb RAM. Місткість носіїв SLOG під ZIL можна оцінити, виходячи з пропускної спроможності мережевих інтерфейсів, об'єму даних, які вони потенційно можуть прийняти за п'ять секунд. Це лічені гігабайти.

Підіб'ємо підсумки

ARC кешує операції читання в RAM. Звідти вони витісняються в L2ARC на SSD - при ротації даних, або застосуваннями, що конкурують за оперативну пам'ять. ARC і L2ARC містять оновлювані копії даних основного сховища, як і належить кеш-памяти.

ZIL не являється кешем запису. Це область на постійних носіях, що виділяється під журнал операцій синхронного запису, - ті не можуть вважатися виконаними, просто потрапивши в енергозалежну RAM. За умовчанням, ZIL розміщується на основному сховищі. Усі в один голос рекомендують додати в систему пару SSD під SLOG - допоміжне сховище малої місткості, але зі швидким відгуком. SLOG дозволяє підняти продуктивність. Проте, первинне його завдання - допомогти відновити дані, які без нього були б загублені після збоїв живлення.

Практичне втілення

Спеціалізовані ОС, як Open - E JovianDSS, перетворюють стандартні платформи на сервери зберігання під критичні застосування: ваговиті бази даних, VDI або роздачу медійного контенту. Функціональність забезпечує програмне забезпечення, продуктивність і підгонку сховища під мережеве оточення - апаратна база і наслідування описаних принципів. Гонитва за місткістю і продуктивністю в модульному підході природним чином розкладається на оптимізацію "тіл" і "голів" окремо - благо одно до іншого підключається стандартним SAS і не зв'язує свободу дій.

Містке "тіло"

Зразковим можна рахувати сімейство Western Digital Ultrastar Data60 JBOD на 60 HDD. Вони продаються відразу з усіма дисками (NL SAS місткістю від 4 до 18tb) або частково заповнені - з 24 дисками з 60. Поступове додавання дисків в JBOD, а потім підключення наступного JBOD дає поетапне масштабування зберігання.

Механічним дискам в спеціалізованих JBOD комфортно - вони якісно гасять наведені вібрації та тримають робочу температуру усередині на добрий десяток градусів нижче, ніж стандартні серверні корпуси під велику кількість дисків. Менше трясіння і температура - довше життя HDD. Усі підсистеми та шляхи до дисків дубльовані. Велика кількість портів SAS дозволяє підключити JBOD до декількох хостів, а при необхідності - зонувати його. За умовчанням усі HDD видно усім ініціаторам, підключеним до будь-якого із зовнішніх портів. Можна згрупувати диски в зони, а зони приписати певним портам. Кожен диск зони буде видний тільки цей порт, і тільки хосту, підключеному до нього. Таблиця дозволів правиться через інтерфейс командного рядка CLI.

Продуктивна "голова"

В області "тіла" все більш-менш консервативно: стандарт SAS стабільний, хіба що помалу росте місткість дисків. На рівні "голови" є широке поле для творчості - адже під ZFS можна використати будь-які платформи, типи підключень внутрішніх носіїв і зовнішніх мережевих інтерфейсів.

Приклад зручної бази - ASUS RS500A - E10 - R12 під один процесор AMD EPYC 7xx2. Потенціал обчислювальної потужності (до 64 ядер CPU, до 2tb RAM) дозволяє обслуговувати сховища масштабу петабайту. У такий сервер можна поставити до 12 х U.2 (2.5" NVMe) SSD c гарячою заміною накопичувачів і підключити периферію PCIe Gen4 - наприклад, карти 200 Gigabit Ethernet.

Припустимо, ми вирішили розпочати зі зберігання півтори сотні терабайтів з перспективою розширення. В якості основного сховища підійде WD Ultrastar Data60 24 (60) x 8tb. Якщо не долучити дедупликацію, йому достатньо сервера, що керує,  з 16-ядерним AMD EPYC 7302p і 256gb RAM. Під L2ARC досить двох Western Digital Ultrastar SN640 U.2 SSDs місткістю 960gb (в дзеркало носії під кеш читання необов'язково ). Під ZIL/SLOG поставимо пару Intel Optane P4801x місткістю 100gb. Для підключення JBOD в сервері є SAS HBA із зовнішніми портами, LSI 9300-8e або 9305-16e.

Intel Optane на пам'яті 3d XPoint перевершує NAND SSD за усіма параметрами: швидкості відгуку, IOPS (особливо, при малій глибині черги запитів), пропускній спроможності, ресурсу. На 100gb Intel Optane P4801x можна записати 10.9 петабайт даних (60 DWPD). І це недорогий SSD - через його малу місткість (а нам більшого і не потрібно).

Така система зберігання продуктивна і масштабована по місткості: додаванням HDD в JBOD, RAM в сервер, SSD в L2ARC сервера.

All - flash

В "голові", що управляє, сконцентровані засоби підвищення продуктивності зберігання : багатоядерні CPU, багатоканальна пам'ять, диски NVMе (на пам'яті NAND і на пам'яті 3d XPoint - кому що), швидкісна периферія. Якщо потрібно забезпечити максимальну продуктивність на об'ємі зберігання в декілька десятків терабайт, можна обійтися просто масивом all - flash, без всяких JBOD і механічних дисків. Первинним сховищем послужить десяток U.2 (місткістю від 480gb до 7.68tb), L2ARC у варіанті all - flash взагалі не потрібний - читання з основного масиву і так швидке. ZIL/SLOG потрібний. 1u-монстру, що вийшов, ще піди, знайди конкурента. Чим менше вільного місця на дисках, тим більше годині йде на транзакції. При 50% заповнення місткості HDD вже можна побачити уповільнення. На рубежі 80% пора бити тривогу і додавати вільний дисковий простір.