VMware Tools. Централизация хранения

VMware Tools — один из важнейших и сильнейших элементов vSphere. Не вдаваясь в глубины возможностей, отмечу: эти инструменты позволяют нам видеть DNS-имена и IP-адреса виртуальных машин, предоставляют гостевым операционным системам драйверы специфических устройств. Также работоспособность VMware Tools необходима при недостатке оперативной памяти на ESXi. В случае наличия у ВМ VMTools, она спокойно проходит все круги борьбы за память: ballooning, TPS, compression. При отсутствии VMware Tools виртуальная машина сразу падает в swap.

Необходимость в централизации хранения образов VMware Tools и флоппи-дисков с драйверами PVSCSI может возникать в нескольких случаях:

1. Требуется поддержка операционных систем, для которых VMware Tools выведены из стандартной поставки гипервизора: Linux с glibc < 2.5, Windows до Vista (Server 2003 там же). При попытке обновить или установить VMware Tools на такие ОС гипервизор ругается на отсутствие образа:

Сами образы последних на данный момент актуальных версий находятся по этой ссылке.
2. В инфраструктуре используются гипервизоры разных версий. VMware Tools имеют обратную совместимость, которую можно проверить по матрице:
Полная и самая актуальная версия матрицы здесь: http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php#interop&39=&1=
К примеру VMware Tools, идующие в комплекте с ESXi 6.5, будут прекрасно работать на гипервизоре версии 5.5.
 3. Используется сетевая загрузка гипервизоров. В этом случае подготовленный образ ESXi должен иметь минимальный размер и собирается без VMware Tools.
Итак, VMware Tools в ESXi запрятаны за забором симлинков (не относящееся к делу удалил):

Собственно, директория /productLocker — прямая ссылка на VMware Tools:

Также внимательные могут заметить совершенно другой путь в ошибке, которую я привёл в самом начале — /usr/lib/vmware/isoimages/. В реальности это выглядит так:


Теперь, чтобы организовать централизованное хранилище образов, необходимо выполнить следующие действия:

1. Определиться с этим хранилищем. Вариантами могут быть общий LUN, специально для этого примонтированная NFS-шара (которую можно создать и на vCenter).

2. Создать там директорию, к примеру productLocker.

3. Залить в эту директорию образы в соответствующие папки floppies и vmtools.

4. Сообщить хостам, что у них сменился productLocker.

Для этого идём host -> Configure -> Advanced System Settings. И там необходимо выставить настройку UserVars.ProductLockerLocation, указав путь к нашей новой шаре с VMware Tools. Или выполняем скрипт PowerCLI (не забываем подключить модуль VMware.VimAutomation.Core и подключиться к vCenter):

 

5. Провести одну из двух манипуляций:

а. Перезагрузить хост ESXi, симлинк обновится самостоятельно.

б. Отправить хост в maintenance mode, далее удалить симлинк productLocker и создать его заново вручную:

Необходимо чётко понимать, что с этого момента VMware Tools не будут обновляться с апдейтом гипервизора (если быть точнее, на самом гипервизоре они обновляться будут, но /productLocker будет искать их совершенно в другом месте), и поддержка их в актуальном состоянии становится нашей собственной головной болью.

 


Таблица разделов ESXi

Гипервизор ESXi позволяет устанавливать себя на носители с размеров от 1 Гб. При этом выбор типа носителя VMware предоставляет достаточно большой: традиционные HDD (классический подход: два небольших диска в RAID 1), USB-Flash, SD карты, выделенные LUN на СХД (SAN boot). Таблица разделов при установке на мелкий носитель и на большой будет различаться.

Общая картина со времён ESXi 5.0 следующая:

1. Первые 4 мегабайта — загрузчик системы, который ищет образ ESXi, расположенный на одном из двух следующих разделов.

2. /bootbank Текущий образ ESXi расположен на первом 250-мегабайтном разделе. Раздел отформатирован в стандартном старом добром FAT. Образ системы, сам по себе, — файл s.v00, являющийся сжатым файлом размером 124 Мб. При загрузке системы он распаковывается.

3. /altbootbank Следующие 250 мегабайт предназначены для хранения образа при живом обновлении. После чистой установки ESXi раздел пуст.

4. 110 мегабайт используются во время крушения системы (ухода в PSOD, Puple Screen of Death) для сохранения дампа ядра (core dump).

5. /store В следующем разделе размером 286 Мб (FAT) хранятся образы VMware Tools и флоппи-дисков, которые можно подмонтировать во время установки Windows, — на них содержатся драйверы для паравиртуального адаптера PCSCSI.

6. /scratch Раздел в 4 Гб создаётся в случае установки ESXi на жёсткий диск (вариант: SAN LUN) размером больше 5 Гб. Так называемый scratch раздел содержит логи системы. При установке на диск меньше 5 Гб и USB-Flash или SD любого размера раздел не создаётся, а все логи хранятся в памяти. Соответственно, в данном случае необходимо логировать систему удалённо (хранение на vCenter или выделенном syslog-сервере).

7. Оставшееся место форматируется под VMFS и может использоваться как стандартный датастор под виртуальные машины и прочие файлы.

В ESXi 6.х произошло изменение — в случае использования носителя 8+ Гб создаётся дополнительный раздел размером 2,5 Гб vmkDiagnostic, используемый для диагностики системы и хранения информации vSAN. Раздел располагается между /store и /scratch разделами.

Отдельно требуется заметить, что загрузка с SD/USB без выделенного постоянного хранилища на HDD/SSD/LUN поддерживается только для хостов с ОЗУ меньше 512 Гб.


VMware: esxcli через PowerCLI

PowerCLI для VMware vSphere — невероятно мощный инструмент, основанный на Microsoft PowerShell. PowerCLI позволяет выполнять 98% рутинных операций по управлению виртуальной инфраструктурой. Циклы, условные переходы, фильтры — неотъемлемая часть скриптов. Тем не менее, часть функций по тонкой настройке и работе с хостами ESXi недоступна из PowerCLI и возможно только с помощью командного интерфейса esxcli. Ранее VMware предлагала решение по автоматизации таких задач — Management Assistant, являвшееся отдельно разворачивающейся виртуальной машиной (а точнее, виртуальным апплайнсом). При этом процедура добавления хостов и выполнения команд на них не была тривиальной.

В настоящий момент (vSphere 6.5) Management Assistant ещё поставляется, но находится в официальном статусе deprecated, то есть в следующей версии — предположительно 7.0 — его уже не будет. В связи с этим предлагается использовать командлет PowerCLI под названием Get-Esxcli. Сейчас данный командлет существует уже во второй версии, которую мы и рассмотрим.

Получение доступа к интерфейсу esxcli

Чтобы подключиться к esxcli необходимо выполнить следующую команду:

После этого становится возможным использовать пространство, свойства и методы esxcli.

Выборка пространства

Одним из процессов написания запроса esxcli является просмотр пространства оператора. Если в командной строке ESXi мы можем получить список подуровней пространства команды, забив просто

esxcli

то в нашем случае обращение будет:

Спускаться по дереву ниже возможно так:

Спустившись ещё ниже мы обнаружим методы, применимые к самому элементу:

Выполнив метод, мы удалённо выполняем команду esxcli. К примеру, выполнение на хосте команды

 

эквивалентно

Обращу внимание на приствутствующий метод Help(), по которому можно получить информацию об операциях с элементом.

Передача аргументов

Передача аргументов во второй версии интерфейса Get-Esxcli производится с помощью хэлпера. Для начала необходимо получить этот хэлпер:

Как мы видим, изначально параметры не заданы. Зададим необходимые.

После этого становится возможным передача аргументов в интерфейс:

Таким образом возможно в цикле, например, проверить доступность хоста со всех узлов ESXi (хэлпер $arguments уже заполнен):

 


vSphere Replication 6.5: звериные грабли империализма

Статья посвящается всем тем, кто пытался или будет пробовать поставить vSphere Replication в версии 6.5. У меня это заняло практически 1,5 месяца с небольшими перерывами, сожгло массу нервных клеток и обогатило ближайший алкомаркет.

Как VMware умудрились испортить инсталлятор такого замечательного продукта — неизвестно. С другой стороны, может быть в 6.5 на данный момент вообще сломан механизм развёртывания OVF, не тестировал. В предыдущей серии — vSphere 6.0 — установка vR была простая и приятная. В новой версии я насчитал 6 основных граблей, по которым ходят все, и решения находятся либо методом проб и ошибок, либо на 500 странице Гугла.

Данная статья актуальна для vCenter 6.5a-d и Replication 6.5.0-4634552 — последних версий, выпущенных на момент написания.

1. Множественный выбор

Раньше при развёртывании OVF необходимо было выбрать только сам .ovf файл, а остальное всё подтянется. Теперь необходимо выбирать все пять прилагающихся файлов:

2. Битый образ

Файлы VMDK для vSphere Replication поставляются с неверным манифестом. Указанный размер файла не соответствует реальному. Это справедливо как для образа, скачанного с официального сайта, так и для того, что распространяется в торрентах. Что не удивительно — хэши совпадают. Для исправления ситуации необходим VMware Open Virtualization Format Tool, который перегонит OVF с прилагающимися к нему .vmdk. Единственный замеченный минус: пропадает цифровая подпись OVF, но мы с вами знаем, откуда взяли файлы.

Самая свежая на данный момент версия лежит тут.

После установки перегоняем файлы Replication через утилиту:

3. Версии ESXi

Версии ESXi в кластере, в который будет устанавливаться vR должны быть строго выровненными. Причём это касается не только мажорных версий и первого знака после точки, но и конкретной сборки.

4. Сеть

Тот самый пункт, который вызывает, мягко говоря, удивление. vSphere Replication невозможно поставить, Если в кластере или на отдельном хосте есть только vDistributed Switches. То есть развёртывание требует наличие стандартных свичей. Обходим эту проблему так: на каждом (!) хосте в кластере заводим по стандартному свичу с одной пустой портгруппой, аплинки не назначаем. Можно вывести пару хостов в отдельный кластер, чтобы не танцевать по всем хостам в больших кластерах. Установка производится на портгруппу распределённого свича. После стандартный свич удаляется.

5. Вычислительный ресурс

В мастере установки OVF необходимо выбирать не конкретный хост ESXi, а сам кластер. Только так.

6. Ресурс хранения

В мастере установки OVF необходимо выбирать конкретный датастор, но никак не Datastore Cluster. Только так.


Детализация желаний заказчика

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

  • Резервное копирование на удалённую площадку
  • Заданные параметры RTO и RPO
  • Ёмкость дисковой системы (с некоторыми оговорками)
  • Прочее

К требованиям с детализацией относятся:

  • Количество пользователей
  • Возможность выдерживать пиковые нагрузки
  • Требования по памяти
  • Прочее

Поговорим о пользователях, нагрузке и памяти.

Количество пользователей

Представим, что мы проектируем терминальную ферму для доступа к какой-нибудь системе учёта. От заказчика в ТЗ получаем следующее требование: «Количество терминальных пользователей — 2000 человек». Самый главный вопрос, который необходимо задать клиенту — какое количество из 2000 человек будут работать одновременно? Рассмотрим, на что влияет общее количество и количество поднятых сессий.

Общее количество пользователей: количество лицензий CAL терминального сервера, место хранения пользовательских профилей и, возможно, данных.

Количество одновременных сессий: требуемые вычислительные мощности, количество серверов Session Host, каналы передачи данных, скорость СХД.

Возможность выдерживать пиковые нагрузки

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

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

Второй график демонстрирует такие же дневные циклы, но на нём появляется непрогнозируемый пик:

Должна ли система выдерживать такую нагрузку или, так как она непрогнозируемая, то закладывать это не нужно?

Требования по памяти

В настоящий момент любой нормальные гипервизор имеет механизмы уплотнения оперативной памяти. То есть виртуальным машинам можно дать памяти существенно больше, чем есть физически. Да, такое размещение ВМ будет не самым оптимальным. Но в некоторых условиях, например VDI, где на одном гипервизоре размещены несколько десятков (а то и сотен) практически одинаковых виртуальных машин, дедупликация памяти может экономить огромные ресурсы. К примеру возьмём стандартную ВМ для VDI с 4 Гб оперативной памяти. Из них около половины (2 Гб) будет занимать Windows. Далее вычислим необходимое количество ОЗУ в случае включенной и выключенной дедупликации:

Кроме дедупликации в рассчёт взят ещё Memory Overhead, который для виртуальной машины с 4 Гб ОЗУ и 2 vCPU будет около 50 Мб. Тем не менее, показательно то, что количество памяти снижается в двое.

Как вывод: необходимо всегда уточнять требования к системе и видение её заказчиком.


Работа архитектора

Коротко о главном:

Работа архитектора — это поиск компромиссов для достижения главной цели с помощью лучшего способа.


Матрица аудита

Аудит систем — достаточно частая задача. Цели у аудита могут быть различные, но по моему опыту самая частая из них — продемонстрировать заказчику узкие места и ошибки проектирования/администрирования системы.

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

Как векторы воздействия необходимо брать стандартные метрики любой информационной системы:

  • Доступность
  • Надёжность
  • Управляемость
  • Восстановимость
  • Гибкость
  • Расширяемость
  • Производительность

При необходимости можно задействовать также:

  • Стоимость внедрения
  • Стоимость владения
  • Время внедрения
  • Простота использования
  • Другие необходимые метрики

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

 ДоступностьНадёжностьУправляемостьВосстановимостьГибкостьРасширяемостьПроизводительностьБезопасность 
Не вынесен VMware Platform Service Controller+++++5
На кластерах гипервизоров не включен DRS++++4
Датасторы не объединены в Datastore Cluster++++4
Не используются vSphere Distributed Switch++++4
Вторые сетевые адаптеры находятся в состоянии stand by++2
У нескольких гипервизоров не указаны серверы NTP+++3
На хостах виртуализации включен SSH+1
На нескольких ВМ не работает VMware Tools++++4
Несколько ВМ работают со снапшотом++2
Виртуальным машинам выделены ресурсы, которые не используются+++3
24624563

Данная таблица будет не более чем оценочной, поверхностным взглядом. То, что не вынесен Platform Service Controller, повлияет только при расширении инфраструктуры. Во время работы с существующей средой такой вариант может быть более чем приемлем. А вот настройка сетевых адаптеров, не смотря на то, что взяла всего 2 балла против 5 у PSC, может кардинально воздействовать на систему. Точно также отсутствие указанных серверов NTP грозит разбежкой по времени и сбоем авторизации по сертификатам (3 балла). Использование же стандартных свитчей (при достаточности функций) грозит в основном ошибкой в человеческом факторе (4 балла).

Аналогично недопустимо слепое сравнение категорий (столбцы в таблице): Восстановимость имеет больший вес, чем Гибкость. Конкретные коэффициенты необходимо подбирать в зависимости от среды. К примеру, для кого-то в энтерпрайз будет важнее Безопасность, а для других — Производительность. В среде разработки возможно безопасность вообще не важна, а Управляемость и Расширяемость стоят на первом месте.


Функциональные и нефункциональные требования

Краткая заметка из разряда «короткая память».

Требования к проектам и системам делятся на функциональные и нефункциональные. Функциональные требования — это то, что система должна делать. Нефункциональные требования — как система должна это делать.

Когда мы описываем функциональные требования, мы можем сказать: «Информационная система должна поддерживать удалённое управление». Это будет одной из функций системы. В нефункциональных требованиях уточняется, каким образом удалённое управление будет производиться — веб-интерфейс, клиент, командная строка или ещё какой API.

Два списка. Типичные функциональные требования:

  • Бизнес-правила
  • Коррекция транзакций
  • Административные функции
  • Аутентификация
  • Уровни доступа
  • Отслеживание событий
  • Внешние интерфейсы
  • Требования по сертификации
  • Требования по отчётам
  • Историческое хранение данных
  • Соответствие законам и регуляторам

Типичные нефункциональные требования:

  • Производительность (например: время отклика, пропускная способность, утилизация)
  • Расширяемость
  • Ёмкость
  • Доступность
  • Восстановимость
  • Сопровождаемость
  • Обслуживаемость
  • Безопасность
  • Управляемость
  • Взаимодействие данных
  • Пользовательские интерфейсы
  • Взаимодействия

Иными словами, нефункциональные требования — это «качественные характеристики».


Не работает поиск «Search Inventory» в клиенте VMware

При попытке поиска в окне Search Inventory выпадает окно

Это происходит в том случае, если осуществлён вход с отметкой «Use Windows session credentials».

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


VMware: Невозможно выключить или перезагрузить виртуальную машину

Сегодня столкнулся с тем, что внешне подвисшая виртуальная машина (остановились VMware Tools) отказывалась перезапускаться. Команда Reset валилась по таймауту (как с vCenter, так и напрямую с хоста ESXi), попытки погасить её по питанию тоже не приносили успеха.

В логах появлялось примерно следующее:

Приходится применять «низкоуровневую» магию — консоль. На это есть несколько способов.

1. esxcli

1. Получаем список запущенных виртуальных машин

при этом вывод будет следующим:

Имя ВМ и её идентификатор (World ID) в первой и второй строчках соответственно

2. Выключаем ВМ командой

WorldNumber — это World ID, в типе выключения использовал force, так как уже всё равно.

3. Проверяем первой командой, что ВМ выключилась (вывода по ней быть не должно). Дальше можно запустить ВМ обратно штатными средствами.

2. vim-cmd

1. Получаем список виртуалок

Вывод команды следующий:

2. Узнаём статус работы нужной ВМ

Вывод команды:

3. Выключаем ВМ (первый способ мягкий, второй — жёсткий)

3. kill

Применяем стандартную *nix утилиту kill

1. Получаем список процессов с виртуальными машинами

Вывод команды примерно следующий:

В этом выводе нам нужно второе число (в моём случае 8816107), которое указывает на родительский процесс vmx

2. Посылаем в процесс приказ завершиться

В моём случае это

3. Если в течение 30 секунд ВМ не завершила работу, то убиваем её с особым цинизмом