ファイルシステムに25 TB以上のファイルを効率的に保存するためのヒント

圧縮されていない25 TBのログファイルに直面しており、25 TBの無料ストレージ容量を備えた20個のコモディティボックスの配列を自由に使用できるとします。

これらをどのように保存しますか？

a）使用する分散ファイルシステム

b）どの圧縮/解凍形式/アルゴリズム？

c）ログファイルのサイズは1MBから最大7MBで、すべてのテキストと多くの空白

d）使用方法はa）人々は以前よりも最新のログファイルが欲しいので、どのキャッシングシステムを使用するかb）人々はそれらを削除せずにログファイルのみを読み取るc）日付範囲に対してログファイルのリストを表示したい

e）コモディティボックスで実行されているオペレーティングシステムはLinuxです。

f）バックアップに関しては、それを処理するストレージアレイがあります。したがって、アレイからデータを復元する機能が存在します。

ファイルシステムに直接アクセスしてほしくありません。私は何をすべきか ？このためにRESTベースのAPIを取得するにはどうすればよいですか？

2セントをcentしまないでください。

アンクル

私は分散ファイルシステムの忍者ではありませんが、できるだけ多くのドライブをできるだけ少ないマシンに統合した後、iSCSIを使用してマシンの大部分を1つのメインマシンに接続しようとします。そこで、できればフォールトトレラントストレージに統合することができました。マシン内（ドライブが停止した場合）およびマシン間（マシン全体が電源オフの場合）のフォールトトレラントが望ましい。

個人的に私はZFSが好きです。この場合、組み込みの圧縮、重複排除、フォールトトレランスが役立ちます。ただし、データをフォールトトレラントにしながら圧縮する方法は他にもたくさんあるはずです。

推奨する実際のターンキー分散ファイルソリューションがあればよかったのですが、これは本当に手間のかかるものであることがわかっていますが、正しい方向を示してくれることを願っています。

編集： 私はまだZFSとiSCSIを設定するのは初めてですが、ドイツのサンがZFSの耐障害性を示しているビデオを見たことを思い出しました。3つのUSBハブをコンピューターに接続し、各ハブに4つのフラッシュドライブを配置しました。次に、1つのハブがストレージプールをダウンさせないように、各ハブの1つのフラッシュドライブで構成されるRAIDzボリュームを作成しました。次に、4つのZFS RAIDzボリュームを一緒にストライプします。この方法では、パリティ用に4つのフラッシュドライブのみが使用されました。次に、1つのハブを取り外し、すべてのzpoolを劣化させましたが、すべてのデータが利用可能でした。この構成では、最大4台のドライブが失われる可能性がありますが、2台のドライブが同じプールにない場合のみです。

この構成が各ボックスのrawドライブで使用された場合、パリティ用ではなくデータ用により多くのドライブが保持されます。 FreeNASは、iSCSIを介して「生の」方法でドライブを共有できる（またはできるようになる）と聞いたので、Linuxでも同じことができると思います。私が言ったように、私はまだ学んでいますが、この代替方法は、以前の提案よりもドライブパリティの観点から無駄が少ないでしょう。もちろん、それが受け入れられるかどうかはわかりませんが、ZFSの使用に依存します。学習経験でない限り、何かを構築/保守/修復する必要がある場合は、通常、あなたが知っていることに固執するのが最善であることを知っています。

これが良いことを願っています。

編集：掘り下げて、私が話したビデオを見つけました。USBフラッシュドライブをハブに分散させることを説明する部分は、2分10秒から始まります。このビデオでは、ストレージサーバー「Thumper」（X4500）のデモと、コントローラーにディスクを分散する方法を説明します。そのため、ハードディスクコントローラーに障害が発生してもデータは良好です。（個人的には、これはオタクが楽しんでいるだけのビデオだと思います。私は自分でサンパーボックスを持っていたらいいのに、妻は家にパレットジャックを走らせたくありません。：Dそれは大きな箱です。）

編集：OpenAFSと呼ばれる分散ファイルシステムに出くわしたことを思い出しました。私はそれを試していませんでした、私はそれについて読んだだけでした。おそらく他の人は、それが現実の世界でどのように処理するか知っています。

まず、ログファイルを非常に高い比率で圧縮できます。ログファイルは10：1の比率で圧縮されています。5：1の比率に圧縮しても、それはたったの5GB、つまりストレージ容量の20％です。

十分なストレージがある場合、特定の圧縮アルゴリズムはそれほど重要ではありません。あなたは出来る...

• Windowsユーザーがファイルに直接アクセスする場合は、zipファイルを使用します。
• Linux経由でアクセスする場合はgzipを使用し、迅速な解凍が重要です。
• Linux経由でアクセスする場合は、bzip2を使用します。可能な限り小さいファイルを用意することが重要です。

より大きな問題は、これらのファイルへの簡単なアクセスをユーザーにどのように提供するのかということです。これの一部は、マシンの構成方法によって異なります。

1台のマシンに十分なストレージを配置できる場合、読み取り専用のWindowsファイル共有など、非常に簡単な操作を実行できます。ファイルをサブディレクトリに整理するだけで、準備は完了です。

これらのファイルに対して単一のファイルサーバーを作成できない場合は、分散ファイルシステムが必要になることがあります。Windowsには、ニーズに合った分散ファイルシステム（DFS）があります。

ニーズがより高度な場合は、ユーザーがログファイルを参照およびダウンロードできるフロントエンドとしてWebアプリケーションが必要になる場合があります。この場合、フロントエンドアプリケーションサーバーで使用するように設計された分散ファイルシステムであるMogileFSを使用することをお勧めします。ほとんどのWebプログラミング言語との統合は非常に簡単です。コンピューターの共有ドライブとしてマウントすることはできませんが、Webアプリケーションのデータストアとしては最高です。

lessfsは、重複排除、圧縮ファイルシステムです。問題全体を解決するわけではありませんが、バックエンドとして見る価値があるかもしれません。

NFS経由でこれらのフォルダーをエクスポートします

apacheが（ドキュメントルートの下で）ツリーとして実行されている単一のマシンにマウントします。

zipを使用して圧縮する-圧縮率は良好で、すべてのOSからzipを開くことができます

Apacheでファイルを一覧表示します-したがって、ユーザーに読み取り専用アクセス権を付与します（ログファイルは編集対象ではありません、正しい）

ログファイルの圧縮について考えたことはありますか？次に、エンドユーザーにサービスを提供する前に、フロントエンドで何かを解凍して解凍します。たぶん、ある種のCGIスクリプトです。

@Ankurと@Porch。これらのログを圧縮する必要性に強く同意します。

@jetシンプルなスキームの方が良いと思います-したがって、エンドユーザーのhttpdは理想に近いものです。そして、バックエンドはどれでもかまいません。

私の意見-ログを2つのグループに分けます-「古い」フォルダーと「新しい」フォルダー。

それらをhttpdのドキュメントルートにマージします。大きな辞書やブロックサイズを持つ古いアーカイブ（すべてのOSで人気のあるxzまたは7zアーカイブ）に強力な圧縮を使用すると、強固なアーカイブになります。

新しいものに圧縮fsを使用：lessfs（rw、deduplication + light compression methods）、fusecompress 0.9.x（rw、light to strong compression methods）、btrfs / zfs、squashfs（ro、light to strong compression methods、some dedup、use新しくローテーションされたログの場合）。

圧縮されたfs（fusecompress、lessfs、btrfs / zfs）にログを透過的に書き込むこともできます。書き込まれるログへのhttpdによるR / oアクセスを提供します。ユーザーに対して透過的で、透過的に解凍されます。

fusecompressに関する警告：1）0.9.xのみを使用してください-安定しています。ここからクローンhttps://github.com/hexxellor/fusecompress

それ以降のバージョンは、lzmaを十分にサポートしていないか、データを失います。

2）1つのファイルの圧縮に1 CPUコアのみを使用するため、時間がかかる場合があります。

一定期間（数か月）より古い「新しい」フォルダーで各ログを再圧縮し、「古い」に移動します。