Сегодня мы протестируем аналогичного «коня», но на примере Linux-based операционной системы. Поскольку сборок Linux великое множество, чтобы никого не обидеть (а еще – потому что я не очень хорошо разбираюсь в этом вашем Линуксе я выбрал в качестве подопытной RouterOS Cloud Hosted Router от Microtik. Это специальная версия RouterOS для виртуальных сред. Поддерживается ESXi, Hyper-V и еще что-то там, список тут – https://wiki.mikrotik.com/wiki/Manual:CHR. Для нашего теста главное – в CHR есть встроенный драйвер VMXNET3.

Я применяю RouterOS CHR в качестве виртуального маршрутизатора на standalone хостах с ESXi, когда нужно просто выставить ВМ из них в интернет. Также можно быстро поднять IP-IP или Ethernet-Over-IP туннели до отдельных ВМ или их групп, поднять VPN сервер, опубликовать порты и многое другое, что умеет RouterOS. В общем, мне очень нравится этот роутер, и сегодня попробуем с его помощью побить мой предыдущий рекорд – 29 гиг/сек.

Для корректности сравнения используем тот же самый хост. Напомню его характеристики: материнская плата ASUS X99-E, процессор Intel Xeon E5-2620 v4 2.1 ГГц, заведомо достаточное количество RAM DDR4 2133. Версия гипервизора ESXi 6.5.0 Update 1 (Build 5969303).

Создаем две ВМ с характеристиками: 2 vCPU, 1024 Mb RAM (All locked), по 2 паравиртуальных сетевых адаптера VMXNET3. Диск приделываем к контроллеру IDE – это требование к загрузочному диску RouterOS CHR. Остальные диски могут быть на паравиртуальном SCSI. Первый адаптер с каждой ВМ включаем в дефолтный виртуальный коммутатор с подключенной к нему сетевой картой Intel I218-V с MTU 1500. Вторые адаптеры – в вновь созданный и никуда не подключенный виртуальный коммутатор с MTU 9000:Установка системы состоит в скачивании с сайта https://mikrotik.com/download из раздела Cloud Hosted Router vmdk–файла свежей версии CHR (на дату написания статьи это 6.40.4) и присовыванию этого файла в качестве диска в ВМ при её создании.

После запуска ВМ входим через консоль под admin без пароля. Далее можно настроить роутер из командной строки, либо настроить только IP-адрес на одном интерфейсе. Далее подключиться к нему с помощью специальной программы winbox, из которой уже настраивать все остальное. Производитель раздает бесплатный триал на 2 месяца, достаточно зарегистрироваться на сайте. При активации триала нужно указать уровень лицензирования, ограничивающий максимальную скорость на интерфейсах. Нас интересует, конечно же, unlimited. В сети куча информации по лицензированию CHR и мануалов по настройке, так что повторяться не будем.

Приступаем! В RouterOS встроен замечательный инструмент по тестированию пропускной способности – Bandwidth test. Это модуль, который цепляется по IP-адресу из одной RouterOS к другой, авторизуется там и начинает гонять данные в указанном направлении до тех пор, пока ему не скажут Stop. И в модуле, и в окнах свойств интерфейсов есть счетчики, которые в реальном времени показывают скорость передачи по интерфейсу. С помощью всего этого мы и будем тестировать пропускную способность между двумя ВМ сначала через виртуальный коммутатор с MTU 1500, а затем через второй виртуальный коммутатор с MTU 9000. И сегодня, в отличие от прошлого раза, никакой академичности. Что мне покажет winbox – то я и заскриню в статью.

Первый тест – tcp в 2 потока между интерфейсами ether1 каждой ВМ. По умолчанию выставлено 20, но мы поставим 2 и посмотрим, что получится. CHR01 слева, CHR02 справа.

Замечаем нечто странное… Меняем в тесте send на receive и запускаем еще раз:

Понимаем, что весьма странно то, что отправляющая и приемная сторона показывают пусть немного, но разные скорости. А еще – количество пакетов в секунду на стороне передачи много меньше, чем количество на стороне приема. Для проверки смотрим одновременно в esxtop – n:

Что-ж, сдаваться санитарам еще рано: две совершенно разные софтины показывают одно и то же: CHR02 отправляет ~34k пакета в секунду (packet per second, PPS) со скоростью 17229 Мб/сек, а CHR01 принимает ~1500k PPS на скорости 17996 Мб/сек. И средний размер пакета (PSZTX), отправляемого CHR02 ~ 64 килобайта. А принимаемого (PSZRX) CHR01 ~ 1500, как и сказано в MTU виртуального коммутатора vSwitch0. Как-то так… Только почему CHR отправляет пакеты размером в 64 килобайта, хотя на интерфейсе четко сказано:

MTU 1500 – непонятно. Но оно работает. И это хорошо.

Пробуем тест по udp:

Разворачиваем:

Никаких фокусов, 16 гигабит в секунду и 1350k PPS с обоих сторон. Esxtop подтверждает:

Средний размер пакета ~ 1500 и на приеме и на передаче, как и указано в тесте.
Теперь попробуем погонять трафик между интерфейсами Ether2 через виртуальный коммутатор с MTU 9000. На каждом интерфейсе обеих CHR также прописан MTU 9000, хотя, судя по тому, что мы видели только что, это еще ничего не гарантирует.

В интерфейсе winbox везде где есть графики загруженности – есть удобная измерительная линеечка – показываю её на этом скриншоте в правом нижнем углу. Разворачиваем тест:

Я увидел небольшие провалы на тесте, остановил и увеличил количество потоков до 10. Получилось 28 гигабит в секунду, что близко к полученному нами в прошлом тестировании ВМ с Windows. Esxtop подтвержадет:

Вновь видим тот же фокус с пакетами под 64к. Но получатель на этот раз получает пакет с MTU 9000, так что по крайней мере виртуальный коммутатор ESXi работает как ожидалось.

Пробуем udp:

Разворачиваем:

Esxtop:

Дамы и господа, поздравляю вас с подтвержденным результатом в 42 гигабита в секунду! :))

Пробуем увеличить количество vCPU. Ставим по 4 в обе ВМ.

Как видим – небольшое падение. Было 28.3, стало 27.6. Думаю, что это следствие того же феномена, который мы исследовали в предыдущей статье: количество vCPU активных ВМ сравнялось с количеством физических ядер процессора и шедулер хоста не знает, куда девать поток, обрабатывающий виртуальный коммутатор. Проверяем. Ставим обеим ВМ Sheduler affinity на физические ядра. Наша задача – не выделить виртуальным машинам больше ресурса, а заставить шедулер вынести обработку виртуального коммутатора не на ядра, занятые ВМ. Поэтому Reservation CPU или Latency Sensitivity – High нас не спасут.



На короткое время, когда шедулер работает так как нам хотелось, мы получаем 30 с копейками гигабит. В остальное – увы – те же 27.6 Гб/с. Пробуем предпоследний фокус – уменьшаем количество vCPU, но оставляем Affinity: 0,2 для CHR01 и 8,10 для CHR02. Запускаем тест – неуспех. Даже скриншот приводить не буду – он такой же, кратковременные подъемы до 30 гиг. Убираем Affinity и просто «на посмотреть» включаем Latency Sensitivity – High. Оно включилось:

4 ядра полностью отданы двум ВМ. Но вот результат… :

Как видим, для нашей CHR отключение «Interrupt coalescing and LRO», которое произошло при включении «Latency Sensitivity – High» дало обратный эффект: vCPU хоть и безраздельно используют физические ядра процессора, однако нагрузились прерываниями от каждого полученного сетевого пакета, и общая пропускная способность снизилась почти вдвое.

Вместо заключения: VMXNEТ3 – действительно жутко быстро и запредельно рядом. Две пары виртуалок под разными ОС показали близкие скорости передачи по tcp: 29 гигабит в секунду. Думаю, что на процессоре с большей частотой этот показатель еще увеличится. CHR по udp показала 40 с лишним гигабит, однако сравнивать не с чем, так как тестирование udp iperf’ом под Windows – та еще песня, и петь её мне совсем не хочется. Заодно мы узнали, что CHR 6.40.4 при тестировании пропускной способности умеет посылать, а виртуальный коммутатор ESXi 6.5 u1 – принимать пакеты размером аж до 64 килобайт, и корректно их обрабатывать.

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

http://rickardnobel.se/vmxnet3-vs-e1000e-and-e1000-part-2/

http://www.computertechblog.com/iperf-network-performance-comparison-between-virtual-machines-on-esxi6/

содержащие весьма противоречивые данные, к тому же многие тесты датировались 2012-2014 годами выпуска. Посему ваш покорный слуга принял решение провести небольшое тестирование самостоятельно.

Часть 1. Тестирование конфигурации с настройками по умолчанию.

Никаких особых планов тестирования не писалось. Было только понимание, что производительность – вещь никакая не абстрактная, а очень даже конкретная. Поэтому и измерения тоже должны быть конкретными – берем конкретный хост, конкретную ОС и конкретно измеряем пропускную способность.

«Под рукой» оказался практически незагруженный хост на базе материнской платы ASUS X99-E с процессором Intel Xeon E5-2620 v4 2.1 ГГц, заведомо достаточное количество RAM DDR4 2133. Версия гипервизора ESXi 6.5.0 Update 1 (Build 5969303).

Первым делом были созданы две ВМ с параметрами 4vCPU, 4 Gb RAM (All locked), 40 Gb disk (on paravirtual SCSI controller), сетевой адаптер VMXNET3. Версия ВМ – 13.

В каждую ВМ был установлен Windows Server 2012R2 со всеми обновлениями на 19.10.2017 и VMware Tools 10.1.7 (Build 5541682). Брандмауэр Windows выключен. На сетевые адаптеры внутри ВМ назначены статические IP-адреса. Для чистоты эксперимента виртуальные сетевые адаптеры обеих ВМ были подключены в отдельную порт-группу на отдельном виртуальном коммутаторе. Виртуальный коммутатор не подключался ни к одному физическому адаптеру, т.к. исследовалась производительность не конкретной сетевой карты, а паравиртуального адаптера и виртуального коммутатора.

Для замеров пропускной способности виртуальной сети между этими двумя ВМ использовался iperf 3.1.3 x64. На основании прошлого опыта использования iperf было принято решение тестировать несколько раз, с изменением количества TCP потоков от 1 до 16.

ВМ TEST2 выполняла роль сервера (команда iperf –s). Чтобы уж совсем придать «академичность» тестированию в соответствии с остатками моих знаний по метрологии замеры производились 3 раза (для последующего усреднения результатов) по 20 секунд, с паузой в 3 секунды. Предварительные измерения показали наличие артефактов (или, если угодно – статистических выбросов) в первые несколько секунд измерений:

Поэтому первые 5 секунд после запуска теста решено было отбрасывать и не учитывать в результатах измерений. Благо у iperf для этого есть специальная опция –O. Также трижды производились замеры в обратном направлении трафика (опция iperf -R). Для всего этого на ВМ TEST1 был написан и запущен небольшой скрипт:

FOR /L %%i IN (1,1,16) DO (
FOR %%j IN (1,2,3) DO (
ECHO %date% %time%>>testresult01.log
iperf3.exe -c 10.10.1.11 -t25 -O5 -P%%i>>testresult01.log
timeout 3 > nul
)
FOR %%j IN (1,2,3) DO (
ECHO %date% %time%>>testresult01.log
iperf3.exe -c 10.10.1.11 -t25 -O5 -P%%i -R>>testresult01.log
timeout 3 > nul
)
)

В результате были получены следующие сырые данные: <файл testresult01.log>

Offtopic: команда ECHO %date% %time% была включена в скрипт чтобы примерно отслеживать время выполнения тестов. Команда прекрасно работала из командной строки, в скрипте же выдавала почему-то один и тот же результат. Разбираться не стал. В следующем скрипте заменил

ECHO %date% %time%>>testresult01.log

на

date /t>>testresult02.log
time /t>>testresult02.log

Быстрый парсинг сырого лога в табличку Excel дал вот такие результаты:

Налицо два явления: плавный рост пропускной способности до 8 потоков, а затем снижение и почти стабилизация. И различие скорости передачи в зависимости от направления. Последнее заинтересовало, и для проверки был проведен аналогичный замер, при котором ВМ «поменяли ролями»: TEST1 стала сервером, скрипт же выполнялся на TEST2. Результаты этого теста были аналогичными, для сокращения объема статьи их не привожу, но и объяснения им, кроме как «это особенность работы iperf в данной среде» на этот момент не было.

Часть 2. Оптимизация.

Нет ничего, что человек, а в особенности – админ среды виртуализации, не мог бы сделать лучше. Наверное. 20 гигабит в секунду на 8 TCP-потоках на дефолтных настройках были неплохим результатом, но я попытался его улучшить. Кто же знал, что все будет совсем не так просто, как предполагалось…

Включаем JUMBO FRAME.

Первое, что пришло на ум: пропускную способность можно повысить, включив Jumbo packet, т.е. увеличив MTU сетевого адаптера до 9000. В реальности, чтобы это работало, нужно, разумеется, чтобы все коммутаторы и маршрутизаторы между хостами также поддерживали MTU 9000. Поэтому включаем Jumbo frame в нашем виртуальном коммутаторе:

И смело лезем на обоих ВМ в настройки сетевого адаптера и делаем так:

Кстати, эту же настройку можно делать через PowerShell командой

Set-NetAdapterAdvancedProperty Ethernet0 -DisplayName "Jumbo Packet" -DisplayValue “Jumbo 9000”

А смотреть все настройки адаптера командой

Get-NetAdapterAdvancedProperty:

Запускаем немного подправленный скрипт:

set logfile=testresult02.log
FOR /L %%i IN (1,1,16) DO (
FOR %%j IN (1,2,3) DO (
date /t>>%logfile%
time /t>>%logfile%
iperf3.exe -c 10.10.1.10 -t25 -O5 -P%%i>>%logfile%
timeout 3 > nul
)
FOR %%j IN (1,2,3) DO (
date /t>>%logfile%
time /t>>%logfile%
iperf3.exe -c 10.10.1.10 -t25 -O5 -P%%i -R>>%logfile%
timeout 3 > nul
)
)

и идем пить чай с печеньками, ибо молотить он будет, по данным предыдущего замера, около часа. И действительно: <файл testresult02.log>

Парсим:

Для удобства сравнения накладываем график MTU 9000 на ранее полученный с MTU 1500:

Поведение графика «Туда» логично и немного предсказуемо. Но вот «Обратно» преподносит сюрприз. Особенно если сравнить значения второго «реверсного» замера с первым и третьим при TCP от 9 (выделено в таблице выше серым и зеленым): второй замер с опцией –R показывает шикарный результат 27 гигабит в секунду, но предыдущий и следующий замеры явно лажают. Это «ж-ж-ж» случилось явно неспроста, повторный тест с «обменом ролями», когда TEST1 стал сервером, а ТЕСТ2 – клиентом, это подтвердил: <файл testresult02-1.log>

27 гигабит в секунду по сравнению с дефолтными 20-ю – неплохой, но нестабильный результат, поэтому было принято решение найти, «кто же там жужжит».

Часть 3. Поиск «ж-ж-ж».

Далее последовали: курение файн и факинг мануалов, множество тестовых запусков, тяжелые раздумья, снова курение мануалов и далее по кругу. Тест упорно показывал то 27 гигабит, то не поднимался выше 20. Единственным моим предположением, объясняющим происходящее, стало следующее: 20 с гаком гигабит в секунду – трафик, на обработку которого в виртуальном коммутаторе хост обязан потратить ощутимое количество процессорного времени. В случае, если это процессорное время шедулер распределяет «условно оптимально» и не пересекает с нагрузкой от ВМ – мы имеем тест со скоростью 27 гигабит. Если же «ошибается» – ВМ конфликтует за ядро pCPU с обработчиком виртуального коммутатора, и скорость теста падает.

Для косвенного подтверждения этого предположения я выставил обеим ВМ Scheduling Affinity на «четные» pCPU:

Offtopic: тут я несколько раз вводил «8,10,12,14» , но после нажатия Save и повторно Edit веб клиент упорно показывает «10,12,14,8». Ну да и бог с ним, вроде работает правильно.

Тест стал проходить намного стабильнее, esxtop показал косвенное подтверждение моего предположения:

Т.к. на хосте запущены только две мои тестовые ВМ, и для них обеих прописано Scheduling Affinity на pCPU, соответствующие физическим ядрам без гипертрейдинга – эти, в красной рамочке, периодически «прыгающие» между «нечетными» (гипертрейдинговыми) pCPU 50-70 процентов нагрузки и есть, по всей видимости, процессорное время, требуемое хосту для обработки трафика внутри виртуального коммутатора.

ВМ с Affinity – не лучшее решение, но другого я пока не нашел. Копал в сторону «можно ли выделить отдельный pCPU для работы процесса виртуального коммутатора» – не преуспел. Зато в результате мы имеем стабильно проходящий тест iperf между двумя виртуальными машинами: <файл testresult04.log >

Итого – имеем скорость «без какой-то копеечки» 30 гигабит в секунду.
При этом настройки адаптера в обеих ВМ выглядят так:

Единственное отличие в этой картинке от аналогичной, приведенной ранее:

Set-NetAdapterAdvancedProperty Ethernet0 -DisplayName ”Enable adaptive rx ring sizing” -DisplayValue “Disabled”

С «Enabled» или пустым полем производительность теста была ниже.По аналогии с «Включаем JUMBO FRAME» планировалось также «Включаем Receive Side Scaling», и «Настраиваем размеры буферов приема и буферов передачи», и даже «Меняем количество vCPU», однако реальность оказалась суровее. Перепробована куча вариантов настроек и ВМ, и сетевого адаптера. Описывать каждую нет смысла, т.к. результат теста они не улучшали. Поэтому за кадром остались некоторые очевидные и не совсем вещи, о которых имеет смысл сказать:

• Уменьшение количества vCPU в тестовых ВМ ведет к уменьшению значений в тестах. Увеличение – тоже. Возможно, на хосте с большим количеством ядер в процессоре будет иначе. Хотя я в этом сомневаюсь – ни в одном тесте ни один из процессоров внутри ВМ не показал полку в 100%.
• Включение Receive Side Scaling (RSS) в настройках сетевого адаптера в отсутствии собственно физического адаптера, этот RSS реализующий, ведет к падению пропускной способности теста. А еще там есть хитрый параметр RSS Base Processor Number, логику работы которого удалось постичь не сразу: https://docs.microsoft.com/ru-ru/windows-hardware/drivers/network/setting-the-number-of-rss-processors

Выводы:

Паравиртуальный адаптер VMXNET3 – это жутко близко и запредельно быстро.

Планы: Попробовать то же самое с Linux-based оерационной системой. Например, с активно применяемой мной в жизни RouterOS Cloud Hoster Router. Вооруженный новыми знаниями я попробую штурмануть рубеж в 40 гигабит в секунду между ВМ.

P.S. А вот тут архив с результатами работы скрипта testresult0#.log.

Тестирование производительности VMXNet3. Часть 2: RouterOS Cloud Hosted Router

Как быстро идентифицировать проблему, связанную с производительностью процессора, какие метрики в этом случае будут наиболее информативными? На эти и многие другие вопросы, имеющие отношение к производительности CPU в виртуальном окружении vSphere, ответим в этой статье.

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

Самые распространенные проблемы производительности CPU

# Ready Time – процессор находится в состоянии готовности, когда виртуальная машина готова к старту, однако не может быть запущена в силу недостаточности ресурсов физического хоста. Показатель Ready Time считается нормальным, когда его значение не превышает 10 %. Если же наблюдается рост этого показателя, повышается вероятность сбоев и зависания гостевой операционной системы. Однако менее чувствительные к показателям CPU приложения и виртуальные машины могут продолжать корректно функционировать и при значении Ready Time выше 10 %.

# High Co–stoptime – показатель Co-stoptime указывает на наличие большего количества vCPU, чем необходимо. А это зачастую вызывает дополнительное расходование ресурсов, уменьшая производительность виртуальной машины. В подобной ситуации при снижении количества vCPU ВМ сможет работать значительно лучше.

# CPU Limits – указывает на установленные процессорные лимиты, запрещающие виртуальной машине превышать пороговые значения. Такое ограничение, в случае если виртуальной машине требуется большее количество ресурсов, становится причиной проблем с производительностью.

# Host CPU Saturation – используется для проверки загрузки процессора хоста. Если средняя загрузка составляет более 75 % или пиковая – более 90 %, то наблюдается нехватка ресурсов CPU узла vSphere, что чревато проблемами запуска имеющихся виртуальных машин.

# Guest CPU Saturation – указывает на загрузку процессора виртуальной машины. Если приложение виртуальной машины использует 90 % и более ресурсов CPU, то наблюдается проблема с производительностью. В этом случае vCPU становится «узким горлышком». Добавление дополнительного vCPU может улучшить производительность виртуальной машины, если приложение умеет распараллеливать нагрузку.

# Low Guest Usage – может указывать на некорректную конфигурацию приложения или недостаточность других ресурсов (будь то оперативная память или жесткий диск) и, следовательно, выделенные ресурсы vCPU не смогут использоваться в полной мере.

Скрипт как средство имитации загрузки CPU: изучаем особенности

Для имитации загрузки CPU в тестовой среде воспользуемся скриптом и понаблюдаем за поведением виртуальной машины. Для начала необходимо запустить VMware vSphere Power CLI, после чего станет доступным окно командной строки, в котором и запускается скрипт Start CPU Test.

За неимением этого скрипта можете взять пару виртуальных машин и запустить в них какое-нибудь стрессовое приложение, например, 7z в режиме тестирования производительности.

Плюсом данного скрипта является то, что он отображает некоторое количество “попугаев”, выжимаемых ВМ.

Переключаемся в окно vSphere, переходим в закладку мониторинга производительности машины PERF-WORKER-01A. Поскольку интересны расширенные параметры, необходимо выбрать опцию Advanced –> Chart Options.

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

При расследовании проблем производительности CPU стоит обратить внимание на следующие счетчики:

• Demand – количество CPU виртуальной машины, необходимых (требуемых) для использования.
• Ready – показатель времени, в течение которого виртуальная машина готова запуститься, но не может в силу недостаточности физически ресурсов.
• Usage – количество CPU виртуальной машины, фактически разрешенных для использования в текущий момент.

Для выбора Demand, Ready, Usage и других счетчиков необходимо перейти в раздел метрик CPU и указать необходимые элементы, после чего нажать кнопку ОК.

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

• Wait (VMWAIT) – такое состояние фиксируется, когда гостевая ОС виртуальной машины находится в состоянии простоя или ожидается выполнение задач на уровне vSphere. К примеру, vCPU может перейти в режим Wait в случае, если ожидается завершение операций ввода-вывода или выполнение «свопирования» на уровне ESX. Иными словами, такой счетчик отображает процент времени, который виртуальная машина потратила на ожидание, пока ядро ESX выполняло какие-либо операции.

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

• Co–Stop (CSTP): этот статус соотносится со временем, когда виртуальная машина готова исполнять команды, но вынуждена ждать высвобождения других vCPU для возможности их одновременного использования.

• Run (исполнение): показывает, что виртуальная машина «исполняется» в системе.

Исходя из рассмотренных статусов и счетчиков, нелишним будет ознакомиться с одной важной формулой. Она верна для отдельно взятой VM, которая либо простаивает и находится в ожидании (%WAIT), либо готова исполнять команды, но CPU занят (%RDY), либо ожидает высвобождения нескольких процессоров (%CSTP), либо исполняется в системе (%RUN).

Для одного vCPU справедливо следующее уравнение.

Сравнение показателей Demand и Usage

Обратите внимание на то, сколько ресурсов CPU требуется для работы виртуальной машины и сколько в действительности используется. Как видно на рисунке, требуется (demand) значительно больше, чем используется (use). Также обратите внимание на показатель Ready Time, равный 9977 ms. Как вы помните, если это значение будет больше 10% или 1000ms, вероятна проблема с производительностью. Для перевода значения из миллисекунд в проценты можно воспользоваться следующей формулой:

Заметка: поскольку некоторые показатели в отчетах vCenter отображаются в миллисекундах, приведенную формулу можно использовать для перевода значений в проценты. Эта формула справедлива для 1vCPU. Если vCPU несколько, то пороговое значение необходимо умножить на количество vCPU. К примеру, для 4vCPU пороговым значением является 40% CPU Ready или 4000ms.

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

Статистика CPU на уровне хоста

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

Здесь можно отслеживать статистику по CPU на уровне хоста ESX.

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

Примечание: данная ситуация совершенно нетипична, далее вы увидите почему!

Редактирование параметров виртуальной машины

А давайте что-нибудь изменим в настройках ВМ. Для этого выделим нашу ВМ VMPERF-WORKER-01A, выберем Actions, а затем Edit Settings, как указано на рисунке.

Выполним проверку параметров CPU affinity на машине PERF-WORKER-01A.

Как видно на рисунке, значение Scheduling affinity равно единице. Это означает, что vCPU этой ВМ работает только на ядре №1. Чтобы сбалансировать виртуальные машины на использование всех физических процессоров в системе, необходимо очистить установленное значение «1» и нажать ОК. Аналогичное действие выполняем и на второй виртуальной машине (PERF-WORKER-01B).

Заметка: в большинстве случаев VMware не рекомендует использовать установленные вручную значения Scheduling affinity. vSphere способна выполнять оптимальную балансировку VM в контексте физических процессорных ресурсов. Кроме того, использование значений «affinity», выставленных вручную, не даст использовать vMotion, а также может вызвать сложности в управлении и проблемы с производительностью.

На прощанье прорекламирую продолжение этой статьи.

Так как актуальность документ все еще не потерял, я попробую осуществить его перевод…

В начале документа находится схема траблшутинга

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

Базовая.

Возможные проблемы упорядочены по принадлежности (с VMware Tools, CPU, etc) и по их влиянию (от 100% влияния на производительность до возможного).

Проверка VMware Tools.

• Выберите хост в vClient;
• Перейдите на вкладку Virtual Machines;
• Добавьте столбец “VMware Tools Status”;
• Оцените статус. OK->возвращаемся к диаграмме траблшутинга.  Not Running/Out of date – устраняем.

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

Если VMware Tools устарели, необходимо их обновить из контекстного меню vClient. Как правило, это случается после установки обновлений на хосты ESX/ESXi. После этого зачастую требуется обновить и VMware Tools.

Проверка загрузки процессора в пуле ресурсов (Resource Pool CPU Saturation).

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

• Выберите пул ресурсов и перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “CPU”;
• Оцените текущую загрузку в MHz (Usage);
• Сравните значение лимита пула ресурсов и текущую загрузку. Если текущая загрузка близка к лимиту, возможно, имеет место нехватка процессорных ресурсов и вам необходимо оценить значение CPU Ready отдельных виртуальных машин в этом пуле;

Проверка CPU Ready:

• Для измерения CPU Ready выберите одну из виртуальных машин (далее ВМ) в пуле, перейдите на вкладку Performance, выберите режим “Advanced” и переключитесь в обзор “CPU” (если вы решаете проблему производительности определенной ВМ, начните с нее);
• Оцените значение Ready для всех “объектов” ВМ. Отдельным “объектом” является каждый виртуальный процессор ВМ. Вам будет необходимо изменить свойства графика “Chart Options…” для отображения этого графика;
• Среднее или максимальное значение Ready для любого виртуального процессора превышает 2000мс? Если да, то у вас наблюдается нехватка процессорных ресурсов из-за установленного лимита на пул ресурсов;
• Повторите для всех ВМ этого пула.

На следующем рисунке проиллюстрирован этот пример

Проверка загрузки процессора хоста (Host CPU Saturation).

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “CPU”;
• Оцените текущую загрузку в MHz (Usage);
• Превышает ли средняя загрузка 75% или пиковая – 90%? Если да, возможно, вам не хватает процессорных ресурсов хоста. Проверьте CPU Ready у ВМ этого хоста как показано ниже. Если средняя загрузка ЦП не превышает 75%, перейдите к следующему блоку…

Проверка CPU Ready:

• Если вы решаете проблему производительности определенной ВМ, начните с нее. В противном случае выберите хост, перейдите на вкладку Virtual Machines, отсортируйте список по столбцу Host CPU – MHz и проверьте одну-две ВМ из начала списка;
• Для измерения CPU Ready выберите ВМ, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “CPU” (если вы решаете проблему производительности определенной ВМ, начните с нее);
• Оцените значение Ready для всех “объектов” виртуальной машины. Отдельным “объектом” является каждый виртуальный процессор ВМ. Вам будет необходимо изменить свойства графика “Chart Options…” для отображения этого графика;
• Среднее или максимальное значение Ready для любого виртуального процессора превышает 2000мс? Если да, то у вас наблюдается нехватка процессорных ресурсов хоста.

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

Загрузка процессора ВМ (Guest CPU Saturation).

• Выберите ВМ с проблемами по производительности, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “CPU”;
• Оцените уровень загрузки ЦП ВМ;
• Превышает ли средняя загрузка 75% или пиковая – 90%? Если да, возможно, вам не хватает процессорных ресурсов.

Проверка ВМ на активное использование свопа (Active VM Memory Swapping).

Нехватка памяти хоста или пула ресурсов может повлечь за собой активное использование технологии Host Swap. А это в свою очередь резко снизит производительность как одной ВМ, так и нескольких “соседних”.

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”. Необходимо будет добавить счетчики “Swap in rate” и “Swap out rate”.
• Оцените показатели “Swap in rate” и “Swap out rate”;
• Если значения счетчиков больше нуля, то у хоста имеются проблемы с памятью.

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

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Измените свойства графика (Chart Options…);
• Выберите Memory/Real-Time, смените тип графика на Stacked Graph (per VM). Выберите все ВМ и счетчики “Swap in rate” и “Swap out rate” для них;
• Если значения счетчиков больше нуля, имеются проблемы с памятью.

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

Проверка ВМ на использование свопа в прошлом (VM Swap Wait).

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

• Выберите ВМ с проблемами по производительности, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “CPU”;
• Оцените значение Swap Wait для ВМ. Его будет необходимо добавить в свойствах графика;
• Содержит ли последний столбец ненулевое значение (столбец average)? Если да, тормоза ВМ из-за свопа. Самое простое решение – перезагрузка ВМ. Если нет – возвращаемся к базовой диаграмме.

Проверка ВМ на “заархивированность” памяти (VM Memory Compression).

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Оцените счетчики “Compression rate” и “Decompression rate”. Да, их придется добавить ;
• Принимали ли эти счетчики значения выше 0? Если да, на хосте имелись проблемы с нехваткой памяти (да и сейчас, быть может, имеются). Если нет, возвращаемся к базовой диаграмме;

Также можно проверить “заархивированность” памяти у ВМ:

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Измените свойства графика (Chart Options…);
• Выберите Memory/Real-Time, смените тип графика на Stacked Graph (per VM). Выберите все ВМ и счетчики “Compression rate” и “Decompression rate” для них;
• Ненулевые значения будут свидетельствовать о нехватке памяти.

Примечание: если ВМ находится в пуле ресурсов DRS-кластера, следует оценить также загрузку остальных хостов.

Проверка перегруженности СХД (Overloaded Storage Device).

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Disk”;
• Добавьте на график счетчик “Commands aborted”;
• Если значение счетчика отлично от нуля, у вас проблемы на стороне СХД. В противном случае ищем дальше.

Проверка на отброс принимаемых пакетов (Dropped Receive Packets).

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Network”;
• Выберите счетчик Receive Packets Dropped для всех адаптеров vmnic*;
• Значение больше нуля? Если да, отправляйтесь решать сетевые проблемы. Нет, продолжаем искать причину тормозов.

Проверка на отброс отправляемых пакетов (Dropped Transmit Packets).

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Network”;
• Выберите счетчик Transmit Packets Dropped для всех адаптеров vmnic*;
• Значение больше нуля? Если да, отправляйтесь решать сетевые проблемы. Нет, продолжаем искать причину тормозов.

На этом “ясные” причины заканчиваются и начинаются нюансы…

Проверка, что во многопроцессорной ВМ используется только один vCPU (one vCPU in an SMP VM).

Если у ВМ несколько виртуальных процессоров (vCPU), возможно, гостевая ОС некорректно настроена и не использует все vCPU.

• Выберите ВМ, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “CPU”;
• Оцените загрузку в MHz (Usage MHz) для всех vCPU;
• Загрузка для одного vCPU большая, для остальных – близка к нулю? Да, ваша ВМ использует только один vCPU, смотрите раздел решения проблем с ЦП. Нет – продолжаем поиски.

Проверка CPU Ready у ВМ на средне-нагруженном хосте.

Если на ВМ нагрузка появляется всплесками, то даже с невысокой средней загрузкой ЦП хоста ВМ может испытывать проблемы производительности.

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “CPU”;
• Счетчик Usage достаточно большой, но не превышает 95%?
• Выберите проблемную ВМ, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “CPU”;
• Включите отображение счетчика Ready для всех vCPU;
• Есть ли промежутки времени, когда Ready для любого процессора больше 1000ms? Если есть – идем и решаем проблемы с ЦП. Нет – ищем причины дальше.

Если на хосте есть другие ВМ, потенциально испытывающие проблемы – проверьте CPU Ready и у них.

Проверка медленного или перегруженного СХД.

Проверим наличие задержек на СХД:

• Выберите проблемную ВМ, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “Virtual Disk”;
• Выберите отображение всех дисков и счетчиков “Read Latency”/”Write Latency”;
• Превышают ли задержки 50ms? Если да, определенные проблемы есть, идем проверять очереди.

Проверка задержки очередей:

• Выберите хост с проблемной ВМ, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Disk”;
• Включите отображение счетчика “Queue Command Latency” для всех хранилищ;
• Превышает ли величина задержки 0ms? Если превышает, то вам необходимо увеличить максимальную глубину очереди устройства, после чего измерить задержки физического устройства.

Измерение задержек физического устройства:

• Выберите хост с проблемной ВМ, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Disk”;
• Выберите счетчики “Physical Device Read Latency” и “Physical Device Write Latency” для всех хранилищ;
• Превышает ли величина задержек 50ms? Если да, мы имеем дело с перегруженным по вводу/выводу СХД. Идите в набор решений для СХД (ниже в документе).

Примечание: 50ms – это верхняя граница, когда все может функционировать. Возможно, в вашем случае это будет 30ms или даже 20ms!

Проверка пиковых нагрузок на СХД.

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Disk”;
• Выберите счетчики “Physical Device Read Latency” и “Physical Device Write Latency” для всех хранилищ;
• Имеются ли на графике пики, превышающие 20ms, даже если среднее значение ниже 10ms? Если да, мы имеем дело с перегруженным по вводу/выводу СХД

Проверка наличия пиков в передаче данных на сеть.

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Network”;
• Оцените “Data Transmit Rate” и “Data Receive Rate”;
• Есть ли периоды, когда пиковая нагрузка превышает 90% на какой-то адаптер? Если да, у вас могут быть проблемы из-за сети, смотрите набор решений под сеть. Если нет, идите и решайте проблему далее.

Проверка низкой загрузки процессора ВМ.

Если загрузка процессора ВМ низкая, но ВМ тормозит, могут быть некоторые проблемы с конфигурацией.

• Выберите проблемную ВМ, перейдите на вкладку Performance, выберите режим Advanced и переключитесь в обзор “CPU”;
• Оцените величину счетчика “Usage”;
• Среднее значение ниже 75%? Возможно, есть некоторые проблемы, которые необходимо “порешать”. Идем в раздел решения проблем с ЦП. Если тормоза затрагивают весь хост, повторяем процедуру с остальными ВМ с хоста.

Проверка того, что память ВМ в прошлом была помещена в своп (Past VM Memory Swapping).

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Добавьте счетчик “Swap Used”;
• Значение счетчика больше нуля? Если да, хост в прошлом активно использовал своп. Читайте решение проблем с памятью. Для определения проблемной ВМ (которая “ушла” в своп) читайте дальше.
• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Выберите тип графика “Stacked Graph (Per VM)” и добавьте счетчик “Swap Used”;
• ВМ, у которых это значение ненулевое, могут испытывать из-за этого проблемы с производительностью.

Проверка нехватки памяти в пуле ресурсов.

Проверяем использование ballooning:

• Выберите пул ресурсов, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Оцените счетчик “Ballooning”;
• Значение больше нуля? Возможно, в пуле ресурсов сильная конкуренция за память. Оцените “Balooning” отдельных ВМ.
• Выберите хост, являющийся частью DRS-кластера, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• В свойствах графика выберите типа графика “Stacked Graph (Per VM)”. Добавьте счетчик “Balloon”;
• Оцените значение счетчика для ВМ, являющихся частью пула. Больше ли оно нуля? Если да, то нехватка памяти вызывает своп в гостевой ОС. Читайте раздел по устранению проблем с ОЗУ. Если нет – повторите операцию с остальными хостами DRS-кластера. Если и там так же – ищем причины дальше.

Проверка нехватки памяти на хосте.

• Выберите хост, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Оцените счетчик “Ballooning”;
• Значение больше нуля? Возможно, в пуле ресурсов сильная конкуренция за память. Оцените “Balooning” отдельных ВМ.
• В свойствах графика выберите типа графика “Stacked Graph (Per VM)”. Добавьте счетчик “Balloon”;
• Оцените значение счетчика для ВМ. Больше ли оно нуля? Если да, то нехватка памяти вызывает своп в гостевой ОС. Читайте раздел по устранению проблем с ОЗУ.

Нехватка памяти для гостевой ОС (High Guest Memory Demand).

• Выберите ВМ, перейдите на вкладку Performance, там переключитесь в режим “Advanced” и выберите объект “Memory”;
• Добавьте счетчик “Usage” и оцените его значение;
• Среднее значение превышает 80%, а пики – 90%? Скорее всего, ВМ не хватает оперативной памяти. Отправляйтесь в раздел устранения проблем с памятью.

Продвинутая диаграмма

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

Проверка наличия проблем с прерываниями (High Timer-Interrupt Rates).

• Запускаем esxtop/resxtop;
• Выбираем экран ЦП, нажав “c”;
• Добавляем “Summary Stats”, нажав “f” и затем “i”. Нажмите любую клавишу для возвращения в основной экран esxtop;
• Оцените счетчик “Times/S”;
• Он больше 1000 для любой ВМ? Если да, необходимо снизить количество прерываний, прочитав соответствующие рекомендации.

Проверяем наличие косяков с NUMA.

• Запускаем esxtop/resxtop;
• Выбираем экран ОЗУ, нажав “m”;
• Добавим “Numa Stats”, нажав “f” и затем “g”. Нажмите любую клавишу для возвращения в основной экран esxtop;
• Оцените счетчик “N%L” для всех ВМ. Если столбец не видно на экране, необходимо нажать “o” и несколько раз “G”, для передвижения счетчиков “NUMA” поближе к началу;
• Если “N%L” меньше 80% для какой-то ВМ, то ВМ имеет косяки с точки зрения Numa-архитектуры. Проследуйте в раздел решения проблем с Numa.

Проверка большого времени отклика у ВМ со снапшотами.

• Запускаем esxtop/resxtop;
• Выбираем экран виртуальных дисков, нажав “v”;
• Если не отображаются задержки, включим их отображение, нажав “f”, а затем “g” и “h”. Нажмите любую кнопку, чтобы вернуться в основной экран esxtop;
• Оцените значения “LAT/rd” и “LAT/wr” для ВМ со снапшотами. Данные значения отражают средние величины задержек при операциях ввода-вывода;
• Перейдите на экран с дисковыми устройствами, нажав “u”;
• Если задержки не отображаются по умолчанию, добавьте требуемые поля, нажав “f”, а затем “j” и “k”. Нажмите любую кнопку, чтобы вернуться в основной экран esxtop;
• Оцените значения “QUED”, “DAVG/rd” и “DAVG/wr”. “QUED” показывает текущее значение дисковой очереди на LUN. DAVG/* – среднее время отклика устройства;
• Значение очереди равно нулю? Задержки на экране “виртуального диска” значительно превышают задержки физического LUN? Если да, то проблема в снапшотах ВМ.

To be continued…

Рекомендации по решению проблем ждите в следующей статье/переводе.

С выпуском P6000 Command View ситуация изменилась коренным образом: появился продукт HP P6000 Performance Advisor, который может не только отображать исторические данные, но и давать определенные советы. Причем, он еще и интегрирован с P6000 Command View. Впрочем, как и за все хорошее в этом мире, за него тоже нужно платить. Причем лицензируется он по массивам, и стоит недетских денег. Для тех, кто хочет и рыбку съесть, и в воду не лезть, есть небольшое продолжение…

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

1. Использование какой-либо системы мониторинга, которая будет собирать статистику с счетчика Windows;
2. Ручная выгрузка данных с помощью Counter Logs в SQL, с дальнейшей отрисовкой их в SQL Reporting Services.

Изначально я хотел идти по второму пути, чтобы опубликовать How-To по дальнейшей настройке SQL Reporting Services. Но “обрушившийся на мои плечи” SCOM изменил расстановку сил. Так что не судьба

P.S. Собственно, основная сложность с Reporting Services как раз и состоит в том, чтобы нарисовать человеческий GUI для визуализации данных из таблицы. А именно “что”, “за какой период” и в каком составе рисовать.

UPD: Наблюдалась странная картина: SCOM переставал собирать данные о производительности после пары часов работы. При этом в логах сервера регистрировалось следующее сообщение:

“Windows cannot load extensible counter DLL EVAPMEXT, the first DWORD in data section is the Windows error code.”

Немного поразмыслив, я решил выгрузить счетчики Евы и загрузить их обратно. Поиск по серверу показал, что evapmext.ini находится не только в каталоге c:\windows\inf, но и в C:\Program Files\Hewlett-Packard.

Я выгрузил данный файл из счетчиков с помощью команды Unlodctr, проверил, что счетчики испарились, и попытался обратно загрузить счетчики из этого файла в каталоге Windows.

Облом’с: ”

Installing the performance counter strings for service c:\windows\inf\009\evapmext\evapmext.ini (c:\windows\inf\009\evapmext\evapmext.ini) failed. The Error code is the first DWORD in Data section.”

А вот счетчики из каталога HP успешно загрузились. Что сказать: пять дней – полет нормальный

CPU Ready – это метрика, показывающая сколько времени процесс стоял в ожидании процессорного времени.

Имеются следующие предпосылки к высокому CPU Ready:

1) Переиспользование (Oversubscription) процессора. То есть соотношение количества физических процессоров (PCPU или “ядер”) к количеству виртуальных процессоров (VCPU – процессоров виртуальных машин). Согласно vSphere 5 Configuration Maximums на одно ядро можно впихнуть до 25 виртуальных процессоров. Чудес не бывает – эти процессоры должны быть должным образом ненагружены, чтобы такой фокус удался. VMKernel предлагает следующие варианты:

– от 1:1 до 1:3 – все ок;

– от 1:3 до 1:5 – могут быть проблемы из-за конкуренции за ресурсы;

– от 1:5 – скорее всего будут проблемы.

Тут же стоит помнить о Hyper-Threading: эта технология удваивает количество PCPU, но полноценно выполняться код может только на одном из пары.

Ситуацию с задержкой из-за HT можно увидеть в ESXTOP/RESXTOP. После запуска нажимаете “F” и добавляете поля “I:  SUMMARY STATS = CPU Summary Stats”. Параметр “%LAT_C” как раз и отвечает за задержки по вине процессора. Обратите внимание еще и на параметр “%LAT_M” – он отвечает за задержки по вине оперативной памяти (например, свопа).

2) Использование лимита процессорного ресурса

Хотя это не рекомендуется, вы можете задать ограничение на количество используемых ресурсов (процессора или памяти) для ВМ или пула ресурсов. В этом случае метрика %RDY будет ненулевой. Данную ситуацию легко можно увидеть, так как в этом случае также ненулевой будет метрика %MLMTD (также включенная в %RDY). То есть для понимания “чистого” CPU Ready вам необходимо из %RDY вычесть %MLMTD.

3) Привязка vCPU к PCPU.

Для определенной виртуальной машины вы можете задать CPU Affinity – список физических процессоров, на которых виртуальная машина может выполняться. В этом случае scheduler не сможет раскидать нагрузку по разным процессорам, и ВМ могут недополучать процессорное время, хотя есть свободные процессоры. Практический смысл тут один – если вы не хотите лицензировать N процессоров физического сервера (например для SQL), задаете подобное соответствие. Вроде бы в этом случае можно купить столько лицензий, на скольки процессорах может работать ВМ.

Ну и подводный камень – vMotion то ли не работает, то ли сбрасывает эту настройку.

4) Использование Fault Tolerance

Если при использовании FT ресурсов хостов не хватает для обеспечения реплики, то машина источник начинает притормаживать. При этом также будет увеличен счетчик %MLMTD.

Основные заблуждения относительно производительности CPU

1) Дополнительный PCPU, получающийся засчет HyperThreading, не дает такой же производительности, как дополнительное ядро. То есть, ваши гигагерцы, указанные в vClient, становятся нечестными. В документе приводится цифра в 75%, на мой взгляд она достаточно оптимистичная. При проектировании это надо учитывать.

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

3) Прямой зависимости между vCPU Usage и CPU Ready нет. Правильнее сказать – оно зависит от…

4) DRS не помогает решать вопросы с CPU Ready. Он всего лишь оценивает загрузку ЦПУ хоста для принятия решения о миграции.

Сколько CPU Ready считать нормальным?

Авторы статьи считают 5% на один vCPU. Duncan Epping считает – 10%.

В ESXTOP этот параметр так и отображается, в vClient он меряется в миллисекундах и вам необходимо провести несложные вычисления.

Например, у вас есть двухпроцессорная машина, CPU Ready которой составляет 5000ms. Так как период сбора статистики составляет 20 секунд, нам необходимо разделить измеренное значение на 20000. И для подсчета “CPU Ready per processor” поделить также на количество процессоров.

%RDY=5000/20000/2 = 12.5%

Также можно почитать VMGU.RU, Yellow Bricks и VMware Community.

• После перезапуска сервера журнал (counter log) приходилось запускать вручную;
• Надо было как-то загружать данные в SQL.

Подпоясавшись IE9, отправился я в путь…

1) Перезапуск журнала осуществляется следующим образом:

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

2) Оказывается, журналы производительности можно сохранять напрямую в SQL, минуя сложный путь импорта данных из CSV (посыпаю голову пеплом и торжественно разрываю сертификат MCSA 2003).

Нажав кнопку Configure, попадаем в следующее окно:

Log Set – название журнала счетчиков, тут вполне можно написать “Exchange Server”, если вы хотите собирать данные с нескольких серверов.

Что особенно удобно, можно тут же указать срок хранения данных (Logset size). К сожалению, его придется вычислять вручную по указанному вами периоду, но это легко проделывается в калькуляторе.

Нажав несколько раз OK, вы начнете сохранять ваши журналы производительности в SQL.

Что такое e1000?

e1000 – это эмулируемый сетевой гигабитный контролер Intel 82545EM. Большинство операционных систем имееют встроенный драйвер, но, к сожалению, качество драйвера не ахти какое. По этой причине на замену ему Intel выпустила e1000e aka 82574L.

Что такое e1000e?

e1000e – это сетевой гигабитный контролер Intel 82574L. В vSphere 5 (HW8) VMware  предлагает эмулируемую версию  e1000e. Windows 7 и Windows 2008 имеют встроенные драйвера для  82574L.

82574L крут, но быстрее ли он, чем VMXNET3?

Что такое VMXNET3?

VMXNET3 – паравиртуализированный сетевой адаптер, спроектированный с расчетом на максимальную производительность. VMXNET3 представляет собой 10Gb виртуальную сетевую карту. Драйвера идут в составе VMware tools и имеют широкую поддержку ОС. VMXNET3 гораздо производительней e1000 и e1000e, требует меньше процессорных ресурсов по сравнению с e1000 и e1000e. Наконец, VMXNET3 более стабилен, чем e1000 и e1000e.

Вы все еще кипятите используете e1000/e1000e? Тогда мы идем к вам 

P.S. от A.Vakhitov. Не забывайте про проблему с остатками сетевого адаптера VMXNET3 при развертывании шаблона или клонировании ВМ. Каюсь, у меня раздобыть и протестировать нужные апдейты не получилось!

Однако же, гайд по EVA говорит, что выход есть

Параметр fnh отвечает за вывод “подключенных серверов с Command View”.

C:\Program Files\Hewlett-Packard\EVA Performance Monitor>evaperf fnh
Verifying access ...
Host Username Accessible
---- -------- ----------

Использовав параметр fnh, укажем параметры [host] и [username] для подключения к Command View EvaPerf и добавления его в список серверов.

C:\Program Files\Hewlett-Packard\EVA Performance Monitor>evaperf fnh localhost Administrator
password:
Verifying access ...
Ключ fn отвечает за генерацию файла fnames.conf, сопоставляющего идентификатор и короткое имя.

C:\Program Files\Hewlett-Packard\EVA Performance Monitor>evaperf fn
Attempting to load names from host: localhost

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

Evaperf не умеет сам накапливать статистику, чтобы посмотреть, что было позавчера. Соответственно, есть следующие варианты:

• запуск Evaperf с ключом, указывающим что мониторить (например, as – показатель IOPS / MBs на массив);
• Сбор статистики через Counter logs.

Рекомендую второй вариант по следующим причинам:

1. Evaperf не может исключать поля из списка (вернее, может, в режиме фильтрации для объектов мониторинга. Счетчики исключать он не может). Соответственно, недельный мониторинг 30 vDisk’ов весит более 50 мегабайт в формате CSV, а 100 hdd – под 200 мегабайт;
2. Evaperf может собирать статистику либо с одного “направления”, например, общая по СХД, либо сборная солянка (СХД, порты, жесткие диски, виртуальные диски, диск-группы, DR-туннели и т.п.). Сказать ему “собирай только общую по СХД и по виртуальным дискам” можно, только если запустить два Evaperf’а.

Также статья доступна на ITband.ru.

Однозначно рекомендуется к прочтению!