web-dev-qa-db-ja.com

ホームサーバーに推奨されるストレージスキームは? (LVM / JBOD / RAID 5 ...)

複数ディスクのホームサーバーに最も適したストレージスキームのガイドラインはありますか?

個別のブート/ OSディスク(したがって、ブート可能性は問題ではありません。これはデータストレージのみ)と、1-2 TBの4-6ストレージディスクを想定しています。範囲4〜12 TB。

ファイルシステムはext4です。すべてのディスクにまたがる大きなパーティションは1つだけになると予想しています。

私が知る限り、選択肢は

個々のディスク

  • pros:ディスクサイズの任意の組み合わせで動作します。ディスクを失うと、そのディスク上のデータのみが失われます。ボリューム管理の必要はありません。
  • cons:論理ユニット(「ムービー」フォルダなど)が単一のドライブの容量よりも大きい場合、データ管理が面倒です。

JBODスパン

  • pros:任意のサイズのディスクをマージできます。
  • cons:ディスクを失うと、すべてのディスク上のすべてのデータが失われます

LVM

  • pros:任意のサイズのディスクをマージできます。ディスクの追加と削除は比較的簡単です。
  • cons:ディスクを失うと、すべてのディスク上のすべてのデータが失われます

RAID

  • 長所:速度
  • cons:1つのドライブを失うと、すべてのデータが失われます。ディスクは同じサイズでなければなりません

RAID 5

  • pros:データは1つのディスクを失っても存続します
  • cons:1ディスク分の容量を放棄します。ディスクは同じサイズでなければなりません

RAID 6

  • pros:データは2つのディスクを失っても存続します
  • cons:2つのディスクに相当する容量を放棄します。ディスクは同じサイズでなければなりません

システムをアップグレードするときに古い、容量の小さいディスクを再利用できるという理由だけで、主にLVMまたはJBODスパンのいずれかを検討しています。次点は、速度の点でRAID 0です。

別のシステムへのフルバックアップを計画しているので、RAIDレベル5または6からの余分な冗長性は重要ではないと予想しています。

これは選択肢の公平な表現ですか?私が見逃した他の考慮事項や選択肢はありますか?そして、あなたは何をお勧めしますか?

6
j-g-faustus

あなたのように、ホームサーバーのディスクを使用して合理化プロセスを行っています。私も、私が持っているJBODセットアップの有機的な成長の結果として、さまざまなサイズのディスクを使用しています。

私は次の理由でLVMルートを取っています。

  1. その最も簡単な
  2. サーバーに既にあるディスクを再利用できます
  3. 復元できると確信しているすべてのデータの完全なバックアップがあります
  4. ディスク障害が発生した場合の回復時間について心配していません

私にとっての決定要因は、#3と#4です。

6
user8216

Greyhole を使用していますが、これは私の使用例にほぼ完全に適合しています。

  • ホームサーバー
  • さまざまなブランド、モデル、サイズのスペアhddの再利用
  • すべてのhddsスペースは、1つの大きなマウントポイントとして見ることができます(jbodなど)
  • 冗長性のニーズに応じて異なる共有を設定できます(つまり、Photos = max redundancy、Data = simple redundancy、Movies = zero redundancy)
  • hddsのアップグレードは一度に1つ実行できます(つまり、500GBのhddを取り外して、合計容量を拡張する4TBのhddに置き換えることができます)
  • 1つのhddが失われても、そのhddに存在する冗長性がゼロのデータのみが失われます。
  • hddが(スマートパラメータモニタリングから)失敗しようとしている早期警告を送信した場合、データを失うことなく別の警告に簡単に置き換えることができます。
  • hddは何もせずにSATAからUSBエンクロージャに移動できます
  • 実際、sata hdd、usb hdd、リモートネットワーク共有など、ストレージは何でもかまいません。
  • (非常に重要)グレイホールシステムからhddを削除する場合、それは通常フォーマットされたext4ディスクで、フォルダー内のデータはどのマシンからでも簡単に読み取り可能です

制限事項:

  • Greyholeは、一度書き込まれ、何度も読み取られるファイルに最適です。 Greyholeボリューム内の所定の場所にあるファイルを変更することはお勧めしません。ファイルを別の場所に移動し、そこで変更してからGreyholeボリュームに再度配置することをお勧めします。
  • Greyholeデータには、Samba共有から(ローカルでも)アクセスする必要があります。
5
Lorenzo

rAIDシステムでは、ディスクは同じサイズである必要はありません...

partitions RAIDに追加したい場合、RAIDを作成するには同じサイズが必要です...

lvmの強みは、パーティションを追加することで仮想ディスクを簡単に拡張できることです。スナップショット機能があります!

lvmとraidを組み合わせることができるため、データセキュリティとlvmの柔軟性が得られます。

3
JMW

スタック Linuxでデバイスをブロックし、すべてのニーズに対応するソフトウェアRAIDとLVMの両方の価値をミックスできます。これはすべて非GUIインストーラーから実行できます。

  • ディスクの99%にまたがる単一のパーティションを使用します[1]
  • 少なくとも1つのホットスペアでMD RAID5(できればRAID6)を作成する
  • MDアレイを初期化する
  • LVM VGを作成する
  • 各MDデバイスを物理ボリュームとして新しいVGに追加します[2]
  • スワップおよびルート論理ボリュームのVGへの追加に進みます
  • ファイルシステムを選択してルートをフォーマット(デフォルトはext4)
  • インストールを続ける

[1]不良ブロックの多いSATAディスクで非常に厄介な障害に遭遇しました。ベンダーツールを使用してディスクを再構成した後。かつて同一のディスクセットはユニークでしたが、不良ドライブは低レベルフォーマットが開始される前よりも数ブロック少なくなりました。これにより、もちろんパーティションテーブルが破壊され、ドライブがMD RAIDセットに再参加できなくなりました。

通常、ハードドライブには、一回だけ使用されるバックアップブロックの「空きリスト」があります。私の理論では、そのリストは使い果たされているはずであり、これはエンタープライズディスクではなかったため、安全に失敗し、データリカバリのためにリストを送信する機会を与えるのではなく、データを切り捨てることに決めました。

[2]フォールトトレラントバッキングストアなしでLVMを展開しないでください。 LVMは災害復旧時にエクセルしません。あなたはただ心痛を求めているだけであり、もし間違えたらデータの損失をもたらします。意味があるのは、VGグループが外部usbディスクまたは外部eSATA RAIDなどの単一のディスクに限定されている場合のみです。ポイントは、単一のユニットとして、または上記のMDの例で示されている仮想の単一ユニットとしてホットプラグ可能なバッキングストアの周りにVGを展開することです。

2
ppetraki

http://zfsonlinux.org/ について

これには、デタッチドライブを接続できるディスクプールの概念があります。本番の準備はできているが、まだチェックする価値があるかどうかはわかりません。

1
narkisr

MHDDFSについては、ほとんどのディストリビューションで既に利用可能であり、JBODのように動作しますが、ドライブが死んだ場合、すべてではなく、そのドライブのデータを失うだけです。これは1つの論理ドライブプールとして認識されるため、たとえば、トラックをアップグレードするときに、論理ドライブプールを別の大容量ディスクにコピーできます。最小限のダウンタイムと最小限の手間で、簡単に実装できます。ここでの使用方法を確認してください: http://zornsoftware.codenature.info/blog/why-i-ditched-raid-and-greyhole-for-mhddfs.html

0
Treefrog