Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Pattern IP mobile per HA tra server con stato attivo e in standby
Il modello di progettazione IP mobile è un meccanismo ben noto per ottenere il failover automatico tra una coppia di nodi hardware attivi e in standby (server multimediali). Al nodo attivo viene assegnato un indirizzo IP virtuale secondario statico. Il monitoraggio continuo tra i nodi attivi e quelli di standby rileva i guasti. Se il nodo attivo si guasta, lo script di monitoraggio assegna l'IP virtuale al nodo di standby pronto e il nodo di standby assume la funzione attiva principale. In questo modo, l'IP virtuale fluttua tra il nodo attivo e quello di standby.
Applicabilità nelle soluzioni RTC
Non è sempre possibile avere più istanze attive dello stesso componente in servizio, ad esempio un cluster attivo-attivo di N nodi. Una configurazione active-standby offre il meccanismo migliore per l'HA. Ad esempio, i componenti stateful di una soluzione RTC, come il server multimediale o il server di conferenza, o anche un SBC o un server di database, sono adatti per una configurazione attiva e in standby. Un SBC o un server multimediale ha diverse sessioni o canali di lunga durata attivi in un determinato momento e, in caso di guasto dell'istanza SBC active, gli endpoint possono riconnettersi al nodo di standby senza alcuna configurazione lato client a causa dell'IP mobile.
Implementazione su AWS
Puoi implementare questo modello su AWS utilizzando le funzionalità di base di Amazon Elastic Compute Cloud (Amazon EC2), Amazon EC2 API, indirizzi IP elastici e il supporto su Amazon EC2 per indirizzi IP privati secondari.
Per implementare il pattern IP mobile su: AWS
-
Avvia due EC2 istanze per assumere i ruoli di nodi primari e secondari, dove per impostazione predefinita si presume che il primario sia in stato attivo.
-
Assegna un indirizzo IP privato secondario aggiuntivo all'istanza principale EC2 .
-
Un indirizzo IP elastico, simile a un IP virtuale (VIP), è associato all'indirizzo privato secondario. Questo indirizzo privato secondario è l'indirizzo utilizzato dagli endpoint esterni per accedere all'applicazione.
-
È necessaria una certa configurazione del sistema operativo (OS) per aggiungere l'indirizzo IP secondario come alias all'interfaccia di rete principale.
-
L'applicazione deve essere associata a questo indirizzo IP elastico. Nel caso del software Asterisk, è possibile configurare l'associazione tramite le impostazioni SIP avanzate di Asterisk.
-
Esegui uno script di monitoraggio, personalizzato, KeepAlive su Linux, Corosync e così via, su ciascun nodo per monitorare lo stato del nodo peer. In caso di guasto del nodo attivo corrente, il peer rileva l'errore e richiama l'API EC2 Amazon per riassegnare a se stesso l'indirizzo IP privato secondario.
Pertanto, l'applicazione che era in ascolto sul VIP associata all'indirizzo IP privato secondario diventa disponibile per gli endpoint tramite il nodo di standby.
Failover tra istanze con stato utilizzando un indirizzo IP elastico EC2
Vantaggi
Questo approccio è una soluzione affidabile a basso costo che protegge dai guasti a livello di EC2 istanza, infrastruttura o applicazione.
Limitazioni ed estensibilità
Questo modello di progettazione è in genere limitato a una singola zona di disponibilità. Può essere implementato in due zone di disponibilità, ma con una variante. In questo caso, l'indirizzo IP elastico mobile viene riassociato tra il nodo attivo e quello di standby in diverse zone di disponibilità tramite l'API di riassociazione degli indirizzi IP elastici disponibile. Nell'implementazione del failover mostrata nella figura precedente, le chiamate in corso vengono interrotte e gli endpoint devono riconnettersi. È possibile estendere questa implementazione con la replica dei dati di sessione sottostanti per garantire un failover senza interruzioni delle sessioni o anche la continuità dei supporti.
Bilanciamento del carico per scalabilità e HA con WebRTC e SIP
Il bilanciamento del carico di un cluster di istanze attive basato su regole predefinite, come round robin, affinità o latenza e così via, è un modello di progettazione ampiamente diffuso grazie alla natura stateless delle richieste HTTP. In effetti, il bilanciamento del carico è un'opzione valida nel caso di molti componenti dell'applicazione RTC.
Il load balancer funge da proxy inverso o punto di ingresso per le richieste all'applicazione desiderata, che a sua volta è configurata per essere eseguita su più nodi attivi contemporaneamente. In qualsiasi momento, il load balancer indirizza una richiesta dell'utente a uno dei nodi attivi nel cluster definito. I sistemi di bilanciamento del carico eseguono un controllo dello stato dei nodi del cluster di destinazione e non inviano una richiesta in entrata a un nodo che non supera il controllo di integrità. Pertanto, il bilanciamento del carico consente di ottenere un livello fondamentale di elevata disponibilità. Inoltre, poiché un load balancer esegue controlli di integrità attivi e passivi su tutti i nodi del cluster a intervalli inferiori al secondo, il tempo di failover è quasi istantaneo.
La decisione su quale nodo dirigere si basa sulle regole di sistema definite nel load balancer, tra cui:
-
Round robin
-
Affinità di sessione o IP, che garantisce che più richieste all'interno di una sessione o dallo stesso IP vengano inviate allo stesso nodo del cluster
-
Basato sulla latenza
-
Basato sul carico
Applicabilità nelle architetture RTC
Il protocollo WebRTC consente di bilanciare facilmente il carico dei gateway WebRTC tramite un sistema di bilanciamento del carico basato su HTTP, come Elastic Load Balancing (ELB), Application Load Balancer (ALB) o Network Load Balancer (NLB)
Attivazione del bilanciamento del carico AWS per WebRTC tramite Application Load Balancer e Auto Scaling
Nel caso delle comunicazioni basate su WebRTC, Elastic Load Balancing fornisce un sistema di bilanciamento del carico completamente gestito, altamente disponibile e scalabile che funge da punto di ingresso per le richieste, che vengono poi indirizzate a un cluster di istanze di destinazione associato a Elastic Load Balancing. EC2 Poiché le richieste WebRTC sono stateless, puoi utilizzare Amazon EC2 Auto Scaling per fornire scalabilità, elasticità e alta disponibilità completamente automatizzate e controllabili.
L'Application Load Balancer fornisce un servizio di bilanciamento del carico completamente gestito che è altamente disponibile utilizzando più zone di disponibilità e scalabile. Ciò supporta il bilanciamento del carico delle WebSocket richieste che gestiscono la segnalazione per le applicazioni WebRTC e la comunicazione bidirezionale tra client e server utilizzando una connessione TCP a lunga durata. L'Application Load Balancer supporta anche il routing basato sui contenuti e le sessioni permanenti, instradando le richieste dallo stesso client allo stesso target utilizzando i cookie generati dal load balancer. Se abiliti le sessioni permanenti, lo stesso target riceve la richiesta e può utilizzare il cookie per ripristinare il contesto della sessione.
La figura seguente mostra la topologia di destinazione.
Scalabilità WebRTC e architettura ad alta disponibilità
Implementazione per SIP tramite Network Load Balancer o un prodotto Marketplace AWS
Nel caso delle comunicazioni basate su SIP, le connessioni vengono effettuate tramite TCP o UDP, con la maggior parte delle applicazioni RTC che utilizzano UDP. Se SIP/TCP è il protocollo di segnale preferito, allora è possibile utilizzare Network Load Balancer per un bilanciamento del carico completamente gestito, altamente disponibile, scalabile e prestazionale.
Un Network Load Balancer opera a livello di connessione (Layer four), instradando le connessioni verso destinazioni come EC2 istanze Amazon, container e indirizzi IP in base ai dati del protocollo IP. Ideale per il bilanciamento del carico del traffico TCP o UDP, il bilanciamento del carico di rete è in grado di gestire milioni di richieste al secondo mantenendo latenze estremamente basse. È integrato con altri servizi AWS popolari, come Amazon EC2 Auto Scaling, Amazon Elastic Container Service (Amazon
Se vengono avviate connessioni SIP, un'altra opzione è utilizzare software commerciale (COTS). Marketplace AWS
Scalabilità RTC basata su SIP con il prodotto AWS Marketplace
