Sissejuhatus

ZEVENET ADC-s toetatud nelja võrguaadressi tõlkimise (NAT) tüübi hulgas on meil Allikas NAT (NAT), Dünaamiline NAT (DNAT), Serveri otsetagastus (DSR)ja kodakondsuseta DNAT. Selles artiklis käsitleme Direct Server Returni (DSR) keerukust, uurime selle arhitektuuri, eeliseid ja võimalikke takistusi. Samuti seadistame DSR-i ZEVENET ADC-s.

DSR on see, kui taustarakendusserverid vastavad päringu vastuvõtmisel ja töötlemisel otse kliendi päringutele. Aga kuidas see toimib? Siit saate teada, kuidas suhtlus serverite ja veebiklientide vahel toimub.

DSR-i suhtlusvoog

Kliendi soov: Klient algatab päringu, näiteks pääseb juurde voogesitatavatele meediumifailidele või saadab andmeid rakendusserveritele ZEVENET ADC kaudu.

Koormuse tasakaalustaja koostoime: Pärast päringu saamist ei muuda ZEVENET päringu sisu, välja arvatud Sihtkoha MAC-aadress. MAC-aadress, milleks on muudetud, on päringu töötlemiseks kasutatava taustaserveri oma. Seejärel saadab koormuse tasakaalustaja päringu koormuse tasakaalustamise algoritmi komplekti alusel vastavale taustaserverile.

Taustarakenduse server: Päringu saamisel töötleb taustaserver päringu ja genereerib vastuse.

Otsene vastus: Seejärel saadab taustaserver vastuse otse klientseadmele, viies lõpule sideahela.

Oluline märkus

1. ZEVENET vastab tavaliselt ARP-päringutele taustaserverite nimel, et säilitada algne klient-server side. Seetõttu on õiged ARP-konfiguratsioonid pakettide õige marsruutimise tagamiseks üliolulised.
2. IP-aadressi skeemi tuleb hoolikalt planeerida, et vältida konflikte ning tagada korralik suhtlus klientide ja taustaserverite vahel. Tavaliselt konfigureerime taustaserverid nii, et nende IP-aadressid sarnaneksid L4xNAT-i farmi kasutatavale virtuaalsele IP-le (VIP), kuid taustaprogrammid ei pruugi konfliktide vältimiseks seda ARP-kõnedes teada anda.

Miks kasutada oma võrgu infrastruktuuri jaoks DSR-i?

DSR on muutunud tänapäeva võrguinfrastruktuuris äärmiselt oluliseks, kuna suudab käsitleda tohutuid andmemahtusid ilma suuri kitsaskohti tekitamata. See siin on suur asi. Lisaks skaleeritavusele, mitmekülgsusele, kõrgele saadavusele ja tõrketaluvusele on peamised põhjused, miks DSR eristub, järgmised:

Turboülelaaduriga jõudlus: Kõrvaldades traditsiooniliste marsruutimismeetoditega kaasnevad täiendavad hüpped, vähendab DSR oluliselt latentsust ja pakettide kadu. Võiksime seda seadistust kasutada mängude ja video voogesituse puhul, kus oluliste andmehulkade tõhus edastamine on ülioluline.

Näiteks mitme mängijaga mängudes võimaldab DSR otsesuhtlust mänguklientide ja mänguserverite vahel, ilma et koormuse tasakaalustaja vahendaks iga andmepaketti. See otsesuhtlus võimaldab kiiremini ja tõhusamalt edastada mänguga seotud andmeid, nagu mängija liikumised, tegevused ja värskendused. Selle tulemusena vähendab DSR latentsust, parandab mängukogemust ja aitab kaasa sujuvamale mängule.

Sarnaselt saavad taustaserverid video voogesituses video voogesituse korral videoandmed otse kliendile edastada, ilma neid koormuse tasakaalustaja kaudu suunamata. Eemaldades andmeteelt koormuse tasakaalustaja, minimeerime võimalikud kitsaskohad, tagades vaatajatele sujuva voogesituskogemuse. See on eriti kasulik kvaliteetse või kõrge eraldusvõimega videosisu puhul, kus suurte andmehulkade tõhus käsitlemine on katkematu taasesituse jaoks hädavajalik.

Koormuse tasakaalustaja vähendatud koormus: DSR-iga vabastame koormuse tasakaalustaja, mis haldab tagaserveri tagasiliiklust. See mahalaadimine vähendab oluliselt koormuse tasakaalustaja töötlemiskoormust, võimaldades sellel keskenduda sissetulevate päringute tõhusale jaotamisele. Selle tulemusena saab koormuse tasakaalustaja hakkama suurema liiklusega ja saavutab parema üldise skaleeritavuse.

Marsruutimistabelit pole vaja hooldada: Marsruutimine võib olla keeruline, eriti suuremahulistes võrkudes, millel on mitu alamvõrku ja keerukad marsruutimispoliitikad. Kui tagasiliikluse jaoks marsruutimistabelit ei halda, väldib koormuse tasakaalustaja vajadust käsitleda ja hallata keerulisi marsruutimiskonfiguratsioone, vähendades väärkonfiguratsioonide või marsruutimisega seotud probleemide tõenäosust.

ZEVENETi konfiguratsioonid Linuxi ja Windowsi taustaserverite jaoks

DSR-i lubamiseks peate esmalt konfigureerima 4. kihi virtuaalserveri või L4xNAT-farmi. Lugege see artikkel selle loomiseks.

Nõuded DSR-ile:

1. . virtuaalne IP ja taustaprogrammid peavad olema samas võrgus.
2. . Virtuaalne port ja taustapordi pordid peavad olema samad.
3. Peab konfigureerima taustaprogrammid tagasihelistamine liidesed sama IP-aadressiga kui koormuse tasakaalustajas konfigureeritud VIP ja keelata ARP selles liideses.

Linuxi taustaserverid

# ifconfig lo:0 192.168.0.99 netmask 255.255.255.255 -arp up

Selle käsuga loome virtuaalse võrguliidese lo:0 koos IP-aadressiga 192.168.0.99 ja alamvõrgu mask 255.255.255.255.

. -arp lipp keelab sellel liidesel Address Resolution Protocol (ARP).

Kehtetute ARP-vastuste keelamine taustaprogrammis.

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

See käsk määrab arp_ignore väärtuseks 1 aasta /proc/sys/net/ipv4/conf/all faili. See parameeter määrab, kuidas kernel ARP-päringutele vastab. Selle määramine väärtusele 1 tähendab, et süsteem peaks ignoreerima ARP-päringuid IP-aadresside jaoks, mida pole võrguliideses konfigureeritud.

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

See käsk muudab taustaserverites parameetrit arp_announce. DSR-i konfiguratsioonides arp_announce väärtuseks 2 tagab, et kui taustaserverid vastavad ARP-päringutele, kasutavad nad päringu sihtkoha IP-aadressi lähte-IP-aadressina ARP-vastuses. See säilitab korraliku side taustaserverite ja kliendi vahel, kuna klient loodab saada vastuse IP-aadressilt, millele ta päringu saatis.

Windowsi taustaserverid

1. Avaleht->Seaded->juhtpaneel->Võrgu- ja sissehelistamisühendused.
2. Paremklõpsake oma võrguadapteril ja klõpsake nuppu Kinnisvara.
3. Ainult Internet Protocol tuleb valida (tühista valikud „MS Networksi klient“ ja „Failide ja printerite jagamine“)
4. TCP/IP atribuudid-> Sisestage ZEVENET ADC farmis VIP-i IP-aadress. Vaikelüüs on valikuline. Sisestage mask 255.255.255.255
5. Määrake Interface Metric väärtuseks 254. See konfiguratsioon on vajalik VIP-ile saadetud mis tahes ARP-vastustele vastamise lõpetamiseks
6. press OK ja salvestage muudatused.

Pärast seda konfigureerige hosti turbemudel nii, et see aktsepteeriks NIC-liideses liiklust ZEVENET ADC-st. Lisaks lubage ZEVENET ADC-l liiklust vaikeliidese kaudu saata ja vastu võtta. Avage CMD administraatorina ja täitke kolm pakutavat käsku.

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

Oluline märkus
Muutke võrgukaarti ja looge tagasi oma Windowsi arvuti vaikeliidese nimed.

DSR-i kasutamise väljakutsed

Kuigi Direct Server Return (DSR) pakub palju eeliseid, võib see mõnikord tekitada potentsiaalseid väljakutseid, mida organisatsioonid peavad arvestama ja lahendama. Nende väljakutsete mõistmine aitab DSR-i tõhusalt planeerida ja rakendada. Siin on mõned DSR-iga seotud levinumad väljakutsed:

Asümmeetriline marsruutimine: See tähendab, et edasi- ja tagasitee kulgevad erinevatel marsruutidel. Kuigi sellel võib olla eeliseid, võib asümmeetriline marsruutimine võrgu tõrkeotsingut ja jälgimist keerulisemaks muuta, kuna liiklusvoog ei ole sümmeetriline.

Serveri ühilduvus: Kõik serverid ei toeta DSR-i igat tüüpi rakendustega. Näiteks võime DSR-i teostada ainult Linuxi või Windowsi serveritega, kui kasutame ZEVENETi.

Olekupõhised toimingud: Seansi teabe säilitamisel põhinevate olekupõhiste toimingute puhul võib DSR tekitada probleeme. Kui kasutate muid NAT-tüüpe, töötlevad koormuse tasakaalustajad seansi püsivuse kõiki vorme, kuid DSR-i puhul läheb otsemarsruutimine neist vahendajatest mööda. Üks võimalus sellest mööda hiilida on seansi püsivuse tagamiseks kasutada 4. kihis allika IP-aadressi ja 7. kihis küpsise lisamist.

Võrgu nähtavus ja jälgimine: DSR võib mõjutada võrgu nähtavust ja jälgimist, kuna liiklus möödub koormuse tasakaalustajatest või pöördpuhverserveritest. Seiretööriistad ja -süsteemid, mis põhinevad nende vahendajate liikluskontrollil või pealtkuulamisel, ei pruugi võrguliiklusest täielikku pilti saada. Organisatsioonid võivad rakendada alternatiivseid seirelahendusi, et tagada nähtavus DSR-teede kaudu kulgevale liiklusele.

Juurutamise keerukus: DSR-i rakendamine võib juurutamise ja konfigureerimise ajal veelgi keerukamaks muuta. Õige planeerimine, projekteerimine ja testimine on sujuva rakendamise tagamiseks üliolulised. Näiteks peate võib-olla määrama iga taustaserveri SSL-i mahalaadimiseks ja logimiseks.

Turvakaalutlused: DSR võib tuua kaasa turvaprobleeme, eriti kui liiklus möödub otseselt koormuse tasakaalustajates rakendatud turvameetmetest. Mõnikord peate võib-olla muutma vastuse päiste üksikasju, mis pole DSR-i seadistustega võimalik.

Nende väljakutsetega ennetavalt tegeledes saavad organisatsioonid edukalt rakendada DSR-i ja kasutada selle eeliseid, minimeerides samal ajal võimalikke puudusi.

järeldus

Direct Server Return (DSR) pakub põnevat koormuse tasakaalustamise lähenemisviisi, mis võib rikastada teie infrastruktuuri oluliste eelistega. Laadides maha tagasiliikluse taustaserveritest ja võimaldades neil vastuseid otse klientidele saata, vähendab DSR koormuse tasakaalustaja koormust ja parandab süsteemi üldist skaleeritavust.

Teine eelis võib olla võrgu madalam latentsusaeg, kuna vastused jõuavad klientideni otse, jättes koormuse tasakaalustajast mööda. See võib olla eriti kasulik latentsustundlike rakenduste jaoks, tagades sisu kiirema edastamise ja parema kasutajakogemuse.

Enne DSR-i rakendamist hinnake siiski hoolikalt oma võrguarhitektuuri spetsiifilisi nõudeid ja rakendusvajadusi. Kaaluge selliseid tegureid nagu võrgu topoloogia, marsruutimisprotokollid, vajadus seansi püsivuse järele ja võimalikud sellega seotud väljakutsed.

DSR-i eeliseid ära kasutades saate optimeerida oma infrastruktuuri, et tulla toime kasvava liikluskoormusega ja pakkuda sujuvat kasutuskogemust.