Главная Virtualization, Windows, Новое Динамическая память в Hyper-V R2 SP1
  • Динамическая память в Hyper-V R2 SP1

    Как я однажды обещал – выкладываю хорошую, годную статью о Hyper-V R2 SP1 Dynamic Memory. Оригинал статьи напечатан в журнале “Windows ITPro” издательства “Открытые системы”, январь, 2011г.

    Что это, и для чего это нужно?

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

    Простой пример

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

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

    Высокая доступность

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

    img2

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

    img3

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

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

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

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

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

    Как это работает?

    До недавнего времени, как уже было замечено, статическое выделение памяти было одним из камней преткновения при внедрении инфраструктуры на базе Microsoft Hyper-V. С выходом Windows Server 2008 R2 Service Pack 1 ситуация значительно улучшилась: благодаря функционалу Dynamic Memory память теперь может перераспределяться между виртуальными машинами «на лету» в зависимости от потребностей. Соответственно, нужда в «десятикратном запасе» отпадает. Несмотря на это, Dynamic Memory подобен молотку, которым умеючи можно забить гвоздь, а неумеючи – отбить себе пальцы. Цель этой статьи – подробно рассказать о функционале Dynamic Memory и об особенностях его работы, тем самым сводя число отбитых пальцев к минимуму.

    Давайте познакомимся с основными принципами работы Dynamic Memory. Так сказать, рассмотрим под микроскопом.

    Архитектура

    Работа Dynamic Memory основывается на взаимодействии служб, работающих в Parent Partition, сиречь – ОС хоста, и компонент уровня ядра, так называемых «улучшений» в гостевой ОС. Внутри гостевой ОС работает компонента Dynamic Memory VSC (DMVSC), взаимодействующая непосредственно с диспетчером памяти гостевой ОС. VSC получает сведения о том, как используется в данный момент времени память в гостевой ОС, и передает их посредством виртуальной шины VMBus провайдеру Dynamic Memory VSP (DMVSP), работающему в окружении хостовой ОС. Он, в свою очередь, передает данные балансировщику памяти – Dynamic Memory Balancer. Балансировщик, на основании полученных данных, а так же настроек (Free Buffer, Weight, Startup/Max RAM) принимает решение о том, надо ли виртуальной машине добавить памяти, или же наоборот – у нее слишком много памяти, и излишек можно «отобрать и поделить». img5

    Команда на удаление или добавление памяти передается обратно по цепочке: Balancer – DMVSP – VMBus – DMVSC. Дальше происходит следующее:

    Добавление памяти

    Если нужно добавить памяти – то диспетчер памяти стека виртуализации выделяет виртуальной машине дополнительную память. Компонента DMVSC, используя технологию «горячего добавления памяти» расширяет адресное пространство виртуальной машины, и после этого соответствующие виртуальные адреса сопоставляются с выделенными физическими адресами. Для того, чтобы это все работало – необходима поддержка Hot Add RAM на уровне гостевой ОС. Именно этим обусловлен достаточно узкий список поддерживаемых ОС – см. «Поддерживаемые ОС».

    Удаление памяти

    Для удаления памяти используется механизм, известный как ballooning. Когда приходит команда на удаление памяти – DMVSC проверяет, какие области памяти на данный момент не используются. Из них отбирается объем, предназначенный для удаления, и затем эти адреса «захватываются» DMVSC в монопольный доступ. После этого «захвата» область памяти помечается как Driver Locked и недоступна для использования ОС и приложениями. Как только память была «захвачена» — соответствующие виртуальные адреса «отвязываются» от физических адресов, и соответствующие ячейки памяти могут быть переданы другим виртуальным машинам. В дальнейшем, если виртуальной машине нужно добавить память – соответствующее адресное пространство «освобождается», и связывается с выделенной областью памяти. Нужно отметить, что удаление памяти происходит для системы абсолютно незаметно: «захваченная» память по-прежнему остается «видна» системе, и программы типа Task Manager в гостевой ОС всегда будут показывать пиковое значение, а не текущее. Увидеть, сколько фактически было выделено памяти – из гостевой ОС невозможно, для этого нужно использовать консоль Hyper-V Manager или счетчики производительности (подробнее о них будет рассказано далее).

    Параметры настройки

    После установки SP1 на закладке «Memory» конфигурации виртуальной машины появится возможность выбора режима выделения памяти: Static/Dynamic. При выборе Static – память будет задаваться «жестко», как было до SP1. При выборе Dynamic станут активными новые параметры настройки:

    • Startup RAM
    • Maximum RAM
    • Memory Buffer
    • Memory Weight

    Рассмотрим эти параметры подробнее.

    Startup RAM

    Объем памяти, выделяемый виртуальной машине при ее запуске. По умолчанию равен 512 Мбайт. Если система не сможет выделить соответствующий объем памяти – виртуальная машина не запустится.

    Maximum RAM

    Максимальный объем памяти, который теоретически может быть выделен виртуальной машине. По умолчанию равен своему максимальному значению – 64 Гбайт.

    Memory Buffer

    Самый интересный параметр. Задается в процентах, и может принимать значения от 5% до 2000%. Дело в том, что система выделяет виртуальной машине память, основываясь на текущем потреблении памяти. Но выдавать памяти в соответствии с учением Маркса «Каждому – по потребностям» — может быть не совсем хорошей идеей. Например, виртуальная машина может периодически испытывать пиковые нагрузки. Разумеется, система тут же постарается выделить необходимый объем памяти, но, во-первых – его может не оказаться под рукой, а во-вторых – потребление памяти может возрасти настолько резко, что механизм Dynamic Memory просто не успеет среагировать, и на какое-то время производительность упадет за счет свопа. Для того, чтобы избежать подобных ситуаций – существует параметр Free Buffer, позволяющий держать определенный объем памяти свободным. Это означает, что, к примеру, если Free Buffer равен 20% — система всегда будет пытаться обеспечить, чтобы у виртуальной машины было свободно не менее 20% памяти. Free Buffer задается именно в процентах, а не в мегабайтах, потому, что зависит от текущего потребления памяти. Значение в мегабайтах можно вычислить по формуле:

    f1

    где Current Commit – суммарное потребление памяти гостевой ОС и всеми запущенными приложениями. Надо заметить, что формула эта справедлива для Windows Server 2008 RC. В Beta-версии формула была немного другая, более сложная.

    Memory Weight

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

    Memory Reserve

    Может возникнуть такая ситуация, когда виртуальные машины потихоньку «сожрут» всю память, и хостовой ОС памяти не останется. В силу особенностей архитектуры Hyper-V, нехватка памяти в хостовой ОС может иметь неприятные последствия для всех виртуальных машин, которые на ней запущены. Чтобы этого избежать – можно использовать параметр Memory Reserve, позволяющий зарезервировать определенный объем памяти для использования хостовой ОС. Зарезервированный объем будет недоступен для использования виртуальными машинами. К сожалению, этот параметр не отображается в настройках, изменить его можно только через редактирование реестра. Параметр этот можно найти в ветке HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Virtualization, называется он MemoryReserve и имеет тип DWORD. Он определяет объем резервируемой памяти в мегабайтах. Максимальное значение – 4096, то есть 4 Гбайт. Даже если установить 8192 – все равно система зарезервирует только 4 Гбайт памяти.

    Работа балансировщика

    Теперь посмотрим, как работает Dynamic Memory Balancer, и как он определяет – кому сколько выдать и у кого сколько забрать.

    Ideal Target Memory

    Для каждой виртуальной машины определяется «идеальный объем памяти». Вычисляется он по формуле:

    f2

    Это значение – идеал: столько, сколько нужно виртуальной машине для нормальной работы. И именно этот объем памяти система попытается ей выделить. А вот выделит ли – вопрос интересный.

    Memory Pressure

    Ключевой критерий – нагрузка (Memory Pressure). Нагрузка – это ни что иное как отношение Ideal Target Memory к фактически выделенной памяти:

    f3

    Этот параметр показывает, что именно происходит в данный конкретный момент с памятью на виртуальной машине: малые значения показывают, что памяти больше, чем достаточно, большие – что использование памяти подбирается к пределу. Значения, превышающие 100%, говорят о том, что памяти сильно не хватает, и виртуальная машина активно использует файлы подкачки.

    Pressure Band

    Так когда же память нужно добавить, а когда – убрать? На основании изменений нагрузки в течение времени, по каким-то одним разработчикам известным хитрым формулам, система рассчитывает максимальное и минимальное допустимые значения нагрузки, образующие диапазон – Pressure Band. До тех пор, пока текущее значение нагрузки в этот диапазон укладывается – не происходит ничего, но как только выходит за рамки – происходит следующее:

    · Если нагрузка больше максимально допустимого значения — виртуальной машине добавляется память

    · Если меньше минимально допустимого значения – излишки памяти отнимаются

    Как этим пользоваться?

    Поддерживаемые ОС

    Поскольку механизм Dynamic Memory использует компоненты как хостовой ОС, так и компоненты уровня ядра в гостевых ОС – список поддерживаемых ОС весьма ограничен.

    Со стороны хоста это следующие ОС (разумеется, с установленным SP1):

    • Microsoft Windows Server 2008 R2 Standard, Enterprise, Datacenter
    • Microsoft Hyper-V Server 2008 R2

    Гостевые ОС – следующие (при условии установки интеграционных служб):

    • Windows Server 2003 Standard, Web, Enterprise, Datacenter SP2
    • Windows Server 2008 Standard, Web, Enterprise, Datacenter SP2
    • Windows Server 2008 R2 Standard, Web, Enterprise, Datacenter SP2
    • Windows Vista Enterprise, Ultimate
    • Windows 7 Enterprise, Ultimate

    Для гостевых ОС Windows Server 2008 R2 и Windows 7 необходимо вместо обновления интеграционных компонент – установить SP1.

    Настройка

    Ну, собственно, ничего особо сложного тут нет – все настройки как на ладони, что они значат – я уже рассказывал:

    img6

    Подводные камни

    А вот теперь я упомяну о некоторых «подводных камнях», которые могут возникнуть при использовании Dynamic Memory

    Startup RAM: 512Mbytes – enough for everybody?

    При запуске виртуальной машины ей выделяется объем памяти, равный значению Startup RAM. Если требуемого объема свободной памяти нет – система попытается «отобрать» память у других виртуальных машин. Сделано это будет в первую очередь, независимо от приоритета запускаемой виртуальной машины. Если набрать требуемый объем памяти все равно не удастся – виртуальная машина не запустится. Особенно необходимо об этом помнить при планировании отказоустойчивых кластеров: может возникнуть такая ситуация, что при failover’e виртуальных машин с одного узла на другой – для запуска некоторых виртуальных машин не хватит памяти. Поэтому объем Startup RAM желательно устанавливать на минимальное значение, необходимое для запуска гостевых ОС. И только в случае, если используются «тяжелые приложения», требующие много памяти сразу на старте – Startup RAM можно увеличить.

    Maximum RAM

    Значение Maximum RAM по умолчанию равно 64 Гбайт. Это значение можно и нужно уменьшить, если используются приложения, очень «прожорливые» по памяти, или если виртуальная машина используется в тестовых целях – чтобы одна маленькая «утечка памяти» не «сожрала» всю доступную память на сервере.

    Memory Buffer & Weight

    Самое главное, о чем необходимо помнить – высокий вес виртуальной машины не гарантирует того, что ей будет выделен требуемый объем памяти. Это гарантирует лишь Free Buffer, да и он, на самом деле не гарантирует. К примеру, у нас есть две виртуальные машины. Одна из них – совсем не критична, и вес у нее установлен минимальный. Но Free Buffer у нее стоит на максимальном значении – 2000%. Другая же виртуальная машина для нас очень важна, и мы установили ей максимальный вес, но Free Buffer – минимальный – 5%. Что же произойдет? А произойдет вот что: виртуальная машина с большим Free Buffer несмотря на свой маленький вес заберет себе практически всю доступную память, и когда виртуальная машина с высоким приоритетом захочет получить дополнительную память себе – система не сможет ей эту память выделить. Чтобы избежать подобных ситуаций, нужно грамотно выставлять значение Free Buffer, и увеличивать его только тогда, когда это реально необходимо. Например, если виртуальная машина может испытывать периодические пиковые нагрузки. Или, например, если необходим некоторый объем свободной памяти для файлового кэша. Ну а если не хочется «играться с настройками» — всегда можно задать статический объем памяти.

    Файлы подкачки

    Для работы Dynamic Memory необходим файл подкачки в гостевой ОС. Минимальный его размер должен «перекрывать» наиболее ресурсоемкие приложения. Что это означает? Допустим, у нашей виртуальной машины остается всего 100 Мбайт свободной памяти. И сконфигурирован размер файла подкачки – 100 Мбайт. Если некое приложение попытается запросить за один раз 400 Мбайт памяти – система просто не сможет столько памяти выделить: лимит выделения всего 200 Мбайт. Если же приложение будет запрашивать 2 раза по 200 Мбайт, то 200 Мбайт система выделит за счет файла подкачки, в это время виртуальной машине будет выделена дополнительная память, и второй раз 200 Мбайт будет выделено приложению. Поэтому минимальный размер файла подкачки должен быть таким, чтобы перекрыть такие «большие запросы».

    Мониторинг

    Как же посмотреть, что именно происходит с нашими виртуальными машинами? Как уже было сказано, изнутри гостевой ОС ничего увидеть невозможно. Увидеть можно из хостовой ОС – через консоль Hyper-V Manager и через счетчики производительности.

    Hyper-V Manager

    img7

    В оснастке Hyper-V Manager имеются следующие колонки:

    • Assigned Memory – сколько памяти было фактически выделено виртуальной машине
    • Memory Demand – сколько памяти виртуальная машина запрашивает у системы (та самая Ideal Target Memory)
    • Memory Status – состояние памяти: статус «ОК» – означает, что все в порядке, у виртуальной машины есть как минимум 80% свободной памяти, «Low» значит, что памяти все еще больше, чем минимально необходимо, но меньше 80%, а «Warning» означает, что все плохо, памяти  не хватает и виртуальная машина начала использовать подкачку.
    Счетчики производительности

    Для более детального анализа можно использовать счетчики производительности из оснастки Perfmon. С Dynamic Memory связаны две группы счетчиков: Hyper-V Dynamic Memory Balancer и Hyper-V Dynamic Memory VM. Первая группа относится ко всему хосту в целом, а вторая – позволяет мониторить параметры отдельных виртуальных машин.img8

    Заключение

    Ну вот моя статья и подошла к концу. Я попытался объяснить суть технологии Dynamic Memory и то, как с этим всем управляться.

    Надеюсь, статья была вам полезна. И еще больше – я надеюсь, что RTM Service Pack 1 не будет так отличаться от RC, как RC от Beta – все-таки много времени и сил было потрачено впустую.

    Если у вас возникнут какие-либо вопросы – милости прошу в e-mail: lcd.admin@gmail.com или же комментарий тут Подмигивающая рожица

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

    MVP: Virtual Machine

Комментарии

  1. Спасибо.

    Доступно. Понятно.

    Интересно, что будет с динамической памятью при живой минрации?

  2. [...] This post was mentioned on Twitter by Andrey Beshkov and Mike Shishov, IT. IT said: Динамическая память в Hyper-V R2 SP1: Как я однажды обещал – выкладываю хорошую, годную статью о Hyper-V R2 SP1 ... bit.ly/g5HYGV [...]

  3. @1

    Ну ничего плохого не будет. Смигрирует тот объем памяти, который есть у виртуалки на момент самой миграции. Принцип тот же самый, на этом сайте есть моя статья о Live Migration.

  4. Отличная статья, спасибо! На хабре надеюсь будет (интересно почитать войну VMWare/HyperV)?

  5. На хабре скорее всего не будет — красноглазики мне в карму поднасрали)))

    А война, думается, и тут может начаться — если эту статью увидит, например, Антон Жбанков :)

  6. Антон ее уже увидел :)

  7. ...тогда зрители ждут рассказа про маркетинговую политику Microsoft

  8. Антона реально не хватает, вот реально, я имя опыт не единожды работы с продуктами компании VMWare, снова решил рассмотреть серьезно для виртуализации благодаря только ему, когда он как истиный «евангелист» рассказывал/показывал разные возможности =) приводил статьи и т.п.

    Интересно будет пощупать данный функционал после выхода в RTM, хотя честно слабо представляю где у себя ее применять... Эксчендч не вижу смысла так ужимать, у DC тоже более менее понятное потребление, какой нибуть бекап сервер или там шарепоинт и все...

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

  10. @8

    >Антона реально не хватает

    Угу. С ним, помнится, статьи по виртуализации обсуждались ну очень весело — холивар такой был, что Win-vs-Lin просто курит в уголку.

    >Интересно будет пощупать данный функционал после выхода в RTM

    Угу, интересно. Вообще в RC по сравнению с бета-версией относительно Dynamic Memory были сильные изменения. В RTM вроде обещают, что таких «глобальных перекроев» не будет.

    > Эксчендч не вижу смысла так ужимать, у DC тоже более менее понятное потребление, какой нибуть бекап сервер или там шарепоинт и все...

    Во-первых Dynamic Memory это не «ужимание». Dynamic Memory позволяет не заморачиваться с сайзингом памяти для виртуалок. Эксчендж — как раз можно. К примеру, в 9:00 утра, когда все пришли на работу и открыли Outlook — нагрузки будут достаточно высокими, а в обед, когда никто никому не пишет ничего — нагрузка упадет, и излишек памяти можно отдать кому-нибудь другому — например, серверу бэкапов, который как раз в это время бэкапит базы. Самое главное — DM позволяет не думать, сколько кому дать памяти — распределяя память автоматически.

    @9

    >Н-р под SQL это точно не следует пользовать.

    Ну SQL с высокими нагрузками вообще ЕМНИП виртуализировать не рекомендуют.

  11. Коллеги, кто-нибудь знает, RTM когда выходит?

  12. @11

    Точной даты не называют, но уверяют, что в 1м квартале этого года.

  13. а разве SP1 не доступен? :)

  14. @13 доступен пока только release candidate 😉

  15. @10

    >Ну SQL с высокими нагрузками вообще ЕМНИП виртуализировать не рекомендуют

    А я про любой SQL, даже под WSUS. Ибо SQL любит память, и сожрет всё, что ему дадут. И не отдаст!

  16. Со вчерашнего дня SP1 RTM доступен подписчикам Technet и MSDN и клиентам Volume Licensing.

    C 22-го февраля будет доступен всем желающим бесплатно.

  17. Спасибо за содержательную статью. Но вот вопрос у меня возник: в реестре, в ветке HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Virtualization на моем сервере нет параметра MemoryReserve. Как мне быть в случае если виртуалки заберут всю память под себя.

  18. Создать этот параметр. Ваш К.О.

  19. [...] 21-Flukostat > Дык разные уровни бывают. Бывает уровень 100, бывает 200 а бывает и 300. Например itband.ru/2011/01/hyper-v... -dynamic-memory/ [...]

Опубликовать

Я не робот.