図8.14はシナリオ実行の所要時間を示している。シナリオ実行の所要時間はノー ド数に関係ないことが見て取れ、100ペア程度の実験であれば、制御性能は十分で あることがわかる。人手により実験を実行した場合には、各ノードでコマンドを 入力することになり、これだけの短時間で実験を終了させることは困難である。
また、図8.17からは、ディスクコピーの所要時間が実験所要時間の大半をしめ ることが見て取れる。ディスクイメージの変更が必要なければ、シナリオでノー
ドをshutdownせず、繰り返し実験に利用することができる。その場合は、利用す
る実ノードとシナリオ内の論理ノードの対応を記述し、masterにディスクコピー をさせないように実行する。これにより、ディスクコピーが必要ない、小さなパ ラメータの変更のみによる再実験などを効率的に行える。
本節では、masterが実行している時間を所要時間として表現してきた。しかし
実際にはmasterを実行するだけで、設定記述に記された実験はすべて自動で行わ
れる。したがって、200台の実験であっても、設定記述を用意しmasterを実行す れば実験実行者は実験が終わるまで、別の作業をすることができるため、実験実 行者の実験への拘束時間は非常に小さい。
表 8.5 〜 8.11に示したとおり、台数に関わらず実施した3回の計測結果の値の 分散は小さかった。これにより、StarBEDおよびSpringOSが安定していること がわかる。
これらから、StarBEDおよびSpringOSでは、以下の2点を達成したといえる。
• 人手で構成することが現実的でないような構成での実験を容易に実行できる
• 何度実行しても同様の結果が得られる
人手で実験を実行するには時間的に現実的でないという点だけでなく、多数の 設定が必要になる実験では、すべての設定を間違いなく行うことは困難である。
SpringOSを利用すれば、機械的に多数のノードの設定およびシナリオ実行が行わ
れるため、ある程度の再現性を確保しているともいえる。
また、すでに4.1 章で述べたように、StarBEDおよびSpringOSを用いて行われ た実験も数多く、SpringOSをStarBEDよりも小規模な環境に導入している組織 も存在する。このようなことからも、StarBEDおよびSpringOSは有用であると いえる。
第 III 部
より高度な実験支援環境の
構築にむけて
第 III 部では、より高度な実験支援のための議論を行う。
第II 部では大規模実証環境の一実装としてStarBEDおよびSpringOSの詳細に ついて述べた。このような経験から9 章では、大規模実証環境に一般的に必要と なる機能を整理する。これにより、実験実行者が、既存の大規模実証環境の機能 を、利用できる大規模実証環境を選択できる。また、その機能を実現するための アーキテクチャを整理し、複数の大規模実証環境の協調による、一つの実験駆動 単位の構築の実現可能性を示す。
大規模実証環境とソフトウェアシミュレータでは、実験駆動単位の構築と実験 実行の支援を行い、実験を容易かつ正確に実行できる。これらを利用するために は、事前に実験内容の決定が必要であるが、実験実行者が実験内容を決定した場 合には、不適切な実験が行われる可能性がある。10 章では、実験実行環境に入力 する実験内容の決定支援に関する議論を行う。
第 9 章
汎用的な実験支援ソフトウェアの アーキテクチャの提案
本章では、これまでの経験にもとづき、実験支援ソフトウェアに必要な機能を 整理し、さらに、それらを実現するアーキテクチャを提案する。また、StarBED だけでなく、その他の実験設備との協調し、実験駆動単位に複数の実験設備を利 用することで、大規模化が可能なだけでなく、より柔軟な実験を行うことができ ると考えた。これを実現することも、本アーキテクチャの目的のひとつである。
実ノードを利用した環境での実験の手順については、5.1 節で述べた。本章で対 象にするのは、図 5.3のうち、実験駆動単位の構築および実験シナリオの実行に 関わる手順2から手順6とする。
9.1 大規模実証環境に求められる機能の実現
5 章で、大規模実証環境で実現する必要がある要件について述べ、StarBEDお
よびSpringOSの設計・開発とその評価について述べた。本節では、これらの経験
をふまえた上で、より汎用的な支援ソフトウェアへの要件をまとめる。
ただし、本アーキテクチャでは以下の点を前提とする。
1. 実験実行者は必要な資源を大規模実証環境に要求し、割り当てを受けその資 源を用いて実験駆動単位を構築する。
管理用ネットワーク 実験用ネットワーク
実験用ノード
管理用ノード
図 9.1: 想定する実験設備のトポロジ
StarBEDと同様に管理用と実験用のネットワークが分離されている ことを前提とする。これによりトラフィックの相互干渉を防ぐととも に、管理用ネットワークを通して実験用のネットワークを自由に再構 成できる。
2. 同時に複数の実験実行者が大規模実証環境を同時に利用でき、大規模実証環 境上に複数の実験駆動単位が生成される。
3. 実験駆動単位を構成するノードのネットワーク設定を実験実行者の意図どお りに行うため、実験用とは別に管理用のネットワークが用意され、すべての ノードが管理用ネットワークに接続されている。
図 9.1に前提とするトポロジの概念を示す。
9.1.1 資源管理および資源割り当て
実験実行のためには、大規模実証環境に存在する資源の情報を管理し、実験実 行者に割り当てる必要がある。この機能を持つモジュールをリソースマネージャ
と呼ぶ。
リソースマネージャが管理するべき資源は、大規模実証環境の実装にも依存す るが、ノード、帯域などがあり、実験ネットワークをVLANを利用して構築する 場合は、VLAN番号も資源情報として管理される。また、実験駆動単位の制御機 構が動作するノードも資源として管理される。
リソースマネージャには、大規模実証環境の資源を管理するだけでなく、資源 を実験駆動単位または実験実行者に割り当てる機能も必要である。実験実行者は 設定記述として、それぞれのノードやリンクに必要とする機能を記述する。この 設定記述にしたがい、実験駆動単位を制御するモジュールが、大規模実証環境の リソースマネージャに割り当て要求を行う。リソースマネージャはこの要求を満 たすノードを何らかのアルゴリズムで選択し割り当てる。また、基本的には割り 当てたノードを別の実験実行者に割り当てないよう排他制御を行う。
大規模実証環境での実験の実行方式として、利用する時点で資源が空いている かどうかを確認し、空いていれば実験実行するといったバッチ型の実行方式もあ るが、ある期間に必要数のノードを確保しておき、実験を行う方式も考えられる。
柔軟な実験制御のためには両方式に対応することが望ましい。資源をある期間、実 験実行者に割り当てる場合は、予約状況も資源の情報として保持されなければな らない。
9.1.2 資源利用の排他処理
大規模実証環境によっては、資源は単一の実験実行者に占有されるばかりでは なく、複数の実験実行者に共有される可能性がある。これにより、大規模実証環境 上の資源をより効率的に利用できる。このためには、実験実行者が必要としてい る資源に応じて共有できるかどうか、共有できるのであればその程度などが考慮 されなければならない。ノードが共有される場合は、CPUやメモリの量などから 共有が可能であるかが決定され、リンクについては必要な帯域や、許容できる遅 延などの情報をもとに共有できるか判断される。大規模実証環境によっては、リ ソースマネージャが、資源共有のためのアルゴリズムを持っている必要があるが、
実ノードを用いている場合は、指定した値でノード負荷やネットワーク特性を固
定することは不可能であるため、実験実行者による機能要求は、ある程度の範囲 での指定を行うこととする。
ノードやリンクの割り当ての排他制御についてはすでに述べたとおり、リソー スマネージャが管理する。これに加え、実際に資源に操作を行う際に、その実験 実行者が対象の資源に対して操作が許されるのか、また、どの程度許されるのか を判断し、実際の操作を制限する必要がある。たとえば、大規模実証環境の中心 となるリンクなどは、複数の実験実行者により共有される可能性は高い。このよ うな場合にはその他の実験に対して影響をおよぼさないよう、管理される必要が ある。共有されたリンクへの設定は、その実験実行者に割り当てられた範囲での 設定のみに制限されるような機構が必要となる。リンク以外でも、共有される可 能性のある資源の割り当てやそのような資源に対する操作を行う機構では、同様 の排他制御を行う必要がある。
9.1.3 設定読み込みおよび実験駆動単位の生成
実験を実行するためには、実験駆動単位を生成する必要がある。実験駆動単位 は制御モジュールと実験用ノードで構成され、実験用ノードは制御モジュールに より施設から割り当てられ、管理される。したがって、実験駆動単位を構成する ためには、まず、制御モジュール群を起動しなければならない。
このためには、制御モジュール群が動作するノードの割り当てが必要である。割 り当て要求は入力された設定記述から、実験の規模などを考慮して行われ、リソー スマネージャはそれを満たす機能を持つノード群を割り当てる。このようにして 起動された制御モジュール群は設定記述を詳細に読み込み、実験資源を確保し、実 験駆動単位を生成する。
9.1.4 ノード制御
ノードを柔軟に制御することにより、ノードの初期設定だけでなく、リンクの 特性の制御や、トポロジの構成変更などさまざまな機能が実現可能である。本節 ではこれらの機構についてまとめる。