7.4. Clustering
Uno storage clusterizzato fornisce una immagine uniforme del file system su tutti i server presenti in un cluster, permettendo così ai server di eseguire un processo di lettura e scrittura su un singolo file system condiviso. Tale impostazione semplifica l'amministrazione dello storage limitando compiti di tipo installazione e patching delle applicazione su un file system. Un file system per l'intero cluster elimina la necessità di usare copie ridondanti di dati dell'applicazione, semplificando così i processi di backup e di disaster recovery.
L'High Availability Add-On di Red Hat fornisce uno storage clusterizzato insieme al Red Hat Global File System 2 (parte del Resilient Storage Add-On).
7.4.1. Global File System 2
Il Global File System 2 (GFS2) è un file system nativo che interfaccia direttamente l'interfaccia del file system del kernel di Linux. Esso permette a computer multipli (nodi) di condividere simultaneamente lo stesso dispositivo di storage in un cluster. Il file system GFS2 esegue regolazioni automatizzate e permette al tempo stesso di eseguire simili operazioni manualmente. Questa sezione contiene alcune considerazioni su come eseguire una ottimizzazione manuale.
Red Hat Enterprise Linux 6.4 introduce alcuni miglioramenti sulla gestione della frammentazione dei file con GFS2. I file creati da Red Hat Enterprise Linux 6.3 o versioni meno recenti, erano propensi alla frammentazione se file multipli venivano archiviati contemporaneamente da più di un processo. Tale frammentazione rallentava l'esecuzione generale in modo particolare con carichi di lavoro in presenza di file molto grandi. Con Red Hat Enterprise Linux 6.4 i processi di scrittura simultanei risultano in una frammentazione del file minore, garantendo così migliori prestazioni in presenza di carichi di lavoro di questo tipo.
Anche se non è presente alcuno strumento di deframmentazione per GFS2 su Red Hat Enterprise Linux, è possibile eseguire una deframmentazione di file singoli identificandoli con filefrag, copiandoli su file temporanei e modificandone il nome per sostituire quelli originali. (È possibile eseguire questa operazione in versioni precedenti alla 6.4 se il processo di scrittura viene eseguito in modo sequenziale.)
Poichè il GFS2 utilizza un meccanismo di bloccaggio globale il quale può richiedere una comunicazione tra i nodi di un cluster, la prestazione migliore avviene quando il sistema viene creato per impedire eventuali contese dei nodi in un file o directory. Di seguito vengono riportati alcuni di questi metodi:
- Preassegnare file e directory con
fallocatequando possibile, per ottimizzare il processo di assegnazione ed evitare la necessità di bloccare le pagine d'origine. - MInimizzare le aree del file system condivise tra nodi multipli per ridurre i rischi di invalidazione cross-node cache migliorando le prestazioni. Per esempio, se numerosi nodi montano lo stesso file system ma accedono a directory secondarie diverse, probabilmente avrete migliori prestazioni spostando una sottodirectory su un file system separato.
- Selezionare un numero ed una dimensione ottimali del gruppo di risorse. Ciò dipende dalle dimensioni del file tipiche e dallo spazio disponibile sul sistema e può interessare la possibilità che nodi multipli cercheranno di usare simultaneamente un gruppo di risorse. Troppi gruppi possono rallentare l'assegnazione durante la ricerca dello spazio, mentre un numero troppo ristretto di gruppi possono causare una contesa del blocco durante l'annullamento dell'assegnazione. È consigliato provare configurazioni multiple per determinare il processo ottimale per il carico di lavoro desiderato.
Tuttavia la contesa non rappresenta il solo problema in grado di interessare le prestazioni del file system GFS2. Altre pratiche per migliorare le prestazioni generali sono:
- Selezionare l'hardware di storage in base ai percorsi I/O previsti dei nodi del cluster e ai requisiti delle prestazioni del file system.
- Usare uno storage "solid-state" quando possibile per ridurre il tempo di ricerca "seek time".
- Creare un file system con dimensioni appropriate per il carico di lavoro desiderato ed assicurarsi che esso non raggiunga mai una capacità di 80%. File system più piccoli avranno tempi di backup proporzionalmente più piccoli, e avranno bisogno di un periodo e di una memoria minori per l'esecuzione dei controlli del file system. Essi soggetti ad una elevata frammentazione se troppo piccoli per il carico di lavoro desiderato.
- Impostare dimensioni più grandi per il journal con carichi di lavoro intensi per i metadati o durante l'utilizzo dei dati presenti nel journal. Tale processo richiede una quantità di memoria maggiore, ma garantisce elevate prestazioni poichè dispone di spazio libero nel journal per l'archiviazione dei dati prima di dover eseguire un processo di scrittura.
- Assicuratevi che gli orologi presenti nei nodi del GFS2 siano sincronizzati per evitare possibili problematiche con applicazioni di rete. È consigliato usare un NTP (Network Time Protocol).
- Se i tempi di accesso alle directory o ai file non sono critici per il normale svolgimento delle operazioni dell'applicazione, montare il file system con le opzioni di montaggio
noatimeenodiratime.Nota
Red Hat consiglia l'uso dell'opzionenoatimecon GFS2. - Se desiderate usare un quota, provate a ridurre la frequenza del numero di operazioni di sincronizzazione, oppure usate una sincronizzazione fuzzy quota per impedire eventuali problemi di prestazioni causati dai continui aggiornamenti del file quota.
Nota
Il fuzzy quota accounting permette a utenti o gruppi di superare di poco i limiti impostati. Per minimizzare questa tendenza, GFS2 riduce dinamicamente il periodo di sincronizzazione quando si è prossimi ad un limite quota "hard".
Per maggiori informazioni su ogni aspetto dell'ottimizzazione delle prestazioni di GFS2 consultare la Global File System 2 guide disponibile su http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.
