24 июня 2010

RHEV 2.2 c поддержкой VDI

Анонсирован выход RHEV 2.2, включающего в себя помимо серверной виртуализации, реализацию VDI на основе протокола SPICE. В качестве виртуальных рабочих мест и клиентов VDI поддерживаются как Linux, так и Windows. Согласно документам имеется перенаправление USB-устройств в виртуальные машины. В последней бета-версии которую я смотрел использовалась версия протокола 0.3, где этой поддержки не было. Будем качать — тестировать...

Из связанных с RHEV новостей, можно также отметить:
  • Выход первого «чернового» релиза RESTful интерфейса к Red Hat Virtualization Enterprise Manager. До этого был единственный вариант написания скриптов использованием PowerShell API.
  • Совместный с Cisco анонс интегрированного решения Cisco Unified Computing System и RHEV, позволяющего получать виртуальным машинам прямой доступ к устройствам ввода/вывода и повысить защиту виртуальной инфраструктуры за счет технологии Cisco Virtual Network Link.
Внешний вид пользовательского портала RHEV-D:

25 комментариев:

alien комментирует...

а где его взять скачать-посмотреть?

Andrey Markelov комментирует...

Можно обратиться к компании-партнеру. Можно также обратиться напрямую в Red Hat. Форма - https://inquiries.redhat.com/go/redhat/rhev-contact-sales

zaytsevstanislav комментирует...
Этот комментарий был удален автором.
tullamoredew комментирует...

не 2003-ий а 2008-ой, для новой версии

а перенос кода освещается на lpeer.blogspot.com

Andrey Markelov комментирует...

Точной даты нет. Но серверная лицензия (2.2 требует 2008 R2) - это не много. А вот чтобы отказаться от Windows CAL помимо портирования кода на Java нужно вытащить зависимости от AD и MS SQL.

tullamoredew комментирует...

с чего вы взяли что существует зависимость от AD? AD это просто тот DS который поддерживается, но менеджер работает и вообще без AD, пользуясь локальными юзерами виндоуса на котором развернут менеджмент

Andrey Markelov комментирует...

Конечно, я знаю что RHEV-M может работать с локальными пользователями.
Но. Как вы без централизованной аутентификации, а поддерживается в настоящий момент тока AD:
- Организуете SSO для виртуальных машин Win?
- В случае использования физической машины организуете высокую доступность для RHEV-M? У вас появится единая точка отказа.

В конфигурации с локальной аутентификацией можно развернуть тестовую зону, но в продакшен?
Кстати для работы в кластере единственной поддерживаемой в настоящей СУБД также требуется AD.

Я не тестировал весь функционал RHEV-M в установке с локальными пользователями, но прежде чем рекомендовать такую конфигурацию посоветовался бы с саппортом и узнал бы какой функционал поддерживается без AD... сейчас я вижу в Installation Guide сплошные ссылки на AD, и вижу "хвосты" AD в интерфейсе....

Но в целом это даже и не важно. Пока есть СУБД работающая только на платформе MS, на отказе от AD вы не сэкономите. За Windows CAL вы платите те-же самые деньги (в случае если не использовать SSO), а в случае SSO - еще и бОльшие.

С радостью бы услышал что я ошибаюсь, тогда бы не пришлось что-то выдумывать и скрещивать "ужа с ежом", хотя конечно варианты имеются :) Тем более я был бы рад чтобы их опроверг человек как я понимаю непосредственно работающий в RH над этим продуктом :)

tullamoredew комментирует...

>- Организуете SSO для виртуальных
>машин Win?
так это же классический случай для AD, а это как раз работает :)

кстати, еще со времен SI есть клиент пользующийся VDI с netware client. тоже работает

>- В случае использования
>физической машины организуете
>высокую доступность для RHEV-M?
AD требуется только если использовать MSCS. А есть еще много вариантов, от RHCS до всяческих doubletake/wansyncHA/neverfail/etc.

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

>В конфигурации с локальной
>аутентификацией можно развернуть
>тестовую зону, но в продакшен?

а если весь парк виртуалок линуксовый, и аутентификация в менеджменте нужна только для входа в GUI? это только пример конечно, есть еще множество вариантов

tullamoredew комментирует...

>Кстати для работы в кластере
>единственной поддерживаемой в
>настоящей СУБД также требуется AD.
смотря в каком кластере

>Я не тестировал весь функционал
>RHEV-M в установке с локальными
>пользователями, но прежде чем
>рекомендовать такую конфигурацию
>посоветовался бы с саппортом и
>узнал бы какой функционал
>поддерживается без AD...
проще рассказать саппорту что вы собираетесь делать с системой, вполне возможно что AD не нужен. кроме того, его можно за несколько кликов развернуть прямо на машине с RHEV-M, если своего AD (как во многих линукс-шопах или у хостеров например) нет.

>сейчас я вижу в Installation Guide
>сплошные ссылки на AD, и вижу
>"хвосты" AD в интерфейсе....
как я уже писал выше - многое из функционала завязанного на AD в определенных видах юз-кейсов не используют вообще

tullamoredew комментирует...

>Но в целом это даже и не важно.
>Пока есть СУБД работающая только
>на платформе MS, на отказе от AD
>вы не сэкономите. За Windows CAL
>вы платите те-же самые деньги (в
>случае если не использовать SSO),
>а в случае SSO - еще и бОльшие.
СУБД там бесплатный, денег оно не стоит. Можно подключиться к центральному, платному SQL но в принципе это не обязательно, разве что если использовать MSCS (а в таком случае лайсенсы уже давно не вопрос). Так что реально RHEV требует один вин2008р2 стандарт и все, а скоро и этого не будет

>С радостью бы услышал что я
>ошибаюсь, тогда бы не пришлось
>что-то выдумывать и скрещивать
>"ужа с ежом",
опишите чего конкретно дибиваетесь при помощи системы, и вполне возможно что все легко и просто без лишних затрат

> Тем более я был бы рад чтобы их
>опроверг человек как я понимаю
>непосредственно работающий в RH
>над этим продуктом :)
ну, я здесь не от имени RH, а как частный блоггер. в IRC FreeNode есть канал #rhev, там много знающего народа бывает, если есть вопросы - велкам

Andrey Markelov комментирует...

Лично я не считаю зависимость от AD и SQL шоу стоппером в подавляющем числе случаев (CAL у заказчиков как правило есть). В редких случаях если мы хотим от этого уйти "проблемные" места идут в следующем порядке:
1) брокер и MSSQL (даже в той бесплатной редакции). Если вам нужно организовать доступ к 1000 рабочих столов RHEL вы все-равно должны купить 1000 CAL. С брокером вопрос очевиден. С MSSQL не так очевиден, но этот случай в руководстве по лицензированию Microsoft описан как проксирование, и все-равно нужно плать CAL (не SQL конечно, а на Win Server)
2) AD. Конечно, если не нужен SSO все понятно. А если нужен? Хотелось бы иметь возможность предложить SSO на Win-клиентах например для eDirectory. И чтобы этот вариант был официально поддерживаемый. Или Red Hat IPA (когда будет v2)

Но это достаточно редкие случаи. Конкуренты так-же в настоящий момент зависят от AD и платформы Win.

Кстати, я не понял фразы про то, что если "умрет" менеджер, то потеряется лишь небольшая часть функционала. А брокер/пользовательский портал? Это как-раз основная часть функционала VDI. Новые пользователи не смогут зайти на портал.

И еще возможно вам известен ответ на вопрос когда появятся тонкие клиенты? В документации упоминания про них есть. Я конечно, понимаю что собрать специализированный дистрибутив и разлить его на аппаратную платформу — не проблема. Понятно что это будет стоить и при каком числе тонких клиентов стоит этим заниматься. Однако, значительно проще было бы перенести эту «головную боль», особенно поддержку, на Wyse или HP.

tullamoredew комментирует...

>В документации упоминания про них
>есть. Я конечно, понимаю что
>собрать специализированный
>дистрибутив и разлить его на
>аппаратную платформу — не
>проблема. Понятно что это будет
>стоить и при каком числе тонких
>клиентов стоит этим заниматься.
есть наработки и под линукс, которые хорошо работают, но это дело партнеров

>Однако, значительно проще было бы
>перенести эту «головную боль»,
>особенно поддержку, на Wyse или
>HP.
все находится именно у партнеров :)

tullamoredew комментирует...

>Кстати, я не понял фразы про то,
>что если "умрет" менеджер, то
>потеряется лишь небольшая часть
>функционала. А брокер/
>пользовательский портал?
да, портал уйдет, но те кто уже работает этого не заметят, а для остальных есть воркэраунды. ну и кроме того НА решения тоже имеются

>Это как-раз основная часть
>функционала VDI. Новые
>пользователи не смогут зайти на
>портал.
штатно - не смогут, те кому важно - админ сможет пустить внештатно

>И еще возможно вам известен ответ
>на вопрос когда появятся тонкие
>клиенты?
они уже есть. пока не списка официально поддерживаемых, но в принципе, любой тонкий клиент с winXP/winCE и выше может работать. у меня на столе их несколько, те у кого CPU и памяти побольше вполне гоняют спайс со всеми наворотами - видео, фотошопы, автокад... более слабые легко тянут стандартные оффисные приложения, да и RDP никто не отменял

tullamoredew комментирует...

>2) AD. Конечно, если не нужен SSO
>все понятно. А если нужен?
если нужен для виндовых десктопов - да, AD нужен. хотя были успешные деплойменты с RHDS плюс несколько костылей, но это все экспериментально. опять же, AD можно развернуть как на менеджера, так и на куче серверов, включая виртуалки под RHEV, так что отказ менеджера по DS не ударит

>Хотелось бы иметь возможность
>предложить SSO на Win-клиентах
>например для eDirectory.
будет :) как клиент и бетатестер, вы можете обратиться в саппорт, с просьбой открыть фичер-риквест, все эти запросы учитываются при планировании функционала новых версий

>И чтобы этот вариант был
>официально поддерживаемый. Или Red
>Hat IPA (когда будет v2)
когда фича выйдет, поддержка будет. пока что DS integration однован на оригинальных разработках от SI, но работа идет вовсю

>Но это достаточно редкие случаи.
для виндовых станций - 100%

tullamoredew комментирует...

>... Если вам
>нужно организовать доступ к 1000
>рабочих столов RHEL вы все-равно
>должны купить 1000 CAL.
CAL винды? зачем? если все гесты с линуксом, то лицензии на винду ни к чему.

>С брокером вопрос очевиден.
да, если он не работает, то доступ к виртуалкам не так тривиален, но все еще возможен в крайнем случае. клиенты уже работающие в десктопе, не заметят потерю.


>С MSSQL не так очевиден, но этот
>случай в руководстве по
>лицензированию Microsoft описан
>как проксирование, и все-равно
>нужно плать CAL (не SQL конечно, а
>на Win Server)
один, который как мы уже установили, пока что неизбежен.

Andrey Markelov комментирует...

> CAL винды? зачем? если все гесты с линуксом, то лицензии на винду ни к чему.

Я же уже писал почему нужны. Для любого сервиса работающего на Win нужны Server CAL для всех обращающихся к нему клиентов. Это относиться к брокеру и к бесплатному MS SQL. Подробнее - в соответствующих документах от Microsoft.

> будет :) как клиент и бетатестер, вы можете обратиться в саппорт

Обращаемся конечно, как компания-партнер. Но тут я выступаю просто как блогер.

>>Но это достаточно редкие случаи.

>для виндовых станций - 100%

Если для виндовых станций - это 100%, то теряется смысл в уходе от работы RHEV-M на плаформе Win. От CAL заказчик не откажится, а экономия на лицензии сервера... Стоимость Win серверов исчезающе мала на фоне CAL. Конечно, я говорю о внедрениях не десятков, а сотен и тысяч рабочих мест.

> но в принципе, любой тонкий клиент с winXP/winCE и выше может работать.

Это понятно, но пока готового решения нет.

> есть наработки и под линукс, которые хорошо работают, но это дело партнеров

Угу. Наше. Только это увеличивает порог "входа". Нужны сотни клиентских мест у заказчика для того чтобы этим стоило заниматься.


В принципе, как я говорил, все эти моменты не являются шоу стопперами. Потенциал решения - на лицо. Плюсы и минусы понятны. Рынку это интересно. Выход еще одной компании на рынок VDI - это здорово, т.к. увеличивает конкуренцию и в итоге идет на пользу заказчику. Я это только могу приветствовать, и как консультант, который в первую очередь должен думать о проблемах заказчика, и как энтузиаст СПО, который может решать эти проблемы теми инструментами, с которыми нравится работать :)

tullamoredew комментирует...

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

SSO, соответственно, там же

100% для виндовых станций - имелось ввиду именно наличие аутентификации имено в AD, а не где либо еще.


>Это понятно, но пока готового
>решения нет.
как нет? у почти всех производителей тонких станций есть вариант с winCE или XP. спайс клиент качается при первом подключении, дальше надо просто жать мышкой в броузере

>Угу. Наше. Только это увеличивает
>порог "входа". Нужны сотни
>клиентских мест у заказчика
>для того чтобы этим стоило
>заниматься.
имелись ввиду партнеры - производители тонких станций, а не обязательно интеграторы


Хочу еще добавить, что решение не только VDI, но и серверное. ИМХО даже в первую очередь серверное, хотя солидайс изначально разрабатывался как VDI.

так что удачи - насчет неофициального саппорт-канала в IRC я уже рассказал :)

tullamoredew комментирует...

кстати, начал узнавать насчет CAL-ов, похоже они релевантны только если IIS аутентифицируется в AD, чего в данном случае на происходит

могу быть и не прав, может есть еще нюансы, но IIS в данном случае только показывает страничку

Andrey Markelov комментирует...

Не нужен CAL если редакция Windows Web Server 2008 или к другим редакциям есть External Connector для подключения внешних пользователей. Во всех других случаях CAL нужен. Разделения с типом аутентификации AD/не AD вообще нет.

tails-up комментирует...

Вставлю свои 5 копеек, раз зашла речь о лицензировании Microsoft :)
ALARM: много букв :)
CAL к Windows Server понадобится для всех клиентов, обращающихся через брокер к любым виртуальным машинам на любой платформе. Если используется для работы брокера Windows Server 2008 R2 Web Edition, но присутствует аутентификация в AD для клиентов брокера, CAL также будут нужны, так как Web Edition не может выполнять функции контроллера домена, а значит нужен сервер редакции Standard или выше.
Кроме того, если такие клиенты так или иначе используют ресурсы SQL Server, то для каждого из них понадобится и CAL к SQL-серверу (если последний лицензирован не на процессоры или не является бесплатной редакцией).
External Connector придется покупать по числу Win-серверов, к которым имеется доступ (брокер + AD, если на разных серверах расположены), а SQL выгоднее лицензировать по числу процессоров в сервере (ФИЗИЧЕСКИХ или ВИРТУАЛЬНЫХ в зависимости от среды запуска SQL Server) в таком случае (если клиентов, которым требуется доступ к SQL Server больше, чем соотношение стоимости всех процессоров в сервере SQL к стоимости CAL-лицензии к нему - как-то так).

tullamoredew комментирует...

интересно, а ссылки на описание этого ограничения не найдется?

tails-up комментирует...

Найдется, как не найтись. Документ сей берется на сайте Microsoft. Называется он Product Use Rights или "Лицензионные права на использование продукта Microsoft" в официальном переводе на русский язык. Выходит каждый календарный квартал. Текущая версия - апрель 2010 - лежит тут: http://www.microsoftvolumelicensing.com/userights/Downloader.aspx?DocumentId=3027
Но уже 01.07.2010 будет опубликована новая версия, смотреть тут: http://www.microsoftvolumelicensing.com/userights/DocumentSearch.aspx?Mode=3&DocumentTypeId=1&Language=24
В начале этого документа даны описания всех правил лицензирования программных продуктов Microsoft, приобретенных по программам корпоративного лицензирования. Для коробочных продуктов и OEM-версий в части прав на использование продуктов действуют соглашения с конечным пользователем, предоставляемые в электронном виде обычно (EULA- End User License Agreement). В корпоративном канале EULA не действует.

tails-up комментирует...

страница 11 из 180 текущей версии PUR:
"Вы можете изменить архитектуру своей сети таким образом, чтобы при использовании оборудования или программного обеспечения уменьшить количество устройств или пользователей, которые напрямую обращаются к программному обеспечению на сервере. Такое изменение называется мультиплексированием или регулированием количества запросов. Однако при этом количество лицензий CAL, требуемых для доступа к серверному программному обеспечению или для его использования, не уменьшается. Лицензия CAL требуется для каждого устройства или пользователя, подключаемого к программному обеспечению или оборудованию с мультиплексированием или регулированием количества запросов."
Вы это ограничение имели ввиду?

tullamoredew комментирует...

чтоб закрыть спор скажу что известно лично мне:
1. представители МС продукт видели и анализировали еще в самом начале разработки солидайса, и ни слова о CALах не прозвучало
2. если у вас в процессе эвалуации возникнут вопросы насчет чего либо, обращайтесь в саппорт

Andrey Markelov комментирует...

> 2. если у вас в процессе эвалуации возникнут вопросы насчет чего либо, обращайтесь в саппорт

Абосолютно верно. :) Все мнения принадлежат их авторам и не могут быть связаны с позициями и мнениями официальных лиц или организаций.