以下を使用して zfs にプールを作成しました:
zpool create data001 mirror /dev/sda /dev/sdb
しかし、振り返ってみると、私は
zpool create data/001 mirror /dev/sda /dev/sdb
私が見つけた名前変更/移動オプションはどれも「データ」が存在しないため機能しませんが、デバイスのないプールを作成しても意味がないように思われるため、「データ」を作成できません。
答え1
最初のものは「zfs create」ではなく「zpool create」を意味していると思います。したがって、次のようにするべきです。
# zpool create data mirror /dev/sda /dev/sdb
# zfs create data/001
最初のコマンドは「データ」プールと /data ファイルシステムを取得し、2 番目のコマンドは /data/001 ファイルシステムを作成します。
答え2
zpool create data mirror /dev/sda /dev/sdb
zfs create data/001これは、データを保持しながら実行すべき、またはまだ実行できるコマンドのセットですか? 最初の行は、既存のプールの上に新しいプールを作成するように見えます。
これは、実行すべきことでした。今これを実行すると、古いプールを破棄するか、ディスクを削除せずに、プールの一部になっているディスクを新しいプールに使用することはできないことがわかります (最後のディスクを除く。ミラーではなく raidz を使用している場合は不可能です)。バックアップ戦略がない場合は、バックアップ戦略について検討するのも良いでしょう。
私はZFSを初めて使いましたが、ZFSとZpoolの機能の分割は恣意的であるように思われます。これはおそらく、技術に対する誤解によるものでしょう。
オラクルは詳細ガイドプールやファイルシステムの使い方、そして凝縮されたベストプラクティス非常に大まかにまとめると、3 つの層があります。
- 特定の冗長機能 (基本、ミラー、または raidz) を使用して、通常のデバイス (通常はディスクですが、ファイルやパーティションの場合もあります) から仮想デバイス (vdev) を構築します。
- 複数の vdev からストレージ プール (zpool) を構築します。これらの vdev は常にストライプ化 (連結) され、それらの vdev の合計サイズが連続ストレージとして提供されます。
- これらのプール内にファイル システムまたは zvol を作成します。ファイル システムは相互にネストできます。理論上はプール自体も書き込み可能ですが、管理やプロパティの継承が容易になるため、これを行わないことをお勧めします。
これらのレイヤーに対する私の個人的な推奨事項:
- 各 vdev に同じサイズ、速度、品質のディスクを使用します。raidz よりも柔軟で高速なミラーを推奨します。1 つの vdev に障害が発生するとプール全体が停止する可能性があるため、基本 vdev は使用しないでください。
- 同様の vdev に対してストレージ プールを作成します。たとえば、VM ストレージ用に SSD vdev (ミラー) を含むプールを 1 つ作成し、低速だが大容量のバックアップ ストレージ用に HDD vdev (raidz2) を含むプールを 1 つ作成します。これらを組み合わせると、プールは HDD と同じくらい遅くなり、すべてのデータ用の単一のミラーと同じくらい危険になるため、お勧めできません。
- 必要な数のファイルシステムを作成し、継承を使用して簡単に管理します (SMB や NFS 共有などのプロパティは、クォータや一般的な ACL 設定と同じ方法で継承できます)。設計は組織と構造によって異なりますが、一般的なルールは「各ユーザーのホーム ディレクトリに 1 つのファイルシステム」と「各独立したネットワーク共有に 1 つのファイルシステム」です。ファイルシステム内のコンテンツが基本的に同じトピックに関するものであるが、移動が頻繁に行われる場合は、ファイルシステムを分割しないでください。ファイルシステム間の移動は、同じプールであっても常に完全でコストのかかる操作です。zvol は、ブロック ストレージをエクスポートする場合、または KVM を使用する場合のみ必要なので、シンプルに開始します (ファイルシステムはブロック ストレージとして使用することもできます)。
- 通常どおりにファイル システム内のディレクトリを使用します (ACL を設定し、データを分離するなど)。