 Print-friendly Version
ZFS - Sun の最新ファイルシステム (パート 1: ストレージの完全性、安全性、およびスケーラビティー)パート 2: 管理の簡素化と将来の機能拡張Amy Rich、2006 年 8 月
目次 : ZFS の概要Solaris 10 06/06 オペレーティングシステムに新しく追加された ZFS は、従来の UNIX ファイルシステムを完全に設計し直した革新的なものです。Sun の技術者とオープンソースコミュニティーのメンバーは、現在の市場での最良事例の中からいくつか (Network Appliance のスナップショット、 VERITAS のオブジェクトベースのストレージ管理、トランザクション、チェックサムなど) を取り出し、それぞれのアイデアと専門知識を提供することによって、ファイルシステムを設計するための、新しい、能率化され、結合力のあるアプローチを開発しました。 まだライフサイクルの初期にもかからわず、ZFSは、ほかのUNIX ベンダーとオープンソースの信奉者が 自分達の固有のオペレーティングシステムにそれを移植する計画をすでにほのめかすほど大きな影響を与えています (OpenSolaris のサイトの「Porting ZFS to other platforms」を参照)。 ZFS によって、Sun はほかの UNIX ファイルシステムの悩みの種であった、完全性、安全性、スケーラビリティー、そして管理の困難さという重要な問題に取り組んでいます。ここでは 2 つのパートに分けて、ZFS の動作の舞台裏と、ZFS を企業の時間と経費の節約につなげる方法について考察します。パート 1 では、データの完全性と安全性のモデル、そして ZFS のスケーラビリティーについて説明します。パート 2 では、管理の簡素化と将来の ZFS の機能拡張を取り上げます。 ZFS データの完全性と安全性ファイルシステムのもっとも重要な構成要素はデータの完全性と安全性です。ディスク上の情報が、ビットの欠落、隠れた破壊、人為的なまたは偶然の改変を受けないことは非常に重要です。これまでファイルシステムは、このような難題を克服し、信頼性のある正確なデータを提供するという、さまざまな問題を抱えました。 これまでのバージョンの UFS など、古い技術で構築されたファイルシステムは、使用中のデータを変更する場合にブロックを上書きします。書き込み中に電源障害が発生すると、書き込み中のデータは破壊され、ファイルシステムは重要なデータへのブロックポインタを失う可能性があります。この問題に対処するために、 信頼性のため、人々はまた、ある種のボリューム管理ソフトウェアを使用して、ディスクまたはファイルシステムのミラーリングへ移行していきました。停電が発生し、ミラー化された両方の間の整合性がとれなくなると、たとえほんの少し疑わしいブロックがあっても、ミラーの片方はもう片方と同期を取り直します。再同期中の入出力のパフォーマンスが低下するだけでなく、マシンはデータのコピーが破壊されていないことを常に正確に予測できるわけではありません。間違っているミラーを信頼して選択し、誤ったデータで正しいデータを上書きしてしまうこともあります。パフォーマンスの問題に対処するために、ボリュームマネージャーの中には、ダーティーリージョンログ (DRL) として知られている機能を採用しているものもあります。この場合、停電が発生した時点でデータの書き込みを行なっていた領域のみ、再同期を取る必要があります。パフォーマンスの問題を軽減するためにはうまく働きますが、ミラーのどちら側が有効データであるかを検知する問題には対処しきれていません。 ZFS では、トランザクションベースの書き込み時コピーによる変更を行うことと、ファイルシステム内にある使用中の各ブロックのチェックサムを常に計算することで、この問題に対処しています。 トランザクションベースの書き込み時コピー操作 ZFS はファイルシステムとボリュームマネージャーを組み合わせたものであり、ストレージプールの仮想化のため、ファイルシステムレベルのコマンドは、背後に物理ディスクのコンセプトを必要としません。すべての高水準な対話がデータ管理ユニット (DMU) を通じて発生し、DMU のコンセプトはメモリー管理ユニット (MMU) に類似し、RAM の代わりに対象がディスクだけです。DMU を通じてコミットされたすべてのトランザクションは不可分であるので、データが整合性のない状態に置かれることは決してありません。 トランザクションベースのファイルシステムであることに加え、ZFS は書き込み時コピー操作のみを実行します。これは、ディスク上の使用中のデータを含むブロックは決して変更されないということを意味します。変更された情報は代替ブロックに書き込まれ、使用中のデータへのブロックポインタは書き込みトランザクションの完了後に移動されるだけです。これは「uberblock」と呼ばれる一番上のブロックまでファイルシステムのブロック構造全体に対して行われます。 図 1 に示すように、変更されたデータを書き込むためにトランザクションは使用されてないブロックを選択してから、前述のブロックがポイントする場所に変更します。
図 1: 書き込み時コピートランザクション データの書き込み中にマシンの電源異常が発生した場合、「正しい」データへのポインタは書き込みがすべて完了するまでは移動されないので、破壊は起きません。(注意 : 移動されるのはデータへのポインタだけです。）これにより、ファイルシステムのジャーナリングまたはロギングの必要がなくなり、マシンが予期せず再起動したときの エンドツーエンドのチェックサム 不慮のデータ破壊を防ぐため、 ZFS はメモリーベースのエンドツーエンドのチェックサムを提供します。チェックサムを行うほとんどのファイルシステムは、ブロックそのものと共にチェックサムが保存されている自己整合性ブロックを使用しているため、ビット欠落を防ぐだけです。この場合、正当性を検証するための外部的なチェックは行われません。この形式のチェックサムでは、次のようなものは捉えません。
ZFS では、チェックサムはブロック内ではなくブロックへのポインタの隣に保存され、uberblock まで続きます。uberblock だけは自己妥当性検査を行う SHA-256 チェックサムを持っています。すべてのブロックチェックサムはサーバーメモリー内で行われるので、前述の誤った指示による読み出しや書き込み、パリティーエラー、実体のない書き込みなどを含む、ツリー全体のあらゆるエラーが捉えられます。以前は、CPU に負荷がかかりマシンをダウンさせてしまうことがありましたが、最近では 処理中にディスクのトランザクションをチェックできるほど CPU 技術と速度が向上しています。ZFS がこれらの問題を捉えるだけでなく、ミラー化された構成または RAID-Z 構成でも、データは自己修復を行います。(このシリーズの 2 回目の記事で、RAID-Z についてさらに詳しく取り上げる予定です。) データの自己修復を示す、良く使われる Sun デモンストレーションの 1 つは、次に示す dd if=/dev/urandom of=/dev/dsk/c0t1d0s5 bs=1024 count=100000 これはミラーの片側にガベージデータを書き込みますが、そのブロックがアクセスされると、ZFS はチェックサムを実行し、そのデータが不正であることを認識します。その後、データ破壊によりパニックに陥ることなく、 ZFS はデータのもう一方のコピーにチェックサムを実行し、それが有効であると判断し、破壊された側のミラーの不正なブロックの「再同期化」を行います。RAID-Z 構成では、ZFS は各ディスク上のブロックを順次チェックし、一致するまでパリティーチェックサムを比較します。一致したら、ZFS は有効なデータのブロックであると判断し、ほかのすべての不正なディスクを修正します。再同期化の処理はユーザーに対して完全に透過的であり、ユーザーは問題が発生していたことを認識することすらありません。 ZFS は常に、消し込みと呼ばれる処理を通じてバックグラウンドでデータが破壊されてないかどうかのチェックを行います。ディスクの消し込みに使用されるファイルシステムのコードは、再同期化、ミラーの接続、ディスクの交換に使用されるものと同じコードで、プロセス全体をしっかりと統合させます。管理者はコマンド #zpool scrub testpool
#zpool status
pool: testpool
state: ONLINE
scrub: scrub completed with 0 errors on Thu Jun 29 12:47:15 2006
config:
NAME STATE READ WRITE CKSUM
testpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s5 ONLINE 0 0 0
c0t1d0s5 ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s6 ONLINE 0 0 0
c0t1d0s6 ONLINE 0 0 0
ミラーの破壊された部分に対して前述の #zpool scrub testpool
#zpool status
pool: testpool
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool online' or replace the device with 'zpool replace'.
次を参照してください。http://www.sun.com/msg/ZFS-8000-9P
scrub: scrub completed with 0 errors on Thu Jun 29 12:51:29 2006
config:
NAME STATE READ WRITE CKSUM
testpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s5 ONLINE 0 0 0
c0t1d0s5 ONLINE 0 0 5 2.50K repaired
mirror ONLINE 0 0 0
c0t0d0s6 ONLINE 0 0 0
c0t1d0s6 ONLINE 0 0 0
出力がここで報告している内容は次のとおりです。
出力はさらに次の情報も提供しています。
詳細な説明については、｢ZFS ミラー再同期化に関する Jeff Bonwick のブログエントリ｣を参照してください。 ZFS の安全性によるもう 1 つの利点は次のとおりです。完全な許可および拒否セマンティクスと継承を含む NFSv4/NT 形式の ACL を使用します。17 の異なる属性に基づくアクセス制御は、非常にきめが細かいものです。 ZFS のスケーラビリティーデータの安全性と完全性が非常に重要であると同時に、ファイルシステムは、適切に機能し、時間の試練に耐える必要があり、そうでなければ広く使われることはないでしょう。 ZFS の設計者は、128 ビットアーキテクチャーを使用し、すべてのメタデータを動的にすることで、現在のファイルシステムが抱える制限を、解消または大幅に減少させました。ZFS はパフォーマンスを向上するために、また、データパイプライン、動的ブロックサイズ、インテリジェント先読み、動的ストライプ、および組み込み型圧縮を実装しています。 128 ビットアーキテクチャー 業界の最近の動向では、ディスクドライブの容量は 9 か月から 1 年ごとに約 2 倍になっています。この動向が続けば、ここ 10 年から 15 年ほどの間に、ファイルシステムは 64 ビットのアドレス指定能力が必要になるでしょう。64 ビットの要件で計画する代わりに、ZFS の設計者たちは長期的視野に立って 128 ビットのファイルシステムを実現しました。これは、ZFS が現在の 64 ビットのシステムよりも 160 億倍以上もの容量を提供できることを意味します。ZFS のチーフアーキテクトの Jeff Bonwick によると、「ZFS:the last word in file systems」の中で、「128 ビットのファイルシステムを実装することで、地球ベースのストレージの量的な限界を超えるでしょう。海が沸騰でもしない限り、128 ビットのストレージプールを満たすことなどできないでしょう」と述べています。Jeff はまた、「128-bit storage」に関する自分のブログエントリの中で、この文章のあとに数学についても論じています。私達は量販市場に対するこの種のエネルギーを生み出す技術をまだ持っていないので、しばらくは安全でしょう。 動的メタデータ 128 ビットであることに加え、ZFS のメタデータは 100% 動的です。このため、新しいストレージプールとファイルシステムは非常に高速に作成されます。ディスクへの書き込みの 1 ～ 2% だけがメタデータであり、これにより初期のオーバーヘッドは大幅に削減されます。たとえば、静的でない i ノードがあり、 その唯一の制約は、ストレージプール内のディスクに収まる i ノードの数です。 128 ビットアーキテクチャーはまた、ファイル、ディレクトリなどの数に実質的な制限がないことを意味します。論理上の制限を示しますが、その大きさを想像することができたら、とてもびっくりすることでしょう。
ファイルシステムのパフォーマンス ZFS の基本設計により、従来のファイルシステムと比べて数多くのパフォーマンスの拡張機能が提供されています。まず、ZFS は CPU パイプラインのコンセプトに似たパイプライン接続の入出力エンジンを使用しています。このパイプラインは、入出力の相互依存性に基づいて動作し、相対的な優先順位と最終期限に基づいてソートすることができます。このパイプラインはスコアボード、優先順位、最終期限のスケジューリング、順序変更の実施、および入出力の集計を提供します。ZFS はまた、アクセスパターンが線形かアルゴリズム的かを認識し、隣のブロックを推測して先読みするインテリジェント先読みアルゴリズムを実装しています。 可能なときはいつでも速度を上げられるように、ZFS は並行処理を採用しています。このファイルシステムは、並列の固定速度ディレクトリ処理だけでなく、同じファイルに対する並列の読み取りと書き込みをサポートし、そのロック方式はスケーラブルで高速です。さらに、あらゆるトランザクション内の処理は任意の順番で実行できるので、DMU バッチはディスク動作を最適化するように読み取りおよび書き込みを行います。トランザクションは書き込み時コピーなので、ディスクをランダムにアクセスするのではなく、新しいデータに対し連続したブロックを選択することができます。これにより、ディスクはプラッタと同じまたはそれに近い速度で動作することができます。ZFS はまた、最適なパフォーマンスを達成するために、ブロックサイズ (512 バイトから 128K バイト) を作業負荷に自動的に適合させます。 ZFS はすべての使用可能なデバイス間でデータを動的にストライプ化します。別のディスクまたはスライスをストライプに追加する場合、ZFS は自動的に新しいスペースを組み込み、新しいスペースを活かすために書き込みストライプのバランスを取り直します。エラーが原因でデバイスが機能低下モードに陥る場合、ZFS はできる限りそのデバイスへの書き込みを行わないようにし、代わりに、ほかのデバイス間に負荷を分散させます。 最後に、ZFS はファイルシステムごとに組み込み型のデータ圧縮を提供します。圧縮はディスク上の消費スペースを削減するだけでなく、入出力の必要回数を 2 倍から 3 倍も減少させることができます。このため、作業負荷が CPU バウンドでなく I/O バウンドであれば、圧縮を有効にすることで、実際にいくつかの作業負荷の処理速度が高まります。 ZFS のベンチマークに関する情報は、次のページを参照してください。
次の記事では、より実践的な ZFS の使用、ストレージプールとファイルシステムの作成、ファイルシステムのパラメータの設定、データスナップショットとクローンについて取り上げる予定です。 さらに、ZFS の開発において実現が差し迫っているさらに興味深いいくつかの機能を明らかにします。 関連情報
ここで取り上げたすべてのテクニカルマニュアル内のコード (記事、FAQ、サンプルを含む ) は、特にほかのライセンス供与がない限り、このライセンスの下に提供されています。 |
 
BigAdmin SubscriptionsBigAdmin Areas
BigAdmin Sun Center
BigAdmin Topics | ||||
 | |
