C: \ è per OS, D: \ è per Dati?

"Back in the day" abbiamo sempre separato le nostre unità del sistema operativo (in Windows) dalle nostre unità dati. Nel mondo Linux, sebbene ne abbia molta meno familiarità, sono consapevole che la saggezza detta ancora più volumi definiti e usati in una configurazione delle migliori pratiche.

Ora che è altrettanto probabile che l'archiviazione del server si trovi su una SAN (in cui le risorse del disco sono condivise da molti singoli sistemi operativi e applicazioni), è davvero importante che il sistema operativo e le partizioni dei dati siano segregati a livello di volume?

Quali sono i tuoi pensieri?

Esistono tre driver principali per mantenere separati il ​​sistema operativo e i dati in termini di archiviazione.

1. Spazio . Come sottolinea ErikA, in realtà non vuoi davvero che il volume del tuo sistema operativo esaurisca lo spazio. Tutti i tipi di cose brutte possono accadere. Separare questi due metodi di crescita
2. I / O Requisiti di accesso . Il tipo di I / O utilizzato sul volume del sistema operativo in genere è molto diverso da quello utilizzato dai volumi di dati. Mantenere separati i tipi di I / O è un'ottima idea su molti livelli.
3. Portabilità di archiviazione . Quando arriva il momento di aggiornare il sistema operativo del tuo server, puoi annotare il volume del sistema operativo e conservare tutti i dati. O in ambienti SAN o VM puoi semplicemente spostare il volume di dati su un nuovo server appena installato e risparmiare tempo sugli aggiornamenti.

Inoltre, alcuni sistemi operativi (tra cui Windows) non prendono troppo bene il ridimensionamento del volume del sistema operativo, il che significa che in genere è necessario fornirne la quantità necessaria durante la formattazione del server. Confrontalo con i volumi di dati che possono e spesso vengono ridimensionati più volte nel corso della vita di un server. Anche in ambienti completamente virtualizzati in cui il sistema operativo e i volumi di dati stessi sono alloggiati nella stessa memoria effettiva, non essere in grado di ridimensionare il volume del sistema operativo può essere un grave svantaggio. Windows 2008+ ora consiglia 30 GB per l'unità C: \ al giorno d'oggi, molto diverso dai 10 GB che utilizzavamo su Server 2003; questo è qualcosa che attirerà molti amministratori di Windows mentre eseguono la conversione dal 2003 al 2008.

Sì, sicuramente separare il sistema operativo dai dati. L'ho visto più volte in cui, con una partizione condivisa, la partizione finisce per riempirsi e rendere impossibile patchare il sistema operativo, impossibile estendere la partizione (per vari motivi), ecc.

IMO, il sovraccarico della gestione di due partizioni è un piccolo prezzo da pagare per l'isolamento fornito.

Per quanto riguarda i sistemi supportati da SAN a cui si fa riferimento, che comunque non ti proteggeranno dai dati che riempiono la partizione del sistema operativo. Con l'archiviazione completamente virtualizzata, non devi preoccuparti troppo di garantire che il sistema operativo e i dati vivano su mandrini separati.

Direi che dipende da cosa stai facendo con il sistema. Se potresti aver bisogno di reinstallare il sistema operativo, potresti risparmiarti qualche seccatura mettendo tutti i tuoi dati su una partizione separata. Altrimenti non vedo più la necessità. I miei due centesimi.

In linea di principio, penso che separare lo spazio del sistema operativo predefinito (come C :) dai dati (D :) sia una buona idea, ma consiglierei anche di creare una partizione più piccola per i file di registro (L :) per tenerli un po ' più sicuro e prevenire alcuni tipi di attacchi Denial of Service.

Linux è molto simpatico in quanto il file system rimane gerarchicamente in una directory principale, indipendentemente dal numero di dischi fisici o partizioni virtuali utilizzati. Definirei sicuramente il partizionamento del disco, ma non necessariamente per la separazione dei dati rispetto al sistema operativo (poiché molto spesso i due si confondono comunque).

Vorrei guardare:

1. Quali sottodirectory possono riempire il loro disco e causare problemi di spazio per altre directory (ad esempio partizione off / home e / var / log per esempio).
2. Se parti diverse della struttura della directory richiedono file system diversi per motivi di prestazioni (ad es. XFS per stabilità, Ext3 per un utilizzo completo, ecc.)
3. Quali directory potrebbero dover essere espanse in futuro - questi sono buoni candidati per il partizionamento perché puoi semplicemente rinominare la directory, partizionare e montare un nuovo set di spazio su disco nella posizione della directory e copiare i dati dal vecchio al nuovo Posizione.

Le raccomandazioni storiche sul partizionamento Linux (beh, in realtà Unix) sono in parte dovute alle sue origini come sistema operativo (mainframe) per server mainframe, che a mia volta sospetto sia stato influenzato dalla (allora) relativa inaffidabilità dell'hardware. Ad esempio, i registri e i dati temporanei erano in genere separati perché quelle aree di archiviazione avevano un sacco di usura, ma non era un grosso problema se andavano perse.

Se stai costruendo un sistema desktop, sceglierei la divisione data / non-data / swap. A meno che tu non stia costruendo un server che si aspetta di prendere sul serio, cose come seperate / usr / local e / var / tmp diventano solo un mal di testa di allocazione dello spazio.

Direi che è ancora bello avere - hai 100Gb di dati (troppo pr0n amico :)) e devi reinstallare il sistema operativo (o, in linea con la cronologia di Windows, reinstallarlo regolarmente per rimuovere il build-up cruft) quindi è molto semplice mantenerlo intatto, che se fosse anche nella partizione C.

Tuttavia, direi che c'è un problema in quanto a Windows piace soprattutto inserire tutti i tipi di cose nelle directory sull'unità C - non è solo la directory 'utenti', ma tutti i dati dell'app e vari bit che finiscono per bloccarsi anche in ProgramData.

Inoltre, c'è un altro fattore: oltre alle cose veramente grandi (sì, che ancora una volta) ci sono molti strumenti di backup online (o utilità di backup locali) che eseguono backup continui. Dati questi, non è una priorità tale separare i dati, in quanto è possibile ripristinarli facilmente dalla posizione di backup.

Personalmente, provo a dividere dati + SO. Cerco anche di mettere le app su una partizione diversa, in modo che i backup del mio sistema operativo siano molto più piccoli.

Sarò il difensore del diavolo per una diversa scuola di pensiero.

Supponiamo che per motivi di prestazioni, il fornitore consiglia che la partizione del sistema operativo non sia "sparsa" e desidera che venga allocata l'intera partizione del sistema operativo in anticipo. Ciò comporta da 10 Gb a 20 Gb (o più) di spazio inutilizzato sull'unità SAN.

Questo va bene per una singola macchina virtuale, ma è probabile che avrai diversi server "critici per le prestazioni", ognuno con un proprio overhead di spazio da 10 a 20 GB. Nel nostro ambiente questo spazio bianco rappresentava il 20% del nostro disco SAN. Tieni presente che ci sono limiti ai quali dovremmo riempire un disco SAN (ma questa è un'altra storia).

La direzione ha avuto una scelta

1) Assorbe lo spazio sprecato del 20% sulla SAN, che è in aggiunta ad altri requisiti di "spazio bianco" e isola qualsiasi scenario di "disco intero" che potrebbe verificarsi

2) Metti tutto sull'unità C: \ e rischi di riempire l'unità a causa dei registri dell'applicazione.

Cosa hanno fatto?

Considerando che Windows 2008R2 può espandere in modo dinamico l'unità C: \ del sistema operativo host e può espandere l'unità quando è piena, la gestione ha preso i "risparmi" sui costi e l'ha reinvestita in strumenti di monitoraggio come SCOM.

Ora stiamo ottenendo qualcosa di più della semplice protezione di un riempimento di unità C: \, ma disponiamo di un monitoraggio dei sistemi più completo per risolvere altri problemi prima che accada.