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

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

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

Что надо знать про VMware HA Cluster. Во первых, что он умеет - сводить к минимуму время простоя ВМ, в случае падения хоста. Есть несколько хостов, включенных в HA кластер, есть ВМ на них. Падает какой то хост - ВМ на нем умирают. Но сразу же включаются на других хостах кластера. Для него необходим VC и соответствующие лицензии. В консоли VC создаем кластер(напомню, что в контексте VMware "кластер" - просто группа хостов). Создали кластер, перетащили туда хотя бы 2(max 32) хостов. В свойствах кластера поставили галочку "HA". Теперь на хостах начнется конфигурирование HA агента. Чтобы это конфигурирование закончилось успешно, должны быть выполнены следующие условия: Интерфейсы SC должны находиться в одной подсети, т.е. из консоли каждого ESX вы должны пинговать все другие. Должно быть настроено разрешение имен - т.е. должны ходить пинги и по именам. Для этого используем DNS, или добавляем в /etc/hosts соответствующие записи . Для ESX 3.5 начиная с Update 2 не критично - ибо начиная с этой версии имена разрешаются в IP за счет информации, предоставляемой Virtual Center. Названия групп портов для ВМ должны называться одинаково на всех хостах кластера. Т.е. вот ВМ1 работает на хосте "ESX1", и ее виртуальный сетевой контроллер смотрит в группу портов "VM_network". Вот на ESX2 должна быть группа портов для ВМ с тем же названием. И, само собой, через нее должна быть доступна та же физическая сеть, что и на ESX1. Само собой, те ВМ, которые мы хотим защитить с помощью 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.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 - рекомендуется к ознакомлению. Он же приаттачен к этой странице. Наконец, что пробовать в первую очередь при траблшутинге - статья в KB Troubleshooting Adding an ESX Server Host to a VMware High Availability Cluster. Если HA кластер не собирается - проверить, что для каждого хоста задано короткое и FQDN имя. проверить можно командной "hostname" в имени хоста используются только маленькие буквы. проверить, что все хосты друг друга пингуют по именам командой "ping <имя другого сервера>". проверить, что в vCenter хосты добавлены по именам(!). т.е. в vCenter вы видите не IP серера а его имя. можно попробовать Переустановить агент VMware HA на хосте ESX, когда не получается добавить его в HA-кластер. еще можно почитать Diagnosing a VMware High Availability cluster configuration failure и Troubleshooting Adding an ESX Server Host to a VMware High Availability Cluster.

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

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