Onderwerp: Failover op website

Wij hebben 2 datacenter locaties en zijn aan het experimenteren met high-availibility voor bepaalde websites.
De volgende situatie zouden we graag willen bereiken.

Website draait op de primaire locatie A. Wanneer daar een onderbreking is moet bij voorkeur dezelfde website of iig. een onderhoudpagina worden getoond op locatie B. Ik heb wel eens gehoord dat er mogelijkheden zijn om dit te realiseren maar niet in welke richting ik moet denken. De DNS kun je niet van prioriteiten voorzien zoals bij MX records.

Zijn er bepaalde DNS diensten die hier een oplossing voor beiden?

Draai je Windows Server of Linux?

Onze systemen draaien op een linux omgeving in combinatie met een VRRP (keepalived) oplossing voor High Availibility.
Wanneer locatie A offline gaat, neemt locatie B het automatisch over.

Om dit te realiseren moet je er wel voor zorgen dat de data op beide servers identiek is.
Dit kan bijvoorbeeld met GlusterFS of DRBD.

Of het mogelijk is met DNS, dat betwijfel ik....

Wij draaien websites voornamelijk onder Linux.
Ik zoek een mogelijkheid om een soort van prioriteit in de DNS. Standaard kan dit niet maar wellicht heeft iemand een handig trucje om dit toch te realiseren. Ik zal eens kijken of we wat we met VRRP kunnen al betwijfel ik of we dit kunnen met onze huidige infra.

Waarom zou dat niet kunnen met je huidige infra?

Maar inderdaad, wellicht dat iemand een handig 'trucje' heeft... mij is het op die manier niet gelukt in ieder geval

Omdat voor zover ik lees VRRP op 2 routers moet worden toegepast. Onze switches hangen middels een Sonicwall NSA Firewall aan het internet. De routers zijn van de netwerk leveranciers. Ik duik er nog even wat verder in want misschien zijn er wel mogelijkheden. Ik wil het bij voorkeur per website kunnen aanzetten. Zo kan ik deze klanten meer toegevoegde waarde geven en een hoge uptime garanderen.

Ik wacht nog op iemand met een "trucje" :-)

Oh, hehe, wij draaien keepalived (VRRP service) op twee debian servers, dus het hoeft niet per se op een router te worden geconfigureerd.

Per website zou kunnen, dan zou je het virtuele IP adres alleen voor de betreffende website moeten gebruiken.

Ah! Dan ga ik me morgen met een collega eens verder verdiepen in deze materie.
bedankt voor de tip!

VRRP of HSRP (cisco) draaien inderdaad.

Ter aanvulling, via DNS kan het in ieder geval niet.

Zat mooie oplossingen voor zoals hier al genoemd. maar je wilt het oldschool dns fixen :-) niet echt mogelijk behalve uuhhh "semi" load balanced "round robin dns" maja lekker uit de oude doos en zal wel weer ene paar leuke reacties hierop krijgen...
^a

hmmm, misschien kan het toch simpeler. Kijk hoe Google dit doet:

www.google.nl. 327739 IN CNAME www.google.com.
www.google.com. 589413 IN CNAME www.l.google.com.
www.l.google.com. 220 IN A 74.125.225.51
www.l.google.com. 220 IN A 74.125.225.48
www.l.google.com. 220 IN A 74.125.225.49
www.l.google.com. 220 IN A 74.125.225.52
www.l.google.com. 220 IN A 74.125.225.50

Oorspronkelijk geplaatst door ionline

hmmm, misschien kan het toch simpeler. Kijk hoe Google dit doet:

www.google.nl. 327739 IN CNAME www.google.com.
www.google.com. 589413 IN CNAME www.l.google.com.
www.l.google.com. 220 IN A 74.125.225.51
www.l.google.com. 220 IN A 74.125.225.48
www.l.google.com. 220 IN A 74.125.225.49
www.l.google.com. 220 IN A 74.125.225.52
www.l.google.com. 220 IN A 74.125.225.50

Dat zijn de roundrobin ips van de loadbalancers en je mag er zeker van zijn dat die loadbalancers via vrrp/heartbeat/keepalive/... in een cluster staan. Het is niet omdat het simpel lijkt aan de buitenkant dat de binnenkant daarom even simpel is.

Oorspronkelijk geplaatst door The-BosS

Dat zijn de roundrobin ips van de loadbalancers en je mag er zeker van zijn dat die loadbalancers via vrrp/heartbeat/keepalive/... in een cluster staan. Het is niet omdat het simpel lijkt aan de buitenkant dat de binnenkant daarom even simpel is.

Google doet nog wel meer dan dat;
Die gequote namen/adressen zijn wat ionline gekregen heeft.

Iemand anders (verder weg) krijgt een ander antwoord;
De traceroute query vanuit sdv.fr bijvoorbeeld naar www.l.google.com eindigt op 209.85.169.104

Kortom, afhankelijk van waar de vraag vandaan komt geeft de google DNS een reeks IP adressen die voor de vrager 'dichtbij' moeten zijn.

Voor services zonder langdurige connecties (zoals DNS) kan het nog leuker, kijk maar eens vanaf een paar verspreide netwerken hoe een traceroute naar bijvoorbeeld 8.8.8.8 (google public dns) loopt.

Maar dat is voor de OP allemaal niet van toepassing.

Met VRRP/HSRP kun je een heel snelle failover realiseren tussen machines die relatief dichtbij elkaar staan; In het zelfde vlan in elk geval, en als het meer dan paar msec RTT is moet je goed gaan nadenken.
Met een loadbalancer of reverse proxy kunnen de backend machines wat verder weg staan (hoewel nog niet al te ver qua RTT), maar is dat apparaat zelf wel een SPOF. Je kunt nog steeds wel een heel snelle failover bieden.
Aan de andere kant is een loadbalancer of reverse proxy meestal simpeler dan een webserver infrastructuur, en heeft daardoor normaal gesproken een hogere beschikbaarheid. (en minder onderhoud; 'planned maintenance' is nog steeds technische downtime).

Met creatief DNS gebruik kunnen machines willekeurig ver weg staan, maar je hebt geen prioriteits mogelijkheden.
Vanwege caching moet je er rekening mee houden dat de snelste failover in geval van problemen in de orde van vijf tot tien minuten ligt, (en dat alleen als je de TTL zo kort gezet hebt).

Afhankelijk van de schaal (binnen DC, nabije DC's, 'wereldwijd') heb je verschillende mogelijkheden.
Netwerk technisch haal je je een hoop last op de hals als je 'lan' technieken (vrrp, hsrp net als allerlei applicatie heartbeat gerommel) over grotere afstanden zoals tussen DC's gaat gebruiken.
Je moet dan een single LAN leveren, (of faken, met bridging, atom tunnel, of whatever).

Een single front (loadbalancer, reverse proxy) heeft dat nadeel minder, maar het blijft een single device (meestal), waarmee je wel machine problemen maar niet een heel DC probleem opvangt.
DNS geeft je de meeste vrijheid, maar is niet heel snel.

De kans is trouwens ook vrij groot dat een technisch complexe oplossing die in theorie heel goed werkt, in de praktijk meer last dan gemak geeft wanneer de hoster 'm niet goed snapt en er niet mee om kan gaan.
Voor de OP en diens klanten, die vraagt om iets tussen twee DC's is _denk ik_ een DNS oplossing de beste, met een vrij korte TTL.
Geplanned onderhoud kan gewoon 'netjes' gedaan (omschakelen, TTL afwachten, en dan rustig klussen aan de niet meer gebruikte server), en bij ongeplande storingen is er een deel van de bezoekers die gedurende de TTL er even last van heeft. Met een TTL van, zeg, 10 of 15 minuten is dat meestal wel te overzien.
Voor alle duidelijkheid : bij DNS moet je dus actief iets wijzigen in de DNS als je naar 'de andere' server wilt omschakelen.
(Bij vrrp/hsrp heb je trouwens ook een fout detectie mechanisme nodig; Wanneer de hele server omvalt heb je dat 'vanzelf' wel, maar als alleen het webproces gecrashed is, moet je nog een mechanisme hebben wat vrrp laat omzwaaien).