Мы наш, мы новый мир построим
Решение программно управляемого флеш (Software-Enabled Flash, SEF) предложила компания KIOXIA. В первую очередь, она нацелена на использование в центрах обработки данных, но может успешно работать и в меньших масштабах — например, в ИТ структуре предприятия. SEF — набор утилит (API) и аппаратная структура для глубокого управления флеш со стороны хост-контроллера, разрешающая целый комплекс проблем флеш накопителей.
Предпосылки появления Software-Enabled Flash
Сложившаяся в эпоху безраздельного царствования HDD на рынке хранилищ система интерфейсов и структуры контроллеров накопителей вызывает все больше раздражения у архитекторов IT систем.
В области интерфейсов уже произошла революция. С нуля, без длинного шлейфа накопленного за десятилетия барахла, создан и принят как производителями, так и потребителями NVMe. Интерфейс NVMe изначально «заточен» на работу с флеш-накопителями с учетом особенностей их функционирования. Результат — увеличение пропускной способности канала передачи и резкое сокращение задержек.
Очередь дошла до перераспределения обязанностей между хост-контроллером интерфейса и контроллером накопителя. Флеш накопитель кардинально отличается от жесткого диска внутренним устройством, но для хост-контроллера и для системы он по-прежнему «HDD». Для периода выхода на рынок это была вынужденная мера, приходилось подстраиваться под имевшиеся в наличии интерфейсы и сложившуюся внутреннюю структуру сервера/хранилища. Революционная ситуация назрела с массовым и повсеместным проникновением флеш. Слишком большие накладные расходы в дорогостоящих накопителях еще как-то терпелись при небольшом их количестве, но в масштабных системах эффективность использования флеш начинает играть заметную роль.
Новый подход позволяет оптимизировать систему средствами, недоступными при использовании традиционных подходов к хранению. Он дает архитекторам возможность более тонко управлять своим хранилищем и определять его поведение, предоставляя следующие функции:
• Контроль задержки для таких алгоритмов, как сборка мусора и выравнивание износа.
• Хост-контроль над физическим размещением и изоляцией данных
• Хост-контроль изоляции рабочей нагрузки с помощью определяемых системой виртуальных устройств и доменов QoS
• Контроль физического адреса устраняет задержку на трансляцию логического адреса LBA в физический FTL (Flash Translation Layer)
• Абстрагирование различий между поколениями и поставщиками флэш-памяти.
За что боремся
Предсказуемость
Для хост-контроллера и файловой системы внутренняя кухня SSD накопителя — «черный ящик». Контроллер накопителя сам определяет — где физически будет храниться информация, обеспечивает ее распределение для выравнивания износа ячеек памяти, «собирает мусор»,… В общем, делает много чего с его, контроллера, точки зрения, полезного. И делает все это одинаково, без разбора, для всех потребителей и всех приложений системы. В какой момент контроллер займется служебной процедурой и какая задержка при этом возникнет — система не знает. Jitter (дрожание или телепание) основных характеристик — не очень полезное явление в нагруженных системах.
Блочная природа SSD определяет огромную разницу в процедурах чтения и записи накопителя.
Чтение — «конек» флеш накопителя. Это относительно простая процедура, но даже она подвержена влиянию внутренних, скрытых работ контроллера SSD.
С записью все еще хуже. В НЖМД можно переписать измененные данные. NAND память SSD разбита на страницы, объединенные в блоки. SSD записывает целиком страницу с измененными данными в блок со свободными страницами, а исходную помечает недействительной.
Наглядный график разброса производительности приводится в блоге OCZ, вошедшей впоследствии в состав Toshiba (https://habr.com/ru/company/ocz/blog/393131/). Показана статистика производительности в МБ/с во времени по мере записи SSD емкостью 200ГБ. Диапазон значений колеблется от 0,4 до 100 (разница в 250 раз!) при среднем 27МБ/с.
Коэффициент полезного использования флеш
Ни для кого не секрет — что SSD отдает пользователю лишь часть физически имеющейся емкости флеш. Служебная область (spare area) служит для подмены неисправных блоков и активно используется в процессе сборки мусора. Скрытая от операционной системы область также участвует в процедуре выравнивания износа ячеек. Размер spare area, а точнее — его доля от общей емкости накопителя прямо влияет на два основных показателя SSD — его производительность и выносливость.
Следующие графики, заимствованные из вышеупомянутого блога OCZ, показывают изменение производительности SSD (IOPS) во времени для трех размеров служебной области: 7%, 12% и 25%
Разброс значений (Jitter) резко уменьшается с увеличением доли служебной области. Но ее увеличение означает, фактически, пропорциональное увеличение стоимости хранения на флеш накопителях в пересчете на полезную емкость.
Гибкость использования SSD
Можно с большой долей уверенности подобрать оптимальные по характеристикам флеш накопители под конкретную задачу при условии, что покупаемая система будет заниматься именно этой задачей впоследствии. Но даже в этих условиях достаточно четкого запроса возникает вопрос — какую емкость системы хранения закладывать? Сразу на годы вперед — как обычно делается? Увеличивается стоимость приобретения. При том, расчеты необходимого пространства на многолетнюю перспективу, как правило, оказываются ошибочными. Логичнее и выгоднее дополнять хранилище накопителями по мере необходимости — эту парадигму маркетологи используют уже десятки лет, но на практике мало кто ее использует. Отличная идея, но нет уверенности в том — что именно эти или близкие по характеристикам накопители будут доступны на рынке в то время, когда потребуется расширение. Возникает вероятность несовместимости различных SSD в одной системе или ухудшения интегральных характеристик системы из-за микса накопителей с разными параметрами.
Далее. Задав размер области spare в накопителях можно получить оптимальное соотношение параметров SSD под характер нагрузки, свойственный задаче (приложению). Но как поступить, если система хранения работает на несколько существенно отличающихся gпо профилю доступа к хранилищу задач? Ведь установки действуют на весь флеш накопитель, значит придется ориентироваться на самый тяжелый вариант, что неэффективно. В масштабных системах и датацентрах ситуация усугубляется. Содержать отдельные хранилища под каждую конкретную задачу или под каждый тип задач — безумие. Требуется масштабируемое хранилище, хорошо справляющееся с постоянно меняющимся набором задач и требований.
На рынке присутствует масса производителей SSD. У каждого из них по нескольку семейств накопителей разного класса. Каждое семейство, в свою очередь, объединяет несколько моделей. Все они обладают индивидуальными наборами свойств. При этом, производителей собственно флеш микросхем и их типов значительно меньше (с уходом Intel осталось всего пять).
Зоопарк возникает за счет разнообразных контроллеров (производителей контроллеров порядка двадцати) и микрокода. Еще одно измерение в этом многомерном кубе добавляют разнообразие типов ячеек NAND микросхем — MLC, TLC, QLC.
Выход есть! Это Software-Enabled Flash
Подход Software-Enabled Flash (SEF) позволяет одним махом разрубить множество узлов.
Цель Software-Enabled Flash технологии — сделать флеш память управляемой, предсказуемой и более защищенной вне зависимости от конкретного производителя устройства хранения и используемой технологии производства.
Низкоуровневые функции SSD, скрытые в настоящее время от контроллера хранилища и операционной системы, как то: физическое расположение данных в микросхемах NAND, процессы сборки мусора и выравнивания износа ячеек, защита данных переносятся в контроллер хранилища. В упрощенном контроллере накопителя SEF остаются необходимые блоки управления: PCIe интерфейс с функцией прямого доступа к памяти DMA; специфическая логика управления флеш и контроля состояния ячеек; блок генерации и проверки кода коррекции ошибок ECC. Контроллер может содержать DRAM с соответствующим блоком управления (Device-Side DRAM) или необходимая оперативная память может располагаться на стороне хост-контроллера (Host-Side DRAM).
Блок-схема контроллера SEF приводится ниже:
Контроллер SEF, при этом, приобретает ранее отсутствующий управляющий функционал. Это физическая изоляция набора страниц, или изоляция рабочей нагрузки, управление уровнем обслуживания (QoS) и управление приоритетами запросов.
* Примечание. Из имеющихся материалов не понятно — будут ли эти функции реализованы программно с полным управлением со стороны хоста или SEF контроллер накопителя будет содержать соответствующие блоки, управляемые командами хоста.
Изоляция рабочей нагрузки
Отсутствие контроля за размещением данных и изоляцией рабочей нагрузки — основные проблемы, с которыми сталкиваются приложения. Программистам и архитекторам предоставляются инструменты SEF, которые определяют и организуют флеш-память на физическом уровне вплоть до уровня кристалла. API назначает конфигурации кристалла и канала одному или нескольким «виртуальным устройствам» (см. рисунок ниже), которые позволяют приложениям определять, какой кристалл использовать в одном или нескольких заранее заданных каналах. Пользователи могут гибко настраивать эти виртуальные устройства в зоны, создавая аппаратную изоляцию, исключающую влияние ввода-вывода из одного домена в другой.
На рисунке показаны варианты объединения контроллером SEF кристаллов (Die) NAND флеш в виртуальные устройства. Виртуальные устройства 0 и 1 объединяют все кристаллы трех (0) или двух (1) каналов. Другой вариант объединения — часть кристаллов из нескольких каналов (устройства 2 и 3).
Управление уровнем обслуживания (QoS)
Домены QoS формируются в пределах изолированных виртуальных устройств и развертываются как фактическое пространство пользователя в блоках SEF (см. рисунок ниже). Виртуальное устройство может иметь один или несколько доменов QoS, управляющихся программными приложениями независимо. Технология позволяет реализовать уровни трансляции флэш-памяти и алгоритмы сбора мусора в каждом домене независимо от других доменов QoS.
Приоретизация запросов
Взвешенная организация очередей (Weighted fair queueing, WFQ) — это алгоритм планирования сети на основе упаковщика, который предусматривает присвоение разных приоритетов полосы пропускания различным типам трафика. Разным типам потоков при принятии решений о планировании назначается разный вес. Например, различные веса могут быть присвоены потокам трафика к различным виртуальным устройствам, установленным на SSD с помощью SEF. Это позволит удовлетворить различные уровни обслуживания.
Увеличивается производительность системы и предсказуемость поведения системы хранения для критических задач.
Управляющее ПО
SEF сопровождается программными инструментами API, содержащими открытый исходный код, аналогичный комплекту разработки программного обеспечения (SDK).
https://github.com/kioxiaamerica
Этот исходный код демонстрирует, как флэш-память может быть развернута через хост контроллер. Набор ПО включает образец традиционного блочного драйвера, который позволит реализации SEF выглядеть как SSD в системе.
Текущее состояние проекта
Пока SEF — это частный проект Kioxia, нет никаких подтверждений принятия его другими производителями. С переносом части функций из контроллера SSD в хост-контроллер согласны все. SNIA принял стандарты Zoned Storage, принципы которого замечательно согласуются и во многом перекликаются с SEF. Есть отсылки на имплементацию Zoned Namespaces в SEF. Kioxia называет его «Nameless Mechanism». Читать больше о зонированных SSD.
Kioxia выложил открытую библиотеку утилит, поддерживающих Software-Enabled Flash. Аппаратная составляющая еще официально не представлена.
По материалам:
https://business.kioxia.com/en-us/memory/sef.html
https://www.snia.org/educational-library/unlocking-potential-flash-new-open-source-software-enabled-flash™-api-2020