Comments 14
На текущий момент такая возможность есть только у XenServer, но работает это только для однопроцессорных серверов.
У VMware давно заявлена поддержка интеловской интеграшки, только драйверов не найти.
Добрый день!
Скорее всего на сайте коллег речь идёт о поддержке GVT-s, а не GVT-g
выдержка с сайта Интел (https://software.intel.com/en-us/blogs/2014/05/02/intel-graphics-virtualization-update)
Intel GVT-s
Commercially available as Virtual Shared Graphics Adaptor (vDGA, VMWare) and Remote FX (Microsoft), this graphics virtualization approach requires a virtual graphics driver in a virtual machine, use an API forwarding technique to interface with the Intel’s graphics hardware (fig-2). Single GPU hardware can be shared amongst many concurrent users, while the graphics hardware remains abstracted from the applications. Specific sharing algorithms remain proprietary to the virtual graphics driver. Many commercial desktop and workstation remoting products in the market use this approach.
Отличия разных вариантов виртуализации графики Интел рассматриваются тут — https://01.org/sites/default/files/downloads/igvt-g/gvtflyer.pdf
На сайте, где рассматривается GVT-g упоминаются XenServer и KVM https://01.org/igvt-g
Подробно об использовании технологии виртуализации графики Intel в XenDesktop можно прочитать тут — https://01.org/sites/default/files/documentation/intel-citrix-vdesktop-refresh_0.pdf
Сравнение производителей графических чипов с точки зрения виртуализации хорошо рассмотрено тут — http://www.brianmadden.com/opinion/NVIDIA-AMD-and-Intel-How-they-do-their-GPU-virtualization
Скорее всего на сайте коллег речь идёт о поддержке GVT-s, а не GVT-g
выдержка с сайта Интел (https://software.intel.com/en-us/blogs/2014/05/02/intel-graphics-virtualization-update)
Intel GVT-s
Commercially available as Virtual Shared Graphics Adaptor (vDGA, VMWare) and Remote FX (Microsoft), this graphics virtualization approach requires a virtual graphics driver in a virtual machine, use an API forwarding technique to interface with the Intel’s graphics hardware (fig-2). Single GPU hardware can be shared amongst many concurrent users, while the graphics hardware remains abstracted from the applications. Specific sharing algorithms remain proprietary to the virtual graphics driver. Many commercial desktop and workstation remoting products in the market use this approach.
Отличия разных вариантов виртуализации графики Интел рассматриваются тут — https://01.org/sites/default/files/downloads/igvt-g/gvtflyer.pdf
На сайте, где рассматривается GVT-g упоминаются XenServer и KVM https://01.org/igvt-g
Подробно об использовании технологии виртуализации графики Intel в XenDesktop можно прочитать тут — https://01.org/sites/default/files/documentation/intel-citrix-vdesktop-refresh_0.pdf
Сравнение производителей графических чипов с точки зрения виртуализации хорошо рассмотрено тут — http://www.brianmadden.com/opinion/NVIDIA-AMD-and-Intel-How-they-do-their-GPU-virtualization
Хорошо бы ещё увидеть статью по выстраиванию различных вариантов инфраструктуры. В прочем мой вопрос может быть задан любому производителю решений виртуализации, но каждый на него ответит — вот 1 или несколько физических серверов, ставь, объединяй в пул, подключай дисковую полку, размещай там образы и вперёд…
Но по факту тут заранее не понятно, какие скорости от дисковой подсистемы будут требоваться, какая полоса должна быть выделена в сети и т.д.
Вот у меня например есть сервер. Допустим RAM и CPU хватает на мои потребности. В нём стоит аппаратный raid контроллер и на нём я сделал 2 массива — один под нужды XenServer, второй под размещение VM. Этот второй массив — RAID10, на не помню каких сигейтах серверной серии, 7200 об, 128.
И есть второй, допустим точно такой же сервер. Хочу что бы VM мигрировали туда сюда, в случае необходимости — по запросу или в аварийной ситуации.
Из того, что попадалось в качестве решения — собрать Ceph клайстер на двух хранилищах для VM. Но под это потребуется либо волокно утилизировать (они у меня на разных географических локациях), либо выделить некую полосу в магистральном канале. Здесь интересно — какую? И может есть что то ещё попроще, более штатное к самому XenServer что ли..?
Но по факту тут заранее не понятно, какие скорости от дисковой подсистемы будут требоваться, какая полоса должна быть выделена в сети и т.д.
Вот у меня например есть сервер. Допустим RAM и CPU хватает на мои потребности. В нём стоит аппаратный raid контроллер и на нём я сделал 2 массива — один под нужды XenServer, второй под размещение VM. Этот второй массив — RAID10, на не помню каких сигейтах серверной серии, 7200 об, 128.
И есть второй, допустим точно такой же сервер. Хочу что бы VM мигрировали туда сюда, в случае необходимости — по запросу или в аварийной ситуации.
Из того, что попадалось в качестве решения — собрать Ceph клайстер на двух хранилищах для VM. Но под это потребуется либо волокно утилизировать (они у меня на разных географических локациях), либо выделить некую полосу в магистральном канале. Здесь интересно — какую? И может есть что то ещё попроще, более штатное к самому XenServer что ли..?
Правильно заданный вопрос содержит в себе часть ответа :)
Для того, чтобы сказать, какая скорость дисковой подсистемы понадобится нужно знать что за рабочую нагрузку вы «крутите» внутри виртуальных машин. В одном случае необходимые вычисления могут полагаться только на оперативную память и тактовую частоту процессора, а в другом случае активно работать с дисковой подсистемой. Естественно ответ будет в каждом случае разный. С сетью такая же ситуация + нужно понимать какой аспект интересует: сколько кбит/сек нужно для работы пользователя с той или иной виртуальной машиной (тогда это вообще вопрос не к гипервизору, а к терминальной системе или системе виртуализации десктопов) или интересует полоса пропускания, необходимая для например перемещения виртуальной машины с одного хоста на другой (XenMotion или Storage XenMotion) в случае нахождения хостов на разных площадках. Тут опять нет однозначного ответа — всё сильно зависит от размера виртуальной машины и объёма виртуальной оперативной памяти.
У вас есть один сервер с XenServer, с работающими виртуальными машинами. Если вы хотите, чтобы в случае аварии машины автоматически перезапустились на другом хосте или при необходимости можно было бы переместить машины не прерывая предоставления сервиса, то для начала нужно добавить в пул второй сервер. HA, XenMotion, Storage XenMotion доступны даже в бесплатной редакции.
Для того, чтобы сказать, какая скорость дисковой подсистемы понадобится нужно знать что за рабочую нагрузку вы «крутите» внутри виртуальных машин. В одном случае необходимые вычисления могут полагаться только на оперативную память и тактовую частоту процессора, а в другом случае активно работать с дисковой подсистемой. Естественно ответ будет в каждом случае разный. С сетью такая же ситуация + нужно понимать какой аспект интересует: сколько кбит/сек нужно для работы пользователя с той или иной виртуальной машиной (тогда это вообще вопрос не к гипервизору, а к терминальной системе или системе виртуализации десктопов) или интересует полоса пропускания, необходимая для например перемещения виртуальной машины с одного хоста на другой (XenMotion или Storage XenMotion) в случае нахождения хостов на разных площадках. Тут опять нет однозначного ответа — всё сильно зависит от размера виртуальной машины и объёма виртуальной оперативной памяти.
У вас есть один сервер с XenServer, с работающими виртуальными машинами. Если вы хотите, чтобы в случае аварии машины автоматически перезапустились на другом хосте или при необходимости можно было бы переместить машины не прерывая предоставления сервиса, то для начала нужно добавить в пул второй сервер. HA, XenMotion, Storage XenMotion доступны даже в бесплатной редакции.
да, вопрос слишком широкий и (1) поэтому статья бы с какими нибудь хорошими практиками для различных задач была бы кстати… а (2) я наверное не смогу правильно задать вопрос, так как совсем не варюсь в теме. У меня есть желание и я его просто изложил)
Вот вы что то рассказали, вроде бы очевидное, но мне есть от чего отталкиваться в дальнейшем разговоре.
Допустим задачи такие:
— 2 терминальных сервера для работы 1С и софта для управления оборудованием. На них нагрузка практически никакая, т.к. вся бухгалтерия редко работает одновременно, а софт никаких данных не собирает, а только отправляет команды и принимает ответы от оборудования через интерфейсы.
— 1 Win сервер с MSSQL базой, размер 10Гб. Работает с ней одно приложение с одним пользователем — биллинг, когда считает — никто нагрузки не замечает, кроме поедания всей оперативы (12Гб).
— почта, днс, Сотрудников меньше 20, почты не много.
Сейчас всё это крутится на xen 4 развёрнутом моими кривыми руками и образами lvm патриций на аппаратном raid10. В общем проблем с производительностью нет. Но хотим получить инструменты XenServer… попутно купили второй сервак с целью получения (в идеале) горячего резерва, размещённого на разной географии. Возможно мы обойдёмся без горячего резерва (подразумеваю, что пользователи при таком резерве даже не заметят, если один из серверов виртуализации отвалится), но с быстрым запуском этой VM на другом сервере без потери оперативной информации (бэкапы делаем, но не каждые 5 минут конечно)
Надеюсь я смог приблизить себя к хорошему ответу на свои вопросу ))
Вот вы что то рассказали, вроде бы очевидное, но мне есть от чего отталкиваться в дальнейшем разговоре.
Допустим задачи такие:
— 2 терминальных сервера для работы 1С и софта для управления оборудованием. На них нагрузка практически никакая, т.к. вся бухгалтерия редко работает одновременно, а софт никаких данных не собирает, а только отправляет команды и принимает ответы от оборудования через интерфейсы.
— 1 Win сервер с MSSQL базой, размер 10Гб. Работает с ней одно приложение с одним пользователем — биллинг, когда считает — никто нагрузки не замечает, кроме поедания всей оперативы (12Гб).
— почта, днс, Сотрудников меньше 20, почты не много.
Сейчас всё это крутится на xen 4 развёрнутом моими кривыми руками и образами lvm патриций на аппаратном raid10. В общем проблем с производительностью нет. Но хотим получить инструменты XenServer… попутно купили второй сервак с целью получения (в идеале) горячего резерва, размещённого на разной географии. Возможно мы обойдёмся без горячего резерва (подразумеваю, что пользователи при таком резерве даже не заметят, если один из серверов виртуализации отвалится), но с быстрым запуском этой VM на другом сервере без потери оперативной информации (бэкапы делаем, но не каждые 5 минут конечно)
Надеюсь я смог приблизить себя к хорошему ответу на свои вопросу ))
По трафику — один из наших заказчиков недавно проводил тестирование (самостоятельно, без участия вендора, с использованием автоматизированных средств тестирования) работы терминальных приложений (без мультимедийных возможностей). В результате усреднённая нагрузка на канал составила около 30 кбит/сек (это с печатью и прикреплением документов с локальной рабочей станции). На случай, если печать и прикрепление файлов будет идти с большинства рабочих станций одновременно была выдана рекомендация на предоставление 1 пользователю 64 кбит/сек.
Теперь про XenServer 4 — давно надо обновлять. Версия XenServer 7.1 также доступна в виде бесплатной редакции. Единственное отличие от XenServer Standard Edition — на бесплатную редакцию нельзя купить техническую поддержку. Так что спокойно добавляйте в пул второй сервер и машины можно будет сразу перемещать между хостами (при условии что у вас процессоры одинаковые или могут быть маскированы гипервизором). High Availability тоже работает в бесплатной редакции и если вы его настроите, то машина в случае падения узла 1 автоматически перезапустится на узле 2, но (!) данные с которыми она работала — потеряются.
Теперь про XenServer 4 — давно надо обновлять. Версия XenServer 7.1 также доступна в виде бесплатной редакции. Единственное отличие от XenServer Standard Edition — на бесплатную редакцию нельзя купить техническую поддержку. Так что спокойно добавляйте в пул второй сервер и машины можно будет сразу перемещать между хостами (при условии что у вас процессоры одинаковые или могут быть маскированы гипервизором). High Availability тоже работает в бесплатной редакции и если вы его настроите, то машина в случае падения узла 1 автоматически перезапустится на узле 2, но (!) данные с которыми она работала — потеряются.
Нагрузка на сеть никакая, поэтому даже внимание не стал этому уделять. Про сеть я беспокоился по вопросу, если разворачивать хранилище Ceph и там будут дублироваться запись на оба сервера. И я знаю, что 1Гб/с не хватит, что бы это хорошо работало.
А Xen 4 — это прям Xen hypervisor, не XenServer от Citrix…
А потеряются данные, это на уровне того, что было не сохранено, или…? Данные то в принципе там будут синхронизироваться между серверами? Или будет лишь быстрый перезапуск образа VM, в котором можно будет продолжать пользовать софтом, а данные (типа 1С баз, документов) нужно будет хранить на отдельном ресурсе, вроде бы NAS и прочих шар?
А Xen 4 — это прям Xen hypervisor, не XenServer от Citrix…
High Availability тоже работает в бесплатной редакции и если вы его настроите, то машина в случае падения узла 1 автоматически перезапустится на узле 2, но (!) данные с которыми она работала — потеряются.
А потеряются данные, это на уровне того, что было не сохранено, или…? Данные то в принципе там будут синхронизироваться между серверами? Или будет лишь быстрый перезапуск образа VM, в котором можно будет продолжать пользовать софтом, а данные (типа 1С баз, документов) нужно будет хранить на отдельном ресурсе, вроде бы NAS и прочих шар?
HA = High Availability = Высокая Доступность и это подразумевает, что вы возможно потеряете то, что в данный момент находилось в оперативной памяти, https://en.wikipedia.org/wiki/High_availability
Виртуальная машина и её данные в случае HA должны располагаться на общей для пула серверов системе хранения данных и тогда, в случае падения ВМ, которая работала на сервере 1, она перезапускается на сервере 2 с общей СХД и оттуда же берёт данные, необходимые ей для работы. Этот подход отличается от Fault Tolerance, кластеризации серверных приложений и других методов обеспечения непрерывности и отказоустойчивости. Так что это «быстрый перезапуск», а данные лучше располагать за пределами ВМ, на отдельном ресурсе. Ну и общая практика такова — чем больше «девяток» вы хотите получить для своей системы, тем более дорогой она оказывается.
Виртуальная машина и её данные в случае HA должны располагаться на общей для пула серверов системе хранения данных и тогда, в случае падения ВМ, которая работала на сервере 1, она перезапускается на сервере 2 с общей СХД и оттуда же берёт данные, необходимые ей для работы. Этот подход отличается от Fault Tolerance, кластеризации серверных приложений и других методов обеспечения непрерывности и отказоустойчивости. Так что это «быстрый перезапуск», а данные лучше располагать за пределами ВМ, на отдельном ресурсе. Ну и общая практика такова — чем больше «девяток» вы хотите получить для своей системы, тем более дорогой она оказывается.
Хмммм — мне кажется, что купить или собрать простой NAS будет проще и дешевле и надёжнее. Но это моё личное мнение.
чем _простой_ nas будет надёжнее raid10 на аппаратном контроллере Intel в шасси Intel?
NAS'ы как бы есть, qnap, мы с iscsi интерфейсы тянем, для бэкапов/хранения справочных баз и пр… ну шара там всякая, понятное дело…
В общем получается, что если реализовывать всё внутри сами серверов, то без drdb или ceph пока не обойтись… а им нужен хороший канал. Стояло бы всё в пределах одного узла — проблемы бы и не было между ними оптику кинуть, да и пусть оно там себе варится по 10Гб аплинку друг в друга. Но нам нужно выделять для этого волокно между локациями… отсюда и все поиски.
PS: вот и я промазал с ответом и запостил в новую ветку… =(
NAS'ы как бы есть, qnap, мы с iscsi интерфейсы тянем, для бэкапов/хранения справочных баз и пр… ну шара там всякая, понятное дело…
В общем получается, что если реализовывать всё внутри сами серверов, то без drdb или ceph пока не обойтись… а им нужен хороший канал. Стояло бы всё в пределах одного узла — проблемы бы и не было между ними оптику кинуть, да и пусть оно там себе варится по 10Гб аплинку друг в друга. Но нам нужно выделять для этого волокно между локациями… отсюда и все поиски.
PS: вот и я промазал с ответом и запостил в новую ветку… =(
Не знаю, зачем я повёлся. Работал пул на два сервера(XS1 и XS2) под XenServer 6.5 с хранилищем на NAS и бэкап-скриптом от Andy Burton — и горя не знал. Дёрнул-ведь чёрт обновиться…
1. Выключил HA.
2. Вывел из пула сервер XS1(мастером работает XS2):
— Обновил винты, установил чистый Citrix XenServer 7.2
— Накатил все апдейты
3. ПРОБЛЕМА 1 — в пуле не живут вместе сервера 6.5 и 7.2; пул обратно не собрать.
— в нерабочее время обновляю на работающем сервере(XS2) 6.5 => 7.2
— как следствие теперь оба сервака на 7.2 и дружно сидят в пуле.
4. Перетащил все виртуалки на сервер XS1 и сделал его мастером пула, чтобы второй сервак так же обновить по железу и поставить с нуля Citrix XenServer 7.2
5. ПРОБЛЕМА 2 — вытащить из пула сервак XS2 не получается. "The SR.shared flag cannot be set to false while the SR remains connected to multiple hosts". Да и фиг-то с ним, думаю. Всё равно все виртуалки на NAS хранятся — не буду винты обновлять. Накачу-ка я апдейты…
6. ПРОБЛЕМА 3 — "XS2: The update precheck stage failed: RPM package validation requires a GPG key that is not present on the host". WTF, Citrix?
7. ОК, дружище. Кажется интуиция правильно говорит, что XenServer 7.2(updated from 6.5) не очень хорошая идея в продакшене и чистая установка необходима. Выключаю капризный сервер XS2.
8. Повторяю всё, что сделал ранее с XS1:
— Обновил винты, установил чистый Citrix XenServer 7.2
— Дурак, не накатив апдейты ввёл XS2 в пул и поимел опять:
-.- Ошибку установки апдейтов "XS2: The update precheck stage failed: RPM package validation requires a GPG key that is not present on the host"
-.- Невозможность вывести сервер XS2 из пула "The SR.shared flag cannot be set to false while the SR remains connected to multiple hosts"
Где ж я так нагрешил-то. © Быков
Работает — не трожь.
Стремясь к лучшему, мы часто портим хорошее. © Шекспир
Да, есть решение для "ПРОБЛЕМА 2" /opt/xensource/packages/iso SR pbd was blocking the host from being ejected. И что ведь удивительно, сервер XS2 вне пула прекрасно принял все апдейты, избавив от "ПРОБЛЕМА 3".
WTF, Citrix? Это Live-patching?
p.s. По ПРОБЛЕМА 3 можно почитать если вы пользуете pvsaccelerator или OpenManage / Zabbix agent. Оба случая не мои.
1. Выключил HA.
2. Вывел из пула сервер XS1(мастером работает XS2):
— Обновил винты, установил чистый Citrix XenServer 7.2
— Накатил все апдейты
3. ПРОБЛЕМА 1 — в пуле не живут вместе сервера 6.5 и 7.2; пул обратно не собрать.
— в нерабочее время обновляю на работающем сервере(XS2) 6.5 => 7.2
— как следствие теперь оба сервака на 7.2 и дружно сидят в пуле.
4. Перетащил все виртуалки на сервер XS1 и сделал его мастером пула, чтобы второй сервак так же обновить по железу и поставить с нуля Citrix XenServer 7.2
5. ПРОБЛЕМА 2 — вытащить из пула сервак XS2 не получается. "The SR.shared flag cannot be set to false while the SR remains connected to multiple hosts". Да и фиг-то с ним, думаю. Всё равно все виртуалки на NAS хранятся — не буду винты обновлять. Накачу-ка я апдейты…
6. ПРОБЛЕМА 3 — "XS2: The update precheck stage failed: RPM package validation requires a GPG key that is not present on the host". WTF, Citrix?
7. ОК, дружище. Кажется интуиция правильно говорит, что XenServer 7.2(updated from 6.5) не очень хорошая идея в продакшене и чистая установка необходима. Выключаю капризный сервер XS2.
8. Повторяю всё, что сделал ранее с XS1:
— Обновил винты, установил чистый Citrix XenServer 7.2
— Дурак, не накатив апдейты ввёл XS2 в пул и поимел опять:
-.- Ошибку установки апдейтов "XS2: The update precheck stage failed: RPM package validation requires a GPG key that is not present on the host"
-.- Невозможность вывести сервер XS2 из пула "The SR.shared flag cannot be set to false while the SR remains connected to multiple hosts"
Где ж я так нагрешил-то. © Быков
Работает — не трожь.
Стремясь к лучшему, мы часто портим хорошее. © Шекспир
Да, есть решение для "ПРОБЛЕМА 2" /opt/xensource/packages/iso SR pbd was blocking the host from being ejected. И что ведь удивительно, сервер XS2 вне пула прекрасно принял все апдейты, избавив от "ПРОБЛЕМА 3".
WTF, Citrix? Это Live-patching?
p.s. По ПРОБЛЕМА 3 можно почитать если вы пользуете pvsaccelerator или OpenManage / Zabbix agent. Оба случая не мои.
Кстати, апдейты с XS72E001 по XS72E009 до сих пор требуют перезагрузки сервера после каждого апдейта.
Алексей, а как-то странно получается — вы пытаетесь смешать 2 варианта — upgrade и установка с нуля. Кто мешал пойти описанным в руководстве путём — обновление в рамках пула одного сервера, а затем второго.
Функционал Live Patching требует платной Enterprise редакции.
Так что я бы определил самой главной ПРОБЛЕМУ 0 — не желание ознакомится с документацией по продукту, а вместо этого принятие решений по изменению конфигурации рабочей среды по принципу "на авось", этакий agile-style — ввяжемся в драку, а там посмотрим, что к чему.
Sign up to leave a comment.
Краткий обзор нововведений гипервизора Citrix XenServer 7.1