Dopo aver installato uCarp ed esserci accertati del suo funzionamento, possiamo continuare la nostra configurazione per far si che il cambio di stato avvenga anche quando Asterisk non dovesse piu’ rispondere.
Sicuramente, la maggior parte di voi, avra’ intuito le potenzialita’ e come sia possibile “integrarlo” a nostro piacimento, una semplice soluzione puo’ essere la seguente:
Asterisk presente in Debian, ci mette a disposizione un simpatico script chiamato safe_asterisk, che seppur non esente da problemi, fa al caso nostro. Tale script non fa altro che verificare che Asterisk sia inesecuzione, se non lo fosse lo esegue.
Aggiungendo poi un altro semplice script, eseguito da cron ogni N minuti, possiamo verificare lo stato di asterisk ed eventualmente switchare server.
A questo punto sappiamo che :
1) asterisk sara’ sempre in esecuzione, grazie a safe_asterisk, tuttavia potrebbe essere bloccato o non rispondere piu a certi comandi/chiamate/etc…
2) lo script a cron, verifica, che le risorse che ci interessano siano disponibili e che asterisk funzioni correttamente.
Nel caso non dovesse rispondere, killeremo ucarp, in tal modo un altro server diventerebbe MASTER e prenderebbe il suo posto, e, visto che ci siamo proviamo a killare anche asterisk, nel caso sia vivo ma non piu funzionante.
Siccome safe_asterisk e’ insecuzione, al suo sucessivo controllo, Asterisk verra’ fatto ripartire.
Nel frattempo anche lo script in cron, continua ad essere eseguito, ed accorgendosi che Asterisk e’ in funzione e risponde ai comandi, riavvia il demone carp.
In tal modo il server non solo ha passato il controllo ad un altro in caso di problemi, ma si e’ anche reso nuovamente disponibile e funzionante.
Lo script proposto e’ molto semplice e il controllo eseguito verifica solamente che asterisk risponda ai comandi, nel caso specifico torna l’uptime di Asterisk, ma con un po’ di bash scripting possiamo adattarlo alle nostre specifiche esigenze, cosa consigliata per chi ha esigenze di alta affidabilita.
Potremmo poi ampliarne i controlli verificando anche la disponibilita’ delle risorse di sistema o lo stato dei dishi, etc etc…
A questo punto tutto dovrebbe funzionare, non vi rimane che riconfigurare i vostri client SIP/IAX2/etc abbassandogli il refresh del register, cosicche se vi dovesse essere un cambio di server, anche i client si accorgeranno si renderanno da subito nuovamente disponibili.
asterisk_ucarp_script.tar.gz contiene tutti gli script utilizzati nell’articolo.
Note e commenti sono apprezzati.
26 Feb 08
13:32
Ciao! Sono molto interessato al tuo articolo. Ti spiego brevemente il mio problema. Ho un server AsteriskNOW al quale tento di accedere tramite AsteriskGUI da browser. Il server rimane sempre acceso e connesso ma dopo qualche giorno di inattività, se tento nuovamente di accedere alla GUI mi da “connessione fallita”. Ho pensato di fare un SSH verso l’IP del server per riavviarlo da remoto ma mi da “Connection timed out”. L’unico modo per farlo ripartire, per adesso, è riavviare manualmente il pc che fa da centralino VoIP (che però è in un’altra sede….quindi sarebbe meglio evitare questa scomoda soluzione). DOMANDA: lo script di cui parli nell’articolo potrebbe risolvere questo problema? Pensi possa andare bene anche su AsteriskNOW? Grazie mille!
26 Feb 08
14:07
Se hai problemi anche a connetterti in ssh, immagino che il problema non risieda in Asterisk. Credo che la soluziona migliore al tuo problema consista nel capire perche dopo N tempo di inattività http e ssh diventano irraggiungibili.
Ad ogni modo lo script va su debian cosi come su altre distribuzioni.
26 Feb 08
14:46
Il pc è nuovo e fa solo da centralino VoIP con AsteriskNOW. Secondo te di che tipo di problema potrebbe trattarsi? Hai qualche idea? Io ci ho pensato e non riesco a capire il perché di tale comportamento.
Grazie mille!