Нужен ли Cache Vault для контроллеров Broadcom с массивами из SSD?
20.12.23
Некоторые из наших клиентов при подборе серверов настаивают на включении в состав модуля защиты кэш-памяти (CacheVault в случае Broadcom) в любых конфигурациях, в том числе all-flash, т.е. с массивами из SSD. Действительно ли это необходимо?
Write Through и Write Back
Немного теории. Большая часть аппаратных RAID-контроллеров поддерживают как минимум два режима работы кэша:
- Write Through. Данные пишутся в кэш контроллера и на накопители, при этом контроллер подтверждает завершение операции только после записи на накопители.
- Write Back. Контроллер подтверждает завершение операции сразу после записи в кэш. На накопители запись осуществляется после дополнительной оптимизации: изменение порядка выполнения в очереди, объединение нескольких операций.
Использование кэширования в режиме Write Back существенно увеличивает производительность случайного доступа на HDD — контроллер может отложить запись и/или объединить несколько небольших блоков. Это особенно актуально при записи в массивы RAID-5/6, где оптимальной является запись полного страйпа.
Аварийное отключение питания приводит к потере размещенных в DRAM данных, в худшем случае — к полной потере данных массива (например, в случае значительного повреждения структуры БД). При этом обеспечить бесперебойное питание сервера в целом (ИБП + дублирование БП) недостаточно — контроллер может потерять питание из-за собственного сбоя или выхода из строя материнской платы. Для сохранения содержимого DRAM кэша при аварийном отключении питания используется питание от батареи ионисторов в течение небольшого времени, необходимого для копирования данных на флеш-память.
Рекомендации вендора
Рекомендации Broadcom (ранее, до поглощения — Avago и LSI) можно обнаружить только в старом документе LSI MegaRAID Advanced Software Evaluation Guide V3.0. С появлением первых контроллеров SAS2 часть функционала была доступна после покупки и активации соответствующих ключей. Ключ FastPath отвечал за оптимизацию работы с SSD, в дальнейшем функционал FastPath сделали бесплатным. На второй странице содержатся рекомендованные настройки для FastPath для контроллеров 926x и 927x:
- Write Policy: Write Through
- IO Policy: Direct IO
- Read Policy: No Read Ahead
- Stripe Size: 64KB
Документация Microchip (Adaptec) гораздо более детально освещает данный вопрос. Статья в базе знаний Smart Adapter - Performance Guide, посвященная оптимизации производительности контроллеров последних серий 3100/3200, рекомендует полностью отключать кэширование для томов из SSD с лимитом производительности свыше 300 тыс. IOPS и больших нагрузках (несколько потоков с большой глубиной очереди).
Тесты, проведенные нашей компанией с контроллерами на базе LSI2108/2208 в те годы, подтверждали справедливость рекомендаций относительно режима кэширования. Но с тех пор появилось несколько поколений новых контроллеров с поддержкой накопителей NVMe, существенно выросла производительность самих контроллеров и могли измениться алгоритмы работы прошивки, связанные с кэшированием. При этом в документации Broadcom к актуальным контроллерам серии 95xx соответствующих прямых рекомендаций найти не удается. Руководство 12Gb/s MegaRAID Tri-Mode Software User Guide просто упоминает Write Through в качестве настройки по умолчанию для SSD при создании томов из профилей (Create Profile Based Virtual Drive в интерфейсе Hii).
Тестирование
Конфигурация тестового стенда
- Платформа SYS-120U-TNR
- 2 процессора Intel Xeon Gold 6334 (8 ядер, 3,6 ГГц)
- 256 ГБ памяти (8 модулей по 32 ГБ)
- RAID-контроллер Broadcom MegaRAID 9560-16i, прошивка 5.270.02-3937
- Массив RAID-10 из 4 SSD Intel S4610 480 ГБ SSDSC2KG480G801
- Arch Linux, ядро 6.6.7, ОС установлена на отдельный накопитель
- FIO 3.36
Методика тестирования
Тесты проводились на массиве RAID-10 из 4 накопителей NVMe. С целью сокращения времени выполнения предварительной нагрузки объем массива был ограничен 300 ГБ.
На массиве была отключена упреждающая запись (Read Ahead, storcli /c0/vX set rdcache=nora
) и выполнена полная инициализация (storcli /c0/vX start init full
).
При тестировании высокопроизводительных устройств важно учитывать топологию NUMA — проще говоря, привязать нагрузку к тому процессору, к которому напрямую подключено PCIe-устройство. В Linux для определения топологии NUMA можно использовать lstopo:
Machine (252GB total)
Package L#0
NUMANode L#0 (P#0 126GB)
...
HostBridge
PCIBridge
PCI 31:00.0 (RAID)
Block(Disk) "sde"
В данном случае мы видим, что том с контроллера подключен к NUMA-узлу 0. Привязать fio к этому определенному узлу можно при помощи параметра --numa_cpu_nodes
.
Параметры теста:
- Предварительная нагрузка: 2-кратное заполнение блоками 128 КиБ
- Размер блока: 4 КиБ
- Случайный доступ
- Соотношение чтение/запись: 70/30
- Потоки: 1, 2, 4, 8
- Глубина очереди на поток: 1, 2, 4, 8, 16, 32
- Дополнительные параметры fio:
--ioengine=libaio --group_reporting --direct=1 --randrepeat=0 --norandommap --thread --refill_buffers
Данные усреднялись по пяти из 10-ти раундов длительностью 60 секунд (5 «прогревочных» + 60-секундная нагрузка) каждый.
Результаты
Средняя задержка:
99,99-перцентиль задержки:
После достижения около 80 тыс. IOPS с Write Back задержка начинает стремительно расти. Использование Write Back на такой нагрузке даже при небольшой глубине очереди не имеет смысла, если обратить внимание на дисперсию задержки (см. график 99,99-перцентиля).
Объяснение
Серверные SSD располагают большим объемом собственного кэша (от сотен МБ до нескольких ГБ, в зависимости от объема NAND и класса накопителя) с собственной защитой от аварийного отключения питания. При прямом доступе запись происходит достаточно быстро — для небольшой нагрузки, не приводящей к заполнению кэша, мы можем наблюдать крайне низкую задержку (десятки микросекунд).
Современные RAID-контроллеры Broadcom достаточно производительны, лимит по IOPS составляет более 1,5 млн. Но при использовании Write Back на RAID-контроллере образуется очередь из отложенных операций записи, и он начинает заниматься ее оптимизацией. При этом оптимизация ничего не дает, так как с ней лучше справляется непосредственно контроллер накопителя. Так как RAID-контроллеру нужно обслуживать и другие операции, то под большой нагрузкой (> нескольких десятков тыс. IOPS) мы наблюдаем значительное снижение общей производительности.
Этот эффект будет не так сильно выражен на бюджетных SATA SSD. На бытовых SSD с DRAM-less контроллерами ситуация может быть и обратной, особенно после исчерпания SLC-кэша — но такие SSD всё равно нельзя использовать с аппаратными RAID-контроллерами.
Второй тест: Broadcom 9361-8i, RAID-5, 6x Samsung PM893
Дополнение от 11.04.2024. Второй тест проведен на другом контроллере — Broadcom MegaRAID 9361-8i. Он снят с поддержки, но всё ещё остается актуальным. На этот раз вместо RAID-10 использовался RAID-5 из 6 накопителей с интерфейсом SATA (Samsung PM893 MZ7L3480HCHQ-00A07). Проверялась следующая гипотеза: возможно ли, оптимизация записи при работе кэша в режиме Write-Back всё же приведет к росту производительности за счет частичного устранения write penalty в RAID-5 за счет записи полных страйпов?
Параметры теста, методика обработки результатов остались прежними. Добавилось соотношение «чтение/запись» 30/70 помимо 70/30.
Мы видим тот же результат, что и на 9560 с RAID-10 — при повышении нагрузки контроллер с Write-Back начинает отставать, и при целевой средней задержке < 1 мс можно увидеть 3–4-кратную разницу с WT.
Средняя задержка:
Низкая средняя задержка с WB при небольшой нагрузке и соотношении «чтение/запись» 70/30 обманчива — пиковые значения растут на порядок:
99,99-перцентиль задержки:
Выводы
Рекомендации из старого документа LSI сохраняют актуальность: для контроллеров Broadcom MegaRAID на томах из SSD оптимальным является Write Policy = Write Through. При этом из-за отсутствия отложенной записи защищать содержимое кэша контроллера нет необходимости, так что в подключении модуля CacheVault нет смысла, если вы не планируете подключать HDD.