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

    Компания 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

    Архитектурная особенность 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 в настройках хоста

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

    Определение параметров vFRC

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


    При конфигурировании 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-дисков, в каждой группе по одному диску.

    Для тестирования диски SSD подключили к RAID-контроллеру Dell PERC H710P

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

    Запуск команды esxcli

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

    Изменение значения флага “Is SSD“ в параметрах устройства

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

    Настройка vFRC в параметрах хоста

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

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

    Определение параметров vFRC

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

    «Синий экран» при попытке запуска одной из виртуальных машин

    На остальных виртуальных машинах явных проблем не наблюдалось.
    Далее решили воспользоваться инструментами, заточенными под мониторинг кеша SSD, и сравнить результаты тестирования. Для начала в одной из виртуальных машин запустили утилиту FIO, которая генерирует необходимый объем данных на диск VMDK2. Как говорилось ранее, именно он был выделен под полезные данные. Утилита FIO может работать в различных режимах, нас интересовала процедура «случайного считывания». Именно поэтому запустили ее в режиме rand-read.
    Примечание: Более подробную информацию об утилите FIO можно найти на сайте http://freecode.com/projects/fio.

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

    Запуск утилиты FIO

    Интересовал вопрос: попали ли считываемые данные в кеш и если да, то каков процент попадания?
    Для поиска ответа воспользовались графиком производительности виртуального диска машины посредством vSphere WEB client.

    График производительности в vSphere WEB client

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

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

    Запуск команды esxcli

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

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

    Использование утилиты esxtop

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

    ИТ-ГРАД

    402,35

    vmware iaas provider

    Поделиться публикацией
    Комментарии 10
      0
      Если коротко — вся эпопея сводится к тому что «что только не придумает VMware, лишь бы нормальный tiering не реализовать».

      Хотя видимо просто не могут.

      Даже новый VSAN6 (в allflash редакции) — и то не имеет тиринга, но рассчитан на использование дорогих SSD как кэша и дешевых как долговременного хранения.
        0
        NVMe диски не такие дорогие.
        А VSAN и правда странный, могли бы задушить конкурентов сделав его бесплатным, но дерут по 4 килобакса за ЦП и единственную фичу в виде интеграции с ESXi.
          0
          А что вы понимаете «под нормальным тирингом»? Что не так с имеющимися фичами Vmware: vsphere-land.com/news/whats-new-with-vsan-in-vsphere-6.html? Какой такой специфический тиринг должен быть?
          0
          Раз уж автор на личку не обращает внимания, напишу тут: Не стоит мерять IOPS в килобайтах, они все же меряются штуками.
            0
            Спасибо за поправку. Опечатались. Вы совершенно правы.
            0
            А можно глупый вопрос? Диски можно юзать только из HCL? www.vmware.com/resources/compatibility/search.php?deviceCategory=vfrc
              0
              Если нужна в дальнейшем официальная поддержка VMware, конечно лучше из HCL. Поскольку все, что прописано в этом списке является рекомендуемым и если что-то вдруг не заработает, вы можете смело обращаться в VMware. Если поддержка от вендора не требуется, то можно работать с любыми дисками не из списка HCL, которые «видит» сервер.
                0
                Странно, или я что-то не так делаю, или лыжи не едут.
                Поставил в ноду Kingston HyperX 240Gb (они себя хорошо показали в самосборном сторе под 4-ю сферу), захожу в «Configuration/Storage» и могу добавить этот диск как хранилище. Тип показывается «SSD». Если добавить диск как стор, он становится доступен в «Configuration/Host Cache Configuration». Но если зайти вебмордой в «Manage/Settings/Virtual Flash Resource Management» и нажать «Add capacity», диска нет в списке доступных. Уже пробовал диск удалять из «Configuration/Storage», уже и таблицу разделов на нём снёс и с консоли его принудительно пометил как «SSD», ничего не помогает.
                Основная суть в чём: хочу протестировать какой будет выигрыш на нашем конфиге и уже исходя из этого выбирать SSD-хи на закупку. Тестирую тем, что есть. Проблема ещё в том, что ДЦ далеко и диски ставлю через «удалённые руки». Любая операция — 100 баксов, много с железом не поиграешься.
                  0
                  Если бы вы использовали устройства из HCL, можно было бы обратиться в поддержку VMware. К сожалению, когда же речь идет об использовании устройств не из HCL, тут гарантии никто не дает. И чтобы ответить на вопрос, почему не работает, нужно разбираться предметно: изучать инсталляцию, логи, локализовать ошибку.
                    0
                    Понятно. Просто заказывать 1 диск из HCL чисто для тестов — лишняя трата времени, и, возможно, денег. Жаль что не получается тестануть с тем что есть в наличии. Но в принципе поведение системы нелогично. Ладно бы явно было сказано что диск не поддерживается, а то в одном списке он есть и нормально работает, а в другом — нет.

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

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