Hogyan osztanak el több száz gigabit forgalmat a Facebook szerverei?

HUP

Egy ekkora rendszer terheléselosztása nem kis feladat. A június 22-i HWSW free! meetupon előad Alex Gartrell, a Facebook szoftvermérnöke is. Alex fő feladata a Linux kernel hálózati képességeinek fejlesztése, a kernelben lévő IPVS ugyanis a Facebook terheléselosztásának is sarokköve. További részletek »

( ricsip v | 2015. 06. 11., cs – 06:04 )

Csak tipp:

1) DNS round robin 5-6 IP cimmel ugyanarra a hosztnevre, igy meg van a redundancia
2) IP anycast-al behirdetni route tablakba minden kontinensen ugyanazt az 5-6 cimet, igy a user mindig a sajat helyzete szerinti legkozelebbi datacenterbe jut
3) combos Radware Alteon HW loadbalancereket a datacenterbe, moge par szaz v. ezer front end szervert, ami moge 100-200.000 backend szervert.

az en abszolut kedvencem a google (jopar evvel ezelotti) megoldasa: a gmail.com domain mx rekordjahoz felvettek vagy 80-100 hosztot, ami azzal a funky mellekhatassal jart, hogy a dns valasz tullepte az 512 byte-ot, igy bizonyos rezolverek beintettek a fakkot. 1-2 napon belul aztan fixalta a G...

--
"what is mostly works", "mods that I describe is choosed" (hrgy84 "nem vagyok anyanyelvi angolos")

Tudom. De azt saccolom, hogy amíg valaki feltölt 1 képet, amit szét kell szórni, addig ugyanonnan letöltenek 100-at, tehát a kifelé menő forgalom jóval nagyobb lesz, mint dc-n belül vagy dc-k között. De utóbbira szerintem amúgyis jobban odafigyelnek, hogy legyen elég dedikált sáv, mert kritikusabb.

--

Pont nem ez a titok. Ha a load balancing technologiat mellettuk masok is fejlesztesztik es tesztelik, az nekik csak jo.
Az o profiljuk a facebook site informaciotartalmanak a kihasznalasa, nem szolgaltatasok beruzemeltetese. Igy nekik az a jo, ha minel olcsobban meg tudjak csinalni.

Ha a Cisco v. Juniper adna elo, akkor valoban igazad lenne.

Azért itt bőven nem csak a hálózati eszközökről van szó.

Már abban nagy belső tudásvagyon van, hogy hány és milyen eszközt hogyan drótoznak össze, hogy meglegyen a kellő sávszél és redundancia. Leginkább az az érdekes, hogy milyen üzleti logika van mögötte, ami abszolút Facebook-specifikus. Tudni kell, melyik kérést melyik node-ok tudják kiszolgálni egyáltalán, ez az elosztás folyamatosan változhat, és még valakinek azt sem árt észrevenni, ha kiküldesz egy kérést, de még a válasz előtt lehal az a node, akinek kiküldted. Földrészenként, percenként jelentősen változhat a terhelés, amit jósolni kell és alkalmazkodni hozzá, stb.

--

OK, kozben rajottem, h te nyertel v. legalabbis fogsz nyerni ugyis.

1. Nem leszek ott.
2. Nyilvan nem megy bele teljes reszletesseggel, akkor pedig te azonnal ravaghatod, hogy megmondtad.
3. A gyakorlatban szerintem ki sem fog derulni, hacsak nem kerdezel ra explicit modon (goto 2). Esetleg azert rakerdeznel, hogy negyed oraban felvazolna a szirszarjukat csak ugy?:)

De amugy tenyleg, mit varsz? Egy meetup gondolatebresztonek valo.

( Fisher v | 2015. 06. 16., k – 09:15 )

Úgy látom hogy az utóbbi napokban elég rosszul, ehe.