Bekijk Volledige Versie : Loadbalancing voor grote aantallen
FransVanNispen
27/09/08, 12:18
Ik ben erg gefascineerd door grote projecten. Bijv hyves, die 1800+ servers online houdt en SecondLive met 3000+ servers. En dan nog niet te spreken over Google.
Wat mij met name bezig houd, hoe je zo'n project het best op zou kunnen zetten, zodat je in theorie, oneindig uit kan bouwen en alles op snelheid blijft.
Technisch gezien is er een beperking op het aantal connecties per IP. Er zijn immers max 65356 poorten beschikbaar voor TCP/IP en UDP
Het lijkt mij dat ook een loadbalancer tegen deze limiet aanloopt.
Stel, we willen 300.000 simultane connecties afhandelen. Hoe zouden we dit kunnen aanpakken?
nou op meerdere ip's dmv een combinatie tussen loadblancers en DNS roundrobin zul je vast 300k aan connecties kunnen wegzetten. Als de backend achter de loadbalancers het aankan :)
bv yahoo Mail park. Yahoo heeft 7 MX records en achter elk record hangt een loadbalanced mail systeem.
of zoals wij het zelf doen, 5 mx records, en sommige MX records hebben meerdere ips zodat je geen loadbalancers nodig hebt.
Nu is het met mail al redelijk makkelijk omdat daar redudantie inzit. Maar met http of een andere applicatie moet je prima meerdere ips kunnen bedienen.
MX kun je totaal niet vergelijken met round robin, het mooie van MX is dat bij een onbereikbaar ip er verder gehopt wordt op prioriteit. a-records daarentegen kennen dit (nog) niet en zijn in dit geval dus gewoon onbereikbaar.
De specs zeggen dat wanneer er meerdere records zijn voor dezelfde host je blijft proberen todat je er een hebt gevonden die werkt. Alleen niemand die zich daar aan houdt. :P
Je kan natuurlijk wel meerdere records naar hetzelfde redundante platform laten wijzen, dan heb je niet het probleem van te veel connecties per IP. Een IP is niet aan 1 apparaat gebonden.
denk dat jij rfc 1794 eens moet gaan bekijken, round-robin is niets meer dan een algoritme dat ervoor zorgt dat er naar willekeur een dns record terug gegeven wordt.
als jij 5 a records hebt
1.subset A 10.0.0.25
2.subset A 10.0.0.26
3.subset A 10.0.0.27
4.subset A 10.0.0.28
5.subset A 10.0.0.29
als 3.subset offline is, en je krijgt deze terug heb je in deze gewoon pech.
Daarentegen iets wat lichtelijk van de grond komt maar eigenlijk veel te langzaam gaat (qua implementatie) rfc 2782 (http://www.faqs.org/rfcs/rfc2782.html) . Het gehele voip gebeuren is een van de drijvende krachten achter dit type dns records :)
Als we dat overaal geimplementeerd zouden hebben heb je vrij snel failovers en load balancing binnen handbereik :)
FransVanNispen
27/09/08, 19:48
Waarschijnlijk is er geen andere mogelijkheid dan DNS trucks te gebruiken in combinatie met meerdere load balancers. Een load balancer kan immers ook niet meer dan 64k connecties aan als we het hebben over streaming sockets.
I het niet op een of andere manier mogelijk dat er andere DNS resultaten worden terug gegeven per IP block of afkomst van een IP?
Ja, zoek maar eens op global server load balancing, dat werkt op dezelfde manier. Afhankelijk van de locatie van de aanvragende nameserver worden er andere records terug gegeven.
FransVanNispen
27/09/08, 23:50
Wat ik daarover kan vinden, is GSLB bedoeld om de balancen over meerdere datacenters. Dat is niet wat ik bedoel.
Wat ik zou willen is bijv. 85.12.0.0/16 -> IP1, 83.0.0.0/8 -> IP2
Of iets als:
(client IP % 3 == 0) -> IP1
(client IP % 3 == 1) -> IP2
(client IP % 3 == 2) -> IP3
Dat heeft iets weg van round robin, maar idiaal zou IP1, IP2 en IP3 dan een round robing pool zijn.
Is zo iets mogelijk met bijv bind?
Netwerkkant
Uit mijn ervaring met de LTM/BigIp toestellen van F5 kan'k zeggen dat ze een ~100.000 connecties per virtuële server aankunnen. Op zich als je over een 300.000 connecties spreekt, dan zou ik eens gaan luisteren bij de loadbalancing vendors wat ze je voorstellen. Hun pre-sales mensen gaan je alvast wat op weg kunnen helpen.
Software
Let wel op als je gaat spelen met dergelijke nummers... Zie dat je backendclustering systeem dezelfde nummers aan kan. Het gaat hier niet enkel om de netwerk kant (wat imho het simpelste is), maar ook om clustering binnen de software.
Afhankelijk van je situatie, wordt het helemaal complex... Heb je bijvoorbeeld stateless informatie (static web content) of heb je nood aan sessie informatie (chat gebeuren etc)? In het eerste geval kan je "domweg" alles wat verdelen, bij het tweede moet je zien wat je doet met de sessie informatie; houden alle nodes die bij, groepeer je die per enkele servers of bezie je die als verloren...
Simpele vraag en je krijgt het standaard consultancy antwoord terug:
"It depends..." :D
FransVanNispen
04/10/08, 12:45
Netwerkkant
Uit mijn ervaring met de LTM/BigIp toestellen van F5 kan'k zeggen dat ze een ~100.000 connecties per virtuële server aankunnen.
Ik neem aan dat je 100.000 connecties per seconde bedoelt? Want streaming sockets kunnen er max 65k op een IP aanwezig zijn. Of bedoel je dat er 100.000 sessie verbindingen kunnen zijn, en dus 100.000 simulatane bezoekers?
Wat ik daarover kan vinden, is GSLB bedoeld om de balancen over meerdere datacenters. Dat is niet wat ik bedoel.
Wat ik zou willen is bijv. 85.12.0.0/16 -> IP1, 83.0.0.0/8 -> IP2
Of iets als:
(client IP % 3 == 0) -> IP1
(client IP % 3 == 1) -> IP2
(client IP % 3 == 2) -> IP3
Dat heeft iets weg van round robin, maar idiaal zou IP1, IP2 en IP3 dan een round robing pool zijn.
Is zo iets mogelijk met bijv bind?
Een niet al te nette optie (die werkt) zou zijn om meerdere malen een naamserver te installeren en op te starten op verschillende poorten (geen enkele op poort 53). Deze naamservers geven voor dezelfde vraag een ander dns record terug.
Via een firewall (bijvoorbeeld IPTables) zou geregeld kunnen worden dat indien een verzoek binnenkomt op poort 53 vanaf ip range 1.0.0.0/8 deze door verwezen wordt naar poort 1531 en indien een verzoek binnenkomt op poort 53 vanaf ip range 2.0.0.0/8 deze door verwezen wordt naar poort 1053. Dit laatste is in ieder geval in theorie mogelijk (in de praktijk moet ik het nog testen).
Let op: valt IPTables uit dan werkt je naamserver niet meer. Daarnaast moet je backend het aan kunnen. Persoonlijk zou ik deze setup niet gauw gebruiken en heb ik hem nog niet getest (laatste ga ik binnenkort een keer testen met apache, principe is echter hetzelfde).
Voor bind zou je kunnen kijken of je hier wat aan hebt:
http://sourceforge.net/projects/rir2dns/
Voor powerdns is er wel een oplossing voor:
http://cvs.blitzed.org/geo-dns/README
GSLB is er op gebaseerd dat bezoekers uit de US naar een server in de US worden gestuurd en bezoekers uit Europa naar een server in Europa. Dit doet het door per dns aanvraag te kijken vanuit welke regio dit komt en daar de reply op aan te passen. Daar kan je natuurlijk ook weer round robin op toepassen.
Een aantal punten (wij hebben enkele jaren ervaring met high-traffic sites waarvan enkele bv. in CIM top 20 staan):
- GeoDNS is een leuke oplossing om je traffic per land/regio te verdelen, dit haalt zowat de meeste load weg, leuke is timezones zodat je clusters kan bouwen welke bijna altijd loaded zijn op 24h. (http://www.caraytech.com/geodns/).
- De 65k limiet moet je opdelen in 2 stukken:
* Een client die connecties maakt naar jouw loadbalancer en waarvan de server een direkte connectie kan terugbouwen (direct routing loadbalancing) is meestal geen probleem (voor de loadbalancer). Daar de destination port altijd hetzelfde is en de source-port verschilt per connection voor inkomende verbindingen (65k limiet per client). Voor uitgaande zit je dan aan de limitatie van de server (65k).
* Als je de servers interne ips geeft en puur via de VIP van de loadbalancer laat werken (NAT-based loadbalancing) heb je dit probleem in je SNAT wel. Je loadbalancer zal na 65k connecties eruit niet verder weten. Dit wordt 'opgelost' op veel loadbalancers (ACE/CSS/BigIP) door een pool van SNAT ips te maken.
Met statefull firewalls kan dit problemen opleveren daar het antwoord van een server terug dient te komen van het ip naar waar de connectie is gestart.
De uiteindelijke oplossing (design van infrastructuur) is meestal een combinatie van GeoDNS/Loadbalancing/... en moet al voorzien worden in de design van bv de applicatie (cluster-ready etc...).
GSLB is er op gebaseerd dat bezoekers uit de US naar een server in de US worden gestuurd en bezoekers uit Europa naar een server in Europa. Dit doet het door per dns aanvraag te kijken vanuit welke regio dit komt en daar de reply op aan te passen. Daar kan je natuurlijk ook weer round robin op toepassen.
Dat is niet per se waar - je kunt het zo gebruiken maar je kunt het ook op een aantal andere manieren gebruiken. Je kan met een GSLB ervoor kiezen te balancen uitsluitend gebaseerd op locatie, uitsluitend gebaseerd op gelijkwaardige verdeling, gebaseerd op een mix van de 2 vorige dingen, of je kunt kiezen voor een active-passive opstelling (waarin de secundaire locatie enkel overneemt indien de primaire onbereikbaar is). Dit laatste is het makkelijkste in gebruik, omdat het soms lastig kan zijn om dingen constant te synchroniseren tussen 2 locaties.
Maar je kunt dus natuurlijk ook gebruik maken van 2 locaties in Nederland, enkel vanwege redundantie en eventueel om tegelijkertijd load te verdelen. In dat geval gaat het dus niet om de locatie.
Even over die 65k limiet op de connecties: dat geldt toch alleen maar voor connecties vanaf 1 IP adres?
Een tcp/ip socket wordt toch geïdentificeerd door <source_ip, source_port, destination_port, destination_ip> ?
Je zal dus toch enkel maar problemen krijgen als 1 client meer dan 65k connecties probeert te maken?
De theoretische limiet op het aantal verbindingen op 1 server poort lijkt mij dan : 256^4 * 65536 . Dit zijn immers alle mogelijke combinaties van IP's en poorten.
Het aantal mogelijke combinaties naar 1 machines op gelijk welke poort zou dan zijn: 256^4 * 65536^2 .
In de praktijk zal je server/router vooral beperkt zijn door het aantal connecties dat hij kan bijhouden.
Idem voor NAT lijkt me?
@luser: ik snap die 65k limiet in geval van NAT niet?
De loadbalancer moet toch gewoon een vertalingstabel bijhouden met als key <source_ip, source_port> waarbij een connectie gemapped wordt op een fysieke server?
Die keys kunnen toch ook 256^4 * 65536 combinaties aannemen? Vandaar die limiet dan?
Of verwar ik hier met DNAT?