1.2, pavlinux (ok), 00:11, 11/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– |
> используется для организации работы тонких клиентов, приложения которых
> выполняются на едином сервере виртуализации, на котором при помощи KVM может
> выполняется множество Windows или Linux десктоп окружений.
Так я (мы :))такую ещё 2006 годе написал(и)
> имеющих доступ к локальным аудио и USB устройствам
да-да-да, мы тоже у япошег стырили USB/IP http://usbip.sourceforge.net/
> в SPICE рендеринг содержимого экрана производится на стороне клиента,
Мы тоже умеем реверсинженерить SunRay протоколы
| |
|
|
3.20, pavlinux (ok), 17:06, 11/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Где же можно посмотреть то, что Вы написали ? :-)
Низя..., говорить-то про это не рекомендуется... :)
| |
|
|
1.4, pavlinux (ok), 00:21, 11/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
>В отличие от таких протоколов как VNC (Virtual Network Computing),
>ICA (Citrix Independent Computing Architecture) и RDP
про VNC они молчат
http://www.redhat.com/virtualization/rhev/desktop/spice/
"SPICE is an adaptive remote rendering protocol used by
Red Hat Enterprise Virtualization for Desktops to connect
users to their virtual desktops. Unlike first-generation
remote rendering protocols such as RDP and ICA, SPICE features
a multi-tiered architecture that was designed to support
today's multi-media desktop experience:"
| |
1.7, anonymous (??), 01:46, 11/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Анонимные аналитики-конспирологи считают, что теперь RHEL6 не за горами. Скорее всего это дело как раз тормозило процесс.
Выходит, что по факту то самое преимущество X (супер пупер сетевая прозрачность) на деле не работает, коль приходится придумывать то же самое но другими способами. Печально. Я так верил в X, и OpenGL через него, и все так просто прозрачно эффективно... хнык.
| |
|
2.8, Slavaz (ok), 03:28, 11/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Анонимные аналитики-конспирологи считают, что теперь RHEL6 не за горами. Скорее всего это
>дело как раз тормозило процесс.
>
>Выходит, что по факту то самое преимущество X (супер пупер сетевая прозрачность)
>на деле не работает, коль приходится придумывать то же самое но
>другими способами. Печально. Я так верил в X, и OpenGL через
>него, и все так просто прозрачно эффективно... хнык.
Для X-сервера нужны тоже ресурсы, причём в зависимости от запускаемой проги на стороне X-клиента потребление ресурсов может "скакать" и расти. А с простеньким X-сервером плюс VNC-вьювером потребление ресурсов(проц, память) на тонком клиенте всё время остается на примерно одном уровне. Наверное, проще проектировать клиентов (меньше RAM, не надо за сетевые свопы беспокоиться и т.д.).
| |
|
1.9, gennady (??), 10:46, 11/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Для сравнения терминал-сервер W2003 на 2*Xenon 2.0 2004G c 4G ОЗУ спокойно обслуживает 25-40 клиентов (операционисты банка) в зависимости от типа CPU. Декстоп на тянет i865 20-30 сессий.
16Г дожно хватать на 150-200 клиентов минимум.
| |
|
2.10, аноним (?), 11:05, 11/12/2009 [^] [^^] [^^^] [ответить]
| +3 +/– |
угу. Все так круто и надежно на самом Ксеноне! А Аргона или Неона нет у вас ?
| |
|
|
4.19, аноним (?), 16:05, 11/12/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну а у меня есть контрпример - 2х4 ядра Xeon, 16 Gb RAM, хранилище через FC. Все под windows 2003. И 8 юзеров завешивают сервер до неприличия. Один нюанс - на сервере разрабатывают ПО под .NET(WPF в основном).
Какое отношение имеет это к теме топика ? Такое же, как и 25-40 одновременных сессий.
| |
|
|
2.14, anonymous (??), 11:53, 11/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Ну операционисты банка и "типичные десктопные задачи" - этот разные вещи. Операционист банка может и по SSH работать с приложением на ncurses :-) Тогда сервер с 512Mb RAM сможет обслуживать 1000 клиентов.
| |
2.15, ананизмус (?), 12:03, 11/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
угу и они все сидят только в инете и в ворде простенький документ редактирует???
видимо они у вас ничего на компе не делают.
| |
|
3.16, Slavaz (ok), 12:08, 11/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>угу и они все сидят только в инете и в ворде простенький
>документ редактирует???
>видимо они у вас ничего на компе не делают.
Неужто они фотошопят, попутно что-то компилят и смотрят фильм?
Чем занимаются операторы-операционисты в банках знаете? Запускают строго определённый набор ПО, часто чуть ли не под ДОС разработанный (консольные приложения не редкость). Шаг влево-вправо - и увольнение. Ибо бапки крутятся. Для них такие технологии - самое то.
| |
|
2.17, rm (??), 12:38, 11/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
вы путаете терминальные сессии и виртуализацию:) если что
| |
2.21, pavlinux (ok), 17:23, 11/12/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Для сравнения терминал-сервер W2003 на 2*Xenon 2.0 2004G c 4G
>ОЗУ спокойно обслуживает 25-40 клиентов (операционисты банка) в зависимости от типа
>CPU. Декстоп на тянет i865 20-30 сессий.
> 16Г дожно хватать на 150-200 клиентов минимум.
40 клиентов породят МИНИМУМ 20Mb/s * 40 = 3.2Gb трафик
(20 - это ужо проверенное число, около 75% время держится такой трафик)
При экране 1024x768x16 bit трафик будет 12.582.912 bit, при 40 юзеров 503.316.480
И это только трафик на картинку экранов.
Увеличим битность до 24 и размер до 19" ~ 1280x1024
Получим 1.258.291.200 ~ 1.2Gb/sec
Опять же, только экран.
Добавляем приложений, пользовательских данных, нагрузку от сервера приложений (АБС какая-нить),
внешний трафик (если прорвётся :)), венда, сама ни хрена не делая, 15% жреёт проц и память...
Уже вижу дымящуюся стойку...
| |
|
3.23, pikador (?), 13:18, 12/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>И это только трафик на картинку экранов.
>
>Увеличим битность до 24 и размер до 19" ~ 1280x1024
>Получим 1.258.291.200 ~ 1.2Gb/sec
>Опять же, только экран.
>Добавляем приложений, пользовательских данных, нагрузку от сервера приложений (АБС какая-нить),
>внешний трафик (если прорвётся :)), венда, сама ни хрена не делая, 15%
>жреёт проц и память...
>
>Уже вижу дымящуюся стойку...
Что-то вы не то пишете, протокол RDP трафик использует весьма экономно, как раз для работы клиенту хватит 20-30 килобит. У меня 30 клиентов без особых проблем работали по каналу в 1 мегабит, и особых проблем со скоростью не было, даже с учетом того, что канал использовался не только для терминалов.
| |
3.24, Аноним (-), 13:21, 12/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
> 40 клиентов породят МИНИМУМ 20Mb/s * 40 = 3.2Gb трафик
У операционистов банка?
Сказочник!!!
Такое может быть только если пытаешься смотреть видео или с какой нибудь 3D графикой.
Работа на каналах для RDP от 512кбит/с для одной сессии через интернет для удаленного офиса (филиал) вполне компфортна. Конечно видео не посмотришь, но оно и не нужно, типичные же пользовательские проги типа почты, браузера, Сметы, 1С и т.п. вполне отзывчивы и быстры.
Вот сейчас под FreeNX нормально работают по сети 100М/б не менее 15-20 пользователей без лагов. Типовые приложения firefox, openoffice и т.п.
VNC да тормоз жуткий, но RDP и NomachineNX уже вполне сносны и на более низкоскоростных каналах.
| |
|
4.26, pavlinux (ok), 22:25, 13/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> 40 клиентов породят МИНИМУМ 20Mb/s * 40 = 3.2Gb трафик
>
>У операционистов банка?
>Сказочник!!!
>
>Такое может быть только если пытаешься смотреть видео или с какой нибудь
>3D графикой.
>
Всё дико начинает висеть если один операционист переключается с одного
приложения на другое, или просто сворачивает окно.
А листание страниц в Консультанте?! Нажав PdDn трафик прыгает на 20Mb/s,
самая веселуха с 10 до 13 когда все всё делают.
А как у же выше писали, сетевая печать убивает всё! А если операционисты генерят
по 1 документу в 15 минут и их 20-30 челов. ....
Мне вот тоже не ясно, как Маздайщики умудряются тормозить удалённое отображение
при сетевой печати. Казалось бы, экран в одну сторону, принтер в другую, разделение в
памяти, в своп не влезших, так нет, там все бьются за ресурсы...
| |
|
|
2.22, mma (?), 09:32, 12/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
C2D 3GHz/4Gb RAM/RAID1/w2003/1C - 30 клиентов
2 x Xeon 4core 2.5GHz/8Gb RAM/RAID5 SAS 256mb/win2k3/1C - 25 клиентов максимум
Не находите что все зависит от специфичности нагрузки а не от абстрактной ее составляющей?
| |
|
1.25, PAiN (?), 05:08, 13/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
блин народ вот RedHat допилет это и посмотрим что будет!
А теперь посмотрим
Автор я так понял что хотел сказать что ставится RHEV потом натягиваем 40-30 виртуальных машин (win & linux), пару танцев с бубном что бы работала с VLAN (вдруг вам понадобиться других пустить ) и и все это на 16 GB ! И пускаем это все на тонкие клиенты ! Я вам скажу что это очень хорошо так как виртулизация от MICRO такое не сможет !
А если и сможет только для пасьянса!
| |
|
2.27, pavlinux (ok), 22:38, 13/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>А теперь посмотрим
>
> Автор я так понял что хотел сказать
>что ставится RHEV потом натягиваем 40-30 виртуальных машин (win & linux),
>пару танцев с бубном что бы работала с VLAN (вдруг вам
>понадобиться других пустить ) и и все это на 16 GB
>! И пускаем это все на тонкие клиенты ! Я вам
>скажу что это очень хорошо так как виртулизация от MICRO такое
>не сможет !
> А если и сможет только для пасьянса!
Я всегда рассчитываю как 1 ядро на 1 GHz и с 1Gb RAM = 1 VM + хостовая система.
Тест прост - Это нормальное листание и прокрутка (scrolling) PDF страниц а Аcrobat Reader.
То есть на Xeon 7450 или Opteron 2439 должно помещаться 12 машин, при 12-16 Gb RAM.
Если используются одинаковые гости, то это очень уменьшает расход памяти.
А если юзать Kernel Samepage Merging и kvm, то впихнуть 50 машин
на 4 процесорнную мать с 4/6 ядерными процами как нефиг делать.
(Ведь в новости не слова про Гигагерцы и количество процов и ядер?! :))
| |
|
|