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

Тайное знание

В X.org есть универсальный драйвер для устройств ввода evdev, который можно использовать, в том числе, для клавиатуры и мыши. Единственный недостаток evdev --- ему надо сказать, какой конкретно device-файл использовать, в отличие от mouse, для которого весь ввод сводится в device-файл /dev/mice. Так вот, для указаний девайса есть специальные симлинки в каталогах /dev/input/by-id и /dev/input/by-path.

Посмотрим, как эта проблема решается, пока что вручную, но более или менее однозначно. При этом по ссылке с именем --- текстовым идентификатором в /dev/input/by-id доступно само устройство, поэтому при подключении мыши к любому порту она будет работать.

Section "InputDevice"
    Identifier  "Mouse using evdev" # Произвольный идентификатор
    Driver      "evdev"
    Option      "Device" "/dev/input/by-id/usb-A4Tech_Ps.2+USB_Mouse-event-mouse" # Имя устройства, в /dev/input/by-id/ или в /dev/input/by-path/
EndSection

ALT Linux Terminal Server

Мы рассмотрим, как устроен дистрибутив ALT Linux Terminal Server (в дальнейшем ALTSP, ALT Linux Terminal Server Project).

Этот дистрибутив был разработан дополнительно к госзаказу (в рамках которого изготовлены Лёгкий Линукс, Линукс Юниор и Линукс Мастер). Над ним работала принципиально другая команда, из Киева, фактически ресурсы (деньги и, что более важно, людей) пришлось делить на большее количество работы. Дело в том, что команда, которая его разрабатывала, занималась внедрением подобных решений на разных предприятиях, и у них уже были наработки, пригодные для внедрения, правда, только авторами и только в благоприятной среде. Они воспользовались открывшимся ресурсом, чтобы доработать все это до дистрибутива, и, надо сказать, работы было много.

Что он себя представляет?

В документации по ALT Linux есть статья Георгия Курячего ("Linux-класс за час, или X-терминалы, тонкие и ленивые"), довольно старая, еще для ALT Linux Compact 3.0.

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

При начале работы с Live CD обычно создаётся очень небольшой виртуальный диск в оперативной памяти, доступный на запись, и второй виртуальный диск, большего размера и доступный только на чтение, состоящий из файлов, находящихся на компакт-диске. Работа с Live CD неудобна тем, что он довольно долго загружается и довольно медленно работает (скорость чтения данных с CD на один---два порядка ниже скорости чтения данных с жесткого диска, а скорость случайного позиционирования у CD ниже на три порядка). Это большой недостаток в случае полноценного использования такой операционной системы, с запуском большого количества программ. Существуют технологии оптимального размещения файлов на компакт-диске для ускорения работы такой системы, но значительного ускорения всё равно не происходит.

В настоящее время, по сравнению со статьей, которая была написана 2 года назад, существует чуть более правильный вариант --- тот же самый Live CD, только записанный на flash-носитель. По сравнению с Live CD существенно возрастает скорость чтения и исчезают затраты на позиционирование, т.к. flash-носитель --- это устройство прямого доступа (отсутствует понятие позиционирования). Кроме того, его можно так разметить, что часть его будет содержать основные файлы системы, как Live CD, а часть будет доступна для записи пользовательских данных. Такой вариант называется по аналогии --- Live Flash.

Недостаток Live Flash в том, что flash-носители быстро изнашиваются, особенно ограничен их ресурс на перезапись. В ALT Linux используется простейший способ построения Live Flash: образ существующего Live CD просто записывается на flash-носитель.

У обеих этих технологий (Live CD и Live Flash) на сегодняшний день есть существенный недостаток: содержимое системной области недоступно на запись, т.е. нельзя изменить состав установленных программ, и т.п. Теоретически, с помощью unionfs можно сконструировать файловую систему, которая будет поддерживать запись в системный раздел, но это приводит к другим проблемам. Одним словом, сбалансированного дистрибутива на базе Live Flash нет.

Ещё одна проблема в том, что существующий парк компьютерной техники может очень различаться по характеристикам и подходить не для всех видов программ и работ. Можно представить себе старый компьютер, на котором Live CD будет работать неприемлемо медленно и, возможно, нестабильно. Часто встречаются именно такие компьютеры, которые, с одной стороны, желательно задействовать в полезной работе, с другой стороны, даже при установке Linux на них, аппаратных ресурсов явно недостаточно для полезной работы. Такие компьютеры мы отнесём к классу машин, на которых нам желательно использовать Linux без установки его на жёсткий диск.

Хотя Live CD и Live Flash и позволяют не устанавливать Linux на жесткий диск, они рассчитаны на работу с достаточно мощными компьютерами, и на старых машинах от них будет немного пользы.

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

Толстый клиент

Идея состоит в следующем. Допустим, у нас есть достаточно новый компьютер, на который Linux можно и поставить, но нам не хочется нам этого делать, например, потому что там стоит купленная вместе с компьютером операционная система, от повреждения которой человек лишается гарантии, или за машиной работают другие пользователи, которые не захотят менять операционную систему. Либо еще одна ситуация: у нас есть операционная система, но компьютеров у нас 20 штук. И каждый раз, когда нам приходит в голову установить что-то или изменить настройку, необходимо будет менять что-то на всех компьютерах по отдельности, а это неудобно.

Было бы неплохо заставить все эти машины каким-то образом работать с одним и тем же системным пространством, условно говоря, диском. Диск им дать один на всех, какие-то мелкие различия, которые существуют, хранить можно и локально. В этом случае администрирование будет намного упрощено, мы просто будем содержимое общего диска модифицировать, в результате работа всех этих компьютером будет как-то изменяться. Например, мы можем установить пакет на этот диск, и любой из 20 компьютеров загрузится с использованием этого диска как системного и будет использовать этот пакет.

На эту тему тоже есть статья Георгия Курячего, которая была в докладе на тему толстых клиентов на конференции в Переславле (http://heap.altlinux.org/pereslavl2006/kouryachy/abstract.html).

В случае, когда мы не хотим устанавливать линукс на компьютере, но хотим его использовать, у нас есть следующие решения:

Вначале рассмотрим решения для новых компьютеров. Мы могли бы использовать livecd или liveflash, но есть дополнительные ограничения:

• мы не хотим мириться с тем, что livecd медленно работает и трудно организовать записываемую часть
• мы хотим изменять системную часть централизованно для многих компьютеров

Тогда можно поступить так. Жесткий диск, как в случае с livecd или liveflash, не используется вообще, а используется технология загрузки по сети. Есть специальные методы загрузить какую-то небольшую программу через сеть с сервера, которая загрузит большую программу, которая уже делает что-то полезное, например, ядро linux или initrd, который примонтирует сетевой диск.

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

Причём здесь возможна следующая ситуация: содержимое livecd перекладываете на сервер, а потом монтируется так же, как монтировалось бы при загрузке с него локально, с той лишь разницей, что во втором случае он будет смонтирован через NFS или другую распределенную файловую систему. Ещё один вариант, если у вас очень много памяти, можно положить образ на http. Клиент его скачает и будет хранить в оперативной памяти. Недостаток (помимо требуемого объема памяти) --- много качать при каждой загрузке. Естественно, при запуске программ с таким образом организованного толстого сервера новые копии их машинного кода в памяти не создаются.

Получается в результате компьютер, жёсткий диск которого вообще не используется, процедура загрузки сетевая, весь корпус программного обеспечения в виде сетевого носителя подключается с специально подготовленного сервера, как и вся процедура загрузки. Машина будет потреблять больше ресурсов, чем если бы Linux был установлен на ее жесткий диск, тем более, если вообще не использовать жесткий диск, то нельзя использовать swap (впрочем, swap на сетевом диске иногда используется, но это ненадежно).

Если мы скачали образ с сервера и разместили его целиком в оперативной памяти, то это, несмотря на то, что использует много памяти, дает также и преимущества:

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

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

Теперь перейдем к ситуации, когда компьютеры старые, и установка Linux на них хоть и возможна, но время установки и загрузки очень большое, да и крупные приложения работать будут очень медленно, засчёт слабого процессора и малого объема оперативной памяти.

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

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

При этом следует учитывать разницу в терминологии и помнить --- на терминальном сервере у нас работают программы --- X-клиенты, а на тонком терминальном клиенте запущен X-сервер.

Для построения такой системы используется та же программа, что и для локального графического входа в систему --- менеджер дисплеев X (X display manager), например kdm, входящий в состав окружения рабочего стола KDE. Происходит взаимодействие по следующей схеме:

Локальный вход

На компьютере 1 запущен X-сервер xorg0, работающий с мышкой и экраном, за которым сидит пользователь. К xorg0 как X-клиент подключен display manager xdm0, который может после авторизации пользователя запустить любое приложение, обычно некоторый менеджер окон или целое окружение рабочего стола, например, kde0, и передать ему свое соединение с xorg0.

Удаленный вход

Но пользователь может попросить xdm0 запросить сеть и найти там другой, проанонсированный display manager xdm1, находящийся на компьютере 2, чтобы xdm0 передал своё соединение с xorg0 ему. X-протокол позволяет сделать это по сети. Затем xdm1 может точно так же запустить kde1, уже на компьютере 2, и пользователь сможет с ним удалённо работать.

При такой организации на терминальном клиенте работает две программы: X-сервер Xorg и display manager. Остальные программы, которые выполняют пользовательские задачи, выполняются удаленно на терминальном сервере.

История проекта

Есть такой довольно давний проект --- LTSP (Linux Terminal Server Project. Без буквы A в начале). У него была довольно активная команда разработчиков, не то в Иркутске, не то в Новосибирске. Суть проекта состояла в том чтобы создать дистрибутив, использующий такую технологию (см. диаграмму), чтобы не нужно было руками все настраивать эти сервисы. Начинался этот LTSP ещё на ядре 2.2, то есть это было давно. Тогда задача могла быть решена только единственным способом: с одной стороны, нужно было собирать два разных ядра, одно для сервера, другое для клиента, причем для клиента оно должно было быть сильно изменено, чтобы происходило автоматическое определение железа и потом эту информацию об этом железе можно было передать на сервер. Еще нужно было организовать достаточно развесистую инфраструктуру по приёму этой информации, адаптации соответствующих настоечных файлов, и т.д.

Со временем выяснилось, что сильное изменение и перекомпиляция ядра не обязательны.

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

CategoryLectures CategoryPspo CategoryMpgu CategoryUneex