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


46

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

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

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

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

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


16
ああ、私はあなた自身とSFの他の「高レプ」ユーザーの何人があなたの最初の質問にどれほど感銘を受けたかコメントしたいだけです。私たちは時々新しい人を打ち負かしたと非難されますが、実際には多くの新しいユーザーが私たちが何をしていて何を読んでいないのですか?よく書かれ、考えられている方法:)
Chopper3 14年

5
ただし、次の2つの意見があります。1)VMWareは製品ではなく、会社です。VMWare ESXiは製品になります。2)この質問は、KVM、Xen、HyperVなどにも同様に関連するため、一般的に仮想化環境に関するものになるように編集します。
スヴェン

1
ありがとう。そして、私は言葉遣いをもう少し一般的になるように編集しました。
サボチェ14年

@savoche答えをマークする必要があります。
ewwhite

回答:


27

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

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

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です。


2
おっと、私を超老feelにさせてくれてありがとう。私にとって、2007年はまだ「ほぼ最新」です。:-)
ブライアンノブラウチ

1
マウントポイントとして追加される追加のVMDKはパーティション化されません。
ewwhite 14年

1
すべてのテクノロジーには限界があり、そのページにはLVMがひどいという主張を裏付けるものは何もありません。答えのその部分を変更することをお勧めします。なぜなら、それは有益な情報よりもFUDの方が多いからです。PS。私のコメントのどれかが耳障りに聞こえた場合は申し訳ありませんが、実際の作業を行う間に書き込みを行うため、自分の言葉が他の人にどのように聞こえるかについてはあまり考えません。
ヤコブソシック14年

5
「昔」は2007年でしたか?私は、バージョン1が出荷された1999年にIBMの無料のライセンス受領者でした。私はVMの恐竜です:D(waves @BrianKnoblauch)。あなたのLVMコメントによれば、あなたはLinuxの文脈でそれを判断しているように聞こえます。LVMは、Linuxが登場する何年も前から商用UNIXの土地で成熟した技術を使用していました。トップエンドのSolaris / Sparc / EMC Symmetrixを管理していた場合、Linuxは一歩下がったようなものでした(それでも多くの点で違いはありません)。小さいディスクの時代、LVMは数テラバイトのデータベースを管理可能にしました。私はあなたが説明する問題を経験したことはありません。それは本当に人々の問題のように聞こえますが、私は確かに関係します。
コデンハイム14年

1
LVMバッシングにもかかわらず+1。答えの残りは、明らかな経験からの良いものです。
コデンハイム14年

7

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

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


6

特定の「大規模な仮想化ソフトウェア会社」のインフラストラクチャで働いていたとき、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が必要です。

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


1
カーネルがパーティションテーブルを再読み込みできるようにするために再起動する必要はありません。ただし、サイズ変更されたデバイスでファイルシステムをアンマウントする必要あります(/パーティションの場合は注意が必要です)。それ以外は、パーティションテーブルはむしろドキュメンタリーの目的に役立ちます-誰もが、おじはfdisk -l(または対応する同等の)を実行して、未知のディスクが何であるかを確認します。パーティションが作成されていない場合、「空」と間違えられて上書きされる可能性があります。これが、ディスク用のパーティションテーブル常に作成する理由です。ただし、LVMは悪です。
the-wabbit 14年

これはこれらの特定のVMでの私の経験ではありませんが、過去には他のVMで機能していました。fsをアンマウントしてもロックは解放されませんでした。たぶんそれはちょうどCentos5だった、私は知らない。私は困惑しました。パーティションの世界では、LVMは素晴らしいです。新しいbtrfs / zfsの世界では、廃止されました。もちろん、私見。
ラウエンツァ14年

VM内で実際にlvmを使用していることに気付くまでに少し時間がかかりました...ホストでLVMを使用せず、ゲストにディスクとして使用するlvを与える理由はありますか?サイズ変更の手順は、ホストのボリュームのサイズ変更、ゲストでの再スキャン、ゲストでのresize2fsです。
GnP 14年

はい、vm内。これはesxの下にあるため、仮想ディスクはvmdkファイルでなければなりません。はい、理論的にはゲストでrawディスクを使用できたはずです。
ラウエンツァ14年

ベアディスクを使用する方がはるかに簡単です。5つのうち2つのステップが削除され、LVMを知る必要はありません。LVMでFSのサイズを変更するのは危険ですが、それは改善されつつあります:LVMの危険性と注意事項
-RichVel

1

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

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

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


VM内のLVにVGが必要なのはなぜですか?(ただ、このようなセットアップの使用を把握しようと、私はあなたの方法を判断していないよ、私はLVMにかなり新しいです注意してください)
GNP

ホストでLVMフィルターを使用して、ネストされたLVを除外できます。
ミルチャVutcovici

1

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

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

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

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

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

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

マルチドライブを使用すると、(少なくともESXiで)一部のディスクファイルを独立モードにすることもできます。これにより、スナップやスナップベースのバックアップなどに一時データを含めることを回避できます。
サボチェ14年

1

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

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

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

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


0

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

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

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


0

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

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


0

私の経験では、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で直接サイズを変更できます。


/ bootの後にスワップを明確にパーティション分割した方法が気に入っています。これは最近(2008年頃)にわかりました。古い肥大化したカーネルイメージを1つでも保持すると、控えめな/ bootパーツが引き伸ばされ、sda2を/ bootに供給することで十分なスペースが得られることがよくあります。それがある場所にあることは、PV保持ルートの再配置がないことを意味し、それは時々リモートで行う必要がある厄介な操作を節約します。:-)
user2066657

0

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

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