Linux on VMware-なぜパーティショニングを使用するのですか？
仮想化環境（私の場合はESXi）にLinux VMをインストールする場合、マウントポイントごとに個別のディスクを追加するだけでなく、ディスクをパーティション化する（ext4を使用する場合）説得力のある理由はありますか？
私が見ることができるのは、ディスク上にデータが存在するかどうかを簡単に確認できることだけです。 fdisk。
一方、パーティションを使用するnotにはいくつかの理由があります（/ boot以外の場合）。
- ディスクの拡張がはるかに簡単です。 VM（通常はVCenter））のディスクサイズを増やしてから、VMでデバイスを再スキャンし、オンラインでファイルシステムのサイズを変更します。
- パーティションを基礎となるLUNと調整することに関する問題はもうありません。
私はこのトピックについてあまり知りませんでした。重要な何かを見逃しましたか？
これは興味深い質問です...
明確な答えはないと思いますが、このトピックを取り巻くベストプラクティスが時間とともにどのように変化したかについて、いくつかの歴史的背景を与えることができます。
2007年以降、VMware環境全体でさまざまな形式で展開された数千のLinux VMをサポートする必要がありました。展開へのアプローチが進化し、ユニークな（時々不幸な）他のエンジニアによって構築されたシステムの継承とリファクタリングの経験。
昔...
当時（2007年）、私の初期のVMwareシステムは、ベアメタルシステムと同じようにパーティション分割されていました。 VMware側では、VMのデータを構成するために2GBの分厚いファイルを使用していましたが、仮想化が機能することさえ嬉しかったので、複数のVMDKの概念についてさえ考えていませんでした。
仮想インフラストラクチャ...
ESX 3.5および初期のESX/ESXi 4.xリリース（2009-2011）では、通常のモノリシックThickプロビジョニングVMDKファイルの上にパーティション分割されたLinuxを使用していました。ストレージを事前に割り当てる必要があるため、実際のハードウェアの場合と同じようにLinuxの設計について考える必要がありました。オペレーティングシステム用に36 GB、72 GB、146 GBのVMDKを作成し、通常の/、/ boot、/ usr、/ var、/ tmpをパーティション化してから、「data」または「growth」パーティション用に別のVMDKを追加しました（/ホーム、/ optまたは何かアプリケーション固有）。繰り返しますが、この時代の物理ハードディスクサイズのスイートスポットは146GBで、事前割り当てが（NFSを使用しない限り）要件だったため、保守的にスペースを確保する必要がありました。
シンプロビジョニングの登場
VMwareは、後のESXi 4.xリリースで シンプロビジョニング に関するより優れた機能を開発しました。これにより、新しいシステムのインストール方法が変わりました。 5.0/5.1で追加された完全な機能セットにより、新しいタイプの柔軟性により、より創造的な設計が可能になりました。ちなみに、これはvCPUの数と個々のVMにコミットできるRAMの数）の点で、仮想マシンの機能の増加に歩調を合わせていました。より多くの種類のサーバーとアプリケーションを仮想化できますこれは、コンピューティング環境が完全に仮想化され始めているため、これは正しいことです。
LVMはひどい...
VMレベルでの完全なホットアド機能が整っていて一般的だった（2011-2012）までに、クライアントのVMの稼働時間をいつでも維持できるように努めている会社と協力していたコスト（stupid）。これには、オンラインのVMware CPU/RAMの増加とrisky既存のVMDKでのLVMディスクのサイズ変更が含まれます。ほとんどのLinuxシステムこの環境では、LVMの上にext3パーティションを持つ単一のVMDKセットアップがありました。LVMレイヤーが操作に 複雑さと不必要なリスク を追加したため、これはひどいものでした。たとえば、/ usrのスペースが不足すると、最終的にはバックアップからシステムを復元することを意味する悪い決定の連鎖の中で...これは部分的にプロセスと文化に関連していましたが、それでも...
パーティションsnobbery ...
私はこの機会を利用してこれを変更しようとしました。 Linuxのpartition-snobの一部であり、監視と運用のニーズのためにファイルシステムを分離する必要があると感じています。私はまた、特にVMwareとあなたが求めていることを実行する能力を備えたLVMが嫌いです。そこで、VMDKファイルの追加を、潜在的に大きくなる可能性のあるパーティションに拡張しました。/opt、/ var、/ homeは、必要に応じて独自の仮想マシンファイルを取得できます。そして、それらはローディスクになります。時々、これはその場で特定の小さめのパーティションを拡張するためのより簡単な方法でした。
オバマケア...
非常に注目度の高いクライアント のオンボーディングで、私はLinuxの設計を任されましたVMそれらの作成に使用される参照テンプレートextremelyvisible application environment。アプリケーションのセキュリティ要件には ユニークなマウントのセット が必要なため、開発者と協力して非拡張パーティションを1つのVMDKに詰め込もうとしました、その後、拡張の可能性がある、または特定の要件（暗号化、監査など）があったマウントごとに個別のVMDKを追加します。したがって、最終的に、これらのVMは5つ以上のVMDKで構成されていましたが、将来のサイズ変更とデータの保護。
今日私がすること...
今日、私のLinuxおよび従来のファイルシステムの一般的な設計は、1つのシンVMDK（パーティション化）上のOSと、それ以外のディスクリートVMDKです。必要に応じてホットアドします。 ZFSのような高度なファイルシステムの場合、OSのVMDKの1つと、ZFS zpoolとして機能し、サイズを変更したり、追加のZFSファイルシステムに分割したりできるVMDKです。
あなたは多くの点で正しいです、私は議論を見ることができます-しかし、トリッキーになるかもしれない1つの問題があります。リソースプールを使用している場合（そして、私が使用していないことはわかっていますが、嫌なことです）、VMはより多くのIOより多くのディスクを持っている場合-時間を取得できます-極端なリソース制約状況ではVMが2つのディスクにある場合、IOリソースが1つのディスクにある場合の2倍になります。これは問題にはならないかもしれませんが、指摘したいと思います。
編集-ああ、それはスナップも少し遅くなりますが、再びそれは問題ではないかもしれません。
特定の「大規模な仮想化ソフトウェア会社」のインフラストラクチャで働いていたとき、しばしばvmのファイルシステムのサイズを増やす必要がありました。当時はext3/4を使っていました。
仮想ディスクの増加は非常に簡単で、ライブOSでの新しいデバイスサイズの取得は比較的簡単です（/ sysを参照）。ext3/ 4ファイルシステムライブのサイズ変更は簡単でしたが、常に（ライブを実行する）不可能と思われたのはパーティションのサイズ変更。
Gdiskedを使用するか、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
しかし、ベアディスクはrescanとresize2fsが必要なだけです。
したがって、要約すると、可能であれば、パーティションテーブルは避けてください。
これを行う方がよいかどうかは、システムによって異なります。
それぞれの設定には長所と短所があります。
ただし、単一のドライブの主な利点は次のとおりです。
- シンプル：1つのドライブに1つのファイルがあり、簡単に配布および複製できます。
- ホストOSへの手がかり：単一のファイルは単一のデータブロックとして扱われるため、ホストOSは、ゲストマシンアクセスのシーケンスがすべて1つのファイルにあることを認識します。これは、すべてのドライブイメージを同じファイルに配置するだけで、一部のホストOS構成で実現できますが、必ずしもそうとは限りません。
ただし、マルチドライブには利点があります。
- ベアメタルアフィニティ/手動の場所：単一のドライブでは、ドライブの単一のベアメタルアフィニティにロックされます。
- サイズの制限：ドライブまたはファイルのサイズにシステムの制限がある場合、非常に大きなシステムで制限が発生する可能性があります。
- セキュリティのための読み取り専用ボリューム：これは大きな利点です。 OSのマスターボリュームがVM側でのみ読み取られる場合、これはセキュリティ上の大きな利点を提供し、本質的にVM内のプログラムの機能を編集できないようにします。ゲストのベースOS。別のデータドライブを使用すると、読み取り専用ドライブを作成でき、クリーンルームテンプレートデータだけでなく、メンテナンスや更新のために読み取り/書き込みで起動でき、サーバー内から重要なOSディレクトリが完全に変更されるのを防ぎます。
別のオプションがあります。NFSボリュームにアプリケーションデータをマウントします。優れたファイラーが必要です（すべてのNFS実装が同じというわけではありません）。
NFSボリュームがいっぱいになったら、ボリュームを拡張すると、Linuxクライアントにすぐに余分なスペースが表示されます。
アプリケーションとベンダーはNFSでのデータの保持をサポートする必要があり、慎重にNAS設計する必要がありますが、仮想化環境のすべてのストレージソリューションを使用する必要があります。
このアプローチのもう1つのボーナスポイントは、ストレージベンダーがスナップショット/クローニングテクノロジー（zfsやNetappなど）を持っている場合、データのバックアップとテスト/開発環境の作成が非常に簡単なことです。
書かれている質問はVMWare（ESXi）に関するものですが、KVMで同じアイデアを得た後、パーティションテーブルの使用に切り替えた状況を追加したいと思います。
LVMボリュームがVMのディスクとしてあり、VM内にパーティションを使用せずに（仮想ディスク全体をPVとして使用して））LVMボリュームグループを作成すると、このVGは外部に表示されることがわかりましたVM。これは、パーティションをPVとして使用する場合には当てはまりません。
確かに、これはまれなケースですが、そのような設定が必要かどうかを検討する価値があります。
私は2つの理由で分割します：
- ドキュメント-以前は「訓練を受けた」EMC管理者がLUNを私のすぐ下から盗みました。それらはドキュメント化されておらず、割り当てられていないように見えたため、真夜中に突然突然オフラインになったOracleデータベースがページングされました。彼は私のLUNを無関係なアプリ用の別のボリューム用に再プロビジョニングしました。それ以来、私はドキュメントについて偏執的です。
- ディスクをオーバープロビジョニングしています。プラッターを使用すると、低速のシリンダーからデータを保護し、SSDを使用すると、寿命/ MTBFが延長されます。
一部のLinuxディストリビューションでディスクをパーティション分割する必要がある理由は、ブートローダーとそれに付随するすべてのレガシー部分、つまりエミュレートされたBIOSがあるためです。これにより、ディスクのサイズ変更が困難になり、多くの場合、LVMまたは他の同様の意味のないものを使用することになります。
ボリューム全体にファイルシステムを作成し、それを/にマウントするだけで、非常にカスタムされた（またはカスタマイズ可能/意見のない）Linuxディストリビューションで動作します。前回、Ubuntu 12.04でこれを試しましたが、愚かなパーティションテーブルとすべてのジャズをインストールする必要があるため、インストーラはそれを処理する方法を知りませんでした。これは、仮想化された世界における汎用配布の問題の1つです。
もう1つは、パーティショニングを従来の用途に実際に使用できることです。たとえば、 ChromeOS および CoreOS には、システムアップグレード用に2つの読み取り専用ルートパーティションがあります。
これまでに言及されていない理由の1つは、Google Computeのような一部のインフラストラクチャで、 disk IOパフォーマンスはディスクのサイズに比例して増加する です。 、1つの大きなパーティションドライブは、複数の小さなドライブよりも優れたIOパフォーマンスを発揮します。
ただし、これは一般的には当てはまりません。 Chopper3で言及されているように、ほとんどの場合、複数のドライブの方がパフォーマンスが向上しますIOパフォーマンス。最終的には、すべての仮想ドライブが単一の物理ドライブにマップされている場合、違いはありません。
私の経験では、より良いアプローチは1つのVMDK for OSを使用することであり、通常は次の方法でパーティションを分割します。
/dev/sda1 - /boot - 256M
/dev/sda2 - swap - ~4GB
/dev/sda3 - / - ~8GB
私は通常、最小のLinuxディストリビューション（約800MB）と必要なソフトウェアをインストールするため、8GBで/に十分であることがわかりました。ログもそのパーティションに送られますが、正しく設定され（1週間logrotate）、別の場所（syslog/elasticsearch）に出荷された場合、通常はパーティションをいっぱいにするような扱いはしません。
データは別のVMDKとして追加され、私は通常、裸のディスク（例：/ dev/sdb）で直接ファイルシステムをフォーマットします。これにより、VmWareでボリュームのサイズを変更し、VMで直接パーティションのサイズを変更できます。再パーティション化/アンマウント/再起動する必要はありません。