ADC Layer 2

Back

LBL ADC layer 2 è lo funzionalità di bilanciamento a layer 2 che permette di bilanciare connessioni effettuando il DNAT dell’indirizzo IP sorgente.

Per poter utilizzare la funzionalità LBL ADC layer 2 è necessario utilizzare la release LBL 9.9.0 o superiore. Se provenienti da release inferiore a 9.9.0 è necessario eseguire l’update a nuova release con l’utility messa a disposizione sul sito oplon (vedere manuale LBL_GDG_InstallUpdate) ed eseguire l’update del sistema operativo attraverso connessione Internet.

Gestione pacchetti layer 2

LBL ADC layer 2 utilizza il sistema di accodamento di routing dei pacchetti del kernel che si impostano attraverso i comandi iptables per essere poi elaborati da LBL.

Si utilizzano per ogni flusso due code, la prima che riceve i pacchetti dal client attraverso una interfaccia di rete, la seconda riceve i pacchetti di risposta provenienti dagli endpoint attraverso un’altra interfaccia di rete.

Nell’esempio di seguito, due proxy ricevono traffico dall’interno del datacenter in bilanciamento layer 2 e ritornano i pacchetti verso le rispettive interfacce verso il sistema ADC.

Le richieste che provengono dai client verso l’interfaccia enp0s10 escono dall’interfaccia enp0s11 con lo stesso IP del client modificato dall’ADC. Una volta elaborati dai proxy i pacchetti di risposta vengono instradati verso l’ADC che provvede a rimodulare i pacchetti per consegnare la risposta ai client che ne hanno fatto richiesta.

Le porte di richiesta del client e del server possono essere differenti, anch’esse verranno modificate dall’ADC durante lo scambio.

Per creare le code a Layer 2 si deve agire a 2 livelli:

1) Generazione delle code di ingresso e uscita a livello stack IP

2) Impostazione dell’utilizzo delle code da parte dell’ADC per il trattamento dei pacchetti

Creazione code stack IP

Per gestire i pacchetti a layer 2 ed il loro instradamento, LBL ADC utilizza il gestore di code realizzato con iptables.

Per ogni flusso logico LBL ADC utilizza 2 code, la prima associata all’interfaccia di comunicazione con i client, la seconda associata con l’interfaccia di comunicazione verso i servizi. Le code vengono numerate per essere poi utilizzate da LBL ADC.

LBL ADC può gestire innumerevoli flussi associati a innumerevoli code simultaneamente.

Nello schema di seguito si prende ad esempio l’utilizzo della componente a Layer 2 per poter bilanciare e mettere in alta affidabilità due proxy. La coda 0 è associata alla scheda di rete verso i client, la coda 1 è associata alla scheda di rete verso i proxy.

Per eseguire il setup delle code eseguire da root i seguenti comandi.

# iptables -t mangle -A PREROUTING -i enp0s10 -p tcp -s 192.168.43.0/24 -j NFQUEUE --queue-num 0

# iptables -t mangle -A FORWARD -i enp0s17 -p tcp -s 192.168.31.0/24 -j NFQUEUE --queue-num 1

 

Per verificare a basso livello il flusso dei pacchetti utilizzare su due terminali i seguenti comandi applicati alle due code. I comandi visualizzano i flussi dei pacchetti con la loro direzione:

Flusso dati interfaccia verso i client

# tcpdump -i enp0s10 port 80 or port 8080 or port 3128

 

Flusso dati interfaccia verso i servizi

# tcpdump -i enp0s17 port 8080 or port 80 or port 3128

 

Un’altra operazione da effettuare è impostare lo stack socket ad eseguire il forwarding dei pacchetti.

# sysctl net.ipv4.ip_forward=1

 

Per verificare la lista delle code assegnate eseguire:

# iptables -t mangle –L

 

Chain PREROUTING (policy ACCEPT)

target prot opt source destination

NFQUEUE tcp -- 192.168.43.0/24 anywhere NFQUEUE num 0

 

Chain INPUT (policy ACCEPT)

target prot opt source destination

Chain FORWARD (policy ACCEPT)

target prot opt source destination

NFQUEUE tcp -- 192.168.31.0/24 anywhere NFQUEUE num 1

 

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

Chain POSTROUTING (policy ACCEPT)

target prot opt source destination

Per verificare l’attività sulle single code eseguire:

# cat /proc/net/netfilter/nfnetlink_queue

 

0 25214 0 2 65531 0 0 97 1

1 2691274501 0 2 65531 0 0 120 1

a- queue number

b- peer portid: good chance it is process ID of software listening to the queue

c- queue total: current number of packets waiting in the queue

d- copy mode: 0 and 1 only message only provide meta data. If 2 message provide a part of packet of size copy range.

e- copy range: length of packet data to put in message

f- queue dropped: number of packets dropped because queue was full

g- user dropped: number of packets dropped because netlink message could not be sent to userspace. If this counter is not zero, try to increase netlink buffer size. On the application side, you will see gap in packet id if netlink message are lost.

h- id sequence: packet id of last packet

i- 1

Associazione della coda di pacchetti al routing ADC

LBL ADC esegue il forwarding dei pacchetti in DNAT mantenendo nel contempo la sessione. Per associare le code all’elaborazione DNAT ad opera dell’ADC è sufficiente utilizzare dei template già presenti nelle distribuzioni.

Dopo il login andare in: ADC Settings>ADCs>Selezionare i listeners dei templates

Con la lista dei listener template andare in search DNAT

Il search DNAT evidenzia il listener template di associazione code Layer 2.

Eseguire copia del listener template sul modulo, in questo caso A10_LBLGoPlatform:

Ritornando in ADC Settings>ADCs il risultato è il seguente:

Ripetere l’operazione anche per il gruppo di endpoint:

Su search digitare DNAT:

Una volta digitato DNAT copiare l’endpoint grouping template sul modulo, in questo caso A10_LBLGoPlatform:

Copia dell’endpoint grouping sul modulo:

Tornando alla visualizzazione ADC Settings>ADCs la situazione è la seguente:

Salvare le impostazioni effettuate fino ad ora:

Eseguire il salvataggio delle impostazioni proposte:

Indicare il motivo del salvataggio:

Una volta copiato i template Layer 2 sul modulo, associare le code al listener:

ADC Settings>ADCs>Edit del modulo:

Espandere il pannello Listeners e premere il pulsante See details:

Il listener presenterà le seguenti carattristiche: osiLayer impostato a 2; layer2QueueIn impostata a 0 e layerQueueOut impostata a 1. In questo caso non vi sarà necessità di modificare le code in quanto le abbiamo precedentemente generate rispettivamente a 0 e 1.

Si noti anche che l’indicazione dell’indirizzo del listener è a 0.0.0.0 e la porta è a 80. Questi valori non vengono presi in considerazione in quanto sono le code che effettuano la creazione della coda in un determinato NIC con determinati filtri. LBL ADC provvederà comunque in maniera trasparente ad eseguire eventuali port rewriting nel caso i pacchetti dovessero avere delle porte differenti tra i pacchetti ricevuti ed i pacchetti inoltrati verso i servizi.

Il trattamento dell’instradamento verso gli endpoint è perfettamente simili al trattamento del layer 4. Saranno indicati gli indirizzi e le porte a cui rispondono i servizi:

ADC Settings>ADCs>Edit sul modulo interessato>Espansione del pannello Endpoints Grouping>See details

Entrare nel dettaglio del dominio (che in questo caso è vuoto):

Modificare, aggiungere o togliere gli endpoit. In questo caso abbiamo due endpoint che rispondono alla porta 8080.

È Molto importante assegnare dei nomi associativi agli endpoit perché questi ci serviranno per eseguire gli healthcheck e disabilitare il routing in caso di irraggiungibilità di uno o più servizi.

Se il modulo è in stato di running eseguire il reinit.

Impostazione health check dei servizi

Il sistema a layer 2 è in grado di ridirottare le richieste sui servizi superstiti in base alla loro vitalità. Per poter verificare la vitalità dei servizi impostare gli healthcheck attraverso il modulo:

Reliability tools>Services Check> Edit

Dopo la selezione del modulo impostare gli health check sui servizi assegnando i nomi associativi:

Salvare ed eseguire i reinit indicati:

Setup routing lato servizi

Affinché i servizi instradino correttamente i pacchetti provenienti dall’ADC è necessario eseguire il setup del routing nei rispettivi sistemi che contengono i servizi.

Si dovrà forzare, con gli strumenti messi a disposizione dei singoli produttori del sistema operativo o dei prodotti, i pacchetti a ritornare nel NIC di provenienza. Di seguito l’esempio non esaustivo dell’argomento ma utile per poterlo poi interpretare ed adattare nelle singole installazioni:

Impostazione di due tabelle mnemoniche “1 rt_dnatnet” e “2 rt_internet”:

vi /etc/iproute2/rt_tables

#

# reserved values

#

255 local

254 main

253 default

0 unspec

#

# local

#

#1 inr.ruhep

1 rt_dnatnet

2 rt_internet

Impostare da utente root il routing dei pacchetti provenienti dall’ADC e come gateway impostare l?ADC stesso:

# ip route add 192.168.31.0/24 dev enp0s17 src 192.168.31.11 table rt_dnatnet

# ip route add default via 192.168.31.1 dev enp0s17 tab rt_dnatnet

# ip rule add tab rt_dnatnet from 192.168.31.11

 

Per verificare il traffico a basso livello e le direzioni dei pacchetti eseguire il seguente comando:

# tcpdump -i enp0s17 port 80 or port 8080 or port 3128

Supporti e template

A titolo di template, è possibile trovare una serie di script Linux di impostazione del routing sia a livello ADC sia a livello di servizio in:

(LBL_HOME)/legacyBin/Linux/ProxyDNAT

+---CentOSNetConfProxy

| +---System000

| | CentOS_Simmetric.sh

| | CentOS_SimmetricInternet.sh

| | CentOS_SimmetricView.sh

| | ifcfg-BACKEND

| | ifcfg-DNATNET

| | ifcfg-INTERNET_DHCP

| | ifcfg-WIRELESS

| | README.txt

| |

| \---System001

| CentOS_Simmetric.sh

| CentOS_SimmetricInternet.sh

| CentOS_SimmetricView.sh

| ifcfg-BACKEND

| ifcfg-DNATNET

| ifcfg-INTERNET_DHCP

| ifcfg-WIRELESS

| README.txt

|

\---NetConfVAPP

CentOS_NFQUEUE.sh

CentOS_NFQUEUEView0.sh

CentOS_NFQUEUEView1.sh

 

Rendere persistenti le regole di routing

ATTENZIONE:

è necessario che le regole di routing e le impostazione delle code siano rese persistenti e che al riavvio delle singole VAPP o ai singoli sistemi operativi che erogano i servizi siano impostate automaticamente e verificate

Sei interessato alle nostre soluzioni?