ZFSホストでVMを実行するとパフォーマンスにどのような影響がありますか？

LinuxでZFSを使用して、Debian Linuxホストのデータストレージ用にext3からZFSに移行することを検討しています。私が本当に欲しいZFSのすばらしい機能の1つは、データの整合性の保証です。ストレージのニーズの増加に合わせてストレージを簡単に拡張できることも楽しみです。

ただし、同じホストでいくつかのVMを実行します。（通常、私の場合、ホスト上で同時に実行されるVMは1つだけです。）

ZFSのデータチェックサムとコピーオンライトの動作、およびVMディスクイメージが比較的大きなファイルである（私のメインVMのディスクイメージファイルは現在31 GBにある）ことを考慮すると、そのようなVMゲスト内のパフォーマンスへの影響はどうなりますか移行？パフォーマンスへの悪影響の可能性を減らすために、どのような手順を実行できますか

必要に応じて、VMディスクイメージのデータ整合性をあまり保証せずに生きることができ（VM内で実際に重要なことは何もしません）、ファイルシステムの残りの部分から簡単に分離できますが、そうしないといいでしょう（選択的にでも）別のファイルシステムに移行したいと思うほとんどの機能をオフにする必要はありません。

ハードウェアは、ワークステーションクラスのシステムにはかなり強力ですが、ハイエンドサーバー（32 GB RAMを使用することはめったにない> 10 GBを超える32 GB RAM、6コア3.3 GHz CPU、現在2.6 TB使用可能）ディスク容量に応じてdf、合計で約1.1 TBの空きがあります.ZFSに移行すると、さらに空き容量が追加される可能性があります）、データ重複排除の実行を計画していません（重複除去をオンにしても、私の状況ではあまり追加されません）。計画はJBOD構成から開始することです（明らかに適切なバックアップを使用します）が、条件が許せば、最終的には双方向ミラーのセットアップに移行するかもしれません。

ZFSはブロックレベルで動作するため、ファイルのサイズに違いはありません。ZFSはより多くのメモリとCPUを必要としますが、ファイルシステムとして本質的にそれほど遅くはありません。ただし、RAIDZの速度はRAID5と同等ではないことに注意する必要があります。RAID10は、速度が優先される場合に適しています。

まともな（つまりバフ）ハードウェア上のZFSは他のファイルシステムよりも高速である可能性が高いため、高速（つまりSSD）の場所にZILを作成する可能性があります。これは、本質的に書き込みをキャッシュする場所です（まあ、ext3 / 4のジャーナルのようなものです）。これにより、実際のスピンドルがデータを持つ前に、ボックスackがディスクに書き込まれていると書き込みます。

読み取りキャッシュ用にSSD上にL2 ARCを作成することもできます。これは、複数のVMを同時に起動することで物理ディスクをひざまずくことができるVM環境では素晴らしいです。

ドライブはVDEVに入り、VDEVはzpoolに入ります（一度にディスク全体を使用してください）。これが小規模なシステムの場合、単一のzpoolと（データの損失をあまり気にしないのであれば）単一のVDEVが必要になる場合があります。VDEVは、RAIDレベルを選択する場所です（ただし、十分なディスクがある場合は、VDEVをミラーリングすることもできます）。VDEVで最も遅いディスクが、VDEV全体の速度を決定します。

ZFSはすべてデータの整合性に関するものです。ファイルシステムメンテナンス用の従来のツール（fsckなど）の多くが存在しない理由は、ZFSファイルシステムでは解決できない問題です。

IMO ZFSの最大の欠点は、ファイルシステムがフル（たとえば75％以上）に近づくと、非常に遅くなることです。そこに行かないでください。

31GBは本当に大きくありません...

とにかく、現在使用しているファイルシステムによっては、ZFSが少し遅いことがわかりますが、ハードウェアの仕様を考慮すると無視できる場合があります。

明らかに、ZFSはキャッシュに十分なRAMのチャンクを使用します。これにより、VMが一般的な使用（「読み取りまたは書き込みを大量に行わない」場合）で「スナップ」に見えることがあります。LinuxでZFSがどのように調整されているかはわかりませんが、可能であれば、ARCを制限してすべてのRAMで実行を停止する必要があるかもしれません VM）。

圧縮を有効にします（最近のアドバイスでは、正当な理由がない限り、圧縮をオンにします）。ファイルシステムにデータを配置する前に、これを実行する必要があることを忘れないでください。圧縮アルゴリズムは一般にディスクIOよりも高速に実行されるため、ほとんどの人は驚くほど驚いています。6コアプロセッサのパフォーマンスの問題の多くを引き起こすとは思いません。VMがあまり圧縮することを期待していませんでしたが、デフォルトの圧縮設定でちょうど470GBのVMデータを304GBに変換することができました。

重複排除に煩わされることはありません。後で戻ってくるだけで、それを取り除こうとして何週間もデータをシャッフルします。

パフォーマンスの問題が発生した場合、明白な答えはSSDをZIL / L2ARCまたはその両方として追加することです。両方に1つのデバイスを使用することは理想的ではありませんが、少数のディスク/ vdevを含むプールでパフォーマンスを改善する可能性が高いでしょう。

追加するには：可能であれば（理想的にはミラーリング）冗長構成から始めるか、できるだけ早くストライプからミラーリングに変換します。ZFSはすべてのデータをチェックサムし、その場で（またはスクラブ中に）エラーを検出しますが、それについては何もできません（copys = 2を使用しないとディスク使用量が2倍になります）。ファイル（おそらくVMディスクイメージ）にエラーがあり、それらのファイルを削除して再作成しないと多くのことを行えないことを伝えるだけです。

ユースケースとVMに応じて、以下を検討します。ホストオペレーティングシステムに、ZFSボリュームに保存しているファイルを処理させます。

可能であれば、オペレーティングシステムと必要なバイナリファイルのみを含む、すべてのVMに対してLUNのみを作成します。また、NFS、samba、iSCSI（またはコメントに記載されているzvols）を介した共有として、個々のデータのストレージステージを提示します。ZFSは、チェックサムとアクセス時間などにより、すべてのファイルを追跡できます。もちろん、速度がそれほど重要でない場合は、一部のデータストアで圧縮を有効にすることもできます。利点は、別のファイルシステムのレイヤーが欠落することです。2番目の仮想ハードドライブ用にLUNを作成し、その上にNTFSファイルシステムを作成する場合、ZFSは大きなバイナリブロブを処理する必要があり、コンテンツやファイルをまったく知らないため、ZILまたはARCキャッシュを利用できません飛行機のファイルと同じように。

ACLについて言及すると、ZFSはNFSv4またはSamba（有効な場合）を介してACLを使用できます。FreeBSDでZFSを使用していることは認めていますが、ZFSボリュームに合致するSambas ACLを有効にする方法は保証できません。しかし、これは大したことではないはずです。

読み取りキャッシュと組み合わせた重複排除は、すべてのVMが同じブロックの読み取りを開始するため、スペースを節約し、大量読み取り（ブートストーム）を改善するという点で大きな利点です。

VMおよびデータストアのZFSスナップショットについても同様です。単純なシェルスクリプトを作成して、VMをフリーズし、VMとデータストアのスナップショットを作成して作業を続行するか、データストアのみを作成し、元のスナップショットを表示するVMのクローンを作成して、いくつかをテストできます。

ZFSでは可能性は無限です;）

編集：うまくいけば、私はそれをもう少し良く説明した

EDIT2：個人的な意見：RAIDZ2（RAID6）の使用を検討してください。二重ディスク障害に耐えることができます！スペアディスクが1つだけ残っている場合、それは間違いではありませんが、2回のディスク障害で迅速に復旧できます。ここでディスクの状態を監視するためのスクリプトをポストするだけです