NVME Raid – We Need To Go Deeper, или что там на глубине. GPU over NVME, с водяным охлаждением
Для ЛЛ: несвязный набор ссылок про что-то душное.
Как пелось в одной песне -
We're going down, down, all the way down
We're heading deeper down
going down > Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
Все началось с того, что мне прислали очередную ссылку на разговор в российской майнинг-группе. Некий юзер начал плакать – как так, у меня NVME не дает в raid больше 100к IOPS, как страшно жить, ведь отдельный Samsung обещает :
Samsung 980 Pro SSD Random Write 4K QD32 Up to 1,000,000 IOPS
Samsung 990 PRO - while 4TB even higher random read speed of up to 1,600K IOPS.
Samsung обещает. Не забывая про то, что там стоит памяти 4 гб - Samsung 4GB Low Power DDR4 SDRAM
Но есть нюанс.
Давать то дает, но не под постоянной нагрузкой, и поэтому для бизнес-задач с нагрузкой 24*7 не годится – будут непредсказуемые падения скорости, когда контроллер решит заняться внутренними операциями.
Дальнейшая дискуссия между сторонами показала, что ни ноющему, ни основному составу майнинг-группы не понятно, зачем ему нужно именно столько, и куда он будет их девать.
Я, в свою очередь, очень удивился – откуда у людей руки растут. Пошел спросил результаты тестов у других коллег на одиноких NVME, без всяких железных raid. Seq WR, все такое.
Блок 4к, зеркало, очередь 16 , 100% чтение – 1600к IOPS
Блок 4к, зеркало, очередь 16 , 70/30 чтение – 850k IOPS на чтение, 350k IOPS на запись
Блок 64к, зеркало, очередь 16 , 100% чтение – 650к IOPS
Блок 64к, зеркало, очередь 16 , 70/30 – 250k / 100 k IOPS
Блок 64к, зеркало, очередь 16 , 100% запись – 150 k IOPS
Результаты, конечно, не показательны - разве что для того, чтобы было с чего разговор начинать. Значимо (в 1.5 раза) влияет и число потоков на файл (точнее, соотношение числа ядер процессоров и потоков на файл – как пишут в руководствах, In general it is recommended to use 1 CPU for testing and use the same number of threads), и количество файлов, точнее используемых в тесте разделов, и тонкие или толстые диски, и так далее.
В тестах выше был MS Server 2019, это тоже имеет значение – в MS Server 2025 обещали улучшить работу с NVME
Чтение по теме:
Use DISKSPD to test workload storage performance
Windows Server 2025 Storage Performance with Diskspd
Command line and parameters
Customizing tests
Best Practices Guide for Using the DiskSpd Performance Test Tool
Performance benchmarking with Microsoft Diskspd on Nutanix
На все это намазывается не только размер блоков, но и число выделяемых дескрипторов\очередей \прочего (внутри СХД, внутри системы, внутри везде, как тех же буферных кредитов – от которых можно получить Slow-Drain), особенно если у вас не локальные диски, а СХД.
И все равно в реальном мире можно нарваться на, цитата:
Setup: Dorado 18000, iSCSI, ESXi 7.0.3 (2x25Gb)На виртуальном диске 100 ГБ запускаю нагрузку FIO 70% read, IO Size 32 KB, вижу на datastore и на dorado одинаковый Read IO Request Size 32 KB.
На виртуальном диске 1024 ГБ тот же тест, та же нагрузка. На ВМ вижу 32 KB, на Datastore уже 25-26 KB на чтение. Запись идёт так же 32 KB. На Dorado соответственно тоже видно на чтение блок стал 25-26 KB.
Решение:
Причина мультипликации IO и несоответствия размеров блоков установлена!Проблема возникает при превышении объёма в 32 ТБ открытых VMDK файлов на хосте.
Накладные IO вызваны нехваткой кэша указателей блоков для открытых vmdk файлов.
Этот кэш необходим для быстрого обращения к открытым блокам VMFS без дополнительного доступа к метаданным из файловой системы.
При утилизации кэша больше 80% включается механизм вытеснения блоков указателей.
Вытесняются наименее активные блоки указатели и включаются (с чтением метаданных с vmfs) новые блоки. Отсюда возникает полученный нами overhead, т.к. нагрузочное тестирование, что FIO, что vdbench запрашивает блоки хаотично и по всему объёму.
Размер кэша задаётся advanced параметром:
VMFS3.MaxAddressableSpaceTB = 32 - Maximum size of all open files that VMFS cache will support before eviction mechanisms kick in
Его максимальное значение 128. При установке 128 - проблема с накладными IO в тестах уходит. Можно для целей тестирования выставить его в 128.
Увеличение кэша ведёт к накладным расходам по памяти, при значении по умолчанию 32 используется 128 МБ памяти. При максимальном значении 128 используется 512 МБ оперативной памяти.
В прод нагрузке вряд ли стоит увеличивать этот кэш, но посмотреть по хостам можно занятые объёмы кэшей командой:
esxcli storage vmfs pbcache get
В реальной жизни нет нагрузки со 100% активными блоками, как в синтетических тестах. Если, к примеру, активны только 20% всех блоков открытых VMDK и их указатели, соответственно попадают в кэш, то мы сможем иметь 160 ТБ открытых VMDK на хосте, при этом активные блоки указателей по-прежнему кэшируются без особого снижения производительности.
Поэтому ответ на исходный вопрос
«Но хотя-бы 400k IOPS почему никак не вытаскиваются из одного сервера с 10 дисков-то?» -
простой.
Наймите специалиста, если сами не можете. Все вытаскивается.
Дальше мне стало интересно, что же используют чуть более богатые фирмы, которые могут себе позволить потратить денег.
Оказалось, достаточно много всего, но, как всегда – есть нюансы.
Пропустим ту часть, где обсуждается «зачем столько». Сын маминой подруги сказал что можно, и дальше по классике -
НЕТ ДЕНЕГ НЕТ
@
НЕТ Я АДМИН
@
Я НИЧЕГО В ЭТОМ НЕ ПОНИМАЮ
@
ЭТО ГОСКОНТОРА ВЗЯЛИ МЕНЯ
Проблема применимости, про нее не стоит забывать.
Если у вас хотя бы 3-4 сервера с дисками, то зачем вам локальный RAID при наличии S2D и vSAN? Что с S2D, что с vSAN на 6-8 серверов можно получить 1-5 миллионов IOPS на чтение блоком 4к, при этом имея (с оговорками) и erasure coding, и, для S2D, ReFS Mirror-accelerated parity, и Data Deduplication, и в vSAN тоже много чего есть, и будет больше.
Но, к делу.
Что может выдать контроллер Broadcom MegaRAID 9670W-16i ? Посмотрим.
Broadcom MegaRAID 9670W-16i RAID Card Review.
Выглядит неплохо – до 240 SAS/SATA, до 32 NVME. Но, как только дело доходит до записи, все становится не так неплохо: для RAID 10 – Optimal
4KB Random Reads (IOPs) - 7,006,027
4KB Random Writes (IOPs) - 2,167,101
Но, есть нюанс.
Broadcom MegaRAID 9670W-16i - Storage controller (RAID) - 16 Channel - SATA 6Gb/s / SAS 24Gb/s / PCIe 4.0 (NVMe) 05-50113-00 – 1500$.
В соседнем тексте упомянули
Adaptec 3258upc32ix2s Cc 3258upc32ix2s Smartraid - 2000$. Тоже не очень дешевое решение для старого сервера.
Хотите быстрее? Нет препятствий патриотам. Только отечество не наше:
With a single SupremeRAID™ card, users can achieve extraordinary results, boasting up to 28M IOPS and 260GB/s. Supporting up to 32 native NVMe drives, it empowers exceptional NVMe/NVMeoF performance while enhancing scalability, server lifespan, and cost-effectiveness.
Supermicro and SupremeRAID™ Data Protection Solution
Performance results with SupremeRAID™ software version 1.5 on SupremeRAID™ SR-1010
2 миллиона IOPS в R5 на запись, пожалуйста.
Performance results with SupremeRAID™ software version 1.5 on SupremeRAID™ SR-1010
Но, есть нюанс.
Graid SupremeRAID GRAID-1000 - 2600 $.
Graid SupremeRAID SR-1010 - 4000 $.
Не хотите карту? Нет проблем, Xinnor xiRAID.
Производительности это решение дает достаточно – до 65/8 миллионов IOPS (Xinnor xiRAID установил новый рекорд производительности среди NVMe-массивов с PCIe 5.0 SSD от Kioxia).
Говорившие «врети!» Graid даже убрали свой отчет с сайта – вот он был:
A Comparative Analysis: SupremeRAID™ NVMe® & NVMe-oF™ RAID vs Xinnor xiRAID Software RAID,
и вот его не стало.
Однако, забрать его успели сюда - Graid GPU-powered RAID card outperforms Xinnor software, картинки сами смотрите, читайте. И читайте, если интересно:
https://xinnor.io/blog/performance-guide-pt-1-performance-ch...
https://xinnor.io/blog/performance-guide-pt-2-hardware-and-s...
https://xinnor.io/blog/performance-guide-pt-3-setting-up-and-testing-raid/
Причем тут GPU?
Да при том. Graid SupremeRAID™ SR-1010 – это RTX A2000 (Ampere), и ее еще 70 ватт сверху, к и так не холодным NVME и CPU.
Вы, конечно, спросите, зачем это все?
И правильно сделаете. Идут такие решения, и подобное для тех, кому слишком дорого взять Nvidia DGX (Deep GPU Xceleration).
Дело не только в «дорого».
Набор для начинающих «по взрослому» - Nvidia DGX GB200 NVL72:
120 киловатт.
1.4 тонны.
Водяное охлаждение.
На 1 (одну) стойку.
Поэтому Equinix уже год рассказывает, какие они молодцы, и они на самом деле молодцы – столько электричества подвести, и столько тепла вывести, это вам не стойки по 5 киловатт на луч продавать.
У кого же денег не просто много, а неприлично много, и так знают те три слова, что я узнал в сегодня лет: weka, vastdata, vast.ai.
WEKA Data Platform for NVIDIA DGX BasePOD with H100
WEKA NVIDIA DGX A100 Systems (BasePOD)
The VAST Data Platform
Теперь там еще и Cosmos.
Концовка.
Тут должна быть какая-то не скомканная концовка, но я ее так и не придумал.
