Показаны сообщения с ярлыком Виртуализация VMware. Показать все сообщения
Показаны сообщения с ярлыком Виртуализация VMware. Показать все сообщения

среда, 14 марта 2018 г.

PowerCLI. Запуск скрипта после завершения всех активных задач.

На форуме VMTN, где я являюсь активным участником, был размещен вопрос "script to call other script when no tasks running in vCenter". Задачка мне показалось интересной, а решение - полезным, я взялся. В результате появилась весьма короткий командлет.

Do {Wait-Event -Timeout 10; Write-Host State: Running} While ((Get-Task).State -eq 'Running'); Script.ps1
Как он работает.
Прежде всего давайте посмотрим как выглядит вывод команды Get-Task
Get-Task

Как видим, выводятся как задачи, запущенные нами, так запущенные системой (vSphere).
Притом задачи отражаются в выводе также и после завершения. 

Мы должны дождаться выполнения всех задач и только после этого запустить какой скрпит/команду. Поэтому используем условие (Get-Task).State -eq 'Running'

В цикле While через заданный промежуток времени (в данном случае 10 секунд)  проверяется статус задач. Если статус Running, то выводится соответствующее сообщение, показывающее что командлет усердно выполняет свою задачу. Как только статус задач изменяется на Success, мы выходим из цикла While, после чего выполняется нужный нам скрипт Script.ps1 (который должен лежать папке, указаной как место жительства скриптов по умолчанию). 
Вот собственно и все.


пятница, 9 февраля 2018 г.

PowerCLI. Get-View. Использование фильтров. Регулярные выражения.

Использование фильтрации вывода результатов командлета Get-View задача не очень простая. В том плане, что обычные приемы, применяемые как в случае с PowerCLI, так и PowerShell не всегда срабатывает. 

воскресенье, 4 февраля 2018 г.

Вышли новые книги про VMware vSphere 6.5

18 октября 2016 года состоялся релиз серверной платформы виртуализации VMware vSphere 6.5. 
И сейчас - в декабре 2017  и январе 2018 по этой версии VMware vSphere вышли в свет новые книги с уже привычными названиями - Mastering VMware vSphere и VMware vSphere Cookbook.

Mastering VMware vSphere 6.5 (авторы Andrea Mauro, Paolo Valsecchi, Karel Novak) состоит из 598 страниц.
VMware vSphere 6.5 Cookbook - Third Edition (составители Abhilash G B, Cedric Rajendra) - 539 страниц.

Если быть точным - то релиз бумажного варианта VMware vSphere 6.5 Cookbook состоится только 9 февраля, но электронная версия уже доступна на сайте www.packtpub.com.


пятница, 2 февраля 2018 г.

PowerCLI. Heartbeat Datastore

В прошлой статье PowerCLI. Использование API. Get-VIObjectByVIView я исследовал объекты, применяя Get-VIObjectByVIView, а тажке Get-Member с фильтром -MemberType Properties.
И обещал рассмотреть командлет получения хранилищ, используемых для Heartbeat Datastore.

Поэтому на этот раз все же рассмотрю вопрос с Heartbeat Datastore и одновременно исследуя командлет Get-Member с фильтром -MemberType Method. Также приведу аналоги командлета, в том числе с использованием Get-View.

Поскольку выделяется целая статья, то можно и дать немного теории про Heartbeat Datastore.
Когда master хост в vSphere HA не может связаться со slave хостом по сети управления, master использует Heartbeat Datastore  чтобы определить тип сбоя:
- выход из строяMaster не может получить сигналов доступности от хоста ни по сети управления, ни по сети хранилищ;
разделение сети. Master видит хосты через Heartbeat Datastores, но не видит хосты через сеть управления. В этом случае в каждом сегменте у нас получится два хоста Master;
изоляция хоста. Хост полностью выпадает из сети управления, не может пинговать Isolation Address, но видит хранилища (а значит не вышел из строя).

четверг, 1 февраля 2018 г.

PowerCLI. Использование API. Get-VIObjectByVIView.

Ранее, в статье PowerCLI. Использование Get-View. Часть 2. я упоминал командлет Get-VIObjectByVIView в контексте совместного использования командлетов Get-View и Get-VM. 

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

Напомню, что Get-VIObjectByVIView - это командлет, который конвертирует  vSphere View object в VIObject. 
VIObject - это объект PowerCLI (ВМ, Хост ESXi, датасторе и т.д.)

Но применение Get-VIObjectByVIView не ограничивается только  лишь случаями совместного использования командлетов Get-View и Get-VM.
Для начала немного теории.

В VMware vSphere имеется application programming interface (API), что переводится как программный интерфейс приложения
API (application programming interface) - это набор готовых классов, функций, процедур, структур и констант. Вся эта информация предоставляется самим приложением (или операционной системой). При этом пользователю не обязательно понимать, что это API технология обеспечивает взаимодействие модулей. Цель предоставленной информации – использование этих данных при взаимодействии с внешними программами.
В VMware PowerCLI есть два способа использования VMware vSphere API. 
1. Использование свойства ExtensionData, имеющееся у большинства объектов PowerCLI. Свойство ExtensionData является прямой ссылкой на vSphere API-объект, связанный с объектом PowerCLI.
2. Использование командлета GetView для извлечения объекта API vSphere, связанного с объектом PowerCLI.

Для лучшего понимания VMware vSphere API и Get-VIObjectByVIView рассмотрим пример получения информации о хранилищах, используемых для Heartbeat Datastore.
Примечание: Heartbeat Datastore служит для обработки сбоев в VMware HA. 

понедельник, 29 января 2018 г.

PowerCLI. Использование хеш таблиц (hash tables).

В прошлых статьях я рассказал как можно одной командой вывести значения, которые содержатся на разных уровнях вложенности. Например значения из Сonfig.tools и .Guest вывода командлета Get-View -ViewType VirtualMachine. Несомненно это очень удобно - вместо последовательного выполнения этих командлетов и выискивания глазами интересующих нас полей мы получаем все в одном месте, и при этом не видим ничего лишнего.

четверг, 25 января 2018 г.

PowerCLI. Использование Get-View. Часть 2.

Во второй части я рассмотрю различные варианты совместного использования Get-View и Get-VM, приведу пример как можно реализовать выполнения одной и тоже задачи с помощью этих командлетов, затрону вопросы их производительности.

Командлеты Get-View и Get-VM совершенно разные, т.е. их выходные данные несовместимы между собой. А имеются ли способы как-то "подружить" их? Ответ: Да, есть! Рассмотрим их.

Если мы выполним
$VM = get-view –viewtype VirtualMachine –filter @{“Name”=”DHCP”}
$VM | Start-VM
То получим ошибку.
Но если используем Get-VIObjectByVIView, 
$VM | Get-VIObjectByVIView | Start-VM
Команда успешно выполнится.

среда, 24 января 2018 г.

PowerCLI. Использование Get-View. Часть 1.

У меня накопилось определенное количество информации об использовании Get-View. И чтобы все это систематизировать, в том числе и для себя, пишу данный цикл статей.

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

пятница, 19 января 2018 г.

Использование PowerCLI для установки "Сheck and upgrade vmware tools before each power on"

Настройка проверки и обновления vmware tools перед каждым включением ВМ возможна в том числе и с помощью Update Manager. Поэтому прежде чем перейти собственно к вопросу, обозначенному в заголовке, рассмотрю некоторые моменты, касающиеся самого процесса обновления VMware Tools, не затронутые в прошлой статье Обновление VMware Tools с использованием VUM (Update Manager). Там не все так просто, поэтому остановлюсь на них поподробнее сейчас.

среда, 17 января 2018 г.

Обновление VMware Tools с использованием VUM (Update Manager)

Также в данной статье будут приведены некоторые команды PowerCLI для получения статуса VMware Tools.

Я как-то всегда надеялся на  VMware vSphere Update Manager (VUM), в том числе и при обновлении VMware Tools. До сегодняшнего дня.
Еще 14.12.2017 вышла версия VMware Tools 10.2.0. В статье VMware обновила пакет VMware Tools до версии 10.2.0 пишут: "Кстати, в онлайн-репозитории VMware версии 10.2 на момент написания заметки еще не было, но скоро он должен обновиться."
И вот я собственно сижу, жду. Сегодня задумался над тем, а где собственно обновления?

вторник, 16 января 2018 г.

Время выполнения команды в 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" дает более грубые результаты. 




понедельник, 15 января 2018 г.

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

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

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

среда, 10 января 2018 г.

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

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

вторник, 26 декабря 2017 г.

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, вмешиваться не надо. На мой взгляд - нужно было добавить "в большинстве случаев".

пятница, 15 декабря 2017 г.

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

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

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

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

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

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

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

вторник, 12 декабря 2017 г.

Стресс тест 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 
Однако в этом случае ВМ может зависнуть.

вторник, 5 декабря 2017 г.

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.

среда, 29 ноября 2017 г.

Сбой 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 и сливаю (реплицирую) на него бэкапы с первого.






пятница, 1 сентября 2017 г.

Установка драйверов 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.