単一の仮想ディスク上のZFS
- 企業は、非常に厳しい予算で大規模なファイルサーバー（17 TBなど）とそれに関連するバックアップをどのように管理していますか？
- Fsckの必要性を排除するために、コピーオンライトの性質のために単一の仮想ディスクでZFS（またはBTRFS）を使用しても大丈夫ですか？ （つまり、RAID、スナップショットなどの機能ではありません）
特定の状況：
仮想用のNFSストレージを提供していて、現在もメインファイルサーバーである、問題のある古いストレージシステムを廃止する必要があります。私は今、新しい40TB iSCSI FreeNASベースのストレージシステムを持っており、古いストレージから新しいストレージまですべての仮想をすでにvMotionしましたが、17 TB of SMB/CIFS＆AFP共有ファイルが残っています。
バックアップは17TBのスキャンに時間がかかるrsyncを介して行われるため、2つのボリュームに分割しました。
- 13 TB 1年間変更されていないファイルの読み取り専用の「アーカイブ」ボリューム上。バックアップするには、rsyncを使用してオンサイトとオフサイトのコピーを作成するだけです。毎日のバックアップバージョンは必要ありません。 。
- 4 TBライブ書き込み可能ストレージ。これはrsyncで毎日バックアップされ、ハードリンクを使用してその特定の日のファイルサーバーの状態の「スナップショット」/バージョンを作成します。上書きされたファイルを回復します。
ITスタッフは、変更が必要な場合にファイルをアーカイブからライブに移動しますが、これらの要求は1日に複数回行われるようになり、受け入れられなくなりました。
当初の計画：
- 仮想Linuxファイルサーバーを作成します。
- 新しい40TBストレージシステムに2x仮想ディスクを作成します。 （13 TBアーカイブ+4 TB書き込み可能なライブ）
- Ext4ファイルシステムで上記のディスクをフォーマットする
- UnionFSとcowmountオプションを使用して、上記のファイルシステムの単一の統合ビューをユーザーに提示し、すべての書き込みを4TBの書き込み可能なシステムに送信します。
元の計画の問題：
- バックアップツールとしてのrsyncのファイルベースの性質を超えています。 1TBの最上位フォルダーの名前を変更すると、1TBフォルダー全体の完全に新しいコピーになります。これにより、ブロックベースのバックアップに数KBしか追加されません。
- UnionFSを実装すると、システム全体にさらに複雑なレイヤーが追加されるだけですが、これは避けたいと思います。
- Rsyncは、変更されたファイルを比較するためにファイルサーバー全体を再スキャンする必要があるため、変更されたファイルが少ない場合でも、バックアップを完了するのに非常に長い時間がかかります。
- バックアップが一晩で完了するのに十分なだけ書き込み可能なボリュームを小さく保つために、継続的なアーカイブを行う必要があります。
代替プラン1：バックアップ用の1つの大容量およびZFSスナップショット
- 上記の計画されたLinuxファイルサーバーを作成しますが、2つではなく1つの大きなボリュームを使用して、UnionFSの必要性を排除します。
- Rsyncで時間がかかりすぎるこの非常に大きなサーバーをバックアップするには、代わりにZFSスナップショットを使用し、「zfssend」を使用してオフサイトに複製します。
代替計画の問題1：
- 17 TB ext4ファイルシステムのfsckは数日かかります！再起動と起動時の強制fsck、またはさらに悪いことに、ファイルシステムの破損を必要とする月曜日の朝の事件を想像してみてください！
代替プラン2：Linuxサーバー上のZFS/BTRFSファイルシステム
- 代替プラン1と同様ですが、ext4の代わりにZFSやBTRFSなどのコピーオンライトファイルシステムを使用します。これらはfsckを必要としないためです。
代替プラン2に関する質問/懸念事項：
- ZFSとBTRFSはどちらも、独自のRAIDを実装するためにrawディスクに直接アクセスする必要があるため、通常は仮想ディスクでは使用されません。これは単一の仮想ディスクでどの程度うまく機能しますか？
代替プラン3：ファイルサーバーとして直接FreeNAS
- 別個の仮想ファイルサーバーを持つ代わりに、FreeNASから直接ファイルを共有します
代替計画3の問題：
- このファイルサーバーをジョブ追跡システムと統合するには、さまざまなパッケージとカスタムPerl/bash/pythonスクリプトをインストールする必要があります。これはストレートLinuxでは問題ありませんが、事前にパッケージ化されたFreeBSDベースのZFSストレージシステム（FreeNAS）では良い考えではないと思います。更新により、変更などが上書きされる場合があります。
質問：
- 代替プラン2-単一の仮想ディスク上のZFS-は良い考えですか？そうでない場合、なぜですか？
- 誰かがより良いオプションを提案できますか？
企業は、非常に厳しい予算で大規模なファイルサーバー（17 TBなど）とそれに関連するバックアップをどのように管理していますか？
これは、パフォーマンスと予算の制約によって異なります。たとえば、Backblaze（クラウドバックアップ会社）はTBごとに非常に厳しい予算を持っていますが、データに対して最高のパフォーマンスや応答時間を必要としません。他の会社は安価なパフォーマンスを必要としているかもしれませんが、必要なデータを減らす方法を見つけています（重複排除、古いバックアップデータの整理、またはビジネスに必要のない実際のデータを単に減らすことによって）。
Fsckの必要性を排除するために、コピーオンライトの性質のために単一の仮想ディスクでZFS（またはBTRFS）を使用しても大丈夫ですか？ （つまり、RAID、スナップショットなどの機能ではありません）
データの安全性を第一原理として信頼する必要がある非開発では、BTRFSを使用しません。 ZFSを使用するのは、より安価で安全な代替手段が見つからなかったためです（IBM、NetAppなどの同様の機能を備えた他のFSはより高価であり、他の無料ファイルシステムは十分に成熟していません（ HAMMER2、BTRFS）または重要な機能（ext2/3/4、reiserfsなど）が不足しています。
あなたの具体的な答え：私はプラン3を好みますが、プラン2も機能します。
Web上に浮かぶ多くのFUDとは異なり、ZFSは、物理、仮想、混合のいずれであっても、基盤となるストレージを気にしません。もちろん、それは基礎となるストレージと同じくらい良い/速い/安全であることができるだけであり、与えられたものについてのみ推論することができます。つまり、パフォーマンスはネイティブほど良くなく、トラブルシューティングには両方のレイヤーが含まれ、両方のレイヤーで問題が発生する可能性があります。あなたがこれを知っていて、これらの欠点に備えているなら、私はそれを実行可能な代替案と見ています。
Send/recv、スナップショット、CoW、チェックサム、ブロックレベルの重複排除などの快適な機能がまだあります。犠牲にするのは主にパフォーマンスとおそらく安全性です（たとえば、SANが1つのディスクだけの場合）。また、ZFSセクターサイズ（ashift）をプールを作成するときの基盤となるストレージ。後で個々のファイルシステムに異なるサイズを設定できますが、プールの設定は破棄せずに元に戻すことはできません。
しかし、私は最初に、それらのスクリプトと統合の書き直しがあなたが想像するほど時間がかかるかどうかを徹底的に評価します。また、FreeNAS（または代替の名前を付けるためにnapp-it）のようなアプライアンスでさえ、通常、ユーザースクリプトまたはユーザー定義可能なプラグインまたはモジュールを備えており、更新後も存続し、アプライアンスでうまく機能します（新しいFreeNAS 10別名Corralがプラグインに取って代わりました） Dockerを使用したアーキテクチャ、それがあなたが精通しているものであれば、それは代替手段かもしれません）。