Пару слов про vSphere vFRC
Начиная с 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 есть инструменты для сбора и анализа статистики по общению ВМ с дисковой подсистемой. Там же мы можем посмотреть статистику обращения по блокам различной величины. Анализ этой статистики покажет нам наиболее часто используемый системой размер блока. Тут все зависит от сервиса, создающего дисковую нагрузку.
Итак, включаем SSH на хосте ESXi и подключаемся к командной строке. Оговорюсь, что часть данных в статье из google и документации.1.Смотрим список машин и использеумых ими дисков на хосте: vscsiStats -l2.Стартуем сбор статистики по интересующему диску: 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 килобайта.
Завершаем сбор статистики: vscsiStats -xИ меняем в настройках vFRC диска ВМ размер используемого блока.
Теперь, как смотреть статистику по работе vFRC? В графическом виде никак. Только командная строка. Не удобно, видимо в будущем допилят, ведь у vSphere есть удобный и мощный графический интерфейс работы со статистикой.
Все там же в командной строке ищем диск кэша, который обслуживает нашу ВМ:~ # esxcli storage vflash cache listvfc-413278667-vfrc-test
Смотрим его детали:~ # esxcli storage vflash cache get -c vfc-413278667-vfrc-testWorld ID: 2299121Cachename: vfc-413278667-vfrc-testVmdkname: 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 и на этом ограничиваются. Похоже, мы достигли предела и все наши данные закэшированы.
Проверяем, идем на систему хранения и смотрим на IOPS, которые долетают до нее.
Да, мы видим, что порядка 1700 IOPS доходят до диска ВМ. Возможно, не 100% данных ушли в кэш. Возможно это особенность работы технологии. Утверждать не берусь.
Далее пробуем перенести диск ВМ на заведомо быструю СХД, которая выдает гарантированные 60.000 IOPS на случайное чтение.Все логично, мы видим всего 16.000 IOPS т.к. данные берутся из vFRC, а не с диска ВМ, иначе мы получили бы существенно большие IOPS.
Для окончательной проверки мы переносим диск ВМ на заведомо медленный сторадж, который дает не более 200 IOPS на случайное чтение (1 диск SATA 7.2k)Получаем 7.000 IOPS!!! Отличный результат для такого медленного хранилища! 
Что мы можем получить из статистики? Вводим команду и смотрим: 
Итак, моё мнение — статистика никуда не годится. Мало того, что данные в ней не понятны простому смертному, так они еще и взяты с потолка. Допустим, самый интересный показатель, процент попадания в кэш, с самого начала теста был равен 36, после чего в течение 2 часов спустился до 32%. Фейк. Остальные параметры не лучше и не имеют отношения к реальности. Лично я статистику забраковал. Не годится.
Что нам показывает статистика по латентности диска ВМ из графической среды vSphere? А там все хорошо: 
Отличная латентность. Влияния смены стороджа для диска ВМ не обнаружено.
Небольшой вывод: технология вполне годная и рабочая. Да, есть некоторые огрехи, но их наверняка исправят, а использовать можно уже сейчас :)Для большей эффективности рекомендуется использовать PCI-E SSD под vFRC. Карты PCI-E должны быть совместимы с ESXi на уровне драйверов.
