大きなファイルサーバー用のLinuxファイルシステム
20TB以上のハードディスクを搭載したファイルサーバーに使用するファイルシステムの最良の選択は、経験豊富な人々から知りたいと思います。個人的には、パーソナルコンピュータと「小さなサーバー」のBOOTディスクとROOTディスクで常にEXT3（昔は）とEXT4（利用可能だったので）[そしてかつてはReiserFS 3を使用していましたが、多くのデータ破損を引き起こしました]。
ただし、EXT4 tools（EXT4自体ではありませんが）は16TBパーティションに制限されているため、これは最善の策ではない可能性があります。配布はDebian6.0（Squeeze）および/またはGentoo（最新バージョン）になるため、カーネルはかなり最近のものである必要があります（Debianでは少なくともバックポートがあります）。つまり、Linuxカーネルは2.6.32以上です。
ファイルサーバーは、メールの3つの目的で使用されます（目的はデータを「安全」に保つことであり、オーバーヘッドをあまり気にしないため、パーティションも分離されます）。 すべてのディスクはLUKSを使用して暗号化されます：
- メディア、ダウンロード、ローカルdebianリポジトリ[Debianを実行しているマシンが少なくとも6台あります]> 20TB（メディア、ダウンロード、Debianリポジトリをさらに分離している可能性があります）
- データ（ドキュメント、写真、...）〜4TB SAFE（raid1またはraid6 +バックアップディスクを意味します）
- バックアップ> = 20 TBギガビットLAN内の他のコンピューターのバックアップ用（ウィンドウであってもOS全体をバックアップするソフトウェアを提案できますか？BackupPCはそれを行うと言っています、他の方法はありますか？）
10 HDD Raid6からの読み取りが「ちょうど」200MB /秒であっても、高速は実際には必要ありません（同時アクセス：最大2つまたは3つの大きなファイル（ビデオなど））。
要約すると、20TB /パーティション以上をサポートする信頼性が高くスケーラブルな（つまり、簡単に拡張できる）ファイルシステムを探しています。 FSの安全性と信頼性が高いほど、優れています。使用するハードウェアは、少なくともクアッドコア（AMD x4630またはInteli5-2500k）と十分なRAM（> 8GB、おそらく> 16GB）であるため、ハードウェア要件を満たす必要があります。
停電の場合、私のPC /サーバーはUPS（無停電電源装置）に接続されますメディアとバックアップを別々のマシン（つまり、2台のサーバー）でも実行する可能性があります。
多くの人がZFSを提案しています。ただし、ZFSは、Fuseを介する場合を除いて、Linuxではネイティブに使用できません。パフォーマンスが重要になる可能性が高い状況では、これはお勧めしません。
残念ながら、ライセンスの問題がなんらかの方法で解決されない限り、ZFSをネイティブカーネルモジュールとして使用することはできません。
XFSは優れていますが、破損の問題を報告している人もいます。私はそれについてコメントできません。私は小さなXFSパーティションで遊んだことがあり、これらの問題は発生していませんが、本番環境では発生していません。
ZFSには、無視できない多くの利点と便利な機能があります。要約すると、それらは次のとおりです（意味の詳細については、 ZFS Wiki を参照してください）。
- データの整合性
- ストレージプール
- L2ARC
- 大容量
- コピーオンライト
- スナップショットとクローン
- ダイナミックストライピング
- 可変ブロックサイズ
- 軽量ファイルシステムの作成
- キャッシュ管理
- アダプティブエンディアン
- 重複排除
- 暗号化
では、どうすればそれを回避できますか？あなたの状況に合うかもしれない私の提案された代替案は、 nexenta を検討することです。これは、GNUユーザーランドツールが実行されているOpenSolarisカーネルです。OpenSolarisカーネルがあるということは、ZFSをネイティブに利用できるということです。
XFSを試して、要件にうまく適合させる必要があります。
XFSは64ビットのファイルシステムです。これは、8エクスビバイトから1バイトを引いた最大ファイルシステムサイズをサポートしますが、これはホストオペレーティングシステムによって課されるブロック制限の対象となります。 32ビットLinuxシステムでは、これによりファイルとファイルシステムのサイズが16テビバイトに制限されます。
最も簡単なオプションは、XFSを使用することです。 XFSに関する多くの悪い経験は、古いバージョンとデスクトップハードウェアの問題に基づいており、標準品質のサーバーハードウェアへの新しい展開にはあまり関係がないと思います。私はあなたが現在の状況を整理するのを助けるかもしれないこの主題について ブログ投稿 を書きました。数百人のユーザーとテラバイトのデータを管理するのに役立つ、ビジーなXFSデータベースのインストールが複数あります。それらはすべてDebianLennyカーネル（2.6.26）以降にあり、私は何年もの間それらの問題のヒントを聞いていません。それより前のカーネルではXFSを使用しません。システムのメモリまたはディスク容量が不足しているときに、XFSの奇妙な動作がまだ見られるという直接的な報告をいくつか聞いています。私はまだそれを見ていません。
他の唯一の合理的なオプションは、ext4を 一部のハッキング とともに使用して、より大きなファイルシステムをサポートすることです。信頼性レベルが大きく異なるとは思いません。カーネルのバグに遭遇した複数の壊れたext4システムからデータを回復する必要がありました。これまでのところ、すべてがアップストリームで修正されていますが、その時点ではディストリビューターのカーネルでは修正されていません。 ext4には、 遅延割り当てデータの損失 のような独自のメタデータの問題のセットがあります。これは、ext3では発生する可能性が低いことです。 ext4のバグにぶつかる確率は、通常のサイズ制限を超えて強制すると、通常よりもさらに高くなると推測されます。これは、ある時点で、十分にテストされていない新しいコードパスにぶつかる可能性が高いためです。 。
別のアイデアは、より安全で退屈なext3を使用し、16 TBの制限を受け入れ、物事をより適切に分割することです。これにより、単一のファイルシステムをそれほど大きくする必要がなくなります。
ジャーナルの問題に関連する1つのルーズエンド。これらすべてのドライブがどのように接続されるかについては話しませんでした。ここで、ストレージチェーンにある書き込みキャッシュの意味を理解してください。無効にするか、ファイルシステムがキャッシュをフラッシュしていることを確認してください。それについてのいくつかのリソースを Reliable Writes に隠しておきましたが、それがまだチェックしているものではない場合。
ドライブは吸う。 RAIDアレイは最悪です。ファイルシステムは最悪です。複数の障害が発生します。あなたがすでにバックアップについて考えているのを見てうれしいです。ストレージの信頼性を良好から優れたものにするには、RAIDといくつかのスペアドライブ以上のものが必要です。冗長性にはあらゆるレベルでいくらかのコストがかかり、ハードウェアとソフトウェアの複雑さのコストはナビゲートするのが難しいものです。そして、パフォーマンスの期待に注意してください。あなたが検討しているようなRAIDアレイは、数百MB/sを簡単に実行できますが、必要なのは、2つの同時リーダーがディスクを常に探し回って、代わりに数MB/sに落とすだけです。 ベンチマークワークロード に対して<5MB/sしか提供しないように、24ディスクRAID10アレイを簡単にクラッシュさせることができます。複数のストリーミングリーダーが可能な場合は、先読みを上向きに調整することをお勧めします。
FreeBSDを使用したZFSへのデプロイは、暗号化に gbde を使用してここで行うことができます。 ZFS自体は、 [〜＃〜] raidz [〜＃〜] を介してソフトウェアRAIDプロバイダーになります。 zpoolを構築する際のストレージ管理の複雑さは、Linuxがmdadmを使用して実行するものとそれほど変わらず、場合によっては実際には簡単になります。私の最初のZFSインストール（約3年前のSolaris 10）には、48台のドライブに17TBのファイルシステムがありました。私はそこで何度も失敗を問題なく乗り越え、ZFS管理を学びました。
主な利点は、 ZFSのチェックサム がLinuxよりも優れたエラー検出を提供することです。これは、検討する価値のある不良ハードウェアに対する防御です。主な欠点は、FreeBSDの人気が低いことです。管理方法はまだわかりません。ハードウェアのサポートはLinuxよりも少し弱く、人気の低いプラットフォームであるため、問題が発生した場合に助けを求める人はそれほど多くありません。
多くのテラバイトのストレージアレイは、ZFSが得意なことを実際に強調しています。あなたが何か新しいことに突入する気があるなら、真剣に検討する価値があります。真のバックアップパラノイアを調査したい場合は、LinuxおよびFreeBSDバックアップサーバーを構築して、単一障害点としてのOSバグの可能性を減らします。