ZFSの特徴
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が少ないときに不要になったエリアを回収する構造となっており、バーストライトが発生するシステムの場合は、中々、削除された領域が解放されないこととなります。
このように、安全性の担保のために、CPU、メモリ、リソース(ストレージ容量など)に十分な余裕を持たせる必要があります。
レコードサイズとRAIDと安全性
UFSは8kですが、ZFSでは128kがデフォルトです。
レコードサイズは、データを書き込む単位のサイズです。たとえば129kiBの場合には2レコード必要とし、実際にはディスクは256KiBの容量が必要となります。つまり、レコードサイズ未満の余りのデータは全てパディング(0で埋める)されます。
また、ZFSでは通常のRAID5やRAID6とは異なり、RAIDZ1、RAIDZ2では、エンドポイントでのデータ保護が行われます。一般のRAID5/6では、ディスクは数本に渡って分散され、ディスク故障の冗長性担保を行っていますが、ファイルシステムの単位の安全性は担保されていません。
しかしRAIDZ/Z2/Z3などの場合は、ファイルをそれぞれのディスクへセクタサイズ4KiB単位で書き、パリティ分を1/2/3本分追加します。この手法で読み書きすることで、ファイルの読み書きの単位でデータの欠損がわかるようになっていますが、かわりにRAIDとして束ねる本数に対して余りに小さなレコードサイズにすると、実データに対してパリティの比率が増加し、ペイロードが大きい利用方法となってしまいます。
スナップショット
スナップショットとは、その瞬間、つまりその「時点」のストレージのイメージを文字通り「スナップショット」として取得する事で、いつでもその時点のデータを取り出すことができる仕組みです。
ZFSのスナップショットは、ファイルシステムの層で行い、データの「差分のみを保持」することにより実現しています。したがって、ある時点のスナップショットを取得したからといって、スナップショット時点のデータと、今現在のデータ、つまり単純計算で2倍のデータを保持しているわけではなく、あくまでその後の差分だけを保持しているため、ストレージ容量の節約になっています。
スナップショットに関しては下記のページを参照してください。
参照≫ テクニカルノート/スナップショットとは？(StorageやPrivate CloudのSnapshot)
この内容から導き出されるとおり、スナップショットが作られているシステムでは、利用容量の計算が難しくなります。
クローン
スナップショットを元に、データのクローンが可能です。
CoWの安全性とデータの遅延削除
CoWの以前のファイルシステムは、Read Modify Write(RMW)方式を多々利用していました。
RMWはデータ更新時に同じ場所に書き換え後のデータを保存するため、書き換え中の瞬間にシステムクラッシュが起きると、そこに保存されていた元のデータが欠損したり、データ化けが発生します。
たとえばデータベースなどで、特定カラム、レコードのアップデートなどを頻繁に発生するシステムなどでは、そのエリアのチェックサムが壊れるとデータがまるごと失われ、データベースの復元ができなくなります。そのため、ワーストケースでは、データベースの再起動さえできなくなることもありえます。このように一般的なRAID5/6の上に作られるRMW方式のファイルシステムは、ストレージの容量効率は良いものの、予期せぬクラッシュ時のデータの欠損が問題となっていました。
ZFSは、Copy On Write(CoW)を採用したファイルシステムです。CoWでデータ更新が必要になると、レコードサイズ単位で読み込み、新しい場所にデータをコピーして格納し、指し示すポインタを切り替え、最終的には元のデータ箇所を開放します。
この手法により、どの瞬間に、どんなワーストケースでシステムがクラッシュしたとしても、書き込み前の状態(元のデータ)には戻ることができる、つまり保持されています。このことで、RMWのデータ化け問題が抜本的に解決されましたが、開放タイミングまでは「書き換え後データ」と「元のデータ」の両方が、ストレージ上に保存されています。実際の解放処理は、ストレージが忙しくないタイミングに行うため、読み書き、書き込みの頻度が多いシステムでは、空き容量がなかなか解放されないことになり、見かけ上の利用容量と実際の利用容量に差異がでるようになっています。
このように、ZFSは、安全を担保するため、容量をトレードオフとしてつかうため、「残り容量」には十分な空きを用意し、システム設計時には充分な空きを確保しておく方が良いこととなります。
デフラグ不要に対するトレードオフ
SSDであったとしても、フラグメント(実際にデータを格納する領域の分断)が発生することで、DMAなどによる連続読み込みができなくなるため、データはなるべく連続した領域に保存されることが理想です。
そこで現在のファイルシステムは、データを格納する際に連続した領域に保存することで読み書きの速度を上げるように設計されています。しかし一度、限界まで使ってしまったストレージの場合、ファイルの更新が行われる度に、今から書き込むデータが「連続して配置できる領域」を探す必要があります。
フラグメントが起きないようにするには、連続したストレージの空き領域を探すこととなります。確率的に、ストレージの残り容量が少ないほど、フラグメンテーションが起きない場所に配置する事が難しくなるため、ZFSでは、通常では「最速一致」方式を、残り容量が一定を切った段階で「最良一致」に変更します。
アルゴリズムが最速一致(最初に見つけたブロックを利用する)から、最良一致(もっともちょうどサイズのブロックを利用する)に変わる時、空いた場所の検索をする負荷が格段に上がり、書き込み速度が顕著に悪化しはじめます。
このタイミングはストレージの利用率によって判断され、現在、当社のストレージで使われているZFSでは、全容量の90％程度となります。したがってストレージ利用では90％未満の利用を死守ラインと考えていただくこととなります。
以上のように、ストレージサイズには余裕が必要になるため、2〜3倍を想定しながら、十分な容量の割当を行ってください。
