Как управлять политикой доступа в vmware HA?

Контроль допуска HA использует так называемые «слоты» для расчета, есть ли место для размещения всех виртуальных машин в случае отказа настроенного количества хостов. Расчет слота - это то, что позволяет вам продолжать включать виртуальные машины, даже если ресурсы памяти в кластере начинают выглядеть ужасно.

Контроль допуска и слоты

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

Расчет размера слота

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

Для ЦП определяется максимальное резервирование виртуальной машины, которое используется в качестве размера слота. Если резервирования нет, используется минимум, который настраивается в кластере. das.vmCpuMinMHz установка; по умолчанию 256 МГц в 4.1, но упало до 32 МГц в 5.0.

Для памяти резервирование памяти плюс используются накладные расходы памяти для виртуальной машины - поэтому, без каких-либо оговорок, размер вашего слота будет большим числом между количеством накладных расходов памяти вашей самой высокой виртуальной машины или кластером das.vmMemoryMinMB настройка, если она настроена (документация в настоящее время говорит, что по умолчанию 256 МБ; это неправда, в 4.1+ по умолчанию 0).

Эти числа вместе дают вам размер слота для кластера.

Предполагая, что у вас нет резервов, размер вашего слота, вероятно, будет минимальным - 256 МГц для ЦП, а размер слота памяти будет размером накладных расходов памяти виртуальной машины с наибольшими накладными расходами.

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

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

• das.slotCpuInMHz устанавливает максимальный размер процессорной части вычисления слота
• das.slotMemInMB устанавливает максимум на память

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

Подсчет слотов и соблюдение ограничений

После определения размера вашего слота подсчитывается количество слотов на каждом хосте в кластере.

Их предел определяется меньшим ресурсом - поэтому, если хост может уместиться в 100 раз больше размера слота ЦП с точки зрения ресурса ЦП, но может соответствовать только 30-кратному пределу памяти, у хоста будет 30 слотов.

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

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

Ссылка «Advanced Runtime Info» на сводной вкладке кластера сообщит вам, на что настроены ваши слоты.

(Игнорируйте счетчик виртуальных ЦП; он больше не используется для расчета слотов)

Это работает?

Я знаю, о чем ты думаешь.

"Подождите, у моих виртуальных машин есть пара гигабайт оперативной памяти! Как, черт возьми, они должны работать в «слоте» произвольного крошечного размера, например 256 МБ?"

Они должны работать на минимальном уровне, указанном в их резервировании ресурсов; если у них нет резервирования, то они не обязательно должны хорошо работать.

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

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

Если память - это ресурс, о котором идет речь ... что ж, вот тогда становится интересно.

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

• Прозрачный обмен страниц
  • Ищет повторяющиеся страницы памяти среди гостевых виртуальных машин. Если одна и та же ОС работает на нескольких, велика вероятность того, что есть дубликаты. Лишние копии выбрасываются, и все попытки чтения памяти направлены на одну копию.
  • Это выполняется постоянно по расписанию, определенному Mem.ShareScanTime настройка - по умолчанию один раз в час.
• Полеты на воздушном шаре
  • Агент, работающий как часть VMware Tools на гостевой виртуальной машине, получает уведомление от гипервизора о том, что ему требуется вернуть часть памяти. Агент, работающий на виртуальной машине, начинает пытаться забрать память у гостя, запрашивая память у гостевой ОС, раздувая «воздушный шар» использования пустой памяти агентом. Это заставляет гостевую ОС предпринимать шаги для освобождения памяти, которые могут включать очистку кеша файловой системы из памяти или перестановку страниц памяти в собственное пространство подкачки. После того, как страница памяти была успешно загружена в балун, он сообщает хосту, что память может быть освобождена.
  • Это первое действие, которое предпримет хост при возникновении конфликта памяти.
• Сжатие памяти
  • Страницы памяти ВМ сжимаются, но по-прежнему хранятся в основной памяти. Это означает, что доступ к этой странице памяти по-прежнему будет иметь штраф, но это все равно быстрее, чем получение из подкачки.
  • Это последний «хороший» вариант перед заменой.
• Обмен гипервизора
  • Вы, наверное, заметили, что при запуске виртуальной машины в хранилище данных создается файл подкачки, равный размеру памяти виртуальной машины. Это резервирование фактически делает так, чтобы в случае крайней необходимости вся основная память виртуальной машины потенциально могла находиться на диске. Если бы это произошло, производительность явно была бы ужасной, но этот вариант - последнее средство. Но целые страницы памяти перемещаются в файл подкачки в хранилище данных; при доступе их нужно получить с диска.

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

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

Так что я должен делать?

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

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

Если размер вашего слота установлен на минимальном или близком к нему уровне из-за отсутствия каких-либо резервирований в кластере, подтолкните его к тому, чтобы он был больше «нормального» размера виртуальной машины для вашей среды. Задайте что-то вроде этого в расширенных настройках кластера:

das.vmCpuMinMHz = 500
das.vmMemoryMinMB = 2048

Если размер вашего слота слишком велик из-за небольшого количества виртуальных машин с высоким уровнем резервирования, то уменьшите его соответствующим образом.

das.slotCpuInMHz = 1000
das.slotCpuInMHz = 4096

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