Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4280 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: vCloud Air Network (vCAN) теперь называется VMware Cloud Provider Program

Новая версия продукта Login PI с возможностями Predictive Power от компании Login VSI.


Пару лет назад мы писали о продукте Login PI от компании Login VSI, который позволяет в реальном времени создавать нагрузку в виртуальном ПК для различных приложений (то есть открывать окна, выполнять некоторые операции), будто бы за этой виртуальной машиной работает реальный пользователь.

Далее, если время выполнения стандартных операций превышает некоторые пороговые значения (например, приложение запускается слишком долго), Login PI оповещает системного администратора о возникшей проблеме. Из коробки измеряется время запуска таких приложений, как Microsoft Office, Internet Explorer и Adobe Reader, но скрипты можно настроить на использование любых приложений.

На прошедшем VMworld Europe 2017 была представлена обновленная версия решения Login PI, в которой появилась возможность Predictive Power. Эта штука позволяет на основе имеющихся исторических данных о производительности экстраполировать их на будущее (на период до одного месяца вперед), что позволит выявить потенциальные проблемы с нехваткой ресурсов, которые могут произойти через некоторое время.

Вот, например, нормальный режим работы инфраструктуры:

Мы видим, что метрика отклика операции логина иногда имеет небольшие всплески, но тренд в целом постоянный.

Здесь тоже есть пики всплесков по Latency, но в целом все стабильно и до установленного трешхолда еще далеко:

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

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

В принципе, штука полезная. Скачать продукт Login PI можно по этой ссылке.


Таги: VMware, Login VSI, Performance, VDI

Анонсы VMworld 2017 - решение VMware Wavefront для поиска аномалий в поведении приложений.


Продолжаем рассказывать об анонсах продуктов и технологий, представленных на конференции VMworld 2017. Компания VMware представила интересный продукт, позволяющий выявлять отклонения в поведении приложений в крупных инфраструктурах - VMware Wavefront. Это продукт одноименной компании, которую VMware приобрела в апреле этого года.

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

Там, где есть подразделения DevOps и команды разработки, Wavefront позволит собирать миллионы метрик от приложений в инфраструктуре компании, отслеживать их и представлять в виде дэшбордов на стороне облака. Также он работает как аддон к существующим приложениям и позволяет собирать их метрики в действительно большие массивы данных и обрабатывать их. Кроме того, у решения есть очень функциональный API.

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

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

Вот пример выявления аномалий в поведении приложений с помощью Wavefront:

Также Wavefront предоставляет полную интеграцию с Amazon AWS, включая компоненты AWS billing, pricing, EC2,
ECS, ELB, Lambda, DynamoDB и Redshift.

Остальные аспекты работы сервиса Wavefront можно увидеть в обзорных видео на отдельном канале, посвященном продукту. А вот тут можно скачать целую книгу по мониторингу метрик с помощью Wavefront.


Таги: VMware, Wavefront, Performance, Cloud, DevOps, Enterprise

Новый документ VMware - "Blast Extreme Display Protocol in VMware Horizon 7".


В августе компания VMware выпустила интересный документ о том, как устроен, работает и настраивается протокол Blast Extreme для виртуальных десктопов VMware Horizon 7.

Напомним, что высокопроизводительный протокол Blast Extreme может использовать как протокол TCP, что позволяет ему адаптироваться к параметрам канала (когда важна непрерывность передачи потока, но допускается отставание от происходящего в оригинале), так и UDP - когда важна скорость передачи без отставания от происходящего (в этом случае будет "перепрыгивание" картинки при узком канале).

В целом в большинстве случаев Blast показывает результаты лучше своего аналога - протокола PCoIP. Об улучшениях Blast Extreme в последней версии решения для виртуализации настольных ПК VMware Horizon 7.1 мы писали вот тут.

Документ "Blast Extreme Display Protocol in VMware Horizon 7" рассказывает о следующих ключевых аспектах использования протокола:

  • Эволюция протокола и появление новых фич.
  • Технологии, вложенные в него (как Lossy, так и Lossless).
  • Подробное описание применяемых в решении кодеков.
  • Архитектура решения и схемы соединений на уровне портов как изнутри VDI-инфраструктуры, так и извне.
  • Средства обеспечения безопасности.
  • Лог-файлы.
  • Развертывание компонентов протокола.
  • Конфигурация клиентских устройств и верификация конфигов.
  • Советы по оптимизации протокола.

Таги: VMware, Blast, Whitepaper, VDI, Performance

Демо-видео VMware vSAN 6.6.1 Performance Diagnostics.


Недавно мы писали о новых возможностях отказоустойчивого кластера VMware vSAN 6.6.1, среди которых есть функция Performance Diagnostics, которая позволяет запускать различные бенчмарки и сравнивать полученные результаты с предыдущими их выполнениями.

По результатам исполнения бенчмарков выдаются рекомендации по увеличению производительности кластера хранилищ, такие как увеличение размера дисковой группы, добавление новых дисковых групп или изменение числа виртуальных машин. Тест проводится около 1 часа, после чего делается вывод о том, достигнуты ли значения параметров maximum IOPS, maximum throughtput и minimum latency. Если нет - то будут выписаны рекомендации.

Дункан Эппинг решил записать небольшое видео с обзором этой возможности, где он показывает результаты работы механизма диагностики производительности:

Надо сказать, что данные, собираемые на стороне кластера vSAN, в обезличенном виде передаются на сторону облака VMware, там анализируются и ответ обратно передается на сторону vSphere Web Client. Поэтому и требуется, чтобы Customer Experience Improvement Program (CEIP) была включена (в последних версиях она включена по умолчанию).

Полезно, что если вы не знаете, как интерпретировать результаты тестов, вы можете нажать ссылку Ask VMware и попасть на статью KB, где описывается, как должны выглядеть оптимальные значения, и что предпринять, если полученные результаты вас не устраивают.


Таги: VMware, vSAN, Performance, Video

Отчет Principled Technologies - VMware vSphere производительнее, чем RedHat Enterprise Virtualization.


На днях вышел интересный отчет компании Principled Technologies, специализирующейся, в том числе, на всякого рода тестировании аппаратно-программных сред. В документе "VMware vSphere memory overcommitment delivered greater VM density than Red Hat Virtualization" рассказывается о том, что на одном и том же оборудовании с помощью гипервизора ESXi можно запустить больше виртуальных машин, чем на гипервизоре KVM платформы RHEV.

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

Для тестирования использовался стоечный сервер Lenovo x3650 M5, на котором в виртуальных машинах работала СУБД Microsoft SQL Server 2016 с нагрузкой типа OLTP. В качестве основного показателя производительности использовался OPM (orders per minute), отображающий количественную оценку исполненных транзакций.

Если не использовать техники Memory Overcommit, то результат выполнения на 15 виртуальных машинах одного хоста в числе OPM примерно одинаковый на обоих гипервизорах:

А вот когда происходит увеличение числа виртуальных машин, то vSphere показывает себя значительно лучше:

Крестиками отмечены машины, которые на RHV просто не запустились, консоль продукта выдала вот такую ошибку:

Несмотря на включение техник оптимизации памяти в Red Hat Virtualization Manager (RHV-M), таких как memory ballooning и kernel shared memory, шестнадцатая виртуальная машина все равно отказывалась запускаться на KVM:

Ну а на vSphere продолжали наращивать число ВМ, пока не уперлись в недостаток ресурсов:

Получилось, что с техниками overcommit на vSphere получилось запустить 24 виртуальных машины, а на RHV - всего 15 штук. По итогу сделали вывод, что на VMware vSphere в 1,6 раза можно запустить больше виртуальных машин:

Не сказать, что это объективное тестирование, но очевидно, что ESXi в данном случае работает лучше KVM с точки зрения всяких оптимизаций памяти и прочих ресурсов ВМ.


Таги: VMware, Red Hat, Performance, RHV, vSphere, ESXi, KVM

VMware Horizon Virtualization Pack for Skype for Business - тесты производительности.


Некоторое время назад мы писали о бета-версии VMware Horizon Virtualization Pack for Skype for Business - решении, которое предназначено для оптимизации голосовых и видеовызовов Skype в виртуальных ПК бизнес-пользователями приложения. Некоторое время назад VMware объявила о выпуске финальной версии этого продукта, а также опубликовала несколько интересных материалов по теме.

Во-первых, вот такое обзорное видео продукта и используемых технологий:

Во-вторых (и это самое интересное), видеоотчет о тестировании решения при совершении звонков в рамках нескольких регионов США:

Суть теста заключалась в следующем: сначала использовали видеозвонок по скайпу типа "точка-точка", который обслуживала встроенная технология оптимизации VMware Real-Time Audio-Video (RTAV). В этом случае виртуальные десктопы находились за 3000 миль от звонящих, и трафик ходил дважды это расстояние, хотя звонящие находились физически недалеко друг от друга:

В этом случае Latency в одну сторону составляло где-то 100 миллисекунд, а производительность видеовызова была не на высоте.

Для второго теста использовался как раз Horizon Virtualization Pack for Skype for Business, который позволяет организовать прямую передачу аудио и видеопотока между конечными устройствами пользователей. Остальные условия были теми же самыми.

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

Более подробно о решении VMware Horizon Virtualization Pack for Skype for Business можно узнать на этой странице.


Таги: VMware, Horizon, Skype, Performance, VDI

Улучшения производительности VMware vSAN 6.6 по сравнению с 6.5.


Весной этого года вышло обновление решения для создания отказоустойчивых кластеров для виртуальных машин на платформе vSphere - VMware vSAN 6.6. Прошлая версия продукта Virtual SAN 6.5 вышла еще осенью 2016 года, и vSAN 6.6 заметно продвинулся в плане функционала. Но, оказывается, это решение стало еще и существенно лучше в плане производительности. И на эту тему есть полезный документ "vSAN 6.6 Performance Improvements", описывающий результаты тестирования обеих версий продукта.

Для тестов использовалось одинаковое оборудование (кластер All-Flash) и 3 типа симуляции рабочей нагрузки:

  • Random Read
  • Random Write
  • Mixed random Read/Write (70/30%)

Посмотрим на графики, показывающие улучшения в различных аспектах:

Большое рабочее множество данных (Large Working Set)

Это самый нагрузочный вариант использования системы хранения, когда на нее идут длинные и непрерывные операции записи, иногда перемежающиеся операциями чтения.

Так выглядит суммаризованный график улучшения по числу IOPS для трех типов нагрузок и различных уровнях RAID:

Вот так выглядит уменьшение задержек при обращении к дискам (Latency). Чем ниже столбик - тем сильнее уменьшилась задержка:

Так выглядит отдельный график по IOPS для типа нагрузки 70% чтения и 30% записи:

Так выглядит Latency для этого типа нагрузки:

IOPS для Random Writes:

Latency для Random Writes:

Малое рабочее множество данных (Small Working Set)

Этот вариант использования хранилища меньше зависит от аппаратных особенностей и больше способен показать улучшения, сделанные в программных компонентах. Несмотря на то, что он не встречается в чистом виде (как впрочем и Large Working Set), малые рабочие множества встречаются в среде, где работают много небольших задач одновременно, обращения которых к хранилищам перемешиваются в потоке ввода-вывода.

Так выглядит суммаризованный график улучшения по числу IOPS для трех типов нагрузок и различных уровнях RAID (заметьте, что процент улучшений здесь значительно выше, чем для Large Working Set):

Вот так выглядит уменьшение задержек при обращении к дискам (Latency). Чем ниже столбик - тем сильнее уменьшилась задержка (также улучшения более существенны, чем для Large Working Set):

Так выглядит отдельный график по IOPS для типа нагрузки 70% чтения и 30% записи:

Так выглядит Latency для этого типа нагрузки:

IOPS для Random Writes:

Latency для Random Writes:

В целом, мы видим, что по всем параметрам и для всех аспектов (рабочее множество, тип нагрузки, уровень RAID) решение vSAN 6.6 обходит своего предшественника (а в некоторых случаях - весьма существенно).


Таги: VMware, vSAN, Performance, Storage

Новый документ "Performance Best Practices for VMware vSphere 6.5".


Компания VMware выпустила долгожданный документ, раскрывающий основные аспекты лучших практик для своей серверной платформы виртуализации в плане производительности - "Performance Best Practices for VMware vSphere 6.5".

В документе более 100 страниц, и он раскрывает практически все аспекты управления виртуальной инфраструктурой и работой виртуальных машин на хост-серверах VMware ESXi.

Вот какие вопросы позволяет решить прочтение данного документа:

  • Подбор необходимого оборудования в качестве хостов для виртуальных машин и управляющих серверов.
  • Настройка серверов ESXi и виртуальных машин на них в целях оптимизации производительности.
  • Применение рекомендаций по конфигурации различных гостевых операционных систем, работающих в ВМ.
  • Настройка всех компонентов инфраструктуры управления платформой vSphere. Это самый интересный пункт, из которого можно узнать лучшие практики по работе с DRS, HA, Fault Tolerance, vSAN и многими другими продуктами и технологиями VMware.

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


Таги: VMware, Performance, Whitepaper

Новый документ "VMware Horizon Apps Performance Reference Architecture".


Не так давно мы писали про документ "RDSH Session Load-Balancing in Horizon 6 and Horizon 7", в котором рассматриваются вопросы балансировки нагрузки на ферму серверов RDSH, в рамках которой работают терминальные приложения и сессии пользователей.

Ну а на днях VMware выпустила на тему RDSH не менее интересный документ "VMware Horizon Apps Performance Reference Architecture", раскрывающий вопросы производительности большой инфраструктуры доставки приложений и терминальных сессий.

Для тестов была взята некая референсная архитектура решения, работающая на базе технологии App Volumes с пулами наиболее используемых приложений, и рассмотрены различные варианты отработки виртуальной инфраструктурой нагрузок в гостевых системах. Сами виртуальные десктопы создавались посредством технологии Instant Clone.

Вот такая архитектура рассматривалась при тестировании:

А так были распределены рабочие нагрузки по хост-серверам VMware ESXi:

Результаты рассматривали в пяти аспектах:

1. Производительность работы пользователей (User-Experience Performance Results).

Время отклика при росте количества одновременных сессий всегда находилось в норме и росло линейно:

2. Пиковые нагрузке при массовой загрузке десктопов (Boot Storms).

Хосты отрабатывали нагрузки Boot Storms на 70% загрузках мощности, после чего нормализовывали текущий уровень:

3. Производительность работы хост-серверов (Host Performance Results).

Хосты RDSH отрабатывали хорошо:

А хосты обслуживания инфраструктуры vSphere и Horizon еще лучше:

4. Производительность виртуальных машин (Virtual Machine Performance Results).

Машины в среднем не были загружены по ресурсам в пике более чем на 50%:

5. Производительность подсистемы хранения (Storage Performance Results).

Виртуальные машины RDSH выдавали вполне приемлемые показатели производительности хранилищ:

На самом деле, документ содержит десятки интересных графиков, таблиц и инсайтов. Очень рекомендуется к прочтению тем, кто планирует у себя развертывание инфраструктуры виртуализованных приложений и терминальных серверов RDSH.


Таги: VMware, Horizon, Performance, RDSH, VDI, Whitepaper

Новый технический документ VMware - RDSH Session Load-Balancing in Horizon 6 and Horizon 7.


Как многие из вас знают, некоторое время назад VMware начала конкурировать с продуктом Citrix XenApp в своем решении VMware Horizon за счет обслуживания механизма доступа Microsoft RDSH (Remote Desktop Session Host) на серверах через Connection Server. На эту тему есть даже документ "Introduction to VMware Horizon 7 for Citrix Administrators", о котором мы недавно рассказывали.

В июне компания VMware выпустила интересный документ "RDSH Session Load-Balancing in Horizon 6 and Horizon 7", в котором рассматриваются вопросы балансировки нагрузки на ферму серверов RDSH, в рамках которой работают терминальные приложения и сессии пользователей.

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

  • Балансировка на основе данных о производительности Windows Perfmon.
  • Размещение новых сессий за счет механизма правил Anti-affinity. Например, за счет паттернов anti-affinity можно определить, что на хосте RDSH можно запустить не более одного экземпляра тяжелого приложения AutoCAD.

Механизм анализа данных Perfmon для CPU, памяти и прочих ресурсов, реализованный в специальном скрипте, позволяет сообщить серверу Horizon Connection Server о том, в каком состоянии с точки зрения нагрузки он сейчас находится. Справа мы видим матрицу этих состояний:

Соответственно, на основе этих данных серверы Horizon Connection Servers принимают решение о том, куда направить ту или иную сессию RDSH. Понятное дело, что новые сессии будут направляться на хосты с преференсом HIGH (то есть, с низкой загрузкой системных ресурсов).

Ну а остальное вы можете узнать из документа "RDSH Session Load-Balancing in Horizon 6 and Horizon 7".


Таги: VMware, Horizon, Whitepaper, RDSH, Performance

VMware vCenter Cluster Performance Tool - утилита для определения производительности кластера в ракурсе различных метрик.


На сайте проекта VMware Labs появился интересный PowerCLI-скрипт vCenter Cluster Performance Tool, с помощью которого можно получить информацию о производительности кластера за счет агрегации данных, поступающих от хостов VMware ESXi.

Это уже вторая версия сценария, переработанная на базе механизма модулей PowerCLI 6.0 (ранее она была построена на снипетах).

Для работы сценария понадобится указать 2 следующих параметра:

  • Интервал от 20 до 300 секунд. По умолчанию это 20 секунд, что соответствует сбору статистики в близкому к реальном времени, а значение 300 даст пятиминутный интервал между сборами, чтобы не создавать лишнюю нагрузку.
  • Специальный флаг для получения списка уникальных идентификаторов счетчиков производительности, доступных на vCenter Server (нужно указать -1 в качестве аргумента для получения списка). Далее можно использовать один из полученных идентификаторов для вывода соответствующей метрики для кластера.

Возможности скрипта vCenter Cluster Performance Tool:

  • Сбор всех данных в указанном интервале, которые доступны на каждом хосте заданного кластера.
  • Простой способ запуска сценария.
  • Данные сохраняются в файл CSV, которые можно подставить в любое средство визуализации.
  • Также генерируется график в формате картинки PNG (как показано выше).

Для работы скрипта потребуется VMware vCenter Server 5.0 или более поздний, а также Microsoft Chart Controls для Microsoft .NET Framework 3.5. Скачать vCenter Cluster Performance Tool можно по этой ссылке.


Таги: VMware, PowerCLI, Labs, vCenter, Performance

Новый документ: What's New in Performance? VMware vSphere 6.5.


В апреле компания VMware выпустила интересный документ, касающийся улучшений в плане производительности различных компонентов последней версии платформы виртуализации - "What's New in Performance? VMware vSphere 6.5".

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

Итак, посмотрим на количественные оценки улучшений. Вот так улучшилось число операций в минуту, которое может выдавать VMware vCenter 6.5:

А вот на столько уменьшилось время этих операций в VMware vSphere Web Client:

Кроме того, как вы знаете, в vSphere 6.5 есть HTML 5 Client (он сейчас называется просто vSphere Client). Основные операции он выполняет намного производительнее своего предшественника - Web Client:

Шифрование vMotion практически не влияет на время этой операции:

Но CPU при выполнении шифрования vMotion нагружается сильнее, соответственно требуется задействовать больше ядер процессора:

При шифровании дисков виртуальных машин производительность в IOPS также падает для обычных HDD-дисков, но это практически незаметно для SSD-дисков:

Ну и уменьшение Latency (задержки) при использовании технологии Direct Path I/O для сетевого адаптера, очень близко к нативной производительности:

Скачать документ "What's New in Performance? VMware vSphere 6.5" можно по этой ссылке.


Таги: VMware, vSphere, Performance, Whitepaper

Новый документ - "DRS Cluster Management with Reservation and Shares".


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

Основным источником знаний о Reservation и Shares является документ "Resource Management Guide", однако он большой и нудный, а на днях VMware выпустила более простую версию, сфокусированную на управлении кластером DRS с точки зрения резерваций и шар - "DRS Cluster Management with Reservation and Shares".

Именно из этого документа лучше узнать, как работают Shares (распределение ресурсов) и Reservations (гарантирование ресурсов) в рамках отдельных виртуальных машин, пулов ресурсов в рамках кластера DRS с учетом возможности заимствования ресурсов из родительского пула (expandable reservation).

Конечно же, если вы администратор платформы VMware vSphere, то вы должны были разобраться с этим всем еще в самом начале, но если какие-то аспекты работы механизмов гарантирования и распределения ресурсов вам остались непонятными, обязательно пробегитесь по документу "DRS Cluster Management with Reservation and Shares".


Таги: VMware, DRS, Whitepaper, Performance

Обновленная версия утилиты IOInsight 1.1 на VMware Labs.


В феврале мы писали о средстве IOInsight, которое позволяет детально взглянуть на характеристики взаимодействия виртуальных машин с хранилищами и провести анализ метрик ввода-вывода на уровне отдельных VMDK-дисков.

На днях на сайте проекта VMware Labs появилось обновление этого виртуального модуля - IOInsight 1.1.

Давайте посмотрим на новые возможности последней версии:

  • Утилита командной строки для установки статического IP-адреса или DHCP.
  • Опция для установки NTP-севреров.
  • Опция в интерфейсе, позволяющая настроить отсылку логов и результатов вывода IOInsight разработчикам для последующего решения проблем.

Вот какие ошибки были исправлены и улучшения добавлены:

  • Устранены проблемы с логином к vCenter.
  • Обработка спецсимволов в именах машин.
  • Улучшенная гистограмма IO-size (данные отображаются корректно).
  • Улучшенный мониторинг дисков VMDK с очень маленькими показателями по вводу-выводу.
  • Улучшенные алерты в интерфейсе и логи продукта.
  • Улучшенная визуализация графиков.

Скачать VMware IOInsight 1.1 можно по этой ссылке.


Таги: VMware, IOInsigth, Update, Labs, Storage, VMDK, Performance

Улучшения протокола Blast Extreme в VMware Horizon 7.1.


Не так давно мы писали о том, что компания VMware выпустила обновленную версию решения для виртуализации настольных ПК предприятия VMware Horizon 7.1. Среди прочих новых возможностей там были и улучшения протокола Blast Extreme, которые мы рассмотрим подробнее ниже.

Напомним, что в Blast Extreme появилась технология Adaptive Transport, которая дает заметный прирост производительности в низкокачественных сетях (с коэффициентом потерь пакетов 20% и выше). Также технологическое превью этого протокола стало доступно для физических компьютеров.

Оптимизация производится за счет того, что Blast Extreme автоматически подстраивается под параметры Bandwidth, Latency и Packet Loss в различных сетях (LAN, public Wi-Fi и т.п.). Протокол Blast поддерживает более 125 тонких клиентов, десктопов, лэптопов и мобильных устройств. Blast Extreme работает по протоколам TCP и UDP на одном порту - 443, с использованием шифрования SSL.

Улучшения, сделанные в Blast Extreme для сетей с высокими показателями задержек (latency), позволяют ускорить передачу файлов в среднем до 4-6 раз. Фреймрейт и качество картинки, принимаемой пользователями в сетях с малой пропускной способностью, улучшилось до 50% по сравнению с прошлыми релизами:

VMware проводила тесты в сети с пропускной способностью 1.5 Mbps и задержкой 200 ms, где потери пакетов доходили до 20% - так вот там производительность возрастала до 12 раз!

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

Blast Extreme предоставляет 3 опции соединения для пользователей:

  1. Excellent (TCP only)
  2. Typical (default, mixed UDP/TCP)
  3. Poor (UDP only)

Пункт Excellent подойдет для LAN-сетей с хорошим качеством (высокая скорость и низкие потери пакетов). В этом случае будет использоваться только TCP протокол - и для управления передачей, и для отправки самих данных.

В случае выбора Poor протокол Blast Extreme будет использовать только UDP для управления передачей и отсылки данных. Это оптимально для WAN-сетей с большими задержками и коэффициентом потерь пакетов 20% и более.

Ну и дефолтный пункт - Typical - это оптимальный выбор для 99% пользователей. В этом случае будет использоваться TCP для управления передачей, а UDP для основной отправки данных, с учетом адаптивного алгоритма. Если по каким-то причинам UDP будет недоступен (например, заблокирован политикой на сетевом экране), то произойдет незаметное для пользователя переключение на TCP.

Обновленный Blast Extreme с технологией adaptive transport доступен для клиентов Horizon Client for Windows, Mac, Linux, iOS и Android версий 4.4 и выше.


Таги: VMware, Blast Extreme, Update, Horizon, Performance, VDI

Проблемы с производительностью хранилищ VMware ESXi 6.5 - медленно копируются файлы, и долго устанавливается гостевая ОС в виртуальной машине.


На интересную проблему обратил внимание Anthony Spiteri в своем блоге - у него после развертывания платформы VMware ESXi 6.5 на сервере с SSD-дисками ISO-образ Windows 2016 полчаса заливался на датастор (интересно, что нам некоторые читатели писали о подобной проблеме). Потом он создал новую виртуальную машину и поставил устанавливаться Windows, а ESXTOP показывал скорость записи 10-20 МБ/с, в то время как она должна была быть на уровне 400-500 МБ/с.

Он стал ковырять проблему дальше и раскопал драйвер, который используется для SATA-контроллера:

Далее он проверил, какие драйверы подсистемы хранения сейчас загружены и используются. Оказалось их два: приведенный выше драйвер и нативный драйвер VMware:

[root@LAB-ESXI-01:~] esxcli software vib list | grep ahci
sata-ahci 3.0-22vmw.650.0.0.4564106 VMW VMwareCertified 2016-11-16
vmw-ahci 1.0.0-32vmw.650.0.0.4564106 VMW VMwareCertified 2016-11-16

Далее он решил отключить нативный драйвер VMware с помощью следующей команды:

[root@LAB-ESXI-01:~] esxcli system module set --enabled=false --module="vmw_ahci"
[root@LAB-ESXI-01:~] esxcli system module list | more

Name Is Loaded Is Enabled
----------------------------- --------- ----------
vmkernel true true
chardevs true true
user true true
....

....
vmkapi_v2_1_0_0_vmkernel_shim true true
vmkusb true true
igbn true true
vmw_ahci true false
iscsi_trans true true
iscsi_trans_compat_shim true true
vmkapi_v2_2_0_0_iscsiInc_shim true true

Как видим, он затем вывел список системных модулей и увидел, что нативный драйвер отключен. После того, как он перезагрузил хост ESXi, все стало летать - гостевая ОС установилась за 5 минут, а тесты внутри ВМ показали высокую скорость чтения-записи.


Таги: VMware, ESXi, Performance, Storage

Новое на VMware Labs: утилита VMware IOInsight для получении детальной информации о взаимодействии ВМ с хранилищами.


На сайте проекта VMware Labs появилась действительно достойная внимания утилита - IOInsight, доступная в виде готового к развертыванию виртуального модуля на платформе vSphere. Она позволяет детально взглянуть на характеристики взаимодействия виртуальных машин с хранилищами и провести анализ метрик ввода-вывода на уровне отдельных VMDK-дисков.

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

В решении каких проблем может помочь IOInsight:

  • Самостоятельная оптимизация производительности и планирование хранилищ пользователями vSphere.
  • Отчет из IOInsight может помочь при обращении в техподдержку VMware, что ускорит решение проблемы.
  • Сотрудники VMware Engineering могут подсказать решения по оптимизации ваших продуктов.

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

Кроме того, предполагается, что администраторы и разработчики сами будут писать плагины к IOInsight, поскольку в состав решения включены SDK и development guide (как видите на картинке, два плагина уже есть). Руководство для обычных пользователей доступно вот тут.

Лучшие практики по использованию IOInsight:

  • 2-4 виртуальных процессора на виртуальный модуль (vCPU)
  • 2 ГБ и более оперативной памяти
  • Желательно разместить IOInsight в той же сети, что и хосты, которые планируется мониторить
  • Нужно выбирать не более 8 VMDK, чтобы не было слишком высокой нагрузки
  • Рекомендуемый период анализа данных - 10-30 минут
  • Cache Simulation analyzer создает нагрузку на процессор, поэтому его нужно запускать для 1 или 2 симулируемых конфигураций кэша (не более)

Утилита IOInsight работает, начиная с версии VMware vSphere 5.5, а скачать ее можно по этой ссылке.


Таги: VMware, Labs, Storage, Performance, ESXi, vSphere, VMDK

Новые документы VMware: производительность vCenter HA, Update Manager и другое.


На днях компания VMware выпустила несколько интересных технических документов, которые могут оказаться полезными в свете выхода новой версии платформы виртуализации VMware vSphere 6.5. Но для начала - интересный ролик о создании кластеров VMware Virtual SAN в маршрутизируемых сетях:

Видео будет полезно всем тем, кто хочет создавать распределенные кластеры Virtual SAN, разнося узлы по разным подсетям. На эту тему есть также несколько полезных ресурсов:

Кроме того, компания VMware выпустила открытый документ "vCenter Server 6.5 High Availability Performance and Best Practices", где описываются сервисы высокой доступности, которые появились в виртуальном модуле VMware vCenter Server Appliance 6.5.

В рамках стрессового тестирования, описанного в документе, были проверены следующие аспекты работы VCHA (vCenter High Availability):

  • Скорость восстановления VCHA и выполнение политики recovery time objective (RTO)
  • Производительность сервера при включенном VCHA
  • Накладные расходы VCHA
  • Влияние на статистики vCenter Server
  • Влияние на сеть
  • Сравнение External Platform Services Controller (PSC) со встроенным Embedded PSC

Второй документ - это "vSphere 6.5 Update Manager Performance and Best Practices". Там описаны лучшие практики по эксплуатации VMware Update Manager и рассказано о производительности VUM. Весьма интересна следующая картинка из документа:

Выходит, что VUM on Linux (который интегрирован с vCSA) работает существенно быстрее, чем его коллега под Windows (в 2 раза для некоторых операций).

Третий документ - "vSphere Virtual Machine Encryption Performance". Не так давно мы писали о том, как работает механизм шифрования в VMware vSphere 6.5, а из этого документа вы узнаете, насколько быстро он работает.

В документе множество графиков, показывающих, что latency при шифровании особенно не меняется (незначительно увеличивается), а вот нагрузка на CPU увеличивается где-то на 20%, что, впрочем, тоже не так уж и много.


Таги: VMware, Whitepaper, VUM, HA, vCenter, Performance

Изменения VMware Storage IO Control и его интеграция в Storage Based Policy Management (SPBM) в обновленной версии VMware vSphere 6.5.


Как мы недавно писали, в новой версии платформы виртуализации VMware vSphere 6.5 появившийся очень давно механизм VMware Storage IO Control (SIOC) теперь работает посредством политик хранилищ (Storage Policies) на базе интерфейса vSphere APIs for IO Filtering (VAIO). О том, как раньше работал SIOC на практическом примере мы уже писали вот тут. А тут мы упоминали о Storage Based Policy Management (SPBM).

Давайте теперь посмотрим, как все это взаимодействует вместе. Во-первых, надо сказать, что Storage IO Control начинает работать, когда на хосте ощущается недостаток ресурсов хранилища (пропускной способности) и виртуальные машины начинают конкурировать между собой. По умолчанию этот механизм выключен, поэтому машины разбираются между собой на общих основаниях.

Давайте включим SIOC для отдельного хранилища. Для этого в vSphere Client нажмем на него правой кнопкой и выберем "Configure SIOC":

Тут мы видим, что есть некоторый Congestion Threshold - это зачение в процентах загруженности хранилища (по пропускной способности) или по Latency (задается вручную), при превышении которого будет включен механизм борьбы за ресурсы SIOC. Также важна галка "Exclude I/O statistics from SDRS" - это Network-Aware DRS, то есть теперь механизм балансировки нагрузки по хранилищам SDRS по умолчанию не перемещает машины на загруженные в плане сети хосты (это можно отключить при желании).

Далее посмотрим на политики хранилищ. Для этого пойдем в раздел VM Storage Policy и далее в Storage Policy Components, где посмотрим параметры дефолтной политики "Normal":

Вот тут-то мы и видим параметры VMware SIOC, которые можно регулировать для данной политики, которая впоследствии будет применена к виртуальной машине или ее отдельным виртуальным дискам. Все то же самое - резервация и лимиты по IOPS, а также shares - то есть доли, которые будут иметь от общего объема shares объекты данной политики.

При создании новой политики хранения можно задать предопределенный набор Reservation, Limit и Shares в качестве компонента Datastore IO Control:

Также в политики хранения можно в качестве правил (rules) задавать определенные сервисы предоставляемые хостом (это понятие Line of Service) - например, шифрование дисков, кэширование, репликация и прочее. Все это доступно для редактирования при задании правил в рамках новой политики хранения (VM Storage Policy):

Ну а для назначения политики надо использовать пункт VM Policies в контекстном меню виртуальной машины, далее выбрать пункт Edit VM Storage Policies:

И далее назначаем стандартную или кастомную политику хранения для всех объектов виртуальной машины (Apply to all) или для отдельных виртуальных дисков (по умолчанию стоит политика, назначенная для всего датастора):

Таким образом, теперь SIOC и SPBM интегрированы в рамках единого рабочего процесса и удобны в использовании при управлении классами обслуживания в плане хранилищ для виртуальных машин и отдельных дисков VMDK.


Таги: VMware, vSphere, SIOC, SPBM, Update, Storage, Performance

Тестирование файловой системы ReFS от StarWind.


В блоге CTO компании StarWind Антона Коломейцева есть интересный тест файловой системы ReFS, которая появилась в серверной ОС Windows Server 2016. В статье "ReFS: Performance" Антон детально рассматривает различные аспекты производительности ReFS, а также подробно описывает конфигурацию среды тестирования и сам процесс его проведения.

Интересен вывод о том, что ReFS с включенной фичей FileIntegrity работает как файловая система Log-Structured File System (LSFS), что очень хорошо для виртуальных машин, так как мелкие команды ввода-вывода объединяются в большие пачки, что позволяет избежать эффекта I/O-блендера.

В общем, интересная статья - почитайте.


Таги: StarWind, ReFS, Performance, Storage

Новое на VMware Labs - утилита HCIbench для организации тестирования производительности инфраструктуры хранилищ Virtual SAN и не только.


На сайте проекта VMware Labs появилась очередная утилита HCIbench, которая может оказаться полезной тем, кому требуется провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.

Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

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

Решение HCIbench позволяет посредством скрипта настроить развертывание новых виртуальных машин, скоординировать в них запуск рабочих нагрузок, агрегировать и вывести результаты тестирования, а также собрать необходимые данные для целей траблшутинга. Ну и тут надо добавить, что HCIbench разработан не только для инфраструктуры VIrtual SAN, но и для любой другой гиперконвергентной инфраструктуры хранилищ, например StarWind.

Суть работы HCIbench проста - пользователь задает параметры работы скрипта, а утилита дает команду Vdbench, какие действия необходимо выполнить в кластере хранилищ.

Вводим число виртуальных машин и дисков, а также их размер:

Задаем тестовую конфигурацию:

Задаем параметры тестирования виртуальных дисков:

Решение состоит из двух компонентов:

  • Виртуальный модуль Controller VM, на котором установлены:
    • Ruby vSphere Console (RVC)
    • Утилита Virtual SAN Observer
    • Automation bundle
    • Файлы конфигурации
  • Тестовая виртуальная машина Linux, используемая как шаблон.

Ну и вот какие задачи может выполнять HCIbench:

  • Соединение с тестируемым окружением Virtual SAN. Утилита может быть в отдельной инфраструктуре vSphere, но нужно иметь доступ к целевому кластеру хранилищ.
  • Развертывание тестовых виртуальных машин с ОС Linux, основываясь на введенных параметрах пользователя (число машин и число виртуальных дисков на одну машину, а также их размер).
  • Опциональный запуск команды dd на каждом из виртуальных дисков, чтобы инициализировать хранилища и создать диски полного размера (thick).
  • Передача параметров VDbench на каждую из тестовых ВМ. В файле конфигурации описана целевая нагрузка и спецификация ее выполнения.
  • Запуск утилиты Virtual SAN Observer перед началом тестирования и генерация статистик по завершению тестов.
  • Удаление тестового окружения инфраструктуры виртуальных машин.
  • Сбор и агрегация данных VDbench.

В итоге мы получаем вот такие графики производительности в Virtual SAN Observer:

Утилита HCIbench поставляется в виде готового виртуального модуля и имеет веб-интерфейс конфигурации. Скачать HCIbench можно по этой ссылке. Инструкция по развертыванию и использованию доступна тут.


Таги: VMware, Labs, Performance, Troubleshooting, Virtual SAN, Storage

Реальная производительность VMware Fault Tolerance в VMware vSphere 6.0.


Как вы знаете, в последней версии платформы VMware vSphere 6.0 технология кластеров непрерывной доступности VMware Fault Tolerance была существенно улучшена (напомним, что добавили поддержку до 4 vCPU и до 64 ГБ памяти). Также в этом году мы писали о тестах производительности технологии FT, которые показали небольшие издержки на поддержание работы таких кластеров (их проводила сама VMware).

Однако есть и другие результаты тестов Fault Tolerance, которые показывают уже не такие бодрые значения. Кстати, напомним, что для FT желательно иметь 10 GbE соединение, иначе на гигабитном линке вы будете получать вот такое предупреждение (хотя все продолжит работать):

Так вот, посмотрим на результаты тестов, которые были сделаны с помощью бенчмарк-утилиты DVDstore. В качестве приложения для тестов использовался MS SQL Server (8GB памяти, адаптер VMXNET3 NIC и контроллер VMware paravirtual SCSI) а также машина с клиентом DVDstore. Между хостами ESXi, на которых были FT-машины, был организован 10-гигабитный линк.

В качестве команды для тестирования нагрузки на MS SQL Server была использована следующая:

ds2sqlserverdriver.exe –target=192.168.150 –run_time=15 –db_size=20GB –n_threads=25 –ramp_rate=5 –pct_newcustomers=10 –warmup_time=0 –think_time=0.085

Ну и, собственно, сами результаты:

 

Основной показатель теста OPM (Orders per Minute) - это оранжевые столбцы. Как видим, добавление новых vCPU не сильно повышает производительность системы, а вот включение Fault Tolerance прямо-таки обрушивает параметр OPM практически в 2 раза (на 47%, если быть точным). Результаты в таблице:

FT disabled FT enabled Difference
OPM test 1 vCPU 12291 6418 -48%
OPM test 2 vCPU 13164 7023 -47%
OPM test 4 vCPU 14139 7458 -47%

Ну и зеленые столбики показывают, как линейно росло использование полосы пропускания с ростом количества виртуальных процессоров (vCPU) для FT. При этом самое большое CPU Latency наблюдалось для одного vCPU.

В итоге, мы видим, что производительность при включении VMware Fault Tolerance вполне себе существенно падает, по крайней мере, при некоторых видах рабочих нагрузок. Поэтому тут главный совет - тестировать технологию в своей инфраструктуре перед тем, как планировать использовать ее в производственной среде.


Таги: VMware, Fault Tolerance, Performance

Возможности Instant Clone в VMware Horizon 7 - насколько быстро и эффективно это работает.


Еще на VMworld 2014 компания VMware анонсировала технологию VMware Project Fargo (которая также называлась VM Fork), позволяющую очень быстро сделать работающую копию работающей виртуальной машины на платформе VMware vSphere.

Суть технологии VMFork такова, что "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory), что и родительская ВМ. При этом дочерняя ВМ в общую память писать не может, а для записи собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ:

В процессе работы VMFork происходит кратковременное "подвешивание" родительской ВМ (quiescence) с помощью технологии "fast suspend resume" (FSR), после чего дочерняя ВМ "отцепляется" от родительской - происходит реконфигурация машины, включающая в себя назначение нового MAC-адреса, получение нового UUID и другое. При этом ВМ шарят общие ресурсы на чтение и имеют свои уникальные области на запись - это очень удешевляет стоимость ресурсов в перерасчете на одну ВМ на хосте.

После выхода новой версии платформы виртуализации настольных ПК VMware Horizon 7 технология VMFork была переименована в Instant Clone и стала доступна для использования в производственной среде. Помимо удешевления стоимости ресурсов для размещения виртуальных машин, Instant Clone имеет еще несколько преимуществ - это делает развертывание виртуальных машин более гибким и быстрым. Ниже мы рассмотрим особенности этих процессов.

В сочетании с технологией доставки приложений через подключаемые виртуальные диски VMware App Volumes 3.0 и средством управления окружениями User Environment Manager, эти возможности позволяют пользователям получить мгновенный доступ к своим данным, при этом рабочая машина пользователя не "загрязняется" ненужными устанавливаемыми программами и распухающими ветками реестра. Это все позволяет собрать десктоп пользователя на лету из полностью кастомизируемых и доставляемых по требованию "кирпичиков".

Десктоп пользователя =
[мгновенный клон родительской ВМ] +
[корпоративные приложения на подключаемых дисках App Volumes] +
[кастомизация Environment Manager] +
[данные пользователя] +
[установленные пользователем приложения]

Давайте посмотрим, насколько Instant Clone упрощает цикл развертывания новых настольных ПК. Вот так выглядит развертывание связанных клонов (Linked Clones) в инфраструктуре VMware View Composer:

  • Клонирование виртуального ПК из реплики мастер-образа
  • Реконфигурация нового ПК
  • Включение ВМ
  • Кастомизация машины
  • Создание контрольной точки нового ПК (checkpoint)
  • Включение ВМ
  • Логин пользователя

С использованием Instant Clone процесс заметно упрощается:

  • Создание копии ВМ в памяти средствами VMFork
  • Кастомизация машины
  • Включение ВМ
  • Логин пользователя

Для администратора виртуальных ПК в пулах Instant Clone удобны тем, что таким десктопам не требуются операции Refresh, Recompose и Rebalance. Ведь после выхода пользователя из ПК его десктоп уничтожается, а перестраивать связанные клоны не требуется. Изменения базового образа проходят "на лету" в течение рабочего дня, а при следующем логине пользователь получает уже обновленные приложения. Также есть возможность принудительного перелогина пользователя для обновления компонентов виртуального ПК (например, фикс в подсистеме безопасности).

Также отпадает необходимость в использовании технологии Content-Based Read Cache (CBRC), ведь виртуальные ПК Instant Clone живут недолго, постоянно выгружаются из памяти при выходе пользователя, и нет нужды прогревать кэш их блоками в памяти, а вот для мастер-ВМ и реплик CBRC вполне себе используется.

Кроме того, теперь не нужны операции wipe и shrink для виртуальных дисков SEsparse, которые позволяют возвращать место на растущем диске для связанных клонов. Виртуальные машины Instant Clone живут недолго, а при их уничтожении дисковое пространство их дельта-дисков возвращается в общий пул пространства хранения.

Ну и в отличие от View Composer, технология Instant Clone не требует наличия и поддержки базы данных для операций с виртуальными ПК, что существенно упрощает обслуживание инфраструктуры виртуальных десктопов.

Многие думают, что пулы Instant Clone трудно создавать, настраивать и поддерживать. Это не так, все делается в несколько простых шагов:

  • Создаем родительскую виртуальную машину, устанавливаем в ней Windows, оптимизируем ее и активируем лицензионным ключом.
  • Устанавливаем VMware Tools.
  • Устанавливаем Horizon Agent и отмечаем фичу Instant Clone для установки.
  • При добавлении нового пула виртуальных ПК типа Automated/Floating отмечаем Instant Linked Clones.

Помимо того, что с Instant Clone процесс проходит меньшее количество шагов, уменьшается и нагрузка на различные компоненты виртуальной инфраструктуры - меньше операций ввода-вывода, быстрее происходит процесс создания мгновенной копии (скорее освобождаются системные ресурсы), меньше объем взаимодействий с сервером vCenter, а дисковое пространство высвобождается сразу после окончания использования виртуального ПК.

Давайте посмотрим, насколько быстрее это работает на тестах. Развертывание связанных клонов View Composer типовой конфигурации (2 vCPU, 2 GB memory, Windows 7, Office 2010, Adobe 11, 7-Zip, Java) на 15 хост-серверах с использованием HDD-дисков занимает где-то 150-200 минут. А то же самое развертывание 1000 виртуальных машин на базе Instant Clone занимает лишь 25-30 минут. То есть скорость получения новой инфраструктуры десктопов по запросу возрастает в 5-7 раз.

При этом не особо-то и растет нагрузка на сервер VMware vCenter. Поначалу, конечно же, возникает пиковая нагрузка на vCenter при операциях в оперативной памяти с мгновенными копиями ВМ, но в итоге средняя загрузка практически такая же, как и при использовании View Composer - ведь не нужно проходить цикл включения (2 раза) и реконфигурации виртуальной машины (3-4 раза), как это происходит у Composer.

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


Таги: VMware, Horizon, Instant Clones, VMFork, VMachines, Performance

Как теперь работает технология дедупликации страниц памяти Transparent Page Sharing в vSphere 6.0.


Какое-то время назад мы писали о том, что технология дедупликации страниц памяти Transparent Page Sharing (TPS) с приходом больших страниц памяти становится ненужной (а в последних версиях vSphere и вовсе она отключена). Но это не значит, что сейчас TPS нигде не используется совсем - ведь большие страницы, при условии недостатка ресурсов памяти на хост-сервере, гипервизор ESXi может разламывать на маленькие, после чего дедуплицировать их.

Между тем, в последних релизах VMware vSphere, включая ESXi 6.0, появилась более гранулярная модель управления механизмом TPS, который можно задействовать для отдельных групп виртуальных машин (например, серверы обрабатывающие одни и те же данные, где вероятность дубликатов страниц высока). Называется этот механизм Salting (хэширование с солью).

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

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

При любой попытке записи в такую страницу со стороны виртуальной машины - мгновенно создается ее физическая копия с помощью механизма copy-on-write (CoW), и она уже перестает быть шаренной (каждая машина начинает использовать свою копию).

Так вот в последних версиях VMware vSphere механизм TPS работает не так просто. По умолчанию используется Salting, а в качестве этой самой соли используется UDID виртуальной машины, который всегда уникален для данного сервера vCenter. То есть перед снятием хэша со страницы памяти происходит добавление соли к исходным данным, а поскольку соль одинакова только для конкретной ВМ, то и дедупликация страниц со стороны TPS происходит только на уровне отдельной виртуальной машины (Intra-VM TPS).

Механизм Salting используется по умолчанию, начиная со следующих версий гипервизоров:

  • ESXi 5.0 Patch ESXi500-201502001
  • ESXi 5.1 Update 3
  • ESXi 5.5, Patch ESXi550-201501001
  • ESXi 6.0

Управлять этим механизмом можно из расширенных настроек хоста VMware ESXi (Advanced Settings, раздел Mem). По умолчанию используется расширенная настройка Mem.ShareForceSalting в значении 2. Это означает, что salting включен и работает Intra-VM TPS.

Если же мы поставим эту настройку в значение 0, как на рисунке выше, то соль перестанет добавляться к хэшу при работе алгоритма TPS, а значит он будет работать для всех виртуальных машин на хосте (Inter-VM TPS).

Ну и, как становится понятным, TPS можно включить для отдельной группы виртуальных машин на хосте ESXi, для чего нужно использовать одинаковую соль для этих виртуальных машин. Для этого в расширенных настройках виртуальной машины нужно добавить параметр sched.mem.pshare.salt с одинаковым значением у всех нужных вам ВМ (это также можно сделать и в vmx-файле).

В этом случае значением настройки Mem.ShareForceSalting должно быть 1 или 2 (разницы тут особой нет, кроме того, что если у вас используется значение 1, то при отсутствии соли включится Inter-VM sharing).

Ну и в таблице ниже приведем различия в работе алгоритма TPS для различных значений Mem.ShareForceSalting и в зависимости от заполненности sched.mem.pshare.salt для виртуальных машин.

Значение Mem. ShareForceSalting (настройка уровня хоста)

Значение sched.mem.pshare.salt (настройка уровня ВМ)

vc.uuid (свойство ВМ)

Значение соли в настройках ВМ

TPS между виртуальными машинами (Inter-VM)

TPS внутри каждой из ВМ (Intra-VM)

0

Игнорируется

Игнорируется

0

Да, между всеми машинами на хосте

Да

1

Установлено

Игнорируется

Используется sched.mem.pshare.salt

Только между ВМ с одинаковой солью

Да

1

Не установлено

Игнорируется

0

Да, между всеми машинами на хосте

Да

2

Установлено

Игнорируется

sched.mem.pshare.salt

Только между ВМ с одинаковой солью

Да


(по умолчанию)

Не установлено (по умолчанию)

Используется

Используется vc.uuid

No inter-VM TPS

Да

2

Не установлено

Отсутствует по какой-либо причине

Используется случайный номер для каждой ВМ

No inter-VM TPS

Да

Для более детальной информации вы можете обратиться к статье KB 2097593.


Таги: VMware, vSphere, Memory, Обучение, TPS, Performance, ESXi, VMachines

Новый документ VMware Virtual SAN 6.2 Network Design Guide с практическими рекомендациями по конфигурации сетевого окружения.


Компания VMware выпустила весьма полезный документ "VMware Virtual SAN 6.2 Network Design Guide", в котором приведены конкретные рекомендации по настройке и конфигурации сети при организации отказоустойчивых кластеров хранилищ.

Посмотрим, какие интересные моменты есть в документе. Например, рассматривается следующая архитектура построения кластера Virtual SAN (это Leaf-Spine архитектура):

В такой сети показатель переподписки (oversubscription) между стойками равен 4:1 (от хостов идет 16 линков по 10 Гбит к свичу, от которого идет 4 линка по 10 Гбит к Spine-коммутатору). В этом случае, если предположить, что на хостах 10 ТБ емкости, из которых 6 ТБ занимают данные виртуальных машин, и вдруг возникнет необходимость операции rebuild для кластера (при FTT=1), то при использовании 3/4 пропускной способности канала (то есть 30 Гбит/с) операция займет 26 минут. Если же объем данных на хосте увеличить до 12 ТБ, а канал уменьшить до 10 Гбит/с, то rebuild займет 156 минут. Мораль такова - нельзя перебарщивать с переподпиской, а также нужно обеспечить широкий канал между узлами кластера.

Еще из рекомендаций в документе:

  • Отключите Flow Control на физическом оборудовании, у Virtual SAN есть свой механизм контроля перегрузки канала.
  • Используйте vSphere Distributed Switch (VDS) совместно с Virtual SAN.
  • Настройте Load Based Teaming (LBT), который балансирует нагрузку, в зависимости от загрузки физического адаптера (похоже на Virtual Port ID, только привязка к порту пересматривается каждые 30 секунд).
  • Если используете несколько кластеров Virtual SAN - помещайте трафик каждого из них в отдельный VLAN.
  • Если в датацентре используются большие кадры jumbo frames - используйте их в кластере Virtual SAN, но если не используются - то отдельно включать их не надо.
  • Включите Cisco Discovery Protocol (CDP) и Link Layer Discovery Protocol (LLDP) в режимах и приема, и передачи.

В документе присутствует еще несколько интересных рекомендаций, прочитать которые будет особенно интересно администраторам крупных инфраструктур и больших кластеров Virtual SAN.


Таги: VMware, Virtual SAN, Whitepaper, Performance, Обучение, VSAN, Networking

Сравнение протоколов VMware Horizon 7: PCoIP и Blast Extreme.


Очень интересное сравнение протоколов доступа к виртуальным ПК и приложениям в инфраструктуре VMware Horizon 7 появилось на одном из блогов, посвященных технологиям виртуализации. Коллега сравнивал производительность проверенного временем PCoIP и пришедшего ему на смену протокола Blast Extreme в следующей тестовой конфигурации:

Автор обращает внимание на то, что PCoIP работает по UDP, поэтому похож на гоночную машину (лучше всего себя ведет на широкой полосе канала без помех и высокой нагрузки), а Blast Extreme, работающий по TCP - это джип, который хорошо едет по пересеченной местности (то есть, адаптируется к параметрам канала).

Тестирование проводилось по следующей схеме:

  • Пользователь логинится и ждет 1 минуту, чтобы сессия настроилась и была готова к тестированию.
  • Открыли локальный PDF-файл, скроллили его вверх и вниз 1 минуту.
  • Зашли на новостной сайт с графикой http://www.vg.no и поскроллили его.
  • Открыли Word и печатали там лабуду в течение 1 минуту.
  • Открыли трейлер фильма Captain America Civil War в полный экран браузера Chrome на полную длительность (2 минуты).

Для сбора данных и настройки окружения использовались следующие средства:

  • Splunk – Uberagent (сбор данных).
  • Netbalancer (bandwidth, возможность установки параметра packet loss, определение лимитов по bandwidth limits и задание latency).

Первый тест (5 MS latency, no packet loss) для Blast Extreme

Параметры использования канала: 248 MB total, Maximum usage 1,6 MBPS

Использование CPU: (Splunk, UberAgent) VMBlastW.exe (около 8.2%):

Среднее использование памяти:

Максимальное использование памяти:

Первый тест (5 MS latency, no packet loss) для PCoIP

Тут надо отметить, что PCoIP буферизует и собирает пакеты по 1198 байт перед отправкой:

Параметры использования канала: 184 MB, Maximum usage 999 KBPS

Использование CPU: (Splunk, UberAgent, около 24.2%):

Среднее использование памяти:

Максимальное использование памяти:

Автор делает вывод, что PCoIP дает намного большую нагрузку на клиентское устройство, чем Blast Extreme, который, в свою очередь, дает лучший User Experience, но потребляет большую ширину канала. Это может быть связано с дополнительными накладными расходами на квитанции TCP, а также тем, что Blast Extreme тестирует канал при начале передачи и пытается выжать из него максимум.

Работа Blast Extreme на latency 200 миллисекунд

Использование канала 43 MB, Maximum bandwidth 201 KBPS:

Здесь latency оказывает весьма негативный эффект на Blast за счет протокола TCP. Также на картинке выше видно, что неэффективно маленькие пакеты используются даже когда буфер пуст или пости пуст.

При просмотре ролика на Youtube Blast все же максимизирует размер пакета:

Максимальное использование памяти:

Работа PCoIP на latency 200 миллисекунд

Использование канала 118 MB, Maximum bandwidth 689 KBPS:

Нагрузка на CPU (обратите внимание, что меньше, чем без latency):

Использование памяти:

Вывод: Blast умеет использовать широкий канал и дает лучший user experience + создает меньшую нагрузку на клиентское устройство.


Таги: VMware, Horizon, Comparison, PCoIP, Blast, Performance, Network, VDI

Бесплатный вебинар: Производительность All-Flash конфигураций на дисках Intel SSD средствами решения StarWind HyperConverged Appliance.


Интересный вебинар проведет компания StarWind о производительности конфигураций серверов All-Flash на платформе решения для обеспечения отказоустойчивости хранилищ StarWind Virtual SAN: Get All-Flash Performance using Intel SSD and StarWind HyperConverged Appliance.

Вебинар пройдет 5 апреля в 20-00 по московскому времени.

Напомним, что у StarWind есть собственное решение для создания гиперконвергентной инфраструктуры на базе серверов Dell, гипервизора Microsoft Hyper-V, ПО для хранилищ StarWind Virtual SAN, резервного копирования Veeam Backup and Replication, а также средств управления 5nine Hyper-V Manager. Поставляется оно в виде готового к использованию программно-аппаратного комплекса.

Бонусом мероприятия является комплект для сборки минималистичного компа CanaKit Raspberry Pi 3 Ultimate Starter Kit - 32 GB Edition. Его получат два участника вебинара. Может быть, повезет именно вам - регистрируйтесь!


Таги: StarWind, Webinar, Hardware, Performance

Наконец-то: вышло превью VMware vSphere HTML5 Web Client.


На протяжении нескольких лет от системных администраторов VMware vSphere постоянно поступают жалобы на низкое быстродействие и глючность тонкого клиента управления платформой - vSphere Web Client. Это неудивительно - ведь веб-клиент vSphere построен на базе фреймворка Adobe Flex (пруф), который вобрал в себя все самые "лучшие" стороны флеш-технологии.

Так вот, время флеша похоже истекает - на сайте проекта VMware Labs появилось превью нового клиента vSphere HTML5 Web Client, построенного на базе новых стандартов HTML 5 и Javascript. Напомним, что флеш плох всего лишь в трех аспектах - производительность, стабильность и безопасность, ну а новый клиент призван все это улучшить.

Клиент vSphere HTML5 Web Client пока поддерживается только для VMware vSphere 6 и более поздних версий. Скажем тут на всякий случай, что этот клиент предназначен для управления виртуальной инфраструктурой только через сервисы VMware vCenter. Если вам нужно управлять отдельным хостом, то используйте ESXi Embedded Host Client, который теперь уже поставляется с vSphere 6.0 Update 2 и более поздними версиями платформы виртуализации.

На данный момент технологическое превью умеет делать следующие вещи:

  • Операции с питанием виртуальных машин (вкл/выкл/приостановка).
  • Изменение настроек ВМ (CPU, память, виртуальные диски).
  • Доступ к консоли виртуальных машин.
  • Страницы информации для хостов и ВМ.
  • Горячая миграция машин между хостами ESXi (без перемещения хранилищ).
  • Клонирование машин и создание шаблонов из ВМ.
  • Создание новой виртуальной машины (пока возможности ограничены).
  • Различные графики производительности для мониторинга и отслеживания событий (Performance charts, Tasks, Events).
  • Представления Global Views (последние задачи, алармы и т.п.).

К сожалению, пока в этом клиенте нет функций vSphere Update Manager (напомним, что и в обычном-то vSphere Web Client они появились спустя оочень долгое время).

Скачать VMware vSphere HTML5 Web Client можно в виде готового к развертыванию виртуального модуля OVA по этой ссылке. Для развертывания тонкого клиента понадобится поколдовать с командной строкой (инструкции доступны здесь), ну а в следующих версиях обещают полноценный GUI.


Таги: VMware, vSphere, Labs, Update, Web Client, Performance

Производительность протокола VMware Horizon Blast Extreme совместно с виртуальными десктопами на базе NVIDIA GRID.


Интересный пост вышел на одном из блогов компании VMware о производительности протокола VMware Horizon Blast Extreme, который используется совместно с технологией построения инфраструктуры производительных виртуальных десктопов NVIDIA GRID.

Не так давно мы писали о новых возможностях VMware Horizon 7, одной из которых стало полноценное включение протокола Blast Extreme на основе видеокодека H.264 в стек используемых протоколов наряду с PCoIP и RDP. Совместно с решением NVIDIA GRID производительность протокола Blast Extreme значительно возрастает, давайте посмотрим насколько.

В тесте команды NVIDIA GRID Performance Engineering Team использовался симулятор рабочей нагрузки ESRI ArcGIS Pro 1.1, который воспроизводил типичные действия пользователей а в качестве основных метрик снимались задержки (latency), фреймрейт (FPS), требуемая полоса пропускания (bandwidth) и прочие. При этом проводилось сравнение Blast Extreme (в программном варианте и при аппаратном ускорении GRID) с протоколом PCoIP, который широко используется в настоящий момент.

Благодаря ускорению обработки кодирования/декодирования на аппаратном уровне, уменьшаются задержки при выполнении операций (за счет ускорения обработки на стороне сервера):

 

Blast Extreme уменьшает задержку аж на 51 миллисекунду по сравнению с традиционным PCoIP.

По результатам теста для FPS производительность Blast Extreme превосходит PCoIP на целых 37%:

Для 19 виртуальных машин на одном сервере в тесте ESRI ArcGIS Pro 1.1 необходимая полоса пропускания для Blast Extreme была ниже на 19%, чем для PCoIP (и это без потерь качества картинки):

Благодаря кодеку H.264, который передает нагрузку на сторону выделенных аппаратных движков NVIDIA GPU, снижается нагрузка на центральный процессор хост-сервера VMware ESXi на 16%:

При этом удалось добиться увеличения числа пользователей на сервере ESXi на 18%, а это 3 человека на сервер.

Понятно, что тест ESRI ArcGIS Pro 1.1 не является универсальной нагрузкой, но в целом можно сказать, что Blast Extreme при аппаратном ускорении повышает производительность процентов на 15.


Таги: VMware, Blast, Performance, PCoIP, VDI, Horizon, NVIDIA, GRID

Сценарии, когда нужно отключить Site / Data Locality для растянутого кластера VMware Virtual SAN.


Какое-то время назад мы писали о функции Data Locality, которая есть в решении для создания отказоустойчивых кластеров VMware Virtual SAN. Каждый раз, когда виртуальная машина читает данные с хранилища, они сохраняются в кэше (Read Cache) на SSD-накопителе, и эти данные могут быть востребованы очень быстро. Но в рамках растянутого кластера (vSphere Stretched Cluster) с высокой скоростью доступа к данным по сети передачи данных, возможно, фича Site / Data Locality вам не понадобится. Вот по какой причине.

Если ваши виртуальные машины часто переезжают с хоста на хост ESXi, при этом сами хосты географически разнесены в рамках VSAN Fault Domains, например, по одному зданию географически, то срабатывает функция Site Locality, которая требует, чтобы кэш на чтение располагался на том же узле/сайте, что и сами дисковые объекты машины. Это отнимает время на прогрев кэша хоста ESXi на новом месте для машины, а вот в скорости в итоге особой прибавки не дает, особенно, если у вас высокоскоростное соединение для всех серверов в рамках здания.

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

[root@esxi-01:~] esxcfg-advcfg -g /VSAN/DOMOwnerForceWarmCache

Value of DOMOwnerForceWarmCache is 0

Устанавливаем значение в 1, если хотим отключить принудительный прогрев кэша при смене площадки размещения машины:

[root@esxi-01:~] esxcfg-advcfg -s 1 /VSAN/DOMOwnerForceWarmCache

Value of DOMOwnerForceWarmCache is 1

Таги: VMware, Virtual SAN, DR, Stretched, HA, Performance

1 | 2 | 3 | 4 | 5 | 6 | 7    >   >>
Реклама

Advertisement

Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

22/09/2017:  Red Hat Forum Russia 2017
26/10/2017:  VeeamON Forum Russia 2017
09/11/2017:  CNews FORUM 2017

Быстрый переход:
Veeam VMware IT-Grad StarWind Microsoft Parallels IaaS Citrix 5nine HP VeeamON VMFS RVTools PowerCLI VM Guru Oracle Red Hat Azure KVM vGate VeeamOn Security Code 1cloud Cloud Docker Storage Offtopic NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo Nutanix vRealize VirtualBox Symantec Gartner Softline EMC Login VSI Xen Enterprise Teradici Amazon NetApp VDI Linux Hyper-V IBM Cisco Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Hardware Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell vSphere IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V vSAN Client DRS VMworld OpenStack Comparison Fusion Workstation Blast Backup Horizon SRM App Volumes Performance Manager Labs Nested vCloud AWS Log Insight XenDesktop VSA vNetwork SSO LSFS Workspace Host Client VMDK vROPs VTL Update iSCSI SDDC vCSA NSX Agent Virtual Appliance Whitepaper PowerShell Appliance VUM VVols V2V Tools Cache Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance DR Photon Vanguard SaaS Connector HA Event Free Datacenter SQL VSAN Lifecycle Sponsorship Finance FT Cloud Computing Converter XenApp esxtop Snapshots VCP Auto Deploy SMB RDM Mirage XenClient MP Video Operations SC VMM Certification SSD VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo Visio Intel vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Networking Monitoring VPLEX UCS SDK Poster VSPP SDRS Receiver vMotion VDI-in-a-Box Deduplication Forum Reporter vShield ACE Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Troubleshooting Air API CLI Plugin DPM Director Book Memory Upgrade SIOC Flex Mac Bug Open Source SSH VAAI Chargeback Heartbeat Android MSCS Ports SVMotion Storage DRS Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Сравнение Oracle VirtualBox и VMware Workstation.

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Как использовать возможности VMware vSphere Management Assistant (vMA).

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2017, Александр Самойленко. Правила перепечатки материалов.