Il filesystem replicato può essere di qualsiasi tipo che si desidera, l'unico requisito è che sia montato. Non sono necessari files di configurazione speciali, perchè l'installazione è semplice come un comando mount (o una riga in fstab).
Ecco una parziale e libera traduzione del manuale d'installazione.
Ricordo che sul sito ufficiale è pubblicata tutta la documentazione completa ( http://www.furquim.org/chironfs/howto.html )
IMPORTANTE: Ricordo a tutti che non rispondo di eventuali danni ai vostri apparati quindi chi segue ciò che scrivo lo fa a suo rischio e pericolo!!!!
Capitolo 1. Come installare e testare Chiron FS
a) Ottenere e installare Chiron FS
ChironFS si può scaricare da Google Code. Ci sono alcune scelte:
* Il codice sorgente, sia come archivio compresso che in formato RPM;
* Binario:
a)i386, sia in formato RPM e DEB;
b)64 bit, sia in formato amd64/DEB che x86_64/RPM
Per il tarball, chironfs-current_version
Se hai una distribuzione recente probabilmente lo hai già installato o è possibile farlo con pochi comandi come apt-get, yum, yast, ecc
Se non è installato puoi scaricarlo dal suo sito.
Scompatta il binario nel path che preferisci ed avrai una directory di nome chironfs-
Basta entrare nella directory appena creata e compilare con i seguenti comandicomandi:
# cd / path/to/source/chironfs-
# ./configure [usare le opzioni desiderate]
# make
# make install
Per installare il pacchetto sorgente in formato RPM basta eseguire:
rpmbuild -ba chironfs-current_version
e questo compilerà ChironFS generando un chironfs-
Fatto ciò si può installare chiron con questo comando:
rpm -i chironfs-
Per i binari in formato RPM, basta lanciare il seguente comando:
rpm -i chironfs-current_version
Per i binari in formato DEB basta eseguire:
dpkg -i chironfs_current_version
b)Testare Chiron FS
Crea 3 directory, una per il filesystem virtuale e due per le repliche e montale tutte con i comandi:
mkdir /virtual /real1 /real2
chironfs /real1=/real2 /virtual
Verifica che siano montate correttamente con il comando:
df
Si dovrebbe vedere una riga come questa:
/real1=/real2 138456396 130613500 809640 100% /virtual
Tenta di creare/modificare/eliminare alcuni file in /virtual e controlla il risultato in /real1 e /real2.
A questo punto abbiamo tutto il necessario per iniziare la replica dei file.
Possiamo smontare il tutto con il comando:
fusermount -u /virtual
Capitolo 2. Utilizzare Chiron FS
Nel test di cui sopra abbiamo appena fatto l'uso più semplice di ChironFS ma non abbiamo usato due opzioni che, pur essendo OPTIONAL, in un ambiente di produzione sono effettivamente essenziali.
In primo luogo, in un ambiente corporate, vogliamo condividere l'accesso a molti utenti.
Ma se FUSE è stato installato con impostazioni predefinite di utente individuale in questo modo solo l'utente che ha montato il sistema virtuale ha la visibilità necessaria mentre gli altri vedono solo il vuoto mount point.
Così per consentire la visibilità anche agli altri utenti dobbiamo utilizzare l'opzione FUSE allow_other.
In secondo luogo vogliamo che ci venga segnalato se qualche replica non riesce.
Il sistema continuerà a funzionare ma non vogliamo scoprire gli errori quando l'ultima replica ha esito negativo ed il sistema si blocca!
Vogliamo venire a conoscenza della replica non funzionante prima!
Abbiamo pertanto bisogno di attivare i log!
Così l'esempio di cui sopra migliora se si cambia il comando mount con questo:
chironfs --fuseoptions allow_other --log /var/log/chironfs.log /real1=/real2 /virtual
Se si desiderano più repliche, 3 per esempio, digitare:
chironfs --fuseoptions allow_other --log /var/log/chironfs.log /real1=/real2=/real3 /virtual
Ora supponiamo in questo esempio che il /real2 sia un filesystem molto più lento di /real1 e /real3.
ChironFS quando deve scrivere i dati deve scriverli in tutte e tre le directory mentre quando si deve leggere sceglierà solo una di esse.
Decidiamo che non vogliamo che ChironFS dia le stesse possibilità di lettura a /real2 rispetto a /real1 e a /real3.
Dato che ChironFS utilizza un algoritmo di round robin se noi non gli specifichiamo che /real2 è lento leggerà da /real2 ad ogni tre letture.
Così, per evitare questo inconveniente, possiamo dare una bassa priorità a /real2 in modo che ChironFS leggerà da quest'ultima solo se /real1 e /real3 saranno in failure. Per fare questo digitiamo i due punti appena prima del path /real2 :
chironfs --fuseoptions allow_other --log /var/log/chironfs.log /real1=:/real2=/real3 /virtual
Capitolo 3. Modificare fstab
Per montare automaticamente al momento del boot la dir virtuale basta aggiungere una riga al file /etc/fstab così come mostrato nell'esempio qui sotto.
La prima colonna deve iniziare con "chironfs #" seguito, senza spazi, con l'elenco delle repliche separate dal simbolo uguale.
La seconda colonna è il punto di mount.
La terza colonna deve essere "fuse".
La quarta colonna indica le opzioni di fuse e chironfs che devono essere separate da due punti.
Le ultime due colonne sono le opzioni di fstab e funziona proprio come si può vedere nella documentazione fstab.
chironfs#/real1=/real2 /virtual fuse allow_other,log=/var/log/chironfs.log 0 0
Capitolo 4. Alcuni esempi
Analizziamo alcuni esempi reali:
a) File e web servers
In questo esempio vedremo 3 diverse soluzioni per la replica dei dati su una rete LAN con 2 server, tipicamente un file server e un server web.
i) Network storage
In questa soluzione avremo bisogno di 2 server in più che ricopriranno il ruolo di 'server dei server', condividendo il loro filesystem utilizzando qualsiasi protocollo come NFS, SSHFS, ecc.
Ai fini del nostro esempio useremo NFS. I 'server dei server'avranno i nomi degli host impostati come nfs1 e nfs2 ed esporteranno la directory /dati.
Il file e web server, avranno i loro nomi di host impostato su fileserver e server web, e saranno, rispettivamente, i 'server degli utenti '.
Creiamo localmente in ciascuno dei server degli utenti le seguenti dir:
mkdir /real1 /real2 /virtuale
Aggiorna i loro /etc/fstabs con l'aggiunta di queste 3 linee:
nfs1: /data /real1 nfs auto 0 0
nfs2: /data /real2 nfs auto 0 0
chironfs#/real1=/real2 /virtual fuse allow_other,log=/var/log/chironfs.log 0 0
Ora è possibile fare il setup del 'server degli utenti'.
Segui le istruzioni specifiche dei servizi che desideri configurare cercando di far sì che il fileserver esporti la directory /virtual agli utenti e mettendo la document root del webserver sotto la directory /virtual.
Per non avere alcun single point of failure è necessario fornire i backup hardware di rete, per esempio 2 schede di rete per ogni server, collegati a switche ridondati.
Infine installa e configura heartbeat nei 'server utenti' per far si che se uno di essi vada in failure sia automaticamente sostituito da uno degli altri.
ii) Local storage
Creiamo il punto di mount locale per tutti i filesystem reale e virtuale in ciascuno dei 'server degli utenti':
mkdir /real1 /real2 /virtuale
Aggiornare il file /etc/fstab sul fileserver con l'aggiunta di queste 2 linee:
webserver:/real1 /real1 nfs auto 0 0
chironfs #/real2 =:/real1 /virtual fuse allow_other,log = /var/log/chironfs.log 0 0
Aggiornare il file /etc/fstab sul webserver con l'aggiunta di queste 2 linee:
fileserver:/real2 /real2 nfs auto 0 0
chironfs #/real1 =:/real2 /virtual fuse allow_other,log=/var/log/chironfs.log 0 0
Ora è possibile l'installazione di 'server degli utenti'.
Seguire le istruzioni specifiche dei servizi che si desidera configurare, cercando di far sì che il fileserver esporti la directory /virtual
agli utenti e mettere la document root del webserver sotto la directory /virtual.
Per evitare single point of failure è necessario fornire i backup hardware di rete, come 2 schede di rete per ogni server, collegati a switches ridondati.
Infine installa heartbeat nei server degli utenti in modo che ' qualsiasi failure di uno di essi sia fronteggiato da uno dei server utenti'.
iii) Local and network storage
Si possono combinare le due soluzioni sopra esposte per una terza soluzione, combinando local e storage network.
Creare il mount point locale per tutti i filesystem reali e virtuali in ciascuno dei 'server degli utenti':
mkdir /real1 /real2 /real3 /virtual
Aggiornare i files /etc/fstabs con l'aggiunta di queste tre linee:
nfs1:/data /real1 nfs auto 0 0
nfs2:/data /real2 nfs auto 0 0
chironfs #/real3 =:/real2 =:/real1 /virtual fuse allow_other,log=/var/log/chironfs.log 0 0
Ora è possibile configurare i 'server degli utenti'.
Seguire le istruzioni specifiche dei servizi che si desidera configurare cercando di far sì che il fileserver esporti la directory /virtual agli utenti e la document root del webserver sotto la directory /virtual.
Per non avere alcun single point of failure è necessario fornire i backup hardware di rete, come 2 schede di rete per ogni server, collegati a switch ridondati.
Infine installare heartbeat nei 'server degli utenti 'in modo tale da far sì che se uno di essi andrà in failure sarà automaticamente sostituito da uno degli altri 'server degli altri utenti'.
b) Desktop con il backup di rete
Se si dispone di un desktop Linux si consiglia di avere un backup dei file locali su alcuni server di rete.
Questa soluzione si applica a fare il backup istantaneo dei tuoi files sulla rete.
ATTENZIONE!!!!!
QUESTO NON SOSTITUISCE UNA QUALSIASI SOLUZIONE DI REALE BACKUP PERCHE' QUALSIASI CAMBIAMENTO O MODIFICA AI FILES (aggiornamento o cancellazione) SARA' REPLICATA VIA RETE, QUINDI CONTINUA A CREARE IL TUO BACKUP REGOLARMENTE!
QUESTA SOLUZIONE SERVE SOLO A NON PERDERE IL TUO RECENTE LAVORO CHE NON PUO' TROVARSI NEL BACKUP PERCHE' LA PROCEDURA NON È ANCORA GIRATA!
Creare i punti di mount locali per tutti i filesystem reali e virtuali in ciascuno dei 'server degli utenti':
mkdir /real1 /real2 /virtual
Aggiorna il tuo fstab con l'aggiunta di queste 2 linee:
nfs1:/data /real1 nfs auto 0 0
chironfs#:/real1=/real2 /virtual fuse allow_other,log=/var/log/chironfs.log 0 0
Capitolo 5. Replica Failures
Ogni volta che qualcuna delle tue repliche non va a buon fine chironfs tenta di tenere i tuoi sistemi in esecuzione.
Se il failure si verifica nel corso di una operazione di lettura chironfs cerca di leggere da qualche altra replica ed in caso di successo ritorna al chiamante senza alcun errore. In questo caso, chironfs registra l'evento se hai operato il mount con la raccomandata opzione di log.
Se il failure si verifica durante un'operazione di scrittura chironfs continua a lavorare cercando di scrivere nelle altre repliche.
Se almeno una delle repliche in scrittura riesce chironfs ritorna al chiamante senza alcun errore.
Ma questa volta chironfs registra l'evento e disattiva le repliche verso il nodo che ha fallito. Ciò significa che nessuna ulteriore lettura
o scrittura sarà effettuata da o verso esso.
A questo punto dovete far sì che il vostro sistema di monitoraggio segnali l'evento.
È possibile utilizzare qualsiasi software, come logwatch, per questo scopo. A partire dalla versione 1.1, ChironFS offre un altro modo per controllare la salute del tuo filesystem. Ora hai la possibilità di montare un proc-like control filesystem utilizzando da riga di comando l'opzione --ctl
Il filesystem di controllo è composto da una directory per ogni replica.
I loro nomi sono il path completo delle repliche con il carattere _ al posto di ogni /.
Ognuno di essi contiene due file: il primo è denominato "status" e contiene un numero "0" per le repliche in buono stato o un numero "2" se la replica è disattivata ed i dati sono incoerenti. Scrivendo "0" o "2" in questo file puoi attivare o disattivare la replica.
Il secondo file, chiamato "check_chironfs.sh" è uno script destinato a funzionare come un plugin nagios.
Se si vuole utilizzare non va copiato in un altro percorso perché i suoi contenuti cambiano in modo dinamico e non funzionerà in un altro percorso.
Quindi ammettiamo che il vostro fstab è qualcosa di simile:
nfs1:/data /real1 nfs auto 0 0
chironfs #:/real1=/real2 /virtual fuse allow_other,log=/var/log/chironfs.log,ctl=/var/run/chironctl 0 0
Se si desidera controllare le repliche con Nagios, basta solo indicare a Nagios di eseguire i seguenti scripts: "/var/run/chironctl/_real1/check_chironfs.sh" e "/ var/run/chironctl/_real2/check_chironfs.sh".
Non è possibile modificare la proprietà o il permesso di bit su uno qualsiasi dei files/directories in questo filesystem.
Configurare chi può accedere e modificare la proprietà di un mount point PRIMA di montarlo.
ChironFS applicherà questa proprietà a tutti i file e le directory sotto di esso.
Dopo aver rilevato il failure devi correggere la causa del fallimento nella replica non server.
DEVI PROVVEDERE TE A RISTABILIRE LA COERENZA DEI DATI SUL SERVER IN FAILURE.
E' consigliabile l'uso di rsync per aggiornare i dati.
QUESTO PASSO DEVE ESSERE FATTO PRIMA DELLA RIATTIVAZIONE DELLA REPLICA ALTRIMENTI SI DANNEGGEREBBERO I DATI IN TUTTIE LE ALTRE REPLICHE.
Per ripristinare l'uso della replica dopo la procedura di recupero di coerenza, supponendo che il tuo fstab sia lo stesso di cui sopra e la replica in failure (e disabilitata) è /real2 utilizzare il file system di controllo per consentirla di nuovo, come di seguito:
echo 0> / var/run/chironctl/_real2/status
Nessun commento:
Posta un commento