NUMA для vCPU в vSphere 5

Сегодня я бы хотел рассказать о мало освещаемой в блогосфере функции vSphere 5 – virtual NUMA. Что такое NUMA Антон уже описывал около года назад. Технология же virtual NUMA (vNUMA) позволяет гипервизору экспортировать в виртуальную машину данные о NUMA физического сервера. Преимущество этой технологии в том, что все современные ОС уже знают о NUMA и умеют с ней правильно работать, и, как следствие, смогут использовать данные о NUMA для получения максимальной производительности.

Для использования vNUMA необходимо, чтобы ВМ использовала vHW версии 8, а, во-вторых, vNUMA уже автоматически активирована для виртуальных машин с количеством vCPU от 8.
Еще один нюанс состоит в том, что если в ВМ ядер на сокет больше 1го, то размер vNUMA будет равен количеству ядер в сокете. Если же по какой-либо причине Вы выставили 1 ядро на сокет, то параметры vNUMA будут соответствовать NUMA ноде сервера.

Также существует набор тонких настроек vNUMA, изменять которые можно в разделе Aвvanced Settings для ВМ:

cpuid.coresPerSocket - Определяет количество ядер на сокете. Также отвечает за размер vNUMA, если таковая используется. Можно настраивать, если известна точная конфигурация NUMA на сервере.

numa.vcpu.maxPerVirtualNode - Если предыдущая чётко указывает количество ядер на узел, то это настройка указывает максимально возможное. Нельзя использовать их обе одновременно.

numa.autosize - каждый раз при включении ВМ размер vNUMA подгоняется под размер NUMA узлов сервера.

numa.autosize.once - то же самое, только работает один раз. Исключение: если из запущенной хотя бы 1 раз ВМ сделать шаблон – виртуальная машина, развёрнутая из этого шаблона будет иметь такую же vNUMA архитектуру, что и источник для шаблона.

numa.vcpu.min - минимальное количество vCPU, необходимых для создания vNUMA.

numa.vcpu.maxPerMachineNode - максимальное количество vCPU одной ВМ, которые могут работать в рамках одного физического NUMA узла.

numa.vcpu.maxPerClient - количество vCPU в NUMA клиенте. Клиент, в свою очередь - группа vCPU, которые обрабатываются как vNUMA, то есть как 1 объект. По умолчанию, 1 vNUMA является 1 клиентом, но если vNUMA больше pNUMA, то vNUMA может быть разбита не несколько меньших vNUMA клиентов.

numa.nodeAffinity - номера физических NUMA узлов, на которых исполяется виртуальная машина. Крайне не рекомендуется менять эту настройку, так как vmkernel не сможет нормально балансировать такую виртуальную машину между NUMA нодами.

Sysprep

Для развертывания Windows ВМ из шаблона требуются customization specification, которые в свою очередь требуют пакета Sysprep под соотв. версию Windows. Duncan Epping собрал ссылки на все версии в одном месте:

Windows 2000 – 32Bit
Windows 2003 – 32bit
Windows 2003 – 64bit
Windows XP – 32bit
Windows XP – 64bit

И заодно важная статья из VMware KB: Sysprep file locations and versions

О пробросе USB

Один из наиболее задаваемых вопросов - а может ли ESX пробрасывать USB порты в ВМ?

Я уже писал о том, почему не нужно делать подобный проброс, но частично все же повторюсь.

Использование портов хоста жестко привязывает ВМ к хосту. Она больше не может никуда мигрировать. Она даже не перезапустится в HA кластере при смерти хоста, на котором выполнялась - ведь нужный ей порт USB вместе с USB ключом, или что там было подключено, находится на недоступном хосте. Более того, как только появилась привязка к аппаратным ресурсам сервера, можно сказать "до свидания" снапшотам, а следовательно, и бэкапу данной ВМ. Впрочем, вполне возможно, что при цене 499$ за vSphere Essentials непосредственный проброс USB в ВМ (по слухам появится в июне в vSphere 4.1) в секторе SMB будет востребован. Решать, разумеется, вам.

Моя же рекомендация - в любом случае использовать USB-over-IP. И здесь есть варианты как аппаратные, так и в программные.

Производительность дисков в ВМ

Часто спрашивают о производительности дисков, мегабайтах в секунду и так далее. Решил проверить на практике, насколько производительны диски под ВМ, запустил IOMeter для VMDK дисков, лежащих на VMFS разделах на разных доступных мне хранилищах. Теста проводилось 3 - на максимальную скорость линейного чтения и записи блоками по 32 кБ, и полностью случайные чтение/запись в пропорции 50/50 блоками по 4 кб как приближенный к реальности тест. Для последнего теста обратите внимание, что дисковая система полностью загружена по IOPS, поэтому значения скорости в мегабайтах очень просели.

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

ESX 4.0 u1 - HP BL460c G1, 2 * Xeon 5365 3GHz
Fiber Channel - 4 Gbit, без балансировки нагрузки, все по одному пути
iSCSI - ESX software iSCSI, 1 Gbit

Результаты тестов IOMeter. Конфигурация ВМ: 1 vCPU (1 ядро Xeon 5365 3GHz), 768 MB RAM, Windows 2003 32bit. Результаты, разумеется, на EagerZeroedThick дисках, усредненные по 3-5 минут работы теста.

Грабли: отваливаются бэкапы, миграция и клонирование ВМ etc

Проблема: начали отваливаться бэкапы в процессе, невозможно склонировать ВМ или перенести на другой datastore. Файловые операции в консоли ESX отваливаются по таймауту.

Причина: скорее всего одна из ВМ решила полностью нагрузить дисковую систему и в частности datastore, на котором и наблюдаются проблемы. Напоминаю, что нагрузка на дисковую систему измеряется не в сотнях мегабайт в секунду, а в операциях в секунду - IOPS.
Как пример из реальной жизни - машина с syslog сервером, из-за которой все и случилось, генерировала примерно 1.5-2 мегабайта в секунду. Вроде бы смешная цифра для Fibre Channel дисковой полки с 10 дисками, но эти 2 мегабайта в секунду с другой стороны равнялись 1200 IOPS - а больше дисковая полка просто не могла выдать.

Решение: размещение выскоконагруженных по дисковым операциям ВМ на выделенных datastore, размещающихся на выделенных дисковых группах. Почему критичны выделенные дисковые группы в данном случае? При размазанных дисковых группах, когда LUN'ы нарезаются на одной большой дисковой группе, стоит вырасти дисковой нагрузке от одной ВМ - ВСЕ datastore на LUN'ах с этой дисковой группы просядут.

Как отследить машинку-негодяйку? В первую очередь esxtop, разумеется. Но значительно удобнее в таких случаях использовать Veeam Monitor, у которого, кстати, есть Free Edition.

Использование non-persistent дисков

Проблемы безопасности, связанные с использованием непостоянных (non-persistent) дисков, заключаются в том, что злоумышленник может откатить выполненные действия или скрыть следы своего присутствия простым выключением машины. При этом уязвимость обнаруженная злоумышленником в виртуальной машине останется и может быть использована повторно в произвольный момент времени по его усмотрению. Угроза же заключается в том, что администратор может и не узнать, что машина попала под контроль злоумышленника.

Использование виртуальных машин с этим типом дисков может привести к затруднению проведения расследований инцидентов в следующих случаях:
1. Ошибочные или некомпетентные действия пользователя в процессе эксплуатации виртуальной машины (не носящие злого умысла).
2. Проникновение на виртуальную машину вредоносного кода, не детектируемого средствами антивирусной защиты вследствие его новизны или заказного характера, с последующим выполнением вредоносной активности.
3. Умышленные злонамеренные действия пользователей, возможно, не обладающих достаточным уровнем для уничтожения всех следов своей деятельности в случае использования обычных дисков (persistent, по умолчанию).

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

Поэтому рекомендуется полный отказ от использования непостоянных дисков, или использование их только в тестовых средах или средах разработки (эта мера так же рекомендована вендором - стр 6. VMware Security Hardening).

Грабли: Windows 7 постоянно уходит в Suspend

Грабли: ВМ с установленной Windows 7 постоянно уходит в Suspend

Лечение: В гостевой Windows 7 в настройках электропитания выставить "Put the computer to sleep: Never"

Типы vHDD (VMDK)

Виртуальным машинам ESX доступны несколько типов дисков (VMDK).

Thin, Thick, ZeroedThick и EagerZeroedThick. Чем же они различаются?

Thin - "тонкий" диск, файл с виртуальным диском растет по мере использования дискового пространства. Перед выделением очередного блока, блок предварительно очищается (забивается нулями).
Thick - "толстый" диск, файл сразу же создается затребованного размера. Ни при создании, ни при обращении не происходит очистки места. Т.е. ВМ может получить доступ к тем данным, котроые раньше хранились на этом месте.
ZeroedThick - "толстый" диск с очисткой блока при первом к нему обращении.
EagerZeroedThick - "толстый" диск с очисткой всего диска при создании.

По умолчанию из VI / vSphere клиента создается ZeroedThick диск. Диск создается моментально, но часто ведет к жалобам на скорость дисковой системы ESX, поскольку первое обращение к любому блоку диска будет медленным из-за предварительной записи всего блока. Поэтому, если у вас есть желание протестировать скорость диска или сразу же получить полную скорость, то необходимо либо прогнать первый раз тест не обращая внимания на результат (просто обращение к каждому блоку), либо использовать EagerZeroedThick диск. EagerZeroedThick диск создается долго, но имеет полную скорость сразу и является безопасным, в отличие от Thick диска.
При включении FaultTolerance все диски ВМ автоматически конвертируются в EagerZeroedThick формат.

Грабли. Низкая производительность ВМ.

Проблема: производительность ВМ неожиданно низкая, все очень тормозит.
Диагностика: посмотрите на загрузку памяти ВМ, если она 100%, все интенсивно свопится, а для машины при этом значительные цифры видны в Memory Ballooned, то это проблема с выставленным Memory Limit.
Лечение: Memory Limit выставить в значение, равное памяти ВМ, или в Unlimited.

Если машин много, то можно сделать это скриптами.

"Композитная" виртуальная машина

Один из часто задаваемых вопросов касается "композитной" виртуальной машины. "Можно ли сделать так, чтобы ресурсы двух хостов ESX объединить в одну виртуальную машину?"

Нет, нельзя. Почему?

Кластерные суперкомпьютеры, которые позволяют "объединять" ресурсы множества узлов, строятся под задачи. ПО для работы на этих суперкомпьютерах разрабатывается специально, с учетом всех их особенностей.

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

Почему же все тогда говорят про "облако" и ресурсы по заказу? Все очень просто. Мы действительно может давать ресурсы по заказу и относиться к большому Fully automated DRS кластеру ESX как к облаку. Но при одном условии - каждая ВМ требует ресурсов, значительно меньших, чем ресурсы одного хоста. Как только уровень ресурсов становится сравним, облако рассеивается на отдельно стоящие хосты.

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

Template & Domain

Вопрос: присоединять Windows ВМ к домену перед ее превращением в шаблон или оставить в рабочей группе?

Ответ: Если присоединить ВМ к домену до запуска sysprep, то членство в домене будет потеряно. Если присоединить ВМ к домену после запуска sysprep, то по истечению некоторого срока (30 дней по умолчанию) временные пароли для создания защищенного канала с контроллером домена потеряют актуальность и членство в домене снова будет потеряно.
Поэтому лучше оставить машину в рабочей группе и присоединять к домену во время развертывания из шаблона используя механизм customization.