Не все администраторы 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 (режим высокой производительности для чувствительных нагрузок).
Итак, если вы ставите 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.
Вкратце это все, но больше новых подробностей о требовательных ко времени отклика виртуальных машинах можно почерпнуть из приведенного выше документа.
В этом документе (или даже, можно сказать, книге) на 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, VSAN, HA, Performance, Storage, ESXi, vSphere
Приложение позволяет убедиться в том, что производительность аудио и видео в реальном времени удовлетворительная, путем непрерывного воспроизведения виртуального видеопотока с веб-камеры и замыкания на себя аудио-дорожки:
(надо отметить что при использовании видео+аудио режима они могут быть несинхронизированы - это нормально, для приложений все будет работать синхронно)
Раньше надо было ставить в виртуальной машине какой-нибудь 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. Классный пост компании ИТ-ГРАД - с реальными тестами.
Таги: NVIDIA, GRID, VDI, IT Grad, VMware, Citrix, Performance
Мы очень много писали о том, как с помощью утилиты esxtop можно собирать с хостов VMware ESXi данные о производительности и различные метрики (например, тут и тут). Данные, полученные с помощью этой утилиты, очень часто помогают разобраться в источнике проблем в части вычислительных ресурсов, хранилищ и сетевого взаимодействия.
В этой заметке мы поговорим немного о визуализации данных esxtop. Не так давно мы писали об утилите VisualEsxtop, которая как раз тем самым и занимается - строит графики по наборам данных. Но недавно мы наткнулись на простой способ, позволяющий с помощью Windows Perfmon сравнивать наборы данных esxtop с разных хостов ESXi.
1. Итак, сначала нужно собрать данные с хоста ESXi в пакетном режиме в файл .csv. Например:
esxtop -b -d 10 -n 360 > esxtopresults.csv
Здесь:
-b - означает пакетный режим работы утилиты.
-d (delay) - промежуток между срезами сбора данных.
-n - число число таких срезов (сэмплов).
В данном случае будет собрано 360 сэмплов данных с промежутком в 10 секунд, то есть сбор займет 1 час.
Можно сжать результаты, чтобы экономить место на хосте, командой:
2. Загружаем данные в Windows Perfmon, выбрав источник - наш файл csv:
Визуализируем нужные счетчики:
3. Пробуем добавить еще один csv с другого хоста ESXi (с которым мы хотим сравнить данные первого хоста), но нам говорят, что так нельзя - можно такие файлы смотреть только по одному:
Не беда - сохраняем данные как бинарный файл с расширением *.blg, выбрав нужные счетчики:
Дальше просто удаляем этот файл из источников данных Perfmon, добавляем второй csv-файл и так же сохраняем его как *.blg.
Ну а дальше оба этих файла добавляем по одному - и все работает:
Добавляем сохраненные счетчики:
И данные с обоих хостов показываются на одном графике:
Сегодня мы хотим рассказать еще о двух вещах. Во-первых, компания 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 по-прежнему один).
В этот раз сравнивалось некий дисковый массив "all flash storage array", который работает на SSD-накопителях, и 7-ми и 8-ми узловые кластеры Virtual SAN. Результаты в очках, поставленных VDImark (View Planner QoS), поставленные кластеру из хостовых хранилищ и дисковому массиву:
Напомним, что очки VDImark - это число виртуальных машин, которое может быть запущено на данной аппаратной конфигурации с соблюдением определенного порогового значения для операций (на самом деле минимум 95% операций должны попасть в эти трешхолды для ВМ, чтобы их засчитали).
Результаты тестов оказались весьма неплохими. Картинка для тестов по времени отклика операций группы А (интерактивные операции пользователя):
Группа B:
Вывод: Virtual SAN - очень неплох в сравнении с нативной производительностью какого-то SSD-массива (VMware, что это за массив-то??).
Уже довольно давно мы писали про техники кэширования в продукте 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, так как последнее - более умная и эффективная технология, разработанная изначально для виртуальных машин.
Сегодня мы хотим обратить внимание на два интересных документа, которые раскрывают подробности использования этой технологии.
Напомним, что Flash Read Cache позволяет использовать кэширование данных только на чтение для дисков VMDK виртуальных машин, работает она на уровне гипервизора и существенно улучшает производительность виртуальных машин, которые интенсивно используют подсистему ввода-вывода для операций на чтение. Очевидно, что SSD-кэш, который по производительности находится между оперативной памятью и обычными дисками, существенно повышает быстродействие в системах, где периодически наблюдается недостаток ресурсов RAM. Все это дело работает в кластере до 32 хостов ESXi.
В этом документе описано, как работает инфраструктура 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 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% для данного случая. Поэтому не меняйте просто так число ядер на процессор. Само же количество процессоров можно менять смело.
Дополнительную информацию по этому вопросу можно найти тут:
Сразу после релиза обновленной версии платформы 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 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:
Соединение как с отдельным хостом ESXi, так и с vCenter Server.
Гибкий способ пакетного вывода результатов.
Загрузка результатов пакетного вывода и его "прогонка" (replay).
Возможность открыть несколько окон для отображения различных данных одновременно.
Визуализация в виде графика выбранных счетчиков производительности.
Гибкий выбор и фильтрация счетчиков.
Тултип на ячейках счетчиков, объясняющий их назначение (см. картинку).
Цветовое кодирование важных счетчиков.
Также VisualEsxtop можно заставить работать под Mac OS X - для этого почитайте вот эту статью.
Скачать VisualEsxtop можно по этой ссылке. Четырехстрочная инструкция доступна тут.
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. Кроме того, доступен отдельный мониторинг и контроль ресурсов этих виртуальных машин.
В целом, VMware заявляет, что Apache Hadoop исполняется в виртуальных машинах практически без потерь производительности (об этом можно почитать здесь):
Скачать VMware vSphere Big Data Extensions v1.0 Beta можно по этой ссылке.
Таги: VMware, vSphere, Hadoop, Big Data, Performance
Не так давно мы писали про средства управления питанием хост-серверов 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 является наиболее оптимальной с точки зрения энергопотребления/производительности, поэтому-то она и установлена по умолчанию.
Таги: VMware, ESXi, Performance, vSphere, Hardware, Power
Мы уже писали о компании 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 можно по этой ссылке.
Этот документ рассказывает о том, как нужно конфигурировать стандартный образ 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 Horizon View. Рекомендации касаются размещения базовых образов и пулов связанных клонов, протоколов хранения, систем хранения данных и методик улучшения производительности.
У компании 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 - используются для удаленного режима или пассивных тестов, т.е. те, откуда происходит доступ к виртуальным ПК.
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 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\
Сама утилитка может работать в трех режимах:
Default - если указан путь к drmdump, то выводятся все ВМ кластера, их назначенные ресурсы, а также запрашиваемые ресурсы.
Guided - если указан путь к drmdump и целевые параметры ресурсов ВМ, то утилита сгенерирует набор рекомендаций для их достижения.
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-диски):
Guest operating system
Data Disk
Boot Disk
Windows Server 2008 R2 (64-bit only)
ESX/ESXi 4.0 Update 1, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 1, ESX/ESXi 4.1, ESXi 5.0
Windows Server 2008 (32 and 64 bit)
ESX/ESXi 4.X, ESXi 5.0
ESX/ESXi 4.0 Update 1, ESX/ESXi 4.1, ESXi 5.0
Windows Server 2003 (32 and 64 bit)
ESX/ESXi 4.x, ESXi 5.0
ESX/ESXi 4.x, ESXi 5.0
Windows 7 (32 and 64 bit)
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
Windows Vista (32 and 64 bit)
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
Windows XP (32 and 64 bit)
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
Red Hat Enterprise Linux (RHEL) 5 (32 and 64 bit) and all update releases
ESX/ESXi 4.X, ESXi 5.0
Not Supported
RHEL 6 (32 and 64 bit)
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
SUSE Linux Enterprise 11 SP1(32 and 64 bit) and later releases
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
Ubuntu 10.04 (32 and 64 bit) and later releases
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
Distros using Linux version 2.6.33 or later and that include the vmw_pvscsi driver
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
В 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.
В рамках Phase V (они величают свои изыскания "фазами") был опубликован 80-страничный документ "Antivirus impact and best practices on VDI", в котором они сравнивают производительность различных антивирусных решений в инфраструктуре VDI (традиционно рассматривалась платформа VMware View / vSphere).
КДПВ из какого-то исследования (есть в документе):
Поэтому детально сравниваются только 3 антивируса для VDI:
Microsoft
Forefront Endpoint Protection 2010 (Now System Center Endpoint Protection 2012)
McAfee
- Enterprise 8.8.0
- MOVE Multiplatform AV 2.x
- MOVE Agentless AV 2.5
Symantec
- Endpoint Protection 12.1
Странно, что обошли стороной компанию Trend Micro с ее весьма популярным, заточеннымспециально под виртуализацию, решением Deep Security. Ну а нам было бы интересно посмотреть, как ведет себя Касперский в среде VDI. Но чего нет, того нет.
Конечно же, в документе рассмотрены и варианты развертывания, когда антивирусный агент работает за пределами виртуальных машин (за счет механизма VMsafe и EPSEC API):
В конце там много всяких графиков без окончательного вывода о том, что же все-таки лучше. Поэтому смотрите сами.
На днях компания VMware провела целых два тестирования (тут и тут), целью которых было сравнение производительности виртуальных дисков VMDK и RDM виртуальных машин на платформе VMware vSphere 5.1. Напомним про предыдущие сравнения VMFS и RDM, где основной моралью был тот факт, что оба этих типа виртуальных дисков практически идентичны по производительности, поэтому их следует использовать только в случаях, когда требуется специфическая функциональность (например, кластеры MSCS и большие диски для RDM):
Итак, для первого тестирования использовалась следующая конфигурация:
В качестве нагрузки использовался тест DVD Store для приложения, симулирующего интернет-магазин на платформе mySQL 5.5. Также было задействовано несколько тестовых клиентов для создания реальной нагрузки.
Масштабируемость производительности под нагрузкой (OPM - это orders per minute):
Как видно из результатов, масштабируемость производительности при увеличении числа ВМ почти линейная, а результаты различных типов дисков - идентичны (на самом деле, VMDK показал себя на 1 процент быстрее RDM для 1-й ВМ и чуть медленнее для 4-х ВМ):
Затраты ресурсов CPU на обслуживание операций ввода-вывода также чуть-чуть (на тот же 1%) лучше в пользу VMDK:
Теперь обратимся ко второму исследованию. Там использовалась следующая тестовая конфигурация, выдающая 1 миллион IOPS на тестах:
Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: Two Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: Five QLogic QLE2562
Storage: One Violin Memory 6616 Flash Memory Array
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Configuration: Random, 4KB I/O size with 16 workers
Тут уже измерялась производительность в IOPS для виртуальных машин на платформе VMware vSphere 5.1. При этом варьировался размер блока ввода-вывода (I/O Size) и сравнивались VMDK диски в VMFS5 и RDM-тома (нагрузка - случайное чтение):
Здесь уже на тот же самый 1% выигрывает RDM (для тестов на I/O). В тестах на MB/s ситуация в одном тесте оказалась в пользу VMFS. Масштабируемость тут уже показана не совсем линейная, при этом завал кривой начинается после размера блока в 4 Кб (единственный и по умолчанию в vSphere 5.1).
Второй тест - 60% операций чтения и 40% операций записи:
Такой рост производительности на блоке в 4 Кб объясняется просто - массив, примененный в тестировании, использует размер блока 4 Кб.
Вывод обоих тестов - виртуальные диски VMDK и RDM практически идентичны с точки зрения производительности.
С приходом Нового года в продукте VMware vCenter, входящем в состав vSphere 5.1, была обнаружена ошибка, следствием которой является отображение за прошедший год статистик производительности (Performance history) только за последние 30 дней (декабрь).
Данная ошибка является следствием недоработок в хранимых процедурах БД vCenter Server, что приводит к удалению (purge) объектов базы данных, касающихся производительности. Исправления ошибки и никакого workaround'а пока нет.
С одной стороны, эти данные не являются критичными и, зачастую, не используются администраторами, однако различные продукты, которые используют исторические данные для анализа и планирования мощностей инфраструктуры виртуализации (Capacity Planning), не смогут уже выполнять свои функции адекватно.
Для получения информации об исправлении ошибки можно подписаться на KB 2042164.
Не так давно мы писали про то, как работает механизм динамического выравнивания нагрузки на виртуальные хранилища VMware Storage DRS. Напомним, что он работает на базе 2-х параметров хранилищ:
Заполненность - в этом случае SDRS выравнивает виртуальные машины для равномерного заполнения хранилищ.
Производительность - при использовании этих метрик SDRS старается динамически перенести виртуальные машины с более нагруженных по параметрам ввода-вывода хранилищ на менее загруженные.
Однако бывает так, что несколько виртуальных хранилищ (Datastores) располагаются на одних и тех же RAID-группах, а значит миграция хранилищ виртуальных машин между ними ничего не даст - суммарно бэкэнд-диски системы хранения будут испытывать ту же самую нагрузку.
Например, бесполезна (с точки зрения производительности) будет миграция с Datastore1 на Datastore2:
Раньше этот факт не учитывался механизмом SDRS в vSphere 5.0, что приводило к бесполезным миграциям в автоматическом режиме. Теперь ситуация изменилась к лучшему в версии vSphere 5.1.
Как многие знают, в VMware vSphere есть механизм Storage IO Control (SIOC), который позволяет измерять мгновенную производительность хранилищ (параметр latency - задержка команд ввода-вывода) и регулировать очередь HBA-адаптеров на хостах ESXi. Так вот, одна из техник SIOC Injection позволяет производить тестирование виртуальных хранилищ на наличие корреляции производительности между ними.
Делается это следующим образом: SIOC запускает тестовую рабочую нагрузку на случайно выбранном Datastore1, измеряет latency, а потом отдельно от него запускает нагрузку на другом Datastore2 и также смотрит на latency:
Это нужно для установления базового уровня производительности для этих виртуальных хранилищ. Потом SIOC запускает нагрузку одновременно на 2 этих хранилища и смотрит, что происходит с latency:
Если оба этих хранилища физических расположены на одних и тех же дисковых устройствах (как в нашем случае), то измеряемые latency в данном случае возрастут, что говорит о взаимной корреляции данных хранилищ в плане производительности.
Узнав про этот факт, Storage DRS не будет генерировать рекомендации по перемещению виртуальных машин между хранилищами Datastore1 и Datastore2:
Однако эти рекомендации перестанут генерироваться только на базе производительности, на базе заполненности хранилищ такие рекомендации останутся.
Достаточно давно, известный многим Duncan Epping писал о стартапе CloudPhysics, для которого он является техническим эдвайзором, и который выпускает продукт в виде виртуального модуля (Observer Virtual Appliance), систематизирующий информацию о количественных параметрах виртуальной среды VMware vSphere в виде карточек. На основе этих карточек можно составить заключение о существующих проблемах своей инфраструктуры виртуализации:
Для работы продукта потребуется установить OVA-модуль в своем окружении VMware vSphere, а дальше для просмотра параметров карточек можно использовать веб-консоль (для кого-то это может быть проблемой, так как данные посылаются на сервер CloudPhysics, однако они утверждают, что данные полностью обезличены).
Сами карточки формируются на базе опросов пользователей и всяческих голосований, которые проводятся, например, на конференциях VMworld. Вот примеры таких карточек:
Затем лучшие карточки, будучи реализованными технически, попадают в основной интерфейс продукта (при этом для появления новых карточек не обязательно обновлять виртуальный модуль в своей инсталляции).
Помимо этого есть всякие технические детали о виртуальной инфраструктуре, корелляции параметров и необычные метрики. В общем, для больших инсталляций в плане траблшутинга - штука интересная, попробуйте, это пока бесплатно.
Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: 2 x Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: 5 x QLA2532
Storage: 2 x Violin Memory 6616 Flash Memory Arrays
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Config: 4K IO size w/ 16 workers
Напомним, что на прошлом VMworld 2011 также была показана производительность в 1 миллион IOPS (300 000 для одной машины), но для хост-сервера VMware ESXi (суммарно от нескольких виртуальных машин).
Также из любопытных фактов, озвученных на VMworld 2012:
60% серверов уже являются виртуальными, VMware стремится к показателю 90% и более.
Число сертифицированных специалистов VMware VCP достигло 125 тысяч.
В VMworld 2012 приняли участие 20 000 специалистов.
Основная концепция на ближайшее будущее - "Software-defined data center" (по аналогии с приобретенной недавно концепцией компании Nicira - Software-defined networking). Предполагается, что ключевые позиции в этой концепции займут продукты VMware vSphere, vCloud Director, vCloud Connector, Site Recovery Manager, vCenter Operations и vFabric Application Director.
Больше об облачных инициативах VMware - в самое ближайшее время.