2009-08-07 7 views
2

私は大規模な大学で働き、私の部署のバックアップ要件の多くは中央ネットワークサービスによって提供されています。しかし、ユーザーの多くは、利用可能な中央記憶域を超える医用イメージングスキャンなどの大きなファイルのコレクションを持っています。ユーザーファイル用のLinuxデータウェアハウスシステム?

私は部署のリソースのための改良されたバックアップソリューションを提供し、スタッフがこれらのコレクションを保管できるLinuxサーバーをセットアップしました。しかし、私は、ほとんどアクセスされていない大量のファイルの集まりによって、サーバー内のストレージが氾濫しているのを見ることができます。私はこれに対処するシステムを持っているが、私は車輪を再発明していないことを確認したい。

マイコンセプト:

  1. ユーザーがサーバーにファイルをコピーします。
  2. スケジュールされたジョブは 別々のストレージメカニズム上のすべてのファイルの完全な 最新のコピーがいつか アクセスされていない
  3. ファイルです(1TB 外付けドライブは、現在このために充て です)キープ サーバーから削除されましたが、 ドライブには余裕があり、ライブ環境には に十分なヘッドルームを確保してください。
  4. シンプルなインターフェース(おそらく ウェブベース)は、ユーザーがライブサーバーにストレージ ドライブからコピーされ、彼らが必要とするものを要求できる からすべてのファイル、 の リストにアクセスすることができます。電子メール のファイルがコピーされた時点で通知が送信されます。

この概念は、私が前のジョブに話を聞いたが、直接使用していませんでしたPACS(画像保管通信システム)に基づいています。それは、ネットワークの他の部分を詰まらせなかった時にローカルマシンへの送信を可能にしながら、膨大な量のデータにアクセスするための「ニアライン」バックアップと同様のプロセスを使用しました。これは、多くの博物館や学術図書館で使用されているものと同様の原則であり、その総「データ所持」は直接アクセスシェルフ上で提示されるものよりもはるかに大きい。

私の要件を満たすシンプルなオープンソースシステムはありますか?異なるパラダイムを使用していますが、依然として私のニーズに合ったシステムがありますか?

答えて

1

S3はここで興味深いアイデアです。 AmazonのS3まで1ヶ月以上アクセスしていないファイルをcronで同期させてから、ユーザーがsync'dファイルをサーバーに復元するためのWebインターフェイスを作成します。ファイルをS3に移動して復元する前に、電子メールを送信します。

無限のストレージ、のみ使用するもののために支払います。既存のオープンソースプロジェクトではありませんが、組み立てるのが難しくありません。

セキュリティが必要な場合は、GPG暗号化でファイルをラップしてからAmazonにプッシュしてください。 GPGは非常に安全です。

もっと費用がかかる方法は、すべてのデータをローカルに保存することです。S3と同様の振る舞いクラスタへ

とSYNC:あなたは大規模なディスク・クラスタまたはビッグNASを購入したくない場合は、HDFSを使用することができます。コモディティハードウェアでHDFSを拡張できます。特に古いマシンと高速ネットワークが既に存在している場合、これは深刻なNASのほうがずっと安く、さらにスケーラブルである可能性があります。

幸運を祈る!私はこれについてもっと答えを見ることを楽しみにしています。

+0

これらのファイルの中には、患者を特定できる情報が含まれているものがあります。そのため、私はクラウドにデータを送り出すのではなく、ローカルサブネット上に何かを設定しようとしています(実際には、長期ストアの暗号化は、特にリムーバブルドライブで考慮する必要があります)。 ありがとうございます。 – basswulf

+0

ああ、私は以前医学で働いていましたが、患者のデータは言及していませんでした。私は上記と同じようにしたいと思いますが、GPG内のすべてのファイルをラップしてからプッシュします。十分な鍵があれば、安全を保つ必要があります。またはHDFS。私は今答えを更新しています。 – mixonic

0

-Please-患者データをS3にアップロードしないでください(少なくとも私のものではない)。

0

Googleのオープンソースファイルライフサイクル管理 "申し訳ありませんが、F/OSSの代替品がない場合、商用SANアプリケーションのみを認識しています。

商用アプリケーションの仕組みはファイルシステムが正常に表示されることです。すべてのファイルが存在します。ただし、ファイルが一定期間(当社にとっては90日間)にアクセスされていない場合、ファイルはセカンダリストレージに移動されます。つまり、最初の4094バイトを除くすべてが移動されます。ファイルがアーカイブされた後、過去のバイト4094をシーク(読み込み)すると、ファイルがセカンダリストレージから引き戻されている間にわずかな遅延があります。私は4094バイト未満のファイルはセカンダリストレージに送信されないと推測していますが、私はそれについて考えたことはありません。

このスキームの唯一の問題は、すべてのファイル(Web検索インデックスなど)をスキャンしようとするものがある場合です。それは二次ストレージからすべてを取り戻し、プライマリをいっぱいにする傾向があり、ITの人々はあなたに毛むくじゃらの眼球を与え始める。 (私はahem、若干の経験から話しています)

ServerFault.comでこれを聞いてみるとよいでしょう。

便利な場合は、cronとシェルスクリプトを使用して同様の方法を考え出すことができます。シンボリックリンクで4094バイトのものを置き換える必要があります(また、以下はテストされていません)。

# This is the server's local storage, available via network 
SOURCE_STORAGE_PATH=/opt/network/mounted/path 

# This is the remote big backup mount 
TARGET_STORAGE_PATH=/mnt/remote/drive 

# This is the number of days to start archiving files 
DAYS_TO_ARCHIVE=90 

# Find old files that are not already symlinks, using temp files 
# NOTE: You might have to account for spaces in file names 
TEMP_FILE=$(mktemp) 
find ${SOURCE_STORAGE_PATH} -atime +${DAYS_TO_ARCHIVE} -a -not -type l > ${TEMP_FILE} 

# This probably needs to change, if too many files in TEMP_FILE... 
# this would be a good point to drop into something like Perl 
for FILE in $(cat ${TEMP_FILE}); do 
    # split source into path and file name 
    BASE_PATH=$(dirname ${FILE}); 
    FILE_NAME=$(basename ${FILE}) 

    # path to target 
    TARGET_PATH=${TARGET_STORAGE_PATH}/${BASE_PATH} 
    # make sure target exists (note -p option to mkdir) 
    [ -d "${TARGET_PATH}" ] || mkdir -p ${TARGET_PATH} 
    # move source to target 
    mv ${FILE} ${TARGET_PATH} 
    # replace source with symlink to target 
    ln -s ${TARGET_PATH}/${FILE_NAME} ${FILE} 
done 
+0

ありがとう - いくつかの興味深いアイデア。私はこの質問を週末に控えて、月曜日にそれに戻ってくるつもりです。 – basswulf

関連する問題