Про подсчет HA Failover Capacity.

Про подсчет HA Failover Capacity.

Засланный казачок ;) изнутри VMware информирует:

для ESX 3.02 (про 3.5 данных нет) применяется следующая схема подсчета т.н. HA Failover Capacity. Вспомнить, что такое HA и с чем его едят можно тут.

Итак - HA оперирует количеством «слотов» под ВМ. Считается по ресурсам CPU и оперативки. И считает это кол-во «слотов» следующим образом(на примере оперативки):

• Имеем кластер. В кластере 4 хоста. В одном 8 ГБ памяти, в остальных больше - 16ГБ.
• Имеем 12 РАБОТАЮЩИХ ВМ - учитываются только работающие. Находим наибольший объем оперативки, данный этим ВМ. Например, у одной виртуалки 2ГБ памяти, у остальных столько же или меньше.
• Берем наибольшее значение оперативки ВМ(2 ГБ) и НАИМЕНЬШЕЕ - оперативки хоста(в этом примере 8ГБ). Делим второе на первое. Получаем 4 "слота". И распространяем это значение на прочие хосты, игнорируя(!), что памяти у них больше. И получаем, в итоге, что у нас есть возможность запустить 16 ВМ - умножив кол-во слотов на кол-во хостов кластера. Что, как вы видите, несколько далековато от реального положения дел.
• Когда мы запустим 17 ВМ в этом кластере, то увидим сообщения “Insufficient resources to satisfy HA failover” и “current failover capacity will be shown as 0″

Дается несколько рекомендаций по предотвращению проблем:

• в настройках кластера ставить “Allow Virtual Machines to be powered on even if they violate availability constraints” - чтобы мочь запустить виртуалки, даже если HA считает что не хватает ресурсов.
  
• Если есть одна ВМ с сильно большИм объемом RAM, его стоит уменьшить. Или запускать эту ВМ на хосте не в кластере.
• Для хостов же обратное - памяти много не бывает.
• Резеврирование ресурсов процессора большее, чем его частота - ошибка.

Автор соглашается, что такая система далека от идеала, и говорит что в планах VMware ее поправить. Надеюсь, в ESX 3.5 это уже сделано - постараюсь выяснить.

Источник.