2.9.2. Regolazione delle prestazioni con GFS2

Generalmente è possibile alterare il metodo attraverso il quale un'applicazione problematica archivia i propri dati, così facendo sarà possibile aumentare considerevolmente le prestazioni.

Un esempio tipico di una applicazione problematica può essere un server di posta elettronica. Generalmente disposti con una directory di spool contenente i file per ogni utente (mbox), o con una directory per ogni utente contente un file per ogni messaggio (maildir). Quando arrivano le richieste attraverso IMAP, l'organizzazione ideale è quella di conferire ad ogni utente una affinità con un nodo specifico. In questo modo le richieste per la visualizzazione e rimozione dei messaggi di posta elettronica verranno serviti dalla cache presente sul nodo interessato. Ovviamente se il nodo fallisce, la sessione potrà essere riavviata su un altro nodo.

Se la posta arriva tramite SMTP i nodi individuali possono essere impostati in modo da passare il messaggio di un particolare utente ad un nodo specifico per default. Se il nodo predefinito non è in funzione, il messaggio potrà essere salvato direttamente nello spool di posta dell'utente da parte del nodo ricevente. Questo tipo di organizzazione è intesa a mantenere set particolari di file archiviati in cache solo su di un nodo in casi normali, e permettere un accesso diretto nel caso di errore del nodo.

Questo tipo di impostazione permette l'uso migliore del page cache di GFS2 rendendo altresì gli errori trasparenti per l'applicazione, sia imap che smtp.

Il backup rappresenta spesso un'altra area spinosa. Se possibile è fortemente consigliato eseguire il backup del set di ogni nodo direttamente dal nodo che esegue il caching del set di inode. Se siete in possesso di uno script di backup il quale viene eseguito in determinati periodi e coincide con il punto massimo del tempo di risposta di una applicazione in esecuzione su GFS2, allora molto probabilmente il cluster non utilizzerà nel modo più efficace il page cache.

Ovviamente se siete in grado di arrestare l'applicazione per poter eseguire il backup allora non avrete alcun problema. Se il backup viene eseguito da un solo nodo dopo il completamento di una sezione molto grande del file system, esso verrà archiviato su quel nodo con un conseguente deterioramento delle prestazioni per accessi successivi eseguiti da altri nodi. Tale tendenza può essere parzialmente ridotta rilasciando il VFS page cache sul nodo di backup dopo il completamento del backup con il seguente comando:

echo -n 3 >/proc/sys/vm/drop_caches

Tuttavia questa non rappresenta la soluzione migliore come può essere per esempio la procedura attraverso la quale il set in funzione su ogni nodo sia condiviso, per la maggior parte in sola lettura sul cluster, o accesso principalmente da un singolo nodo.