Linux auf VMware - warum Partitionierung verwenden?

Gibt es bei der Installation von Linux-VMs in einer virtualisierten Umgebung (in meinem Fall ESXi) zwingende Gründe, die Festplatten zu partitionieren (bei Verwendung von ext4), anstatt nur separate Festplatten für jeden Einhängepunkt hinzuzufügen?

Das einzige, was ich sehen kann, ist, dass es etwas einfacher ist zu sehen, ob Daten auf einer Festplatte mit zB fdisk vorhanden sind.

Auf der anderen Seite sehe ich einige gute Gründe, warum ich Partitionen nicht benutze (für andere als / boot natürlich).

• Deutlich einfacher zu erweiterende Festplatten. Sie müssen lediglich die Festplattengröße für die VM erhöhen (normalerweise in VCenter), dann das Gerät in der VM erneut scannen und die Größe des Dateisystems online ändern.
• Keine Probleme mehr beim Ausrichten von Partitionen mit zugrunde liegenden LUNs.

Ich habe nicht viel zu diesem Thema gefunden. Habe ich etwas Wichtiges verpasst?

Das ist eine interessante Frage ...

Ich glaube nicht, dass es eine endgültige Antwort gibt, aber ich kann einen historischen Kontext dazu geben, wie sich die Best Practices in Bezug auf dieses Thema im Laufe der Zeit geändert haben könnten.

Ich musste seit 2007 Tausende von Linux-VMs unterstützen, die in verschiedenen Formen in VMware-Umgebungen bereitgestellt wurden. Mein Ansatz für die Bereitstellung hat sich weiterentwickelt, und ich hatte die einzigartige ( manchmal unglückliche ) Erfahrung, von anderen Ingenieuren erstellte Systeme zu erben und umzugestalten.

Die alten Tage...

Damals (2007) waren meine frühen VMware-Systeme genauso partitioniert wie meine Bare-Metal-Systeme. Auf der VMware-Seite verwendete ich geteilte Dateien mit einer Dicke von 2 GB, um die Daten der VM zusammenzufassen, und dachte nicht einmal über die Idee mehrerer VMDKs nach, da ich nur froh war, dass die Virtualisierung überhaupt funktionieren konnte!

Virtuelle Infrastruktur ...

Mit ESX 3.5 und den frühen ESX / ESXi 4.x-Versionen (2009-2011) verwendete ich Linux, das wie gewohnt auf monolithischen Thick- bereitgestellten VMDK-Dateien partitioniert war . Da ich Speicher vorab zuweisen musste, musste ich über Linux-Design auf ähnliche Weise nachdenken wie über echte Hardware. Ich habe VMDKs mit 36 ​​GB, 72 GB und 146 GB für das Betriebssystem erstellt, das übliche /, / boot, / usr, / var und / tmp partitioniert und dann ein weiteres VMDK für die Partition "data" oder "growth" hinzugefügt (unabhängig davon, ob dies / home, / opt oder etwas anwendungsspezifisches). Wiederum lag der Sweet-Spot bei den physischen Festplattengrößen in dieser Ära bei 146 GB, und da eine Vorbelegung erforderlich war (außer bei Verwendung von NFS), musste ich sparsam mit dem Speicherplatz umgehen.

Das Aufkommen von Thin Provisioning

VMware hat in späteren ESXi 4.x-Releases bessere Funktionen für Thin Provisioning entwickelt , und dies hat die Art und Weise geändert, in der ich mit der Installation neuer Systeme begonnen habe. Mit dem vollständigen Funktionsumfang von 5.0 / 5.1 ermöglichte eine neue Art der Flexibilität kreativere Designs. Wohlgemerkt, dies hat mit den erweiterten Funktionen auf virtuellen Maschinen Schritt gehalten, was die Anzahl der vCPUS und die Menge des Arbeitsspeichers anbelangt, die für einzelne VMs festgeschrieben werden können. Es könnten mehr Servertypen und Anwendungen virtualisiert werden als in der Vergangenheit. Dies ist richtig, als die Computerumgebungen anfingen, vollständig virtuell zu werden.

LVM ist schrecklich ...

Als die vollständige Hot-Add-Funktionalität auf VM-Ebene verfügbar und üblich war (2011-2012), arbeitete ich mit einer Firma zusammen, die sich bemühte, die Verfügbarkeit der VMs ihrer Kunden um jeden Preis zu gewährleisten ( dumm ). Also diese enthalten Online VMware CPU / RAM erhöht und riskant auf bestehenden VMDKs Ändern der Größe LVM - Platte. Die meisten Linux-Systeme in dieser Umgebung waren einzelne VMDK-Setups mit ext3-Partitionen auf LVM. Dies war schrecklich, da die LVM-Schicht die Komplexität und das unnötige Risiko für den Betrieb erhöht hat. Wenn beispielsweise in / usr nicht genügend Speicherplatz zur Verfügung steht, kann dies zu einer Reihe von Fehlentscheidungen führen, die letztendlich die Wiederherstellung eines Systems aus Sicherungskopien bedeuteten. Dies war teilweise prozess- und kulturbedingt, aber dennoch ...

Partition Snobismus ...

Ich habe diese Gelegenheit genutzt, um dies zu ändern. Ich bin ein bisschen wie ein Partitions-Snob in Linux und denke, dass Dateisysteme für Überwachungs- und Betriebsanforderungen getrennt werden sollten. Ich mag LVM auch nicht, besonders mit VMware und der Fähigkeit, das zu tun, wonach Sie fragen. Deshalb habe ich das Hinzufügen von VMDK-Dateien zu Partitionen erweitert, die möglicherweise größer werden könnten. / opt, / var, / home könnten bei Bedarf ihre eigenen virtuellen Maschinendateien abrufen. Und das wären rohe Scheiben. Manchmal war dies eine einfachere Methode, um bestimmte untergroße Partitionen im laufenden Betrieb zu erweitern.

Obamacare ...

Mit der Einbindung eines sehr hochkarätigen Clients wurde ich mit dem Entwurf der Linux-VM-Referenzvorlage beauftragt, die zum Erstellen ihrer äußerst sichtbaren Anwendungsumgebung verwendet werden sollte. Die Sicherheitsanforderungen der Anwendung erforderten einen eindeutigen Satz von Bereitstellungen. Daher arbeiteten die Entwickler daran, die nicht wachsenden Partitionen auf eine VMDK zu packen und dann für jede Bereitstellung, die Wachstumspotenzial oder spezifische Anforderungen hatte (Verschlüsselung, Auditing usw.) Letztendlich bestanden diese VMs aus 5 oder mehr VMDKs, boten jedoch die beste Flexibilität für zukünftige Größenänderungen und den Schutz von Daten.

Was ich heute mache ...

Heute ist mein allgemeines Design für Linux und traditionelle Dateisysteme das Betriebssystem auf einer dünnen VMDK (partitioniert) und diskrete VMDKs für alles andere. Ich werde nach Bedarf hinzufügen. Für erweiterte Dateisysteme wie ZFS ist es ein VMDK für das Betriebssystem und ein weiteres VMDK, das als ZFS-Zpool dient und in der Größe geändert, in zusätzliche ZFS-Dateisysteme umgewandelt usw. werden kann.

Sie haben in vielerlei Hinsicht Recht, ich kann das Argument sehen - es gibt jedoch ein Problem, das sich als schwierig erweisen könnte. Wenn Sie Ressourcenpools verwenden (und ich weiß, dass dies keine abscheulichen Dinge sind), können VMs mehr E / A-Zeit erhalten, wenn sie über mehr Festplatten verfügen. In Situationen mit extremen Ressourcenbeschränkungen kann eine VM mit zwei Festplatten doppelt so viel E / A-Ressourcen erhalten wie eine mit eine einzelne Festplatte. Dies mag für Sie kein Problem sein, aber ich dachte, ich würde darauf hinweisen.

Bearbeiten - oh und es würde das Knipsen auch etwas verlangsamen, aber auch das könnte kein Problem sein.

Als ich in einer bestimmten "großen Virtualisierungssoftware-Firma" in der Infrastruktur arbeitete, mussten wir oft das Dateisystem einer VM vergrößern. Wir haben damals ext3 / 4 verwendet.

Das Erhöhen der virtuellen Festplatte ist sehr einfach, das Auffinden der neuen Gerätegröße in einem Live-Betriebssystem ist relativ einfach (stöbern Sie in / sys), das Ändern der Größe des Live-Dateisystems ext3 / 4 war einfach, aber was immer unmöglich schien (live zu tun) war Größenänderung der Partition.

Sie mussten gparted verwenden oder die Partitionstabelle mit fdisk neu schreiben / in der Größe ändern - aber sie war immer vom Kernel gesperrt und erforderte einen Neustart, damit der Kernel das neue Layout aufnimmt (partprobe hat es auch nicht getan).

Ich habe viele Systeme auf LVM umgestellt und das Ändern der Größe von Dateisystemen wurde zu einer einfachen, beinahe angenehmen Erfahrung!

• Erhöhen Sie das Image der virtuellen Festplatte außerhalb der VM
• In der VM
  • Poke / sys zum erneuten Scannen der Datenträgermetriken (Echo "1"> / sys / class / scsi_device // device / rescan)
  • pvresize / dev / sdX (Größe des physischen Volumes in LVM ändern)
  • lvresize --extents + 100% FREE / dev / VG / lvolXX (Größe des logischen Volumes in LVM ändern)
  • resize2fs (Ändere die Größe des Dateisystems)

All dies kann sicher auf einem Live-System durchgeführt werden - und es ist kein Neustart erforderlich!

Warum nicht eine leere Platte? Es macht mich nervös - ich habe noch nicht das Gefühl, dass Bare Disks weit genug akzeptiert werden, aber ich denke, wir stehen vor einer viel größeren Akzeptanz. Es gab einen Thread auf der btrfs-Mailingliste, der damit zusammenhängt:

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

Aber eine leere Festplatte würde nur den Rescan und resize2fs benötigen.

Zusammenfassend sollten Sie Partitionstabellen vermeiden, wenn Sie können.

Während sich Ihre Frage wie geschrieben auf VMWare (ESXi) bezieht, möchte ich eine Situation hinzufügen, in der ich wieder Partitionstabellen verwendet habe, nachdem ich die gleiche Idee in KVM hatte.

Es stellte sich heraus, dass wenn Sie LVM-Volumes als Festplatten für VMs haben und eine LVM-Volume-Gruppe innerhalb der VM erstellen, ohne Partitionen zu verwenden (wobei die gesamte virtuelle Festplatte als PV verwendet wird), diese VG außerhalb der VM auf dem Hostcomputer sichtbar ist. Dies ist nicht der Fall, wenn Sie Partitionen als PV verwenden.

Zugegeben, es ist ein Eckfall, aber es lohnt sich zu überlegen, ob Sie ein solches Setup benötigen.

Ob dies besser ist oder nicht, hängt von Ihrem System ab.

Bei jedem Setup gibt es Vor- und Nachteile.

Die Hauptvorteile eines einzelnen Laufwerks sind jedoch folgende:

1. Einfachheit: Ein einzelnes Laufwerk verfügt über eine einzelne Datei, die problemlos verteilt und repliziert werden kann.
2. Hinweise zum Host-Betriebssystem: Eine einzelne Datei wird als einzelner Datenblock behandelt, und daher weiß das Host-Betriebssystem, dass sich alle Sequenzen des Gastcomputerzugriffs in dieser einen Datei befinden. Dies kann bei einigen Host-Betriebssystemkonfigurationen erreicht werden, indem einfach alle Laufwerk-Images in derselben Datei abgelegt werden. Dies muss jedoch nicht unbedingt der Fall sein.

Mehrfachantriebe bieten jedoch Vorteile.

1. Bare-Metal-Affinität / manueller Speicherort: Mit einem einzelnen Laufwerk sind Sie an eine einzelne Bare-Metal-Affinität des Laufwerks gebunden.
2. Größenbeschränkungen: Wenn in Ihrem System die Größe des Laufwerks oder der Dateien begrenzt ist, können Sie sie auf sehr großen Systemen treffen.
3. Nur-Lese-Datenträger für die Sicherheit: Dies ist der große Vorteil. Wenn Ihr Mastervolume für das Betriebssystem nur auf der VM-Seite gelesen werden kann, bietet dies erhebliche Sicherheitsvorteile, da im Wesentlichen verhindert wird, dass Programme innerhalb der VM das Basisbetriebssystem des Gastbetriebssystems bearbeiten können. Durch die Verwendung eines separaten Datenlaufwerks können Sie schreibgeschützte Laufwerke erstellen, die für Wartungs- und Aktualisierungszwecke schreibgeschützt gebootet werden können, ohne dass lediglich Reinraum-Vorlagendaten erforderlich sind. Auf diese Weise wird verhindert, dass wichtige Betriebssystemverzeichnisse innerhalb des Servers geändert werden.

Es gibt noch eine andere Option: Hängen Sie die Anwendungsdaten auf NFS-Volumes ein. Sie benötigen gute Filer (nicht alle NFS-Implementierungen sind gleich).

Wenn die NFS-Volumes voll sind, erweitern Sie das Volume, der Linux-Client sieht den zusätzlichen Speicherplatz sofort.

Ihre Anwendung und Ihr Anbieter müssen die Verwendung von NFS-Daten unterstützen, und Sie benötigen ein sorgfältiges NAS-Design. Dies ist jedoch bei jeder Speicherlösung für Ihre virtualisierte Umgebung der Fall.

Ein weiterer Pluspunkt für diesen Ansatz ist, dass das Sichern der Daten und das Erstellen von Test- / Entwicklungsumgebungen wirklich einfach ist, wenn Ihr Speicheranbieter über eine Snapshot- / Klontechnologie (wie zfs oder Netapp) verfügt.

Der Grund, warum Sie die Festplatte für einige Linux-Distributionen noch partitionieren müssen, ist die Tatsache, dass es einen Bootloader und alle dazugehörigen Legacy-Komponenten gibt, dh das emulierte BIOS. Dadurch wird es schwieriger, die Größe einer Festplatte zu ändern, und viele verwenden am Ende LVM oder eine andere ähnliche Funktion, die nicht sinnvoll ist.

Man kann einfach ein Dateisystem auf dem gesamten Volume erstellen und es mounten /, was mit einer sehr benutzerdefinierten (oder anpassbaren / nicht bewerteten) Linux-Distribution funktioniert. Als ich das letzte Mal mit Ubuntu 12.04 versuchte, wusste der Installer nicht, wie er damit umgehen sollte, da er die dumme Partitionstabelle und den ganzen Jazz installieren musste. Dies ist eines der Probleme von Allzweckverteilungen in der virtualisierten Welt.

Auf der anderen Seite kann man die Partitionierung tatsächlich zu einem weniger traditionellen Zweck machen , zum Beispiel haben ChromeOS und CoreOS zwei schreibgeschützte Root-Partitionen für System-Upgrades.

Ein Grund, der bisher nicht erwähnt wurde, ist, dass in einigen Infrastrukturen wie Google Compute die Festplatten-E / A-Leistung linear mit der Größe der Festplatte ansteigt . Mit anderen Worten, ein großes partitioniertes Laufwerk bietet eine bessere E / A-Leistung als mehrere kleine Laufwerke.

Beachten Sie jedoch, dass dies im Allgemeinen nicht der Fall ist. Wie von Chopper3 erwähnt, weisen mehrere Laufwerke am häufigsten eine bessere E / A-Leistung auf. Wenn alle Ihre virtuellen Laufwerke einem einzigen physischen Laufwerk zugeordnet sind, sollte es keinen Unterschied geben.

Meiner Erfahrung nach besteht der bessere Ansatz darin, 1 VMDK für das Betriebssystem zu verwenden, und ich partitioniere es normalerweise folgendermaßen:

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

Ich habe festgestellt, dass 8 GB für / ausreichen, da ich normalerweise eine minimale Linux-Distribution (~ 800 MB) + benötigte Software installiere. Protokolle werden auch in diese Partition geschrieben, aber wenn sie korrekt eingerichtet sind (eine Woche lang logrotieren) und an einen anderen Ort geliefert werden (syslog / elasticsearch), sind sie normalerweise kein Leckerbissen, um die Partition zu füllen.

Daten werden als ein anderes VMDK hinzugefügt, und ich formatiere das Dateisystem normalerweise direkt über die leere Festplatte (z. B. / dev / sdb). Auf diese Weise kann ich die Größe des Volumes in VmWare und direkt in der VM ändern, ohne dass eine erneute Partitionierung / Bereitstellung / Neustart erforderlich ist.

Ich partitioniere aus zwei Gründen:

1. Dokumentation - Ich hatte einmal einen "ausgebildeten" EMC-Administrator, der LUNs direkt unter mir stahl, weil sie undokumentiert waren und ihm nicht zugeordnet zu sein schienen und mitten in der Nacht für eine Oracle-Datenbank ausgelagert wurden, die plötzlich offline ging. Er hatte meine LUNs für ein anderes Volume für eine unabhängige App erneut bereitgestellt. Seitdem bin ich paranoid in Sachen Dokumentation.
2. Überprovisionierung meiner Festplatte. Mit Platten hält es Daten von den langsameren Zylindern fern und mit SSD verlängert es die Lebensdauer / MTBF.