К вопросу об SSD-кэшировании

Здравствуйте, дорогие друзья! Сегодня хочу немного поговорить об SSD дисках и хранении данных. Есть много статей на эту тему, но я хочу затронуть тему чуть более специфическую, а именно: «Использование SSD дисков для кэширования данных в СХД».

Какие бывают SSD?

Разновидностей SSD-дисков немало, они отличаются друг от друга по следующим параметрам:

типу подключения: SATA, SAS, U.2 NVME, PCI-e NVME;
типу флеш-памяти: SLC, MLC, TLC и т.п.;
классу: для корпоративного или домашнего использования;
объему: от 128 ГБ до нескольких ТБ;
гарантированному сроку службы;
по скорости доступа на чтение и запись.

Это всего лишь несколько отличительных характеристик, которые важны для выбора SSD-дисков для СХД, в том числе и для целей кэширования.

Как выбирать?

Как я уже писал в предыдущей статье про подход к выбору СХД, в зависимости от вашей задачи на СХД будет создаваться различная нагрузка, которая трансформируется в непосредственную нагрузку на носители. Поскольку носители могут быть организованы в разные RAID-структуры, трансформация вашего входного паттерна нагрузки в непосредственную нагрузку на носитель может быть далеко не прямой. Например, при работе с RAID 5, RAID 6, RAID 7.3, RAID N+M запись на диски ведется чанками, которые не соответствуют размеру блоков, которыми «пишет» инициатор. При модификации части такого чанка необходимо его перечитать, модифицировать и записать обратно.

Если речь идет о случайной записи, то на RAID четности количество записей будет гораздо большим, то есть одна операция ввода-вывода (IO) вызывает аналогичную операцию на всех дисках RAID. Если вы работаете с RAID 0 или 10, нагрузка будет трансформироваться в нагрузку на диски более прямолинейно. Одна IO на массив будет вызывать одну IO на диск в случае RAID 0, и по одной IO на два диска в случае RAID 10.

Кроме того, запись на SSD-диск осуществляется не совсем так, как на вращающийся. Логическая адресация ячеек памяти, доступная пользователю (local block addressing; LBA), не соответствует физической. Если записать один блок данных, а потом еще один, то об их физическом размещении будет «знать» только контроллер диска. Для операционной системы это процесс прозрачный, так как она будет оперировать своими стандартными LBA.

Как известно, физически запись на SSD-диск осуществляется страницами, а очистка – erase-блоками, причем в одном erase-блоке обычно содержатся сотни страниц. Например, страница размером 8KБ и блок размером 1024КБ. Запись на SSD всегда ведется кратно размеру страницы, то есть, если вы записали 4К, вторые 4К страницы останутся не заполнены. При записи следующих 4К будет занята следующая страница.

При перезаписи данных на SSD новые данные пишутся на свободное место, а старые данные помечаются как удаленные.

При работе контроллер диска периодически запускает «сборку мусора», при которой фактически дефрагментирует данные на SSD. Контроллер берет частично пустые страницы и записывает данные в новые страницы, и только когда erase-блок содержит исключительно удаленные или перенесенные данные, он может быть переиспользован для записи данных. Причем для этой операции SSD обычно использует специальный запас свободного места. Чем больше этот запас и менее заметно влияние процесса «сборки мусора» на производительность, тем выше класс SSD и его стоимость.

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

Каков же будет паттерн нагрузки на кэширующий SSD? Тут логика проста. При записи на SSD правильно использовать лог-структурированную запись. Это позволяет снизить износ самого диска и нагрузку на «сборщик мусора», зашитый в контроллер диска. В итоге нагрузка будет следующего вида:

Последовательная запись (за счет лог-структурированной записи) комфортными для SSD блоками;
Случайное/последовательное чтение. Размеры блоков следует анализировать в зависимости от приложения: обычно это 2-16K в случае транзакционных приложений. Перезаписи при этом не происходит, но, если запрашиваемые данные кэшируются, они также вызывают запись на кэширующий SSD.

Количество перезаписей будет в простейшем случае приблизительно соответствовать общему объему считанных и записанных случайных данных, поделенных на полезный объем диска.

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

Выводы:

SSD диск для кэширования должен поддерживать нужное вам количество перезаписей в день, при этом обычно под кэширующие SSD надо выбирать SSD enterprise-класса с большим количеством перезаписей в день – около 10.
Для эффективной работы SSD-кэша вместимость диска должна позволять хранение необходимого объема данных для записи с учетом скорости вытеснения данных на основное хранилище. То есть большой поток случайных данных на запись не должен переполнить диск SSD-кэша по мере вытеснения данных в основное хранилище.
Кроме того, с учетом вышесказанного, диск должен параллельно располагать нужным объемом для хранения локальностей для случайного чтения (одни и те же области данных, которые регулярно запрашиваются случайным образом).
SSD не должен быть узким местом в системе по показателям скорость записи. Отдельный твердотельный диск или группа SSD, объединенная в RAID, должна позволять записывать и считывать данные с необходимой скоростью (в IOps).

В RAIDIX 4.4 уже есть возможность использовать SSD-кэширование случайного чтения. В RAIDIX 4.5 будет также доступна опция SSD-кэширования случайной записи, что позволит улучшить производительность при работе со смешанными и случайными паттернами. В этой же версии мы планируем использовать SSD не только для кэширования, но и в качестве основного носителя информации.

Следите за нашими обновлениями и техническими новинками!