Documenti BQN

Introduzione

‍

A partire dalla versione R5.0, è possibile raggruppare più server BQN in un unico cluster. Il cluster copre diversi aspetti gestionali: configurazione comune delle regole, aggiornamenti software comuni e visibilità comune da entrambi i server che compongono il cluster.

Accedere a uno qualsiasi dei server del cluster:

La pagina iniziale mostra il volume di traffico di ciascun server; cliccando su una casella BQN si verrà reindirizzati alla consueta pagina iniziale BQN di quel server.

Le pagine possono mostrare non solo le informazioni relative al server locale, ma anche quelle relative a qualsiasi server del cluster. Ad esempio, nella sezione Status->Interfaces->Throughput, un selettore in alto a destra consente di visualizzare la velocità di trasmissione di un determinato ID BQN o di tutti i server del cluster (l'icona accanto a BQN 0 indica che abbiamo effettuato l'accesso a BQN 0):

In questa versione, il cluster non include gli aspetti relativi alle API (integrazione tramite REST, RADIUS o sistemi di fatturazione), che ogni server BQN gestisce autonomamente. Non copre nemmeno la distribuzione del traffico a livello di dati: ogni server BQN riceverà il proprio traffico in base a una distribuzione esterna (ad esempio, in base alla posizione nella rete dell'ISP in cui è implementato ciascun server BQN).

Implementazione in cluster

Di seguito è riportato un esempio di implementazione di un cluster a tre server:

‍

Ogni server del cluster possiede un identificatore univoco; in questo esempio, gli identificatori sono 0, 1 e 2. Il server con l'ID più basso (0 in questo caso) è quello che comunica con gli altri server del cluster: è quello che chiamiamo server primario. Gli altri due sono server secondari. Il cluster è resiliente: se il server primario diventa indisponibile, il successivo con l'ID più basso (1 nel nostro esempio) assumerà il ruolo di primario.

Le comunicazioni tra i server del cluster utilizzano gli indirizzi IP di gestione dei server. Esistono due tipi di comunicazione:

• Traffico di controllo del cluster: TCP, con porte comprese nell'intervallo 63500-63755. Un BQN ascolterà sulla porta 63500 + Id. Ad esempio, il BQN con Id 0 utilizzerà la porta 63500, quello con Id 1 la porta 63501 e così via.
• Trasferimento dei dati: SSH/SCP sulla porta 22.

Ogni server del cluster deve essere in grado di comunicare con gli altri server tramite queste porte.

Per definire un cluster, occorre l'elenco degli ID con l'indirizzo IP e la porta SSH su cui sono raggiungibili. Si tratta di un'operazione semplice se tutti gli indirizzi di gestione dei server si trovano nella stessa sottorete.

Se sono presenti configurazioni NAT o di inoltro delle porte, occorre tenerne conto durante la configurazione del cluster. Nell'esempio seguente, i BQN sono raggiungibili tramite indirizzi IP pubblici e la loro porta SSH è sottoposta a inoltro.

La sezione seguente illustra i dettagli relativi alla verifica della connettività di rete e le fasi di configurazione necessarie per creare un cluster.

Configurazione del cluster

Di seguito è riportata una procedura dettagliata per la creazione di un cluster. Utilizzeremo un semplice esempio di cluster composto da un server primario con ID BQN 0 e un solo server secondario con ID 1.

Installazione del software

Tutti i server BQN che devono far parte del cluster devono avere installato il software BQN (versione 5.0 o successive), seguendo la procedura descritta in sezione Installazione del software .

Impostazione degli identificatori BQN (ID BQN)

Ogni server BQN avrà un identificatore univoco. Il BQN con l'ID più basso fungerà da server primario.

Il nostro consiglio è di partire dall'ID 0 e proseguire con 1, 2, ecc.

Per impostazione predefinita, un server BQN ha l'ID 0, quindi non sarà necessario modificare l'ID del server che dovrà fungere da primario. Per gli altri server, seguire questa procedura:

• Vai su Amministrazione->Cluster e clicca su Modifica ID BQN.

• Inserisci il nuovo valore dell'ID BQN, compreso tra 0 e 255 (ad es. 1). La modifica comporta il riavvio del software; pertanto, se il BQN sta elaborando traffico, si verificherà un'interruzione del servizio. L'interfaccia grafica ti disconnetterà. Effettua nuovamente l'accesso per continuare.

‍

Connettività degli indirizzi IP OAM

Gli indirizzi IP di gestione dei BQN devono essere raggiungibili l'uno dall'altro. Quindi, ad esempio, per due BQN con indirizzi IP 192.168.56.111 e 192.168.56.112, accediamo a entrambi i server per verificare la loro reciproca connettività:

ssh bqnadm@192.168.56.111
bqnadm@bqn0# net ping 192.168.56.112
PING 192.168.56.112 (192.168.56.112) 56(84) bytes of data.
64 bytes from 192.168.56.112: icmp_seq=1 ttl=64 time=0.202 ms
64 bytes from 192.168.56.112: icmp_seq=2 ttl=64 time=0.149 ms
64 bytes from 192.168.56.112: icmp_seq=3 ttl=64 time=0.193 ms
64 bytes from 192.168.56.112: icmp_seq=4 ttl=64 time=0.193 ms
^C
--- 192.168.0.122 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3050ms
rtt min/avg/max/mdev = 0.149/0.184/0.202/0.022 ms
bqnadm@bqn0# exit
ssh bqnadm@192.168.56.112
bqnadm@bqn1# net ping 192.168.56.111
PING 192.168.56.111 (192.168.56.111) 56(84) bytes of data.
64 bytes from 192.168.56.111: icmp_seq=1 ttl=64 time=0.200 ms
64 bytes from 192.168.56.111: icmp_seq=2 ttl=64 time=0.199 ms
64 bytes from 192.168.56.111: icmp_seq=3 ttl=64 time=0.202 ms
^C
--- 192.168.0.121 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2032ms
rtt min/avg/max/mdev = 0.199/0.200/0.202/0.011 ms
bqnadm@bqn1# exit

Il cluster utilizza l'intervallo di porte TCP compreso tra 63500 e 63755. La porta dipende dall'identificatore BQN. Ad esempio, se vengono utilizzati solo gli ID 0 e 1, per il controllo del cluster verranno utilizzate le porte 63500 e 63501.

Per verificare che tali porte siano aperte, genera del traffico TCP verso ciascun indirizzo e porta BQN tramite telnet e controlla che venga ricevuto utilizzando tcpdump sul sistema di destinazione. Ad esempio, per verificare che bqn0 possa inviare pacchetti TCP a bqn1, occorre controllare la porta 63501 (la porta su cui è in ascolto un BQN con ID 1). Avvia tcpdump sul sistema di destinazione:

ssh root@bqn1
bqn1:~ # tcpdump -i enp0s3 'tcp and port 63501'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s3, link-type EN10MB (Ethernet), capture size 65535 bytes

Generare traffico verso la porta tramite Telnet (è prevedibile che venga rifiutato, poiché non c'è alcun processo in ascolto quando il cluster non è ancora configurato):

ssh root@bqn0
bqn0:~ # telnet 192.168.56.112 63501
Trying 192.168.56.112...
telnet: connect to address 192.168.56.112: Connection refused
bqn0:~ #

una volta giunti a destinazione, il traffico viene ricevuto:

bqn1:~ # tcpdump -i enp0s3 'tcp and port 63501'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s3, link-type EN10MB (Ethernet), capture size 65535 bytes
19:55:01.510551 IP 192.168.56.111.51808 > 192.168.56.112.63501: Flags [S], seq 1158501329, win 29200, options [mss 1460,sackOK,TS val 277566580 ecr 0,nop,wscale 7], length 0
19:55:01.511800 IP 192.168.56.112.63501 > 192.168.56.111.51808: Flags [R.], seq 0, ack 1158501330, win 0, length 0
19:55:26.344664 IP 192.168.56.111.51812 > 192.168.56.112.63501: Flags [S], seq 3902161536, win 29200, options [mss 1460,sackOK,TS val 277591420 ecr 0,nop,wscale 7], length 0
19:55:26.344835 IP 192.168.56.112.63501 > 192.168.56.111.51812: Flags [R.], seq 0, ack 3902161537, win 0, length 0

Lo stesso vale per la porta 63500, da bqn1 a bqn0.

Si utilizza anche SSH. Per verificare una connessione SSH da bqn0 a bqn1.

bqn0:~ # ssh bqnadm@192.168.56.112
Password:
Last login: Thu Mar 26 19:28:22 2026 from 192.168.56.1
Have a lot of fun...
Copyright (c) 2009-2015 Bequant S.L.
bqnadm@bqn1# exit

E allo stesso modo da bqn1 a bqn0:

bqn1:~ # ssh bqnadm@192.168.56.111
Password:
Last login: Thu Mar 26 19:35:17 2026 from 192.168.56.1
Have a lot of fun...
Copyright (c) 2009-2015 Bequant S.L.
bqnadm@bqn0# exit

Se si intende aggiungere un terzo server al cluster, è necessario verificare la connettività tra questo server e gli altri due come descritto in precedenza.

A volte, un indirizzo IP OAM di un BQN è raggiungibile tramite un indirizzo IP pubblico mappato sull'IP effettivo del BQN. In tal caso, è necessario aggiungere le porte del cluster alla mappatura (ad es. 63500-63501). Quando si verifica la connettività, utilizzare l'indirizzo IP pubblico per raggiungere quel server BQN.

Unificare la configurazione in tutto il cluster

Se il cluster verrà creato utilizzando BQN precedentemente impiegati in modalità autonoma, è necessario verificare le loro configurazioni per individuare eventuali differenze e concordarne una comune. Se sono presenti differenze e non viene effettuata alcuna unificazione, la configurazione del server primario verrà utilizzata come configurazione del cluster.

L'esempio seguente illustra una procedura tipica. Avremo due server da aggiungere al cluster.

1. Accedere al server principale in Amministrazione->Backup->Salva configurazione e salvare la configurazione (ad es. bqn0-v1.conf).
2. Procedere allo stesso modo nel server secondario, in Amministrazione->Backup->Salva configurazione, e salvare la configurazione (ad es. bqn1-v1.conf).
3. Confronta i due file. Ad esempio, utilizzando lo strumento kdiff3, si riscontrano le seguenti differenze:

• Il server NTP 216.229.0.50 non è presente in bqn0. Lo aggiungeremo.
• bqn0 non ha l'API REST abilitata. La aggiungiamo.
• Le differenze nell'interfaccia sono accettabili, poiché dipendono dal server, quindi non interveniamo. Anche l'instradamento dipende dal server (in questo esempio è lo stesso, ma se fosse diverso, non verrebbero uniti).
• Nel profilo dei test di velocità, bqn1 presenta una voce in più; la aggiungiamo a bqn0.
• In sw-updates, bqn0 presenta una voce in più; aggiungiamola a bqn1.
• bqn0 prevede una regola aggiuntiva per gli aggiornamenti software nelle ore di punta. Aggiungiamo la politica e la regola a bqn1 (il profilo orario era già presente).

Dopo aver completato i passaggi precedenti, dovremmo avere i file abqn0-v2.conf e bqn1-v2.conf contenenti la configurazione unificata.

Vai su Amministrazione -> Backup -> Carica configurazione nel server principale e carica il file bqn0-v2.conf.

Procedi allo stesso modo sul server secondario con il file bqn1-v2.conf.

Configurazione del cluster

Inizieremo la creazione del cluster configurando il server primario. Accedere all'interfaccia grafica del server primario, selezionare Amministrazione->Cluster e fare clic su Aggiungi BQN a un cluster...

Nella finestra di dialogo, inserire l'ID BQN secondario (1) e il relativo indirizzo IP di gestione BQN. Nel campo " Indirizzo IP per questo BQN nel cluster", inserire l'indirizzo primario.

In questo esempio utilizziamo gli indirizzi IP di gestione 192.168.56.111 e 192.168.56.112. Se i server sono accessibili tramite indirizzi IP pubblici, utilizzare invece questi ultimi.

Si segue la stessa procedura sul server BQN secondario: accedere all'interfaccia grafica secondaria, selezionare Amministrazione->Cluster e fare clic su Aggiungi BQN a un cluster...

Nella finestra di dialogo, inserire l'ID BQN primario (0) e l'indirizzo IP del BQN. Nel campo " Indirizzo IP per questo BQN nel cluster ", inserire l'indirizzo IP del server secondario.

‍

Gli indirizzi IP possono essere quelli di gestione, come in questo esempio, ma se uno dei server è accessibile tramite un indirizzo IP pubblico, utilizzare invece quell'indirizzo.

Il cluster dovrebbe mostrare lo stato "pronto " e lo stato " completo":

È possibile ripetere la procedura per aggiungere altri server al cluster accedendo all'interfaccia grafica di quel server e facendo clic su "Aggiungi BQN a un cluster".

‍

‍

‍

‍