Время выполнения команды в VMware vSphere PowerCLI

Для того, чтобы узнать время выполнения команды в VMware vSphere PowerCLI, необходимо заключить ее в Measure-Command -Expression {КОМАНДА}. Например:

Measure-Command -Expression {Move-VM -VM VM-CLI -Datastore Huawei-1} 

Таким образом можно узнать время миграции ВМ с одного стораджа на другой.

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

Еще один способ - это использование методов "StartExecutionTime" и "EndExecutionTime" уже после выполнения замеряемой команды 

$command = Get-History -Count 1  
$command.EndExecutionTime - $command.StartExecutionTime



Однако использование StartExecutionTime" и "EndExecutionTime" дает более грубые результаты. 

PowerCLI: включение SSH на хостах ESXi

Мою шпаргалку по использованию PowerCLI начну со статьи о SSH (включение, отключение, статус). 

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

VMware ESXi 6.0. Влияние балансировки NUMA на производительность. Часть 2.

Первую статью в новом 2018 году начну с продолжения рассмотрения NUMA.
В прошлой статье VMware ESXi 6.0. Влияние балансировки NUMA на производительность. Оптимальное число VPD я рассматривал тяжелые условия работы виртуальных машин. Одним из показателей "тяжелости" - это количество свободной памяти в NUMA узле. Проводя множество экспериментов, я пришел к выводу, что имеется своеобразный порог свободного объема на NUMA узле: 12-15 Гб. Причем этот порог не жесткий. Рассмотрим как этот порог возникает.

VMware ESXi 6.0. Влияние балансировки NUMA на производительность. Оптимальное число VPD.

На тему NUMA в vmware написано относительно много статей, где даны рекомендации по конфигурированию виртуальной машины. В основном они касаются настройки процессора и даны соответствующие рекомендации. Однако когда я приступил к практическим тестам то выяснил, что не все так однозначно. Даже если все сделано согласно рекомендациям, и у вас достаточно свободных ресурсов (CPU, память), то производительность wide vm (виртуальная машина, которая выходит за пределы узла NUMA) может проседать. Виной тому - балансировка NUMA. Вернее - память, несбалансированная между NUMA-узлами. Да и прочитанные рекомендации по "ядро-на-сокет" тоже оказались не универсальными.
Сразу оговорюсь - по сути это не такая большая проблема, поскольку просадка производительности наблюдается лишь для приложений, которые умеют задействовать многопоточность. А вот например Corona Renderer не зависит от балансировки NUMA. Более того, тест, сделанный программой Corona 1.3 Benchmark не зависел также и от конфигурации "ядро-на-сокет".
Данная статья написана для тех, кто знаком с технологией NUMA и знает правила конфигурования ВМ. Если кто-то не ориентируется в данной технологии, но ему все же интересны мои эксперименты с конфигурацией "двухпроцессорный сервер с 12 ядрами" то предварительно рекомендую прочитать соответствующие материалы, на некоторые приведены ссылки в низу моей статьи.
Итак, что пишет про балансировку сама VMware: The intelligent, adaptive NUMA scheduling and memory placement policies in ESXi can manage all virtual machines transparently, so that administrators don’t need to deal with the complexity of balancing virtual
machines between nodes by hand (Performance Best Practices for VMware vSphere® 6.0). Если по-русски, то: NUMA сама знает как балансировать виртуальные машины и размещать их память между узлами NUMA, вмешиваться не надо. На мой взгляд - нужно было добавить "в большинстве случаев".

Соображения при выделении памяти ВМ

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

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

В частности данные по оперативной памяти гипервизора ESXi следующие:

Параметры виртуальных машин	ESXi 5.5	ESXi 6.0	ESXi 6.5
Оперативной памяти (RAM) на хост	4 ТБ	12 ТБ	12 ТБ
RAM на ВМ	1 ТБ	4 ТБ	6 ТБ

Как изменялись другие параметры можно узнать в статье Изменение основных максимумов виртуальной инфраструктуры от VMware vSphere 5.5 до 6.5.

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

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

Стресс тест ESXi (потребление памяти виртуальными машинами)

Что мы делаем, когда обнаруживаем нехватку памяти на гипервизоре?

Ну, наверное думаем как решить проблему. Одновременно некоторые пытаются анализировать поведение гипервизора, т.е. как отрабатывают механизмы работы с памятью (Memory Ballooning, Memory Compression, Hypervisor Swapping). 

Но что делать если необходимо вдумчиво изучить как это все работает? Протестировать, скажете вы, и будете правы. Есть много программ для тестирования нагрузки CPU, диска. 

А вот для памяти выбор не так уж и велик.

Я использую утилиту TestLimit 

http://download.sysinternals.com/files/TestLimit.zip
Для большинства случаев необходима 64-версия.
Правда данная утилита не подходит для продолжительного тестирования, поскольку выделяемая ей память в долгосрочной перспективе отображается как "Consumed Host Memory". Т.е. это тот вид памяти, который выделен ВМ, но не используется.

Итак, как тестировать.

Запускаем командную строку, переходим в каталог с программой, вводим

testlimit64.exe

и видим ключи утилиты

Для того, чтобы выделить 1 Гб ОЗУ

testlimit64.exe -d 1024 -c 1

Для увеличения размера памяти каждые 10 секунд используем ключ -e 10

testlimit64.exe -d 1024 -e 10

Для выделения всей памяти

testlimit64.exe -d 

Однако в этом случае ВМ может зависнуть.

Microsoft Cluster Services Across Hypervisors (vmware+huawei)

В данной статье рассматривается режим работы Microsoft Cluster Services, при котором ВМ работают на гипервизорах разных вендоров.

Администрируя vSphere 5.5 я ни под какими предлогами не допускал в инфраструктуру Microsoft Cluster Services (MSCS). Поскольку развернув кластер MSCS прочувствовал на себе все ограничения данной технологии, после чего отказался от ее использования.
Виртуальные машины кластера MSCS  не мигрировали, висели на хосте, гордо заявляя: "Перезагрузка хоста ESXi только через наш труп!". Что сводило на нет многие плюсы виртуализации.

В vSphere 6 это ограничение было устранено - vMotion и MSCS подружились.
Что несомненно вдохнуло новую жизнь в использование технологии кластеризации Microsoft совместно с кластеризацией VMware.

В статье vMotion support for MSCS приводятся оставшиеся ограничения. Но как по мне - так ограничениями их считать нельзя.

Вообще существуют несколько реализаций кластера, которые описаны как в официальной документации - Setup for Failover Clustering and Microsoft Cluster Service, так и более понятно и компактно в статях, например MICROSOFT CLUSTERING WITH VMWARE VSPHERE DESIGN GUIDE.