Low Level Asterisk Cluster e High Availability
Nonostante l’ottima affidabilità riscontrata nel corso degli anni dei Server, di qualsiasi marca e a partire dalla fascia bassa del mercato, esiste la necessità, a volte, di mettere in campo delle soluzioni necessarie per assicurare la continuità del servizio telefonico, riducendo quindi il periodo di down in caso di guasto fisico, la necessità quindi di creare un Low Level Asterisk e High Availability Cluster
La stessa affidabilità dei Server, non la abbiamo riscontrata invece negli Hard Disk, Sata o SAS che fossero, molto meglio gli SSD attualmente…e la vecchia tecnologia SCSI quando era disponibile.
La continuità del servizio o High Availability,è una caratteristica chiave di un sistema informatico di classe Server. come Asterisk PBX, la quale ha lo scopo di assicurare livelli di operatività che devono tendere, per quanto reso possibile dalle disponibilità economiche, al raggiungimento delle percentuali definite five-nine,cioè 99,999% di uptime.
Un sistema come Asterisk pbx, per funzionare ed offire ai suoi fruitori i servizi per cui è stato disegnato, consta di varie parti. Ciascuna di queste parti deve sottostare ad alcuni principi chiave per garantirne il funzionamento continuo.
- Eliminazione del single point of failure, quindi aggiungere ridondanza ai componenti
- Sistema efficace ed efficente di sovrapposizione e/o affiancamento dei sottosistemi
- Rilevazione tempestiva di malfunzionamenti.
Dal lato prettamente HW, del Server che ospiterà il nostro sistema Asterisk, per eliminare il Single Point of Failure dovremo ricorrere ad almeno 2 Server fisici (nodi del cluster), operanti , nel caso che prenderemo in questione, in modalità Attiva / Passiva, cioè col secondo nodo pronto ad entrare in funzione in caso di guasto del primo.
CentOS, il sistema operativo utilizzato di preferenza dagli sviluppatori di Asterisk, dispone di uno Stack che rende disponibile tutto il necessario per creare un semplice e funzionale Asterisk e High Availability Cluster.
Si parla di Stack per intendere la presenza di più software e servizi, necessari, ciascuno, per sottendere ad un particolare aspetto della sua gestione.
Il Cluster Stack deve gestire essenzialmente due feature :
- La comunicazione tra i nodi ( i 2 o più Server) del cluster
- La gestione delle risorse che devono essere rese disponibili in cluster
Per gestire correttamente le comunicazioni, ciascun Server deve disporre di due schede di rete, dovendone riservare una per le comunicazioni relative alla gestione interna del Cluster, in special modo per rilevare il possibile down di un nodo.
Pacemaker, Corosync, Heartbeat e DRDB, sono gli strumenti software necessari a creare il nostro Cluster.
Pacemaker è quello che si definisce CRM o cluster resource manager ed è il livello più esterno dei layer che compongono il nostro stack, essendo quello che si occupa di garantire la continuità dei servizi del Cluster.
Corosync / Heartbeat rappresenta il layer di comunicazione tra i nodi del cluster, necessario per sapere se uno dei nodi diventa improvvisamente irragiungibile.
DRBD ( Distributed Replicated Block Device) è una soluzione di archiviazione replicata tra i nodi del cluster ed attraverso di esso, si potranno rendere disponibili lo stesso set di file di configurazione di Asterisk, log, cdr….
Una volta configurato, il dispositivo DRDB potra contenere una partizione od un set di cartelle, di modo che tutto quello che viene creato, modificato od eliminato al suo interno, dal nodo attivo del cluster passerà anche nel nodo passivo.