Introduktion

Blandt de fire typer netværksadresseoversættelse (NAT), der understøttes i ZEVENET ADC, har vi Kilde NAT (NAT), Dynamisk NAT(DNAT), Direkte serverretur (DSR)og statsløs DNAT. I denne artikel vil vi dykke ned i forviklingerne ved Direct Server Return (DSR), og udforske dens arkitektur, fordele og potentielle forhindringer. Vi vil også opsætte DSR i ZEVENET ADC.

DSR er, når backend-applikationsservere reagerer direkte på klientens anmodninger ved modtagelse og behandling af en anmodning. Men hvordan virker dette? Her er hvordan kommunikationen flyder mellem servere og webklienter..

DSR Kommunikationsflow

Kundeanmodning: En klient starter en anmodning, såsom at få adgang til streambare mediefiler eller sende data til applikationsservere via ZEVENET ADC.

Load balancer interaktion: Ved modtagelse af anmodningen ændrer ZEVENET ikke indholdet af anmodningen undtagen Destinations MAC-adresse. Den MAC-adresse, der er ændret til, er den for backend-serveren til at behandle anmodningen. Belastningsbalanceren videresender derefter anmodningen til den relevante backend-server baseret på belastningsbalanceringsalgoritmesættet.

Backend applikationsserver: Efter modtagelse af anmodningen behandler backend-serveren anmodningen og genererer et svar.

Direkte svar: Backend-serveren sender derefter svaret direkte til klientenheden og fuldender kommunikationsløkken.

Vigtigt

1. ZEVENET svarer typisk på ARP-anmodninger på vegne af backend-serverne for at bevare den oprindelige klient-server-kommunikation. Derfor er korrekte ARP-konfigurationer afgørende for at sikre korrekt routing af pakker.
2. Man skal nøje planlægge IP-adresseringsskemaet for at undgå konflikter og sikre korrekt kommunikation mellem klienter og backend-servere. Vi konfigurerer normalt backend-servere til at have IP-adresser, der ligner den virtuelle IP (VIP), der bruges af L4xNAT-farmen, men backends annoncerer det muligvis ikke i ARP-kald for at undgå konflikter.

Hvorfor bruge DSR til din netværksinfrastruktur

DSR er blevet ekstremt vigtigt i nutidens netværksinfrastruktur på grund af dets evne til at håndtere enorme mængder data uden at forårsage store flaskehalse. Det her er en stor ting. Udover skalerbarhed, alsidighed, høj tilgængelighed og fejltolerance, er hovedårsagerne til, at DSR skiller sig ud på grund af:

Turboladet ydeevne: Ved at eliminere de ekstra hop, der introduceres af traditionelle routingmetoder, reducerer DSR forsinkelse og pakketab betydeligt. Vi kunne bruge denne opsætning i spil og videostreaming, hvor effektiv levering af betydelige datastykker er afgørende.

For eksempel i multiplayer-spil muliggør DSR direkte kommunikation mellem spilklienter og spilservere, uden at load balanceren formidler hver datapakke. Denne direkte kommunikation muliggør hurtigere og mere effektiv transmission af spilrelaterede data, såsom spillerbevægelser, handlinger og opdateringer. Som et resultat reducerer DSR latens, forbedrer spiloplevelsen og bidrager til et mere jævnt gameplay.

Tilsvarende, i videostreaming, når en klient anmoder om en videostream, kan backend-serverne direkte transmittere videodataene til klienten uden at dirigere dem gennem belastningsbalanceren. Ved at fjerne belastningsbalanceren i datastien minimerer vi potentielle flaskehalse, hvilket sikrer en problemfri streamingoplevelse for seerne. Dette er især fordelagtigt for videoindhold af høj kvalitet eller høj opløsning, hvor effektiv håndtering af store datastykker er afgørende for uafbrudt afspilning.

Reduceret belastning på Load Balancer: Med DSR aflaster vi load balancer, der håndterer returtrafik fra backend-serveren. Denne aflastning reducerer behandlingsbyrden på belastningsbalanceren betydeligt, så den kan fokusere på effektivt at distribuere indgående anmodninger. Som et resultat vil load balanceren håndtere en større mængde trafik og opnå bedre overordnet skalerbarhed.

Ingen grund til at vedligeholde en routingtabel: Routing kan være komplekst, især i store netværk med flere undernet og indviklede routingpolitikker. Ved ikke at vedligeholde en routingtabel for returtrafik, undgår load balanceren behovet for at håndtere og administrere komplekse routing-konfigurationer, hvilket reducerer chancerne for fejlkonfigurationer eller routing-relaterede problemer.

ZEVENET-konfigurationer til Linux- og Windows-backend-servere

For at aktivere DSR skal du først konfigurere en virtuel lag 4-server eller en L4xNAT-farm. Læs denne artikel for at oprette en.

Krav til DSR:

1. virtuel IP og backends skal være i samme netværk.
2. Virtual Port og Backend-portene skal være de samme.
3. Man skal konfigurere backends loopback grænseflader med samme IP-adresse som VIP, der er konfigureret i belastningsbalanceren og deaktiver ARP i denne grænseflade.

Linux backend-servere

# ifconfig lo:0 192.168.0.99 netmask 255.255.255.255 -arp up

Med denne kommando opretter vi en virtuel netværksgrænseflade lo:0 med IP-adressen 192.168.0.99 og en subnetmaske af 255.255.255.255.

-arp flag deaktiverer Address Resolution Protocol (ARP) på denne grænseflade.

Deaktiverer ugyldige ARP-svar i backend.

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

Denne kommando indstiller værdien af ​​arp_ignore til 1 i /proc/sys/net/ipv4/conf/all fil. Denne parameter bestemmer, hvordan kernen reagerer på ARP-anmodninger. Indstilling til 1 betyder, at systemet skal ignorere ARP-anmodninger for IP-adresser, der ikke er konfigureret på netværksgrænsefladen.

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

Denne kommando ændrer parameteren arp_announce på backend-serverne. I DSR-konfigurationer indstilles arp_announce til 2 sikrer, at når backend-serverne svarer på ARP-anmodninger, bruger de destinations-IP-adressen for anmodningen som kilde-IP-adressen i ARP-svaret. Dette opretholder korrekt kommunikation mellem backend-serverne og klienten, da klienten forventer at modtage svaret fra den IP-adresse, den sendte anmodningen til.

Windows backend-servere

1. Starten->Indstillinger->kontrol panel->Netværks- og opkaldsforbindelser.
2. Højreklik på din netværksadapter og klik Ejendomme.
3. Kun Internet Protocol skal vælges (fjern markeringen af ​​"Client for MS Networks" og "Fil and Printer Sharing")
4. TCP/IP-egenskaber-> Indtast IP-adressen på VIP'en i ZEVENET ADC-farmen. Standard-gatewayen er valgfri. Indtast masken 255.255.255.255
5. Indstil Interface Metric til 254. Denne konfiguration er nødvendig for at stoppe med at svare på ethvert ARP-svar til VIP'en
6. Presse OK og gem ændringerne.

Konfigurer derefter værtssikkerhedsmodellen til at acceptere trafik fra ZEVENET ADC på NIC-grænsefladen. Tillad desuden ZEVENET ADC at sende og modtage trafik gennem standard NIC-grænsefladen. Åbn CMD som administrator og udfør de tre angivne kommandoer.

netsh interface ipv4 set interface NIC weakhostreceive=enabled
netsh interface ipv4 set interface loopback weakhostreceive=enabled
netsh interface ipv4 set interface loopback weakhostsend=enabled

Vigtigt
Skift NIC og loop tilbage til standardgrænsefladenavnene på din Windows-computer.

Udfordringer ved at bruge DSR

Mens Direct Server Return (DSR) tilbyder adskillige fordele, kan det nogle gange give potentielle udfordringer, som organisationer skal overveje og løse. Forståelse af disse udfordringer vil hjælpe med at planlægge og implementere DSR effektivt. Her er nogle almindelige udfordringer forbundet med DSR:

Asymmetrisk routing: Det betyder, at frem- og returstierne tager forskellige ruter. Selvom dette kan have fordele, kan asymmetrisk routing komplicere netværksfejlfinding og overvågning, da trafikstrømmen ikke er symmetrisk.

Serverkompatibilitet: Ikke alle servere vil understøtte DSR med alle typer applikationer. For eksempel må vi kun udføre DSR med Linux- eller Windows-servere, når vi bruger ZEVENET.

Stateful Operations: For stateful operationer, der er afhængige af vedligeholdelse af sessionsinformation, kan DSR udgøre udfordringer. Når du bruger andre NAT-typer, håndterer belastningsbalancere alle former for sessionsvedholdenhed, men med DSR omgår den direkte routing disse mellemled. En måde at omgå dette på er at bruge Source Ip Address på lag 4 og Cookie Insert på lag 7 for at fortsætte sessionen.

Netværkssynlighed og overvågning: DSR kan påvirke netværkets synlighed og overvågning, da trafik omgår belastningsbalancere eller omvendte proxyer. Overvågningsværktøjer og -systemer, der er afhængige af trafikinspektion eller aflytning hos disse mellemmænd, fanger muligvis ikke det komplette billede af netværkstrafikken. Organisationer kan implementere alternative overvågningsløsninger for at sikre synlighed i trafikken, der flyder gennem DSR-stier.

Implementeringskompleksitet: Implementering af DSR kan introducere yderligere kompleksitet under implementering og konfiguration. Korrekt planlægning, design og test er afgørende for at sikre en problemfri implementering. For eksempel kan det være nødvendigt at indstille hver backend-server til at udføre SSL-aflastning og logning.

Sikkerhedsovervejelser: DSR kan introducere sikkerhedsudfordringer, især når trafikken direkte omgår sikkerhedsforanstaltninger implementeret ved load balancers. Nogle gange skal du muligvis ændre detaljerne i svaroverskrifter, hvilket er umuligt med DSR-opsætninger.

Ved proaktivt at adressere disse udfordringer kan organisationer med succes implementere DSR og udnytte fordelene ved at minimere potentielle ulemper.

Konklusion

Direct Server Return (DSR) præsenterer en fængslende belastningsbalancerende tilgang med potentiale til at berige din infrastruktur med betydelige fordele. Ved at aflaste returtrafikken fra backend-servere og give dem mulighed for at sende svar direkte til klienter, reducerer DSR belastningen på belastningsbalanceren og forbedrer den overordnede systemskalerbarhed.

En anden fordel kunne være lavere netværksforsinkelse, da svar tager en mere direkte vej til klienter og omgår belastningsbalanceren. Dette kan være særligt fordelagtigt for latensfølsomme applikationer, hvilket sikrer hurtigere levering af indhold og forbedret brugeroplevelse.

Vurder dog omhyggeligt de specifikke krav til din netværksarkitektur og applikationsbehov, før du implementerer DSR. Overvej faktorer som netværkstopologi, routingprotokoller, behovet for sessionsvedholdenhed og potentielle tilknyttede udfordringer.

Ved at udnytte DSR's fordele kan du optimere din infrastruktur til at håndtere stigende trafikbelastninger og levere en problemfri brugeroplevelse.