Еще 8 лет назад мы писали о кэшировании в решении StarWind Virtual SAN, которое является лучшим на сегодняшний день программным средством создания отказоустойчивых хранилищ для виртуальных машин. У кэширования на запись write-back есть недостаток - возможность потери данных в случае отключения электропитания. Поэтому сегодня мы расскажем о том, что такое новый Log-structured Write Cache (LWC), и для чего он нужен...

Недавно компания StarWind, выпускающая лучший в отрасли продукт для создания программных отказоустойчивых хранилищ под виртуализацию, опубликовала интересный технический документ "StarWind Virtual SAN L1 and L2 caches. Operational principles".

В этом документе описывается подход компании StarWind к работе с кэшем уровня L1 (RAM buffer) и L2 (SSD-кэш), а также подробно раскрываются методики кэширования Write-Back и Write-Through, о которых мы также писали ранее.

Кэширование StarWind для уровней L1 и L2 основывается на одном механизме, поэтому множество вещей из документа вполне применимы к обоим уровням кэширования. Данные из кэша, кстати, удаляются в соответствии с политикой LRU (least recently used), то есть наименее используемые данные стираются из кэша первыми.

Остальные интересные технические вещи о кэшировании StarWind (которых немало) читайте в документе.

Некоторое время назад мы писали о технологии VMware vFlash (она же Virtual Flash), которая позволяет использовать высокопроизводительные накопители SSD (вот тут - о производительности) для решения двух важных задач:

• Предоставление виртуальным машинам дополнительного места, в которое будут свопиться страницы памяти в случае недостатка ресурсов на хосте (это намного более производительно, чем свопить на обычный HDD-диск). Эта техника называется Virtual Flash Host Swap и пришла на смену механизму Swap to SSD.
• Прозрачное встраивание в поток ввода-вывода на хосте между виртуальными машинами и хранилищами, что позволяет существенно ускорить операции чтения данных виртуальных дисков. Называется это VMware Flash Read Cache (vFRC).

Ниже мы вкратце расскажем о настройке этих двух механизмов через VMware vSphere Web Client (в обычном C#-клиенте этого, к сожалению, нет). Если что, более подробно о технике vFRC можно почитать по этой ссылке.

Итак, в vSphere Web Client переходим на вкладку "Manage" для нужного хоста, далее в разделе "Settings" выбираем пункт "Virtual Flash Resource Management". Это кэш, который мы добавляем для того, чтобы в случае нехватки места, его могли использовать виртуальные машины, чтобы не свопить данные на медленный магнитный диск, кроме того он же будет использоваться для целей vFRC.

Нажимаем Add Capacity:

Выбираем диски, которые мы будем использовать как Host Swap и нажимаем "Ок" (все данные на них будут стерты):

Всего под нужды Virtual Flash может быть выделено до 8 дисков суммарной емкостью до 32 ТБ. Видим, что ресурс добавлен как Virtual Flash Resource (его емкость отдельно учитывается для vFRC и Host Cache):

Настройка Virtual Flash Host Swap

Первым делом рекомендуется настроить именно этот кэш, а остаток уже распределять по виртуальным машинам для vFRC.

Выбираем пункт "Virtual Flash Host Swap Cache Configuration" в левом меню, а далее в правой части мы нажимаем кнопку "Edit":

Указываем необходимый объем, который планируется использовать, и нажимаем "Ок":

После того, как мы настроили нужное значение - в случае недостатка ресурсов на хосте виртуальные машины будут использовать высокоскоростные диски SDD для своих нужд внутри гостевой ОС (файлы подкачки прочее).

Настройка VMware Flash Read Cache (vFRC)

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

Сам кэш vFRC можно настроить на уровне отдельных виртуальных машин на хосте VMware ESXi, а также на уровне отдельных виртуальных дисков VMDK.

Чтобы выставить использование нужного объема vFRC для отдельной виртуальной машины, нужно выбрать пункт "Edit Settings" из контекстного меню ВМ и на вкладке "Virtual Hardware" в разделе "Virtual Flash Read Cache" установить нужное значение для соответствующего виртуального диска:

Если этого пункта у вас нет, то значит у вас версия виртуального "железа" (Virtual Machine Hardware) ниже, чем 10, и ее нужно обновить.

По ссылке "Advanced" можно настроить размер блока для кэша (значение Reservation, установленное тут, обновит значение на предыдущем скрине):

Чтобы понять, какие значения SSD-кэша можно и нужно выставлять для виртуальных машин, рекомендуется почитать документ "Performance of vSphere Flash Read Cache in VMware vSphere 5.5".

Как знают те из вас, кто следит за развитием технологий VMware, есть такой механизм как vFRC (vSphere Flash Read Cache), представляющий собой распределенный кэш на SSD-накопителях локальных дисков серверов ESXi (ранее он имел рабочее название vFlash). Не так давно мы писали про обзорный документ "What’s New in VMware vSphere Flash Read Cache", а на днях вышел более глубокий технический документ "Performance of vSphere Flash Read Cache in VMware vSphere 5.5", посвященный производительности vFRC.

Помимо всего прочего, в документе рассматривается способ получения информации о структуре и содержимом кэша vFRC. Сделать это можно с помощью команды:

~ # esxcli storage vflash cache list

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

 # esxcli storage vflash cache get –c <cache-identifier>

Несколько больше информации (включая объем закэшированных данных) можно почерпнуть из команд, приведенных ниже. Для этого потребуется создать переменную CacheID:

~ # cacheID='vsish -e ls /vmkModules/vflash/module/vfc/cache/'
~ # vsish -e get /vmkModules/vflash/module/vfc/cache/${cacheID}stats

В результате будет выведено что-то подобное:

vFlash per cache instance statistics {
cacheBlockSize:8192
numBlocks:1270976
numBlocksCurrentlyCached:222255
numFailedPrimaryIOs:0
numFailedCacheIOs:0
avgNumBlocksOnCache:172494
read:vFlash per I/O type Statistics {
numIOs:168016
avgNumIOPs:61
maxNumIOPs:1969
avgNumKBs:42143
maxNumKBs:227891
avgLatencyUS:16201
maxLatencyUS:41070
numPrimaryIOs:11442
numCacheIOs:156574
avgCacheLatencyUS:17130
avgPrimaryLatencyUS:239961
cacheHitPercentage:94
}
write:vFlash per I/O type Statistics {
numIOs:102264
avgNumIOPs:307
maxNumIOPs:3982
avgNumKBs:10424
maxNumKBs:12106
avgLatencyUS:3248
maxLatencyUS:31798
numPrimaryIOs:102264
numCacheIOs:0
avgCacheLatencyUS:0
avgPrimaryLatencyUS:3248
cacheHitPercentage:0
}
rwTotal:vFlash per I/O type Statistics {
numIOs:270280
avgNumIOPs:88
maxNumIOPs:2027
avgNumKBs:52568
maxNumKBs:233584
avgLatencyUS:11300
maxLatencyUS:40029
numPrimaryIOs:113706
numCacheIOs:156574
avgCacheLatencyUS:17130
avgPrimaryLatencyUS:27068
cacheHitPercentage:58
}
flush:vFlash per operation type statistics {
lastOpTimeUS:0
numBlocksLastOp:0
nextOpTimeUS:0
numBlocksNextOp:0
avgNumBlocksPerOp:0
}
evict:vFlash per operation type statistics {
lastOpTimeUS:0
numBlocksLastOp:0
nextOpTimeUS:0
numBlocksNextOp:0
avgNumBlocksPerOp:0
}
}

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