web-dev-qa-db-ja.com

ZFSは、Windowsとは大きく異なるサイズと、利用可能なものを報告します

始める前に、はい、セットアップが最適ではないことはわかっていますが、すべてを最初からセットアップする計画に取り組んでいます。もうここで働いていないアルバイトから受け継いだ。これは、考えられる解決策に関する質問です。

NAS)を再構築する前に、修正する必要のある非常に緊急の障害があります。

セットアップ:Raidz2に8x 300GBディスクを備えた2xサーバー、1x Windowsサーバー2012r2(Vmhostと呼ばれる)および1x FreeBSD(Nasと呼ばれる)。 nasは、iscsiを使用して2つのlunをvmhostに公開します。

Vmhostは、これらのiscsiディスクに格納されているいくつかのVM(duh)を実行しています。

問題:hyper-vに2年前のスナップショット(またはチェックポイント)がある1 VM)があり(理由は聞かないでください)、その結果、スナップショットファイルは実際のディスクファイル(vhdxディスク)と同じ大きさです。

Nasのスペースが不足しているため、VMが遅くなったり応答しなくなったりします。

私が理解していないことの1つ(おそらく非常に簡単に説明できます)は、300 * 6(+2パリティ)GBを超えるHDDがインストールされていないのに、Windowsがiscsiディスクにほぼ4TBのデータがあると報告していることです。これはZFS側のちょうど良い圧縮ですか?

ウィンドウのサイズのスクリーンショット

提案された解決策:vmのディスクを他のディスクに移動し、vm configのマッピングを修正してから、hyper-vで[チェックポイントの削除]を押し、hyper-vにスナップショットをディスクにマージさせてから、iscsiディスクに戻します。 。

質問は次のとおりです。vhdxディスクが1tbで、スナップショットファイルが1tbの場合、3tbディスクはマージディスクとして十分ですか?そしてそれは実際に1TBのロックを解除しますか? (vhdxのサイズは固定されています)または(明らかに正しいサイズを報告していないため)あまり効果がありませんか?

より大きな質問:サイズは実際にはどの方向にも意味がないので、どの数字を信頼できますか?数字で見ると、1800GBのスペースで合計4TBを超えるデータがあります。 zfsは非常にスマートなので、スナップショット内の一部のデータがディスク上のデータと同じであり、余分なスペースを使用しない可能性がありますか?

zfsリスト

zpoolリスト

hyper-v

Windowsエクスプローラー

1

一般に、ZFSはVMディスクの1.2:1圧縮を簡単に実現できます。また、スマートで、ディスクにゼロブロックを保存しません。データベースの圧縮率が向上します。一般に、圧縮率の高い4Tbの仮想ディスクが1.8Tの物理スペースを持つアレイに収まっても驚かないでしょう。

ZFSでスナップショットを作成すると、CoWスナップショットになります。最初は、ZFSはデータが同じであることを認識し、同じデータをディスクに1回だけ保存します。あるコピーがブロックに書き込まれると、そのブロックはコピーされて別の場所に保存され(つまり、コピーオンライト、CoW)、コピーの1つが変更されます。今後は、コピーを元に戻して同じデータにしたとしても、通常はマージされません。

スナップショットから始めなくても、たまたま同じだったブロックをマージできます。データ領域に重複ブロックがあるかどうかを確認するように指示し、推測すると、それらを1回だけ保存することができます。この機能は重複排除と呼ばれますが、zpoolリストにDEDUP 1.00xがあるため、使用していないようです。また、この機能は大量のメモリを消費することに注意してください。

疑わしいWindows VMを起動して、セクターごとのコピーを作成してバックアップを実行し、そのVM内から仮想ディスクの完全バックアップを実行するディスクバックアップソフトウェアを起動することから始めます(つまり、 Windowsが認識しているものをバックアップします)。または/および仮想ディスクイメージをバックアップします。これにより、少なくとも確実にアクセスできるデータを失わないようにすることができます。次に、説明したとおりに行動します。

また、サイドノート。スクリーンショットに「仮想バックアップ」と呼ばれるものが表示されています。このようなバックアップは行わないでください。同じ論理構造に依存しないでください。スタック内のまれなエラー(ZFSプール上のベースディスク上のNTFS上の仮想ディスク上のNTFS)がディスク上の構造を破壊し、データのフォレンジックリカバリを実行できない場合、保護する必要のあるデータとともにそのバックアップが失われます。そのようなダブルケーキから。多くの場合、バックアップをメインストレージから独立した可能な限り単純な構造に保存するのが最善です。つまり、個別のディスク、高度なボリューム管理のない裸のパーティションテーブル、最も単純なファイルシステムです。いずれにせよ、アクセスとリカバリが簡単です。

1