Vraag Linux op VMware - waarom partitionering gebruiken?


Als ik Linux VM's installeer in een gevirtualiseerde omgeving (ESXi in mijn geval), zijn er dan ook dwingende redenen om de schijven te partitioneren (bij gebruik van ext4) in plaats van alleen maar afzonderlijke schijven toe te voegen voor elk koppelpunt?

De enige die ik kan zien is dat het het wat gemakkelijker maakt om te zien of er gegevens aanwezig zijn op een schijf met b.v. fdisk.

Aan de andere kant zie ik enkele goede redenen voor niet met behulp van partities (voor andere dan / boot, uiteraard).

  • Veel eenvoudiger om schijven uit te breiden. Het is gewoon om de schijfgrootte voor de VM te vergroten (meestal in VCenter), vervolgens het apparaat opnieuw te scannen in de VM en het formaat van het bestandssysteem online aan te passen.
  • Geen problemen meer met het afstemmen van partities met onderliggende LUN's.

Ik heb hier niet veel over gevonden. Heb ik iets belangrijks gemist?


45
2017-10-02 09:07


oorsprong


Oh en ik wilde alleen maar zeggen hoe onder de indruk was van mezelf en een aantal van de andere 'high-rep' gebruikers van SF waren met je eerste vraag. We worden er soms van beschuldigd nieuwe jongens te verslaan, maar het is gewoon zo dat veel nieuwe gebruikers niet lezen waar we over gaan en wat we niet zijn - dus ik dacht dat ik gewoon moest bedanken voor het stellen van een passende vraag in een goed geschreven en overwogen manier :) - Chopper3
Ik heb echter twee opmerkingen: 1) VMWare is geen product maar een bedrijf. VMWare ESXi zou een product zijn. 2) Ik zou deze vraag willen aanpassen om over gevirtualiseerde omgevingen in het algemeen te gaan, aangezien dit even relevant is voor bijvoorbeeld KVM, Xen en HyperV. - Sven♦
Bedankt. En ik heb de bewoordingen iets algemener bewerkt. - savoche
@savoche je moet een antwoord markeren. - ewwhite


antwoorden:


Dit is een interessante vraag ...

Ik denk niet dat er een definitief antwoord is, maar ik kan een historische context schetsen over hoe de beste praktijken rond dit onderwerp in de loop van de tijd kunnen zijn veranderd.

Ik heb duizenden Linux-VM's moeten ondersteunen die sinds 2007 in verschillende vormen zijn geïmplementeerd in VMware-omgevingen. Mijn benadering van implementatie is geëvolueerd en ik heb de unieke (soms ongelukkig) ervaring met overerf- en revisiesystemen die door andere ingenieurs zijn gebouwd.

De oude tijd...

Vroeger (2007) waren mijn vroege VMware-systemen net als mijn blanke metalen systemen gepartitioneerd. Wat VMware betreft, gebruikte ik gesplitste 2 GB dikke bestanden om de gegevens van de VM te bevatten, en dacht ik niet eens na over het begrip meerdere VMDK's, omdat ik gewoon blij was dat virtualisatie zelfs zou kunnen werken!

Virtuele infrastructuur ...

Door ESX 3.5 en de vroege ESX / ESXi 4.x-releases (2009-2011), gebruikte ik Linux, gepartitioneerd als normaal bovenop monolithisch Dik voorziene VMDK-bestanden. Als ik opslag vooraf moest toewijzen, moest ik op dezelfde manier over Linux-ontwerp denken als met echte hardware. Ik was bezig met het maken van 36GB, 72GB, 146GB VMDK's voor het besturingssysteem, partitioneren van de gebruikelijke /, / boot, / usr, / var, / tmp, en dan nog een VMDK toevoegen voor de "data" of "groei" partitie (of dat nu is / thuis, / opt of iets applicatiespecifiek). Wederom was de sweet-spot in fysieke harde schijven in dit tijdperk 146 GB, en aangezien voorallocatie een vereiste was (tenzij ik NFS gebruikte), moest ik voorzichtig zijn met ruimte.

De komst van thin provisioning 

VMware heeft betere functies ontwikkeld Dunne voorzieningen in latere releases van ESXi 4.x, en dit veranderde de manier waarop ik begon met het installeren van nieuwe systemen. Met de volledige functieset toegevoegd in 5.0 / 5.1, stond een nieuw type flexibiliteit meer creatieve ontwerpen toe. Let op, dit was gelijke tred houden met de toegenomen mogelijkheden op virtuele machines, in termen van hoeveel vCPUS en hoeveel RAM zou kunnen worden toegewezen aan individuele VM's. Meer soorten servers en applicaties kunnen worden gevirtualiseerd dan in het verleden. Dit klopt, omdat computeromgevingen volledig virtueel begonnen te worden.

LVM is vreselijk ...

Tegen de tijd dat de volledige hot-add-functionaliteit op het VM-niveau aanwezig was en gebruikelijk (2011-2012), werkte ik met een bedrijf dat ernaar streefde de uptime voor de VM's van zijn klanten te handhaven tegen elke prijs (dom). Dus dit omvatte online VMware CPU / RAM-verhogingen en riskant LVM-schijfformaat wijzigen op bestaande VMDK's. De meeste Linux-systemen in deze omgeving waren afzonderlijke VMDK-setups met ext3-partities bovenop LVM. Dit was verschrikkelijk omdat de LVM-laag toegevoegd complexiteit en onnodig risico operaties. Het opraken van de ruimte in / usr kan bijvoorbeeld resulteren in een keten van slechte beslissingen die uiteindelijk betekende dat een systeem moest worden hersteld van back-ups ... Dit was deels proces- en cultuurgerelateerd, maar toch ...

Partitie snobbery ...

Ik maakte van deze gelegenheid gebruik om proberen om dit te veranderen. Ik ben een beetje een scheidingswandtypewarmtewisselaar snob in Linux en zijn van mening dat bestandssystemen gescheiden moeten worden voor monitoring en operationele behoeften. Ik heb ook een hekel aan LVM, vooral met VMware en het vermogen om te doen waar je om vraagt. Dus ik heb de toevoeging van VMDK-bestanden uitgebreid naar partities die mogelijk kunnen groeien. / opt, / var, / home kunnen zo nodig hun eigen virtuele machinebestanden krijgen. En dat zouden onbewerkte schijven zijn. Soms was dit een eenvoudiger methode om een ​​specifieke ondermaatse partitie uit te breiden.

Obamacare ...

Met het aan boord gaan van een zeer high-profile klant, Ik was belast met het ontwerp van de Linux VM-referentiesjabloon die zou worden gebruikt om hun te maken uiterst zichtbare applicatieomgeving. De beveiligingsvereisten van de applicatie vereisten een unieke set mounts, dus werkten we samen met de ontwikkelaars om de non-growth-partities naar één VMDK te proppen en voegden vervolgens afzonderlijke VMDK's toe voor elke mount die groeipotentieel had of specifieke vereisten had (encryptie, auditing, enz.). Uiteindelijk zijn deze dus VM's bestonden uit 5 of meer VMDK's, maar leverden de beste flexibiliteit voor toekomstige aanpassing en bescherming van gegevens.

Wat ik vandaag doe ...

Tegenwoordig is mijn algemene ontwerp voor Linux en traditionele bestandssystemen OS op één dunne VMDK (gepartitioneerd) en discrete VMDK's voor al het andere. Ik zal zo nodig heet toevoegen. Voor geavanceerde bestandssystemen zoals ZFS is het één VMDK voor het besturingssysteem en een andere VMDK die als een ZFS-zpool fungeert en kan worden aangepast, in andere ZFS-bestandssystemen gesneden, enz.


26
2017-10-02 10:29



ik gebruik geen partities in plaats van root-schijven - c4f4t0r
Oh geez, bedankt dat je me super oud hebt gemaakt. Voor mij is 2007 nog steeds "bijna actueel". :-) - Brian Knoblauch
Je hebt veel tijd verloren aan het beschrijven van wat je in het verleden hebt gedaan (wat niet relevant is voor vandaag), dus je vergat te vermelden dat je extra VMDK's partitioneert of het bestandssysteem er direct bovenop legt. Tussen haakjes, wat is er mis met LVM? Het heeft me nooit in de steek gelaten, misschien voelde je je niet op je gemak bij het gebruik ervan, maar het is een geweldige toevoeging aan Linux (zolang we geen native ZFS hebben). - Jakov Sosic
Extra VMDK's die als mountpoint worden toegevoegd, worden niet gepartitioneerd. - ewwhite
"Terug in de dag" was 2007? Ik was een gratis licentie-ontvanger bij IBM in 1999 toen versie 1 werd verzonden. Ik ben een VM-dinosaurus: D (waves @BrianKnoblauch). Volgens uw LVM-opmerkingen, klinkt het alsof u het beoordeelt in de context van Linux. LVM volwassen technologie in commercieel UNIX-land al jaren voor Linux. Als je top-end Solaris / Sparc / EMC Symmetrix had beheerd, was Linux een stap naar beneden (en nog steeds op veel manieren). In de dagen van kleine schijven maakte LVM databases met meerdere terabytes beheersbaar. Ik heb nooit de problemen gehad die je beschrijft, die echt als mensenproblemen klinken, hoewel ik me wel kan verhouden. - codenheim


Je hebt in veel opzichten gelijk, ik kan het argument zien - er is echter één probleem dat lastig kan zijn. Als u Resource Pools gebruikt (en ik weet dat ik het niet doe, haatdragende dingen), kunnen VM's meer IO-tijd krijgen als ze meer schijven hebben. In extreme beperkte bronnen kan een VM met twee schijven tweemaal zoveel IO-resources krijgen als één met een enkele schijf. Dit is misschien geen probleem voor u, maar ik dacht dat ik het zou opschrijven.

Bewerken - oh en het zou ook iets langzamer gaan klikken, maar dat is misschien geen probleem.


7
2017-10-02 09:10





Toen ik in een infrastructuur werkte bij een bepaald "groot bedrijf voor virtualisatiesoftware", moesten we vaak het bestandsysteem van een vm vergroten. We gebruikten toen ext3 / 4.

Het verhogen van de virtuele schijf is erg eenvoudig, het oppikken van de nieuwe apparaatgrootte in een live OS is relatief eenvoudig (rondneuzen in / sys), het formaat van het ext3 / 4 bestandssysteem was eenvoudig, maar wat altijd leek onmogelijk (om live te doen) was het formaat van de partitie wijzigen.

Je moest gparted gebruiken of de grootte van de partitietabel herschreven / herschalen met fdisk - maar deze was altijd vergrendeld door de kernel en moest opnieuw worden opgestart om de kernel de nieuwe lay-out te laten ophalen (partprobe deed het ook niet).

Ik verhuisde veel systemen naar LVM en het resizen van bestandssystemen werd een gemakkelijke, bijna aangename ervaring!

  • Vergroot de afbeelding van de virtuele schijf buiten de VM
  • In de VM,
    • Poke / sys om de schijfstatistieken opnieuw te scannen (echo "1"> / sys / class / scsi_device // device / rescan)
    • pvresize / dev / sdX (formaat van het fysieke volume in LVM wijzigen)
    • lvresize --extents + 100% GRATIS / dev / VG / lvolXX (formaat van het logische volume in LVM wijzigen)
    • resize2fs (formaat van het bestandssysteem wijzigen)

Dit alles kan veilig worden gedaan op een live-systeem - en geen opnieuw opstarten vereist!

Waarom geen blote schijf? Ik word er nerveus van - ik heb niet het gevoel dat blote schijven al voldoende geaccepteerd zijn, maar ik denk dat we op het punt staan ​​om veel breder geaccepteerd te worden. Er was een thread op de btrfs-mailinglijst die hiermee verband houdt:

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

Maar een kale schijf zou alleen de rescan en resize2fs nodig hebben.

Dus, kort samengevat, ja, vermijd zo mogelijk partitietabellen.


6
2017-10-02 19:07



U hoeft niet opnieuw te worden opgestart om de kernel de partitietabel opnieuw te laten lezen. Maar jij zou moet het bestandssysteem (de bestanden) op het verkleinde apparaat ontkoppelen (wat lastig is als het de / partitie is). Anders dan die partitietabellen zijn eerder dienende documentaire doeleinden - iedereen en zijn oom zouden een fdisk -l (of het overeenkomstige equivalent) om te zien waar een onbekende schijf over gaat. Als het niet gepartitioneerd is, kan het gemakkelijk worden aangezien voor "leeg" en overschreven. Dit is de reden waarom ik maak altijd een partitietabel voor schijven. LVM is echter slecht. - the-wabbit
Dat is niet mijn ervaring met deze specifieke VM's, hoewel het in het verleden op anderen heeft gewerkt. Het ontgrendelen van de fs heeft het slot niet vrijgegeven. Misschien was het gewoon Centos5, ik weet het niet. Ik was stumped. In een partitiewereld is LVM geweldig. In de nieuwe btrfs / zfs-wereld is het verouderd. IMHO, natuurlijk. - rrauenza
Het duurde even voor ik besefte dat je lvm daadwerkelijk in de VM gebruikte ... Is er een reden waarom je LVM niet op de host gebruikt en de gast eenvoudig een lv geeft om als schijf te gebruiken? De stappen voor het wijzigen van de grootte zijn: formaat van het volume wijzigen in host, opnieuw scannen op gast, resize2fs wijzigen op gast. - GnP
Ja, binnen de vm. Aangezien dit onder esx is, moet de virtuele schijf een vmdk-bestand zijn. Ja, in theorie hadden we een onbewerkte schijf in de gast kunnen gebruiken. - rrauenza
Het gebruik van een kale schijf is zoveel eenvoudiger - verwijdert 2 stappen uit 5, zonder LVM te hoeven kennen. Het wijzigen van een FS in LVM is riskant, hoewel het steeds beter wordt: LVM-gevaren en kanttekeningen. - RichVel


Hoewel uw vraag zoals geschreven over VMWare (ESXi) gaat, zou ik een situatie willen toevoegen waarin ik terugging naar het gebruik van partitietabellen nadat ik hetzelfde idee had op KVM.

Het bleek dat als je LVM-volumes als schijven voor VM's hebt en een LVM-volumegroep binnen de VM maakt zonder partities te gebruiken (met gebruik van de hele virtuele schijf als PV), deze VG zichtbaar zal zijn buiten de VM op de hostcomputer. Dit is niet het geval als u partities als PV gebruikt.

Toegegeven, het is een hoekgeval maar het is het overwegen waard als je zo'n opstelling nodig hebt.


1
2017-10-02 10:10



Waarom zou je een VG op een LV binnen de VM nodig hebben? (merk op dat ik vrij nieuw ben voor LVM, ik beoordeel niet wat je wilt, alleen probeer het gebruik van een dergelijke setup te begrijpen) - GnP
U zou LVM-filter op host kunnen gebruiken om genestelde LV's te filteren. - Mircea Vutcovici


Of het beter is om dit te doen of niet hangt af van uw systeem.

Er zijn voor- en nadelen van elke opstelling.

De belangrijkste voordelen van een enkele schijf zijn echter:

  1. Eenvoud: een enkele schijf heeft één bestand, dat gemakkelijk kan worden gedistribueerd en gerepliceerd.
  2. Cues naar het host-besturingssysteem: een enkel bestand zal worden behandeld als een enkel datablok, en daarom zal het host-besturingssysteem weten dat sequenties van gastmachinetoegang zich allemaal in dat ene bestand bevinden. Dit kan worden bereikt op sommige OS-configuraties door simpelweg alle schijfafbeeldingen in hetzelfde bestand te plaatsen, maar dit hoeft niet noodzakelijk het geval te zijn.

Er zijn echter voordelen aan multi-drive.

  1. Kale metaalaffiniteit / handmatige locatie: met een enkele schijf bent u vergrendeld op een enkele kale metaalaffiniteit van de omvormer.
  2. Grootte beperkingen: als uw systeem limieten heeft op de grootte van het station of op bestanden, kunt u ze op zeer grote systemen raken.
  3. Alleen-lezen volumes voor beveiliging: dit is het grote voordeel. Als uw hoofdvolume voor het besturingssysteem alleen aan de VM-kant wordt gelezen, biedt dit belangrijke beveiligingsvoordelen, waardoor de mogelijkheid van programma's in de VM om het basis-besturingssysteem van de gast te bewerken, vrijwel volledig wordt geblokkeerd. Met behulp van een afzonderlijke gegevensschijf kunt u alleen-lezen schijven maken, die kunnen worden opgestart voor onderhoud en updates, zonder alleen cleanroom-sjabloongegevens, waardoor wijziging van vitale OS-mappen helemaal niet mogelijk is binnen de server.

1
2017-10-02 17:53



Multi-drive laat je ook (op ESXi tenminste) een aantal schijfbestanden in de onafhankelijke modus hebben. Op die manier kunt u voorkomen dat bijvoorbeeld b. tijdelijke gegevens in snaps en snap-gebaseerde back-ups. - savoche


er is nog een andere optie: mount de applicatie data op NFS volumes. U hebt goede filters nodig (niet alle NFS-implementaties zijn hetzelfde).

Wanneer de NFS-volumes vol raken, vergroot u het volume, de linux-client ziet meteen de extra ruimte.

Uw applicatie en leverancier moeten de gegevens van NFS ondersteunen en u hebt een zorgvuldig NAS-ontwerp nodig, maar dat doet u met elke opslagoplossing voor uw gevirtualiseerde omgeving.

Een ander bonuspunt voor deze aanpak is dat als uw opslagleverancier snapshotting / kloningstechnologie (zoals zfs of Netapp) heeft, de back-up van de gegevens ondersteunt en het maken van test / dev-omgevingen echt gemakkelijk is.


1
2017-10-03 06:41





De reden waarom je nog steeds de schijf moet partitioneren voor sommige Linux-distributies is te wijten aan het feit dat er een bootloader en alle oude stukken bij hoort, d.w.z. geëmuleerde BIOS. Dit maakt het moeilijker om het formaat van een schijf te wijzigen en veel zouden eindigen met het gebruik van LVM of een andere soortgelijke niet-sense.

Men kan eenvoudig een bestandssysteem maken op het hele volume en het opwaarderen /, wat zal werken met een zeer aangepaste (of aanpasbare / niet-eigenzinnige) Linux-distributie. De laatste keer dat ik dit met Ubuntu 12.04 probeerde, wist het installatieprogramma niet hoe het moest worden aangepakt, omdat het hun stomme partitietabel en alle jazz moest installeren. Dit is een van de problemen met distributies voor algemene doeleinden in de gevirtualiseerde wereld.

Aan de andere kant kan men de partitionering zelfs op een minder traditioneel gebruik zetten, bijvoorbeeld ChromeOS en CoreOS heb twee alleen-lezen root partities voor systeemupgrades.


0
2017-10-04 07:17





Een reden die tot nu toe niet genoemd is, is dat in sommige infrastructuren zoals Google Compute, de IO-prestaties van schijven nemen lineair toe met de grootte van de schijf. Met andere woorden: een grote gepartitioneerde schijfeenheid heeft betere IO-prestaties dan meerdere kleine schijven.

Merk op dat dit over het algemeen echter niet het geval is. Zoals vermeld door Chopper3 zullen meestal meerdere drives betere IO-prestaties hebben. Als uiteindelijk al uw virtuele schijven zijn toegewezen aan één fysieke schijf, zou er geen verschil moeten zijn.


0
2017-10-04 09:02





In mijn ervaring is een betere aanpak om 1 VMDK voor OS te gebruiken en ik partitioneer het meestal op de volgende manier:

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

Ik heb vastgesteld dat 8GBs voldoende is voor /, omdat ik meestal minimale Linux-distributie (~ 800MB) + software installeer die ik nodig heb. Logboeken gaan ook naar die partitie, maar als ze correct zijn ingesteld (logrotate voor een week) en elders worden verzonden (syslog / elasticsearch), vormen ze meestal geen traktatie om de partitie op te vullen.

Gegevens worden toegevoegd als een andere VMDK, en ik formatteer het bestandssysteem meestal direct op blote schijf (bijv. / Dev / sdb). Hierdoor kan ik het formaat van het volume in VmWare wijzigen en het rechtstreeks in VM wijzigen zonder te moeten herpartiëren / opstarten / rebooten.


0
2017-10-04 11:00



Ik vind het leuk hoe je je ruil specifiek hebt gepartitioneerd na de / boot, iets wat ik pas sinds kort heb uitgedacht (2008 of zo). Als je zelfs maar één oude opgeblazen kernelafbeelding rondhoudt, zorgen de bescheiden / opstartonderdelen ervoor dat het uitsteken van sda2 naar / boot vaak genoeg ruimte biedt. Het hebben van waar het is betekent geen verplaatsing van de PV-houdende root, en dat bespaart een lastige operatie die soms op afstand moet worden gedaan. :-) - user2066657


Ik partitioneer om twee redenen:

  1. Documentatie - Ik heb eens een "getrainde" EMC-beheerder gestolen LUN's recht onder mij vandaan omdat ze niet-gedocumenteerd waren en hem niet toegewezen leken te zijn en midden in de nacht werd opgeroepen voor een Oracle-database die plotseling offline ging. Hij had mijn LUN's opnieuw ingericht voor een ander deel voor een niet-gerelateerde app. Sindsdien ben ik paranoïde over documentatie.
  2. Over-provisioning van mijn schijf. Met schotels houdt het gegevens van de langzamere cilinders en met SSD verlengt dit de levensduur / MTBF.

0
2017-10-06 05:21