Главная Virtualization, Без рубрики, Новое Встречайте: Hyper-V R2 Service Pack 1. Dynamic Memory.
  • Встречайте: Hyper-V R2 Service Pack 1. Dynamic Memory.

    Совсем скоро выйдет Service Pack 1 для Windows Server 2008 R2. Помимо исправлений ошибок, SP1 несет в себе и некоторые нововведения, в том числе – касающиеся Hyper-V. Если говорить именно о Hyper-V – то это две новые технологии: Dynamic Memory и Remote FX. Технология Remote FX позволяет использовать расширенный мультимедиа-функционал при работе с виртуальными машинами, в частности – возможности современных видеокарт, и прямой «проброс» USB-портов через терминальную сессию. Это позволит в полной мере использовать виртуальные рабочие станции для таких задач, как обработка 3D-графики, FullHD-видео или современных компьютерных игр. Тема эта – достаточно объемная, и достойна даже не отдельной статьи, а целого цикла статей. Начнем же мы с Dynamic Memory.

    Dynamic Memory – технология, позволяющая автоматически добавлять и уменьшать память, выделенную виртуальным машинам, причем делать это «на лету» – без останова гостевой ОС. До недавнего времени, объем памяти виртуальной машины можно было задать только «жестко», для изменения необходимо было останавливать гостевую ОС. Теперь же у виртуальных машин будет два основных параметра выделения памяти: Startup RAM и Maximum RAM. При запуске виртуальной машине выделяется объем памяти, равный Startup RAM. В дальнейшем, в зависимости от потребностей самой виртуальной машины, а так же – других виртуальных машин – ей может быть выделена дополнительная память, либо же излишки памяти, которые все равно не используются – могут быть «отобраны».

    Для чего это может понадобиться?

    Дело в том, что точно оценить объем памяти, необходимый виртуальной машине – может быть сложно. Нагрузка на систему может изменяться, причем иногда возможны и пиковые значения, которые бывает сложно предсказать на этапе проектирования. Простой пример – веб-сервер компании. В нормальном режиме на этот веб-сервер заходят 50-100 человек в день, но вот рекламщики запускают очередную акцию – и посещаемость подскакивает в разы или даже в десятки раз. И если эти скачки не были учтены при проектировании – сервер «захлебывается» от нагрузки и «падает» – перестает отвечать на запросы. Именно поэтому еще на этапе проектирования закладывается некий «запас» по памяти, который может быть достаточно существенным. К сожалению, или к счастью – но такие пиковые нагрузки длятся не постоянно, и большую часть времени эта память не используется. В масштабах одного сервера это может быть и не существенно, но представьте, что у нас используются виртуальные машины, и их, ну например, десять. Если для каждой из них делать «запас» по 1 Гб – то есть большую часть времени фактически будет использоваться 1 Гб памяти, и 1 Гб будет «простаивать» – то мы получаем целых 10 Гб памяти, которые фактически использоваться не будут – они будут «в запасе», но и использовать под что-то нужное – нельзя.

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

    Классический сценарий

    Возьмем для примера хост с 16 Гб памяти. Путем прикидок и гадания на кофейной гуще мы установили, что максимум, сколько может потребоваться одной виртуальной машине – это 3 Гб памяти. С запасом в 1 Гб мы делаем по 4 Гб памяти для каждой виртуальной машины. В итоге, на нашем хосте у нас будет три виртуальные машины. При этом фактически использоваться будет не так и много (3,5 Гб в нашем случае), но доступно будет лишь 4 Гб. Максимум – это позволит создать еще одну виртуальную машину. И то вряд ли: использовать все оставшиеся 4 Гб не даст система.

    А теперь, если мы используем Dynamic Memory – то благодаря рациональному использованию памяти, мы сможем запустить на том же самом хосте еще две виртуальных машины, две из которых могут испытывать пиковые (потребление 3 Гб памяти) и сверх-пиковые (аж 4,5 Гб) нагрузки. И при этом, теоретически, можно запустить еще 3 виртуальных машины (при условии Startup RAM = 512 Мб). Забегая немного вперед – скажу, что в примере взяты настройки Dynamic Memory по умолчанию: Startup RAM = 512 Мб, Maximum RAM = 64 Гб, Free Buffer = 20%.

    Отказоустойчивые сценарии

    Возьмем другой пример – кластер из трех узлов. Каждый из узлов имеет 3 Гб памяти, и запущено на каждом узле по три виртуальных машины (объем памяти – 3 и 4 Гбайт):

    Тут вдруг внезапно NODE3 выходит из строя, и виртуальные машины перезапускаются на других узлах. Как видим, одной из виртуальных машин не хватает памяти, и она не может стартовать:

    Как мы видим, на NODE1 виртуальные машины уже используют 13 Гб памяти, и, поскольку хостовая ОС тоже «хочет кушать» – то свободных 3 Гб для VM8 нет. То есть, для получения отказоустойчивости нам нужно выполнить одно из перечисленных действий:

    • Добавить еще один узел
    • Уменьшить количество виртуальных машин
    • Уменьшить объем памяти у одной или нескольких виртуальных машин

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

    А теперь посмотрим, как будет выглядеть ситуация с использованием Dynamic Memory. Допустим, что Startup RAM установлен в 1 Гб. Это значит, что виртуальной машине при запуске будет выделяться 1 Гб памяти, и для успешного запуска не нужны все 4 Гб свободной памяти:

    Как видно, с Dynamic Memory все виртуальные машины успешно стартуют на узлах NODE1 и NODE2.

    Заключение

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

Комментарии

  1. так а физически как реализовано будет? гости будут макс объем сразу видеть?

  2. p.s. пропустил заключение… 🙁

  3. “Если для каждой из них делать «запас» по 1 Гб – то есть большую часть времени фактически будет использоваться 1 Гб памяти, и 1 Гб будет «простаивать» — то мы получаем целых 20 Гб памяти, которые фактически использоваться не будут, но и использовать подо что-то нужное – нельзя.” – почему 20???

  4. А “Классический сценарий” весь пересчитать и пересмотреть надо. Мало того, что цифры в статье не сходятся с картинкой, так еще и выгода туманна, поскольку на правой половинке почему-то vm1-vm3 выделено менее 4Гб. Если “Allocated Ram” это максимум выделенный vm, то почему он вдруг стал меньше, чем слева? Кроме теоретической возможности запуска еще 3-х vm выгоды у вас не получилось.

  5. @mr.fed
    Спасибо за найденные баги, чуть-чуть пофиксил статью 🙂
    На рисунке: Committed RAM – это память, которая фактически используется гостевой ОС и приложениями. Allocated RAM – это выделенная фактически виртуальной машине память. Система будет пытатья выдать виртуалке чуть больше памяти, чем ей нужно – это и есть Free Buffer, и об этом я расскажу обязательно в следующей статье.

  6. Может пропустил. Есть ли ограничения на версию ОС работающий в виртуальной машине? Т.е это будет одиноково работать и при виртуальном FreeBSD и при Windows XP?

  7. Увы и ах, Dynamic Memory основывается на enligthment’ах в гостевой ОС, так что пока что официально поддерживаются WS2008, WS2008R2, WS2003 и Vista/7 Ent./Ultimate. Вообще MS официально поддерживает кроме виндов RHEL и SLES, а так как интеграционные компоненты для Linux выходят реже, чем для виндов – возможно, что в следующем релизе Integration Services for Linux и будет поддержка линуксов. Фря точно не будет поддерживаться официально, так что про Dynamic Memory можно будет забыть. В любом случае – сам SP1 еще только в версии RC, так что рано еще говорить о чем-то.

  8. Очень хорошая статья и очень хорошая технология. Сам недавно столкнулся при реализации проекта по виртуализации с такой проблемой и решилось все покупкой дополнительной ОЗУ. Потому вижу большую перспективу технологии.

  9. @8
    А не могли бы Вы поделиться подробностями проекта? Возможно, даже в виде статьи.
    А памяти – как и денег, много не бывает. Особенно – при Dynamic Memory 🙂

  10. Спасибо за статью, очень познавательно!

    “… но и использовать подо что-то нужное – нельзя.”
    наверно лучше заменить просто на “под”

  11. @10
    Яволь, майн граммар-фюрер! :)))

  12. а где продолжение?

  13. Продолжение будет, но, увы, в первых числах января. 🙁

  14. Называется – мы придумали то что давно было у VMware и то о чем MS говорило что данная функция – ну никому просто не нужно. (ну прямо как vMotion vs Quick Migration)

    аналог Transparent Page Sharing(которая реально уменьшает требуемый объем памяти в случае VDI,без драйверов вообще-цена – небольшая нагрузка на процессор) – у MS видимо появится в Hyper-V 2012 SP1 -:)?

    про Memory compression – даже не говорю…

  15. 14
    Антон, это вы? Я не узнаю вас в гриме! :))

    MS говорило, и продолжает говорить, что memory overcommitment никому не нужно. Dynamic memory – это не overcommitment, оно не позволяет виртуалкам использовать больше памяти, чем есть физически у сервера. Именно поэтому никакого Page Sharing (который еще и ресурсы процессора хавает, и хреново работает там, где память не простаивает) и никаких файлов подкачки на уровне гипервизора (в который случайно может угодить страничка из памяти ядра, отчего гостевая ОС выпадет в BSoD) в Hyper-V не будет. И кстати да, с vMotion нужно сравнивать не Quick Migration, а Live Migration – это немножечко разные вещи 😉