Рекомендации по настройкам Limit, Reservation и Shares

Основной  идеей мне кажется  следующая: ситуаций,  когда вам пригождаются эти настройки,  следует избегать. Чуть ранее я уже приводил иллюстрацию – см. рис. 6.16.

Здесь вы видите, что ресурсов сервера (большая окружность) достаточно для удовлетворения текущих  аппетитов  ВМ (маленькие круги).  Однако  их недостаточно для  одновременного удовлетворения максимально возможных аппетитов  (три пунктирные окружности). Если у нас нет твердой уверенности в том, что эти виртуальные машины не будут требовать максимума  своих ресурсов одновремен но, то эта ситуация неправильна. Правильной ситуацией является та, когда ресурсов сервера заведомо больше, чем необходимо для всех ВМ (рис. 6.17).

Если у вас ситуация как на втором рисунке – то Limit, Reservation и Shares вам особо и не нужны, и именно к такой ситуации вы должны стремиться при сайзинге сервера/серверов под ESX(i).

Рис. 6.16. Иллюстрация недостаточного количества ресурсов сервера

Рис. 6.17. Иллюстрация достаточного количества ресурсов сервера

Отлично,  этот момент принят  во внимание, конфигурация и количество  серверов достаточны для удовлетворения нагрузки со стороны ВМ. Проблема в том, что количество  серверов  может  резко  уменьшиться в результате  сбоя.  Это  не проблема  для доступности приложений в ВМ – при наличии  разделяемого хранилища мы легко можем перезапустить ВМ с отказавшего  сервера на остальных за минуты. А при наличии лицензии на VMware High Availability  это произойдет автоматически.

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

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

Когда ресурсов в достатке

Все-таки как мы можем использовать эти настройки, когда ресурсов в достатке: Q  может быть неплохой  идеей создать  пул ресурсов  с установленным limit для некритичных (тестовых,  временных) ВМ, от которых можно ожидать вcплесков нагрузки или нагрузка со стороны которых мало прогнозируема;

Q  если у вас запрашивают сервер с большими ресурсами памяти/процессора, притом вы твердо знаете, что запрашивают лишнего, то можно с помощью limit  указать  достаточное количество ресурсов.  Плюсом  является то, что вам не нужно спорить  и доказывать  завышенные требования  к ресурсам, и то, что если больше ресурсов дать все-таки захотите, то достаточно будет поднять  limit,  и ВМ  без перезагрузки сможет  воспользоваться дополни тельными ресурсами;

Q  увеличение  reservation для оперативной памяти  уменьшает  размер файла подкачки, который ESX(i) создает при включении  каждой ВМ;

Q  если политика  использования виртуальной инфраструктуры предполагает

выделение  под какие-то  задачи  фиксированного количества  ресурсов, то имеет смысл создать пул ресурсов, в настройках  которого и зафиксировать максимальное (limit) и минимальное гарантированное (reservation) количество ресурсов.  Классический пример  таких  задач – хостинг  ВМ, когда клиент платит за некую производительность, и в наших интересах сделать так, чтобы он получал за что заплатил,  и не больше.

Когда ресурсов не хватает

Типовые рекомендации таковы:

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

Какими  настройками лучше манипулировать – shares или reservation/limit? В типовых случаях лучше shares, потому что это не блокирующая настройка. Напомню, что если недостаточно ресурсов для обеспечения reservation, ВМ не включится. В случае shares таких проблем гарантированно не будет.

Reservation может иметь смысл давать для критичных ВМ, для того чтобы гарантировать ресурсы для их работы в случае нехватки ресурсов. Однако зачастую не стоит резервировать весь объем памяти  для них. Для виртуальных машин гипервизор  предоставляет нам счетчики  Active Memory  – к такому объему оперативной  памяти  виртуальная машина  обращается  активно, часто. Обычно  имеет смысл резервировать среднее значение Active Memory за период времени не менее недели. Это гарантирует, что достаточно большой объем памяти для ВМ будет выделен в любом случае.

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

Не забывайте, гарантия ресурсов для одних ВМ означает гарантированное вытеснение  в файл  подкачки  и недостаточность  процессорных тактов  для других, в случае когда ресурсов перестанет  хватать  на всех.

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

Если какая-то  ВМ критична  для нас и критичен  уровень отклика этой ВМ (то есть скорость работы)  – для нее имеет смысл зарезервировать все или большую часть выделяемых ресурсов.

Итак, сводный план действий примерно такой:

1.    Думаем,  нужна  ли  нам  эта схема  распределения ресурсов.  Может  быть, даже выход из строя  сервера  другого не приведет  к недостатку ресурсов

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

2.    Создаем пулы ресурсов для ВМ разной степени критичности.

3.    Соответственно критичности настраиваем shares: High  – для  критичных пулов,  Low – для  некритичных. Оставляем Normal  для  всех остальных. Если есть пулы для тестовых ВМ, пулы, ВМ в которых создаются и удаляются не нами, – может иметь смысл для них поставить limit, чтобы эти ВМ не задействовали слишком много ресурсов.

4.    При необходимости гарантировать каким-то ВМ уровень ресурсов настраиваем для них reservation. Это потребует  настроить reservation для пулов, в которых они находятся.

Не настраивайте reservation пулов ресурсов «впритык». Вернитесь к рис. 6.14 – сумма reservation дочерних объектов меньше, чем reservation родительского пула, и так поступать правильно.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий