Differences between revisions 12 and 13
Revision 12 as of 2008-07-10 19:07:02
Size: 20064
Comment:
Revision 13 as of 2008-07-13 21:07:19
Size: 19120
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
##1:11:00
Первый кадр, который мы сняли это загруженное программное обеспечение на сервере, которое естественно запускает свой собственный XDM .
Со временем, после появления версии 2.6 ядра Linux и виртуальной файловой системы sysfs, политика по оформлению и регистрации драйверов и аппаратного обеспечения компьютера изменилась и необходимость в сборке отдельного специфического ядра для терминальных клиентов отпала. LiveCD в ALT Linux, к примеру, изготавливается из самого обычного ядра с обычными модулями. Проект же LTSP, к сожалению, был сильно привязан к уже разработанной инфраструктуре и системе патчей, а потому непосредственная интеграция его в обычный дистрибутив не представлялась возможной. Сборка LTSP в рамках ALT Linux, к примеру, была большим bundle-файлом. Он выкладывался в определенное место, после чего целая коллекция скриптов настраивала нужные сервисы, --- только так это работало. Поэтому был создан ALTSP - ALT Linux Terminal Server Project. Его разработчики частично скопировали инфраструктуру LTSP, избежав при этом необходимости собирать специальное ядро. Результатом работы ALTSP стал специализированный дистрибутив, установка которого практически ничем не отличается от установки ALT Linux Мастер, за двумя исключениями:
Line 6: Line 5:
Времена менялись, и в какой-то момент с появлением ядра 2.6 и виртуальной файловой системы sysfs, а также с изменением политики по оформлению и регистрации драйверов и аппаратного обеспечения машины в ядре Linux необходимость в создании отдельного специфического ядра для клиентов отпала. Например, LiveCD в АльтЛинуксе изготавливается из самого обычного ядра с обычными модулями, в общем берётся обычная система. К сожалению , проект LTSP был сильно завязан на уже разработанную инфраструктуру и систему патчей, и поэтому так просто интегрировать его в обычный дистрибутива не представлялось возможным. Один раз даже кто-то даже собрал LTSP под Альт - это получился большой bundle который надо было выложить в определенное место, после чего различные скрипты настраивали нужные сервисы и это начинало как-то работать. Но полной автоматизации достичь было невозможно. Поэтому разработчики проекта который получил название ALTSP - Alt Linux
Terminal Server Project - поступили очень просто --- они частично скопировали инфраструктуру - т.е. структуру настройки сервисов из проекта LTSP, некие технологии, позволяющие осуществлять удалённого выполнение, но никакого специального ядра , никаких специальных хитрых утилит делать не стали, и выяснилось что и без этого все достаточно неплохо работает. Получился специализированный дистрибутив, который устанавливается на выделенный сервер - обращаем внимание- на выделенный сервер- т.е. никаких вещей подобных установке ОС Windows параллельно с ALTSP не предусмотрено, установка которого практически ничем не отличается от установки того же Мастера, за двумя исключениями:
 *первое --- раздела установщика под названием "разметка диска" нет, там есть окно в котором написано примерно следующее - "а сейчас я вам весь диск убью" и галочка "я согласен". Потому что там достаточно хитро надо разметить всё.
 *Второе --- в этом сервере должны быть две сетевых карты, причем eth0 должна смотреть в внешний интернет, а другая в локальную сеть - точнее в класс которому вы раздаете загрузку. Настраиваются они следующим образом: внешняя карта должна быть настроена статически, или необходимо совершать некие упражнения для того чтобы сам сервер получал настройки например по DHCP. Если вкратце то надо узнать настройки, затем настроить статически при установке, а затем убрать и перенастроить на DHCP. Вторая сетевая карта обязана быть настроена единственным способом (адрес должен быть 192.168.0.1).
 * отсутствует раздел установщика "Разметка диска": дистрибутив требует для работы выделенный сервер, а потому на соответствующей стадии установки требуется лишь подтвердить передачу всего жесткого диска в распоряжение установщика;
Line 11: Line 7:
Больше видимых различий в установке скажем Мастера и ALTSP нет. Ну и другой пакетный набор.  * дистрибутив требует наличия в компьютере двух сетевых карт, причем Интернет должен быть доступен через устройство eth0 (''это в какой момент оно eth0?'' -- DmitryChistikov <<DateTime(2008-07-14T01:07:18+0400)>>), а локальная сеть (класс, машины в котором будут загружаться по сети) --- через eth1 (''еще раз уточнить этот момент!'' -- DmitryChistikov <<DateTime(2008-07-14T01:07:18+0400)>>); устройство eth0 при этом должно получать IP-адрес статически (в случае DHCP создается специальная "обертка", позволяющая загрузиться со статическими настройками и затем перенастраивающаяся на DHCP), а IP-адрес для eth1 должен быть 192.168.0.1.

Других видимых различий в процедуре установки "Мастера" и ALTSP нет. Заметим, что пакетный состав дистрибутивов, естественно, различается.

 ''(Конец переведенной на данный момент части. Окончание работы над фрагментом --- сегодня утром.)'' -- DmitryChistikov <<DateTime(2008-07-14T01:07:18+0400)>>
Line 94: Line 94:
|| 20 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, DmitryChistikov || || || || 25 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, DmitryChistikov || || ||

Терминальный сервер со стороны пользователя

Со временем, после появления версии 2.6 ядра Linux и виртуальной файловой системы sysfs, политика по оформлению и регистрации драйверов и аппаратного обеспечения компьютера изменилась и необходимость в сборке отдельного специфического ядра для терминальных клиентов отпала. LiveCD в ALT Linux, к примеру, изготавливается из самого обычного ядра с обычными модулями. Проект же LTSP, к сожалению, был сильно привязан к уже разработанной инфраструктуре и системе патчей, а потому непосредственная интеграция его в обычный дистрибутив не представлялась возможной. Сборка LTSP в рамках ALT Linux, к примеру, была большим bundle-файлом. Он выкладывался в определенное место, после чего целая коллекция скриптов настраивала нужные сервисы, --- только так это работало. Поэтому был создан ALTSP - ALT Linux Terminal Server Project. Его разработчики частично скопировали инфраструктуру LTSP, избежав при этом необходимости собирать специальное ядро. Результатом работы ALTSP стал специализированный дистрибутив, установка которого практически ничем не отличается от установки ALT Linux Мастер, за двумя исключениями:

  • отсутствует раздел установщика "Разметка диска": дистрибутив требует для работы выделенный сервер, а потому на соответствующей стадии установки требуется лишь подтвердить передачу всего жесткого диска в распоряжение установщика;
  • дистрибутив требует наличия в компьютере двух сетевых карт, причем Интернет должен быть доступен через устройство eth0 (это в какой момент оно eth0? -- DmitryChistikov 2008-07-13 21:07:18), а локальная сеть (класс, машины в котором будут загружаться по сети) --- через eth1 (еще раз уточнить этот момент! -- DmitryChistikov 2008-07-13 21:07:18); устройство eth0 при этом должно получать IP-адрес статически (в случае DHCP создается специальная "обертка", позволяющая загрузиться со статическими настройками и затем перенастраивающаяся на DHCP), а IP-адрес для eth1 должен быть 192.168.0.1.

Других видимых различий в процедуре установки "Мастера" и ALTSP нет. Заметим, что пакетный состав дистрибутивов, естественно, различается.

  • (Конец переведенной на данный момент части. Окончание работы над фрагментом --- сегодня утром.) -- DmitryChistikov 2008-07-13 21:07:18

Запустим клиент. Что должен сделать системный администратор для настройки клиента? На всех машинах- терминалах должна быть настроена сетевая загрузка, причём, желательно, по умолчанию. Администратор также должен обеспечить, чтобы клиенты и сервер были в одной СПД. Сетевых загрузок бывает несколько видов, нам нужна та, которая называется PXE. По сути, это встроенный в сетевую карту достаточно полный большой клиент dhcp, bootp для получения IP-адреса и tftp для скачивания первичного загрузчика.

../terminal_client_boot.png

Как видите подсказка у логина та же самая, но удалённый XDM знает, что к нему подключились не с локальной машины, поэтому в меню другой состав.

../terminal_client_login.png ../terminal_client_login_options.png ../terminal_server_login_options.png

Какие проблемы связаны с такой организацией работы:

  • Проблема с разделением ресурсов- разделение на уровне пользователей. Если у вас в компьютерном зале 4 компьютера и один сервер то 4 пользователя работающие одновременно на одном сервере запускают соответственно 4 комплекта ПО. Если 24 компьютера и один сервер, то 24. Когда пользователи запускают n комплектов ПО, то они потребляют без малого n объемов оперативной памяти и едят без малого n промежутков процессорного времени и генерируют n потоков обмена данными с диском. Практика эксплуатирования терминальных классов показывает, что для того чтобы нормально работать пользователям (большой документ в OOffice и Firefox с несколькими вкладками) надо оперативной памяти примерно 256 мб под сервер плюс 8 клиентов по 256 мб(c KDE или аналогичной DE ) и еще 8 по 128 мб(например с xfce).Замеров загрузки CPU и обращений к диску не проводилось. Хотя опыт показывает что вместо одного диска лучше использовать RAID. Мораль --- если есть класс достаточно старых компьютеров и есть возможность купить современную нормальную машину, то это хорошее решение задачи.
  • проблема с доступом к ресурсам на уровне машин. Мы решили ровно одну проблему --- мы разделили запуск задач и ввод/вывод, но ввод\вывод исключительно связанный с графической подсистемой X11. Все что связанно с X11 отлично разделяется на клиенте и сервере - задача запускается на машине-сервере, а ввод\вывод X11 - на рабочей станции. Но таким образом не решаются следующие проблемы:
    • если например программа звук играет, то играть она будет на машине-сервере.
    • Однако гораздо интереснее момент, когда пользователь поработал, достал из кармана флешку и вставил её в ... рабочую станцию. Между тем все файлы с которыми он работал, все что он видит на экране работает на сервере. А ввод\вывод на флешку надо осуществлять на клиенте.
    Есть два способа решения задачи:
    • первое --- по окончании работы все пользователи выстраиваются в очередь к администратору с флешками. Это решение на самом деле вполне реально если у вас учебный класс.
    • Для решения этой проблемы в терминале проделана дополнительная работа.

$ mount
/dev/hda2 on / type ext3 (rw)
proc on /proc type proc (rw,noexec,nosuid,gid=19)
sysfs on /sys type sysfs (rw)
udevfs on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw)
shmfs on /dev/shm type tmpfs (rw)
tmpfs on /dev/tmp type tmpfs (rw,nosuid)
/dev/hda6 on /home type ext3 (rw,nosuid)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
ltspfs on /home/user/Drives/floppy0/ type fuse  (rw,nosuid,nodev,user=user)

Если посмотреть на mount, обратите внимание на последнюю строчку. Это некое волшебное действие, которое производится на сервере, чтобы возвратить имеющееся устройство обратно на клиент. То есть у пользователя будет в домашнем каталоге подкаталог Drives, а в нем соответствующий подкаталог floppy0, который будет соответствовать дискетке подключенной к терминальному клиенту.../terminal_client_floppy_unmounted.png

  • На скриншоте /*виден этот файл под названием floppy и*/ видна иконка на панели под названием "отмонтированная дискета". Идея состоит в следующем: устройство, подключённое к локальной машине, то есть к рабочей станции, неким образом (с помощью fuse) прокидивается на сервер. Собственно именно этому соответствует эта строка. Тем самым, когда вы запускаете на сервере программу, которая обращается сюда, в результате она заходит на рабочую станцию к соответствующему каталогу. Аналогично с CD/DVD-приводами. Для нелюбознательного пользователя это выглядит как работа с обычной машиной. Хитрость в том, что всё работает на сервере, а диск доступен на сервере именно путём обратного проброса. Посмотрим ещё раз mount.

../terminal_client_cd_mount.png

$ mount
/dev/hda2 on / type ext3 (rw)
proc on /proc type proc (rw,noexec,nosuid,gid=19)
sysfs on /sys type sysfs (rw)
udevfs on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw)
shmfs on /dev/shm type tmpfs (rw)
tmpfs on /dev/tmp type tmpfs (rw,nosuid)
/dev/hda6 on /home type ext3 (rw,nosuid)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
ltspfs on /home/user/Drives/floppy0/ type fuse  (rw,nosuid,nodev,user=user)
ltspfs on /home/user/Drives/atacd-hdc/ type fuse  (rw,nosuid,nodev,user=user)
/dev/hdc on /media/cdrom type iso9660 (rw,noexec,nosuid,nodev,utf8,user=user)

  • То же самое творится со звуком. Но со звуком есть одна неприятная особенность, которая состоит в следующем: из-за того, что работа со звуковой подсистемой в разных видах Unix-систем устроена немного по разному, далеко не все программы в действительности легко работают с таким пробросом звука на клиент. Для решения используется ESD и PulseAudio. Проброс звука делается следующим образом: для тех программ, которые умеют в качестве выходного устройства использовать не конкретные устройства (/dev/dsp), а предоставляют возможность выбора, для них используется самый простой из всех возможных способов. На клиентской машине запускается ESD(Enlightened Sound Daemon) --- программа, которая по специальному протоколы принимает подключения по сети( эти подключения связаны с проигрыванием звука) и проигрывает звук. На сервере устанавливается переменная окружения ESPEAKER, которая указывает, тем программам которые умеют работать с ESD что звук надо выводить не на текущую машину, а подключаться по указанному адресу. Все программы, которые скомпилированы с libesd, работают таким образом. Для тех машин, которые не умеют это делать, но умеют работать с pulseaudio, запускается ещё и pulseaudio-сервер,который делает ровно тоже самое. Все программы, которые работают с alsa с помощью специального плагина для alsa и pulseaudio тоже в итоге работают сетевым образом. Лишь те программы которые по старинке пишут сразу в /dev/dsp работают с /dev/dsp и поэтому звук прокинут быть не может. Поэтому множество запущенных таких программ создают страшную какофонию. Лечится это очень простым способом --- нужно убить звуковую карту на сервере (открутить её, поставить в черный список её модуль), - в общем сделать так чтобы /dev/dsp отсутствовал.

Речь о терминальном классе идёт в двух случаях:

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

Недостатки терминального класса:

  • Современные X Window System не работают например на s3 trio64.
  • Еще один значимый недостаток терминального сервера --- один пользователь не может одновременно работать на двух терминальных клиентах.Т.е. при работе через тонкий терминальный клиент каждый сеанс работы(пользователь сидящий за терминальным клиентом) должен использовать использовать отличную от других учетную запись. С другой стороны, на сегодняшний день только "Линукс терминал" обеспечивает концепцию терминального класса и мобильного рабочего места. Реализуется это тем, что у каждого пользователя есть личные персональные записи, хранящиеся на сервере, которые он эксплуатирует и использовать чужие ему не позволяется. Это делается централизованно и абсолютно прозрачно с помощью Альтератора, который заводит пользователей на сервере(потому что больше нигде заводить их не надо).


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

25

1

1

1

1

ArtemSerebriyskiy, DmitryChistikov


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080709/02TerminalClient (last edited 2008-10-09 18:39:06 by MaximByshevskiKonopko)