AI Block Dev: интеллектуальный блочный кэш

Обзор

AI Block Dev - это исследовательский проект в области систем хранения: интеллектуальный блочный кэш и слой управления многоуровневым хранением. Его задача не просто "держать популярные блоки в кэше", а заранее оценивать, какие регионы данных скоро понадобятся, насколько дорог промах по ним и на каком уровне хранения их выгоднее держать: в DDR, NVMe, SSD или оставить на HDD.

В отличие от классических LRU/LFU-политик, проект опирается на вероятностную модель и разделяет быстрый контур данных от более тяжелого контура управления. За счет этого идея остается реалистичной для инфраструктурного продукта: ускорение не должно ломать корректность хранения, а любая ошибка модели обязана безопасно переводить систему на базовую политику.

Зачем нужен проект

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

Проект решает эту задачу как программный ускоритель:

• ускоряет чтение и повторный доступ к горячим данным;
• сглаживает всплески записи и снижает давление на нижележащий слой хранения;
• уменьшает p95/p99 latency для чувствительных сценариев;
• позволяет использовать небольшой быстрый уровень как интеллектуальный ускоритель большого HDD-массива;
• создает основу не только для ускорения, но и для воспроизведения, отката и выявления аномального поведения.

Как помогает в коммерческом продукте

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

• в локальных и гибридных системах хранения, где нужно продлить жизнь существующим HDD-массивам;
• в системах виртуализации и резервного копирования, где нагрузка смешанная и простые кэш-политики быстро деградируют;
• в продуктовых базах данных и аналитических системах, где важны хвостовые задержки;
• в OEM- и встраиваемых решениях хранения, где нужен отличающий признак без переписывания всего стека хранения.

Для бизнеса ценность в том, что система продает не просто "кэш", а более выгодную экономику: меньше CAPEX на полную миграцию в быстрые носители, лучше использование уже купленного железа, стабильнее SLA и больше платных функций поверх того же ядра.

Как проект может зарабатывать деньги

Монетизация у такого решения естественно строится вокруг корпоративных систем хранения:

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

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

Компоненты

• AI Cached Block Driver: концепция прозрачного блочного драйвера, который принимает решения о размещении, предзагрузке, вытеснении и буферизации записи;
• cpp_baesian: C++20-ядро вероятностного вывода с BayesianNetwork, DynamicBayesianNetwork, FactorTable и JunctionTree;
• Контур воспроизведения и отката: архитектурная связка с журналированием и последующим воспроизведением сценариев;
• QEMU/devcontainer-лаборатория: среда для безопасных экспериментов с блочными устройствами и тестовыми конфигурациями.

Как он устроен

Архитектурно проект делится на два независимых контура.

Контур данных работает на горячем пути ввода-вывода. Он принимает read/write, переводит LBA в region, смотрит метаданные, быстро достает снимок признаков, запускает вывод и превращает результат в конкретное действие: положить блок в DDR, отправить в NVMe, сделать предзагрузку, удержать грязный регион или наоборот обойти кэш.

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

Базовая единица принятия решений - не файл и не сектор, а region данных. Для каждого региона система оценивает признаки вроде:

• вероятности скорого повторного чтения;
• вероятности read-after-write;
• последовательности доступа и полезности предзагрузки;
• стоимости промаха;
• давления на текущий уровень хранения;
• риска аномального или вредоносного паттерна.

Дальше вероятности переводятся в управляющие решения:

• promote_to_ddr;
• promote_to_nvme;
• demote_to_ssd;
• write_allocate или write_around;
• keep_dirty или flush_early;
• prefetch_neighbors;
• fallback_to_baseline, если модель не укладывается в budget или дает сомнительный результат.

Ключевые идеи

• Предиктивное многоуровневое размещение вместо реактивного кэширования по LRU/LFU
• Разделение контура данных и контура управления, чтобы AI не ломал горячий путь
• Безопасный возврат к базовой политике как обязательная часть архитектуры
• Воспроизведение и откат как встроенные свойства системы, а не внешняя надстройка
• Единая ткань телеметрии для ускорения, наблюдаемости и аналитики безопасности

Технический стек

• Язык: C++20
• Сборка: CMake
• ML/вывод: байесовские сети, JunctionTree, факторные таблицы
• Виртуализация и эксперименты: QEMU, Docker, devcontainer
• Документация: подробные архитектурные и продуктовые markdown-документы