1.　OPUSシステム概要

　OPUSシステムは，当社の提供する“Shared Nothing”型の並列処理プロセッサである．ハードウェア 的には，Intel社のスーパコンピュータ（PARAGON）で実証済みの格子（メッシュ）型相互接続ネットワー ク（以降，MESHと呼ぶ）のアーキテクチャが使用されている．各プロセッサ・ノードには，CPU，メモ リ，I/O装置が実装されており，高速（175Mバイト/秒）なMESHを介してプロセッサ間の通信が行われる．
　この並列処理プロセッサをサポートするOS（オペレーティング・システム）は，SVR4/MKと呼ばれ る分散OSである．SVR4/MKは，Chorus社の提供するマイクロカーネルをベースに， UNIX^[*1]SVR4.2（System V Release 4.2）を実装したものであり， アプリケーション側からはオープンなSVR4.2システムとして利用できる．
　OPUSシステムは，先ずは，大規模データベースの検索処理を中心とした意思決定支援システム構築 マシンとして，1995年に提供された．現在，ORACLE7^[*2]，および，Open Parallel MAPPERが使用可能で ある．将来的には，OPUSシステムの有するシステム資源のキャパシティと潜在的な耐障害性に着目し， OLTPアプリケーションの開発が計画されている．

1.1　ハードウェア構成/構造 1.　システム構成
　OPUSハードウェアは，モジュラー型キャビネット内に収容される下記のコンポーネントから構 成される．
　　・プロセッサ・ノード
　　・MESHが装着されたバックプレーン
　　・統合された大容量記憶サブシステム
　　・システム・コンソール
　この構成は，16（4×4）ノード単位の単純な増設により，最小のコストでのシステム能力の増強 を可能としている（図1）．

2.　プロセッサ・ノード
　図2はプロセッサ・ノードのアーキテクチャを示している．プロセッサ・ノードは，以下のコン ポーネントから構成される．
　　・ベースボード
　　・CPUモジュール
　　・I/Oモジュール

3.　MESHとバックプレーン
　MESH（図3）はバックプレーン・カード上に配列されており，1枚のバックプレーン・カードあ たり16（4×4）ノードがサポートされる．複数のバックプレーンは相互に接続され，より大きなMESHを 形成する（たとえば，4×8，4×16，16×16等）．4枚までのバックプレーンが1キャビネットに収容でき る（図1）．

4.　大容量記憶サブシステム
　OPUSシステムの各ノードに含まれるSCSI-2インタフェースを通して，以下の各I/O装置が接続 可能である．
　　・デュアルポート・ディスク・サブシステム
　　・RAIDサブシステム
　　・各種テープ・サブシステム（QIC，3480カートリッジ，9トラック・オープンリール等） 5.　システム・コンソール
　システム管理と診断は，UNIXベースのシステム・コンソールを通して行われる．システム・コ ンソールはOPUS CPUキャビネット内にあって，各ノードのバックプレーンと繋がっているDAD （Diagnostic and Display）ボードとも直接接続されている．使用者は，コンソール上での操作により， OPUSシステムの初期化，システム分割（複数のノードをいくつかの独立システムとして運用すること）， 操作環境の変更，およびシステム構成要素の診断テストの実行などが可能である．

1.2　ソフトウェア構成/構造
1.2.1　分散OS SVR4/MK
　ChorusマイクロカーネルをベースとしたSVR4/MKは，OPUSの並列アーキテクチャのために開発され ており，対称型マルチプロセッサ（SMP）システムで成し得る範囲を越えたスケールのシステム性能を提 供する．
　SVR4/MK OSでは，UNIXのシステム・サービスは複数のアクタと呼ばれるシステム・サーバ（プロ セス）によって分担されて処理される．このUNIXシステム・サービスのサーバ・プロセス化においては， システム内での通信・計算の負荷を低く抑え，スピード・効率を落とさないようデザインされている．ア クタはある種のシステム・サービスの集合をまとめてサポートしている．たとえば，システム・アクタ OM（Object Manager）はファイル関連サービスのすべてを処理する．他には，PM（Process Manager), STM （Stream Manager), IPCM（System V Inter Process Communication Manager）などのシステム・アクタがある．
　マイクロカーネルが提供するサービスには以下のものがある．

『CPUスケジューリング』

• CPUスケジューリング
• 仮想記憶機構
• アクタ間での位置透過な通信（Chorus/IPC: Inter Process Communication）
• インタラプトのディスパッチ

　図4はサーバ化されたオペレーティング・システムを表している．実際には，10個以上のアクタが存 在するが，この図では基本的な3アクタのみを示している．
　第2章では，ChorusマイクロカーネルのOPUSへの実装にあたって生じたいくつかの課題から

• プロセッサ間通信におけるメッセージ・デッドロックの回避
• メモリ管理における遅延コピーの最適化

について記述する．

1.2.2　単一システム・イメージ（SSI: Single System Image）機能
　OPUSシステム内の各ノードで稼働するマイクロカーネルは，OSを構成するシステム・サーバ間での 位置透過な通信をサポートしている．これらのシステム・サーバは各ノードにまたがり，互いにメッセー ジを介して協調動作をしあいながら「単一システム・イメージ」を実現している．この分散OS・ SVR4/MKが有するメッセージング（通信）機能は，異なるノード上のシステム・サーバ間で使用される 場合でも同一ノード上のシステム・サーバ間で使用される場合とまったく同じコール形式で行われる．す なわち，リクエスタが宛先となるノードを明示することなく，位置透過に行われる．たとえば，あるノー ド上で動いているプロセスがファイル“/usr/home/test/file1”をオープンしたと想定したとき，SVR4/MK は該ファイルの位置情報を明示されることなしに，そのファイル位置を突き止めることができる．
　SSI機能により，UNIXアプリケーションは，何の変更も受けずに，OPUS上で稼働が可能である．ま た，アプリケーションはどのノード上でも実行可能である．
　SVR4/MKは単一ノード・システムのように振る舞うが，アプリケーションは複数ノード・システム であるが故の特性を利用する事ができる．たとえば，プロセスを特定のノードあるいは特定ファイルが存 在するノードにて実行するよう割当てることも可能である．
　第3章では，SVR4/MKの最大の特徴であるSSI機能の個々の説明と，SSI機能のうち，

• 分散ブート
• パス名解析

の実現方法について記述する．

2.　Chorusマイクロカーネルの実装

　本章では，OPUS SVR4/MK OSの基礎となっているChorusマイクロカーネルをOPUSに実装するにあ たって課題とされたいくつかの中から，

• プロセッサ間通信におけるメッセージ・デッドロック問題の回避
• メモリ管理における遅延コピーの最適化

について述べる．
　本稿では紙面の都合により，Chorusマイクロカーネルについては巻末に主な用語だけを説明するにと どめる．詳細説明についは参考文献を参照されたい．

2.1　プロセッサ間通信におけるメッセージ・デッドロック問題とその回避
　オペレーティングシステム内部でipcCallやipcSend等のIPCインタフェースによって処理が進められる とき，メッセージを受信したスレッドはそのメッセージの処理中にさらに他のサーバへipcCallやipcSendを 行ない得る．このようなipcCallやipcSendの入れ子呼び出しは，コールチェーン（call chain）と呼ばれる． クライアントからの一つの要求を処理するために最初にipcCallまたはipcSendが呼ばれ，それにともなって さらにipcCallまたはipcSendが入れ子にn回呼ばれた場合，ここではそれを入れ子数がnであると呼ぶことに する（図5）．

　Chorus/IPCにおいてフロー制御は，クレジット（credit）によって行われる．たとえば，サイトAがサ イトBへメッセージを送信するとき，サイトAにはあらかじめサイトBからクレジットが与えられていなけ ればならない．クレジットは，クレジットを発行したサイトがクレジットを与えられたサイトからメッセー ジを受信できることを保証する．
　また，どのサイトもクレジットなしにメッセージを送信することはできない．クレジットの管理は， IPCプロトコル・フロー制御層によって制御メッセージ部を通して行われる．
　はじめにサイトAは，サイトBから許される限り最大数のクレジットを与えられているとする．サイ トAがサイトBへメッセージを送信すると，サイトAはサイトBへのクレジットを一つ消費したことになり， サイトBは受信したメッセージを受信バッファに蓄える．クレジットの補充は，常に受信側サイトでメッ セージの処理が完了したとき，すなわち受信バッファが解放されるときに受信側サイトによって行われる．
　今，サイトAとサイトBが互いに最大のクレジット数mを持ち，他にIPCが一切ないとする．連続して サイトA―B間を往き交う入れ子数nのコールチェーンが一つ発生した場合，最大クレジット数mが（n ＋1)/2以上ならば，コールチェーンは処理可能である．しかし一般には，複数のコールチェーンが同時に 発生し得るため，もし受信側サイトが送信側サイトのクレジットを補充する機会を迎える前に，送信側サ イトがクレジットを使い果たすとデッドロックが発生する．また，デッドロックはこのようにメッセージ の流れが二つのサイト間で折り返したり循環する地点で出現する．図6は，連続してサイトA―B間を往き 交う二つのコールチェーンがやがてデッドロックに遭遇するシナリオを示している．オペレーティングシ ステム設計者は，あらかじめ発生可能な最大入れ子数を知ることはできるが，同時に発生し得るコールチェー ンの数を求めることはできない．

　このようなデッドロック問題を回避するために，OPUSのChorus/IPCでは，メッセージレベル・アル ゴリズム（message level algorithm）と呼ぶ資源管理手法を用いている．このアルゴリズムでは，まず OPUSにおけるNucleus（ニュークリアス；Chorusマイクロカーネルの名称）で発生可能なコールチェーン の最大入れ子数がnであると仮定すると，資源すなわち受信バッファをレベル0（L0と表す）からレベルn （Ln）までのn＋1のレベルに分割する．最初に実行されるipcCallはレベルL0で行われる．受信サイトはこ のメッセージを受信するためにレベルL0の受信バッファを使用する．レベル値はメッセージに含まれ，受 信サイトへ渡される．スレッドがメッセージを受信すると，レベルはインクリメントされてスレッドのコ ンテキストに保存される．スレッドが次にメッセージを送信する場合には，コンテキストに保存されたレ ベルでIPCが行われる．よって次の受信サイトでは異なるレベルの資源が利用される．また，スレッドが リプライするときも同様に，コンテキストに保存されたレベルが使用されるため，リプライメッセージの レベルは常に受信したメッセージのレベルより1だけ大きくなる（図7）．

　ただし，メッセージレベル・アルゴリズムはデッドロックを回避する代わりに，発生し得るコールチェー ンの最大入れ子数（レベル値）が大きなものになると，アルゴリズムはオペレーティングシステムにとっ て高価なものになる可能性がある．メッセージレベル・アルゴリズムがどのように機能するか，いくつか のケースに分けて以下に述べる．
　図8は，二つの要求コールチェーンが同じ方向に進んでいる場合を示している．要求コールチェーン が進行する場合には，レベルはチェーンを進むたびにインクリメントされていく．この二つのコールチェー ンは，メッセージの流れが折り返す地点には未だ到達していない．二つの要求コールチェーンが，サイト AからサイトBへメッセージを送るとき，両者のレベルが異なるならば（Li≠Lj），サイトB上ではレベル によって分離された異なる資源を利用するために競合は発生しない．もし両者のレベルが等しく（Li＝Lj） かつ資源の競合が発生した場合には，どちらかが勝ち他方が待つことになるが，資源はやがて解放され， デッドロックは発生し得ない．これはリプライ・コールチェーンでも同様で，デッドロックは発生し得な い．リプライメッセージのレベルは元の要求メッセージのレベルより1だけ大きいレベルが使用されるた め，リプライ・コールチェーンでは，その進行にともなってレベルはデクリメントされていくように見え る（図8内の矢印の向きをすべて逆にし，全てのレベルに1を加えた形になる）．

　図9は，二つの要求コールチェーンが逆方向に進んでいる場合を示している．レベルがすべて異なる 場合には，すべて異なる資源が利用されて競合は起こらない．仮にレベルが一致して競合が発生してもど ちらかが先に進み他方は待つが，資源はやがて解放され，デッドロックは発生し得ない．

　図10は，逆方向に進んですれ違った二つのコールチェーンが互いに折り返した様子を表している．デッ ドロックはこのような場面で起こり得ると前に述べた．しかし，メッセージレベル・アルゴリズムによっ て，もはやデッドロックは起こり得ない．図10では，チェーン1はサイトBで折り返し，サイトBからサイ トAへリプライメッセージを送るためにサイトAからレベルLiのクレジットの獲得を試みている．このと き，チェーン2がチェーン1とデッドロックを起こすためには，チェーン2は折り返してサイトAからサイ トBへリプライを送るためにサイトBからレベルLi−1のクレジット獲得を試みていて，かつチェーン2はこ のとき直前のレベルとしてLiを保持していなければならない．しかし，リプライメッセージのレベルは元 のメッセージのレベルより1だけ大きいという規則から，チェーン2の直前のレベルは図10に示す通りLi −2であり，Liではあり得ないためである．

2.2　遅延コピーの最適化
　Nucleusの遅延コピーは，Mach（CMU）のシャドウオブジェクトに類似したヒストリオブジェクトに よって実装されている．しかし，ヒストリオブジェクトによる遅延コピーにはいくつかの欠点がある．こ こでは，OPUSへのNucleusの実装に際してどのように遅延コピーが変更され，最適化されたかについて述 べる．
　一般にセグメントが複製されると，元のセグメントはすべて書き込みが禁止されたソースセグメント となり，複製されたセグメントはコピーセグメントと呼ばれ，さらにヒストリオブジェクトと呼ばれる特 殊なセグメントが作成される．ソースセグメントが書き込み例外を起こすと，ページが複製され，一つは 変更されてソースセグメントに与えられ，もう一つはヒストリオブジェクトと呼ばれるセグメントへオリ ジナルを保存するために与えられる．初めコピーセグメントは，そのページへのアクセスを持たないため， アクセスは例外を起こす．例外処理はまず，コピーセグメントからソースセグメントへ向けてセグメント をたどりながらページ探索を行う．やがてページはどこかのセグメントで発見される．アクセスが書き込 みであったならば，ページは複製され，次に変更され，例外処理は完了する．遅延コピーは，言い替えれ ば，一種のバージョン管理である．図11は，ソースセグメントがページ4の自身のバージョンを作成して そのオリジナルをヒストリセグメントに保存し，コピーセグメントがオリジナルからページ2の自身のバー ジョンを作成した様子を示している．

　このヒストリオブジェクトによる遅延コピーの手法には二つの欠点がある．ソースセグメントは常に 自身のセグメントにページを見つけられるのに比べて，コピーセグメントは常にページ探索を行わなけれ ばならない．複製が何世代にも渡ると，最も端のコピーセグメントが行うページ探索の仕事量はかなり大 きくなる可能性がある．
　もう一つは，ヒストリセグメントがかかえるオリジナルのページに対するバッキングストアのために， セグメントに対して予想されるバッキングストアの必要量を計算するのが困難なことである．たとえば， UNIXサブシステムがプロセスのためにバッキングストアを用意するとき，ヒストリセグメントによって オリジナルページが保存されるため，その量は一つのプログラムが必要とする量を上回る可能性がある． そのため，OPUSへのNucleusの実装に際して，ヒストリセグメントを極力排除して遅延コピーを最適化し ている．
　ヒストリオブジェクトを使用した従来のセグメントの構造と，ヒストリオブジェクトを廃止した新し いセグメントの構造を図12に示す．

　第0世代のセグメント（SRC）はソースセグメントである．新しいセグメント構造（図12右側）では， 世代が増すごとに子（child）へのリンクが作られ，さらに同世代内の兄弟（sibling）が増すごとに兄弟へ のリンクが作られてセグメントが配置されていく．新しいセグメント構造では，正しいバージョンへのア クセスを保証するために新しいページ操作の規則が必要になる．今，第1世代のコピーセグメントC1.1で ページの変更が発生したとする．ヒストリセグメントを使用したときには，ページ探索によってページは ヒストリセグメントH1かSRCで発見される．ページは二つ複製され，一つは変更されてC1.1によって使 用され，もう一つはオリジナルとしてH2.1に保存される．新しい規則では，ページ探索は年長の兄弟，次 に親の方向へ行われる．C1.1の兄弟，子がともにオリジナルを発見できるようにページは三つ複製される． 自身で新たに作成するバージョン以外は，子C2.1と，自分より下の年長の兄弟C1.2の両方へ渡される．た だし，子や兄弟がすでに自身のバージョンを持っている場合には複製を渡す必要はない．
　新しいセグメント構造は，ヒストリオブジェクトを廃止することによってページ探索の距離を短縮す るだけでなく，これまでヒストリオブジェクトのために必要であったメモリ空間を解放する．しかし，新 しい遅延コピーの手法では，より多くページを複製する必要があるかも知れない．一般に，オペレーティ ングシステムにとってページの複製は面倒な作業であるが，これはページオブジェクトによってページの 多重参照を実現することで回避できる．
　ヒストリオブジェクトは常にオリジナル・バージョンの保存場所であった．ヒストリオブジェクトの 廃止によって，コピーセグメントは自身で変更したページだけでなく，オリジナル・バージョンも保存し なくてはならない．このことはプロセスの終了に対して影響を及ぼす．たとえば，図12の新しいセグメン ト構造において，C1.2にさらに兄弟C1.3がいるとする．プロセスの終了によってC1.2が削除されるとき， C1.2がオリジナルを持っているならば，それはC1.3とC2.3の両方に渡されなければならない．図13は，遠 隔遅延コピー時のセグメントの扱いを示している．

　今，C2は遠隔サイトBへ移送され，サイトBに二つの子がいる．このとき，サイトAのC2（点線枠） はサイトAに残され，ヒストリセグメントとして機能する．もしサイトBでC2あるいはその子からページ 探索が開始されると，探索はサイトBのC2からサイトAのC2を経て継続される．

3.　SSI―Single System Image

　SSIについては，すでに簡単に1.2.2項で述べたが，この章の前半では個々のSSI機能について説明を行 なう．また，後半はSSI機能のうち「分散ブート」と「パス名解析」の事例を紹介する．

3.1　SSI概要
　SSIは，ユーザ，あるいはアプリケーション・プログラムに対して，OPUSの特徴であるリソースの分 散性を意識させることなく，単一のUNIXイメージを提供する．いくつかの例外を除いて，OPUSの使用者 が分散環境を意識する必要はない．これは，システムを効率良く使用することとは意を異にするが． UNIXのセマンティクスを失うことなく分散環境を使えることは，OPUSを単一システムイメージ（SSI） として特徴付けている．

3.1.1　単一プロセス名空間
　プロセスに関する情報，管理機能をプロセス位置とは独立して提供する．プロセスが動作している実 際のノード位置とは無関係にプロセスの情報を得，プロセスを制御することができる．また，/procファイ ルシステムや，プロセスのグループ管理，セッション管理，シグナルの伝搬などをノード位置から独立し て提供する．
　たとえば，あるプロセスAがプロセスBへSIGHUPを送ることを想定する．この時，シグナルを受ける べきプロセスBがどのノードで実行されているかは知る必要はなく，また逆にシグナルを送ろうとするプ ロセスAの実行位置も知る必要はない．この場合，知る必要があるのはプロセスBのプロセスIDだけであ る．プロセスIDは従来のUNIXと何ら変わることなく，システム全体で唯一無二の存在である．プロセス ID自体にはそのプロセスが発生したノードの位置情報が含まれているかも知れないが，そのIDは現在その プロセスを実行しているノードの位置情報は含んでいない．また，プロセスのグループID，セッションID なども実行位置に無関係であり，UNIXのセマンティクスに完全に従う．/procファイルシステムもシステ ムに唯一存在し，完全に位置透過性を実現している．

3.1.2　複数サイトでのプロセス実行
　プロセスを複数のノードに分散させる機能を提供する．自ノード以外のノードで実行させるリモート 実行と，あるノードから別なノードへプロセスを移動させるプロセス移送を提供する．
　リモート実行は，指定したノードでプロセスを実行させるものである．たとえば，あるプロセスにとっ てI/Oの発生する率の高いディスクがノードNに存在することを知っているなら，そのノードでプロセスが 実行できれば，理論的にはメッシュ間のメッセージ転送などのオーバーヘッドが減少し，プロセスの効率 は高くなる．また，プロセス間通信においても，メッセージ交換の頻度の高いプロセス同士を同一のノー ドで実行できれば，より高い効率が望める．
　プロセス移送は，実行中のプロセスを指定したノードへ移送するものである．リモート実行と同様に， 使用頻度の高い資源を保有するノードへプロセスを移送できれば，プロセスの効率も高くなる．また，こ れらの機能からロードバランスと呼ばれる負荷分散の機能が容易に想像できる．資源に密着したノードで の実行という考えからは相反するが，負荷の集中しているノードから負荷が比較的少ないノードへプロセ スを移送することにより，ロードバランスは実現できる． リモート実行，プロセス移送のいずれも，

• 自ノード
• ルート・ディレクトリを保有するノード
• カレント・ディレクトリを保有するノード
• 指定ノード
• 指定ファイルの存在するディスクを保有するノード
• 指定プロセスを実行しているノード
• 指定したSystem V IPC（共有メモリ，セマフォ，メッセージ）の存在するノード

を指定してプロセスの実行，移送を行うことができる．これらのリモート実行，プロセス移送によって UNIXのセマンティクスが失われることはない．

3.1.3　単一ファイルシステム名空間
　プロセスの位置やノードにまたがる分散された個々のファイルシステムの位置に関わらず，ファイル 名の位置透過性を提供する．ファイル名に対応するディスクのノード位置情報を付加することなく，ファ イルにアクセス可能である．アプリケーション・プログラムからは，リモート・ディスク，ローカル・ディ スクといった区別はなく，また，ファイルのパスにノード位置情報（たとえば“/nodeX/dir1/file1”という ように，パス名の先頭のノード位置を示す「タグ」など）を含める必要もない．ある意味では，NFSと非 常によく似ている．NFSでマウントされたファイルシステムにアクセスする際，そのファイルシステムが どのホストからマウントしているのかという情報を付加する必要がないのと同様である．すなわち， OPUSの「単一ファイルシステム名空間」の機能は，ノード間メッシュ結合内で閉じた広義のNFSである といえる．

3.1.4　ファイル・データ一貫性
　すべてのプロセスに位置透過な，ファイル・データの一貫性を提供する．ファイル・データはすべて のノードから参照可能であり，キャッシュを行なって入出力の効率化を図る．したがって任意の複数ノー ドにデータがキャッシュされていることになるが，これらのデータが一貫している必要がある．つまり， あるノードにおけるデータの変更は，その他のノードがキャッシュしている同一領域データとの整合性， 一貫性を保ちながら行われなければならない．OPUSではCM（Coherency Manager）と呼ばれるシステムア クタを導入し，ファイル・データの一貫性を保持している．

3.1.5　ファイル・メタデータ一貫性
　ファイル・データ同様，すべてのプロセスに位置透過な，ファイルに関する情報を持つファイル・メ タデータの一貫性を提供する．

3.1.6　単一デバイス名空間
　位置透過な，デバイスおよびデバイス・ドライバへのアクセスを提供する．それぞれのノードでは， 独立してデバイスおよびデバイス・ドライバを保有している．すべてのプロセスからそれらの資源へのア クセスは，特殊ファイル名を通して行われる．特殊ファイル名の解析は「単一ファイル名空間」がその位 置透過性を提供すると共に，実際のデバイスのノード位置について透過的に提供される．すなわち，ドラ イバのノード位置を意識することなく，遠隔ノードが保有するデバイスへのアクセスを可能にしている．

3.1.7　単一ストリーム名空間
　位置透過な，ストリーム・モジュールおよびドライバへのアクセスを提供する．「単一デバイス名空 間」同様，デバイス・ドライバの位置透過性を実現すると共に，ストリーム・モジュールへのアクセスも 位置透過で提供する．プロセスの実行位置，ストリーム・デバイス・ドライバの存在位置，プッシュされ たストリーム・モジュールの位置がそれぞれ異なる場合でも，それらは位置透過に機能する．つまり，プ ロセスからドライバ，モジュールを参照するためにその位置を知る必要がないだけではなく，プロセス移 送による実行位置の変化を受けない．

3.1.8　単一System V IPC名空間
　全ノードのプロセスに，System V共有メモリ，メッセージ・キュー，およびセマフォの共通視点を提 供する．OPUSでは，個々のノード上のChorusが独立にメモリを管理しているため，各ノードから直接に 共通使用されるメモリの領域は存在しない．しかし，SVR4のセマンティクスを，System V IPCについて， 個々の独立したOSの集合ではなく，単一のエンティティとして実現している．つまり，プロセスの実行 位置，対象となるSystem V IPCの存在位置に関係なく，従来のUNIXと同様に識別子だけで制御・アクセ ス可能である．

3.1.9　分散ブート
　一貫性のある複数ノードのシステム・ブートを提供する．OPUSではすべてのノードですべて同じ UNIXイメージが作動している．この動作イメージの同一性を保持し，さらに任意のノードにおける独立 性を提供する．RS（Repository Server）と呼ばれるシステム・アクタの導入により，個々のノードの任意 の時点でのブートを可能とする．

3.1.10　単一システム管理領域
　複数ノードの構成を，高速ネットワークで接続された個々のサイトの集合としてではなく，単一エン ティティとして管理する機能を提供する．保有する資源を個々のノードごとに管理しなければならないの は当然であるが，それらを包括的に管理する機能を提供する．

3.2　SSI事例(1)分散ブート
3.2.1　UNIXイメージのロード方法
　OPUSでは，すべてのノードで同一のUNIXイメージが協調しながらそれぞれ独立に動作する．分散共 有メモリ上で動くUNIXイメージをロードし，動作させる方法はいくつか考えられる．

1. 単一ノードのメモリ上にロードし，それを他のノードと共有する．
2. 単一ノードの二次記憶上にイメージを保持し，それぞれのノードがそれをローカル・メモリ上へ ロードする．
3. それぞれのノードに直接接続された二次記憶上から，それぞれ独立にイメージをローカル・メモ リ上へロードする．

　1.では，実行時のオーバーヘッドが大きくなり，明らかに効率が悪い．2.では，ブート時のオーバー ヘッドが大きいが，UNIXイメージの同一性は保証される．3.では，ブート時のオーバーヘッドは減るが， ロードすべきイメージの同一性は，保証されない．2.と3.の折衷案なども考えられるが，現在OPUSでは 2.を採用している．

3.2.2　分散ブートの流れ
　ブートは次のような順で行われる．

1. 　ハードウェアのチェック
   　個々のハードウェアが状態をチェックし，待機する．
2. 　EOSの起動
   　CPUのリセットと共に，決められたアドレスから命令が開始され（Intel社Pentium^[*3]プロセッサ では，リセット直後は0×FFFFFFF0から命令が実行される），さらにF/Wとして用意されているEOSがメ モリへ展開（EOSは初期状態では，FLASH ROM上に圧縮されて格納されている）されてエントリアドレ スの命令が実行される．
   　EOSはラウンド・ロビン・スケジューリングを基本とする簡易オペレーティングシステムであり， FLASH ROM上に格納されている．物理アドレス0×E0000から動作するため，“EOS”と呼ばれている． 初期状態では圧縮されているため，まず本体を展開することから始まり，I/Oのためのインタフェースを 提供する．このインタフェースの中には，SCSIディスクへのアクセスも含まれている．EOSはPentiumの 保護モードをつかわず，仮想アドレス＝物理アドレスの実メモリ空間で動作する．EOSは自己の初期化が 終ると，同じくFLASH上に格納されているPOLを呼び出す．
3. 　POLの起動
   　POLはEOS同様FLASH上に存在する．POLの役割は，コーディネータおよびRL（Repository Loader）を探し，ロードし，実行することである．
4. 　RLの起動
   　RLの役割はUNIXイメージ（リポジトリ）を探し，ロードし，実行することである．
5. 　RSの起動
   　RS（Repository Server）の役割は，POLとRLのためにファイルシステムのサービスを提供し， UNIXイメージをロードできるようにすることである．RSはChorus Actorの一つとして実装されている．す なわち，実際には，RSはChorusマイクロカーネルの実行と共に動作する．
6. 　UNIX―Chorus/Mixの起動
   　Chorusマイクロカーネルの初期化と共に，Chorus/Mixが実行を開始し，UNIXのセマンティクス を提供する．

　リポジトリを保持するノードをコーディネータと呼び，現在は一つのパーティション・システムに唯 一である．コーディネータは自らがリポジトリを保持していることを知ると，RLを経てRSに至る．一方， コーディネータ以外のノードでは，POLでRSと通信し，RLを経てUNIXを起動する．SSIの一環として， このように分散ブートが行われている．現在は，コーディネータは一つのシステムに唯一固定で存在する が，将来はコーディネータが動的に変更する可能性がある．前者は“Dumb Boot”，後者は“Smart Boot” と呼ばれている．Smart Bootでは，コーディネータが複数存在し，そのRSによって，リポジトリが提供さ れる．

3.2.3　POL: Power On Loader
　POLはEOS上で動作する．GTIインタフェースを用いて，ブロードキャストを行ない，コーディネー タのRSからの応答を待つ．
　コーディネータを含めたすべてのノードで，次のような処理が行われる．

1. 自ノードの初期化
   • EOSを介して自ノードの位置などのコンフィギュレーションを得る．また，必要なデバイス，不 必要なデバイスの許可・不許可を設定する．
   • 自ノードに接続されたシステムディスクを走査し，ブートイメージがあれば (V STAND)，ローカ ル・リポジトリが有効である旨を示すフラグを設定する．
   • 現在のバージョンでは，VRAMに設定された唯一のノードだけがコーディネータになり得る（パー ティション内のノード0に固定）．
   • 将来のSmart Bootでは，複数のノードがコーディネータになることができる．すべてのノードがリ ポジトリを持つことができるが，リポジトリを持っていることがすなわちコーディネータではない．コー ディネータはリポジトリを持っていることが必要条件である．
2. コーディネータの検索
   • コーディネータを探すためにブロードキャストを繰り返す．
   • 最初のブロードキャストがタイムアウトなどで失敗した後，自ノードがコーディネータであれば， ローカルディスクからRLを読み込み，これを実行する．
   • 自ノードがコーディネータでなければ，ブロードキャストを繰り返し，RSからのリプライを待つ． RSからACKが返れば，RLの送付を要求，これをロード・実行する．
3. UNIXイメージの読み込み・実行
   • コーディネータから，UNIXイメージの実体を受信し，これを実行する．

3.2.4　RS: Repository Server
　RS（Repository Server）はChorus/Mixのシステムアクタの一つとしてPOLからの要求に備える．RSの 主目的はPOLに対してリポジトリ（UNIX image）を提供することである．RSが動き出した時点で，その ノードではすでに単一のUNIXとして動作し始めているため，OMなどからサービスを受けることも可能で ある．RSは準備が整うと，文字通りのサーバとして待機し，POLのリクエストにしたがって，各種情報 の提供，UNIXイメージの転送を行う．

3.3　SSI事例(2)パス名解析
「単一ファイル名空間」の事例としてパス名解析をとりあげる．

3.3.1　PM: Process Manager とOM: Object Manager
　SVR4/MKの主要アクタはPM（Process Manager), OM（Object Manager），およびSTM（Stream Manager） の三つであるが，ここでは簡単化のためにPMとOMで概要を示す（図14）．

　PMはユーザ（アプリケーション・プログラム）へのインタフェースを提供し，すべてのシステムコー ルはPMを通して処理される．PMではすべてのプロセスに関する情報を管理する．また，/procファイルシ ステムの実態を管理している．
　OMはメモリとストリーム以外のすべての資源に関する情報を管理する．また，Chorusの概念におけ るマッパーに相当する．ここでは，具体的にはPMはシステムコールからのインタフェース，OMはローカ ル・ディスク（ファイル）管理という面の機能のみに焦点をあてて説明を行なう．すなわち，それぞれの マネージャの別の機能面については触れない．またNFS（STMが関与）についてもここでは触れない（し かし，以下の説明で容易に想像できるだろう）．また，パス名解析の最終目標は対象とするファイル名の ケイパビリティを得ることである．

3.3.2　シングル・ノードにおけるパス名解析
　OPUSとは対照的にノードが一つしか存在しない場合を考える．この場合，OMはすべてのディスク を管理し，PMからの要求はすべてこのOMが受けることによって，解決できる．
　たとえばアプリケーション・プログラムからopen(2)システムコールが行われた場合を考える．この 場合，open()の引数であるファイル名はPMからOMへそのまま渡され，OMで該当するファイルのケイパ ビリティを作成すればよい．ファイルシステムのマウント・ポイントが存在したとしても，それはローカ ルにOM内で解決できるはずである．すべてのディスクに関する情報は単一のOMが把握している．した がって，PMはopen要求をOMに送り，OMは与えられたパス名を元にケーパビリティを返す，という単純 な構図によってパス名解析が行われる．図14：PMとOM内に書かれた矢印は，PMからOMへのopenサービ ス要求とOMからPMへのケイパビリティの返送を表している．

3.3.3　分散環境におけるパス名解析
　OPUSでは，ディスクは各ノードが保有し，それぞれのノードが個々のディスクを管理している．こ の環境下では，マウント・ポイントを通過するたびに，そのファイルシステムを保有するノードが変わる 可能性がある．したがって，3.3.2項で示したようなPMとOMが一対一で対応するのではなく，一つのPM からのリクエストに対し，複数のOMが関与する可能性がある．OPUSでは従来のPM，OMに大きな変更 を加えることなくパス名解析を行なうために，新たにPNM（Path Name Manager）と呼ばれるシステムア クタを導入している．PNMは一つのPMに対して必ず一つ存在する．現行では一つのノードに一つのPM が存在するため，言い替えると，一つのノードにかならず一つのPNMが存在することになる．PNMはPM とOMとの間の橋渡しをし，PMからパス名解析においてOMの存在を隠蔽する．図15にその概念図を示す．

　たとえば，アプリケーション・プログラムからopen(2)システムコールを呼び出す場合を考える．アプ リケーション・プログラムからのopenリクエストは，用意されたインタフェースを通して，PM内の該当 する関数を呼び出す．PMではパス名の解析が生じるため，そのパス名は一旦PNMへ送られる．PNMでは， 最近使用されたパス名をキャッシュしているため，キャッシュにヒットすると，同時に，OMにopenリク エストを出し，ファイルディスクリプタを返す．
　キャッシュにヒットしなかった場合，PNMはOMへopenの要求と共に，解析できたディレクトリまで のケイパビリティと，未解決部分のパス名を送付する．OMでは，要求を受けて解析できたパス名あるい はファイルのケイパビリティと未解決部分のパス名とを返し，PNMにその解決をキャッシュにロードす るように要求する．この動作を完全にパス名が解析されるまで繰り返し，最終的にOMからPNMを通して PMへファイルディスクリプタを始めとする情報が返る．アプリケーション・プログラムへはPMからファ イルディスクリプタが返されて，open(2)の呼び出しが終了する．
　この様子を図16に示す．

　これらの動作には，/(ルート）ディレクトリは必ずノード0に存在し，初期時にはすべてのノードのカ レント・ディレクトリが/(ルート）であるという大前提がある．PMは当然/(ルート）のケイパビリティを 保持している．また，マウント時には，マウントポイントのあるディスクを保有するノードのOMにマウ ントするファイル・システム（ディレクトリ）のケイパビリティが知らされている．PNMから見た場合， ケイパビリティがローカルノードのOMに対するものか，リモートノードのOMに対するものかという区 別は全くない．すべてはケイパビリティとipcCallによって，位置透過で操作される．
　PNMのパス名のキャッシュは「プレフィックス・キャッシュ」と呼ばれ，実際には「コンポーネン ト」と呼ばれる，単一のファイル名，あるいは単一のディレクトリ名単位で行われる．“/dir1/dir2/file” というパスをキャッシュを使ってパス名を解決する例を示す．/(ルート）ディレクトリのケイパビリティ をrootCap，それぞれのコンポーネントのケイパビリティをdir1Cap, dir2Cap, fileCapと表すと，表1のように して，パス名が解析される．

　今までは絶対パスについて触れたが，相対パスでも基本的には動作に変わりはない．解析を始めるディ レクトリのケイパビリティが/(ルート）からカレント・ディレクトリのものに置き換わるだけである．カ レントディレクトリ“．”と，親ディレクトリ“..”について，さらに考慮が必要である．カレントディ レクトリはすでに得られているディレクトリのケイパビリティを以って，パスの解析を終了する．親ディ レクトリについては，検索しているカレントディレクトリがマウント・ポイントすなわちファイル・シス テムのルートディレクトリである場合，それがリモートノードからマウントされたものである可能性があ る．この場合は，OMからPNMに対し，解析ができた（つまり，リモート・ノードのディレクトリの）ケ イパビリティと未解決部分のパス名と共に，解析を該当するOMに解析をフォワードするように依頼する． 最終的に解析が終了すると，PNMはPMへ要求されたファイルに対するケイパビリティを返す．

4.　お　わ　り　に

　OPUSシステムは，ハードウェア的にもソフトウェア的にも，すでに実績のある技術をベースにして 構築されたものであり，初期の狙い通り短期間で開発され，安定したシステムとして提供されている．昨 今超並列プロセッサのブームの中でも，本稿で紹介したSSI機能は，とりわけOPUSシステムの最大の特徴 になっており，操作・運用の容易性とアプリケーション移植性の容易性により，ますます多くのユーザに 使用されていくと期待されている．
　本稿では，紙面の都合上，テーマを局所化せざるを得なかったが，分散並列環境における処理のいく つかの課題とそのOPUSでの解決法についてご理解いただければ幸いである．
　最後になりましたが，本稿作成にあたって適切な助言を頂いたオープンプロダクト部内の室長各位， および，I&Cシステム第一本部システム二部長島部長に深く感謝致します．

---

用語解説

IPCインタフェース	：	Chorus/IPCは，信頼性のある要求/応答型の同期式通信へのプログラミ ング・インタフェースとしてipcCall/ipcReceive/ipcReplyシステムコールを，信頼性のない非同期式通信へ のプログラミング・インタフェースとしてipcSend/ipcReceiveシステムコールを提供する．
アクタ	：	資源獲得と分散の単位である．アクタはアドレス空間を定義し，そのアドレス 空間の中に一つあるいは複数のスレッドが存在できる．
ケイパビリティ	：	Chorus分散環境におけるユニークな大域名と認証の両方を意味するオブジェク ト．
サイト	：	一つのマイクロカーネルによって制御される計算機環境をサイトと呼ぶ．
スレッド	：	スレッドは実行の単位である．スレッドは，一つのアクタに属し，実行状態を 保持している．
ノード	：	OPUSハードウェアの一つのプロセッサ・ノードのこと．一つのプロセッサ・ ノードは一つのマイクロカーネルによって制御されるため，OPUSではサイトとノードは同義である．
ポート	：	Chorus/IPCにおいてメッセージの送受信を司るオブジェクト．メッセージは常 にポートに配送される．ポートはChorus分散環境の中でユニークな大域名を持つため，位置透過な通信が 可能となる．
メッセージ	：	Chorus/IPCにおける通信メッセージのこと．

---

[*1]　UNIXは，X/Openカンパニーリミテッドがライセンスしている米国ならびに他の国における登録商標である．
[*2]　ORACLE7は，Oracle社の登録商標である．
[*3]　Pentiumは，Intel社の商標である．
　その他，本稿に記載の会社名，商品名は一般に各社の商標または登録商標である．

---

参考文献

[ 1 ]　Unisys. White Paper, Hardware Overview.

[ 2 ]　Chorus Systems. CHORUS Kernel V3, Programmer's Guide&Implementation Guide.

[ 3 ]　Chorus Systems. CHORUS/MiX V4, Programmer's Guide&Implementation Guide.

---

---

執筆者紹介

石　川　　伸 (Shin Ishikawa)
　昭和25年生．49年名古屋大学理学部数学科卒業．同年日本ユニシス(株)に入社．2200シリーズOS，通 信プロダクト，SCFコンソールの受入/開発/保守に従事．現在，オープンプロダクト部オペレーティング システム一室に所属し，OPUS OSの受入/保守作業に従事．

五十嵐　　智 (Satosi Ikarashi)
　昭和37年生．平成2年新潟大学工学部電気工学科卒業．同年日本ユニシス(株)に入社．Unisys U6000 UNIX SVR4, Unisys S8400 OSの受入/保守に従事．現在，オープンプロダクト部オペレーティングシステ ム一室に所属し，OPUS OSの受入/保守作業に従事．

小　野　恭　嗣 (Yasushi Ono)
　昭和40年生．平成2年信州大学農学部砂防工学科卒業．同年日本ユニシス(株)に入社．UNIX OSI通信 ドライバ，Unisys SS-7 OS, Unisys S8400 OSの受入/保守に従事．現在，オープンプロダクト部オペレーティ ングシステム一室に所属し，OPUS OSの受入/保守作業に従事．

  

● 商標等について