仮想マシンイメージにLVMパーティションを使用する必要がありますか？

「時によって変わりません」

管理する環境（vmware、kvmなど）にあり、ディスクのパフォーマンスQoSを直接決定できる場合は、仮想マシンでLVMを使用しないことをお勧めします。ハイパーバイザーレベルでは得られない柔軟性を提供しません。

ハイパーバイザーはすでにこれらのタスクを効果的に実行していることを覚えておいてください。ファイルシステムのサイズを任意に調整するには（良いアイデア）、各ファイルシステムごとに別々の仮想ディスクを作成するだけです。

この道を行くと、一つの考えが浮かび上がるだろう。これにより、仮想ディスクにパーティションを配置する必要もありません。たとえば、仮想マシン内にあります/home。用の仮想ディスクを作成できます。ファイルシステムを作成するときにパーティションを指定するのではなく、これを行うだけです /dev/vdc。mke2fs -j /dev/vdc

これは良い考えですが...ほとんどのツール（およびそれ以降の他の管理者）は各ディスクのパーティションを見たいと思います。ディスクにパーティションを置いて作業を完了することをお勧めします。ただし、これはファイルシステムのサイズを変更するときにさらに1つのステップが必要であることを意味します。そして、パーティションを正しく整列することを忘れないでください。最初のパーティションでは、1MBから始めるのが良い経験則です。

ただし、ハイパーバイザーレベルでこれを行うと、パーティションのサイズを変更するためにVMを再起動する必要があります。 LVMを使用すると、仮想ディスクをホット追加し（ハイパーバイザー/ OSの組み合わせでこれを可能にすると仮定）、再起動せずにファイルシステムを拡張できます。これは確かにプラスです。

一方、クラウドプロバイダを使用する場合は、より微妙です。

私は、Azure、GCP、またはその他の小規模企業に精通していないので、助けることができません。

AWSを使用すると、上記のアドバイスに従うことができ、通常は大丈夫でしょう。 （現在）EBSボリューム（仮想ディスク）のサイズを即座に増やしてパーティションのサイズを変更するなどの操作を実行できます。

しかし、一般的なケースでは、すべてを大規模なEBSボリュームに配置し、LVM（または私の考えでは通常のパーティション化）を使用するのが合理的かもしれません。 AmazonはボリュームあたりのIOPS制限を提供します。デフォルトでは、この制限はボリュームサイズに応じて拡張されます。たとえば、gp2ボリュームの場合、GiBあたり3 IOPS（最小100 IOPS）を取得します。バラよりhttps://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

ほとんどのワークロードでは、現在の要件に応じて、利用可能なすべてのIOPSをすべてのファイルシステムで利用できるようにしたいと思います。したがって、大規模なEBSボリュームを作成し、すべてのIOPSをバケットに配置してから、パーティション/ LVMを作成するのが妥当です。

例:

それぞれ100GBの独立したファイルシステム/スワップ領域を持つ3つのディスク。それぞれ300 IOPSを取得します。パフォーマンス制限はディスクあたり300IOPSです。

ディスク1つ、サイズ300GB。ディスクのLVMパーティションはそれぞれ100 GBです。ディスクは900 IOPSを取得します。すべてのパーティションは900 IOPS全体を使用できます。