RRD, Round Robin DNS er en simpel metode til at fordele forespørgsler til forskellige IP Adresser, det bruges typisk til Webservere men det kan også bruges til mange andre ting, men i denne artikel vil vi fokusere på anvendelse i forbindelse med Webapplikationer.
Der er primært to årsager til at man ønsker at dele belastningen fra et website ud på to eller flere servere, den ene er stabilitet og tilgængelighed, den anden er at fordele belastning ud over flere serveren, fordi én simpelthen ikke kan følge med belastningen.
RRD er utroligt nemt at implementere, det handler helt lavpratisk set blot om at oprette to eller flere A-Records for det domæne, som f.eks. Microsoft har gjort:
$ host -t a microsoft.com
microsoft.com has address 64.4.11.37
microsoft.com has address 65.55.58.201
og hvis du lægger mærke til det kan du se at ip adresserne er vidt forskellige, det betyder rimelig sikkert at de har to webservere i to forskellige datacentre til at håndtere deres website.
Eksperterne diskuterer ofte RRD og hvorvidt det er brugbart til Load Balancering og High Availability, svaret afhænger af den enkelte situation. Alternativet til RRD vil som regel være en fysisk load balancer, den skal være redundant og rent hardware mæssigt være af en kaliber så den ikke bliver en flaskehals.
Modsat kan man sige at RRD fordeler brugerne ligeligt, du har ikke mulighed for at sende 25% til én og 75% til én anden, for nyligt havde jeg en kunde hvor RRD passede perfekt til kundens behov, der var 2 servere fordelt på 2 forskellige datacentre, serverne og forbindelserne var lige kraftige, altså var der behov for ligelig fordeling af brugerne, en rigtig load balancer havde krævet yderligere to servere af samme størrelse som de 4 vi allerede havde. Altså ville vi have øget udgifterne med 50% uden at øge kapaciteten.
Kunden var bekymret for hvor hurtigt fallover i tilfælde af servernedbrud ville ske og bad mig derfor køre en test med forskellige browser og forskellige operativsystemer. For at køre testen satte jeg 4 webservere op, og lagde en simpel fil på hver af dem som blot viste serverens hostname, f.eks. “node1.lab.mikjaer.com” eller “node2.lab.mikjaer.com” således er det nemt for mig at se hvilken server der servicerer den enkelte request.
Efter et par forsøg viste det sig at de fleste browsere foretager et DNS Opslag første gang de tilgår siden, og husker ip adressen hele sessionen igennem med mindre forbindelsen fejler, så foretager browseren et nyt opslag.
Test: Jeg har alle webserveren kørende, jeg går ind på RRD domænet med den browser jeg tester, ser hvilken server jeg rammer, reloader et par gange for at bekræfte at jeg bliver på den server, derefter lukker jeg den pågældende server ned og refresher browseren og ser hvor lang tid det tager den at vise siden.
* Windows, IE6: Failover: 3-4s
* Windows, IE7: Failover: 1s
* Windows, IE8: Failover: 1s
* Windows, IE9: Failover: <1s
* Windows, Firefox: Failover: <1s
* Windows, Chrome: Failover: <1s
* OSX, Safari: Failover: <1s
* OSX, Chrome: Failover: <1s
* OSX, Firefox: Failover: <1s
* IOS(Ipad,Iphone): Failover: <1s
* Android (Sony Ericsson Xperia 10iv, 2.2.3): <1s
Med andre ord har alle moderne browsere lavet failover uden brugeren bemærker det, og selv IE6 som er berygtet for at være en af historiens mest ustabile, usikre og useriøse browsere klarer skiftet på 3-4s. IE7 og IE8’s (relative) høje loadtider skyldes muligvis at jeg brugte IETester til at teste dem i.
Vi har brugt RRD til både High Availability og High Load clustre og har således flere gange i praksis brugt RRD til produktionsløsninger, og vi kan jo se at både Microsoft, Facebook, Google og Twitter bruger RRD aktivt i produktion.
Så dels på baggrund af praktisk erfaring, disse tests og flere som dem samt en længere række store aktørers valg af samme løsning har jeg intet problem i at anbefale RRD til implementering af både High Availability og High Load Clustre.
