PspoClasses/080709/01TerminalTheory

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

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

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

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

  Section "InputDevice"
        Identifier      ...
  Driver             "evdev"
  Option             "Device"
        "/dev/input/by-id/usb-A4Tech_Ps.2+USB_Mouse-event-mouse"
EndSection 

ALT Linux Terminal Server

Мы рассмотрим, как устроен дистрибутив ALT Linux Terminal Server, ALTSP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На эту тему тоже есть статья Георгия Курячего, которая была в докладе на тему толстых клиентов на конференции в Переславле.

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

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

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

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

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

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

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

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

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

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

Вычитано до этого места -- VladimirLysikov 2008-07-14 19:21:36

Теперь мы переходим на этаж ниже в таблице, и находим там старые компьютеры, установка линукс на которые возможна была бы, если бы ни одно прискорбное но, мы туда поставим линукс, мы там сможем, наверное, поставить, но ставится он будет долго и работать слабо. Что запустишь на компьютере с 64 MB RAM?..

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

(Я где-то читал одним глазом, что в случае, когда клиент и сервер оба на одной машине, они не обязательно будут все гонять по TCP-сокетам, а найдут друг друга и воспользуются, например, shared memory. --PavelSutyrin)

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

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

Какие нас ждут неприятности? По сути никаких. В той же статье про тонкие клиенты лектор показывал, как одной командой из n+1 livecd делать сеть из n клиентов и 1 сервера. Нужно чтобы сервер разрешал подсоединяться к ему по сети и использовать его программы, клиент --- разрешал подсоединяться к его X-серверу и работать с устройствами ввода-вывода. Это сделать легко.

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

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

Тут может быть ещё отдельный сервер приложений, который об этом говорит. Мы получили, что на работающей станции работает две программы: Xorg и XDM. Результатом становится то, что в табличке: все задачи запускаются не на рабочей станции (компьютер 1), а на сервере (компьютер 2).

starvm altsp...

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

Начинался этот LTSP ещё на ядре 2.2, то есть это было давно. И в те поры ничего, кроме как вносить собственные изменения в ядро, чтобы кое-что там автоматически определялось, и т.д., а с другой стороны выкладывать в качестве специализированного образа...

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

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

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

CategoryLectures CategoryPspo CategoryMpgu CategoryUneex