SSD-кеширование в облаке VMware

В этой статье мы хотим рассмотреть особенности и возможности SSD-кеширования в облаке VMware. Но для начала дадим ряд ключевых определений, чтобы все наши читатели находились на одной волне повествования.

Итак, начнем.

Диск SSD (Solid State Drive) — это твердотельный накопитель, в котором нет подвижных элементов, а для хранения данных используется флеш-память.

Такой диск можно сравнить с большой флешкой, его преимущество заключается в скорости работы, устойчивости к механическим повреждениям, малом энергопотреблении и не только. Обычно дисковая подсистема считается одним из слабых мест как для массово распространяемых приложений, так и для серверов, заточенных под различные задачи и решения. Зачастую администраторы и хостинг-провайдеры задаются вопросом: «Как же ускорить СХД / сервер / работу виртуальной машины с минимальными затратами?».

На данный вопрос есть и такой ответ: с помощью технологии SSD-кеширования.

Остановимся чуть более подробно на технологии SSD-кеширования, которую достаточно часто именуют флеш-технологией, и рассмотрим базовые принципы ее функциональности.

Использование SSD-дисков в качестве кеш (SSD-кеширование) — это технология, позволяющая кешировать как операции чтения, так и операции записи по алгоритмам, схожим с работой кеша жесткого диска и/или оперативной памяти (буферизация запросов ввода-вывода).

При этом блоки данных, запрашиваемые при операциях чтения, копируются с HDD на SSD и в дальнейшем могут быть считаны с SSD. Операции записи при выполнении определенных условий (алгоритм работы кеш) сохраняются на SSD-диски, затем копируются на HDD. Время хранения блоков данных, записанных на SSD, ограничено, как правило, миллисекундами.

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

Безусловным преимуществом данной технологии является прозрачная автоматическая оптимизация использования памяти дисков при неизменности логики приложений, работающих с файлами. Большинство современных жестких дисков используют свой собственный кеш, однако он ничтожно мал по сравнению с SSD-кешем и не настолько эффективен. Последний, в свою очередь, не ограничивается единицами/десятками мегабайтов, а может доходить до нескольких гига- и терабайтов.

Что касается непосредственно данных на жестких дисках (HDD), они характеризуются интенсивностью обращения к ним и формально могут быть названы «холодными» (при достаточно редком к ним обращении) и «горячими» (при достаточно активном использовании). Если данные из кеша долго не запрашивались, они либо удаляются, либо сбрасываются на жесткий диск, а занятое место отдается под более «горячие» данные, которые могут быть затребованы. Таким образом, место в кеше используется более продуктивно.

От общего к частному

Использование флеш-технологий в корпоративных системах хранения данных на сегодняшний день является достаточно частым явлением, а реализация механизмов кеширования, в свою очередь, возможна на различных уровнях. Попробуем разобраться в вариантах реализации, рассмотрев основные особенности и принципы работы.

Большинство облачных хостинг-провайдеров вместо увеличения количества жестких дисков или твердотельных накопителей отдают предпочтение оптимизации производительности уже имеющихся СХД. При этом почти каждый ставит целью повысить пропускную способность подсистем ввода-вывода, уменьшить время ожидания отклика приложений, добиться возможности использовать меньшее число жестких дисков большего объема и снизить затраты в целом.

Использование технологии кеширования позволяет уменьшить зависимость производительности СХД от количества дисков в базовом дисковом массиве, значительно сокращая расходы и достигая вышеозвученные цели, одновременно уменьшая при этом административную нагрузку для настройки производительности.

Как работают с SSD-кешем СХД на примере флеш-технологий NetApp

Напомним, что компания NetApp была первой в области разработки инновационных технологий кеширования (чтение/запись) и по сей день подтверждает свое лидерство в отрасли СХД корпоративного класса с поддержкой флеш-технологий, реализуя при этом многоуровневый подход.

Кеширование на уровне контроллера

NetApp Flash Cache (ранее PAM II) — это технология Flash на уровне контроллера СХД, которая позволяет сохранять «горячие», часто запрашиваемые данные. Основное преимущество этого решения заключается в увеличении производительности для рабочих нагрузок с большим количеством операций произвольного чтения без добавления высокопроизводительных дисковых устройств. За счет высокопроизводительного кеша для операций чтения время ожидания по сравнению с дисковыми накопителями снижается в десять и более раз, а также улучшается пропускная способность ввода-вывода. Способность кешировать огромные объемы активных данных обеспечивает эффективность работы Flash Cache с целым спектром рабочих нагрузок.

Уровень контроллера Flash Cache

Кеширование на уровне дисковой подсистемы (массива)

NetApp Flash Pool технология Flash, использующая гибридную модель: сочетание дисков SSD и HDD в одном дисковом агрегате (наборе дисков). Отличительной особенностью данного решения является кеширование часто запрашиваемых данных на SSD-носитель, а также сохранение данных повторяющейся записи.

Уровень дисковой подсистемы Flash Pool

Кеширование под управлением ОС СХД на уровне сервера

Технология NetApp Flash Accel задействует устройство Flash на стороне сервера (Flash-карта PCI-e или диск SSD) в качестве локального кеша, который разгружает сеть, выполняя часть операций ввода-вывода, и обеспечивает тем самым оптимальную эффективность операций ввода-вывода для самых загруженных приложений, освобождая при этом ресурсы ЦП и памяти на сервере.

Уровень сервера Flash Accel

Рассмотрев различные уровни флеш-технологий, можно сделать следующие выводы: Flash Cache ускоряет процессы получения данных, Flash Pool ускоряет операции случайного чтения и записи на уровне системы хранения данных, а Flash Accel кеширует данные непосредственно на сервере для повышения производительности самых ресурсоемких и требовательных приложений.

Как работает кеширование SSD средствами гипервизора в облаке VMware?

Для начала небольшой экскурс в прошлое. Компания VMware еще с выходом VMware vSphere 5.1 объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, включая возможность использования распределенного кеш на SSD-накопителях локальных дисков серверов ESXi. Данная технология имела рабочее название vFlash и находилась в стадии Tech Preview, превратившись позднее в полноценную функцию vSphere Flash Read Cache (vFRC) платформы VMwarevSphere 5.5. И это вполне рабочий инструмент, который можно использовать в задачах различного уровня.

Технология vFRC призвана повысить эффективность взаимодействия клиентских приложений с дисковой подсистемой за счет кеширования считываемых данных, при этом значительно увеличивая производительность приложений, активно выполняющих операции чтения.

С работает на уровне гипервизора, существенно улучшая при этом производительность виртуальных машин, которые интенсивно используют систему ввода-вывода для операций на чтение. Для кеширования могут быть использованы PCIe флеш-карты и SAS/SATA SSD-диски, локально установленные в хост. Устройства объединяются во флеш-пул, из которого VMDK-дискам виртуальных машин выделяется пространство для кеширования данных.

Напомним, что VMDK (Virtual Machine Disk) — это формат файла, разработанный VMware для использования в качестве образа диска в своих виртуальных машинах.

По уровню производительности SSD-кеш находится между оперативной памятью и обычными дисками.

Обзор архитектуры vFRC

Архитектурная особенность vFRC заключается в следующем:

Когда к VMDK диску с включенным vFRC приходит запрос на чтение, в первую очередь выясняется, есть ли требуемые данные на vFlash.

• Если да, то виртуальная машина получает данные из кеша. Это событие называют «попаданием» (vFRC hit, отмечено на рисунке 1 стрелками фиолетового цвета).
• Если данные отсутствуют в кеше, то ESXi считывает их из VMDK-диска и отдает машине, параллельно записывая данные в кеш. Это событие называется «промахом» (vFRC miss, отмечено на рисунке 1 стрелками оранжевого цвета). Когда приходит запрос на запись, данные записываются на VMDK-диск и асинхронно в кеш.

Что необходимо для vFRC?

Для того чтобы активировать функциональность vFRC, необходимо соблюдение следующих условий:

• Иметь в наличии сконфигурированный узел как минимум с одним SSD или PCIe SSD.
• Использовать vSphere 5.5 (vCenter 5.5 и ESXi 5.5).

Как включается vFRC?

После физического подключения устройства к серверу с ESXi его нужно добавить в vSphere Flash Infrastructure layer. Выполнить это можно на вкладке Virtual Flash Resource Management в настройках хоста.

Для включения vFRC в виртуальной машине в параметрах жесткого диска используется пункт Virtual Flash Read Cache, в котором можно указать объем выделенного пространства для кеширования и размер блока. Размер блока для vFRC следует выбирать в зависимости от того, какими блоками приложение пишет данные на диск. Статистику по блокам для каждого диска можно собрать с помощью утилиты vscsiStats на ESXi.

Особенности конфигурации

При конфигурировании vSphere Flash Read Cache необходимо учитывать следующие особенности:

• На хост-сервере должен быть установлен VMware ESXi 5.5 в редакции Enterprise Plus.
• Настройка и управление vFRC осуществляется только через vSphere Web Client, поэтому требуется VMware vCenter Server.
• Максимальный размер кеша для одного виртуального диска — 400 Гб.
• Максимальные размер кеша на хост — 2 Тб.
• Максимальный размер виртуального диска — 16 Тб.
• Максимальное количество SSD-накопителей, используемых под кеш, — 8.
• Требуется обновить Hardware Version виртуальной машины до 10-й версии.
• Необходимо вручную настраивать кеш для каждого виртуального диска, минимальное значение — 1 Гб.

vFRC на практике

И немного из личного опыта компании. Как мы тестировали SSD-кеш в облаке VMware и с какими подводными камнями столкнулись на практике?

Прежде чем предлагать клиентам какое-либо решение, необходимо убедиться в его полноценной функциональности и работоспособности, а значит — протестировать и понять, что полученный результат в полной мере соответствует заявленным возможностям и удовлетворяет требованиям заказчика. А если появилась новинка, которую еще никто не тестировал и не внедрял, обкатывать ее следует с особо пристальным вниманием. Ведь ни для кого не секрет, что во всем новом могут скрываться недоработки, баги и прочие неприятные мелочи.

Как только компания VMware заявила о новой возможности использования распределенного кеша на SSD-накопителях локальных дисков серверов ESXi, мы решили протестировать эту функциональность. Поскольку данная технология до выхода vSphere 5.5 была в стадии Tech Preview, захотелось протестировать уже доработанное решение. Перед нами стояла задача проверить работоспособность vFRC на сооруженном стенде.

Для тестирования диски SSD подключили к RAID-контроллеру Dell PERC H710P. Создали RAID-0 группы по числу SSD-дисков, в каждой группе по одному диску.

Поскольку RAID-контроллер Dell PERC H710P не умеет предоставлять информацию о физическом типе подключенных к нему носителей, пришлось отмечать вручную, что диски, подключенные к ESXI, являются SSD-дисками. Для этого запустили команду esxcli, как указано на рисунке 5:

После запуска команды в параметрах устройства значение флага “Is SSD” изменилось на “True” — как на рисунке 6:

После чего добавили устройства в vSphere Flash Infrastructure layer. Текущая процедура выполнялась в настройках хоста посредством опции Virtual Flash Resource Management:

Заранее для тестирования SSD-кеша нами был подготовлен стенд с виртуальными машинами на базе ОС Windows Server 2008 R2 x 64 и двумя выделенными под каждую виртуалку VMDK-дисками объемом в 100 Гб каждый:

• VMDK1 определили под ОС,
• VMDK2 — под данные.

Далее в параметрах жесткого диска VMDK2 виртуальных машин включили vFRC, выделив 100 Гб под кеш, определив при этом размер блока в 4 Кб.

Основные шаги конфигурации выполнены. Далее стояла задача проверки работоспособности включенной функциональности. Однако при запуске виртуальных машин одна попросту отказалась стартовать, вместо окна приветствия появился «синий экран» со следующим содержимым:

На остальных виртуальных машинах явных проблем не наблюдалось.

Далее решили воспользоваться инструментами, заточенными под мониторинг кеша SSD, и сравнить результаты тестирования. Для начала в одной из виртуальных машин запустили утилиту FIO, которая генерирует необходимый объем данных на диск VMDK2. Как говорилось ранее, именно он был выделен под полезные данные. Утилита FIO может работать в различных режимах, нас интересовала процедура «случайного считывания». Именно поэтому запустили ее в режиме rand-read.

Примечание: Более подробную информацию об утилите FIO можно найти на сайте.

Утилита FIO подразумевает использование job-файла (или, проще говоря, файла-конфигурации), в котором прописываются параметры под тестирование. Утилита выполняет операции чтения над случайно сгенерированными данными диска VMDK2. В файле конфигурации для чтения фиксируется размер блока считывания (в нашем случае равный 4 Кб). После чего запустили операцию произвольного чтения. Время теста составило 6 часов 46 минут.

Интересовал вопрос: попали ли считываемые данные в кеш и если да, то каков процент попадания?

Для поиска ответа воспользовались графиком производительности виртуального диска машины посредством vSphere WEB client (рисунок 11).

Интересно было посмотреть на следующие счетчики: среднее количество операций вывода в секунду, задержка чтения и счетчик, дающий статистику по использованию кеша. Последний несколько разочаровал, показав очень маленький процент попадания данных в кеш. При среднем количестве операций вывода в секунду (18 689,328) значение для кешируемых данных составило 4439,389, а это всего 23% попадания. Согласно такому статистическому раскладу кеш попросту можно считать неработающим.

Поскольку штатное средство не показало ожидаемых результатов, обратились к другому инструменту: команде esxcli. Она так же работает со статистикой по определенному VMDK-диску с включенной опцией vFRC . Запустили команду со следующими параметрами:

~ # esxcli storage vflsh cache stats get

На рисунке 12 вы можете наблюдать значение cache hit rate, представленное в процентах. Оно показывает так называемое «попадание» vFRC hit, то есть процент данных из кеша, которые используются виртуальной машиной. Рассматриваемую команду пришлось запускать несколько раз, поскольку результаты при очередном запуске оказывались совершенно разными. По одним значением кеш не работал вовсе, как и в первом случае, по другим работал, с процентом попадания данных в кеш, равным 96%.

Не стали останавливаться на полученном, воспользовались еще одной утилитой: esxtop (c отправкой интерактивной команды “u” (u:disk device)) для отображения статистики по использованию кеша. Согласно выведенной на экран информации, получили следующий результат: при «чтении» данные извлекались непосредственно из кеша. Учитывая, что среднее количество операций вывода в секунду составляло 18 689,328, а объем операций для данных, считываемых с SSD-кеша, 18 184,03, процент попадания данных в кеш составил примерно 97%.

Результаты тестов не до конца оправдали наши ожидания, и мы, как крупный сервис-провайдер, партнер VMware, обратились за помощью к коллегам на стороне вендора.

Компания VMware имеет достаточно богатый опыт взаимодействия со своими клиентами и партнерами. В случае обнаружения багов, узких мест и прочих моментов по части функциональности продукта разработчики прикладывают все силы, чтобы внести необходимые исправления.

В результате осенью 2014 года было выпущено обновление VMware ESXi 5.5 Update 2, которое устраняет описанную проблему по «синему экрану» виртуальной машины с операционной системой Windows Server 2008 R2 x64.

Вышедшее обновление, безусловно, нас заинтересовало. Решили протестировать, установив его на рассмотренной ранее тестовой площадке с включенным vFRC. Каков результат? Все виртуальные машины запустились как одна. Ставим «+» в этом тесте и двигаемся в сторону показателей счетчиков. Как и в самом начале тестирования, запустили утилиту FIO в режиме rand-read с используемым ранее файлом конфигурации, после чего запустили операцию произвольного чтения. Счетчики в большинстве своем показывали рабочую статистику и лишь периодически указывали неверные значения. То есть VMware ESXi 5.5 Update 2 не устранил описываемую проблему по отображению статистики vFRC. Несмотря на данный баг, технология vSphere Flash Read Cache, как показала дальнейшая практика применения этой функциональности, существенно повышает производительность виртуальных машин за счет уменьшения показателя latency.

После очередных тестов мы перешли к внедрению технологии SSD-кеширования на хостах в промышленную среду. Сегодня на наших площадках успешно реализовано несколько проектов с использованием vSphere Flash Read Cache для наших особо требовательных к производительности клиентов. Последние, в свою очередь, довольны результатами ускорения работы своих систем и приложений.