НЛТСС

Сетевая ливерморская система разделения времени (NLTSS)

Разработчик	Ливерморская лаборатория Лоуренса
Написано в	Модель ( расширение Паскаля )
Семейство ОС	основанный на возможностях
Рабочее состояние	Снято с производства
Исходная модель	Закрытый исходный код
Первоначальный выпуск	1979 год ( 1979 )
Финальный выпуск	Финал / 1988 год ( 1988 )
Маркетинговая цель	Суперкомпьютеры
Доступно в	Английский
Обновить метод	Скомпилировать из исходного кода
Платформы	CDC 7600 , Cray-1 , Cray X-MP , Cray Y-MP
ядра Тип	Микроядро
Лицензия	Собственный

Сетевая Ливерморская система разделения времени ( NLTSS , также иногда Новая Ливерморская система разделения времени ) — операционная система , которая активно разрабатывалась в Ливерморской лаборатории Лоуренса (ныне Ливерморская национальная лаборатория Лоуренса ) с 1979 по 1988 год, хотя она продолжала запускать производственные приложения до 1995. Более ранняя система, Ливерморская система разделения времени, была разработана более десяти лет назад.

Первоначально NLTSS работал на компьютере CDC 7600 , но производился только с 1985 по 1994 год на компьютерах Cray , включая модели Cray-1 , Cray X-MP и Cray Y-MP .

Характеристики

Операционная система NLTSS была во многих отношениях необычной, а в некоторых — уникальной.

Низкоуровневая архитектура

NLTSS представлял собой на основе микроядра систему передачи сообщений . Он был уникален тем, что ядром системы поддерживался только один системный вызов. Этот системный вызов, который можно было бы назвать «общаться» (у него не было имени, поскольку его не нужно было отличать от других системных вызовов), принимал список «буферных таблиц» (например, см. Интерфейс системы сообщений NLTSS). ) который содержал управляющую информацию для передачи сообщений – либо отправляет, либо получает. Такое общение, как локально внутри системы, так и по сети, было всем ядром системы, поддерживаемым непосредственно для пользовательских процессов . «Система сообщений» (поддерживающая один вызов и сетевые протоколы ) и драйверы для дисков и процессора составляли все ядро ​​системы.

Архитектура среднего уровня

NLTSS — это система безопасности, основанная на возможностях клиент-серверная . Двумя основными серверами являются файловый сервер и сервер обработки. Файловый сервер представлял собой процесс, которому доверяли драйверы локального хранилища (дисковое хранилище), а сервер процессов представлял собой процесс, которому доверял драйвер процессора (программное обеспечение, которое переключало управление разделением времени между процессами в «генераторе переменного тока»). , обрабатывал прерывания для процессов помимо вызова «коммуникации», обеспечивал доступ к памяти и состоянию процесса для сервера процессов и т. д.).

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

Для связи между процессами в NLTSS по соглашению использовался набор протоколов Livermore Interactive Network Communication System (LINCS), который определял стек протоколов в соответствии с тем, что определено эталонной моделью OSI . Протокол транспортного уровня для NLTSS и LINCS получил название Delta-T . На уровне представления LINCS определил стандарты для передачи нумерованных параметров в виде токенов (например, целых чисел, возможностей и т. д.), которые хранились в записи уровня сеанса для обработки в удаленного вызова процедур механизме типа .

Понятие « пользователь » было определено в NLTSS лишь второстепенно. Существовал «сервер учетных записей», который отслеживал, какие пользователи какие ресурсы использовали (например, запросы на создание таких объектов, как файлы или процессы, требовали такой возможности учетной записи). Контроль доступа полностью управлялся с помощью возможностей (передаваемых токенов полномочий).

Файловый сервер

Любой процесс мог отправлять запросы файловому серверу на создание файлов (возвращая возможность файла ), запрашивать чтение или запись файлов (путем предоставления возможности файла) и т. д. Например, для чтения файла обычно требовалось три буфера. таблицы: одна для отправки запроса на файловый сервер, одна для получения ответа от файлового сервера и одна для получения данных из файла. Эти три запроса обычно отправлялись в систему сообщений одновременно, иногда вместе с другими запросами. Биты управления можно было установить в таблицах буферов для пробуждения (разблокировки) процесса всякий раз, когда какая-либо из представленных таблиц буферов была помечена как «Готово». Вызов библиотеки для чтения файла обычно блокируется до тех пор, пока не будет получен управляющий ответ от файлового сервера, хотя асинхронный ввод-вывод, конечно, не блокируется и может проверить или заблокировать позже. Любые подобные различия на стороне пользователя были невидимы для файлового сервера.

Сервер обработки

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

Сервер каталогов

Примером сервера более высокого уровня в NLTSS был сервер каталогов. Задачей этого сервера было, по сути, превратить файлы (невидимые для пользователя) в каталоги, которые можно было использовать для хранения и извлечения возможностей по имени. Поскольку возможности представляли собой просто данные, это не было особенно сложной задачей, состоящей в основном из управления разрешениями на доступ к возможностям в соответствии с соглашениями, определенными в наборе протоколов LINCS. Один момент, где это стало немного интересным, касался разрешения доступа, называемого наследованием . Если этот бит был включен (разрешен), то возможности можно было получить с полным доступом из каталога. Если этот бит был отключен (запрещен), то любые разрешения, отключенные в возможности каталога, в свою очередь, были отключены в возможности, извлекаемой до того, как она была возвращена запрашивающему приложению. Этот механизм позволял людям хранить, например, файлы для чтения и записи в каталоге, но давал другим пользователям только разрешение на получение их экземпляров, доступных только для чтения.

Разработка

Основная часть программирования для NLTSS была выполнена в расширении Pascal , разработанном в Национальной лаборатории Лос-Аламоса и известном как «Модель». Модель расширила Паскаль, включив в него механизм абстрактного типа данных (объекта) и некоторые другие функции.

NLTSS был обременен наследием совместимости. NLTSS последовал за разработкой и внедрением Ливерморской системы разделения времени (LTSS) в Ливерморском компьютерном центре в LLNL (~ 1968–1988?). Разработка NLTSS началась примерно в то же время, когда LTSS был перенесен на Cray-1 и стал системой разделения времени Cray . Чтобы оставаться обратно совместимым со многими научными приложениями в LLNL, NLTSS был вынужден эмулировать системные вызовы предыдущей операционной системы LTSS. Эта эмуляция была реализована в виде библиотеки совместимости под названием «baselib». В качестве примера: хотя структура каталогов и, следовательно, структура процессов для NLTSS, естественно, представляла собой ориентированный граф (возможности процесса могли храниться в каталогах точно так же, как возможности файлов или возможности каталогов), библиотека baselib эмулировала простой линейный процесс (контроллер-контролируемый). структуру (даже не древовидную структуру , как в Unix ), чтобы оставаться совместимой с предыдущей версией LTSS. Поскольку научные пользователи никогда не обращались к сервисам NLTSS за пределами библиотеки baselib, NLTSS в конечном итоге выглядел для своих пользователей почти точно так же, как LTSS. Большинство пользователей не знали о возможностях, не осознавали, что они могут получить доступ к ресурсам в сети, и, как правило, не знали, что NLTSS предлагает какие-либо услуги, помимо услуг LTSS. НЛТСС поддержал с общей памятью Симметричная многопроцессорная обработка — разработка, которая шла параллельно аналогичной разработке в системе разделения времени Cray .

Даже название NLTSS было своего рода наследием. Название «Новая Ливерморская система разделения времени» изначально считалось временным названием, которое можно было использовать во время разработки. Как только система начала запускать некоторые приложения в двухсистемном режиме (что-то вроде виртуальной машины, более постоянное имя — LIncs Network Operating System разделяющей драйверы с LTSS), разработчики выбрали (LINOS). К сожалению, руководство LLNL решило, что название не может быть изменено на этом этапе (по-видимому, потому, что предыдущий термин использовался в бюджетных запросах), поэтому временное имя NLTSS для разработки оставалось в системе на протяжении всего ее срока службы.

Параллельно с NLTSS была также разработана система хранения данных , которая использовала протоколы LINCS (те же протоколы файлов и каталогов, что и NLTSS). Эта система/программное обеспечение позже было коммерциализировано как продукт Unitree. На смену Unitree пришла высокопроизводительная система хранения данных (HPSS), которую можно было бы условно считать наследием LINCS и NLTSS. Например, LINCS и NLTSS представили форму передачи данных третьей стороне (чтобы скопировать файл в файл в NLTSS, процесс мог отправить два запроса на файловые серверы: один на чтение и один на запись, и направить файловые серверы на передачу данных между собой). это было перенесено в измененной форме на Unitree и HPSS.

Проблемы реализации и дизайна

Самым большим ударом по NLTSS за время его производства была производительность. Единственной проблемой производительности, которая больше всего затрагивала пользователей, была задержка доступа к файлам . Обычно это не представляло серьезной проблемы для дискового ввода-вывода (I/O), но системы, на которых работал NLTSS, также поддерживали значительный набор твердотельных дисков с очень низкой задержкой и временем доступа менее 10 микросекунд. Начальные задержки файловых операций при NLTSS были сопоставимы с задержкой доступа к твердотельному диску и значительно превышали задержку LTSS такого доступа. Чтобы уменьшить задержку доступа к файлам при NLTSS, реализация была значительно изменена, чтобы поместить наиболее чувствительные к задержке процессы (в частности, файловый сервер) «в ядро». Эти усилия были не такими значительными, как может показаться на первый взгляд, поскольку все серверы NLTSS работали по многопоточной модели. На самом деле это изменение заключалось в перемещении потоков, отвечающих за службы файлового сервера, из отдельного процесса файлового сервера в «процесс» ядра. Связь с пользователями не изменилась (по-прежнему через буферные таблицы, токены LINCS и т. д.), но файловые операции избежали некоторых существенных изменений контекста, которые были основной причиной более высоких задержек по сравнению с более старыми LTSS и конкурирующими системами. Предусмотрена система разделения времени Cray . Это изменение значительно (~3 раза) уменьшило задержку операций файлового ввода-вывода, но это также означало, что файловый сервер стал доверенной частью ядра (по реализации, а не по замыслу).

Вторая проблема реализации NLTSS связана с безопасностью/целостностью его возможностей реализации данных. В этой реализации использовалась модель возможности пароля (например, см. «Управление с помощью пароля»). В рамках этой модели любой человек или процесс, который может получить доступ к пространству памяти процесса, будет иметь право доступа к возможностям, представленным данными, найденными в этой памяти. Некоторые системные архитекторы (например, Эндрю С. Таненбаум , архитектор распределенной операционной системы Amoeba ) предположили, что это свойство доступа к памяти, подразумевающее доступ к возможностям, не является внутренней проблемой. В среде NLTSS иногда случалось, что люди отдавали дампы памяти программ другим на анализ. Из-за этой и других проблем такие возможности пароля считались уязвимостью в NLTSS. Для защиты от этой уязвимости была разработана конструкция «Контроль с помощью шифрования с открытым ключом». механизм. Этот механизм не был запущен в производство в NLTSS как из-за его значительных затрат на производительность, так и из-за того, что пользователи не знали об уязвимости, связанной с возможностями пароля. Современные достижения в криптографии сделают такую ​​защиту возможностей практичной, особенно для возможностей Интернета/Веб (например, см. YURLs). или WideWORD).

Проблема проектирования NLTSS, которая не рассматривалась до тех пор, пока она не была снята с производства, заключалась в ее открытой сетевой архитектуре. В NLTSS процессы рассматривались как виртуальные процессоры в сети без брандмауэров или других ограничений. Любой процесс может свободно взаимодействовать с любым другим. Это означало, что было невозможно обеспечить изоляцию даже в смысле ограничения прямого общения, например, по сравнению с ограничением скрытых каналов, таких как «стук в стену». Чтобы исправить эту проблему, NLTSS должен будет потребовать возможности обеспечения связи. Поздние разработки NLTSS, такие как «номера потоков», приближались к такой возможности, но к моменту прекращения активной разработки в 1988 году связь в NLTSS все еще не была ограничена.

См. также

• Ливерморская система разделения времени

Дальнейшее чтение

• Дж. Э. Доннелли, Компоненты сетевой операционной системы , Четвертая конференция по локальным сетям, Миннеаполис, 1979. Также в Computer Networks 3 (1979) 389–399.
• Дж. Э. Доннелли, Управление доменами в сетевой операционной системе , Материалы конференции по локальным сетям и распределенным офисным системам, Лондон, май 1981 г., стр. 345–361.
• С. Т. Брюггер, М. Ганди и Г. Стрелец, Ливерморская сетевая система разделения времени (NLTSS) , 2001 г.

Внешние ссылки

• Вычисление возможностей в LLNL. Обсуждение истории использования возможностей в вычислениях в LLNL, включая краткое упоминание системы RATS и того, как ее развитие привело к NLTSS.
• Истории развития крупномасштабных научных вычислений в Ливерморской национальной лаборатории имени Лоуренса
• Хроники NLTSS Мультфильмы о разработке NLTSS и LINCS