Linux on VMware-パーティション化を使用する理由

Linux VMを仮想化環境（私の場合はESXi）にインストールする場合、マウントポイントごとに個別のディスクを追加するだけでなく（ext4を使用する場合）ディスクをパーティション分割する説得力のある理由はありますか？

私が見ることができる唯一のことは、例えばfdiskでディスク上にデータが存在するかどうかを見るのがいくらか簡単になることです。

一方、パーティションを使用しない理由はいくつかあります（明らかに/ boot以外）。

• ディスクを簡単に拡張できます。VM（通常はVCenter）のディスクサイズを増やしてから、VMでデバイスを再スキャンし、オンラインでファイルシステムのサイズを変更するだけです。
• パーティションを基礎となるLUNに揃える際の問題はもうありません。

このトピックについてはあまり見つけていません。重要なものを見逃していませんか？

これは興味深い質問です...

決定的な答えがあるとは思いませんが、このトピックを取り巻くベストプラクティスが時間とともにどのように変化したかについて、歴史的な背景を説明できます。

2007年以降、VMware環境全体にさまざまな形式で展開された数千のLinux VMをサポートする必要がありました。展開へのアプローチは進化しており、他のエンジニアによって構築されたシステムを継承およびリファクタリングするユニークな（時には不幸な）経験がありました。

昔...

当時（2007年）、初期のVMwareシステムはベアメタルシステムと同様にパーティション分割されていました。VMware側では、VMのデータを構成するために2GBの分割ファイルを使用していましたが、複数のVMDKの概念についても考えていませんでした。

仮想インフラストラクチャ...

ESX 3.5および初期のESX / ESXi 4.xリリース（2009〜2011）では、Linuxを使用し、モノリシックなシックプロビジョニングされたVMDKファイルの上に通常のパーティションとしてパーティション分割されました。ストレージを事前に割り当てなければならなかったため、実際のハードウェアと同様の方法でLinuxの設計を考える必要がありました。オペレーティングシステム用に36GB、72GB、146GBのVMDKを作成し、通常の/、/ boot、/ usr、/ var、/ tmpをパーティション分割してから、「data」または「growth」パーティションに別のVMDKを追加しました（/ home、/ opt、またはアプリケーション固有のもの）。繰り返しますが、この時代の物理ハードディスクサイズのスイートスポットは146GBでした。また、（NFSを使用しない限り）事前割り当てが必要だったため、スペースを節約する必要がありました。

シンプロビジョニングの出現

VMwareは、以降のESXi 4.xリリースでシンプロビジョニングに関するより優れた機能を開発しました。これにより、新しいシステムのインストール方法が変わりました。5.0 / 5.1で追加されたすべての機能セットにより、新しいタイプの柔軟性により、より創造的なデザインが可能になりました。念頭に置いて、これは、vCPUの数と個々のVMにコミットできるRAMの量の点で、仮想マシンの機能強化に対応していました。過去よりも多くの種類のサーバーとアプリケーションを仮想化できました。これは、コンピューティング環境が完全に仮想化され始めていたためです。

LVMはひどい...

VMレベルでの完全なホットアド機能が導入され一般的になった頃（2011〜2012）、私はクライアントのVMの稼働時間をなんとかして（愚か）維持しようと努力していました。そのため、これには、オンラインのVMware CPU / RAMの増加と、既存のVMDKでのリスクのある LVMディスクのサイズ変更が含まれていました。この環境のほとんどのLinuxシステムは、LVM上にext3パーティションを持つ単一のVMDKセットアップでした。これはひどいものでした。なぜなら、LVMレイヤーは操作に複雑さと不必要なリスクを追加したからです。たとえば、/ usrのスペースが不足すると、最終的にシステムをバックアップから復元することを意味する一連の不適切な決定が発生する可能性があります...

パーティションの盗聴...

私はこの機会にこれを変えようとしました。私はLinuxのパーティションスノブに少し慣れており、監視と運用上のニーズのためにファイルシステムを分離する必要があると感じています。また、特にVMwareと、あなたが求めていることを実行する機能に関しては、LVMも嫌いです。そこで、VMDKファイルの追加を、成長する可能性のあるパーティションに拡張しました。/ opt、/ var、/ homeは、必要に応じて独自の仮想マシンファイルを取得できます。そして、それらはrawディスクになります。時々、これは特定のサイズの小さいパーティションをその場で拡張する簡単な方法でした。

オバマケア...

非常に知名度の高いクライアントのオンボーディングにより、非常に目に見えるアプリケーション環境を作成するために使用されるLinux VMリファレンステンプレートの設計を行いました。アプリケーションのセキュリティ要件には独自のマウントセットが必要だったため、開発者と協力して非成長パーティションを1つのVMDKに詰め込み、成長の可能性がある特定の要件（暗号化、暗号化、そのため、最終的にこれらのVMは5つ以上のVMDKで構成されましたが、将来のデータのサイズ変更と保護に最高の柔軟性を提供しました。

私が今日すること...

今日、Linuxおよび従来のファイルシステムの私の一般的な設計は、1つのシンVMDK（パーティション化）上のOS、およびそれ以外のディスクリートVMDKです。必要に応じてホットアドします。ZFSのような高度なファイルシステムの場合、OS用のVMDKの1つであり、ZFS zpoolとして機能し、サイズ変更、追加のZFSファイルシステムへの分割などが可能なVMDKです。

あなたは多くの点で正しいです、私は議論を見ることができます-しかし、トリッキーなことを証明する可能性がある1つの問題があります。リソースプールを使用する場合（嫌いなことはわかりません）、VMにディスクがあればIO時間を増やすことができます-極端なリソース制約の状況では、2つのディスクを持つVMは、2つのディスクを持つIOリソースの2倍のIOリソースを取得できます単一のディスク。これは問題にならないかもしれませんが、指摘したいと思います。

編集-ああ、それはスナップも少し遅くなりますが、再びそれは問題ではないかもしれません。

特定の「大規模な仮想化ソフトウェア会社」のインフラストラクチャで働いていたとき、vmのファイルシステムのサイズを増やす必要がし​​ばしばありました。当時はext3 / 4を使用していました。

仮想ディスクの増加は非常に簡単であり、ライブOSで新しいデバイスサイズを選択するのは比較的簡単です（/ sysで確認）、ライブext3 / 4ファイルシステムのサイズ変更は簡単でしたが、常に不可能と思われた（ライブを実行する）ことはパーティションのサイズを変更します。

gpartedを使用するか、fdiskを使用してパーティションテーブルを書き換え/サイズ変更する必要がありましたが、カーネルによって常にロックされており、カーネルに新しいレイアウトを適用させるには再起動が必要でした（partprobeもそれを行いませんでした）。

多くのシステムをLVMに移行し、ファイルシステムのサイズ変更は簡単で、ほとんど快適な体験になりました！

• VM外の仮想ディスクイメージを増やす
• VMで、
  • / sysを呼び出してディスクメトリックを再スキャンします（エコー "1"> / sys / class / scsi_device // device / rescan）
  • pvresize / dev / sdX（LVMの物理ボリュームのサイズ変更）
  • lvresize --extents + 100％FREE / dev / VG / lvolXX（LVMの論理ボリュームのサイズを変更）
  • resize2fs（ファイルシステムのサイズ変更）

これらはすべて、稼働中のシステムで安全に実行でき、再起動は不要です。

なぜベアディスクではないのですか？それは私を緊張させます-裸のディスクがまだ十分に広く受け入れられているとは感じていませんが、私たちはもっと広く受け入れられる寸前だと思います。これに関連するbtrfsメーリングリストにスレッドがありました。

http://www.spinics.net/lists/linux-btrfs/msg24730.html

ただし、ベアディスクには再スキャンとresize2fsが必要です。

要約すると、ええ、できればパーティションテーブルを避けてください。

書かれている質問はVMWare（ESXi）についてですが、KVMで同じアイデアを出した後、パーティションテーブルの使用に切り替えた状況を追加したいと思います。

LVMボリュームをVMのディスクとして使用し、パーティションを使用せずに（VMとして仮想ディスク全体を使用して）VM内にLVMボリュームグループを作成すると、このVGはホストマシン上のVMの外部で表示されることが判明しました。パーティションをPVとして使用する場合はそうではありません。

確かに、これはコーナーケースですが、そのようなセットアップが必要かどうかを検討する価値があります。

これを行う方が良いかどうかは、システムによって異なります。

各セットアップには長所と短所があります。

ただし、単一ドライブの主な利点は次のとおりです。

1. シンプルさ：単一のドライブには単一のファイルがあり、簡単に配布および複製できます。
2. ホストOSへのキュー：単一のファイルは単一のデータブロックとして扱われるため、ホストOSはゲストマシンアクセスのシーケンスがすべてその1つのファイルにあることを認識します。これは、すべてのドライブイメージを同じファイルに配置するだけで、一部のホストOS構成で実現できますが、必ずしもそうとは限りません。

ただし、マルチドライブには利点があります。

1. ベアメタルアフィニティ/手動の場所：単一のドライブでは、ドライブの単一のベアメタルアフィニティにロックされます。
2. サイズの制限：システムでドライブまたはファイルのサイズに制限がある場合、非常に大きなシステムでそれらを使用できます。
3. セキュリティのための読み取り専用ボリューム：これは大きな利点です。OSのマスターボリュームがVM側でのみ読み取られる場合、セキュリティ上の大きな利点が得られ、VM内のプログラムがゲストのベースOSを編集できないようになります。別のデータドライブを使用すると、読み取り専用ドライブを作成できます。このドライブは、クリーンルームテンプレートデータだけでなく、メンテナンスと更新のために読み取り/書き込みで起動できます。

別のオプションがあります：アプリケーションデータをNFSボリュームにマウントします。優れたファイラーが必要です（すべてのNFS実装が同じではありません）。

NFSボリュームが一杯になったら、ボリュームを拡張すると、Linuxクライアントに余分なスペースがすぐに表示されます。

アプリケーションとベンダーは、NFSでのデータの保持をサポートする必要があり、慎重なNAS設計が必要ですが、仮想化環境のすべてのストレージソリューションを使用する必要があります。

このアプローチのもう1つのボーナスポイントは、ストレージベンダーがスナップショット/クローニングテクノロジー（zfsやNetappなど）を持っている場合、データのバックアップとテスト/開発環境の作成が非常に簡単であることです。

一部のLinuxディストリビューションでディスクのパーティション分割を行う必要があるのは、ブートローダーとそれに付随するすべてのレガシーピース、つまりエミュレートされたBIOSがあるためです。これにより、ディスクのサイズ変更が難しくなり、多くの場合、LVMまたはその他の同様のナンセンスを使用してしまいます。

ボリューム全体にファイルシステムを作成してマウントするだけで/、非常にカスタム（またはカスタマイズ可能/非意見）のLinuxディストリビューションで動作します。Ubuntu 12.04でこれを最後に試したとき、インストーラーは、愚かなパーティションテーブルをすべてジャズにインストールする必要があるため、その処理方法を知りませんでした。これは、仮想化された世界での汎用配布の問題の1つです。

他方では、実際にはパーティション分割をあまり伝統的でない用途に置くことができます。例えば、ChromeOSとCoreOSはシステムのアップグレード用に2つの読み取り専用ルートパーティションを持っています。

これまで言及されていない理由の1つは、Google Computeのような一部のインフラストラクチャでは、ディスクIOのパフォーマンスがディスクのサイズとともに直線的に増加することです。つまり、1つの大きなパーティションドライブは、複数の小さなドライブよりも優れたIOパフォーマンスを発揮します。

ただし、これは通常そうではないことに注意してください。Chopper3で述べたように、多くの場合、複数のドライブの方がIOパフォーマンスが向上します。最終的に、すべての仮想ドライブが単一の物理ドライブにマッピングされている場合、違いはありません。

私の経験では、OSに1つのVMDKを使用するのがより良いアプローチであり、通常は次のようにパーティション分割します。

/dev/sda1 - /boot - 256M
/dev/sda2 - swap  - ~4GB
/dev/sda3 - /     - ~8GB

通常、最小限のLinuxディストリビューション（〜800MB）+必要なソフトウェアをインストールするため、/には8GBで十分であることがわかりました。ログもそのパーティションに移動しますが、正しくセットアップ（1週間ログローテーション）し、他の場所（syslog / elasticsearch）に出荷した場合、通常はパーティションをいっぱいにすることはできません。

データは別のVMDKとして追加され、通常はベアディスク（/ dev / sdbなど）で直接ファイルシステムをフォーマットします。これにより、VmWareでボリュームのサイズを変更し、パーティションを再作成/アンマウント/再起動する必要なく、VMで直接サイズを変更できます。

次の2つの理由でパーティション分割します。

1. ドキュメント-かつて「トレーニングを受けた」EMC管理者がLUNを盗みました。ドキュメント化されておらず、割り当てられていないように見えたため、深夜に突然オフラインになったOracleデータベースのためにページングされました。彼は、無関係なアプリの別のボリューム用に私のLUNを再プロビジョニングしていました。それ以来、私はドキュメンテーションについて偏執的です。
2. ディスクのオーバープロビジョニング。プラッターを使用すると、低速のシリンダーのデータが保持され、SSDを使用すると、寿命/ MTBFが延長されます。