Direct Server Return támogatás érkezett az OpenBSD-be

OpenBSD

Nemrég rendezték meg Japánban a n2k8 névre hallgató, hálózatra specializálódott OpenBSD HackAthon-t. A kódfesztivál egyik eredménye, hogy a fejlesztők elkezdtek dolgozni egy új, a pf(4)-hez és a relayd(8)-hez szánt szolgáltatáson. Ez az új szolgáltatás a Direct Server Return (DSR) névre hallgat. A Kanadában nemrég lezárult c2k8-on további tekintélyes mennyiségű fejlesztés készült a kódhoz, így az OpenBSD load balancer-ek már használhatják a DSR-t. De mi is ez?

natvsdsr

Hálózati terhelés-elosztásnál (network load balancing) elosztjuk a hálózati terhelést több erőforrás (node) közt. Tipikus setup, hogy a szolgáltatást egy, a hálózati terhelés-elosztón (Load balancer) beállított virtuális IP-n keresztül érjük el, a load balancer pedig NAT-olja a kéréseket (lásd első ábra) a backend szerverek (Server 1, Server 2) felé. A kérésekre érkező válaszok ebben az esetben a load balancer-en keresztül utaznak vissza a kliens felé (Client). Ez teljesen jól működő megoldás, azonban nem ritka, hogy a visszafelé haladó hálózati forgalom lényegesen nagyobb, mint amit a bejövő kérések generálnak. Például mikor nagyméretű file-okat szolgálunk ki HTTP-n, gyakran látunk csekély bejövő forgalom mellett (kérések a file-ok letöltésére) tekintélyes kimenő forgalmat. Mivel NAT alkalmazása esetén az összes forgalom a hálózati terhelés-elosztónkon megy keresztül, könnyű belátni, hogy maga a load balancer lehet a terhelés-elosztott rendszer szűk keresztmetszete.

És itt jön a képbe a Direct Server Return. Alkalmazásával (kettes kép) jól látszik, hogy a visszafele tartó hálózati forgalom közvetlenül a kliensek felé halad, elkerülve a load balancer-t, amelynek nem kell ezzel a forgalommal foglalkoznia.

A szolgáltatásról bővebb információk, gyorstalpaló tutorial, interjú a fejlesztőkkel, stb. olvasható itt.

( frank | 2008. 06. 18., sze – 17:14 )

Valóban okos megoldás. IMHO nem csökkent a fejlesztés értékén, hogy máshol, más néven már létezett. Azt sehol nem állítják - én nem találtam ilyet a bejelentésben-, hogy ők találták volna ki.

Jobb későn, mint soha. Vagy hamar munka ritkán jó. Van közhely pro dögivel. ;)

( LiRul | 2008. 06. 18., sze – 17:14 )

A teljesség kedvéért, s azoknak akik nem olvassák el a bővebb doksit: ez csak akkor működik, ha a real server-eidnek publikus IP címe is van, s közvetlen (értsd: tűzfalon/útválasztón keresztül) elérik a netet.

Szerintem nem muszáj publikus IP-vel rendelkeznie, elég ha a válaszcsomagokban lecseréli a feladót a terhelés elosztó címére. Erre akkor is szükség lenne, ha van publikus IP címe, mivel a kliens nem a szervert szólítja meg közvetlenül, így nem tőle várja a választ.

Ja, IMHO :-)

Igen, ebben igazad van a router is megteheti az SNAT-ot, csak az ábrán az LB egyben router is.

Az emlékeim és a http://www.linuxvirtualserver.org/VS-DRouting.html szerint is Linux esetén a legjobb megoldás, ha az lo-ra felhúzód aliasként az LB külső IP címét és így a routeren még SNAT-ra sincs szükséged.

Én főleg arra akartam rámutatni, hogy nem kell publikus IP cím feltétlenül, sőt szerintem az a gyakoribb, hogy nincs is publikus címe a valós szervereknek.

( arpi_esp v | 2008. 06. 18., sze – 21:42 )

ize. a kepeken a routernek mi a szerepe? mert mindket oldalan ugyanaz a subnet van... ergo az inkabb switch :)

A'rpi