Una breve rassegna dei comandi principali legati all'utilizzo di GFS (Global File System)
Formattazione e uso di GFS
In fase di formattazione di un file system GFS si devono indicare diverse informazioni:
- il nome della lock table (opzione -t
) che deve contenere il nome del cluster che utilizza il file system (qui clus424) e il nome del file system (qui data02, e' arbitrario e server per distinguere diversi file system nello stesso cluster);
- il tipo di lock (opzione -p
, nel dubbio usare lock_dlm, in alternativa se si usa GFS su un solo nodo si pud' indicare -p lock_nolock . L'opzione -p lock_gulm e' ormai in disuso);
- il numero di giornali previsti (opzione -j
, ricordarsi che bisogna prevedere almeno un giornale per ogni nodo che dovra' ccedere al file system, per cui con un cluster a 4 nodi, si deve specificare almeno -j 4)
- le loro dimensioni (-J
, valore minimo 32 Mb, default 128 Mb)
- la partizione o il logical volume da formattare (qui /dev/mapper/shared01-data02 )
gfs_mkfs -p lock_dlm -t clus424:data02 -J 32 -j 2 /dev/mapper/shared01-data02
Una volta formattato il file system puo' essere montato normalmente:
mount -t gfs /dev/shared01/data02 /mnt
Raccolta informazioni
Per visualizzare informazioni dettagliate su un file::
gfs_tool stat /mnt/testo.txt
Per un elenco dei file system GFS correntemente montati:
gfs_tool list
Per visualizzare statistiche su un file system (negli esempi che seguono e' montato su /mnt
). Usare l'opzione -c
per un output continuo:
gfs_tool counters /mnt
Per info sullo spazio usato da un file system montato:
gfs_tool df /mnt
Per visualizzare il superblock di un file system montato:
gfs_tool getsb /mnt
Per visualizzare i parametri di tuning correnti di un file system montato:
gfs_tool gettune /mnt
Aumentare e diminuire giornali e dimensioni file system
Si si aggiungono nodi ad un cluster che gestisce un GFS, puo' essere necessario aggiungere il numero dei giornali presenti sul file system (si ricorda che serve almeno un giornale per nodo). Se non e' piu' disponibile spazio e' necessario prima allargare il file system e poi aggiungere i giornali che servono.
Visualizzare info sui giornali :
gfs_tool jindex /mnt
Aggiungere 2 giornali, per prova (-T
) :
gfs_jadd -j 2 -T -J 32 /mnt
Aggiungere 2 giornali:
gfs_jadd -j 2 -J 32 /mnt
Allargare un file system GFS ( va fatto dopo un comando tipo lvresize/lvextend e dopo l'eventuale aggiunta di nuovi giornali, se necessari) (aggiungere l'opzione -T
per fare solo una prova preliminare) :
gfs_grow -T -v /mnt
Gestione dello spazio disco (Quota)
GFS supporta le quota, secondo un meccanismo proprio, che prevede comandi specifici.
Per impostare un limite a livello di utenti:
gfs_quota limit -u User -l Size -f MountPoint
Per imposta un limite a livello di gruppi:
gfs_quota limit -g Group -l Size -f MountPoint
Esempio (il size, impostato con -l
, e' in Mb, al posto del nome del gruppo e' stato usato il suo GID):
gfs_quota limit -u pippo -l 100 -f /mnt
gfs_quota limit -g 100 -l 50 -f /mnt
Per visuallizare tutti i limiti impostati:
gfs_quota list -f /mnt
Per visualizzare i limiti di un utente:
gfs_quota get -u pippo -f /mnt
Per visualizzare il limite di un gruppo:
gfs_quota get -g users -f /mnt
Le informazioni sulle quote vengono memorizzate in un file sul GFS e non viene aggiornato continuamente ma per default ogni 60 secondi. Tale intervallo puo' essere variato (per per prova si imposta a 90 secondi) con :
gfs_tool settune /mnt quota_quantum 90
Per evitare possibili problemi puo' essere utile sincronizzare le quote su di ogni nodo tramite il comando:
gfs_quota sync -f /mnt
Per impostare il warn quota:
gfs_quota warn -u User -l Size -f MountPoint
gfs_quota warn -g Group -l Size -f MountPoint
Esempi (sempre in Mb):
gfs_quota warn -u utente1 -l 90 -f /mnt
gfs_quota warn -g 100 -l 40 -f /mnt
Di default GFS tiene traccia degli utenti e gruppi per i quali non sono stati impostati i valori di quota. Questo potrebbe rallentare le funzioni del cluster, per disabilitare tale controllo si puo' modificare il parametro quota_account:
gfs_tool settune /mnt quota_account 0
Questo comando deve essere ripeturo ad ogni mount del file system e su ogni nodo.
Re: GNBD
Premetto che non ho mai usato GNDB e immagino tu abbia già letto i doc redhat ufficiali (o i rispettivi centos: http://www.centos.org/docs/5/html/5.2/pdf/Global_Network_Block_Device.pdf ).
Effettivamente a prima vista non si vedono file di conf in cui scrivere i device in cui scrivere. Ti consiglio di fare un rpm -ql nome-pacchetti-gndb per vedere se installano file che possono essere significativi. In alternativa ti fai uno script di avvio del servizio, co i comandi che ti servono, lato client e server e lo metti in /etc/init.d/ formattandolo come un normale script di gestione di un servizio..
GNBD
Dunque... ho proceduto così: usando GNBD, ho esportato lo storage del nodo A e importato nel nodo B, e viceversa. Poi, sul nodo A, ho creato un VG coprendo il device locale e quello importato e ha funzionato: ha creato il VG anche sul nodo B, e lo stesso dicasi per il successivo LV che ho messo nel VG. Allo stato attuale tutto dovrebbe funzionare, ma il problema sorge spontaneo...
Quando riavvio una delle macchine, i device GNBD montati non persistono ma spariscono e tutto quanto costruitovi sopra non ha più senso, compreso il LV GFS. Come posso far sì che i volumi così creati persistano anche dopo il riavvio? Non credo sia sufficiente automatizzare il modprobe gnbd, perchè anche gli import-export vengono persi e tutto smette di avere senso.
Re: CLVM
Puoi far vedere dei LV su ogni nodo, ma devono stare su uno storage condiviso, altrimenti non c'è proprio modo:
"Logical volumes created with CLVM on shared storage are visible to all nodes that have access to the shared storage."
CLVM
http://www.centos.org/docs/5/html/5.2/Cluster_Suite_Overview/s1-clvm-overview-CSO.html
Stando a questo link sembra che potrei utilizzare CLVM per far visualizzare i volumi da ogni nodo. Oppure è OBBLIGATORIO utilizzare uno stumento come GNBD, o iSCSI, o una SAN hardware o RAID o AoE per fare una cosa del genere?
Re: Re: Re: Re: Precisazione
Allora, se metti un iscsi target su un server, questo, più per ragioni di design che funzionali, non dovrebbe essere uno dei due nodi del cluster.
In questo modo hai ridondanza sul cluster, ma non ce l'hai, completa, sull'iscsi server, che sarebbe standalone e conterrebbe tutti i tuoi dati. La ridondanza reale l'avresti con una SAN che lo garantisce, in alternativa ti devi arrangiare valutando costi, impatto, e tempi di recovery di eventuali backup a freddo.
Re: Re: Re: Precisazione
Cioè sostanzialmente, utilizzando magari IET, dovrei installare l'iscsi server su una macchina, il client sull'altra, definire un LUN sul server e farvi accedere il client?
RispondiRe: Re: Precisazione
Credo tu abbia inteso bene. Allora considerando che io ho bisogno di prevenire il failure di uno dei due nodi, qual è secodo te il procedimento che dovrei seguire? Grazie ancora
RispondiRe: Precisazione
Uhm, qui mi sovviene un dubbio: quando dici "Io ho bisogno di farlo per 2 PVs che si trovano ognuna su un nodo." intendi dire che i PV sono associati a due dischi fisicamente collegati a due diversi nodi? (uno su ciascuno)? Se è così non si può fare "per natura" semplicemente perchè il disco (o i dischi) in cui metti i dati di un cluster DEVONO essere accessibili da entrambi in nodi (su una SAN o, meglio un NAS) contemporaneamente. Solo così può funzionare un cluster con storage condiviso e un file system tipo GFS.
Una SAN non è propriamente sempre a disposizione, ma si può facilmente simulare con macchine virtuali (aggiungendo nelle conf di entrambe le MV il riferimento allo stesso file, accessibile in modalità "promiscua"), oppure usando dischi condivisi tramite ISCSI (esiste una buona implementazione di un iscsi-target per Linux).
Fammi sapere se ho inteso male.
Precisazione
Ovviamente con "almeno 2 PVs" intendevo 2 PVs occupati contemporaneamente da un singolo VG.
RispondiVG su PVs in diversi computer
Sto continuando a lavorare alla questione, e scrivo ancora per cercare di indirizzarvi meglio su qual è la mia problematica. Dunque, credo di aver finalmente capito il funzionamento di GFS2: bisogna creare un Volume Group con clustered = true, ma non su un singolo PV ma su almeno 2 PVs. Il problema è che su internet ho visto solo esempi di questo in cui i PVs sono sullo stesso disco o comunque sullo stesso nodo. Io ho bisogno di farlo per 2 PVs che si trovano ognuna su un nodo. Oppure non devo fare così?
RispondiAltri particolari
Aggiungo altre cose al mio intervento di prima:
- Si, in lvm.conf c'è locking_type = 3
- Il cluster è correttamente avviato e quorato
- In cluster.conf c'è <cman expected_votes="1" two_node="1"/>
Quello che secondo è il succo di tutto è: come devo preparare i nodi che devono poi accedere al filesystem GFS?
- Devo creare un VG clustered a mano in ogni nodo? Ci ho provato e non mi fa poi creare la LV sotto (Error locking on node);
- Devo crearlo solo dal nodo in cui poi lancio mkfs_gfs? Ci ho provato e stesso identico errore;
- Solo se creo i VG non-clustered poi funziona la creazione con mkfs_gfs ma poi non "propaga" il filesystem;
Come la risolvo?
Re: Re: Re: Re: GFS shared con Xen e RHCS
Innanzitutto ti ringrazio per le risposte :) luci "dovrebbe" o "deve" stare su una console esterna? Finora le mie prove sono sempre state con luci girante su uno dei due nodi. Può essere lì l'errore riguardo GFS?
RispondiRe: Re: Re: GFS shared con Xen e RHCS
Per poter vedere il VG clustered devi avere il cluster quorato, con un cluster a due nodi (two-node mode in cluster.conf) dovrebbe bastare un nodo per tirare in piedi i fs shared.
Luci non dovrebbe essere installato su uno nodo del cluster ma su una console esterna (anche un portatile o comunque un host non nel cluster).
In tutte le volte che ho formattato una partizione gfs l'ho fatto solo su un nodo, avendo tutti i nodi del cluster online e, ovviamente, il cluster quorato.
Hai modificato lvm.conf con un locking type clustered? Ad esempio:
locking_type = 3
Re: Re: GFS shared con Xen e RHCS
Si, il VG è settato come clustered. Ma ho dei malfunzionamenti; ad esempio nel nodo principale (dove è installato luci) quando riaccendo la macchina cman non si riavvia e di conseguenza il GFS2 non si rimonta da solo e quindi i servizi non ripartono. Da luci se tento di joinare a mano il nodo mi dà Unable to retrieve batch indirizzoip:11111 eccetera. Ho fatto prove anche a firewall completamente giù e SELinux è disabilitato. Un'altra cosa che vorrei chiarire: creando uno storage clustered GFS, è necessario creare con mkfs.gfs solo da un nodo oppure esplicitamente in tutti i nodi indicando lo stesso cluster? A questo proposito ho letto pareri diversi nel web e vorrei capirlo bene.
RispondiRe: GFS shared con Xen e RHCS
Il file system GFS che vuoi formattare sta un un logical volume? E' un LV che appartiene ad un VG "clustered"?
In ogni caso ti consiglio di usare come disco per le macchine virtuali un logical volume e non un file.
Quindi nel cluster a due nodi ti basta creare un volume group clustered (vgcreate -c y ...) usare CLVM e sui logical volume che ci crei dentro metterci le macchine virtuali.
GFS shared con Xen e RHCS
Salve, sto cercando di realizzare un cluster RHCS che controlli 4 macchine virtuali Xen, che le migri quando uno dei 2 nodi va in failure. Non riesco però a configurare uno storage GFS sotto. Quando lancio il comando per la formattazione, il filesystem non viene propagato anche nell'altro nodo e non riesco quindi a condividere i contenuti. Il cluster sembra configurato bene (in termini di nodi) e il comando è stato lanciato (credo) con i parametri giusti. Cosa potrei aver dimenticato? Grazie