Базовые элементы Flash Virtualization Platform (FVP), часть 2. Использование собственной платформы или файловой системы

Одна из тем, которую я обсуждал с Satyam и Murali Vilayannur, была файловая система, которая используется для хранения данных на флеш-устройствах. Следует помнить о следующих примечательных фактах: Satyam создал VMFS3, Murali был ведущим разработчиком VMFS5. С этой точки зрения, казалось бы, использование VMFS очевидно. Однако большим сюрпризом для меня оказался тот факт, что для флеш-устройств мы не используем VMFS, еще большим сюрпризом стало то, что мы вообще не используем файловую систему.

Почему не VMFS?
Файловые системы предоставляют возможности, которые не требуются и иногда даже конфликтуют с требованиями платформы, обрабатывающей активный ввод-ввывод на флеш-устройствах. Одна из самых больших проблем использования файловой системы, аналогичной VMFS, на флеш-устройстве состоит в том, что она оптимизирована для SAN-систем хранения и их моделей управления данными; Satyam написал статью об этом для ACM во время работы в VMware. К сожалению, это делает файловую систему неподходящим инструментом для задач FVP.

Файловые системы прямой адресации перегружают флеш-устройства, сокращая срок их службы, не оптимальным образом обрабатывают произвольные операции ввода-вывода, испытывают на прочность свои (часто весьма хрупкие) алгоритмы сбора мусора, и их объекты (файлы и каталоги) меньше подходят для ускорений на уровне виртуальных машин и управления качеством сервиса, что является чрезвычайно важным для задач FVP. Следующий раздел подробно раскроет проблему управления данными на флеш-устройствах, пока же краткий вывод: если вам дорого ваше флеш-устройство, не помещайте на него файловую систему прямой адресации.

Файловые системы также предоставляют возможности, которые значительно превосходят потребности FVP. Например, дисковые блокировки. VMFS имеет продвинутый менеджер распределенных блокировок, который управляет доступом разных хостов ESXi к дискам. FVP управляет локальными дисками хоста и не требует блокировок на других хостах, как результат, менеджер распределенных блокировок становится абсолютно лишним. То же самое можно сказать про POSIX-совместимость и распределенные транзакции. И так далее.

Низкоуровневые операции с флеш-памятью
Вот пример, чем запись на флеш-устройства принципиально отличается от записей на жесткие диски. Флеш не может перезаписать существующие данные. Данные во флеш-память могут быть записаны только на пустую страницу. Особенностью флеш-памяти является то, что запись может производиться страницами, а стирание -  только блоками. Что такое страница и что такое блок? Флеш хранит данные в ячейках; ячейки объединены в страницы (4 КБ); страницы сгруппированы в блоки. Большинство производителей объединяют 128 страниц в один блок. Если нужно стереть страницу, то нужно стереть весь блок. Все необходимые данные из других страниц должны быть сохранены где-то еще. Широко известно, что флеш-устройства имеют ограниченное число циклов записи и стирания.

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

Управление износом
Обратите внимание, для простоты я принял решение показать 9 страниц в одном блоке вместо 128 страниц на блок.

Начнем с процесса управления износом. В этом примере приложение уже создало данные и записало их в страницы A, B и C в блоке 1 (Шаг 1). Поступают новые данные (Шаг 2), которые записываются на страницы D, E, и F. Приложение обновляет предыдущие данные (A-C) и вместо использования предыдущих страниц флеш-устройство продолжает использовать новые страницы. Эти новые данные помечены как A-1, B-1 и C-1. Распределение записей как можно более равномерно называется "управление износом". Старые страницы теперь помечены как просроченные.

Сборка мусора и множественная запись
В этом примере блок A заполнен, что случится, если место, доступное пользователю для записи, закончилось и поступают новые данные?

Флеш скопирует актуальные данные в пустые ячейки. Актуальные данные в блоке считываются и записываются в другой блок. Просроченные данные останутся в своих страницах и будут стерты вместе с остальными страницами блока. Этот процесс называется "сборка мусора".

Сборка мусора - это прекрасно, но множественная запись, возникающая при его работе, причиняет значительный ущерб флеш-устройствам. Для того, чтобы записать 3 страницы, флеш-устройство должно считать 6 страниц и записать эти 6 страниц в другое место до того, как будет способно записать новые данные. И не забывайте о цикле стирания. Предположите сценарий, в котором диск заполнен полностью, куда мы (временно) переместим данные до записи новых данных? В моей схеме я добавил блок B для такого варианта. Для того, чтобы проделать это в реальной ситуации (при использовании файловой системы), нужно выделить избыточное пространство, зарезервированное контроллером флеш.

Избыточное пространство
Флеш-емкость может быть зарезервирована для процессов, управляемых контроллером флеш. Это может быть сделано как производителем флеш-устройства, так и пользователем. К примеру, когда вы покупаете 160 Гб флеш PCIe ускоритель, в действительности, вы приобретаете карту на 192 Гб. 160 Гб доступны для пользователя и 32 Гб зарезервированы дополнительно для операций на уровне контроллера флеш, таких как сборка мусора, коррекция ошибок и прошивка контроллера. При покупке непромышленного SSD-диска вы обычно получаете небольшое зарезервированное избыточное пространство. Форматируя данное флеш-устройство в какую-либо файловую систему, следует помнить о таких особенностях и, возможно, зарезервировать дополнительное место за пределами доступной к использованию емкости. В настоящее время отсутствуют стандартизованные рекомендации по масштабированию, так что придется делать выбор на основании собственного опыта. В худшем случае, вы окажетесь с фрагментированным диском и SSD придется постоянно переносить данные для записи новых. Представьте себе детей, играющих в пятнашки, только схема перемещений немного сложнее.

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

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

Динамически распределяемая емкость между виртуальными машинами
Благодаря глубокой интеграции с VMkernel, FVP может отслеживать блоки данных и определять читает или записывает их виртуальная машина. Независимо отслеживая такие операции, платформа может масштабировать буферы чтения и записи в пространстве, выделенном для виртуальной машины. FVP может кэшировать или удалить из кэша произвольный набор данных виртуальной машины. Напротив, политика эвакуации данных на традиционной файловой системе для флеш-устройства будет неоптимальна и приведет к множественным перезаписям, т.к. файловая система может дописывать данные только в конец файла или удалать блоки так же с конца.

Это также означает, что вам не нужно назначать статическую конфигурацию пространства кэша для каждой виртуальной машины, как это было бы в случае использования файловой системы с прямой адресацией. Это было прекрасным решением для нас; пользовательский опыт от продукта должен быть максимально интуитивным.

Цитирую нашего менеджера продукта Bala: "Элегантность продукта, по моему мнению, в том, что он выполняет основные задачи, НЕ требуя от пользователя каких-то новых или необычных действий".

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

Оригинальная статья.

С 2016 года FVP снят с продажи.