Нужен ли 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.