VMware ESX / vCenter - статистика использования памяти

Справочный материал - где посмотреть статистику использования памяти и что означают конкретные счетчики.

Прежде всего, ESXTOP.

• В заголовке содержатся данные, влияющие на все ВМ, запущенные на данном хосте. Строка физической памяти (PMEM) содержит общий объем установленной памяти, объем, используемый операционной системой сервис-косоли (COS), использование памяти ядром (VMK) и т.д.
• Следующие несколько строк содержат данные по различным подсистемам ESX:
  
  
  
  • VMKMEM: статистика VMkernel
  • COSMEM: статистика использования памяти сервис-консолью
  • PSHARE: статистика разделяемых страниц памяти (page sharing)
  • SWAP: статистика использования свопа
  • MEMCTL: статистика баллонного драйвера

Дешевое разделяемое хранилище для ESX

Для полноценной работы почти всего функционала ESX, кроме непосредственного запуска виртуальных машин, требуется shared storage, разделяемое хранилище. Для HA и VMotion, и того, что с ними связано - DRS, Fault Tolerance.

Но что делать если нет денег на HP EVA, NetApp и даже на Starwind iSCSI? Спасут старые добрые пингвины и старенький, уже слабый, но все еще исправно работающий сервер.

Итак, берем сервер, очень желательно с аппаратным RAID и обязательно с гигабитной сетью, и набиваем его дисками. Программная часть: CentOS, iSCSI Enterprise Target и/или стандартный NFS сервер, идущий в комплекте с CentOS. Я взял дистрибутив, бывший под рукой, CentOS 5.3 32bit.

Выключение TPS вредит производительности?

Duncan Epping указал на один интересный факт, связанный с особенностями работы Transparent Page Sharing (TPS).

Все дело в том, что TPS на NUMA системах работает только в пределах NUMA узла. Из чего следует простой вывод: страницы памяти не могут быть расшарены между NUMA узлами. Frank Denneman написал целую статью о том, как работает ESX на NUMA системах и правильном сайзинге ВМ для NUMA. Так вот, если страницы памяти выделяются удаленно, на другом узле, то для них действует "штраф" (кстати, “esxtop” в метрике N%L показывает процент удаленных страниц). Доступ к этим страницам осуществляется через шину интерконнекта, что, разумеется, медленнее, чем к так называемой локальной памяти.

Возникает вопрос - так какая же связь между NUMA, TPS и производительностью? Задумайтесь над этим. TPS уменьшает количество необходимых физических страниц памяти. Т.е. при выключении TPS возрастают шансы, что при выделении очередной страницы памяти придется выйти за пределы NUMA узла и выделить удаленную страницу. Что, как уже было сказано, отрицательно скажется на производительности. Забавно, как выключение технологии, повсеместно ассоциируемой с повышенной нагрузкой на CPU, приводит к росту задержек при обращении к памяти.

P.S. представителями NUMA архитектуры являются Intel Nehalem и все AMD Opteron .

HA Deepdive: Isolation

1. Slots
2. Primary nodes
3. Isolation
4. Host selection

Говоря об HA и переключениях, инициированных HA, необходимо помнить о такой настройке как "isolation response" (ответ на изоляцию). Ответ на изоляцию - это действие, которые предпринимает HA при обнаружении изоляции, недоступности heartbeat сети. На сегодня существует три возможных варианта: "power off" (жесткое выключение ВМ), "leave powered on" (оставить включенными) и "shut down" (мягкое выключение).

До версии ESX 3.5 U2 / vCenter 2.5U2 ответ на изоляцию по умолчанию при создании нового кластера был "power off". В ESX 3.5 U3 / vCenter 2.5 U3 ответ был изменен на “leave powered on”, а в ESX 4.0 / vCenter 4.0 стал "shut down". Обязательно помните об этом при настройке новой среды, возможно, будет необходимо изменить ответ по умолчанию на какой-то конкретный для нужд заказчика.

Backup / restore конфигурации ESX/ESXi

Часто задают вопрос "как забэкапить конфиг ESX хоста?"

Один из вариантов - использовать Host Profiles. К сожалению, данный метод работает только для лицензии Enterprise Plus, но зато очевиден и крайне прост в использовании.

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

1. Записываем сетевые настройки ESX: DNS имя, IP, mask, gateway, DNS серверы.
2. Host Profile / Create Profile from Host.
3. Maintenance mode, Remove
4. Устанавливаем ESX (ESXi) с нуля на хост.
5. Настраиваем ESX соотв. записанному в пункте 1.
6. Добавляем хост под управление vCenter.
7. Host Profile / Manage Profile / Attach - указываем профиль хоста, созданный в пункте 2.
8. Maintenance mode, Apply Profile.
...
PROFIT!

Особенности резервирования CPU / памяти

Duncan Epping продолжает радовать разъяснениями тонких технических моментов работы vSphere. На этот раз тонкостями работы механизма резервирования ресурсов.
CPU
Предположим, что у нас есть бездействующая ВМ с резервом 2 GHz.  В этом случае другие машины могут получить процессорное время, не используемое данной ВМ, несмотря на резерв.
Память
А вот с памятью все иначе.

Грабли: vCenter 4 и ESX3 - не хочет работать Storage VMotion

Дано: vCenter 4 управляет смешанной инфраструктурой из ESX 4 и 3.5, все лицензии Enterprise. ESXi 3.5 - standalone, не в кластере.
Проблема: невозможно совершить Storage VMotion для ВМ на ESXi 3.5, поскольку "VMotion is not licensed for host".

Возникает вопрос - как это нет лицензии, у меня же Enterprise?!

Решение: для VMkernel интерфейса включить поддержку VMotion, даже если мы не собираемся мигрировать машины на другие хосты. VMotion для 3.5 является отдельным продуктом и требует свою собственную лицензию, и потому соотв. изначально запрашивается лицензия только ESX Standard + vCenter Agent. Чтобы хост получил лицензию VMotion, он должен ее сначала попросить у сервера лицензий, а если нет VMotion интерфейса, то и просить нечего :)

Все больше и больше слоев FUD'а

Невероятно, но старая байка про то, что VMware добавляет еще один слой, до сих пор рассказывается Microsoft в их Virtualization Comparison Brochure. Довольно удивительно и совершенно нечестно - использование термина "слой" лишь для порядка следования в иерархии, но не в смысле объема. И что, черт побери, слой виртуализации делает поверх слоя приложений?

В данном случае Microsoft хочет доказать, что если у вас нет виртуализации VMware, то нет и VMware. В общем-то соответвует действительности, но слоев на самом деле столько же.
Я взял право сделать несколько поправок к материалу Microsoft и рад показать еще три более корректных варианта представления слоев виртуализации.

HA Deepdive: Slots

1. Slots
2. Primary nodes
3. Isolation
4. Host selection

Многие, пожалуй, встречались с ситуацией, когда в HA-кластере ресурсов на первый взгляд предостаточно, а HA ругается на нехватку ресурсов.
Это происходит по причине того, что у HA своя собственная арифметика, основанная на слотах.

Что такое слот? Слот - это место под условную машину, и возможное количество ВМ в кластере определяется количеством слотов под них. HA берет самый большой резерв по процессорам и памяти в кластере и устанавливает в качестве размера слота (память + overhead). Если нет резервов, то процессорная мощность в слоте устанавливается в 256 MHz, а память в слоте считается по размеру наибольшего overhead.

Как определяется колчиство слотов на хосте? Делением. При этом, если количество процессорных слотов получается 25, но только 5 слотов по памяти, то считается, что слотов на хосте 5. А далее слоты всех хостов просто суммируются - в итоге мы имеем емкость HA кластера.

Что в этом случае происходит с несбалансированными кластерами? Несбалансированным кластером, например, является кластер из 5 хостов, в котором на 4х хостах по 16ГБ памяти, а на 5м - 32.

Одна из ВМ сконфигурирована с 4 vCPU / 4 GB, и поскольку резервов нет, то слоты памяти рассчитываются по оверхеду данной машины - 325 MB.



Что в итоге дает по 50 слотов для esx01 - esx04, и 100 для esx05. При включенном Admission Control берется худший сценарий и рассчитывается все на случай падения самых мощных хостов. Т.е. при установленном "Host failures cluster tolerates: 1" мы получаем 200 слотов в кластере. В случае 5и хостов по 16ГБ результат был бы тот же самый - "5*50 - 1*50 = 200".
Если включаете Admission Control, то балансируйте ваши кластеры.

Есть в расширенных настройках такие параметры как das.slotCpuInMHz и das.slotMemInMB для принудительной установки размера слота. Эти параметры могут очень помочь, если у нескольких ВМ в кластере высокие значения резервов, однако здесь тоже есть свои нюансы.



Размер слота памяти установлен в 1024 MB, а VM24 имеет резерв в 4 GB. Как можно заметить, ни у одного из хостов нет 4х свободных слотов, и хотя по сумме слотов требования HA выполняются, есть вероятность, что HA не сможет рестартовать VM24.

Оригинал - Duncan Epping

HA Deepdive: Primary nodes

1. Slots
2. Primary nodes
3. Isolation
4. Host selection

HA кластер состоит из максимум 32 узлов, которые в свою очередь подразделяются на Primary и Secondary. Primary узлы являются "управляющими" и держат у себя информацию о конфигурации и состоянии кластера, синхронизируя между собой.

Primary узлы посылают хартбиты (heartbeat) только Primary узлам, Secondary узлы посылают хартбиты тоже только Primary узлам. По умолчанию 1 хартбит в секунду, но это конфигурируемый параметр: das.failuredetectioninterval.

Первые 5 узлов, включенные в HA кластер автоматически становятся Primary, а все остальные Secondary. Но если производится действие "Reconfigure for HA", то узлы назначаются Primary и Secondary случайным образом. vSphere клиент не показывает, является ли выбранный узел Primary или Secondary, есть только одна возможность это увидеть - из сервис-консоли:

cat /var/log/vmware/aam/aam_config_util_listnodes.log

или

/opt/vmware/aam/bin/Cli (ftcli on earlier versions)
AAM> ln

Распространена ошибка, что при падении Primary узла происходят перевыборы. Не в этом случае. Перевыборы Primary (выдвижение Secondary узла на Primary роль) происходят только при введении Primary узла в Maintenance Mode, отключении от кластера (disconnect) или удалении из кластера.

Если же все 5 Primary узлов упали одновременно, то рестарта виртуальных машин не произойдет, HA требует наличия хотя бы одного Primary узла для работы. Именно поэтому максимум 4 хоста могут выйти из строя в HA кластере.

Это правило, примененное к блейд-серверам, модифицируется следующим образом: разделяйте блейды из одного кластера по разным корзинам и не включайте в HA-кластер более 4х блейдов из одной корзины.

Один из Primary узлом получает роль Fail-over coordinator или Active Primary. Именно он управляет рестартом виртуальных машин при выходе узлов из строя. Если падает Active Primary, то эту роль берет на себя один из оставшихся Primary узлов.

Оригинал - Duncan Epping.

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

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

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

Какие нужны диски для ESX?

Часто задают вопрос - какие нужны диски для ESX? А какой на них делать RAID?

Первая часть ответа: диски нужны такие и в таком количестве, чтобы обеспечить достаточный уровень IOPS - подробнее здесь.

Вторая часть ответа: RAID нужно делать не для ESX, а для ВМ. И если вы собираетесь держать в ВМ СУБД, то и делайте подходящий для данной базы RAID. Что точно НЕ стоит делать - это держать виртуальные машины с критическими сервисами на RAID0.

Проблемы с большими VMDK в 3.5

На форуме поделились информацией:

В 3.5u4 вы не можете увеличить VMDK диск, если он больше терабайта размером, через VI Client. Придется пользоваться командной строкой и vmkfstools.
VMware официально признала это багом, ждем исправления.

Free ESXi & ESX

Существует интересный технический момент - если ввести серийный номер от Free ESXi на ESX сервере, то Evaluation режим остановится и мы получим полноценный ESX сервер с сервис-консолью. Разумеется, с функционалом, соответствующим бесплатному ESXi.

Однако согласно лицензионному соглашению данный способ использования ESX запрещен, и серийные номера Free ESXi должны использоваться только с ESXi.

Не получается создать локального пользователя на ESXi

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



Попробовал и я. Действительно для пар (логин/пароль) itadmin/itadmin и admin/admin такое сообщение. Но при этом прекрасно сработали пары itadmin/qweasdzxc и admin/qweasdzxc, и пользователи были созданы.

Проверил логи:

<Error type="Vmomi.Fault.SystemError">
  <Message>A general system error occurred: passwd: Authentication token manipulation error
passwd: 
</Message>
  <DetailedMessage>A general system error occurred: passwd: Authentication token manipulation error
passwd: 

</DetailedMessage>
  <Reason>passwd: Authentication token manipulation error
passwd: 
</Reason>
</Error>
[        :ShowErr ] 2009-07-07 14:40:40.936  Create User: User name or password has an invalid format

Итак, проблема в том, что passwd не хочет создавать пользователя с таким паролем, но почему? Открыл ssh до ESX

[root@esx2] ~ # passwd dummy
Changing password for user dummy.
New UNIX password: admin
BAD PASSWORD: it is too short
Retype new UNIX password:

[root@esx2] ~ # passwd dummy
Changing password for user dummy.
New UNIX password: itadmin
BAD PASSWORD: it is based on a dictionary word
Retype new UNIX password:

Вот, в общем-то и все, проблема в сложности пароля и недостаточной детализированности ответа ESXi. Все мы, конечно, понимаем, что "qweasdzxc" в качестве пароля вряд ли надежнее чем "admin", но ESXi в лице утилиты passwd считает иначе.

Типы vHDD (VMDK)

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

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

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

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

ESX(i) build number

Все наверное замечали, что при установке некоторых патчей меняется номер билда ESX(i).

Вот здесь можно посмотреть соответствие билдов и версий.

ESX 4 может виртуализовать даже сам себя

Eric Gray (VCritical) поделился рецептом рекурсивной виртуализации ESX 4.



После инсталляции ESX 4 необходимо изменить настройки vSwitch на следующие:



Создайте новую ВМ следующей конфигурации (выберите "Custom")

Virtual Machine Version 7

Guest OS: Linux / Red Hat Enterprise Linux 5 (64-bit)

2 VCPUs, 2GB RAM

2 NICs - e1000

LSI Logic Parallel

Новый диск - разумного размера

После этого подключите в виртуальный CD-Rom ISO с ESX 4 и поставьте как гостевую ОС.



После установки добавьте новый виртуальный ESX к vCenter 4 и создайте новую ВМ.



Если не требуется запускать ВМ в этом виртуальном ESX, то здесь можно остановиться. При попытке запустить ВМ будет выдаваться следующее сообщение:



Чтобы обойти это, достаточно всего одной минуты. Выключите виртуальный ESX и измените настройки ВМ: Edit Settings; Options; Advanced / General / Configuration Parameters… ; Add Row
Name/Value: monitor_control.restrict_backdoor / TRUE

Как устроен VMFS раздел

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

Подробности об устройстве VMFS - здесь.

В качестве полемики с сотрудниками MS

А конкретно с Алексеем Кибкало.

На данный момент известно 14 критических обновлений безопасности (сравним с 36 критическими и 31 обновлений безопасности для VMware ESX Server 3.5 за тот же срок), а всех исправлений к Windows Server 2008 на сегодня известно 41 (сравним с 148 исправлениями для VMware ESX Server 3.5). Очевидно, что большая часть новых обновлений включает в себя часть предыдущих, заменяя их. Однако, если их устанавливать их не все сегодня, а постепенно — сразу после выхода, то количество установок было было бы именно такое. Эти числа приведены для полного варианта установки и наличии всех ролей и функций ОС.

Насколько же изменится ситуация в варианте установки Server Core?

Говоря языком цифр, получится следующее. Для Server Core со всеми ролями и функциями количество критических обновлений меньше на 35%, суммарное количество всех обновлений на 59%, а перезагрузок при их установке потребуется на 62% меньше, чем для полного варианта установки.

1. Наличие бОльшего количества обновлений и даже критических обновлений для ESX не говорит ни о чем, кроме бОльшего количества обновлений.
2. В обновления ESX включаются так же и обновления драйверов (!). Напомните пожалуйста, как там с обновлением драйверов у Hyper-V?
3. При наличии лицензии VMotion (Live Migration) даунтайма для сервисов при установке обновлений на хост нет вообще. Сравним с Hyper-V, у которого Live Migration только-только выйдет.
4. Обновления VMware выпускаются обычно сразу по несколько и ставятся за один раз, что автоматически опровергает расчеты количества перезагрузок.

Итого, вроде и цифры есть, а толку в них?

Интересна и реакция данного сотрудника Microsoft на вот этот пост у меня в блоге.

Даже не буду комментировать бред параноидального MS-ненавистника.

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

У меня возник вопрос: параноидальным MS-ненавистником назвали Stu (vinternals.com) или меня? И лично я не припомню никаких комментариев с цифрами, не говоря уже о том, чтобы я что-то удалял (за исключением спама).
Да и MS-ненавистником я не являюсь ни в какой мере, за исключением пожалуй, неприязни к многим методам маркетинга MS. И я рад тому, что в рунете есть возможность дискутировать на эту тему с НЕмаркетинговыми специалистами.