NLTSS
Supercomputer operating system
Operating system
ネットワークリバモアタイムシェアリングシステム（NLTSS）
開発者ローレンス・リバモア研究所
書かれたモデル（Pascal拡張）
OSファミリー能力ベース
作業状態製造中止
ソースモデルクローズドソース
初回リリース1979年; 46年前 (1979)
最終リリース最終回 / 1995年; 30年前 (1995)
マーケティングターゲットスーパーコンピュータ
入手可能な英語
更新方法ソースコードからコンパイルする
サポートされているプラ​​ットフォームCDC 7600、Cray-1、Cray X-MP、Cray Y-MP
カーネルタイプマイクロカーネル
ライセンス独自の

ネットワークリバモア タイムシェアリング システム( NLTSS、時にはNew Livermore Time Sharing Systemとも呼ばれ、内部的にはLINOS ( LINCS Interactive Network Operating System ) とも呼ばれる) は、ローレンス リバモア研究所 (LLL) (現在のローレンス リバモア国立研究所、LLNL) で 1979 年から 1988 年頃まで積極的に開発されていたオペレーティングシステムであり、1995 年まで実稼働アプリケーションの実行とサポートが継続され、場合によっては拡張も行われました。以前のオペレーティング システムであるリバモア タイムシェアリング システムは、 10 年以上前に LLL で開発されていました。

NLTSS は当初CDC 7600コンピュータ上で実行されていましたが、1984 年頃から 1995 年までの間、Cray-1、Cray X-MP、Cray Y-MPモデルなどのCrayコンピュータ上でのみ実稼働されていました。

特徴

NLTSS オペレーティング システムは、多くの点で異例であり、いくつかの点ではユニークでした。

低レベルアーキテクチャ

NLTSSはマイクロカーネルの メッセージパッシングシステムでした。システムのカーネルがサポートするシステムコールが1つだけという点で、NLTSSは独特でした。このシステムコールは「communicate」（他のシステムコールと区別する必要がないため、名前はありませんでした）と呼ばれていましたが、メッセージ通信（送信または受信）の制御情報を含む「バッファテーブル」（例えば、「NLTSSメッセージシステムインターフェース」を参照）[1]のリストを受け取りました。システム内ローカルおよびネットワーク経由の両方におけるこのような通信は、システムカーネルがユーザープロセスに対して直接サポートするすべてでした。「メッセージシステム」（1つのシステムコールとネットワークプロトコルをサポート）と、ディスクおよびプロセッサ用のドライバが、システムのカーネル全体を構成していました。

中レベルアーキテクチャ

NLTSSは、機能ベースのセキュリティ クライアントサーバーシステムです。2つの主要なサーバーは、ファイルサーバーとプロセスサーバーです。ファイルサーバーは、ローカルストレージ（ディスクストレージ）のドライバーによって信頼される特権を持つプロセスであり、プロセスサーバーは、プロセッサドライバー（ 「オルタネータ」内のプロセス間のタイムシェアリング制御の切り替え、「通信」呼び出し以外のプロセスへの割り込み処理、プロセスサーバーへのメモリおよびプロセス状態へのアクセスなどを行うソフトウェア）によって信頼される特権を持つプロセスです。

NLTSSは真のネットワークオペレーティングシステムであり、リソース要求はローカルプロセスからでもネットワーク上の任意のリモートプロセスからでも発生する可能性があり、サーバーはそれらを区別しませんでした。サーバーがそれらを区別する唯一の手段はネットワークアドレスでしたが、サーバーにはそのような区別をする理由がありませんでした。サーバーへのすべての要求はネットワーク要求として認識されていました。

NLTSSにおけるプロセス間の通信には、慣例的にLivermore Interactive Network Communication System (LINCS)プロトコルスイートが使用されました。LINCSは、OSI参照モデルで定義されたプロトコルスタックに沿ったプロトコルスタックを定義していました。NLTSSとLINCSのトランスポートレベルプロトコルはDelta-Tと名付けられました。プレゼンテーションレベルでは、LINCSは、番号付きパラメータ（整数、機能など）をトークンとして通信するための標準を定義しました。トークンはセッションレベルのレコードに格納され、リモートプロシージャコールのようなメカニズムで処理されます。

NLTSSでは、「ユーザー」という概念はごく曖昧にしか定義されていませんでした。どのユーザーがどのリソースを使用しているかを追跡する「アカウントサーバー」が存在しました（例えば、ファイルやプロセスなどのオブジェクトの作成リクエストには、アカウントケイパビリティが必要でした）。アクセス制御は、ケイパビリティ（通信可能な権限トークン）によって完全に管理されていました。

ファイルサーバー

任意のプロセスは、ファイルサーバに対してファイル作成要求（ファイルケーパビリティを返す）や、ファイル読み取りまたは書き込み要求（ファイルケーパビリティを提示する）などを行うことができました。例えば、ファイルを読み取るという動作には通常3つのバッファテーブルが必要でした。1つはファイルサーバに要求を送信するためのバッファテーブル、1つはファイルサーバからの応答を受信するためのバッファテーブル、そしてもう1つはファイルからデータを受信するためのバッファテーブルです。これらの3つの要求は通常、メッセージシステムに一度に送信され、他の要求とバンドルされることもありました。送信されたバッファテーブルのいずれかが「完了」とマークされたら、バッファテーブルに制御ビットを設定することで、プロセスをウェイクアップ（ブロック解除）できます。ファイル読み取りのためのライブラリ呼び出しは、通常、ファイルサーバから制御応答を受信するまでブロックされますが、非同期I/Oは当然ブロックされず、後でチェックまたはブロックできます。ユーザー側のこのような違いは、ファイルサーバからは見えませんでした。

プロセスサーバー

NLTSSでは、プロセスサーバーはファイルサーバーと非常に似ており、ユーザープロセスはプロセスの作成、開始または停止、プロセスメモリまたはレジスタの読み取りまたは書き込み、プロセス障害の通知を要求できました。プロセスサーバーは、ファイルサーバーがディスクドライバーとの通信を信頼していたのと同様に、 CPUドライバーとの通信を信頼する通常のユーザーモードプロセスでした。プロセスサーバーは、ファイルサーバーが提供するファイルにプロセスの状態を保存し、その点ではファイルサーバーからは他のユーザープロセスと同様に見えました。

ディレクトリサーバー

NLTSS の上位サーバーの例としては、ディレクトリ サーバーが挙げられます。このサーバーの役割は、基本的にファイル (ユーザーには表示されません) をディレクトリに変換し、名前で機能を格納および取得できるようにすることです。機能は単なるデータであるため、これは特に難しい作業ではなく、LINCS プロトコル スイートで定義されている規則に従って機能へのアクセス許可を操作することがほとんどでした。ここで少し興味深いのは、inheritanceというアクセス許可に関する部分です。このビットがオン (許可) の場合、ディレクトリから機能をフル アクセスで取得できます。このビットがオフ (不許可) の場合、ディレクトリ機能でオフになっているアクセス許可は、取得する機能でもオフになってから、要求元のアプリケーションに返されます。このメカニズムにより、たとえば、ディレクトリに読み取り/書き込み可能なファイルを格納し、他のユーザーには読み取り専用のインスタンスを取得するアクセス許可のみを与えることができます。

発達

NLTSSのプログラミングの大部分は、ロスアラモス国立研究所で開発された「Model」と呼ばれるPascal拡張言語で行われました。ModelはPascalを拡張し、抽象データ型（オブジェクト）メカニズムやその他の機能 を追加しました。

NLTSSは互換性というレガシーを背負っていました。NLTSSは、LLNLのリバモア・コンピュータセンター（1968年頃～1988年頃）におけるリバモア・タイムシェアリング・システム（LTSS）の開発と導入に追随しました。NLTSSの開発は、LTSSがCray-1に移植され、 Crayタイムシェアリング・システムとなったのとほぼ同時期に始まりました。LLNLの多くの科学アプリケーションとの後方互換性を維持するために、NLTSSは以前のLTSSオペレーティングシステムのシステムコールをエミュレートせざるを得ませんでした。このエミュレーションは、「baselib」という互換性ライブラリの形で実装されました。例えば、NLTSSのディレクトリ構造、ひいてはプロセス構造は、当然ながら有向グラフ（プロセス機能はファイル機能やディレクトリ機能と同様にディレクトリに格納可能）でしたが、baselibライブラリは以前のLTSSとの互換性を維持するために、単純な線形（コントローラ制御）プロセス構造（ Unixのようなツリー構造でさえない）をエミュレートしました。科学分野のユーザーはベースライブラリライブラリ外のNLTSSサービスにアクセスすることはなかったため、NLTSSはユーザーにとってLTSSとほぼ同じように見えました。ほとんどのユーザーはNLTSSの機能に気づかず、ネットワーク経由でリソースにアクセスできることにも気づかず、NLTSSがLTSSを超えるサービスを提供していることにも気づいていませんでした。NLTSSは共有メモリ対称型マルチプロセッシングをサポートしていましたが、これはCrayタイムシェアリングシステムにおける同様の開発と並行して進められたものです。

NLTSSという名称自体が、ある種のレガシーでした。「New Livermore Time Sharing System」という名称は、当初開発中の暫定的な名称として考えられていました。システムがデュアルシステムモード（LTSSとドライバを共有する仮想マシンのようなもの）で一部のアプリケーションを実行するようになると、開発者はより永続的な名称であるLIncs Network Operating System (LINOS)を選択しました。しかし残念ながら、LLNLの経営陣は、その時点で名称を変更することはできないと判断しました（以前の名称が予算要求で使用されていたためと思われます）。そのため、暫定的な開発中のNLTSSという名称は、システムの寿命を通してそのまま残りました。

NLTSSと並行して、LINCSプロトコル（NLTSSと同じファイルおよびディレクトリプロトコル）を使用する大容量ストレージシステムも開発されました。このシステム/ソフトウェアは後にUnitree製品として商品化されました。Unitreeは、LINCSとNLTSSの遺産とも言える高性能ストレージシステム（HPSS）にほぼ取って代わられました。例えば、 LINCSとNLTSSは、サードパーティ転送（NLTSSでファイルをコピーする場合、プロセスはファイルサーバーに読み取りと書き込みの2つの要求を送信し、ファイルサーバー間でデータを転送するように指示する）という形式を導入し、これは改良された形でUnitreeとHPSSに引き継がれました。

実装と設計の問題

NLTSSの製品ライフサイクルにおける最大の批判はパフォーマンスでした。ユーザーに最も大きな影響を与えたパフォーマンス上の問題は、ファイルアクセスのレイテンシでした。これは通常、ディスク入出力（I/O）では大きな問題ではありませんでしたが、NLTSSが動作するシステムは、アクセス時間が10マイクロ秒未満の、レイテンシが非常に低いソリッドステートディスク（SSD）も多数サポートしていました。NLTSSにおけるファイル操作の初期のレイテンシは、SSDアクセスのレイテンシと同程度で、LTSSのレイテンシよりも大幅に高くなっていました。NLTSSにおけるファイルアクセスのレイテンシを改善するため、実装に大幅な変更が加えられ、レイテンシの影響を受けやすいプロセス（特にファイルサーバー）が「カーネル内」に配置されました。この変更は、すべてのNLTSSサーバーがマルチスレッドモデルで動作していたため、一見するとそれほど重要ではありませんでした。この変更の本質は、ファイルサーバーサービスを担当するスレッドを、独立したファイルサーバープロセスからカーネル「プロセス」に移動させたことでした。ユーザーとの通信は変更されていません（バッファテーブル、LINCSトークンなどを介して行われます）が、ファイル操作では、従来のLTSSや競合するCray Time Sharing Systemと比較してレイテンシが高くなる主な原因となっていた、いくつかの大きなコンテキスト変更が回避されました。この変更により、ファイルI/O操作のレイテンシは大幅に（約3倍）改善されましたが、ファイルサーバーがカーネルの信頼できる部分（設計ではなく実装による）になったことも意味しました。

NLTSS の 2 つ目の実装上の問題は、データ実装としてのその機能のセキュリティ/整合性に関連していました。この実装では、パスワード機能モデル (Control by Password を参照) を使用していました。[2]このモデルでは、プロセスのメモリ空間にアクセスできるすべての人物またはプロセスに、そのメモリ内にあるデータによって表される機能にアクセスする権限が与えられます。一部のシステム アーキテクト ( Amoeba分散オペレーティング システムのアーキテクトであるAndrew S. Tanenbaumなど) は、メモリへのアクセスが機能へのアクセスを意味するというこの特性は、固有の問題ではないと示唆しています。NLTSS の環境では、プログラムメモリのダンプを分析のために他の人に渡すことが時々ありました。このことやその他の懸念から、このようなパスワード機能は NLTSS の脆弱性であると見なされました。この脆弱性から保護するために、公開鍵暗号化による制御[3]メカニズムという設計が行われました。このメカニズムは、パフォーマンス コストが非常に高いことと、ユーザーがパスワード機能の脆弱性に気付かなかったことの両方から、NLTSS の製品版には採用されませんでした。暗号技術の最近の進歩により、特にインターネット/ウェブ機能（YURL [4]やWideWORDなど）に対するこのような保護は実用的になるだろう。 [5]

NLTSSの設計上の問題は、生産中止になってから何年も経ってから初めて認識されました。それは、そのオープンネットワークアーキテクチャでした。NLTSSでは、プロセスはファイアウォールなどの制限のないネットワーク内の仮想プロセッサとして扱われていました。どのプロセスも他のプロセスと自由に通信できました。つまり、直接通信を制限するという意味でも、例えば「ウォールバンギング」のような隠れ通信路を制限するという意味でも、通信を制限できませんでした。この問題を解決するには、NLTSSに通信を可能にする機能が必要でした。「ストリーム番号」などのNLTSSの後期開発作業は、そのような機能に近づいていましたが、1988年に開発が停止した時点では、NLTSSの通信は依然として制限されていませんでした。

参照

参考文献

  1. ^ 「ネットワークオペレーティングシステムのコンポーネント」。webstart.com。
  2. ^ 「ネットワーク オペレーティング システムでのドメインの管理」。webstart.com。
  3. ^ 「ネットワーク オペレーティング システムでのドメインの管理」。webstart.com。
  4. ^ "YURL". Waterken Inc.
  5. ^ “Home”. wideword.net . 2002年11月7日時点のオリジナルよりアーカイブ。

さらに読む

  • JE Donnelley、「ネットワーク オペレーティング システムのコンポーネント」、第 4 回ローカル ネットワーク カンファレンス、ミネアポリス、1979 年。また、Computer Networks 3 (1979) 389–399 にも掲載。
  • JE Donnelley、「ネットワーク オペレーティング システムでのドメインの管理」、ローカル ネットワークおよび分散オフィス システム カンファレンスの議事録、ロンドン、1981 年 5 月、345 ～ 361 ページ。
  • ST Brugger、M. Gandhi、G. Streletz、「Network Livermore Time Sharing System (NLTSS)」、2001年
  • LLNLにおけるケイパビリティコンピューティング LLNLにおけるコンピューティングにおけるケイパビリティの使用の歴史について、RATSシステムと、その開発がNLTSSにどのようにつながったかについて簡単に説明します。
  • ローレンス・リバモア国立研究所における大規模科学計算の開発ストーリー
  • NLTSSクロニクル NLTSSとLINCSの開発に関する漫画
Retrieved from "https://en.wikipedia.org/w/index.php?title=NLTSS&oldid=1310237830"