日時：2006年12月14日(木) 18:30 から
場所：東京大学 本郷キャンパス 工学部2号館 4階 245号講義室（旧25号講義室）（地図）
話者：
金田憲二（グーグル株式会社）
話題：
実行環境の動的な変化にユーザが適応することを可能にするためのミドルウェアシステム
概要：
動的に参加・脱退する計算資源を効率的に利用するためのミドルウェアシス
テムについて述べる．
近年その重要度が増しつつある，計算機のクラスタやグリッドは，動的に変 化する環境である．資源共有や故障などの原因によって，アプリケーションが 利用可能な資源の質は絶えず変化する．例えば，デスクトップPCなどの非占有 マシンは複数の利用者によって共有されるため，その可用性が動的に変化する． 数百のノードからなるシステムにおいては，マシン・ネットワークの故障が頻 繁に起こり得る．このような資源の可用性が動的に変化することが，クラスタ やグリッドの普及への大きな障害となっている．
本研究の目標は，利用者が自分の実行環境の変化に適応し，動的に変化する 資源を有効利用することを可能にすることである．この目標に向けて，我々は， それぞれ異なる焦点を持つ2つのアプローチで取り組む．一つのアプローチは， 地理的に分散した大規模環境上での並列プログラミングのための枠組みを構築 することに焦点を置いている．もう一つのアプローチは，単一システムイメー ジを提供し，動的に変化する資源を簡便に利用可能にすることに焦点を置いて いる．前者のアプローチのために，我々は， Grid-enabled メッセージパッシ ングライブラリと，遠隔ジョブ投入のためのコマンドシェルを設計・実装した． 後者のアプローチのために，単一システムイメージを提供するための仮想マシ ンモニタを開発した．
出席者：29名
伊知地宏（ラムダ数教研）、並木美太郎、（農工大）、石畑清（明治大）、 尾上浩一、三輪誠、大住裕之、島本大輔、淺川浩紀、稲葉一浩、田中哲朗、 筧一彦、笹田耕一、金子知適、横山大作（東大）、浜地慎一郎（東大、NII）、 三廻部大、黒田滋樹（東工大）、東達軌、山口文彦（東京理科大）、 吉田紀彦（埼玉大）、首藤一幸（ウタゴエ）、須崎有康（産総研）、 伊藤宏通（びぎねっと）、齊藤正伸（IIJ）、匿名希望1名、 小林弘明（元電通大）、岩崎英哉、寺田実、丸山一貴（電通大）
・プロセスの上に仮想ノードが載っている、という図だが、そう言う構造なのか。 はい。 ・仮想ノード名は誰が管理するのか。 プログラマが管理する。 ・マシンの追加や削除はどのように認識されるのか。 仮想ノード名の委譲で伝える。 たとえば、新たに追加されたマシンは、他のマシンから仮想ノード名を受け取る。 削除されるマシンは、自分に割り当てられた仮想ノード名を、他のマシンに渡す。 ・1つのプロセスが複数の仮想ノード名に対応するようだが、別個の計算が1つの プロセスに含まれてしまっていることのデメリットは。 デメリットは、個々の仮想ノードと対応する計算のロジックや状態を、 プログラマが明示的に管理する必要のあること。 ・ph_assumeとph_releaseの引数は集合か。これらは個々のプロセスが実行するのか。 名前の重複はどう管理するのか。 ph_assumeとph_releaseの引数は集合。これらの関数は、個々のプロセスが呼び出す。 名前の重複が起こらないように、プログラマが管理する必要がある。 重複を回避する簡単な手段としては、プロセス間で、仮想ノード名をmigrationする ようにすればよい。 ・ph_sendの引数に仮想ノード名を指定する場合、そのノードが自分かどうかは 事前にチェックするのか。それとも自分であってもうまくいくのか。 どちらでもよい。メッセージの送信先の仮想ノード名を自分がassumeしている場合には、 そのメッセージは自分に届く。 そのため、チェックをしない場合には、メッセージを受信する処理の側で対応することができる。 ・それぞれの物理ホストが全て、仮想ノード名と物理ホストの対応表を持っているのか。 物理ホストが何台までならscalableか。多くなるとオーバヘッドが出そうだが。 基本的には、れぞれの物理ホストが全て、仮想ノード名と物理ホストの対応表を持っている。 実際にはルーティングを行っている。 実験では、大体~300ぐらいまでスケールする。 ・物理ホストの1台が故障した、というのはライブラリが判断して吸収するのか。 そうでない場合、故障の検知はどのようにするのか。 故障を検知したとしても、アプリケーションプログラムはノード番号の割り当てが 分からないとうまく動かないのか。 故障を検知するシステムはある（堀田勇樹くんによる研究）。 故障検知システムは、故障によって失われた仮想ノード名をアプリケーションに 通知するので、その情報をもとに、アプリケーションプログラムはノード番号の再割り当て をすることができる。たとえば、欠けた仮想ノードが出てきた場合、 それと隣り合う仮想ノードをもつプロセスが、欠けた仮想ノードを担当するようにする。 ・マシンの増減がないときでも、単位時間あたりの仕事量の実測値がかなり上下 しているのはなぜか。 マシンの増減後も、ルーティングなどの更新処理が完了していないため。 ・単位時間あたりの仕事量の理論値はどのように導いたのか。 単純に、(一台のマシンでの平均仕事量) x (その時点でのマシン数) 。 ・更新メッセージの重複送信の回避方法と、動的なスパニングツリーとの比較は。 我々の方が、直接通信可能なマシン間では、直接コネクションが確立されるため、 アプリの通信に余分なメッセージのrelayを必要としない。 その反面、スパニングツリーの方が、オーバレイネットワークの構築・経路計算などの オーバヘッドは小さい。 ・ゲートウェイがない場合は完全グラフができるのか。 できる。 ・プロセッサ数が5000や10000まで行ったとき、中央サーバ方式を超えることは できるのか。 ルーティング表構築のオーバヘッドという点では、 中央サーバ方式を超えることは難しい。 ・仮想SMPの場合、仮想マシンのメモリサイズは、実マシンの中で実装メモリの 最も小さいもののサイズに束縛されるのか。 はい。 ・fib以外の実例はないのか。GCCを複数プロセッサで行うとか。 NAS parallel benchmarkがある。博士論文を参照。 ・仮想SMPマシンでも動的再構成をする場合、1台が抜けるときは全てのVMを 停止してやるのか。もっといい方法はあるか。 今現在は、すべての仮想プロセッサの状態を止めている。 既存のVMのmigrationの手法などを利用して、停止時間を削減することは可能。 ・Linuxカーネルのバージョンに依存していると思うが、そのバージョンは。 新しいカーネルに対しても適用しやすいのか。 適用しやすい。LilyVMとほぼ同様の変更を、各カーネルに対してすればよい。 ・IA32なら問題ないのか。IntelとAMDの混在は可能か。HyperThreadingは 対応しているか。 混在は可能。各仮想プロセッサがユーザプロセスとして実装されているので、 HyperThreadingのあるマシンで、複数ユーザプロセスを立ち上げることは可能。 ただ、そうしたプロセス間でメモリの共有が可能な場合もTCPで通信してしまっている。 ・実装に使っているptraceは負荷が高いと思うが、他の方法はなかったのか。 ユーザランドより低いレイヤーでの実装はどうか。開発時のデバッグの しやすさはどうか。 ハードウェアの上に直にVMMを置く実装も可能だが、開発コスト大。 開発を始めた時点では、Xenもなかった。 デバグも難しい。 ・仮想SMPのメモリサイズを実マシンの合計にするのはどの程度大変か。 実装すること自体は可能。ただ、もちろんオーバヘッドは大きくなる。 ・Phoenixのノードの減少では、チェックポイントを行うのか。 行わない。 ・静的にパフォーマンスチューニングすることは可能か？ MPIと比べて、メモリの取り方の違いはどうか。 静的にパフォーマンスチューニングすることは難しい。 ・仮想SMPで、共有ページのディレクトリ管理はどうなっているか。 ハッシュテーブルに似たデータ構造。 ・ある種のソフトウェア分散共有メモリを実現していると思うが、既存の 仕組みを使わなかった理由は。 メモリの仮想化として、共有メモリの管理とアドレス変換の処理を同時に行う必要があるため、 既存のDSMをそのまま利用するのは難しい。 ・計算機間の情報共有における、ネットワークの信頼性は。TCPにおまかせか。 ネットワーク効率を上げる方法に関する知見はあるか。 実際の仕様ネットワークはGigabitEthernetか。 TCPにおまかせ。 UDPを使って自前で信頼性の管理を行ったり、メモリコピーの回数を減らして 通信性能を上げることは可能。 実際の仕様ネットワークはGigabitEthernet。 ・VMのMigrationはどの程度まで実現できているか。ネットワークはどうか。 仮想プロセッサのmigrationは可能。ネットワークデバイスなどの 仮想化、migrationは未実装。