差分

このページの2つのバージョン間の差分を表示します。

--- memo:test [2020-12-03 10:30]
Decomo
+++ — (現在)
@@ 行 1: / 行 1: @@
-. ZFS Primer
-ZFSは先進的で現代的なファイルシステムで、特に伝統的なUNIXファイルシステムでは利用できなかった機能の提供を目的に設計されました。
-オリジナルはSunにおいてソースのオープン化の意向とともに開発されたため、他のオペレーティングシステムへ移植することが可能でした。
-OracleによるSunの買収後、ZFSのオリジナル開発者の何人かが、オープンソースバージョンの継続的な共同開発を提供するために[[http://open-zfs.org/wiki/Main_Page|OpenZFS]]を創設しました。
-ここにZFSの特徴の概要を記します：
-**ZFSはトランザクションを持つCopy-On-Write ([[https://en.wikipedia.org/wiki/ZFS#Copy-on-write_transactional_model|COW]])なファイルシステムです。**
-各書き込み要求について、関係するディスクブロックのコピーが作られ、そして全ての変更は元のブロックではなくコピーに対して作用します。
-書き込みが完了すると、全てのブロックポインタの指す先がその新しいコピーに変更されます。
-これは、ZFSは常に空き領域に書き込み、ほとんどの書き込みはシーケンシャルで、そして古いバージョンのファイルは新バージョンの書き込みが完全に成功するまで分離されないことを意味します。
-ZFSはディスクへの直接アクセスを行い、複数の読み込み/書き込み要求をトランザクションにまとめます。
-ほとんどのファイルシステムはこれを行わず、ただディスクブロックへアクセスするのみです。
-完了か失敗どちらか一方に定まるトランザクションは、[[https://blogs.oracle.com/bonwick/raid-z|ライトホール]]は決して存在せず、そしてファイルシステムの確認ユーティリティは必要ないことを意味します。
-このトランザクションベースの設計により、追加のストレージ領域が足されれば、それはすぐさま書き込み用に利用可能となります。
-データの再均衡化のために、データをコピーして既存のデータを全ての利用可能なディスクに横断的に上書きすることができます。
-ビットファイルシステムなので、ファイルシステムとファイルの最大サイズは16エクサバイトです。
-**ZFSは自己修復ファイルシステムとして設計されました。**
-ZFSはデータを書くたびに、対象のディスクブロックごとにチェックサムを生成し記録します。
-ZFSはデータを読むたびに、対象のディスクブロックごとのチェックサムを読み込み検証します。
-メディアのエラーや“ビット腐敗”はデータに変化を引き起こし、そのチェックサムが一致することはありません。
-ZFSがミラーないしRAIDZ構成のプール上にディスクブロックのチェックサムエラーを検出した場合、ZFSは壊れたデータを正しいデータで置き換えます。
-滅多に読まれないディスクブロックもあることから、定期的なscrubをスケジューリングし、ZFSが全データブロックを読んでチェックサムの検証と異常ブロックの訂正が行えるようにすると良いでしょう。
-冗長性とデータ訂正の提供のために複数のディスクが要求される一方で、1ディスクのシステムにおいてもZFSはデータ異常検出を提供します。
-FreeNAS®は各ZFSプールに対し月1回のscrubを自動的にスケジュールし、その結果は[[https://www.ixsystems.com/documentation/freenas/11.3-U5/storage.html#pools|Pools]]を選択し (Settings)→Statusとクリックすると表示されます。
-scrub結果をチェックすることは、ディスクの潜在的な問題の早期発見につながる可能性があります。
-伝統的なUNIXファイルシステムと違い、**ファイルシステム作成時にパーティションサイズを決める必要はありません。**
-代わりに、vdevと呼ばれるディスクのグループがZFSプールに組み込まれます。
-ファイルシステムは必要に応じて、そのプールから生成されます。
-より多くの容量が必要になった時は、同一のvdevをプールにストライピングすることができます。
-FreeNAS®の[[https://www.ixsystems.com/documentation/freenas/11.3-U5/storage.html#pools|Pools]]はプールの作成と拡張に使われます。
-プールの作成後、必要に応じて、プールから動的サイズのデータセットまたは固定サイズのzvolを切り出すことができます。
-データセットを用い、格納されるデータの種類に応じたパーミッションや容量制限・圧縮といったプロパティをデータセット単位で設定し、ストレージを最適化することができます。
-zvolは本質的には生の仮想ブロックデバイスで、iSCSIデバイスエクステントなどのローデバイスを必要とするアプリケーションで使用されます。
-**ZFSはリアルタイムデータ圧縮をサポートします。**
-ブロックがディスクに書き込まれたときに圧縮が行われますが、そのデータが圧縮の恩恵を受けられる場合に限ります。
-圧縮済みブロックにアクセスがあった時は、自動的に展開されます。
-圧縮はファイルレベルではなくブロックレベルで行われるため、あらゆるアプリケーションが透過的に圧縮データにアクセスします。
-FreeNAS®バージョン9.2.1以降で作られたZFSプールは、推奨のLZ4圧縮アルゴリズムを使います。
-**ZFSは低コストの即時スナップショットを提供します。**対象となるのはプール、データセット、あるいはzvolです。
-COWのおかげで、スナップショットは最初は余分な領域を必要としません。
-スナップショットのサイズは時間とともに、スナップショットに含まれるファイルがディスクに書き込まれ、変更があるにつれ増加します。
-スナップショットを使うと、スナップショットを取得した時点のデータのコピーを提供することできます。
-通常、ファイルが削除されると対応するディスクブロックは空きリストに追加されます。しかし、スナップショット内にファイルが存在する場合、参照するすべてのスナップショットが削除されるまで、ファイルブロックが空きリストに追加されることはありません。
-これにより、スナップショットはファイルの履歴の保持、古いコピーや削除されたファイルの復元に便利な賢い手段となります。
-こうした理由で, 多くの管理者は頻繁にスナップショットを取得し、一定期間保存し、そして別のシステムに保管します。
-このような戦略は、管理者にシステムを特定の時点へロールバックすることを可能とします。
-もし破滅的なデータ消失があった場合、オフサイトのスナップショットはシステムを最後の定期スナップショット─例えばデータ消失の直前15分の時点に、システムを復元することができます。
-スナップショットはローカルに保管されますが、リモートのZFSプールにレプリケートすることもできます。
-レプリケーションでは、ZFSはバイト単位のコピーは行わず、代わりにスナップショットをデータストリームへ変換します。
-この設計は、受信側のZFSプール構成が同一である必要はなく、異なるRAIDZレベル、プールサイズ、あるいは圧縮設定が使用可能なことを意味します。
-**ZFS Boot Environemtはシステム更新の失敗から復旧する手段を提供します。**
-FreeNAS®では、アップグレードやシステム更新の前に、OSが存在するデータセットのスナップショットが自動取得されます。
-この保存済みBoot Environmentは自動的にGRUBブートローダに追加されます。
-万が一、アップグレードや設定変更が失敗したら、単にシステムを再起動し起動メニューから以前のBoot Environmentを選択します。
-ユーザーは必要に応じて、例えば設定変更を行う前にSystem ➞ Bootで自身のBoot Environmentを作ることもできます。
-**ZFSはライトキャッシュを提供します。**オンメモリキャッシュとZFSインテントログ(ZIL)があります。
-ZILは、[[https://pthree.org/2013/04/19/zfs-administration-appendix-a-visualizing-the-zfs-intent-log/|「同期書き込み」を、ZFSプールに書き込まれるまで一時的に保持する]]ストレージ領域です。
-高速（低遅延）で電源保護されたSSDをSLOG (Separate Log)デバイスとして追加すると、はるかに高い性能を得られます。
-これはESXi越しのNFSに不可欠で、またデータベースサーバや同期書き込みに依存する他のアプリケーションで強く推奨します。
-SLOGの恩恵と使い方の詳細は、以下のブログとフォーラムの投稿をご覧ください：
-  * [[http://www.freenas.org/blog/zfs-zil-and-slog-demystified/|The ZFS ZIL and SLOG Demystified]]
-  * [[https://forums.freenas.org/index.php?threads/some-insights-into-slog-zil-with-zfs-on-freenas.13633/|Some insights into SLOG/ZIL with ZFS on FreeNAS®]]
-  * [[http://nex7.blogspot.com/2013/04/zfs-intent-log.html|ZFS Intent Log]]
-SMB、AFP、iSCSIでは同期書き込みは比較的まれで、すなわち、これらプロトコルの性能改善のためのSLOG追加は特別な場合のみであると意味します。
-システムがSLOGの恩恵を受けられるかの判定のため、zilstatユーティリティをShellで実行することができます。
-使い方の情報は[[http://www.richardelling.com/Home/scripts-and-programs-1/zilstat|このウェブサイト]]をご覧ください。
-現在のところZFSはSLOG用に16GiBの領域を使います。
-より大きなSSDを組み込んでも、余分な領域は使用されません。
-SLOGデバイスはプール間で共有できません。
-それぞれのプールは別々のSLOGデバイスを要求します。
-帯域とスループットの制約により、SLOGデバイスはこの単一目的のためだけに使用されなければなりません。
-同一のSSDに他のキャッシュ機能を追加しようとしてはなりません。さもないと性能を損なうことになるでしょう。
-ミッションクリティカルなシステムでは、ミラー構成のSLOGデバイスを強く推奨します。
-ミラー構成のSLOGデバイスはZFSバージョン19以前のZFSプールで要求されます。
-ZFSプールのバージョンはShellで''zpool get version プール名''コマンドで確認します。
-バージョン番号が「-」の場合、そのZFSプールは（Feature Flagとしても知られる）バージョン5000かそれ以降を意味します。
-**ZFSはリードキャッシュを提供します。**ARCとして知られる読み込みレイテンシを削減するオンメモリキャッシュです。
-FreeNAS®はARCの状態をtop(1)に追加し、またARCの効率をモニタリングするためのarc_suymmary.pyとarcstat.pyツールを含みます。
-SSDを専用キャッシュデバイスとして使う場合、それはL2ARCとして知られています。
-追加の読み込みデータはL2ARCにキャッシュされ、ランダム読み込み性能を向上させます。
-L2ARCは（ZFSにおける）十分なメモリの必要性を低減するものではありません。
-事実、L2ARCは機能するのにメモリを必要とします。
-ARC用に必要十分なメモリがない場合、L2ARCを追加しても性能は増加しません。
-実際のところ、殆どの場合で性能が低下し、潜在的にシステムの不安定性を引き起こします。
-RAMは常にディスクより速いので、システムがL2ARCデバイスからの恩恵を享受できるかどうかを考える前に、まずは可能な限りのRAMを追加します。
-アプリケーションがデータセットに対し、L2ARCに十分に収まるサイズ程度の膨大な量のランダム読み込みを行う場合、専用キャッシュデバイスの追加によって読み込み性能が向上する可能性があります。
-SSDキャッシュデバイスは、活きているデータ量がシステムRAMより大きく、かつSSDの大きさに対し十分に小さい場合にのみ有効に働きます。
-原則として、32GiBのRAMより小さなシステムにL2ARCを追加するべきではなく、L2ARCの大きさはRAM量の10倍を超えるべきではありません。
-幾つかのケースにおいて、2つの別々のプールを持つ方が効率的かもしれません：1つはアクティブデータ用としてSSDに、そしてもう1つは稀に使われるコンテンツ用としてHDDに。L2ARCデバイスの追加後、arcstatなどのツールでその効率を監視します。
-既存のL2ARCのサイズを増やすには、別のキャッシュデバイスを取り付けストライピングします。
-ウェブインタフェースからは、L2ARCをミラーではなく常にストライピングで追加します。そして、L2ARCの内容は起動のたびに再生成されます。
-プールのL2ARCを構成する個々のSSDの障害はプールの整合性に影響しませんが、読み込み性能にインパクトを与える可能性があり、これはワークロードおよびデータセットサイズとキャッシュサイズの比率に依存します。
-専用L2ARCデバイスはZFSプール間で共有できないことに留意してください。
-**ZFSは冗長性を提供すると同時にハードウェアRAIDに内在する幾つかの問題に取り組むよう設計されました。**その問題とは、ライトホール問題とハードウェアコントローラが警告を出す前に、書き込まれたデータが時間とともに壊れる問題です。
-ZFSは3レベルの冗長性を提供し、それはRAIDZとして知られ、そしてRAIDZの後ろの数値はデータを保ったまま失うことのできるvdevあたりのディスク数を示します。
-ZFSはミラー構成にも対応し、ミラー中のディスク数に制限はありません。
-ZFSは一般品のディスク向けに設計されたため、RAIDコントローラは必要ありません。
-ZFSをRAIDコントローラとともに使うこともできますが、ZFSはディスクの全制御を行うため、コントローラをJBODモードにすることを推奨します。
-使用するZFS冗長性の種類を決定する際、ゴールはディスク容量の最大化なのか性能の最大化なのかを考えます：
-  * RAIDZ1はディスク容量を最大化し、一般的に大きなチャンク（128KB以上）のデータの読み書きの時に良く機能します。
-  * RAIDZ2はRAIDZ1よりも良いデータ可用性と有意に良好な平均データ消失時間(MTTDL)を提示します。
-  * ミラーリングはディスク容量をより消費しますが、一般的に小さなランダムリードでより良く機能します。より良い性能のためには、あらゆるRAIDZよりミラーを強く推奨します。巨大で、キャッシュ不可能なランダムリードの負荷ではなおさらです。
-  * vdevあたり12を超えるディスクの利用は非推奨です。vdev毎の推奨ディスク数は3～9です。より多くのディスクを扱う場合は、複数のvdevを使ってください。
-  * 古いZFSドキュメントのなかには、最適性能の達成のため各RAIDZタイプごとに特定数のディスクを推奨しているものがあります。LZ4圧縮を使うシステムにおいて、これには標準のFreeNAS® 9.2.1以降も含まれますが、もはや真実ではありません。詳細は[[https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz|ZFS RAIDZ stripe width, or: How I Learned to Stop Worrying and Love RAIDZ]]をご覧ください。
-以下の情報源も、特定のストレージ要求に対する最適なRAID設定の選定に役立つでしょう：
-  * [[https://forums.freenas.org/index.php?threads/getting-the-most-out-of-zfs-pools.16/|Getting the Most out of ZFS Pools]]
-  * [[https://constantin.glez.de/2010/06/04/a-closer-look-zfs-vdevs-and-performance/|A Closer Look at ZFS, Vdevs and Performance]]
-<note warning>警告
-__
-RAIDとディスク冗長化は、信頼あるバックアップ戦略の代わりではありません。
-悲運に見舞われた時、価値あるデータを守るために善きバックアップ戦略が依然として求められます。
-__
-[[https://www.ixsystems.com/documentation/freenas/11.2/tasks.html#periodic-snapshot-tasks|Periodic Snapshot Tasks]]と[[https://www.ixsystems.com/documentation/freenas/11.2/tasks.html#replication-tasks|Replication Tasks]]を見て、バックアップ戦略の一部として複製されたZFSスナップショットを使ってください。
-</note>
-**ZFSはデバイスを管理します。**
-ミラーやRAIDZの構成デバイスに障害が発生しユーザーによって交換された時、ZFSは置き換えられたデバイスをvdevに追加し、resilveringと呼ばれる処理の中で冗長データを新デバイスにコピーします。
-ハードウェアRAIDコントローラは、通常、どのブロックが使われているかを知る術がないため、全てのブロックを新デバイスにコピーしなければなりません。
-ZFSは使用中のブロックだけをコピーするので、vdevの再構築時間を削減します。
-Resilveringは中断可能でもあります。
-中断後、resilveringは最初から開始するのではなく、中断した部分から再開します。
-ZFSは多くの恩恵を提供する一方、いくつかの注意点があります：
-  * 容量の90%に達すると、ZFSは最適化戦略を性能ベースから空間ベースへと切り替えます。これは性能に関して大変な意味合いを持ちます。最大書き込み性能とドライブ置き換え時の問題を防ぐために、プールの使用率が80%に達する前に容量を増やしてください。
-  * vdevあたりの使用ディスク数を考える時、そのディスクのサイズとvdevの再構築処理であるresilveringに要する時間を考慮します。大きなサイズのvdevは、それだけresilveringが長くなります。RAIDZ内のディスクを置き換える場合、resilvering処理の完了前に別のディスクが故障する可能性があります。故障ディスクの数がRAIDZの種類によって決まるvdevあたりの耐障害数を超えると、そのプールのデータは失われます。この理由により、1TiB以上のドライブでRAIDZ1はおすすめしません。
-  * vdevを作成する場合、使用するドライブの容量を合わせることを推奨します。ZFSは異なる容量のドライブでvdevを作成できるものの、vdevの容量は最小のディスクの容量によって制限されます。
-ZFS入門者にとって、WikipediaのページはZFSの特徴をより知るための素晴らしい出発地点を提供します。
-参考までに、以下の情報源も有益です：
-  * [[https://wiki.freebsd.org/ZFSTuningGuide|FreeBSD ZFS Tuning Guide]]
-  * [[https://docs.oracle.com/cd/E19253-01/819-5461/index.html|ZFS Administration Guide]]
-  * [[https://www.youtube.com/watch?v=tPsV_8k-aVU|Becoming a ZFS Ninja Part 1 (video)]] と [[https://www.youtube.com/watch?v=wy6cJRVHiYU|Becoming a ZFS Ninja Part 2 (video)]]
-  * [[https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/zfs.html|The Z File System (ZFS)]]
-  * [[https://www.youtube.com/watch?v=aTXKxpL_0OI&list=PL5AD0E43959919807|ZFS: The Last Word in File Systems - Part 1 (video)]]
-  * [[https://www.youtube.com/watch?v=ptY6-K78McY|The Zettabyte Filesystem]]
-.1. ZFS Feature Flags
-OracleのZFSバージョン番号との識別のため、OpenZFSは機能フラグ(feature flags)を使います。
-機能フラグは、ZFSプールで有効になっている全ての機能フラグが両方のプラットフォームでサポートされている限り、異なるプラットフォーム上で動くOpenZFS実装間での移植性を提供するために、一意の名前で機能にタグ付けするために使用されます。
-FreeNAS®はOpenZFSを採用し、FreeNAS®の各新バージョンは最新の機能フラグとOpenZFSのバグ修正を最新状態に維持します。
-FreeBSDで利用可能なOpenZFSの全機能フラグの完全なリストは[[https://www.freebsd.org/cgi/man.cgi?query=zpool-features|zpool-features(7)]]をご覧ください。