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







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


    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) можно заметно повысить общую производительность.
    Skilline
    Компания

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое