- сокращение затрат на создание полноценных рабочих мест;
- создание более удобного механизма администрирования рабочих мест сотрудниками ИТ отдела и, как следствие, сокращение времени на выполнение тех или иных операций, связанных с технической поддержкой пользователей;
- реализация возможности резервного копирования и быстрого восстановления данных (или рабочих мест целиком).
Самым популярным решением первой и второй озвученных задач является внедрение терминальных серверов на предприятии и замена дорогостоящих рабочих станций тонкими клиентами. Действительно, в условиях постоянной потребности в приобретении аппаратного и программного обеспечения, терминальный сервер и тонкие клиенты способны сократить расходы, связанные с увеличением количества рабочих мест, а также позволить сотрудникам ИТ отдела использовать более удобные и прозрачные механизмы для администрирования и технического обслуживания вышеупомянутых рабочих мест. С реализацией решения третьей задачи отлично справляется виртуализация рабочих мест и серверов. Мощный инструментарий различных современных гипервизоров позволяет сотрудникам ИТ отдела незаметно для пользователей производить резервное копирование и, в случае выхода из строя того или иного рабочего места или сервера, в короткие сроки восстанавливать их до полностью рабочего состояния.
Однако, иногда возможностей удаленного сеанса терминального сервера или операционной системы, развернутых в качестве гостевых, не хватает. Я говорю о случаях, когда пользователю, работающему за тонким клиентом, использующим возможности удаленного рабочего стола, необходимо работать со специфичным набором программ, например, различными 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:
| 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 |
2560x1600 2560x1600 2560x1600 2560x1600 |
2 4 8 16 |
| GRID K1 | K180Q K160Q K140Q K120Q |
4ГБ 2ГБ 1ГБ 512МБ |
4 2 2 2 |
2560x1600 2560x1600 2560x1600 2560x1600 |
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 программ. Кому интересно, подробнее тут. Результаты в таблице ниже. Разрешение окна везде 1900x1060 (по умолчанию в бенчмарке).
| Тест | 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). Все тесты произведены в полноэкранном режиме 1920x1080.
| Тест | 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. Подробнее тут. Результаты в таблице ниже. Все тесты произведены в полноэкранном режиме 1920x1080.
| Тест | 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. Все тесты произведены в окне разрешением 1280x720 по причине того, что бенчмарк не захотел запускаться в полноэкранном режиме на виртуальных машинах по неизвестным мне причинам, выдавая ошибку. Результаты в таблицах ниже.
| 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 программы и иной софт успешно устанавливаются и запускаются на виртуальных машинах. Осталось дать поработать с удаленным рабочим столом специалисту, использующему эти программы и пусть он вынесет окончательный вердикт о возможности использования этого решения. Также хочу подчеркнуть, что писал эту статью вовсе не от безделья, а именно потому что, когда сам искал решение поставленной передо отделом ИТ задачи, не увидел подобных статей, полностью раскрывающих различия разных технологий проброса возможностей графической платы в виртуальную машину, не увидел статей, в которых описано качественное применение данных технологий.
Надеюсь, опыт нашего отдела ИТ кому-нибудь пригодится. Благодарю за внимание.
Комментарии (36)
Superblaze
06.05.2015 21:22Я тоже задумывался как можно (и возможно ли) полноценно виртуализировать графические станции, и разумного экономичного решения видеть не приходилось. Но если говорить о резервном копировании и снапшетах приходят на ум массив на виртуалках на подключенный к полноценной станции по iscsi. Простите за банальность.
zorgrhrd
06.05.2015 22:18А есть данные по vSphere 6.0? Хотелось бы подобной таблички, сравнение с физической рабочей станцией.
p.s.: Недавно тоже задумался о полноценной виртуализации графических станций, хотел провести подобное тестирование RemoteFX, а тут вы, благодарю!
kharlashkin
07.05.2015 09:40Да, VMWare с последними обновлениями и добавлением поддержки vGPU выглядит тоже привлекательно, особенно если уже вся серверная инфраструктура в компании на этом гипервизоре.
Интересно кто-нибудь сталкивался с лицензированием MS для VDI. Можно ли вместо нужного количества копий Windows 7 использовать Windows Server 2008 Datacenter Edition? Помнится мне когда-то проскакивала новость что для DaaS вроде как разрешалось… (могу ошибаться)
omnimod
07.05.2015 13:23Недавно тестировали vGPU на vSphere 6.0 + View 6.1 + NVIDIA GRID K2 с гостевыми ОС Windows 7. Все работает весьма шустро, поддерживается DirectX 11, OpenGL 4.0.
Также заметил, что в некоторых тестах vGPU профили с меньшим объемом видеопамяти (K260Q) могут демонстрировать лучшую производительность. Использование пофилей K280Q вообще не очень целесообразно, т.к. можно отдать ядро видеоадаптер напрямую (режим vDGA), единственный плюс vGPU в этом случае — чуть более простая настройка аппаратного ускорения внутри гостевой ОС.
Бенчмарк SPECviewPerf, по-сути, единственный широко применяемый тест, но его результаты сильно зависят от частоты процессора, поэтому не стоит удивляться ситуации, когда на какой-нибудь средненькой рабочей станции Core i5 с 4-я ядрами, результаты будут заметно лучше, чем на сервере с 16-ядерными Xeon с меньшей частотой.
Что касается Windows Server, то их можно использовать в качестве гостевых ОС в VDI вместо Windows 7, но нужно обращать внимание на то, какие функции VDI не поддерживаются в Windows Server.kharlashkin
07.05.2015 15:28Что касается Windows Server, то их можно использовать в качестве гостевых ОС в VDI вместо Windows 7, но нужно обращать внимание на то, какие функции VDI не поддерживаются в Windows Server.
Так получается что можно использовать возможность иметь неограниченное количество виртуальных ОС для WS2k8 DC для двухпроцессорного сервера, чтобы не покупать лицензии на Win7. А вот и официальная инструкция.
anton1234
07.05.2015 00:12+1Хочу поделиться своим личным опытом по затронутым вопросам.
реализация возможности резервного копирования и быстрого восстановления данных (или рабочих мест целиком).
Это казалось хорошей идеей, до тех пор пока не было реализовано. В 2012r2 hyper-v научился делать экспорт работающих ВМ, однако на действительно работающей вм это будет весьма проблематично. Чекпоинты для этих целей не подходят. МС открытым текстом не рекомендует использовать их в продакшине, по причине падения производительности дисковой системы ВМ. А на форумах еще добавят, что снапшоты имеют свойство ломаться.
В любом случае это крайне не эффективно с точки зрения ресурсов. У вас будет огромный перерасход дисковой подсистемы, и в объеме и в производительности. Лучше продумайте способы хранения данных пользователей. Использование перемещаемых профилей и dfs даст куда больше.
Учитывая стоимость cad систем, тоже очень хотелось запускать их на сервере. В теории красиво, на практике сложно. Я не решал задачу проброса видеоадаптера в вм. Я использовал выделенные серверы. Мои инженеры сидели за огромными мониторами и очень требовательно относились как к качеству картинки, так и к точности управления. RDP протокол категорически их не устроил. И по моему убеждению, проблема доставки изображения с сервера до клиента гораздо сложнее проброса видео в вм.
Jedi-Knight Автор
07.05.2015 16:26В любом случае это крайне не эффективно с точки зрения ресурсов. У вас будет огромный перерасход дисковой подсистемы, и в объеме и в производительности. Лучше продумайте способы хранения данных пользователей. Использование перемещаемых профилей и dfs даст куда больше.
Используйте сторонний софт, например Alike DR, он ужимает данные, которые бэкапит. Перерасход дисковой подсистемы можно потерпеть, а вот упавших UNIX-сервер вряд-ли спасут способы хранения данных пользователей. Ведь, чтобы развернуть какую-нибудь сложную штуку, как например прокси (FreeBSD+apache+mysql+squid_ntlm+sams+havp+rejik+frox) — это, знаете-ли, не 5 минут. Я в статье говорил про возможность резервного копирования не только виртуальных рабочих станций и терминальных серверов (у последних действительно есть инструментарий для того, чтобы хранить папки профилей пользователей на архивном сервере), а также про возможность восстановления из резервных копий различных серверов со сложной конфигурацией, чьё падение причинит очень много неприятностей отделу ИТ.anton1234
07.05.2015 16:54В статье речь про терминальные серверы, причем для весьма специфичных приложений. Поддерживать актуальность данных в резервных копиях на приемлимом уровне делая полную копию обойдходится очень дорого. Если вы успеваете сделать за ночь копии всех вм, сжать, а по хорошему и переместить на другое физическое хранилище, это значит лишь то что у вас слишком много неиспользуемых ресурсов. И даже в этом случае ваши сотрудники теряют день работы.
Перемещаемые профили и распределенное хранение данных на порядок эффективнее по всем параметрам. Для восстановления системы вам всего лишь нужны шаблоны вм с предустановленным ПО. Пользователи даже разницы не заметят если ночью их рабочий сервер сгорит в буквальном смысле.
Про юникс системы не соглашусь еще больше. Копия конфигов + экспорт бд и синхронизация файлов рсинком упрощает процесс. При условии, что вы об этом подумали до того как все упало.
Копирование вм работает только на очень маленьких объемах. Чем сложнее и больще сервер, тем менее пригоден этот метод. Чтобы сделать копию вм активно работающую с бд под линукс вам потребуется изрядная доля везения. Live backup не гарантирует консистентность данных.
Jedi-Knight Автор
07.05.2015 16:42Кстати, сударь. Вы говорите про дисковую подсистему сервера на котором развернут Hyper-V? Просто если о ней, то не понимаю Вашего беспокойства. У нас, к примеру, есть архивный сервер с созданными шарами, а гипервизор Hyper-V посредством скрипта, написанного на PowerShell и обычного планировщика льет экспортируемые машины на удаленную шару. Этот скрипт и способ в целом уже выручал нас.
anton1234
07.05.2015 17:14Я делился своим опытом. Если 5 пользователей имеют данных на 50 гб, а системаспо занимает еще 50. Делая бэкап вм мне нужно
1. Скопировать их на сервере hyper-v
2. Сжать на сервере hyper-v
3. Переместить по сети
Вы вероятно успеваете это делать ночью. И вероятно можете себе позволить грузить систему ночью т.к. сервисы у вас не 24х7. Это не критика, просто описываю разные условия.
У меня не было такой роскоши. При этом у меня был практически риалтайм бэкап пользовательских данных(а не вчерашний), версионная история за пару месяцев(можно восстановить любой в тч удаленный файл по состаянию на любой день с шагом в 12 часов). Восстановление системы = копированию шаблона вм + время на актуализацию шаблонов. Но при типовых конфигурациях оно окупается.
Но это все оффтоп. Мне очень интересно появилось ли решение по рдп. Для меня это было тупиком. xenapp вроде бы все мог, но очень уж много всего за собой тянул.Jedi-Knight Автор
07.05.2015 23:30Я не знаю что за опыт у Вас был, но…
1. Скопировать их на сервере hyper-v
2. Сжать на сервере hyper-v
3. Переместить по сети
Это из ряда того, когда люди не знают как делать бэкапы. Ничего не нужно копировать на локальный сервер, ничего на нем не нужно сжимать, а следовательно и перерасхода дисковой подсистемы или какого-то запредельного запаса не требуется. Даже встроенными воозможностями PowerShell машина сразу экспортируется на удаленную шару. Возможно применение стороннего софта. Я его упоминал выше. Alike DR, бэкапит куда угодно, сразу сжимая и имеет возможность выделять под это дело отдельный сетевой адаптер, дабы не просадить сеть на гипервизоре. На «горячую» машина отлично бэкапится и отлично восстанавливается, проверено даже с UNIX. Копировать БД и настройки, как Вы предлагаете. Ну не знаю. Если Вы умудритесь поднять сервер на вроде того, что я упоминал выше, а потом поднять его из бэкапов конфигов и БД без костылей (особенно учитывая то, что Вам еще сначала нужно поднять то, что будет автоматом бэкапить конфиги и БД), то обязательно поделитесь со мной опытом. Мне даже интересно послушать будет, может это я один не знаю, как так хитро бэкапить BSD, чтобы все потом работало, учитывая что версии пакетов, которые вы можете из портов поставить могут отличаться кардинально, а следовательно и их конфигурационные файлы. Вы будете переподнимать это заново, в лучшем случае опираясь на свои старые конфиги, если сервер проработал 1,5-2 года. Я успеваю делать это ночью, да, тут Вы правы. Однако, я успевал это делать и в рабочее время незаметно для пользователей и, надо отметить, все превосходно возвращается в рабочее состояние. И да, восстановить любую версию данных за два месяца с шагом 12 часов мы не можем, но нам не придется поднимать новую операционку и устанавливать софт, чтобы подсунуть туда пользовательские данные (если мы конечно говорим об одном и том же). Дело в том, что пользователи, в не зависимости от подразделения и вне зависимости от того, работают ли они на виртуальной или физической машине, хранят все важные данные на сетевых дисках серверов, которые постоянно создают архивные копии, почта хранится на почтовых серверах, которые крутятся на BSD в качестве виртуальных и бэкапятся на «горячую», а профили пользователей мы не делаем переносными именно потому, что, в связи со всем вышеизложенным, они не настолько важны, а во-вторых эти профили «крутятся» на терминальниках, которые также успешно бэкапятся на «горячую» и, уж поверьте, отлично работают после восстановления из бэкапов. Это оффтоп, Вы правы. Однако, предлагая решение по бэкапу конфигов и БД с их дальнейшей синхронизацией, Вы предлагаете решение максимум одинаково надежное и уж точно более сложное. ИМХО
Sergey-S-Kovalev
07.05.2015 05:49Отличная статья!
Не знаю наткнулся автор на нюанс или нет, но в статье нет информации о том, что в последнем Windows Server 2012 R2 c Hyper-V при включении RemoteFX нельзя задать количество видеопамяти памяти выделяемой гостевой системе. Как следствие по умолчанию выделяется 20% от памяти видеоадаптера, что может быть недостаточно при использовании «не профессиональных» решений.
В следующей версии сервера данную настройку обещают сделать, но в Server Technical Preview полгода назад такой возможности не было.Jedi-Knight Автор
07.05.2015 16:11Как не наткнулся? Наткнулся конечно. Вообще в Hyper-V есть подобие выбора профиля конфигурации трёхмерного адаптера. Однако, это подобие ограничивается только выбором разрешения и количеством мониторов для удаленного рабочего стола. В следующей обещают и аппаратное OpenGL, но пока это всего лишь обещания.
alexander007
07.05.2015 08:10Не могли бы вы подсказать мне один нюанс относительно RemoteFX. RemoteFX это технология только для виртуализации или она может применяться для ускорения и на обычном терминальном сервере, который стоит поверх реального железа? На сколько я знаю RemoteFX помимо всего прочего включает в себя еще и кодек для передачи изображения в RDP сессии.
Вопрос этот возник по следующей причине. Взяли мы несколько тонких клиентов у отечественного производителя. Настроили терминалку на Win2008R2SP1. В политиках включили RemoteFX. При подключении с тонкого без использования RemoteFX графика начинает подтормаживать у пользователя (при просмотре веб-браузера или pdf документа изображение обновляется сегментами). При включении RemoteFX на тонком клиенте графика идет влет, но появляются проблемы с клавиатурой (в терминальном клиенте win7 при использовании RemoteFX таких проблем нет). Тех. поддержка производителя тонких клиентов сказала что RemoteFX это технология только для виртуализации, но однако разница есть и большая.
gotch
07.05.2015 09:19По поводу притормаживания графики нюанс в том, что RDP отрисовывает клиент, а RemoteFX — сервер. То есть, насколько я понимаю технологию, в RDP к вам на клиент приходят объекты GDI, а в RemoteFX — потоковое видео. Чем слабее клиент, тем заметнее преимущества RemoteFX.
Вероятно в вашем тонком клиенте не «родной» Microsoft RDP/RemoteFX клиент, который и работает «не очень»?
По поводу только технологии виртуализации, это не совсем правда, есть официальное руководство по развертыванию RemoteFX на терминальных серерах:
Deploying Microsoft RemoteFX on a Remote Desktop Session Host Server Step-by-Step Guide
www.microsoft.com/en-us/download/details.aspx?id=6006alexander007
07.05.2015 10:43И еще один вопрос. Имеет ли смысл ставить видео карту в сервер терминальных клиентов (сервер стоит поверх железа, НЕ в виртуалке) для таких приложений как:
— Веб браузер
— MS Office, Libre/OpenOffice
— всякие смотрелки pdf/djvu
— Видео плееры (например VLC)
Планируем использовать OS для сервера не ниже Win2008R2.
Если есть смысл ставить, то как какую? geforce, quadro, firepro?Jedi-Knight Автор
07.05.2015 16:35Не имеет смысла. Проверено. Терминальники и без видео-карт нормально функционируют. Если Вы ограничитесь теми программами, что перечислили, то стандартного адаптера достаточно. Видео по RDP будет конечно не таким, как на физической машине с подключенным к ней монитором, но вполне терпимо.
dklm
07.05.2015 22:22я устанавливал в сервер видеокарту quadro k600, и увидел только ускорения воспроизведения видео.
для офисных задач установка видеокарты не даст заметного результата.
в случаи с quadro k600 при увеличении количества пользователей, производительность быстро падала.
без аппаратной видеокарты, если использовать windows media player и клиента c os win7, декодирование выполняется на стороне клиента и нагрузка на сервер будет минимальной, я так смотрел без проблем 1080p видео.
zorgrhrd
08.05.2015 10:44Более детально вопрос RemoteFX на терминальных раскрыт вот тут blogs.technet.com/b/vm/archive/2010/08/17/remotefx-3-remote-desktop-session-host-rdsh-terminal-services.aspx
RemoteFX на терминальном дает вам лучшее сжатие, а плюшки в виде 3D ускорения работать не будут, оно работает только с Hyper-V.
gotch
07.05.2015 08:50Машина с Nvidia GeForce GTX 650 физическая или виртуальная? Кажется, ВМ и ФМ перепутаны в таблице.
dklm
07.05.2015 23:08-1мне кажется или автор не пробовал использовать GPU pass-through?
но в этом случаи 3D в связке с RemoteFX работать не будет, если я все правильно понимаю, и придется использовать протоколы удаленного доступа от VMware или Citrix.
Как построить VDI для сложной графики
3D ускорение VDI на практике
на презентациях NVIDIA GRID выглядит очень не плохо…Jedi-Knight Автор
08.05.2015 06:32+1Эммм… Я пробовал использовать GPU pass-through, хоть и тестов не проводил. Однако, статья про технологию NVIDIA GRID VGPU, а проброс всей платы, во-первых, не имеет никакого отношения к этой технологии, а во-вторых, носит характер использования сравнимого с сюжетом басни «Мартышка и очки». И если кому-то придет в голову пробрасывать всю плату, которая стоит очень недешево и которая предназначена для совсем иных задач в виду концепции на которую опиралась её разработка, то это человеку нечем заняться. Вы уж извините. И ещё. Может я чего и не понимаю, но причём тут вообще RemoteFX? Протокол удаленного доступа это не RemoteFX, а RDP, который в своей 8 версии поддерживает технологию RemoteFX. Причем в RDP клиенте Windows, даже в самом новом, нет никакого упоминания про RemoteFX, а вместо этого Вы можете галочками разрешить некоторые возможности вроде визуальных эффектов, сглаживания шрифтов, стилей оформления. И в случае использования любого из виртуальных профилей VGPU и даже GPU pass-through, у Вас не будет никакого RemoteFX. Вы видимо как-то по другому поняли эту тему.
dklm
08.05.2015 10:33-1В случаи VMware, vDGA(pass-through) это один из сценариев использования ускорителей ;-).
Плата NVIDIA GRID K1 состоит из 4 чипов, а плата GRID K2 состоит из 2х чипов.
Каждый отдельный чип можно привязать к отдельным VM, и если цель получить максимальную производительность это наиболее интересный вариант.
Думаю что не стоит путать убогие возможности RDP и RemoteFX.
RemoteFX использует кодек отличный от классического RDP, и появился он только с выходом SP1 для ws2008R2.
Поддержку RemoteFX нужно включать как на клиенте так и на сервере.
Всё управление настройками спрятано в групповые политики, настройки скорости обновления кадров и качества картинки очень сильно меняю результат, я так понял вы не устанавливали максимальное качество картинки и частоту смены кадров?Jedi-Knight Автор
08.05.2015 11:27+1Уважаемый, Вам стоит почитать о технологии RemoteFX более подробно. Её действительно не стоит путать с RDP, её вообще не стоит сравнивать с RDP, ведь RemoteFX-это не замена RDP, а технология расширения возможностей протокола удаленных рабочих столов. Ещё раз повторюсь, статья написана о технологии NVIDIA GRID VGPU, пожалуйста услышьте меня. В описании технологии нигде не сказано, что pass-through имеет отношение к возможностям этой технологии. В описании технологии сказано, что она имеет 4 виртуальных профиля (виртуальных!!!). При чём здесь pass-through? Вы как будто говорите со мной о совершенно разных вещах. Просто прочтите, что такое технология NVIDIA GRID VGPU и технология RemoteFX и Вам станет ясно, что они не имеют ничего общего. Ничего, понимаете? Технология RemoteFX — это технология создания эмулированного трехмерного графического адаптера RemoteFX, который выборочно передает физической плате графику на обработку. Технология RemoteFX не работает без трехмерного графического адаптера RemoteFX, который Вы можете увидеть в диспетчере устройств виртуальной машины, если успешно развернете эту технологию на гипервизоре Hyper-V. Тут я рассказываю Вам о технологии создания виртуальной графической платы, а не эмулированной программно. На сайте Microsoft вот здесь прочтите о том, что представляет из себя технология RemoteFX. Я видел Вашу публикацию, где Вы сравниваете RemoteFX с RDP будто это два разных протокола, но нет… Читайте, что пишет разработчик.
Итак, что же скрывается за названием RemoteFX? Два года назад Microsoft купила компанию Calista Technologies, разрабатывающую решения для передачи по сети видео и прочих данных. Доработанная версия RemoteFX позволяет пользователю комфортно работать по протоколу Удалённого рабочего стола (Remote Desktop Protocol, RDP) с видео высокой чёткости и прочей сложной графикой в любых форматах — включая Silverlight, Direct3D 9.0c, трёхмерные модели и, конечно, Windows Aero.
Это не я придумал. Это разработчик так говорит. До тех пор, пока Вы не поймете, что концепция технологии NVIDIA GRID VGPU не имеет ничего общего с GPU pass-through, а также то, что RemoteFX — это не замена протоколу RDP, мы, к моему сожалению, не сможем вести с вами качественную дискуссию на эту тему. До тех пор пока вы не поймете, что нельзя, как Вы выражаетесь, «включить» RemoteFX на сервере без трехмерного графического адаптера RemoteFX, речь о котором идет в начале статьи, вот до этих пор мы с Вами будем говорить о разных вещах.dklm
08.05.2015 19:55думаю можно сказать что услышал 8-)
вопросы по существу:
1 — какое количество пользователей будут работать с 3D?
2 — почему К2 а не более дешевый вариант к1?
3 — сейчас у вас в инфраструктуре только один адаптер grid?Jedi-Knight Автор
08.05.2015 22:21- Количество пользователей, которые будут работать с 3D посредством удаленных рабочих столов ещё не известно.
- K2 нам нравится больше исходя из показателей его производительности, приведенных на сайте производителя.
- Да, у нас пока один адаптер GRID. Мы только начали идти по этому пути, но уже знаем, что путь верный, решение рабочее.
Могу сказать с уверенность, что с каждым новым пользователем мы будем отслеживать сколько ресурсов израсходовано и благодаря отличной масштабируемости, которую обеспечивает внедрение технологии NVIDIA GRID VGPU совместно с общими положениями концепции виртуализации рабочих мест, будем либо добавлять графические адаптеры GRID, либо гипервизоры с такими адаптерами на борту. Возможно потом напишу статью о том, сколько виртуальных рабочих мест было создано благодаря одному вышеупомянутому адаптеру и с какими программами работают пользователи, чтобы читатели оценили возможности самой технологии на нашем примере.
nckma
08.05.2015 11:24Что-то я так ничего и не понял…
Я понял в виртуальной машине пользователя появляется один из физических чипов (или его какая-то часть?) и это ускоряет графику внутри виртуальной машины — правильно?
Ну а к удаленным клиентам то как эта графика попадает? Все тем же RDP? То есть сервер отрендеренную платой картинку считывает из памяти видеоплаты и как-то кодирует в RDP протокол и отправляет по сети? И это быстро работает?Jedi-Knight Автор
08.05.2015 11:30Сейчас объясню. Вы совершенно правы. Технология NVIDIA GRID VGPU никак не претендует на технологию, которая ускоряет отрисовку картинки на удаленных рабочих столах, она не в состоянии разогнать протокол RDP. Речь идет о обработке графики, о работе аппаратного 3D ускорения.
dklm
08.05.2015 20:15GRID VGPU FOR CITRIX XENSERVER
GRID VGPU FOR VMWARE VSPHERE
Quadro & NVS Professional Drivers for Windows
если использовать pass-through:
1 — да, у вас появится физическое устройство внутри VM.
2 — для того чтобы увидеть плоды работы 3д ускорения нужно использовать VMware View или CITRIX Desktop.
3 — hyper-v виртуальные машины не умеют работать с pass-through, NVIDIA пишет только про конкурентов MS.
почему я зациклился pass-through.
в зависимости от задач, pass-through позволит использовать более дешевые адаптере чем GRID k1/k2.
за стоимость одного адаптера к2 можно купить 9 штук quadro к2000.
грустный пример из практики:
— на одном предприятии которые занимаются «черчением» купили кучу графических станций HP.
обслуживающий персонал начал ставить графические станции бухгалтерам и сотрудником которым 3д и не снилось, далее адаптеры quadro из этих ПК исчезали.
— Какой ущерб нанесли я не вникал, но размещение видеокарт в «дата центре» может исключить подобные случаи.Jedi-Knight Автор
08.05.2015 21:22pass-through есть в XenServer 6.5 по-умолчанию, это абсолютно бесплатная опция. Вы можете поставить сервер XenServer 6.5 и активировав его бесплатной лицензией, пробрасывать графические карты в вм абсолютно бесплатно. Но это оффтоп чистой воды. Вы задаете вопрос, почему я не описывал pass-through в статье, а я Вам ещё раз говорю, что статья не про возможности XenServer пробрасывать графические адаптеры в вм, а про технологию NVIDIA GRID VGPU, поэтому я не счел нужным тестировать в статье опцию проброса целиком.
Jedi-Knight Автор
08.05.2015 22:04И еще, Вы пишите:
за стоимость одного адаптера к2 можно купить 9 штук quadro к2000
А вот теперь задумайтесь. У Вас есть гипервизор, допустим на базе недешевого DELL PowerEdge R720, куда Вы будете пихать там 9 физических видеокарт? Речь идет об оптимизации. Вы будете плодить гипервизоры или покупать огромные и дорогущие платформы, пытаясь съэкономить на стоимости GRID? Эту карту для того и придумали, это же ясно как божий день. Эта карта и технология, которую она продвигает сделана для того, чтобы не пихать в сервер 100500 видеокарт, а затем пробрасывать их в вм, а чтобы поставить 1-4 видеокарты, которые посредством драйвера позволят выделять из аппаратной платформы виртуальные профили, которые работают ничем не хуже физических видеокарт, проброшенных в вм. Концепция такая, понимаете? И не преувеличивайте пожалуйста. Только что ознакомился с ценами на яндекс маркете, и 9ти K2000 Вы не купите по цене одной GRID K2, а с учетом того, что Вам придется распихивать эти Ваши 9 видеокарт по, как минимум, пяти серверам (в случае если в наличии Вы будете иметь такую-же серверную платформу, которая имелась у нас), то ничего Вы не съэкономите, а наоборот вгрохаете бюджет очень бездарно. Вы почитайте про опыт компаний, внедряющих NVIDIA GRID в инфраструктуру виртуальных машин. Например, вот тут. Сама технология рассчитана на то, чтобы сделать инфраструктуру виртуализации более компактной и дешевой, чем использование физических машин с графическими адаптерами, чем проброс целиком одного графического адаптера одной виртуальной машине. Вы приводите какие-то очень странные примеры. Ей богу. Железо расходовалось не по назначению, видеокарты пропадали… И что? Вам не кажется, что это не проблема, которую должен решать отдел ИТ? Вам не кажется, что это проблема менеджмента на предприятии и службы безопасности? Почему Вы пытаетесь решить проблему перерасхода средств, перерасходом средств? Если честно, то уже до смеха.dklm
08.05.2015 22:43Jedi-Knight со всем уважением к вашему труду…
когда на местах тырят то что было куплено за мои налоги или мне не повысили зп, лично мне это не нравится, и это не проблема менеджмента это проблема у людей в голове!Jedi-Knight Автор
09.05.2015 13:17Со всем уважением относясь к Вашему чувству гражданской ответственности и Вашему чувству обиды за то, что Вам не поднимают зарплату и тырят то, что куплено на «Ваши» налоги, я не хочу участвовать в этой полемике, ибо она уже давно вышла из рамок темы, которая изначально поднималась мной в статье. И с каждым Вашим комментарием, мы все больше отдаляемся от первоначальной темы.
celebrate
Спасибо за статью! Очень интересно и полезно.