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

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

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

На сайте проекта 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 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%, если быть точным). Результаты в таблице:

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

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

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

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

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

Компания 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 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 + создает меньшую нагрузку на клиентское устройство.

Интересный вебинар проведет компания 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. Его получат два участника вебинара. Может быть, повезет именно вам - регистрируйтесь!

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

Какое-то время назад мы писали о функции 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 выпустила очень интересный документ "VMware vSphere 6 Fault Tolerance Architecture and Performance", посвященный производительности технологии VMware Fault Tolerance (FT), которая позволяет обеспечивать непрерывную доступность виртуальных машин, даже в случае отказа хост-сервера VMware ESXi. Делается это за счет техники Fast Checkpointing, по своей сути похожей на комбинацию Storage vMotion и vMotion, которая копирует состояние дисков, памяти, процессорных команд и сетевого трафика на резервную машину, поддерживая ее в полностью синхронизированном с первой состоянии. На данный момент vSphere 6 FT поддерживает виртуальные машины с конфигурацией до 4 vCPU и до 64 ГБ оперативной памяти на хост ESXi.

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

1. Процедура компиляции ядра в гостевой ОС.

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

2. Сетевая активность.

Если говорить о производительности сетевой коммуникации, то на получение данных потерь практически нет, а вот на передачу все происходит процентов на 10 медленнее. Результат для 1 Гбит сети:

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

Результат для 10 Гбит сети. Вот тут и происходит ситуация, когда канал на прием забивается FT-трафиком, как итог - прием происходит только на полосе 2,4 Гбит:

Из-за необходимости поддержки параметров сетевой передачи и приема в синхронном режиме возникает Latency около 6 миллисекунд:

3. Тестирование подсистемы ввода-вывода.

Для тестирования работы с хранилищами (I/O) взяли стандартный инструмент IOMeter. Особых потерь не обнаружилось:

4. Тест Swingbench для Oracle 11g.

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

5. Тест DVD Store на Microsoft SQL Server 2012.

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

6. Бенчмарк на базе TPC-E.

Здесь были симулированы операции сервера брокерской компании, который производит обработку OLTP-транзакций в реальном времени. Тест очень стрессовый, и потери здесь весьма существенны:

7. Операции VMware vCenter Server.

Ну а здесь уже сам сервер vCenter защитили технологией Fault Tolerance и измерили производительность операций для двух типов нагрузки - легкой и тяжелой. При тяжелой нагрузке все происходит медленнее больше чем в 2 раза:

vSphere Web Client работает, в общем-то, неплохо, но хотелось бы лучше:

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

Вчера мы писали про режим воспроизведения, который можно использовать для утилиты esxtop, предназначенной мониторинга производительности хост-серверов VMware ESXi. А сегодня предлагаем вам скачать постер "vSphere 6 ESXTOP quick Overview for Troubleshooting", в котором приведена основная информация для начала работы с esxtop, а также базовые приемы по решению возникающих в виртуальной инфраструктуре проблем с производительностью. Также стоит заглянуть вот в эту и эту заметку на нашем сайте.

Постер можно повесить в админской или серверной, где часто приходится работать с консолью серверов ESXi:

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

Однако их использование в крупных инфраструктурах неизбежно. Рано или поздно возникает необходимость удаления/консолидации снапшотов виртуальной машины (кнопка Delete All в Snapshot Manager), а процесс этот достаточно длительный и требовательный к производительности хранилищ, поэтому неплохо бы заранее знать, сколько он займет.

Напомним, что инициирование удаления снапшотов в vSphere Client через функцию Delete All приводит к их удалению из GUI сразу же, но на хранилище процесс идет долгое время. Но если в процесс удаления возникнет ошибка, то файлы снапшотов могут остаться на хранилище. Тогда нужно воспользоваться функцией консолидации снапшотов (пункт контекстного меню Consolidate):

О процессе консолидации снапшотов мы также писали вот тут. Удаление снапшотов (как по кнопке Delete All, так и через функцию Consolidate) называется консолидацией.

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

• Размер дельта-дисков - самый важный параметр, это очевидно. Чем больше данных в дельта-диске, тем дольше их нужно применять к основному (базовому) диску.
• Количество снапшотов (число дельта-файлов) и их размеры. Чем больше снапшотов, тем больше метаданных для анализа перед консолидацией. Кроме того, при нескольких снапшотах консолидация происходит в несколько этапов.
• Производительность подсистемы хранения, включая FC-фабрику, Storage Processor'ы хранилищ, LUN'ы (число дисков в группе, тип RAID и многое другое).
• Тип данных в файлах снапшотов (нули или случайные данные).
• Нагрузка на хост-сервер ESXi при снятии снапшота.
• Нагрузка виртуальной машины на подсистему хранения в процессе консолидации. Например, почтовый сервер, работающий на полную мощность, может очень долго находится в процессе консолидации снапшотов.

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

Итак, как можно оценивать производительность процесса консолидации снапшотов:

Смотрим на производительность ввода-вывода хранилища, где находится ВМ со снапшотами.

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

1. Сначала смотрим размер файлов снапшотов через Datastore Browser или с помощью следующей команды:

ls -lh /vmfs/volumes/DATASTORE_NAME/VM_NAME | grep -E "delta|sparse"

2. Суммируем размер файлов снапшотов и записываем. Далее находим LUN, где размещена наша виртуальная машина, которую мы будем тестировать (подробнее об этом тут).

3. Запускаем команду мониторинга производительности:

# esxtop

4. Нажимаем клавишу <u> для переключения в представление производительности дисковых устройств. Для просмотра полного имени устройства нажмите Shift + L и введите 36.

5. Найдите устройство, на котором размещен датастор с виртуальной машиной и отслеживайте параметры в колонках MBREAD/s и MBWRTN/s в процессе консолидации снапшотов. Для того, чтобы нужное устройство было вверху экрана, можно отсортировать вывод по параметру MBREAD/s (нажмите клавишу R) or MBWRTN/s (нажмите T).

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

Смотрим на производительность конкретного процесса консолидации снапшотов.

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

1. Запускаем команду мониторинга производительности:

# esxtop

2. Нажимаем Shift + V, чтобы увидеть только запущенные виртуальные машины.

3. Находим ВМ, на которой идет консолидация.

4. Нажимаем клавишу <e> для раскрытия списка.

5. Вводим Group World ID (это значение в колонке GID).

6. Запоминаем World ID (для ESXi 5.x процесс называется vmx-SnapshotVMX, для ранних версий SnapshotVMXCombiner).

7. Нажимаем <u> для отображения статистики дискового устройства.

8. Нажимаем <e>, чтобы раскрыть список и ввести устройство, на которое пишет процесс консолидации VMX. Что-то вроде naa.xxx.

9. Смотрим за процессом по World ID из пункта 6. Можно сортировать вывод по параметрам MBREAD/s (клавиша R) или MBWRTN/s (клавиша T).

10. Отслеживаем среднее значение в колонке MBWRTN/s.

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

Какое-то время назад мы писали о технологии доставки приложений пользователям инфраструктуры настольных ПК предприятия - VMware App Volumes (ранее это называлось Cloud Volumes). Суть ее заключается в том, что виртуализованные и готовые к использованию приложения VMware ThinApp доставляются пользователям в виде подключаемых виртуальных дисков к машинам.

Недавно компания VMware выпустила документ "VMware App Volumes Reference Architecture", в котором объясняется работа технологии App Volumes, рассматривается референсная архитектура этого решения, а также проводится тестирование производительности доставляемых таким образом приложений по сравнению с их нативной установкой внутри виртуальных ПК:

Собственно, типовая архитектура решения App Volumes выглядит следующим образом:

Здесь показаны основные компоненты такой инфраструктуры:

• AppStacks - это тома, которые содержат сами установленные приложения и работают в режиме Read Only. Их можно назначить пользователям Active Directory, группам или OU. Один такой диск может быть назначен сразу нескольким виртуальным ПК (по умолчанию доступен всем машинам датацентра).
• Writable Volumes - это персонализированные тома, которые принадлежат пользователям. Они хранят настройки приложений, лицензионную информацию, файлы конфигураций приложений и сами приложения, которые пользователь установил самостоятельно. Один такой диск может быть назначен только одному десктопу, но его можно перемещать между десктопами.
• App Volumes Manager Server - это Windows-сервер, содержащий административную консоль для настройки продукта и управления им.

В качестве референсной архитектуры используется инфраструктура из 2000 виртуальных ПК, запущенных на 18 хостах ESXi инфраструктуры VMware Horizon View:

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

Здесь описаны 3 варианта тестирования:

• Приложения, нативно установленные в виртуальных ПК.
• Приложения App Volumes, использующие один AppStack, содержащий основные приложения пользователей.
• Приложения App Volumes, распределенные по трем различным AppStack.

Для обоих случаев тестирования App Volumes использовался один Writable Volume. Тут были получены следующие результаты (больше очков - это лучше).

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

Взглянем на время отклика приложений:

Оценим время запуска приложений:

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

Документ очень полезен для оценки потерь производительности с точки зрения User Experience при использовании App Volumes по сравнению с традиционной доставкой приложений. Скачать 50-страничный документ можно скачать по этой ссылке - почитайте, там действительно интересно все изложено.

Пару месяцев назад мы писали о том, что вышло обновление VMware vSphere 5.5 Update 3, которое полезно для пользователей, еще не перешедших на обновленную версию платформы виртуализации vSphere 6.

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

Как вы знаете, в vSphere Web Client 6.0 был сделан шаг вперед в плане улучшения производительности, а сейчас инженеры VMware портировали эти изменения уже на младшую версию vSphere 5.5 U3. При этом, по оценке самой VMware, теперь производительность тонкого клиента в этой версии в некоторых аспектах аналогична оной в vSphere 6.0 Update 1.

Улучшения были сделаны в следующих областях:

• Меню действий и меню по правому клику мыши
• Страницы Related Objects, Summary и Settings
• Мастера выполнения операций (миграция, создание шаблона и т.п.)
• Процесс логина в консоль
• Графики отображения производительности

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

• Маленькое – vCenter Server (4 vCPU / 16 GB RAM), 2 хост, 4 ВМ
• Большое – vCenter Server (32 vCPU / 64 GB RAM), 1000 хостов, 15000 ВМ

Посмотрим на время логина в Web Client:

Уменьшилось ровно в 2 раза. Теперь посмотрим на отклик меню действий (оно же вызывается по правой кнопке мыши):

Здесь кое-где и в 3 раза улучшилась ситуация. Для меню виртуальных машин ситуация не сильно улучшилась, так как в этом меню большое количество контекстно-зависимых действий.

Генерация графиков производительности (выбор объектов, ресайз графиков, обновление, выбор элементов для отображения). Здесь очень существенные улучшения, более чем в 2 раза:

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

В общем, если вы еще не обновились - причина поставить новую версию Web Client есть.

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

На блогах VMware появился интересный пост про производительность виртуальных машин, которые "растянуты" по ресурсам на весь физический сервер, на котором они запущены. В частности, в посте речь идет о сервере баз данных, от которого требуется максимальная производительность в числе транзакций в секунду (см. наш похожий пост о производительности облачного MS SQL здесь).

В данном случае речь идет о виртуализации БД с типом нагрузки OLTP, то есть обработка небольших транзакций в реальном времени. Для тестирования использовался профиль Order-Entry, который основан на базе бенчмарка TPC-C. Результаты подробно описаны в открытом документе "Virtualizing Performance Critical Database Applications in VMware vSphere 6.0", а здесь мы приведем основные выдержки.

Сводная таблица потерь на виртуализацию:

А вот так выглядит график итогового тестирования (кликабельно):

Для платформы VMware ESXi 5.1 сравнивалась производительность на процессоре микроархитектуры Westmere, а для ESXi 6.0 - на процессорах Haswell.

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

А вот так выглядят усредненные значения для версий ESXi в сравнении друг с другом по отношению к запуску нагрузки на нативной платформе:

Ну и несложно догадаться, что исследуемая база данных - это Oracle. Остальное читайте в интереснейшем документе.

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

Horizon Toolbox 2 - это дополнение к стандартной консоли View Administrator, исполненное в виде веб-портала с различными функциями вроде аудита, удаленной поддержки и прочих полезных возможностей:

Перечислим основные нововведения VMware View Horizon Toolbox 2:

1. Console Access

Теперь появилась возможность полноценного доступа к консоли виртуальных ПК:

Можно просматривать список виртуальных машин для пулов виртуальных ПК и фильтровать их по именам машин (или DNS-именам).

2. Power-on policy

Теперь появилась вкладка Power-on policy, на которой можно посмотреть и изменить политику включения рабочих виртуальных ПК по дням недели:

Отдельную политику включения можно настраивать для каждого пула виртуальных десктопов.

3. Client IP address auditing

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

4. Installation file

Теперь процесс развертывания Horizon Toolbox 2 идет в полноценном графическом интерфейсе.

5. Прочие улучшения

• Производительность функций аудита была существенно повышения за счет оптимизации SQL-запросов.
• Функция Remote assistance работает более стабильно.
• Улучшена совместимость с различными версиями Horizon View.
• Установщик на стороне пользователя проверяет, что режим Windows Remote Assistance настроен корректно.

Также вы можете почитать 2 полезных документа о View Horizon Toolbox 2 - это руководство по продукту, а также открытый документ об этом решении.

Скачать Horizon Toolbox 2 можно по этой ссылке.

В блоге VMware появился интересный пост о производительности СУБД Microsoft SQL Server на облачной платформе VMware vCloud Air. Целью исследования было выявить, каким образом увеличение числа процессоров и числа виртуальных машин сказываются на увеличении производительности баз данных, которые во многих случаях являются бизнес-критичными приложениями уровня Tier 1 на предприятии.

В качестве тестовой конфигурации использовались виртуальные машины с числом виртуальных процессоров (vCPU) от 4 до 16, с памятью от 8 до 32 ГБ на одну ВМ, а на хост-серверах запускалось от 1 до 4 виртуальных машин:

На физическом сервере было 2 восьмиядерных процессора (всего 16 CPU), то есть можно было запустить до 16 vCPU в режиме тестирования линейного роста производительности (Hyper-Threading не использовался).

В качестве приложения использовалась база данных MS SQL с типом нагрузки OLTP, а сами машины размещались на хостинге vCloud Air по модели Virtual Private Cloud (более подробно об этом мы писали вот тут). Для создания стрессовой нагрузки использовалась утилита DVD Store 2.1.

Первый эксперимент. Увеличиваем число четырехпроцессорных ВМ на хосте от 1 до 4 и смотрим за увеличением производительности, выраженной в OPM (Orders Per Minute), то есть числе небольших транзакций в минуту:

Как видно, производительность показывает вполне линейный рост с небольшим несущественным замедлением (до 10%).

Второй эксперимент. Увеличиваем число восьмипроцессорных ВМ с одной до двух:

Здесь также линейный рост.

Замеряем производительность 16-процессорной ВМ и сводим все данные воедино:

Проседание производительности ВМ с 16 vCPU обусловлено охватом процессорами ВМ нескольких NUMA-узлов, что дает некоторые потери (да и вообще при увеличении числа vCPU удельная производительность на процессор падает).

Но в целом, как при увеличении числа процессоров ВМ, так и при увеличении числа виртуальных машин на хосте, производительность растет вполне линейно, что говорит о хорошей масштабируемости Microsoft SQL Server в облаке vCloud Air.

Кстати, если хочется почитать заказуху про то, как облака VMware vCloud Air уделывают Microsoft Azure и Amazon AWS, можно пройти по этим ссылкам:

• Processor performance using the SPEC CPU2006 benchmark
• Storage I/O performance using the Flexible I/O (FIO) benchmark
• Database performance using the DVD Store 2.1 benchmark

Мы уже писали о том, что "растянутый" кластер VMware HA Stretched Cluster прекрасно работает и поддерживается вместе с отказоустойчивыми хранилищами Virtual SAN. Также мы писали о документе с лучшими практиками по построению таких кластеров, для которых требуется обеспечивать максимальную производительность.

Однако многие задаются вопросом - а как планировать ширину канала между площадками таких растянутых кластеров, чтобы обеспечить необходимую пропускную способность для синхронизации узлов кластера VMware Virtual SAN? В помощь таким пользователям компания VMware выпустила интересный документ "VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance", в котором даются конкретные параметры и формулы для расчета необходимой пропускной способности между площадками.

Архитектура растянутого кластера в общем случае выглядит так:

Таким образом, имеет место быть 2 связи - между двумя площадками как узлами кластера, а также между каждой из площадок и компонентом Witness, следящим за состоянием каждой из площадок и предотвращающим сценарии Split Brain.

Для этих соединений рекомендуются следующие параметры:

Как известно, реальный трафик состоит из отношения операций чтения и записи, которое зависит от характера нагрузки. Например, в VDI-среде это отношение составляет примерно 30/70, то есть 30% - это операции чтения (read), а 70% - операции записи (write).

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

B = Wb * md * mr

где:

• Wb - полоса записи данных.
• md - множитель данных, он зависит от потока метаданных кластера VSAN и сервисных операций. VMware рекомендует использовать значение 1,4 для этого параметра.
• mr - множитель ресинхронизации. Для целей ресинхронизации VMware рекомендует заложить в канал еще 25%, то есть использовать значение этого параметра 1,25.

Например, рабочая нагрузка у вас составляет 10 000 IOPS на запись (10 тысяч операций в секунду). Возьмем типичный размер операции записи в 4 КБ и получим параметр Wb:

Wb = 10 000 * 4KB = 40 MB/s = 320 Mbps

Мегабайты в секунду переводятся в мегабиты умножением на 8. Ну и заметим, что требование канала по записи нужно умножать на 1,4*1,25 = 1,75. То есть канал нужно закладывать почти в 2 раза больше от требований по записи данных.

Теперь считаем требуемую пропускную способность канала между площадками:

B = Wb * md * mr = 320 Mbps * 1,4 * 1,25 = 560 Mbps

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

Компания VMware выпустила очень познавательный документ "An overview of VMware Virtual SAN caching algorithms", который может оказаться полезным всем тем, кто интересуется решением для создания программных хранилищ под виртуальные машины - VMware Virtual SAN. В документе описан механизм работы кэширования, который опирается на производительные SSD-диски в гибридной конфигурации серверов ESXi (то есть, SSD+HDD).

SSD-диски используются как Performance tier для каждой дисковой группы, то есть как ярус производительности, который преимущественно предназначен для обеспечения работы механизма кэширования на чтение (Read cache, RC). По умолчанию для этих целей используется 70% емкости SSD-накопителей, что экспериментально было определено компанией VMware как оптимальное соотношение.

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

То есть, вы можете купить диск SSD Intel S3700 на 100 ГБ за $200, который может выдавать до 45 000 IOPS, а это где-то $0,004 за IOPS. С другой же стороны, можно купить за те же $200 диск от Seagate на 1 ТБ, который будет выдавать всего 100 IOPS, что составит $2 на один IOPS.

Кэш на чтение (RC) логически разделен на "cache lines" емкостью 1 МБ. Это такая единица информации при работе с кэшем - именно такой минимальный объем на чтение и резервирование данных в памяти используется. Эта цифра была высчитана экспериментальным путем в исследовании нагрузок на дисковую подсистему в реальном мире, которое VMware предпочитает не раскрывать. Кстати, такой же величины объем блока в файловой системе VMFS 5.x.

Помимо обслуживания кэша на SSD, сервер VMware ESXi использует небольшой объем оперативной памяти (RAM) для поддержки горячего кэша обслуживания этих самых cache lines. Он содержит несколько самых последних использованных cache lines, а его объем зависит от доступной памяти в системе.

Также в памяти хранятся некоторые метаданные, включая логические адреса cache lines, валидные и невалидные регионы кэша, информация о сроке хранения данных в кэше и прочее. Все эти данные постоянно хранятся в памяти в сжатом виде и никогда не попадают в своп. При перезагрузке или выключении/включении хоста кэш нужно прогревать заново.

Итак, как именно работает кэширование на SSD в VMware Virtual SAN:

1. Когда операция чтения приходит к Virtual SAN, сразу же включается механизм определения того, находятся ли соответствующие данные в кэше или нет. При этом запрашиваемые данные за одну операцию могут быть больше одной cache line.

2. Если данные или их часть не находятся в RC, то для них резервируется буфер нужного объема с гранулярностью 1 МБ (под нужное количество cache lines).

3. Новые аллоцированные cache lines вытесняют из кэша старые в соответствии с алгоритмом Adaptive Replacement Cache (ARC), который был лицензирован VMware у IBM.

4. В случае промаха кэша каждое чтение одной cache line с HDD разбивается на чанки размером 64 КБ (этот размер тоже был определен экспериментально в ходе исследований). Это сделано для того, чтобы не забивать очередь на чтение с HDD "жирной" операцией чтения в 1 МБ, которая бы затормозила общий процесс ввода-вывода на диск.

5. В общем случае, одна операция чтения запрашивает лишь часть данных одной cache line, а первыми читаются именно нужные 64 КБ чанки с HDD-диска от этой cache line.

6. Запрошенные с HDD-диска данные сразу отдаются к подсистеме вывода и направляются туда, откуда их запросили, а уже потом в асинхронном режиме они попадают в соответствующие cache lines кэша и под каждую из них выделяется буфер 1 МБ в памяти. Таким образом устраняются потенциальные затыки в производительности.

В документе описаны также и механики работы кэша на запись (Write cache), для которого используется техника write-back, а также рассматриваются All Flash конфигурации. Читайте - это интересно!

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

Но оказывается, что использование esxtop само по себе может тормозить работу сервера VMware ESXi!

Это может произойти в ситуации, если у вас к ESXi смонтировано довольно много логических томов LUN, на обнаружение которых требуется более 5 секунд. Дело в том, что esxtop каждые 5 секунд повторно инициализирует объекты, с которых собирает метрики производительности. В случае с инициализацией LUN, которая занимает длительное время, запросы на инициализацию томов будут складываться в очередь. А как следствие (при большом числе томов) это будет приводить к возрастанию нагрузки на CPU и торможению - как вывода esxtop, так и к замедлению работы сервера в целом.

Выход здесь простой - надо использовать esxtop с параметром -l:

# esxtop -l

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

На днях компания VMware выпустила полезный документ о лучших практиках по использованию "растянутых" кластеров на базе решения для создания отказоустойчивых хранилищ - "VMware Virtual SAN Stretched Cluster Performance and Best Practices".

Напомним также, что не так давно мы писали про конфигурацию VMware HA Stretched Cluster вместе с отказоустойчивыми хранилищами Virtual SAN.

Как и другие документы этой серии, этот whitepaper богат различными графиками и диаграммами, касающимися производительности решения. Например, вот производительность обычного кластера VMware Virtual SAN 6.1 и растянутого с задержками (latency) в 1 мс и 5 мс:

Основные моменты, раскрываемые в документе:

• Развертывание и настройка Virtual SAN Stretched Cluster
• Производительность растянутого кластера в сравнении с обычным
• Производительность кластера при различных отказах (хост, сайт целиком)
• Лучшие практики использования растянутых кластеров

Больше 5 лет назад мы писали о технологии VMware Storage I/O Control (SIOC), которая позволяет приоритизировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены. С тех пор многие администраторы применяют SIOC в производственной среде, но не все из них понимают, как именно это работает.

На эту тему компания VMware написала два интересных поста (1 и 2), которые на практических примерах объясняют, как работает SIOC. Итак, например, у нас есть вот такая картинка:

В данном случае мы имеем хранилище, отдающее 8000 операций ввода-вывода в секунду (IOPS), к которому подключены 2 сервера ESXi, на каждом из которых размещено 2 виртуальных машины. Для каждой машины заданы параметры L,S и R, обозначающие Limit, Share и Reservation, соответственно.

Напомним, что:

• Reservation - это минимально гарантированная производительность канала в операциях ввода-вывода (IOPS). Она выделяется машине безусловно (резервируется для данной машины).
• Shares - доля машины в общей полосе всех хостов ESXi.
• Limit - верхний предел в IOPS, которые машина может потреблять.

А теперь давайте посмотрим, как будет распределяться пропускная способность канала к хранилищу. Во-первых, посчитаем, как распределены Shares между машинами:

Общий пул Shares = 1000+2500+500+1000 = 5000

Значит каждая машина может рассчитывать на такой процент канала:

VM1 = 1000/5000 = 20% = 0,2 * 8000 = 1600 IOPS
VM2 = 2500/5000 = 50% = 0,5 * 8000 = 4000 IOPS
VM3 = 500/5000 = 10% = 0,1 * 8000 = 800 IOPS
VM4 = 1000/5000 = 20% = 0,2 * 8000 = 1600 IOPS

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

ESX1 = 3500/5000 = 70%
ESX2 = 1500/5000 = 30%

А теперь обратимся к картинке. Допустим у нас машина VM1 простаивает и потребляет только 10 IOPS. В отличие от планировщика, который управляет памятью и ее Shares, планировщик хранилищ (он называется mClock) работает по другому - неиспользуемые иопсы он пускает в дело, несмотря на Reservation у это виртуальной машины. Ведь он в любой момент может выправить ситуацию.

Поэтому у первой машины остаются 1590 IOPS, которые можно отдать другим машинам. В первую очередь, конечно же, они будут распределены на этом хосте ESXi. Смотрим на машину VM2, но у нее есть LIMIT в 5000 IOPS, а она уже получает 4000 IOPS, поэтому ей можно отдать только 1000 IOPS из 1590.

Следовательно, 590 IOPS уйдет на другой хост ESXi, которые там будут поделены в соответствии с Shares виртуальных машин на нем. Таким образом, распределение IOPS по машинам будет таким:

VM1 = 10 IOPS
VM2 = 4000+1000 = 5000 IOPS (так как установлен Limit)
VM3 = 800 + ((500/1500) * 590) = 997 IOPS
VM4 = 1600 + ((1000/1500) * 590) = 1993 IOPS

Все просто и прозрачно. Если машина VM1 начнет запрашивать больше канала, планировщик mClock начнет изменять ситуацию и приведет ее к значениям, описанным выше.

Бывает так, что на виртуальной или физической машине заканчивается свободное место на диске, где расположена база данных для VMware vCenter. Чаще всего причина проста - когда-то давно кто-то не рассчитал размер выделенного дискового пространства для сервера, где установлен vCenter и SQL Server Express.

В этом случае в логах (в SQL Event Log Viewer и SQL Log) будут такие ошибки:

Could not allocate space for object ‘dbo.VPX_EVENT_ARG’.’PK_VPX_EVENT_ARG’ in database ‘VIM_VCDB’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 4096 MB per database.

Could not allocate space for object 'dbo.VE_event_historical'.'PK__VE_event_histori__00551192' in database 'ViewEvent' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files tothe filegroup, or setting autogrowth on for existing files in the filegroup.

Решение в данном случае простое - нужно выполнить операцию по очистке старых данных из БД SQL Server (Shrink Database). Делается это в SQL Management Studio - нужно выбрать базу данных и выполнить Tasks -> Shrink -> Database:

Смотрим, что получится и нажимаем Ok:

Также в KB 1025914 вы найдете более детальную информацию о том, как почистить базы данных Microsoft SQL Server и Oracle. Там же есть и скрипты очистки БД:

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

Давайте посмотрим, как же технология VVols влияет на процесс резервного копирования виртуальных машин, например, с помощью основного продукта для бэкапа ВМ Veeam Backup and Replication, который полностью поддерживает VVols. Для начала рассмотрим основные способы резервного копирования, которые есть в виртуальной среде:

• Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
• Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
• Резервное копирование по сети SAN (SAN-to-SAN backup) - в этом случае на выделенном сервере (Backup Server) через специальный механизм Virtual Disk API происходит снятие снапшота ВМ без задействования хоста ESXi и бэкап машины на целевое хранилище напрямую в сети SAN без задействования среды Ethernet.

Последний способ - самый быстрый и эффективный, но он требует наличия специальных интерфейсов (vSphere APIs и Virtual Disk Development Kit, VDDK), которые должны присутствовать на выделенном сервере.

К сожалению, для VVols способ резервного копирования по сети SAN еще не поддерживается, так как данный механизм для прямой работы с хранилищами SAN для VVols еще не разработан. Поэтому при работе с VVols придется использовать NBD backup. Однако не расстраивайтесь - большинство компаний именно его и используют для резервного копирования машин на томах VMFS в силу различных причин.

Работа хоста VMware ESXi с томами виртуальной машины VVols выглядит следующим образом:

Для процессинга операций используется Protocol Endpoint (PE), который представляет собой специальный административный LUN на хранилище. PE работает с лунами машин (VVols), которые представлены через secondary LUN ID, а VASA Provider со стороны дискового массива снабжает vCenter информацией о саблунах виртуальных машин, чтобы хост ESXi мог с ними работать через PE.

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

Вернемся к процессу резервного копирования. Как известно, он опирается на механизм работы снапшотов (Snapshots) - перед снятием резервной копии у ВМ делается снапшот, который позволяет перевести базовый диск в Read Only, а изменения писать в дельта-диск снапшота. Далее базовый диск ВМ копируется бэкап-сервером, ну а после того, как базовый диск скопирован, снапшот склеивается с основным диском, возвращая диски машины обратно в консолидированное состояние.

Так это работает для файловой системы VMFS, которая развертывается поверх LUN дискового массива. Сами понимаете, что при интенсивной нагрузке во время резервного копирования (особенно больших виртуальных дисков) с момента снятия снапшота может пройти довольно много времени. Поэтому в дельта-дисках может накопиться много данных, и процесс консолидации снапшота на практике иногда занимает часы!

Для виртуальных томов VVols все работает несколько иначе. Давайте взглянем на видео:

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

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

Такой рабочий процесс несколько увеличивает время создания снапшота в среде VVols:

Но это всего лишь десятки секунд разницы. А вот время консолидации снапшота по окончанию резервного копирования уменьшается во много раз:

Как следствие, мы имеем уменьшение совокупного времени резервного копирования до 30%:

Так что, если говорить с точки зрения резервного копирования виртуальных машин, переход на VVols обязательно даст вам прирост производительности операций резервного копирования и позволит уменьшить ваше окно РК.

Еще в самом конце августа компания VMware выпустила весьма достойный внимания документ "VMware vCenter Server Performance and Best Practices", рассказывающий о лучших практиках по использованию сервера vCenter версии 6 в контексте производительности. Напомним, что ранее мы уже писали про еще один документ о vCenter - "VMware vCenter Server 6.0 Cluster Performance".

Основные моменты документа:

• vCenter Server 6.0 имеет существенно большую производительность, чем предыдущая версия vCenter Server 5.5. Некоторые операции исполняются почти в 2 раза быстрее, а отображение страниц в Web Client работает на 90% быстрее.
• vCenter Server Appliance работает почти так же быстро, как и полноценный vCenter Server для Windows.
• Ресурсы, выделенные для vCenter (CPU, память, диск и полоса пропускания сети) влияют на размер доступного в vCenter окружения и скорость исполнения операций.
• Используя рекомендации из документа и правильно выделяя ресурсы в зависимости от нагрузки, пользователи могут значительно повысить производительность стандартной конфигурации VMware vCenter.

Скачать документ "VMware vCenter Server Performance and Best Practices" можно по этой ссылке.

Совсем недавно компания VMware выпустила интересный документ о производительности операций виртуальной инфраструктуры под управлением VMware vCenter 6 для серверов, работающих в кластере HA/DRS - "VMware vCenter Server 6.0 Cluster Performance".

Упор сделан на сравнение производительности свежей версии vCenter 6.0 с предшественником - vCenter 5.5. Напомним, что шестая версия поддерживает до 64 хоста ESXi в кластере и до 8000 виртуальных машин (до этого было 32 хоста ESXi и 3000 виртуальных машин).

Конфигурация тестовой среды была следующей:

Программные компоненты:

Производительность каких операций проверялась:

• Add Port Group
• Remove Port Group
• Clone VM
• Create Folder
• Delete Folder
• Create Snapshot
• Delete Snapshot
• Group Power-On VMs
• vMotion VM
• Power On VM
• Power Off VM
• Reconfigure VM
• Register VM
• Unregister VM
• Relocate VM
• Remove VM
• Reset VM
• Suspend VM
• Resume VM

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

• vCenter 6.0 показывает лучшую операционную производительность (в количестве операций) до 66% лучше прошлой версии.

• Улучшенная производительность под очень тяжелыми нагрузками.
• Одинаковая производительность как vCenter Server для Windows, так и виртуального модуля vCSA на базе Linux.
• Операции с виртуальными машинами происходят существенно быстрее.

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

Недавно компания VMware выпустила очень интересный документ "What’s New in VMware vSphere 6 - Performance", в котором рассказывается о том, какие улучшения были сделаны в новой версии vSphere 6.0, касающиеся различных аспектов производительности платформы (вычислительные ресурсы, хранилища и сети).

Документ выпущен отделом технического маркетинга VMware, и в нем приведены вполне конкретные сведения об увеличении производительности компонентов vSphere.

Например, вот сводная картинка улучшения производительности vCenter (версия 6.0 против 5.5) при тяжелых нагрузках на Microsoft SQL Server 2012 в зависимости от числа объектов, которые находятся под управлением сервиса (размер Inventory). Данные приведены в количестве операций в минуту. Результаты впечатляют:

Улучшения кластеров отказоустойчивых хранилищ VMware Virtual SAN (результаты по конфигурации All-Flash еще не обработаны):

С точки зрения производительности виртуальных сетевых адаптеров VMXNET 3, платформа vSphere 6.0 научилась выжимать из них более 35 гигабит в секунду при работе с физическими адаптерами 40 GbE:

Ну и в целом в документе есть еще много чего интересного - скачивайте.