Настройка кэширования в системах хранения: SSD, NVMe и Intel Optane

Зачем нужно кэширование в системах хранения

Центральный процессор обрабатывает данные со скоростью, на порядки превышающей возможности постоянной памяти. Даже самый быстрый NVMe-накопитель задерживает конвейер вычислений. Этот разрыв - главный ограничитель производительности любой СХД. Кэш выступает посредником: он хранит часто запрашиваемые блоки на устройстве, чья скорость отклика сопоставима с оперативной памятью. Результат - снижение задержек до сотен микросекунд и рост пропускной способности в десятки раз.

Кэширование делится на два направления: чтение и запись. Кэш чтения предугадывает, какие данные понадобятся, и подгружает их заранее. Кэш записи аккумулирует входящий поток и сбрасывает его на медленные диски асинхронно. В этой статье мы разберем оба механизма на практике: настроим алгоритмы write-back, write-through и write-around, добавим Intel Optane как SLOG для синхронной записи и NVMe SSD как L2ARC для горячих данных. Все команды проверены на TrueNAS и Linux с ZFS.

Если вы проектируете новое хранилище или модернизируете существующее, понимание архитектуры кэша обязательно. Без него вы рискуете оставить 70% производительности неиспользованными. Разберемся, как выжать максимум.

Алгоритмы кэширования записи: write-back, write-through, write-around

Выбор режима записи определяет баланс между скоростью и сохранностью данных. Ошибка здесь стоит либо потерянных транзакций, либо напрасно потраченных ресурсов. Три базовых алгоритма покрывают все сценарии - от банковских баз до потокового видео.

Write-through: безопасность в ущерб скорости

При write-through контроллер подтверждает операцию хосту только после физической фиксации данных на диске. Кэш дублирует запись, но не дает преимущества по задержке. Зато при внезапном отключении питания вы не теряете ни одного подтвержденного байта.

Этот режим оправдан для журналов транзакций СУБД, финансовых систем и любых нагрузок, где целостность критичнее производительности. Задержка записи здесь равна задержке самого медленного диска в массиве - обычно 5-15 мс для HDD. Пропускная способность упирается в механику шпинделей. Если ваша задача - гарантировать сохранность, а не гнаться за IOPS, включайте write-through.

Write-back: максимальная производительность с риском

Write-back меняет порядок: данные сначала попадают в энергозависимый кэш, хост получает подтверждение мгновенно, а сброс на диск происходит позже. Задержка падает до десятков микросекунд. Пропускная способность записи приближается к скорости шины PCIe.

Риск очевиден: содержимое кэша, не успевшее уйти на диск, исчезает при сбое питания. Для защиты применяют батарейные модули (BBU) на RAID-контроллерах или суперконденсаторы на серверных SSD. В ZFS роль защищенного буфера выполняет отдельное устройство SLOG - обычно Intel Optane с собственной энергонезависимостью. Write-back - стандартный выбор для виртуализации, файловых серверов и баз данных с высокими требованиями к задержке. Подробнее о реализации кэша для виртуальных сред читайте в руководстве по кэшированию NVMe в дисковых массивах.

Write-around: оптимизация для потоковой записи

Write-around пропускает кэш при записи: данные идут сразу на диск. Кэш заполняется только когда эти блоки запрашивают на чтение. Смысл в том, чтобы не вытеснять полезные горячие данные ради однократного потока, который никогда не перечитают.

Типичные сценарии - резервное копирование, запись потокового видео с камер наблюдения, логирование. Здесь объем однократной записи велик, а повторный доступ отсутствует. Write-around сохраняет кэш чтения эффективным для реально востребованных блоков. В ZFS этот режим не настраивается явно, но достигается через параметр primarycache=metadata или отключение secondarycache для конкретного датасета.

Кэширование в ZFS: архитектура ARC, L2ARC и ZIL/SLOG

ZFS реализует многоуровневый кэш, который работает автоматически, но требует осмысленной настройки под нагрузку. Три компонента - ARC, L2ARC и SLOG - решают разные задачи. Их путают, и это приводит к бесполезной трате железа.

ARC и L2ARC: кэширование чтения

ARC (Adaptive Replacement Cache) размещается в оперативной памяти. Он работает всегда, использует алгоритм, учитывающий частоту и давность обращений, и делит пространство между недавно использованными (MRU) и часто используемыми (MFU) блоками. Объем ARC по умолчанию - половина RAM сервера. Этого достаточно для большинства файловых нагрузок.

Когда ARC переполняется, блоки вытесняются. L2ARC - это расширение ARC на SSD или NVMe. Он хранит вытесненные блоки, к которым еще могут обратиться. Важный нюанс: заголовки L2ARC хранятся в RAM. Каждые 20-40 ГБ L2ARC требуют примерно 1 ГБ оперативной памяти под индексацию. Правило sizing: объем L2ARC не должен превышать 5-10 объемов RAM. На сервере с 64 ГБ ОЗУ ставить 2 ТБ L2ARC бессмысленно - индексы съедят всю память, и hit ratio упадет.

Добавление L2ARC выполняется одной командой:

zpool add tank cache nvme0n1

Проверка статуса:

zpool status tank

Если RAM не хватает, ограничьте L2ARC до метаданных:

zfs set secondarycache=metadata tank/dataset

Детальную настройку ARC и L2ARC через GUI TrueNAS мы разбирали в практическом руководстве по кэшированию в TrueNAS.

ZIL и SLOG: ускорение синхронной записи

ZFS Intent Log (ZIL) - это журнал, куда временно попадают синхронные операции записи до фиксации в основном пуле. По умолчанию ZIL размещается на тех же дисках, что и данные. Для HDD это означает задержку 5-15 мс на каждую синхронную транзакцию. NFS и iSCSI используют синхронную запись активно, поэтому без отдельного SLOG их производительность проваливается.

SLOG (Separate LOG) - это выделенное устройство, куда выносится ZIL. Требования к SLOG: низкая задержка (желательно десятки микросекунд), высокая стойкость к износу и защита от потери питания. SLOG читается только при восстановлении после сбоя. В нормальном режиме работают только записи.

Разница между синхронной и асинхронной записью принципиальна. Синхронная - хост ждет подтверждения фиксации на постоянном хранилище. Асинхронная - данные уходят в RAM и подтверждаются сразу. SLOG ускоряет синхронную запись до уровня асинхронной, сохраняя гарантии целостности. Подробнее о проектировании пулов с SLOG читайте в материале по архитектуре ZFS.

Выбор устройств для кэша: SSD, NVMe и Intel Optane

Не каждый SSD подходит для кэша. Ключевые параметры: задержка на 99-м перцентиле, IOPS на малых блоках, ресурс перезаписи (TBW или DWPD) и наличие энергонезависимой защиты кэша (PLP). Обычный потребительский SSD без PLP в роли SLOG даст задержку хуже, чем HDD, потому что его встроенный кэш сбрасывается синхронно.

Intel Optane как идеальный SLOG

Технология 3D XPoint, лежащая в основе Optane, обеспечивает задержку на порядок ниже, чем NAND. Запись происходит побайтово, без необходимости стирания целых блоков. Это устраняет проблему усиления записи (write amplification) и дает огромный ресурс - до 60 полных перезаписей в день (DWPD).

Optane сохраняет данные при отключении питания без батарей и конденсаторов. Для SLOG это критично: после сбоя сервер читает ZIL и восстанавливает незавершенные транзакции. Модели P4800X и 900P - эталон для высоконагруженных систем. P1600X в формате M.2 2280 подходит для компактных серверов и домашних NAS. Всегда зеркалируйте SLOG: потеря устройства SLOG при отключении питания равносильна потере последних транзакций. Команда для зеркалирования:

zpool add tank log mirror /dev/disk/by-id/nvme-optane1 /dev/disk/by-id/nvme-optane2

NVMe SSD для L2ARC и специальных vdev

NVMe SSD с интерфейсом PCIe 4.0 выдают 1-1.5 млн IOPS на чтение. Для L2ARC это означает быструю подгрузку вытесненных из ARC блоков. Выбирайте модели с DWPD не менее 1 - постоянный поток вытеснений быстро изнашивает дешевые накопители. Корпоративные Samsung PM9A3, Kioxia CD6 или Solidigm P5520 подходят оптимально.

Special allocation vdev (special vdev) - альтернатива L2ARC для метаданных. Вы помещаете метаданные и мелкие блоки на зеркало из NVMe, а данные остаются на HDD. Это ускоряет листинг директорий, поиск и операции с файловой системой без прогрева кэша. Настройка:

zpool add tank special mirror nvme0n1 nvme1n1

В отличие от L2ARC, данные на special vdev постоянны и не требуют индексации в RAM.

Практическая настройка кэша в TrueNAS и Linux с ZFS

Переходим к командам. Все примеры выполняются от root на Linux с установленным ZFS или через Shell в TrueNAS. Перед добавлением устройств убедитесь, что они видны системе:

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL

Добавление SLOG (ZIL) на Intel Optane

Определите идентификаторы устройств Optane. Используйте /dev/disk/by-id/ для стабильности:

ls -la /dev/disk/by-id/ | grep nvme

Добавьте зеркалированный SLOG в существующий пул tank:

zpool add tank log mirror /dev/disk/by-id/nvme-INTEL_SSDPEK1A118GA /dev/disk/by-id/nvme-INTEL_SSDPEK1A118GB

Проверьте конфигурацию пула:

zpool status tank

В выводе появится раздел logs с зеркалом. Для датасетов, требующих гарантированной синхронной записи, включите sync=always:

zfs set sync=always tank/nfs-share

Стандартный режим sync=standard использует синхронную запись только когда её запрашивает приложение. Для iSCSI и NFS этого достаточно - они сами требуют синхронности.

Добавление L2ARC на NVMe SSD

Добавьте устройство кэша чтения:

zpool add tank cache /dev/disk/by-id/nvme-SAMSUNG_MZQL21T9HCJR

Отслеживайте использование L2ARC:

zpool iostat -v tank 5

Колонка cache покажет операции чтения и записи. Если hit ratio L2ARC ниже 20% после недели работы, устройство не окупает затраченную RAM на индексацию. Либо добавьте памяти, либо уменьшите объем L2ARC, либо переключите его на метаданные:

zfs set secondarycache=metadata tank/dataset

Для полного отключения L2ARC на датасете:

zfs set secondarycache=none tank/temp

Мониторинг и анализ эффективности кэша

Кэш без мониторинга - черный ящик. Вы не знаете, работает ли он на 90% или на 9%. ZFS предоставляет инструменты, которые показывают состояние каждого уровня.

Ключевые метрики ZFS для кэша

Основная команда для ARC:

arcstat -f time,hits,miss,hit%,l2hits,l2miss,l2hit%,arcsz 1

Параметры для оценки:

• hit% - процент попаданий в ARC. Значение выше 90% означает, что кэш чтения работает эффективно.
• l2hit% - попадания в L2ARC. Выше 20% - L2ARC оправдан. Ниже 10% - устройство зря тратит RAM на индексацию.
• arcsz - текущий размер ARC. Если он упирается в лимит и miss растет, увеличивайте RAM.

Детальный отчет по ARC:

arc_summary -d | head -50

Для SLOG критичны задержка и пропускная способность. Используйте zilstat:

zilstat 1

Колонки показывают количество операций ZIL в секунду и средний размер записи. Если задержка SLOG превышает 1 мс на Optane - проверьте температуру устройства или целостность PCIe-линков.

Типичные проблемы и их решение

Низкий hit ratio L2ARC. Проверьте объем RAM: возможно, заголовки L2ARC вытеснили полезные данные из ARC. Решение - увеличить ОЗУ или сократить L2ARC. Команда для удаления устройства кэша:

zpool remove tank nvme0n1

Высокая задержка записи при наличии SLOG. Убедитесь, что датасет использует синхронную запись: zfs get sync tank/dataset. Если стоит sync=disabled, SLOG не используется. Включите sync=standard или always.

Кэш не используется. Проверьте настройки датасета: zfs get primarycache,secondarycache tank/dataset. Значение none отключает кэш. Верните all для primarycache и all для secondarycache.

Аппаратное кэширование RAID-контроллеров

Аппаратные RAID-контроллеры (Broadcom/LSI, Microchip/Adaptec) используют DRAM-кэш с батарейной защитой (BBU) или флэш-модулем CacheVault. Принцип схож с ZFS: данные сначала попадают в быстрый буфер, затем сбрасываются на диски.

Три режима работы:

• Write-Back - аналог ZFS с SLOG. Подтверждение хосту после записи в кэш контроллера. Требует BBU/CacheVault.
• Write-Through - запись напрямую на диски. Кэш используется только для чтения.
• Read-Ahead - упреждающее чтение последовательных блоков. Эффективно для потоковых нагрузок.

Аппаратный RAID предпочтителен для Windows Server и сред, где ZFS недоступен. Контроллер берет на себя расчет четности в RAID 5/6, разгружая CPU. Однако гибкость настройки уступает ZFS: вы не можете добавить SLOG на Optane или L2ARC на NVMe как отдельные vdev. Кэш контроллера един для всего массива.

Риски те же: при отказе BBU и пропадании питания данные в DRAM теряются. Регулярно проверяйте статус батареи и заменяйте её по расписанию производителя. Подробное сравнение программных и аппаратных RAID-решений с командами для настройки мы приводили в руководстве по RAID-массивам на Linux.

Заключение: оптимальная стратегия кэширования

Кэширование в СХД - это не покупка самого дорогого SSD. Это точное соответствие устройства задаче. Для синхронной записи (NFS, iSCSI, базы данных) ставьте зеркалированный SLOG на Intel Optane. Задержка упадет с миллисекунд до десятков микросекунд. Для чтения горячих данных добавляйте L2ARC на корпоративных NVMe, но только при достатке оперативной памяти - соблюдайте соотношение 1 ГБ RAM на 20-40 ГБ L2ARC.

Алгоритм выбора за пять шагов:

1. Определите профиль нагрузки: синхронная или асинхронная запись, случайное или последовательное чтение.
2. Для синхронной записи - добавьте зеркалированный SLOG на Optane.
3. Для чтения - сначала увеличьте RAM под ARC. Если hit ratio ниже 90% - добавляйте L2ARC.
4. Для метаданных и мелких файлов - рассмотрите special vdev на NVMe вместо L2ARC.
5. Настройте мониторинг через arcstat и zilstat. Без цифр оптимизация слепа.

Тестируйте изменения на нерабочей копии данных. Ошибка в конфигурации SLOG может привести к потере последних транзакций при сбое. После внедрения наблюдайте за метриками неделю и корректируйте sizing. Правильно настроенный кэш превращает массив из восьми HDD в систему, сравнимую по отзывчивости с all-flash массивом, при вдвое меньшей стоимости.