Tiering (многоуровневое хранение) распределяет блоки и файлы по носителям разной скорости и цены: горячие данные остаются на NVMe, тёплые живут на SATA SSD, холодные переезжают на HDD, а архив уходит на ленту или в дешёвое объектное хранилище. Система измеряет частоту обращений и сама переносит данные между уровнями. Цель одна: сохранить отклик на активных запросах и не платить за быстрые носители там, где они простаивают.
Экономика здесь считается в лоб. Разрыв в цене за терабайт между NVMe и лентой измеряется десятками раз, а разрыв в IOPS между ними - тысячами. Держать все 100 ТБ на NVMe означает платить за ёмкость, которой реально пользуются 10-20% приложений. При раскладке по уровням дорогие носители обслуживают только рабочую нагрузку.
Ниже разобраны алгоритмы автоматического переноса данных, политики, конкретные настройки в TrueNAS и Ceph, подходы вендоров коммерческих СХД, расчёт TCO и типичные ошибки, из-за которых tiering ухудшает отклик вместо улучшения.
Что такое многоуровневое хранение и зачем нужен tiering
Многоуровневое хранение строится на трёх предпосылках: носители отличаются по цене за терабайт, по задержке и по ресурсу записи; доступ к данным неравномерен; перемещение данных можно автоматизировать. Tiering соединяет эти предпосылки: быстрый и дорогой тир получает меньший объём и обслуживает активные блоки, медленный и дешёвый тир забирает основную ёмкость.
Принцип тот же, что у файла подкачки в операционной системе. Разбор причин просадок производительности в играх показывает: при нехватке физической RAM система активнее использует подкачку, а это даёт подтормаживания, рывки и нестабильное время кадра, при этом быстрый NVMe SSD справляется с виртуальной памятью заметно лучше старого механического HDD (источник). В СХД логика повторяется в масштабе пула: RAM работает как первый уровень, NVMe как второй, HDD как третий.
Горячие, тёплые и холодные данные: как определить уровень
- Горячие данные. Высокая частота чтения и записи, жёсткие требования к задержке: транзакционные базы данных, диски виртуальных машин, очереди сообщений, индексы поиска. Место размещения: NVMe.
- Тёплые данные. Периодический доступ, отклик важен, но допускает задержку в единицы миллисекунд: рабочие каталоги пользователей, файловые хранилища, свежие резервные копии, артефакты сборки. Место размещения: SATA SSD или быстрые HDD.
- Холодные данные. Редкий доступ: ночные бэкапы, отчёты за прошлые периоды, вложения, журналы за несколько месяцев. Место размещения: HDD большой ёмкости.
- Архив. Доступ измеряется единицами раз в год и регулируется регламентом: долгосрочные копии, лог-архивы, данные для соответствия требованиям. Место размещения: лента или объектное хранилище с отложенным доступом.
Уровень определяется не названием сервиса, а метриками: IOPS и пропускная способность на блок, доля чтения и записи, средний размер запроса, задержка 95-го и 99-го перцентиля, объём рабочей выборки и возраст файла. Правило 80/20 (20% блоков дают 80% обращений) работает как ориентир для планирования, но не как гарантия: в аналитических системах рабочая выборка может занимать 40-60% ёмкости.
Классификация динамическая. Нагрузка меняется по часам и неделям: отчётный период вытаскивает наверх данные, которые месяц лежали нетронутыми. Поэтому окно измерения выбирают от нескольких часов до нескольких дней и пересчитывают карту активности регулярно. Как устроены уровни и политики жизненного цикла в целом, разобрано в материале про организацию хранения данных по уровням.
Ключевые компоненты: кэширование, миграция и политики
Рабочая система tiering состоит из трёх частей. Первая - кэширование: быстрый носитель хранит копию часто читаемых блоков, оригинал остаётся на медленном тире. В ZFS эту роль выполняет L2ARC (чтение) и SLOG (журнал синхронной записи). Вторая - миграция: фоновый процесс переносит блоки между тирами, меняя их постоянное место размещения. Третья - политики: правила, по которым система решает, что и когда переносить.
В Ceph место размещения задают не миграцией готовых данных, а через CRUSH-правила и пулы: пул для горячих данных собирается из устройств класса NVMe, пул для холодных - из HDD. Приложение или шлюз S3 выбирает пул при записи объекта. Правило размещения описывает, по каким устройствам и с каким доменом отказа раскладываются данные.
Политику переноса строят по возрасту данных, частоте обращений, типу приложения, размеру блока и приоритету сервиса. Смешанные политики встречаются чаще одиночных: метаданные и мелкие блоки удерживают на быстром тире независимо от возраста, крупные холодные объекты выталкивают на HDD. Общие принципы проектирования уровней hot, warm, cold и archive с расчётом ёмкости описаны в статье про проектирование системы хранения предприятия.
Как работает автоматический tiering: алгоритмы и политики
Автоматический tiering работает циклом из четырёх шагов. Сбор метрик: система фиксирует обращения к блокам и файлам, агрегирует их по окнам времени. Построение карты активности: каждому блоку или диапазону присваивается вес (температура). Решение: блок получает повышение до быстрого тира или понижение до медленного. Исполнение: фоновый процесс копирует данные и переключает ссылки, чаще всего асинхронно, чтобы не блокировать ввод-вывод приложения.
Пороги промоушена и демоушена задаются с гистерезисом. Без него блок с пограничной активностью начинает прыгать между тирами, и система тратит полосу на бессмысленные переносы. Типовые настройки выглядят так: горячим считается блок с обращениями чаще нескольких раз в час в течение суток, холодным - блок без обращений 30 дней. Точные значения зависят от профиля нагрузки, универсальных цифр нет.
Миграция стоит ресурсов. Перенос больших объёмов занимает дисковую полосу и процессорное время, поэтому в большинстве систем задают лимит скорости переноса и окно выполнения. Планирование переноса на ночные часы снижает влияние на дневную нагрузку.
Политики перемещения данных: от эвристик до машинного обучения
- LRU (least recently used). Вытесняется то, к чему давно не обращались. Простая политика, хорошо работает на равномерной нагрузке, плохо переживает разовые всплески.
- LFU (least frequently used). Приоритет у блоков с высокой суммарной частотой обращений. Устойчивее к всплескам, но медленно расстаётся с данными, которые были популярны раньше.
- По размеру и типу блока. Метаданные, мелкие блоки и журналы закрепляются за быстрым тиром, крупные последовательные данные уходят вниз.
- По возрасту и регламенту. Файл старше N дней автоматически переезжает в холодный тир, старше года - в архив. Предсказуемо, удобно для отчётности и требований хранения.
- Прогнозные модели. Коммерческие системы и часть open-source решений оценивают будущую активность по истории и заранее поднимают данные. Выигрыш заметен на повторяющихся циклах нагрузки, на нерегулярной - модель ошибается.
Сложная политика требует настройки и постоянного контроля. Модель с десятком параметров без мониторинга даёт эффект хуже простой LRU, потому что ошибки прогноза никто не отслеживает.
Кэширование vs tiering: в чём разница и что выбрать
| Критерий | Кэширование | Tiering |
|---|---|---|
| Что происходит с данными | Копия на быстром носителе, оригинал остается | Данные переносятся на другой уровень на постоянной основе |
| Влияние на ёмкость | Ёмкость кэша расходуется на дубли | Общая ёмкость складывается из всех тиров |
| Потеря быстрого носителя | Потеря только копий, данные целы | Данные остаются, но доступ замедляется до перестроения |
| Профиль нагрузки | Read-heavy с небольшой горячей выборкой | Есть выраженное холодное большинство |
| Основная выгода | Скорость отклика | Стоимость хранения |
В ZFS L2ARC кэширует чтение, SLOG ускоряет синхронную запись, но не хранит пользовательские данные: он принимает журнал операций. В Ceph кэш-пулы относились к tiering, но сейчас считаются устаревшим механизмом.
Tiering в TrueNAS и ZFS: L2ARC, SLOG и special vdev
Классического автоматического tiering в ZFS нет: система не переносит блоки между vdev по температуре. Многоуровневость собирается из трёх механизмов: кэш чтения L2ARC, журнал синхронной записи SLOG и special vdev для метаданных и мелких блоков. Основную работу выполняет ARC в оперативной памяти.
Настройка L2ARC: когда и сколько
L2ARC имеет смысл, когда горячая выборка не помещается в RAM и нагрузка преимущественно читающая. Индекс L2ARC хранится в ARC, то есть в оперативной памяти, поэтому сначала увеличивают RAM и только потом добавляют кэш-устройство. Распространённая эвристика: ёмкость L2ARC в пределах 5-10% от объёма пула, при пуле 100 ТБ это примерно 1 ТБ на NVMe.
- L2ARC ускоряет чтение и не влияет на скорость записи.
- Содержимое кэша не сохраняется между перезагрузками, после старта он наполняется заново.
- Потеря L2ARC не приводит к потере данных: это копии блоков.
- Несколько устройств L2ARC объединяются, отказоустойчивость здесь не требуется.
- Для пула общего назначения ориентируются на 1 ГБ RAM на 1 ТБ ёмкости; при дедупликации требования к памяти выше в разы.
При выборе устройства смотрят на интерфейс и форм-фактор: SATA или NVMe, корпус 2,5 дюйма или M.2, при этом совместимость не определяют по внешнему виду разъёма (источник). В TrueNAS кэш-устройство добавляется в существующий пул как отдельный vdev типа Cache.
SLOG: ускорение синхронной записи
SLOG принимает синхронные операции записи: NFS с sync, iSCSI, базы данных с fsync, почтовые серверы. Асинхронную запись он не ускоряет, потому что такие данные и так попадают в память и сбрасываются позже.
- Объём невелик: 10-20 ГБ хватает на большинство нагрузок, потому что журнал постоянно очищается.
- Нужен носитель с защитой от потери питания (PLP) и высоким ресурсом записи; NVMe класса Optane или серверные модели с PLP.
- SLOG ставят в зеркало: при отказе одиночного устройства без зеркала теряются последние подтверждённые синхронные операции.
- Устройство без PLP искажает гарантию синхронной записи, и после сбоя питания база данных может получить неполный журнал.
Третий механизм, special vdev, хранит метаданные, дедупликационную таблицу и мелкие блоки на быстром носителе. Он относится к размещению данных, а не к кэшированию, и требует зеркала или RAIDZ, потому что при его потере пул становится нечитаемым. Для пула с миллионами мелких файлов special vdev на NVMe дает больший прирост, чем L2ARC.
Tiering в Ceph: пулы, CRUSH-правила и device class
В Ceph данные раскладываются алгоритмом CRUSH по устройствам, объединённым в пулы. Устройства получают класс (hdd, ssd, nvme), а правило CRUSH определяет, какие классы и с каким доменом отказа используются. Пулы для горячих и холодных данных указывают на разные правила, поэтому одни и те же данные можно развести по носителям без ручного копирования.
Создание пулов и CRUSH-правил
- Проверить классы устройств: команда ceph osd df tree показывает OSD и их классы, ceph osd crush class ls выводит список классов.
- Создать правило размещения для быстрых носителей, например: ceph osd crush rule create-replicated hot-nvme default nvme.
- Создать пул на этом правиле: ceph osd pool create hot 128 128 replicated hot-nvme. В новых версиях число PG задаёт автоскейлер, и параметры можно не указывать.
- Повторить шаги для второго правила на HDD и получить пул cold.
- Отдать пулы приложениям: RBD, CephFS или шлюзу RGW с разными placement target.
Синтаксис отличается между релизами, поэтому сверяйтесь с документацией своей версии. Перед переносом продакшена проверьте поведение на тестовом кластере: неверное правило может разложить данные по одному диску и уронить отказоустойчивость.
Кэш-пулы в Ceph: особенности и ограничения
Режим cache tiering, при котором быстрый пул выступает кэшем для медленного, в документации Ceph помечен как устаревший и не рекомендуется в новых кластерах. Причины: непредсказуемая задержка при промахе кэша, сложность настройки порогов flush и evict, риск переполнения быстрого пула и деградация на последовательных нагрузках.
Рабочие альтернативы: отдельные пулы с разными CRUSH-правилами и явным выбором пула приложением; политики жизненного цикла объектов в RGW, которые переносят объекты между классами хранения по возрасту; вынос архива во внешнее объектное хранилище через шлюз. Статус функции проверяйте в документации своей версии Ceph, он менялся между релизами.
Tiering в коммерческих СХД: подходы вендоров
Коммерческие системы закрывают ту же задачу автоматически и с меньшим участием администратора. Публичная документация вендоров описывает такие подходы: Dell PowerStore строит размещение данных по политикам с учётом IOPS и задержек, NetApp ONTAP с функцией FabricPool переносит холодные блоки в объектное облако или на отдельный дешёвый тир, HPE делает ставку на телеметрию и рекомендации по перебалансировке, IBM и Hitachi предлагают выделенные архивные уровни с лентой.
Практическая разница с open-source решением: вендор даёт гарантированный SLA, готовые отчёты, интеграцию с системами мониторинга и обновления, которые не ломают размещение данных. Плата за это - лицензии, привязка к аппаратному списку совместимости и меньшая свобода в настройке нестандартных политик. Набор функций меняется между версиями ПО и уровнями лицензий, поэтому перед покупкой сверяйте конкретную опцию с текущей документацией вендора.
Сравнение с open-source: TrueNAS и Ceph
| Критерий | TrueNAS | Ceph | Коммерческая СХД |
|---|---|---|---|
| Лицензии | Базовая версия бесплатна, платная подписка на поддержку | Открытый код, поддержку покупают у вендоров сборок | Лицензия на ёмкость или на систему |
| Автоматический перенос | Нет в классическом виде: L2ARC, SLOG, special vdev | Через пулы и CRUSH-правила, cache tiering устарел | Встроенные политики, часто с прогнозом |
| Сложность старта | Низкая, настройка через веб-интерфейс | Высокая, нужен опыт работы с кластером | Средняя, настройка с вендором |
| Масштабирование | Один узел, при необходимости пара узлов | Горизонтальное, от нескольких узлов до тысяч | По модели системы, с шагом расширения |
| Гибкость политик | Ограничена возможностями ZFS | Максимальная за счёт правил размещения | Определена вендором |
Ориентир для выбора: небольшая компания с одним-двумя серверами и нагрузкой до нескольких сотен терабайт закрывает задачу на TrueNAS; распределённая инфраструктура с объектным хранилищем и требованием к масштабированию выбирает Ceph; организация с SLA, требованиями регуляторов и бюджетом на поддержку берёт коммерческую систему. Разбор классов СХД, уровней RAID и расчёта IOPS приведён в статье про СХД в 2026 году.
Экономический эффект: как tiering снижает стоимость хранения
Выгода tiering складывается из разницы цен между уровнями. Чем больше доля данных живёт на медленных носителях, тем ниже средняя стоимость терабайта. Ключевое условие: перенос на медленный тир не должен затрагивать данные, к которым обращаются каждый день, иначе экономия обернётся просадкой сервиса.
Расчёт TCO: пример для 100 ТБ
Ниже упрощённый расчёт с условными ценами за терабайт. Он показывает порядок величин, а не прайс конкретного поставщика.
| Уровень | Доля | Объём, ТБ | Цена за ТБ, руб. | Стоимость, руб. |
|---|---|---|---|---|
| NVMe | 10% | 10 | 50 000 | 500 000 |
| SATA SSD | 20% | 20 | 20 000 | 400 000 |
| HDD | 50% | 50 | 5 000 | 250 000 |
| Лента LTO | 20% | 20 | 1 000 | 20 000 |
| Итого с tiering | 100% | 100 | 11 700 | 1 170 000 |
| Все данные на NVMe | 100% | 100 | 50 000 | 5 000 000 |
Разница составляет 3 830 000 руб., или около 77% от варианта с одними NVMe. Если часть холодных данных уже лежит на HDD и архив не нужен, экономия всё равно остается существенной: перенос 50% ёмкости с NVMe на HDD снижает стоимость более чем вдвое.
Упрощение здесь важное: расчёт не включает контроллеры, шасси, дисковые полки, ленточную библиотеку, лицензии и резерв под рост. Сравнение вариантов с учётом этих затрат и задержек приведено в материале про выбор систем хранения по TCO и задержкам.
Скрытые затраты: миграция и управление
- Время инженера на проектирование политик, тесты и разбор инцидентов. Это регулярная статья расходов, а не разовая.
- Нагрузка на сеть и процессор при переносе данных, особенно если тиры находятся на разных узлах.
- Деградация отклика во время миграции и на промахах кэша.
- Ленточная библиотека, носители, ротация и периодическая проверка восстановления стоят денег сверх цены картриджа за терабайт.
- Мониторинг и алертинг: без них ошибка политики обнаруживается по жалобе пользователей.
Итоговая выгода обычно ниже расчётной. Практический ориентир: планируйте экономию в диапазоне 40-60% от максимального расчёта и уточняйте её по пилоту.
Подводные камни: деградация при миграции и сложность прогнозирования
Главный риск - просадка производительности в момент переноса. Перемещение крупного массива данных между уровнями занимает полосу дисковой подсистемы, и задержка на активных запросах растёт. Перенос 1 ТБ с NVMe на HDD в фоне может идти часами и заметно ограничить пропускную способность пула, если не задан лимит скорости.
Вторая проблема - качество прогноза. Система ошибается в двух направлениях: держит на дорогом тире блоки, к которым давно не обращались, или спускает вниз данные с редкими, но критичными запросами. Второй случай хуже: отчёт, который открывают раз в месяц, начинает читаться секундами вместо миллисекунд, и жалоба приходит от руководителя, а не от системы мониторинга.
Третий риск - нестабильность порогов. Без гистерезиса блоки с пограничной активностью перемещаются между тирами постоянно, создавая паразитную нагрузку. Четвертый - нехватка резерва в быстром тире: если горячих данных стало больше, чем ёмкость NVMe, система начинает вытеснять активные блоки.
Как избежать деградации: лучшие практики
- Переносить данные асинхронно и в окна низкой нагрузки.
- Ограничивать скорость миграции, оставляя запас полосы для рабочих запросов.
- Держать 20-30% свободной ёмкости в быстром тире как буфер для всплесков.
- Задавать гистерезис: порог промоушена выше порога демоушена.
- Использовать QoS или приоритеты ввода-вывода, чтобы фоновые задачи не конкурировали с приложениями.
- Проверять политику на копии данных или на небольшом сегменте, прежде чем применять ко всему пулу.
- Следить за ресурсом записи кэш-накопителей: для оценки состояния смотрят наработку, объём записанных данных, ошибки и предупреждения по SMART, и одного процента «здоровья» для решения недостаточно (источник).
Инструменты мониторинга и прогнозирования
- ZFS: arc_summary и arcstat дают hit ratio ARC и L2ARC, zpool iostat -v показывает нагрузку по vdev, zpool status выводит состояние устройств.
- Ceph: ceph osd perf показывает задержки OSD, ceph df - заполнение пулов, дашборд собирает сводку по кластеру.
- Универсальный контур: Prometheus с экспортерами и Grafana для графиков hit ratio, задержек 95-го и 99-го перцентиля, объёма переносов.
- Коммерческие СХД: встроенные отчёты о размещении данных и эффективности тиров.
- SMART для всех кэш-устройств с алертами по износу и ошибкам.
Метрики стоит пересматривать регулярно: раз в квартал сверяйте распределение данных по тирам с исходными допущениями. Нагрузка растёт, и политика, работавшая год назад, может давать обратный эффект.
Заключение: нужен ли tiering в 2026 году
Tiering остаётся рабочим способом сократить стоимость хранения на 40-60% при сохранении отклика на активных данных. Оправдан он там, где есть выраженное холодное большинство: архивы, резервные копии, файловые хранилища, исторические данные. Если рабочая выборка занимает почти весь объём и нагрузка ровная, выгода окажется небольшой, а сложность вырастет.
Порядок действий для пилота:
- Снять baseline: IOPS, пропускная способность, задержки 95-го и 99-го перцентиля, доля чтения и записи по каждому сервису.
- Оценить объём горячей выборки и сравнить с ёмкостью быстрого тира.
- Развернуть тестовый контур: ZFS с L2ARC и SLOG на TrueNAS либо пул Ceph с отдельным CRUSH-правилом.
- Задать простую политику (по возрасту или LRU) и включить мониторинг hit ratio и задержек.
- Через 2-4 недели сравнить метрики с baseline и только затем переносить остальные данные.
Начинайте с малого сегмента и измеряйте результат. Пошаговый алгоритм выбора системы хранения с учётом протоколов, масштабируемости и TCO на 3-5 лет приведён в статье про выбор системы хранения данных.