Cosa fare se la potenza di un server non è sufficiente per elaborare tutte le richieste e il produttore del software non fornisce il bilanciamento del carico? Esistono molte opzioni, dall'acquisto di un bilanciatore del carico alla limitazione del numero di richieste. Quale sia quella corretta deve essere determinata dalla situazione, tenendo conto delle condizioni esistenti. In questo articolo ti diremo cosa puoi fare se il tuo budget è limitato e disponi di un server gratuito.
Come sistema per il quale era necessario ridurre il carico su uno dei server, abbiamo scelto DLP (sistema di prevenzione della fuga di informazioni) di InfoWatch. Una caratteristica dell'implementazione è stata il posizionamento della funzione di bilanciamento su uno dei server "da combattimento".
Uno dei problemi che abbiamo riscontrato è stata l'impossibilità di utilizzare Source NAT (SNAT). Perché questo era necessario e come è stato risolto il problema, lo descriveremo ulteriormente.
Quindi, inizialmente il diagramma logico del sistema esistente appariva così:
Il traffico ICAP, SMTP e gli eventi provenienti dai computer degli utenti sono stati elaborati sul server Traffic Monitor (TM). Allo stesso tempo, il server del database ha gestito facilmente il carico dopo l'elaborazione degli eventi sulla TM, ma il carico sulla TM stessa era pesante. Ciò era evidente dalla comparsa di una coda di messaggi sul server Device Monitor (DM), nonché dal carico della CPU e della memoria sul TM.
A prima vista, se aggiungessimo un altro server TM a questo schema, sarebbe possibile passare ad esso sia ICAP che DM, ma abbiamo deciso di non utilizzare questo metodo, poiché la tolleranza agli errori era ridotta.
Descrizione della soluzione
Nel processo di ricerca di una soluzione adeguata, abbiamo optato per il software libero con . Perché keepalived risolve il problema della creazione di un cluster di failover e può gestire anche il bilanciatore LVS.
Ciò che volevamo ottenere (ridurre il carico su TM e mantenere l'attuale livello di tolleranza ai guasti) avrebbe dovuto funzionare secondo il seguente schema:
Durante il controllo della funzionalità, è emerso che l'assembly RedHat personalizzato installato sui server non supporta SNAT. Nel nostro caso, abbiamo pianificato di utilizzare SNAT per garantire che i pacchetti in arrivo e le risposte ad essi vengano inviati dallo stesso indirizzo IP, altrimenti otterremmo la seguente immagine:
Questo è inaccettabile. Ad esempio, un server proxy, dopo aver inviato pacchetti a un indirizzo IP virtuale (VIP), si aspetterà una risposta da VIP, ma in questo caso arriverà da IP2 per le sessioni inviate al backup. È stata trovata una soluzione: era necessario creare un'altra tabella di routing sul backup e connettere due server TM con una rete separata, come mostrato di seguito:
Impostazioni
Implementeremo uno schema di due server con servizi ICAP, SMTP, TCP 9100 e un bilanciatore di carico installato su uno di essi.
Abbiamo due server RHEL6, dai quali sono stati rimossi i repository standard e alcuni pacchetti.
Servizi che dobbiamo bilanciare:
•ICAP – tcp 1344;
• SMTP – TCP 25.
Servizio di trasmissione traffico da DM – tcp 9100.
Per prima cosa dobbiamo pianificare la rete.
Indirizzo IP virtuale (VIP):
• IP: 10.20.20.105.
ServerTM6_1:
• IP esterno: 10.20.20.101;
• IP interno: 192.168.1.101.
ServerTM6_2:
• IP esterno: 10.20.20.102;
• IP interno: 192.168.1.102.
Quindi abilitiamo l'inoltro IP su due server TM. Come farlo è descritto su RedHat .
Decidiamo quale dei server che avremo sarà quello principale e quale sarà quello di backup. Lascia che il master sia TM6_1, il backup sia TM6_2.
Durante il backup creiamo una nuova tabella di routing del bilanciatore e regole di routing:
[root@tm6_2 ~]echo 101 balancer >> /etc/iproute2/rt_tables
[root@tm6_2 ~]ip rule add from 192.168.1.102 table balancer
[root@tm6_2 ~]ip route add default via 192.168.1.101 table balancerI comandi precedenti funzionano fino al riavvio del sistema. Per garantire che i percorsi vengano preservati dopo un riavvio, è possibile inserirli in /etc/rc.d/rc.local, ma meglio attraverso il file delle impostazioni /etc/sysconfig/network-scripts/route-eth1 (nota: qui viene utilizzata una sintassi diversa).
Installa keepalived su entrambi i server TM. Abbiamo utilizzato rpmfind.net come fonte di distribuzione:
[root@tm6_1 ~]#yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/keepalived-1.2.13-5.el6_6.x86_64.rpmNelle impostazioni keepalive, assegniamo uno dei server come master, l'altro come backup. Quindi impostiamo VIP e servizi per il bilanciamento del carico. Il file delle impostazioni si trova solitamente qui: /etc/keepalived/keepalived.conf.
Impostazioni per TM1 Server
vrrp_sync_group VG1 {
group {
VI_1
}
}
vrrp_instance VI_1 {
state MASTER
interface eth0
lvs_sync_daemon_inteface eth0
virtual_router_id 51
priority 151
advert_int 1
authentication {
auth_type PASS
auth_pass example
}
virtual_ipaddress {
10.20.20.105
}
}
virtual_server 10.20.20.105 1344 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 1344 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 1344
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 1344 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 1344
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 10.20.20.105 25 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 25 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 25
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 25 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 25
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 10.20.20.105 9100 {
delay_loop 6
lb_algo wrr
lb_kind NAT
protocol TCP
real_server 192.168.1.101 9100 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 9100
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.1.102 9100 {
weight 1
TCP_CHECK {
connect_timeout 3
connect_port 9100
nb_get_retry 3
delay_before_retry 3
}
}
}Impostazioni per TM2 Server
vrrp_sync_group VG1 {
group {
VI_1
}
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
lvs_sync_daemon_inteface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass example
}
virtual_ipaddress {
10.20.20.105
}
}Installiamo LVS sul master, che bilancerà il traffico. Non ha senso installare un bilanciatore per il secondo server, poiché nella configurazione abbiamo solo due server.
[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpmIl bilanciatore sarà gestito da keepalived, che abbiamo già configurato.
Per completare il quadro, aggiungiamo keepalived all'avvio automatico su entrambi i server:
[root@tm6_1 ~]#chkconfig keepalived onconclusione
Controllo dei risultati
Eseguiamo keepalived su entrambi i server:
service keepalived startVerifica della disponibilità di un indirizzo virtuale VRRP
Assicuriamoci che il VIP sia su master:
E non c'è alcun VIP nel backup:
Utilizzando il comando ping, controlleremo la disponibilità del VIP:
Ora puoi spegnere master ed eseguire nuovamente il comando ping.
Il risultato dovrebbe rimanere lo stesso e durante il backup vedremo VIP:
Verifica del bilanciamento del servizio
Prendiamo ad esempio SMTP. Lanciamo due connessioni al 10.20.20.105 contemporaneamente:
telnet 10.20.20.105 25Sul master dovremmo vedere che entrambe le connessioni sono attive e connesse a server diversi:
[root@tm6_1 ~]#watch ipvsadm –Ln
Pertanto, abbiamo implementato una configurazione tollerante agli errori dei servizi TM installando un bilanciatore su uno dei server TM. Per il nostro sistema, ciò ha ridotto della metà il carico sulla TM, il che ha permesso di risolvere il problema della mancanza di ridimensionamento orizzontale utilizzando il sistema.
Nella maggior parte dei casi, questa soluzione viene implementata rapidamente e senza costi aggiuntivi, ma a volte esistono una serie di limitazioni e difficoltà nella configurazione, ad esempio nel bilanciamento del traffico UDP.
Fonte: habr.com