На днях после года бета-тестирования вышел Remote Desktop Services Connector для SCVMM, часто именуемый в кругах Microsoft как RDV plugin for VMM.
RDS Connector позволяет SCVMM учитывать текущую загруженность узлов при размещении VDI десктопов на узлах виртуализации, по сути выполняя операцию Intelligent Placement. Что более важно, наличие данной компоненты позволяет RD Connection Broker отслеживать состояние виртуальной машины, - если та переносится между узлами, брокер переключает соединение вслед. Если брокер попытается включить виртуальную машину из сохранённой копии на узле, которому не хватает ресурсов, SCVMM теперь сможет перенести машину на другой узел, чтобы поднять её там.
Устанавливать RDV plugin можно на любом сервере, имеющем установленную консоль администратора SCVMM, потому и доступен он в 32-бит и 64-бит версиях. Очевидно, что оптимальнее всего будет использовать компоненту непосредственно на сервере SCVMM, который также является RD Connection Broker. Remote Desktop Services Connector начинал разрабатываться еще более года назад, предполагалось, что он будет поддерживать лишь персональные VDI десктопы. Однако, с разработкой Service Pack 1 для Windows Server 2008 R2 и обновлением самого RDS Broker, была реализована поддержка и общих (pooled) десктопов. Сам RDS Connector поддерживает персональные виртуальные машины в случае использования брокера 2008 R2, а для поддержки общих виртуальных машин требуется установка SP1 на сам RDS Broker. К Hyper-V данная компонента прямого доступа не имеет. Текущая версия документации к компоненте будет обновлена с выходом Service Pack 1. Сам RDS Connector обновления не потребует.
Внимание: Официальная позиция Microsoft такова: Microsoft has not released SP1 to OEMs at this time, though we are on track for a Q1 release, as we previously announced. The comments made in this blog entry included some inaccuracies.
Очередная значимая веха на победном пути виртуализации Microsoft – релиз первого пакета обновлений для Windows 7 и Windows Server 2008 R2.
Для Hyper-V данный пакет примечателен в первую очередь появлением долгожданной функции динамической памяти и возможностей RemoteFX. Мы достаточно глубоко рассмотрели обе технологии в прошлых заметках, сейчас поговорим о другом. Помимо анонсированных двух нововведений в Service Pack 1 включены все обновления, выходившие ранее для Hyper-V R2. Поддержка новых процессоров Nehalem и Westmere, исправления работы VSS, и так далее. Со списком можно будет ознакомиться уже завтра на сайте Microsoft.
Неожиданным, но приятным анонсом явилось увеличение рейтинга отношения возможного суммарного количества виртуальных процессоров к количеству логических процессоров на системе. Как мы помним, ранее значением поддержки являлось 8:1. С выходом первого пакета обновления данное значение увеличено до 12:1 для задач VDI в случае использования на серверах виртуализации исключительно гостевых систем с Windows 7 Service Pack 1. Подробности можно увидеть из следующей статьи TechNet. Что это даёт? Теперь на двухпроцессорном сервере с новыми процессорами Xeon Westmere можно запустить до 144 виртуальных машин! Не зря на TechEd рассказывалось о том, что плотность в VDI задачах увеличена на 40% с SP1. Обращу внимание – изменение касается только клиентских SKU. Данное изменение поддержки отношения суммы используемых виртуальных процессоров к количеству логических процессоров никак не влияет на максимально возможное значение количество виртуальных процессоров в одной виртуальной машине, здесь изменений не произошло.
Пакет обновления будет публично доступен в первом квартале. Для установки следует удалить предварительные версии данного пакета, если таковые установлены на вашем ПК или сервере. В первое время для скачивания будет доступен пакет обновления «нулевой волны», включающий в себя поддержку английского, но не содержащий русского языка. Если вам не терпится установить его на русифицированную систему, придется доставить английский интерфейс, сделать его по умолчанию, удалить русский, поставить пакет обновления, а затем вернуть русский язык.
Обновлено: Официальная позиция Microsoft такова: Microsoft has not released SP1 to OEMs at this time, though we are on track for a Q1 release, as we previously announced. The comments made in this blog entry included some inaccuracies.
За последние несколько месяцев я несколько раз начинал писать статью про динамическую память, которая приходит в Hyper-V R2 с Windows Server 2008 R2 Service Pack 1, - и столько же раз откладывал написание статьи. Писать многотомные мемуары, переводя известные статьи главы подразделения виртуализации Microsoft нет никакого желания, - там больно много маркетинга; а реального материала для написания статьи мне не хватало. Сейчас, в разгар TAP программы, с внедрением предварительной версии Service Pack 1 у ключевых заказчиков, у меня появляются материалы. Я решил написать две заметки – теоретическую об архитектуре динамической памяти, поддерживаемых платформах, типичных настойках, использовании динамической памяти, приоритетах и связи с физической памятью, изобилующую глубокой теорией организации памяти в Windows; и более практическую, рассказывающую о настройках динамической памяти через Virtual Machine Manager. Начнем..
Что же такое – динамическая память? Очевидно, это есть некий механизм, который при необходимости увеличивает или уменьшает объём памяти, доступной виртуальным машинам. Как это происходит?
С точки зрения архитектуры Hyper-V это выглядит следующим образом:
Dynamic Memory VSC (Virtual Service Consumer) – компонента в виртуальной машине, которая
Dynamic Memory VSP (Virtual Service Provider) – компонента на хосте виртуализации, которая
Memory Balancer – компонента на хосте виртуализации, которая
Каким образом виртуальной машине предоставляется дополнительная память?
Каким образом у виртуальной машины забирается память?
Используется метод «воздушного шарика» – в гостевой ОС специальный драйвер начинает потреблять выделенную память, занимая её, чтобы ОС в ВМ не могла к ней обратиться, а по сути, отдавая занятую память гипервизору для других виртуальных машин. Гостевая ОС продолжает считать, что у неё «много» памяти, просто она занята неким процессом и помечена как «driver locked». При последующих добавлениях памяти к этой виртуальной машине память будет добавляться в адресное пространство этого процесса – и высвобождаться им для нужд ОС.
Чтобы понять, как гипервизор понимает, каким виртуальным машинам в настоящее время требуется дополнительная память, а у кого её можно забрать нам потребуется ввести термин загрузка памяти виртуальной машины (Guest Memory Pressure), в процентах отражающий текущую ситуацию с памятью виртуальной машины – отношения объёма памяти, которую процессы используют в настоящее время к объёму физической памяти, выданной данной машине. Увы, на словах это довольно сложно объяснить, посему я расскажу вам об архитектуре использования памяти в Windows.Поговорим о том, как вообще используется память. Ведь даже без всякой виртуализации мы разделяем физическую память «physical memory» и виртуальную память «virtual memory». Любые приложения и даже ядро ОС работают именно с виртуальной памятью. Как это выглядит?
32-битные версии ОС адресуют только 4ГБ памяти. По умолчанию, память делится пополам между процессами режима ядра и пользователя. Однако это поведение может быть изменено ключами /3GB и UserVA, которые позволяют выделить больше памяти процессам в режиме пользователя.
64-битные версии ОС в теории могут адресовать до 16ЭБ памяти. На деле, текущие 64-бит реализации Windows адресуют до 16ТБ памяти, но как мы знаем, с установкой роли Hyper-V ОС Windows может использовать лишь 1ТБ памяти. Также как и в предыдущем случае, этот виртуальный 1ТБ делится поровну между режимами ядра и пользователя, с возможностью повлиять на этот процесс через BCDEdit.
При переключении между процессами уровня пользователя Windows переключает текущее адресуемое пространство виртуальной памяти на то, которое используется процессом, в данный момент обрабатываемым процессором. Процессы режима ядра всегда занимают своё пространство памяти, вне зависимости от того, какой процесс в данный момент обрабатывается процессором:
Поговорим о терминологии, используемой в Windows, при описании памяти:
Зарезервированная (Reserved) память – память, выделяемая под конкретный процесс, запрашивающий набор блоков памяти в своём адресном пространстве. Зарезервированная память не связана напрямую с физической (в оперативной памяти или на диске), так что процесс не может ничего в ней хранить.
Гарантированная (Committed) память – память, выделенная под процесс из физической памяти – оперативной или дисковой (файл подкачки или другие временные файлы памяти).
Свободная (Free) память – память адресного пространства, не используемая процессами.
Предел гарантированной памяти (System Commit Limit) – максимальный объём памяти, которую система может гарантировать процессам. Равен размеру оперативной памяти + файлов подкачки.
Текущее гарантированное значение (Current System Commit Charge) – суммарное количество памяти, гарантированной в настоящий момент процессам.
Пустые страницы (Zeroed Pages) – обнулённые страницы памяти готовые к использованию процессами.
Свободные страницы (Free Pages) – неиспользуемые страницы памяти, которые еще не обнулены, и потому не могут ещё быть переданы другим процессам.
Изменённые страницы (Modified Pages) – страницы, которые уже некоторое время не использовались процессом, но содержат некие изменения, которые необходимо записать на диск перед высвобождением страниц.
Ожидающие страницы (Standby Pages) – страницы памяти, уже записанные на диск, но ещё не высвобожденные. Они могут быть отданы оригинальному процессу, если он к ним обратится, но также могут быть очищены и отданы другому процессу при необходимости.
Рабочее множество процесса (Working Set) – объём гарантированной процессу памяти, находящийся в настоящее время в оперативной памяти.
Активная (Active) память – объём памяти, используемый во всех текущих рабочих множествах.
Итак, возвращаемся к динамической памяти и тому, как же Hyper-V понимает, кому в данный момент память действительно требуется.
Загрузка памяти виртуальной машины (Guest Memory Pressure)
Как я уже говорил выше, термин загрузки памяти виртуальной машины выражается процентным отношением текущего гарантированного значения и объёма физической памяти, реально адресуемой виртуальной машиной.
Посмотрим на реальном примере:
Моей виртуальной машине в настоящее время гипервизором выделено 798 МБ (на самом деле 798264 Килобайт) памяти. При этом сейчас данная система и её процессы используют 534 МБ (534780КБ) реальной оперативной памяти.
Отношение этих двух значений даёт мне процентный показатель загрузки памяти в виртуальной машине:
При этом 33% памяти в настоящий момент свободны и образуют так называемый свободный буфер (free buffer).
В реальной жизни бывают ситуации, когда значение превышает 100%. При этом активно используется файл подкачки внутри виртуальной машины и её производительность падает.
Как же гипервизор принимает решения о необходимости увеличения или уменьшения объёма памяти? Введём понятие шкалы загрузки (pressure band). В каждой виртуальной машине постоянно считается значение загрузки памяти. Для каждой виртуальной машины гипервизор отслеживает изменения этого параметра. И для каждой виртуальной машины, на основе её исторических показателей, формирует так называемую шкалу загрузки. При этом за некие минимальный и максимальный индикаторы шкалы берёт значения из истории использования данной конкретной виртуальной машины:
Если значение текущей загрузки памяти данной виртуальной машины находится между её историческими минимальным и максимальным индикаторами, то ничего не происходит. Если процент загрузки памяти падает ниже исторического минимального значения – балансировщик памяти логически мыслит, что виртуальная машина неэффективно использует предоставленную ей память, и забирает часть памяти, возвращая значение загрузки памяти в границы шкалы загрузки. Если процент загрузки памяти начинает превышать историческое максимальное значение, это означает, что виртуальной машине не хватает памяти, и балансировщик принимает решение динамически добавить ей памяти. Если свободной памяти для добавления в настоящее время нет, балансировщик может несколько повысить значение минимального индикатора в шкале загрузке всех виртуальных машин и забрать неиспользуемую память.
Какие параметры влияют на процесс распределения памяти? Балансировщик выделяет или забирает память исходя из следующих параметров:
Как работает свободный буфер?
Каждая виртуальная машина в некий момент времени имеет некий объём реальной памяти. Часть этой памяти – индицируемый термином загрузки памяти используется процессами. Это мы уже рассматривали. Остальная память (100% - загрузка памяти%) как раз и называется свободным буфером. Некое процентное отношение от выделенной памяти, которое вы хотите оставить в данной виртуальной машине свободным, чтобы она в любой момент времени могла начать использовать реальную память.
Объём памяти в любой момент состоит из занятой памяти (её процент характеризуется значением загрузки памяти) и буфером.
Объём в мегабайтах данного буфера можно вычислить из значений сконфигурированного вами в свойствах виртуальной машины значения желаемого свободного буфера (в процентах) и текущего объема занятной памяти:
Чтобы понять это на реальном примере, рассмотрим ситуацию:
Моя виртуальная машина сконфигурирована с начальным значением памяти в 512МБ и максимальным в 64ГБ. Значение в процентах свободного буфера я установил равным 25%. То есть я предполагаю, что четверть всей памяти, выделенной виртуальной машине, не будет использоваться активными процессами, а будет резервом для будущего использования. Очевидно, что как только она начнет использоваться, процентное значение свободного буфера упадет ниже требуемых 25% и балансировщик начнёт добавлять память виртуальной машине.
Предположим, что в некий момент времени моя виртуальная машина получила 673 МБ, а реально потребляет 515МБ:
Согласно формуле, озвученной выше, размер буфера свободной памяти должен вычисляться по формуле:
Тогда объём памяти, который балансировщик должен предоставить виртуальной машине целевой памяти в объёме:
Так как в данный момент памяти машина имеет меньше, и свободный буфер составляет менее требуемых 25%, балансировщик начинает процесс добавления памяти:
Поговорим о настройке приоритетов для динамической памяти
Очевидно, что не всегда количество физической памяти на сервере будет достаточным, чтобы покрыть аппетиты виртуальных машин. Когда запрашиваться у балансировщика будет больше чем он может предоставить, он начнёт кому-то отказывать. Кому именно, и в какой мере – зависит от приоритета в настройках динамической памяти каждой виртуальной машины.
Разницу между объёмом целевой памяти (сколько виртуальная машина хотела бы получить от балансировщика при наличии неограниченного объёма свободной памяти) и реально выданной памятью называется штрафом. Логично предположить, что чем выше приоритет, тем меньше штраф. То есть для виртуал��ных машин с высоким приоритетом динамической памяти, балансировщик будет пытаться выделить максимальный объём и достичь целевого значения. Для виртуальных машин с меньшим приоритетом буфер свободной памяти может быть существенно меньше запрашиваемого, так что значение штрафа будет высоким.
Резерв памяти для родительского раздела
Теперь у нас появилась возможность указать явно, какой объём памяти мы готовы эксклюзивно предоставить самому хосту виртуализации. На этот объём виртуальные машины претендовать не будут. Это помогает получить уверенность, что аппетиты высокоприоритетных виртуальных машин не лишат памяти сам гипервизор.
Значение MemoryReserve в ветви реестра HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization позволяет настроить данный резерв.
Изменение данного значения потребует перезагрузки узла.
Файл подкачки в виртуальных машинах
Включение динамической памяти для виртуальной машины делает необходимым использование её файла подкачки (pagefile). Ведь в случае нехватки реальной памяти на узле и требовании балансировщика отобрать память у вашей виртуальной машины, она начнёт активно писать свою память в файл подкачки, чтобы отдать требуемый кусок памяти балансировщику.
Каким объёмом задать файл подкачки, – тема для отдельного исследования. Я для себя уже наметил некоторую формулу, которой готов поделиться по почте (в комментариях отвечать не буду). Очевидно, что стандартные значения, предлагаемые вам операционной системой вполне достаточны. Однако если вы выставляете максимальным значением памяти стандартные 64ГБ, то рискуете получить файл подкачки аналогичного размера. Если вас тема затронула, и вы имеете свои соображения, пишите, обсудим.
Хочу подвести некий итог. Service Pack 1 для Windows Server 2008 R2 и Hyper-V Server R2 принёс два крупных нововведения. Поддержку динамической памяти и поддержку полноценного видео и USB устройств в виртуальных машинах через RemoteFX. Мы рассмотрели обе технологии, а в ближайшем будущем я расскажу о том, как данными нововведениями можно управлять при помощи System Center Virtual Machine Manager, который также получит долгожданный пакет обновлений вскоре после самой ОС.
С некоторой задержкой после «Платформы» я бы хотел начать серию статей о востребованной задаче виртуализации, - защите вашей виртуальной инфраструктуры между двумя датацентрами. Бывают форс-мажорные ситуации, когда нарушена работа основного центра обработки данных (ЦОД) компании: проблемы с электропитанием, кондиционированием, незваными «гостями» в черных масках. Как защитить критические для бизнеса сервисы, чтобы, в случае возникновения проблем в основном ЦОД, их работоспособность могла в кратчайшее время быть восстановлена в резервном? У основного конкурента есть решение, называемое Site Recovery Manager, позволяющее защитить виртуальные машины между ЦОД, настроив перенос критичных сервисов в случае отказа одного из датацентров. Увы, ни ОС Windows Server 2008 R2, ни System Center Virtual Machine Manager 2008 R2 ничего подобного не предлагают. Выходящий в ближайшее время Service Pack 1 ситуации не меняет. Очевидно, существует необходимость решать такую задачу. В помощь приходит продукт Citrix Essentials for Hyper-V и его компонента StorageLink Site Recovery.
Что же дает StorageLink Site Recovery? По сути, данный продукт решает вышеописанную задачу: настраивает репликацию конфигураций виртуальных машин между узлами или кластерами узлов Hyper-V между несколькими ЦОД. Продукт тесно интегрируется с системами хранения данных, позволяя настроить репликацию между хранилищами в традиционном интерфейсе MMC, указав тип репликации, выбрав виртуальные машины для защиты, настроив правила переноса и возврата виртуальных машин.
Существует несколько изданий Citrix Essentials for Hyper-V. Нас для задачи Site Recovery устраивают лишь два: максимальное Platinum для крупных промышленных внедрений и бесплатное Express для защиты небольших кластеров – по два узла в ЦОД. Очевидно, бесплатное решение имеет некие технологические ограничения, в основном касающиеся количества узлов в защищаемом кластере и возможностей настройки полностью автоматического переноса виртуальных машин между ЦОД в случае возникновения проблем с одним из датацентов.
Предваряя вопросы, расскажу о стоимости. Citrix Essentials Platinum лицензируется на физический узел. Розничная стоимость лицензии на один узел, согласно Яндексу, составляет порядка $3000. Для оценки: предположим, наш кластер в основном ЦОД имеет 16 узлов (максимально возможное количество серверов в кластере) и на нём запущено 1000 виртуальных машин. Для такой конфигурации я исхожу из объема памяти на узле в 128ГБ, современные блейд серверы поддерживают до 512ГБ, а Hyper-V поддерживает до 1ТБ памяти на узле. Из данной 1000 виртуальных машин, посчитаем 400 критически важными для бизнеса компании, с необходимостью их работы в случае отказа основного датацентра. Очевидно, что многие инфраструктурные сервисы и часть бизнес систем, используемых в офисе компании также важны и критичны, но в случае форс-мажора, их недоступность в течении некоторого времени не нанесет ущерба бизнесу компании, так что мы можем не заниматься их защитой. Для запуска 400 виртуальных машин в резервном ЦОД нам потребуется кластер из 7 узлов – с теми же требованиями к серверам, что и в основном ЦОД. Стоимость лицензий Citrix для 16+7=23 серверов составит не более $70000. Много ли это? Решение конкурента VMware Site Recovery Manager не входит даже в самое максимальное издание vSphere Enterprise Plus, но лицензируется отдельно по количеству защищаемых виртуальных машин. Базовая цена пакета на 25 виртуальных машин, согласно тому же Яндексу, составляет порядка $12000. То есть для защиты 400 виртуальных машин за SRM придется доплатить порядка $192000. Так что цена в $70000 за решение от Citrix перестает казаться завышенной. А ведь в Citrix Essentials Platinum входит далеко не только StorageLink Site Recovery.
Что же вообще включено в продукт? Что вы получите вдобавок к Site Recovery при покупке лицензий Citrix?
Во-первых, сам StorageLink совсем не ограничен применением для Site Recovery. По сути StorageLink предоставляет возможности thin provisioning, автоматизации создания требуемых конфигураций на хранилищах для виртуальных машин посредством шаблонов, поддержку любых дисковых массивов, в том числе NAS решений, управление всеми дисковыми хранилищами из единой консоли и многое другое.
Во-вторых, в Essentials for Hyper-V также входит и Lab Manager – решение для автоматизации сценариев разработки и тестирования программного обеспечения, а также проведения тренингов и обучения. В чём-то продукт похож на Visual Studio 2010 Lab Manager.
В-третьих, полезной компонентой Essentials является Provisioning Server, позволяющий динамически создавать виртуальные машины по мере необходимости.
В-четвертых, Workflow Studio позволяет автоматизировать выполнение типовых задач. Решение напоминает Opalis, но более тесно интегрировано с продуктами Citrix.
Понятно, что программный продукт не подарит вам возможности репликации данных между вашими ЦОД, если дисковые хранилища этого не поддерживают, или не лицензированы на выполнение репликации. На данный момент StorageLink Site Recovery работает со следующими дисковыми системами, позволяя настроить их репликацию и защиту виртуальных машин из своей консоли:
В одной из следующих статей я опишу процесс настройки стенда Site Recovery, не требующего каких-либо начальных инвестиций. Мы воспользуемся бесплатной версией Express и виртуализованными дисковыми хранилищами HP P4000, - виртуальными машинами Hyper-V, представляющими любые локальные диски (DAS) или ваш SAN как виртуальный iSCSI SAN HP P4000 с возможностями построения сетевого массива RAID и настройки программной репликации массивов. Для промышленных сценариев, очевидно, мы рекомендуем выбирать аппаратные решения репликации.
Если тема построения сценария Site Recovery на виртуальной платформе Microsoft актуальна для вашего бизнеса, и вы бы хотели обратиться в Microsoft за коммерческим предложением по проектированию подобной системы, выполнению пилотного проекта, или построения решения под ключ, напишите мне через форму справа, Microsoft Consulting имеет опыт выполнения таких проектов у различных крупных заказчиков в разных странах. Мы тесно сотрудничаем с Citrix, что гарантирует тщательность и проработанность дизайна такой системы.
Если у вас есть общие или технические вопросы по построению Site Recovery на платформе Hyper-V, можете задавать их в комментариях (блог публикует комментарии только от зарегистрированных пользователей, имеющих LiveID) или свяжитесь со мной через ту же форму справа, я отвечу на вопросы или перенаправлю на необходимых специалистов.
Во вопросу «а как настроить» прошу подождать следующей статьи цикла. Мы рассмотрим решение с виртуализованным HP P4000 и StorageLink Express, но я отдельно уделю внимание сценариям, которые доступны лишь в Platinum версии, и оговорю отличия между реальным и виртуальным SAN.