実装されたext4ディスクからのZFSプールの拡張

Question

4つのext42TBドライブ、1つのext4 4TBドライブ、および1つの新しい空の4TBドライブを備えたUbuntuメディアサーバーがあります。 ext4ボリュームは、個別のドライブとして構成されます（RAIDなどではありません）。 2TBドライブは約70％がいっぱいで、4TBドライブは約50％いっぱいです。

それらすべてを共有ZFSプールに変換して、ドライブの障害/ビットロット保護を提供したいと思います。私の質問は次のとおりです：一度に1つのディスクを実行できますか（空をZFSとしてフォーマットし、データをext44TBからZFS4TBに移動してから、空になったext4 4TBドライブをプールに追加してから、 2TBドライブの1つをオーバーして、そのディスクをプールなどに追加します。それは可能ですか？また、これにはどのような構成をお勧めしますか？RAID-Z？

a CVn · Answer

プールの作成後にデバイスをプールに追加できますが、実際には想像したとおりではありません。

ZFSでは、デバイスを追加できる唯一の冗長構成はミラーです。現在、raidzN vdevを作成した後、追加のデバイスで拡張することはできません。ミラーにデバイスを追加すると、冗長性は向上しますが、使用可能なストレージ容量は増加しません。

redundancyデバイスのスパースファイルを使用して目的の構成のraidzNvdevを作成し、vdevにデータを入力する前にスパースファイルを削除することで、これをある程度回避することができます。ドライブを使用できるようになったら、それらを含む（現在は存在しない）スパースファイルをzpool replaceします。このアプローチをより理想的なソリューションへの移行パス以上のものとして使用する場合の問題は、プールが常にDEGRADEDとして表示されることです。つまり、actualを認識するためにさらに詳しく調べる必要があります。 =ストレージの劣化;したがって、永続的な解決策としてはお勧めしません。

ZFSプールにデバイスを単純に追加すると、実際には深刻なリスクが発生します減少プールが機能するためには、すべてのトップレベルのvdevが機能している必要があるため、プールの障害に対する回復力があります。これらのトップレベルのvdevは冗長な構成を持つことができますが、そうする必要はありません。 JBODスタイルの構成でZFSを実行することは完全に可能です。その場合、単一のデバイスに障害が発生すると、プールがダウンする可能性が高くなります。（回避できる場合は悪い考えですが、単一ドライブのセットアップでも多くのZFS機能を提供します。）基本的に、冗長ZFSプールは、1つ以上の冗長vdevのJBODの組み合わせで構成されます。非冗長ZFSプールは、1つ以上のJBODvdevのJBODの組み合わせで構成されます。

トップレベルのvdevを追加しても、ZFSが新しいデバイスにデータのバランスをとることはありません。それ最終的に再書き込みされるデータに対して発生します（ファイルシステムのコピーオンライトの性質とより多くの空き領域を持つvdevを好むため）が、発生しませんそこにあるだけで読み取られるが、決して書き換えられないデータ。データを書き換えることで（たとえば、プールの重複排除がオンになっていないと仮定して、zfs send | zfs recvを使用して）それを実現できますが、特定のアクションを実行する必要があります。

あなたの投稿の数字に基づいて、あなたは持っています：

4×2TBドライブ
2×4TBドライブ
約8 TBのデータ

冗長構成が必要だと言っているので、これらの制約（特に使用可能なドライブのセット）を考えると、ドライブをミラーペアとしてグループ化することをお勧めします。これにより、次のようなプールレイアウトが得られます。

タンク
- ミラー-0
  - 2TBHDD1
  - 2TBHDD2
- ミラー-1
  - 2TBHDD3
  - 2TBHDD4
- ミラー-2
  - 4TBHDD1
  - 4TBHDD2

このセットアップには、ユーザーがアクセスできる約8 TBのストレージ容量があり、メタデータオーバーヘッドを与えるか、または取ります（2つのミラーがそれぞれ2 TB）を提供し、1つのミラーが4TBを提供します。 8 TB）後でミラーペアを追加してプール容量を増やすか、2つのTBドライブのペアを4つのTBドライブに置き換えることができます（ただし、ミラーペアでドライブに障害が発生した場合に再シルバーリングすると、残りのドライブに深刻なストレスがかかることに注意してください。双方向ミラーの場合、ミラーが完全に故障するリスクが大幅に高まります。欠点この構成の利点は、プールが最初から実質的にいっぱいになることです。一般的な提案は、ZFSプールを約75％未満に保つことです。データがほとんど読み取られるだけの場合は、マージンを少なくして逃げることができます。、しかしパフォーマンスは大幅に低下します特に書き込みの場合。データセットが書き込みの多い場合は、ブロックアロケーターが機能するためのマージンが必要です。したがって、これはWordの定義によっては、構成は「機能」しますが、最適ではありません。

Vdevにミラーデバイスを自由に追加できるので、ある程度の計画を立てれば、データが失われないようにこれを行うことができるはずです。

原則として、上記のミラー0とミラー1を、最終的に4台の2 TB HDDで構成される単一のraidz1vdevに置き換えることができます（6 TB 4 TBではなく使用可能なストレージ容量、および2 TBデータが危険にさらされる前のHDD障害）に耐える能力。ただし、これは、これらのドライブのうち3つを最初にZFSにコミットすることを意味します。使用量の数値は次のように聞こえますmightデータをシャッフルすることで可能です。ただし、冗長性レベルの異なるvdevを混在させることはお勧めしません。その場合、ツールによって効果的に発言することもできます。「はい、私は自分が何をしているのかを本当に知っています」。

プール内で異なるサイズのドライブを混在させること（および特に単一のvdev内で、大容量ドライブへの移行パスを除く）は実際には推奨されません。ミラー構成とraidzNvdev構成の両方で、vdev内の最小の構成ドライブがvdev容量を決定します。容量の異なるvdevを混在させることは可能ですが、ストレージのセットアップが不均衡になります。ただし、ほとんどのデータがほとんど読み取られず、読み取りが順次読み取られる場合、後者は大きな問題にはなりません。

最適な構成は、おそらく3台の4 TBドライブを追加して、次のドライブで構成されるプールを作成することです。これらの5つの4 TBドライブで構成される単一のraidz2vdev、および2つのTBドライブ。5つの4 TB raidz2のドライブは、12 TBのストレージ容量（拡張するための十分な余地を残します）を提供し、raidz2は、ミラーを残して、これらのドライブのいずれか2つの障害に耐える機能を提供しますディスクの問題に対する回復力の観点から、ほこりの中でセットアップします。計画とデータシャッフルを行うことで、データを失うことなく、このようなセットアップに簡単に移行できるはずです。5台のドライブraidz2もほぼ最適 1人のユーザーが実行し、4月下旬にZFS On Linuxディスカッションリストに公開されたテストによるストレージオーバーヘッドの割合。1TBデバイスを使用した場合、最適の96.4％で使用可能なストレージ容量を示しています。同じテストで97.3％を与えたvdevあたり6ドライブの構成によってのみ。

5台の4 TBドライブは家庭環境では実用的ではないかもしれませんが、ZFSはエンタープライズファイルシステムであり、その制限の多く（特にこの場合は作成後に冗長vdevを拡張する際の制限）はそれを反映しています。

そして、常に覚えておいてください どのタイプのRAIDもバックアップではありません 。データ損失に対して適度に安全であるためには、両方が必要です。