web-dev-qa-db-ja.com

LVM拡張ファイルシステム：新しいパーティションと既存のパーティションの拡張

VMWare-ESX 6で実行されるRHEL7-Systemでファイルシステムを拡張する必要があることがよくあります。通常、既存の仮想ディスクのサイズを変更して、次のcmdを実行します。

  1. echo "1">/sys/class/scsi_disk/0：0：X：X/device/rescan
  2. pvresize/dev/sdX
  3. lvextend -l + 100％FREE [VolumeGroup]
  4. resize2fs [MountPoint]

これは便利な解決策だと思いますが、RedHat、VMWare、および私が見つけた他のHow2の大部分は別の方法を使用しています。彼らは新しいパーティションを作成し、既存のパーティションのサイズを変更する代わりに、ボリュームグループに追加します。

見る：

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006371

https://access.redhat.com/solutions/2477

スペースの必要性を予測できないため、かなり頻繁にサイズ変更する必要がありましたが、毎回新しいパーティションを作成したくありません。彼らが2番目の方法を使用して好む理由があるはずですが、私はそれが悪い方法だと思います。誰か教えてもらえますか？

よろしくサシャ

linuxredhatlvm
4
C_o_H

実際、RedHat記事のステップへのリンクには、次のように書かれています。

空きディスクまたはパーティション（例：/ dev/sdc1をパーティションとして）から物理ボリュームを作成します

また、VMWareの記事へのリンクには、上部に注記があります。

注：これらの手順はEXT3ファイルシステムにのみ適用されます。

したがって、どちらかまたは両方を行うことができます。ほとんどすべての場合（RHEL7/GRUB2の時点で-申し訳ありませんがVMWareについて話すことはできません）に推奨される方法は、以下のようなスキームを作成しているため、パーティションを作成しないことです。

Disk
|- MBR
|- |- LVM 
|- |- |- Superblock

かつてはパーティション分割を行わないことでアライメントの問題があり、パフォーマンスが低下しましたが、LVMで不足しているパーティションを必要とするシステムの場合は、それを補うことができます。

パーティション化の推奨は、他のOSがLVMメタデータを読み取ることができず、パーティションがないため、ディスクがパーティションを持っていると表示するのではなく、フォーマットされていないものとして表示するという事実に基づいていました。実際、Linuxでも、パーティションがない場合、ディスクはすべてのパーティションツール（fdisk、gdisk、partedなど）で使用されていないように見えます。これは、パーティションを探すように設計されているためです。

VMwareを実行している場合は、コントロールが配置されている企業環境で作業していると想定しています。SAは、パーティションを操作する理由がなく、Windowsやその他の「その他」を使用することはありません。マシンが再利用されていない限り、OS」がマシンにインストールされています。したがって、パーティション分割の推奨は適用されません。

古いバージョンのRHELでのベストプラクティスは、パーティションを作成することでした： https://unix.stackexchange.com/questions/76588/what-is-the-best-practice-for-adding-disks-in-lvm

古いシステムではGRUB2の代わりにGRUB）を使用するため、ディスク全体を使用するという改訂された推奨事項はもちろんRHEL 7にとって新しいものです。これらの古いシステムでは、パーティション分割を維持する理由は/ bootが物理ディスク上にあります。

あなたの場合、OSディスクを参照していないので、古いシステムでも、パーティションなしでLVMメタデータをrawディスクに直接安全に保持できます。

保護MBRを使用したい場合が1つあります。これは、vmdkまたはその他のタイプのファイルを使用する代わりに、ゲストOSの物理ドライブでLVMを使用している場合です。しかし、@ shodanshokで指摘されているように、ハイパーバイザーのlvm.confでフィルターを使用してそれらを非表示にすることができます。

これがSANバックアップされた物理ディスクの場合、ここで議論があります： https://access.redhat.com/discussions/148802

Oracle DBAは、rawディスクの使用も推奨しています。 http://www.dba-Oracle.com/real_application_clusters_rac_grid/raw_devices_linux.html

最後に、これについてRedditでも議論があります： https://www.reddit.com/r/sysadmin/comments/292qf2/lvm_physical_disk_vs_partitions/

ほとんどの人が同意し、ディスク全体を使用します。

興味があれば、LVMでバックアップされたディスクからの起動についてさらに読んでください。 https://unix.stackexchange.com/questions/136614/how-does-grub2-load-the-kernel-from-an-lvm-volume

http://forums.fedoraforum.org/showthread.php?t=263325

要約すると、ディスク全体を使用します。ある日、パーティショニングツールは、zfsツール、btrfsツール、lvm、またはこれら3つの組み合わせなどを優先して、* nixでの使用を完全に廃止する可能性があります。

1
Speeddymon

コマンドに基づいて、rawデバイスを物理ボリュームとして使用しています。 Red Hatは通常、完全に問題ありませんが、保護MBRを作成し（つまり、基盤となるディスクをパーティション分割するため）、パーティションを物理ボリュームとして使用することをお勧めします。

fdiskのような一般的なツールは、パーティションサイズを直接拡張することはできません。むしろ、パーティションを手動で削除/再作成する必要があります。そのため、オンラインFAQは通常、新しいパーティションを作成し、それを新しい物理ボリュームとして追加するという、より単純なアプローチを提示します。さらに、ゲストシステムにパーティション拡張を検出させるために、多くの場合、再起動が必要になります。一方、パーティションを追加しても、再起動は必要ありません。

とにかく、vdiskサイズを拡張するためにパーティションを継続的に追加することは最善のアプローチではないことに同意します。私は通常、（MBRバックアップを作成した後）手動でパーティションのサイズを変更し、ゲストシステムを再起動してから、サイズ変更されたパーティションに対してpvresizeを発行することを好みます。

1
shodanshok