Transcript 他のプロセスに与える影響の少ない 実行時ミラーリングシステム

他のプロセスに与える影響の少ない
実行時ミラーリングシステム
柳澤 佳里*1 千葉 滋*1
*1 東京工業大学 情報理工学研究科
1
サーバーのディスクバックアップ

YahooやGoogleでのバックアップ作成は困難
• 常時アクセスがある環境でのバックアップは困難
• バックアップ作成中は極度に性能低下
• 繫がらないユーザの[Reload]による輻輳の恐れ

バックアップの災害耐性を持たせるのは困難
• バックアップが手元にあると同時に被災する恐れ
• 遠隔地にバックアップテープを移送するのは手間
2
サーバーのディスクバックアップの要件

実行時ディスクバックアップ
• Incrementalにディスクバックアップを実行
• バックアップ実行の負荷を時間分散
• 時間分散させることで瞬間バックアップ負荷を軽減

遠隔地ディスクバックアップ
• 遠隔地のマシンのディスクにバックアップ
• 災害耐性を持たせる
• e.g. 隣のビルにバックアップし火災によるデータ破損に対処
3
バックアップ処理のスケジューリング

バックアップ処理による性能低下を避けたい
• サーバー負荷増大時にバックアップ処理を休止
• バックアップ処理はサーバープロセスより低い重要度
• サーバーへのアクセスが多いときには変更も多い

競合する資源全てを考慮してスケジュールしたい
• スケジューリングで考慮する資源は多岐にわたる
• ディスクバックアップは多種の資源を使用
4
我々の
Tottottoミラーリングシステム

スケジューリングの工夫
• ヒントつきprogress-based regulation (Pbr)
• ネットワークの使用量をヒントとしたPbr
• Pbrと従来スケジューリングとのハイブリッド
• Pbr: プログラムの進捗を見てスケジューリング
• 特定の資源によらずスケジューリング
• 統計処理を行うので反応が遅い
• 従来型:資源の使用量を見てスケジューリング
• 即応性が必要な資源競合をスケジューリング
• Pbrの遅さをカバー
5
Progress-based regulation (Pbr)

進捗状況のフィードバックによるスケジューリング
• 重要度の低いプロセスは進捗をスケジューラに報告
• 資源を譲る善意のプロセスのためのスケジューリング
• 進捗悪化時:重要度の低いプロセスを停止
• 資源の競合の恐れ
• 進捗良好時:重要度の高いものと同じ資源割り当て

個々の資源の使用量を調べずスケジューリング可
• 資源ごとのスケジューラ作成は不要
6
Progress-based regulationの難点

Pbrは統計処理で進捗を判断
• 適切な閾値を設定するのは困難
• 従来の閾値による動作への反省

急激な資源の使用量の上昇への対応に遅れ
• 統計処理に足るデータ量が必要

量に限りがある資源の割り当てには不向き
• 個々の資源を見ずにスケジューリング
7
資源監視によるスケジューリング

資源使用量を見てスケジューリング
• 閾値を超える変化をした場合に停止
• 即応性のあるスケジューリングが可能
• 量に限りがある資源も適切にスケジュール可能

閾値のチューニングが困難
• うまくスケジュールするには適度な閾値が必要
• 適切な閾値を多数の資源に定めるのは困難

Tottottoではネットワーク流量について閾値を
経験的に定め監視
8
スケジューラの実装

ミラーリングソフトが自主的にスケジューリング
• Kernelの改造が不要
• 資源競合時に
• Usleep(2),Sleep(3)により他プロセスに資源を移譲
• Sleep時間はbinary exponential back-offで増加

ヒントつき Pbr
• ネットワーク流量監視スケジューリングをヒント
• 競合する資源をネットワーク資源(mbuf)と想定
• ネットワークサーバー用途を想定

NetBSD 1.6Rに実装
• LFSが実装されているOS
9
Tottottoにおけるミラーリング

LFSv2/NetBSD対象
• LFS: Log-structured File System,ログ構造のFS
• LFSのブロック(segment)単位でミラーリング
• 前回ミラーリングした箇所との差分発見が容易
• LFSでは追記にてファイルシステムの変更を表現
• 現在書き込み中のsegmentはsuperblockに記録
10
スケジューリングのタイミング

流量監視スケジューリング: segment送信ごと
• ネットワーク使用の直前に使用量を調査
• 混雑時に混雑を助長するのを防止

Progress-based regulation: 差分送信ごと
• 進捗を調べやすいところで進捗調査
• 前回からの差分を求める箇所も調査対象に
• Segment送信ごとだと重み付けが困難
11
提案するスケジューリング法の
効果を見る実験

目的
• バックアップ処理がWebサーバープロセスに資源を譲る速さを測定

実験方法
• http_loadにて8並列でミラーリング元へ負荷をかけ、throughputを計
測

実験環境
• ミラーリング元、先:
AMD Athlon 1.8GHz,メモリ 1GB,NetBSD 1.6R
• Web Client:
AMD Athlon 1.8GHz,メモリ 1GB,FreeBSD 4.7R
12
実験1: ネットワーク流量が多い場合

目的
• 急激な資源使用量上昇への反応を確認
• 流量監視によるスケジューリングを加えた効果を測定

実験方法
• 送信された文字列を記録し、送り返すCGI
• 単純な処理なので処理時間が短い
• 相対的にネットワーク流量増大
13
実験結果1: 流量が多い場合
処理性能比(%)
Tottotto
Progress-based
regulation
Schedulingなし
(秒)経過時間
図: バックアップ実行中の時間あたりのプロセス処理量
バックアップしない場合を0とした比で表現

考察
• Tottottoがprogress-based regulationより早くスケジューリング
14
実験2: ネットワーク流量が少ない場合

目的
• 流量が少ない場合の反応を確認
• 流量監視のみによるスケジューリングの効果を測定

実験方法
• ファイルを検索し記録した後に送り返すCGI
• 検索には長時間を要する
• 相対的にネットワーク流量(mbuf使用量)減少
15
実験結果2: 流量が少ない場合
処理性能比(%)
Tottotto
流量監視のみ
Schedulingなし
経過時間(秒)
図: バックアップ実行中の時間あたりの処理量
バックアップしない場合を0とした比で表現

考察
• ネットワーク流量監視では流量が少ない場合うまく動かない
16
• Pbrによるフォローが必要
関連研究
資源監視によるスケジューリング

資源監視によるスケジューリングの難点
• 対象資源以外のスケジュールは困難
• 資源ごとにスケジューラを作るのはよくない
• 個別に実装するのは面倒
• 協調動作させるのに苦労
Run queues
High
priority
process
process
process
process
process
.
.
.
Low
priority
17
関連研究
Progress-based regulation

低重要プロセス
• プログラムの進捗を報告し、競合時には自主的に停止
• Kernelの改造不要
• 限りある資源を使うプロセスのスケジュールに向かない

統計処理により進捗を判断
• 競合への対応が遅い
• データ量が不足するとスケジュールしない
Progress-based regulation of low importance processes [Johnら ‘99]
18
関連研究
Kernel改造を伴うProgress-based
regulation

進捗を見てCPU割り当て時間を変更
• 進捗はリソース処理具合より判断
• User landとOSを分離

kernel schedulerへの変更が必要
• Kernel改造は万人向きではない
• Tottottoは改造不要で内部にスケジューラーを保持
A Feedback-driven Proportion Allocator for Real-Rate Scheduling [Davidら ‘99]
19
まとめ

ヒントつきprogress-based regulation (Pbr)の提案
• Pbrの反応の遅延をカバー

実行時ミラーリングシステムTottottoを作成
• 流量監視をヒントとする Pbr
• Tottottoが自主的に他プロセスに資源を移譲
• Kernel改造不要

実験
• 流量監視による効果があった
• ヒントを付けたことでPbrよりも早くスケジュール
• 流量監視のみでは不十分なことを確認
• Pbrによるフォローは重要
20
今後の課題

ディスクなど他資源の検討
• サーバー以外の用途への応用

スケジューリングの粒度の検討
• パケット単位のスケジューリング
• 細粒度でのオーバーヘッドの検討

ミラーリングの粒度の検討
• Segment単位よりも細かい単位でのミラーリング
21