Project Home Downloads Wiki Issues Source
FSCK  
MogileFSのFSCKの実行
Updated Jul 9, 2012 by normalpe...@gmail.com

メンテナンスページに戻る

MogileFS ファイルシステムのチェック

MogileFSは大規模な分散HTTP支援データストアであり、伝統的な'fsck'コンポーネントを持っていません。ファイルシステム全体の内容を平行して、動作中に非同期のやり方で、歩き検証するメカニズムを持っています。

MogileFS の fsck はデフォルトでは、全ての格納されているFIDを渡り歩き、検証します:

  • FIDがリプリケーションポリシーにおいて健全か(過度に健全では無い) (例えば: 複数のホストを跨いで 3つのコピーがある)。
  • FIDのそれぞれのコピーがあるべき場所に格納され、存在し、正しい長さである。
  • ファイルが見つからなくなった場合(どのパスもうまく行かない)、全てのデバイス上でFIDを見つけようとするでしょう。
  • Checks devcount cache, and some other misc minor notes.
  • ファイルのチェックサムをまだ確認していないことに注意してください。

FSCKは厳密には暴力的です。特定のドメイン、クラス、またはファイルのプリフィックスで、それに重点的に取り扱うことはできません。しかしながら、MogileFSのそれぞれのリリースでFSCKのコードに小さな改善が追加されています。ですので、何が追加更新されたのかを見るために最新のコードをチェックしてください。

いつFSCKを実行するか

絶え間なくFSCKを実行する必要はありませんが、時々あるいは大きなイベントの後に実行することは健康に良いです。大きなソフトウェアのエラーや、注目に値するアップグレード、停電などです。いずれもFSCKを実行するには良い言い訳になります。また、クラスのリプリケーションポリシーを変更(replicasの追加または削除)する場合は、その変更はFSCKが実行されるまで効果がありません。

FSCKは古いバージョンのバグを修正することができます。しばらくの間リプリケーションを満たすような十分なユニークなホストが無い状況でリカバーするのにも役立つでしょう。FIDs will end up on multiple devices, just not on enough hosts to be happy.

MogileFSのFSCKの実行

FSCKの開始

fsck は mogadmを使って制御されます。

$ mogadm fsck 
Help for 'fsck' command:
 (enter any command prefix, leaving off options, for further help)

  mogadm fsck clearlog                               Clear the fsck log
  mogadm fsck printlog                               Display the fsck log
  mogadm fsck reset [opts]                           Reset fsck position back to the beginning
  mogadm fsck start                                  Start (or resume) background fsck
  mogadm fsck status                                 Show fsck status
  mogadm fsck stop                                   Stop (pause) background fsck
  mogadm fsck taillog                                Tail the fsck log

fsckを初めて開始する場合は、単純に 'mogadm fsck start' を実行してください。少しすると、動き始めるでしょう。進捗を見るにはmogadm fsck statusを実行します。

FSCK オプション

fsckを2,3のオプションをつけて実行することができます。新しいファイルに対してのみそれを実行したい場合、開始する番号をFID番号で指定したり、あるいはディスク上のファイルの状態のチェック無しでリプリケーションポリシーのチェックだけをするように指定することができます。

mogadm fsck stop
mogadm fsck reset --startpos=5000 --policy-only
mogadm fsck start

FSCKの実行の監視

草の成長を見るのを好きであれば、fsckの監視はあなたにとってうってつけです!

    Running: Yes
     Status: 55252778 / 75053798 (73.61%)
       Time: 791m (1164 fids/s; 19801020m remain)
 Check Type: Normal (check policy + files)

 [num_GONE]: 1
 [num_NOPA]: 1
 [num_POVI]: 365
 [num_REPL]: 365
 [num_SRCH]: 1

定期的にfsckの進捗を監視するために mogadm fsck status を実行したいかも知れません。バージョン2.30からステータス情報が幾分奇妙になっていることに注意してください。2.33 以上でステータスの出力が改善されましたが、fsckが "Running: No" に切り替わると、内部キューの排出の間、fsckは数分間FIDをまだフィルターしていることに注意してください。

fsckの結果を mogadm fsck printlogを使って検査することができます。あるいは実行している間mogadm fsck taillogを使って出力を見ることができます。

FSCKのチューニング

2.30+バージョンでは、FSCkに調整可能な改善がされました。以前のfsckは一つのトラッカー上の正確に一つのworkerプロセスから実行していました。もし数億のファイルがあった場合、実行に一ヶ月以上かかっていたでしょう。今では、分散され、実行可能なリソースがある限り速く実行することができます。

トラッカーのログ(syslogか、trackerにtelnetして!watchを実行)を見て、タイムアウトエラーを探すことは、良い考えです。それらを大量になり始めたら、クラスタは大変なことになりはじめています。

FSCK Workerの数

もっとも簡単なチューニング方法は、単純に必要な並列fsck workerの数にすることです。

telnet trackerhost 7001
Trying 172.16.151.10...
Connected to 172.16.151.10
Escape character is '^]'.
!jobs
[...]
fsck count 1
fsck desired 1
fsck pids 32664
.
!want 5 fsck
!want 5 fsck
Now desiring 5 children doing 'fsck'.
.

トラッカー、データベース、ストレージクラスターに渡ってロードを監視している間、ゆるやかにfsck workerプロセスの数が増加します。The trackers will slowly ramp up how much work it fetches from the fsck queue at once, so it could take a few minutes for them to ramp up. fsck workerをもっと追加したがfsckが速くならない場合は、おそらく他に幾つか設定を調整する必要があるでしょう。

FSCK のスピード設定

FSCKには多くのキュー管理オプションがあります。デフォルトは小さなセットアップ時に重い負荷を与えるのを避けるために比較的遅いものです。25+のfsck workerがある(そして、クラスタが高負荷で無い)場合、もっと速くするためにそれらを調整する必要があるかも知れません。

$ mogadm settings list
     internal_queue_limit = 500
      queue_rate_for_fsck = 1000
      queue_size_for_fsck = 20000
[etc]

デフォルトからそれらの値を調整していない場合は、それらはここに表示されないでしょう。デフォルトが決定されるまで(JobMaster.pmで見ることができます)、何がデフォルトなのか見つけることはちょっと難しいですが、2.33から2.45までのしばらくの間は上のものがデフォルトです。

internal_queue_limit はトラッカーがfsckデータベースのキューから一度に取り出すFIDの数です。fsck workerはこのキューから内部的にFIDのチャックを取り出すでしょう。'!stats'コマンドでtrackerを見ると、work_queue_for_fsck 0のような様々な変数をみることができるでしょう。多くのworkerでfsckを活発に実行している場合は、このstatはしばしばかなり低いか0になります。internal_queue_limit を増やすことで、速くすることができるでしょう。あまり高くしすぎないように気をつけてください。。必要なのはおそらく数千です。内部的に起動が遅いため、耐えてください。この搬送を維持するために以下の値を調整する必要もあるかも知れません。

queue_size_for_fsck は、トラッカーが取り出してworkerに渡すためにfsckがデータベースにキューしたままにしておく数です。高くすればするほどディスクの容量を消費しますが、キューは常に0であれば、この制限を二倍あるいは三倍にすることでキューが要求に対して存在するようにできます。

queue_rate_for_fsck は、キューがこの制限より少ない時にfsckがサイクル(一秒おき)ごとにキューに入れるFIDの数です。値をあまりに大きく設定するとDBの過負荷を起こしますが、あまりに小さいとトラッカーがキューを追い越します。一度にキューできるFIDの総数は、queue_size_for_fsck + queue_rate_for_fsckまでです。

結果の解釈

fsckは問題を発見したり処理する時に、あいまいなエラーコードの束を記録するでしょう。

  • NOPA: FID は利用可能なパスを持っていません。おそらく死亡しています。
  • POVI: FID はクラスのリプリケーションポリシーに違反しています。これはコピーがあまりにも少ないか、あるいはあまりにも多いかを意味します。
  • MISS: FID は少なくとも一つはあると思っていたコピーを見失いました。
  • BLEN: FIDのコピーは正しいファイルの長さではありません
  • GONE: なんらかの動作の発見、修正、FIDのコピーをしようとしたが、できなかった。ファイルが死亡しています。これらのエラーを受け取った場合は、なぜ見失ったのかを調べるために、FIDとアプリケーションを深く調べる必要があります。
  • SRCH: FSCKは見失ったファイルのために徹底的な検索を開始した。
  • FOND: FSCKが消失したと思われていたFIDをリカバーした。
  • REPL: リプリケーションがポリシーの違反を修正するために、FIDがすけじゅーるされた。
  • BCNT: FIDの'devcount' キャッシュが正しくない。
  • BSUM: データベースのチェックサムがディスク上の内容と一致しない
  • NSUM: チェックサムに必要なデータベースチェックサムがクラスから見失われている
  • MSUM: (fsck_checksum=$HASH のユーザのみ) 複数のチェックサムが計算され、MogileFSはどれが正しいものか分からなかった。

十分に新しいバージョンの MogileFS::Utils をインストールしていれば、FSCKログに記録されているfidを取り出しmogfiledebug を使ってそれらを実行できるかも知れません。このユーティリティは特定のfidを見つけることができる全てを一切合切取り出しますが、何が問題なのかの思いつきをあたえてくれるでしょう。少なくとも、それはメーリングリストあるいはIRCで助けを得るために必要なすばらしい出力を与えるでしょう。

各実行の合間の掃除

fsck status はログから違反の要約を数えるでしょう。これは、実行している間にログを消去しなければ、実際にあったよりも多くの失敗を見るということを意味します。また、ログファイルはデータベース上で大きくなり容量を使いがちです。そこで、一度ログの記入にざっと目を通し(あるいはどこかのファイルにコピーし)たら、リセットするのは良い考えです。

mogadm fsck status
(confirm that it isn't running, and hasn't been for a few minutes at least)
mogadm fsck clearlog
mogadm fsck reset
Comment by project member tsaavik, Jun 4, 2010

週に一回自動でfsckを実行するcron jobです。fsckがすでに実行されていれば、メッセージをemail/logします。そうでなければ新しいコピーを開始し、出力を /tmp/mogadm.fsck に記録します

cronのユーザパスにmogadmが無ければ、mogadmにフルパスを追加する必要があるかも知れません。

mogadm fsck status |grep " Yes " || (mogadm fsck reset; mogadm fsck clearlog; mogadm fsck start) >/tmp/mogadm.fsck 2>&1
d
Comment by oja...@gmail.com, Apr 10, 2011

それはとても良くない考えです。再起動した後で、悪いユーザが "ln -s /etc/shadow /tmp/mogadm.fsck" を実行したら、shadowを(あるいはどのようなファイルでも)上書きするでしょう。

Comment by project member tsaavik, Sep 2, 2011

神経質なバージョン:

mogadm fsck status |grep " Yes " || (mogadm fsck reset; mogadm fsck clearlog; mogadm fsck start) >/var/log/mogadm.fsck 2>&1

Comment by brother...@gmail.com, Nov 13, 2011

もしバックエンドに悪いユーザがいるのであれば、あなたはすでにだまされています。


Sign in to add a comment
Powered by Google Project Hosting
TOP
inserted by FC2 system