Vmware host cache настройка
Одним из нововведений в vSphere 5.x является функция Host Cache, которая позволяет администратору разместить файл подкачки (vswp) виртуальной машины на локальном диске с целью увеличения скорости работы за счет размещения свопа на локальных высокопроизводительных дисках (оптимально на SSD дисках, так как скорость доступа на них выше). Реализуется технология за счет создания на SSD диске отдельного раздела VMFS, который затем определяется службой SATP (Storage Adapter Type Plugin) и которая позволяет добавлять и управлять кэшированием на локальном хранилище VMFS.
С текущим падением цен на SSD это может дать реальный прирост производительности VMware ESXi 5.x-сервера, которому, например, не хватает памяти.
Собственно на новых серверах (которые заказывались с SSD дисками) мы и решили протестировать технологию SSD Host Cache. Но столкнулись с трудностью, по умолчанию локальное SSD хранилище не отображается как доступное для работы функции кэширования (пустая вкладка Host Cache Configuration).
Для борьбы с этой проблемой пришлось немного повозиться. Как оказалось, стандартные правила SATP не позволяют обнаружить установленный SSD диск, однако можно создать специальное правило для конкретного устройства SSD .
- Отключаем все диски, презентованные серверу по сети SAN (чтобы не возникло путаницы)
- Открываем локальную консоль сервера ESXi5 (зайти можно по ssh или через vMA) и выполняем команду:
- Затем выполняем команду
Проверяем применение настроек командами:
Если ESXi установлен на этом же диске, нужно перезагрузить сервер, если же диск пустой, сразу выполняем
И еще раз проверяем настройки командой
Что еще можно отметить: после включения SSD Host Cache на локальном хранилище будет создана папка с произвольным (сгенерированным автоматически) именем, внутри которой будет находится папка hostCahe с кучей файлов по 1 MB, представляющие собой файлы свопа для страниц памяти виртуальных машин, запущенных на данном ESX сервере. При миграции (VMotion) этих виртуалок, данные файлы также должны быть перенесены на другой хост (или на общее хранилище, если на хосте Host Cache не включен), за счет чего время миграции несколько увеличивается.
В случае же отказа хост-сервера, надобность в этих файлах исчезает, т.к. виртуалки перезапускаются на другом хосте, и данные из старого файла подкачки им больше не нужны.
Для чего это может понадобиться? Ну, например, для того, чтобы единственной настройкой сказать гипервизору, чтобы хранил все swap’ы на этом Storage.
Со значения по умолчанию:
На вот такую конфигурацию: жмем Edit.
Теперь файлы подкачки всех ВМ хоста будут хранится на выделенном SSD хранилище.
Интересующимся применением технологии SSD в других современных продуктах, рекомендуем познакомиться со статьей «Оптимизация SSD для Windows 8»
You are using an outdated browser. Please upgrade your browser to improve your experience.
Enable your ESXi host to swap to the host cache. You can also change the percentage of space allocated for the host cache.
Use this task if you do not have an appropriate license that allows you to set up and manage a virtual flash resource. If you have the license, use the virtual flash resource for host cache configuration.
Prerequisites
Create a flash-backed VMFS datastore. See Create a VMFS Datastore.
GoodSerg work, hobby, life and. В этом блоге выражается моё личное мнение на описанные здесь события и информацию. При кросблогинге информация предоставляется "как есть" без изменения.
вторник, 20 декабря 2011 г.
Настройка SSD Host Cache на VMware ESXi 5.0
Начали мы тут в компании на 5-ку переходить (VMware ESXi 5.0) и решили попробовать функцию SSD Host Cache используя локальные SSD диски в сервере (благо сервера купили с SSD)
Немного порывшись в интернете нашли как делается настройка эта:
1. По умолчанию локальный SSD storage не видится как SSD (Non-SSD)
Для того что бы это изменить идём локальную консоль сервера (или ssh/vMA) и запускаем команду
"esxcli storage core device list" (предварительно рекомендую отключить все SAN диски что бы остался только один и не было путаницы какой нужен)
3. затем проверяем применилась ли настройка командами
esxcli storage nmp satp rule list | grep enable_ssd
и
esxcli storage core device list
4. Если на используемом локальном storage установлен VMware ESXi 5.0, то перезагружаем сервер, если storage пустой, то выполняем команду:
esxcli storage core claiming reclaim -d ИМЯ_STORAGE
Например:
esxcli storage core claiming reclaim -d naa.600508e000000000ac041b9eeaddc90c
5. Затем ещё раз проверяем всё ли хорошо командой:
"esxcli storage core device list"
GoodSerg work, hobby, life and. В этом блоге выражается моё личное мнение на описанные здесь события и информацию. При кросблогинге информация предоставляется "как есть" без изменения.
вторник, 20 декабря 2011 г.
Настройка SSD Host Cache на VMware ESXi 5.0
Начали мы тут в компании на 5-ку переходить (VMware ESXi 5.0) и решили попробовать функцию SSD Host Cache используя локальные SSD диски в сервере (благо сервера купили с SSD)
Немного порывшись в интернете нашли как делается настройка эта:
1. По умолчанию локальный SSD storage не видится как SSD (Non-SSD)
Для того что бы это изменить идём локальную консоль сервера (или ssh/vMA) и запускаем команду
"esxcli storage core device list" (предварительно рекомендую отключить все SAN диски что бы остался только один и не было путаницы какой нужен)
2. Заускаем команду
esxcli storage nmp satp rule add --satp VMW_SATP_LOCAL --device ИМЯ_STORAGE --option=enable_ssd
например
esxcli storage nmp satp rule add --satp VMW_SATP_LOCAL --device naa.600508e000000000ac041b9eeaddc90c --option=enable_ssd
3. затем проверяем применилась ли настройка командами
esxcli storage nmp satp rule list | grep enable_ssd
и
esxcli storage core device list
4. Если на используемом локальном storage установлен VMware ESXi 5.0, то перезагружаем сервер, если storage пустой, то выполняем команду:
esxcli storage core claiming reclaim -d ИМЯ_STORAGE
Например:
esxcli storage core claiming reclaim -d naa.600508e000000000ac041b9eeaddc90c
5. Затем ещё раз проверяем всё ли хорошо командой:
"esxcli storage core device list"
6. после всех проделанных операций заходим в раздел Configuration-Host Cache Configuration (можно на всякий случай сделать refresh в этом окне) и видим в списке доступных Datastores локальный.
Выбрав свойства Datastore включаем опцию Host Cache Configuration - Allocate space for host cache.
Я бы рекомендовал жёстко задать данный параметр. Так как у меня доступно только 40 Gb на SSD, а RAM в сервере 144 GB я для себя решил что 25% от объёма памяти хватит и поставил Custom size в значение 36 Gb.
В третьей части мы посмотрим на то, как работает с оперативной памятью гипервизор, а также на техники, которые применяются для высвобождения памяти, когда её становится крайне мало.
Memory Sizing
Стоит внимательно подходить к вопросу выделения оперативной памяти виртуальной машине.
Рекомендуется выделять виртуальной машине достаточное количество оперативной памяти для работы системы и приложений и, одновременно, не стоит выделять значительно больше, чем требуется.
Нужно понимать, что чем больше памяти выделено машине – тем больше накладные расходы гипервиозра на обслуживание данной памяти (overhead). Даже если гипервизор сможет высвободить часть ресурсов из виртуальной машины, уменьшить оверхед уже не получится.
Memory Overcommit Techniques
ESXi использует 5 техник для оптимизации количества потребляемой ОЗУ, в случаях, если ее становится крайне мало.
Page Sharing – в случае, если участки памяти двух виртуальных машин одинаковы, нет смысла держать два одинаковых участка и занимать двойное пространство ОЗУ, когда можно просто сослать обе машины на один участок памяти, а второй высвободить. До версии 6.0 Page Sharing работал между виртуальными машинами в рамках одного хоста, однако, с 6-й версии, по умолчанию данный метод применяется только внутри виртуальных машин в целях безопасности.
Ballooning – Модуль, который устанавливается в гостевую операционную систему вместе с пакетом VMware Tools, который может «подтолкнуть» гостевую ОС к высвобождению наименее важных страниц памяти.
Memory Compression – Тут все понятно из описания. Сжатие страниц памяти на хосте. Это, конечно, снижает скорость доступа к памяти, но все еще быстрее, чем использование swap файлов.
Swap to Host Cache – Включается своппинг на уровне хоста. Но в данном случае в кэш, если он, конечно, сконфигурирован. Swap to Host Cache позволяет выделить пространство на SSD, доступ к которому будет все еще быстрее, чем доступ к swap на обычном жестком диске.
Несмотря на все вышеуказанные техники, которые позволяют выделить виртуальным машинам значительно большее количество ресурсов, чем есть на хосте, на котором они располагаются, до этого лучше не доводить.
Если имеется подозрение, что вышеуказанные техники начинают применяться к VM и это сказывается на ее производительности, следует проверить следующее:
- Проверить значения параметра Ballooning у виртуальной машины в меню Monitor – Performance – Advanced в разделе Memory. Нулевое значение данного параметра обычно говорит о том, что у хоста не наблюдается проблем с переподпиской (overcommitment) и ресурсов достаточно для облуживания виртуальной машины. Стоит помнить, что данный параметр имеется только у виртуальных машин с установленным Balloon Driver, который входит в пакет VMware Tools. Небольшое количество balloon memory не всегда говорит о наличии каких-либо проблем;
- Проверить раздел Utilization виртуальной машины. Отличные от нуля значения Swapped и Compressed могут говорить о нехватке памяти гипервизора. Обращение к данным участкам памяти будет замедленно, что скажется на производительности виртуальной машины;
- Стоит проверить активность использования файла подкачки в виртуальной машине. Это может говорить либо об активной процедуре балунинга, либо о недостаточном количестве памяти, выделенной виртуальной машине.
Memory Page Sharing
Как уже было сказано ранее, начиная с версии 6.0, Page sharing работает по умолчанию только в рамках виртуальной машины (intra-VM sharing). При необходимости, его можно включить между виртуальными машинами (inter-VM sharing), если у них выставлено одинаковое значение «salt».
В связи с большой распространенностью страниц памяти размером 2MB (large memory pages), которые не «шарятся», даже если параметр Page Sharing включен, использование дедупликации страниц будет иметь в большинстве случаев незначительный эффект.
В инсталляциях, где используется большое количество мелких страниц памяти (например, VDI, где используется больное количество однотипных машин), Page Sharing может оказаться полезным.
По умолчанию значение «salt» для виртуальной машины это ее uuid, который всегда уникален, что ограничивает Page Sharing рамками данной VM.
Для того, чтобы включить Page Sharing на всех виртуальных машинах хоста, необходимо выставить параметр Mem.ShareForceSalting в значение 0.
Либо, для включения Page Sharing между определенной группой виртуальных машин, можно использовать параметр sched.mem.pshare.salt в конфигурационном параметре VM.
Следует ознакомиться со статьями в базе знаний VMware (1 , 2 )
Memory Swapping Optimizations
Когда ESXi больше не может высвобождать память и оптимизировать ее использование в связи с высокой переподпиской, последней возможностью остается использование файлов подкачки на уровне хоста, что может сильно сказаться на производительности виртуальных машин.
Далее следуют рекомендации, как этого избежать, либо минимизировать негативный эффект:
- Не отключать Ballooning (не забывать устанавливать VMware Tools и следить за их работой в гостевой ОС), Page Sharing и Memory Compression;
- При включении виртуальной машины ESXi создает swap файл для данной VM, который равен размеру памяти машины за вычетом зарезервированной для нее ОЗУ. Следовательно, дисковых ресурсов на хранилище должно быть достаточно для размещения swap файлов машин;
- Если на хосте имеется SSD диск, не будет лишним задействовать его под кэш (Swatp to the Host Cache). Этот кэш доступен всем виртуальным машинам, располагаемым на хосте. Хороший вариант для SSD небольших размеров;
- Хорошим выбором будет размещение swap файлов виртуальных машин на самых скоростных доступных дисках. Лучший выбор – локальный для хоста SSD. Если объема SSD недостаточно для хранения swap файлов машин, лучше его задействовать под Host Cache;
- Если локальных SSD нет, следует размещать файлы на наиболее быстром доступном хранилище, подключенном, например, по Fibre Channel. К примеру, All-Flash массив;
- Независимо от типа используемого хранилища для лучшей производительности и избегания потенциальной ситуации, связанной с нехваткой доступного дискового пространства, не следует размещать файлы подкачки на thin-provisioned хранилище.
По умолчанию swap файл создается там же, где хранится vmx файл виртуальной машины, изменить данный параметр можно в Advanced секции настроек VM.
Уменьшить объем памяти, которая может оказаться в файле подкачки, либо вообще от него избавиться, можно, зарезервировав объем оперативной памяти для виртуальной машины.
Хорошая идея – зарезервировать для виртуальной машины тот объем памяти, с которым она регулярно работает.
В случае, если резерв выставлен во время работы виртуальной машины, эффект от резервирования появится не сразу и будет появляться постепенно. Для мгновенного эффекта стоит выключить и включить виртуальную машину (не перезагрузить из операционной системы, а именно выключить – включить).
Memory Overhead
Стоит понимать, что при использовании системы виртуализации, будут так же появляться и небольшие накладные расходы. Некоторое количество ОЗУ необходимо гипервизору и его службам, а часть ОЗУ для работы виртуальных машин. В целом дополнительно потребляемую память можно поделить на две категории:
- Как уже было сказано часть памяти используется непосредственно гипервизором и его службами (hostd, vpxa и т.п.). ESXi может использовать системный swap файл и уменьшить потребление ОЗУ до 1GB, в ситуациях когда памяти перестает хватать для работы виртуальных машин. Для использования данной возможности необходимо создать swap файл самостоятельно. esxcli sched swap system set -d true -n <datastore name>. Создается файл объемом 1GB на указанном хранилище;
- Дополнительная память используется для каждой запущенной виртуальной машины. Часть памяти резервируется для VMX процесса, часть для процесса VMM. Память резервируется также для виртуальных устройств (мышь, клавиатура, USB). Объем резервируемой оперативной памяти зависит от многих факторов, например, от количества vCPU, сконфигурированного объема памяти, 32-bit или 64-bit гостевая операционная система и т.п.
2MB Large Memory Pages
В дополнение к стандартным размерам страниц памяти в 4KB, ESXi так же может работать со страницами размером в 2MB (Large Pages).
ESXi назначает 2MB страницы гостевой ОС всегда, когда это возможно, даже если гостевая ОС их не запрашивает. Использование Large Pages снижает значения TLB miss, увеличивает производительность многих приложений, особенно, активно работающих с большими объемами памяти, так же уменьшаются служебные затраты ОЗУ на виртуальную машину.
ESXi не использует Page Sharing с большими страницами (скорее всего потому что найти пару двух одинаковых страниц достаточно тяжело). Однако, в случае нехватки оперативной памяти на хосте, большие страницы начинают дробиться на мелкие (4KB), задействуя при этом механизм Page Sharing.
На этом третья часть осмысления заканчивается. В следующей части рассмотрим советы, касающиеся работы с подсистемой хранения.
Всем привет сегодня разберем Как включить Virtual Flash Read Cache в VMware vSphere 5.5. Обновив свой тестовый стенд до VMware vSphere 5.5, мне захотелось попробовать в деле новую функцию - Virtual Flash Read Cache, позволяющую кэшировать данные на локальных SSD накопителях, установленных в сервер, и тем самым снижать нагрузку на хранилища (локальные или SAN) при выполнении операций чтения. так, что давайте разбираться в данном вопросе.
Virtual Flash Read Cache может работать с обычными носителями с интерфейсом SATA/SAS или накопители, подключаемые по шине PCI-E ( список совместимых устройств невелик, но для VFRC можно использовать и другие носители). На текущий момент VFRC имеет следующие ограничения и максимумы:
- На хост-сервере должен быть установлен VMware ESXi 5.5 в редакции Enterprise Plus.
- Настройка и управление VFRC осуществляется только через vSphere Web Client, поэтому требуется VMware vCenter Server.
- Максимальный размер кэша для одного виртуального диска - 400 ГБ.
- Максимальные размер кэша на хост - 2 ТБ.
- Максимальный размер виртуального диска - 16 ТБ.
- Максимальное количество SSD накопителей, используемых под кэш - 8.
- Требуется обновить Hardware Version виртуальной машины до 10-й версии.
- SSD накопитель должен использоваться только под VFRC, на нем нельзя устанавливать гипервизор, создавать VMFS хранилища, или включать в кластер Virtual SAN.
- Администратор должен вручную настраивать кэш для каждого виртуального диска (минимум 1 ГБ). Кэш выделяется (резервируется) при включении ВМ, никакого совместного использования или пере подписки для кэша настроить нельзя.
- Нет поддержки Admission Control для vSphere HA, если на сервере недостаточно кэш-памяти, ВМ просто не запустится.
- Процедура включения Virtual Flash Read Cache крайне проста , однако, у меня сразу же возникли проблемы с добавлением SSD накопителя.
Как включить Virtual Flash Read Cache в VMware vSphere 5.5-01
Как включить Virtual Flash Read Cache в VMware vSphere 5.5-02
Но даже после добавления правила, SSD носитель не появился в списке. Открыв командную консоль и набрав esxcli storage vflash device list, я увидел нечто интересное.
Как включить Virtual Flash Read Cache в VMware vSphere 5.5-03
Снова благодаря RAID контроллеру, ESXi не посчитал мое устройство локальным, и поэтому не давал создать на нем файловую систему под кэш. nРешить проблему удалось удаление старого правила SATP и добавлением нового:
Читайте также: