вторник, 27 января 2009 г.

[VMware VI Wiki] Обновлено: VMware HA

Пользователь Михаил Михеев обновил страницу VMware HA. Изменения указаны ниже.

Цветовой ключ: Вставка | Удаление

Что надо знать про VMware HA Cluster.

Во первых, что он умеет - сводить к минимуму время простоя ВМ, в случае падения хоста. Есть несколько хостов, включенных в HA кластер, есть ВМ на них. Падает какой то хост - ВМ на нем умирают. Но сразу же включаются на других хостах кластера.



Для него необходим VC и соответствующие лицензии. В консоли VC создаем кластер(напомню, что в контексте VMware "кластер" - просто группа хостов). Создали кластер, перетащили туда хотя бы 2(max 32) хостов. В свойствах кластера поставили галочку "HA".
Теперь на хостах начнется конфигурирование HA агента. Чтобы это конфигурирование закончилось успешно, должны быть выполнены следующие условия:
  1. Интерфейсы SC должны находиться в одной подсети, т.е. из консоли каждого ESX вы должны пинговать все другие.
  2. Должно быть настроено разрешение имен - т.е. должны ходить пинги и по именам. Для этого используем DNS, или добавляем в /etc/hosts соответствующие записи . Для ESX 3.5 начиная с Update 2 не критично - ибо начиная с этой версии имена разрешаются в IP за счет информации, предоставляемой Virtual Center.
  3. Названия групп портов для ВМ должны называться одинаково на всех хостах кластера. Т.е. вот ВМ1 работает на хосте "ESX1", и ее виртуальный сетевой контроллер смотрит в группу портов "VM_network". Вот на ESX2 должна быть группа портов для ВМ с тем же названием. И, само собой, через нее должна быть доступна та же физическая сеть, что и на ESX1.
  4. Само собой, те ВМ, которые мы хотим защитить с помощью HA, должны лежать на общем(shared) LUN на внешней СХД. Т.е. чтобы с каждого хоста в кластере все файлы этих ВМ были видны.
Как работает HA кластер:
когда мы перетаскивам хосты в кластер в консоли VC, то VC настраивает HA агенты на этих хостах. Будучи настроенными, агенты не требуют(!) VC для своей работы. Т.е. VC может находиться даже на виртуалке, и даже если эта виртуалка сдохнет вместе со сдохшим хостом - HA все равно отработает, и поднимет эту ВМ на другом хосте. Достигается это тем, что HA агенты на хостах образуют между собой децентрализованную систему, управляемую самими агентами.

Агенты друг друга пингуют. Для какого то хоста пропажа пингов означает одно из двух - или умер неотзывающийся хост, или умерла сеть для этого хоста. Второй случай называется изоляцией, и должен обрабатываться особым образом:
Вот у нас 3 хоста. У одного становиться недоступен интерфейс SC(напр. выгорает порт на коммутаторе). Остальные думают что он умер(т.к. пинги к нему не ходят) и пытаются запустить те ВМ, которые работали на нем. Это не создаст проблемы, т.к. файлы этих ВМ заблокированны как открытые. Но если выход из строя этого порта коммутатора отрезал от сети ВМ этого хоста - то от того, что они работают, нам не легче.

Поэтому каждый хост умеет проверять, не изолирован ли он. Делается это пингованием IP, по умолчанию это шлюз SC. Или произвольный. Или два произвольных - подробнее про это я писал тут. Предпологается, что эти IP будут отзываться 24\7.

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

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

Что еще мы можем настроить:
Number of hosts failures allowed - смерть какого кол-ва хостов должен пережить наш кластер. Чем большая тут цифирка - тем больше ресурсов резервируется на случай сбоя. Например - у нас 6 хостов, на каждом по 10 ВМ. Если хотим защититься от сбоя одновременно 2 хостов - значит на любых 4х надо мочь запустить все 60 ВМ. Если хотим защититься от падения одновременно 3х - значит на любых 3 надо мочь запустить все 60. "Смочь" - имеется в виду ,что ресурсов должно хватить.
Admissions control - можно ли запускать ВМ, если ее запуск потребует использования заначки ресурсов из предыдущей настройки.

Рекомендации - HA best practices.


Advanced Options.

Многие настройки HA не вынесены в галочки и выпадающие меню. Они вводятся в табличку, доступную по кнопке "Advanced Options" в настройках HA кластера, в виде "имя опции"  "значение".

Возможные опции:

  • das.failuredetectiontime - количество миллисекунд. Таймаут перед срабатыванием "isolation response". Значение по умолчанию 15000 миллисекунд.
  • das.isolationaddress[x] - IP адрес. Этот(эти) IP адреса используются ESX для проверки на событие изоляции. [x] = 1‐10. По умолчанию используется шлюз Service Console. Эти IP'шники должны отвечать на пинги 24\7.
  • das.poweroffonisolation - Значение False или True. Это - настройка действия по умолчанию в случае изоляции.
  • das.vmMemoryMinMB - Чем выше значение, тем больше памяти будет резервироваться на случай сбоя.
  • das.vmCpuMinMHz - Чем выше значение, тем больше ресурсов CPU будет резервироваться на случай сбоя.
  • das.defaultfailoverhost - значение - имя хоста. Этот хост будет использоваться как предпочитаемый в случае сбоя.
  • das.failuredetectioninterval - количество миллисекунд. Для изменения интервала проверочных пингов между хостами (heartbeat). По умолчанию - каждую секунду (1000 миллимекунд).
  • das.allowVmotionNetworks - Allows a NIC that is used for VMotion networks to be
    considered for VMware HA usage. This permits a host to have only one NIC configured for management and VMotion combined.
    Если через сетевушку идет трафик Vmotion, то HA не использует ее для своих пингов. Этот параметр разрешает ему это делать.  Подробности и варианты, когда опция пригодится см. в VMware HA Implementation Notes ниже.
  • das.allowNetwork[x] - имя интерфейса Service Console, а точнее - ее portgroup. Например - ʺService Console 2ʺ. [x] = 1‐? .
    Если у нас несколько интерфейсов SC, указываем в каком порядке использовать их под heartbeat'ы HA.
  • das.isolationShutdownTimeout - таймаут перед выключением ВМ в случае изоляции, если выбрана опция "Shutdown VM". По умолчанию - 300 секунд. Другими словами, если ВМ корректно не завершили работу в случае изоляции, то через 300 секнуд они будут выключены насильно.

Опции из непроверенных источников, пока, к сожалению, без описания:

  • das.trace = ON|OFF
  • das.tracelevel = 0..3|FunctionTracing
  • das.traceoutput = File|EventLog|stdout
  • das.consoleperm = perm_all | perm_oper | perm_user
  • das.consolenode = fqdn
  • das.consoleuser = username
  • das.checkvmstatedelay
  • das.primarycount

Историческая справка - "DAS" - это первый вариант название функции, ныне известной как VMware HA. Отсюда и наличие этих букв в названии опций.

Еще на ту же тему: "Расширенные настройки (advanced settings) кластера VMware HA (High Availability) для отказоустойчивости хостов ESX и виртуальных машин."


Отдельная функция VMware HA, появившаяся после Update 2 - Virtual Machine Failure Monitoring (VMFM).

Работает она следующим образом: система мониторит ежесекундные heartbeat сигналы от VMware tools, и по факту их пропажи перезагружает ВМ.
Таким образом, для включения этой функции нам надо:
ESX 3.5
VC 2.5
HA кластер
Установленные VMware tools

Чтобы включить VMFM, идем в расширенные настройки HA кластера, и указываем следующие опции:
  • das.vmFailoverEnabled – true (true или false)
  • das.FailureInterval – 30 (ВМ считается зависшей, если от нее не было heartbeat в течении этого кол-ва секунд)
  • das.minUptime – 120 (После включения ВМ нужно какое то время - для загрузки ОС, VMware tools и стабилизации heartbeat'ов. Вот тут мы это время и указываем, в секундах.)
  • das.maxFailures - 2 (Максимальное кол-во сбоев и последующих перезагрузок ВМ в течении времени, указанного в опции das.maxFailureWindow. Если das.maxFailureWindow выставленно ‐1 (no window), das.maxFailures представляет абсолютное количество сбоев, после которого VMFM прекращает автоматические перезапуски ВМ.)
  • das.maxFailureWindow выставлен не в -1, и число  – 86400 (Или -1 или значение в секундах. Если число рестартов превысило указанное в опции das.maxFailures, то VMFM прекращает автоматические рестарты.)

Для тестов этой функции можно пользоваться симуляцией BSOD.




Как считаются ресурсы под HA:

http://virtualgeek.typepad.com/virtual_geek/2008/06/so-how-exactly.html


http://virtualgeek.typepad.com/virtual_geek/2008/07/vm-ha---service.html


что то вроде FAQ по работе HA
имеет смысл перевести и добавить сюда
http://www.yellow-bricks.com/2008/09/09/ha-primary-and-secondary-nodes/

Очень правильный документик - VMware HA Implementation Notes - рекомендуется к ознакомлению. Он же приаттачен к этой странице.

Наконец, что пробовать в первую очередь при траблшутинге.
Если HA кластер не собирается -
  1. проверить, что для каждого хоста задано короткое и FQDN имя. проверить можно командной "hostname"
  2. в имени хоста используются только маленькие буквы.
  3. проверить, что все хосты друг друга пингуют по именам командой "ping <имя другого сервера>".
  4. проверить, что в vCenter хосты добавлены по именам(!). т.е. в vCenter вы видите не IP серера а его имя.
  5. можно попробовать Переустановить агент VMware HA на хосте ESX, когда не получается добавить его в HA-кластер.

еще можно почитать Diagnosing a VMware High Availability cluster configuration failure.

Перейти на страницу: VMware HA


-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

[VMware VI Wiki] Обновлено: VMware HA

Пользователь Михаил Михеев обновил страницу VMware HA. Изменения указаны ниже.

Цветовой ключ: Вставка | Удаление

Что надо знать про VMware HA Cluster.

Во первых, что он умеет - сводить к минимуму время простоя ВМ, в случае падения хоста. Есть несколько хостов, включенных в HA кластер, есть ВМ на них. Падает какой то хост - ВМ на нем умирают. Но сразу же включаются на других хостах кластера.



Для него необходим VC и соответствующие лицензии. В консоли VC создаем кластер(напомню, что в контексте VMware "кластер" - просто группа хостов). Создали кластер, перетащили туда хотя бы 2(max 32) хостов. В свойствах кластера поставили галочку "HA".
Теперь на хостах начнется конфигурирование HA агента. Чтобы это конфигурирование закончилось успешно, должны быть выполнены следующие условия:
  1. Интерфейсы SC должны находиться в одной подсети, т.е. из консоли каждого ESX вы должны пинговать все другие.
  2. Должно быть настроено разрешение имен - т.е. должны ходить пинги и по именам. Для этого используем DNS, или добавляем в /etc/hosts соответствующие записи . Для ESX 3.5 начиная с Update 2 не критично - ибо начиная с этой версии имена разрешаются в IP за счет информации, предоставляемой Virtual Center.
  3. Названия групп портов для ВМ должны называться одинаково на всех хостах кластера. Т.е. вот ВМ1 работает на хосте "ESX1", и ее виртуальный сетевой контроллер смотрит в группу портов "VM_network". Вот на ESX2 должна быть группа портов для ВМ с тем же названием. И, само собой, через нее должна быть доступна та же физическая сеть, что и на ESX1.
  4. Само собой, те ВМ, которые мы хотим защитить с помощью HA, должны лежать на общем(shared) LUN на внешней СХД. Т.е. чтобы с каждого хоста в кластере все файлы этих ВМ были видны.
Как работает HA кластер:
когда мы перетаскивам хосты в кластер в консоли VC, то VC настраивает HA агенты на этих хостах. Будучи настроенными, агенты не требуют(!) VC для своей работы. Т.е. VC может находиться даже на виртуалке, и даже если эта виртуалка сдохнет вместе со сдохшим хостом - HA все равно отработает, и поднимет эту ВМ на другом хосте. Достигается это тем, что HA агенты на хостах образуют между собой децентрализованную систему, управляемую самими агентами.

Агенты друг друга пингуют. Для какого то хоста пропажа пингов означает одно из двух - или умер неотзывающийся хост, или умерла сеть для этого хоста. Второй случай называется изоляцией, и должен обрабатываться особым образом:
Вот у нас 3 хоста. У одного становиться недоступен интерфейс SC(напр. выгорает порт на коммутаторе). Остальные думают что он умер(т.к. пинги к нему не ходят) и пытаются запустить те ВМ, которые работали на нем. Это не создаст проблемы, т.к. файлы этих ВМ заблокированны как открытые. Но если выход из строя этого порта коммутатора отрезал от сети ВМ этого хоста - то от того, что они работают, нам не легче.

Поэтому каждый хост умеет проверять, не изолирован ли он. Делается это пингованием IP, по умолчанию это шлюз SC. Или произвольный. Или два произвольных - подробнее про это я писал тут. Предпологается, что эти IP будут отзываться 24\7.

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

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

Что еще мы можем настроить:
Number of hosts failures allowed - смерть какого кол-ва хостов должен пережить наш кластер. Чем большая тут цифирка - тем больше ресурсов резервируется на случай сбоя. Например - у нас 6 хостов, на каждом по 10 ВМ. Если хотим защититься от сбоя одновременно 2 хостов - значит на любых 4х надо мочь запустить все 60 ВМ. Если хотим защититься от падения одновременно 3х - значит на любых 3 надо мочь запустить все 60. "Смочь" - имеется в виду ,что ресурсов должно хватить.
Admissions control - можно ли запускать ВМ, если ее запуск потребует использования заначки ресурсов из предыдущей настройки.

Рекомендации - HA best practices.


Advanced Options.

Многие настройки HA не вынесены в галочки и выпадающие меню. Они вводятся в табличку, доступную по кнопке "Advanced Options" в настройках HA кластера, в виде "имя опции"  "значение".

Возможные опции:

  • das.failuredetectiontime - количество миллисекунд. Таймаут перед срабатыванием "isolation response". Значение по умолчанию 15000 миллисекунд.
  • das.isolationaddress[x] - IP адрес. Этот(эти) IP адреса используются ESX для проверки на событие изоляции. [x] = 1‐10. По умолчанию используется шлюз Service Console. Эти IP'шники должны отвечать на пинги 24\7.
  • das.poweroffonisolation - Значение False или True. Это - настройка действия по умолчанию в случае изоляции.
  • das.vmMemoryMinMB - Чем выше значение, тем больше памяти будет резервироваться на случай сбоя.
  • das.vmCpuMinMHz - Чем выше значение, тем больше ресурсов CPU будет резервироваться на случай сбоя.
  • das.defaultfailoverhost - значение - имя хоста. Этот хост будет использоваться как предпочитаемый в случае сбоя.
  • das.failuredetectioninterval - количество миллисекунд. Для изменения интервала проверочных пингов между хостами (heartbeat). По умолчанию - каждую секунду (1000 миллимекунд).
  • das.allowVmotionNetworks - Allows a NIC that is used for VMotion networks to be
    considered for VMware HA usage. This permits a host to have only one NIC configured for management and VMotion combined.
    Если через сетевушку идет трафик Vmotion, то HA не использует ее для своих пингов. Этот параметр разрешает ему это делать.  Подробности и варианты, когда опция пригодится см. в VMware HA Implementation Notes ниже.
  • das.allowNetwork[x] - имя интерфейса Service Console, а точнее - ее portgroup. Например - ʺService Console 2ʺ. [x] = 1‐? .
    Если у нас несколько интерфейсов SC, указываем в каком порядке использовать их под heartbeat'ы HA.
  • das.isolationShutdownTimeout - таймаут перед выключением ВМ в случае изоляции, если выбрана опция "Shutdown VM". По умолчанию - 300 секунд. Другими словами, если ВМ корректно не завершили работу в случае изоляции, то через 300 секнуд они будут выключены насильно.

Опции из непроверенных источников, пока, к сожалению, без описания:

  • das.trace = ON|OFF
  • das.tracelevel = 0..3|FunctionTracing
  • das.traceoutput = File|EventLog|stdout
  • das.consoleperm = perm_all | perm_oper | perm_user
  • das.consolenode = fqdn
  • das.consoleuser = username
  • das.checkvmstatedelay
  • das.primarycount

Историческая справка - "DAS" - это первый вариант название функции, ныне известной как VMware HA. Отсюда и наличие этих букв в названии опций.

Еще на ту же тему: "Расширенные настройки (advanced settings) кластера VMware HA (High Availability) для отказоустойчивости хостов ESX и виртуальных машин."


Отдельная функция VMware HA, появившаяся после Update 2 - Virtual Machine Failure Monitoring (VMFM).

Работает она следующим образом: система мониторит ежесекундные heartbeat сигналы от VMware tools, и по факту их пропажи перезагружает ВМ.
Таким образом, для включения этой функции нам надо:
ESX 3.5
VC 2.5
HA кластер
Установленные VMware tools

Чтобы включить VMFM, идем в расширенные настройки HA кластера, и указываем следующие опции:
  • das.vmFailoverEnabled – true (true или false)
  • das.FailureInterval – 30 (ВМ считается зависшей, если от нее не было heartbeat в течении этого кол-ва секунд)
  • das.minUptime – 120 (После включения ВМ нужно какое то время - для загрузки ОС, VMware tools и стабилизации heartbeat'ов. Вот тут мы это время и указываем, в секундах.)
  • das.maxFailures - 2 (Максимальное кол-во сбоев и последующих перезагрузок ВМ в течении времени, указанного в опции das.maxFailureWindow. Если das.maxFailureWindow выставленно ‐1 (no window), das.maxFailures представляет абсолютное количество сбоев, после которого VMFM прекращает автоматические перезапуски ВМ.)
  • das.maxFailureWindow выставлен не в -1, и число  – 86400 (Или -1 или значение в секундах. Если число рестартов превысило указанное в опции das.maxFailures, то VMFM прекращает автоматические рестарты.)

Для тестов этой функции можно пользоваться симуляцией BSOD.




Как считаются ресурсы под HA:

http://virtualgeek.typepad.com/virtual_geek/2008/06/so-how-exactly.html


http://virtualgeek.typepad.com/virtual_geek/2008/07/vm-ha---service.html


что то вроде FAQ по работе HA
имеет смысл перевести и добавить сюда
http://www.yellow-bricks.com/2008/09/09/ha-primary-and-secondary-nodes/

Очень правильный документик - VMware HA Implementation Notes - рекомендуется к ознакомлению. Он же приаттачен к этой странице.

Наконец, что пробовать в первую очередь при траблшутинге.
Если HA кластер не собирается -
  1. проверить, что для каждого хоста задано короткое и FQDN имя. проверить можно командной "hostname"
  2. в имени хоста используются только маленькие буквы.
  3. проверить, что все хосты друг друга пингуют по именам командой "ping <имя другого сервера>".
  4. проверить, что в vCenter хосты добавлены по именам(!). т.е. в vCenter вы видите не IP серера а его имя.

еще можно почитать Diagnosing a VMware High Availability cluster configuration failure.

Перейти на страницу: VMware HA


-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

пятница, 23 января 2009 г.

[VMware VI Wiki] Обновлено: Первая страница

Пользователь Михаил Михеев обновил страницу Первая страница. Изменения указаны ниже.

Цветовой ключ: Вставка | Удаление

Привет.
Здесь собирается информация по работе с VMware Virtual Infrastructure, т.е. таким продуктам как VMware ESX \ ESXi, VMware Virtual Center, VMware Consolidated Backup и сопутствующим.

Проект является некоммерческим. Осуществляется на голом энтузиазме и общественных началах.

См. также "О проекте".

Для ориентирования используй "Sitemap" - слева в панеле Navigation. "Первая страница" в той же панели вернет тебя сюда.
Вот в этот блог автоматически публикуются изменения здесь. Для оповещения используй подписку по rss или email.

Краткое содержание:










Если в конкретной статье не указано иное, то к ресурсам этого сайта применяется лицензия

"С указанием авторства - Некоммерческая"

Attribution-NonCommercial (by-nc)

 Изображение:CC-By.pngИзображение:CC-nc.png

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

Читать Commons Deed Attribution-NonCommercial 3.0 Unported

Перейти на страницу: Первая страница


-------------
Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
Не хотите получать уведомления о собственных изменениях? Измените настройки.

воскресенье, 18 января 2009 г.

[VMware VI Wiki] Обновлено: VMFS

Пользователь Михаил Михеев обновил страницу VMFS. Изменения указаны ниже.

Цветовой ключ: Вставка | Удаление

Специализированная, проприетарная файловая система VMware.

Ее отличительными чертами являются:
  • минимальные накладные расходы - т.е. производительность при прямом доступе к диску сопоставима при доступе к vmdk файлу на этом диске. (за конкретными цифирками можно посмотреть сюда - Performance Characterization
    of VMFS and RDM Using a SAN
    - официальный whitepaper VMware)
  • Поддержка файлов большого размера - до 2 ТБ.
  • Кластерность - т.е. к VMFS разделу могут одновременно обращаться несколько хостов.
Когда идет штатная работа, т.е. есть несколько ВМ, которые обращаются к своим vmdk файлам на VMFS разделе, то:
производительность этого раздела(диска\LUN'а на котором он находится) делится между ними. По умолчанию, в равных долях, можем изменить эту настройку - в св-х ВМ, для ее диска есть возможность указать произвольные shares.

Но в некоторых ситуациях возникают дополнительные факторы, влияющие на скорость. Это ситуации, когда необходимо внести изменения в т.е. метаданные(metadata, метадата). Когда необходимо изменить метаданные раздела, используется SCSI Reservation для получения эксклюзивного доступа к диску\LUN'у каким то хостом. Таким образом, на время внесения изменения другие хосты(ВМ с них) ждут снятия блокировки. Слишком большое число таких блокировок может существенно снизить количество I\O, которое мы могли бы выжать из дисковой подсистемы. Таким образом, мы заинтересованы в минимизации их количества.

SCSI Reservation используются в следующих случаях:
  • Создание и удаление VMFS хранилища
  • Расширение (extent) VMFS хранилища
  • Включение и выключение ВМ
  • Получение или особождение блокировки файла
  • Создание или удаление файла
  • Создание шаблона
  • Разворачивание ВМ из шаблона
  • Создание новой ВМ
  • VMotion ВМ
  • Рост файла(актульно для файлов снапшотов или дисков (vmdk файлов) в режиме thin  - эти файлы не preallocated, т.е. на диске занимают только столько места, сколько реально весят файлы гостевой ОС. При необходимости, они растут, блокми по 16 МБ. )
Таким образом, не стоит делать много атких операций одновременно в часы пиковой загрузки.
Отсюда растут уши рекомендации разносить тестовые и производственные ВМ по разным LUN'ам - т.к. лоя тестовых ВМ характерен "рваный" режим работы - включения, выключения, перезагрузки, снятие снапшотов, откат на снапшоты и пр.

Бывает такое, что блокировка LUN не снимается. Чтобы определить такую ситуацию, поможет команда
esxcfg-info -s | grep -i -B 12 pending
Соотвтетствующая тема на форуме - How to check if a LUN is being locked by a host.


Сколько ВМ может лежать на одном VMFS разделе?
Судя по этой теме на форуме, ограничений два: это достаточность I\O и ограничение на кол-во файлов(достаточность обьема я не учитываю как очевидную). Написано, что на VMFS разделе может лежать порядка 31 715 файлов. Это дает нам порядка 3000 ВМ(одна папка и 9-15 файлов на каждую ВМ, не учитывая снапшоты). Достаточно много, не так ли? Но, учитывая производительность, редко встречаются инфраструктуры более чем с полутора сотнями ВМ на одном ЛУНе, а обычное значение 7-30 ВМ, в зависимости от их требовательности к диску и скорости СХД.

Есть мнение, что по умолчанию один хост VMware ESX может иметь одновременный доступ к виртуальным дискам *.vmdk «на сумму» до 4 ТБ. Это меньше, чем заявленные 64 ТБ.
Чтобы подключить дисковых ресурсов больше чем на эти 4 ТБ, читаем что сделать тут - VMFS Heap Size для VMware ESX / ESXi.

of VMFS and RDM Using a SAN - официальный whitepaper VMware)
  • Поддержка файлов большого размера - до 2 ТБ.
  • Кластерность - т.е. к VMFS разделу могут одновременно обращаться несколько хостов.
  • Когда идет штатная работа, т.е. есть несколько ВМ, которые обращаются к своим vmdk файлам на VMFS разделе, то:
    производительность этого раздела(диска\LUN'а на котором он находится) делится между ними. По умолчанию, в равных долях, можем изменить эту настройку - в св-х ВМ, для ее диска есть возможность указать произвольные shares.

    Но в некоторых ситуациях возникают дополнительные факторы, влияющие на скорость. Это ситуации, когда необходимо внести изменения в т.е. метаданные(metadata, метадата). Когда необходимо изменить метаданные раздела, используется SCSI Reservation для получения эксклюзивного доступа к диску\LUN'у каким то хостом. Таким образом, на время внесения изменения другие хосты(ВМ с них) ждут снятия блокировки. Слишком большое число таких блокировок может существенно снизить количество I\O, которое мы могли бы выжать из дисковой подсистемы. Таким образом, мы заинтересованы в минимизации их количества.

    SCSI Reservation используются в следующих случаях:
    • Создание и удаление VMFS хранилища
    • Расширение (extent) VMFS хранилища
    • Включение и выключение ВМ
    • Получение или особождение блокировки файла
    • Создание или удаление файла
    • Создание шаблона
    • Разворачивание ВМ из шаблона
    • Создание новой ВМ
    • VMotion ВМ
    • Рост файла(актульно для файлов снапшотов или дисков (vmdk файлов) в режиме thin  - эти файлы не preallocated, т.е. на диске занимают только столько места, сколько реально весят файлы гостевой ОС. При необходимости, они растут, блокми по 16 МБ. )
    Таким образом, не стоит делать много атких операций одновременно в часы пиковой загрузки.
    Отсюда растут уши рекомендации разносить тестовые и производственные ВМ по разным LUN'ам - т.к. лоя тестовых ВМ характерен "рваный" режим работы - включения, выключения, перезагрузки, снятие снапшотов, откат на снапшоты и пр.

    Бывает такое, что блокировка LUN не снимается. Чтобы определить такую ситуацию, поможет команда
    esxcfg-info -s | grep -i -B 12 pending
    Соотвтетствующая тема на форуме - How to check if a LUN is being locked by a host.


    Сколько ВМ может лежать на одном VMFS разделе?
    Судя по этой теме на форуме, ограничений два: это достаточность I\O и ограничение на кол-во файлов(достаточность обьема я не учитываю как очевидную). Написано, что на VMFS разделе может лежать порядка 31 715 файлов. Это дает нам порядка 3000 ВМ(одна папка и 9-15 файлов на каждую ВМ, не учитывая снапшоты). Достаточно много, не так ли? Но, учитывая производительность, редко встречаются инфраструктуры более чем с полутора сотнями ВМ на одном ЛУНе, а обычное значение 7-30 ВМ, в зависимости от их требовательности к диску и скорости СХД.

    Есть мнение, что по умолчанию один хост VMware ESX может иметь одновременный доступ к виртуальным дискам *.vmdk «на сумму» до 4 ТБ. Это меньше, чем заявленные 64 ТБ.
    Чтобы подключить дисковых ресурсов больше чем на эти 4 ТБ, читаем что сделать тут - VMFS Heap Size для VMware ESX / ESXi.

    Появился документик - VMFS Best Practices.

    Перейти на страницу: VMFS


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Обновлено: Логи ESX и vCenter.

    Пользователь Михаил Михеев обновил страницу Логи ESX и vCenter.. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление

    Взял основу отсюда - Which ESX log file, Which Virtual Center Log File.

    ESX:

    • Vmkernel - /var/log/vmkernel – records activities related to the virtual machines and ESX server.

    • Vmkernel Warnings - /var/log/vmkwarning – records activities with the virtual machines.

    • Vmkernel Summary - /var/log/vmksummary - Used to determine uptime and availability statistics for ESX Server; human-readable summary found in /var/log/vmksummary.txt

    • ESX Server host agent log - /var/log/vmware/hostd.log - Contains information on the agent that manages and configures the ESX Server host and its virtual machines (Search the file date/time stamps to find the log file it is currently outputting to).

    • Service Console - /var/log/messages - Contain all general log messages used to troubleshoot virtual machines on ESX Server.

    • Web Access - /var/log/vmware/webAccess - Records information on Web-based access to ESX Server.

    • Authentication log - /var/log/secure - Contains records of connections that require authentication, such as VMware daemons and actions initiated by the xinetd daemon.

    • VirtualCenter agent - /var/log/vmware/vpx - Contains information on the agent that communicates with VirtualCenter.

                Ротация настраивается /etc/opt/vmware/vpxa/vpxa.cfg


    Ротация большинства логов настраивается в  /etc/logrotate.conf


    Virtual Machines - The same directory as the affected virtual machine’s configuration files; named vmware.log - Contain information when a virtual machine crashes or ends abnormally.

    To specify an alternative location or file name for virtual machine logging, use the log.filename option.
    To direct logs to be written to an alternate location, use log.filename.
    To configure log rotation behaviors, define them in the .vmx file of the virtual machine and use log.rotateSize and log.keepOld.

    Можно еще сюда попробовать заглянуть - VMware logs. Кое какакая информация, полезная при трабшутинге.

    А из этой статьи в KB можно вычитать настройки логирования для логов ВМ:
    • logging = true or false
    • log.rotateSize = maximum size in bytes the file can grow to: 10000
    • log.keepOld = rotation level, amount of log files to keep: 10
    • log.fileName = change name and path of log file

    vCenter:

    Virtual Center Installation Logs

    Install logs are located in the %TEMP%directory of the user that installed software

    • vmlic.log test results for served license file during install
    • redist.log MDAC/MCAD QFE rollup install results
    • vmmsde.log MSDE installation log
    • vmls.log License server installation log
    • vmosql.log Creation of database/trans logs for VCDB
    • vminst.log Log of VC server installation and subtasks
    • VCDatabaseUpgrade.log Details of upgrading from VC 1.x DB
    • vmmsi.log VI client installation logvpx’vpxd-0.log small stub from first time starting service
    Virtual Center Logs
    • Location: %TEMP%\vpx (relative to the user account running vpxd)
    • Name: vpxd-#.log (# is one digit, 0-9)
    • vpxd-index contains the # of the currently active log file
    • Logs rotate each time vpxd is started, and also when it reaches 5 MB in size
    Miscellaneous Logs
    • Core dump location %USERPROFILE%’Application Data’VMware
    • License Server debug log %ALLUSERSPROFILE%’Application Data’VMware’VMware License Server’lmgrd.log(reset each time the service starts; no rotation)
    • %ALLUSERSPROFILE%’Application Data’Macrovision’FLEXlm’
    • Web Access (Tomcat) LogsC:’Program Files’VMware’VMware VirtualCenter 2.0’tomcat’logs


    Ротация настраивается в конфиге
    %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\vpxd.cfg

    VI Client Logs
    • Intended for client-specific diagnostics
    • Location: %TEMP%\vpx (relative to the user running the client)
    • Name: viclient-#.log (# is one digit, 0-9)
    • No index file
    • Logs rotate each time VI Client is started

    Перейти на страницу: Логи ESX и vCenter.


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Обновлено: Официальные и неофициальные списки железа, с которым работает ESX

    Пользователь Михаил Михеев обновил страницу Официальные и неофициальные списки железа, с которым работает ESX. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление


    Официальные списки совместимости доступны на странице
    VMware Infrastructure 3 Documentation.
    • Systems Compatibility Guide for ESX Server 3.5 and ESX Server 3i (PDF)
    • I/O Compatibility Guide for ESX Server 3.5 and ESX Server 3i (PDF)
    • Storage/SAN Compatibility Guide for ESX Server 3.5 and ESX Server 3i (PDF)
    • Backup Software Compatibility Guide for ESX Server 3.5 and ESX Server 3i (PDF)

    Но удобнее всего, наверное, будет онлайн ресурс - online Hardware Compatibility Guide.

    Так же, существует отдельная станица, под названием Compatibility Guides.
    На ней есть список т.н. "Community-Supported Hardware and Software". Это то железо, работа с которым подтверждена сообществом, но официально не поддерживается.

    Примерно тому же самому посвящен сайт Ultimate ESX Whitebox - посвященный списку дешевого железа, на котором заведется ESX.
    Еще одно место - Motherboards and unsupported servers that work with ESX 3.5 and / or ESXi 3.5 Installable.
    Так же, есть список совместимости с гостевыми ОС - Supported Guest Operating Systems.
    Тема на форуме VMware - Low Cost ESX 3.5 System - Suggestions?.


    Наконец, ESX можно запустить в ВМ под Workstation. Нужна железка с процессорами, поддерживающими Intel-VT и гайд - ESX3.5 on Workstation 6.5.

    Перейти на страницу: Официальные и неофициальные списки железа, с которым работает ESX


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Обновлено: Если ВМ перестали отвечать.

    Пользователь Михаил Михеев обновил страницу Если ВМ перестали отвечать.. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление

    Перейти на страницу: Если ВМ перестали отвечать.


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Обновлено: Первая страница

    Пользователь Михаил Михеев обновил страницу Первая страница. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление

    Привет.
    Здесь собирается информация по работе с VMware Virtual Infrastructure, т.е. таким продуктам как VMware ESX \ ESXi, VMware Virtual Center, VMware Consolidated Backup и сопутствующим.

    Проект является некоммерческим. Осуществляется на голом энтузиазме и общественных началах.

    См. также "О проекте".

    Для ориентирования используй "Sitemap" - слева в панеле Navigation. "Первая страница" в той же панели вернет тебя сюда.
    Вот в этот блог автоматически публикуются изменения здесь. Для оповещения используй подписку по rss или email.

    Краткое содержание:










    Если в конкретной статье не указано иное, то к ресурсам этого сайта применяется лицензия

    "С указанием авторства - Некоммерческая"

    Attribution-NonCommercial (by-nc)

     Изображение:CC-By.pngИзображение:CC-nc.png

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

    Читать Commons Deed Attribution-NonCommercial 3.0 Unported

    Перейти на страницу: Первая страница


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Создано: vm-troubleshooting

    Пользователь Михаил Михеев создал страницу vm-troubleshooting.

    Перейти на страницу: vm-troubleshooting


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Обновлено: Мониторинг загрузки хоста, достаточности ресурсов из VIC. rollup.

    Пользователь Михаил Михеев обновил страницу Мониторинг загрузки хоста, достаточности ресурсов из VIC. rollup.. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление

    книжка стр. 212.

    VC хранит статистику разными интервалами:
    за последний час - раз в 20 сек., 180 значений.
    за неделю - раз в 15 мин., 672 значения.
    за год - раз в день, 365 значений.

    rollup - это как мы переводим данные из интервала в интервал. Четыре типа приближений:
    • Последнее значение
    • Среднее
    • совокупность
    • мин\макс
    почитать стоит whitepaper VirtualCenter Monitoring and Performance Statistics.

     также, есть 4 уровня сбора статистики:
    • level 1 - сбор основных счетчиков. не включает статистику по устройствам.
    • level 2 - сбор всех счетчиков. типы rollup - среднее, сумма, последнее. Не собирает значения макс\мин. не включает статистику по устройствам.
    • level 3 - сбор всех счетчиков. типы rollup - среднее, сумма, последнее. Не собирает значения макс\мин.
    • level 4 - собирает все.

    Уровень 1 - по умолчанию.
    Есть мнение, что лучше использовать уровни 2 или 3 - но размер базы будет больше.
    Уровень 4, как правило, используется при траблшутинге.

    Документ на тему - VirtualCenter Performance Counters - описания счетчиков.

    Перейти на страницу: Мониторинг загрузки хоста, достаточности ресурсов из VIC. rollup.


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

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

    [VMware VI Wiki] Обновлено: Официальные и неофициальные списки железа, с которым работает ESX

    Пользователь Михаил Михеев обновил страницу Официальные и неофициальные списки железа, с которым работает ESX. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление


    Официальные списки совместимости доступны на странице
    VMware Infrastructure 3 Documentation.
    • Systems Compatibility Guide for ESX Server 3.5 and ESX Server 3i (PDF)
    • I/O Compatibility Guide for ESX Server 3.5 and ESX Server 3i (PDF)
    • Storage/SAN Compatibility Guide for ESX Server 3.5 and ESX Server 3i (PDF)
    • Backup Software Compatibility Guide for ESX Server 3.5 and ESX Server 3i (PDF)

    Так же, существует отдельная станица, под названием Compatibility Guides.
    На ней есть список т.н. "Community-Supported Hardware and Software". Это то железо, работа с которым подтверждена сообществом, но официально не поддерживается.
    Примерно тому же самому посвящен сайт Ultimate ESX Whitebox - посвященный списку дешевого железа, на котором заведется ESX.

    Так же, есть список совместимости с гостевыми ОС - Supported Guest Operating Systems.

    Официальные списки совместимости доступны на странице
    VMware Infrastructure 3 Documentation.
    • Systems Compatibility Guide for ESX Server 3.5 and ESX Server 3i (PDF)
    • I/O Compatibility Guide for ESX Server 3.5 and ESX Server 3i (PDF)
    • Storage/SAN Compatibility Guide for ESX Server 3.5 and ESX Server 3i (PDF)
    • Backup Software Compatibility Guide for ESX Server 3.5 and ESX Server 3i (PDF)

    Но удобнее всего, наверное, будет онлайн ресурс - online Hardware Compatibility Guide.

    Так же, существует отдельная станица, под названием Compatibility Guides.
    На ней есть список т.н. "Community-Supported Hardware and Software". Это то железо, работа с которым подтверждена сообществом, но официально не поддерживается.

    Примерно тому же самому посвящен сайт Ultimate ESX Whitebox - посвященный списку дешевого железа, на котором заведется ESX.
    Еще одно место - Motherboards and unsupported servers that work with ESX 3.5 and / or ESXi 3.5 Installable.
    Так же, есть список совместимости с гостевыми ОС - Supported Guest Operating Systems.

    Перейти на страницу: Официальные и неофициальные списки железа, с которым работает ESX


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.

    [VMware VI Wiki] Обновлено: Мониторинг загрузки хоста, достаточности ресурсов из SC - esxtop

    Пользователь Михаил Михеев обновил страницу Мониторинг загрузки хоста, достаточности ресурсов из SC - esxtop. Изменения указаны ниже.

    Цветовой ключ: Вставка | Удаление

    утилита esxtop позволяет смотреть данные по загрузке хоста в реальном времени. Также, с помощью скрипта vm-support можно делать "снимки" загрузки за период, и потом "проигрывать" их с помощью esxtop.

    для ESXi есть утилита resxtop - как и прочие, входит в состава RCLI.

    важная штука - load averages. значение = 1.0 означает 100% занятость ресурсов CPU. Значение 2.00 означало бы, что хост(ВМ на нем) задействовали бы в два раза больше CPU чем есть. 0.5 - задействована половина ресурсов.

    CPU:

    PCPU% - на сколько загружен каждый проц, вернее, ядро. это для хоста.

    USED% - на сколько загружен каждый VCPU
    RUN% - "percentage of total time scheduled" - это значение имеет смысл для многопроцессорных ВМ.
    RDY% - CPU ready

    Правильная ссылка - Performance Monitoring and Analysis. К ознакомлению строго рекомендуетсяПравильная ссылка - Performance Monitoring and Analysis. К ознакомлению строго рекомендуется.
    Еще одна, может даже более правильная  - Interpreting esxtop Statistics.







    Перейти на страницу: Мониторинг загрузки хоста, достаточности ресурсов из SC - esxtop


    -------------
    Было запрошено уведомление с Сайтов Google. Отменить подписку можно в любое время.
    Не хотите получать уведомления о собственных изменениях? Измените настройки.