ZFSのトレードオフ
当社のStorageに使われているZFSは、データの一貫性とデータ保護を重視した堅牢なファイルシステムです。
しかし、安全性を担保したことにより、技術的に従来のシステムとは異なるトレードオフがあります。
ZFSの安全性と、容量に対するトレードオフ
ZFSは、スナップショットやクローン、圧縮、暗号化、など様々な魅力的な機能があるだけでなく、データの安全性にも定評があるファイルシステムです。最大の特徴は、CoW(Copy on Write)の構造上、RMW(Read modify Write)方式と違い、データロストがほとんど起きず、fsckなどの起動時のディスクチェックが不要になるというメリットが上げられます。
かわりに「メモリやディスクが潤沢にある」ことが前提に設計されているため、CPUコアの余裕、メモリの余裕、ストレージの余裕が十分に必要になります。
具体的な数字は利用用途によって異なりますが、ZFSに割り充てるキャッシュメモリは、ストレージ容量に関しては、概ね1/512程度の用意しておくことをお薦めしています(※1TBであれば2GB)。これは、システム設計の上で、OSのカーネルが自動的にメモリを専有するものだと考えて、キャパシティ設計をする必要があることを意味します。
ストレージは、必要な容量の2〜3倍程度を用意することをお薦めしています。これは、ZFSがデータロストなどがないようにCopy On Writeを利用していることにも起因します。書き換え時、データは新しい場所に書き込まれ、ある程度、ストレージのIOが少ないときに不要になったエリアを回収する構造となっており、バーストライトが発生するシステムの場合は、中々、削除された領域が解放されないこととなります。安全性側に余裕をみた設計だと考えてください。
レコードサイズ
UFSは8kですが、ZFSでは128kがデフォルトです。データサイズをレコードサイズで割り、あまりのレコードサイズ未満のデータは全てパディング(レコードサイズの量)になります。
スナップショット
クラウド化の時、様々な状態で試行錯誤を行う場合があります。その際、現時点のスナップショットを取って以前の状態を保全したり、Solaris10では、ZFSによって拡張されたLive Upgradeの機能でるlucreateコマンドとluactivateを利用、Solaris11ではbeadmにより「起動環境」を複数持つことが可能です。
クローン
スナップショットを元に、データのクローンが可能です。
CoWの安全性とデータの遅延削除
CoWの以前のファイルシステムは、Read Modify Write(RMW)方式を多々利用していました。
RMWはデータ更新時に同じ場所に書き換え後のデータを保存するため、書き換え中の瞬間にシステムクラッシュが起きると、そこに保存されていた元のデータが欠損したり、データ化けが発生します。たとえばデータベースなどで、特定カラム、レコードのアップデートなどを頻繁に発生するシステムなどでは、そのエリアのチェックサムが壊れたりしてデータがまるごと失われたりし、データベースの復元ができなくなったり、データベースの再起動ができなくなることもありえます。このようにRMW方式は、ストレージの容量効率は良いものの、予期せぬクラッシュ時のデータの欠損が問題となっていました。
ZFSは、Copy On Write(CoW)を採用したファイルシステムです。CoWでデータ更新が必要になると、レコードサイズ単位で読み込み、新しい場所にデータをコピーして格納し、指し示すポインタを切り替え、最終的には元のデータ箇所を開放します。この手法により、どの瞬間にシステムがクラッシュしたとしても、書き込み前の状態(元のデータ)には、最悪条件でも保持ができます。このことで、RMWのデータ化け問題が抜本的に解決されましたが、開放タイミングまでは「書き換え後データ」と「元のデータ」の両方が、ストレージ上に保存されています。実際の解放処理は、ストレージが忙しくないタイミングに行うため、読み書き、書き込みの頻度が多いシステムでは、空き容量がなかなか解放されないことになり、見かけ上の利用容量と実際の利用容量に差異がでるようになっています。
このように、ZFSは安全を担保するため、容量をトレードオフとしてつかうため、「残り容量」には十分な空きを用意し、システム設計時には充分な空きを確保しておく方が良いこととなります。
デフラグ不要に対するトレードオフ
SSDであったとしても、フラグメント(実際にデータを格納する領域の分断)が発生することで、DMAなどによる連続読み込みができなくなるため、データはなるべく連続した領域に保存されることが理想です。
そこで現在のファイルシステムは、データを格納する際に連続した領域に保存することで読み書きの速度を上げるように設計されています。しかし一度、限界まで使ってしまったストレージの場合、ファイルの更新が行われる度に、今から書き込むデータが「連続して配置できる領域」を探す必要があります。
フラグメントが起きないようにするには、連続したストレージの空き領域を探すこととなります。確率的に、ストレージの残り容量が少ないほど、フラグメンテーションが起きない場所に配置する事が難しくなるため、ZFSでは、通常では「最速一致」方式を、残り容量が一定を切った段階で「最良一致」に変更します。
アルゴリズムが最速一致(最初に見つけたブロックを利用する)から、最良一致(もっともちょうどサイズのブロックを利用する)に変わる時、空いた場所の検索をする負荷が格段に上がり、書き込み速度が顕著に悪化しはじめます。
このタイミングはストレージの利用率によって判断され、現在、当社のストレージで使われているZFSでは、全容量の90％程度となります。したがってストレージ利用では90％未満の利用を死守ラインと考えていただくこととなります。
以上のように、ストレージサイズには余裕が必要になるため、2〜3倍を想定しながら、十分な容量の割当を行ってください。
