Просмотрено
Месяц: Декабрь 2017

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

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 (потребление памяти виртуальными машинами)

Стресс тест 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 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.

В частности:
Cluster In A Box (CIB): виртуальные машины размещены на одном хосте. При сбое одной ВМ кластеризованая служба, например файловый сервер, продолжает функционировать. Однако при сбое хоста мы имеем сбой и кластера MSCS.

Cluster Across Boxes (CAB): ВМ размещены на двух хостах, — соответственно при сбое одного хоста кластерная служба, продолжает функционировать.

Virtual Machine + Physical. Один из сценариев использования — это миграция кластера с физических хостов в виртуальную инфраструктуру.

 

Сравнение различных реализаций приведено в таблице:

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

И тут у меня возник вопрос: а только ли из физической? Ведь в реализациях Cluster Across Boxes (CAB) и Virtual Machine + Physical используется Raw Device Mapping (RDM).

Режим работы виртуальных дисков Raw Device Mapping (RDM) позволяет напрямую использовать блочное устройство хранения без создания на нем файловой системы VMFS.

И этот режим поддерживает не только гипервизор ESXi…

Так что мешает реализовать Cluster Across Hypervisors?


Поискав информацию о данном режиме, я ее …. не нашел.
Поэтому решил проверить на практике, использовав в качестве альтернативного гипервизора платформу Huawei FusionSphere.

Создал на двух гипервизорах две ВМ, презентовал хостам VMware и Huawei два луна — т.е. сам диск свидетель и диск для использования в качестве файловой шары. Прокинул их в ВМ как RDM диски и … кластер заработал.

Т.е. Cluster Across Hypervisors вполне себе имеет право на существование.

И да, миграция кластеризованной ВМ работает, притом в обоих гипервизорах.
Правда в случае с Huawei наличие RDM диска увеличивает время миграции примерно в три раза.

Для VMware наличие RDM диска никак не изменяет время миграции.

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

При этом миграция виртуальных машин является стрессом для кластерной роли.  Поэтому в условиях рабочих нагрузок перед проведением миграции виртуальной машины роль с нее нужно переносить средствами Диспетчера отказоустойчивости кластеров. Либо для восстановления работоспособности роли это необходимо делать уже после миграции
Вариант использования, как я писал выше — это перенос сервиса между гипервизорами разных вендоров без прерывания его работы. Правда работает это только в случае кластеризованного сервиса. И усилий необходимо приложить гораздо больше, чем просто миграция между гипервизорами одного вендора. С другой стороны если вам необходимо протестировать работу боевого кластера SQL на разных платформах, то опять же нет ничего проще. Просто запускаете роль на альтернативном гипервизоре и смотрите как она себя ведет в реальной обстановке. И в случае очень неудовлетворительных результатах просто переносите роль на другой узел отказоустойчивого кластера.