分散システムのための Styx アーキテクチャ

Rob Pike
Dennis M. Ritchie
Computing Science Research Center
Lucent Technologies, Bell Labs
Murray Hill, New Jersey
USA

NOTE: Originally appeared in Bell Labs Technical Journal, Vol. 4, No. 2, April-June 1999, pp. 146-152.
Copyright © 1999 Lucent Technologies Inc. All rights reserved.

概要

分散システムは、お互いに独立した各部分が集まって構成され、 その集合体が場所的にも機能的にも分散していながら、 統一された形を作りあげています。その例としてはネットワークＯＳ、 インターネットサービス、国際電話通信網、さらに一般的には、今日の デジタルネットワークを使うすべての技術が分散システムといえます。 しかしながら分散システムの設計、構築、保守は依然として困難な ままであり、その主な原因は、簡単明瞭な相互接続のモデルが欠けて いるためだと思われます。

Plan 9 と Inferno という二つの分散システムを通して我々が得た経験は、 上記のようなモデルを提案する助けになりました。これらのシステムは、 ある有用なアイディアのもとして作られ、それが実際に有効であることを 示していますし、またシステムの大部分において、そのアイディアができる かぎり利用されています。その アイディアとは、システムの持つ資源を、階層的な名前空間の中に置かれた ファイルとして提供する、ということです。ファイルとしてあらわされる ものの実体は保存されたデータかもしれませんし、あるいはデバイス、 動的情報のソース、サービスへのインタフェース、制御の参照口かも しれません。この手法によって、全てのシステム資源に対して統一された 基本的な名前付け、構造付け、アクセス制御のメカニズムを提供することが できるようになります。これを支える Styx という単純なネットワーク プロトコルがこのアーキテクチャの中心となって、システム内通信のための 共通の言葉を提供しているのです。

分散されてないシステムでさえ、サービスをファイルとして提供 することで、使いなれた名前付け、アクセス制御、システム資源との 結びつきを大幅に拡張できます。しかし、より重要なのは、リモートファイル システムと接続するという良く知られた技術を使うことで、この手法が 分散システムを構築するための自然な方法をとなるという事です。 資源がファイルとして提供されていて、しかもリモートファイルシステムが あるのなら、それはすでに分散システムなわけです。ある場所で利用 できる資源は、別の場所からも利用できるわけです。

導入

Styx プロトコル

*

通信を開始する (ファイルシステムに接続する);

*

ファイルシステム内を探索する (つまり、必要なファイルの名前を指定し、 それに対するハンドルを得る);

*

ファイルに対する読み書きを行う;

*

ファイルの情報に対する照会、変更を処理する。

open("/usr/rob/.profile", O_READ);

*

ルートへの接続を保ったまま階層内を移動できるように、 clone メッセージによってルートの FID がコピーされ、 新しい FID が返されます。

*

次に、 walk メッセージが複数発行され、この新しい FID がパスの中身を一つづつ移動 (usr, rob, .profile) してゆき、 /usr/rob/.profile ファイルへと辿りつきます。

*

最後に、このファイルを読み込めるかどうか open メッセージによって ユーザのパーミッションがチェックされ、続く read あるいは write メッセージによる操作をこの FID に対して行うことが許可されます。

*

I/O 操作が終了したら、 close メッセージによって FID は開放されることになるでしょう。

アーキテクチャの手法

ネットワーク通信の例

/net/
	dns/
	tcp/
		clone
		stats
		0/
			ctl
			status
			data
			listen
		1/
			...		
		...
	ether0/
		0/
			ctl
			status
			...
		1/
			...
	...

*

すべてのインタフェースはファイルのようにみえ、すでに C や C++、Java といったプログラム言語から利用できるのと同じ I/O 機能を使ってアクセス できます。しかしながら、これらのインタフェースを提供するファイルには、 対応してディスク上に存在するデータファイルはありません。そのかわり、 これらのファイルはミドルウェアのプログラムによって提供されている ものです。

*

基本的に、インタフェースとのやりとりはバイナリによる表現ではなく、 できるかぎり表示可能な文字列を使って行うことになっています。 これはつまり、インタフェースとのやりとりのシンタックスが、 CPU アーキテクチャや言語の細かい部分に依存しないということです。

*

ネットワーク通信機能へのインタフェースである /net の例のように、 インタフェースが階層ファイルシステムの一部であるため、これを 遠く離れた場所にあるリモートマシンへと開放するのは簡単で、ほぼ 自動的に実現されます。

デバッギングの例

/proc/
	1/
		status
		ctl
		fd
		text
		mem
		...
	2/
		status
		ctl
		...
	...

samterm dmr Read 0 20 2478910 0 0 ...

PathStar^TM アクセスサーバの例

/trip/
	config
	admin/
		ospfctl
		...
	boot/
		0/
			ctl
			eeprom
			memory
			msg
			pack
			alarm
			...
		1/
			...
/net/
	...

セキュリティの問題

まとめ

1. システム外との通信は全て、構成要素間でメッセージを明示的に送ることで 行う。この通信は、ローカルな資源を利用するときとは違った方法で アプリケーションから使用される。
2. 通信は全て、密接に共有された資源を利用して行われる。具体的には CPU からアクセスできる様々なメモリ領域を、大規模なネットワークを 介して直接参照できるようにする。アプリケーションは遠隔地のオブジェクトを、 自分が実行されている CPU のように、同じマザーボード上にあるかのように 読み書きできる。

*

簡単で馴染のあるプログラミングモデルによる、名前で指定される ファイルの読み書き。ファイルシステムにはしっかりと定義された 名前付け、アクセス、許可の構造があります。

*

プラットフォームや言語に無関係である。 資源を参照する下位構造はファイルレベルにありますから、どのシステムでも ほぼ利用することが可能で、特定の言語やオペレーティングシステムの機能に 依存しません。この機能を利用するための、C++ や Java のクラス、C 言語の ライブラリを作ることもできます。

*

階層化された名前付けおよびアクセス制御構造。 資源の名前付け、アクセスの設計をわかりやすく、良く構造化されたものにする 助けになります。

*

簡単な試験とデバッグ作業。 細かく規定された、限定されたインタフェースをファイルレベルで利用することで、 分散されたもの同士の通信を簡単に観察することができます。

*

低コスト。 サポートソフトウェアは数千行のプログラムで作成でき、機器の容量を 少し占有するだけですみます。これはクライアントとサーバ両方を合計しての 話です。

参考文献

[NFS]

R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh, and B. Lyon, ``Design and Implementation of the Sun Network File System'', Proc. Summer 1985 USENIX Conf., Portland, Oregon, June 1985, pp. 119-130.

[RFC]

Internet RFC 1094.

[9man]

Plan 9 Programmer's Manual, Second Edition, Vol. 1 and 2, Bell Laboratories, Murray Hill, N.J., 1995.

[Kill84]

T. J. Killian, ``Processes as Files'', Proc. Summer 1984 USENIX Conf., June 1984, Salt Lake City, Utah, June 1984, pp. 203-207.

[PPTTW93]

R. Pike, D.L. Presotto, K. Thompson, H. Trickey, and P. Winterbottom, ``The Use of Name Spaces in Plan 9'', Op. Sys. Rev., Vol. 27, No. 2, April 1993, pp. 72-76.

[PrWi93]

D. L. Presotto and P. Winterbottom, ``The Organization of Networks in Plan 9'', Proc. Winter 1993 USENIX Conf., San Diego, Calif., Jan. 1993, pp. 43-50.

[Nee89]

R. Needham, ``Names'', in Distributed systems, edited by S. Mullender, Addison-Wesley, Reading, Mass., 1989, pp. 89-101.

[CIFS]

Paul Leach and Dan Perry, ``CIFS: A Common Internet File System'', Nov. 1996, http://www.microsoft.com/mind/1196/cifs.htm.

[INF1]

Inferno Programmer's Manual, Third Edition, Vol. 1 and 2, Vita Nuova Holdings Limited, York, England, 2000.

[INF2]

S.M. Dorward, R. Pike, D. L. Presotto, D. M. Ritchie, H. Trickey, and P. Winterbottom, ``The Inferno Operating System'', Bell Labs Technical Journal Vol. 2, No. 1, Winter 1997.

[MAN]

R. A. Lakshmi-Ratan, ``The Lucent Technologies Softswitch-Realizing the Promise of Convergence'', Bell Labs Technical Journal, Vol. 4, No. 2, April-June 1999, pp. 174-196.

[PATH]

J. M. Fossaceca, J. D. Sandoz, and P. Winterbottom, ``The PathStar Access Server: Facilitating Carrier-Scale Packet Telephony'', Bell Labs Technical Journal, Vol. 3, No. 4, October-December 1998, pp. 86-102.