Linux su VMware: perché usare il partizionamento?


46

Quando si installano VM Linux in un ambiente virtualizzato (nel mio caso ESXi), ci sono motivi validi per partizionare i dischi (quando si usa ext4) piuttosto che aggiungere solo dischi separati per ciascun punto di montaggio?

L'unico che posso vedere è che rende un po 'più facile vedere se ci sono dati presenti su un disco con es. Fdisk.

D'altra parte, posso vedere alcuni buoni motivi per non usare le partizioni (per altro che / boot, ovviamente).

  • Estendere i dischi molto più facilmente. È solo per aumentare le dimensioni del disco per la macchina virtuale (in genere in VCenter), quindi eseguire nuovamente la scansione del dispositivo nella macchina virtuale e ridimensionare il file system online.
  • Niente più problemi con l'allineamento delle partizioni con i LUN sottostanti.

Non ho trovato molto su questo argomento in giro. Ho perso qualcosa di importante?


16
Oh, e volevo solo commentare quanto sono rimasto colpito da me e da alcuni degli altri utenti "ad alta reputazione" di SF con la tua prima domanda. A volte siamo accusati di aver picchiato nuovi ragazzi, ma è davvero solo che molti nuovi utenti non leggono di cosa stiamo parlando e cosa non siamo - quindi ho pensato di dover dire grazie per aver posto una domanda appropriata in un modo ben scritto e considerato :)
Chopper3

5
Ho due osservazioni però: 1) VMWare non è un prodotto ma un'azienda. VMWare ESXi sarebbe un prodotto. 2) Modificherei questa domanda in modo da riguardare gli ambienti virtualizzati in generale, poiché questo è ugualmente rilevante per es. KVM, Xen e HyperV.
Sven

1
Grazie. E ho modificato il testo per renderlo un po 'più generale.
savoche,

@savoche dovresti segnare una risposta.
ewwhite,

Risposte:


27

Questa è una domanda interessante ...

Non credo che ci sia una risposta definitiva, ma posso fornire un contesto storico su come le migliori pratiche relative a questo argomento possano essere cambiate nel tempo.

Ho dovuto supportare migliaia di VM Linux distribuite in varie forme in ambienti VMware dal 2007. Il mio approccio alla distribuzione si è evoluto e ho avuto l' esperienza unica (a volte sfortunata ) di ereditare e refactoring sistemi creati da altri ingegneri.

I vecchi tempi...

Nel passato (2007), i miei primi sistemi VMware erano partizionati proprio come i miei sistemi bare metal. Sul lato VMware, stavo usando file spessi da 2 GB per comprendere i dati della VM e non pensavo nemmeno al concetto di più VMDK, perché ero solo felice che la virtualizzazione potesse persino funzionare!

Infrastruttura virtuale ...

Con ESX 3.5 e le prime versioni di ESX / ESXi 4.x (2009-2011), stavo usando Linux, partizionato come normale in cima a file VMDK con provisioning thick monolitici . La necessità di preallocare lo spazio di archiviazione mi ha costretto a pensare al design di Linux in un modo simile a quello che farei con l'hardware reale. Stavo creando VMDK da 36 GB, 72 GB, 146 GB per il sistema operativo, partizionando il solito /, / boot, / usr, / var, / tmp, quindi aggiungendo un altro VMDK per la partizione "dati" o "crescita" (indipendentemente dal fatto che sia / home, / opt o qualcosa di specifico per l'applicazione). Ancora una volta, il punto debole nelle dimensioni del disco rigido fisico durante questa era era di 146 GB, e poiché il preallocazione era un requisito (a meno che non si utilizzasse NFS), dovevo essere prudente con lo spazio.

L'avvento del thin provisioning

VMware ha sviluppato funzionalità migliori per il thin provisioning nelle versioni successive di ESXi 4.x e questo ha cambiato il modo in cui ho iniziato a installare nuovi sistemi. Con l'insieme completo di funzionalità aggiunto in 5.0 / 5.1, un nuovo tipo di flessibilità ha consentito progetti più creativi. Intendiamoci, questo stava tenendo il passo con le maggiori capacità sulle macchine virtuali, in termini di quanti vCPUS e quanta RAM poteva essere impegnata nelle singole VM. È possibile virtualizzare più tipi di server e applicazioni rispetto al passato. Questo è vero poiché gli ambienti informatici stavano iniziando a diventare completamente virtuali.

LVM è terribile ...

Quando la funzionalità di hot-add completa a livello di VM era attiva e comune (2011-2012), stavo lavorando con un'azienda che si sforzava di mantenere il tempo di attività delle VM dei propri clienti a qualsiasi costo ( stupido ). Quindi questo includeva aumenti della CPU / RAM VMware online e il ridimensionamento del disco LVM rischioso su VMDK esistenti. La maggior parte dei sistemi Linux in questo ambiente erano singole configurazioni VMDK con partizioni ext3 su LVM. Ciò è stato terribile perché il livello LVM ha aggiunto complessità e rischi inutili alle operazioni. A corto di spazio in / usr, ad esempio, potrebbe tradursi in una catena di decisioni sbagliate che alla fine significava ripristinare un sistema dai backup ... Ciò era parzialmente legato al processo e alla cultura, ma comunque ...

Lo snobismo della partizione ...

Ho colto l'occasione per provare a cambiarlo. Sono un po ' snob in Linux e sento che i filesystem dovrebbero essere separati per esigenze di monitoraggio e operative. Inoltre, non mi piace LVM, specialmente con VMware e la capacità di fare ciò di cui stai chiedendo. Quindi ho ampliato l'aggiunta dei file VMDK alle partizioni che potrebbero potenzialmente crescere. / opt, / var, / home potrebbe ottenere i propri file di macchine virtuali, se necessario. E quelli sarebbero dischi grezzi. A volte questo era un metodo più semplice per espandere al volo una particolare partizione sottodimensionata.

Obamacare ...

Con l'onboarding di un client di alto profilo , mi è stato affidato il compito di progettare il modello di riferimento di VM Linux che sarebbe stato usato per creare il loro ambiente applicativo estremamente visibile. I requisiti di sicurezza dell'applicazione richiedevano un set unico di montaggi , quindi hanno collaborato con gli sviluppatori per provare a stipare le partizioni di non crescita su un VMDK e quindi aggiungere VMDK separati per ogni mount che aveva un potenziale di crescita o che aveva requisiti specifici (crittografia, auditing, ecc.) Quindi, alla fine, queste VM erano composte da 5 o più VMDK, ma offrivano la migliore flessibilità per il futuro ridimensionamento e protezione dei dati.

Cosa faccio oggi ...

Oggi, il mio progetto generale per Linux e filesystem tradizionali è il sistema operativo su un VMDK sottile (partizionato) e VMDK discreti per qualsiasi altra cosa. Aggiungerò a caldo se necessario. Per i filesystem avanzati come ZFS, è un VMDK per il sistema operativo e un altro VMDK che funge da zpool ZFS e può essere ridimensionato, scolpito in file system ZFS aggiuntivi, ecc.


2
Oh cavolo, grazie per avermi fatto sentire molto vecchio. Per me il 2007 è ancora "quasi attuale". :-)
Brian Knoblauch,

1
I VMDK aggiuntivi aggiunti come mountpoint non vengono partizionati.
ewwhite,

1
Ogni tecnologia ha i suoi limiti e nulla in quella pagina supporta la tua affermazione che LVM è terribile. Ti consiglierei di modificare quella parte della tua risposta, perché è più un FUD che un'informazione benefica. PS. scusate se qualcuno dei miei commenti è sembrato duro, io scrivo tra un lavoro reale e quindi non penso spesso a come le mie parole possano suonare agli altri.
Jakov Sosic,

5
"Back in the day" era il 2007? Ero un destinatario di licenza gratuito presso IBM nel 1999 quando la versione 1 è stata spedita. Sono un dinosauro VM: D (waves @BrianKnoblauch). Secondo i tuoi commenti LVM, sembra che tu lo stia giudicando nel contesto di Linux. Tecnologia matura LVM in terra commerciale UNIX per anni prima di Linux. Se avevi gestito il top-end Solaris / Sparc / EMC Symmetrix, Linux era come un passo indietro (e lo è ancora in molti modi). Ai tempi dei piccoli dischi, LVM rendeva gestibili database multi-terabyte. Non ho mai avuto i problemi che descrivi, che suonano davvero come i problemi delle persone, anche se posso sicuramente relazionarmi.
codenheim,

1
+1 nonostante il bashing LVM. Il resto della risposta è roba buona per ovvia esperienza.
codenheim,

7

Hai ragione in molti modi, posso vedere l'argomento - c'è un problema che potrebbe rivelarsi difficile. Se usi Pool di risorse (e so di no, cose odiose) allora le VM possono ottenere più tempo di I / O se dispongono di più dischi: in situazioni con risorse limitate una VM con due dischi può ottenere il doppio delle risorse di I / O di una con un singolo disco. Potrebbe non essere un problema per te, ma ho pensato di segnalarlo.

Modifica - oh e renderebbe anche lo scatto leggermente più lento, ma potrebbe non essere un problema.


6

Quando lavoravo nelle infrastrutture di una particolare "grande azienda di software di virtualizzazione", spesso dovevamo aumentare le dimensioni del filesystem di VM. Abbiamo usato ext3 / 4 al momento.

L'aumento del disco virtuale è molto semplice, la raccolta delle nuove dimensioni del dispositivo in un sistema operativo live è relativamente semplice (curiosare in / sys), ridimensionare il filesystem ext3 / 4 dal vivo è stato facile, ma quello che sembrava sempre impossibile (fare live) era ridimensionamento della partizione.

Dovevi usare gparted o riscrivere / ridimensionare la tabella delle partizioni usando fdisk - ma era sempre bloccato dal kernel e richiedeva un riavvio per far sì che il kernel prendesse il nuovo layout (neanche partprobe lo faceva).

Ho spostato molti sistemi su LVM e il ridimensionamento dei filesystem è diventato un'esperienza facile, quasi piacevole!

  • Aumenta l'immagine del disco virtuale all'esterno della VM
  • Nella macchina virtuale,
    • Poke / sys per ripetere la scansione delle metriche del disco (echo "1"> / sys / class / scsi_device // device / rescan)
    • pvresize / dev / sdX (ridimensiona il volume fisico in LVM)
    • lvresize --extents + 100% FREE / dev / VG / lvolXX (ridimensiona il volume logico in LVM)
    • resize2fs (ridimensiona il filesystem)

Tutto questo potrebbe essere fatto in sicurezza su un sistema live e non è necessario riavviare!

Perché non un disco nudo? Mi rende nervoso - non credo che i dischi nudi siano ancora ampiamente accettati, ma penso che siamo sull'orlo di un'accettazione molto più ampia. Sulla mailing list di btrfs c'era un thread relativo a questo:

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

Ma un disco nudo avrebbe solo bisogno di rescan e resize2fs.

Quindi, in sintesi, sì, evita le tabelle delle partizioni se puoi.


1
Non è necessario un riavvio per consentire al kernel di rileggere la tabella delle partizioni. Ma si avrebbe bisogno di smontare il file system (s) sul dispositivo ridimensionata (che è difficile se si tratta della partizione /). A parte questo, le tabelle delle partizioni servono piuttosto a scopi documentali: tutti e suo zio eseguono un fdisk -l(o l'equivalente corrispondente) per vedere di cosa tratta un disco sconosciuto. Se non è partizionato, potrebbe facilmente essere scambiato per "vuoto" e sovrascritto. Questo è il motivo per cui creo sempre una tabella delle partizioni per i dischi. LVM è malvagio, però.
the-wabbit,

Questa non è la mia esperienza su queste macchine virtuali specifiche, sebbene abbia funzionato in passato su altre. Smontare la fs non ha liberato la serratura. Forse era solo Centos5, non lo so. Ero sconcertato. In un mondo di partizioni, LVM è fantastico. Nel nuovo mondo btrfs / zfs, è obsoleto. IMHO, ovviamente.
rrauenza,

Mi ci è voluto un po 'per capire che stavi effettivamente usando LVM all'interno della VM ... C'è un motivo per cui non usi LVM sull'host e dai semplicemente al guest un LV da usare come disco? I passaggi per il ridimensionamento sarebbero: ridimensionare il volume nell'host, eseguire nuovamente la scansione sul guest, resize2fs sul guest.
GnP,

Sì, all'interno del vm. Poiché questo è in esx, il disco virtuale deve essere un file vmdk. Sì, teoricamente avremmo potuto usare un disco grezzo nel guest.
rrauenza,

L'uso di un disco nudo è molto più semplice: rimuove 2 passaggi su 5, senza bisogno di conoscere LVM. Ridimensionare un FSM in LVM è stato rischioso anche se sta migliorando: pericoli e avvertenze LVM .
RichVel,

1

Mentre la tua domanda scritta riguarda VMWare (ESXi), vorrei aggiungere una situazione in cui sono tornato a utilizzare le tabelle delle partizioni dopo aver avuto la stessa idea su KVM.

Si è scoperto che se si hanno volumi LVM come dischi per macchine virtuali e si crea un gruppo di volumi LVM all'interno della macchina virtuale senza utilizzare le partizioni (utilizzando l'intero disco virtuale come PV), questo VG sarà visibile all'esterno della macchina virtuale sul computer host. Questo non è il caso se si utilizzano partizioni come PV.

Certo, è un caso angolare ma vale la pena considerare se hai bisogno di una tale configurazione.


Perché avresti bisogno di un VG su un LV all'interno della VM? (nota che sono piuttosto nuovo in LVM, non sto giudicando la tua strada, sto solo cercando di cogliere l'uso di una tale configurazione)
GnP

È possibile utilizzare il filtro LVM sull'host per filtrare LV annidati.
Mircea Vutcovici,

1

Se è meglio farlo o no dipende dal tuo sistema.

Ci sono pro e contro di ogni installazione.

Tuttavia, i principali vantaggi di un singolo disco sono i seguenti:

  1. Semplicità: una singola unità ha un singolo file, che può essere facilmente distribuito e replicato.
  2. Indizi al sistema operativo host: un singolo file verrà trattato come un singolo blocco di dati, e quindi il sistema operativo host saprà che le sequenze di accesso alla macchina guest saranno tutte in quel file. Ciò può essere ottenuto su alcune configurazioni del sistema operativo host semplicemente posizionando tutte le immagini dell'unità nello stesso file, ma non sarà necessariamente così.

Tuttavia, ci sono vantaggi per il multi-drive.

  1. Affinità bare metal / posizione manuale: con una singola unità si è bloccati su una singola affinità bare metal dell'unità.
  2. Limitazioni delle dimensioni: se il tuo sistema ha limiti alle dimensioni dell'unità o ai file, potresti colpirli su sistemi molto grandi.
  3. Volumi di sola lettura per la sicurezza: questo è il grande vantaggio. Se il volume principale per il sistema operativo viene letto solo sul lato VM, offre notevoli vantaggi in termini di sicurezza, essenzialmente bloccando la capacità dei programmi all'interno del VM di modificare il sistema operativo di base del guest. L'uso di un'unità dati separata consente di creare unità di sola lettura, che possono essere avviate in lettura e scrittura per manutenzione e aggiornamenti senza solo i dati del modello di cleanroom, impedendo la modifica delle directory vitali del sistema operativo dall'interno del server.

Il multi-drive consente anche di avere (almeno su ESXi) alcuni file su disco in modalità indipendente. In questo modo è possibile evitare di includere, ad esempio, dati temporanei negli snap e nei backup basati su snap.
savoche,

1

c'è un'altra opzione: montare i dati dell'applicazione su volumi NFS. Sono necessari buoni filer (non tutte le implementazioni NFS sono uguali).

Quando i volumi NFS si riempiono, espandi il volume, il client Linux vedrà subito lo spazio extra.

L'applicazione e il fornitore devono supportare la disponibilità dei propri dati su NFS e occorre un'attenta progettazione del NAS, ma lo si deve fare con ogni soluzione di archiviazione per il proprio ambiente virtualizzato.

Un altro punto in più per questo approccio è che se il tuo fornitore di archiviazione dispone di una tecnologia di snapshot / clonazione (come zfs o Netapp) il backup dei dati e la creazione di ambienti test / dev è davvero semplice.


0

Il motivo per cui è ancora necessario eseguire il partizionamento del disco per alcune distribuzioni Linux è dovuto al fatto che esiste un bootloader e tutti i pezzi legacy che lo accompagnano, ovvero il BIOS emulato. Ciò rende più difficile il ridimensionamento di un disco e molti finiranno per usare LVM o altri non-senso simili.

Si può semplicemente creare un filesystem sull'intero volume e montarlo su /, che funzionerà con una distribuzione Linux molto personalizzata (o personalizzabile / non supponente). L'ultima volta che ho provato questo con Ubuntu 12.04, il programma di installazione non sapeva come gestirlo in quanto doveva installare la loro stupida tabella delle partizioni e tutto il jazz. Questo è uno dei problemi delle distribuzioni generiche nel mondo virtualizzato.

Dall'altro, uno può effettivamente mettere il partizionamento ad un uso meno tradizionale, ad esempio ChromeOS e CoreOS hanno due partizioni root di sola lettura per gli aggiornamenti di sistema.


0

Un motivo che non è stato menzionato finora è che in alcune infrastrutture come Google Compute, le prestazioni di I / O del disco aumentano linearmente con le dimensioni del disco . In altre parole, una grande unità partizionata avrà prestazioni IO migliori rispetto a più unità piccole.

Si noti che questo non è generalmente il caso però. Come menzionato da Chopper3 il più delle volte più unità avranno prestazioni IO migliori. In definitiva, se tutte le unità virtuali sono mappate su una singola unità fisica, non dovrebbero esserci differenze.


0

Nella mia esperienza, un approccio migliore consiste nell'utilizzare 1 VMDK per OS e di solito lo partiziono nel modo seguente:

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

Ho trovato 8 GB sufficienti per /, perché di solito installo una distribuzione Linux minima (~ 800 MB) + software di cui ho bisogno. I log vanno anche a quella partizione, ma se impostati correttamente (logrotate per una settimana) e spediti altrove (syslog / elasticsearch) di solito non rappresentano un piacere per riempire la partizione.

I dati vengono aggiunti come un altro VMDK e di solito formatto il filesystem direttamente su disco nudo (ad es. / Dev / sdb). Questo mi consente di ridimensionare il volume in VmWare e ridimensionarlo direttamente nella VM senza dover ripartizionare / smontare / riavviare.


Mi piace come hai partizionato in modo specifico lo swap dopo / boot, qualcosa che ho scoperto solo di recente (2008 o giù di lì). Mantenere anche solo una vecchia immagine del kernel gonfio provoca l'allungamento di parti modeste / boot e l'alimentazione di sda2 per / boot spesso gli dà abbastanza spazio. Avendolo dove si trova non significa alcun trasferimento della radice di mantenimento del fotovoltaico e ciò consente di risparmiare un'operazione complicata che a volte deve essere eseguita in remoto. :-)
user2066657

0

Ho partizionato per due motivi:

  1. Documentazione - Una volta ho avuto un amministratore "addestrato" di EMC che rubava i LUN da sotto di me perché erano privi di documenti e gli sembravano non allocati, e nel mezzo della notte, è stato richiesto un database Oracle che improvvisamente è andato offline. Aveva effettuato il provisioning dei miei LUN per un altro volume per un'app non correlata. Da allora sono paranoico sulla documentazione.
  2. Provisioning eccessivo del mio disco. Con i piatti mantiene i dati lontani dai cilindri più lenti e con SSD, prolunga la durata / MTBF.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.