Главная Virtualization, Windows, Без рубрики, Новое Настройки виртуальных процессоров в Hyper-V
  • Настройки виртуальных процессоров в Hyper-V

    image_thumb_1В этой статье я расскажу о «продвинутых» настройках процессоров виртуальных машин в Hyper-V. Наверняка все эти настройки видели, но мало кто реально пробовал их менять, и еще меньше – знают, для чего они реально нужны и как они работают.

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

    Вот они, эти настройки:

    clip_image002

    Virtual Machine Reserve

    Этот параметр означает, что определенный процент ресурсов будет жестко зарезервирован за виртуальной машиной. По умолчанию равен 0%. В первую очередь этот параметр играет роль в ситуации «борьбы за ресурсы» (то есть когда физические процессоры используются на 100%, а виртуальным машинам требуется еще). В этой ситуации те из виртуальных машин, у которых задан этот параметр, гарантированно получат как минимум то, что за ними зарезервировано.

    Работает этот параметр следующим образом. Возьмем наш 4-ядерный сервер и 5 виртуальных машин, по 4 виртуальных процессора на каждой. Если установить Virtual Machine Reserve, равный 20%, то от физически имеющихся ресурсов для каждой виртуальной машины будет зарезервировано 0,2 * 4 / 4 = 20%. Это значение отобразиться в поле «Percent of total system resources». Если у сервера будет 8 ядер, то это значение будет уже другое: 0,2 * 4 / 8 = 10%.

    Но вернемся к нашим баранам. Если мы запустим все 5 наших виртуальных машин, то все процессорные ресурсы будут заняты, и запустить 6ю виртуальную машину будет можно только в том случае, если Virtual Machine Reserve установлен равным 0%:

    clip_image004

    А вот теперь более интересный пример. На той же самой 4-ядерной системе создадим две виртуальных машины. Одной из них назначим 4 виртуальных процессора, и установим Virtual Machine Reserve 50%. Это значит, что наша виртуальная машина получает половину от каждого из имеющихся ядер, половину от всех системных ресурсов сервера. Запустим ее. Второй виртуальной машине дадим два виртуальных процессора и Virtual Machine Reserve 80%. Это – 40% от всех системных ресурсов. Казалось бы, 50% + 40% = 90%. То есть вторая виртуальная машина тоже должна запуститься, но на самом деле она не запустится. А все потому, что система попытается найти два ядра, от которых можно «отщипнуть» в резерв 80%, а все 4 ядра зарезервированы на 50% каждое:

    clip_image006

    Об этом ограничении нужно всегда помнить, и не «играться» с параметром Virtual Machine Reserve без насущной необходимости. Особое внимание нужно уделять при использовании кластерных решений: при сбое одного узла возможна ситуация, что часть виртуальных машин не сможет перезапуститься на доступном узле из-за недостатка ресурсов для резервирования.

    Тем не менее, резервирование здесь не совсем «жесткое». Допустим, в примере с 5ю виртуальными машинами и 20% Virtual Machine Reserve все 5 виртуальных машин простаивают. Если вдруг одной из виртуальных машин потребуется больше, чем 20% доступных ресурсов – эти ресурсы будут ей предоставлены, не смотря на то, что все 100% вроде бы как зарезервированы. Дело в том, что процессорный ресурс может легко выделяться виртуальным машинам, и так же легко у них забираться. Так что, если возникнет необходимость – резервы для всех гарантируются.

    Для чего можно использовать этот параметр? Главное его назначение – гарантировать ресурсы для бизнес-критичных виртуальных машин, имеющих жесткое SLA. Кроме этого, его можно использовать для искусственного ограничения на количество одновременно запущенных виртуальных машин, хотя по моему мнению – это не самое красивое решение.

    Virtual Machine Limit

    Этот параметр, как и предыдущий (Virtual Machine Reserve), задается в процентах от доступных виртуальной машине ресурсов. Точно так же, как и предыдущий параметр – есть поле «Percent of total system resources» – все точно так же. По умолчанию равен 0, что означает, что никаких ограничений нет, и виртуальная машина может забирать себе столько процессорных ресурсов, сколько ей необходимо и сколько доступно физически. Ненулевое значение параметра Virtual Machine Limit означает, что виртуальная машина ни при каких условиях не сможет использовать больше процессорных ресурсов, чем разрешено. Единственное применение этого параметра – ограничить «аппетит» виртуальной машины, если используются приложения, которые слишком сильно нагружают процессор.

    Так же, как и Virtual Machine Reserve, лимит применяется отдельно к каждому виртуальному процессору. К примеру, если виртуальная машина сконфигурирована с 2 процессорами и установлен лимит 50% – то она получит два виртуальных процессора, каждый из которых ограничивается 50%.

    Но есть одно небольшое отличие: лимит задается жестко. Если Virtual Machine Limit равен 50% – виртуальная машина никогда не сможет использовать больше, даже если на сервере больше ничего не запущено. Кроме этого, лимит применяется отдельно к каждому виртуальному процессору. К примеру, если виртуальная машина сконфигурирована с 2 процессорами и установлен лимит 50% – то она получит два виртуальных процессора, каждый из которых лимитирован 50%.

    Relative Weight

    Третий параметр, о котором я хотел бы рассказать – Relative Weight. В отличие от предыдущих этот параметр – безразмерная величина, и может изменяться от 0 до 10000. По умолчанию равен 100.

    До тех пор, пока у сервера имеются свободные системные ресурсы – параметр Relative Weight не проявляет себя абсолютно никак. Будь значение веса хоть 100, хоть 200, хоть 10000 – на работе виртуальных машин это не отразится. Но как только виртуальные машины начинают запрашивать больше процессорных ресурсов, чем сервер готов предоставить физически – тут-то и начинается самое интересное. Если у всех виртуальных машин значение этого параметра одинаково (к примеру, у всех 100) – то каждая из них получит равную долю процессорного ресура. А вот если у одной или нескольких виртуальных машин Relative Weight выше – это значит, что они «равнее, чем другие», и они получат больше процессорного ресурса, чем остальные. А если есть виртуальные машины с еще более высокими значениями этого параметра – то они получат еще больше. Этот параметр хорош тем, что позволяет выделять более критичные виртуальные машины, при этом не боясь, что какая-то из виртуальных машин откажется запускаться, и придется менять настройки еще и для нее. Но есть один небольшой нюанс: Relative Weight вовсе не дает гарантий, что виртуальная машина в трудную минуту получит ровно столько процессорных ресурсов, сколько ей нужно. Если какие-то из виртуальных машин являются особо критичными, и на них распространяются жесткие SLA – лучше использовать Virtual Machine Reserve, который гарантирует выделение ресурсов.

    Если систему обслуживают несколько администраторов – то необходимо договориться о единой шкале для параметра Relative Weight. В частности, если один будет ставить для некритичныхвиртуальных машин значение 100, для критичных 200, а другой будет ставить 500 для некритичных и 1000 для критичных – система может повести себя немного непредсказуемо. Но это уже вопрос стандартизации, и в более-менее сложных системах, которые управляются более чем одним администратором – такие договоренности должны быть a priori.

    Заключение

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

    Кстати, для пытливых умов предлагаю провести паралель между настройками, описанными в статье и Dynamic Memory (см. Другую мою статью). В этом – корень идеологии Dynamic Memory: не пытаться выделить больше ресурсов, чем есть физически, а сделать память таким же легко распределяемым ресурсом, как и процессорное время.

    Александр Косивченко, MVP: VM

Комментарии

  1. Саш, в ситуации, которая описана в первой части, когда одной машине зарезервированны 50% от четырех ядер, а второй 80% от двух, в случае конликта, решение будет приниматься на основе Relative Weight, правильно?

  2. 1 Нет, не правильно. Вторая виртуалка не запустится.

  3. Понял. А если нет борьбы за ресурсы, то запустится?

  4. Борьбы не будет, просто одна из виртуалок запустится, а другая – нет. В статье объяснено, почему. С картинками 😉

  5. Фак. Надо меньше пить %)
    Извиняюсь.

  6. RSS чёт заоздал.
    Всё забываю просвятиться по такому вопросу:
    Насколько я понял VMWare складывает чстоты процессора и мы выделяем только частоту.
    А Hyper-V проецирует виртуальный процессор на реальный. Т.е. ВМ имеющая 1 процессор никогда не будет обслуживаться на двух ядрах, так?
    Если так, то подход VMWare лучше… Особенно если есть пиковые нагрузки без борьбы за ресурсы.

  7. Для меня, если честно, это тоже странно – однако, по видимому, это так. Спрошу еще у Бена, если будут подробности – напишу.

  8. #6, а ты уверен, что VMware реально распаралелит задачу? Т.е., скажем, если я запущу 7zip в виртуальке с 2(или 4) процессорами в один поток , то будут ли все физические процессоры/ядра задействованы? Что-то я не уверен, что это правда…

  9. Дико извиняюсь за офтоп. Пользуясь случаем вопрос к гражданину Косивченко – а ты с белкой общаешься? еще семинары будут или все умерло после того, как Штусы себе домен w2a зохавал?

  10. @9 Да, с Белко недавно общался. w2a – скорее мертв, чем жив. Вроде бы он и Нео собираются замутить свой проект, с преферансом и куртизанками, но когда точно что-то появится – неизвестно. Обещали первый семинар еще в феврале замутить, но что-то не заладилось.

  11. >>>RSS чёт заоздал.
    >>>
    >>>Всё забываю просвятиться по такому вопросу:
    >>>
    >>>Насколько я понял VMWare складывает чстоты процессора и мы выделяем только частоту.
    >>>
    >>>А Hyper-V проецирует виртуальный процессор на реальный. Т.е. ВМ имеющая 1 процессор никогда не будет обслуживаться на двух ядрах, так?
    >>>
    >>>Если так, то подход VMWare лучше… Особенно если есть пиковые нагрузки без борьбы за ресурсы.

    VMWare (ESX), так же как и Hyper-V, выделяет одно ядро на vCPU. То есть, если у вас 1vCPU, то оно не может одновременно выполняться на двух pCPU.. или 2 vCPU на 1 pCPU.

    VMWare, как и Hyper-V, может перераспределить vCPU между pCPU, если произошли какие-либо изменения, требующие перераспределения ресурсов.

  12. А если в описаном вами случае с Virtual Machine Reserve 50% для VM в 4-ре vCPU и Virtual Machine Reserve 80% для VM в 2-ва vCPU использовано два pCPU по 4-ре ядра – то тогда вторая машина с Virtual Machine Reserve 80% запустится?
    И еще вопрос – ОС Hyper-V server 2008 R2. Создаю на двухпроцесорном сервере с 4-мя ядрами 4-ре VM по 4 vCPU с настройками по умолчанию. Как Hyper-V распределяет ресурсы? Он возьмет и назначит этим VM ядра одного и того же pCPU или распределит их между двумя pCPU? ТОесть непонятен алгоритм распределения – он последовательный или есть жесткие правила, что-то вроде – 4VM x4 vCPU, значит две VM на один pCPU, а две других VM на другой (свободный) pCPU или все 4-ре VM на один pCPU, а если им будет мало, все будут загружены, то подключю второй pCPU.

  13. 1) Да, запустится. Поскольку останется еще целых 4 ядра, не занятых резервом вообще.

    2) Если настройки остаются по умолчанию – то распределение будет зависеть только от нагрузки.

  14. Извините, по п.2 ответ не ясен.
    Что значит “Будет зависеть только от нагрузки” ?
    То есть если параметры по умолчанию, то все машины вешаются на 1 pCPU, а если им мало ресурсов, то подключается другой pCPU. Если так, то тогда у меня второй pCPU может простаивать если, например, на 4-х VM с 4-мя vCPU загрузка каждого vCPU не превышает 25% или на 4-х VM с 1-им vCPU загрузка не превышает 100% Верно?

  15. Совершенно верно. Зачем задействовать второй процессор, если он не нужен? Более того, в 2008R2 появилась фича под названием Core Parking, позволяющая, если отдельные ядра на данный момент не нужны – переводить их в спящий режим. Сделано это для экономии энергии – гринпис, мать их, “Выключи Num Lock – спаси планету!”