分散オペレーティングシステム

各ロケール（通常はノード）において、カーネルはノードの基盤となるハードウェアとリソースを操作するために必要な、ノードレベルのユーティリティの最小限の完全なセットを提供する。これらのメカニズムには、ノードのリソース、プロセス、通信、および入出力管理サポート機能の割り当て、管理、および処分が含まれる。^{[ 5 ]}カーネル内では、通信サブシステムが分散OSにとって最も重要である。^{[ 3 ]}

分散OSでは、カーネルは多くの場合、低レベルのアドレス空間管理、スレッド管理、プロセス間通信（IPC）などの最小限の機能セットをサポートします。このような設計のカーネルはマイクロカーネルと呼ばれます。^{[ 6 ] [ 7 ]}そのモジュール性により、分散OSに不可欠な機能である信頼性とセキュリティが向上します。^{[ 8 ]}

システム管理コンポーネントは、ノードのポリシーを定義するソフトウェアプロセスです。これらのコンポーネントは、カーネル以外のOSの部分です。これらのコンポーネントは、より高レベルの通信、プロセスおよびリソース管理、信頼性、パフォーマンス、およびセキュリティを提供します。これらのコンポーネントは、単一エンティティシステムの機能に一致し、分散環境で必要とされる透過性を追加します。^{[ 3 ]}

OSの分散型の性質上、ノードがグローバルシステムに対して負う責任をサポートするために追加のサービスが必要となります。さらに、システム管理コンポーネントは、信頼性、可用性、永続性といった「防御的」責任も担います。これらの責任は互いに矛盾する可能性があります。一貫したアプローチ、バランスの取れた視点、そしてシステム全体に対する深い理解は、収穫逓減の兆候を特定するのに役立ちます。ポリシーとメカニズムを分離することで、このような矛盾を軽減できます。^{[ 9 ]}

分散オペレーティングシステムのアーキテクチャと設計は、個々のノードとグローバルシステムの両方の目標を実現する必要があります。アーキテクチャと設計は、ポリシーとメカニズムを分離するという原則に沿ったアプローチで行われなければなりません。そうすることで、分散オペレーティングシステムは、基盤となるコマンドと制御の取り組みに対するユーザーの認識を最小限に抑えつつ、効率的で信頼性の高い分散コンピューティングフレームワークを提供しようとします。^{[ 8 ]}

カーネルとシステム管理コンポーネント間、そして分散オペレーティングシステム内の個々のノード間における多層的な連携は、分散オペレーティングシステムの機能上の課題です。これは、システムにおいて目的の完全な調和を維持しつつ、同時に意図と実装の完全な分離を維持しなければならない部分です。この課題は、信頼性が高く、効率的で、可用性が高く、堅牢で、拡張性があり、スケーラブルなシステムの基盤とフレームワークを構築する機会を分散オペレーティングシステムにもたらすものです。しかしながら、この機会は複雑さという点で非常に高い代償を伴います。

分散オペレーティングシステムでは、その固有の複雑さが非常に大きいため、システム全体がユーザーにとって忌まわしいものになりかねません。そのため、分散オペレーティングシステムを実現する論理的なコストは、多くの領域とレベルにおける膨大な複雑さを克服するという観点から計算する必要があります。この計算には、最も控えめな実装であっても実現するために必要な設計投資とアーキテクチャ計画の深さ、広さ、範囲が含まれます。^{[ 10 ]}

これらの設計および開発上の考慮事項は、極めて重要かつ厳格です。たとえば、分散オペレーティングシステムの全体的なアーキテクチャと設計の詳細を非常に早い段階で深く理解する必要があります。^{[ 1 ]}分散オペレーティングシステムの開発には、膨大な数の設計上の考慮事項が内在しています。これらの設計上の考慮事項のそれぞれが、他の多くの考慮事項に大きな影響を与える可能性があります。そのため、個々の設計上の考慮事項とその多くの組み合わせに関して、バランスの取れたアプローチに多大な労力を費やす必要があります。この取り組みを支援するために、ほとんどの場合、分散コンピューティング能力に関する文書化された経験と研究に頼っています。

初期の取り組みの一つが、汎用同期コンピュータであるDYSEACでした。 1954年4月、Association for Computing Machinery（ ACM ）の初期の出版物の一つで、国立標準局（現在の国立標準技術研究所（NIST））の研究者がDYSEACの詳細な仕様を発表しました。序文では、柔軟な通信を含む想定されるアプリケーションの要件に重点が置かれていましたが、他のコンピュータについても言及されていました。  

最後に、外部デバイスには、DYSEACと同じデジタル言語を使用する他のフルスケールコンピュータも含まれる可能性がある。例えば、SEACやそれに類似した他のコンピュータをDYSEACに接続し、協調プログラムを使用することで、共通のタスクにおいて相互に協力して動作させることができる。その結果、コンピュータを使用して、すべての外部デバイスの多様な活動を効果的なアンサンブル動作に調整することができる。

この仕様書では、マルチコンピュータシステムのアーキテクチャについて論じられており、マスタースレーブ方式よりもピアツーピア方式が推奨されていた。

このような相互接続された複数のコンピュータからなるグループの各メンバーは、いつでもシステム内のパートナーに対して特別な制御命令を開始および送信することができます。その結果、共通タスクに対する監視制御は、最初はシステム全体に緩やかに分散され、その後一時的に1台のコンピュータに集中したり、必要に応じてあるマシンから別のマシンへと迅速に移行したりすることができます。…これまで説明してきた様々な割り込み機能は、コンピュータとそれに付属する外部デバイスとの相互協力に基づいており、単なるマスタースレーブ関係を反映したものではありません。

これは分散制御を備えたコンピュータの初期の例の1つです。陸軍省の報告書^{[ 20 ]}は、1954年4月に信頼性が証明され、すべての受入試験に合格したと報告しています。完成し、予定通り1954年5月に納入されました。これはトラクタートレーラーに搭載された「ポータブルコンピュータ」で、2台の補助車両と6トンの冷凍能力を備えていました。

実験的な入出力システムとして説明されているLincoln TX-2は、柔軟で同時動作可能な入出力デバイス、すなわちマルチプログラミングを重視していた。TX-2の設計はモジュール式で、高度な変更と拡張をサポートしていた。^{[ 12 ]}

このシステムは、多重シーケンスプログラム技術を採用していた。この技術により、複数のプログラムカウンタがそれぞれ32種類のプログラムコードシーケンスのいずれかに関連付けることができた。これらの明示的に優先順位付けされたシーケンスは、インターリーブして同時に実行することができ、処理中の計算だけでなく、シーケンスの制御フローやデバイスの切り替えにも影響を与えた。デバイスのシーケンス処理については、多くの議論がなされた。

DYSEACと同様に、TX-2では個別にプログラムされたデバイスを同時に動作させることができ、スループットが向上します。中央ユニットの全パワーはどのデバイスでも利用可能でした。TX-2は分散制御を示すシステムのもう一つの例であり、中央ユニットは専用の制御機能を持っていませんでした。

メモリアクセスを抽象化する初期の試みの1つは、セルがメモリ要素の集合で構成されていた相互通信セルでした。メモリ要素は基本的にバイナリ電子フリップフロップまたはリレーでした。セル内には、シンボルとセルの2種類の要素がありました。各セル構造は、名前とパラメータのセットからなるシンボルの文字列でデータを格納します。情報はセル関連付けによってリンクされます。^{[ 13 ]}

この理論は、アドレス指定は無駄で価値のない間接レベルであると主張した。情報へのアクセスは、直接検索と相互検索の2つの方法で行われた。直接検索は名前を受け取り、パラメータセットを返す。相互検索はパラメータセットを射影し、指定されたパラメータのサブセットを含む名前のセットを返す。これは、各キー（名前）に対して複数の値（パラメータ）を許容する修正されたハッシュテーブルデータ構造に似ている。

この構成は分散システムにとって理想的だった。メモリを介した定数時間射影による格納と取得は、本質的にアトミックかつ排他的であった。セルラーメモリの固有の分散特性は非常に貴重だった。ユーザー、ハードウェア／デバイス、またはアプリケーションプログラミングインターフェースへの影響は間接的だった。著者らは分散システムについて次のように述べている。

ここでは、分散論理システムの基本概念を紹介したいと考えました。スキャン、検索、アドレス指定、カウントといった処理から離れた、論理設計のマクロ的な概念も同様に重要です。私たちは、進化の段階が低い機械にしか当てはまらないような、詳細な局所的問題の負担から、何としても解放されなければなりません。

この点をより分かりやすく説明するために、集中型、分散型、分散型の3つのシステムアーキテクチャを検討してみましょう。この検討では、組織、接続、制御という3つの構造的側面を考慮します。組織とは、システムの物理的な配置特性を指します。接続とは、ノード間の通信経路を指します。制御とは、前述の2つの要素の動作を管理するものです。

透過性、あるいは単一システムイメージとは、アプリケーションが、分散システムであるかどうか、またハードウェアやその他の実装の詳細に関係なく、動作するシステムを処理できる能力を指します。透過性は、アクセス、場所、パフォーマンス、命名、移行など、システムの多くの領域でメリットをもたらします。透過性を考慮することは、分散オペレーティングシステムの設計におけるあらゆる側面での意思決定に直接影響を与えます。透過性は、他の設計上の考慮事項に特定の要件や制約を課す可能性があります。

システムは、特定のアプリケーション要件を満たすために、透過性をどの程度まで侵害するかを選択できます。たとえば、分散オペレーティングシステムでは、あるコンピュータ上のハードドライブを「C:」として、別のコンピュータ上のドライブを「G:」として表示できます。ユーザーはデバイスドライバやドライブの場所を知る必要はありません。アプリケーションの観点からは、どちらのデバイスも同じように動作します。透過性の低いインターフェースでは、アプリケーションがドライブをホストしているコンピュータを知る必要がある場合があります。透過性ドメイン:

• 位置の透明性– 位置の透明性は、名前の透明性とユーザーの移動性という2つの異なる側面から構成される。名前の透明性とは、システムエンティティへの物理的または論理的な参照において、エンティティの位置、あるいはユーザーやアプリケーションとのローカルまたはリモートの関係を示すものが一切含まれてはならないことを意味する。ユーザーの移動性とは、参照の発信元となるシステム上の場所に関係なく、システムエンティティを一貫して参照することを要求する。^{[ 8 ]： 20}
• アクセスの透明性– ユーザーインターフェースを通して見た場合、ローカルシステムエンティティとリモートシステムエンティティは区別できない状態を維持する必要があります。分散オペレーティングシステムは、システムエンティティがユーザーにとってローカルかリモートかに関わらず、単一のアクセスメカニズムを公開することでこの認識を維持します。透明性とは、ローカルかリモートかを問わず、特定のシステムエンティティへのアクセス方法の違いは、ユーザーには見えず、検出できないものでなければならないことを意味します。^{[ 3 ] : 84}
• 移行の透明性– リソースとアクティビティは、システムのみによって制御され、ユーザー/アプリケーションの認識や操作なしに、ある要素から別の要素へと移行する。^{[ 36 ]： 16}
• レプリケーションの透明性– リソースが別の要素に複製されるプロセスまたは事実が、システム制御下で発生し、ユーザー/アプリケーションの認識や介入なしに行われること。^{[ 36 ]： 16}
• 並行性透過性– ユーザー/アプリケーションは、他のユーザーの存在/活動を認識しておらず、影響を受けない。^{[ 36 ] : 16}
• 障害の透明性– システムはシステム障害の検出と修復を担当します。ユーザーはシステムが問題を解決するのを待つ以外に、知識や操作を必要としません。^{[ 9 ]： 30}
• パフォーマンスの透明性– システムは、ローカルまたはグローバルなパフォーマンスの低下を検出して修復する責任を負います。システムポリシーによっては、一部のユーザー/ユーザークラス/タスクが他のユーザー/ユーザークラス/タスクよりも優先される場合があります。ユーザーの知識や操作は不要です。^{[ 8 ] : 23}
• サイズ/スケールの透明性– システムは、ユーザーの知識や操作を必要とせずに、地理的範囲、ノード数、ノード機能レベルを管理する責任を負います。^{[ 8 ]： 23}
• 改訂の透明性– システムは、ユーザーの認識や操作なしに、システムインフラストラクチャのアップグレード、改訂、変更を担当します。^{[ 9 ]： 30}
• 制御の透明性– システムは、すべてのシステム情報、定数、プロパティ、構成設定などを、一貫した外観、意味、および指示で、すべてのユーザーとアプリケーションに提供する責任を負います。^{[ 3 ]： 84}
• データ透明性– システムは、ユーザーがデータの保存場所について知る必要も操作する必要もなく、アプリケーションにデータを提供する責任を負う。^{[ 3 ]： 85}
• 並列処理の透過性– システムは、ユーザーの知識や操作なしにタスク実行を並列化するあらゆる能力を活用する責任を負う。これは透過性において最も難しい側面であり、タネンバウムは分散システム設計者にとっての「聖杯」と表現している。^{[ 37 ]： 23-25}

プロセス間通信（IPC）とは、分散OSにおいて、ノード内およびノー​​ド間におけるスレッド間、プロセス間、そしてスレッド間およびプロセス間の一般的な通信、プロセス間相互作用、およびデータフローを実現するものです。ノード内およびノー​​ド間の通信要件は、低レベルのIPC設計を推進する原動力となります。これは、透過性をサポートする通信機能を実装するための典型的なアプローチです。この意味で、プロセス間通信は、分散オペレーティングシステムの低レベル設計における最も重要な基盤概念と言えます。

プロセス管理は、分散プロセス間でリソースを効果的かつ効率的に共有するためのポリシーとメカニズムを提供します。これらのポリシーとメカニズムは、プロセスとポートをプロセッサに割り当てたり割り当て解除したりする操作、およびプロセスの実行、一時停止、移行、停止、再開を行うためのメカニズムをサポートします。これらのリソースと操作は、互いにローカルまたはリモートのいずれであっても構いませんが、分散OSはシステム内のすべてのプロセスの状態と同期を維持します。

例えば、負荷分散は一般的なプロセス管理機能です。負荷分散はノードのパフォーマンスを監視し、システムがバランスを崩した場合にノード間でアクティビティを分散させる役割を担います。負荷分散機能の一つとして、移動させるプロセスを選択することが挙げられます。カーネルは、優先度に基づく選択など、複数の選択メカニズムを採用する場合があります。このメカニズムは、「最新のリクエスト」などのポリシーに基づいてプロセスを選択します。システムはこのポリシーを実装します。

メモリ、ファイル、デバイスなどのシステムリソースはシステム全体に分散しており、どのノードも常に軽負荷またはアイドル状態のワークロードを抱えている可能性があります。負荷共有と負荷分散には、アイドル状態のCPUの検出、移動のタイミング、移動対象の選択など、ポリシーに基づいた多くの決定が必要です。これらの決定を支援するアルゴリズムは数多く存在しますが、シナリオとその状況に最適なアルゴリズムを選択するためには、第2レベルの意思決定ポリシーが必要となります。

分散OSは、高い信頼性、つまりエラーを防止および/または回復する能力を実現するために必要なリソースとサービスを提供できます。障害とは、システムにエラーを引き起こす可能性のある物理的または論理的な欠陥のことです。システムが信頼できるためには、何らかの方法で障害の悪影響を克服する必要があります。

障害に対処する主な方法には、障害回避、障害耐性、および障害検出と回復があります。障害回避とは、障害の発生を最小限に抑えるために講じられる予防措置を指します。これらの予防措置には、トランザクション、レプリケーション、バックアップなどがあります。障害耐性とは、障害が発生してもシステムが動作を継続できる能力のことです。障害が発生した場合、システムは障害を検出し、完全な機能を回復する必要があります。いずれの場合も、あらゆる措置は単一のシステムイメージを維持するために最大限の努力を払う必要があります。

可用性とは、システムが要求に応答できる時間の割合のことです。

パフォーマンスを定量化するベンチマーク指標は数多く存在します。スループット、応答時間、単位時間あたりのジョブ完了数、システム利用率などがその例です。分散OSにおいては、パフォーマンスは多くの場合、プロセス並列性とIPC（プロセス間通信）のバランスによって決まります。並列処理のタスク粒度を、サポートに必要なメッセージ数との適切な関係で管理することは非常に効果的です。また、データをコピーするのではなく、プロセスをデータのある場所に移行する方が有利な場合を特定することも効果的です。

協調して動作する並行プロセスには、変更が正しく予測可能な方法で行われることを保証する同期が本質的に必要です。この必要性の範囲を定義する3つの基本的な状況は次のとおりです。

• 1つ以上のプロセスが特定の時点で同期しなければ、他の1つ以上のプロセスは継続できない。
• 1つ以上のプロセスは、続行するために非同期条件を待機する必要があります。
• または、プロセスが共有リソースへの排他的アクセスを確立する必要がある。

不適切な同期は、原子性、一貫性、分離性、耐久性の喪失、デッドロック、ライブロック、直列化可能性の喪失など、複数の障害モードにつながる可能性があります。

分散オペレーティングシステムの柔軟性は、分散OSのモジュール特性と、より豊富な高レベルサービスの提供によって向上します。カーネル／マイクロカーネルの完全性と品質は、こうしたサービスの実装を簡素化し、サービスプロバイダーがサービス提供者をより幅広く選択できる可能性を高めます。

 E1分散オペレーティングシステムのアーキテクチャ設計^{[ 38 ]}  Cronus分散オペレーティングシステム^{[ 39 ]}  MINIX分散オペレーティングシステムの設計と開発^{[ 40 ]}

デナリ隔離カーネルにおけるスケールとパフォーマンス。^{[ 41 ]}

マルチカーネル：スケーラブルなマルチコアシステムのための新しいOSアーキテクチャ。^{[ 42 ]}

Corey: マルチコア向けオペレーティングシステム。^{[ 43 ]}

Almos: cc-NUMA マルチコア向け高度局所性管理オペレーティングシステム。^{[ 44 ]}

Helios: サテライトカーネルを使用した異種マルチプロセッシング。^{[ 45 ]}

Tessellation: Manycore Client OS における時空間分割。^{[ 46 ]}

分散オペレーティングシステムコンピューティング（DOSC）は、組み込みオペレーティングシステム機能を持つ「アプリケーションオブジェクト」を介してアプリケーションソフトウェアを実装するコンピューティングパラダイムです。実装例としては、Webサーバー^{[ 47 ]} 、 VoIP ^{[ 48 ]}、ファイルシステム^{[ 49 ]}などがあります。