SSD-кэш + HDD-массив: тиеринг данных — когда выгодно и когда нет

Компания докупила в массив СХД пару NVMe «под кэш», ожидая ускорения в разы, а через полгода производительность та же, и пользователи всё так же жалуются на медленный квартальный отчёт. SSD-кэш и HDD-массив дают ожидаемый эффект только тогда, когда совпадают паттерн нагрузки и конфигурация кэша. На случайной записи без локализации горячих данных гибрид нередко проигрывает обычному массиву с большим RAM-кэшем на хосте.

Между All-Flash и HDD-массивом гибридная схема даёт скорость SSD на горячей части данных за цену, ближе к HDD. Ниже разберём механику, сценарии работы и случаи, когда дешевле сразу All-Flash.

Тиеринг (tiering) - многоуровневое хранилище, где данные распределяются по слоям с разной скоростью и стоимостью. Горячие - на быстрых и дорогих, холодные - на медленных и дешёвых. Классический auto-tiering на enterprise-СХД перемещает блоки между слоями SSD/SAS/NL-SAS по статистике обращений - полноценная подсистема с фоновой работой.

Современный массовый вариант - SSD-кэширование: данные физически живут на HDD, на SSD автоматически попадают копии часто запрашиваемых блоков. Где применяется: виртуализация со смешанной активностью ВМ, базы данных с предсказуемым рабочим набором, файловые серверы с активной папкой текущих проектов. Где не применяется: видеоархив (последовательная запись, чтение редкое - кэш бесполезен), аналитика с full table scan по всей базе, бэкап-системы.

Тиеринг данных на уровне read-кэша работает так: когда хост запрашивает блок с массива, контроллер проверяет, есть ли он на SSD. Если есть, читаем оттуда. Если нет, читаем с HDD и копируем на SSD под флаг «горячий».

Алгоритмы вытеснения распределены по платформам. LRU (Least Recently Used) - базовая логика большинства аппаратных RAID-контроллеров (Broadcom, Microchip) и софтверных кэшей вроде bcache в Linux: выталкивается самый давно не используемый блок. LFU (Least Frequently Used) встречается в специализированных СХД от Dell EMC и NetApp и учитывает не время, а частоту обращений. ARC (Adaptive Replacement Cache) - собственная разработка Sun, по умолчанию работает в ZFS и в Solaris ZFS-стеке. Динамически смешивает LRU и LFU и адаптируется под характер нагрузки.

В кэше лежат не файлы, а блоки 4–64 КБ - это критично: даже из крупного документа в кэш попадают только активно читаемые блоки. На первом запросе - скорость HDD, на повторных - скорость SSD.

Кэширование записи делится на два режима. Write-through - запись идёт сразу на оба уровня: SSD и HDD. SSD здесь не ускоряет запись (она идёт со скоростью HDD), но новые данные сразу попадают в кэш и быстро читаются. Безопасный режим: при отключении питания ничего не теряется.

Write-back - запись идёт только на SSD, на HDD сбрасывается позже в фоне. Даёт ускорение записи до скорости SSD, но рискованно: при сбое SSD до фонового сброса данные теряются. Требует резервирования - зеркало SSD-кэша или BBU.

ZIL (ZFS Intent Log) на отдельном SSD - частный случай write-кэша для ZFS: sync-записи идут через быстрый SSD, потом сбрасываются на массив. Очень быстрый sync-write при резервированном SSD под ZIL. Для большинства сценариев выбирают write-through (безопасно), write-back - только когда производительность записи критична и есть железная защита (резервированный SSD, BBU, ИБП).

Оптимизация IOPS через SSD-кэш срабатывает там, где у нагрузки есть локализация - горячий набор данных, который умещается в кэш.

Антисценариев тоже несколько.

Гибридное хранилище проектируется от размера горячего набора, а не от объёма всего массива. Базовый ориентир - 5–10% объёма HDD на SSD-кэш под типовую корпоративную нагрузку: файловые серверы, документооборот, виртуализация со смешанной активностью. Для 50 ТБ HDD это 2,5–5 ТБ SSD. Точная цифра проверяется по cache hit ratio: выше 80% - кэша хватает, ниже 60% - мал или нагрузка непредсказуема.

Под крупные транзакционные БД и плотную виртуализацию с десятками активных ВМ горячий набор больше - индексы, журналы транзакций, активные tempdb и снапшоты ВМ растут быстро, и доля горячих блоков доходит до 10–15% объёма данных. Соответственно и кэш закладывают на этом уровне: на 100 ТБ HDD - 10–15 ТБ SSD. Под мелкие сценарии вроде файл-сервера на 10 ТБ хватит 5% - гнаться за большим кэшем смысла нет. Когда cache hit ratio уже 90%+, добавление SSD даёт прирост в единицы процентов и не оправдано.

На каком SSD строить кэш - только enterprise-класса с высоким TBW и DWPD 1+. Потребительские NVMe горят на write-кэше за месяцы: типовая Samsung 990 PRO 2 ТБ с TBW 1200 терабайт при write-кэше на 10 ТБ/сутки выработает ресурс примерно за 120 суток, диск на 1 ТБ с TBW 600 за ~60 дней. Для read-кэша допустим mixed-use класс, ресурс там не съедается так быстро. Когда понятна целевая ёмкость и характер нагрузки, проще отталкиваться от типовых конфигураций - гибридное хранилище SSD+HDD уже сбалансировано по пропорциям между быстрым кэшем и ёмким HDD-массивом, и от него удобнее двигаться к проектному решению.

SSD-кэш поверх HDD-массива оправдан там, где есть предсказуемо горячий набор данных. На случайной нагрузке без локализации, write-intensive задачах и в малой инфраструктуре 10–50 ТБ часто проще взять All-Flash. Главный показатель того, что гибридка работает у вас правильно - cache hit ratio выше 80% и стабильные IOPS. Если эти цифры не получаются, пересматривают архитектуру, а не докупают ещё SSD. Когда архитектура выбрана и понятно, какая комбинация SSD и HDD нужна под нагрузку, дальше это вопрос подбора железа: дисковые системы для серверной инфраструктуры выбираются под целевой объём, протокол подключения и горизонт роста.