Компании VMware и Intel в партнерстве выпустили новый документ "Intel Data Plane Development Kit with VMware vSphere" (DPDK), который описывает работу с данной библиотекой приложений Linux User Space. Она позволяет на высоком уровне работать с подсистемой ввода-вывода и сетевого взаимодействия и на программном уровне обрабатывать то, что ранее необходимо было делать только на аппаратном для высоконагруженных систем, например, Application-specific integrated circuits (ASICs) и Field programmable gate arrays (FPGAs).

Данный DPDK с использованием техник паравиртуализации позволяет напрямую обращаться к аппаратным функциям оборудования или виртуальных устройств VMware vSphere.

Решение DPDK with VMware vSphere может быть использовано для миграции систем (обычно в сфере телекома и какого-то необычного сетевого взаимодействия), которые раньше были жестко завязаны на аппаратные функции "железа", на платформу VMware vSphere.

При использовании DPDK можно взаимодействовать со следующими механизмами VMware vSphere:

• Виртуальный сетевой адаптер VMXNET3
• Коммутаторы vSwitch и Virtual Distributed Switch
• Прямой проброс устройств через VMware vSphere DirectPath I/O или технологию SR-IOV

Стандартная реализация паравиртуализационного взаимодействия гостевой ОС через vSwitch и VDS выглядит так:

Если речь идет о пробросе устройств напрямую в ОС, то схема выглядит следующим образом:

Больше интересных подробностей можно узнать в самом документе.

Те из вас, кто еще застал VMware ESX 2.x-3.x, наверняка помнят, что в VMware vSphere несколько лет назад иногда возникала проблема некорректного выравнивания блоков на двух уровнях - гостевой ОС по одношению к VMFS и VMFS по отношению к блокам дискового массива (подробнее здесь и здесь):

В такой ситуации смещения блоков на разных уровнях (гостевая ОС, VMFS, дисковый массив) чтение одного кластера в ОС виртуальной машины потенциально могло привести к чтению сразу трех чанков дискового массива.

Были даже специальные утилиты (о них мы писали тут и тут), которые занимались этой проблемой и позволяли получить вот такую правильную картинку, где чтение одного кластера в гостевой ОС приводило к чтению только одного чанка дискового массива.

Выравнивание на стороне файловой системы VMFS было реализовано еще в VMFS-3 (для vSphere 3.x и 4.x), где стартовый Logical Block Address (LBA) выставлялся в значение 128, а в VMFS-5 (начиная с vSphere 5.x) выравнивается по LBA 2048.

Корректное выравнивание в гостевых ОС Windows было также реализовано достаточно давно, начиная с Windows Server 2008 и Windows Vista (естественно, и в версиях 7/8 тоже), начало партиций уже выровнено как положено.

Как же дела обстоят с хранилищами VMware Virtual SAN, которые не используют VMFS?

Тут надо понимать два момента:

1. Virtual SAN использует свое собственное нативное хранилище объектов, и не использует VMFS, поэтому проблем VMFS<->хранилище и VMFS<->гостевая ОС не существует.

2. Проблема гостевая ОС<->хранилище потенциально может существовать для старых ОС (например, Windows Server 2003), однако даже в этом случае она будет мало влиять на производительность.

И вот почему проблема выравнивания блоков в среде VMware VSAN является надуманной:

1. Все операции записи идут через SSD-накопитель как буфер, где они складываются в пачки и только потом идут на HDD, соответственно, импакта тут нет.

2. Операции чтения также обслуживаются кэшем на SSD (vFRC), поэтому тут тоже почти не будет потерь производительности в невыровненной конфигурации.

Поэтому, вывод один - не заморачивайтесь проблемой выравнивания блоков в среде VMware Virtual SAN.

Многие из вас знают о компании Login Consultants, которая занимается тестированием гипервизоров и ПО для виртуализации настольных ПК. Она делает хорошие сравнения в виде технических документов, а также наглядных демонстраций. Выпускаемый компанией инструмент VSI (Virtual Session Indexer) для симуляции нагрузки и тестирования VDI-сред стал стандартом де-факто при тестировании инфраструктуры виртуальных ПК у различных вендоров (например, см. тут). Напомним, что это коммерческое решение, а для бесплатного использования доступен продукт VSI Express.

Совсем недавно вышло обновление - Login Consultants Virtual Session Indexer (VSI) 4.1, в котором, несмотря на незначительное продвижение номера версии, появилось достаточно много всего нового.

Напомним, что средство Login VSI является вендоронезависимым, поэтому с его помощью можно тестировать любое VDI-решение, которое есть сегодня на рынке.

Итак, что нового:

1. Появилось 4 новых типа пользовательских нагрузок:

• Task
• Office (1vCPU)
• Knowledge (2vCPU)
• Power user

Можно создать и свой собственный профиль нагрузки на базе ваших корпоративных приложений.

2. Улучшения компонента Login VSI Analyzer.

Теперь это средство может собирать данные через VMware esxtop и Microsoft Windows Performance Monitor (есть возможность объединения данных от разных источников), обрабатывать их и делать выводы об "узких местах" VDI-инфраструктуры.

Работает это так: например, у вас есть график, где по горизонтали отложено количество виртуальных ПК на сервер ESXi, а по вертикали - время отклика. Провели два теста для нагрузки на ПК с ОС Windows 7 и Microsoft Office 2010 на борту. В одном тесте для достижения трэшхолда по отклику удалось разместить 148 сессий пользователей, а вот в другом - только 112 (кликабельно).

Надо выяснить, в чем дело - почему теперь на сервере помещается меньше пользователей? Накладываем график загрузки CPU и дисков и видим, что загрузка процессора достигает 100%, когда число пользователей переваливает за границу 112.

Таким образом, Virtual Session Indexer 4.1 позволяет не только получать информацию о производительности своей VDI-инфраструктуры, но и решать подобного рода проблемы, а также отвечать на вопрос, где ресурсов не хватает, а где наоборот переизбыток.

Скачать Login VSI 4.1 можно по этой ссылке. Если у вас уже есть версия 4.0, то вы просто можете скачать патч. Скриншоты продукта можно скачать тут.

Одна из самых популярных статей на VM Guru - это статья про типы дисков виртуальных машин на платформе VMware vSphere. Там рассказано про все имеющиеся виды виртуальных дисков, среди которых можно выделить три основных:

• Lazy zeroed thick disks - все пространство диска выделяется в момент создания, при этом блоки не очищаются от данных, которые находились там ранее. Но при первом обращении ВМ к этому блоку он обнуляется.
• Eager zeroed thick disks - все пространство такого диска выделяется в момент создания, при этом блоки очищаются от данных, которые находились там ранее. Далее происходит обычная работа с блоками без очистки.
• Thin disks ("тонкие диски") - эти диски создаются минимального размера и растут по мере их наполнения данными до выделенного объема. При выделении нового блока - он предварительно очищается. Эти диски экономят пространство на массиве, так как не забивают его нулями и не требуют аллокации заданного объема.

Между администраторами VMware vSphere очень часто возникает дискуссия: диски какого типа нужно создавать, особенно если дело касается высоких нагрузок ВМ на дисковую подсистему? Сейчас это становится актуальным и для флэш-массивов, которые начинают появляться в организациях различного масштаба и предназначены как раз для высоких нагрузок ВМ на диски.

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

Результаты оказались интересны - диски типа Thin и Lazy zeroed серьезно уступают в производительности дискам Eager zeroed, когда дело касается нагрузок случайного типа.

Использованная тестовая конфигурация:

• Сервер Dell R910 с 40 ядрами и 256 ГБ оперативной памяти.
• Дисковый массив Pure FA-420 FlashArray с двумя полками, на которых 44 флэш-диска по 238 ГБ каждый (суммарно 8.2 ТБ полезной емкости).
• Виртуальная машина Windows 2008 R2 Virtual Machine следующей конфигурации: 4 vCPU, 8 GB RAM, 40 GB OS/Boot Disk, 500 GB Data Disk.
• Инициатор SW iSCSI для карточки 10 Gb.

Таблица результатов тестов, сделанных с помощью IOMETER для различных размеров блоков:

Из таблицы видно, что все диски на последовательных нагрузках показывают примерно одинаковый результат, а вот на Random-нагрузках уже совершенно другая картина. Все это более наглядно можно увидеть графиков, где диски Thin и Lazy zeroed существенно проседают по производительности:

Вывод - не все йогурты одинаково полезны. Для высокопроизводительных нагрузок желательно использовать диски типа Eager zeroed - хуже точно не будет. Единственный их минус - требуется существенное время на их создание, поскольку происходит обнуление блоков. Но если ваш дисковый массив поддерживает примитивы VAAI, то много времени не понадобится: например, в том же тесте диск Eager zeroed размером 500 ГБ создался менее чем за одну минуту.

Мы достаточно часто пишем о средстве для создания отказоустойчивых кластеров VMware Virtual SAN (статьи можно найти по тэгу VSAN). Не так давно мы писали про документ, который позволяет правильно выбрать серверное оборудование для создания кластеров VSAN, а в этой заметке на основе информации от Дункана Эппинга, мы расскажем о выборе дисков для Virtual SAN.

Как известно, на одном хосте VMware ESXi, являющимся узлом VSAN, может быть до пяти дисковых групп (Disk Groups), каждая из которых содержит один SSD-диск и от 1 до 7 HDD-дисков:

Возникает резонный вопрос, что лучше - иметь одну дисковую группу большой емкости или несколько дисковых групп емкостью поменьше. Например, у вас такие требования к кластеру VSAN:

• Всего нужно емкости : 20 ТБ
• Всего емкости флэш-накопителей (10% по best practices): 2 ТБ
• Всего хостов ESXi: 5

В этом случае на каждом хосте можно использовать одну из двух альтернативных конфигураций:

• 2 x 2 ТБ SAS-диска и 1 x 400 ГБ флэш-диск (одна дисковая группа)
• 4 x 1 ТБ SAS-диска и 2 x 200 ГБ флэш-диска (две дисковых группы)

Тут получается три аспекта, на которые влияет выбор конфигурации:

1. SSD-диск+HDD-диски дисковой группы являются единой точкой отказа (fault domain), так как отказ единственного SSD-накопителя приведет к отказу дисковой группы в целом. В случае отказа флэш-накопителя данные вы, конечно, не потеряете, но понадобится некоторое время, чтобы восстановить избыточную конфигурацию. Так что чем больше групп, тем лучше.
2. С точки зрения производительности - также лучше иметь две дисковых группы. Как вы знаете SSD-диск используется для кэширования данных, а один диск большей емкости, хоть и выжимает больше IOPS, но не намного. То есть, в первом случае, например, вы будете получать на кэше 36 000 IOPS, а во втором 2 x 32 000 IOPS. Аналогично, больше иопсов будут выжимать и HDD-диски. Очевидно, второй случай с точки зрения производительности - выгоднее.
3. Затраты - здесь надо балансировать между оптимальной емкостью SSD-накопителей и HDD-дисков. Диски большой емкости, начиная с какой-то точки, стоят намного дороже. Тут второй вариант тоже в плюсе.

Итого - несколько дисковых групп на хосте небольшой емкости лучше одной гигантской дисковой группы.

Тем из вас, кто развернул средство для создания отказоустойчивых кластеров VMware Virtual SAN, может потребоваться мониторинг состояния кластера в разрезе использования различных вычислительных ресурсов на хостах ESXi, а также виртуальными машинами.

Для этого есть специальная утилита с графическим интерфейсом VSAN Observer, которая позволяет через веб-интерфейс наблюдать за кластером VSAN. По умолчанию на сервере VMware vCenter она отключена.

Чтобы включить ее, делаем следующее:

1. Если вы используете VMware vCenter Virtual Appliance, то нужно запустить Ruby-консоль следующей командой:

rvc username@localhost

Здесь вводим логин и пароль администратора vCenter.

Если вы используете vCenter Server для Windows, то эту консоль можно запустить следующим bat-файлом (логин-пароль аналогичны предыдущему пункту):

%PROGRAMFILES%\VMware\Infrastructure\VirtualCenter Server\support\rvc\rvc.bat

2. Используем команды cd и ls, чтобы перейти в рабочий каталог VSAN:

cd localhost

cd VSAN

3. Запускаем веб-сервер VSAN Observer командой:

vsan.observer ~/computers/VSAN --run-webserver --force

4. После этого запускаем консоль VSAN Observer, перейдя по ссылке:

http://<vCenter Server>:8010

На первой вкладке мы видим дэшборд с различными характеристиками хост-серверов VMware ESXi, входящих в состав кластера Virtual SAN:

На вкладке VSAN Disks (per-host) мы видим уже графики на уровне отдельных физических дисков хостов:

На вкладке VSAN Disks (deep-dive) мы смотрим детальные параметры дисков на уровне отдельного хоста ESXi, включая кэширующий SSD-диск и HDD-диски с данными.

Каждый график можно развернуть отдельно, просто нажав на него:

На вкладке PCPU можно отслеживать параметры загрузки процессоров хост-серверов, обслуживающих кластер VSAN:

То же самое, но касательно памяти:

На вкладке Distribution можно смотреть информацию относительно баланса кластера - равномерно ли загружены его ресурсы:

Вкладка DOM Owner похожа на первую вкладку - говорят она для техподдержки VMware:

А вот вкладка VMs - полезная штука. Тут можно смотреть за производительностью на уровне отдельных виртуальных дисков конкретных ВМ, использующих ресурсы хранения кластера VSAN.

Также тут можно узнать, на каких хостах находятся реплики виртуальных дисков VMDK конкретной ВМ:

Ну а если вы хотите использовать VSAN Observer на сервере VMware vCenter под Windows, то команда ниже позволит вам добавить соответствующее правило в его сетевой экран:

netsh advfirewall firewall add rule name = "VMware RVC VSAN Observer" dir = in protocol = tcp action = allow localport = 8010 remoteip = localsubnet profile = DOMAIN

Не все администраторы VMware vSphere знают о том, что в версии vSphere 5.5, компания VMware сделала специальную настройку для виртуальных машин - Latency Sensitivity. Она позволяет снизить издержки на виртуализацию для виртуальной машины в случае, когда требуется ее производительность близкая к нативной (то есть почти без потерь на нужды слоя виртуализации).

Найти ее можно в vSphere Web Client, если выбрать нужную ВМ, перейти на вкладку Manage, далее выбрать Settings->VM Options и в разделе Advanced Settings перейти на опцию Latency Sensitivity:

Там можно выбрать значения Low, High, Medium и Normal, однако значения Medium и Normal в vSphere 5.5 являются экспериментальными, поэтому пока можно использовать только Low (по умолчанию) и High (режим высокой производительности для чувствительных нагрузок).

Детально о том, что конкретно делает этот режим, можно почитать в документе "Deploying Extremely Latency-Sensitive Applications in VMware vSphere 5.5", мы же здесь приведем основные моменты.

Итак, если вы ставите Latency Sensivity для виртуальной машины в значение High, происходит следующее:

Виртуальная машина получает эксклюзивный доступ к физическим ресурсам хоста

• Планировщик CPU хоста ESXi определяет возможность того, может ли быть предоставлен эксклюзивный доступ виртуального процессора vCPU к физическому процессору (ядру) сервера pCPU, учитывая реальное состояние процессора (нагруженность, over-commit и прочее). При возможности происходит резервирование pCPU для виртуального процессора на 100%. В этом случае никакие другие vCPU и трэды не могут быть исполнены на этом pCPU (включая VMkernel I/O threads).
• Возможность latency-sensitivity требует от пользователя установки резервирования памяти (Memory Reservation), чтобы выделенная виртуальной машине память не была ненароком отдана другой машине средствами Memory Ballooning. Это позволит дать гарантию, что машина всегда будет иметь в своем распоряжении четко выделенный сегмент физической оперативной памяти хоста ESXi, даже в случае недостатка ресурсов на хосте.

Обход слоя виртуализации

• Как только машина получила эксклюзивный доступ к pCPU, ее виртуальный процессор может напрямую взаимодействовать с его ресурсами в обход планировщика VMkernel. Это ликвидирует затраты на переключение между VMkernel и монитором виртуальных машин (VMM), однако переключения между исполнением кода гостевой ОС и VMM по-прежнему остаются (но это делается очень быстро за счет технологий аппаратной виртуализации, которые есть сейчас в любом процессоре).

Тюнинг механизмов виртуализации на хосте

• Когда в качестве виртуального сетевого адаптера (VMNIC) виртуальной машины используется устройство VMXNET3, то функция Interrupt coalescing и поддержка LRO отключаются, чтобы уменьшить время отклика и джиттер. Если виртуальной машине не нужны такие функции, как vMotion, NetIOC и Fault tolerance, то можно и нужно использовать механизмы проброса сетевого устройства напрямую в виртуальную машину (pass-through) через механизм Single-root I/O virtualization (SR-IOV). Поддержка этого механизма появилась еще в VMware vSphere 5.1, но была существенно доработана в версии 5.5.

Вкратце это все, но больше новых подробностей о требовательных ко времени отклика виртуальных машинах можно почерпнуть из приведенного выше документа.

На днях компания VMware обновила свой главный документ о производительности и мониторинге виртуальной инфраструктуры - VMware vSphere 5.5 Monitoring and Performance.

В этом документе (или даже, можно сказать, книге) на 175 страницах рассказывается о лучших практиках по отслеживанию производительности серверов VMware ESXi 5.5 под управлением VMware vCenter 5.5.

Основное содержание документа:

• Monitoring Inventory Objects with Performance Charts - полное описание графиков и счетчиков производительности в VMware vCenter.
• Monitoring Guest Operating System Performance - немного о мониторинге гостевой ОС виртуальной машины.
• Monitoring Host Health Status - проверка жизнедеятельности хостов и выявление проблем.
• Monitoring Storage Resources - построение отчетов по хранилищам и графическое представление Storage maps.
• Monitoring Events, Alarms, and Automated Actions - просмотр событий для объектов vCenter, алармы и действия по срабатыванию триггеров.
• Monitoring Solutions with the vCenter Solutions Manager - мониторинг расширений vCenter.
• Performance Monitoring Utilities: resxtop and esxtop - утилиты для мониторинга производительности из командной строки (там же есть расшифровки всех счетчиков). Об этом мы пишем тут.
• Monitoring Networked Devices with SNMP and vSphere - мониторинг хостов по протоколу SNMP и настройка агентов.
• System Log Files - просмотр активностей виртуальной инфраструктуры в лог-файлах журналов.

Документ обязателен к прочтению системным администраторам VMware vSphere, а также всем тем, кто готовится к различным экзаменами, например VMware VCP.

Мы уже много писали о технологии VMware Virtual SAN (VSAN), которая позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бетаэтого решения, кроме того мы не так давно писали о производительности VSAN тут.

В этой заметке (на базе статьи Дункана) мы поговорим о том, как кластер VSAN обрабатывает сбои различного типа, и как происходит восстановление работоспособности виртуальной машины без ее простоя.

Итак, в нормальном режиме функционирования, при значении параметра FailuresToTolerate равном 1, который означает, какое количество отказов хостов может пережить кластер хранилищ, реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно заметить 5 особенностей кластера VMware VSAN:

• Виртуальный диск VMDK и его реплика всегда находятся на разных хост-серверах VMware vSphere.
• ВМ не обязательно должна исполняться на том хосте ESXi, на дисках которого находятся ее хранилища.
• Компонент witness находится на третьем по отоношению к виртуальному диску и его реплике хосте, чтобы создать определенность на случай разделения сети VSAN (где окажется 2 компонента из набора "vmdk-реплика-witness" - тот сегмент и будет определяющим).
• Сеть VSAN используется для операций ввода-вывода и определения доступности.
• Реплика VMDK-диска вместе с основной копией образуют RAID-1 массив, который увеличивает производительность операций чтения в виртуальной машине, так как для чтения используются оба хранилища.

Кроме того, вследствие особенностей реализации кластера VSAN, надо понимать, что команды ввода-вывода не применяются к диску данных виртуальной машины, пока не пришло подтверждение об их записи на реплике. Но подтверждение приходит не от HDD-диска, где находятся данные ВМ (это было бы очень медленно), а от SSD-диска, который используется как энергонезависимый Write Buffer для команд ввода вывода. Таким образом, этот буфер (и данные, само собой) зеркалирован в рамках дисковой группы на другом хосте ESXi.

Теперь рассмотрим различные виды сбоев в кластере VSAN.

1. Ломается диск дисковой группы, где исполняется виртуальная машина.

Выглядит это так:

В этом случае такой диск сразу же помечается как "degraded", а команды ввода-вывода перенаправляются на другой хост-сервер VMware ESXi. При этом виртуальная машина этого не замечает, так как переключается на работу с SSD-буфером/кэшем и HDD-дисками другого хоста мгновенно (данные на момент сбоя были синхронизированы, ничего не потерялось).

Одновременно с этим сразу же начинается процесс построения реплики на другом хосте ESXi в рамках его дисковой группы, при этом проверяется, достаточно ли там свободных дисковых ресурсов. Если их недостаточно, то механизм VSAN будет ожидать. Как только вы добавите диски/дисковые группы на хостах - сразу же начнется процесс построения реплики (до его окончания машина будет помечена как "degraded").

Тут надо отметить, что в degraded-состоянии скорость записи данных останется прежней, простоя не будет, а вот скорость чтения упадет до построения новой реплики, поскольку второй копии данных пока нет.

2. Отказывает хост VMware ESXi целиком.

В этом случае запускать процесс восстановления сразу же, конечно, не нужно - мало ли что могло случиться с хостом, например, его случайно перезагрузили, или временно пропало сетевое соединение.

В этом случае происходит ожидание в течение 60 минут, и если отказавший хост ESXi не оживет, то начнется процесс создания реплики виртуального диска VMDK на другом хосте. Это время можно изменить в расширенной настройке кластера VSAN.ClomRepairDelay, но пока не известно будет ли это поддерживаться со стороны VMware.

3. Отказ SSD-диска в дисковой группе.

В кластере VMware Virtual SAN поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп.

В данном случае Failure Domain - это вся дисковая группа, включающая в себя SSD-диск, который используется для двух типов операций:

• Read Cache (70% емкости) - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
• Write Buffering (30% емкости) - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Таким образом, при отказе SSD-диска, виртуальная машина начинает использовать реплику на уровне всей дисковой группы на другом хосте VMware ESXi. Вот почему выгодно делать две дисковых группы 3HDD+1SSD, чем одну  6HDD+1SSD.

Вот, в общем-то, и все. Более подробно об использовании SSD-дисков, их производительности и ресурсе можно прочитать вот в этой статье.

Как знают многие администраторы VMware, на сайте проекта VMware Labs часто появляются полезные штуки и мы про них так же часто пишем. На этот раз очередная нужная вещь для пользователей VMware Horizon View - средство тестирования аудио и видео в реальном времени в виртуальном ПК - Real-Time Audio-Video Test Application (RTAV).

Приложение позволяет убедиться в том, что производительность аудио и видео в реальном времени удовлетворительная, путем непрерывного воспроизведения виртуального видеопотока с веб-камеры и замыкания на себя аудио-дорожки:

(надо отметить что при использовании видео+аудио режима они могут быть несинхронизированы - это нормально, для приложений все будет работать синхронно)

Раньше надо было ставить в виртуальной машине какой-нибудь Skype или WebEx, чтобы протестировать производительность, а теперь ничего такого делать не надо - просто ставите утилиту RTAV в виртуальном ПК и все. Кроме этого, это приложение можно использовать и для нагрузочного тестирования инфраструктуры VMware Horizon View.

Возможности утилиты:

• Отображение картинки с веб-камеры в режиме разрешения 1:1.
• Автоматический старт передачи картинки сразу после запуска (аудио-поток будет замкнут на себя, если выбран этот вариант, то audio-in будет перенаправлен на audio-out).
• Не требуется создавать никаких аккаунтов.
• Поддержка устройства VMware Virtual Webcam, а также физических камер ноутбуков и ПК.
• Работа как на x86, так и на x64 операционных системах.

Для приложения потребуется установить пакет Microsoft 2008 C++ x86 (SP1) вот по этой ссылке.

Скачать Real-Time Audio-Video Test Application (RTAV) можно по этой ссылке.

Отсутствие аппаратного ускорения графики является существенным препятствием при внедрении технологий виртуализации в компаниях, работающих в сфере дизайна, проектирования, конструкторских разработок и пр. Рассмотрим, какие новые возможности появились с выходом адаптеров, предназначенных специально для работы с 3D-графикой NVIDIA GRID. Классный пост компании ИТ-ГРАД - с реальными тестами.

Мы очень много писали о том, как с помощью утилиты esxtop можно собирать с хостов VMware ESXi данные о производительности и различные метрики (например, тут и тут). Данные, полученные с помощью этой утилиты, очень часто помогают разобраться в источнике проблем в части вычислительных ресурсов, хранилищ и сетевого взаимодействия.

В этой заметке мы поговорим немного о визуализации данных esxtop. Не так давно мы писали об утилите VisualEsxtop, которая как раз тем самым и занимается - строит графики по наборам данных. Но недавно мы наткнулись на простой способ, позволяющий с помощью Windows Perfmon сравнивать наборы данных esxtop с разных хостов ESXi.

1. Итак, сначала нужно собрать данные с хоста ESXi в пакетном режиме в файл .csv. Например:

Здесь:

• -b - означает пакетный режим работы утилиты.
• -d (delay) - промежуток между срезами сбора данных.
• -n - число число таких срезов (сэмплов).

В данном случае будет собрано 360 сэмплов данных с промежутком в 10 секунд, то есть сбор займет 1 час.

Можно сжать результаты, чтобы экономить место на хосте, командой:

esxtop -b -d 10 -n 360 | gzip > esxtopresults.csv.gz

2. Загружаем данные в Windows Perfmon, выбрав источник - наш файл csv:

Визуализируем нужные счетчики:

3. Пробуем добавить еще один csv с другого хоста ESXi (с которым мы хотим сравнить данные первого хоста), но нам говорят, что так нельзя - можно такие файлы смотреть только по одному:

Не беда - сохраняем данные как бинарный файл с расширением *.blg, выбрав нужные счетчики:

Дальше просто удаляем этот файл из источников данных Perfmon, добавляем второй csv-файл и так же сохраняем его как *.blg.

Ну а дальше оба этих файла добавляем по одному - и все работает:

Добавляем сохраненные счетчики:

И данные с обоих хостов показываются на одном графике:

Источник заметки: www.viktorious.nl.

Мы уже писали о технологии VMware Virtual SAN, которая сейчас находится в режиме бета-тестирования. Кроме того, мы затрагивали тему производительности виртуальных ПК VMware Horizon View на хранилищах Virtual SAN (там про то, что VSAN масштабируется почти без потерь производительности).

Сегодня мы хотим рассказать еще о двух вещах. Во-первых, компания VMware выпустила обновление беты Virtual SAN, которое получило следующие новые возможности:

• AHCI fix - как писала VMware ранее, была проблема с контроллерами AHCI, которая приводила к потере данных на устройствах VSAN (см. PDL, Permanent Device Loss). Теперь эту проблему исправили, и можно продолжать тестирование на этих контроллерах.

• New RVC Commands - теперь в Ruby Virtual Console, которая входит в состав VMware vCenter 5.5, есть команды по управлению хранилищами в пространстве имен spbm (Storage Policy Based Management). Существующие политики можно найти в папке "~/storage/vmprofiles".

• PowerCLI fling - многим пользователям интересна автоматизация задач в VMware vCloud Suite. Теперь и для VSAN есть набор командлетов PowerCLI, которые позволяют управлять хранилищами VSAN. Более подробно об этом здесь.

• Limit Changes - в первой бета-версии дисковая группа могла иметь 1 SSD-Накопитель и до 6 HDD-дисков, но поскольку есть серверы, в которых восемь слотов, то HDD-дисков теперь поддерживается до 7 штук (SSD по-прежнему один).

Во-вторых появилась третья статья в серии про Virtual SAN - "VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 3" из цикла статей, где делаются всяческие замеры производительности хранилищ VSAN.

В этот раз сравнивалось некий дисковый массив "all flash storage array", который работает на SSD-накопителях, и 7-ми и 8-ми узловые кластеры Virtual SAN. Результаты в очках, поставленных VDImark (View Planner QoS), поставленные кластеру из хостовых хранилищ и дисковому массиву:

Напомним, что очки VDImark - это число виртуальных машин, которое может быть запущено на данной аппаратной конфигурации с соблюдением определенного порогового значения для операций (на самом деле минимум 95% операций должны попасть в эти трешхолды для ВМ, чтобы их засчитали).

Результаты тестов оказались весьма неплохими. Картинка для тестов по времени отклика операций группы А (интерактивные операции пользователя):

Группа B:

Вывод: Virtual SAN - очень неплох в сравнении с нативной производительностью какого-то SSD-массива (VMware, что это за массив-то??).

Ну и ссылки на все статьи цикла:

• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 1
• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 2
• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 3

Уже довольно давно мы писали про техники кэширования в продукте StarWind iSCSI SAN & NAS, который предназначен для создания отказоустойчивых iSCSI-хранилищ под виртуальные машины. Эти техники постоянно совершенствуются (см., например, новые возможности StarWind V8 Beta 2) и иногда в разы увеличивают быстродействие виртуальных машин, особенно в условиях высоких требований к подсистеме ввода-вывода.

У некоторых пользователей возникает вопрос - а нужно ли использовать кэш StarWind, когда на сервере используется SAS-адаптер со своим кэшем, например, HP Smart Array P420, имеющий на борту 1GB RAM. На форуме StarWind Антон отвечает на этот вопрос следующим образом:

• У кэша контроллера весьма ограниченный объем, а StarWind может использовать очень большой объем RAM для оптимизации ввода-вывода.
• Кэш контроллера медленный, так как использует шину PCIe, а кэш StarWind - быстрый, так как использует шину оперативной памяти.
• Кэш контроллера небезопасен - только одна копия данных. При использовании кэширования StarWind метаданные дублируются и даже "триплируются" при использовании трехузлового кластера. Вероятность, что все хосты кластера хранилищ упадут одновременно - очень низка.
• Кэш контроллера работает только для одного узла, то есть когда ВМ переезжает с этого узла - она уже не имеет доступа к своему кэшу. StarWind же имеет умную систему распределенного кэша между узлами, и когда виртуальная машина переезжает на другой хост кластера хранилищ, она продолжает его использование.

Таким образом, вывод прост - конечно же, включайте кэширование на уровне SCSI-адаптера, но не подразумевайте это как альтернативу кэшированию StarWind, так как последнее - более умная и эффективная технология, разработанная изначально для виртуальных машин.

Мы уже писали про распределенный кэш на SSD-накопителях локальных дисков серверов ESXi, который имел рабочее название vFlash, а затем превратился в полноценную функцию VMware vSphere Flash Read Cache платформы VMware vSphere 5.5.

Сегодня мы хотим обратить внимание на два интересных документа, которые раскрывают подробности использования этой технологии.

Напомним, что Flash Read Cache позволяет использовать кэширование данных только на чтение для дисков VMDK виртуальных машин, работает она на уровне гипервизора и существенно улучшает производительность виртуальных машин, которые интенсивно используют подсистему ввода-вывода для операций на чтение. Очевидно, что SSD-кэш, который по производительности находится между оперативной памятью и обычными дисками, существенно повышает быстродействие в системах, где периодически наблюдается недостаток ресурсов RAM. Все это дело работает в кластере до 32 хостов ESXi.

Итак, первый документ о том как работает технология Flash Read Cache - "What’s New in VMware vSphere Flash Read Cache":

В этом документе описано, как работает инфраструктура vFlash в рамках виртуальной инфраструктуры vSphere, для каких целей можно использовать данную технологию, требования, а также шаги по установке и настройке этого механизма.

Второй документ - это официальный FAQ VMware по технологии Flash Read Cache - "VMware vSphere Flash Read Cache 1.0 FAQ". Так как она появилась впервые, и не все технические особенности ясны администраторам, в документе даны ответы аж на 67 вопросов.

Интересные факты из этого FAQ:

• В качестве интерфейсов накопителей поддерживаются SATA, SAS и PCI Express.
• До 8 устройств vFlash на один хост ESXi и до 4 ТБ емкости на устройство (до 400 ГБ на один VMDK). На один контейнер VFFS (то есть на хост) поддерживается до 32 ТБ.
• В качестве хранилищ ВМ механизмом поддерживаются тома VMFS/NFS/vRDM (pRDM не поддерживается).
• Настраивается только через Web Client.
• При изменении настроек vFlash все кэши для дисков сбрасываются.
• Thin provisioning не поддерживается технологией vFlash.
• При миграции виртуальной машины средствами vMotion можно использовать 2 политики: Always migrate the cache contents (copy) - кэш копируется вместе с ВМ и Do not migrate the cache contents (drop) - кэш очищается. Техники VMware HA / SVMotion также полностью поддерживается.
• Механизм VMware DRS при миграции не затрагивает машины с включенным Virtual Flash Read Cache.
• Операции, которые очищают кэш ВМ: suspend, изменение конфигурации, удаление, перезапуск машины или хоста, восстановление из снапшота. Операции, которые не очищают кэш: снятие снапшота, клонирование, миграция vMotion, fast suspend/resume.
• В vCenter есть 3 специальных метрики для мониторинга vFlash (IOPS, Latency и объем кэша).
• Кэшем vFlash можно управлять через ESX CLI: get –m <module> -c <cache file name>
• Файлы кэша vFlash находятся в следующей директории на хосте: /vmfs/volumes/vffs/vflash

Информацию об официально поддерживаемых механизмом VMware vSphere Flash Read Cache устройствах можно найти по этой ссылке: http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vfrc

Мы уже писали о технологии VMware VSAN, которая позволяет построить распределенный кластер хранилищ на базе локальных дисков серверов VMware ESXi. Этот кластер позволяет отказоустойчиво хранить виртуальные машины и обращаться к ним с любого из хостов. Недавно компания VMware опубликовала результаты тестов работы ВМ в VDI-инфраструктуре на базе хранилищ VSAN.

Как многие знают, еще в прошлых версиях VMware vSphere появилась такая возможность, как задание нескольких виртуальных ядер для vCPU виртуальных машин (cores per socket), которое требуется, в основном, для случаев хитростей с лицензированием. То есть, например, для случаев, когда требуется покрыть лицензиями только виртуальные сокеты, а производительности нужно больше (как вариант - так можно поступать с лицензиями Windows Server не Datacenter Edition).

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

Рекомендации тут просты:

• Оставлять по одному ядру на виртуальный процессор машин.
• Если все-таки приходится изменять число ядер на vCPU, то нужно знать особенности организации архитектуры сервера.

Про второй пункт и идет речь ниже. Дело в том, что в VMware vSphere есть такая технология как vNUMA, которая работает при количестве vCPU равном 8 и больше для одной виртуальной машины и позволяет самым оптимальным образом отображать физическую архитектуру сервера на топологию NUMA-узлов виртуальной машины (по количеству и размеру).

Например, для процессора AMD Opteron 6174, который имеет два 6-ядерных процессора, объединенных в единый сокет - такая архитектура представляет собой 8 NUMA-узлов (две пары на один процессор). Таким образом для конфигурации без изменения cores per cpu для виртуальной машины технологией vNUMA будет поддерживаться 8 vNUMA узлов, что отлично отражает физическую архитектуру:

Это для случая, когда мы не изменяем количество ядер на vCPU. В VMware прогнали тест в гостевой ОС (какая-то внутренняя утилита) и получили базовое время исполнения этого бенчмарка для указанной конфигурации:

Если же в ВМ ядер на виртуальный сокет больше одного, то размер vNUMA будет равен количеству процессоров ВМ. Выставляем 2 сокета с 12 ядрами на сокет:

Получаем 2 vNUMA-узла, что не совпадает с конфигурацией оборудования:

Поэтому тест выполняется подольше:

А вот если сделаем целых 24 ядра на один сокет:

То получим всего один узел vNUMA:

И как следствие, самую низкую производительность ВМ:

65 секунд против 45 в первом тесте, что означает падение производительности на 31% для данного случая. Поэтому не меняйте просто так число ядер на процессор. Само же количество процессоров можно менять смело.

Дополнительную информацию по этому вопросу можно найти тут:

• KB 1010184
• The CPU Scheduler in VMware vSphere 5.1
• Check out VSCS4811 Extreme Performance Series: Monster Virtual Machines in VMworld Barcelona

Сразу после релиза обновленной версии платформы vSphere 5.5 компания VMware выпустила очень интересный и полезный документ Performance Best Practices for VMware vSphere 5.5, в котором рассматриваются аспекты производительности серверов VMware ESXi и виртуальных машин уже с учетом функциональности новой версии.

Например, теперь в документе описаны следующие фичи в контексте производительности:

• Функции кэширования на SSD-накопителях vSphere Flash Read Cache, о которых мы писали вот тут. Они увеличивают производительность за счет применения кэша на чтение для операций ввода-вывода виртуальных машин.
• Возможность VMware Virtual SAN (VSAN), о которой мы писали тут. Она позволяет использовать локальные ресурсы хостов ESXi для построения распределенной инфраструктуры хранения виртуальных машин.
• База данных VMware vFabric Postgres database (vPostgres).

Кроме того, были обновлены и дополнены следующие темы в документе (который уже можно смело называть книгой, так как занимает он 90 страниц):

• Использование нагрузок в ВМ, чувствительных к скорости подсистемы ввода-вывода и сетевому взаимодействию (интересна также статья в тему)
• Техники NUMA и Virtual NUMA (vNUMA)
• Техники экономии памяти хоста (Memory overcommit)
• Технология Large memory pages
• Техника Receive-side scaling (RSS), как в гостевых ОС, так и для адаптеров 10 Gigabit Ethernet
• Средства миграции VMware vMotion, Storage vMotion, а также Cross-host Storage vMotion
• Техники балансировки нагрузки VMware Distributed Resource Scheduler (DRS) и экономии электропитания Distributed Power Management (DPM)
• Обновленный (а точнее полностью переписанный) VMware Single Sign-On Server (об этом у нас тут)

Не так давно мы писали про утилиту VMware View Planner 2.0, которая позволяет смоделировать и организовать нагрузочное тестирование инфраструктуры виртуальных ПК на платформе VMware Horizon View.

Не так давно было выпущено обновление этого средства - VMware View Planner 3.0, которое теперь можно свободно скачать с этой страницы.

View Planner 3.0 имеет следующие возможности:

• Тестирование производительности для реальных моделей нагрузок на основе популярных приложений.
• Уникальная технология для измерения производительности виртуального ПК для адекватного замера пользовательских метрик.
• Методология, позволяющая повторять тесты и масштабировать их.
• Метрики, позволяющие определить сильные стороны инфраструктуры - глубину размещения виртуальных ПК, производительность и экономическую эффективность.
• Поддержка последних версий VMware vSphere и VMware Horizon View.
• Улучшенные отчеты по статистикам.
• Автоматически генерируемые отчеты в PDF.

Суммарный отчет View Planner 3.0 предоставляется в виде метрики VDImark. Эта метрика показывает, сколько пользователей может использовать виртуальные ПК VMware View без превышения заданных пороговых значений задержек (response time) для приложений.

Операции, проверяемые View Planner 3.0, разделены на три группы:

• (1) Group A - базовые интерактивные операции (пороговое значение - 1 секунда).
• (2) Group B - операции ввода-вывода (I/O operations).
• (3) Group C - операции в фоновом режиме (пороговое значение - 6 секунд)

При тестировании VDI-инфраструктуры с помощью View Planner в этой статье использовалась следующая базовая конфигурация оборудования (замерялись значения для 3,5 и 6 хостов ESXi при такой нагрузке - 285 ВМ (3 хоста), 480 ВМ (5 хостов) и 560 ВМ (6 хостов)).

Результаты получились весьма ровными и попадающими в нужные диапазоны:

Как минимум 95% ВМ попадали в эти пороговые значения, что является весьма неплохим результатом для такого количества машин, размещенного на протестированном оборудовании.

Несколько детальнее по самим тестам операций группы А:

По тестам операций группы Б:

Результаты по IOPS:

Более подробно о VMware View Planner 3.0 можно почитать по этой ссылке. Скачать его можно по этой.

Мы много пишем о проекте VMware Labs, созданный для того, чтобы инженеры VMware выкладывали там свои наработки, которые не были оформлены в виде конечных продуктов компании (заметки об этом можно найти у нас по тэгу Labs).

На этот раз на VMware Labs появилась по-настоящему полезная штука - VisualEsxtop. Как можно догадаться из названия, эта утилита, написанная на Java, позволяет визуализовать данные о производительности в реальном времени, выводимые командой esxtop. Утилита кроссплатформенная и работает под Windows и Linux как .bat или .sh сценарий.

Возможности VisualEsxtop:

1. Соединение как с отдельным хостом ESXi, так и с vCenter Server.
2. Гибкий способ пакетного вывода результатов.
3. Загрузка результатов пакетного вывода и его "прогонка" (replay).
4. Возможность открыть несколько окон для отображения различных данных одновременно.
5. Визуализация в виде графика выбранных счетчиков производительности.
6. Гибкий выбор и фильтрация счетчиков.
7. Тултип на ячейках счетчиков, объясняющий их назначение (см. картинку).
8. Цветовое кодирование важных счетчиков.

Также VisualEsxtop можно заставить работать под Mac OS X - для этого почитайте вот эту статью.

Скачать VisualEsxtop можно по этой ссылке. Четырехстрочная инструкция доступна тут.

Время от времени мы пишем об исследованиях Project Virtual Reality Check, которые проводят компании Login Consultants и PQR в сфере виртуализации. На этот раз стал доступен отчет "Phase VI – Best practices and impact of Microsoft Office 2007, 2010 and 2013 in VDI", который является продолжением исследования про влияние антивирусов на производительность виртуальных ПК.

Этот отчет посвящен работе различных версий Microsoft Office (2007, 2010 и 2013) в виртуальных ПК в составе VDI-решения. Интересные разделы документа:

• Office 2007 v.s. Office 2010 v.s. Office 2013
• Office 2013 Performance Tuning
• Win 7 x86 Office 2010 x86 v.s. Win 7 x64 Office 2010 x86
• Win 7 x64 Office 2010 x86 v.s. Win 7 x64 Office 2010 x64
• Win 7 x86 Office 2010 x86 v.s. Win 7 x64 Office 2010 x64
• Office 2010 Indexing On vs. Off

Познавательна картинка, полученная с помощью Login Virtual Session Indexer (VSI):

И вывод исследователей:

Comparing both Microsoft Office 2010 and 2013 with Office 2007 there is a negligible capacity impact of 1% with Office 2010, but there is a very substantial difference of 20% with Office 2013. As a result, upgrading to Office 2013 requires 20% more VDI capacity in comparison to Office 2007 and Office 2010.

То есть, готовьтесь увеличивать свои мощности под прожорливый офис.

Некоторое время назад компания VMware инициировала Project Serengeti, целью которого было обеспечение возможности запуска кластеров Apache Hadoop на виртуальной платформе (в частности, VMware vSphere). Это одна из первых серьезных инициатив VMware в сегменте Big Data.

Совсем недавно была выпущена бета-версия расширений VMware vSphere Big Data Extensions v1.0 Beta, которые позволяют применить все наработки Serengeti для создания виртуальных машин с Hadoop на борту. Эти расширения обеспечивают жизненный цикл Hadoop на платформе VMware vSphere и позволяют отслеживать потребляемые ими ресурсы.

Возможности VMware vSphere Big Data Extensions v1.0 Beta:

• Графический интерфейс Big Data Extensions. Он позволяет создавать, масштабировать и удалять кластеры Hadoop. Кроме того, доступен отдельный мониторинг и контроль ресурсов этих виртуальных машин.
• Поддержка большинства дистрибутивов Hadoop.
• Автоматическая "эластичность кластеров" (возможность автоматического наращивания ресурсов).
• Возможность динамического изменения ресурсов, выделенных запущенным кластерам Hadoop.
• Возможность Disk Failure Recovery.
• Возможность создания ВМ Hadoop с кастомной конфигурацией CentOS.
• Поддержка vSphere Standard Edition на время Technology Preview (дальше будут поддерживаться только более высокие издания vSphere).

Немного документации:

• vSphere Big Data Extensions Administrator's and User's Guide
• vSphere Big Data Extensions Command-line Interface Guide
• Benefits of Virtualizing Hadoop
• Hadoop Performance on vSphere
• Serengeti User Guide
• Hadoop High Availability Solution on VMware vSphere (with Hortonworks)
• Protecting Hadoop with VMware vSphere 5 Fault Tolerance
• White Paper: Hadoop Virtualization Extensions

В целом, VMware заявляет, что Apache Hadoop исполняется в виртуальных машинах практически без потерь производительности (об этом можно почитать здесь):

Скачать VMware vSphere Big Data Extensions v1.0 Beta можно по этой ссылке.

Не так давно мы писали про средства управления питанием хост-серверов ESXi, которые имеются в VMware vSphere 5.1. Там мы рассматривали такую политику как Balanced - она разработана для того, чтобы максимально использовать переключения между состояниями P-states процессора в целях экономии энергии. Она обладает слегка большей инерционностью, чем обычное максимальное использование ресурсов процессора (High performance), но почти не влияет на производительность. Эта политика выставлена по умолчанию для серверов VMware ESXi 5.0 и более поздней версии.

Недавно на блоге VROOM! компании VMware появилось интересное исследование, посвященное механизмам управления питанием серверов ESXi. Как и обычно, в качестве инструмента для тестирования и создания нагрузки на хосты ESXi использовался продукт VMware VMmark, который и был разработан для тестирования производительности решений VMware на различных аппаратных платформах.

Сравнивались три подхода к управлению питанием:

• Политика Performance - максимальное использование процессора за счет его поддержки в наивысшем P-state состоянии все время (то есть, по-сути политика энергосбережения отключена). При этом используются только 2 C-state состояния: С0 (running) и C1 (halted). Соответственно, данный режим выдает максимальную производительность, не имеет инерционности и потребляет больше всего энергии. Управляется эта политика BIOS'ом сервера.
• Политика Balanced - сбалансированное энергопотребление за счет переключения между P-states. Эта политика управляется хостом ESXi.
• Политика BIOS Balanced - функции энергосбережения, которые управляются на уровне BIOS сервера (например, Dell Active Power Controller).

Для тестирования производительности использовался стандартный подход VMmark, который предполагает создание возрастающих уровней нагрузки на хост-серверы (Tiles).

С точки зрения аппаратной платформы, использовалась следующая конфигурация:

• 4 сервера Dell PowerEdge R620
• CPUs (на сервер): один Eight-Core Intel® Xeon® E5-2665 @ 2.4 GHz, Hyper-Threading enabled
• Memory (на сервер): 96GB DDR3 ECC @ 1067 MHz
• Host Bus Adapter: два QLogic QLE2562, Dual Port 8Gb Fibre Channel to PCI Express
• Network Controller: один Intel Gigabit Quad Port I350 Adapter
• Версия гипервизора: VMware ESXi 5.1.0
• Дисковый массив: EMC VNX5700
• 62 флеш-диска (SSDs), RAID 0, сгруппированных в 3 x 8 SSD LUNs, 7 x 5 SSD LUNs и 1 x 3 SSD LUN
• Средства управления: VMware vCenter Server 5.1.0
• Версия VMmark: 2.5
• Power Meters: три устройства Yokogawa WT210

Итак, что получилось. График очков VMmark (чем выше столбики - тем лучше). Результаты нормализованы к BIOS Balanced на уровне Tile 1:

Как мы видим, худшие результаты показывает политика BIOS Balanced.

Теперь посмотрим на результаты тестов по новой методике VMmark 2.5, позволяющей измерять производительность сервера на киловатт питания:

Как мы видим, политика Performance показывает самые низкие результаты (это логично, так как энергии потребляется много, а столько мощности не всегда требуется процессору), политика ESXi Balanced показывает результат на 3% лучше, а вот политика BIOS Balanced - аж на 20% лучше.

Кстати, интересны измерения потребления мощности при простаивающем процессоре:

• Политика Performance потребляет 128 Вт
• ESXi Balanced - 85 Вт
• BIOS Balanced - тоже около 85 Вт

Казалось бы, почему тогда не использовать BIOS Balanced? А вот почему - при тестировании нагрузки приложений политика BIOS Balanced выдает огромные задержки (latency), негативно влияющие на производительность:

Таким образом, если снова вернуться к первому графику с обобщенными результатами, можно понять, что политика ESXi Balanced является наиболее оптимальной с точки зрения энергопотребления/производительности, поэтому-то она и установлена по умолчанию.

Мы уже писали о компании VMTurbo, выпускающей продукты для мониторинга и управления виртуальной инфраструктурой на базе платформ различных вендоров. На днях VMTurbo сделала бесплатным продукт Virtual Health Monitor, предназначенный для мониторинга гетерогенной инфраструктуры виртуализации.

Надо сказать, что Virtual Health Monitor - это несколько доработанная версия издания Community Edition продукта VMTurbo Operations Manager, являющегося основным коммерческим решением компании, предназначенным для управления виртуальной средой.

 Высокоуровневыми возможностями VMTurbo Virtual Health Monitor являются:

• Возможность отслеживания производительности компонентов виртуального датацентра и определение уровня его работоспособности
• Мониторинг параметров и построение отчетов о виртуальных машинах и хост-серверах в любом количестве (то есть настоящая бесплатность, без ограничений)
• Поддержка нескольких гипервизоров одновременно
• Еженедельный анализ аппаратных мощностей для определения степени эффективности их использования, а также прогнозирование необходимых дополнительных мощностей

Virtual Health Monitor поставляется уже в виде готового виртуального модуля (Virtual Appliance), который можно разместить на следующих платформах (они же, соответственно, и поддерживаются продуктом):

• VMware vSphere
• Microsoft Hyper-V
• RedHat Enterprise Virtualisation (RHEV)
• Citrix XenServer

Virtual Health Monitor был выпущен в преддверии выхода решения VMturbo Operations Manager 4.0, которое будет поддерживать гибридные облака и иметь специальные модули сопряжения с хранилищами различных производителей.

Скачать Virtual Health Monitor можно по этой ссылке.

Компания VMware, вскоре после релиза VMware Horizon View 5.2, выпустила руководство по оптимизации гостевых ОС Microsoft в виртуальных ПК - "VMware Horizon View Optimization Guide for Windows 7 and Windows 8".

Этот документ рассказывает о том, как нужно конфигурировать стандартный образ Windows для использования в VDI-инфраструктуре Horizon View. Для администраторов есть советы о том, как сделать такой образ с помощью Microsoft Deployment Toolkit (MDT) или с использованием сценариев для оптимизации виртуальных машин.

Для различных операций по оптимизации Windows 7 и Windows 8 включены детальные шаги по созданию необходимой конфигурации. Обновленный шаблон для групповых политик Windows 8 (а Horizon View также поддерживает интерфейс Metro) позволяет регулировать различные настройки этой ОС еще более гибко. Также рассматривается модель загрузки Windows 8, когда стартуют только необходимые службы ОС, а остальные запускаются по мере необходимости (Triggered Start).

Некоторое время назад мы уже писали о том, что в VMware Horizon View 5.2 Feature Pack 1 появилась возможность организовать доступ к виртуальным ПК по протоколу Blast через браузер с поддержкой технологии HTML5.

Для этого на сервер VMware View Connection надо поставить специальный компонент HTML Access Web Portal, а на клиентские ПК - агенты HTML Access Agent.

Для доступа к своему ПК пользователь соединяется с VMware View Security Server, который соединяется с View Connection Server по протоколу Blast по порту 8443, а тот уже, в свою очередь, взаимодействует с виртуальными ПК пула по порту 22443 (см. тут):

При этом похоже, что Blast - это отдельный протокол в VMware View, а не просто проброс PCoIP через HTML5. Вот так это выглядит в мониторинге сессий View Administrator:

Напомним, что для работы функции HTML Access в виртуальных ПК посредством Blast на данный момент поддерживаются следующие браузеры:

• Google Chrome 22 и выше
• Internet Explorer 9 и выше
• Safari 5.1.7 и выше
• Firefox 16 и выше
• Mobile Safari для iOS с iOS 6 и выше (через Unity Touch)

Ну и самое интересное. Поскольку Blast - это отдельная ветка протокола VMware, то при отображении виртуального ПК через браузер не работают следующие вещи:

• Отсутствует Multimedia и Flash Redirection
• Не работает универсальная печать через ThinPrint
• Не работает перенаправление USB
• Не работает звук в виртуальном ПК
• Не работают веб-камеры
• Нет возможности доступа с Android-устройств
• Производительность Blast существенно ниже, чем для PCoIP-сессии через толстый клиент
• Возможны проблемы совместимости в различных браузерах

В целом для многих окружений критичной является только производительность пользовательских сессий в сравнении с PCoIP-соединениями. Поэтому ждем в ближайшее время обратной связи от пользователей на эту тему.

Компания VMware выпустила документ "Storage Considerations for VMware View".

В документе описаны лучшие практики посроения подсистемы хранения для инфраструктуры виртуальных ПК VMware Horizon View. Рекомендации касаются размещения базовых образов и пулов связанных клонов, протоколов хранения, систем хранения данных и методик улучшения производительности.

Разделы документа:

• Windows Disk I/O Workloads
• Base Image Considerations
• Storage Protocol Choices
• Storage Technology Options
• Storage Array Decisions
• Increasing Storage Performance

У компании VMware есть специализированное ПО для моделиирования рабочей нагрузки в VDI-среде - VMware View Planner 2.0. К сожалению, это средство доступно только партнерам VMware, однако умной голове не составит труда раздобыть его. Также, напомним, что мы уже писали о средствах тестирования VDI-нагрузок: VDI Sizing Tool и Login VSI.

View Planner поставляется в виде виртуального модуля (Virtual Appliance) в формате OVF, построенного на базе дистрибутива Linux Centos 5.x и требующего 2 GB памяти и один vCPU на виртуальную машину.

View Planner предназначен для генерации различных сценариев рабочей нагрузки виртуальных ПК, включая управление состояниями виртуальных машин, пользователями Active Directory, построение отчетов и прочее. Все это управляется через веб-интерфейс, присутствующий у виртуального модуля, включая службы Active Directory и конфигурации View Connection servers, контролируемые средствами развертываемых на них агентов.

Архитектурно решение VMware View Planner состоит из следующих компонентов:

• Виртуальные ПК на хостах VMware ESXi.
• Несколько клиентских виртуальных машин на хостах ESXi - используются для удаленного режима или пассивных тестов, т.е. те, откуда происходит доступ к виртуальным ПК.
• VDI controller appliance - управляющий модуль View Planner.

View Planner можно запускать в трех различных режимах:

• Remote mode - в этом случае для каждой тестируемой ВМ будет своя клиентская машина. Это самый затратный с точки зрения необходимых ресурсов способ тестирования, однако самый адекватный.
• Passive Client mode - в этом режиме клиентских машин требуется меньше и они только пассивно принимают результаты вывода тестируемых машин, а последние генерируют нагрузку. Это позволяет снизить требования к нужным для тестирования ресурсам.
• Local mode - в этом случае тесты исполняются только на десктопах, без клиентов. Это не учитывает сетевой трафик между ними, поэтому менее репрезентативно, зато и менее затратно.

Вот, например, как работает тест в режиме Remote mode:

Все данные о тестировании нагрузок хранятся в базе данных MySQL.

Модель нагрузки задается в виде блоков, каждый из которых создается под свою задачу для виртуальных ПК:

Пример рабочей нагрузки, генерируемой View Planner:

В качестве результатов работы View Planner вы получите следующие полезные параметры:

• Время отклика в виртуальном ПК (Responce Time) - показатель QoS для пользователей
• Статистики использования ресурсов (Resource stats)

Запускаем тест, получаем примерное число виртуальных ПК (пользователей), которые выдержит наша виртуальная инфраструктура с заданным показателем QoS (в данном случае время отклика - 1,5 секунды):

Из таблицы видно, что при заданной модели нагрузки наша VDI-инфраструктура с приемлемым показателем качества обслуживания будет выдерживать максимум ~130 пользователей. Не такого ли ответа на вопрос ожидают те из вас, кто планирует VDI-инфраструктуру у себя в организации?

Чтобы продолжить изучение полезного продукта VMware View Planner, рекомендую обратиться по следующим ссылкам:

• VMware View Planner: Measuring True Virtual Desktop Experience at Scale
• View Planner 2.0: Load-test your VMware View implementation
• VMware View Planner Installation and User Guide

Остальное - на официальной странице VMware View Planner.

На днях, на сайте проекта VMware Labs (у нас есть тэг Labs) появилась новая утилита DRMdiagnose, с помощью которой возможно просмотреть информацию о текущем состоянии ресурсов кластера и получить рекомендации по управлению ими.

DRM - это Distributed Resource Manager, основной компонент VMware vSphere, являющийся ядром механизма VMware DRS, который осуществляет балансировку ресурсов в кластере. Основное назначение утилиты DRMdiagnose - это предоставление информации о том, что произойдет с производительностью виртуальных машин и их вычислительными ресурсами, если настройки ресурсов (limit, shares, reservation) будут изменены для какой-то из виртуальных машин. Кроме того, эта утилита выдает рекомендации относительно того, что нужно сделать с ресурсами виртуальных машин по отношению к текущим назначенным ресурсам (уменьшить, увеличить).

Появилась эта утилита по той причине, что пользователи VMware vSphere не знали, что происходит с кластером и его производительностью при регулировании настроек выделения ресурсов для виртуальных машин. Утилита позволяет получить рекомендации относительно того, как можно изменить настройки ресурсов ВМ для достижения оптимальной производительности.

DRMdiagnose позволяет увидеть рекомендации в кластере наподобие таких:

Increase CPU size of VM Webserver by 1
Increase CPU shares of VM Webserver by 4000
Increase memory size of VM Database01 by 800 MB
Increase memory shares of VM Database01 by 2000

Decrease CPU reservation of RP Silver by 340 MHz
Decrease CPU reservation of VM AD01 by 214 MHz
Increase CPU reservation of VM Database01 by 1000 MHz

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

• vCenter server appliance: /var/log/vmware/vpx/drmdump/clusterX/
• vCenter server Windows 2003: %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\
• vCenter server Windows 2008: %ALLUSERSPROFILE%\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\

Сама утилитка может работать в трех режимах:

1. Default - если указан путь к drmdump, то выводятся все ВМ кластера, их назначенные ресурсы, а также запрашиваемые ресурсы.
2. Guided - если указан путь к drmdump и целевые параметры ресурсов ВМ, то утилита сгенерирует набор рекомендаций для их достижения.
3. Auto - если указан путь к drmdump, то будут сгенерированы рекомендации для самых несбалансированных ВМ (то есть ВМ, для которых разница между назначенными и запрашиваемыми ресурсами самая большая).

Выглядят снапшоты кластера вот так:

А вот так можно запустить утилиту в дефолтном режиме для вывода информации в файл output.txt:

Формат использования DRMdiagnose:

Работает DRMdiagnose только с VMware vCenter 5.1 и выше, скачать утилиту можно по этой ссылке.

Очень давно мы писали про тип виртуальных дисков Paravirtual SCSI (PVSCSI), который появился в VMware vSphere 4 и был создан для требовательных к ресурсам ввода-вывода нагрузок. На заре своего развития виртуальные диски типа PVSCSI не рекомендовались к использованию в качестве загрузочных, а также имели несколько серьезных багов, но широко тестировались в связи с тем, что показывали большую производительность, чем стандартный LSI SCSI.

Эту статью мы пишем, главным образом, здесь для того, чтобы сказать - уже можно. Виртуальные диски Paravirtual SCSI достаточно стабильно работают в VMware vSphere. В KB 1010398 мы видим матрицу поддержки дисков pvscsi для различных релизов VMware vSphere (обычные и boot-диски):

В VMware vSphere/ESXi 5.1 поддерживается все то, что поддерживалось и в предыдущих версиях платформы.

Что же раньше были за баги с PVSCSI? Смотрим, например, в статье тут, отсылающей нас к KB компании Microsoft. Ошибка существовала для ОС Windows Server 2008 R2 и была критической, а устранена была только в VMware vSphere 5.0 Update 1, о чем есть KB 2004578.

Теперь о том, как поставить диск типа PVSCSI в качестве загрузочного для виртуальной машины на ESXi. Выбираем в vSphere Client контроллер типа VMware Paravirtual :

В настройках виртуальной машины добавляем виртуальный floppy-дисковод и указываем образ дискеты с драйвером PVSCSI, который лежит в папке vmimages->floppies (если там ничего нет, идем сюда):

Дальше при выборе диск для установки Windows указываем драйвер с дискеты:

Дальше ставим все как обычно. Если хочется запихнуть драйвер PVSCSI в кастомизированную ISO-шку, то вам сюда. И да, драйвер на образе дискеты от Windows Server 2008 прекрасно работает на Windows Server 2012, который, в свою очередь, работает на VMware vSphere 5.1.