Компания VMware еще с выходом VMware vSphere 5.1 объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, включая возможность использования распределенного кеш на SSD-накопителях локальных дисков серверов ESXi. Данная технология имела рабочее название vFlash и находилась в стадии Tech Preview, превратившись позднее в полноценную функцию vSphere Flash Read Cache (vFRC) платформы VMware vSphere 5.5. И это вполне рабочий инструмент, который можно использовать в задачах различного уровня.
Технология vFRC призвана повысить эффективность взаимодействия клиентских приложений с дисковой подсистемой за счет кеширования считываемых данных, при этом значительно увеличивая производительность приложений, активно выполняющих операции чтения.
Flash Read Cache работает на уровне гипервизора, существенно улучшая при этом производительность виртуальных машин, которые интенсивно используют систему ввода-вывода для операций на чтение. Для кеширования могут быть использованы PCIe флеш-карты и SAS/SATA SSD-диски, локально установленные в хост. Устройства объединяются во флеш-пул, из которого VMDK-дискам виртуальных машин выделяется пространство для кеширования данных.
Напомним, что VMDK (Virtual Machine Disk) — это формат файла, разработанный VMware для использования в качестве образа диска в своих виртуальных машинах.
По уровню производительности SSD-кеш находится между оперативной памятью и обычными дисками.
Обзор архитектуры vFRC
Архитектурная особенность vFRC заключается в следующем:
Когда к VMDK диску с включенным vFRC приходит запрос на чтение, в первую очередь выясняется, есть ли требуемые данные на vFlash.
- Если да, то виртуальная машина получает данные из кеша. Это событие называют «попаданием» (vFRC hit).
- Если данные отсутствуют в кеше, то ESXi считывает их из VMDK-диска и отдает машине, параллельно записывая данные в кеш. Это событие называется «промахом» (vFRC miss). Когда приходит запрос на запись, данные записываются на 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-дисками. Для этого запустили команду esxcl:
После запуска команды в параметрах устройства значение флага “Is SSD” изменилось на “True”:
После чего добавили устройства в 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 можно найти на сайте http://freecode.com/projects/fio.
Утилита FIO подразумевает использование job-файла (или, проще говоря, файла-конфигурации), в котором прописываются параметры под тестирование. Утилита выполняет операции чтения над случайно сгенерированными данными диска VMDK2. В файле конфигурации для чтения фиксируется размер блока считывания (в нашем случае равный 4 Кб). После чего запустили операцию произвольного чтения. Время теста составило 6 часов 46 минут.
Интересовал вопрос: попали ли считываемые данные в кеш и если да, то каков процент попадания?
Для поиска ответа воспользовались графиком производительности виртуального диска машины посредством vSphere WEB client.
Интересно было посмотреть на следующие счетчики: среднее количество операций вывода в секунду, задержка чтения и счетчик, дающий статистику по использованию кеша. Последний несколько разочаровал, показав очень маленький процент попадания данных в кеш. При среднем количестве операций вывода в секунду (18 689,328 Кб) значение кешируемых данных составило 4439,389 Кб, а это всего 23% попадания. Согласно такому статистическому раскладу кеш попросту можно считать неработающим.
Поскольку штатное средство не показало ожидаемых результатов, обратились к другому инструменту: команде esxcli. Она так же работает со статистикой по определенному VMDK-диску с включенной опцией vFRC. Запустили команду со следующими параметрами:
~ # esxcli storage vflsh cache stats get
На этом рисунке вы можете наблюдать значение 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 для наших особо требовательных к производительности клиентов. Последние, в свою очередь, довольны результатами ускорения работы своих систем и приложений.
О других механизмах кеширования можно прочитать в статье: «SSD-кеширование в облаке VMware» в первом блоге о корпоративном IaaS.
Автор: it_man
