Introduzione #

Tra i quattro tipi di Network Address Translation (NAT) supportati in RELIANOID ADC, abbiamo Fonte NAT (NAT), NAT dinamico(DNAT), Ritorno diretto al server (DSR)e DNAT apolideIn questo articolo, approfondiremo le complessità di Direct Server Return (DSR), esplorandone l'architettura, i vantaggi e i potenziali ostacoli. Imposteremo anche DSR in Relianoid ADC.

DSR è quando i server delle applicazioni back-end rispondono direttamente alle richieste del client dopo aver ricevuto ed elaborato una richiesta. Ma come funziona? Ecco come scorre la comunicazione tra i server e i client web..

Flusso di comunicazione DSR #

Richiesta del cliente: Un client avvia una richiesta, ad esempio l'accesso a file multimediali in streaming o l'invio di dati ai server applicativi tramite Relianoid ADC.

Interazione del bilanciamento del carico: Dopo aver ricevuto la richiesta, Relianoid non modifica il contenuto della richiesta, ad eccezione del Indirizzo MAC di destinazione. L'indirizzo MAC modificato è quello del server back-end per elaborare la richiesta. Il sistema di bilanciamento del carico inoltra quindi la richiesta al server back-end appropriato in base all'algoritmo di bilanciamento del carico impostato.

Server applicazioni di back-end: Dopo aver ricevuto la richiesta, il server back-end elabora la richiesta e genera una risposta.

Risposta diretta: Il server back-end invia quindi la risposta direttamente al dispositivo client, completando il ciclo di comunicazione.

Nota importante

1. Relianoid risponde in genere alle richieste ARP per conto dei server backend per preservare la comunicazione client-server originale. Pertanto, le configurazioni ARP appropriate sono fondamentali per garantire il corretto routing dei pacchetti.
2. È necessario pianificare attentamente lo schema di indirizzamento IP per evitare conflitti e garantire una corretta comunicazione tra client e server back-end. Di solito configuriamo i server di backend in modo che abbiano indirizzi IP simili all'IP virtuale (VIP) utilizzato dalla farm L4xNAT, ma i backend potrebbero non annunciarlo nelle chiamate ARP per evitare conflitti.

Perché utilizzare DSR per la tua infrastruttura di rete #

DSR è diventato estremamente importante nell'odierna infrastruttura di rete grazie alla sua capacità di gestire enormi quantità di dati senza causare gravi colli di bottiglia. Questo, qui, è un grosso problema. Oltre a scalabilità, versatilità, alta disponibilità e tolleranza ai guasti, i motivi principali per cui DSR si distingue è dovuto a:

Prestazioni turbo: Eliminando gli hop aggiuntivi introdotti dai metodi di routing tradizionali, DSR riduce significativamente la latenza e la perdita di pacchetti. Potremmo utilizzare questa configurazione nei giochi e nello streaming video, dove la consegna efficiente di blocchi di dati sostanziali è fondamentale.

Ad esempio, nei giochi multiplayer, DSR consente la comunicazione diretta tra client di gioco e server di gioco senza che il bilanciamento del carico media ogni pacchetto di dati. Questa comunicazione diretta consente una trasmissione più rapida ed efficiente dei dati relativi al gioco, come i movimenti dei giocatori, le azioni e gli aggiornamenti. Di conseguenza, DSR riduce la latenza, migliora l'esperienza di gioco e contribuisce a un gameplay più fluido.

Allo stesso modo, nello streaming video, quando un client richiede un flusso video, i server back-end possono trasmettere direttamente i dati video al client senza instradarli attraverso il bilanciamento del carico. Rimuovendo il bilanciamento del carico nel percorso dei dati, riduciamo al minimo i potenziali colli di bottiglia, garantendo un'esperienza di streaming senza interruzioni per gli spettatori. Ciò è particolarmente vantaggioso per i contenuti video di alta qualità o ad alta risoluzione, in cui la gestione efficiente di grandi blocchi di dati è essenziale per una riproduzione ininterrotta.

Carico ridotto sul bilanciamento del carico: Con DSR, alleggeriamo il bilanciamento del carico che gestisce il traffico di ritorno dal server back-end. Questo offload riduce significativamente il carico di elaborazione sul sistema di bilanciamento del carico, consentendogli di concentrarsi sulla distribuzione efficiente delle richieste in entrata. Di conseguenza, il sistema di bilanciamento del carico gestirà un volume di traffico più elevato e otterrà una migliore scalabilità complessiva.

Non è necessario mantenere una tabella di routing: Il routing può essere complesso, soprattutto nelle reti su larga scala con più sottoreti e politiche di routing complesse. Non mantenendo una tabella di instradamento per il traffico di ritorno, il sistema di bilanciamento del carico evita la necessità di gestire configurazioni di instradamento complesse, riducendo le possibilità di configurazioni errate o problemi relativi all'instradamento.

Configurazioni Relianoid per server backend Linux e Windows #

Per abilitare DSR, devi innanzitutto configurare un server virtuale di livello 4 o una farm L4xNAT. Leggere questo articolo per crearne uno.

Requisiti per DSR: #

1. Migliori IP virtuale e i backend devono trovarsi nella stessa rete.
2. Migliori Porta virtuale e le porte back-end devono essere le stesse.
3. Bisogna configurare i backend loopback interfacce con lo stesso indirizzo IP del VIP configurato nel bilanciamento del carico e disabilitare ARP in questa interfaccia.

Server back-end Linux #

# ifconfig lo:0 192.168.0.99 maschera di rete 255.255.255.255 -arp up

Con questo comando, creiamo un'interfaccia di rete virtuale lo:0 con l'indirizzo IP 192.168.0.99 e una subnet mask di 255.255.255.255.

Migliori -arp flag disabilita il protocollo ARP (Address Resolution Protocol) su questa interfaccia.

Disabilitazione delle risposte ARP non valide nel back-end. #

# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

Questo comando imposta il valore di arp_ignore a 1 nella /proc/sys/net/ipv4/conf/all file. Questo parametro determina come il kernel risponde alle richieste ARP. Impostandolo su 1, il sistema deve ignorare le richieste ARP per gli indirizzi IP non configurati sull'interfaccia di rete.

# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

Questo comando modifica il parametro arp_announce sui server back-end. Nelle configurazioni DSR, impostando arp_announce su 2 garantisce che quando i server back-end rispondono alle richieste ARP, utilizzino l'indirizzo IP di destinazione della richiesta come indirizzo IP di origine nella risposta ARP. Ciò mantiene una corretta comunicazione tra i server back-end e il client, poiché il client si aspetta di ricevere la risposta dall'indirizzo IP a cui ha inviato la richiesta.

Server di back-end Windows #

1. Inizio->Impostazioni profilo->Pannello di controllo->Connessioni di rete e remote.
2. Fare clic con il tasto destro sulla scheda di rete e fare clic Proprietà a Confronto.
3. A soli Internet Protocol deve essere selezionato (deselezionare "Client per reti MS" e "Condivisione file e stampanti")
4. Proprietà TCP/IP-> Inserisci l'indirizzo IP del VIP nella farm ADC Relianoid. Il gateway predefinito è facoltativo. Inserisci la maschera 255.255.255.255
5. Impostare Metrica interfaccia su 254. Questa configurazione è necessaria per interrompere la risposta a qualsiasi risposta ARP al VIP
6. Stampa OK e salvare le modifiche.

Dopo, configura il modello di sicurezza Host per accettare il traffico da Relianoid ADC sull'interfaccia NIC. Inoltre, consenti a Relianoid ADC di inviare e ricevere traffico tramite l'interfaccia NIC predefinita. Apri CMD come amministratore ed esegui i tre comandi forniti.

interfaccia netsh ipv4 imposta NIC interfaccia debolehostreceive=abilitato interfaccia netsh ipv4 imposta loopback interfaccia debolehostreceive=abilitato interfaccia netsh ipv4 imposta loopback interfaccia debolehostsend=abilitato

Nota importante
Cambia la scheda NIC e torna ai nomi di interfaccia predefiniti del tuo computer Windows.

Sfide dell'uso del DSR #

Sebbene Direct Server Return (DSR) offra numerosi vantaggi, a volte può presentare potenziali sfide che le organizzazioni devono considerare e affrontare. Comprendere queste sfide aiuterà a pianificare e implementare la DSR in modo efficace. Ecco alcune sfide comuni associate al DSR:

Instradamento asimmetrico: Ciò significa che i percorsi di andata e ritorno prendono percorsi diversi. Sebbene ciò possa avere dei pregi, il routing asimmetrico può complicare la risoluzione dei problemi e il monitoraggio della rete poiché il flusso del traffico non è simmetrico.

Compatibilità server: Non tutti i server supporteranno DSR con tutti i tipi di applicazioni. Ad esempio, potremmo eseguire DSR solo con server Linux o Windows quando utilizziamo Relianoid.

Operazioni con stato: Per le operazioni con stato che si basano sul mantenimento delle informazioni sulla sessione, DSR può porre problemi. Quando si utilizzano altri tipi di NAT, i sistemi di bilanciamento del carico gestiscono tutte le forme di persistenza della sessione, ma con DSR il routing diretto ignora questi intermediari. Un modo per aggirare questo problema è utilizzare l'indirizzo IP di origine al livello 4 e l'inserimento di cookie al livello 7 per la persistenza della sessione.

Visibilità e monitoraggio della rete: DSR può influire sulla visibilità e sul monitoraggio della rete poiché il traffico ignora i bilanciamenti del carico o i proxy inversi. Gli strumenti ei sistemi di monitoraggio che si basano sull'ispezione o l'intercettazione del traffico presso questi intermediari potrebbero non acquisire il quadro completo del traffico di rete. Le organizzazioni possono implementare soluzioni di monitoraggio alternative per garantire la visibilità del traffico che scorre attraverso i percorsi DSR.

Complessità di distribuzione: L'implementazione di DSR può introdurre ulteriore complessità durante la distribuzione e la configurazione. Una corretta pianificazione, progettazione e test sono fondamentali per garantire un'implementazione senza intoppi. Ad esempio, potrebbe essere necessario impostare ciascun server back-end per eseguire l'offload e la registrazione SSL.

Considerazioni sulla sicurezza: DSR può introdurre problemi di sicurezza, in particolare quando il traffico aggira direttamente le misure di sicurezza implementate nei bilanciatori del carico. A volte potrebbe essere necessario modificare i dettagli delle intestazioni di risposta, cosa impossibile con le impostazioni DSR.

Affrontando in modo proattivo queste sfide, le organizzazioni possono implementare con successo la DSR e sfruttarne i vantaggi riducendo al minimo i potenziali inconvenienti.

Conclusione #

Direct Server Return (DSR) presenta un accattivante approccio di bilanciamento del carico con il potenziale per arricchire la tua infrastruttura con vantaggi significativi. Scaricando il traffico di ritorno dai server back-end e consentendo loro di inviare risposte direttamente ai client, DSR riduce il carico sul bilanciamento del carico e migliora la scalabilità complessiva del sistema.

Un altro vantaggio potrebbe essere una minore latenza di rete poiché le risposte prendono un percorso più diretto verso i client, aggirando il bilanciamento del carico. Ciò può essere particolarmente vantaggioso per le applicazioni sensibili alla latenza, garantendo una consegna più rapida dei contenuti e una migliore esperienza utente.

Tuttavia, prima di implementare DSR, valuta attentamente i requisiti specifici dell'architettura di rete e le esigenze dell'applicazione. Considera fattori come la topologia di rete, i protocolli di routing, la necessità di persistenza della sessione e le potenziali sfide associate.

Sfruttando i vantaggi di DSR, puoi ottimizzare la tua infrastruttura per gestire carichi di traffico crescenti e offrire un'esperienza utente senza problemi.