Linux Integration Services v2.1 теперь доступны.

Очередной перевд, я уже переводил анонс к бета-версии, и вот наконец-то полноценный релиз, надеюсь информация окажется ценной.

Ссылка на оригинал: Virtualization Team Blog

Linux Integration Services v2.1 теперь доступны.

Мы очень рады объявить о доступности Hyper-V Linux Integration Services для Linux версии 2.1. Эта версия является еще одной вехой в создании всесторонней платформы виртуализации для наших клиентов. Клиенты, которые владеют гетерогенным окружением операционных систем стремятся сделать свою платформу виртуализации способной поддерживать все операционные системы, которые находятся в их центре обработки данных. Мы поддерживаем Linux в качестве гостевой операционной системы, на наших платформах виртуализации, начиная со времен Virtual Server и продолжаем расширять нашу поддержку в этом направлении.

Следующие компоненты включены в версию 2.1:

• Поддержка драйверов для синтетических устройств (Driver support for synthetic devices): Linux Integration Services поддерживает синтетические сетевые контроллеры и синтетические контроллеры накопителей, которые были разработаны специально для Hyper-V.
• Поддержка быстрой загрузки для Hyper-V (Fastpath Boot Support for Hyper-V): Загрузочные устройства используют блок виртуализации служб клиента (Virtualization Service Client, VSC) для предоставления повышенной производительности.
• Синхронизация времени (TimeSync): Часы внутри виртуальной машины будут синхронизироваться с часами хоста.
• Интегрированное выключение (Integrated Shutdown): Виртуальные машины с запущенным Linux могут быть корректно выключены при помощи диспетчера Hyper-V или System Center Virtual Machine Manager.
• Поддержка Symmetric Multi-Processing (SMP): Поддерживаемые дистрибутивы Linux могут использовать до 4 виртуальных процессоров в одной виртуальной машине.
• Heartbeat: Позволяет хосту определять запущена ли гостевая система и отвечает ли она на запросы.
• Подключаемые источники времени (Pluggable Time Source): Встроенный модуль подключения источников времени предоставляет более точный источник времени гостевой системе.

Эта версия служб интеграции для Hyper-V поддерживает Novell SUSE Linux Enterprise Server 10 SP3 SUSE Linux Enterprise Server 11, и Red Hat Enterprise Linux 5.2 / 5.3 / 5.4 / 5.5.

Клиенты могут получить Linux IC через Microsoft Download Center по этой ссылке: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=eee39325-898b-4522-9b4c-f4b5b9b64551.

Переменные в Windows PowerShell 2.0

Продолжаю серию веб-кастов посвященных Windows powerShell 2.0. На этот раз разбираем использование различных переменных в оболочке и сценариях Windows PowerShell.

Подробности и видео: LebedevUM

Динамическая память (Dynamic Memory) приходит в Hyper-V Часть 6.

Представляю перевод последней публикации из серии Dynamic Memory, в данной публикации описано при помощи каких настроек можно управлять Hyper-V Dynamic Memory, а также разобраны примеры описывающие каким образом работает динамическая память. Ссылки на оригиналы и переводы оставльных публикаций есть в конце или на LebedevUM.

Ссылка на оригинал: Virtualization Team Blog

Динамическая память (Dynamic Memory) приходит в Hyper-V Часть 6.

======================================================

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

======================================================

В нескольких предыдущих публикациях мы рассматривал Страничное распределение (Page Sharing) и Второй уровень подкачки (Second Level Paging). Сегодня давайте будем копать, то что предоставляет динамическая память Hyper-V в Windows Server 2008 R2 SP1, а также в наш бесплатный гипервизор Microsoft Hyper-V Server 2008 R2 SP1. Итак, что же такое динамическая память (Dynamic Memory)?

Динамическая память (Dynamic Memory) - это расширение Hyper-V R2, которое объединяет всю доступную память на физическом хосте и динамически распределяет ее по мере необходимости между запущенными на хосте виртуальными машинами. Это означает, что основываясь на изменениях рабочих нагрузок, виртуальные машины смогут получить новое пространство в памяти без остановок служб, через балансировку динамической памяти (Dynamic Memory Balancing). Одним словом, Динамическая память (Dynamic Memory) - это и есть динамическая память.

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




Динамическая память в глубине.

В Hyper-V (V1 & R2), память статически назначалась виртуальным машинам. Смысл заключается в том, что вы назначаете память виртуальной машине, и когда она включается Hyper-V размещает и предоставляет эту память виртуальной машине. Эта память занимается до тех пор пока виртуальная машина запущена или приостановлена. Когда виртуальная машина сохранена или выключена память освобождается. Ниже представлено изображение, на котором показано назначение памятив Hyper-V V1/R2.


У динамической памяти Hyper-V есть два значения: Startup RAM (Начальный объем памяти) и Maximum RAM (Максимальный объем памяти), выглядит это вот так:


Startup RAM (Начальный объем памяти) это объем памяти во время инициализации/запуска виртуальной машины. Когда виртуальная машина запущена этот объем памяти будет выделен виртуальной машине. В данном примере виртуальная машина будет запускаться с 1 Гб памяти.

Свойство Maximum RAM (Максимальный объем памяти) это максимальный объем памяти до которого гостевая операционная сможет дорасти, в данном случае до 64 Гб памяти (при условии, что операционная система поддерживает такой объем памяти). На основе перечисленных выше настроек, вот пример того, как память будет выделяться в течении рабочего дня.



Как вы можете видеть, рабочая нагрузка динамически выделяет память в зависимости от потребностей.

Далее, давайте посмотрим на Memory Buffer (Буфер памяти).

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

Мы полностью согласны.

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

Буфер динамической памяти определяет специфику памяти, доступной в виртуальной машине в целях кеширования файлов (например SuperFetch) или свободной памяти. Диапазон таких значений от 5 до 95. Цель буфера памяти заключается в определении процента свободной памяти от текущей используемой памяти. Целевой процент буфера памяти 20%, это значит, что в виртуальной машине, где используется 1 Гб, 250 Мб будут "свободными" (или доступными), общий объем памяти виртуальной машины будет составлять 1,25 Гб. По умолчанию, динамическая память Hyper-V использует значение буфера 20%. Если вы находите это значение слишком консервативным или не достаточно консервативным, вы можете изменить его на лету, пока виртуальная машина запущена без выключения.


Это подводит нас к последней настройке динамической памяти (Dynamic Memory), Memory Priority (Приоритет памяти).

Memory Priority (Приоритет памяти): По умолчанию все виртуальные машины создаются с равным значением приоритета памяти. Однако, вы, скорей всего, захотите изменить приоритет памяти, в зависимости от рабочей нагрузки. Для примера, Я предвижу сценарий, в котором вы захотите установить контроллеру домена больший приоритет памяти, нежели чем серверу печати какого-нибудь отдела. Приоритет памяти - это настройка каждой отдельной виртуальной машины, она указывает на приоритетность виртуальной машины при распределении памяти, относительно других виртуальных машин. По умолчанию приоритет памяти установлен в "Средний". Если вы посчитаете необходимым изменить этот параметр, вы можете сделать это на лету, в тот момент, когда виртуальная машина запущена, без ее остановки.




Динамическая память с течением времени работает с несколькими виртуальными машинами...

Я рассказывал про настройки каждой виртуальной машины и показывал как они будут работать с одной виртуальной машиной, но как динамическая память (Dynamic Memory) будет работать с несколькими виртуальными машинами? Ниже есть пример того, как динамическая память (Dynamic Memory) работает. Я специально хранил этот пример, чтобы избежать путаницы. Предположим, что у меня есть сервер с 8 Гб памяти. Я собираюсь запустить три виртуальные машины, по одной из финансовой службы, отдела продаж и отдела проектирования. Каждой виртуальной машине я дам одинаковые настройки: Sturtup RAM (Начальный объем памяти) = 1 Гб и Maximum RAM (Максимальный объем памяти) = 4 Гб. С такими настройками каждая виртуальная машина будет включаться с 1 Гб памяти и сможет увеличить свой объем памяти до 4 Гб, в случае необходимости.

Запуск виртуальных машин. на графике представленном ниже в левой части можно увидеть три запущенных виртуальных машины. Каждая виртуальная машина использует 1 Гб памяти. В правой же части графика можно видеть общий объем памяти, используемый всей системой ~3 Гб.


15 минут спустя. Виртуальная машина финансовой службы запускает отчеты, в то же время виртуальная машина отдела проектирования делает аналитическую работу. При помощи динамической памяти (Dynamic Memory), виртуальной машине финансовой службы выделено 3 Гб памяти, виртуальной машине отдела проектирования выделноо 2 Гб памяти, а виртуальная машина отдела продаж осталась с 1 Гб. В масштабах все системы, сервер использует 6 Гб из 8 Гб, или 75% от всей физической памяти.


30 минут спустя. Виртуальная машина финансовой службы работает с отчетами, в то время как виртуальная машина отдела проектирования выполняет аналитическую работу. При помощи динамической памяти (Dynamic Memory), виртуальной машине финансовой службы, выделено 2 Гб памяти, виртуальной машине отдела проектирования выделенно 3,5 Гб памяти, виртуальная машина отдела продаж осталась с 1 Гб памяти, и четвертая служебная виртуальная машина запущена с использованием 1 Гб памяти. В масштабах всей системы, сервер теперь использует 7,5 Гб памяти для виртуальных машин из 8 Гб. На данный момент сервер полностью распределил ресурсы памяти и использует ее наиболее эффективно.


И вот теперь вопрос, который я постоянно задаю: "Что теперь? Что если виртуальной машине нужно еще памяти? Нужно ли запускать подкачку на стороне родительской системы?"

Нет.

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



Превышение лимита и аналогии с процессором.

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

Отличная аналогия, но неправильный вывод.

Пример 1: Предположим вы работаете на 8 физических серверах и используете их на 10%, виртуализовав их и запустив эти 10 виртуальных машин на одном выделенном сервере, вы будете использовать его ~85%. В этом примере вы не превышали лимит и сервер до сих пор не использовал 15%.

Вот что такое превышение лимита...

Пример 2: Предположим вы работаете на 8 серверах и используете их на 50%, виртуализуете их и запускаете эти 8 виртуальных машин на одном сервере. Один сервера может максимально использоваться на 100%, но рабочая нагрузка требует использовать его ~400%, производительность будет ужасной. Что бы вы сделали? Конечно же переместили бы виртуальные машины на другие серверы, чтобы избежать превышения лимита. Если сказать короче, то что бы вы делали, чтобы максимизировать использование ресурсов для получения наилучшего распределения ресурсов и производительности.

Это именно то что мы делаем при помощи Hyper-V Dynamic Memory.



Требования клиентов и динамическая память.

Когда речь заходит о виртуализации и памяти, пользователи виртуализации неоднократно предъявляли следующие требования:

1. Использовать физическую память настолько эффективно и динамично, насколько это возможно, с минимальными потерями производительности. Клиенты вкладываю в виртуализацию хостов, выбирая системы с большими конфигурациями памяти (32 Гб, 64 Гб, 128 Гб и больше) и хотят полностью использовать возможности системы. В то же время они покупают эту память, чтобы предоставить высочайшую производительность и избежать подкачки.
2. Обеспечить устойчивую производительность и масштабируемость. Один из частых ответов от пользователей виртуализации это то, что они не хотят компонентов, с возможными срывами производительности или переменной производительностью. Это затрудняет управление и увеличивает общую стоимость владения.

Вы получили это. Вот почему мы выбрали динамическую память (Dynamic Memory):

1. Dynamic Memory, это действительно динамическое решение. Память выделяется виртуальным машинам на лету, на основе политики, без остановки виртуальной машины.
2. Dynamic Memory позволяет избежать значительных потерь производительности, потому как не добавляет новые уровни подкачки, которые могут существенно повлиять на производительность.
3. Dynamic Memory использует большие страницы памяти и оптимизирована под использование больших страниц памяти.
4. Dynamic Memory - это отличное решение для виртуализации серверов и настольных систем (кстати, Dynamic Memory отлично работает с SuperFetch).

Ура,

Jeff Woolsey

Principal Group Program Manager

Windows Server & Cloud, Virtualization

P.S. Здесь ссылки на все публикации из этой серии:

• Часть-1: Оригинал; Перевод.
• Часть-2: Оригинал; Перевод.
• Часть-3: Оригинал; Перевод.
• Часть-4: Оригинал; Перевод.
• Часть-5: Оригинал; Перевод.

Установка Windows SharePoint Service 3.0

Здравствуйте коллеги, открываю новую серию веб-кастов, посвященных WSS, собственно, представляю вам первый из этой серии: "Установка Windows SharePoint Services 3.0".

Подробности и видео: LebedevUM

Windows PowerShell и командная строка Windows

Продолжаю серию веб-кастов, посвященных Windows PowerShell. Данный веб-каст посвящен способам использования Windows PowerShell из командной строки Windows и из командный файлов Windows, а также представлено создание нового экземпляра со специальными параметрами из PowerShell. Демонстрация проходит на операционной системе Microsoft Windows 7 Ultimate (x32).

Подробности и видео: LebedevUM

Сценарии в Windows PowerShell 2.0

Продолжаю серию веб-кастов, посвященных Windows PowerShell. В этом веб-касте демонстрирую аспекты создания и использования сценариев в Windows PowerShell 2.0. Демонстрация проходит на Microsft Windows 7 Ultimate (x32).

Подробности и видео: LebedevUM

Динамическая память (Dynamic Memory) приходит в Hyper-V Часть 5.

Итак, в центре внимания второй уровень подкачки, очередная публикация из серии "Dynamic Memory coming to Hyper-V". Так как объем приличный, буду переводить частями, постепенно дополняя эту публикацию.

Ссылка на оригинал: Team Virtualiazation Blog.

Динамическая память (Dynamic Memory) приходит в Hyper-V Часть 5.

======================================================

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

======================================================

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

Виртуальная память на высоком уровне

Современные операционные системы используют виртуальную память. Виртуальная память представляет способ увеличения эффективного объема памяти компьютера, за счет использования дискового файла (как области подкачки) для имитации дополнительного объема памяти. Операционная система отслеживает адреса памяти, которые на самом деле располагаются в памяти и какие должны быть привлечены с диска в случае необходимости. Вот несколько общих функций управления памятью, реализуемых современными операционными системами:

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

Виртуальная память в глубинах.

Давайте погрузимся в глубины. Для этого, я буду ссылаться на статью TechNet, в которой обсуждается диспетчер виртуальной памяти Windows. Если вы желаете прочитать статью целиком, то она здесь: http://technet.microsoft.com/en-us/library/cc767886.aspx. Второй статьей я настоятельно рекомендую публикацию о виртуальной памяти от Марка Руссиновича: http://blogs.technet.com/markrussinovich/archive/2008/11/17/3155406.aspx.

Из статьи TechNet:

Распределение физической памяти компьютера.

Операционные системы, которые поддерживают многозадачность, позволяют программному коду и данным от различных приложений существовать в физической памяти компьютера (оперативная память [random access memory]) в одно и то же время. В обязанности операционных систем входит контроль за тем, чтобы физическая память распределялась настолько эффективно, насколько это возможно и чтобы память не расходовалась в пустую. В результате диспетчер памяти операционной системы вынужден бороться с проблемой, называемой фрагментация памяти. Фрагментация памяти относится к ситуации, когда свободная (доступная) память разбивается на маленькие разрозненные части, которые не являются достаточно большими, чтобы они могли быть использованы приложениями. В примере, обсуждаемом здесь, свободная память разделена на три отдельных блока:

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

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

Виртуализация доступа к памяти.

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

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

Расширение виртуальной памяти за счет подкачки.

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

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

Подкачка делается для увеличения объема виртуальной памяти, доступной на компьютере. Диспетчер памяти производит подкачку "за кулисами", в результате получается так, как будто компьютер имеет больше физической памяти, чем есть на самом деле. Фактически, виртуальная память, доступная на компьютере, равна физической памяти плюс все место на жестком диске, которое диспетчер виртуальной памяти использует для временной записи кода и данных.

Загрузка выгруженного кода и данных по требованию.

Если приложение пытается получить доступ к коду или данным, которые не находятся в физической памяти (которые выгружены на диск) диспетчер виртуальной памяти забирает управление. Диспетчер виртуальной памяти находит (или создает) доступные блоки свободной памяти, затем копирует необходимый код и данные в эти блоки, так чтобы они были доступны. Приложения не знают куда именно на диск были выгружены код и данные. Код и данные автоматически загружаются в физическую память диспетчером виртуальной памяти, когда приложение нуждается в их использовании.

Ключевые моменты:

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

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

Статическая память и подкачка только на стороне гостевых операционных систем.

Сегодня с Hyper-V (V1 & R2), память статично назначается на виртуальную машину. Это означает, что вы назначаете память виртуальной машине и когда она включена Hyper-V выделяет и предоставляет эту память виртуальной машине. Эта память удерживается до тех пор пока виртуальная машина запущена или приостановлена. Когда виртуальная машина сохраняется или выключается эта память освобождается. Ниже приведен снимок того, как сегодня происходит назначения памяти виртуальной машине:


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


Хорошо, давайте теперь погрузимся на второй уровень подкачки.

Второй уровень подкачки (Second Level Paging): Что это?

Второй уровень подкачки (Second Level Paging, SLP) - это технология, в которой платформа виртуализации создает второй уровень абстракции памяти и в момент перегрузки системы выгружает файлы, созданные на уровне виртуализации в область подкачки на диск. С SLP, вы имеете два яруса подкачки на диск: один расположен в гостевой операционной системе и еще один расположенный ниже на уровне виртуализации. Вот еще одна схема, которая иллюстрирует то, как второй уровень подкачки размещается. Вновь, есть четыре запущенные виртуальные машины и каждое ядро гостевой операционной системы управляет своей собственной памятью. Однако, заметьте, что ниже, расположен второй уровень подкачки, которым независимо управляет платформа виртуализации.


Один из распространенных доводов в пользу второго уровня подкачки, который я слышал это: "Если Windows и другие современные операционные системы используют подкачку сегодня, тогда почему это плохо для использования с виртуализацией?"

Хороший вопрос.

Ответ: Производительность.

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

Выгрузка ядра гостевой системы.

Выгрузка ядра гостевой системы это пример, в котором виртуализация создает проблему, которой не существует в физических системах. В ядре операционной системы есть специальные области, которые ядро операционной системы никогда не выгружает на диск в целях увеличения производительности. Это тема, в которой Microsoft и VMWare согласны друг с другом и VMWare много раз заявляет об этом в своей документации.

«...подкачка гипервизора это гарантированная технология освобождения определенного объема памяти в течении определенного времени. Однако, подкачка гипервизора, может серьезно отразиться на производительности гостевой системы. Это происходит в тот момент, когда гипервизор, не обладая сведениями о том что хранится в страницах физической памяти гостевой системы, выгружает их, и такая выгрузка может привести к непредвиденным взаимодействия с родной политикой управления памятью гостевой операционной системы. Для примера, гостевая операционная система никогда не выгружает страницы ядра, поскольку они имеют решающее значение в производительности ядра операционной системы. Гипервизор, в свою очередь, не может определить, какие страницы памяти принадлежат ядру и поэтому он может выгрузить их. В дополнение, гостевая операционная система восстанавливает чистые страницы буфера, путем их сброса. Опять же, поскольку гипевизор не может определить чистые страницы буфера гостевой системы, это может привести к бесполезной выгрузке их на устройство подкачки гипервизора, для того, чтобы вернуть физическую память хоста.»

Понимание управления ресурсами памяти в VMware ESX Server стр. 9-10;
http://www.vmware.com/resources/techresources/10062

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

Производительность памяти против производительности диска.

Наконец, сравнение производительности, или, если быть точнее, отсутствие сравнения, потому что не может быть никакого сравнения между памятью и диском. И это бесспорно. Это факт. Давайте немного посчитаем. Предположим, что у типичного диска время отклика составляет ~8 миллисекунд. А время отклика при доступе к памяти измеряется в наносекундах:

• DDR3-1600 = 5 наносекунд
• DDR3-1333 = 6 наносекунд
• DDR3-1066 = 7.5 наносекунд
• DDR3-800 = 10 наносекунд

Так что, если вы хотите сравнить доступ к диску с доступом к памяти DDR-3 1600, то формула выглядит следующим образом: 0,008/0,000000005. Здесь приведены результаты вычислений:

• Память DDR3-1600 в 1600000 раз быстрее чем диск.
• Память DDR3-1333 в 1333333 раза быстрее чем диск.
• Память DDR3-1066 в 1066666 раз быстрее чем диск.
• Память DDR3-800 в 800000 раз быстрее чем диск.

Мы много раз слышали, как пользователи виртуализации говорят, что производительность второго уровня подкачки "не так уж плоха". Я не знаю как можно говорить, с серьезным выражением лица, что разница в производительности в 6 десятков не так уж плоха. Можно ли отбросить перспективу в 1,6 миллионов раз, предположим вам требуется час на одну милю ходьбы. Если вы можете путешествовать в 1,6 миллиона раз быстрее, вы могли бы совершить путешествие к Сатурну и обратно за этот час. (Сатурн расположен на расстоянии примерно 746 миль от Земли.)

Microsoft и VMWare согласны друг с другом: Избегайте превышения объема.

Это факт, что подкачка на диск существенно снижает производительность и вы должны предотвращать это, нужно отметить что это еще одна область, в которой Microsoft и VMWare согласны друг с другом. Это не новое руководство, поэтому я включил примеры из ESX 3 и VSphere.

Из VMWare:

Пример 1: Убедитесь что хост обладает большим объемом физической памяти, чем будет использовано ESX вместе с суммарным объемом рабочей памяти, используемой всеми виртуальными машинами в любое время.

--Performance Tuning Best Practices for ESX Server 3 [Лучшая практика настройки производительности для ESX Server 3].

Пример 2: Если рабочий объем памяти настолько велик, что активные страницы постоянно выгружаются и загружаются (высок объем обмена станицами с областью подкачки), то это может привести к значительному снижению производительности. Чтобы избежать подкачки в конкретной виртуальной машине, пожалуйста настройте резервирование памяти для нее (через VI Client) по крайней мере равный объему рабочей памяти. Но будьте осторожны, потому что настройка резервирования ресурсов может сократить число виртуальных машин, которые вы можете консолидировать в системе.

--Performance Tuning Best Practices for ESX Server 3 страниа 15 [Лучшая практика настройки производительности для ESX Server 3].

Пример 3: ESX, также использует подкачку на уровне хоста, для того чтобы вернуть память из виртуальной машины. Так как это будет выгрузка активных страниц, это существенно снизит производительность виртуальных машин.

--Performance Tuning Best Practices for VSphere страница 23 [Лучшая практика настройки производительности для VSphere].

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

Финальная точка во втором уровне подкачки.

• Второй уровень подкачки нарушает фундаментальное предположение о том, что гостевые операционные системы имеют точное представление о физической памяти.
• Производительность памяти по отношению к диску от 800000 раз до 1600000 раз быстрее.
• Когда система превышает объем памяти, второй уровень подкачки может нанести существенный удар по производительности. Проще говоря, чем больше система превышает объем памяти, тем больше он выгружает на диск и это приводит к падению производительности всей системы.

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

Ура,

Jeff Woolsey

Principal Group Program Manager

Windows Server, Virtualization

Microsoft RemoteFX: Закрывает разрыв пользовательских возможностей.

Очередной перевод публикации, посвященной подробностям реализации перенаправления устройств при помощи перенаправления RemoteFX USB.

Ссылка на оригинал: Team Virtualization Blog.

Microsoft RemoteFX: Закрывает разрыв пользовательских возможностей.

Привет, Max Herrmann, из команды Windows Server RDS в Microsoft, снова здесь. В прошлом месяце я писал о Microsoft RemoteFX - ключевой возможности платформы RDS, которую мы вводим с Windows Server 2008 R2 SP1 и которая разработана для предоставления сокровищ мультимедиа, подобных работе за настольной системой пользовательских возможностей для виртуальных и терминальных рабочих столов и приложений. Анонс Microsoft RemoteFX создал большое оживление, особенно среди партнеров по программному и аппаратному обеспечению, которые уже работают над решениями с добавлением новых возможностей. И почему же Microsoft RemoteFX так важен? Потому что это поддержка полного качества видео, а также богатства мультимедиа и 3D графика, они помогут закрыть разрыв между возможностями пользователя сидящего за физической настольной системой и удаленным пользователем, подключающимся к виртуальному рабочему столу.

Сегодня, я хочу представить другой аспект Microsoft RemoteFX и как можно больше помочь в закрытии разрыва пользовательских возможностей между физическим и виртуальным рабочим столом: Клиенты, рассматривая инфраструктуру виртуальных рабочих столов (Virtual Desktop Infrastructure, VDI), ожидают, что их пользователи смогут работать с любыми периферийными устройствами на своих клиентских устройствах и видеть работу с виртуальным рабочим столом такой же, как если бы это была физическая настольная система.

На сегодняшний день ситуация такова, что протокол удаленного рабочего стола (Remote Desktop Protocol, RDP) обеспечивает только определенного вида перенаправление на высоком уровне (такие как: перенаправление принтеров, перенаправление дисковых устройств, перенаправление устройств Plug and Play, и так далее). Однако, из-за самых разнообразных типов устройств и разницы в качестве и доступности драйверов, невозможно обеспечить единый высокий уровень решения для перенаправления устройств для каждого устройства через каждую платформу, использующую RDP. В результате решения завязанные на специфике устройств необходимы для каждого типа устройств.

Гораздо лучше решение для перенаправления устройств на уровне USB (или если быть точнее, блок запросов USB или уровень URB). Именно этот тип решения мы выбрали для рабочих столов VDI, никакие драйвера устройств не нужны на клиентском устройстве и мы можем предоставить универсальный интерфейс, который будет работать с любым устройством USB и на любой из поддерживаемых платформ. Это решение в состоянии успешно перенаправить большинство устройств, используемых пользователями, включая устройства ввода/вывода звука, устройства хранения, HID-совместимые устройства (планшеты, клавиатуры и так далее), принтеры и сканеры.

Как и богатые мультимедиа расширения, где возможности отправки RemoteFX будут добавлены к существующей клиентской отправке в RDP, так и перенаправление RemoteFX USB будет добавлено к существующим возможностям перенаправления устройств в RDP, а не заменят их.

Если вы один из множества наших клиентов, успешно внедривших централизованную архитектуру рабочих столов на основе терминальных служб в прошлом или вы планируете перейти на VDI или виртуализацию сессий при помощи служб удаленного рабочего стола в Windows Server 2008 R2 SP1 , новые возможности RemoteFX, значительно расширят пользовательские возможности ваших удаленны пользователей.

Как я и сказал в одной из моих предыдущих публикаций, это только начало для потрясающего времени прихода централизованных настольных систем и преимуществ усовершенствований пользовательских возможностей, которые предоставляет Microsoft RemoteFX. Так что проверяйте мои публикации каждый раз, когда хотите узнать что-то новое и интересное про Microsoft RemoteFX.

Max

Инструменты Windows PowerShell 2.0

В последнее время, довольно часто сталкиваюсь с вопросами о PowerShell, а еще чаще с вопросом, а как начать работать с PowerShell, поэтому начинаю серию веб-кастов, посвященных Windows PowerShell, первый веб-каст из серии называется: "Инструменты Windows PowerShell 2.0" он расскажет об основных инструментах для работы и о принципах использования командлетов (cmdlets), работы со справочником команд и со справкой по командам.

Веб-каст и дополнительная информация: LebedevUM

Новая версия Microsoft Security Essentials теперь доступна!

Мне на lebedev.yuriy@gmail.com пришел вопрос о том, как защитить компьютер под управлением Microsoft Windows от вирусов, как мне кажется данный перевод отетит на все вопросы.

Ссылка на оригинал: MicrosoftFeed

Новая версия Microsoft Security Essentials теперь доступна!

Microsoft выпустила бета версию Microsoft Security Essentials. Программа Securit Essentials - это бесплатный набор утилит для любых пользователей Windows, для защиты от вредоносных программ, отравляющих мир компьютеров Windows.

Microsft Security Essentials - бесплатно загружается с сайта Microsoft, легко устанавливается, проста в использовании и регулярно проверяет и загружает обновления, поэтому вы можете быть уверены, что ваш компьютер защищен новейшими технологиями. Это очень легко сказать защищен ли ваш компьютер - если вы зеленый, то все у вас хорошо. Это очень просто. Новые компоненты бета-версии Microsoft Security Essentials включают:

• Windows Firewall integration (Интеграция с Брандмауэр Windows) - во время установки Microsoft Security Essentials спросит вас, не желаете ли вы включить или выключить Брандмауэр Windows Windows Firewall.
• Enhanced protection for web-based threats (улучшенная защита от веб-угроз) - Microsoft Security Essentials теперь интегрируется с Internet Explorer для предоставления защиты от веб-угроз.
• New protection engine (Новое ядро защиты) - новое анти-вирусное ядро обладает улучшенным обнаружением и возможностями очистки с лучшей производиельностью.
• Network inspection system (Система контроля сети) - Защита от сетевых атак теперь встроена в Microsoft Security Essentials.

Для загрузки бета-версии Microsoft Security Essentials, нажмите здесь, и вы перейдете на страницу Microsoft Connect для регистрации на получение бета-версии. По завершении вы получите инструкции для загрузки и установке бета-версии.

Динамическая память (Dynamic Memory) приходит в Hyper-V Часть 4.

Итак, продолжение перевод цикла статей посвященных Dynamic Memory, данная публикация продолжает предыдущую расставляя все точки в вопросах о страничном распределении памяти.

Ссылка на оригинал: Team Virtualization Blog

Динамическая память (Dynamic Memory) приходит в Hyper-V Часть 4.

======================================================

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

======================================================

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

Вопросы

Вопрос: Когда вы говорите что Hyper-V R2 поддерживает большие страницы памяти, это означает что Hyper-V использует распределение страниц памяти по 2 Мб или она предоставляет большие страницы памяти гостевой системе или и то и другое?

Ответ: И то и другое.

1. Поддержка больших страниц памяти в Hyper-V R2 означает, что если эти возможности поддерживаются оборудованием, то Hyper-V R2 будет автоматически использовать эту функциональность в распределении памяти. Важно отметить, что возможности Hyper-V R2 запущенной на платформе, поддерживающей большие страницы памяти, принесут пользу виртуальным нагрузкам и не будут обязывать память гостевых систем использовать большие страницы.
2. 2. Если гостевая операционная система поддерживает большие страницы памяти (и конечно же лежащее в основе оборудование поддерживает большие страницы памяти), тогда виртуальные нагрузки этой системы могут также использовать распространение памяти в больших страницах в гостевой системе.

===================================================

Вопрос: Итак, чтобы использовать большие страницы памяти в приложениях, необходимо их переписать для поддержки этой функциональности?

Ответ: Нет. Имея гостевую операционную систему и приложения, использование больших страниц памяти может быть хорошим вариантом, это важно знать, что приложение вообще может не знать о больших страницах, чтобы извлечь выгоды Hyper-V от использования больших страниц памяти в гостевых операционных системах.

===================================================

Вопрос: Вы упомянули, что SuperFetch может повысить эффективность страничного распределения, так как это устраняет нулевые страницы. Разве это не особенность Windows, используют ли другие операционные системы подобные методы?Ответ: Да, прочие операционные системы используют подобные методы. Для примера, Linux использует функцию под названием "Preloaded". Preloaded - это "адаптивный демон предварительной загрузки", он работает в фоновом режиме и отмечает программы, которые вы используете наиболее часто для последующего кеширования с целью увеличения скорости загрузки. Использование Preloaded задействует неиспользованную оперативную память и повышает общую производительность системы.

Цитата: OSNews говорят о SuperFetch:

SuperFetch - это то, что все операционные систем должны иметь. Я не стал бы покупать 4 Гб оперативной памяти только для того чтобы они ничего не делали в ситуации с малыми требованиями к памяти. SoperFetch делает загрузку приложений быстрее, именно тех приложений которые важны для меня - я пришел из мира BeOS и мне нравится когда мои приложения загружаются мгновенно.

SuperFetch ни коем образом не мешает работе системы, он делает ее более гибкой. Потому что имеет второстепенное значение и его кеш не отнимает память у уже запущенных приложений.

http://www.osnews.com/story/21471/SuperFetch_How_it_Works_Myths

===================================================

Вопрос: Вы не сказали про Address Space Layout Randomization (ASLR) и про то как это влияет на страничное распределение?

Ответ: Я не говорил про ASLR, так как о нем уже были публикации, правда довольно давно, но раз вы спросили...

Да, ASLR влияет на эффективность страничного распределения, но для начала краткое описание ASLR из статьи TechNet, которую написал Mark Russinovich:

Компонент Windows Address Space Layout Randomization (ASLR) усложняет вредоносным программам поиск API, за счет загрузки системных DLL и исполняемых файлов в различные места, при каждой загрузке системы. В начале загрузки диспетчер памяти выбрасывает загрузочные образы DLL в один из 256 назначенных 64-ех Кб-ных адресов в 16-и Мб-ной секции в начале пользовательского адресного пространства. DLL у которых есть новый флаг динамического перемещения в процесс, диспетчер памяти упаковывает в память запуская адрес образа загрузки и работает так далее.

Mark продолжает...

Кроме того, стратегия пере размещения ASLR, имеет дополнительные выгоды, благодаря которым адресное пространство более плотно упаковано, нежели чем в предыдущих версиях Windows, создается больше свободных секций для размещения памяти, уменьшает число таблиц страниц размещенных диспетчером памяти для проверки расположения адресного пространства, и минимизирует промахи Translation Lookaside Buffer (TLB).

Сегодня, влияние ASLR на страничное распределение ~ 10%, это относительно мало по сравнению с большими страницами памяти и SuperFeatch, но это действительно еще один фактор воздействия на эффективность страничного распределения. Более того, это не означает что улучшения в ASLR не будут влиять на эффективность страничного распределения в будущем.

===================================================

Вы сказали что поддержка больших страниц памяти включена в последние несколько поколений процессоров Opteron и Intel добавила поддержку в новых процессорах "Nehalem". Вы хотите сказать что старые процессоры Intel x84/x64 не поддерживают большие страницы памяти?

Ответ: 5/6/2010: ИСПРАВЛЕНИЕ: На самом деле старые x86/x64 процессоры поддерживают большие страницы памяти и так было всегда. Однако, 32-ух битные системы не поддерживают большие объемы оперативной памяти (в основном поддержка не превышает 4 Гб, что является лишь малой долей, от возможностей поддержки памяти в 64-ех битных системах), поэтому поддержка для них совсем не критична, однако сейчас 64-ех битные серверы являются нормой.

В моей следующей публикации мы обсудим второй уровень подкачки...

Jeff Woolsey

Principal Group Program Manager

Windows Server, Virtualization

Установка Service Pack 1 на Microsoft Hyper-V Server 2008 R2.

Здравствуйте коллеги, пару дней назад получил на lebedev.yuriy@gmail.com письмо с вопросом о доступности Service Pack 1 для Microsoft Hyper-V Server 2008 R2. Признаюсь, не знал как ответить, знал что должен быть, но отельный он или нет, есть ли какие-нибудь нюансы не знал. Но вот чудо, наткнулся на данную публикацию и все встало на свои места. Думаю после прочтения данного перевода вопросов ни у кого остаться не должно.

Ссылка на оригинал: Team Virtualization Blog

Установка Service Pack 1 на Microsoft Hyper-V Server 2008 R2.

С выходом бета-версии Service Pack 1 для Windows Server 2008 R2, многие из вас спрашивали о Service Pack 1 для независимого Microsoft Hyper-V Server 2008 R2 и о доступности новых возможностей динамической памяти (Dynamic Memory) и RemoteFX для него. Безусловно, и динамическая память, и RemoteFX были разработаны в том числе и для Microsft Hyper-V Server 2008 R2.

Для того чтобы получить эти новые возможности для Microsoft Hyper-V Server 2008 R2, вам нужно установить бета-версию Service Pack 1 на Microsoft Hyper-V Server 2008 R2. Обратите внимание, что с первой волной установщика пакета обновления доступно только 5 языков (Английский, Французский, Немецкий, Японский и Испанский), так что если вы будете пытаться установить обновление на Microsoft Hyper-V Server 2008 R2 (который содержит все 11 языковых пакетов по умолчанию), то вы увидите следующее окно:


Довольно просто удалить эти языковые пакеты, для дальнейшей установки пакета обновления. Для удаления языковых пакетов есть отличная встроенная утилита (lpksetup.exe). Запустите ее из командной строки с правами администратора и выберите опцию "Uninstall display languages".


На следующем экране выберите все языки, кроме пяти поддерживаемых ("English", "French", "German", "Japanese" and "Spanish"). Разумеется если вы хотите сэкономить дополнительное место на диске, вы можете удалить все языки, оставив только тот, который вы будете использовать в вашей среде, нажмите "Next" и дайте утилите сделать свою работу. После этого вы можете установить Service Pack 1. Наслаждайтесь!!


Vijay Tewari

Principal Program Manager, Windows Server Virtualization

Клонирование ОС средствами WDS

Вот, наконец и опубликовал веб-каст посвященный возможностям WDS по клонированию ОС с предустановленными драйверами, программами и т.д. Демонстрация проходит на Microsoft Windows Server 2008 R2 и Windows 7.

Все подробности и видео: LebedevUM

Загружаем бэта-версию Windows Server 2008 R2 SP1

Доброго дня.
Сначала я хотел самостоятельно написать небольшую публикацию о вышедшем SP1 для Windows Server 2008 R2, затем хотел перевести публикацию "Available for Download: Windows Server 2008 R2 SP1 Beta!" из Windows Server Division WebLog, но прочитав ее решил что в ней много не очень важной информации и поэтому я остановился на этом.

Ссылка на оригинал: Virtualization Team Blog.

Загружаем бэта-версию Windows Server 2008 R2 SP1

В Windows Server Division blog, Oliver написал о доступности бэта-версии для загрузки. Oliver сконцентрировал свое внимание на Windows Server 2008 R2 SP1, но Windows 7 SP1 также доступен. Все это было сегодня объявлено на нашей всемирной партнерской конференции в Вашингтоне.

Вот выдержка из публикации, которую сделал Oliver:

Двумя наиболее важными разработками в SP1 для Windows Server 2008 R2 являются:

• Динамическая память (Dynamic Memory) предоставляет администраторам Hyper-V пул доступной памяти на физическом хосте и динамически распределяет его на любые виртуальные машины, запущенные на этом хосте. Так как рабочая нагрузка постоянно меняется: требуется либо больше, либо меньше памяти. Динамическая память дает администраторам возможность менять распределение памяти между виртуальными машинами без перерыва в работе. Больше информации можно получить вот тут {Перевод публикации доступен у меня в блоге}.
• RemoteFX расширяет виртуализацию настольных систем Microsoft. RemoteFX предоставляет администраторам Windows Server 2008 R2 более богатые и скрытые от пользователей возможности настольной виртуализации. RemoteFX предоставляет богатое содержимое, независимое к любым графическим адаптерам для размещенных на сервере виртуальных машин и терминальных сессий, разрешает им любое наполнение экрана, включая полную поддержку видео, возможности Sliverlight и 3D-приложения. Так как это может использовать виртуализованную графику и расширенные кодеки, RemoteFX может доставить эти возможности на гораздо более широкий спектр устройств, в том числе не только стандартные настольные компьютеры и ноутбуки, но и множество новых тонких клиентов. Вы также сможете перенаправлять USB-порты локального компьютера к виртуальной машине, осуществляя доступ к устройству - также как вы можете перенаправлять локальный принтер сегодня.

Убедитесь, что вы проверили новую страницу ресурсов бэта-версии SP1 на Microsoft.com, а также страницу SP1 в TechNet - и не забудьте вот эту загрузку.

Patrick

Динамическая память (Dynamic Memory) приходит в Hyper-V Часть 3.

Итак ближайшее время займусь переводом публикации "Dynamic Memory Coming to Hyper-V Part 3...", так как данная публикация помимо массы интересной информации о страничном распределении памяти, обладает и значительным объемом, то переводить ее буду по частям, дополняя данный пост.

Ссылка на оригинал: Virtualization Team Blog.




Динамическая память (Dynamic Memory) приходит в Hyper-V Часть 3.

======================================================

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

======================================================

Memory Overcommit, термин перегрузки...

Когда речь заходит о виртуализации и памяти я часто слышу термин "memory overcommit", используемый так, как будто это единая технология. Проблема заключается в том, что есть множество технологий, которые могут быть задействованы для более эффективного использования памяти, но это может привести к еще большей путанице. Некоторые клиенты считают, что страничное распределение (page sharing) эквивалентно overcommit. Другие думают, что второй уровень подкачки эквивалентен memory overcommit и так далее.

Итак, чтобы избежать путаницы, вот определение overcommit из интернет-словаря Merriam Webster:
http://www.merriam-webster.com/dictionary/overcommit

overcommit - для чрезмерного выполнения
a: для совершения (действия) выходящего за пределы возможностей (собственных).
б: выделить (ресурсы) излишки мощностей для пополнения

Если сказать простыми словами memory overcommit означает следующее: выделить больше ресурсов памяти, чем физически присутствует. В физическом (не виртуальном) окружении, использование файла подкачки является примером memory overcommit. Теперь, когда мы определили это, я буду использовать этот термин, чтобы избежать вышеупомянутой путаницы. Также, с этого момента я буду ссылаться на конкретные технологии памяти.

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

Сегодня мы детально обсудим страничное распределение (Page Sharing).

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



Как страничное распределение (Page Sharing) работает.

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

Страничное распределение это хорошее понимание технологии использования памяти и это набор факторов способствующих ее более эффективному использованию, таких как:

1. Большие страницы памяти (Large Memory Pages)
2. Использование памяти операционной системой (OS Memory Utilization) и Нулевые страницы (Zero Pages)

Страничное распределение, TLB, большие страницы памяти и так далее...

Для обсуждения поддержки больших станиц памяти и ее последствий для страничного распределения и ее влияния на страничное распределение, давайте сделаем шаг назад. Для этого, я буду ссылаться на отличную статью, которую сделал Alan Zeichick из AMD в 2006 году. Хотя статья сфокусирована на применении больших страниц памяти и виртуальных машинах java, это также применимо и к машинной виртуализации. Я буду ссылаться на конкретные разделы, но если вы пожелаете прочитать ее целиком, то она расположена вот по этой ссылке:
http://developer.amd.com/documentation/articles/pages/2142006111.aspx


Все процессоры с архитектурой x86 и современные 32-ух и 64-ех разрядные операционные системы размещают физическую и виртуальную память в страницах. Таблица страниц связывает виртуальный адрес с физическим для каждого приложения и поиск нужного значения в этой таблице занимает время. Чтобы ускорить этот процесс современные процессоры используют Translation Lookside Buffer (TLB), для кэширования наиболее частых связей между физической и виртуальной памятью.

Часто, когда физическая память назначенная приложению или выполнение не является непрерывным, то работая в условиях операционной системы, страницы памяти могут стать фрагментированными. Но из-за того, что таблица страниц скрывает адреса физической памяти от приложения, приложение думает, что имеет непрерывную память. (По аналогии, подумайте о том, как фрагментированные файлы на диске не видимы для приложений, файловая система операционной системы скрывает все это.)

Когда приложение нуждается в считывании или записи в память, процессор использует таблицу страниц для перевода (трансляции) адресов виртуальной памяти, используемых приложением, в адреса физической памяти. Как упоминалось ранее, для ускорения процессор использует систему кэширования - Translation Lookside Buffer (TLB). Если запрашиваемый адрес находится в кэше TLB, то процессор может обслужить запрос быстрее, без поиска адресов в таблице страниц. Если запрашиваемый адрес не находится в кэше, то процессор, перед ответом на запрос, переходит к таблице страниц для поиска соответствия виртуального адреса физическому.

TLB кэш имеет большое значение, так как страниц памяти очень много. В стандартных 32-разрядных Linux, Unix или Windows серверах с 4 ГБ оперативной памяти в таблице страниц присутствует миллион маленьких страниц по 4 КБ. Это очень много, но что если это 64-разрядная система с 32 ГБ оперативной памяти? Это означает, что в системе есть 8 миллионов страниц памяти по 4 КБ.

Мистер Zeichick продолжил:

Почему это [большие страницы] лучше? Предположим ваше приложение пытается прочитать 1 МБ (1024 КБ) непрерывных данных, к которым не было обращений последнее время и они не хранятся в кэше TLB. Если страница памяти имеет размер 4 КБ, это означает, что вам придется получить доступ к 256 отдельным страницам памяти. Это означает поиск не содержащихся в кэше 256 раз и затем поиск в таблице страниц 256 раз. Медленно, медленно, медленно.

В отличии от этого, если страница имеет размер 2 МБ (2048 КБ), тогда для доступа к блоку данных потребуется один или два запроса к таблице страниц - один если данные содержатся в одной странице и два если данные переходят через границу сраницы памяти. После этого TLB кэширует все необходимое. Быстрее, быстрее, быстрее.ли страница имеет размер 2 МБ (2048 КБ), тогда для доступа к блоку данных потребуется один или два запроса к таблице страниц - один если данные содержатся в одной странице и два если данные переходят через границу сраницы памяти. После этого TLB кэширует все необходимое. Быстрее, быстрее, быстрее.

Это становится лучше.

Для маленьких страниц, механизм TLB содержит 32 записи в L1 кэше и 512 записей в L2 кэше. Так как каждая запись ссылается на 4 КБ, вы можете посчитать что вместе они покрывают чуть более 2 МБ виртуальной памяти.

Для больших страниц TLB содержит восемь записей. Так как каждая страница отображает 2 МБ, TLB может показывать 16 МБ виртуальной памяти. Если ваше приложение обращается с большим объемом памяти, то в таком случае это намного эффективнее. Представьте себе выгоды если ваше приложение читает, ну скажем, 2 ГБ данных. Как считаете этот процесс для тысяч буферизованных страниц по 2 МБ, вместо полумиллиона страниц по 4 КБ?

Браво, мистер Zeichick.

Я расширил пример мистера Zeichick по сравнению физической памяти с количеством записей в таблице страниц и создал эту таблицу для дальнейших демонстраций страниц по 4 КБ на различных объемах физической памяти.

Физическая память - Записи таблицы страниц (4КБ)
4 ГБ - 1 миллион страниц
32 ГБ - 8 миллионов страниц
64 ГБ - 16 миллионов страниц
96 ГБ - 24 миллиона страниц
128 ГБ - 32 миллиона страниц
192 ГБ - 48 миллионов страниц
256 ГБ - 64 миллиона страниц
384 ГБ - 96 миллионов страниц
512 ГБ - 128 миллионов страниц
1 ТБ - 256 миллионов страниц

Если учесть, что серверы не поддерживают 32/64 ГБ памяти вечно и что многие серверы сегодня, такие как HP DL 385 G6 поддерживают до 192 ГБ памяти на один сервер, вы увидите что время для использования больших страниц памяти давно настало. Взгляните на недавно выпущенный процессор Nehalem EX. Nehalem EX поддерживает до 256 ГБ памяти в каждый разъем. Теоретически вы можете владеть сервером с четырьмя разъемами и 1 ТБ физической памяти. Вы действительно хотите получать доступ к этой памяти по 4 КБ за раз?

(Уже используя 64 ГБ физической памяти работа с ней, как заполнение олимпийского бассейна при помощи маленьких емкостей: по 8 чашек за раз и чем больше памяти становится тем хуже...)

Ключевые моменты:

• TLB является одним из важнейших ресурсов системы, который вы хотите использовать эффективно и настолько эффективно, насколько это возможно, так как это может оказать существенное влияние на производительность системы.
• Использование 4 КБ-ых страниц в 32-битном мире, где системы максимально обладают 4 ГБ памяти была проблемой на протяжении нескольких лет, теперь проблема стала серьезней в 64-битном мире, где системы поддерживают десятки (если не сотни) гигабайт оперативной памяти.
• Использование страниц памяти с размером 4 КБ на 64-битных с поддержкой огромных объемов памяти резко снижает эффективность TLB и общую производительность системы.

Еще больше: SLAT, NPT/RVI, EPT и большие страницы...

Один момент, который я хотел бы добавить, это то, как большие страницы и второй уровень трансляции адресов (Secound Level Address Translation, SLAT) сосуществуют на аппаратном уровне. Со встроенной подкачкой, (AMD называет это Rapid Virtualization Indexing (RVI ~ Быстрая индексация виртуализации) и/или Nested Page Tables (NPT ~ встроенные таблицы страниц), в то же время Intel называет это Extended Page Tables (EPT ~ расширенные таблицы страниц)) таблицы страниц на аппаратном уровне отвечают за трансляции между адресом гостевой виртуальной машиной и физическим адресом, сокращая затраты. С оборудованием, поддерживающим SLAT, производительность в целом увеличивается на 20% по всем направлениям, и может быть гораздо выше (независимая третья сторона сообщила о 100%+ приросте производительности), все зависит от того какая нагрузка приходится на память. Одним словом, аппаратная поддержка SLAT является правильным решением и если вы закупаете сервер в качестве виртуального хоста сегодня, необходимо удостоверится, что он обладает этой возможностью.

Один важный момент, который не так хорошо известен, это то что аппаратная технология SLAT, разработана и оптимизирована под использование больших страниц памяти. Нужно отметить, что дополнительные вложенные таблицы страниц, делают TLB кэш не выгодным и в результате теряется примерно 20% производительности, в том случае, когда вы используете возможности аппаратного SLAT с отключенными большими страницами памяти. Более того, здесь не учтены 10-20%-ное (может и больше) увеличение производительности, за счет использования больших страниц памяти. В общем мы говорим о 40%-ом приросте или потере производительности на оборудовании с поддержкой SLAT, в зависимости от того, используются ли большие страницы памяти или нет.

Вы можете захотеть прочитать эти последние два пункта еще раз.

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

• Увеличение производительности (в среднем на 10-20%, может и больше).
• Более эффективное использование TLB.
• Избегайте 20% процентной потери производительности на оборудовании с поддержкой SLAT.

Эволюция оборудования, большие страницы памяти и последствия для страничного распределения (Page Sharing).

Компьютерное оборудование постоянно эволюционирует. Возьмите к примеру сетевые технологии. Ранее, размер кадра для Ethernet составлял 1518 байт, в значительной степени это связано с более низкой скоростью и большим количеством ошибок. Вместе с эволюцией и улучшением сетей (быстрые с малым количеством ошибок), размер в 1518 байт был признан узким местом, в связи с чем были введены большие кадры. Гигантские кадры (Jumbo frames) еще больше, они достигают 9014 байт и доставляют до 6 пакетов за раз, тем самым уменьшая нагрузку на процессор, за счет сокращения числа прерываний.

Аналогичная ситуация происходит в настоящее время с большими страницами памяти, где серверное оборудование развивается, увеличивая масштабы и производительность всей системы. Последствием такого развития становится изменение базовых допущений. В частности, большие страницы памяти изменяют фундаментальные допущения о маленьких страницах памяти по 4 Кб на большие и более эффективные страницы памяти по 2 Мб. Однако, есть и последствия таких изменений. Пока вы можете определять и распространять страницы по 4 КБ относительно легко, вероятность распространения страниц по 2 Мб очень, очень мала (если вообще не является нулевой). По сути в данной области Microsoft и VMWare солидарны. VMWare подтверждает эту точку зрения.

Из VMWare:
Единтсвенная проблема, связанная с использованием больших страниц, страничное распределение нуждается в поиске равных фрагментов для 2 Мб (по сравнению с 4 Кб фрагментами, когда используются маленькие страницы) и вероятность нахождения весьма мала (если гость записывает все нули в 2 Мб фрагмент) так ESX не пытается сокращать большие страницы и из-за этого память, сохраняемая за счет TPS уменьшается, в тот момент, когда все гостевые страницы передаются в большие страницы гипервизора.

http://communities.vmware.com/message/1262016#1262016

Страничное рапределение работает в наследстве от мира страниц памяти по 4 Кб, но не предоставляет ценности в современном мире страниц памяти по 2 Мб.

Как отмечалось ранее, поддержка больших страниц памяти не так уж и сложна. На самом деле, при проектировании Hyper-V Dynamic Memory, мы убедились в возможности оптимизации в случае использования больших страниц памяти, потому как мы ожидаем, что в скором времени они станут стандартом. Мы настолько уверены в поддержке больших страниц памяти, что:

• В Windows Server 2008/2008 R2 большие страницы памяти разрешены по умолчанию.
• В Windows Vista/7 большие страницы памяти разрешены по умолчанию.
• В Windows Server 2008 R2 Hyper-V добавлена поддержка для больших страниц памяти (Сюрприз!) и это всего одно из улучшений производительности в R2.

Размер страницы памяти эволюционирует. Вы можете рассчитывать и на размер страниц памяти превышающий 2 Мб в будущем. На самом деле новые процессоры AMD64 могут использовать страницы памяти размером 1 Гб в длинном режиме, также и Intel добавляет поддержку страниц размером 1 GB в их выходящих процессорах Westmere. (Кстати, это не опечатка, страницы с размером 1 Гб...)

В дополнение к большим страницам памяти, другим фактором влияющим на эффективность страничного распределения является OS Memory Utilization(Использование памяти операционной системой) и Zero Pages (Нулевые страницы).


Страничное распределение (Page Sharing), использование памяти операционной системой (OS Memory Utilization) и нулевые страницы (Zero Pages).

Один из аспектов страничного распределения, о котором большинство людей могут не знать, заключается в том, что наибольшая выгода от страничного распределения получается за счет распределенного обнуления страниц. Давайте представим, что передо мной система Windows XP с 2 Гб памяти. Как вы можете видеть на снимке ниже, имеется только что загруженная система Windows XP, без приложений, операционная система использует ~375 МБ памяти, в то время как оставшиеся ~ 1,8 Гб памяти не задействованы и простаивает без пользы.


В действительно, вы хотите, чтобы операционная система полностью использовала всю память в качестве интеллектуального кэша для повышения производительности и гибкости. Если вы собираетесь купить новую систему (а я вижу в интернете рекламу новых четырех-ядерных систем с 8 Гб памяти за 499 долларов), разве вы не хотите чтобы операционная система использовала эту память? Конечно же вы хотите. Именно поэтому мы создали SuperFetch (Суперусиление).

SuperFetch отслеживает какие приложения вы используете наиболее часто и загружает эту информацию в оперативную память, для того чтобы программы загружались быстрее, чем если бы вы грузили их каждый раз с жесткого диска. Windows SuperFetch расставляет приоритеты к программам работающем в фоновом режиме, которые вы используете и старается предварительно загрузить в память те из них, с которыми вы работаете наиболее часто. При помощи SuperFetch фоновые задачи продолжают выполняться даже тогда, когда компьютер простаивает. Однако когда фоновая задача завершает свое выполнение, SuperFeatch обновляет системную память содержащую данные до запуска фоновой задачи, данными с которыми вы работали. Теперь когда вы вернетесь к вашей настольной системе, ваши программы будут работать так же эффективно, как будто вы никуда не уходили. SuperFetch настолько хорош, что знает какой сегодня день, если вы используете определенные приложения в конкретные дни.

Итак, как же на самом деле используется оперативная память? Вы наверняка заметили, что Windows 7 использует гораздо больше оперативной памяти, чем Windows XP. Это не редкость увидеть в диспетчера задач Windows 7, на системе с несколькими гигабайтами оперативной памяти, свободными менее 100 Мб. Для примера, вот диспетчер задач машины на которой я сейчас работаю:


Как вы можете увидеть, эта система обладает 8 Гб оперативной памяти и использует 3,29 Гб. Я запустил Windows 7 64-разрядную редакцию, Outlook, One Note, Word, Excel, PowerPoint, Windows Live Writer, Live Photo Gallery, несколько экземпляров IE c более чем дюжиной открытых вкладок и еще кучу других повседневных инструментов, и вы можете видеть, что доступно 0 Мб свободной физической памяти. На первый взгляд - это повод для беспокойства, но если помнить про SuperFetch, то становится ясно, что беспокоиться тут не о чем. Обратите внимание что ~5872 Мб используется для кеширования.

Превосходно.

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

Итак почему же я объясняю нулевые страницы и SuperFetch?

Потому что наибольшая выгода от страничного распределения достигалась за счет обнуления страниц в предыдущих версиях операционных систем, а в современных операционных системах это становится менее выгодным. Также как и Гигантские кадры и большие страницы памяти, SuperFeatch это новый пример эволюционных изменений в компьютерах.

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

Финальная точка в страничном распределении

Подведем итоги...

Сегодня доступна широкая поддержка больших страниц памяти (2 Мб) в процессорах AMD и Intel. AMD и Intel включили поддержку больших страниц памяти для многих поколений x86/x64 процессоров. Однако 32-разрядные системы не поддерживают большие объемы памяти (поддержка в большинстве случаев заканчивается на 4 Гб, которые составляют лишь малую часть от того объема, который поддерживается 64-разрядными системами), поэтому большие страницы памяти для них не столь важны, однако сейчас 64-разрядные серверы становятся нормой.

• Страничное распределение на системах с большими страницами памяти в результате как правило не дают распределенных страниц. Пока вы можете относительно легко определить страницу размером 4 Кб, вероятность совместного использования страниц с размером 2 Мб очень, очень мала (если вообще не ноль). Опять же в этой области Microsoft и VMWare солидарны.
• Прочитайте последний пункт еще раз.
• Страничное распределение работает с маленькими страницами по 4 Кб. Недостатком маленьких страниц является неэффективное использование TLB, в случае использования больших страниц TLB используется более эффективно, что приводит к значительному увеличению производительности.
• Использование маленьких страниц памяти по 4 Кб на оборудовании с поддержкой SLAT снижает производительность ~20%
• В Windows Server 2008/2008 R2 большие страницы памяти включены по умолчанию.
• В Windows Vista/7 большие страницы памяти включены по умолчанию.
• В Windows Server 2008 R2 Hyper-V добавлена поддержка больших страниц памяти и это только одно из улучшений производительности в R2 (сюрприз!)
• Эффективность страничного распределения снижается (это не связано с большими страницами памяти), так как современные операционные системы полностью используют оперативную память для увеличения производительности.
• Процесс проверки, хэширования всей памяти в системе и записи в хэш таблицу может занимать часы. Время зависит от целого ряда переменных, таких как: однородность гостевых систем, какая нагрузка приходится на гостевые системы, сколько памяти на физической системе, используете ли вы балансировку нагрузки между виртуальными машинами и так далее.
• Страничное распределение не является динамичной технологией, если гипервизор потребует памяти на другую виртуальную машину, то страничное распределение не является наилучшим ответом. Также верно и обратное. Если виртуальная машина освобождает память, которая может быть использована другими виртуальными машинами, то и в этом случае страничное распределение не является наилучшим ответом.

Я надеюсь данная публикация наглядно показывает, что мы потратили много времени рассматривая данную технологию и после тщательного анализа пришли к выводу, что это не лучший вариант для использования вместе с Hyper-V Dynamic Memory. Более того, много ума не нужно, чтобы понять необходимость поддержки больших страниц памяти. Мы настолько сильно уверены в больших страницах памяти, что при разработке Hyper-V Dynamic Memory, мы оптимизировали поддержку больших страниц памяти, так как мы ожидаем, что в скором времени она станет стандартом. Преимущества слишком очевидны, чтобы их упустить. Хорошая новость заключается в том, что существуют и другие способы объединения и выделения памяти, и Hyper-V Dynamic Memory является хорошим решением для настольных и серверных операционных систем.

В следующей публикации мы обсудим второй уровень подкачки.

Jeff Woolsey

Windows Server Hyper-V