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

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

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

В частности данные по оперативной памяти гипервизора 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.

Сбой vSphere Data Protection при операции "Reconfigure virtual machine"

Сбой vSphere Data Protection при операции "Reconfigure virtual machine"

vSphere Data Protection - 6.1.5
vSphere vCenter (VA) - 6.0 (30300-7037817).

При выполнении бэкапа VDP спотыкается на некоторых машинах при попытке выполнить операцию "Reconfigure virtual machine". После чего уходит в перезагрузку. После чего задание бэкапа не сохраняется. Также не сохраняются и ранее сделанные успешные бэкапы.

Как оказалось причина - использование vSAN. Когда VDP живет на датасторе, отличном от vSAN, он с vSAN не дружит. И как следствие не дружит с некоторыми ВМ, чьи файлы лежать на vSAN. Точную зависимость я не установил.

Решение проблемы - перенос (миграция) системного диска VDP на vSAN. При этом остальные диски, на которых собственно и хранятся данные бэкапа, могут оставаться на резервном датасторе.

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

Для повышения отказоустойчивости я развернул второй VDP и сливаю (реплицирую) на него бэкапы с первого.

Установка драйверов Huawei на хост ESXi

После установки гипервизора ESXi на сервер Huawei RH2288H V2, описанной в прошлой статье, установим драйвера Huawei.

Открываем FusionServer iDriver-Vmware-Driver-VХХХ.zip (как скачивать описывалось ранее) и находим папку "vmware6.0".  Драйвера из этой папки нам и нужно установить.
Для чего первым делом необходимо закачать папку на хост. Способов на самом деле много, я использую WinSCP. Для успешного подключения WinSCP к ESXi на последнем необходимо открыть порт SSH. Для чего в консоли сервера на который мы поставили ESXi жмем "Enable SSH" (меню - Troubleshooting Options).

Итак, порт открыли, запускаем WinSCP и подключаемся к ESXi. 

Затем в папку tmp копируем папку vmware6.0.
После чего с помощью например putty подключаемся к хосту и выполняем инструкцию из файла readme, т.е. выполняем команды:

cd /tmp/vmware6.0/

chmod +x install.sh

./install.sh

После чего жмем "1" для автоматической установки драйверов и перегружаемся.

На этом можно и остановиться, но у меня в сервере еще есть сетевая карта Intel(R) X540-AT2.
Актуальная версия драйвера - 4.5.2

Посмотрим установленную версию драйвера: 

ethtool -i vmnic0

Версия - 3.21.6.

Обновим.

Скачиваем драйвер с сайта, копируем файл net-ixgbe_4.5.2-1OEM.600.0.0.2494585.vib  на хост, переименовываем его, сокращая длинное имя до net-ixgbe.vib, запускаем установку

esxcli software vib install -v /tmp/net-ixgbe.vib

Установка прошла успешно, драйвер обновился.
Обращаем внимание на надпись: Reboot required: true

Перегружаемся.

reboot



По аналогии ставим и другие драйвера. Например я установил драйвер SSD карточки, без которого она не была видна ESXi, и обновил Embedded Host Client.

Установка ESXi (6.0) на сервер Huawei RH2288H V2

За время работы как с виртуализацией от компании Huawei, так и с серверами я усвоил главное правило: логика ничто, - инструкция все!!! Поэтому читаем инструкцию. 

Начинаем с Huawei Server Best Practice with VMware ESXi System. 

Прежде всего инструкция предлагает нам проверить совместимость сервера с ESXi на веб-станице по адресу: http://support.huawei.com/onlinetoolsweb/ftca/en 

Открываем, при необходимости заходим в iMana

Добавление диска в MS SQL

После создания кластера MS SQL 2016 в Hyper-V решил его оптимизировать, разнеся базу данных и журнал на разные диски. 

При этом системная база TEMP уже создана, и остается на диске F. Поскольку системную базу используют все другие базы, т.е. нагрузка на нее ложится существенная, то на диске F она будет жить в гордом одиночестве.

Создал в Hyper-V, вернее в диспетчере отказоустойчивости кластеров общие диски, настроил их в ОС гостевых машин. Вроде все хорошо - диски назначены роли SQL Server, но сам SQL их не видит. Т.е. диски имеют буквы H и I, а видны только F и G.