Данной статьей я открываю цикл статей, посвященных работе с памятью в Windows Server 2008 R2 SP1 Hyper-V. В принципе, в SP1 есть два интересных нововведения, касающихся Hyper-V:

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

В этом цикле статей (их будет несколько, так что запасайтесь пивом ;) будет говориться о динамической памяти. При этом конкретно о dynamic memory в Hyper-V скорее всего будет говориться только в последней из статей :)

Для чего же изначально была придумана виртуализация серверов? Как я уже рассказывал в статье «Для чего нужна виртуализация?» — одна из причин – это повышение консолидации и более рациональное использование аппаратных ресурсов. Можно либо использовать под каждую отдельную задачу отдельный сервер, который будет использовать свои ресурсы в лучшем случае на половину, либо же консолидировать их все в виде множества виртуальных серверов на одном физическом, используя его ресурсы практически на 100% и избавляясь от необходимости покупать гору железа.
Так вот, о чем же это я? А о том, что многие заказчики хотят и на елку влезть, и ничего не поцарапать, а говоря научным языком – хотят разместить как можно больше виртуальных машин на одном сервере, и при этом не потерять производительность. К сожалению, очень многие допускают ошибку еще на первом этапе – определения требований к ресурсам серверов. Простой пример: спросите любого знакомого, работающего в соответствующей сфере – сколько памяти он берет, когда заказывает новый сервер? А затем – конкретизирующие вопросы:

А если это будет веб-сервер?
— Внутренний веб-сервер для запуска бизнес приложения?
— Внешний веб-сервер, с сотнями/тысячами/десятками тысяч хитов в день?
А для файлового сервера?
— Внутренняя «файлопомойка» для, допустим, одного отдела в десяток-другой пользователей?
— Здоровенный корпоративный файл-сервер, на котором хранят документы несколько тысяч сотрудников?
А сколько памяти нужно для контроллера домена?
А для принт-сервера?
А для <вставьте свое серверное приложение сюда>

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

Ставить на все сервера по 2 (4, 8, 16, 32, etc.) Гб памяти, а если пользователи начинают жаловаться на «тормоза» — добавить еще
Посмотреть минимальные системные требования для ОС и приложений и добавить «запас» в 25% (50%, 100%, etc.) Все равно как эта память будет использоваться, лишь бы пользователи не жаловались.
Сделать так, как рекомендует вендор. Если в даташите написано, что на 100 пользователей для этого приложения нужно 4 Гб памяти – я поставлю 4 Гб плюс сколько-то про запас. Рассчеты и тестирование – это слишком долго и нудно, на это как правило нет ни времени ни желания.

Разумеется, при любом из приведенных вариантов мы получим не совсем (или совсем не) оптимальное решение. Либо приобретем памяти заведомо больше, чем необходимо, и зря потратим деньги, либо же приобретем меньше, чем нужно, и получим проблемы с производительностью. Разумеется, намного интереснее будет, если память можно будет распределять гибко, в зависимости от нагрузок, и использовать ее наиболее эффективно.

Memory Overcommitment

Раз уж зашла речь о памяти и виртуализации – невозможно не упомянуть о словосочетании, часто вызывающем горячие споры: memory overcommitment. В переводе на русский айтишный это выражение означает «выделить виртуальной машине ресурсов (в нашем случае – памяти, прим. авт.) больше, чем существует физически». То есть, грубо говоря, дать трем виртуалкам по 1 Гб памяти, когда физически у сервера имеется только 2,5 Гб. Основной причиной, почему само словосочетание «memory overcommitment» вызывало такие дикие баталии между сторонниками разных платформ виртуализации является то, что Microsoft подобных технологий не предоставляет: если у сервера есть 3 Гб памяти – то именно столько можно отдать виртуалкам, и никак не больше. Вроде бы считается, что это плохо: пропадает возможность так называемого overselling. Что есть overselling? Яркий пример – интернет-провайдеры. Они предоставляют доступ в интернет на скорости «до 8 Мбит/с», по факту же скорость скорее всего будет колебаться в районе 4-6Мбит/с из-за того, что канал на аплинк у провайдера чуть уже, чем 8Мбит, помноженное на число его абонентов. Тем не менее, при определенных фазах Луны, в полночь, когда Меркурий находится в знаке Водолея и свои любимые видеоролики в интернете никто кроме вас не просматривает – скорость вполне может достичь обещанных 8 Мбит. Если же вам захочется получить ровно 8Мбит/с и не бодом меньше – существуют тарифы с гарантированной пропускной способностью, и, как ни странно – совсем с другой ценой. Так вот, при использовании Hyper-V возможности оверселлинга нет, и потому на каждую виртуальную машину выделяется фиксированный объем оперативной памяти, который, правда, можно и поменять, но только при шатдауне гостевой ОС.
Но мы все же (я надеюсь) технари и жуткие материалисты, а по сему фазы Луны и прочая биоэнергетика нас не интересует. Так что мы с вами посмотрим, что же на самом деле кроется за фразой «memory overcommitment».
Как ни странно, однозначного мнения нет: существуют аж целых три технологии, которые можно этими словами описать. Итак, это:

Page Sharing
Second Level Paging
Dynamic Memory Balancing (a.k.a ballooning)

Следующая статья будет посвящена технологии Page Sharing, в которой будет рассматриваться подробно сама технология шаринга страниц памяти, а так же «за» и «против» ее применения. Почитать ее можно тут. В дальнейших статьях я попытаюсь рассказать о других перечисленных технологиях, а так же — о самой фиче Dynamic Memory в Windows Server 2008 R2, и почему она не подходит под термин «memory overcommitment».

Реальная виртуальность, или «640 килобайт памяти хватит всем»