Пару слов про vSphere vFRC

    image

    Начиная с vSphere 5.5 в лицензии VMWare vSphere Enterprise Plus появилась такая фича, как vFRC.
    Что это и для чего?
    vFRC — vFlash Read Cashe — функция кэширования операций чтения диска виртуальной машины на локальный SSD накопитель хоста виртуализации.
    То есть вставляем SSD диск в хост ESXi. добавляем в настройках хоста этот диск(и) в пул vFRC, идем в свойства виртуальной машины и для каждого из её дисков при необходимости добавляем vFRC нужного размера. Например, диск у ВМ на 100 GB, добавили vFRC на 20 GB. Получили некий гибридный диск. Все операции записи идут на основной, а все операции чтения кэшируются на SSD зеркале vFRC. По некому статистическому алгоритму в этом кэше остаются наиболее частые блоки запросов на чтение. При миграции ВМ на соседний хост vFRC данные дисков этой ВМ так же переносятся в пул FRC нового хоста. Если там пула vFRC нет, или в нем недостаточно места, то vFRC для такой машины отключается. Работа этого правила имеет возможность настройки.

    Я давно хотел протестировать данную технологию и вот, наконец, руки дошли.
    SSD диск PNY на 120 GB (eMLC) был вставлен в хост ESXi и сконфигурирован как vFRC.
    Попытка протестировать в лоб не показала хороших результатов. IOMETER никак не хотел давать прибавки IOPS.
    Начал изучать вопрос и обнаружил, что при подключении vFRC мы имеем возможность указать размер блока, который будет использоваться при кэшировании. По умолчанию размер блока 8 килобайт. Проблема, как оказалась, была зарыта именно тут.
    У ESXi есть инструменты для сбора и анализа статистики по общению ВМ с дисковой подсистемой. Там же мы можем посмотреть статистику обращения по блокам различной величины. Анализ этой статистики покажет нам наиболее часто используемый системой размер блока. Тут все зависит от сервиса, создающего дисковую нагрузку.


    Итак, для просмотра статистики с помощью vscsiStats, включаем SSH на хосте ESXi и подключаемся к командной строке. Оговорюсь, что часть данных в статье из google и документации.
    1.Смотрим список машин и использеумых ими дисков на хосте: vscsiStats -l
    2.Стартуем сбор статистики по интересующему диску: vscsiStats -s -w YYYYY -i XXXX ( Где YYYYY это wouldGroupID виртуальной машины, а XXXX её Virtual SCSI Disk handleID)
    3. Далее запускаем типовую нагрузку и ждем.
    4. Смотрим нашу статистику: vscsiStats -p ioLength -c -w YYYYY -i XXXX

    Получаем распечатку вида:
    min,512
    •max,1052672
    •mean,18434
    •count,21150
    •Frequency,Histogram Bucket Limit
    •1576,512
    •1073,1024
    •539,2048
    •375,4095
    5219,4096
    •428,8191
    •4246,8192
    •787,16383
    •1858,16384
    •3877,32768
    •62,49152
    •405,65535
    •155,65536
    •32,81920
    •324,131072
    •138,262144
    •9,524288
    •47,524288
    Где первым столбцом указано количество блоков (обращений), а вторым столбцом размер этих блоков. Ищем самое большое количество и понимаем, какой блок у нас самый популярный. В конкретно нашем случае это 4 килобайта.
    image

    Завершаем сбор статистики: vscsiStats -x
    И меняем в настройках vFRC диска ВМ размер используемого блока.

    Теперь, как смотреть статистику по работе vFRC? В графическом виде никак. Только командная строка. Не удобно, видимо в будущем допилят, ведь у vSphere есть удобный и мощный графический интерфейс работы со статистикой.

    Все там же в командной строке ищем диск кэша, который обслуживает нашу ВМ:
    ~ # esxcli storage vflash cache list
    vfc-413278667-vfrc-test

    Смотрим его детали:
    ~ # esxcli storage vflash cache get -c vfc-413278667-vfrc-test
    World ID: 2299121
    Cachename: vfc-413278667-vfrc-test
    Vmdkname: vfrc-test-flat.vmdk

    Смотрим статистику:
    ~ # esxcli storage vflash cache stats get -c vfc-413278667-vfrc-test

    Или обнуляем статистику:
    ~ # esxcli storage vflash cache stats reset -c vfc-413278667-vfrc-test

    Отлично. Давайте посмотрим как это работает в реальности.
    Цепляем к ВМ новый толстый (Thick Eager Zeroed) диск на 5 гигабайт, к нему подключаем vFRC диск, так же на 5 гигабайт. Создаем кэшу максимально эффективные условия для работы. Весь диск ВМ покрыт кэшом на чтение.

    Запускаем IOMETER и наблюдаем.
    64 потока, 1 worker, 4kb BS, 100% random, 100% read

    Для начала кладем диск виртуальной машины на систему хранения, которая обеспечивает 10.000 IOPS на случайное чтение.
    IOMETER честно их показывает. Пару минут ничего не происходит, но после показатели IOPS начинают плавно расти. Через 2 часа они достигают уровня 15.000 IOPS и на этом ограничиваются. Похоже, мы достигли предела и все наши данные закэшированы.
    image

    Проверяем, идем на систему хранения и смотрим на IOPS, которые долетают до нее.
    image

    Да, мы видим, что порядка 1700 IOPS доходят до диска ВМ. Возможно, не 100% данных ушли в кэш. Возможно это особенность работы технологии. Утверждать не берусь.

    Далее пробуем перенести диск ВМ на заведомо быструю СХД, которая выдает гарантированные 60.000 IOPS на случайное чтение.
    Все логично, мы видим всего 16.000 IOPS т.к. данные берутся из vFRC, а не с диска ВМ, иначе мы получили бы существенно большие IOPS.
    image

    Для окончательной проверки мы переносим диск ВМ на заведомо медленный сторадж, который дает не более 200 IOPS на случайное чтение (1 диск SATA 7.2k)
    Получаем 7.000 IOPS!!! Отличный результат для такого медленного хранилища!
    image

    Что мы можем получить из статистики?
    Вводим команду и смотрим:
    image

    Итак, моё мнение — статистика никуда не годится. Мало того, что данные в ней не понятны простому смертному, так они еще и взяты с потолка. Допустим, самый интересный показатель, процент попадания в кэш, с самого начала теста был равен 36, после чего в течение 2 часов спустился до 32%. Фейк. Остальные параметры не лучше и не имеют отношения к реальности. Лично я статистику забраковал. Не годится.
    В статистике самой vSphere тоже странности. После подключение vFRC перестает сохранться статистика по передаче объема данных на чтение и запись всех дисков ВМ. То есть там просто ноль. Латентность на запись становится порядка 50мс (хотя в реальности она не такая). Такой она лишь отображается в статистике. Апгрейд до vSphere 5.5-u2 не исправил ситуацию.

    Что нам показывает статистика по латентности диска ВМ на чтение из графической среды vSphere? А там все хорошо:
    image

    Отличная латентность. Влияния смены стороджа для диска ВМ не обнаружено.

    Небольшой вывод: технология вполне годная и рабочая. Да, есть некоторые огрехи, но их наверняка исправят, а использовать можно уже сейчас :)
    Для большей эффективности рекомендуется использовать PCI-E SSD под vFRC. Карты PCI-E должны быть совместимы с ESXi на уровне драйверов.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 0

    Only users with full accounts can post comments. Log in, please.