Зачем нужно кэширование в системах хранения
Кэш сглаживает разрыв между скоростью вычислений и скоростью носителя. Вычислительный узел способен запрашивать десятки тысяч блоков в секунду, а один HDD 7200 об/мин отдаёт 75-150 случайных операций ввода-вывода (IOPS) при задержке 5-10 мс. Кэширование переносит горячие данные на носитель, который отвечает в 100-1000 раз быстрее, и снимает очередь дисковых операций.
| Уровень | Задержка доступа | Случайные IOPS 4K | Данные при отключении питания |
|---|---|---|---|
| HDD 7200 об/мин | 5-10 мс | 75-150 | сохраняются |
| SATA SSD | 50-100 мкс | 50 000-90 000 | сохраняются |
| NVMe SSD | 20-100 мкс | 200 000-1 000 000 | сохраняются |
| RAM (кэш ARC) | около 100 нс | миллионы | теряются |
Уровней кэша в типовой СХД три. Первый, оперативная память сервера: ZFS использует под чтение и агрегацию записи Adaptive Replacement Cache (ARC). Второй, SSD или NVMe: L2ARC расширяет кэш чтения, SLOG ускоряет синхронную запись. Третий, кэш контроллера RAID или SAN с энергонезависимой защитой (BBU, суперконденсатор) и tiered storage, где данные распределяются между SSD и HDD по политикам.
Работа кэша связана с отказоустойчивостью напрямую: для сервисов важны доступность, целостность данных и скорость восстановления после сбоя (разбор принципов отказоустойчивой инфраструктуры). Кэш повышает доступность за счёт снижения задержек, но добавляет точку, где данные существуют в единственном экземпляре. Разница между read-кэшем и write-кэшем определяет, чем обернётся отключение питания: минутой деградации или потерей записи, которую приложение уже считало записанной.
RAM-кэш: самый быстрый уровень
RAM-кэш хранит копии блоков в оперативной памяти. В ZFS этим управляет ARC: он держит и чистые блоки для чтения, и грязные данные, ещё не попавшие в пул. Алгоритм сам решает, что вытеснить: ARC состоит из двух списков (недавно использованные и часто используемые блоки), поэтому сканирование больших файлов не вымывает горячий набор данных.
По умолчанию ARC может занять до половины физической памяти сервера. Сервер с 64 ГБ RAM и пулом на HDD получает до 32 ГБ кэша: попадание в ARC отдаёт данные за микросекунды вместо 5-10 мс ожидания диска. Обратная сторона: чем больше памяти уходит под ARC, тем меньше остаётся приложениям, поэтому лимит подбирают по профилю нагрузки.
RAM энергозависима. Блоки, которые уже лежат в пуле, при сбое питания не пострадают: в ARC хранятся их копии. Иначе обстоит дело с грязными блоками: ZFS фиксирует транзакционную группу примерно раз в 5 секунд (параметр zfs_txg_timeout), а подтверждённые синхронные записи до этого момента защищает журнал ZIL. Схему пулов, типы vdev и их влияние на производительность разбирает руководство по архитектуре ZFS.
Настройка ARC в ZFS
Текущее состояние кэша смотрят утилитами arcstat (arcstat 1 5 выводит срез раз в секунду) и arc_summary (сводка с hit rate). Ключевой показатель - hit ratio чтения: у нагруженного файлового сервера он держится выше 90%, у потоковых нагрузок вроде бэкапов остаётся низким, и это нормально.
Лимит задают параметром zfs_arc_max в файле /etc/modprobe.d/zfs.conf строкой options zfs zfs_arc_max=34359738368, где 34359738368 байт = 32 ГБ. После правки на Debian и Ubuntu выполняют update-initramfs -u и перезагрузку. На части сборок значение меняется на лету: echo 34359738368 > /sys/module/zfs/parameters/zfs_arc_max.
Предупреждение: заниженный zfs_arc_max (например, 4 ГБ на 128 ГБ RAM) срезает производительность чтения и заставляет L2ARC работать вхолостую. Слишком высокий лимит на сервере с базой данных или Kubernetes приводит к срабатыванию OOM-killer. Значения по умолчанию и способ их расчёта отличаются между релизами OpenZFS, поэтому перед правкой боевого узла сверяйте параметры с документацией своей версии.
SSD-кэш: компромисс между скоростью и энергонезависимостью
SSD-кэш закрывает два разных сценария. Для чтения служит L2ARC: второй уровень после ARC, который хранит блоки на быстром носителе и переживает перезагрузку. Для записи - SLOG, отдельное устройство под ZFS Intent Log, которое принимает синхронные операции. Оба механизма добавляют в пул отдельный vdev-класс и не расширяют полезную ёмкость.
Выбор носителя зависит от роли. L2ARC пишет много и постоянно, поэтому потребительский SSD с ресурсом 0,3 DWPD выработает запас за год активной работы; под кэш берут накопители класса enterprise с ресурсом от 1 DWPD и защитой от потери питания. Как считать DWPD и TBW под конкретную нагрузку, разобрано в материале про NVMe-кэш в дисковых массивах. Команды для SLOG на Intel Optane и L2ARC на NVMe с мониторингом hit ratio собраны в руководстве по настройке кэширования в СХД.
L2ARC: настройка и типичные ошибки
Устройство добавляют командой zpool add tank cache /dev/nvme0n1, убирают командой zpool remove tank /dev/nvme0n1. Кэш не участвует в проверках целостности: отказавший L2ARC не разрушает пул, ZFS переключается на диски, и производительность чтения падает до уровня HDD.
Главная ошибка - L2ARC при маленьком ARC. Каждый блок в L2ARC требует записи в индексы, которые живут в оперативной памяти: примерно 70-80 байт ARC на блок. При размере записи 128 КБ кэш на 1 ТБ добавляет около 600-700 МБ занятой RAM. Если ARC занимает 8 ГБ, индексы съедят заметную долю и вытеснят полезные данные. Практическое правило: не добавлять L2ARC, пока ARC меньше 8-16 ГБ.
Эффективность проверяют через arcstat -a: смотрят на l2_hit, l2_size, l2_read_bytes и l2_write_bytes. После прогрева l2_hit выше 5-10% оправдывает устройство, а близкий к нулю показатель говорит о том, что рабочее множество данных не помещается в кэш или нагрузка последовательная. Ещё одна частая ошибка - отсутствие зеркала там, где важна доступность чтения: L2ARC можно собрать зеркалом командой zpool add tank cache mirror /dev/nvme0n1 /dev/nvme1n1, тогда потеря одного SSD не обрушит кэш.
SLOG (ZIL) для синхронных записей
ZIL фиксирует синхронные операции (fsync, O_SYNC, NFS с sync, iSCSI, запись базы данных) до того, как данные попадут в основные vdev. Без отдельного устройства журнал размещается на дисках пула, и каждая синхронная запись разбивается на два потока: запись в журнал и запись в основной массив. SLOG переносит журнал на быстрый носитель с низкой задержкой.
Добавляют SLOG командой zpool add tank log mirror /dev/nvme1n1 /dev/nvme2n1. Ёмкость здесь почти не важна: журнал хранит только те записи, которые ещё не зафиксированы в транзакционной группе, то есть считанные секунды потока записи. Накопители по 100-200 ГБ с защитой от потери питания (PLP) закрывают задачу с большим запасом, и покупать под журнал 2 ТБ смысла нет.
Проверить, нужен ли SLOG, помогает zilstat: он показывает поток синхронных записей в байтах за интервал. Для больших последовательных записей (бэкапы, медиа) SLOG не даёт ничего, потому что такие операции копятся в памяти и фиксируются целиком. Выигрыш появляется на базах данных, виртуализации с fsync и NFS с sync=standard.
Предупреждение: SLOG без зеркала создаёт риск. При отказе единственного устройства пул импортируется, но подтверждённые синхронные записи, не успевшие попасть в основной массив, теряются. Для продакшена SLOG собирают в зеркало, а накопители выбирают с PLP, чтобы данные переживали отключение питания внутри самого SSD.
Read-кэш и write-кэш: в чём разница и как не потерять данные
Read-кэш хранит копии блоков, которые уже лежат на дисках: ARC, L2ARC, кэш чтения контроллера. Потеря такого кэша стоит только производительности. Write-кэш буферизует данные, которых на дисках ещё нет: кэш записи контроллера RAID с BBU, грязные блоки ARC, ZIL и SLOG. Потеря write-кэша означает потерю записей, о которых приложение уже получило подтверждение.
| Свойство | Read-кэш (ARC, L2ARC) | Write-кэш (ZIL, SLOG, BBU-кэш контроллера) |
|---|---|---|
| Что хранит | копии прочитанных блоков | данные до записи в основной массив |
| Отключение питания | кэш пуст, данные целы | незафиксированные записи могут исчезнуть |
| Влияние на целостность | нет | есть, если нет защиты |
| Отказ устройства кэша | падение производительности чтения | потеря последних синхронных записей |
В ZFS режим записи регулирует параметр sync. При sync=standard синхронными считаются только операции с fsync и O_SYNC, остальные проходят через память. При sync=always через ZIL идёт каждая запись: это самый безопасный и самый медленный вариант, если SLOG нет. При sync=disabled ZFS игнорирует флаги синхронизации, и отключение питания может унести до 5 секунд записей, которые приложение считало записанными. Такой режим уместен для тестовых стендов и наборов данных, которые можно пересоздать.
Аппаратный контроллер RAID с кэшем записи ведёт себя похоже: без BBU или суперконденсатора он либо работает в режиме write-through, либо принимает данные в кэш с риском потери при сбое. Проверять стоит не только наличие батареи, но и её состояние: разряженный BBU заставляет прошивку автоматически отключать write-back.
Целостность важнее скорости. Если заказы, платежи и учётные записи не должны теряться и искажаться, write-кэш защищают комплексом: зеркалом SLOG, накопителями с PLP и ИБП, который держит сервер до момента фиксации данных. При повреждении базы данных восстановление идёт из реплики или резервной копии с минимальной потерей данных, и наличие кэша этот сценарий не отменяет (как устроено восстановление после сбоя).
Tiered storage: автоматическое перемещение данных между уровнями
Tiered storage распределяет данные по уровням: NVMe и SSD для горячих блоков, HDD для основной ёмкости, объектное хранилище или лента для архива. Перемещение выполняет сама система по политикам: частота обращения, возраст данных, тип файла, размер блока.
В ZFS автоматического переноса данных между пулами нет. Роль быстрого уровня играют кэши и отдельные vdev-классы: L2ARC кэширует чтение, SLOG принимает синхронную запись, special vdev хранит метаданные и мелкие блоки на SSD, пока основные данные лежат на HDD. Свойство special_small_blocks в OpenZFS 2.2 и TrueNAS SCALE задаёт размер блоков, которые целиком уходят на быстрый vdev. Это ближайший аналог тиринга на уровне пула: данные не переносятся между HDD и SSD, а изначально распределяются по классам устройств.
Автоматический тиринг реализуют другие системы: СХД уровня Dell, NetApp и HPE с политиками по частоте доступа; блочные механизмы Linux dm-cache и bcache, которые ставят SSD перед HDD на уровне блочного устройства; Storage Spaces в Windows Server. В Ceph исторически был cache tiering, но от него отказались в пользу разделения пулов по классам устройств (device class) и правил CRUSH.
Практический риск тиринга - неверные политики. Слишком агрессивный перенос на медленный уровень превращает горячий набор данных в поток отложенных чтений с HDD, а неудачный размер блока заставляет систему постоянно перемещать одни и те же данные туда и обратно. Политики проверяют на реальном профиле нагрузки, а не на одном синтетическом файле.
Пример настройки tiered storage в TrueNAS
Сценарий: пул fast на NVMe ёмкостью 2 ТБ и пул slow на HDD объёмом 40 ТБ. Горячие данные (виртуальные машины, база, рабочие каталоги) живут на fast, архив и медиа на slow. Готового автомата переноса в веб-интерфейсе нет, поэтому шаг выполняется снимками и отправкой: zfs snapshot slow/data@tier-2026-09-18, затем zfs send -R slow/data@tier-2026-09-18 | zfs recv -F fast/data. Обратный перенос холодных данных делают тем же способом, но инкрементными снимками с флагом -i, чтобы не гонять весь набор данных.
Расписание вешают на cron: раз в сутки скрипт определяет по atime или по результатам zfs get -r used наборы данных, переросшие порог, и переносит их снимком. Такой подход требует мониторинга свободного места на fast, контроля числа снимков и проверки того, что приложение остановлено или работает с файловой системой в режиме чтения. Настройку ARC, L2ARC и подбор SSD под кэш в TrueNAS Scale и Core разбирает отдельное руководство по TrueNAS.
Практические рекомендации по настройке кэша без потери данных
- Считайте ARC по объёму памяти, а не по ёмкости пула. Начните с лимита в 50% RAM, следите за hit ratio через arc_summary и за свободной памятью приложений.
- Не добавляйте L2ARC, пока ARC меньше 8-16 ГБ: индексы кэша конкурируют с данными за оперативную память.
- Собирайте SLOG в зеркало минимум из двух устройств с PLP и ресурсом от 3 DWPD. Ёмкости 100-200 ГБ на устройство достаточно.
- Ставьте ИБП. Кэш записи на базе RAM не переживает отключение питания без журнала и внешнего питания.
- Проверяйте результат под нагрузкой. Методика измерений до и после правки конфигурации через fio и iostat описана в разборе производительности файловой системы.
- Запускайте zpool scrub по расписанию (раз в месяц для HDD-пулов) и следите за zpool status: растущие ошибки контрольных сумм говорят о проблемах с диском или кабелем, а не о кэше.
- Держите реплику или резервную копию за пределами пула с кэшем. Кэширование ускоряет доступ, но не заменяет сценарий восстановления.
Ориентир для рабочей конфигурации: сервер с 128 ГБ RAM, ARC до 64 ГБ, L2ARC на NVMe 1 ТБ, SLOG в зеркале из двух NVMe по 200 ГБ с PLP, пул на HDD в RAID-Z2, ИБП на 15 минут автономии. Такая схема отдаёт горячее чтение из памяти и SSD, синхронную запись держит на быстром журнале, а холодные данные оставляет на дисках.
Полностью исключить сбои невозможно: аварии, ошибки конфигурации и проблемы у внешних провайдеров случаются даже у крупных облачных платформ (ограничения отказоустойчивости). Определите допустимое время простоя заранее, ограничьте масштаб последствий понятным сценарием восстановления, а кэш настраивайте так, чтобы он ускорял работу и не создавал новую точку отказа.