Как стать автором
Обновить
11.34
Рейтинг

Реализация SSD кэширования в СХД QSAN XCubeSAN

Блог компании Skilline IT-инфраструктура *Виртуализация *SAN *Хранение данных *

Технологии повышения производительности, основанные на использовании 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 кэша, можно выделить основные операции при работе с ним:







Чтение данных, когда они отсутствуют в кэше


  1. Запрос от хоста поступает в контроллер;
  2. Так как запрашиваемых нет в SSD кэше, они считываются с жестких дисков;
  3. Считанные данные отправляется хосту. Одновременно идет проверка, являются ли эти блоки «горячими»;
  4. Если да, то они копируются в SSD кэш для дальнейшего использования.





Чтение данных, когда они присутствуют в кэше


  1. Запрос от хоста поступает в контроллер;
  2. Так как запрашиваемые данные есть в SSD кэше, они считываются оттуда;
  3. Считанные данные отправляется хосту.





Запись данных при использовании кэша на чтение


  1. Запрос на запись от хоста поступает в контроллер;
  2. Данные записываются на жесткие диски;
  3. Хосту возвращается ответ об успешной записи;
  4. Одновременно проверяется, является ли блок «горячим» (сравнивается параметр Populate-on-Write Threshold). Если да, то он копируется в SSD кэш для последующего использования





Запись данных при использовании кэша на чтение+запись


  1. Запрос на запись от хоста поступает в контроллер;
  2. Данные записываются в SSD кэш;
  3. Хосту возвращается ответ об успешной записи;
  4. Данные из 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) можно заметно повысить общую производительность.
Теги:
Хабы:
Всего голосов 8: ↑7 и ↓1 +6
Просмотры 3.3K
Комментарии Комментировать

Информация

Дата основания
Местоположение
Россия
Сайт
skillproject.ru
Численность
11–30 человек
Дата регистрации