HA admission control

Последние несколько недель у меня происходило довольно много дискуссий по поводу вроде бы довольно банального VMware HA. Дело в том, что в какой-то момент я задумался над некоторыми его настройками, и нашел их менее очевидными, чем это мне казалось. И вот по этому поводу и хотелось бы немного вбросить.

Часть первая, введение

Итак, коллеги, начнем с банальностей.

Чем мы платим за высокую доступность, которую дает нам VMware HA?

Правильный ответ – ресурсами. Вернее, заначкой ресурсов на случай сбоя.

Эту заначку ресурсов мы учитываем

1. При планировании инфраструктуры.
   
2. При эксплуатации инфраструктуры.
   

В первом пункте это выглядит примерно так:

«Ага, нам надо будет запустить 40 ВМ по 2 ГБ ОЗУ каждая, всего 80 ГБ. Накинем еще

• Запас на пиковые нагрузки;
  
• Запас на рост на будущее;
  
• Запас на случай отказа одного из серверов;
  
• Запас на неправильные расчеты исходных ресурсов ВМ.
  

И получим (к примеру) 120 ГБ, которые и раскидаем по трем предлагаемым серверам, очевидно по 40 ГБ в каждом».



А во втором случае это выглядит примерно так:

«Ага, если нагрузка на мои сервера превысит 65%, то при отказе одного (двух\трех\...) серверов ресурсов остальных уже не хватит для всех виртуальных машин. Поимею-ка я это в виду…»

Часть вторая, контроль заначки ресурсов

Теперь, внимание, вопрос – а каким образом мы можем поиметь в виду недопустимость нагрузки на каждый из серверов выше порогового значения? Вариантов, в общем-то, два:

1. Или сам администратор заявляет «Я не включу ни одной дополнительной виртуальной машины, пока не будет приобретен еще сервер-другой в мою вСферу». Или, как вариант, «Давайте купим еще сервер, иначе через месяц новые ВМ негде будет включать без опасения что ресурсов не хватит в случае отказа сервера».
   
2. или при попытке администратора включить еще одну ВМ появится сообщение об ошибке вида как на рис. 1
   

Рисунок 1. Сообщение о невозможности включить ВМ из за настроенного Admission Control

Вольный перевод:
«VMware HA запрещает тебе, холоп, включать эту ВМ, ибо претендует она на мою заначку ресурсов на случай сбоя».


И какой вариант контроля выберете вы?


Давайте их обсудим.

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

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

Случай номер два, в принципе, выглядит неплохим. Мы поручаем работу по контролю нагрузки на инфраструктуру кластеру HA, и теперь система непрерывно следит «А можем ли мы себе позволить еще одну ВМ?». Однако, и вот моя самая главная претензия, способы оценки «можем\не можем» далеки от идеала, и именно этот тонкий момент мне хотелось бы проговорить.

Часть третья, настройки Admission Control

У кластера HA есть соответствующая настройка - Admission Control (рис.2).

Рисунок 2. Настройка контроля заначки ресурсов

В положении «Disable: Power on VMs…» HA не будет сам контролировать заначку. Как раз такая настройка нам подойдет, если мы этот контроль будем осуществлять сами.

А настройка «Enable: Do not power on VMs…» как раз и приведет к автоматическому контролю «заначки ресурсов», что может вызвать за собой сообщение с рис.1.

А три варианта настройки с рис.2 – это способы оценки заначки. Давайте про них поговорим.

Specify a failover host – сервер-запаска

Рисунок 3. Указание сервера-запаски

Самый простой вариант. Мы сами выбираем тот один сервер, на котором HA не позволит работать ни одной виртуальной машине. Даже DRS или мы сами не сможем мигрировать на него ВМ или включить. Но сам сервер работать будет все время, пустым. А остальные сервера HA не будет контролировать никак (рис. 4).


 

Рисунок 4. Пример статистики по нагрузке на сервера кластера

Мне этот вариант настройки нравится по следующим причинам:

• Он простой и понятный. Вот сервер – запаска, вот – все остальные сервера, на которые контроль не распространяется.
  
• Он дает хорошую гарантию достаточности ресурсов. Если допустить, что сервера у нас типовой конфигурации, то при отказе одного у нас есть 100% ресурсов такого же сервера – неплохая гарантия что после сбоя виртуалкам будет где подняться.
  

Однако минусы тоже есть:

• В маленьком кластере выделить целый один сервер может быть слишком много.
  
• В большом кластере резервирование только одного сервера может быть слишком мало.
  

Впрочем, как сегодня вижу я, остальные варианты резервирования практически совсем не применимы, так что этот мне нравится больше всего.

Кстати, если вдруг откажут одновременно два сервера, один из которых - сервер запаска, то HA будет распихивать виртуальные машины по наиболее свободным серверам кластера из оставшихся в живых.

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

Percentage of cluster resources reserved as failover spare capacity – процент ресурсов

Второй вариант настройки резервирования ресурсов кластера на случай отказа – резерв указанного процента ресурсов на каждом сервере (рис. 5).

Рисунок 5. Резерв процента ресурсов

Проблем две.


Первая, не очень острая - а сколько процентов надо указать?


Вторая  проблема возникает в правильном понимании этих процентов. Как вы думаете, что они означают?

Наводящая картинка – как вы думаете, рис. 6 это чудеса фотошопа или реально возможная ситуация?

Рисунок 6. Статус резервирования для кластера и фактическая нагрузка на сервера кластера

Раскрою что здесь изображено - HA считает что ему надо резервировать 25% ресурсов, а реально у него еще свободно от резервов 97%. 
А на нижней части рисунка отображена реальная нагрузка на оба сервера кластера в 100%.


Так как - это возможно?


Правильный ответ – такая ситуация возможна, и вполне вероятна.

Для правильного понимания ситуации давайте немного отвлечемся.

Взгляните – вот информация по параметрам виртуальных машин (рис. 7).

Рисунок 7. Четыре разных параметра ОЗУ виртуальных машин

Здесь мы видим, что у виртуальной машины vCenter:

• 3 гигабайта памяти – максимум;
  
• 0.5 гигайбата – резерв;
  
• 1.9 гигабайта гипервизор реально тратит на нее;
  
• 7% от 3 гигабайт она активно использует.
  

Внимание, вопрос – какой из этих показателей контролируется HA Admission Control?

Правы те, кто ответил Reservation.

Т.е. резервирование 25% ресурсов каждого сервера означает, что на каждом сервере сумма резервов включенных виртуальных машин должна быть меньше-равна 75% ресурсов сервера.

А максимальное или реальное потребление ресурсов виртуальными машинами НЕ_УЧИТЫВАЕТСЯ_НИКАК.

Допустим:

• У типового сервера 64 гигабайта оперативной памяти;
  
• 4 ГБ занял гипервизор, 60 ГБ (для ровного счета) доступно виртуальным машинам;
  
• Для HA мы указали зарезервировать 25% ресурсов – т.е. 15 ГБ памяти он зарезервировал;
  
• Типовая виртуальная машина имеет 4 ГБ памяти как максимум, 0.1 ГБ как резерв, сколько-то потребляет де-факто.

Сколько типовых ВМ нам дадут запустить на этом типовом сервере с 25% резерва под HA?

Правильный ответ: До задницы много.Порядка 450 если учитывать только резервирования памяти.

Это означает, что

без указания адекватного reservation для каждой (или большей части) ВМ этот тип резервирования – фикция.

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

Кстати говоря, а какой должна быть настройка reservation?

Я вижу два основных варианта – или reservation = 100% от выданного ВМ объема памяти, или reservation равен среднему объему активно используемой памяти (рис. 8).

Рисунок 8. Активно потребляемая память

Именно на уровне каждой ВМ, не только пулов ресурсов или vApp!

Host failures cluster tolerates – по слотам

В этом варианте резервирования мы указываем число серверов (рис. 9), смерть которого кластер должен пережить без тормозов виртуальных машин.

Рисунок 9. Резервирование "По слотам"

Далее, HA формирует размер «слота». «Слот» это всего лишь количество мегагерц и мегабайт. 

Формируется слот или автоматически – по наибольшему reservation среди всех ВМ в кластере, или (что правильнее) указывается вручную через Advanced settings.

Так или иначе размер слота выбран, теперь считаем статистику нашего кластера (рис. 10).

Рисунок 10. Статистика по слотам в кластере

Мы видим, что:

• Один слот это 50 МГц и 100 МБ;
  
• В кластере у нас 82 слота;
  
• 14 слотов занято;
  
• 9 слотов можно занять еще (9 а не 27 по той причине что серверы различны по конфигурации, а расчет идет по наихудшему сценарию – отказу самого мощного сервера).

(Эти подсчеты никак не связаны с параметрами виртуальных машин из предыдущих примеров).

Одна виртуальная машина может занять один, а может несколько слотов (как на рисунке 10 – включено всего 2 ВМ, однако занято 14 слотов). 

Внимание, вопрос – от чего это зависит?

Внимание, не самый радостный ответ – снова от reservation виртуальной машины.

Т.е. в случае со слотами ситуация очень похожа на случай с процентами – если мы не озаботились указанием reservation для всех или всех критичных ВМ, то эти расчеты заначки нам гарантируют ничего.

Небольшая иллюстрация на рис. 11:

Рисунок 11. Размер кресла = размер слота, а реальный размер задницы соседей (= реальным аппетитам прочих ВМ) не учитывается

Этим чудесным хенд-мейд комиксом я хочу проиллюстрировать тот факт, что нам будет мало радости от того, что очередная виртуальная машина включиться (так как слот под нее есть), но работать будет плохо (так как достаточно ресурсов для нее нет) – рис. 12 или, что то же самое – рис. 6.

Рисунок 12. Иллюстрация оторванности подсчета слотов от реальных аппетитов ВМ

Некоторые факты и соображения

В инфраструктурах покрупнее кластеру HA впору опасаться не только отказа сервера, но и отказа группы серверов – из-за отказа шасси блейд-серверов.

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

Рисунок 13. Разбивка кластеров HA по шасси

В каждом шасси не более четырех серверов, потому что HA гарантированно переживает отказ максимум четырех серверов.


И теперь нас интересует настройка резервирования ресурсов для каждого кластера независимо. К сожалению, если отказ шасси влечет за собой отказ более одного сервера кластера, то простого способа гарантировать достаточность ресурсов для ВМ после сбоя нет. Ну или я не вижу :-)

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

Подведение итогов

Если ручной контроль запаса ресурсов на случай отказа сервера нам не подходит, то следует пользоваться автоматическим.

Для автоматического контроля запаса ресурсов есть несколько вариантов расчета этого запаса.
Вариант «резервирование целого одного сервера» мне видится очень хорошим, но не всегда применимым по вышеизложенным причинам.

Варианты резервирования «процент ресурсов кластера» и «по слотам» мне видятся неприменимыми без указания адекватного reservation для каждой важной ВМ.

Обратите внимание - по данным опроса в прошлом посте 169 из 184 (на момент написания) ответивших не используют reservation для широкого круга ВМ - т.е. если у этих 92% ответивших  настроен первый или второй вариант Admission Control - это бессмысленно.

А стоит ли заморачиваться с reservation для работы этих вариантов Admission control – это отдельный вопрос, и не факт что ответ будет «да».

Еще одним вариантом как можно поступить является следующий:

1. Как-то адекватно настроить admissions control – самое применимое это выбрать сервер-запаску или вообще отключить этот контроль.
   
2. Создать набор пулов ресурсов, и распихать туда виртуальные машины в соответствии с их важностью для нас. В соответствие с важностью указать shares(и, может быть, reservation) на уровне пулов.
   
3. Теперь мы получим гарантию, что нашим важным виртуальным машинам хватит ресурсов, пусть даже путем вытеснения неважных ВМ с процессоров и в своп если после срабатывания HA ресурсов на всех не хватает.
   

ИМХО, этот вариант лидер по соотношению сложности\эффективности.

Еще одним вариантом является добавление логики к работе HA при помощи самописных скриптов. Но это уже нефиговое такое джедайство, и я тут ничего конкретного посоветовать не могу.