Frage Linux auf VMware - warum Partitionierung?


Warum gibt es bei der Installation von Linux-VMs in einer virtualisierten Umgebung (in meinem Fall ESXi) zwingende Gründe, die Festplatten zu partitionieren (wenn ext4 verwendet wird), anstatt für jeden Bereitstellungspunkt separate Festplatten hinzuzufügen?

Der einzige, den ich sehen kann ist, dass es etwas einfacher ist zu sehen, ob Daten auf einer Platte mit z.B. fdisk.

Auf der anderen Seite kann ich einige gute Gründe dafür sehen nicht Verwenden von Partitionen (für andere als / boot, offensichtlich).

  • Viel einfacher, Festplatten zu erweitern. Es dient lediglich dazu, die Festplattengröße für die VM zu erhöhen (normalerweise im VCenter), anschließend das Gerät in der VM erneut zu scannen und die Größe des Dateisystems online zu ändern.
  • Keine Probleme mehr beim Ausrichten von Partitionen mit zugrunde liegenden LUNs.

Zu diesem Thema habe ich nicht viel gefunden. Habe ich etwas wichtiges verpasst?


45
2017-10-02 09:07


Ursprung


Oh, und ich wollte nur kommentieren, wie beeindruckt mich und einige der anderen 'High-Rep' Benutzer von SF mit Ihrer ersten Frage waren. Wir werden manchmal beschuldigt, neue Leute verprügelt zu haben, aber es ist wirklich nur so, dass viele neue Nutzer nicht lesen, worum es uns geht und was nicht - also dachte ich, ich sollte mich einfach bedanken, dass ich eine passende Frage gestellt habe gut geschrieben und überlegt :) - Chopper3
Ich habe zwei Bemerkungen: 1) VMWare ist kein Produkt, sondern eine Firma. VMWare ESXi wäre ein Produkt. 2) Ich würde diese Frage bearbeiten, um über virtualisierte Umgebungen im Allgemeinen zu sein, da dies für z.B. KVM, Xen und HyperV. - Sven♦
Vielen Dank. Und ich habe den Wortlaut etwas allgemein gehalten. - savoche
@savoche solltest du eine Antwort markieren. - ewwhite


Antworten:


Das ist eine interessante Frage ...

Ich glaube nicht, dass es eine definitive Antwort gibt, aber ich kann einen historischen Kontext dazu geben, wie sich die Best Practices im Zusammenhang mit diesem Thema im Laufe der Zeit verändert haben könnten.

Ich musste seit 2007 Tausende von Linux-VMs unterstützen, die in verschiedenen Umgebungen in VMware-Umgebungen bereitgestellt wurden. Mein Ansatz für die Bereitstellung hat sich weiterentwickelt, und ich hatte die einzigartige (manchmal unglücklich) Erfahrung mit dem Erben und Refactoring von Systemen anderer Ingenieure.

Die alten Tage...

Damals (2007) wurden meine frühen VMware-Systeme wie meine Bare-Metal-Systeme partitioniert. Auf der VMware-Seite nutzte ich geteilte 2 GB dicke Dateien, um die VM-Daten zu erfassen, und dachte nicht einmal über die Idee mehrerer VMDKs nach, denn ich war einfach nur froh, dass die Virtualisierung überhaupt funktionieren konnte!

Virtuelle Infrastruktur ...

Mit ESX 3.5 und den frühen Versionen von ESX / ESXi 4.x (2009-2011) habe ich Linux verwendet, das wie normal auf einer monolithischen Partition partitioniert ist Dick Bereitgestellte VMDK-Dateien. Die Vorspeicherung von Speicher zwang mich, ähnlich wie bei echter Hardware über Linux-Design nachzudenken. Ich erstellte 36GB, 72GB, 146GB VMDKs für das Betriebssystem, Partitionierung der üblichen /, / boot, / usr, / var, / tmp, dann Hinzufügen einer weiteren VMDK für die "Daten" oder "Wachstum" Partition (ob das / home, / opt oder etwas anwendungsspezifisches). Auch hier lag der "Sweet-Spot" bei den physikalischen Festplattengrößen in dieser Ära bei 146 GB. Da die Vorbelegung eine Voraussetzung war (es sei denn, NFS wurde verwendet), musste ich mit Platz sparsam umgehen.

Das Aufkommen von Thin Provisioning 

VMware hat bessere Funktionen entwickelt Thin Provisioning in späteren Versionen von ESXi 4.x, und dies änderte, wie ich neue Systeme zu installieren begann. Mit dem vollständigen Feature-Set, das in 5.0 / 5.1 hinzugefügt wurde, ermöglichte eine neue Art von Flexibilität mehr kreative Designs. Beachten Sie jedoch, dass dies mit den erweiterten Funktionen auf virtuellen Maschinen Schritt hielt, in Bezug darauf, wie viele vCPUS und wie viel RAM für einzelne VMs bereitgestellt werden konnte. Mehr Arten von Servern und Anwendungen könnten virtualisiert werden als in der Vergangenheit. Dies ist richtig, da Computerumgebungen damit begannen, vollständig virtuell zu werden.

LVM ist schrecklich ...

Zu der Zeit, als die volle Hot-Add-Funktionalität auf VM-Ebene vorhanden und üblich war (2011-2012), arbeitete ich mit einer Firma zusammen, die darum bemüht war, die Verfügbarkeit der VMs ihrer Kunden um jeden Preis aufrechtzuerhalten (blöd). Also das inklusive Online VMware CPU / RAM erhöht und riskant Größe der LVM-Festplatte auf vorhandenen VMDKs. Die meisten Linux-Systeme in dieser Umgebung waren einzelne VMDK-Setups mit ext3-Partitionen auf LVM. Das war schrecklich, weil die LVM-Ebene hinzugefügt wurde Komplexität und unnötiges Risiko zu Operationen. Wenn beispielsweise in / usr kein Platz mehr zur Verfügung steht, könnte dies zu einer Kette falscher Entscheidungen führen, die schließlich dazu führen, dass ein System aus Sicherungen wiederhergestellt wird ... Dies war teilweise prozess- und kulturbezogen, aber dennoch ...

Partition Snobismus ...

Ich habe diese Gelegenheit genutzt Versuchen um das zu ändern. Ich bin ein bisschen Partition-Snob in Linux und der Ansicht, dass Dateisysteme für Überwachungs- und Betriebsanforderungen getrennt sein sollten. Ich mag auch LVM nicht, vor allem nicht mit VMware und der Fähigkeit, das zu tun, wonach Sie fragen. Also habe ich das Hinzufügen von VMDK-Dateien zu Partitionen erweitert, die möglicherweise wachsen könnten. / opt, / var, / home könnte bei Bedarf eigene Dateien für virtuelle Maschinen abrufen. Und das wären rohe Festplatten. Manchmal war dies eine einfachere Methode, um bestimmte unterdimensionierte Partitionen im laufenden Betrieb zu erweitern.

Obamacare ...

Mit dem Onboarding eines sehr bekannter KundeIch wurde mit der Gestaltung der Linux VM Referenzvorlage beauftragt, mit der sie erstellt werden sollten äußerst sichtbare Anwendungsumgebung. Die Sicherheitsanforderungen der Anwendung benötigt a einzigartiger Satz von ReittierenAlso arbeitete ich mit den Entwicklern zusammen, um zu versuchen, die Nicht-Wachstum-Partitionen auf eine VMDK zu stopfen, und dann separate VMDKs für jedes Mount hinzuzufügen, das Wachstumspotenzial hatte oder bestimmte Anforderungen hatte (Verschlüsselung, Auditing usw.) VMs bestehen aus 5 oder mehr VMDKs, bieten jedoch die beste Flexibilität für die zukünftige Größenanpassung und den Schutz von Daten.

Was ich heute mache ...

Heute ist mein allgemeiner Entwurf für Linux und traditionelle Dateisysteme OS auf einer dünnen VMDK (partitioniert) und diskrete VMDKs für alles andere. Ich werde hot-hinzufügen wie nötig. Für erweiterte Dateisysteme wie ZFS ist es eine VMDK für das Betriebssystem und eine andere VMDK, die als ZFS-Zpool dient und in der Größe geändert werden kann, in zusätzliche ZFS-Dateisysteme geschnitten werden kann usw.


26
2017-10-02 10:29



Ich benutze Partitionen nicht für Root-Datenträger - c4f4t0r
Oh mein Gott, danke, dass du mich super alt fühlst. Für mich ist 2007 noch "fast aktuell". :-) - Brian Knoblauch
Sie haben viel Zeit verloren, um zu beschreiben, was Sie in der Vergangenheit getan haben (was heute irrelevant ist). Sie haben also vergessen zu erwähnen, dass Sie zusätzliche VMDKs partitionieren oder das Dateisystem direkt darüber legen. Was ist falsch mit LVM? Es hat mich nie im Stich gelassen, vielleicht haben Sie sich nicht wohl gefühlt, aber es ist eine großartige Ergänzung zu Linux (solange wir kein eigenes ZFS haben). - Jakov Sosic
Zusätzliche VMDKs, die als Mountpoint hinzugefügt werden, werden nicht partitioniert. - ewwhite
"Zurück in den Tag" war 2007? Ich war ein kostenloser Lizenznehmer bei IBM im Jahr 1999, als Version 1 ausgeliefert wurde. Ich bin ein VM-Dinosaurier: D (Wellen @ BrianKnoblauch). Laut deiner LVM-Kommentare klingt das so, als würdest du es im Kontext von Linux beurteilen. LVM ausgereifte Technologie im kommerziellen UNIX landet seit Jahren vor Linux. Wenn Sie die Top-End-Solaris / Sparc / EMC-Symmetrix verwaltet hätten, wäre Linux ein Schritt nach unten (und ist es immer noch in vielerlei Hinsicht). In der Zeit der kleinen Platten machte LVM Multi-Terabyte-Datenbanken handhabbar. Ich habe nie die Probleme gehabt, die du beschreibst, die sich wirklich wie Probleme von Menschen anhören, obwohl ich das sicherlich nachvollziehen kann. - codenheim


Du hast recht in vielerlei Hinsicht, 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 ich keine hasserfüllten Dinge mache), können VMs mehr IO-Zeit bekommen, wenn sie mehr Festplatten haben - in extremen Ressourcenbeschränkungen könnte eine VM mit zwei Festplatten doppelt so viele IO-Ressourcen bekommen wie eine mit eine einzelne Festplatte. Das mag kein Problem für Sie sein, aber ich dachte, ich würde darauf hinweisen.

Edit - oh, und es würde auch etwas langsamer schnappen, aber auch das ist kein Problem.


7
2017-10-02 09:10





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

Die virtuelle Festplatte zu vergrößern ist sehr einfach, die neue Gerätegröße in einem Live-Betriebssystem aufzunehmen ist relativ einfach (herumstochern in / sys), die Größe des ext3 / 4-Filesystems war einfach, aber was immer unmöglich schien (live) war Größe der Partition ändern.

Sie mussten gparted verwenden oder die Partitionstabelle mit fdisk neu schreiben / ändern - aber sie wurde immer vom Kernel gesperrt und erforderte einen Neustart, um den Kernel dazu zu bringen, das neue Layout aufzunehmen (partprobe hat es auch nicht gemacht).

Ich habe viele Systeme nach LVM verschoben und die Größenanpassung von Dateisystemen wurde zu einer einfachen, fast angenehmen Erfahrung!

  • Vergrößern Sie das Image des virtuellen Laufwerks außerhalb der VM
  • In der VM,
    • Poke / sys zum erneuten Scannen der Datenträgermetrik (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 (Größe des Dateisystems ändern)

All dies könnte sicher auf einem Live-System erfolgen - und kein Neustart erforderlich!

Warum nicht eine nackte Festplatte? Es macht mich nervös - ich glaube nicht, dass nackte Festplatten noch weit genug akzeptiert sind, aber ich denke, wir sind am Rande einer viel breiteren Akzeptanz. Es gab einen Thread auf der Btrfs-Mailingliste, der damit zusammenhängt:

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

Aber eine nackte Festplatte würde nur die Rescan und resize2fs benötigen.

Also, zusammenfassend, yeah, vermeiden Sie Partitionstabellen, wenn Sie können.


6
2017-10-02 19:07



Sie benötigen keinen Neustart, damit der Kernel die Partitionstabelle erneut lesen kann. Aber du würde müssen das Dateisystem auf dem skalierten Gerät aushängen (was schwierig ist, wenn es die Partition / ist). Abgesehen davon dienen die Partitionstabellen eher dokumentarischen Zwecken - jeder und sein Onkel würden ein fdisk -l (oder das entsprechende Äquivalent), um zu sehen, worum es bei einer unbekannten Festplatte geht. Wenn es nicht partitioniert ist, könnte es leicht mit "leer" verwechselt und überschrieben werden. Dies ist der Grund, warum ich Erstellen Sie immer eine Partitionstabelle für Festplatten. LVM ist jedoch böse. - the-wabbit
Das ist nicht meine Erfahrung auf diesen spezifischen VMs, obwohl es in der Vergangenheit auf anderen gearbeitet hat. Das Entfernen der fs hat das Schloss nicht freigegeben. Vielleicht war es nur Centos5, ich weiß nicht. Ich war ratlos. In einer Partitionswelt ist LVM großartig. In der neuen btrfs / zfs-Welt ist es veraltet. IMHO natürlich. - rrauenza
Es hat eine Weile gedauert, bis ich realisiert habe, dass du tatsächlich lvm in der VM benutzt hast ... Gibt es einen Grund, warum du LVM nicht auf dem Host verwendest und dem Gast einfach ein lv gibst, um es als Festplatte zu benutzen? Die Schritte zur Größenanpassung wären: Größe des Volumes im Host ändern, Suche auf Gast wiederholen, Größe von 2fs auf Gast ändern. - GnP
Ja, in der vm. Da dies unter esx ist, muss die virtuelle Festplatte eine vmdk-Datei sein. Ja, theoretisch hätten wir eine rohe Platte im Gast verwenden können. - rrauenza
Die Verwendung einer nackten Festplatte ist so viel einfacher - entfernt 2 von 5 Schritten, ohne LVM zu kennen. Die Größe eines FS in LVM zu ändern war riskant, obwohl es besser wird: LVM Gefahren und Vorbehalte. - RichVel


Während Ihre Frage in Bezug auf VMWare (ESXi) geschrieben wurde, möchte ich eine Situation hinzufügen, in der ich nach der gleichen Idee auf KVM wieder zur Verwendung von Partitionstabellen zurückgekehrt bin.

Es stellte sich heraus, dass, wenn Sie LVM-Volumes als Festplatten für VMs haben und eine LVM-Volumegruppe innerhalb der VM erstellen, ohne Partitionen zu verwenden (unter Verwendung der gesamten virtuellen Festplatte als PV), 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 eine Überlegung wert, wenn Sie ein solches Setup benötigen.


1
2017-10-02 10:10



Warum brauchen Sie eine VG auf einem LV in der VM? (Beachte, dass ich für LVM ziemlich neu bin, ich beurteile mich nicht, versuche nur, den Nutzen eines solchen Setups zu begreifen) - GnP
Sie können den LVM-Filter auf dem Host verwenden, um verschachtelte LVs herauszufiltern. - Mircea Vutcovici


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

Für jedes Setup gibt es Vor- und Nachteile.

Die Hauptvorteile eines einzelnen Laufwerks sind jedoch folgende:

  1. Einfachheit: Ein einzelnes Laufwerk verfügt über eine einzige Datei, die einfach verteilt und repliziert werden kann.
  2. Hinweise zum Host-Betriebssystem: Eine einzelne Datei wird als ein einzelner Datenblock behandelt, und daher weiß das Host-Betriebssystem, dass alle Sequenzen des Zugriffs auf den Gastcomputer in dieser einen Datei enthalten sind. Dies kann bei einigen Host-Betriebssystemkonfigurationen erreicht werden, indem einfach alle Laufwerksabbilder in dieselbe Datei platziert werden, aber dies muss nicht unbedingt der Fall sein.

Es gibt jedoch Vorteile für Multi-Laufwerk.

  1. Bare-Metal-Affinität / manueller Standort: Mit einem einzigen Laufwerk sind Sie an eine einzige Bare-Metal-Affinität des Laufwerks gebunden.
  2. Größenbeschränkungen: Wenn Ihr System Beschränkungen hinsichtlich der Größe des Laufwerks oder der Dateien hat, könnten Sie diese auf sehr großen Systemen treffen.
  3. Read-Only-Volumes für die Sicherheit: Das ist der große Vorteil. Wenn Ihr Master-Volume für das Betriebssystem nur auf der VM-Seite gelesen wird, bietet es wichtige Sicherheitsvorteile. Es blockiert im Wesentlichen die Fähigkeit von Programmen in der VM, das Basisbetriebssystem des Gasts zu bearbeiten. Mit einem separaten Datenlaufwerk können Sie schreibgeschützte Laufwerke erstellen, die für Wartungs- und Aktualisierungszwecke ohne Reinraum-Vorlagedaten gebootet werden können, wodurch die Änderung von wichtigen Betriebssystemverzeichnissen innerhalb des Servers verhindert wird.

1
2017-10-02 17:53



Mit Multidrive können Sie (zumindest auf ESXi) auch einige Disk-Dateien im unabhängigen Modus haben. Auf diese Weise können Sie vermeiden, z. temporäre Daten in Snapshots und Snap-basierten Backups. - savoche


Es gibt eine weitere Option: Mounten Sie die Anwendungsdaten auf NFS-Volumes. Sie benötigen gute Filer (nicht alle NFS-Implementierungen sind gleich).

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

Ihre Anwendung und Ihr Anbieter müssen die Daten auf NFS unterstützen, und Sie benötigen ein sorgfältiges NAS-Design, das Sie jedoch bei jeder Speicherlösung für Ihre virtualisierte Umgebung verwenden.

Ein weiterer Pluspunkt für diesen Ansatz ist, dass, wenn Ihr Storage-Anbieter über Snapshot- / Clone-Technologie (wie zfs oder Netapp) verfügt, die Daten gesichert werden und das Erstellen von Test- / Entwicklungsumgebungen sehr einfach ist.


1
2017-10-03 06:41





Der Grund, warum Sie immer noch die Partition für einige Linux-Distributionen partitionieren müssen, liegt an der Tatsache, dass es einen Bootloader und alle Legacy-Teile gibt, die dazu gehören, d. H. Emulierte BIOS. Dies macht es schwieriger, die Größe einer Platte zu ändern, und viele würden mit LVM oder einem ähnlichen Nicht-Sinn enden.

Man kann einfach ein Dateisystem auf dem gesamten Volume erstellen und es mounten /, die mit einer sehr benutzerdefinierten (oder anpassbaren / nicht-rechtmäßigen) Linux-Distribution funktionieren wird. Das letzte Mal, als ich das mit Ubuntu 12.04 probiert habe, wusste der Installer nicht, wie er damit umgehen sollte, da er seine dumme Partitionstabelle und den ganzen Jazz installieren musste. Dies ist eines der Probleme von Allzweckverteilungen in der virtualisierten Welt.

Auf der anderen Seite konnte man die Partitionierung zum Beispiel zu einem weniger traditionellen Gebrauch machen ChromeOS und CoreOS haben zwei schreibgeschützte Root-Partitionen für System-Upgrades.


0
2017-10-04 07:17





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

Beachten Sie, dass dies jedoch im Allgemeinen nicht der Fall ist. Wie von Chopper3 am häufigsten erwähnt, haben mehrere Laufwerke eine bessere IO-Leistung. Wenn schließlich alle Ihre virtuellen Laufwerke einem einzelnen physischen Laufwerk zugeordnet sind, sollte es keinen Unterschied geben.


0
2017-10-04 09:02





Nach meiner Erfahrung ist ein besserer Ansatz, 1 VMDK für OS zu verwenden, und ich partitioniere es normalerweise auf folgende Weise:

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

Ich habe herausgefunden, dass 8GB für / genug sind, weil ich normalerweise eine minimale Linux-Distribution (~ 800 MB) + Software, die ich brauche, installiere. Protokolle gehen auch auf diese Partition, aber wenn sie richtig eingerichtet (eine Woche lang logrotate) und an anderer Stelle (syslog / elasticsearch) versendet werden, sind sie normalerweise kein Leckerbissen, um die Partition zu füllen.

Daten werden als eine andere VMDK hinzugefügt, und ich formatiere das Dateisystem normalerweise direkt über eine leere Platte (zB. / Dev / sdb). Dadurch kann ich die Größe des Volumes in VmWare ändern und die Größe direkt in der VM ändern, ohne dass die Partition neu partitioniert / umount / reboot werden muss.


0
2017-10-04 11:00



Ich mag, wie Sie Ihren Swap nach dem / boot spezifisch partitioniert haben, etwas, das ich gerade erst herausgefunden habe (2008 oder so). Wenn man nur ein altes, aufgeblähtes Kernel-Image herumfährt, streckt sich die Größe von bescheidenen / boot-Teilen und die Zufuhr von sda2 zu / boot gibt oft genug Platz. Wenn es dort ist, wo es ist, bedeutet dies keine Verlagerung der PV-Wurzel, und das spart eine knifflige Operation, die manchmal aus der Ferne durchgeführt werden muss. :-) - user2066657


Ich partitioniere aus zwei Gründen:

  1. Dokumentation - Ich hatte einmal einen "geschulten" EMC-Administrator, der LUNs direkt unter mir stiehlt, weil sie undokumentiert waren und ihm offenbar nicht zugeteilt waren, und mitten in der Nacht wurde nach einer Oracle-Datenbank gesucht, die plötzlich offline ging. Er hatte meine LUNs erneut für einen anderen Datenträger für eine nicht verwandte App bereitgestellt. Seitdem bin ich paranoid über Dokumentation.
  2. Übermäßige Bereitstellung meiner Festplatte Mit Platten hält es Daten von den langsameren Zylindern und mit SSD verlängert es die Lebensdauer / MTBF.

0
2017-10-06 05:21