Реализация SSD кэширования в СХД QSAN XCubeSAN
Технологии повышения производительности, основанные на использовании SSD и широко применяемые в СХД, уже давно изобретены. Прежде всего — это применение SSD в качестве пространства хранения, что на 100% эффективно, но дорого. Поэтому в ход идут технологии тиринга и кэширования, где SSD используются только для наиболее востребованных («горячих») данных. Тиринг хорош для сценариев долговременного (дни-недели) использования «горячих» данных. А кэширование, наоборот, для краткосрочного (минуты-часы) использования. Оба этих варианта реализованы в СХД QSAN XCubeSAN. В данной статье мы рассмотрим реализацию второго алгоритма — SSD кэширования.
Суть технологии SSD кэширования — это использование SSD в качестве промежуточного кэша между жесткими дисками и оперативной памятью контроллера. Производительность SSD, конечно же, ниже, чем производительность собственного кэша контроллера, но зато объем на порядок выше. Поэтому получаем некий компромисс между скоростью и объемом.
Показания для использования SSD кэша на чтение:
- Преобладание операций чтения над операциями записи (чаще всего характерно для баз данных и web приложений);
- Наличие узкого места в виде производительности массива жестких дисков;
- Объем востребованных данных менее объема SSD кэша.
Показаниями для использования SSD кэша на чтение+запись являются те же причины, за исключением характера операций — смешанный тип (например, файл сервер).
Большинство вендоров СХД используют в своих продуктах SSD кэш только для операций чтения. Принципиальным отличием QSAN от них является возможность использования кэша также и для записи. Для активации функционала SSD кэширования в СХД QSAN требуется приобретение отдельной лицензии (поставляется в электронном виде).
SSD кэш в XCubeSAN физически реализован в виде отдельных SSD кэш пулов. В системе их может быть до четырех. Каждый пул, разумеется, использует свой собственный набор SSD. И уже в свойствах виртуального диска мы определяем, будет ли он использовать кэш пул и какой именно. Включение и отключение использования кэша для томов можно производить в режиме online без останова ввода/вывода. Также на «горячую» можно добавлять SSD в пул и убирать их оттуда. При создании SSD кэша пула необходимо выбрать, в каком режиме он будет работать: только чтение или чтение+запись. От этого зависит его физическая организация. Раз кэш пулов может быть несколько, то функционал у них может быть разный (то есть в системе могут быть одновременно кэш пулы для чтения и для чтения+записи).
В случае использования кэш пула только для чтения он может состоять из 1–8 SSD. Диски не обязательно должны быть одного объема и одного вендора, так как они объединяются в структуру NRAID+. Все SSD в пуле используются совместно. Система самостоятельно старается распараллелить поступающие запросы между всеми SSD для достижения максимальной производительности. В случае выхода из строя одного из SSD ничего страшного не произойдет: ведь кэш содержит лишь копию данных, хранящихся на массиве из жестких дисков. Просто объем доступного SSD кэша уменьшится (или станет нулевым в случае использования изначального SSD кэша из одного накопителя).
Если же кэш используется для операций чтения + записи, то количество SSD в пуле должно быть кратно двум, так как содержимое зеркалируется на парах накопителей (используется структура NRAID 1+). Дублирование кэша необходимо из-за того, что в нем могут содержаться данные, которые еще не успели записаться на жесткие диски. И в этом случае выход из строя SSD из кэш пула привел бы к потере информации. В случае же NRAID 1+ отказ SSD просто приведет к переводу кэша в состояние работы «только на чтение» со сбросом незаписанных данных на массив из жестких дисков. После замены неисправного SSD кэш вернется в свой первоначальный режим работы. Кстати, для большей безопасности кэшу, работающему на чтение + запись, можно назначить выделенные hot spare.
При использовании функции SSD кэширования в XCubeSAN есть ряд требований по объему памяти контроллеров СХД: чем больше системной памяти, тем больший объем кэш пула будет доступен.
В отличие опять же от большинства производителей СХД, которые в качестве настройки SSD кэша предлагают лишь опцию включить/выключить, QSAN предоставляет бОльшие возможности. В частности, можно выбрать режим работы кэша в зависимости от характера нагрузки. Имеются три предустановленных шаблона, наиболее близкие по своей работе к соответствующим сервисам: база данных, файловая система, web сервис. Помимо этого, администратор может создать свой собственный профиль, задав требуемые значения параметров:
|
|
Профили можно менять «на лету», но, разумеется, с обнулением содержимого кэша и его новым «прогревом».
Рассматривая принцип работы SSD кэша, можно выделить основные операции при работе с ним:
Чтение данных, когда они отсутствуют в кэше
- Запрос от хоста поступает в контроллер;
- Так как запрашиваемых нет в SSD кэше, они считываются с жестких дисков;
- Считанные данные отправляется хосту. Одновременно идет проверка, являются ли эти блоки «горячими»;
- Если да, то они копируются в SSD кэш для дальнейшего использования.
Чтение данных, когда они присутствуют в кэше
- Запрос от хоста поступает в контроллер;
- Так как запрашиваемые данные есть в SSD кэше, они считываются оттуда;
- Считанные данные отправляется хосту.
Запись данных при использовании кэша на чтение
- Запрос на запись от хоста поступает в контроллер;
- Данные записываются на жесткие диски;
- Хосту возвращается ответ об успешной записи;
- Одновременно проверяется, является ли блок «горячим» (сравнивается параметр Populate-on-Write Threshold). Если да, то он копируется в SSD кэш для последующего использования
Запись данных при использовании кэша на чтение+запись
- Запрос на запись от хоста поступает в контроллер;
- Данные записываются в SSD кэш;
- Хосту возвращается ответ об успешной записи;
- Данные из SSD кэша в фоновом режиме записываются на жесткие диски ;
Проверка в деле
2 сервера (CPU: 2 x Xeon E5–2620v3 2.4Hz / RAM: 32GB) подключены двумя портами через Fibre Channel 16G напрямую к СХД XCubeSAN XS5224D (16GB RAM/контроллер).
Использовались 16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s, объединенные в RAID5 (15+1), для массива с данными и 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, 100GB, SAS 12Gb/s в качестве кэша
Были созданы 2 тома: по одному для каждого сервера.
Тест 1. SSD кэш только на чтение с 1–8 SSD
|
SSD Cache
|
I/O Pattern
|
В теории, чем больше SSD в кэш пуле, тем выше производительность. На практике это и подтвердилось. Единственное, значительное увеличение количества SSD при малом числе томов не приводит к взрывному эффекту.
Тест 2. SSD кэш в режиме чтение + запись с 2–8 SSD
|
SSD Cache
|
I/O Pattern
|
Тот же самый результат: взрывной рост производительности и масштабирование при увеличении количества SSD.
В обоих тестах объем рабочих данных был меньше суммарного объема кэша. Поэтому со временем все блоки скопировались в кэш. И работа уже, по сути, велась с SSD, практически не затрагивая жесткие диски. Целью этих тестов было наглядно показать эффективность прогрева кэша и масштабирования его производительности в зависимости от количества SSD.
Теперь вернемся с небес на землю и проверим более жизненную ситуацию, когда объем данных больше размера кэша. Чтобы тест прошел за вменяемое время (срок «прогрева» кэша сильно возрастает при увеличении размера тома), ограничимся размером тома в 120ГБ.
Тест 3. Эмуляция работы базы данных
|
SSD Cache
|
I/O Pattern
|
Вердикт
В качестве очевидного вывода, конечно, напрашивается неплохая эффективность использования SSD кэша для повышения производительности любой СХД. Применительно к QSAN XCubeSAN данное утверждение относится в полной мере: функция SSD кэширования реализована превосходно. Это касается поддержки режимов чтения и чтения + записи, гибкой настройки работы для любых сценариев использования, а также итоговой производительности системы в целом. Поэтому за весьма разумную стоимость (цена лицензии соизмерима со стоимостью 1–2 SSD) можно заметно повысить общую производительность.
