LVMにディスクを追加するためのベストプラクティスは何ですか
Linuxのマンページによると、ボリュームグループにrawディスクとパーティションを追加できます。
他のドキュメント（RedHat、CentOS、またはopenSUSE）では、すべての例は、RAWディスクではなくVGにパーティションを追加することを示しています。一般的な（ベスト）プラクティスとは何ですか？
RHEL6 LVM管理ガイド
RHEL 6論理ボリューム管理ガイド によると、ドライブ全体をLVMボリュームグループの物理ボリュームとして使用する場合でも、パーティション化することをお勧めします。
「RHEL6 Logical Volume Manager Administration LVM Administrator Guide」からの抜粋
2.1.2。ディスク上の複数のパーティション
LVMでは、ディスクパーティションから物理ボリュームを作成できます。以下の理由により、通常、ディスク全体をカバーする単一のパーティションを作成して、LVM物理ボリュームとしてラベルを付けることをお勧めします。
管理上の利便性
各実ディスクが一度しか表示されない場合は、システムのハードウェアを追跡する方が簡単です。これは、ディスクに障害が発生した場合に特に当てはまります。さらに、単一ディスク上の複数の物理ボリュームは、起動時に不明なパーティションタイプに関するカーネル警告を引き起こす可能性があります。
LVM Howto
セクション 11.1。LVM Howtoのディスクまたはディスクパーティションの初期化 は次のように述べています。
LVM Howtoからの抜粋
ディスク全体の場合：
ディスクでpvcreateを実行します。
# pvcreate /dev/hdbこれにより、ディスクの先頭にボリュームグループ記述子が作成されます。
非推奨
ディスク全体を（パーティション全体にまたがるパーティションではなく）PVとして使用することは、ディスク全体で発生する可能性がある管理上の問題のため、お勧めできません。ディスクを参照する他のOSはLVMメタデータを認識せず、ディスクが空いていると表示するため、上書きされる可能性があります。 LVM自体はディスクPV全体で正常に動作します。
LVMがパーティションテーブルを含むディスクを初期化できないというエラーが発生した場合は、まず、操作しているディスクが正しいものであることを確認してください。確信がある場合は、次のコマンドを実行してください。
[〜＃〜]危険[〜＃〜]
次のコマンドは、操作対象のディスク上のパーティションテーブルを破壊します。正しいディスクであることを確認してください。
# dd if=/dev/zero of=/dev/diskname bs=1k count=1 # blockdev --rereadpt /dev/diskname
結論
これらは、物理ボリュームとして追加する前に、HDD上の単一のパーティションをフォーマットする必要があるかどうかを判断する際に信頼できる主要なソースです。他の回答が示しているように（コメントも）、パーティションなしでドライブ全体を追加するだけで間違いはありません。
私にとっては、シートベルトを付けたまま車を運転するようなものです。事故に遭ったことがなければシートベルトは役に立たなかったが、事故に遭ったことがあったとしてもそれを着ていて良かった。
フォローアップ＃1（@Joelのコメントへ）
上記の2つのガイドが2つのかなり良い理由だと思いました。彼らは両方とも公式ガイドであり、一方はRHから、もう一方はLVMチームがまとめたHowtoです。
別の理由があります。 HDDにパーティションを設定しないことにより、HDDの使用方法を明確に識別するためのIDがHDDに明示的に設定されることはありません。
fdisk -l
...
/dev/sda6 318253056 956291071 319019008 8e Linux LVM
システムの管理者として、私や他の人にとって、この特定のドライブが8eなしでどのように使用されているかという意図ははるかに明白です。
@Joelの言ったことに感謝します。私もフォーチュン500の会社で働いていました。デスクトップ/サーバーの物理的/仮想的な展開と大規模なストレージの展開の両方で、100のLinuxを展開していたので、言って。
一般に認識されている記述子（メタデータ）をいくつか用意しておくと、MBRはそのような記述子として十分に機能します。 GPTでさえ、古いMBRベースのパーティションテーブルを使用して、その存在を示します。
確かに、ディスク領域がいくらか失われますが、ディスク上にあるもの（および場所）を理解することの利点は自明ですが、それはかなり無視できます。
ディスクの100％を占めるパーティションに物理ボリュームを作成することは、ほとんど正しいことではありません。私が「ほぼ」と言うのは、私が何かをする理由が考えられないからといって、それをする理由がないということではないという態度を取るからです。とはいえ、LVMになるのであれば、ディスクのパーティションを100％のスペースに配置する理由は1つとは思えません。
パーティション分割の硬直性の一部を取り戻す代わりに、認識できる利点はありません。これらがSANでサポートされている物理ボリュームであり、それを行う場合、ボリュームグループのストレージスペースを拡張する方法は2つしかありません。
- 新しい大きなLUNを提示し、それをボリュームグループに追加し、不可解にパーティション化したLUNをpvmoveで削除し、ボリュームグループから削除して、SAN人に提示しないように伝えます。オンラインで実行できます（パフォーマンスヒットがあり、これらの2つのLUNを保持するのに十分なSANストレージプールのスペースSAN=側）と仮定します同時に）しかし、それは実行可能です。
- 他の唯一の方法は、パーティションの扱いに戻ることです。これは、よく設計されたボリューム管理スキーム（btrfs、lvm、zfsなど）を好む理由の一部です。物理ボリュームのパーティションテーブルを編集して
partprobeで新しいサイズを読み取れることを期待できますが、これは私の個人的な経験から2のうち約1回しか機能せず、ファイルシステムをアンマウントする必要があります（つまり、 offlineボリュームマネージャーが好きなもう1つの理由）。
ディスク全体を実行する場合、SAN管理者がLUNを拡張できるので、SCSIバスを再スキャンし、LUNの新しいサイズを取得してから、pvresizeを使用して物理ボリュームを拡張します。ファイルシステムをオフラインにする必要はありません。
MBRビットから離れると、通常、PVを1つのシステムから取得して、エンタープライズ環境で別のシステムに提示することはありません。そうした場合でも、それがLVMの場合、LVMをサポートするためにLUNを提示する予定のOSが必要になります。そうでなければ、彼らにそれを提示する意味は何ですか？その場合、すべての物理ボリューム情報、ボリュームグループ情報、および論理ボリュームが表示されます（これがボリュームグループ内の唯一のPVであると想定しています）。したがって、その方法で自己文書化します。
基本的に：ディスク全体を100％に分割することは、Apple pieにあなたを連れてきたウェイターにもナイフを持ってくることを要求するようなものです。ナイフを横にして、顔をパイに埋めるだけです。意味：とにかく一度にすべてを使用する場合は、ツールを使って何かを小さな部分に分割することは意味がありません。
私の経験から、ディスクやストレージが利用できないテスト環境や小規模な環境であれば、パーティションを使用するのが良いでしょう。学校やガレージでの作業に最適です。現実の世界では、必要に応じてディスクを拡張できる仮想サーバーを使用して、パーティショニングの代わりにLVMにraw /全体ディスクを管理させると、より優れています。サーバーを再起動せずに管理するのは簡単で柔軟性があります。どれだけの時間を節約できるか知っていますか？管理する必要があるすべてのサーバーのを乗算します！カーネルが新しいテーブルを認識しない可能性があるため、パーティション/スライスのためにサーバーを再起動する必要があるという問題が何度かあります。 LVMにrawディスク/仮想ディスクを追加し、ファイルシステムを拡張する必要がある場合、rawディスクを使用してLVMを使用すると便利です。 「echo 1>/sys/block/XXX/device/rescan」のような簡単なコマンドを実行すると、XXXはディスク（sdb、sdc、sddなど）で、再起動せずにディスクを再スキャンして追加のスペースを探し、ブームが発生します。その場でファイルシステムを拡張できます。 Linuxサーバーを再起動せずにディスクを拡張するには、5分間かかります。パーティション化されたディスクでは、このプロセスは複雑です