- PVSM.RU - https://www.pvsm.ru -
Технологии повышения производительности, основанные на использовании SSD и широко применяемые в СХД, уже давно изобретены. Прежде всего – это применение SSD в качестве пространства хранения, что на 100% эффективно, но дорого. Поэтому в ход идут технологии тиринга и кэширования, где SSD используются только для наиболее востребованных («горячих») данных. Тиринг хорош для сценариев долговременного (дни-недели) использования «горячих» данных. А кэширование, наоборот, для краткосрочного (минуты-часы) использования. Оба этих варианта реализованы в СХД QSAN XCubeSAN [1]. В данной статье мы рассмотрим реализацию второго алгоритма – SSD кэширования [2].
Суть технологии SSD кэширования – это использование SSD в качестве промежуточного кэша между жесткими дисками и оперативной памятью контроллера. Производительность SSD, конечно же, ниже, чем производительность собственного кэша контроллера, но зато объем на порядок выше. Поэтому получаем некий компромисс между скоростью и объемом.
Показания для использования SSD кэша на чтение:
Показаниями для использования SSD кэша на чтение+запись являются те же причины, за исключением характера операций – смешанный тип (например, файл сервер).
Большинство вендоров СХД используют в своих продуктах SSD кэш только для операций чтения. Принципиальным отличием QSAN [3]от них является возможность использования кэша также и для записи. Для активации функционала 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 кэша, можно выделить основные операции при работе с ним:
Чтение данных, когда они отсутствуют в кэше
Чтение данных, когда они присутствуют в кэше
Запись данных при использовании кэша на чтение
Запись данных при использовании кэша на чтение+запись
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 тома: по одному для каждого сервера.
SSD Cache
|
I/O Pattern
|
В теории, чем больше SSD в кэш пуле, тем выше производительность. На практике это и подтвердилось. Единственное, значительное увеличение количества SSD при малом числе томов не приводит к взрывному эффекту.
SSD Cache
|
I/O Pattern
|
Тот же самый результат: взрывной рост производительности и масштабирование при увеличении количества SSD.
В обоих тестах объем рабочих данных был меньше суммарного объема кэша. Поэтому со временем все блоки скопировались в кэш. И работа уже, по сути, велась с SSD, практически не затрагивая жесткие диски. Целью этих тестов было наглядно показать эффективность прогрева кэша и масштабирования его производительности в зависимости от количества SSD.
Теперь вернемся с небес на землю и проверим более жизненную ситуацию, когда объем данных больше размера кэша. Чтобы тест прошел за вменяемое время (срок «прогрева» кэша сильно возрастает при увеличении размера тома), ограничимся размером тома в 120ГБ.
SSD Cache
|
I/O Pattern
|
В качестве очевидного вывода, конечно, напрашивается неплохая эффективность использования SSD кэша для повышения производительности любой СХД. Применительно к QSAN XCubeSAN [1] данное утверждение относится в полной мере: функция SSD кэширования реализована превосходно. Это касается поддержки режимов чтения и чтения + записи, гибкой настройки работы для любых сценариев использования, а также итоговой производительности системы в целом. Поэтому за весьма разумную стоимость (цена лицензии соизмерима со стоимостью 1-2 SSD) можно заметно повысить общую производительность.
Автор: Skilline
Источник [8]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/virtualizatsiya/301722
Ссылки в тексте:
[1] QSAN XCubeSAN: http://www.qsan.su/goods/sistemyi-xraneniya-dannyix/
[2] SSD кэширования: http://www.qsan.su/soft/san-os-4.0/ssd-keshirovanie-(qcache-2.0).html
[3] QSAN : http://www.qsan.su/
[4] Чтение данных, когда они отсутствуют в кэше;: #1
[5] Чтение данных, когда они присутствуют в кэше;: #2
[6] Запись данных при использовании кэша на чтение;: #3
[7] Запись данных при использовании кэша на чтение + запись.: #4
[8] Источник: https://habr.com/post/432366/?utm_campaign=432366
Нажмите здесь для печати.