ミラーの同期ずれ

ミラー再同期 (Resilvering) は、破損が起きたドライブのデータを、正常なほかのディスクの内容を元に修復する作業のことで、再構築、リビルド、再構成などと呼ぶこともあります。どんなボリュームマネージャーや RAID アレイでも、ディスクが寿命になった場合、交換した場合、一時的な停止があった場合などには必ず、この作業をしなければなりません。

ミラーリングの場合、単にディスク全体をコピーするだけで再同期できます。RAID-5 の場合は、少しだけ複雑になります。あるディスクからほかのディスクにデータをコピーするのではなく、RAID-5 ストライプを構成する全ディスクの XOR を取ります。どちらも、基本的な考え方は同じです。

従来のストレージシステムでは、ボリュームマネージャーか RAID ハードウェアのどちらかが再同期を行なっていました。いずれにせよ、ファイルシステムよりもずっと下のレイヤーでの処理になります。

しかし、私たちが使っているのは ZFS です。従来のファイルシステムと同じなどということはありません。

以前の投稿で RAID-Z の再同期に通常とは異なるアプローチが必要だという話に触れました。RAID-Z のジオメトリを判断するためにメタデータが必要になるからです。実質的には ZFS が、あるディスクからほかのディスクに、ストレージプールのブロックツリーを「cp -r」します。単純にディスク全体をコピーするのと比べて効率が悪く、ライブプールの走査を安全に行うのは厄介な問題だと感じるかもしれません (詳細な情報を後日投稿します)。しかし、メタデータを基にした再同期には多くの利点があるため、単純なミラーリングに対しても、私たちはこの方法を採用しています。

もっとも説得力のある理由は、データの整合性です。単純なディスクコピーでは、コピー元のディスクが正常なデータを返しているかどうか、確認する手段がありません。エンド・ツー・エンドのデータ整合性を実現するには、各データブロックについてそれぞれ別途保存されたチェックサム確認をしなければなりません。各ブロックが変化していないことを確認するだけでは、誤ったブロックからの読み取りや書き込み成功の誤報告など、ハードウェアやファームフェアに見られる一般的なバグを把握できないため、不十分です。

ZFS ではメタデータを走査することで、通常の読み取りを行う場合と同様に、エンド・ツー・エンドのチェックサムを用いたサイレント破損の検出と修正ができます。ディスクから不正なデータが返ってきた場合、ZFS がこれを検出して読み取りをリトライします。3 ウェイミラーリングで、正常であるはずのミラー 2 つのうち 1 つが実は破損していた場合、ZFS がチェックサムを用いてどちらのミラーが正しいのか判断し、新しいディスクにデータをコピーして、破損したディスクのデータを修正します。

単純なディスク全体のコピーでは、このようなデータ保護は機能しません。このことを考えただけでも、たとえパフォーマンス的にそれなりのコストがかかったとしても、メタデータを元にした再同期が望ましいのです。

幸いなことに、ほとんどの場合パフォーマンスはそれほど低下しません。それどころか、メタデータを元にした再同期のほうが優れている点もあります。

ライブブロックだけを読み取る。 ZFS では、未割り当てのディスクブロックのコピーで時間や入出力帯域を無駄にすることがありません。未割り当てブロックは、ストレージプールのブロックツリーに含まれないからです。プールの容量を 10 から 20% しか使っていないなら、これは大きな利点です。

トランザクションの効率化。ディスクに一時的な停止が起きた場合、ディスク全体を再同期する必要はなく、変更があった部分だけで済みます。詳細は後日投稿しますが、概要は次のとおりです。ZFS は、各ブロックの作成時刻を用いて、ツリーの下位に再同期が必要な部分があるかどうか判断します。これにより巨大なツリー全体を検証する必要がなくなり、不具合発生後にデータが変更された部分をすばやく発見できます。

実用上の意義としては、たとえばディスクが 5 秒間の不具合を起こした場合、再同期にも約 5 秒間しかかかりません。しかもこの機能は Veritas の変更オブジェクトを使う場合と違い、コスト (金銭面でもパフォーマンス面でも) がかかりません。トランザクションの効率化は、ZFS アーキテクチャーの本質的な機能です。

トップダウン式の再同期。ストレージプールはブロックをツリー状に集めたものです。ツリーの上位であればあるほど、ブロックが破損した場合に大きな被害をもたらします。破損したブロックより下位にアクセスすることができなくなるためです。

ZFS では、メタデータの走査によりトップダウン式の再同期が可能です。つまり、ZFS では最上位ブロックとディスクラベルから再同期が始まります。その後、プール全体のメタデータ、ファイルシステムのメタデータと続けて、同様にツリーの下位へと進みます。この手順全体を通して ZFS は、次のルールに従います。つまり、上位ブロックの再同期が完了していないブロックは再同期しない、というルールです。

このことの大切さは、どんなに強調しても足りないくらいです。ディスク全体のコピーでは、コピーが 99% まで進んでも、ツリー最上位 100 ブロックのうちいずれかがまだコピーされていない、という可能性がかなりあります。MTTR の観点からは、まったく作業が進んでいないのと同じことになります。さらに、このタイミングで 2 台目のディスクも故障すると、大変なことになります。

トップダウン式の再同期では、ブロックを 1 つコピーするごとにアクセス可能なデータが増えます。2 台目のディスクが故障したとしても、故障の直前までに再同期したデータすべてにアクセスできます。

優先度に従った再同期。ZFS でまだ実現していませんが、実装中の機能です。データの論理構造に従った再同期を行うことで、ファイルシステムやファイルごとの再同期優先度を簡単に指定できるようにします。たとえばファイルサーバーで、非常に小さいものの重要なデータであるカレンダーを最初に、次に /var/mail、次にホームディレクトリを再同期したい、などです。


ここ一連の投稿で私が伝えたいことは、単に各機能の実装がどのようなメカニズムなのかということではなく、ぞれらを統合した ZFS 全体がどのようなものなのかということです。これは、ぱっと見ただけではわからないことです。たとえば、トランザクションのセマンティクスは再同期と何の関係もありませんが、トランザクションの効率化により、一時的な故障から非常に短時間で復旧ができます。次回のポストで、この仕組みがどのように機能しているのか紹介します。

Comments:

Post a Comment:
Comments are closed for this entry.
About

bonwick

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today