SR（サービスリゾルバ）配置機構 東京大学大学院工学系研究科 青山・森川研究室 修士2年 大石 佳敬 1 研究の背景 ネットワーク上に偏在する機器間の接続が自動 的になされる世界 プラグアンドプレイの普及･進化 Jini、UPnP、SLP・・・ サービス提供アーキテクチャに関する研究 DANSE、VNA、STONE・・・ ディレクトリサービスが重要な位置を占める 2 ディレクトリサービス 目的 サービス自身の定期的広告 ユーザがサービスを発見するためにブロードキャスト 冗長性・帯域浪費低減 STONE SR（サービスリゾルバ）がディレクトリサービスとしての 役割を保持 SRはマニュアルで配置 配置数などは固定的 3 SRの配置数に関する考察 SRが過少 負荷が集中し、結果的に応答時間が増加 耐障害性低 SRが過多 リソースに達するまでに、無駄なホップ数重ねることで、ユーザ要 求等に対する応答時間が増加 ディレクトリサーバを置く意味が低下 SRを適切な数に保つことは重要 ネットワーク帯域 SRの性能 リソース数 仮定：リソースは潜在的にSRとしての能力を保持 4 SR配置機構（１） 目的 SRを用いた際のサービス発見までの平均的な応答時 間の向上 負荷分散 ディレクトリサーバ ネットワーク 耐障害性の向上 SR配置にかかる管理の為の人的コスト低減 5 SR配置機構（２） 動作 SR（サービスリゾルバ）側 SRの生成・消滅 SR間のConnection追加・変更 Name Caching リソース（サービス / 機能）側 登録先SR変更 自身の複製生成や移動（Mobile Code) 6 SR側動作 SRの生成・消滅 SRを適応的に配置 配置数：ユーザ要求の頻度、サービス数などに応じて SRを配置 位置：サービスやユーザの位置から判断される妥当 な物理的位置にSRを配置 負荷分散 応答性向上 7 SR側動作 SR間のConnectionの追加・変更 応答時間向上の為のショートカットの作成 あまりにも沢山ショートカットを作成すると、更新情報氾濫 リゾルバの負荷分散の為の迂回路の作成 これだけだと本質的解決にはならない！ 特に迂回路形成に関しては、良く参照されるリソースを直接管理 するSRはどうしても負荷が増加 「リソース側アプローチの登録SR変更」との組み合わせが必要 辛いよ～。 SR サービス / 機能 8 SR側動作 Name Caching 機能偏在化を容易にするために必要 解決率UP 応答時間向上 オブジェクトの実体を複製するわけではないので。 負荷分散にはならない 複製の出来ないオブジェクトに対して有効 9 リソース側動作 登録先SR変更 登録先SRを変更、もしくは複数のSRに登録 SR SR SR ：サービスリゾルバ ：リソース ：登録先SR変更を しようとしているリソース 変更前 SR SR SR SR 登録先変更 登録先の多重化 •直接的な管理負荷の移譲 •クエリー数の低減 10 リソース側動作 自身の複製生成や移動（Mobile Code) 複製可能なリソース（プログラム、データ等）であ れば、参照頻度などに応じて自身の複製を作成 ネットワーク上の適切な位置に移動 適切な＝ユーザに対する応答時間向上、SRやネット ワーク帯域の負荷分散 11 SR配置機構（３） 動作のためのトリガ情報 SRの負荷状態 履歴情報 リソースに対するアクセス頻度 クライアント（要求元ユーザ・要求先リソース）の位 置情報 ユーザ要求に対する応答時間 12 SR配置機構の存在形態 SR自体が水平分散的に配置 SR配置機構も分散型を利用 集中型 SR配置機構 分散型 この辺にリゾル バがあったほう がいいよ！ この辺にリゾル バがあったほう がいいよ！ SR サービス / 機能 13 SR配置機構に関するシミュレーション SR配置機構の動作 リソース側動作の「自身の複製生成や移動」は除く 動作のトリガとなる情報 SRの負荷状態 確認項目 負荷分散：それぞれのSRの保持する負荷のバランシ ング 安定動作：生成・消滅といった相反する動作によるシ ステムの発散を抑制 14 まとめと今後の課題 まとめ SR配置機構の基本動作 それぞれの動作に関して概説 現在シミュレーションを開始。近日中に結果 今後の課題 履歴情報等を利用した、よりインテリジェントなシステ ム 配置位置を決定するアルゴリズム STONEへの実装 15
© Copyright 2024 ExpyDoc
