Различия между версиями 4 и 34 (по 30 версиям)
Версия 4 от 2008-07-10 01:58:09
Размер: 14139
Редактор: eSyr
Комментарий:
Версия 34 от 2008-10-09 21:39:06
Размер: 23490
Редактор: MaximByshevskiKonopko
Комментарий: No more illustration needed.
Удаления помечены так. Добавления помечены так.
Строка 1: Строка 1:
##1:11:00
Первый кадр, который мы сняли это загруженное программное обеспечение на сервере, которое естественно запускает свой собственный XDM .
== Терминальный сервер со стороны пользователя ==
Строка 4: Строка 3:
Времена менялись, и в какой-то момент с появлением ядра 2.6 и виртуальной файловой системы sysfs, а также с изменением политики по оформлению и регистрации драйверов и аппаратного обеспечения машины в ядре линукс необходимость в создании отдельного специфического ядра для клиентов отпала. Например, LiveCD в АльтЛинуксе изготавливаеться из самого обычного ядра с обычными модулями, в общем берётся обычная система. К сожалению , проект LTSP был сильно завязан на уже
разработтанную инфраструктуру и систему патчей, и поэтому так просто интегрировать его в обычный дистрибутива не представлялось возможным. Один раз даже кто-то даже собрал LTSP под Альт - это получился большой bundle который надо было выложтить в определенное место, почле чего различные скрипты настраивали нужные сервисы и это начинало как-то работать. Но полной автоматизации достичь было невозможно. Поэтому разработчики проекта который получил название ALTSP - Alt Linux
Terminal Server Project - поступлии очень просто --- они частично скопировали инфраструктуру - т.е. структуру настройки сервисов из проекта LTSP, некие технологие, позволяющие осуществлять удалённого выполнение, но никакого специального ядра , никаких специальных хитрых утилит делать не стали, и выяснилось что и без этого все достаточно неплохо работает. Получился специализированный дистрибутив, который устанавливаеться на выделенный сервер - обращаем внимание- на выделенный сервер- т.е. никаких вещей подобных установке ОС Windows паралельно с ALTSP не предусмотренно, установка которого практически ничем не отличается от установки того же Мастера, за двумя исключениями:
 *первое --- раздела установщика под названием "разметка диска" нет, там есть окно в котором написанно примерно следующее - "а сейчас я вам весь диск убью" и галочка "я согласен". Потому что там достаточно хитро надо разметить всё.
 *Второе --- в этом сервере должны быть две сетевых карты, причем eth0 должна смтореть в внешний интернет, а другая --- в локальную сеть - класс которому вы раздаете загрузку. Настраиваються они следующим образом: внешняя карта должна быть настроена статически, или необходимо совершать некие упражнения для того чтобы сам сервер получал настройки например по DHCP. Вкратце надо узнать настройки, затем настроить статически при установке, а затем убрать и перенастроить на DHCP.
 Вторая сетевая карта обязана быть настроена единственным способом (адрес должен быть 192.168.0.1).
Со временем, после появления версии 2.6 ядра Linux и виртуальной файловой системы sysfs, политика по оформлению и регистрации драйверов и аппаратного обеспечения компьютера изменилась и необходимость в сборке отдельного специфического ядра для терминальных клиентов отпала. LiveCD в ALT Linux, к примеру, изготавливается из самого обычного ядра с обычными модулями. Проект же LTSP был, к сожалению, сильно привязан к уже разработанной инфраструктуре и системе патчей, а потому непосредственная интеграция его в обычный дистрибутив не представлялась возможной. Сборка LTSP в рамках ALT Linux, к примеру, была большим bundle-файлом. Он выкладывался в определенное место, после чего целая коллекция скриптов настраивала нужные сервисы, --- только так это работало. Поэтому был создан ALTSP --- ALT Linux Terminal Server Project. Его разработчики скопировали часть инфраструктуры LTSP, избежав при этом необходимости собирать специальное ядро. Результатом работы ALTSP стал специализированный дистрибутив "Линукс Терминал", установка которого практически ничем не отличается от установки дистрибутива "Линукс Мастер", за двумя исключениями:
Строка 11: Строка 5:
Больше видимых различий в установке скажем Мастера и ALTSP нет. Ну и другой пакетный набор.  * отсутствует раздел установщика "Разметка диска": дистрибутив требует для работы выделенный сервер, а потому на соответствующей стадии установки требуется лишь подтвердить передачу всего жесткого диска в распоряжение установщика;
Строка 13: Строка 7:
Запустим клиент. что должен сделать системный администратор для настройки клиента.
1. а всех машинах- терминалах должнв быть настроена сетевая загрузка, причём, желательно, по умолчанию. Администратор
также должен обеспечить, чтобюы клиенты и сервер были в одной СПД. Сетевых загрузок бывает несколько видов, нам нужна
та, которая называеться PXE. По сути, это встроенный в сетевую карту достаточно полный большой клиент dhcp, bootp для
получения IP-адреса и tftp для скачивания первичного загрузчика.
 * дистрибутив требует наличия в компьютере двух сетевых карт, причем Интернет должен быть доступен через устройство eth0, а локальная сеть (класс, машины в котором будут загружаться по сети) --- через eth1; устройство eth0 при этом должно получать IP-адрес статически (в случае DHCP создается специальная "обертка", позволяющая загрузиться со статическими настройками и затем перенастроиться на использование DHCP), а IP-адрес для eth1 должен быть 192.168.0.1.

##(''это в какой момент оно eth0?'' -- DmitryChistikov <<DateTime(2008-07-14T01:07:18+0400)>>)
##У нас же ж ifrename. Надо eth0 --- будет eth0.


Других видимых различий в процедуре установки "Мастера" и "Терминала" нет. Заметим, что пакетный состав дистрибутивов, естественно, различается. Приглашение XDM (в роли которого выступает kdm) на установленном "Линукс Терминале" выглядит так:

{{attachment:../terminal_client_login.png}}

Организуем теперь запуск клиентских машин (рабочих станций, или машин-терминалов). В первую очередь необходимо убедиться, что клиенты и сервер находятся в общей СПД. Во вторую --- настроить на клиентах сетевую загрузку (желательно --- по умолчанию). Заметим, что способов загрузить машину по сети есть несколько. Нужный нам вариант называется PXE. Поддерживающие PXE сетевые карты могут получать настройки по DHCP (используется протокол BOOTP) и использовать протокол TFTP для скачивания первичного загрузчика. Во время загрузки по сети экран рабочей станции может выглядеть, например, так:
Строка 21: Строка 21:
Как видите подсказка у логина та
же самая, но удалённый XDM знает, что к нему подключились не с локальной машины, поэтому в меню другой
состав.
Если загрузка прошла успешно, то на экране мы увидим приглашение XDM, ничем с первого взгляда не отличающееся от приглашения XDM на сервере. Однако, как мы понимаем, это результат взаимодействия программы xdm на сервере и программы X (X-сервера) на клиентской машине. Удаленный XDM знает о том, что к нему подключились по сети, и потому предложит другой состав меню.
Строка 25: Строка 23:
{{attachment:../terminal_client_login.png}}
{{attachment:../terminal_server_login.png}}
{{attachment:../terminal_client_login_options.png}}
На машине-сервере:
Строка 30: Строка 27:
На машине-клиенте:
Строка 31: Строка 29:
Какие проблемы с этим связаны: проблема с разд. ресурсов и проблема с доступом к ресурсам. {{attachment:../terminal_client_login_options.png}}
Строка 33: Строка 31:
Про разделение. Если у вас в комп. зале 4 компьютера, то 4 комплекта ПО, если 24, то 24. Кгда пользователи запускают n комплектов ПО, то они потребляют n комплектов памяти и едят n отрезков времени и генерируют n потоков обращения к диску. Практика эксплдуатирования терм. классов показывает, что нормально работать пользователям (большой документ в оофисе и фаерфокс с несколькими вкладками) надо 256 метров под сервер, и на каждыцй клиент по 256 (для xfce -- по 128). Мораль --- если есть класс достаточно старых компьютеров и есть возможность купить нормальную машину, то это хорошее решение задачи. Но на этом грабли не кончаются. Итак, терминальный класс успешно функционирует. При этом, однако, мы должны решить следующие проблемы:
Строка 35: Строка 33:
Мы решили ровно одну проблему --- мы разделили запуск задач и В/В, но только связанный с X11. Не решаются какие проблемы: если программа звук играет, то играть она будет на сервере. Но это ладно, гораздо интереснее момент, когда полоьзователь решил скинуть файлы на флешку. Есть два спосба решения задачи: первое --- все пользователи выстраиваются в очередь к администратору с флешками. Для этог в терминале проделана дополнительная работа. Если посмотреть на mount, обратите внимание на последнюю строчку. Это некое волшебное действие, которое произв. на сервере, чтобы возратить имеющееся устройство обратно на клиент. То есть у польз. будет каталог drives, а у него подкаталог floppy0, который будет сответствовать его дискетке.  * разделение ресурсов;
 * доступ к ресурсам.
Строка 37: Строка 36:
На скриншоте виден этот файл под названием floppy и иконка на панели "неподключённый диск". Другое дело, что мы не можем его сейчас вставить. Идея состоит в следующем: устройство, подключённое к локальной машине, то есть к рабочей станции, неким образом (с помощью fuse) прокидивается на сервер, чему соответствует эта строка. Тем самым, когда запускаете на сервере программу, которая лезет туда, она лезет на рабочую станцию. Аналогично с диском. Для нелюбознательного пользователя это выгляит как работа с обычной машиной. Хитрость в том, чт всё работает на сервере, и доступен он путём обратного проброса. Посмотрим ещё раз mount. То же самое творится со звуком. Но со звуком лектор уже имел некое неприятное упражнение. Тут есть одна непр. особенность, которая состит в следующем: из-за того, что работа со звуком в разных юних-системах устроена немного по-разнму, то не все программы могут со звуком работать. Тут используется ESD. Проброс звука делается след. образом: для тех программ, которые умеют исп. не конкретные устройства (/dev/dsp), дл них исп. самый постой из всех возм. способов. На клиентской машине запускается ESD, это всего лишь программа, которая принимает подклю. по сети, он связаны с проигр. звука. На сервере у польз. указывается переменная ESPEAKER, которая указывает, куда программам пдключаться. Все рпограммы, которые скомпилированы с libesd, они работают. Для тех машин, которые не умеют это делать, а умеют pulseaudio, запускается ещё и pulseaudio-сервер. Наше счастье, что на сервере не было звуоковй карты. Все программы, которые работают с alsa, ни тоже работают по сети. Лектор на это наталкивался, но это лечится очень простым способом --- убить звуковую карту (открутить её, поставить в блеклист модуль), сделать так, чтобы он отсутствовал (например удалить руками в rc.local). Рассмотрим их подробнее.
Строка 39: Строка 38:
Речь о терминалсервере идёт в двух случаях: эксплуатация старого железа. Есть, правда, один недстаток: современные иксы не работают на s3 trio64. Второй случай --- когда адм. подлежит одна машина, а не все в классе. При этом экономится куча времени. Переустановка ПО делается сама. === Проблема разделения ресурсов ===
Строка 41: Строка 40:
Ещё один недостаток терминального сервера --- не может быть двух логинов с разных машин. С другой тсороны, на сегодняшний день только Линукс терминал обеспечивает концепцию терминлаьного класса и мобильного места. Реализуется это тем, что у каждого пользователя свои записи, которые заводятся на сервере. Эта проблема касается разделения ресурсов между пользователями. Если в нашем компьютерном классе используются 4 клиентских и одна серверная машина, то 4 одновременно работающих на одном сервере пользователя запускают, соответственно, 4 комплекта программного обеспечения. Если сервер по-прежнему один, а клиентов 24, то комплектов запущенного ПО будет тоже 24. Когда пользователи запускают N комплектов ПО, то они потребляют почти в N раз больше оперативной памяти, используют почти в N раз больше промежутков процессорного времени и генерируют N потоков обмена данными с дисковой подсистемой (по сравнению с одним комплектом ПО).

Практика эксплуатирования терминальных классов показывает, что для нормальной работы пользователей (открыт большой документ в !OpenOffice.org, запущен Mozilla Firefox с несколькими вкладками) необходимы следующие объемы оперативной памяти: примерно 256 MB для нужд сервера, по 256 MB для каждого из примерно 8 клиентов и по 128 MB для каждого из клиентов, начиная с девятого (если всего их больше восьми). Экономия при большом количестве клиентов может достигаться, к примеру, за счет эффективного использования механизма разделения памяти. Заметим, что если использовать не KDE (или аналогичную по "тяжести" среду), а, скажем, XFCE, то на 8 клиентов вполне может хватить и 1 GB памяти.

## ''Не уверен насчет '''разделения памяти'''. С одной стороны, shared memory --- это средство System V IPC, с другой --- в данной ситуации '''разделяться''' могут не только библиотеки.'' -- DmitryChistikov <<DateTime(2008-07-14T15:36:30+0400)>>
## Тут значения замеров есть. Да будут значения замеров.

Замеров загрузки CPU и обращений к диску при исследованиях не проводилось. Опыт, тем не менее, говорит, что вместо одного диска разумно использовать RAID-массив. Так или иначе, если в наличии имеется целый класс достаточно старых компьютеров и есть возможность купить хорошую современную машину "под сервер", то использование сетевой загрузки с "тонкими" клиентами является, безусловно, хорошим выбором.

## ''Тут еще желательно перепроверить числа, а еще лучше --- положить ссылку на источник (результаты тестов, описания набора ПО).'' -- DmitryChistikov <<DateTime(2008-07-14T15:36:30+0400)>>

=== Проблема доступа к ресурсам ===

На самом деле мы решили только часть поставленной ранее задачи. У нас корректно разделены запуск и выполнение задач, а также ввод-вывод, связанный с подсистемой X11 (сюда относится в том числе работа с клавиатурой и мышью). Задачи запускаются на машине-сервере, а ввод-вывод X11 осуществляется на рабочей станции. Но таким способом не решаются следующие проблемы:

 1. Работа с данными осуществляется на сервере, в то время как для работы со сменными носителями разумно использовать клиентские машины.
 1. Если запущенная программа, к примеру, проигрывает звук, то его вывод использует оборудование сервера.

Первую из указанных проблем можно решать по-разному. Первый вариант довольно прозаичен: по окончании работы все пользователи выстраиваются в очередь к администратору класса с флэшками. Это, если вдуматься, весьма разумное решение, особенно в случае учебного класса со строгой дисциплиной работы. Второй вариант использует проделанную создателями "Линукс Терминала" дополнительную работу. Рассмотрим эту возможность подробнее. Выведем список подмонтированных файловых систем:

##{{attachment:../terminal_client_konsole_mounted_devices.png}}

## ''Тут был аттачмент, переведенный, по-видимому, в текст (вывод '''''mount'''''). Я не уверен, правильно ли он отредактирован. Надо проверить (ссылка на аттачмент закомментирована).'' -- DmitryChistikov
##'' поправил '' - ArtemSerebriyskiy <<DateTime(2008-07-14T15:36:30+0400)>>

{{{
$ 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)
/dev/hda5 on /var type ext3 (rw,nosuid)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
ltspfs on /home/user/Drives/floppy0/ type fuse (rw,nosuid,nodev,user=user)
}}}

Обратим внимание на последнюю строку. Она означает, что на сервере заранее произведено некое "волшебное" действие, которое "возвращает" имеющееся устройство обратно на рабочую станцию. В домашнем каталоге пользователя (который расположен, как и вся файловая система клиента, на сервере) есть подкаталог Drives, а в нем соответствующий подкаталог floppy0, который соответствует дискете, вставленной в машину-клиент.

{{attachment:../terminal_client_floppy_unmounted.png}}

На скриншоте видна иконка на панели с названием "отмонтированная дискета". Идея проста: устройство, подключенное к локальной машине (рабочей станции) хитрым способом (с помощью системы fuse --- filesystem in userspace) "прокидывается" на сервер. Именно информацию об этом пробросе и сообщила нам программа mount. Тем самым, когда какая-либо программа на сервере обращается к каталогу `/home/user/Drives/floppy0`, она в действительности заходит на нужную рабочую станцию в соответствующий каталог. Для нелюбознательного пользователя это выглядит точно так же, как работа с обычной машиной.

Таким же образом устроена и работа с CD/DVD-приводами. Функционирование ПО происходит на сервере, при этом диск с клиентской машины доступен с помощью такого же обратного проброса. Кликнем по соответствующей иконке и подмонтируем наш диск, выбрав пункт меню "Подключить":

{{attachment:../terminal_client_cd_mount.png}}

Посмотрим теперь на вывод программы mount:

{{{
$ 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)
/dev/hda5 on /var type ext3 (rw,nosuid)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
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)
}}}

##{{attachment:../terminal_client_cd_mounting.png}}

Последние две строки говорят нам о том, что подключение прошло успешно. Изменилась и иконка на панели:

{{attachment:../terminal_client_cd_mounted.png}}

Кликнем по ней и выберем пункт меню "Открыть в новом окне":

{{attachment:../terminal_client_cd_open.png}}

Откроется окно с содержимым нашего DVD-диска:

{{attachment:../terminal_client_cd_browse.png}}

Подобным же образом (проброс сервиса) решается и вторая проблема, касающаяся звукового вывода. Здесь, однако, есть одна неприятная особенность: поскольку работа со звуковой подсистемой в разных видах Unix-систем устроена несколько различающимися способами, то далеко не все программы легко умеют работать с пробросом звука на рабочую станцию. Для тех программ, которые умеют в качестве выходного устройства использовать не конкретные файлы (`/dev/dsp`), а специальные звуковые подсистемы (иными словами, предоставляют пользователю возможность тонкой настройки), есть возможность использовать esd --- Enlightened Sound Daemon. Эта программа запускается на клиентской машине, принимает сетевые подключения по специальному протоколу и воспроизводит передаваемые ей аудиоданные. На сервере устанавливается переменная окружения ESPEAKER, которая указывает умеющим работать по этому протоколу программам, что для проигрывания звука надо использовать удаленный esd-сервер с заданным адресом. Все собранные с поддержкой библиотеки libesd программы работают именно так. Аналогичная схема используется и для программ, работающих со звуковой системой !PulseAudio. Программы, использующие ALSA (Advanced Linux Sound Architecture), работают с помощью специального !PulseAudio-плагина (plug-in) к ALSA. Лишь пишущие по старинке в `/dev/dsp` программы не могут быть настроены для работы по сети. Множество запущенных программ такого типа могут создать какофонию на звуковом устройстве сервера. Для устранения этой проблемы достаточно настроить сервер таким образом, чтобы устройство `/dev/dsp` в системе отсутствовало: вынуть (физически) звуковую карту, отключить (запретить) загрузку ее модуля ядра и т. п. Тогда можно будет эмулировать `/dev/dsp` пробрасываемыми по сети средствами.

Подведем итоги. Терминальный класс дает возможность:

 * эффективно эксплуатировать устаревшее оборудование;
 * администрировать одну машину вместо целого класса (если рабочий процесс допускает возможность использования терминальных клиентов; существенно упрощается при этом, например, процедура переустановки ПО).

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

 * Современные X Window System не работают с некоторыми устройствами, к примеру с !S3Trio64.
 * Один пользователь не имеет возможности работать на двух рабочих станциях одновременно (различные запущенные в одно время сеансы работы должны использовать различные учетные записи).

Заметим, что на сегодняшний день только "Линукс Терминал" обеспечивает "из коробки" концепцию терминального класса и мобильного рабочего места. Достигается это при помощи личных учетных записей, хранящихся на сервере. Использовать чужие учетные записи пользователь не может, так как они защищены неизвестными ему паролями. Каждый пользователь при этом может сесть за любое свободное рабочее место и получить доступ к своей учетной записи, то есть к своему собственному персонализированному окружению. Управление учетными записями централизованно и абсолютно прозрачно (может производиться, к примеру, с помощью Alterator'а).
Строка 49: Строка 145:
|| 5 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, ОльгаТочилкина || || || || 90 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy,  DmitryChistikov, MaximByshevskiKonopko || || ||

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

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

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

Других видимых различий в процедуре установки "Мастера" и "Терминала" нет. Заметим, что пакетный состав дистрибутивов, естественно, различается. Приглашение XDM (в роли которого выступает kdm) на установленном "Линукс Терминале" выглядит так:

../terminal_client_login.png

Организуем теперь запуск клиентских машин (рабочих станций, или машин-терминалов). В первую очередь необходимо убедиться, что клиенты и сервер находятся в общей СПД. Во вторую --- настроить на клиентах сетевую загрузку (желательно --- по умолчанию). Заметим, что способов загрузить машину по сети есть несколько. Нужный нам вариант называется PXE. Поддерживающие PXE сетевые карты могут получать настройки по DHCP (используется протокол BOOTP) и использовать протокол TFTP для скачивания первичного загрузчика. Во время загрузки по сети экран рабочей станции может выглядеть, например, так:

../terminal_client_boot.png

Если загрузка прошла успешно, то на экране мы увидим приглашение XDM, ничем с первого взгляда не отличающееся от приглашения XDM на сервере. Однако, как мы понимаем, это результат взаимодействия программы xdm на сервере и программы X (X-сервера) на клиентской машине. Удаленный XDM знает о том, что к нему подключились по сети, и потому предложит другой состав меню.

На машине-сервере:

../terminal_server_login_options.png

На машине-клиенте:

../terminal_client_login_options.png

Итак, терминальный класс успешно функционирует. При этом, однако, мы должны решить следующие проблемы:

  • разделение ресурсов;
  • доступ к ресурсам.

Рассмотрим их подробнее.

Проблема разделения ресурсов

Эта проблема касается разделения ресурсов между пользователями. Если в нашем компьютерном классе используются 4 клиентских и одна серверная машина, то 4 одновременно работающих на одном сервере пользователя запускают, соответственно, 4 комплекта программного обеспечения. Если сервер по-прежнему один, а клиентов 24, то комплектов запущенного ПО будет тоже 24. Когда пользователи запускают N комплектов ПО, то они потребляют почти в N раз больше оперативной памяти, используют почти в N раз больше промежутков процессорного времени и генерируют N потоков обмена данными с дисковой подсистемой (по сравнению с одним комплектом ПО).

Практика эксплуатирования терминальных классов показывает, что для нормальной работы пользователей (открыт большой документ в OpenOffice.org, запущен Mozilla Firefox с несколькими вкладками) необходимы следующие объемы оперативной памяти: примерно 256 MB для нужд сервера, по 256 MB для каждого из примерно 8 клиентов и по 128 MB для каждого из клиентов, начиная с девятого (если всего их больше восьми). Экономия при большом количестве клиентов может достигаться, к примеру, за счет эффективного использования механизма разделения памяти. Заметим, что если использовать не KDE (или аналогичную по "тяжести" среду), а, скажем, XFCE, то на 8 клиентов вполне может хватить и 1 GB памяти.

Замеров загрузки CPU и обращений к диску при исследованиях не проводилось. Опыт, тем не менее, говорит, что вместо одного диска разумно использовать RAID-массив. Так или иначе, если в наличии имеется целый класс достаточно старых компьютеров и есть возможность купить хорошую современную машину "под сервер", то использование сетевой загрузки с "тонкими" клиентами является, безусловно, хорошим выбором.

Проблема доступа к ресурсам

На самом деле мы решили только часть поставленной ранее задачи. У нас корректно разделены запуск и выполнение задач, а также ввод-вывод, связанный с подсистемой X11 (сюда относится в том числе работа с клавиатурой и мышью). Задачи запускаются на машине-сервере, а ввод-вывод X11 осуществляется на рабочей станции. Но таким способом не решаются следующие проблемы:

  1. Работа с данными осуществляется на сервере, в то время как для работы со сменными носителями разумно использовать клиентские машины.
  2. Если запущенная программа, к примеру, проигрывает звук, то его вывод использует оборудование сервера.

Первую из указанных проблем можно решать по-разному. Первый вариант довольно прозаичен: по окончании работы все пользователи выстраиваются в очередь к администратору класса с флэшками. Это, если вдуматься, весьма разумное решение, особенно в случае учебного класса со строгой дисциплиной работы. Второй вариант использует проделанную создателями "Линукс Терминала" дополнительную работу. Рассмотрим эту возможность подробнее. Выведем список подмонтированных файловых систем:

$ 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)
/dev/hda5 on /var type ext3 (rw,nosuid)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
ltspfs on /home/user/Drives/floppy0/ type fuse (rw,nosuid,nodev,user=user)

Обратим внимание на последнюю строку. Она означает, что на сервере заранее произведено некое "волшебное" действие, которое "возвращает" имеющееся устройство обратно на рабочую станцию. В домашнем каталоге пользователя (который расположен, как и вся файловая система клиента, на сервере) есть подкаталог Drives, а в нем соответствующий подкаталог floppy0, который соответствует дискете, вставленной в машину-клиент.

../terminal_client_floppy_unmounted.png

На скриншоте видна иконка на панели с названием "отмонтированная дискета". Идея проста: устройство, подключенное к локальной машине (рабочей станции) хитрым способом (с помощью системы fuse --- filesystem in userspace) "прокидывается" на сервер. Именно информацию об этом пробросе и сообщила нам программа mount. Тем самым, когда какая-либо программа на сервере обращается к каталогу /home/user/Drives/floppy0, она в действительности заходит на нужную рабочую станцию в соответствующий каталог. Для нелюбознательного пользователя это выглядит точно так же, как работа с обычной машиной.

Таким же образом устроена и работа с CD/DVD-приводами. Функционирование ПО происходит на сервере, при этом диск с клиентской машины доступен с помощью такого же обратного проброса. Кликнем по соответствующей иконке и подмонтируем наш диск, выбрав пункт меню "Подключить":

../terminal_client_cd_mount.png

Посмотрим теперь на вывод программы mount:

$ 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)
/dev/hda5 on /var type ext3 (rw,nosuid)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
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)

Последние две строки говорят нам о том, что подключение прошло успешно. Изменилась и иконка на панели:

../terminal_client_cd_mounted.png

Кликнем по ней и выберем пункт меню "Открыть в новом окне":

../terminal_client_cd_open.png

Откроется окно с содержимым нашего DVD-диска:

../terminal_client_cd_browse.png

Подобным же образом (проброс сервиса) решается и вторая проблема, касающаяся звукового вывода. Здесь, однако, есть одна неприятная особенность: поскольку работа со звуковой подсистемой в разных видах Unix-систем устроена несколько различающимися способами, то далеко не все программы легко умеют работать с пробросом звука на рабочую станцию. Для тех программ, которые умеют в качестве выходного устройства использовать не конкретные файлы (/dev/dsp), а специальные звуковые подсистемы (иными словами, предоставляют пользователю возможность тонкой настройки), есть возможность использовать esd --- Enlightened Sound Daemon. Эта программа запускается на клиентской машине, принимает сетевые подключения по специальному протоколу и воспроизводит передаваемые ей аудиоданные. На сервере устанавливается переменная окружения ESPEAKER, которая указывает умеющим работать по этому протоколу программам, что для проигрывания звука надо использовать удаленный esd-сервер с заданным адресом. Все собранные с поддержкой библиотеки libesd программы работают именно так. Аналогичная схема используется и для программ, работающих со звуковой системой PulseAudio. Программы, использующие ALSA (Advanced Linux Sound Architecture), работают с помощью специального PulseAudio-плагина (plug-in) к ALSA. Лишь пишущие по старинке в /dev/dsp программы не могут быть настроены для работы по сети. Множество запущенных программ такого типа могут создать какофонию на звуковом устройстве сервера. Для устранения этой проблемы достаточно настроить сервер таким образом, чтобы устройство /dev/dsp в системе отсутствовало: вынуть (физически) звуковую карту, отключить (запретить) загрузку ее модуля ядра и т. п. Тогда можно будет эмулировать /dev/dsp пробрасываемыми по сети средствами.

Подведем итоги. Терминальный класс дает возможность:

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

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

  • Современные X Window System не работают с некоторыми устройствами, к примеру с S3Trio64.

  • Один пользователь не имеет возможности работать на двух рабочих станциях одновременно (различные запущенные в одно время сеансы работы должны использовать различные учетные записи).

Заметим, что на сегодняшний день только "Линукс Терминал" обеспечивает "из коробки" концепцию терминального класса и мобильного рабочего места. Достигается это при помощи личных учетных записей, хранящихся на сервере. Использовать чужие учетные записи пользователь не может, так как они защищены неизвестными ему паролями. Каждый пользователь при этом может сесть за любое свободное рабочее место и получить доступ к своей учетной записи, то есть к своему собственному персонализированному окружению. Управление учетными записями централизованно и абсолютно прозрачно (может производиться, к примеру, с помощью Alterator'а).


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

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

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

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

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

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

Level

Maintainer

Start date

End date

90

1

1

1

1

ArtemSerebriyskiy, DmitryChistikov, MaximByshevskiKonopko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080709/02TerminalClient (последним исправлял пользователь MaximByshevskiKonopko 2008-10-09 21:39:06)