スケジューリングシステムとレプリカ管理システムによるデータインテンシブアプリケーション実行環境

Size: px

Start display at page:

Download "スケジューリングシステムとレプリカ管理システムによるデータインテンシブアプリケーション実行環境"

よいかずももき
3 years ago
Views:

1 レプリカ管理システムを利用したデータインテンシブアプリケーション向けスケジューリングシステム町田悠哉滝澤真一朗, 中田秀基, 松岡聡 : 東京工業大学 : 産業技術総合研究所 : 国立情報学研究所

2 研究背景グリッド環境で扱われるデータサイズの大規模化物理学天文学バイオインフォマティクス etc 同一データセットを利用する均質なタスクの集合バッチジョブとしてサブミットバッチスケジューリングシステムによる実行マシンの決定バッチスケジューリングシステムにおけるデータ利用法分散ファイルシステムを利用したデータ共有データ転送機構を利用した単純なステージング

3 グリッド環境での大規模データ処理グリッド環境での大規模データ処理シナリオデータ転送ツールを利用したデータステージングデータ転送元転送先の選択ジョブサブミット時にユーザが決定レプリケーションアルゴリズムにより決定ユーザがサブミットしたデータ解析ジョブをスケジューリングシステムが実行マシンを決定分散ファイルシステム (NFS, AFS, etc) によるデータ共有転送ツール (GridFTP, Stork, etc) によるステージングデータ転送とジョブスケジューリングが独立

4 問題点 - 共有手法分散ファイルシステムなどを利用したデータ共有 Scheduler Data Server Submit Machine task F Job I/O ノードにおいてアクセス集中が発生

5 問題点 - ステージングデータ転送機構を利用した単純なステージング Submit Machine Scheduler task Job F I/O ノードにおいてアクセス集中が発生

6 問題点 - ステージングデータ転送機構を利用した単純なステージング Submit Machine Scheduler task F 同一データの非効率な転送が発生

7 問題点 - データの複製データレプリケーションデータの複製 ( レプリカ ) を作成してアクセスを分散ポリシーに応じたレプリカの作成削除 1 対 1 転送を想定しているためアクセス集中発生ジョブスケジューリングとは独立なレプリケーションデータインテンシブアプリケーションを効率的に実行するためのシステムとして十分ではない

8 研究目的と成果研究目的グリッド環境でデータインテンシブアプリケーションを効率的に実行するためのスケジューリングシステムの構築研究成果バッチスケジューリングシステムを拡張しレプリカ管理システムと連動したシステムを構築従来のシステムよりも効率的にデータインテンシブアプリケーションを実行できることを確認

9 関連研究 - Stork[Kosar ら, 04] データ転送用スケジューリングシステム Condor[Livny ら, 88] と連動してデータインテンシブアプリケーションを実行 DAGMan がジョブの依存関係を解決計算ジョブは Condor にサブミットデータ転送ジョブは Stork にサブミット転送元転送先が静的に決定されるためアクセス集中の回避は困難

10 関連研究 - BAD-FS[Bent ら, 04] ストレージのコントロールをスケジューリングシステムにエクスポーズデータインテンシブアプリケーションを効率的に実行 WAN 上のファイル転送の最小化各タスクが必要とするデータおよびデータロケーションを記述する必要ありユーザの負荷が大きい利用されるデータはユーザが静的に決定 job a a.condor job b b.condor job c c.condor job d d.condor parent a child b parent c child d volume b1 ftp://home/data 1 GB volume p1 scratch 50 MB volume p2 scratch 50 MB mount b1 a /mydata mount b1 c /mydata mount p1 a /tmp mount p1 b /tmp mount p2 c /tmp mount p2 d /tmp extract p1 x ftp://home/out.1 extract p2 x ftp://home/out.2

11 関連研究 -[Ranganathan ら, 02] スケジューリングとレプリケーションの分割各ファイルへのアクセス数をカウントアクセス数に応じてレプリカ作成削除単一データへのアクセス集中発生スケジューリングとの連動なしデータのレプリケーション先は実行マシンのロケーション考慮されず

12 提案手法ジョブスケジューリングとレプリカ管理をタイトに結合最適なデータレプリケーションジョブ実行マシンへのレプリケーションデータロケーションに応じたスケジューリング同一データの反復転送回避同一データのアクセス集中の回避同一データ転送リクエストの集約計算資源の遊休時間の削減計算とデータ転送の同時実行システム全体の資源利用効率が上昇

13 提案システムの設計レプリカ情報を加味したジョブスケジューリングレプリカ保持ノードへ優先的にスケジューリングデータの再利用性の向上転送コストの低いノードへスケジューリング遊休時間の最小化同一データの転送要求の集約近隣ノードの中で代表ノードのみがオリジナルファイルを取得 WAN 上のデータ転送を最小限に抑制計算資源の遊休時間の削減計算中にデータ転送を実行データ転送中にジョブ実行サスペンド機構が必要

14 提案システムの概要サブミットマシン Job job info. 実行マシン A セントラルマネージャ allocate allocate machine info. 実行マシン B query レプリカ管理システム replica info. File F A B F F replicate レプリカ管理システムとの連動によりデータの再利用性の向上アクセス集中の回避に

15 プロトタイプシステムの実装以下のコンポーネントを統合バッチスケジューリングシステム Jay Condor を規範としたシステム GSI[Foster ら, 98] を利用したセキュアなシステムマルチレプリケーションフレームワーク MultiReplication[Takizawa ら, 05] レプリカロケーションサービス (RLS) レプリカの位置情報を管理アプリケーションレベルマルチキャスト転送 Dolly+[ 真鍋, 01] により O(1) の転送時間

16 プロトタイプシステムの実装容易に拡張可能なバッチスケジューリングシステムを実装しレプリカ管理との連動のために拡張バッチスケジューリングシステム Jay[ 町田ら, 04] Condorを規範とした容易に拡張可能なシステムセキュリティ基盤にGSI[Fosterら, 98] を利用複製管理システム MultiReplication[Takizawa ら, 05] セントラルマネージャー ClassAd ClassAd サブミットマシン実行マシン

17 Jay システムの概要 Match notification Negotiator Collector Matchmaking Request ClassAd Match notification Job ClassAds Startd Schedd 0.0 NextClus 1.0 MyType 1.0 Exec 1.0 Out 1.0 Err 1.0 Rank Shadow Starter Computation

18 Jay のスケジューリング受信したマシンとジョブの ClassAd[Livny ら, 97] の中からマッチメイキング [Raman ら, 98] により最適なマシンとジョブの組み合わせを決定マシンの ClassAd MyType = Machine TargetType = Job Memory = 256 Arch = INTEL OpSys = LINUX Requirements = (Owner == smith ) ジョブの ClassAd MyType = Job TargetType = Machine Cmd = sim Owner = smith Args = 900 Out = sim.out Rank = Memory Requirements = (Arch == INTEL ) && (OpSys == LINUX )

19 レプリカ管理システムとの連動実行マシンはセントラルマネージャに送信するマシン情報にレプリカ情報を追加保持するレプリカファイルの論理名保持しないファイルのレプリケーションコストマッチメイキング [Raman ら, 98] 時に rank 値にレプリカのロケーションに応じた値をプラス executable = application input = input.$(process) output = output.$(process) error = error.$(process) arguments = $(Replica_Files) transfer_replica_files = data1, data2 queue 100

20 レプリカ管理システムとの連動実行マシンはセントラルマネージャに送信するマシン情報にレプリカ情報を追加 Startd が定期的にどのくらい低コストでレプリカ作成できるかを表す値 (ReplicaValue) をチェックレプリカを作成するのに必要なコストに反比例現在の実装ではレプリカ作成コストとしてRTT 値を使用 MyType = Machine TargetType = Job Memory = 256 Arch = INTEL OpSys = LINUX ReplicaInfo = data1,500, data2,294, RTT=0.5 1 RTT=1.2 2

21 本システムのスケジューリング受信したマシンとジョブの ClassAd の中からマッチメイキングにより以下の値が最大となる最適なマシンとジョブの組み合わせを決定マシンの Rank 値 + ジョブの Rank 値 +(ΣReplicaValue(i)) / N ユーザが記述するサブミットファイル executable = application input = input.$(process) output = output.$(process) error = error.$(process) arguments = $(Replica_Files) transfer_replica_files = data1, data2,, datan queue 100

22 レプリカ管理システム MultiReplication[Takizawa ら, 05] を利用 RLS 転送機構レプリカセレクターレプリカ選択の指標として RTT を使用サイト内では Dolly+[Manabe, 01] による転送ノード数に対して O(1) の転送時間アクセス集中回避 Site B Site A HTTP Data Trans Client Data Trans Server F OK request Data Trans Negotiator request F Data Trans Client Data Trans Server F Dolly+ Data Trans Client Data Trans Server F

23 システム全体図 Central Manager RLS server Data Trans Negotiator request Schedd Shadow ClassAds location list query location list Site A Shadow Startd request OK Startd Starter Site B Starter DataTransClient F DataTransClient DataTransServer F DataTransServer Dolly+ F HTTP

24 評価実験サンプルアプリケーション BLAST( 核酸タンパク質の相同性検索ツールクエリに類似した核酸タンパク質の配列をデータベースから検索クエリの性質を調査実験概要データベース nt に対して 5 つの核酸配列をクエリとして BLAST を実行するジョブジョブを 5n(n = 4, 8, 16, 32) 個サブミット実行マシンは n ノード

25 評価手法以下の 4 手法を比較共有手法 NFS によりデータベースを共有ステージング手法 scp によりステージング提案手法レプリカ管理システムと連携理想状態すべての実行マシンにデータベースを格納

26 評価環境松岡研究室 PrestoIII クラスタ CPU Opteron 242 Memory 2GBytes OS Linux Network 1000Base-T セントラルマネージャサブミットマシン RLS サーバ NFS サーバについても上記スペック

27 平均実行時間の比較 Average Execution Time (min) Number of Nodes 共有手法ステージング提案手法理想状態従来の手法より高い性能が確認された

28 ジョブの稼働状況 -NFS Number of Running Jobs ジョブ実行終了後別のジョブ実行開始 Elapsed Time (min) NFS サーバでのアクセス集中によりパフォーマンスの低下が発生

29 ジョブの稼働状況 - ステージング Number of Running Jobs 同時データ転送によるアクセス集中発生 Elapsed Time (min) データ転送中のジョブ共有手法ステージング ( 計算 ) ステージング ( 転送 ) データ転送により遊休時間が発生

30 ジョブの稼働状況 - 提案手法 Number of Running Jobs アクセス集中回避 = リクエスト集約非効率なデータ転送抑制 = データ再利用性向上 Elapsed Time (min) 共有手法ステージング提案 ( 計算 ) 提案手法 ( 転送 ) システム全体の利用効率アップ

31 考察共有手法 (NFS) データサーバにアクセスが集中ステージング手法ステージング元マシンにアクセス集中データ転送によるアイドル時間発生提案手法理想状態に近い性能を達成システム全体の利用効率上昇レプリケーションリクエストの集約レプリカファイルの再利用

32 まとめと今後の課題まとめバッチスケジューリングシステム Jay を拡張しレプリカ管理システムと連動したスケジューリングを実現従来の手法より効率的な環境を構築今後の課題単一マシン上での計算ジョブとデータ転送の同時実行によるシステム全体の利用効率の向上複雑なシナリオを用いた大規模環境での評価実験

Microsoft PowerPoint - yamagata.ppt

Microsoft PowerPoint - yamagata.ppt グリッド上におけるにおける仮想計算機を用いたいたジョブジョブ実行環境構築システムシステムの高速化山形育平高宮安仁中田秀基, 松岡聡, : 東京工業大学 : 産業技術総合研究所 : 国立情報学研究所 1 背景グリッド技術の普及複数ユーザがネットワーク接続された計算機資源を共有する機会が増加ユーザが利用する OS やライブラリが多様化各計算機にインストールされている必要がある各計算機間で管理ポリシーが異なる