ZFSのカルト的信仰
ITの世界では、特定のカルト的または「ファンボーイ」的なメンタリティが発達することが珍しくない。このような反応がテクノロジーや製品に対して生じる原因はよくわからないが、それが起きることは否定できない。このような現象が起こるとは思っていなかった1つの分野がファイルシステムだ。これはシステムコンポーネントの中でも最も「内部的な」ものの1つで、最近まで技術的な議論においても文字通り注目されることのなかった領域だ。率直に言って、Active DirectoryとNTFSのどちらから何かが提供されているかについての誤解はほぼ遍在している。ファイルシステムは、単純に無視されている。Windows NT 4がリリースされてNTFSが唯一の実行可能な選択肢となって以来、ファイルシステムがオペレーティングシステムの固有のコンポーネントではなく、ファイルストレージには他の選択肢があるかもしれないという考えはほぼ消えていた。それが、最近まで続いていた。
この現象がある程度起こらなかった1つのコミュニティはLinuxコミュニティだったが、そこでもExt2とその子孫が圧倒的にマインドシェアを獲得したため、広く利用可能だったにもかかわらず代替ファイルシステムは脇に置かれ、歴史的にはXFSのみが注目を受け、それさえも非常に少なかった。
より最近、本当に奇妙な動きが起きているのは、OracleのZFSファイルシステムを巡るものだ。これはもともとSolarisオペレーティングシステムとX4500「Thumper」オープンストレージプラットフォームのために開発された（Oracleによる買収前は最初Sun管理下にあった）。ZFSがリリースされた当時（9年前）、競合するファイルシステムは今後構築が予想される大型ディスクアレイを扱う準備がほとんどできていなかった。ZFSはそれらを扱えるよう設計され、大規模ファイルシステムの時代を告げた。当時のほとんどのファイルシステムと同様に、ZFSは単一のオペレーティングシステムに限定されていたため、ファイルシステム設計の大きな進歩として広く認められていたが、ストレージの世界ではわずかな波しか起こさず、Solarisの管理者でさえかなりの期間は主に興味点としてのみ見なしていた。彼らは長年使用してきた実績ある信頼のUFSを使い続けることを選んでいた。
ZFSは本当に画期的なファイルシステムであり、私はその強力な支持者であり続けている。しかし、ZFSが何を行い、その目標は何であり、それらの目標がなぜ重要であったか、そして今日の私たちへの適用方法を理解することが非常に重要だ。ZFSの複雑さはファイルシステムがどのように機能するか、そしていつ使用することが適切かについて多くの混乱と誤解を招いた。
ZFSの主な目標は、非常に大型のディスクアレイにうまくスケールできるファイルシステムを作ることだった。導入時点でのZFSが対応できるスケールは他のファイルシステムでは前例のないものだったが、ファイルシステムがそれほど大型に成長する必要がある実際の世界ではまだなかった。その必要性が生じるまでには、NTFS、XFS、Ext3などの多くのファイルシステムがその必要性に対応するよう拡張されていた。ZFSは確かに大型ファイルシステム処理への道を切り開いたが、間もなく多くの他のものが加わった。
ZFSはSolarisの世界に由来しており、すべての大型のUNIXシステムと同様にハードウェアRAIDがなかった。Solarisはその独自のサブシステムとして常にソフトウェアRAIDを利用可能にしていた。新しいソフトウェアRAID実装をZFSに直接組み込む決定が下された。これにより、RAIDレイヤーとファイルシステムの両方に対して単一のツールセットによる管理の簡素化が可能になった。よく信じられているようにZFSに重大な変化や優位性をもたらしたわけではなく、単純にソフトウェアRAIDレイヤーのインターフェースを独自のコマンドセットからZFSコマンドセットの一部に移行させただけだ。
ZFSのRAID実装は、パリティRAIDレベルに可変幅ストライプを導入した。このイノベーションは「ライトホール」として知られるマイナーなパリティRAIDリスクを解消した。このイノベーションは非常に優れたものだったが、信頼性の高いパリティRAIDの時代が終わりを迎えつつあった時期に遅れて登場した。ライトホール問題はすでにパリティアレイの「バックグラウンドノイズ」リスクとして言及されないリスクと見なされていた。なぜなら、バッテリーバックアップされたアレイキャッシュ、そしてほぼ同時期に不揮発性アレイキャッシュの使用によって排除されると見なされていたからだ。電力損失を避けることでライトホールを避けられる。ZFSがこの問題に対処する必要があったのは、ソフトウェアRAIDとして電力損失から保護されたキャッシュの機会がないため、ハードウェアRAIDよりもライトホールに対して脆弱だったからだ。ハードウェアRAIDはアレイに対する電力保護の追加レイヤーの可能性を提供する。
ZFSが意図せず行った本当の「イノベーション」は、RAID 1、5、6、10の通常のRAIDレベルを実装する代わりに、これらのレベルを独自の命名規則で「ブランド化」したことだ。RAID 5はRAIDZとして知られる。RAID 6はRAIDZ2として知られる。RAID 1は単にミラーリングとして知られる。以下同様だ。これは当時は愚かで無用に混乱を招くと広く見なされたが、判明したように、その混乱が後年のZFSの復活の礎石になった。
なお、ZFSは後に業界初の量産実装としてRAID 7（別名RAID 7.3）、つまり三重パリティRAIDシステムを追加してRAIDZ3としてブランド化した。この後の追加は、最高の容量を維持しながら極めて安全でパフォーマンスを犠牲にすることも厭わない大規模アレイにとって重要なイノベーションだ。これはZFSのユニークな機能として残っているが、使用されることは稀だ。
ストレージスタックを統合して単一のコマンドセットでストレージのすべての側面を管理するという精神のもと、論理ボリューム管理機能もZFSに組み込まれた。特定のサークルではZFSが論理ボリューム管理を導入したと誤って信じられることが多いが、AIX、Linux、Windows、さらにはSolaris自身を含むほぼすべてのエンタープライズプラットフォームが既に長年にわたり論理ボリューム管理を持っていた。ZFSは新しいパラダイムを導入するためではなく、単に管理を統合し、3つの主要なストレージレイヤー（RAID、論理ボリューム管理、ファイルシステム）を1つのエンティティにまとめて管理を簡素化し、スタック上下への固有の通信を提供するためにこれを行った。この方法には長所と短所があり、ほぼ10年後も業界の意見は定まっていない。
3つのシステムを1つに統合したこの最も重要な側面の1つは、非常に混乱しやすい製品について議論することになるということだ。ZFSはファイルシステムだが、ファイルシステムだけではない。論理ボリュームマネージャーだが、論理ボリュームマネージャーだけでもない。人々はZFSをファイルシステムと呼ぶが、それが主要な機能であっても、ファイルシステム以上のものであることは非常に混乱を招き、他のストレージシステムとの比較を困難にする。この混乱は当時は予見されていなかったと思う。
この混乱した統合から生じた結果として、ZFSはしばしばXFSやExt4などの他のファイルシステムと比較される。しかしこれは混乱を招く。ZFSは完全なスタックであり、XFSはスタックの1つの側面にすぎないからだ。ZFSはXFSだけではなく、MD（LinuxソフトウェアRAID）/ LVM / XFSや、SmartArray（HP ハードウェアRAID）/ LVM / XFSと比較する方が適切だ。そうしないと、ZFSはXFSにはない機能で溢れているように見えるが、実際には意味論的な勝利に過ぎない。ZFSの支持者がよく賞賛する機能のほとんどはZFSに由来するものではなく、ZFSが存在するずっと前から代替ファイルシステムで一般的に利用可能だった。しかし「あなたのファイルシステムはそれをするのか」と比較するのは難しい。答えは「いいえ……私のRAIDや論理ボリュームマネージャーがそれをしている」だからだ。そして本当に、RAIDZを提供しているのはファイルシステムとしてのZFSではなく、ソフトウェアRAIDサブシステムとしてのZFSだ。
非常に大型のファイルシステムを優雅に処理するために、データ整合性機能がZFSに組み込まれた。これにはファイルシステム全体にわたるチェックサムまたはハッシュチェックが含まれており、組み込みのソフトウェアRAIDを活用して破損したファイルを修復できる。これはZFSファイルシステムの将来の予想サイズのために必要と見なされた。ファイルシステムの破損は稀に見られる現象だが、ファイルシステムが大きくなるにつれてリスクが増加する。ZFSのこのあまり知られていない機能は、おそらく最も優れた機能だ。
ZFSはまた、ファイルシステムチェックの処理方法も変更した。ZFSが非常に大型のファイルシステムに使用されるという前提から、起動時のファイルシステムチェックが完了するまで不可能なほど長い時間がかかるという本物の懸念があり、代替戦略が見つかった。再起動時にチェックを行うのではなく、システムはスクラビングプロセスを実行してシステムの稼働中に同様のチェックを実行する必要がある。これはシステムが稼働中にシステムオーバーヘッドを増加させるが、予期しない再起動からの回復が早くなる。トレードオフだが、広く非常にポジティブと見なされている。
ZFSは論理ボリュームレイヤーに強力なスナップショット機能を持ち、RAIDレイヤーには非常に堅牢なキャッシュメカニズムが実装されており、多くのユースケースにおいてZFSを優れた選択肢にしている。これらの機能はZFSに固有ではなく、ZFSより古いシステムで広く利用可能だ。しかし、これらはZFSの性質上、非常に優れた実装であり非常によく統合されている。
かつてZFSはオープンソースであり、その時代にZFSのコードはZFSライセンスと互換性があったAppleのMac OSXとFreeBSDオペレーティングシステムの一部となった。Linuxはライセンス周りの課題からその時点ではZFSを得られなかった。ZFSのライセンスがLinuxに制限なく使用を許可していたなら、Linuxの状況は今日と大きく異なっていただろう。Mac OSXはその環境でZFSには十分な利点がないと見なされ、最終的にZFSを廃止した。FreeBSDはZFSにしがみつき、時間の経過とともにそのプラットフォームで最も人気のあるファイルシステムとなったが、UFSも依然として広く使用されている。OracleはSun買収後にZFSのソースを非公開にし、FreeBSDはZFSバージョンの継続的な更新がなくなったが、OracleはSolaris向けにZFSの開発を内部で続けた。
今日、SolarisはオープンソースコミュニティとのZFS分離以降いくつかの更新があった元のZFS実装を使用し続けている。FreeBSDとその他は、コードが非公開になった状態のZFSを使い続け、Oracleの最新の更新にはもはやアクセスできない。最終的に、放棄されたオープンソースZFSコードベースを更新する作業が進められ、現在OpenZFSとして知られている。OpenZFSはまだ初期段階にあり、まだ本当の意味での実績を上げていないが、オープンソース空間でZFSプラットフォームを復活させる可能性を秘めているが、現時点ではOpenZFSは依然としてZFSより遅れている。
この分野でのオープンソース開発は、ここ数年はZFSの新たなライバルであるBtrFSにより焦点を当てている。BtrFSはLinuxでネイティブに開発されており、多くの主要なオペレーティングシステムベンダーから幅広くサポートされている。BtrFSは非常に初期段階だが、実装機能においてZFSとの機能パリティを達成するため大きな進歩を遂げており、大きな野望を持ち、ZFSの非公開ソースの性質から市場の勢いという恩恵を受けている。BtrFSはZFSと同様にOracleによって開始され、ZFSの後継となるOracleの将来像の見方として広く見なされ、Oracleにおいてさえそうだ。現時点でBtrFSはすでにZFSと同様に、ファイルシステム、論理ボリューム管理、ソフトウェアRAIDのレイヤーを統合し、ファイルシステム整合性のためのチェックサムを実装し、ZFSよりもさらに大きくスケールし（同じ絶対制限だがより多くのファイルを扱える）、コピーオンライトスナップショットなどを実装している。
ZFSは間違いなく、全盛期には驚くべきファイルシステムであり、今日も依然としてリーダーだ。2005年にはその支持者であり、今でも強く信じている。しかし、ZFSのコミュニティが何の役にも立たず、ZFSへの言及がほぼ否定的に聞こえるような熱狂と熱意を帯びていくのを見ることは悲しかった。ZFSがほぼ普遍的に間違った理由で選ばれているからだ。主に、その機能が他のどこにも存在しないという信念、そのRAIDがそれらのRAIDレベルが常に直面するリスクと制限に左右されないという信念、またはそれが設計されたもの（主にパフォーマンス）と異なる目的のために設計されたという信念だ。そしてZFSが良い選択肢である場合も、しばしば誤った前提に基づいて不十分な方法で実装されている。
ZFSは、もちろん、責められるべきではない。私が判断する限り、その企業の支持者やオープンソース開発者も同様だ。ZFSが道を踏み外したように見えるのは、ZFSをごく最近知った、しばしばそれが新しいか「次世代」だと信じているゆるく非公式なコミュニティにある。まさにZFSを発見したばかりだからだ。私が見たところでは、SolarisやFreeBSDのチャンネルを通じてではなく、ほぼ独占的にFreeNASやNAS4Freeのようなパッケージ化された「NAS OS」を使用したい中小企業であり、UNIXオペレーティングシステムに不慣れな人々だ。パッケージ化されたNAS OSの使用、主に深いUNIXやストレージスキルを持たないITショップによるものであり、その結果としてWindowsの外のファイルシステムの広い世界、そして特にソフトウェアRAIDを含む論理ボリューム管理やRAIDへの露出がほとんどまたはまったくないことが、ZFSを中心とした「神話」文化につながり、ZFSがほぼ疑いようのない、不可謬のステータスを帯びているように見える。
このカルト的な追随とZFSに関する一般的な誤解は、しばしばZFSの誤用や、悪い前提に基づいた意思決定の連鎖につながり、非常に大きく誤った方向に向かわせる可能性がある。
この分野で最も驚くべき変化の1つは、ハードウェアRAIDからソフトウェアRAIDへの追随の変化だ。従来、ソフトウェアRAIDはWindows管理者のサークルでは根拠なく厄介者扱いされていた。Windows管理者と中小企業は、大規模なUNIXサーバーに不慣れなため、ハードウェアRAIDが普遍的なものだと信じていたが、実際には大規模なシステムは常にソフトウェアRAIDを使用していた。ハードウェアRAIDはほぼ業界全体で必需品と見なされ、ソフトウェアRAIDは完全に忌避されていた。その同じ層が、今は「ZFSのカルト」運動に直面して、ハードウェアRAIDは悪でZFSのソフトウェアRAIDが唯一の実行可能な選択肢だと信じるまったく逆の方向に振れている。この変化は劇的であり、どちらのアプローチも有効ではない。ハードウェアとソフトウェアの両方のRAID、さらに多くの実装において、どちらも非常に有効な選択肢であり、ZFSを使用していてもハードウェアRAIDが容易に適切である可能性がある。
ZFSはしばしばファイルシステムにおける最高のパフォーマンス選択肢であると信じられて選ばれるが、これはZFSの主要な設計目標ではなかった。非常に大型にスケールし、ストレージの多くの異なる側面を処理できるようにする機能は、実際に高いパフォーマンスを発揮することを非常に困難にする。ZFSは作成当時、同じシステムで動作していた実績あるUFSと同じくらい速くなるとも期待されていなかった。しかし、これはしばしば副次的なことになる。なぜなら、ファイルシステムのパフォーマンスは広く無意味であり、すべての現代のファイルシステムは非常に速く、ファイルシステムの速度はほとんど重要な要素ではないからだ。特に非常に大規模な高性能ストレージシステム以外では。
2013年にPhoronixがLinux上の10のファイルシステムに対して実施した興味深い調査では、ワークロードによってファイルシステムに大きな差があることが示されたが、全体的なパフォーマンスに関して明確な勝者はいなかった。調査が明確に示したのは、ワークロードをファイルシステムに合わせることが最も重要な選択であり、ZFSはより現代的な実装においてさえもすべての主流ファイルシステムの中で遅い側に位置しており、ワークロードへの深い理解なしにパフォーマンスのためにファイルシステムを選択することは予測不能なパフォーマンスをもたらすということだ。パフォーマンスが重要な要素であれば、ファイルシステムを盲目的に選ぶべきではない。残念ながら、この調査はLinux上で行われたため、ZFSの主要な競合相手、特にSolarisやFreeBSD上でのUFSが欠けており、またMac OSXのHFS+も欠けていた。
ハードウェアRAIDからソフトウェアRAIDへの移行は、UNIXに経験のないショップにとって追加の、しばしば予見されないリスクを伴う。ZFSはホットスワップを可能にするが、ホットスワップは主にソフトウェアではなくハードウェアの機能であることが忘れられがちで、ブラインドスワッピング（オペレーティングシステムで最初にオフラインにせずにハードドライブを取り外すこと）はホットスワッピングと同義ではないことも広く知られていない。これは、互換性、ホットスワップ、ブラインドスワッピングを透過的に処理してくれたハードウェアRAIDの伝統から、より多くの計画、調整、安全に使用するためのシステムへの理解が必要なソフトウェアRAIDシステムに移行するショップに対して、災害をもたらす可能性がある。
ZFSのより少ないが、まだよくある誤解は、ZFSがOCFS、VxFS、GFS2のような共有DASやSANシナリオに適したクラスター化ファイルシステムだということだ。ZFSはクラスター化ファイルシステムではなく、その空間ではすべての一般的な競合他社と同じ制限を共有している。
ZFSは優れた選択肢になり得るが、唯一の選択肢ではない。ZFSには大きな注意事項があり、特にそれに関連するオペレーティングシステムの制限があり、多くの利点を持つが、そのどれも（あるとすれば）ZFSに固有のものではなく、どのショップもそれらのすべてから恩恵を受けることは非常に稀だ。あらゆる技術と同様に、トレードオフが伴う。1つのサイズがすべてに適合するわけではない。ZFSが自分にとって適切かどうかを知るための鍵は、ZFSとは何か、何がZFSに固有で何がそうでないか、設計目標は何か、ストレージスタックを純粋なファイルシステムと比較することがどのように誤解を招く結果をもたらすか、そしてどのような固有の制限が伴うかを理解することだ。
ZFSはSolarisまたはFreeBSDが選択されたオペレーティングシステムである場合の重要な検討事項であり、一般的な選択肢だ。まれな例外を除いて、ZFSのためにオペレーティングシステムを選ぶべきではなく、オペレーティングシステムが選ばれた時にZFSがしばしば（ただし常にではなく）選ばれるべきだ。OSはごく稀なケースを除いて、すべての場合においてファイルシステムの選択を牽引すべきだ。オペレーティングシステムの選択は、ファイルシステムの選択よりも劇的に重要だ。
ZFSはLinux上でも使用できるが、エンタープライズオプションとは見なされず、実験のためのホビーシステムに近い。エンタープライズベンダー（Red Hat、Suse、Canonicalなど）がLinux上のZFSをサポートしておらず、Linuxはすでに優れた代替品を持っているからだ。いつかZFSがLinuxで一流のファイルシステムに昇格するかもしれないが、BtrFSがすでにメインラインカーネルに入り、いくつかの主要なベンダーによって量産リリースに含まれているため、これは期待されていない。
ZFSはSolarisとFreeBSDのデプロイメントの大多数で見られるが、これは主にデフォルトのファイルシステムとしての地位に移行したためであり、それらのケースで明確に優れた選択肢だからでも、あるいは批判的に評価されたからでもない。ZFSはネイティブでサポートされている場所での汎用ファイルシステムとして十分に適している。
ZFSの主要なユースケースとは何か？
ZFSの設計目標と主要なユースケースは、他のサーバーに共有ストレージを提供するか、ローカルにインストールされたアプリケーション向けの大規模データリポジトリとして機能するSolarisおよびFreeBSDのオープンストレージシステムだ。これらのケースでは、スケーラビリティとデータ整合性に対するZFSの焦点が本当に輝く。ZFSは大型でエンタープライズ規模のショップに大きく傾き、Solarisとスキル、および大規模なストレージニーズが稀な中小企業への適用可能性からは一般的に離れている。
参考: http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=1
広告
