Automatizzare l'avvio di Galera Cluster su 2 nodi dopo un reboot
Nel post Galera Cluster per MySQL abbiamo visto come installare configurare ed avviare un cluster Galera con MySQL su 2 nodi, e ci siamo anche soffermati sull’importanza della procedura di avvio dei nodi. Il problema è legato al fatto che all’avvio ciascun nodo cerca un primario al quale connettersi. In caso di riavvio del singolo server non ci sarebbero problemi ad attivare lo start automatico di mysqld tramite systemctl, ma in caso di riavvio completo dell’infrastruttura su uno dei server è necessario procedere con il bootstrap del cluster.
Galera Cluster per MySQL, setup su 2 nodi
Galera Cluster è un framework free per l’attivazione di cluster sincrono multi-master per MySQL/MariaDB. In poche parole, permette di realizzare una topologia multi-master active-active con replica sincrona dei dati, abilitando le operazioni di lettura e scrittura su tutti i nodi del cluster.
Redis in HA utilizzando Sentinel
Redis (REmote DIctionary Server) è un database in-memory non relazionale, open-source, ad alte prestazioni, che può essere utilizzato come archivio di strutture dati di tipo chiave-valore. Può essere ovviamente usato come singola istanza, quindi installato su un singolo server, oppure configurato in Alta Affidabilità. Esistono due modi per avere un’architettura Redis di tipo HA, attivare un Cluster Redis avendo a disposizione almeno 6 nodi (3 Master + 3 Slave), oppure utilizzare il tool Sentinel avendo a disposizione 3 nodi su cui attivare Sentinel oltre i nodi Master e Slave di Redis stesso.
Kamailio funzionalità di Balancer
Le funzionalità di load balancer su Kamailio sono rese disponibili attraverso il modulo “dispatcher”, che prevede il supporto di diversi algoritmi di balancing e traffic dispatching.
In questo tutorial vedremo come configurare Kamailio per bilanciare il traffico verso differenti destinazioni in base alla loro disponibilità, illustrando le modalità round-robin e priority. Kamailio è in grado di monitorare lo stato degli end-point di destinazione attraverso l’utilizzo di SIP OPTIONS oppure altri messaggi come INFO.
Configurare Kamailio con rtpengine per gestire traffico RTP dietro NAT
In uno scenario di laboratorio, quindi ideale direi, di solito tutti gli elementi coinvolti in una chiamata VoIP sono sulla stessa subnet e questo vuol dire che i flussi media RTP transitano direttamente tra chiamante e chiamato. Questo però non accade mai nel mondo reale, dove invece lo scenario è molto più complesso e sia i messaggi di segnalazione SIP sia i flussi media devono transitare attraverso firewall e NAT.
In generale possiamo pensare ad uno scenario come quello illustrato nella figura seguente, dove il chiamante è localizzato esternamente alla nostra infrastruttura ed il chiamato si trova su una rete locale dietro un SIP Proxy, che a sua volta è dietro un firewall.
Kamailio installazione e configurazione
Kamailio è un SIP Server Open Source rilasciato su licenza GPLv2+, capace di gestire migliaia di call setup al secondo, e con il pieno supporto del protocollo SIP definito in IETF RFC 3261, inclusi i vari annessi e addon. L’utilizzo principale di Kamailio è quello di un SIP Proxy per il routing di messaggi SIP, ma ci sono poi tutte una serie funzionalità aggiuntive supportate e descritte sul sito ufficiale al link https://www.kamailio.org/w/. Sulla documentazione ufficiale si trovano i dettagli dei vari moduli supportati dal sistema, qui invece andiamo a vedere brevemente come installare Kamailio e come configurarlo per la gestione di chiamate in ingresso.
Installare RTPengine su CentOS/RHEL 7
Guida completa per l’installazione di RTPengine su un server CentOS 7 o RHEL 7
Installare sngrep
Esistono diversi strumenti per monitorare il traffico di rete, come ad esempio tcpdump su Linux oppure wireshark su Windows, qui invece andremo ad installare sngrep, un utilissimo tool per l’analisi del traffico SIP. La caratteristica principale di sngrep è la possibilità di visualizzare in forma grafica il flusso completo di una chiamata SIP anche su una sessione SSH.
SIPp simulatore traffico SIP
SIPp è un generatore di traffico SIP free Open Source, con il quale è possibile disegnare scenari di chiamata tramite file xml da mandare poi in esecuzione. Uno scenario di chiamata descritto su file xml altro non è che un call flow SIP, nel quale è possibile andare a definire nel dettaglio i vari messaggi SIP che si vuole simulare, dal semplice scenario di gestione della sequenza REGISTER - 200OK, a scenari di complessità elevata con re-INTIVE, REFER, ecc…
Essendo un tool molto leggero in termini di allocazione risorse è ottimo per realizzare scenare di stress test, gestendo migliaia di chiamate, ma nello stesso tempo può essere usato per simulare singole chiamate di test. SIPp può eseguire scenari di chiamata lavorando sia come UAS (SIP Server), oppure come UAC (SIP Client), ed include anche la possibilità di gestire i media tramite RTP echo e RTP pcap play. A ciò si aggiungono le funzionalità di reporting necessarie a monitorare l’andamento dello scenario in esecuzione.
In poche parole è un tool estremamente configurabile e facile da usare in tutti quei casi in cui abbiamo necessità di andare ad effettuare test su applicativi di traffico SIP.
RHEL7 Failover Cluster
In questo tutorial vedremo come creare un cluster tra due macchine virtuali Red Hat Enterprise Linux (RHEL) 7. Io le ho installate su piattaforma ESXi, con 2 vPCU e 2 GB di RAM ciascuna, ma questo è un dettaglio. Sono necessari tre indirizzi IP, uno per ciascun server RHEL ed uno come IP virtuale, il cluster appunto. Le macchine virtuali devono comunicare tra loro.