Onderwerp: Hosting met gigaveel downloads...

Bedankt voor de aanvulling, daar zit wel iets in wat je zegt.

Met RAID zou ik niet voor striping gaan omdat je kans op uitval groter wordt en de zoektijden op de hardeschijf worden ook vaak ietsje groter. Het enige voordeel van striping is de doorvoersnelheid, maar dat lijkt mij in dit geval niet echt nodig. De RAID-1 die ik aanbeveel is dus niet voor de backup van data, maar voor de uptime/betrouwbaarheid van de server

(wat is redundancy toch een heerlijk woord )

Ik denk zelf dat in dit geval Round Robin een betere keuze is. Maar uiteraard afhankelijk van de situatie en de uitwerking van het systeem. Als je gaat loadbalancen, doe het dan in ieder geval wel goed

Het is misschien geen enorme load, maar wel genoeg traffic en server belasting om een goed plan voor te (laten) maken

Origineel geplaatst door Swiftway-UK
"als je met round robin zou werken, op bijvoorbeeld 10 servers, dan is bij de uitval van een server maar 10% van je systeem down. Maar als je loadbalancer eruit vliegt, dan is je systeem 100% down."

Dat is zeker niet zo, round robin DNS werkt iets anders dan dat je hier beschrijft. Round robin geeft nog altijd de hele lijst beschikbare hosts aan je computer (en dus browser) door echter in andere volgordes van prioriteit.

Browsers proberen eerst contact te zoeken met host 1, als dat niet lukt (na de time out) met host 2 etc.

Dit is een misvatting die vaker voorkomt. De meeste browsers kiezen geen andere hosts als de eerste down is.

Een browser vraagt aan het OS gewoon het IP van de website. Round-robin geeft dan een redelijk willekeurige terug (nameservers geven ze ALLEMAAL terug, maar in willekeurige volgorde; het OS pakt dan meestal de eerste). Vervolgens verbindt de browser met dat IP. Werkt dat IP niet, dan is het doorgaans einde verhaal. Punt uit.

Gaat het echter om je eigen applicatie, dan houdt niets je natuurlijk tegen zelf een lookup te doen, en bij onbereikbaar zijn van 1 host een volgende te proberen, etc. Zo wordt het wel een erg sterke oplossing.

Zo leren we allemaal weer wat

Overigens kan de TS zijn applicatie natuurlijk wel de hele lijst laten afwerken, het is immers geen browser. De applicatie bepaalt in dit geval of het de tweede optie gaat uitproberen.

http://hacks.oreilly.com/pub/h/79

"As most applications only use the first address returned by DNS, this works rather nicely. Approximately half of the requests will go to each address, and therefore the load of two servers should be roughly half of that of a single server. We set the TTL low (to 60 seconds) to prevent any intervening caching DNS servers from hanging onto one sort order for too long, which will hopefully help keep the number of requests to each host more or less equal.

It is only useful to spread out the load if all of the servers are in agreement about what they're serving. If your data gets out of sync, then browsers might get one version of a web page on the first hit and another when they hit reload. If you're looking for a way to keep that from happening, take a look at . "

In dit geval lijkt het me eenvoudig, om de applicatie in kwestie een "reload" te laten uitvoeren zodra er geen data terugkomt na een request.

Cisco Local Director is overigens ook een goede oplossing, niet eens erg prijzig als je er simpelweg een aantal van Ebay afplukt.

Ik ben het zeker met Thomas eens dat er een goed plan gemaakt dient te worden!

Edit time voorbij, laat ik eens concreet antwoord geven op de vragen van de TS en wat aanvullingen op diverse antwoorden van collegas.

Eigen netwerk lijkt me niet zinvol, het kost veel tijd, geld en expertise om dit te bouwen en onderhouden. In tegenstelling tot wat velen denken, is het niet zinvol om dit voor 500 mbit verkeer te doen (uit een kosten/baten oogpunt). Denk eraan dat je een full time staff nodig hebt, redundante routers en veel tijd om een dergelijk netwerk te realiseren. Zeker als je een zekere uptime wilt kunnen garanderen.

Een of twee fulltimers die het netwerk onderhouden is niet voldoende, tenzij dit personen zijn die nooit ziek worden, weinig slaap nodig hebben, geen vakantie nodig hebben en nooit op stap gaan etc

BNIX is verder een lastige IX, het is zeer moeilijk om de juiste peers te verzamelen (denk aan telenet) zonder goede contacten.

Wat voor hardware is er nodig?

Ik denk dat een klein NFS, SCSI raid 51 van zeg een aantal (12) 15K RPM SCSI disks voor data doorvoer voldoende is, dit geeft voldoende doorvoersnelheid en tevens de gewenste redundantie. Je kunt gaan voor qua opslag kleine harde schijven, gezien opslagruimte geen prioriteit is, je serveert immers slechts dagelijks een file van 50 megabyte.

Dit connecteer je met gigabit fiber naar een klein webcluster van een drietal dual xeons of een drietal (gebruikte, Ebay) quad SUN 220R servers met 4 gigabyte ram, hiervoor plaats je twee load balancers (al dan niet hardware, ik vind Alteon erg mooie Load balancers) verbonden met gigabit ethernet naar een provider verbonden met enkele goede transit providers "and you are good to go"

tenzij dit personen zijn die nooit ziek worden, weinig slaap nodig hebben, geen vakantie nodig hebben en nooit op stap gaan, geen vrije tijd nodig hebben etc

Klinkt als een gemiddelde IT'er hoor

dat is wel weer zo
Maar we worden allemaal wel eens ziek en ongelukjes zitten in een klein hoekje.

Conclusie tijd?!

Simpel beginnen, niet te over-done maken en later uitbreiden als echt blijkt dat het een hit is.

Geen eigen netwerk, te duur. Geen moeilijke oplossingen maar bijv dubbele DNS records doen wonderen.

Om even verder te gaan op de loadbalancer.

Als je met degelijk spul werkt is het zeker niet zo dat 10% down gaat vanaf 1 machine dood is bij een cluster van 10. Verder kan je een zulke loadbalancer ook redundant uitvoeren dat ze het ip van elkaar overnemen vanaf een dood is. Zo kan je geen 100% uptime garanderen maar wel een 5 9's behalen.

Om even een praktischer voorbeeld te geven. Enkele topic's geleden verkocht ik een extreme summit met 'i' chipset. Deze heeft een server load balancing functie.
Je maakt hierop een pool van servers aan en stelt ook direkt in op wat voor een manier hij moet controlleren of deze wel echt leven.
Mogelijkheden hiervan zijn:
- Simpele ping check
- Layer4 port test (is de http poort wel open bv, hij kan zelf zover ik weet een index.html vergelijken met die die van de server komt)
Geeft de server geen teken van leven terug wordt hij ook uit de pool gegooit. Redelijk failsave toch als defecte machines na 10sec (of minder) eruit gekickt worden. Komen ze back worden ze binnen de 60sec terug toegevoegt.

Voor de load balancing zelf heb je dan ook verschillende mogelijkheden:
- Round robin: elke request wordt naar de volgede server gestuurt (request 1 server 1, request 2 server 2 enz).
- Met een ratio, dus als machines verschillend sterk zijn kan je zo tweaken dat bij 3 machines 1 50% krijgt en de 2 andere elk 25%.
- Dat bij een connect een ip op 1 bep server blijft (voor sessie bv), volgende connect van ander ip wordt toegewezen aan een andere server. (dacht dat dit ook kon, zoniet kwam het van een andere loadbalancer bij ons).

Zo zie je dat round robin dns totaal nutteloos is en je met goede apparatuur veel verder shot.

Origineel geplaatst door CharlieRoot
Conclusie tijd?!

Simpel beginnen, niet te over-done maken en later uitbreiden als echt blijkt dat het een hit is.

Geen eigen netwerk, te duur. Geen moeilijke oplossingen maar bijv dubbele DNS records doen wonderen.

Dubbele dns records , gewoon round robin dus. Werkt prachtig zolang alles werkt.

Allemaal zeer erg bedankt voor de goeie antwoorden.

Als programmeur en dus helemaal geen netwerkdeskundige, zie ik hier wel heel wat expertise op dat vlak.
Vermits we inderdaad met een eigen applicatie gaan werken en niet met een browser; is die Round Robin inderdaad een zeer goed voorstel:

We werken op bv. 10 servers die allemaal mirrors zijn van zichzelf. Deze 10 zetten we ergens in een bestandje op de 10 servers. De Round Robin Server (RRS) meet constant de traffic op de 10 servers. Een client connecteert met de RRS en krijgt in oplvolgende volgorde van traffic, de 10 IP-adressen binnen en gaat dan downloaden van de minst drukke.
Valt de RSS uit, hebben we nog steeds de 10 IP-adressen waar we dan willekeurig een adres van gaan aanspreken. Als we dan een random hebben zal de verdeling ook tijdens de uitval evenredig gebeuren.

Eigenlijk een supersimpel algoritme dus.
Vraagje: bestaat er software die de traffic constant in 't oog houdt van de verschillende servers en deze permanent rapporteert naar een server die we dan via HTTP kunnen raadplegen?

Bij mijn weten bestaat zulke software, echter denk ik dat het slimmer is om dan naar de load te kijken van de servers (indien linux). Dan kun je beter inschatten welke server de eerste requests moet krijgen en welke bijvoorbeeld geen requests moet krijgen. Aan de hand hiervan bepaal je de volgorde, hierbij is er zelfs de optie om te kijken of de servers bereikbaar zijn, indien niet bereikbaar: tijdelijk uit de lijst halen. Met PHP en MySQL zou dit al mogelijk zijn op een linux server.

mrtg / rrd / rtg enz Genoeg keuze dus.

Koop gewoon twee loadbalancers (Extreme, Cisco, Alteon) gebruikt zijn ze niet duur, duurzaam, betrouwbaar en het scheelt je heel wat codeerwerk

Nu ik zou voor beide oplossingen gaan.

Mocht je veel problemen hebben met het ene platform kan je overschakelen naar een 2de platform.
Maar dit is natuurlijk weer een beslissing die je neemt naargelang uptime belangrijk is (en wat ie je zou kosten).

Origineel geplaatst door Andromedaris
We werken op bv. 10 servers die allemaal mirrors zijn van zichzelf. Deze 10 zetten we ergens in een bestandje op de 10 servers. De Round Robin Server (RRS) meet constant de traffic op de 10 servers. Een client connecteert met de RRS en krijgt in oplvolgende volgorde van traffic, de 10 IP-adressen binnen en gaat dan downloaden van de minst drukke.

Je slaat de spijker op de kop

Een paar regels code, geen extra kosten, de beste bereikbaarheid
Je kunt dan zelfs gemakkelijk servers verdelen over meerdere netwerken en datacentra.

Origineel geplaatst door Andromedaris
Vraagje: bestaat er software die de traffic constant in 't oog houdt van de verschillende servers en deze permanent rapporteert naar een server die we dan via HTTP kunnen raadplegen?

Ja hoor, dat kan heel simpel met bijvoorbeeld MRTG of een zelfgemaakt tooltje. Via PHP of Perl zet je die waarde in een XML bestandje waarmee jullie applicatie een keuze zal maken. Dit is allemaal geen probleem en hier zijn bestaande oplossingen voor.