Capitolo 2. Considerazioni operative e configurazione del GFS2
Global File System 2 (GFS2) permette a diversi computer ("nodi") in un cluster di condividere lo stesso storage. Per raggiungere questo tipo di cooperazione e mantenere una certa consistenza dei dati tra i nodi, viene utilizzato uno schema di locking per l'intero cluster per le risorse del file system. Questo schema utilizza alcuni protocolli di comunicazione come TCP/IP, per lo scambio di informazioni.
Per migliorare le prestazioni seguire i consigli riportati in questo capitolo, inclusi quelli relativi alla creazione, utilizzo e gestione di un file system GFS2.
Importante
Assicuratevi che l'implementazione di Red Hat High Availability Add-On possa essere supportata ed in grado di soddisfare i vostri requisiti. Consultate un rappresentante autorizzato di Red Hat per una verifica della configurazione prima dell'impiego.
2.1. Considerazioni sulla formattazione
Questa sezione fornisce le informazioni su come formattare il file system GFS2 per il miglioramento delle prestazioni.
2.1.1. Dimensione del file system: è meglio avere una dimensione più piccola
GFS2 si basa su una architettura a 64-bit la quale può in teoria ospitare un file system di 8 EB. Tuttavia la dimensione massima supportata corrente di un file system GFS2 per un hardware a 64-bit è 100 TB. La dimensione massima corrente supportata di un file system GFS2 per un hardware a 32-bit è 16TB.
Anche se è possibile creare un file system GFS2 molto grande, questa operazione non è consigliata. La regola generale è quella di usare dimensioni più piccole: è meglio avere 10 file system di 1TB che uno di 10TB.
Diversi sono i motivi per i quali è consigliato avere una dimensione piccola per i file system GFS2:
- È necessario un minor tempo per il back up di ogni file system.
- Quantità di tempo minore per il controllo del file system con il comando
fsck.gfs2. - Minore quantità di memoria necessaria per controllare il file system con il comando
fsck.gfs2.
Numero minore di gruppi di risorse per migliori prestazioni.
Se il GFS2 è troppo piccolo potreste avere problemi di spazio e quindi dover risolvere problemi in tal senso. Prima di decidere la misura del file system determinarne il tipo di utilizzo.
2.1.2. Dimensione blocco: È preferito il default di (4K) blocchi.
Con Red Hat Enterprise Linux 6 il comando
mkfs.gfs2 tenta di stimare una dimensione ottimale del blocco in base al tipo di dispositivo usato. In generale, blocchi da 4K sono la dimensione preferita poichè 4K è la dimensione predefinita della pagina (memoria) per Linux. Diversamente da altri file system, GFS2 esegue la maggior parte delle sue operazioni usando kernel buffer da 4K. Se la dimensione del blocco che utilizzate è di 4K, il kernel dovrà lavorare meno per manipolare i buffer.
È consigliato usare la dimensione predefinita del blocco per avere migliori prestazioni. Usare una dimensione diversa solo se è necessario avere uno storage efficiente per numerosi file di piccole dimensioni.
2.1.3. Numero di journal: Uno per ogni nodo che esegue il montaggio
GFS2 ha bisogno di un journal per ogni nodo del cluster che deve montare il file system. Per esempio, se siete in presenza di un cluster a 16 nodi ma avete bisogno di montare solo il file system di due nodi, in tal caso avrete bisogno solo di due journal. Se è necessario eseguire il montaggio da un terzo nodo, sarà sempre possibile aggiungere un journal con il comando
gfs2_jadd. Con GFS2 è possibile aggiungere i journal in modo istantaneo.
2.1.4. Dimensione journal: Predefinita (128MB), generalmente risulta essere ottimale
Quando eseguite il comando
mkfs.gfs2 per creare un file system GFS2, è possibile specificare la dimensione del journal. Se non specificate la dimensione del journal verrà impostato come default 128MB. Questa dimensione dovrebbe essere ottimale per la maggior parte delle applicazioni.
Alcuni amministratori di sistema possono pensare che 128MB siano eccessivi e ridurre la dimensione a 8MB o a 32MB. Anche se questa operazione può funzionare, essa può abbasare le prestazioni. Come numerosi altri file system con journal, ogni qualvolta GFS2 scrive i metadati, quest'ultimi verranno salvati sul journal prima di poterli utilizzare. Ciò significa che se il sistema si arresta inaspettatamente o perde alimentazione, sarà possibile recuperare tutti i metadati quando si riutilizza il journal al momento del montaggio. Tuttavia un journal di 8 MB può non avere più spazio disponibile in tempi molto brevi, e quando il journal è pieno, le prestazioni diminuiscono poichè GFS2 dovrà attendere prima di poter utilizzare lo storage.
È generalmente consigliato l'uso della dimensione predefinita del journal di 128MB. Se il file system è molto piccolo (5GB) l'uso di 128MB potrebbe non essere pratico. Se al contrario il file system è più grande, l'utilizzo di 256MB potrebbe aumentare le prestazioni.
2.1.5. Dimensione e numero dei gruppi delle risorse
Al momento delle creazione di un GFS2 tramite il comando
mkfs.gfs2, lo storage verrà suddiviso in sezioni uniformi conosciute come gruppi di risorse. Durante questo processo verrà stimata una dimensione del gruppo ottimale (che varia da 32MB a 2GB). È possibile annullare l'impostazione predefinita con l'opzione -r del comando mkfs.gfs2.
La dimensione del gruppo di risorse ottimale dipende dal tipo di uso del file system. Considerate il tipo di utilizzo e la sua frammentazione.
Controllate quale delle dimensioni del gruppo di risorse è quella ideale per le prestazioni. Per fare questo utilizzate un cluster di prova prima di implementare GFS2 in ambienti di produzione.
Se il file system presenta un numero molto alto di gruppi (ognuno dei quali risulta essere molto piccolo), l'assegnazione del blocco potrà richiedere una quantità di tempo molto elevata a causa della ricerca del blocco libero tra migliaia (o centinaia di migliaia) di gruppi. Più il file system è pieno, maggiore sarà il numero di gruppi da ricercare, e ognuno di essi avrà bisogno di un blocco dell'intero cluster. Questa operazione rallenterà notevolmente le prestazioni.
Se invece il file system presenta un numero limitato di gruppi (ognuno dei quali è molto grande), si potrà verificare più frequentemente una contesa per lo stesso blocco del gruppo di risorse, abbassando così il livello delle prestazioni. Per esempio, se siete in possesso di un file system di 10GB con 5 gruppi di risorse da 2GB, i nodi presenti nel cluster si contenderanno più spesso i cinque gruppi, rispetto ad un file system composto da 320 gruppi da 32MB. Il problema potrebbe diventare più acuto se il file system è quasi pieno poichè durante l'assegnazione del blocco sarà necessario controllare ogni gruppo di risorse prima di poter trovarne uno con un blocco disponibile. GFS2 cerca di mitigare questo problema in due modi:
- Come prima cosa quando un gruppo di risorse è pieno cercherà di non controllare l'assegnazione futura (fino a quando il blocco non risulta disponibile). Se i file non verranno mai rimossi, la contesa risulterà essere meno severa. Tuttavia, se l'applicazione usata cancella costantemente i blocchi assegnandone di nuovi su un file system quasi pieno, la contesa risulterà essere molto alta con un conseguente rallentamento delle prestazioni.
- Secondo, quando nuovi blocchi vengono aggiunti ad un file esistente, GFS2 cercherà di raggruppare i nuovi blocchi nello stesso gruppo di risorse del file. Questa operazione viene eseguita per aumentare le prestazioni: su un disco in rotazione, le ricerche richiederanno minior tempo se risultano essere fisicamente vicini.
Nei casi peggiori, quando è presente una directory centrale nella quale tutti i nodi creano i file, e i nodi entrano in contesa cercando di bloccare lo stesso gruppo di risorse.
