Quanto è grave installare Linux su una grande partizione?

Eseguiremo CentOS 7 sul nostro nuovo server. Abbiamo 6 unità da 300 GB in raid6 interne al server. (L'archiviazione è in gran parte esterna sotto forma di una casella di raid da 40 TB.) Il volume interno arriva a circa 1,3 TB se formattato come volume singolo. Il nostro amministratore di sistema ritiene che sia una pessima idea installare il sistema operativo su una grande partizione da 1,3 TB.

Sono un biologo Installiamo costantemente nuovi software da eseguire e testare, la maggior parte dei quali arriva in / usr / local. Tuttavia, poiché abbiamo circa 12 biologi non informatici che utilizzano il sistema, anche noi raccogliamo molto innesto in / home. Il nostro ultimo server aveva una partizione da 200 GB per / e dopo 2,5 anni era pieno al 90%. Non voglio che ciò accada di nuovo, ma non voglio nemmeno andare contro il parere di un esperto!

Come possiamo utilizzare al meglio gli 1.3 TB disponibili per assicurarci che lo spazio sia disponibile quando e dove è necessario ma non creare un incubo di manutenzione per l'amministratore di sistema ??

Le ragioni principali (storiche) per il partizionamento sono:

• per separare il sistema operativo dai dati dell'utente e dell'applicazione . Fino al rilascio di RHEL 7 non esisteva un percorso di aggiornamento supportato e un aggiornamento della versione principale avrebbe richiesto una reinstallazione e quindi avere ad esempio /homee altri dati (dell'applicazione) su partizioni separate (o volumi LVM) consente di conservare facilmente i dati utente e i dati dell'applicazione e cancellare le partizioni del sistema operativo.

• Gli utenti non possono accedere correttamente e il sistema inizia a fallire in modo interessante quando si esaurisce completamente lo spazio su disco. Le partizioni multiple consentono di assegnare spazio su disco riservato per il sistema operativo e di tenerlo separato dall'area in cui gli utenti e / o le applicazioni specifiche sono autorizzate a scrivere (ad esempio, /home /tmp/ /var/tmp/ /var/spool/ /oradata/ecc.), Mitigando il rischio operativo di utenti e / o applicazioni con comportamenti scorretti.

• Quota. La quota del disco consente all'amministratore di impedire a un singolo utente di utilizzare tutto lo spazio disponibile, interrompendo il servizio a tutti gli altri utenti del sistema. La quota del singolo disco è assegnata per ogni file system, quindi una singola partizione e quindi un singolo file system significa solo 1 quota del disco. Partizioni multiple (LVM) significano più file system che consentono una gestione più granulare delle quote. A seconda dello scenario di utilizzo che potresti desiderare, ad esempio, permetti a ciascun utente 10 GB nella propria directory home, 2 TB nella directory / data sull'array di archiviazione esterno e imposta una vasta area di memoria condivisa in cui chiunque può scaricare set di dati troppo grandi per la propria directory home e dove la politica diventa "piena è piena", ma quando ciò accade, non si rompe nulla.

• Fornire percorsi IO dedicati . Potresti avere una combinazione di SSD e dischi rotanti e faresti bene ad affrontarli in modo diverso. Non è un grosso problema in un server generico, ma abbastanza comune nelle impostazioni del database è anche assegnare determinati mandrini (dischi) a scopi diversi per prevenire contese IO, ad esempio disco separato per i registri delle transazioni, dischi separati per i dati del database effettivi e separati dischi per spazio temporaneo. .

• Avvio Potrebbe essere necessaria una /bootpartizione separata . Storicamente per affrontare i problemi del BIOS con l'avvio oltre il limite del cilindro 1024, oggigiorno più spesso un requisito per supportare volumi crittografati, per supportare determinati controller RAID, HBA che non supportano l'avvio da SAN o file system non immediatamente supportati dall'installer ecc.

• Ottimizzazione Potrebbero essere necessarie diverse opzioni di ottimizzazione o persino file system completamente diversi.

Se si utilizzano partizioni rigide, è più o meno necessario farlo nel momento dell'installazione e una singola partizione di grandi dimensioni non è la peggiore, ma presenta alcune delle restrizioni di cui sopra.

In genere, consiglio di partizionare il volume principale come un singolo volume fisico LVM Linux di grandi dimensioni, quindi di creare volumi logici che soddisfino le esigenze attuali e per il resto dello spazio su disco, lasciare non assegnato fino a quando necessario .

Puoi quindi espandere quei volumi e i loro file system in base alle necessità (che è un'operazione banale che può essere eseguita su un sistema live), oppure crearne di nuovi.

La riduzione dei volumi LVM è banale, ma spesso la riduzione dei file system su di essi non è supportata molto bene e probabilmente dovrebbe essere evitata.

Il concetto di utilizzare più partizioni è che uno completo nel posto sbagliato non farà funzionare inaspettatamente l'intero sistema.

Considera un processo sulla macchina che riempie un file di registro abbastanza velocemente fino al punto che non c'è spazio libero disponibile. Su una macchina a partizione singola, ciò potrebbe, ad esempio, impedire al sistema di scrivere nuovi dati su / tmp. Se esiste un altro processo che vorrebbe scrivere su / tmp, probabilmente terminerebbe con un errore, causando comportamenti imprevisti.

Questo può essere evitato se si utilizzano partizioni diverse per i luoghi in cui gli utenti o i processi scrivono normalmente (/ home, / var, / tmp).

Consiglierei di controllare sul vecchio server quali cartelle tendono a diventare grandi. Puoi farlo dalla riga di comando con

du -h -d 1 / 2> /dev/null

Vedrai dove vengono accumulati la maggior parte dei dati e progetterai il tuo prossimo sistema in modo appropriato. "-D 1" limita l'output a un solo livello di profondità della cartella rendendolo più leggibile.

Il problema principale con una singola grande partizione è che riempiendo il filesystem è possibile che non sia più possibile effettuare il login.

L'utente root ha la sua cartella home ( /root) al di fuori /homedi questo motivo. Se il filesystem viene riempito in alcune circostanze, anche root non può accedere e non può riparare il sistema.

Questo è il motivo per cui normalmente crei punti di montaggio separati per /var, /tmpe /homeper poter accedere almeno come root per riparare il sistema quando una delle altre partizioni viene riempita.

IMHO, con una partizione come / è abbastanza ragionevole.

Ma puoi usare lvm (gestore di volumi logici). Usa tutto il disco come gruppo lvm, ma crea piccoli dischi logici per /, / home, / usr e qualunque cosa il tuo sysadmin preferisca. Quindi metti un po 'di monitoraggio, che sai, quando il tuo sistema inizia a riempirsi ed espandi i dischi di cui hai bisogno. lvresize e resize2fs sono strumenti online e puoi fare l'espansione senza riavviare il server. Tuttavia, non è possibile ridurre i dischi, quindi è necessario iniziare ragionevolmente piccoli e aumentare dove si vede necessario.

Ci sono problemi minimi riguardo alla configurazione di una singola partizione di Linux, ma ha grandi ricompense.

Cambiare il layout di una partizione è una cosa un po 'difficile e rischiosa, che spesso non puoi fare senza lunghi tempi di inattività.

Il suo unico vantaggio è che hai una certa protezione contro i problemi del disco pieno. Ma troverai questi problemi molto spesso. Immagina la situazione, se una delle tue partizioni è piena e non puoi usare lo spazio sulle altre partizioni, anche se sono quasi vuote !

Alcuni amministratori di sistema professionisti hanno un'opinione totalmente diversa su questo. Stanno dicendo che avere più partizioni può rendere il tuo sistema più affidabile e devi sapere prima del tuo partizionamento, quanto saranno grandi le tue partizioni. A mio avviso, semplicemente non si può dire che sia un terribile svantaggio per la flessibilità del sistema e la loro vera motivazione è che semplicemente preferiscono giocare con le mappe delle partizioni .

Esiste un semplice sistema chiamato lvm , che consente lo spostamento / il ridimensionamento al volo di "partizioni" (nella sua terminologia, volumi). Ma su un singolo server dipartimentale locale, IMHO normalmente non è necessario.

Esistono due motivi principali per il partizionamento:

1. Per mantenere i dati statici lontani dai dati non statici
2. Per mantenere i dati pubblici lontani dai dati privati

Il primo motivo è il più ovvio: è necessario isolare le aree che si riempiranno di file da quelle che non lo sono e in particolare si desidera proteggere /, per evitare un sistema non avviabile. Ad esempio, la directory / var è in genere dove verranno archiviati i file di registro (var sta per "variabile") ed è per questo che / var tende a essere montato su una partizione separata da /.

Il secondo motivo di cui sopra è meno citato (l'ho sentito l'ultima volta in un corso Veritas Volume Manager circa 15 anni fa) ed è realmente rilevante solo per i sistemi in cui molte persone accedono e svolgono lavoro.

C'è qualcosa di un'arte per un'efficace partizionamento, ed è forse per questo che ci sono amministratori di sistema che la spingono un po 'troppo (IMO). Non solo devi conoscere a fondo il filesystem, ma devi anche conoscere l'uso previsto. Personalmente penso che sia un approccio piuttosto vecchio stile che sta diventando sempre meno rilevante per il modo in cui i server vengono utilizzati oggi.

Come sviluppatore di software, sono particolarmente stufo del reparto Ops che costruisce macchine virtuali con schemi di partizionamento sconsiderati che limitano fortemente le dimensioni di / tmp, / home, / var e /, indipendentemente dallo spazio su disco totale disponibile, ma poi don monterai scelte ovvie come / usr o / opt separatamente. Queste macchine in genere inseriscono tutto ciò che resta dello spazio su disco richiesto in un volume "/ stuff" in cui inevitabilmente si finisce per installare e collegare in modo simbolico tutto, ma non è certo una consolazione. Il risultato netto è che spesso passiamo più tempo a mescolare i file e inviare e-mail di avviso piuttosto che fare qualsiasi lavoro reale.

Non c'è nulla di intrinsecamente "cattivo" nell'avere una singola partizione. Su qualsiasi sistema, dovresti monitorare proattivamente il tuo utilizzo del disco e utilizzare strategie di housekeeping sensibili (ad es. Rotazione dei registri, quote sulle directory home), quindi l'unica vera domanda è: di quanti filesystem separati vuoi preoccuparti?

Direi quindi: a meno che tu non sia sicuro al 100% della tua capacità di partizionare il sistema in modo efficace per il tuo particolare caso d'uso, non partizionare affatto .

IMHO, dipende interamente da te. Innanzitutto considera alcune cose, anche se è del tutto relativo.

• questo sistema sarà amministrato frequentemente?
• questo sistema verrà utilizzato da uno o più utenti?
• questo sistema fungerà da desktop o da server o da entrambi?

Dal momento che si può considerare (quasi) qualsiasi directory un mountpoint, si dovrebbe anche considerare cosa contiene dati in qualche modo in crescita e cosa contiene dati in crescita.

Saresti sorpreso da quanto poco richiede un sistema linux (dati in qualche modo in crescita) e quanto viene consumato dalla crescita dei dati (in genere / var / opt / home / srv)

Dipende anche da come si definisce l'uso per questo sistema che delinea i requisiti di partizionamento. L'uso per LVM incluso.

Un tipico sistema desktop richiederebbe circa 20 GB per l'installazione di un sacco di software, quindi tutto il resto assegnato a una casa dedicata andrà bene. LVM causa un lieve sovraccarico sul tuo sistema e in questo caso particolare non è di grande beneficio. Sebbene le opinioni possano essere diverse.

Su un server è meno probabile che il software installato sia dinamico come per un sistema desktop. È anche più saggio disporre di mountpoint effettivi per componenti tipici del filesystem come / tmp / var / usr / home / opt / srv Si consiglia di non utilizzare LVM qui.

Ciò offre una grande modularità del sistema, ma consente anche di fare cose stupide come clonare quella partizione in una VM, ad esempio. O creando un backup a livello di blocco usando dd.

Sulla base di alcune esperienze, ecco alcune note. Considera anche di avere più punti di montaggio che consentono un maggiore controllo, l'assegnazione di un dispositivo disco veloce o lento a un mountpoint può fare la differenza e aumentare notevolmente l'efficienza in termini di costi.

Mounpoint /

• 1 GB (se si utilizzano mountpoint separati per / var / usr / opt / home / tmp)
• +10 o anche +20 GB se si utilizza come sistema desktop con un / home separato

se si utilizza mountpoint / home

• assegna tutto lo spazio libero se utilizzato, / home ne

se si utilizza mountpoint / opt

se si utilizza mountpoint / usr

• questo è difficile e dipende enormemente dalla base software installata

se si utilizza mountpoint / var

• questo è difficile e dipende enormemente dalla base software installata
• per esempio, i database scrivono i loro dati qui su sistemi basati su Debian, se non su Linux
• avere un / var / tmp separato non è irragionevole

se si utilizza mountpoint / tmp

• considera che esiste tmpfs e alloca / tmp su RAM
• considera che alcune applicazioni possono scrivere molti dati qui

Prima di tutto, devo chiedermi perché stai anche pubblicando questa domanda qui, essendo un biologo che sta discutendo con un amministratore di sistema apparentemente competente per quanto riguarda i punti più sottili del partizionamento del disco rigido! (senza offesa, mi chiedo davvero perché non ti fidi del tuo amministratore di sistema).

Quindi, alcune osservazioni:

• 1.3 TB non è più un disco di grandi dimensioni. 2 TB è una dimensione di unità SATA standard più o meno standard nel mondo desktop in questi giorni.

• è improbabile che un'installazione di qualsiasi Linux Distro richieda più di 100 GB. Certamente, la dimensione di / (root) e (swap) dovrebbe essere facilmente determinata come numeri con limite superiore sovradimensionandoli generosamente (per root) o dalle linee guida di configurazione del sistema (swap).

• il mount point per / home dovrebbe puntare a qualcosa di spento sul tuo server RAID da 40 TB. Non è necessario che tali dati, le home directory degli utenti, siano ovunque su quel dispositivo root. Metterli sul server RAID probabilmente ti darà comunque una migliore protezione. E, molto probabilmente, è una struttura NAS facilmente espandibile, mentre probabilmente il piccolo RAID integrato nella scatola del server non lo è.

• dovresti probabilmente mettere il tuo software speciale in una partion separata (mount point per / usr / local / bin etc) in modo da poterlo conservare attraverso gli aggiornamenti del sistema operativo e le salviette della partizione di root. Altrimenti ti troverai di fronte alla possibilità che dovrai reinstallare le tue app software "speciali" dopo un aggiornamento del sistema operativo / correzione / qualunque cosa.

• se vuoi preoccuparti dell'amministrazione del tuo sistema, farei una domanda diversa: qual è il processo di ripristino di emergenza dopo che l'edificio prende fuoco e i server e le scatole RAID vengono distrutti? A meno che i dati a cui tieni non siano completamente nella tua testa, questa è una domanda che ogni utente dovrebbe porre alla propria gente IT / amministratore di sistema. La strategia dovrebbe includere domande come "come potremo replicare l'hardware di cui abbiamo bisogno" e "quanto tempo ci vorrà prima di poter eseguire il backup e l'esecuzione". Alcune discussioni sulla virtualizzazione dei server potrebbero aiutare a risolvere i problemi relativi alle dipendenze hardware e a ripristinare le attività senza la necessità di riconfigurare il sistema operativo (poiché potrebbe essere configurato per l'esecuzione in un ambiente di dispositivo "soft" che non cambia,

• allo stesso modo, potresti voler chiedere quale sia la strategia per proteggere i dati degli utenti da perdite di dati degli errori del programma e dell'utente. Salvare un file vuoto sulla bozza davvero eccezionale del tuo documento di ricerca o avere un utente che digita il comando errato (ad esempio rm -rf *) causerà la perdita dei dati con la stessa sicurezza di un terremoto o di un incendio o di altri danni fisici. Le soluzioni per il recupero di singoli file sono leggermente diverse (o possono essere!) Da quelle più utili per il ripristino di emergenza all'ingrosso.

-

Ciò consente di eseguire il backup, il ripristino o la reinstallazione del sistema operativo indipendentemente dai dati dell'utente. Questo ti dà libertà, indipendenza e sicurezza.

1. È molto più facile migrare verso un'altra distribuzione Linux preservando comunque la maggioranza assoluta dei dati dell'utente.

2. È facile ripristinare gli aggiornamenti con errori applicando il backup della partizione del sistema operativo (è richiesto il doppio avvio). Questo backup potrebbe anche essere piuttosto vecchio: puoi applicarlo e successivamente aggiornarlo alla versione consapevolmente stabile.

3. È semplice ripristinare la versione precedente del sistema operativo se non ti piace l '"aggiornamento importante" applicato di recente (è necessario il doppio avvio).

Per il massimo potenziale di questo approccio, è necessario configurare anche il doppio avvio (può anche essere CentOS / CentOS), in modo da poter sovrascrivere una partizione del sistema operativo mentre si esegue il sistema operativo da un altro. E, sicuramente, è necessario eseguire il backup della partizione di sistema almeno una volta qualche mese.

La mia breve risposta è che anche un desktop non dovrebbe mai usare "una grande partizione". Di recente l'ho provato contro il mio miglior giudizio perché era "solo un laptop" e l'autoinstallatore utilizzava una singola partizione e ho appena fatto clic sul pulsante.

Quando sono andato per installare una distro diversa, ho dovuto ripartizionare i miei dischi perché il programma di installazione non si installa su una distro esistente. Può e manterrà intatto il tuo / home se è sulla sua stessa partizione. Così, ho finito con l'avvio di un cd live partizionato e la riduzione della partizione, la creazione di nuove partizioni per / home e altri, lo spostamento dei miei dati nelle nuove partizioni e infine l'avvio nell'installer per il nuovo sistema operativo.

Idealmente, mettere / su un SSD, / home su un disco rigido, / var su un disco rigido, / usr potrebbe trovarsi su un SSD o HDD a seconda della frequenza con cui si pianifica l'aggiornamento. / tmp su un disco rigido. Di solito creo un'altra partizione per file multimediali condivisi come mp3 e film con collegamenti simbolici dal mio / home. Nota che / sbin fa parte di root, ed è / bin e / root. Questa è la differenza tra / bin e / usr / bin, è / usr è roba che potrebbe non essere disponibile fino a quando non saranno montate tutte le unità, quindi il comando mount non può essere in / usr! Di solito tengo un paio di partizioni extra per altre distribuzioni di Linux, come se quella partizionata fosse sul mio disco rigido nel caso in cui avessi rovinato qualcosa di veramente brutto, ho un altro sistema live pronto per fare il lavoro di recupero.

Per un server in cui potrebbe essere necessario spostare roba in giro, aggiungere spazio di archiviazione in modo dinamico e rimanere costantemente attivo, utilizzare LVM sicuramente !!!

Non è necessario installare il software su / usr / local, è possibile installare tutto il software con un prefisso diverso, che potrebbe essere in / home. La maggior parte dei software può farlo quando lo compili dal sorgente, eseguendo ad es ./configure --prefix=/home/bin

Dato che sei un biologo, potresti essere interessato a un sacco di software che non è correttamente impacchettato in un rpm o deb e dovrai comunque compilarlo dalla fonte.

Sono un amministratore di sistema per un sistema HPC con molti biologi tra i nostri utenti, installiamo tutto il software richiesto in un / app / filesystem, quindi so che è possibile farlo per la maggior parte dei software, tuttavia a volte potrebbe sii molto duro. Per risolvere questo problema, io e i miei colleghi abbiamo scritto su uno strumento chiamato EasyBuild (gratuito e open source) Può compilare e installare software dal sorgente, installarlo in una cartella diversa e creare automaticamente un file del modulo di ambiente per te, quindi puoi effettivamente avere 2 diverse versioni dello stesso software installato e non avere conflitti.

Dai un'occhiata al nostro elenco di pacchetti che possiamo installare con un solo comando, come biologo potresti riconoscerne molti ;-)

Disclaimer: sono uno sviluppatore di EasyBuild

Penso che in generale per un utente principiante / introduttivo * ix che avere il minor numero di partizioni possa funzionare fino a quando non si impara di più sulla natura del sistema. Tuttavia, non puoi semplicemente avere una paritizione e nel tuo caso, signore, per diversi motivi.

Il primo e più pubblicamente pratico motivo di ciò è che la maggior parte di tutti i sistemi Linux richiedono una partizione di swap (in genere dovrebbe essere compresa tra 1-2 * la RAM) e anche un sistema separato, partizioni di avvio o home e nel caso di sistemi Linux di avvio UEFI una partizione EFI (solo 500 MB).

Il secondo motivo, specificamente applicabile alla tua situazione, è che prendere 6 unità da 300 GB e trasformarle in un raid 6 non è, per usare un eufemismo, l'array ottimale. Sebbene, la nuova tecnologia, consideri Raid 6 come un sistema universalmente migliore, l'algoritmo di striping è più richiesto e lo spazio richiesto per archiviare le informazioni (rispetto a RAID 5) è di dimensioni maggiori.

Per non parlare del fatto che RAID 6 richiede hardware aggiuntivo. Quale dovrebbe essere usato, secondo la mia rispettosa opinione, nel tuo caso per acquistare dischi più grandi per evitare guasti del disco, tempi di inattività, ripristino di emergenza o costi aggiuntivi di assistenza tecnica. Capisco che alcuni, molti forse, non saranno d'accordo con me e voglio riaffermare che quando i dischi diventano di dimensioni maggiori nei prossimi due anni (poiché sono diminuiti di prezzo negli ultimi pochi) RAID6, per array più grandi e le grandi società di reddito saranno una scelta ovvia. Tuttavia, in questo caso, non suggerisco l'uso di RAID 6.

Al secondo problema (non basato su RAID), la creazione di una partizione gigante quando il mirroring può tuttavia funzionare per te, se vuoi massimizzare l'efficienza usa unità più grandi e più partizioni. In questo modo, se si verifica un errore del doppio disco, non si avranno tempi di inattività su determinati punti di montaggio o poco a seconda di / dev + / dir.

Almeno fai funzionare il tuo / sys (sistema, kernel, ecc.) Separatamente in modo che se per qualsiasi motivo il tuo kernel decide di non avviarsi puoi semplicemente usare un kernel di recupero, l'avvio remoto o PXE, l'avvio del disco, ecc. Il tuo kernel e avere società- ampio accesso alle tue informazioni mentre ha luogo il processo di d-recovery.

La tua azienda potrebbe non preoccuparsi di questi accenti finché il sistema funziona, ma sto cercando di spiegare i motivi per cui le persone fanno le cose. Mi piacerebbe anche sentire di più dagli altri, a favore e contro questo argomento e sollevare altri punti. Se non sei d'accordo, fammi sapere perché. Poster-- Ti farò anche alcuni link.

Un amore per la nostra comunità Linux Spencer Reiser

PS Soprattutto su server di rete o sistemi disponibili al pubblico, anche se tramite credenziali, sarebbe davvero meglio separare le tue partizioni. Altri possono inserire di più qui, ho bisogno di più caffè.