File system clustering su debian: odi et amo 3° parte (La soluzione finale)

E cosi venne il giorno dopo, tornando in ufficio cercai di pensare ad una qualche soluzione sperando che il sonno porti consiglio, ma a quanto pare il mio di sonno se ne strafotte e mi lascia ben volentieri senza idee.

Ovviamente appena arrivato subito a rapporto dal Boss che mi chiede delucidazioni, ma avendo ben poco da delucidare è facile immaginare che il mio rapporto fu breve ma intenso.

Boss: Allora? che mi dici?
Io: e che ti devo dire, non funziona una sega e non so perchè, in casa RHEL
a quanto pare non amano i workaround, procedono direttamente al bugfix,
e siccome debian non è famosa per avere sempre i pacchetti
dell’ultima moda possiamo attaccarci al
Boss: …tram….
Io: Beh io non avrei usato proprio quella metafora però il senso è quello.
Boss: e scusa è possibile che non c’è una soluzione?
Io: Se c’è è timida e difficile da scovare, ho provato a fare qualche ricerca
ma i risultati si contano sui capelli di un pelato…
cmq adesso continuo a vedere se riesco a cavare qualcosa.

In quel momento la mia faccia era simile a quella di Homer Simpson, esattamente come quando gli si parla e lui dentro la testa ha le scimmie ballerine, perchè non sapevo proprio cosa fare, al chè si materializzò il mio collega che dal nulla disse: "prova a scrivere su it.comp.os.linux.sys magari qualcuno ti sa dire qualcosa".

Detto fatto postai la richiesta e puntualmente il giorno dopo un utente disse:

"Prova con OCFS, non conosco GFS quindi non so compararli in termini di prestazioni ma penso che faccia al caso tuo"

Felice come un bimbo a natale col suo giocattolo preferito, ringrazio, e mi immergo in una mastodontica navigata alla scoperta di questo OCFS scoprendo cose alquanto interessanti, scopro innanzitutto che OCFS è sempre un file system clusterizzato, ma scritto da Oracle ed inizialmente usato per cluster appunto, dei database Oracle.

Il mio collega, autore del suggerimento che aveva letto la risposta la sera prima, mi afferma che potrebbe fare al caso nostro in quanto documentandosi, scoprì che è un filesystem con le stesse caratteristiche di ext3.

Solo che, avendo imparato la lezione, lascio perdere le macchine di produzione e mi tiro su 4 belle macchine virtuali, eliminando futuri viaggi in server farm a causa di altri kernel panic.

"Se per gfs2 o installato gfs2-tools" pensai, "per ocfs2 dovrò installare ocfs2-tools secondo me", detto fatto

:~# apt-get install ocfs2-tools
Reading package lists… Done
Building dependency tree
Reading state information… Done
Suggested packages:
ocfs2console
The following NEW packages will be installed:
ocfs2-tools
0 upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
Need to get 601kB of archives.
After this operation, 1372kB of additional disk space will be used.
Get:1 http://ftp.debian.org lenny/main ocfs2-tools 1.4.1-1 [601kB]
Fetched 601kB in 0s (2414kB/s)
Preconfiguring packages …
Selecting previously deselected package ocfs2-tools.
(Reading database … 64063 files and directories currently installed.)
Unpacking ocfs2-tools (from …/ocfs2-tools_1.4.1-1_i386.deb) …
Processing triggers for man-db …
Setting up ocfs2-tools (1.4.1-1) …

Attraverso la man page di ocfs2 scopro che il file di configurazione è da creare, e dentro /etc/ocfs2/cluster.conf, vado quindi sul sito oracle e cerco la documentazione, finalmente dopo soli 10 minuti, sono riuscito a configurare il cluster su 4 macchine ed ad iniziare i test. Freeze…zero, kernel panic…zero.

Penso: "Scoprirlo prima sto ocfs no eh?"

diffondo la lieta novella al capo, trasformando di conseguenza anche lui in un bimbo felice in periodo natalizio, e giurerei di aver visto anche una puntina di bava scendere dalla bocca…ma va beh sorvoliamo…

Faccio tutti i test possibili immaginabili per cercare di portare al freeze le macchine, scritture contemporanee, decine di migliaia letture di vario tipo cadenzate da pochi millisecondi, ecc ecc, ed il tutto filava liscio senza battere ciglio.

Sfodero un sorriso a 94 denti dorati, e dall’alto del mio successo annuncio al mondo:

Io: Sembra funzionare TUTTO, potete non crederci, ma è cosi…
Boss: Davvero? Hai provato tutto? Sei sicuro?
Io: Si sono sicuro, adesso riavvio a caso le macchine durante i test e vediamo…
Boss: mi sembra giusto.

:~# reboot

essendo macchina virtuale il reboot dura pochissimi secondi, mi loggo sulla macchina e….

:~# cd /mnt/ocfs
:/mnt/ocfs# ls
:/mnt/ocfs#

"E’ vuoto….e perchè è vuoto?" rido ‘ls’ ma niente, provo su un altra macchina e ricevo output, riprovo sulla prima e niente…

Boss: Allora?
Io: Non funziona una fava….
Boss: Ci risiamo te pareva…

rifletto e noto che la differenza tra la macchina che non mi da output e quella che invece funziona sta nel fatto che la seconda non era stata riavviata, controllo i processi e li ottengo l’agghiacciante verità, o2cb ed ocfs2 (che sono i demoni che si occupano rispettivamente di leggere la configurazione e joinare il cluster, ed il secondo di montare le partizioni ocfs) NON sono attivi; avviandoli a mano il tutto riprende a funzionare…

Con ‘dmesg’ ottengo la seconda aberrante verità, in tutta questa manfrina ci siamo scordati i open-iscsi, il demone (ed in questa occasione il termine è proprio azzeccato) maledetto che non riesce a contattare lo storage in fase di boot, non agganciando quindi lo storage successivamente ocfs non riesce a montare la partizione e quindi non parte.

Fortunatamente però open-iscsi è più usato rispetto ad ocfs e gfs e la soluzione la trovo con una rapida ricerca, pastruzzando un pò gli script di init e la configurazione delle interfaccie alla fine sono riuscito ad avere open-iscsi e ocfs funzionanti come due gioiellini, diffondo la notizia, ed il capo riprende a sbavare…

Dopo circa due giorni di test quindi comunichiamo la messa in certificazione (che deve avvenire dagli sviluppatori del cms) di ocfs sul cluster di produzione, ancora adesso però aspetto risposte da parte di chi deve testare il funzionamento di questo benedetto cms sul mini-cluster di 4 macchine….e meno male che come al solito era tutto stra-urgentissimo…