• 検索結果がありません。

サーバ動的切り替えの性能

4.3 評価

4.3.1 サーバ動的切り替えの性能

F-Omegaの自動ステアリングシステムによって適切なサーバ切り替えが自動的に

なされるかを検証するべく,サーバ動的切り替えの動作実験を行った.実験設定は 次のとおりである.

4.3 評価 47

サーバ運用計画ファイルに記載されるサーバ稼働状況の計画的変動は,サーバ のメンテナンスと外乱ジョブによるとした.

メンテナンス 任意の期間,サーバ全体をあらわす serverサービスか,あるい は他のサービス(4.2.1節を参照)のいずれか1つを利用不可にする事象 である.

外乱ジョブ (事前予約を用いるジョブを想定し)サーバ上で利用可能なプロ セッサ数(job maxNoOfCPUsサービスの値)を任意の期間減少させる事 象である.

なお,本実験ではサーバのメンテナンスや外乱ジョブを実際には発生させず,

それらに関するシミュレーションで求まるサーバ稼働状況の計画的変動をサー バ運用計画ファイルに設定するのみとした.

サーバの運用計画には次を仮定したシミュレーション結果を用いた.

各サーバにおいて,メンテナンスが一ヶ月間に計2回発生する.各メン テナンスでは6種類のサービスのうちランダムに選ばれた1つが利用不 能となる.発生日時を一様乱数で与え,長さを1時間から3日の間の一 様乱数で与えた.

各サーバにおいて,外乱ジョブが一ヶ月間に5回発生する.発生日時,外 乱ジョブが占有するプロセッサ数を一様乱数で与えた.また,長さを1時 間から3日の間の一様乱数で与えた.外乱ジョブが用いるプロセッサ数 を一様乱数で設定した.

これらの頻度・長さに関する仮定は次から算出した現実的な値である.(1)AIST スーパークラスタ[61]の運用に関する電子メール,(2)TeraGrid[14]のシステ ムイベントカレンダー.算出方法の詳細を付録Bに載せる.

サーバ利用方針には次の2通りを用いた.

利用方針1. 利用するプロセッサ数を最大12に制限した.また,サーバプログ ラムの起動に3種類のサービスが稼動していることを条件とした.

 この利用方針の場合,ユーザの要求するプロセッサ数がサーバ運用計 画で定まるプロセッサ数よりも少ない.

4.3 評価 48

利用方針2. 利用するプロセッサ数を30とした.サーバプログラムの起動に1 種類のサービスが稼動していること(具体的には,サーバが動作してい ること;選択時に常に真となる)を条件とした.

 この利用方針の場合,ユーザの要求するプロセッサ数がサーバ運用計 画で定まるプロセッサ数よりも常に多い.

本実験における「適切なプロセッサ利用」は,サーバ管理者がサーバ運用計画で 定める利用可能プロセッサ数と,ユーザがサーバ利用方針で要求するプロセッサ数 のうちの,最小値である.

利用方針1. を設定した動作実験において実際に利用されたプロセッサ数の推移を 図14に示す.図中の「実際の利用」では,変化のない期間に限り,間引いてプロッ トしている.また,サーバ運用計画のみで決まる利用可能プロセッサ数と,サーバ 利用方針で要求するプロセッサ数も示す.図14より,2.7日間にわたって,実験中 に利用されたプロセッサの数が,サーバ利用方針で要求したプロセッサ数に追随し ていることがわかる.グラフ中の11月25日9時頃では,運用計画に基づいた代替 サーバへの切り替えの振る舞いを確認できる.なお本条件では,アプリケーション の実行を妨げる,サービスの稼働状況の変動が計9回生じたが,計算が正しく継続 された.

同様に,利用方針2. を設定した実験における,利用プロセッサ数の推移を図15 に示す.図15から,利用方針2.においては,実験中に利用されたプロセッサの数 が,サーバ運用計画で定められたプロセッサ数に追随していることがわかる.なお 本条件では,アプリケーションの実行を妨げる,サービスの稼働状況の変動が計9 回生じたが,計算が正しく継続された.

以上より,F-Omega の自動ステアリングシステムによって,(F-Omegaのイベン ト駆動型プログラミングモデルで書かれた)GridRPCアプリケーションが利用する サーバが,サーバ運用計画とサーバ利用方針に応じて自動的に適切に切り替えられ ることを示した.

考察

グリッドアプリケーションのサーバ利用の振る舞いとサーバ切り替えに要するコ ストに関して,以下のように,提案する枠組み F-Omega の方が従来方式よりも優 れている.すなわち,この点で,提案する枠組みの有用性が高いといえる.

4.3 評価 49

図 14: 実験中の利用プロセッサ数の推移(利用方針1.)

4.3 評価 50

図 15: 実験中の利用プロセッサ数の推移(利用方針2.)

4.3 評価 51

サーバ自動管理機構を持たない従来のGridRPCミドルウェア(Ninf-G)を用い た場合,サーバを動的に変更できず,アプリケーションを長時間実行することが困 難である.なぜなら,サーバを動的に変更する機構を持たないため,サーバに障害 が発生するにつれて,アプリケーションで利用できるサーバが減る一方であるから である.

サーバ監視機構と連携しないサーバ管理機構を持った並列プログラミングミドル ウェア(Phoenix[22],ProActive[62]等)では,サーバ監視とサーバ切り替え指示の ためのコストが莫大となり,適切なサーバ利用を長時間維持し続けるのが難しい.こ の方法では,ユーザは,サーバ毎にサーバ運用に関する電子メール・ウェブページ 等を読み,サーバ群全体から適切なサーバを選択し,アプリケーションにサーバ切 り替え指示を与えなければならない.今回の実験のように,サーバ稼動状況が数時 間おきに度々変動するグリッドにおいて,ユーザはこの作業を数時間毎に定期的に 行わなければならず,作業コストが大きい.ユーザはおそらく2,3回程度で断念し,

その結果,適切でないサーバ利用が発生すると考えられる.

F-Omegaの場合,実験で示したように,ユーザが一切介入せずに,自動的に適切

なサーバ切り替えが行われ,アプリケーションを長時間安定実行できる.