SNAT vs PBR per il bilanciamento del carico del server

In una configurazione SLB a un braccio, SNAT viene utilizzato per forzare il traffico di ritorno a passare attraverso lo SLB. Questo ha un aspetto negativo: semplicemente che i log web non possono acquisire l'IP client vero a meno che non vengano passati nell'intestazione XFF (X-Forwarded-For) e il web server non sia in grado di registrare.

Un'alternativa è usare PBR (policy based routing) per riportare il traffico di ritorno allo SLB, ma cerco di evitare PBR a meno che non ci sia altra / migliore soluzione sulla piattaforma 6500E con SUP720 / PFC3B - e conosco il particolare Anche la versione IOS può essere un fattore: PBR aggiunge latenza rispetto a fare SNAT supponendo che PBR sia tutto fatto nell'hardware? Se la PBR viene eseguita nell'hardware utilizzando solo i comandi supportati oggi, è possibile che l'aggiornamento di IOS in futuro possa cambiare la PBR in software / commutazione di processo?

Oggi, i nostri sistemi di bilanciamento del carico hanno la maggior parte delle VLAN dei server Web direttamente dietro di loro - g / w predefinito che punta a SLB - e altri server come SQL nelle VLAN non SLB. Tuttavia, questo traffico web sql transita lo SLB. Il nostro obiettivo sarebbe quello di evitare di attraversare lo SLB e di mantenere separato il traffico SQL, mantenendo comunque il client reale nei log web. Preferirei non introdurre complessità nella risoluzione dei problemi con PBR e possibilmente avere questa modifica dall'hardware al software elaborato in futuro. A parte XFF e SNAT menzionati in precedenza, PBR è l'unica opzione qui e qual è il modo migliore per mantenere PBR strettamente configurato?

— generalnetworkerror
fonte

Non sono sicuro al 100% di comprendere la topologia, il tuo server ha due interfacce e hai bisogno di SNAT in modo che il server possa avere un'unica route statica per restituire il traffico di "produzione" all'interfaccia SLB? Ma SNAT nella configurazione 1: N implica stati, che devono sempre essere evitati, PBR è stateless quindi si ridimensiona molto meglio.

— ytti,

Normalmente, sconsiglio il design del bilanciamento del carico con un braccio (o potresti chiamarlo bilanciamento del carico su uno stick) e vado con una sottorete sul lato anteriore per i VIP con bilanciamento del carico e una sottorete sul lato posteriore per il server piscine. I server predefiniti tramite l'interfaccia sul retro del bilanciamento del carico. Questo elimina completamente la necessità di SNAT o PBR.

— Mike Pennington,

A parte il mio commento sulle topologie di bilanciamento del carico ... potresti aggiungere alcuni diagrammi per riferimento, perché alcune delle domande non sono chiare quando non sei sicuro di come sia l'immagine più grande.

— Mike Pennington,

@ytti, la topologia attuale ha SLB in linea con il g / w predefinito dei server che punta a SLB - NIC / server singolo. Abbiamo essenzialmente quello che Mike ha descritto con le VLAN lato client e lato server su due interfacce di SLB ora, ma questa è una domanda sul passaggio a una topologia diversa come una armata in modo che il traffico server-SQL non debba attraversare lo SLB e preferiamo non aggiungere alcuna complessità ai server come NIC doppie con route statiche del server, ecc. Comprendere la latenza di SNAT vs PBR è fondamentale, così come altri progetti che ho perso (come il Direct Server Return descritto in una risposta ).

— generalnetworkerror

Quali server sono? In Linux (o * BSD) è facile da configurare in modo che il pacchetto venga restituito all'interfaccia in cui è arrivato, il che è utile nelle configurazioni SLB (lo usiamo per connettere in modo ridondante i server a due scatole SLB disconnesse, i VIP sono ECMPd quindi entrambi sono caldi, ma potrebbe anche essere di un fornitore diverso in quanto ignari l'uno dell'altro).

— ytti,

Risposte:

PBR aggiunge latenza rispetto a SNAT supponendo che PBR sia tutto realizzato nell'hardware?

Sup720 supporta PBR in HW , la latenza aggiuntiva (se presente) è trascurabile perché PBR non aggiunge più accodamento dell'interfaccia. Penso che PBR renderebbe le cose più difficili di quanto debbano essere (e non sono ancora nemmeno sicuro che funzionerebbe ... i dettagli di quell'opzione non sono del tutto chiari)

A parte XFF e SNAT menzionati in precedenza, PBR è l'unica opzione qui e qual è il modo migliore per mantenere PBR strettamente configurato?

PBR non è l'unica opzione. L'opzione proposta è un po 'poco chiara, ma PBR normalmente si riduce a nient'altro che a un modo più elaborato per eseguire il routing statico.

In genere questa è la migliore topologia per servizi con bilanciamento del carico che richiedono query SQL ...

Metti i tuoi VIP su una sottorete frontale ... 172.16.1.0/24 nel diagramma
Inserire i pool di server in una sottorete sul lato posteriore ... 172.16.2.0/24 nel diagramma
Inserisci le tue query SQL su un'altra interfaccia ... 172.16.3.0/24 nel diagramma. Aggiungi una seconda interfaccia a tutti i server che richiedono query SQL. Effettua tutte le tue query SQL agli indirizzi su questa sottorete. Questa topologia funziona sia per Unix che per Windows, poiché fai affidamento solo su ARP o route host (a seconda delle tue preferenze) per la connettività SQL.

Diagramma:

LB con rete di query SQL

Questa topologia presenta ulteriori vantaggi:

Separa le interfacce SQL dal traffico Web, dal momento che le query SQL sono esplose e possono finire nel traffico web congestionato.
Fornisce MTU diversi per i servizi con bilanciamento del carico (che di solito devono rimanere a 1500 o inferiore, se transitano su Internet) e per i servizi SQL (che favoriscono i frame jumbo).

Qualsiasi topologia con bilanciamento del carico con un braccio è un'opzione meno desiderabile poiché si finisce per dimezzare il rendimento massimo a causa della topologia con un braccio.

EDIT per domande su commutazione HW vs SW su Sup720

Questo è un argomento profondo, ma fornirò la versione di riepilogo ... Sup720 applica un ACL in ogni direzione (ingresso / uscita) e l'ACL deve adattarsi al TCAM in base a qualsiasi algoritmo di unione che la piattaforma ha scelto. Il Feature Manager di Sup720 (ad es. Fm) è responsabile della mediazione delle funzionalità in TCAM e della segnalazione se si dispone di una adiacenza punt (che significa commutazione SW) o se la combinazione di protocollo e direzione è commutata in HW. Per isolare se

Innanzitutto, identifica tutte le interfacce Layer3 di ingresso e uscita che il traffico PBR potrebbe transitare
Quindi, esaminare l'output di show fm fie int <L3_intf_name> | i ^Interf|Result|Flow|Config(è necessario guardare entrambe le direzioni di ingresso e uscita per tutte le interfacce nel passaggio 1 ). Il tuo traffico verrà cambiato HW se i valori in CAPS corrispondono ai valori che vedi sotto ... nota che l'output del comando che sto usando è molto simile a quello che vedi in show fm fie summary...

Tx.Core01#sh fm fie int Vl220 | i ^Interf|Result|Flow|Config
Interface Vl220:
 Flowmask conflict status for protocol IP : FIE_FLOWMASK_STATUS_SUCCESS      <--- in HW
 Flowmask conflict status for protocol OTHER : FIE_FLOWMASK_STATUS_SUCCESS   <--- in HW
 Flowmask conflict status for protocol IPV6 : FIE_FLOWMASK_STATUS_SUCCESS    <--- in HW
Interface Vl220 [Ingress]:
 FIE Result for protocol IP : FIE_SUCCESS_NO_CONFLICT                        <--- in HW
 Features Configured : V4_DEF   - Protocol : IP
 FIE Result for protocol OTHER : FIE_SUCCESS_NO_CONFLICT                     <--- in HW
 Features Configured : OTH_DEF   - Protocol : OTHER
 FIE Result for protocol IPV6 : FIE_SUCCESS_NO_CONFLICT                      <--- in HW
 Features Configured : V6_DEF   - Protocol : IPV6
Interface Vl220 [Egress]:
 No Features Configured
No IP Guardian Feature Configured
No IPv6 Guardian Feature Configured
No QoS Feature Configured
Tx.Core01#

L'interfaccia sopra non mostra output in uscita, ma questo è irrilevante ... l'output è simile alla direzione Ingress. Ricky Micky ha scritto un'eccezionale spiegazione dell '"interfaccia f fm fie" se desideri maggiori dettagli sulla dinamica delle banche TCAM / i risultati della fusione.

— Mike Pennington
fonte

Avevo già eliminato questa opzione di progettazione in quanto richiede l'adiacenza L2 tra il livello front-end e il livello back-end, oltre a non ridimensionare bene per le nostre VLAN back-end multiple e a causa della potenziale necessità di posizionare un firewall (non trasparente ) tra i livelli. Tuttavia, è ancora un'opzione eccellente per coloro che non hanno queste preoccupazioni. Un buon punto sugli MTU.

— generalnetworkerror

A corto di consulenza sulla documentazione di PBR per specifiche versioni di IOS per sapere se una determinata funzione PBR innesca la necessità che venga eseguita nel software, questo può essere determinato all'interno di IOS? Questo è ciò che intendevo per "strettamente configurato" per PBR per mantenerlo operativo all'interno dell'hardware.

— generalnetworkerror

@generalnetworkerror, su quale hardware vuoi eseguire PBR? Se Sup720 / Sup2T, non è così difficile identificare se stai cambiando in HW vs SW ... abbiamo bisogno di più dettagli per aiutarti. In effetti, se non ti dispiacesse un diagramma di come funziona questo concetto PBR sarebbe davvero utile

— Mike Pennington

SUP720 / PFC3B ... cercando di vedere come è possibile determinare dalla CLI se una determinata funzione PBR ha forzato questo passaggio in commutazione s / w

— generalnetworkerror

@generalnetworkerror, sh fm fie summary... o leggi la mia risposta per maggiori informazioni ...

— Mike Pennington,

Se il bilanciamento del carico lo supporta, Direct Server Return farà anche ciò che desideri. Deve essere supportato dal bilanciamento del carico e ci sono alcuni problemi del sistema operativo. Implica l'inserimento di interfacce "loopback" in ciascun server che hanno tutte l'indirizzo IP del VIP, il bilanciamento del carico pur avendo gli indirizzi del server reale utilizza solo l'indirizzo MAC del server reale per inoltrare il pacchetto, poiché il server ha l'interfaccia di loopback con il VIP in esso, il server accetta il pacchetto.

È necessario consultare il documento del fornitore LB specifico e i team del server devono essere in grado di gestire l'adattatore virtuale (non utilizziamo questa funzione perché non pensiamo che il nostro provisioning automatizzato del server possa gestire un adattatore loopback MS.

Ma questo non usa NAT in LB e non devi fare PBR.

— fredpbaker
fonte