Когда вы думаете о пакете обновлений, вы, вероятно, имеете в виду какие-то незначительные модернизации и настройки. Вам приходят на ум такие фразы, как «повышение надежности» и «улучшение производительности», а не «новые функции в данной технологии». Такое восприятие было бы верным, если бы речь шла о Windows 7 SP1. В нем есть исправления, направленные на решение проблем и повышение производительности, а некоторые незначительные функциональные дополнения относились к интеграции с продуктами третьих фирм, производительности HDMI-аудио и документам XPS, но все это не предмет обсуждения в данной статье. Когда вы смотрите на SP1 для Windows Server 2008 R2, он выглядит совершенно иначе. Если сказать, что он добавляет новые функции, это не будет преувеличением. SP1 меняет правила игры в пользу виртуализации, особенно за счет поддержки Virtual Desktop Infrastructure (VDI).
SP1 для Server 2008 R2 вносит некоторые незначительные изменения и помимо Hyper-V, но в данной статье я рассмотрю новинки именно Hyper-V. Даже до выпуска SP1 гипервизоры от разных поставщиков практически достигли равенства, были только незначительные отличия в вопросах производительности и функциональности. Выбор технологии виртуализации основывался на цене, управлении и интеграции с имеющейся инфраструктурой. Однако у Hyper-V был один недостаток: ему не хватало контроля чрезмерного выделения памяти. Благодаря SP1 Microsoft устраняет данный недостаток.
Hyper-V 2008 R2 SP1 вводит понятие динамической памяти, которая позволяет определять начальный объем оперативной памяти для виртуальной машины и максимальный объем оперативной памяти, который может быть ей выделен. Hyper-V гибко распределяет память по виртуальным машинам, согласно изначально заданному им объему, отталкиваясь от нагрузки и объема доступной физической оперативной памяти. В этом отличие от принципа чрезмерного выделения памяти, когда вы запускаете каждую виртуальную машину с максимальным объемом доступной памяти, невзирая на то как она используется, надеясь, что ресурсы не иссякнут. При использовании механизма динамической памяти разным виртуальным машинам назначается дополнительная память, если она доступна. Память также может быть переназначена для одной виртуальной машины от других виртуальных машин, если она им не требуется.
На экране 1 показано диалоговое окно для указания объема памяти в Server 2008 R2 SP1, поддерживающего виртуальные машины. Заметьте, что вы еще можете задействовать старую конфигурацию Static, где вы определяете для виртуальной машины объем памяти, которая распределяется вся, когда виртуальная машина работает, и не может быть увеличена. Более интересная функция — это вариант Dynamic, который вы видите на экране. Startup RAM — это память, изначально назначаемая виртуальной машине, когда та запускается, а Maximum RAM — это объем, до которого память виртуальной машины может увеличиваться в зависимости от ее потребностей и возможности использования физической памяти. Значение Maximum RAM по умолчанию равняется 64 Гбайт (это максимум, который поддерживается виртуальной машиной в Hyper-V). Я полагаю, вы можете установить более реальные значения для планирования и защиты от нежелательных последствий расходования всей имеющейся оперативной памяти одной виртуальной машиной. В моем примере я установил 2 Гбайт. Согласно ожидаемой нагрузке, это разумный объем для виртуальных машин.
Экран 1. Настройка динамической памяти для виртуальной машины |
В диалоговом окне мы видим два ползунка. Первый — это процент памяти, которая выделяется под буфер. Вы задаете буфер, потому что не хотите, чтобы операционная система полностью исчерпала память, прежде чем Hyper-V начнет добавлять ей больше. Процесс добавления дополнительной оперативной памяти может занять несколько секунд. За это время производительность виртуальной машины может пострадать: гостевая операционная система может начать перемещать страницы памяти в собственный файл подкачки для того, чтобы восполнить недостаток оперативной памяти. Чтобы избежать зависания, вы устанавливаете желаемый процент памяти, который всегда будет доступен виртуальной машине (по умолчанию это 20%). Когда виртуальной машине доступен меньший процент памяти, она добавляется виртуальной машине, чтобы таким образом достигнуть желаемого значения (при условии, что на хосте есть доступная оперативная память). Если 20% — это слишком мало или слишком много для потребностей виртуальной машины, можно изменить эту настройку, используя ползунок. Хотя 20% — это подходящее значение для большинства случаев.
Другой ползунок предназначен для установки приоритета выделения памяти в случаях, кода недостаточно физической оперативной памяти для обеспечения всех виртуальных машин. Подобно приоритетам процессора, виртуальная машина с более высоким приоритетом на память получает в случае необходимости дополнительную память раньше, чем виртуальная машина с более низким приоритетом.
Я сказал, что механизм динамической памяти гибко распределяет память по разным виртуальным машинам. Я также использовал фразу «доступная память», а не «свободная память». Это важно, потому что доступная память и свободная память — разные вещи. Windows Vista и более новые операционные системы используют всю память для кэша, что помогает улучшить производительность путем предварительной загрузки программ в память. Память, использованная для кэша, может расходоваться приложениями, когда требуется, таким образом, кэш в значительной степени доступен. Говорить о свободной памяти бесполезно, нужно думать о доступной памяти, которая включает в себя и большую часть памяти, используемой кэшем. Так действует динамическая память.
Обновления в службах интеграции Hyper-V предоставляют нового клиента динамической памяти Virtual Server Client (VSC) для гостевых операционных систем. VSC имеет дело с соответствующим провайдером Virtual Service Provider (VSP) на родительском разделе диска, где составляется отчет об использовании памяти, особенно о объеме доступной памяти. На основании объема доступной памяти в гостевой системе задается буфер желаемой памяти виртуальной машины, а в зависимости от объема физической оперативной памяти базовой системы дополнительный объем может быть назначен гостевой системе.
Этот тип разумного распределения памяти возможен в силу того, что клиент динамической памяти VSC обеспечивает понимание запросов гостевой операционной системы. Это было бы невозможно, если бы гипервизор просто извне смотрел на то, как используется память в виртуальных машинах: Hyper-V не мог бы сказать, расходуется память приложением или применяется для служебных целей вроде кэширования (о других технологиях рассказано во врезке «Невосполнимое распределение ресурсов памяти»). На экране 2 показана память, выделенная виртуальной машине, и процент доступной памяти. Следует убедиться, что процент доступной памяти близок к проценту для буфера памяти, значение которого вы задаете.
Экран 2. Настройки памяти в Hyper-V Manager |
Некоторые версии Windows поддерживают увеличение памяти операционной системы методом «горячего» добавления, без выключения компьютера, но динамическая память не использует такую возможность. Увеличение памяти без выключения компьютера все-таки встречается редко и позволяет добавлять модули памяти в работающий сервер. Этот процесс отличается от частого добавления памяти небольшими объемами, и практика показала, что «горячее» добавление памяти — не слишком удачное решение. Вместо этого службы интеграции Hyper-V, которые запускаются внутри гостевых операционных систем, были на уровне ядра оснащены низкоуровневыми компонентами памяти, которые взаимодействуют с родительским разделом. Когда он сообщает, что была выделена дополнительная память, службы интеграции представляют ее гостевой операционной системе, которая продолжает работать с увеличенным объемом памяти. В моих тестах этот метод работал великолепно.
Когда данной виртуальной машине дополнительная память больше не нужна или она требуется другой виртуальной машине, динамическая память использует драйвер распределения памяти для запрашивания памяти. Драйвер распределения памяти — это драйвер устройства уровня ядра, поэтому когда он запрашивает память, операционная система вынуждена выполнить его просьбу. Hyper-V предписывает службам интеграции выдать драйверу распределения памяти объем оперативной памяти определенного размера. Драйвер распределения памяти отбирает память у гостевой операционной системы и оставляет ее свободной для того, чтобы Hyper-V перераспределил память. Гостевая операционная система самостоятельно решает, откуда забрать память, и может переместить наименее ценные данные в памяти в локальный файл подкачки. Если гостевой операционной системе нужно будет больше памяти позднее (и она доступна), размер памяти у драйвера распределения может быть снижен, а память возвращена в гостевую операционную систему.
Когда быть динамичным
Использование динамической памяти нельзя назвать удачным решением для всех виртуальных нагрузок, но оно является таковым для большинства из них. Обычно вы назначаете некоторым службам, таким как контроллеры домена и файловые серверы, 4 Гбайт памяти, но когда вы обращаете внимание на детали, вы видите, как мало памяти они используют. VDI является еще одной средой, в которой желательно использовать динамическую память, поскольку компьютерам сотрудников редко требуются большие объемы памяти для выполнения ежедневных задач. Так когда же она нужна? Подумайте над такими службами, которые очень разумно относятся к памяти и распределяют ее, когда запускаются, или над такими службами, которые постоянно потребляют столько памяти, сколько возможно (серверы SQL Server и Exchange с ролью Mailbox подходят под это описание). Если вы попытаетесь использовать динамическую память с этими службами, они займут всю память, которую вы им дадите. Это будет продолжаться до тех пор, пока вы не осуществите настройку служб для ограничения количества оперативной памяти, которая может быть ими использована. Как правило, конфигурация со статической памятью будет намного лучше, чем динамическая для такого рода емких служб.
Динамическая память не означает, что планировать ничего не нужно. Вам еще необходимо вычислить средний объем памяти своих виртуальных сред и, соответственно, назначить ресурсы. Динамическая память означает, что вам не нужно указывать максимальную память, используемую виртуальной машиной все время. Вы можете разрешить виртуальной машине использовать больше или меньше памяти, когда это требуется. Динамическая память позволяет «втиснуть» больше виртуальных машин в имеющуюся оперативную память при сокращении затрат на управление.
RemoteFX
Компонент RemoteFX состоит из трех функций, которые базируются на приобретенных Microsoft вместе с компанией Calista Technologies технологиях. Calista акцентировала внимание на совершенствовании технологий виртуализации уровня представления, таких как Remote Desktop. Одну из функций, доступных для Remote Desktop Session Host, мы здесь и рассмотрим (официально она называется Terminal Services). Две другие функции доступны только для сред Windows 7 VDI.
Технология RemoteFX vGPU нацелена на обеспечение графического отображения информации у пользователей, вне зависимости от возможностей их устройств. С vGPU пользователи, подсоединяющиеся к сессиям Windows 7 VDI с клиентских систем Windows 7, могут включать формирование рабочего стола в настройках удаленного соединения и наслаждаться всеми возможностями Aero Glass. Используя перенаправление мультимедиа, определенные типы мультимедиа-форматов, такие как файлы WMV, направляются на устройства клиентов в необработанном виде, и рендеринг проводится локально, что обеспечивает гладкое воспроизведение мультимедиа. Пользователи систем Windows 7 получают отличное воспроизведение благодаря локальной операционной системе Windows 7 и мощному оборудованию. Но когда выполняется соединение с тонкого клиента или устаревшей операционной системы, пользователи получают другой вид: только базовая графика и почти никаких медийных возможностей. vGPU исправляет подобные недостатки и позволяет всем пользователям получать почти одинаковое воспроизведение в Windows 7 VDI.
vGPU работает с использованием виртуального графического процессора, являющегося частью обновленных служб SP1, который представляется гостевой операционной системе через обновленный драйвер виртуализации VMBus. vGPU использует графический процессор на хосте, для того чтобы производить графические вычисления. Заметим, что вам не нужен один физический графический процессор на каждый vGPU на гостевых компьютерах. Один физический графический процессор может поддерживать множественные vGPU точно так же, как и одно физическое ядро процессора может использоваться множественными виртуальными процессорами.
У вас есть два варианта использования графического процессора на хосте. Первый вариант — это применение графических адаптеров на хостах, поддерживающих DirectX 9.0c и 10 и имеющих как минимум 256 Мбайт памяти (хотя, возможно, вам понадобится больше для какого-нибудь большого задания) и разъем PCI-Express (в идеале x16). Процессоры на хостах также должны поддерживать Second Level Address Translation (SLAT). Причем в рабочих средах вам лучше использовать специализированные профессиональные графические карты, а не потребительские графические процессоры, хотя в тестовой среде лучше иметь базовый GPU (в своих тестах я использовал GTX 275с 1 Гбайт памяти). Заметьте, что эти графические карты могут быть внешними. Второй вариант заключается в использовании аппаратного устройства, известного как Application Specific Integrated Circuit (ASIC), которое применяется для того, чтобы разгрузить GPU или не использовать GPU хоста.
При помощи данного vGPU гостевая операционная система имеет расширенные графические возможности, включая DirectX 3D 9.0c (которая используется мощными приложениями, такими как PowerPoint 2010), Silverlight, Adobe Flash, Aero и многие другие. Все изображения и команды, ассоциирующиеся с графикой виртуальной машины vGPU, посредством VMBus посылаются компоненту Render Capture Compress операционной системы хоста и воспроизводятся графическим процессором гостевой операционной системы, используя внеэкранную память. Все воспроизведение осуществляется хостом. Далее компонент захвата сканирует изменения во внеэкранной памяти, выполняет воспроизведение, сжимает изменения и посылает их клиенту. Графический контент RemoteFX посылается через новый графический виртуальный канал Remote Desktop Protocol (RPD). Именно поэтому клиент должен поддерживать RDP 7.1 и RemoteFX. Эта конструкция совсем не использует возможности воспроизведения клиентской системы, поэтому вы получаете тот же самый вид, несмотря на возможности локального клиента (при условии, что этот клиент совместим с RemoteFX). Если клиент несовместим с RemoteFX или у него нет соединения по локальной сети (наличие такого соединения — необходимое условие для RemoteFX), у клиента по умолчанию будет стандартный RDP, а RemoteFX vGPU не станет использоваться.
Теперь многие клиенты, включая клиентов со стандартной Windows, традиционные тонкие клиенты, ультратонкие клиенты, использующие компоненты RemoteFX ASIC для декодирования и распаковки и даже мониторы со встроенным RemoteFX ASIC, смогут использовать преимущества RemoteFX. У всех будет одинаковая графика, поскольку воспроизведение осуществляется хостом, а изменения на экране отсылаются по сети. Помните, что целевая система должна запускаться с Windows 7 SP1 и Hyper-V 2008 R2 SP1, где активирован RemoteFX. Вы не можете использовать RemoteFX vGPU и взаимодействующие расширенные графические возможности на Remote Desktop Session Host (RDSH).
До сих пор я рассуждал о графической стороне RemoteFX, но еще надо сказать об одном компоненте RemoteFX, о котором пока не упоминалось. У RemoteFX есть набор интеллектуальных кодеков для кодирования и декодирования графических данных, посылаемых через RDP, которые сжимают информацию. Эти кодеки являются ключом ко всему RemoteFX, они дают повышенную производительность и используют меньшую полосу пропускания. Если у вас есть ASIC в RDSH, работа кодека будут приносить пользу, передавая кодирование и декодирование ASIC без применения возможностей GPU.
Перенаправление RemoteFX USB
Другая важная функция RemoteFX — это перенаправление USB. Традиционный RDP имеет несколько возможностей перенаправления устройств высокого уровня, таких как направление ввода, перенаправление смарт-карты, перенаправление порта, двунаправленное аудио, протокол передачи изображения, перенаправление принтера (с использованием EasyPrint для печати без драйвера) и диска. Сегодня существует огромное количество устройств, которые не поддерживаются обычным перенаправлением RDP.
RemoteFX обращается к ним посредством перенаправления устройства на уровне протокола USB. Это означает, что гораздо больше устройств могут быть перенаправлены с использованием возможности перенаправления RemoteFX USB, а вы можете получать доступ к устройствам, таким как сканеры, устройства «все в одном», различные карманные устройства, мобильные телефоны, мультимедийные гарнитуры, веб-камеры и биометрические устройства. Пример такого усовершенствованного перенаправления USB можно увидеть на экране 3. При обычном перенаправлении RDP я вижу одно устройство, которое может быть перенаправлено. При использовании RemoteFX USB я могу видеть гораздо больше.
Экран 3. Настройка USB |
Добавление этой функции не означает, что перенаправление RDP на высоком уровне больше не нужно. При использовании перенаправления RemoteFX USB вы осуществляете перенаправление на уровне USB. Таким образом, драйвер устройства перенаправляется и должен быть установлен на удаленной операционной системе. Устройство более недоступно на локальном клиенте, что не подходит для клавиатуры и мыши. При использовании обычного перенаправления RDP драйвер нужен только на локальном клиенте, и это перенаправленное устройство может использоваться во множественных сессиях, в то время как перенаправление RemoteFX USB делает его доступным только для одной сессии за раз.
В выпущенном RemoteFX из состава Server 2008 R2 SP1 перенаправление USB и vGPU взаимосвязаны. Если на виртуальной машине вы не можете активировать vGPU, потому что вашему процессору не хватает поддержки SLAT или у вашего сервера нет FPU, вы не сможете использовать перенаправление RemoteFX USB. Это также означает, что перенаправление RemoteFX USB недоступно для сессий, основанных на RDSH. Вы можете ожидать обновлений в последующих версиях, включая потенциальное разделение этих возможностей.
Поскольку вы используете компонент RDS, вам нужно несколько лицензий RDS CAL для клиентов, которые пользуются преимуществами RemoteFX. Поскольку это привязано к VDI, многие компании, которые могут задействовать RemoteFX, уже имеют несколько RDS CAL как часть комплекта для того, чтобы активировать применение других компонентов RDS, которые часто используются при развертывании VDI.
Активация и использование Remotefx
Для основанных на Hyper-V виртуальных машин и использования RemoteFX вам нужно сделать несколько изменений на сервере. Необходимо убедиться, что сервер отвечает требованиям RemoteFX, таким как наличие графического процессора и поддержки SLAT процессором. Вам нужно активировать служебную роль Remote Desktop Virtualization Host, которая является частью роли Remote Desktop Services, и убедиться, что Core Services и RemoteFX, как дочерний компонент Remote Desktop Virtualization Host, установлены, как показано на экране 4.
Экран 4. Компоненты RDS нуждаются в активации RemoteFX |
Впервые установив компонент, вы увидите, что доступен новый тип оборудования, который может быть добавлен к виртуальной машине. Это RemoteFX 3D Video Adapter. Добавьте это оборудование к виртуальной машине, а затем настройте его для этой виртуальной машины, как показано на экране 5. Убедитесь, что клиент работает на Windows 7 SP1, затем создайте соединение с удаленного клиента RDP 7.1 с активированным RemoteFX.
Экран 5. Настройка RemoteFX |
Чтобы разрешить перенаправление RemoteFX USB, нужно внести изменение на клиентах при помощи Group Policy. Перейдите в раздел управления политикой Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Connection Client и RemoteFX USB Device Redirection и включите настройку Allow RDP redirection of other supported RemoteFX USB devices from this computer. Укажите тех, у кого есть права перенаправления RemoteFX USB, затем нажмите OK и закройте редактор политик.
Помните, что пока RemoteFX доступен только для соединений по локальной сети. Поэтому проверьте вкладку Experience на Remote Desktop Connection Client. Если вы выберете не локальное соединение, RemoteFX будет работать неправильно, и у вас будут возможности обычного RDP.
SP1 позволит вам получить максимум возможного от своей инфраструктуры виртуализации, основанной на Hyper-V. Он не только добавляет возможность интенсивного использования памяти, но и обеспечивает более гибкое управление памятью виртуальных сред. При использовании RemoteFX основанные на Hyper-V среды VDI позволяют задействовать возможности разных оконечных устройств, которые поддерживает RemoteFX.
Невосполнимое распределение ресурсов памяти
Один из методов, позволяющих рассмотреть, как виртуальная машина работает с сервером виртуализации, можно описать так: «Этот блок имеет 16 Гбайт памяти. Я хочу оставить 1 Гбайт для гипервизора, управления и частичного разделения диска. Остальные 15 Гбайт памяти я использую для виртуальных машин. Память, которую я могу распределить по виртуальным машинам, не может быть больше 15 Гбайт. Я мог бы обладать 15 виртуальными машинами с 1 Гбайт памяти у каждой и семью виртуальными машинами с 2 Гбайт памяти каждая и т. д.»
Этот метод показывает, что физической памяти RAM всегда достаточно, даже если все ваши виртуальные машины запущены. Обычно виртуальные машины не используют всей памяти, распределенной на них. Невосполнимое распределение ресурсов памяти выигрывает от этого, поскольку мы получаем возможность назначать большее количество памяти на виртуальные машины, чем физически существует в блоке. Этот подход основан на ожидаемом реальном использовании частей, которые были обнаружены и спланированы. Виртуальная машина исходит из того, что обладает полным объемом памяти, однако на самом деле память виртуальной машины не соединена с физической RAM до того, пока виртуальная машина не попытается обратиться к ней. Как только виртуальная машина обращается к своему виртуальному пространству памяти, страницы соединяются с физической RAM.
Проблема невосполнимого распределения ресурсов памяти заключается в том, что вы распределяете ресурсы, которые на самом деле есть у вас в блоке. Если эти ресурсы распределяются с условием максимально возможного использования, у вас будет недостаточно необработанных ресурсов, а виртуальные машины на самом деле не получат достаточного количества ресурсов. Тщательное планирование поможет избежать этих проблем, но невосполнимое распределение ресурсов памяти не работает так хорошо с современными операционными системами, как в устаревших операционных системах.Операционные системы сегодня экономны. В старых версиях Windows, если было 4 Гбайт памяти, а вам нужно было 1,5 Гбайт, вы могли видеть огромную цифру значения свободной памяти в Task Manager. Гипервизор, который распределял RAM на первое использование, не назначал оставшиеся 2,5 Гбайт на другую виртуальную машину, поэтому невосполнимое распределение ресурсов было безопасным. Сейчас у операционных систем потерь нет. Какую бы память они ни имели, они будут пытаться использовать ее для работы со свойствами кэша, по большей части с SuperFetch (который был внедрен Windows Vista и сначала загружал в память наиболее часто используемые приложения, чтобы они быстрее начинали работу). У операционных систем Linux предусмотрена похожая функциональность. Вы можете в этом убедиться, если взглянете на значения Free (свободной) и Available (доступной) памяти. У меня есть 12 Гбайт памяти, свободной — только 68 Мбайт, а доступной — 10 Гбайт. Windows использует 10 Гбайт памяти в качестве кэша, чтобы хранить информацию, которую я использовал или могу использовать. Однако данные можно легко удалить из кэша, чтобы воспользоваться программами, которые могут потребоваться. Именно поэтому значение Available включает в себя память Cached.
В гипервизоре, который распределяет физическую память при первом обращении, невосполнимое распределение ресурсов памяти не поможет, потому что Windows Server 2008, Windows Vista, последующая версия операционной системы Windows и современные операционные системы Linux будут пытаться использовать любую память, которая есть, для улучшения производительности. Первое распределение памяти не будет эффективным и несет в себе риск снижения производительности.«Воздухоплавание»
Процесс возвращения памяти, которая больше не нужна виртуальной машине, называется «воздухоплаванием». Это способ заставить операционную систему решить, какой объем памяти ей требуется. Драйверы «воздухоплавания» — это драйверы центрального узла устройства, поэтому операционные системы дают им память, когда они просят об этом. Менеджер виртуализации указывает гостевому компоненту нарастить драйвер «воздухоплавания» до определенного размера. Драйвер «воздухоплавания» делает запрос о количестве памяти операционной системе. Та, в свою очередь, обследует свою память и ищет наилучший способ выполнить запрос (надеясь сделать это только назначением свободной памяти, но, возможно, она использует память, которая распределена на кэш, и, вероятно, извлекает страницу из памяти для файла страницы гостевой операционной системы). Гостевая операционная система решает, от каких страниц отказаться так, чтобы нанести наименьший ущерб производительности.К однажды распределенной на драйверы «воздухоплавания» памяти обращается менеджер виртуализации, который сообщает гипервизору, что тот теперь не может обращаться к ней с физической RAM: на самом деле драйвер «воздухоплавания» никогда не будет трогать память, и ни одной части гостевой операционной системы не дозволено делать это. Способ «воздухоплавания» — очевидный метод возвращения памяти вручную и самая лучшая возможность запросить у виртуальной машины область памяти. Если виртуальной машине требуется дополнительная память, то она может попросить драйвер «воздухоплавания» выпустить и перераспределить физическую RAM на области памяти, возвращенные гостевой операционной системе.
Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP