🥇Реализация 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 сервис. Помимо этого, администратор может создать свой собственный профиль, задав требуемые значения параметров:

Размер блока (Cache Block Size) – 1/2/4 МБ
Число запросов на чтение блока, чтобы он был скопирован в кэш (Populate-on-Read Threshold) – 1..4
Число запросов на запись блока, чтобы он был скопирован в кэш (Populate-on-Write Threshold) – 0..4

Профили можно менять «на лету», но, разумеется, с обнулением содержимого кэша и его новым «прогревом».

Рассматривая принцип работы 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 Type: Customization
Cache Block Size: 4MB
Populate-on-read Threshold: 1
Populate-on-write Threshold: 0

I/O Pattern

Tool: IOmeter V1.1.0
Workers: 1
Outstanding (Queue Depth): 128
Access Specifications: 4KB, 100% Read, 100% Random

В теории, чем больше SSD в кэш пуле, тем выше производительность. На практике это и подтвердилось. Единственное, значительное увеличение количества SSD при малом числе томов не приводит к взрывному эффекту.

Тест 2. SSD кэш в режиме чтение + запись с 2-8 SSD

SSD Cache

I/O Type: Customization
Cache Block Size: 4MB
Populate-on-read Threshold: 1
Populate-on-write Threshold: 1

I/O Pattern

Tool: IOmeter V1.1.0
Workers: 1
Outstanding (Queue Depth): 128
Access Specifications: 4KB, 100% Write, 100% Random

Тот же самый результат: взрывной рост производительности и масштабирование при увеличении количества SSD.

В обоих тестах объем рабочих данных был меньше суммарного объема кэша. Поэтому со временем все блоки скопировались в кэш. И работа уже, по сути, велась с SSD, практически не затрагивая жесткие диски. Целью этих тестов было наглядно показать эффективность прогрева кэша и масштабирования его производительности в зависимости от количества SSD.

Теперь вернемся с небес на землю и проверим более жизненную ситуацию, когда объем данных больше размера кэша. Чтобы тест прошел за вменяемое время (срок «прогрева» кэша сильно возрастает при увеличении размера тома), ограничимся размером тома в 120ГБ.

Тест 3. Эмуляция работы базы данных

SSD Cache

I/O Type: Database
Cache Block Size: 1MB
Populate-on-read Threshold: 2
Populate-on-write Threshold: 1

I/O Pattern

Tool: IOmeter V1.1.0
Workers: 1
Outstanding (Queue Depth): 128
Access Specifications: 8KB, 67% Read, 100% Random

Вердикт

В качестве очевидного вывода, конечно, напрашивается неплохая эффективность использования SSD кэша для повышения производительности любой СХД. Применительно к QSAN XCubeSAN данное утверждение относится в полной мере: функция SSD кэширования реализована превосходно. Это касается поддержки режимов чтения и чтения + записи, гибкой настройки работы для любых сценариев использования, а также итоговой производительности системы в целом. Поэтому за весьма разумную стоимость (цена лицензии соизмерима со стоимостью 1-2 SSD) можно заметно повысить общую производительность.

Источник: habr.com