Меню

Xen windows grid k1 настройка



Установка Windows на Xen

Установка Windows на Xen очень сильно отличается от развертывания паравиртуализованных гостей — есть отличия как в процессе установки, так и в последующей настройке . Все моменты я постараюсь подробно объяснить в статье.

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

Установка Windows на Xen

Как всегда сначала обратимся к теоретической составляющей.

Типы DomU

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

Все это, разумеется, относится лишь к свободно распространяемым операционным системам. ОС с закрытым кодом, такие как Windows, не могут похвастаться «пропатченным» под Xen ядром, в этой связи им необходима эмуляция оборудования. Такие ОС называются полностью виртуализованными гостями (или HVM-guests — Hardware-assisted virtualizion).

В плане производительности PV и HVM — это две крайности.

Чтобы как-то улучшить показатели гостей HVM, были разработаны специальные драйверы, называемые PVHVM-drivers 2 . Подобные драйверы для PV-гостей уже встроены в ядро, а потому в их установке нет никакой необходимости.

Сводную таблицу с типами гостей вы можете найти в официальной документации:

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

Источник

Виртуализация рабочих станций с использованием платформы NVIDIA GRID

Индустрия проектирования, дизайна и визуализации интенсивно выходит в облака. Сейчас ни кого не удивить словосочетанием «посчитаем и сохраним в облаке», а для многих студий это может дать большие возможности в экономии средств и развертывании IT-инфраструктуры и привлечения работников с внешней стороны (аутсорсинг).
Одним из серьезных препятствий применения виртуализации в дизайне предыдущих лет являлся вывод в облака высокопроизводительных рабочих станций используемых для проектирования в пакетах CAD и DCC. В первую очередь это было обусловлено отсутствием соответствующего оборудования, особенно графических процессоров (GPU) которые так необходимы в работе с ресурсоемкими CAD и DCC приложениями. В 2012 году компания NVIDIA выпустила первые продукты линейки GRID ориентированные на применение в виртуальных средах и предназначенные для виртуализации рабочих станций. К NVIDIA подключились такие известные компании разработчики платформ и инструментов виртуализации, как Citrix, VMware, Microsoft и за три года представили рынку комплексные решения для виртуализации с поддержкой GPU и Виртуализированных GPU (vGPU). Затем к новому направлению стали присоединяться разработчики прикладных приложений, такие как Autodesk, Adobe и другие. Стали разрабатываться новые модели лицензирования по подписке и выполняться оптимизация приложений и лицензий под применение в виртуальных средах.
В представленной вашему вниманию статье рассматриваются основные принципы виртуальных рабочих станций и технологии виртуализации, какие возможности получают пользователи при использовании виртуализации с поддержкой полноценных вычислений на GPU. Как ведут себя профессиональные графические приложения, и какие возможности графических подсистем поддерживаются при работе на виртуальной рабочей станции.
Материал подготовлен при поддержке наших старых друзей, — компании FORSITE, любезно предоставившей тестовую платформу с несколькими виртуальными машинами в различных конфигурациях, а также всю необходимую информацию по виртуализации рабочих станций с поддержкой полноценного ускорения графики.

Графические ускорители NVIDIA GRID K1 и K2

Основная задача графических ускорителей NVIDIA GRID заключается в предоставлении высокой производительности графики в работе с ресурсоемкими приложениями требовательными к графическим вычислениям напрямую в виртуальной среде. Компания NVIDIA предлагает две модели графических процессоров линейки GRID, – K1 и K2. В ряде случаев могут быть использованы графические ускорители линейки NVIDIA Quadro, но решения Quadro не предназначены для установки в сервера и не позволяют обеспечить необходимую для задач виртуализации плотность, а также существует необходимость в большом количестве таких ускорителей.

Рассмотрим основные характеристики решений K1 и K2. Так как графические ускорители линейки GRID должны быть установлены в сервера их корпус, и система охлаждения значительно оптимизированы, обеспечивая хорошее охлаждение графическим чипам и памяти при интенсивной нагрузке. В моделях K1 и K2 лежат графические чипы на основе архитектуры NVIDIA Kepler. Чип GK107 используется в модели K1, а чип GK104 в модели K2. Модель K1 ориентирована на применение в виртуализации рабочих столов и приложений, не требующих высокой производительности от графической подсистемы, но в то же время, когда необходимо развернуть виртуальные машины для множества пользователей, в данной модели используется 4Гб графической памяти на каждый из четырех GPU. В то же время модель K2 ориентирована на более требовательные к графическим вычислениям приложения, такие как пакеты DCC. В данной модели используются более производительные GPU и быстрая память, для каждого из них также выделено по 4Гб графической памяти стандарта GDDR5.

В таблице 1.1 приведены основные технические характеристики GPU NVIDIA GRID K1 и K2.

Citrix XenServer с NVIDIA GRID Hypervisor

+ XenDesktop с HDX

Windows Server 2012 + RemoteFX

Windows Server 2008 R2 + RemoteFX

VMware ESXi + View с vSGA

Citrix XenServer + XenDesktop с HDX 3D Pro

Citrix XenServer с NVIDIA NVIDIA GRID

Hypervisor + XenDesktop с HDX

Windows Server 2012 + RemoteFX

Windows Server 2008 R2 + RemoteFX

VMware ESXi + View с vSGA

Таблица 1.1. Конфигурация плат NVIDIA GRID K1 и K2.

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

Виртуализация рабочих столов и vGPU

Перед тем как мы перейдем к практическим экспериментам и демонстрации работы технологии в реальных приложениях, необходимо разобраться с теоретическими аспектами виртуализации рабочих столов и GPU, а так же в том, как организован сервер с NVIDIA GRID управляемый решениями Citrix.

Терминология

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

  • CitrixReceiver – Легковесное приложение которое запускается на Windows, Mac, Linux, iOS, Android и Windows Phone устройстве пользователя и соединяется с виртуальной машиной в дата-центре на которой установлен Citrix XenDesktop.
  • CitrixXenDesktop – Продукт виртуализации рабочих столов от Citrix предоставляющий пользователю доступ к удаленному рабочему столу.
  • CitrixXenServer – Коммерческий гипервизор от Citrix который позволяет запускать множество операционных систем на одном серверном узле.
  • ВыделенныйGPU (DedicatedGPU) – решение, где GPU полностью используется виртуальной машиной не распределяясь между другими виртуальными машинами.
  • GPUPass-Through – технология которая связывает виртуальную машину с GPU. Эта технология разработана NVIDIA и известна как NMOS (NVIDIA Multi-OS). Она позволяет каждой операционной системе выполняемой на сервере виртуализации напрямую использовать все возможности физического GPU.
  • Хост (HostMachine) – компьютер на котором установлен гипервизор и запущена одна или несколько виртуальных машин и являющийся хостом. Каждая из виртуальных машин называется гостевой машиной. Гипервизор предоставляет гостевым операционным системам виртуальную операционную платформу и управляет выполнением гостевых операционных систем.
  • Гипервизор (Hypervisor) – технологически гипервизор или менеджер виртуальных машин (VMM) является частью программного обеспечения, прошивка или оборудование которого создают и запускают виртуальные машины.
  • Удаленная рабочая станция (RemoteWorkstation) – единица рабочей станции, которая запускается в дата-центре и перенаправляется через сеть на клиентское устройство. Удаленная рабочая станция может быть доступна как из офиса пользователя, так и может быть доступна со стороны партнерского портала, в путешествии или из дома пользователя.
  • Виртуальная машина (VirtualMachine) – единица операционной системы, которая запускается поверх гипервизора, используя абстрактный образ оборудования реализуемым гипервизором.
  • Виртуализация (Virtualization)– практика абстракции виртуальной машины из физического оборудования, на котором она выполняется. На практике виртуализация используется для запуска виртуальных машин на одном физическом сервере (оборудовании).
    • Инфраструктура виртуальных рабочих столов (VirtualDesktopInfrastructure (VDI)) – практика размещения операционной системы на виртуальной машине в централизованном или удаленном сервере.
    • Виртуализация оборудования (HardwareVirtualization) – создание виртуальной машины, которая действует подобно реальному оборудованию поверх гипервизора или как поднабор оборудования. Программное обеспечение выполняемое на таких виртуальных машинах, работает поверх ресурсов физического оборудования (т.е. операционная система может загружать родные для оборудования драйверы и взаимодействовать с ними напрямую).
    • Аппаратно-виртуализированныйGPU (HardwareVirtualizedGPU) – платы K1 и K2 на основе чипов архитектуры NVIDIA Kepler позволяют множеству пользователей использовать возможности одного GPU и предоставляют каждому пользователю прямой доступ к «железному» GPU. Это увеличивает плотность пользователей, предоставляя им реальную производительность и совместимость.
    • Программная виртуализация (SoftwareVirtualization) – программная виртуализация обеспечивает интерфейс между оборудованием и виртуальной машиной, создавая плотную адаптацию между различными уровнями конфигураций оборудования. На практике программы действуют аналогично аппаратным ресурсам, пропуская команды к гипервизору, который может выполнять их на реальном оборудовании или эмулируемом оборудовании.
    • ВиртуальныйGPUNVIDIAGRID (NVIDIAGRIDvGPU) – ключевая технология, используемая для реализации виртуализации GPU. Это позволяет множеству виртуальных машин взаимодействовать напрямую с GPU. Система GRID Virtual GPU управляет ресурсами GPU которые позволяют множеству пользователей распределять возможности основного оборудования увеличивая плотность и формировать возможности полноценных PC в облаке.

Как вы можете заметить, ключевые технологии достаточно просты в понимании их назначения. Но как же реализуется инфраструктура сервера виртуальных машин на базе гипервизора Citrix XenServer и NVIDIA GRID? Для демонстрации инфраструктуры в данной статье мы приведем два примера; первый для решения VDI на основе GPU Pass-Through, а второй для VDI на основе vGPU.

NVIDIA CUDA и vGPU важная особенность

Если вы планируете использовать приложения, активно использующие GPU для ускорения вычислений, вам стоит обратить внимание на важную особенность. Технология виртуализированных GPU (vGPU) не поддерживает NVIDIA CUDA, OpenCL и Direct Compute. Это технологическая особенность присущая технологии вычислений общего назначения на GPU. Для обхода данной особенности необходимо использовать Dedicated GPU с технологией GPU Pass-Through. Это позволяет напрямую выполнять обращение из виртуальной машины к графическому процессору и «пробрасывать» GPU-accelerated приложения из виртуальной среды на реальное оборудование. При использовании vGPU вам доступны только графические API, такие как OpenGL и DirectX.

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

Приложение

Поддержка vGPU

(OpenGL и DirectX)

Ограниченные возможности 1

Редакторы 3D графики и анимации

Источник

Xen windows grid k1 настройка

Memory exhaustion can occur with vGPU profiles that have 512 Mbytes or less of frame buffer.

This issue typically occurs in the following situations:

  • Full screen 1080p video content is playing in a browser. In this situation, the session hangs and session reconnection fails.
  • Multiple display heads are used with Citrix XenDesktop or VMware Horizon on a Windows 10 guest VM.
  • Higher resolution monitors are used.
  • Applications that are frame-buffer intensive are used.
  • NVENC is in use.

To reduce the possibility of memory exhaustion, NVENC is disabled on profiles that have 512 Mbytes or less of frame buffer.

When memory exhaustion occurs, the NVIDIA host driver reports Xid error 31 and Xid error 43 in XenServer’s /var/log/messages file.

The following vGPU profiles have 512 Mbytes or less of frame buffer:

  • Tesla M6-0B, M6-0Q
  • Tesla M10-0B, M10-0Q
  • Tesla M60-0B, M60-0Q
  • GRID K100, K120Q
  • GRID K200, K220Q

The root cause is a known issue associated with changes to the way that recent Microsoft operating systems handle and allow access to overprovisioning messages and errors. If your systems are provisioned with enough frame buffer to support your use cases, you should not encounter these issues.

Workaround

  • Use an appropriately sized vGPU to ensure that the frame buffer supplied to a VM through the vGPU is adequate for your workloads.
  • Monitor your frame buffer usage.
  • If you are using Windows 10, consider these workarounds and solutions:

    Use a profile that has 1 Gbyte of frame buffer.

    Optimize your Windows 10 resource usage.

    To obtain information about best practices for improved user experience using Windows 10 in virtual environments, complete the NVIDIA GRID vGPU Profile Sizing Guide for Windows 10 download request form.

    For more information, see also Windows 10 Optimization for XenDesktop on the Citrix blog.

    Источник

    Xen server своими руками. Часть первая

    В комментариях к топику Системное администрирование. Начало. прочитал, что сообществу были бы интересны статьи о виртуализации. Довольно давно у меня на жёстком диске лежит описание процесса установки Xen hypervisor и гостевой ОС на сервер под управлением Ubuntu/Debian.

    Большинство людей пользуют для виртуализации VmWare или VirtualBox редко кто Qemu.
    В том числе и под Win x32\x64 платформой они очень популярны. Творение The Sun даже понимает аппаратную поддержку Intel VT.
    Но я бы хотел поговорить о реальной альтернативе на Linux платформах — Xen.
    Тем более что он присутствует в репозиториях Ubuntu\Debian.

    Ставим Xen на сервер

    Для полной совместимости и возможности использовать все функции нам нужна аппаратная поддержка со стороны сервера.
    Intel VT (Virtualization Technology, aka Vanderpool): Selected Pentium 4 and Pentium D, Xeon 5000 and later, Xeon LV, Core Duo, Core 2 Duo, and Core 2 Quad processors
    AMD — V/SVM (Virtualization/Secure Virtual Machine, aka Pacifica): Selected Athlon, Opteron, and Turion Socket F and AM2 processors

    Intel VT — поддерживается во всех Core2Duo, так что это не проблема. Желательно зайти в BIOS и проверить включен ли.
    Аппаратная совместимость позволит нам запускать не модифицированные ОС (читай Win XP и прочее )

    Получаем версию ядра — в моём случае 2.6.24-19-generic, это нам пригодится позже.

    Ставим Xen на наш Ubuntu server 8.04.1 x64.
    Все команды приведённые далее требуют привилегий root, поэтому для экономии времени полностью переходим в рутовую консоль:

    aptitude install ubuntu-xen-server

    подтвердить установку всех запрошенных пакетов.
    Ждем конца установки.

    После старта сервера в удачном случае вы должны увидеть что система на новом ядре Xen.

    Видим что теперь ядро называется — 2.6.24-19-xen — как раз то что нам нужно.

    Гипервизор Xen запускает саму ОС Ubuntu уже на своем ядре.

    # xm list
    Name ID Mem VCPUs State Time(s)
    Domain-0 0 2048 8 r—— 167826.8

    Эта команда показывает что демон Xend запущен и работает, запустив основную систему и показывая ее состояние.

    Система готова для инсталяции гостевых ОС (далее DomU)

    Источник

    Почему не RemoteFX, а также подробнее о технологиии NVIDIA GRID VGPU

    Увеличение количества рабочих мест на предприятии и рост инфраструктуры ИТ в целом рано или поздно заставляет задуматься о ряде вопросов, связанных с более грамотным построением самой ИТ-инфраструктуры, нацеленной на решение следующих задач, стоящих перед сотрудниками ИТ-отдела:

    1. сокращение затрат на создание полноценных рабочих мест;
    2. создание более удобного механизма администрирования рабочих мест сотрудниками ИТ отдела и, как следствие, сокращение времени на выполнение тех или иных операций, связанных с технической поддержкой пользователей;
    3. реализация возможности резервного копирования и быстрого восстановления данных (или рабочих мест целиком).

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

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

    Довольно давно я знаком с гипервизором от компании Microsoft под названием Hyper-V. Надо отметить, что данный гипервизор с каждым следующим поколением серверной платформы Windows Server становится всё более функциональным и интуитивно понятным для администрирования. В PowerShell добавляются новые командлеты, позволяющие легко управлять гипервизором. Появляется отличная возможность реализовывать с помощью скриптов даже такие необходимые задачи, как резервное копирование виртуальных машин и создание снапшотов по расписанию в планировщике без использования сторонних и довольно дорогостоящих программ. Администрировать Hyper-V легко, производительность гипервизора не вызывает нареканий, постоянно растет список операционных систем, имеющих либо установленные службы интеграции с гипервизором, либо имеющих возможность установить такие службы, либо поддерживающих Hyper-V благодаря модулям ядра. Еще совсем недавно состоялся релиз FreeBSD 10.0, первой из BSD систем, которая легко и непринужденно устанавливалась в качестве гостевой на гипервизор от Microsoft, и которая избавилась от детских болячек, вроде ограниченного размера виртуального жесткого диска и возможности использования только устаревшего сетевого адаптера (legacy или эмулированного), чья скорость не может превышать 100мбит/сек, в то время как физический сетевой адаптер является гигабитным. В общем, как может показаться, тенденция к улучшению имеет ну очень положительную динамику. Именно поэтому изначально мы занялись поиском ответа на вопрос, о том, существует ли возможность использования физической видеокарты в гостевой операционной системе Hyper-V. Ответ, как нам казалось тогда, не заставил себя долго ждать и уже через 5 минут, судя по статьям в интернете, мы были уверены, что такая возможность существует и, более того, она качественно реализована разработчиками Hyper-V. Как оказалось, мы жестоко ошибались, но обо всем по порядку.

    Microsoft предложила в качестве решения технологию RemoteFX, которую изначально разрабатывала компания Calista Technologies, которая в последствии была приобретена Microsoft. Сама технология имеет очень весомые аппаратные требования как к серверу виртуализации, так и к видеокарте, которая в дальнейшем будет использоваться гостевой операционной системой посредством этой технологии. Требования заключаются в том, что сам сервер должен иметь CPU с поддержкой SLAT (EPT on Intel, NPT/RVI on AMD), а вот с GPU все еще веселее. Вот собственно требования и рекомендации, озвученные самими Microsoft:

NVIDIA GRID K1 NVIDIA GRID K2
Чип 4 × GK107 2 × GK104
Частота ядра 850 MHz 745 MHz
Частота памяти 891 MHz 2.5 GHz
Ядра NVIDIA CUDA 768 (192 на GPU) 3072 (1536 на GPU)
Объем памяти 16 GB (4 GB на GPU) 8 GB (4 GB на GPU)
Шина памяти 128-bit DDR3 256-bit GDDR5
Конфигурация памяти 32 блока по 256M × 16 DDR3
Коннекторы дисплеев Нет Нет
Питание 1x 6-pin PCI Express коннектор 1x 8-pin PCI Express power connector 1

1x 6-pin PCI Express power connector

Общая мощность платы 130 W 225 W
Rank NVIDIA AMD
Best NVIDIA Grid
1. Grid K1
2. Grid K2
AMD FirePro series
1. AMD FirePro S10000
2. AMD FirePro S9000
3. AMD FirePro S7000
Better NVIDIA Quadro
1. Quadro K6000
2. Quadro K5000
AMD FirePro series
1. AMD FirePro V9800P
2. ATI FirePro V9800
Good AMD FirePro series
1. ATI FirePro V8800
2. ATI FirePro V7800
3. AMD FirePro V7800P
4. ATI FirePro V5800

На просторах всемирной сети есть немало руководств по развертыванию RemoteFX на Windows Server. Однако о качественном применении почти ни в одной из этих статей речи не идёт, а в основном статья имеет такой законченный смысл «Поднял, поковырялся, вроде работает, вроде даже шевелится побыстрее, вроде даже нагрузку на центральный процессор снизили. Для чего делал? Черт его знает».

Так вот, я хочу рассказать вам о нашем опыте поиска решения задачи по расширению возможностей виртуальных машин в обработке 3D-графики. Перед нами стояла довольно чётко обрисованная задача. Нам нужно было сделать так, чтобы пользователи удаленных рабочих столов терминального сервера, развернутого на платформе Windows Server 2012 R2, смогли как минимум качественно просматривать различные 3D чертежи и сборки в специализированных viewer-ах, а как максимум и сами могли нет-нет, да и запустить различные CAD программы.

Первоначальной идеей стало развертывание RemoteFX на Windows Server 2012R2. Сказано – сделано. В наличии имелась серверная платформа DELL PowerEdge R720, оснащенный двумя процессорами Intel Xeon CPU E5-2670 v2 @ 2.50GHz поддерживающими SLAT, а также вычислительный графический модуль NVIDIA GRID K2. На сервер была установлена операционная система Windows Server 2012R2 standard с графической оболочкой, была развернута служба Hyper-V и настроен RemoteFX. На самом деле, тогда мы думали, что это окончательное решение и технология RemoteFX нас полностью устроит. Однако, в дальнейшем мы узнали, что Microsoft накладывает на технологию и существенные программные требования, что в качестве гостевой операционной системы, способной использовать трехмерный графический адаптер RemoteFX, могут выступать только операционные системы Windows 7 и 8 и только в редакциях Ultimate и Enterprise. Не совсем справедливо конечно, учитывая то, что сам гипервизор по заявлениям своих разработчиков поддерживает уйму других операционных систем.

Стало понятно, что наша цель использовать графический адаптер в виртуальном терминальном сервере, который развернут на Windows Server 2012R2, останется неосуществимой. Ладно, работаем с тем, что есть. Так что-же у нас есть? Совсем немного. Всего-то возможность установки в качестве гостевой операционной системы Windows 7-8 Ultimate-Enterprise с возможностью подключения к ним только одного пользователя. И даже распрекрасная библиотека RDP Wrapper не в состоянии решить этой проблемы. К тому-же, как нам стало известно по результатам производительности, трехмерный графический адаптер RemoteFX практически не умеет работать с таким API, как OpenGL, который используют большинство CAD программ, а вместо этого поддерживает полностью только проприетарную разработку Microsoft только для Windows – Direct3D. Об этом совсем скромно-скромно заявляют лишь две строчки в описании технологии RemoteFX на сайте Microsoft:

«Support in Windows Server 2012 R2 is provided for DX 11.0, DirectCompute, and C++ AMP. Most of the latest graphics cards will support OpenGL 4.0 and OpenCL 1.1 or later, but these APIs are currently unsupported by RemoteFX in Windows Server 2012 R2.»

Что это, проприетарная разработка для поддержания возможности развертывания терминального сервера на основе виртуальных машин, предложенной в последнем поколении Windows Server? Сложно ответить на этот вопрос. Однако, ясно только одно, технология RemoteFX неприменима для решения поставленной перед нами задачи, особенно ввиду чрезмерно завышенных аппаратных и программных требований к платформе, серверу и гостевым операционным системам. Все эти требования мы, конечно, готовы удовлетворить, но получить в результате готовое решение с крайне сомнительным функционалом – это расточительство.

Именно поэтому поиск не прекратился и, к своему стыду, мы первый раз обратили внимание на то, что пишет сама NVIDIA, о разработанном им графическом вычислительном модуле и его применении. Подробнее можно прочесть здесь, а если коротко, то NVIDIA создала технологию NVIDIA GRID vGPU, благодаря которой графические команды каждой виртуальной машины передаются напрямую в GPU, без трансляции гипервизором. Один физический графический модуль, благодаря драйверу, имеет несколько профилей виртуального GPU c различным количеством ядер и дискретной графической памяти. Вот таблица доступных виртуальных профилей для графических плат NVIDIA GRID:

Графическая плата NVIDIA GRID Профиль виртуального GPU Графическая память Максимальное число дисплеев на пользователя Максимальное разрешение дисплея Максимальное число пользователей на графическую плату
GRID K2 K280Q
K260Q
K240Q
K220Q
4ГБ
2ГБ
1ГБ
512МБ
4
4
2
2
2560×1600
2560×1600
2560×1600
2560×1600
2
4
8
16
GRID K1 K180Q
K160Q
K140Q
K120Q
4ГБ
2ГБ
1ГБ
512МБ
4
2
2
2
2560×1600
2560×1600
2560×1600
2560×1600
4
8
16
32

Всё предельно просто и прекрасно. Драйвер имеет возможность выделять из аппаратной платформы платы виртуальные профили, отличающиеся друг от друга количеством графических ядер и памяти, которые могут стать аналогом физической видеокарты в виртуальной машине. В то время, как технология RemoteFX – всего лишь программная прослойка между виртуальной машиной и реальной графической платой, которая выборочно передает на обработку ту или иную графику. Зачем тогда Microsoft рекомендует к использованию графическую плату, чей функционал в полной мере не поддерживается возможностями их гипервизора? Зачем рекомендовать эту плату к использованию, если гипервизор, написанный ими, не идет по пути развития концепции, предложенной производителями графической платы? Не понятно. Однако, надо отметить, что в описании самой технологии NVIDIA GRID VGPU на сайте NVIDIA, не говорится ни слова (и слава богу) о гипервизоре Microsoft, а вместо этого упоминаются такие разработчики, как VMware c vSphere и Citrix со своим XenServer.

Было решено попробовать в качестве гипервизора XenServer 6.5 от Citrix, чей функционал в редакции Enterprise как раз поддерживает распределение виртуальных графических профилей между виртуальными машинами. Хоть это и не имеет никакого отношения к статье, всё же отмечу, что установка и настройка сервера простая и интуитивно понятная до безобразия. Сервер был установлен и активирован триальной лицензией на 90 дней, которую можно получить, с учетом количества сокетов хоста, за 5 минут, зарегистрировавшись на сайте разработчиков. После активации функция распределения графических профилей становится доступной в XenCenter. К сожалению, для загрузки пока доступны драйвера исключительно для операционных систем Windows, однако радует уже то, что графический профиль имеет возможность устанавливаться не только на версии Windows 7-8 Ultimate-Enterprise, но и на другие операционные системы Microsoft такие как Windows 7-8 других редакций и Windows Server 2008-2012, из коробки поддерживает OpenGL 4.4 и DirectX 11 и OpenCL, а также не имеет ограничений на количество одновременных подключений средствами удаленного рабочего стола к виртуальной машине.

Чтобы оценить качество работы виртуальных графических профилей, в качестве гостевой была установлена операционная система Windows 8.1_x64_Enterprise, в настройках виртуальной машины поочередно добавлялись первые три профиля (K280Q, K260Q, K240Q), которые считаются максимально производительными в порядке убывания, и с каждым графическим профилем было запущено по 4 бенчмарка, тестирующих производительность 3D графики с использованием API OpenGL и Direct3D. Чтобы сравнение не казалось чрезмерно-абстрактным, было принято решение сравнить результаты бенчмарков, запущенных на ВМ, с результатами этих же бенчмарков запущенных на физической машине, имеющей схожие характеристики. Коротко о технических характеристиках виртуальной и физической машины можно узнать из таблицы представленной ниже.

ОС ЦП ОЗУ Видеоадаптер
ФМ Windows 8.1 x64 Enterprise Inter Core(TM) CPU i5-4670 @ 3.40GHz 12ГБ Nvidia GeForce GTX 650
ВМ Windows 8.1 x64 Enterprise Inter Xeon CPU E5-2670 v2 @ 2.50GHz 12ГБ Nvidia GRID VGPU
K280Q ||
K260Q ||
K240Q.

В таблицах с результатами работы бенчмарков я буду указывать только название графического адаптера.

Итак, первым бенчмарком будет SPECviewperf 12.0.2, который многими специалистами почитается как эталонный бенчмарк для тестирования графики различных CAD программ. Кому интересно, подробнее тут. Результаты в таблице ниже. Разрешение окна везде 1900×1060 (по умолчанию в бенчмарке).

Тест GTX 650 K280Q K260Q K240Q
Catia-04 9.06 17.16 31.83 12.14
Creo-01 9.21 17.85 34.41 17.72
Energy-01 0.43 0.72 0.74 0.18
Maya-04 22.45 6.14 13.99 2.85
Medical-01 6.18 15.17 18.76 15.38
Showcase-01 14.99 11.14 32.80 10.84
Snx-02 2.07 18.31 34.80 18.41
SolidWorks-03 20.56 19.02 38.14 20.79

Все результаты выкладываю как есть. Немного смутило меня, что профиль K260Q по идее должен быть «слабее», чем K280Q, однако показал более выдающиеся результаты. Перепроверил, запустив тест еще раз на обоих профилях и пришел к выводу, что показания стабильные (не рандомные) и хоть и отличаются от первоначальных, но в разумных пределах 0.2-0.4.

Следующим бенчмарком, а вернее набором различных бенчмарков для тестирования графики OpenGL стал GpuTest с сайта geeks3d.com, подробнее можно узнать здесь. Результаты в таблице ниже в формате (points/FPS). Все тесты произведены в полноэкранном режиме 1920×1080.

Тест GTX 650 (points/FPS) K280Q (points/FPS) K260Q (points/FPS) K240Q (points/FPS)
FurMark (OpenGL 2.1/3.0) 1214/20 2068/34 1790/29 1619/26
GiMark (OpenGL 3.3) 960/15 1630/27 1578/26 1604/26
PixMark Julia FP32 (OpenGL 2.1/3.0) 6724/111 2231/37 3874/64 3364/56
PixMark Julia FP64 (OpenGL 4.0) 490/8 1046/17 1216/20 1082/18
Plot3D (OpenGL 2.1/3.0) 39817/664 2289/38 2299/38 2296/38
TessMark x16 (OpenGL 4.0) 13458/224 1545/25 1329/22 1542/25
TessMark x64 (OpenGL 4.0) 3039/50 1511/25 1419/23 1535/25
Triangle (OpenGL 2.1/3.0) 145268/2421 3748/62 3871/64 3757/62

Следующим бенчмарком стал RedSDK turbine benchmark от компании REDWAY3D. Подробнее тут. Результаты в таблице ниже. Все тесты произведены в полноэкранном режиме 1920×1080.

Тест GTX 650 K280Q K260Q K240Q
Real-time viewport 1623 1018 368 400
High quality real-time 1800 1576 355 366
Dynamic ambient occlusion 1311 2459 2378 2418
Hybrid ray-tracing 1114 414 413 399
Total score 1437 1131 599 614

Последним бенчмарком стала бесплатная версия Heaven Benchmark 4.0 от разработчиков Unigine. Подробнее тут. Выбор на него пал в том числе потому, что он может протестировать графику Direct3D. Все тесты произведены в окне разрешением 1280×720 по причине того, что бенчмарк не захотел запускаться в полноэкранном режиме на виртуальных машинах по неизвестным мне причинам, выдавая ошибку. Результаты в таблицах ниже.

OpenGL GTX 650 K280Q K260Q K240Q
FPS 44.9 56.8 54.0 56.3
Score 1131 1432 1361 1418
Min FPS 11.2 13.2 8.8 11.8
Max FPS 83.7 66.1 66.0 66.0

Direct3D 11 GTX 650 K280Q K260Q K240Q
FPS 46.9 69.4 34.2 57.4
Score 1183 1747 862 1446
Min FPS 10.7 9.2 6.9 9.9
Max FPS 88.1 137.5 93.8 67.5

Никаких выводов из произведенных мною тестов делать не буду, лучше оставлю это для общественности. Если честно, то результаты тестов мне не до конца понятны и если читающему есть чем качественно прокомментировать их, то буду только рад.

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

Надеюсь, опыт нашего отдела ИТ кому-нибудь пригодится. Благодарю за внимание.

Источник

Читайте также:  Региональные настройки windows server 2012
Adblock
detector