Различия между версиями 10 и 11
Версия 10 от 2008-07-12 12:04:08
Размер: 30186
Редактор: PavelSutyrin
Комментарий: вычитано до маркера
Версия 11 от 2008-07-12 12:06:53
Размер: 30159
Редактор: PavelSutyrin
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 15: Строка 15:
например перемещение, его протокол можно распознать автоматически.  например перемещение, его протокол можно распознать автоматически.
Строка 19: Строка 19:
те, что кроме стандартных трёх. 
Единственный недостаток evdev --- ему надо сказать, куда смотреть, какой девайс. 
те, что кроме стандартных трёх.
Единственный недостаток evdev --- ему надо сказать, куда смотреть, какой девайс.
Строка 48: Строка 48:
Мы рассмотрим, как устроен дистрибутив ALT Linux Terminal Server, ALTSP.  Мы рассмотрим, как устроен дистрибутив ALT Linux Terminal Server, ALTSP.
Строка 56: Строка 56:
доработать все это до дистрибутива, и надо сказать, работы было много.  доработать все это до дистрибутива, и надо сказать, работы было много.
Строка 68: Строка 68:
а основные ресурсы находятся на компакт-диске. и начинается работа.  а основные ресурсы находятся на компакт-диске. и начинается работа.
Строка 76: Строка 76:
случайного позиционирования у cd больше аж на три порядка).  случайного позиционирования у cd больше аж на три порядка).
Строка 79: Строка 79:
с запуском большого количества программ.  с запуском большого количества программ.
Строка 82: Строка 82:
работы такой системы, но значительного ускорения не происходит. 

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

В настоящее время, по сравнению со статьей, которая была написана 2 года назад,
Строка 87: Строка 87:
затраты на позиционирование, т.к. flash-носитель --- это устройство прямого доступа,  затраты на позиционирование, т.к. flash-носитель --- это устройство прямого доступа,
Строка 89: Строка 89:
доступна для записи пользовательских данных. Такой вариант называется по аналогии --- liveflash. 

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

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

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

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

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

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

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

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

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

У этой проблемы есть решение, но прежде рассмотрим другую технологию,
Строка 120: Строка 120:
=== Толстый клиент ===  === Толстый клиент ===

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

Разное интересное перед лекцией

(Про fontconfig и перемещаемые профили)

Относительно мыши. Есть тайное знание. Есть драйвер evdev в X.org, который, вообще говоря... Вот вы покупаете мышь. У этой мыши 8 кнопок, два колеса и мохнатые уши. Драйвер evdev устроен принципиально не так, как драйвер mouse, kbd, т.к. он умеет и клавиатуру хватать. Он по поведению устройства пытается определить, что это за устройство, более того, он ходит по идентификаторам разным, ведь для usb-устройства можно получить его текстовый id. И если это мышь, то некоторые вещи у них более или менее стандартные, например перемещение, его протокол можно распознать автоматически. Дальше начинается распознавание, вы нажали на какую-то кнопку, это будет кнопка номер 1, нажали на другую, другое событие пришло, значит это будет кнопка номер 2, и так все 8 кнопок, точнее те, что кроме стандартных трёх. Единственный недостаток evdev --- ему надо сказать, куда смотреть, какой девайс. Раньше проблему с устройствами решали по-другому, на уровне системы. Раньше весь input сваливали /dev/mice, дальше говорили -- у меня драйвер mouse, все остальное автоматически, работайте, иксы. Там не распознавалась ни одна кнопка. А здесь это делается независимо от системы, т.к. он садится на какой-то девайс потом с ним работает. А в случае с evdev'ом и многозадачным линуксом проблема в том, что неизвестно, какой номер usb-девайса будет у мыши, когда вы ее воткнёте, точнее, когда он ее определит. Но спасибо добрым линуксостроителям за скажем ls /dev/input/by-id.

Посмотрим /etc/X11/xorg.conf, как эта проблема решается, пока что вручную, но более или менее однозначно. При этом текстовый идентификатор возвращает само устройство, поэтому при подключении к любому порту все будет работать.

  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 неудобна тем, что он довольно долго загружается и довольно долго работает (скорость чтения данных с 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 компьютерах, оно нам в голову приходит, потом мы представляем, что нам 20 раз делать одно и то же, и как-то вот оно и выходит из головы.

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

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

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

наши компьютеры

локальные linux-решения

сетевые linux-решения

новые

livecd или liveflash

толстые клиенты с загрузкой всего и вся на них по сети

старые (немощные)

?

тонкие клиенты

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

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

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

Есть специальные методы загрузить какую-то небольшую программу через сеть с сервера, которая загрузит большую программу, которая уже всё делает (она, собственно может являться ядром линукс, или, в нашем случае, небольшим дистрибутивом initrd).

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

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

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

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

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

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

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

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

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

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

клиент

ввод-вывод

задачи

файлы

толстый

станция

станция

сервер

тонкий

станция

сервер

сервер

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

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

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

../thin_client.png

На компьютере 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, то есть это было давно. И в те поры ничего, кроме как вносить собственные изменения в ядро, чтобы кое-что там автоматически определялось, и т.д., а с другой стороны выкладывать в качестве специализированного образа...

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

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


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

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

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

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

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

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

Level

Maintainer

Start date

End date

30

1

1

1

1

PavelSutyrin, VladimirLysikov


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080709/01TerminalTheory (последним исправлял пользователь MaximByshevskiKonopko 2008-10-09 21:35:34)