Cluster dinamico CommuniGate Pro

Il cluster dinamico di CommuniGate Pro implementa un'architettura in cui tutti i nodi sono "attivi". Molte altre soluzioni si accontentano di schemi di recupero dopo inattività o sostituzione d'emergenza, mentre nel cluster dinamico tutti i sistemi funzionano insieme come un'unica entità logica e tutti i nodi assumono la loro parte del carico. Allo stesso tempo, è possibile estrarre ciascun nodo del cluster in qualsiasi momento oppure aggiungerne un altro con qualsiasi ruolo. In questo modo il cluster dinamico consente di eseguire la manutenzione delle sue unità e di aumentare (o ridurre) le attività produttive direttamente durante il funzionamento, senza interruzioni nella fornitura dei servizi.

I vantaggi principali del cluster dinamico, di cui parleremo meglio di seguito, sono:

• Manutenzione dei nodi senza interruzione del servizio
• Sistema unificato
• Utilizzo efficiente dei server
• Scalabilità prevedibile con basse spese aggiuntive
• Servizi ad alta disponibilità

Manutenzione dei nodi senza interruzione del servizio

Diversi aggiornamenti software e hardware dei nodi riducono notevolmente il tempo di disponibilità del sistema di comunicazione. Nel mondo dell'informatica aziendale, questi guasti vengono chiamati "interruzioni pianificate". Tali interruzioni non sono purtroppo assolutamente accettabili nell'ambito delle soluzioni SaaS carrier-class. Immaginate una situazione in cui il telefono fisso sia staccato il sabato per manutenzione.

Al fine di eliminare la necessità di interruzioni, nel cluster dinamico è realizzato un meccanismo di aggiornamenti in serie che consente all'amministratore del cluster di disattivare un dato nodo e distribuire i collegamenti aperti tra le altre unità del cluster, fino a quando il nodo non passa completamente in modalità off-line. A questo punto il nodo diventa disponibile per la manutenzione, terminata la quale può essere nuovamente reintegrato nel cluster.

Sistema unificato

Il cluster dinamico CommuniGate Pro consente all'operatore di considerare l'intero sistema come una singola entità logica, anche quando comprende più di 40 server. Pertanto, la gestione di grandi infrastrutture risulta estremamente più facile rispetto ai sistemi di livello aziendale.

I provider SaaS che forniscono i servizi per piccole imprese e imprenditori individuali hanno bisogno di sistemi facilmente scalabili. E per i nostri clienti che utilizzano il cluster dinamico la scelta più naturale è lavorare su cloud, sistemi che gestiscono più di 20.000 piccole imprese (5-30 utenti finali).

Allo stesso tempo, nel caso di soluzioni IP PBX e posta elettronica non inizialmente progettate per l'utilizzo come piattaforma SaaS, la gestione diventa molto più complicata con un aumento del numero di utenti, a causa della crescita dei singoli elementi: server proxy, database, server LDAP, media gateway, ecc.

Il cluster dinamico è una soluzione elegante e priva di costi aggiuntivi, in grado di crescere con l'aumento del numero di utenti.

Efficienza

La piattaforma CommuniGate Pro sfrutta le risorse hardware in modo molto efficiente. Il provider può pertanto ottenere una maggiore densità di utenti per server rispetto alle soluzioni aziendali. La densità di utenti è un fattore critico nei data-center in quanto permette di ridurre notevolmente le spese relative ad amministrazione, elettricità e raffreddamento.

La maggior parte dei sistemi carrier-class a 64 bit (Solaris, Linux, BSD) permettono a CommuniGate Pro di raggiungere 90.000 sessioni per sistema. Esistono inoltre configurazioni, già collaudate in maniera pratica, che funzionano per oltre 450.000 utenti finali sullo stesso sistema.

Scalabilità prevedibile

Il cluster dinamico è un sistema con scalabilità possibile a spese aggiuntive minime. Per aumentare la capacità del sistema sono sufficienti server semplici a basso costo form factor 1U o di tipo blade server. A differenza di altre architetture con elevati requisiti di potenza di calcolo, per CommuniGate Pro non è consigliato utilizzare server troppo potenti (come 8-way). Ad esempio, un cluster dinamico 4x4 con server a 2 processori rappresenta una scelta migliore rispetto a un 2x2 con server a 4 processori, in quanto nel primo caso il carico specifico su un singolo server è molto più basso.

Il codice sorgente di CommuniGate Pro ben parallelizzato consente di utilizzare le risorse di calcolo e la memoria nel modo più efficiente possibile e le previsioni del volume delle risorse necessarie per l'aumento della base di utenti sono trasparenti e vicine a una relazione di proporzionalità diretta. Tutti i nodi del cluster CommuniGate Pro utilizzano lo stesso file eseguibile e quindi non vi è alcuna differenza nelle prestazioni tra nodi, tipica invece delle architetture eterogenee.

La struttura elegante del cluster dinamico permette ai provider di analizzare e pianificare le loro spese con elevata precisione, siano esse relative a un server o a uno spazio per memorizzazione dei dati.

Alta disponibilità

Una delle caratteristiche principali e l'obiettivo dello sviluppo del cluster dinamico è la riduzione del tempo di inattività praticamente a zero. I nodi del cluster sono tutti attivi e, qualora uno di questi venga meno, le altre unità del cluster assumeranno il relativo carico di utenti.

Architettura del cluster dinamico

Gli elementi principali dell'architettura del cluster CommuniGate Pro includono:

• Bilanciamento del carico
• Topologia di rete
• Front-end
• Back-end
• Memoria di archiviazione condivisa di tipo NFS/CFS

Bilanciamento del carico

Il cluster è composto da diversi server e richiede pertanto, al fine di consentire l'accesso agli utenti sullo stesso URL o indirizzo IP, un bilanciamento del carico. Nel mondo sono operativi numerosi cluster dinamici che hanno diversi tipi di dispositivi di bilanciamento. Si consiglia di utilizzare solo dispositivi L4 di alta qualità ed elevata capacità di Cisco, F5, Foundry. Informazioni più dettagliate sulla configurazione dei bilanciatori sono disponibili nel manuale.

I front-end su Linux possono inoltre svolgere le funzioni di bilanciatore grazie alla tecnologia IPVS integrata nel core.

Topologia di rete

Organizzando un cluster dinamico vengono utilizzate almeno 4 singole reti e alcuni switch ad alta velocità per ottenere prestazioni ottimali. Si consigliano switch Cisco, F5, Foundry, HP o altri switch di livello simile che garantiscono una velocità dell'ordine del gigabit. Allo stesso tempo, questi devono essere dispositivi semplici ed affidabili, come ad esempio la serie Cisco Catalyst 2960.

Ogni server del cluster deve disporre di almeno tre interfacce di rete. Per il corretto funzionamento del cluster dinamico è necessaria una serie di configurazioni di rete:

• Rete pubblica: rete esterna con l'indirizzo IP vuoto. Di solito ogni front-end ha un indirizzo (accompagnato dalla registrazione DNS) e anche al bilanciatore sono assegnati uno o più indirizzi. Per esempio:
  
  Bilanciatore, 64.10.1.1, uc.domain.com
  
  frontend1.domain.com ->64.10.1.11
  frontend2.domain.com ->64.10.1.12
  frontend3.domain.com ->64.10.1.13


• Nelle proprie applicazioni client, gli utenti finali utilizzano solo uc.domain.com. Il bilanciatore, a sua volta, distribuisce le richieste sui front-end attivi. La registrazione DNS è necessaria per il front-end per agevolare il lavoro degli amministratori.
• La rete di scambio intracluster, una rete interna con indirizzi IP grigi, è utilizzata per trasferire informazioni tra i nodi del cluster. Nessun altro traffico è consentito e pertanto sui front-end per questa rete viene usata una seconda interfaccia separata.
• La rete di archiviazione, una rete interna utilizzata per il collegamento tra back-end e memoria di archiviazione, deve essere una rete ad alta velocità su cavo a fibra ottica o Ethernet a 10 Gigabit.
• La rete dirigente, rete chiusa, è di solito una rete locale del provider. È riservata agli amministratori e per attivare la fatturazione API, plug-in e altre attività di gestione del cluster.

Front-end

Nel cluster i front-end eseguono le seguenti funzioni:

• Scambio della posta elettronica su protocollo SMTP con altri server.
• Organizzazione della segnalazione SIP ed esecuzione di applicazioni PBX (l'esecuzione di questa funzione è sincronizzata tra i nodi e questi cluster vengono chiamati SIP-farm).
• Funzioni di protezione: RBL, contatori di errore e di quantità di informazioni ricevute da un indirizzo, liste nere/bianche di indirizzi IP e DNS e altro...
• Organizzazione di collegamenti client-server (IMAP, POP, HTTP, XIMSS, ...). Organizzato il collegamento, il front-end si rivolge al back-end solo per i dati.
• Elaborazione di collegamenti SSL.

Back-end

Nel cluster dinamico i back-end sono il nucleo della piattaforma.

Questi sono responsabili per:

• Impostazioni di dominio
• Impostazioni di account
• Messaggi di posta e altri oggetti creati dall'utente
• Dati ausiliari per il cluster
• Gestione del cluster
• Autenticazione
• Generazione di pagine HTML su tecnologia WSSP

La tecnologia di sincronizzazione a livello di account utilizzata nel back-end assicura che in qualsiasi momento l'accesso ai file dell'account è concesso a un solo server (in intervalli di 6 secondi). Il cluster CommuniGate Pro elimina quindi la necessità di arresto dei file a livello del file system (eccetto heartbeat.data, l'arresto del quale esegue il controller del cluster). Considerando il fatto che il cluster non conta sui meccanismi di arresto nel file system, le prestazioni NFS aumentano di 5-7 volte.

Il cluster dinamico supporta l'aggiornamento successivo dei nodi e il recupero automatico dopo l'inattività di qualsiasi nodo in qualsiasi momento; configurazione consigliata in questo caso: cluster 3x3 (3 front-end, 3 back-end). Per l'inattivazione programmata si consiglia però di utilizzare inattivazione "soft": impostazione "Make Not-Ready" dell'interfaccia WebAdmin nella pagina Monitors->Clusters.

Installazione del cluster

La parte più critica del cluster dinamico è l'archiviazione dati.

Si consiglia di utilizzare soluzioni NAS o SAN, a seconda del sistema operativo e delle funzioni disponibili, quali i protocolli NFS e diversi file system (CFS).

Il processo di installazione comprende i seguenti passi:

• Impostazione della rete
• Impostazione del sistema operativo
• Scelta del file system e del sistema di archiviazione dati
• Adempimento di requisiti del sistema operativo
• Configurazione di CommuniGate Pro.

Impostazione della rete

Il cluster CommuniGate Pro consente una certa flessibilità nelle impostazioni di rete. È possibile:

• Collocare tutte le sottoreti del cluster sotto NAT
• Utilizzare indirizzi diretti WAN
• Le reti miste, front-end si trovano in DMZ e back-end invece che nella rete sicura

CommuniGate Pro consente di gestire centinaia di indirizzi IP e assegnarli a specifici domini amministrati.

A volte l'amministratore può ottenere maggiori prestazioni dal nodo del cluster semplicemente riconfigurando leggermente il sistema operativo. Impostazioni tipiche, regolabili:

• Limite sul numero di file aperti
• Limite sul numero di processi in esecuzione per un singolo utente
• Buffer di rete e cache
• Impostazioni delle parti del core di sistema operativo che gestiscono la rete
• Impostazioni della cache del file system

Impostazioni specifiche e valori sono diversi in tutti i casi.

Verificare gli effetti indesiderati delle impostazioni presso il rivenditore del sistema operativo.

Scelta del file system

La scelta del file system dipende dal sistema operativo e dal sistema di accesso ai dati. In ogni caso, il file system deve:

• Supportare operazioni simultanee con i file della stessa cartella eseguibili da diversi nodi del cluster
• Essere in grado di elaborare milioni di piccoli file
• Essere in grado di elaborare circa 10.000 file in una stessa cartella
• Supportare percorsi file più lunghi di 255 byte
• Supportare i simboli multibyte per i nomi di file o cartelle

Requisiti del sistema operativo

• Il nome del server deve corrispondere al nome del dominio principale nella chiave di licenza (es. licenza — *.domain.com, server — frontend1.domain.com)
• Tutti gli indirizzi IP usati per l'amministrazione sono impostati prima dell'installazione di CommuniGate Pro
• Nel sistema operativo non sono installati altri server di posta elettronica
• Nella configurazione del sistema operativo ci sono DNS server operativi
• Al momento dell'installazione nel sistema operativo non sono presenti firewall (è possibile installarli in un secondo momento)

Oltre a quanto elencato sopra si consiglia vivamente di controllare accuratamente le prestazioni dei back-end prima dell'installazione di CommuniGate Pro e del montaggio del sistema di archiviazione.

Esempi pratici di scelta dell'hardware

La scelta dell'hardware dipende naturalmente da tanti fattori. Gli esempi riportati di seguito sono basati su due versioni standard di utilizzo del cluster, in modo da offrire un'idea generale sugli hardware e le architetture ottimali in pratica. I seguenti parametri incidono sul calcolo della capacità necessaria e delle prestazioni hardware:

• Tipi di servizi (e-mail, VoIP, sincronizzazione con dispositivi mobili, Pronto! (client Flash su server), numero previsto di audioconferenze, quantità di dati memorizzati dagli utenti, ...)
• Nel caso di servizi VoIP, IM, stato presente/assente, l'utilizzo di trasferimento/transcoding dello streaming occuperà delle risorse. Idealmente tutti gli streaming sono trasmessi direttamente da utente a utente, ma le reti con topologia complessa e codec audio non uniformati spesso richiedono che lo streaming sia elaborato dal server.
• Numero di utenti, suddivisi in base ai tipi di servizi utilizzati.
• Percentuale di carico: il rapporto tra il numero di sessioni attive e il numero totale di account nelle ore di punta, suddivisi per tipo di collegamento.
• Modelli di utilizzo del servizio (utenti diversi possono variare notevolmente per numero di client di posta elettronica, client mobili e chiamate per unità di tempo).

utti i fattori vengono presi in considerazione per determinare i requisiti hardware. Considerando questi fattori e la pratica di creazione di tantissimi cluster dinamici il personale di CommuniGate Systems può assistere alla scelta della piattaforma e dei suoi parametri.

Esempi:

1. Servizio di posta elettronica con notifiche push e messaggi istantanei

2. Traffico previsto in percentuale:

Numero previsto di utenti simultaneamente connessi: 4.000.

Architettura consigliata:

Cluster dinamico 3x3.

Front-end

HP DL380G6 X5550
CPU: 2 x Intel® Xeon® Processor X5550 (2.66 GHz, 8MB L3 Cache, 95W, DDR3-1333, HT, Turbo 2/2/3/3)
Memoria: 12 GB
Controller di rete: 2 x HP NC382i Dual Port Multifunction Gigabit Server Adapters
Controller di archiviazione: HP Smart Array P410i/512MB, BBWC
Sistema operativo: SuSE o Redhat Linux 64bit

Back-end

HP ProLiant DL580G5 X7460 16GB (4P)
CPU: Intel® Xeon® X7460 (6 core, 2.67 GHz, 16 MB L3, 130W)
Memoria: 16 GB
Controller di rete: 1GbE NC373i Multifunction 2 Ports
Controller di archiviazione: Smart Array P400i/512MB, BBWC
Sistema operativo: SuSE o Redhat Linux 64bit

Per un aumento del numero di utenti fino a 100.000 è necessario potenziare la configurazione con un front-end (4x3). Per un aumento fino a 200.000, sono necessari 6 front-end e 4 back-end.

3. Servizio VoIP con Pronto! in modalità background, HD audio con trasformazione dello streaming

Proporzione tipi di traffico:

Numero totale di chiamate simultanee 9.000.

Numero di sessioni simultaneamente aperte dagli utenti: 90.000.

Architettura consigliata:

Cluster dinamico 3x3.

Front-end

DELL PowerEdge R710
CPU: 2 x Intel® Xeon® Processor X5550 (2.66 GHz, 8MB L3 Cache, 95W, DDR3-1333, HT, Turbo 2/2/3/3)
Memoria: 24 GB
Controller di rete: 2 x HP NC382i Dual Port Multifunction Gigabit Server Adapters
Controller di archiviazione: HP Smart Array P410i/512MB, BBWC
Sistema operativo: SuSE o Redhat Linux 64bit

Back-end

DELL PowerEdge R710
CPU: 2 x Intel® Xeon® Processor X5550 (2.66 GHz, 8MB L3 Cache, 95W, DDR3-1333, HT, Turbo 2/2/3/3)
Memoria: 16 GB
Controller di rete: 1GbE NC373i Multifunction 2 Ports
Controller di archiviazione: Smart Array P400i/512MB, BBWC
Sistema operativo: SuSE o Redhat Linux 64bit

Suggerimenti per le impostazioni dell'archiviazione dati per il cluster

Nel dominio del cluster tutti gli account utente devono essere disponibili su tutti i back-end. Per organizzare l'archiviazione si consiglia di utilizzare NAS con protocollo NFS, in quanto il cluster CommuniGate Pro non usa l'arresto file a livello di file system e il protocollo NFS è più adatto per esso.

Nello stesso cluster è possibile usare diversi punti di accesso e dei server NFS. Esempi di soluzioni adottate:

NETAPP FAS2000	EMC Celerra NS-120	SUN Storage 7110

Struttura dei file nel cluster

Gli account nel dominio principale sono salvati nelle cartelle con percorso del tipo:

SharedDomains / domainName / accountName.macnt/

Per esempio:

SharedDomains / company.com / aivanov.macnt/

Non è conveniente salvare decine di migliaia di account nella stessa directory (la maggior parte dei file system aprono lentamente le cartelle contenenti un gran numero di oggetti). È stato pertanto sviluppato un meccanismo "Account-level foldering", secondo il quale gli account sono salvati in una serie di sottocartelle:

SharedDomains / company.com / a.sub / aivanov.macnt/

oppure

SharedDomains / company.com / a.sub / i.sub / aivanov.macnt/

oppure

SharedDomains / company.com / ai.sub / v.sub / aivanov.macnt/

Se il cluster comprende tanti domini (oltre circa 5.000), ha senso attivare il "Domain-level foldering":

SharedDomains / c.sub / company.com / aivanov.macnt/
SharedDomains / c.sub / o.sub / company.com / aivanov.macnt/

Oppure, in caso di elevato numero di domini grandi:

SharedDomains / c.sub / company.com / a.sub / i.sub / aivanov.macnt/

È consigliabile scegliere un sistema di ripartizione per cartelle non appena sia noto il numero di utenti e domini. È possibile cambiare le impostazioni anche durante il funzionamento del cluster.

Ottimizzazione dell'archiviazione via SSD

CommuniGate Pro presenta una funzione particolare che può essere utilizzata per ottimizzare l'archiviazione via SSD.

Ogni account possiede nella sua cartella i file account.setting e account.info. Questi file sono letti ogni volta che l'utente accede al proprio account e il file .info cambia ogni volta che i metadati dell'account sono modificati (ad esempio durante la registrazione di un dispositivo SIP).

Per migliorare l'efficienza complessiva del sistema di archiviazione, è possibile salvare questi file separatamente su un supporto più costoso ed efficiente (SSD). Per 1 milione di account, la dimensione totale di tutti questi file sarà tra 5 e 20 GB.

Ad esempio, con una configurazione standard del cluster, i file sono memorizzati nella cartella:

SharedDomains / company.com / a.sub / aivanov.macnt / account.settings
SharedDomains / company.com / a.sub / aivanov.macnt / account.info

Se viene attivato l'uso di "Fast Storage Type" (impostato su un valore non nullo, ad esempio 1), il percorso dei file .info e .settings sarà:

SharedDomains / company.com / fast / a.sub / aivanov.settings
SharedDomains / company.com / fast / a.sub / aivanov.info

In questo modo è possibile installare un dispositivo di archiviazione veloce all'indirizzo

SharedDomains / company.com / fast/,

in cui saranno memorizzati tutti i file .settings e .info.

Cluster dinamico simmetrico

È possibile configurare il cluster CommuniGate Pro in modo tale che ogni nodo funzioni sia come front-end, sia come back-end. Questa configurazione è detta simmetrica:

Super cluster (cluster di cluster)

Questa configurazione è applicata quando è necessario assicurare:

Distribuzione regionale della capacità per una migliore qualità della connessione e l'accesso locale per gli utenti.

Il servizio per un elevatissimo numero di utenti (oltre 15 milioni di account), con ripartizione del carico tra diversi cluster dinamici.

Cluster dinamico nella configurazione SIP-farm

SIP-farm è una tecnologia di CommuniGate Systems per il clustering di VoIP e per raggiungere il 99,999% del tempo di disponibilità del servizio, margine di sicurezza e scalabilità.

Sia il cluster dinamico convenzionale, sia il super cluster possono essere configurati come SIP-farm (in questo caso parte delle unità è assegnata al SIP-farm).

I pacchetti SIP UDP in ingresso o le connessioni TCP sono distribuiti, come al solito, attraverso i bilanciatori di carico. Il server che riceve il pacchetto determina se è necessario elaborarlo in un'altra unità del SIP-farm (se è una risposta o un ACK per una richiesta già esistente o un pacchetto per un'attività su un determinato server) e, se richiesto, lo inoltra.

I pacchetti non destinati a specifici nodi vengono distribuiti tra le unità del farm su algoritmi intracluster, a seconda del carico e della disponibilità dei nodi del SIP-farm.

Risultati

Il cluster dinamico è, tra quelle possibili, la configurazione principale del server CommuniGate Pro. Storicamente il prodotto è progettato proprio sulla base dei servizi "use cases" (come presentati nell'articolo) ad alta prestazione, destinati ad un utilizzo di massa.

Per qualsiasi domanda sul prodotto, non esitate a rivolgervi a russia@communigate.ru. Per questioni tecniche complesse: support@communigate.ru

È possibile scaricare la versione gratuita (fino a 5 utenti, senza cluster) dal nostro sito.