Каталог статей
Сетевая организация многозадачных ОС на примере операционной системы Plan 9
Сетевая организация многозадачных ОС на примере операционной системы Plan 9
Введение
За последние 10 лет в нашей стране произошел качественный скачок в развитии информационных технологий. Изначально ПК был предусмотрен именно как машина для персонального использования с собственным автономным хранилищем для информации. Поэтому при работе над каким-либо коллективным проектом программы данные передавались между отдельными компьютерами с помощью внешних носителей (дискеты, накопители на магнитной ленте и т.д.).
Сейчас, с развитием компьютерной техники объемы разрабатываемых и используемых в процессе работы программных продуктов возросли. Соответственно увеличилось и количество программистов, задействованных в каждом отдельном проекте. Также эти коллективы могли быть распределены географически на достаточно большом расстоянии друг от друга. Все это в целом привело необходимости создания эффективного способа взаимодействия между отдельными компьютерами.
Конструкция персонального компьютера предусматривает наличие последовательного коммуникационного порта, который возможно использовать для связи двух ЭВМ. Как развитие этой технологии возникла идея локально вычислительной сети (ЛВС). В простейшем варианте ЛВС – это провод, к которому параллельно посредством специальных разъемов подключаются отдельные компьютеры, называемые в этом случае рабочими станциями. Первые сети строились на основе стандартных коммуникационных портов, однако скорости обмена данных через это устройство были слишком малы. Для устранения этой проблемы были созданы специальные сетевые платы со своим разъемом, которые позволяли довести скорость передачи данных до скоростей внутренней шины компьютера.
Сети играют важнейшую роль в любой распределенной системе. В данной статье раскрываются реализация, проектная философия и организация сетевой поддержки в операционной системе Plan 9. Тема включает сетевые требования для распределенных систем, реализацию ядра, сетевое присваивание имен, пользовательские интерфейсы и эффективность.
Plan 9 от Bell Labs
Plan 9 [1] — независимая операционная система, изобретённая Bell Labs. Она написана с нуля и не включает исходный код сторонних разработчиков. Интерфейс приложений этой операционной системы схож с интерфейсом Unix, но Plan 9 — не альтернатива и не замена Unix, это новый проект со своей конструкцией, идеями и применением. Новизна системы Plan 9 лежит в частях, находящихся за пределами ядра, и способе их взаимодействия.
Система Plan 9 состоит из файловых серверов, CPU серверов и терминалов. Файловыми и CPU серверами обычно являются централизованные многопроцессорные машины с большим количеством памяти и высокоскоростными взаимосвязями. Различные машины класса рабочих станций служат терминалами, соединенными с центральными серверами посредством нескольких сетей и протоколов. Соединения между файловыми и CPU серверами — волоконные связи точка-точка, обладающие высокой пропускной способностью. Соединения от серверов развертываются к локальным терминалам с использованием сетей средней скорости, наподобие Ethernet и Datakit [3].
У пользователей всегда есть выбор: запускать программы локально на своих терминалах или удаленно на CPU серверах, потому что CPU серверы и терминалы используют одно и то же ядро. На работе пользователи используют свои терминалы как рабочие станции, запуская интерактивные программы локально и резервируя CPU серверы для заданий интенсивной обработки данных. Дома или при соединении через медленную сеть, пользователи для снижения траффика выполняют большую часть работы на CPU сервере. Задача сетевой организации в Plan 9 состоит в обеспечении одинаковой среды для пользователей независимо от используемых ресурсов.
Сетевая поддержка в ядре ОС Plan 9
Изначально ОС Plan 9 разрабатывалась как сетевая операционная система. Также, её концепции имеют отношение больше к организации сети, чем к потребностям индивидуального пользователя. Её характеристики определяют пути, которыми она оперирует сетью.
Система Plan 9 основана на концепции распределенного вычисления в сетевой, клиент-серверной среде. Набор ресурсов, доступных приложениям, прозрачно доступен всюду в распределенной системе, так что не важно, где приложения фактически выполняются. Основным принципом Plan 9 является представление ресурсов в виде иерархической файловой системы.
Сетевой код ОС Plan 9 имеет очень сложную структуру и его доля по отношению к полноразмерному коду постоянно растёт: из 25 тысяч строк кода ядра 12,5 приходится именно на сеть. Большинство ресурсов организованы во внешние по отношению к ядру серверы. На сегодняшний день ядро имеет поддержку Datakit, волоконных связей типа точка-точка, Internet протокола и ISDN.
Сетевой код ядра разделен на 3 слоя:
• аппаратный интерфейс
• обработка протокола
• программный интерфейс.
Драйвер устройства обычно использует потоки для соединения двух интерфейсных слоев. Для обработки протоколов, модули дополнительного потока могут выталкиваться в устройстве. Каждый драйвер устройства является ядро-резидентной файловой системой. Простые драйверы устройств подаются в виде одноуровневого каталога, содержащего всего несколько файлов; например, мы представляем каждое UART устройство файлами данных и управления. Связь между ядром, драйверами устройств и локальными или удаленными файловыми системами обеспечивает протокол под названием 9P.
Сетевые соединения представлены как псевдо-устройства, которые называются устройствами протокола. Драйверы устройств присутствуют для протокола Datakit URP и каждого из Internet IP протоков TCP, UDP, и IL. IL, описанный ниже, является новым протоколом связи и используется в Plan 9 для передачи удаленных процедурных вызовов файловой системы. Все драйверы протокола выглядят одинаково, так что пользовательские программы не содержат специфического для сети кода.
Поток [4] — это двунаправленный канал, соединяющий физическое или псевдо-устройство с пользовательскими процессами. Пользовательские процессы вставляют и удаляют данные из одного конца потока. Ядро обрабатывает действие на стороне устройства, вставляя данные в другой конец. С использованием потоков реализованы асинхронные каналы связи типа каналов, обмены информацией TCP, Datakit, и линии RS232 [5].
Поток включает линейный список обрабатывающих модулей. Каждый модуль имеет две подпрограммы вставки (называемые также put-процедурами): поток-вверх (по отношению к процессу) и поток-вниз (по отношению к устройству). Вызов подпрограммы вставки модуля на любом конце вставляет данные в поток. Каждый модуль вызывает последующую отправку данных вверх или вниз в поток.
Сетевая адресация. Сетевой протокол IL.
Из-за невозможности передачи сообщений 9P через сети Ethernet или Internet по стандартным IP-протоколам был разработан новый протокол IL [6]. Он основан на соединениях и обеспечивает надежную передачу упорядоченных сообщений. Поскольку протокол предназначен для передачи сообщений RPC между клиентом и сервером, то отпадает необходимость в средствах управления потоками. В отличие от других протоколов, IL избегает слепые повторные передачи, таким образом не происходит продублирование сообщений. Подобно TCP, IL имеет адаптивные тайм-ауты, в результате чего протокол работает одинаково хорошо как в Internet, так и в Ethernet. Код протокола почти в два раза короче, чем в случае с TCP.
Во многих операционных системах сетевая информация хранятся в виде нескольких файлов наподобие /etc/hosts, /etc/networks. Большую часть времени и ресурсов затрачивается на администрирование этих файлов и поддержку их взаимной последовательности. Программные средства пытаются автоматически создать один или более файлов из информации других файлов, но эксплуатация продолжает усложняться и иметь склонность к ошибкам.
В связи с тем, что Plan 9 была написана с нуля, в ней был использован новый, более простой метод. Одна база данных на распределенном сервере содержит всю информацию, требуемую для сетевого администрирования. Два текстовых файла включают основную базу данных: один содержит локально управляемую информацию, а другой содержит информацию, импортируемую из других мест. Файлы содержат комплекты пар атрибут/значение. Системы описаны многострочными записями, строка-заголовок в левом поле начинает каждую запись предваренными нулем или более отступов парами атрибут/значение, которые определяют имена, адреса и свойства.
Взамен деления записи вроде сетевой маски и шлюза, Plan 9 определяет эту информацию с сетью или подсетью. Записи базы данных также описывают отображение сервисных имен в номера портов для TCP, UDP и IL.
В каждой системе сервер соединений пользовательского уровня, CS, преобразует символические имена в адреса. Для преобразования имен, CS использует информацию о доступных сетях, сетевой базе данных и других серверах (например DNS). CS — это файловый сервер, обслуживающий файл /net/cs. Клиент записывает символическое имя в этот файл, затем читает одну строку для каждого соответствующего места назначения, достижимого из этой системы. Строки представляют собой форму «имя_файла сообщение», где «имя файла» — это путь открываемого аналогичного файла для нового соединения и сообщение — это строка, запись который приводит к созданию соединения.
Обычно CS получает информацию именования из файлов своей базы данных. Тем не менее для доменных имен CS сначала обращаться к другому процессу пользовательского уровня, серверу доменных имен (DNS). Если нет DNS, то CS полагается на свои собственные таблицы.
Сетевая организация на пользовательском уровне.
Протокол 9Р посредством терминов обеспечивает связь между машинами в ОС Plan 9. При этом используется два сервиса: cpu и exportfs [7]. Сpu создает процесс на удаленной машине, чье пространство имен эквивалентно пространству имен окна, в котором он был вызван. Exportfs — это сервер пользовательского уровня, который позволяет экспорт пространства имен из машины к машине через сеть, он используется командой cpu для обслуживания файлов в пространстве имен терминала, когда они доступны из CPU сервера. По соглашению, файловые системы протокола и драйверов устройств монтируются в каталог /net. Хотя пространство имен процесса позволяет пользователям конфигурировать произвольный вид системы, на практике их профайлы формируют стандартное пространство имен.
Exportfs запускается входящим сетевым вызовом. Слушатель перед запуском запускает профайл пользователя, запрашивающего сервис для создания пространства имен. После того как начальный протокол установил корень экспортируемого файлового дерева, удаленный процесс монтирует соединение, позволяя exportfs действовать в роли главного файлового сервера. Операции в импортируемом файловом дереве выполняются на удаленном сервере с возвращением результатов. Вследствие чего пространство имен удаленной машины экспортируется в локальное файловое дерево. Команда import вызывает exportfs на удаленной машине, монтирует результат в локальное пространство имен и завершает работу. Для обслуживания монтирований не требуется локальный процесс; сообщения 9P генерируются драйвером монтирования ядра и отправляются непосредственно через сеть.
Разработчиками Plan 9 было решено реализовать интерфейс протокола FTP в виде файловой системы, а не традиционной команды. Ftpfs подключается к FTP порту удаленной системы, запрашивает логин и пароль, устанавливает образный режим и монтирует удаленную файловую систему в /n/ftp. Для уменьшения траффика, файлы и каталоги поддаются кешированию. Кеш обновляется всякий раз, когда создается файл.
Заключение.
Представление всех сетевых ресурсов Plan 9 в виде файловых систем в связке с ASCII интерфейсом оказалось мощной инновацией. Ресурсы могут использоваться любым компьютером в сетях независимо от порядка байт или типа процессора. Сервер соединений обеспечивает изящные решения использования несвязанных средств в сетях. Пользователи успешно используют Plan 9 без знания топологии системы или сетей, используемых ими. Более подробная информация о 9P может быть найдено в разделе 5 руководства программиста Plan 9, первый том [8].
Источники
[1] Plan 9 from Bell Labs, http://plan9.bell-labs.com/plan9/about.html
[2] Glenda, the Plan 9 Bunny, http://plan9.bell-labs.com/plan9/glenda.html
[3] Introduction to the Plan 9 File Protocol, 9P, http://man.cat-v.org/plan_9/5/intro
[4] The Organization of Networks in Plan 9, http://doc.cat-v.org/plan_9/4th_edition/papers/net/
[5] Christopher E. Strangio “The EIA232 Standart”, http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html
[6] Dave Presotto «The IL protocol», http://doc.cat-v.org/plan_9/4th_edition/papers/il/
[7] Russ Cox и др. «Безопасность в Plan 9» http://ru.inferno-os.wikia.com/wiki/Безопасность_в_Plan_9
[8] Howard Trikey, Plan 9 Programmer's Manual, Volume1, АТ&Т Bell Laboratories, Murray Hill, NJ, 1991.
|
| Категория: Мои статьи | Добавил: Zaikin_Volodya (01.12.2011)
| Автор: Владимир Заикин E
|
| Просмотров: 1442 | Комментарии: 4
| Рейтинг: 0.0/0 |
|
|
|
