web-dev-qa-db-ja.com

RAID、LVM、LUKSの最適な順序

Debian GNU/Linux 8でファイルサーバーをインストールします。

Mdadmを使用したソフトウェアRAID-1とLUKSを使用した暗号化されたディスクが必要です。 LVMの柔軟性も気に入っています。

これにはさまざまな方法があります。 1つの方法は次のとおりです。最初にmdadmを使用してRAID-1をセットアップします。次に、作成された/ dev/mdXをカバーするようにLVM PVをセットアップします。次に、LVをセットアップし、LUKSを使用してそれらを暗号化します。次に、これらをファイルシステム、たとえばext4でフォーマットします。これにより、次のようなレイアウトになります。

RAID --> LVM --> LUKS --> ext4

または、別の順序でそれを行うこともできます：

RAID --> LUKS --> LVM --> ext4

または多分：

LVM --> RAID --> LUKS --> ext4

そしておそらく、まったく別の順序でさえも。

異なるアプローチの利点と欠点は何ですか？何が最高のパフォーマンス、セキュリティ、保守性などをもたらしますか？

これを行う「最善の方法」はありますか？

linuxdebianraidlvmluks
13
Thomas

まず、LUKSとLVMの順序は、異なるLVに対して異なるLUKSパスワードまたは他の設定を使用するかどうかによって異なります。たとえば、LVごとに異なるパスワードを設定する必要がある場合は、LVMの上にLUKSを配置する必要があります。一方、すべてのLVが同じパスワードとkeylenのような設定を共有している場合は、LVMの下にLUKSを配置することで、複数のLUKSパーティションを持つオーバーヘッドに対処する必要がなくなります（たとえば、パスワードを変更する必要があるときに行う必要があります）。

第2に、ほとんどの場合、RAIDを最低レベルにする必要があるため、1つのディスクが停止したときに簡単かつ透過的に交換できます。 LVMの上にRAIDをセットアップする場合、1つのディスクが停止したときにPVを交換する必要があります。これは大きな負担になります。また、LVM上のRAIDは、LVMの柔軟性を完全に無効にします。次に、おそらくRAIDの上にLVMの第2レイヤーを再度セットアップする必要があります！

したがって、ほとんどの場合、ユーザーは単一のパスワードを使用する必要があるだけなので、これで十分です。

RAID-> LUKS-> LVM-> ext4

場合によっては、LVMを使用して複数のRAIDデバイスを大きなボリュームに結合する必要があるかもしれません。それから、次のことができます。

RAID-> LVM-> LUKS（-> LVM）-> ext4

理論的には、順序がパフォーマンスに大きな影響を与えることはありませんすべてのレイヤーが正しく設定されている場合、実際には、この設定が特に悪いことはありません。パフォーマンス。最も重要なことはおそらく調整です：

  1. パーティションが1MBに揃えられていることを確認してください（SSDにとって非常に重要です）。
  2. rAIDレイヤーの場合、 チャンクサイズ を慎重に選択します。
  3. lVMの場合は、RAIDチャンクサイズと一致するように--dataalignmentを設定してください（ this が役立つ場合があります）。

また、SSDの場合は、rd.luks.options=discardに/etc/default/grubを追加し、/etc/crypttabにdiscardを追加して、LUKS TRIM/DISCARDパススルーが有効になっていることを確認してください（これらはRedで行うものです） Hat/FedoraLinux。Debianでは少し異なる場合があります。）LVMとRAIDは、新しいカーネルを使用する場合、破棄を自動的にサポートするはずです。

もちろん、これらは単なる一般的なガイドラインです。特別なニーズがある場合は、ここで質問やコメントを更新してください。

18
Yan Li

すべてのRAID、LUKS、LVMが必要な場合は、RAID -> LUKS -> LVM -> FSをお勧めします。 RAID --> LVM --> LUKS --> LVM --> FSはRAID -> LUKS -> LVMよりも優れていません。ボリュームを拡張するには、ボリュームグループにRAID -> LUKSデバイスを追加するだけです。

RAID --> LVM --> LUKS --> FS-特定の論理ボリュームのみを暗号化すると、デフォルトではすべてが暗号化されないという機能があります（利点または欠点と見なされる場合があります）が、ルートFS=の拡張が容易になります。

論理ボリュームの上にLUKSを拡張することは、ユーザーが間違った順序でLUKSを拡張/サイズ変更する場合の問題の一般的な原因です。 md RAIDデバイス全体にLUKSがあると、サイズ変更が簡単になります-新しいmdデバイスを追加し、その上にLUKSを作成し、デバイスを/ etc/crypttabに追加します（少なくともFedoraおよびRHELクローンでは）、ボリュームグループを拡張します。ルートFSがボリュームグループ上にある場合、カーネルコマンドラインに別のrd.luks.uuidエントリを追加する必要があります（編集/ etc/default/grub そしてgrub.cfgを再生成します。

LUKS -> RAIDは通常間違っています-データは複数回暗号化され、ゲインなしでより多くのCPUサイクルを消費します。また、ディスクに障害が発生したときに、LUKSを設定せずに、障害のあるディスクを誤って新しいディスクと交換する可能性もあります。

拡張と縮小：

伸ばすときは常にスタックの一番下から、一番上から縮むとき。

例：

拡張RAID -> LVM -> LUKS -> FS（ボリュームグループに十分な空き容量がある場合、最初の2つのステップはオプションです）：

  1. 新しいディスクを追加し、md RAIDを作成します。
  2. MdXデバイスをボリュームグループに追加します。
  3. 論理ボリュームを拡張します。
  4. LUKSデバイスを拡張します。
  5. FSを拡張します。

縮小RAID -> LVM -> LUKS -> FS：

  1. FSを縮小します。
  2. LUKSデバイスを縮小します。
  3. 論理ボリュームを縮小します。
4
Martian