Уважаемые читатели, я тут планирую в ближайшее время пост по одному интересующему меня вопросу.
Как вводную к нему мне хотелось бы собрать чутка статистики - заодно и пост сделается для вас более наглядным.
Просьба ответить на единственный вопрос:
Обратите внимание, что "использую reservation для ВМ" следует читать как "reservation сделан в размере 50-100% от ресурсов ВМ".
вторник, 31 мая 2011 г.
опрос про reservation
воскресенье, 29 мая 2011 г.
Список MAC адресов на dvSwitch
Вот тут - How to query for MACs on internal vSwitch on ESXi - делятся набором команда и готовым скриптом, который поможет получить данные по MAC адресам с распределенного виртуального коммутатора.
вторник, 24 мая 2011 г.
оптимизация PCoIP
Две известные мне ссылки по оптимизации работы по протоколу PCoIP:
старая - Optimising PCoIP Display & Imaging
и новая - PCoIP Recommended Practices for Networking Devices.
понедельник, 23 мая 2011 г.
HP Proliant Support Pack Cleaner
VMware Converter - очень эффективное средство миграции физических серверов в виртуальные машины.
Однако после миграции физического сервера в ВМ имеет смысл удалить программное обеспечение, которое неактуально после смены железа.
Для серверов HP есть специальная программа - HP Proliant Support Pack Cleaner.
ZeroClient и VMware View
В контексте VDI часто упоминается про т.н. zero client - клиентские устройства еще более "тонкие" чем thin client.
Немного иллюстраций про то что это и с чем это едят - ZeroClient и VMware View.
cloud, vcloud, vcloud director, it-grad
В продолжение разговора про vCloud Director:
Уже было:
Добавилось:
Уже было:
Добавилось:
VMware Horizon App Manager
VMWare выпустила сервис единой аутентификации.
Цитата:
Как известно, основные проблемы с SaaS-сервисами возникают не у пользователей, а у ИТ-администраторов, потому, что они теряют контроль над происходящим. Из-за этого, они всячески тормозят внедрение SaaS-сервисов на предприятии, мотивируя это в частности, повышенным риском кражи паролей и коммерческих данных при их передаче от браузера к сервису. Кроме того, их раздражает, что при использовании сразу нескольких SaaS сервисов приходится по каждому из них вести базу логинов или синхронизировать ее с Active Directory (если еще есть такая возможность). Для решения этих проблем возник новый класс сервисов и решений - SSO (Single Sign-on = сервисы единой аутентификации). Мы уже рассказывали об одном из них - OneLogin. Есть еще несколько, но все это полу-стартапы, которые не могли пока полностью успокоить совесть сисадминов. И вот появилось подобное решение от солидной компании - VMware Horizon App Manager.
vMA + Splunk
Как вы знаете, у VMware есть для vSphere небольшой доппродукт - vMA, vSphere Management Appliance.
Когда-то я о нем написал:
vMA - это ВМ. Бесплатно скачивается с соответствующего ресурса.Кроме прочего, его можно использовать для сбора логов с серверов ESX(i).
Зачем ее скачивать?
Она позиционируется как точка централизованного управления инфраструктурой vSphere.
Управления в смысле:
запуска команд и скриптов - для этого в эту ВМ предустановленны vSphere CLI - Remote Command Line Interface.
Кроме vSphere CLI, в составе этой ВМ есть, цитирую
Applications installed include VMware Tool, Perls command line tools that function similarly to the ESX service console commands, the VI Perl Toolkit, Java JRE 1.5, a VMware authentication component called vi-fastpass, a VMware logging component called vi-logger, and a Simple Network Management Protocol (SNMP) server.
Таким образом, если у нас появятся приложения, которые применяются для управления ESX'ами - можно их ставить в vMA, и из одного места управлять всем. Тем более, есть модули для сквозной авторизации на ESX(i)/vCenter .
Плохая новость в том, что пока что с такими приложениями не густо. Я ни одного не знаю.
А вот тут - vMA + Splunk = Syslog Awesomeness - предлагают доустановить на vMa дополнительный продукт, упрощающий доступ к анализ этих логов:
воскресенье, 22 мая 2011 г.
starwind
Я как-то неотреагировал, а недавно компания Starwind объявила о честной бесплатности своего программного iSCSI target под Windows - StarWind Software Inc. Presents Free Version of iSCSI SAN Solution.
Хотя за рекламу мне они не платят, несколько хороших слов про данный продукт мне сказать хочется.
Несколько лет назад я начинал работать с виртуальной инфраструктурой VMware, и находился в поисках способа организовать разделяемое хранилище для своей тестовой среды. Опробовав несколько вариантов программных iSCSI и NFS стораджей, я ими остался неудовлетворен - по тем или иным причинам.
С какими-то реализациями ESX не захотел работать. С какими-то не захотел работать я :-), особенно это касалось вариантов под Linux.
И тогда я узнал о существовании Starwind software (тогда еще rocket division). Специально поднял свою переписку - в марте 2007 года я написал им письмо с запросом NFR лицензии для демо-стендов, и Anton Kolomyeytsev любезно мне ее предоставил.
С тех пор я наподнимал десятки стендов, некоторые из которых просуществовали по нескольку месяцев, а один - уже почти два года.
Вот это скриншот Windows 7, в которой установлен продукт от starwind. На этой же Windows 7 установлен VMware Workstation, в виртуальных машинах которой крутятся ESX, ESXi и vCenter, для которых Starwind iSCSI target и предоставляет разделяемое хранилище.
Этой конфигурацией я пользовался для написания небезызвестной в наших узких кругах книги, для изучения, отладки и проверки всякого. Почти два года!
Все это время я ни разу не испытал проблем с продуктом Starwind - ребята, спасибо!
С первых использованных мною версий продукт значительно развился, обзавелся функционалом высокой доступности, дедупликации и др., рекомендую глянуть первоисточник - StarWind Free Edition Overview.
P.S.
Довольно интересен и, местами, даже холиворен вопрос про использовании программных СХД (тем более под винду!!!111) в производственной среде - тут я опытом поделиться не могу, поэтому промолчу. Но, к слову сказать, небезинтересная дискуссия развернулась вот на форуме VMware - Starwind Free.
Ярлыки:
сторонний софт под,
СХД\Storage,
vSphere
Snapshot это плохо
Перевод интересного поста - Влияние снапшотов на производительность - 1.
Цитата:
Мы уже получили очень важную информацию: для начала, один лишь факт наличия снапшота означает двукратный рост операций read. Более того, если ВМ записивает блок, который еще не был записан в снапшот, происходит две операции записи - сначала нужно обновить таблицу "где найти конкретный блок" (снапшот или базовый диск). И это очень сильно влияет на производительность!
Если вы еще не верите, что для производственных ВМ снапшоты это зло, см. интересную подборку "всё всё всё про снапшоты" - Snapshots: Подборка интересных постов и статей.
четверг, 19 мая 2011 г.
Inventory Snapshot
На сайте экспериментальных продуктов VMware новое поступление - InventorySnapshot.
Обещают, что эта штука сохранит объекты иерархии vCenter, т.е. папки для хостов и ВМ, кластеры, какой хост в каком кластере, пулы ресурсов, vApp, роли и назначение ролей, custom fields.
А затем запустит PowerShell скрипт, который восстановит эту иерархию объектов в указанном (предполагается новом или другом) vCenter.
Видео с иллюстрацией работы:
понедельник, 16 мая 2011 г.
VMware vSphere 4.1 Storage Performance: Measuring FCoE, FC, iSCSI, and NFS
VMware и NetApp зарелизили интересный документ - VMware vSphere 4.1 Storage Performance: Measuring FCoE, FC, iSCSI, and NFS.
Взяли кучу железа, кучу ВМ, кучу нагрузки с них на диски и померяли IOps, нагрузку на процессор и latency для разных протоколов (FC 4 Gbit, iSCSI 1\10 Gbit, NFS 1\10 Gbit, FCOE 10 Gbit).
Вывод - разницы нет что использовать :-)
The HA and DRS Audit Script
Не так давно вышла книга "HA and DRS deepdive". Я ее купил, прочел, и, в целом, могу рекомендовать для тех, кому хочется понимать устройство этих кластеров. Как альтернативу придти ко мне на курсы пообщаться на эту тему ;-)
PowerCLI-гуру Alan Renouf "...прочел первые 50 страниц, возбудился, и, с разрешения авторов, накидал скрипт, проверяющий кластер на соответствие рекомендациям".
Выглядит эта штука шикаарно - после запуска скрипта в консоли PowerCLI можно наблюдать красочную форму для ввода параметров доступа к vCenter:
После себя остается не менее красочный html файл с выжимкой текущих настроек кластеров HA\DRS, и статистики по ним:
Посмотреть этот отчет по моему кластеру можно вот тут.
Видео как это все используется:
HA and DRS Audit Script from Alan Renouf on Vimeo.
Однако я пока глубокого смысла в этих данных не углядел.
Впрочем, кому-то может и пригодится, и, самое главное, стоит ждать доработки этого скрипта - так что страницу с ним стоит проверять - The HA and DRS Audit Script.
воскресенье, 15 мая 2011 г.
HA Slot sizes
Помнится мне, как-то на форуме VMware было довольно бурное обсуждение касаемо подсчета слотов для кластера HA.
Для интересующихся темой может быть интересной информация отсюда - HA Slot sizes – how do we get those numbers from vCenter?
Для интересующихся темой может быть интересной информация отсюда - HA Slot sizes – how do we get those numbers from vCenter?
Check VMware View 4.x pool provisioning status
У продукта VMware View есть такое понятие как "пул", пул десктопов. Это логическое объединение, куда попадают ВМ, разворачиваемые из указанного шаблона или мастер-образа в случае Linked Clones. Иногда это самое разворачивание не удается - и при настройках по дефолту очередных виртуальных машин для наших любимых пользователей можно не ждать, пока не поставить на место галочку в свойствах пула
Проблема даже не в наличии галочки "Остановить развертывание при ошибке" - это-то как раз ОК, а проблема в отсутствии внятной индикации по этому поводу.
Как костыль можно попробовать использовать скрипт на PowerShell отсюда - Check VMware View 4.x pool provisioning status. Он опрашивает данные из ADAM и шлет email при обнаружении пула с отключенным развертыванием.
P.S. Вы еще не пользуетесь PowerShell для управления своей виртуальной инфраструктурой? Рекомендую ознакомиться с азами - PowerShell + VMware = PowerCLI. How-to - это быстро, легко и многое позволяет реализовать без особых усилий.
Проблема даже не в наличии галочки "Остановить развертывание при ошибке" - это-то как раз ОК, а проблема в отсутствии внятной индикации по этому поводу.
Как костыль можно попробовать использовать скрипт на PowerShell отсюда - Check VMware View 4.x pool provisioning status. Он опрашивает данные из ADAM и шлет email при обнаружении пула с отключенным развертыванием.
P.S. Вы еще не пользуетесь PowerShell для управления своей виртуальной инфраструктурой? Рекомендую ознакомиться с азами - PowerShell + VMware = PowerCLI. How-to - это быстро, легко и многое позволяет реализовать без особых усилий.
Deshifrator
Гугля по ходу написания всякого в блог, обнаружил ранее мне неизвестный русскоязычный блог по нашей любимой теме - Deshifrator's Blog.
VMware vSphere 4.1 Networking Performance
Помните не очень давно камрад Umlyaut рассказывал о достижении скоростей порядка 16 Gbps между двумя ВМ на одном ESX(i) - vSphere network test - vmxnet3, Jumbo Frames
А теперь сама VMware рассказывает о достижении аж 27 Gbps - VMware vSphere 4.1 Networking Performance.
Правда, не при любых условиях и не для любой ОС:
Одна из идей документа - если есть приложение, которое генерит трафик в нереальных объемах, то можно воткнуть в ESX(i) до 4х контроллеров 10 Гбит Ethernet, выпустить через них ВМ с этим приложением, и при совпадении некоторых условий она получит канал с пропускной способностью до 36 Гбит\с, что близко к рассчетным значениям для современного железа.
Притом, этот канал можно и разделить между несколькими ВМ - накладных расходов от деления нет или почти нет.
А теперь сама VMware рассказывает о достижении аж 27 Gbps - VMware vSphere 4.1 Networking Performance.
Правда, не при любых условиях и не для любой ОС:
Одна из идей документа - если есть приложение, которое генерит трафик в нереальных объемах, то можно воткнуть в ESX(i) до 4х контроллеров 10 Гбит Ethernet, выпустить через них ВМ с этим приложением, и при совпадении некоторых условий она получит канал с пропускной способностью до 36 Гбит\с, что близко к рассчетным значениям для современного железа.
Притом, этот канал можно и разделить между несколькими ВМ - накладных расходов от деления нет или почти нет.
VMware vCenter Orchestrator Plugins
Помните, что у всех у кого есть vCenter есть и VMware Orchestrator - мощное средство автоматизации рутинных задач?
В его составе уже есть определенные "кирпичики", атомарные действия над vSphere. А еще можно добавить недавно вышедший vCenter Orchestrator Plug-in for Microsoft Active Directory - 34 действия над AD, которые можно объединять в цепочки и запускать в один клик.
Кстати, еще доступен плагин для связки с vCloud Director - VMware vCenter Orchestrator Plug-in for VMware vCloud Director.
В его составе уже есть определенные "кирпичики", атомарные действия над vSphere. А еще можно добавить недавно вышедший vCenter Orchestrator Plug-in for Microsoft Active Directory - 34 действия над AD, которые можно объединять в цепочки и запускать в один клик.
Кстати, еще доступен плагин для связки с vCloud Director - VMware vCenter Orchestrator Plug-in for VMware vCloud Director.
Performance Recommendations for Virtualizing AnyThing with VMware vSphere 4
Список банальных рекомендаций для повышения (не уменьшения?) производительности абстрактного приложения\ВМ на vSphere - Performance Recommendations for Virtualizing AnyThing with VMware vSphere 4.
VMworld 2011
Как вы, вполне вероятно, знаете, в конце августа должна состояться большая конференция VMware - VMworld.
В этом году ждать ее особенно интересно, так как ходят слухи про релиз vSphere 5 в тех же числах (хотя, если мне склероз не изменяет, релиз четверки откладывался чуть не год, так что все может быть).
А еще в этом году на VMworld может выступить многим знакомым Антон Жбанков - так что голосуем за его сессию! :-)
Для этого на сайте мероприятия нужно нажать кнопку Vote Now и указать номер его доклада - 3332. Потребуется завести учетку, если ее еще нет - рекомендую это сделать в любом случае, с ее помощью в дальнейшем будут доступны материалы с конференции.
В этом году ждать ее особенно интересно, так как ходят слухи про релиз vSphere 5 в тех же числах (хотя, если мне склероз не изменяет, релиз четверки откладывался чуть не год, так что все может быть).
А еще в этом году на VMworld может выступить многим знакомым Антон Жбанков - так что голосуем за его сессию! :-)
Для этого на сайте мероприятия нужно нажать кнопку Vote Now и указать номер его доклада - 3332. Потребуется завести учетку, если ее еще нет - рекомендую это сделать в любом случае, с ее помощью в дальнейшем будут доступны материалы с конференции.
PCoIP Server Offload Card
Интересная штука - PCIe плата для аппаратного ускорения PCoIP, PCoIP Server Offload Card. С поддержкой VMware View начиная с версии 4.5, без ограничений к клиентам.
Обещают плаг-энд-плей, разве что после установки платы\плат в сервера потребуется поставить галочку "использовать аппаратное ускорение PCoIP".
Заявлено, что каждая плата поддерживает до 64 дисплеев в разрешении1920x1200, или до 32 с разрешением 2560x1600.
Обещают плаг-энд-плей, разве что после установки платы\плат в сервера потребуется поставить галочку "использовать аппаратное ускорение PCoIP".
Заявлено, что каждая плата поддерживает до 64 дисплеев в разрешении1920x1200, или до 32 с разрешением 2560x1600.
SSL certificates in VMware View environments
Если нужны свои ssl сертификаты для VMware View, краткая инструкция - SSL certificates in VMware View environments.
vCap - кепка + 10 ко всем параметрам
На прошлой неделе пришел бумажный сертификат VCAP DCA. Самый обычный, выглядит точно как сертификат VCP.
Так же, как к сертификату VCP, к нему полагается честная лицензия на VMware Workstation. Не очень круто, уж для Advanced Professional'ов можно было бы и на честный кейген разориться ;-).
Ну а мне еще обломилась модная кепочка, в стандартный комплект не входящая. VMware обязала своих инструкторов сдать этот тест до 31 марта. Как это не удивительно, но большинство забило\не успело. Поэтому дедлайн подвинули на лето, а успевших премировали кепкой :-)
Кстати, коллеги, кто собирается сдавать тест на VCP - получение бесплатной второй попытки:
Так же, как к сертификату VCP, к нему полагается честная лицензия на VMware Workstation. Не очень круто, уж для Advanced Professional'ов можно было бы и на честный кейген разориться ;-).
Ну а мне еще обломилась модная кепочка, в стандартный комплект не входящая. VMware обязала своих инструкторов сдать этот тест до 31 марта. Как это не удивительно, но большинство забило\не успело. Поэтому дедлайн подвинули на лето, а успевших премировали кепкой :-)
Кстати, коллеги, кто собирается сдавать тест на VCP - получение бесплатной второй попытки:
Хотя актуальность сдачи сейчас VCP по четвертой версии vSphere под вопросом.
четверг, 12 мая 2011 г.
command-line cheat sheet
Углядел тут маленькую шпаргалку по командной строке для тех, кто собирается сдавать VCAP DCA - VMware VCAP-DCA exam command-line cheat sheet.
Впрочем, может быть полезно кому угодно.
Впрочем, может быть полезно кому угодно.
вторник, 10 мая 2011 г.
esx2esxi?
Сегодня, в четвертой версии vSphere, присутствуют две версии гипервизора VMware - ESX и ESXi. Ваша компания использует какой-то один из них.
Завтра, в пятой версии, останется только ESXi.
VMware рекомендует использовать ESXi уже сейчас не только тем, кто только начинает разворачивать vSphere, но и уже живущим с ESX - т.е. мигрировать с ESX на ESXi
Хотя у VMware есть документы, книги, онлайн и оффлайн курсы по этому делу - миграция, обычно, штука не сложная. См. картинку:
Ситуация сложнее в случае если используются продукты, интегрирующиеся в всферу. Этими продуктами могут быть как продукты, поддерживающие оба гипервизора, так и только ESX.
В первом случае, например при использовании vShield или Nexus1000v, просто чуть больше работы при миграции.
А во втором, обычно это агенты мониторинга/управления железа сервера, миграция будет неоправдана - до сих пор ESXi не обзавелся возможностью на любом железе мониторить статус рейд-массива или ошибки памяти, а неспециальноподнегосделанный софт завести вряд ли удасться.
И я даже еще немного вброшу - даже если ничего интегрирующегося у вас не используется, и сейчас вы используете ESX - лично я не вижу веских причин затевать миграцию.
Нет, правда, зачем? Вернее, причины-то можно найти, я вижу основными узкоспециализированность ESXi и (возможно!) более простую миграцию на vSphere 5.
А вот оправданно ли затевать миграцию нормально работающей инфраструктуры ради не совсем конкре ной выгоды - я не уверен. Первую заповедь админа никто не отменял ;-).
Завтра, в пятой версии, останется только ESXi.
VMware рекомендует использовать ESXi уже сейчас не только тем, кто только начинает разворачивать vSphere, но и уже живущим с ESX - т.е. мигрировать с ESX на ESXi
Хотя у VMware есть документы, книги, онлайн и оффлайн курсы по этому делу - миграция, обычно, штука не сложная. См. картинку:
Ситуация сложнее в случае если используются продукты, интегрирующиеся в всферу. Этими продуктами могут быть как продукты, поддерживающие оба гипервизора, так и только ESX.
В первом случае, например при использовании vShield или Nexus1000v, просто чуть больше работы при миграции.
А во втором, обычно это агенты мониторинга/управления железа сервера, миграция будет неоправдана - до сих пор ESXi не обзавелся возможностью на любом железе мониторить статус рейд-массива или ошибки памяти, а неспециальноподнегосделанный софт завести вряд ли удасться.
И я даже еще немного вброшу - даже если ничего интегрирующегося у вас не используется, и сейчас вы используете ESX - лично я не вижу веских причин затевать миграцию.
Нет, правда, зачем? Вернее, причины-то можно найти, я вижу основными узкоспециализированность ESXi и (возможно!) более простую миграцию на vSphere 5.
А вот оправданно ли затевать миграцию нормально работающей инфраструктуры ради не совсем конкре ной выгоды - я не уверен. Первую заповедь админа никто не отменял ;-).
Project “Lightning”
В посте Understanding Project “Lightning”, про перспективы использования твердотельных накопителей в EMC, углядел полезную картинку:
сам пост посвящен, в первую очередь, анонсу решения, представляющего из себя распределенный кеш на ssd, притом распределенный и между серверами, и между СХД.
сам пост посвящен, в первую очередь, анонсу решения, представляющего из себя распределенный кеш на ssd, притом распределенный и между серверами, и между СХД.
среда, 4 мая 2011 г.
Monitoring vSphere
На официальном форуме как-то появилась ветка Чем глобально мониторить почти сотню esx(i), и в ней я углядел ссылку на обзор нескольких средств мониторинга - Обзор основных продуктов мониторинга.
Заслуживает внимания, имхо.
- пост с мобильного устройства, сорри за краткость и опечатки.
вторник, 3 мая 2011 г.
vm4.ru/view
Blogger тут прикрутил новую фичу - если к адресу блога приписать /view , то блог начнет отображаться в одном из нескольких новых вариантах отображения, с возможностью выбора.
Возможно, они будут вам более удобны, скорее всего дефолтный вариант Sidebar
http://www.vm4.ru/view/sidebar:
Возможно, они будут вам более удобны, скорее всего дефолтный вариант Sidebar
http://www.vm4.ru/view/sidebar:
Transparent memory page sharing, vdi, large pages
Как вы, должно быть, знаете, у ESX(i) есть несколько технологий для повышения эффктивности использования памяти. (если кто не до конца в теме см. тут - Memory management).
Одна из технологий - Transparent memory page sharing, дедупликация оперативной памяти.
Гипервизор подсчитывает контрольную сумму страниц памяти виртуальных машин, находит одинаковые - и одинаковые страницы разных виртуалок в реальной оперативной памяти адресует в единственную копию.
По умолчанию, сканирование происходит раз в час, что должно быть достаточно хорошо для большей части случаев.
Однако вот тут - Increase VDI consolidation ratio with TPS tuning on ESX - описывается мнение что для VDI имеет смысл уменьшить частоту сканирования (с 60 до 10 минут). И довольно внушающая аргументация - часто много виртуальных рабочих станций одновременно включается, примерно в одно время на них начинают и заканчивают работать пользователи, часто в одно время случаются пики из за старта антивирусов и другого ПО. Если сканирование памяти будет быстрее отлавливать эти массовые изменения - экономия будет более эффективной.
Это первая часть поста.
Однако, есть нюанс касательно page sharing в целом, актуальный и для VDI при использовании Windows 7 - Large Pages.
Современные серверы позволяют операционным системам использовать большие страницы памяти (Large Pages). Операционные системы могу адресовать память страницами по два мегабайта, а не по четыре килобайта.
Это значительно сокращает размер таблицы адресов страниц, ускоряя работу с памятью когда этой памяти много. Обычно говорят о 10-20% повышении эффективности (см. Large Page Performance.)
Интересно, что сам ESX(i) вроде как поддерживает работу с большими страницами, и старается их использовать для памяти даже тех гостей, что сами по себе их использовать не обучены. (в том смысле что cам ESX(i) использует большие страницы для той памяти, что он выделил этому гостю, а сам гость работает по старинке "внутри" выделенного куска памяти). Правда, непонятно как это влияет на эффективность TPS.
Однако при использовании Large Pages эффективность дедупликации начинает уменьшаться, и очень значительно - найти абсолютно идентичные 2 мегабайта намного сложнее, чем идентичные 4 килобайта (см. немного подробнее на русском тут - Продолжаем говорить о памяти – Page Sharing).
Интересно, что при недостатке свободной ОЗУ на сервере ESX(i) начинает сам разбивать большие страницы на маленькие 4хкилобайтные, для возвращения эффективности Page Sharing.
(см. Transparent Page Sharing is not utilized under normal workloads on Nehalem based Xeon 5500 series CPUs.)
Известная мне теория гласит, что:
1) При использовании серверов на последней платформе (Nehalem у Intel и не знаю как называется у AMD), которые обладают поддержкой EPT\RVI
и при запуске современных ОС, умеющих работать с большими страницами
эти большие страницы используются, что приводит к околонулевой эффективности Page Sharing (исключая пустые страницы памяти, если они есть).
2) Можно отключить использование Large Pages.
Можно отключить использование LP для всех ВМ хоста, при помощи настройки
Mem.AllocGuestLargePage to 0
Можно отключить использование LP для отдельной ВМ правкой ее конфига:
monitor_control.disable_mmu_largepages = TRUE
В этом случае есть немалая вероятность что сервер начнет показывать, что свободной памяти стало больше - за счет дедупликации. Но может снизиться производительность. Однако, снижение производительности вероятно для ВМ с большим объемом ОЗУ (от 4 ГБ? от 8 ГБ?), и менее вероятно для ВМ с меньшими объемами.
Коллеги, если в теории я нигде не ошибся, остается тестировать ;-)
Одна из технологий - Transparent memory page sharing, дедупликация оперативной памяти.
Гипервизор подсчитывает контрольную сумму страниц памяти виртуальных машин, находит одинаковые - и одинаковые страницы разных виртуалок в реальной оперативной памяти адресует в единственную копию.
По умолчанию, сканирование происходит раз в час, что должно быть достаточно хорошо для большей части случаев.
Однако вот тут - Increase VDI consolidation ratio with TPS tuning on ESX - описывается мнение что для VDI имеет смысл уменьшить частоту сканирования (с 60 до 10 минут). И довольно внушающая аргументация - часто много виртуальных рабочих станций одновременно включается, примерно в одно время на них начинают и заканчивают работать пользователи, часто в одно время случаются пики из за старта антивирусов и другого ПО. Если сканирование памяти будет быстрее отлавливать эти массовые изменения - экономия будет более эффективной.
Это первая часть поста.
Однако, есть нюанс касательно page sharing в целом, актуальный и для VDI при использовании Windows 7 - Large Pages.
Современные серверы позволяют операционным системам использовать большие страницы памяти (Large Pages). Операционные системы могу адресовать память страницами по два мегабайта, а не по четыре килобайта.
Это значительно сокращает размер таблицы адресов страниц, ускоряя работу с памятью когда этой памяти много. Обычно говорят о 10-20% повышении эффективности (см. Large Page Performance.)
Интересно, что сам ESX(i) вроде как поддерживает работу с большими страницами, и старается их использовать для памяти даже тех гостей, что сами по себе их использовать не обучены. (в том смысле что cам ESX(i) использует большие страницы для той памяти, что он выделил этому гостю, а сам гость работает по старинке "внутри" выделенного куска памяти). Правда, непонятно как это влияет на эффективность TPS.
Однако при использовании Large Pages эффективность дедупликации начинает уменьшаться, и очень значительно - найти абсолютно идентичные 2 мегабайта намного сложнее, чем идентичные 4 килобайта (см. немного подробнее на русском тут - Продолжаем говорить о памяти – Page Sharing).
Интересно, что при недостатке свободной ОЗУ на сервере ESX(i) начинает сам разбивать большие страницы на маленькие 4хкилобайтные, для возвращения эффективности Page Sharing.
(см. Transparent Page Sharing is not utilized under normal workloads on Nehalem based Xeon 5500 series CPUs.)
Известная мне теория гласит, что:
1) При использовании серверов на последней платформе (Nehalem у Intel и не знаю как называется у AMD), которые обладают поддержкой EPT\RVI
и при запуске современных ОС, умеющих работать с большими страницами
эти большие страницы используются, что приводит к околонулевой эффективности Page Sharing (исключая пустые страницы памяти, если они есть).
2) Можно отключить использование Large Pages.
Можно отключить использование LP для всех ВМ хоста, при помощи настройки
Mem.AllocGuestLargePage to 0
Можно отключить использование LP для отдельной ВМ правкой ее конфига:
monitor_control.disable_mmu_largepages = TRUE
В этом случае есть немалая вероятность что сервер начнет показывать, что свободной памяти стало больше - за счет дедупликации. Но может снизиться производительность. Однако, снижение производительности вероятно для ВМ с большим объемом ОЗУ (от 4 ГБ? от 8 ГБ?), и менее вероятно для ВМ с меньшими объемами.
Коллеги, если в теории я нигде не ошибся, остается тестировать ;-)
Подписаться на:
Сообщения (Atom)