Компания VMware на днях выпустила новый документ, раскрывающий основные моменты улучшения производительности VMware vSphere 6.7 по сравнению с прошлой версией - What’s New in Performance - VMware vSphere 6.7.

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

• Увеличение в 2 раза числа операций vCenter в секунду по сравнению с vCenter 6.5.
• vCenter использует в 3 раза меньше памяти для основного процесса vpxd.
• Уменьшение времени на операции, связанных с DRS, до 3 раз (например, запуск виртуальной машины).
• Улучшение производительности Virtualization Based Security.

Здесь повышение производительности в числе транзакций в минуту составило 33% по сравнению с работой VBS в vSphere 6.5:

• Поддержка больших страниц памяти (Large Memory Pages) размером 1 ГБ.

Хост ESXi с размером страницы в 1 ГБ (появилось в vSphere 6.7) работает на 26% лучше, чем хост со страницей в 2 МБ:

• Улучшения драйвера vmxnet3 версии 4 в плане механизмов RSS (улучшение 28-146% в числе полученных пакетов в секунду) и VXLAN/Geneve Offload (до 415% улучшение в пропускной способности канала при некоторых условиях).
• Поддержка новых сервисов Persistent Memory.

С помощью технологии vSphere Persistent Memory пользователи могут применять специальные аппаратные модули от Dell-EMC и HPE (DRAM NVDIMM), которые могут использовать высокопроизводительные системы хранения с большим числом IOPS или предоставлять их возможности гостевым системам как non-volatile memory.

Работает это быстрее, чем SSD (vPMEMDisk - это работа такой памяти как локальное хранилище хоста ESXi, а vPMEM - прямое предоставление хранилища гостевой системе как устройства):

• Скорость создания мгновенных клонов (Instant Clones) виртуальных машин по сравнению со скоростью создания связанных клонов.

Мгновенные клоны создаются почти в три раза быстрее, чем связанные (время в секундах на создание 64 клонов):

Все остальное - в документе "What’s New in Performance - VMware vSphere 6.7".

Как знают пользователи решения для создания отказоустойчивых кластеров VMware vSAN, этот продукт имеет множество средств для обработки ситуаций отказа физических устройств - дисков HDD и SSD. В vSAN есть специальный механизм Degraded Device Handling (DDH), который приводит кластер в жизнеспособное сосотояние при отказе одного диска или всей дисковой группы. При этом отказом устройства считается не только его полная физическая поломка, но и резкое снижение производительности, что ведет к ухудшению качества обслуживания пользователей.

Давайте посмотрим, как это работает:

1. Механизм DDH в VMware vSAN 6.1.

vSAN 6.1 ищет устройства, на которых операции ввода-вывода вызывают задержки более 50 мс. Если такое поведение на устройстве сохраняется в течение 10 минут, то vSAN отключает это устройство и вызывает аларм. Если таким устройством является кэш-диск, то в офлайн выводится вся дисковая группа (к счастью, современные SSD-диски весьма надежны).

Вот что будет в этом случае в логах:

2015-09-15T02:21:27.270Z cpu8:89341)VSAN Device Monitor: WARNING – READ Average Latency on VSAN device naa.6842b2b006600b001a6b7e5a0582e09a has exceeded threshold value 50 ms 1 times.

2015-09-15T02:21:27.570Z cpu5:89352)VSAN Device Monitor: Unmounting VSAN diskgroup naa.6842b2b006600b001a6b7e5a0582e09a

Компоненты на такой дисковой группе механизм DDH помечает как "Absent". Ребилд для таких компонентов начнется через 60 минут после отказа устройства, когда истечет rebuild timer. Если этот компонент не является частью группы RAID-1 или RAID-5/6, то он становится недоступным.

В случае с RAID-1 все продолжает работать, и если компонент witness работает, то вы получите только оповещение в vSphere Client:

Однако по некоторым причинам выдача больших latency для операций ввода-вывода на диске в течение более чем 10 минут может быть обусловлена некоторыми рабочими моментами, а начинать rebuild дисковой группы в этом случае нежелательно. Поэтому в vSAN 6.2 появились следующие улучшения DDH.

2. Улучшения DDH в vSAN 6.2.

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

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

2. По умолчанию DDH не размонтирует кэш-девайсы и в случае превышения latency на запись. Поскольку это ведет к выводу в офлайн всей дисковой группы, было сделано решение, что такое поведение несет больше вреда, чем медленная работа кэш-устройства. Но это дефолтное поведение можно изменить следующей командой (затрагивает не только кэш, но и диски с данными):

esxcfg-advcfg –set 1 /LSOM/lsomSlowTier1DeviceUnmount

После ее выполнения кэш-устройства и их дисковые группы будут размонтироваться при привышении порога latency на запись.

3. DDH мониторит устройства в рамках случайных 10-минутных интервалов и учитывает несколько таких интервалов. Это предотвращает ложные срабатывания механизма в случае таких операций, как vSAN component recovery, ремапинг секторов HDD-дисков, сбор мусора на SSD и прочее. Теперь для срабатывания DDH нужно 4 превышения latency в непоследовательных 10-минутных интервалах, которые случайно распределены в окне 6-7 часов.

4. DDH пытается снова смонтировать устройства vSAN, которые были ранее размонтированы по превышению latency. Число таких попыток - 24 в окне 24 часа (то есть примерно раз в час). Если условие размонтирования сохраняется, то попытки обратного монтирования прекратятся через сутки.

3. Улучшения DDH в vSAN 6.6 и более поздних версиях.

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

Для HDD дисков был сделан threshold 500 миллисекунд на запись, для SSD - 50 миллисекунд на чтение и 200 миллисекунд на запись.

Теперь, если вышедший из строя диск является последней копией данных, но с него еще как-то можно получить данные, то vSAN не пометит диск как Absent, но начнет эвакуацию данных, таймер vSAN CLOM Rebuild Timer не включится.

В этом процессе есть 4 стадии:

1. Preventative evacuation in progress - желтый аларм сработает, чтобы дать администратору знать о проблеме. vSAN сам превентивно эвакуирует данные, без необходимых действий со стороны администратора.

2. Preventative evacuation is incomplete due to lack of resources - превентивная эвакуация данных не удалась вследствие недостатка ресурсов. В этом случае будет показан красный аларм. Администратору нужно будет высвободить дисковое пространство, например, удалить ВМ или добавить больше дисков, чтобы завершить эвакуацию данных. Разработчики vSAN рекомендуют на такие случаи держать 25-30% кластера свободными.

3. Preventative evacuation is incomplete due to inaccessible objects - это самая плохая ситуация, говорящая о том, что дисковые объекты degraded-устройства недоступны. Если добавление новых ресурсов не помогает, то остается только удалить этот диск из конфигурации vSAN, выбрав опцию "no data migration".

4. Evacuation complete - эвакуация данных завершена, и диск можно безопасно удалить из конфигурации vSAN (не забудьте заменить его рабочим диском).

Еще в далеком 2011 году мы писали о средстве VMware I/O Analyzer, которое позволяет сгенерировать нагрузку на хранилища VMware vSphere, а после чего замерить производительность этих хранилищ. Делается это средствами интегрированного фреймворка, который поддерживает распределенную архитектуру - центральный управляющий виртуальный модуль и воркеры (генераторы нагрузки).

В 2014 году это средство еще раз обновилось для поддержки актуальных на тот момент версий ESXi, ну а на днях появилось обновление VMware I/O Analyzer 1.6.2u1, которое поддерживает VMware vSphere 6.5 и более поздние версии, то есть vSphere 6.7.

Напомним основные возможности VMware I/O Analyzer:

• Интегрированный фрейворк для тестирования производительности хранилищ.
• Простая настройка и возможность исполнения тестов на одном или нескольких хостах ESX/ESXi.
• Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС.
• Возможность экспорта данных для последующего анализа.
• Средства "повторения" нагрузки на хранилища путем ее воспроизведения из трейса ввода-вывода.
• Возможность загрузки трейсов ввода-вывода для автоматического извлечения необходимых метрик.
• Графическая визуализация метрик и результатов анализа производительности.

В новой версии I/O Analyzer 1.6.2u1 появились следующие фичи:

• Поддержка последних версий vSphere.
• Обновление протокола до версии OpenSSL 1.0.2o.
• Сценарий для горячего обновления с прошлой версии 1.6.2.
• В прошлой версии 1.6.2 были пофикшены уязвимости Shellshock и Heartbleed.

Скачать VMware I/O Analyzer 1.6.2u1 можно по этой ссылке. Инструкция к данному средству тестирования доступна тут.

Компания VMware сделала доступным интересный документ VMware vSAN PoC Performance Checklist, в котором рассматриваются различные аспекты производительности кластеров хранилищ VMware vSAN, которые пользователи развертывают в рамках PoC (proof of concept).

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

• VMware vSAN Design and Sizing Guide
• VMware vSAN Network Design Guide
• vSphere 6.5 Performance Best Practices Guide
• VMware vSAN Proof of Concept Guide

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

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

• "Before you Start" Tasks
• Host Based Tasks after vSAN is Deployed
• Choosing An Appropriate Policy to Test
• Choosing Data Services
• Prepping for the HCIBench Benchmark
• Initial Functional Test -HCIBench Easy Run
• HCI Bench - Further Tuning

Надо сказать, что эти проверки могут оказаться полезными всем тем, кто испытывает проблемы с производительностью vSAN и поиском их причин. Также в онлайн-документе VMware vSAN PoC Performance Checklist есть возможность скачать его в формате PDF. Ну и если ничего не помогло, то всегда есть почта для обращений - vsanperformance@vmware.com.

Мы часто пишем о продукте StarWind Virtual SAN, который позволяет организовать кластеры отказоустойчивых хранилищ на базе серверов для виртуальных машин VMware vSphere и Microsoft Hyper-V. В связи с большим интересом к тому, как именно работает это решение с технической точки зрения, постараемся писать об этом побольше. Сегодня мы расскажем об опциональной файловой системе LSFS (Log-Structured File System), которая повышает производительность операций записи и срок службы накопителей.

Недавно мы писали о полезном документе для администраторов VMware vSphere 6.5 - Performance Best Practices for VMware vSphere 6.5. Этот документ обязательно надо прочитать, там много всего полезного и интересного.

Например, там есть немного про улучшение команды esxtop, показывающей производительность хоста и виртуальных машин в различных аспектах. Теперь там добавилась метрика Power Management, где можно в реальном времени наблюдать за актуальной частотой процессора. Эта информация теперь отображается в колонке %A/MPERF.

Чтобы добавить ее, после запуска esxtop нажмите клавишу <p> и затем клавишу <f> для добавления колонки.

Вы увидите значения, некоторые из которых больше 100. Например, для процессора 2 и 4 на картинке выше значения равны 150. При этом это процессор Xeon E5-2699 v3 2.3 ГГц с функцией разгона частоты Turbo Boost до 3.6 ГГц. Значение 150 означает, что в данный момент процессор работает на частоте 2.3*1.5 = 3.45 ГГц, то есть почти на пределе.

Блогер David Pasek опубликовал интересный пост, касающийся ограничения виртуальных машин и их виртуальных дисков по числу операций ввода-вывода. Смысл его в том, что автор, являющийся ярым сторонником обеспечения QoS на уровне виртуальных дисков, настоятельно рекомендует применять ограничения IOPS limit к виртуальным дискам машин, которые потенциально могут выесть много полосы ввода-вывода.

Сейчас ограничивать виртуальные машины по IOPS можно как на уровне виртуальных дисков на томах VMFS/RDM/NFS, так и на уровне томов VVols. Многие системы хранения оперирует понятием логического тома LUN, на котором размещается один том VMFS. Как правило, LUN - это логический том, что значит, что несколько LUN могут размещаться на одной физической группе дисков:

Таким образом, виртуальные машины, потребляющие много IOPS от хранилища (он называет их "noisy neighbor") могут существенно замедлить работу других производственных систем.

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

Например, в vSphere Web Client создаем новую VM Storage Policy с ограничениями IOPS limit for object:

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

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

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

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

• Команды ввода-вывода (IO) нормализуются к блоку 32 КБ, то есть команда в 128 КБ будет преобразована в 4 IO.
• IOPS limit не влияет на операции SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.
• IOPS limit применяется только ко вводу-выводу гостевой ОС и не затрагивает операции с самим диском VMDK и его swap-файлами.
• Если у машины несколько лимитов по IOPS для дисков на одном датасторе, то эти лимиты складывают и применяются для всей ВМ на этом датасторе в целом. Если же диски находятся на разных хранилищах, то тут уже действуют правила для каждого из групп дисков.
  • Например, если у каждой из 4 дисков машины на одном датасторе стоит лимит 100 IOPS, то для всей машины будет совокупный лимит 400. То есть, если три VMDK едят по 10 IOPS каждый, то четвертый диск сможет съесть максимум 370 IOPS.
  • А вот для NFS-хранилищ все работает несколько иначе - если у каждого из 4 дисков на одном датасторе стоит лимит 100 IOPS, то сколько бы ни потребляли остальные диски, для каждого из дисков будет применен максимальный лимит 100.
• Полная информация об ограничении ввода-вывода для виртуальных машин приведена в KB 1038241.

Также рекомендуем почитать нашу статью "VMware Storage I/O Control (SIOC) - как это работает на практическом примере".

Почти все из вас в курсе, что недавно в процессорах Intel были найдены уязвимости Meltdown и Spectre. Недавно мы писали о том, то компания VMware выпустила патчи для хост-серверов VMware ESXi, а также для управляющего сервера vCenter. Вильям Лам даже написал скрипт PowerCLI для проверки накаченных обновлений на хосты и виртуальные машины.

Но...18 января VMware, получив некую "важную информацию" от Intel, отозвала выпущенные патчи и опубликовала специальную KB 117649, в которой описала сложившуюся ситуацию, не особенно ее проясняя. Пока мы ждем патчей от VMware и Intel, можно взглянуть на некоторые результаты тестов производительности (раз и два), где показано, как исправления микрокода серверов от описанных уязвимостей негативно влияют на производительность:

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

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

Единственное ее ограничение - бесплатная версия прекратит работать 31 марта этого года. С помощью Login VSI вы можете протестировать производительность таких платформ, как Citrix XenApp, XenDesktop, Microsoft RDS и, конечно же, VMware Horizon View. 

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

Запросить бесплатную лицензию на Login VSI можно здесь.

Многие из вас знают, что одной из новых возможностей решения для организации отказоустойчивых кластеров хранения VMware vSAN стали проактивные тесты, которые доступны через VMware vSphere Web Client. Раньше их было три штуки:

Но недавно некоторые из вас, возможно, заметили, что в новой версии VMware vSAN (которая доступна с VMware vSphere 6.5 Update 1 Patch 02) остался только одиноко болтающийся тест на создание виртуальной машины:

Дункан Эппинг пишет, что это обусловлено двумя факторами:

• Тест Multicast performance ушел, так как мультикаст-режим был убран из VMware vSAN (еще в версии vSAN 6.6), соответственно, ушел и тест на его производительность. Теперь когда вы используете vSAN в режиме юникаст, то тест показан не будет, но если будете использовать все же мультикаст - тест появится.
• А вот тест Storage Performance ушел вот почему: у VMware есть методика тестирования HCI Bench, которая позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ vSAN, а также других конфигураций виртуальной инфраструктуры. Это очень гибкий инструмент, который позволяет проводить наиболее точное тестирование и настраивать различные аспекты методики и среды тестирования. Соответственно, VMware решила поддерживать только один инструмент, а Storage Performance Test убрать из клиента для управления виртуальной инфраструктурой.

Мы часто пишем о встроенной утилите на хосте ESXi - esxtop, которая позволяет отслеживать все основные аспекты производительности хост-серверов и виртуальных машин (процессор, память, диски и сеть). Напомним, что наши последние посты о esxtop расположены тут, тут, тут, тут, тут и тут.

А недавно вышло весьма полезное образовательное видео "Using esxtop to Troubleshoot Performance Problems", в котором показано на практическом примере, как именно использовать esxtop для решения проблем производительности (хотя голос и весьма уныл):

Ну и напомним, что у esxtop есть графический интерфейс - это утилита VisualEsxtop.

Оказывается, у VMware есть интересная утилита с открытым исходным кодом - Weathervane. Это бенчмаркинг-тул, предназначенный для запуска тестов производительности в виртуальных средах VMware vSphere (как онпремизных, так и облачных), с учетом симуляции реальной нагрузки различных приложений. Утилита доступна в открытом репозитории на GitHub.

Weathervane позволяет, например, снять метрики с двух различных окружений или его конфигураций, что позволит выбрать наиболее производительную конфигурацию виртуального окружения и выставить самые эффективные настройки виртуальной среды. Также с помощью Weathervane компания VMware сама делает различные тесты, к примеру, вот документ о производительности контейнеров Docker в виртуальной среде VMware vSphere - "Performance of enterprise web applications in Docker containers on VMware vSphere 6.5".

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

Weathervane состоит из трех основных компонентов:

• Приложение (Auction application), которое развертывается в среде тестирования.
• Драйвер рабочей нагрузки (Workload driver), который выдает реалистичную нагрузку для приложения с учетом заданных параметров тестирования.
• Компонент исполнения (Run harness), который автоматизирует процесс исполнения тестовых запусков приложения и собирает результаты, логи и, собственно, данные о производительности.

Также в составе Weathervane есть Supporting tools, которые включают в себя скрипты для настройки экземпляра операционной системы со всем необходимым для запуска утилиты, создания образов Docker и подготовки приложения для запуска в среде тестирования.

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

• Число экземпляров на уровне каждого сервиса. Например, может быть любое число балансировщиков нагрузки, серверов приложений или узлов веб-серверов. Это позволяет создавать конфигурации любого масштаба.
• Число ярусов целевой архитектуры. Например, вы можете не использовать некоторые компоненты, такие как балансировщики и веб-сервера, если вам нужно протестировать небольшую по объему среду.
• Вариант развертывания среды. Например, Weathervane сейчас поддерживает PostgreSQL и MySQL в качестве транзакционной БД, а также Apache Httpd и Nginx в качестве веб-серверов. Ну и надо помнить, что это open source проект, а значит вы сами можете расширять его.
• Конфигурацию сервисов. В настроечном файле можно изменять параметры для каждого из ярусов, которые будут применяться компонентом run harness перед началом каждого прогона бенчмарка.

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

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

Руководство по использованию VMware Weathervane доступно по этой ссылке. Ну а сам проект Weathervane на GitHub доступен тут: https://github.com/vmware/weathervane.

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

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

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

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

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

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

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

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

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

Продолжаем рассказывать об анонсах продуктов и технологий, представленных на конференции 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 выпустила интересный документ о том, как устроен, работает и настраивается протокол 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 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, где описывается, как должны выглядеть оптимальные значения, и что предпринять, если полученные результаты вас не устраивают.

На днях вышел интересный отчет компании 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 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 можно узнать на этой странице.

Весной этого года вышло обновление решения для создания отказоустойчивых кластеров для виртуальных машин на платформе 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 выпустила долгожданный документ, раскрывающий основные аспекты лучших практик для своей серверной платформы виртуализации в плане производительности - "Performance Best Practices for VMware vSphere 6.5".

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

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

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

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

Не так давно мы писали про документ "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 начала конкурировать с продуктом 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 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 выпустила интересный документ, касающийся улучшений в плане производительности различных компонентов последней версии платформы виртуализации - "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 знают, что такое параметры 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".

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

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

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

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

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

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

Скачать VMware IOInsight 1.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 и выше.

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

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

• Virtual SAN Layer 2 and Layer 3 Network Topology Deployments – Cisco, Brocade - документ
• Virtual SAN Layer 2 and Layer 3 Network Topology Deployments – Arista – заметка в блоге на основе документа выше
• Virtual SAN Enterprise Network Design and Implementation with Brocade – документ
• Virtual SAN Network Deployment with Brocade VCS Fabrics – документ

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