Onderwerp: Webhosting full redudant

Beste,

Voor een belangrijke website wil ik zoveel mogelijk redundantie opzetten. Het idee is om in 2 verschillende datacenters en verschillende netwerken een server te plaatsen. Op deze servers draait deze website.
Nu maken deze websites gebruikt van een mysql database. Deze zal dus continue identiek moeten zijn op allebei de locaties.

Nu zit ik alleen met het volgende. De dns staat naar bijv. locatie nummer 1. Nu gaat daar stroom / netwerk / server stuk en zou de dns gelijk naar de server op locatie 2 moeten verwijzen. We zitten dan alleen met een dns update die toch wel even kan duren denk ik.

Verder wil ik dat dit allemaal volledig automatisch gaat.

Iemand goeie ideeën of tips voor mij hoe dit het beste aan te passen.

Oorspronkelijk geplaatst door Jethro

Beste,

Voor een belangrijke website wil ik zoveel mogelijk redundantie opzetten. Het idee is om in 2 verschillende datacenters en verschillende netwerken een server te plaatsen. Op deze servers draait deze website.
Nu maken deze websites gebruikt van een mysql database. Deze zal dus continue identiek moeten zijn op allebei de locaties.

Nu zit ik alleen met het volgende. De dns staat naar bijv. locatie nummer 1. Nu gaat daar stroom / netwerk / server stuk en zou de dns gelijk naar de server op locatie 2 moeten verwijzen. We zitten dan alleen met een dns update die toch wel even kan duren denk ik.

Verder wil ik dat dit allemaal volledig automatisch gaat.

Iemand goeie ideeën of tips voor mij hoe dit het beste aan te passen.

(Global) load balancing is de key. Als je al de moeite neemt om 2 servers op 2 verschillende lokaties/netwerken op te hangen kan dat er ook nog wel bij En is bovendien dus realtime.

En als dat onwenselijk is, of niet betaalbaar.. Waarom niet gewoon de DNS entries naar beide bakken verwijzen. Dan heb je bij uitval maar ~ 50% van je verkeer wat kwijt raakt tot de DNS geprogageerd is.

Oorspronkelijk geplaatst door Pur

En als dat onwenselijk is, of niet betaalbaar.. Waarom niet gewoon de DNS entries naar beide bakken verwijzen. Dan heb je bij uitval maar ~ 50% van je verkeer wat kwijt raakt tot de DNS geprogageerd is.

round robin, een a-record met twee ips.

Als je het echt goed aan wilt pakken ga je al snel praten over global load balancing en een dedicated lijntje tussen de 2 dc's om je data synchroon te houden.
Mocht je meer informatie willen over hoe je zoiets opzet dan ben je welkom om een pm te sturen.

Is de website eventueel aan te passen? Zo ja dan kun je alle update en insert querys dubbel uitvoeren en eventueel als de andere server niet bereikbaar is in een bestand opslaan dat uitgevoerd wordt zodra die server weer bereikbaar is.

Enige waar je mogelijk mee zit is dat keys en dergelijke problemen gaan geven (is afhankelijk van de site/setup wel af te vangen).

Met wat script werk en 2 A-records is het dus wel af te vangen.

Ligt ook aan het doel van de website, als er bijv. een winkel op draait dan wil je niet op 2 verschillende databases de orders accepteren. Als je voorraden bijhoud wil je dat ook niet op 2 verschillende databases doen.
Ik weet daarom ook niet of roundrobin de beste oplossing is.

Voordat er allerlei meningen/ideen geventileerd worden lijkt het mij beter om te vragen wat het doel van de website is. Winkel? veiling? Informatie?
En wat te denken van afbeeldingen.. prop je die in de database of op het filesystem..

Het gaat om een website waarvan alleen database informatie veranderd.
Er worden wel account geregisteerd en betalingen verwerkt.

Plaatjes of andere zaken zijn niet zo belangrijk. Ik kan deze ook bij aanpassingen
naar elke server uploaden dat is geen probleem.

Ik ben zelf ook flink aan het lezen en denk dat ik het volgende nodig heb.

global loadbalancing ( hier hoor ik graag ervaringen over en hoe mensen dit opgezet hebben en welke software / hardware er gebruikt word ).

En een oplossing om de mysql servers gelijk te houden. Ook als er een offline is geweest dat hij zich automatisch weer update.

MySQL (multi-master) replicatie, voor zowel de website als DNS.
Altijd beide (of zelfs meer) volledig (realtime) in sync. Bij uitval van 1, wordt direct geupdate zodra deze weer online komt.

Global loadbalancing en daarbij mysql replicatie over twee gescheiden locaties is niet alleen duur om op te zetten, maar ook duur in onderhoud. Realiseer je goed dat het grootste deel van storingen wordt veroorzaakt door menselijke fouten... Verwacht dus geen wonderen van een redundante oplossing.

De eerste stap in dit soort trajecten zou een kosten-baten analyse moeten zijn. Je maakt hiermee voor de klant inzichtelijk hoe hoog de kosten van bijvoorbeeld 1 uur downtime zijn (gemiste bestellingen, image schade e.d.). Op basis daarvan ga je kijken welke maatregelen je kunt nemen om dat uur downtime te voorkomen en dus of de kosten van die maatregelen opwegen tegen de kosten van de downtime.

Natuurlijk is het technisch gezien een hele leuke uitdaging om een extra 9 aan je beschikbaarheid toe te kunnen voegen (want daar praten we over het algemeen over bij zulke oplossingen), maar vaak bereik je meer als je eerst de verwachtingen van de klant goed afzet tegen de realiteit.

Vanavond bezig geweest met het opzetten van een mysql multi master replication.

Moet zeggen dat dit tot nu toe er goed uit ziet. Er draaien nu 2 servers met mysql 5
en de database word netjes in sync gehouden. Ook als er 1 uit gaat zodra deze weer online
komt dan syncen ze meteen weer. ( dit ga ik de komende tijd verder testen en uit werken )

Wat betreft de global loadbalancing ben ik een beetje van terug gekomen na het lezen van het volgende artikel : http://www.tenereillo.com/GSLBPageOfShame.htm

Graag hoor ik van mensen of hun andere ervaringen hebben

Je zou eens kunnen zoeken naar de term anycast. Volgens mij wordt dat op die pagina waarnaar je linkt omschreven als "BGP Host Route Injection". Wordt volgens mij gebruikt voor veel root-server clusters en bijvoorbeeld www.opendns.com. Maar ik betwijfel of deze techniek echt geschikt is voor webservers.

Oorspronkelijk geplaatst door hostlogic.nl

Je zou eens kunnen zoeken naar de term anycast. Volgens mij wordt dat op die pagina waarnaar je linkt omschreven als "BGP Host Route Injection". Wordt volgens mij gebruikt voor veel root-server clusters en bijvoorbeeld www.opendns.com. Maar ik betwijfel of deze techniek echt geschikt is voor webservers.

AnyCast is veel te duur om op te zetten. Van de week het een en ander nagezocht voor een klant waar ik gedetacheerd zit. Dan kom je beter weg met MySQL replicatie. Maar denk eraan: Het is net als raid en beschermd je niet tegen menselijke fouten.
Wil je goed, snel en goedkoop, zet dan gewoon je server neer in een netwerk / datacentrum dat niet om de maand problemen heeft. Neem een goede server met zoveel mogelijk redundant onderdelen en plaats in je rack nog eens een eigen UPS.

Voor de DNS heb ik het volgende bedacht.

TTL zo laag mogelijk zetten.
Standaard 2 records in de DNS zetten bijv.

website.extensie 1.1.1.1
website.extensie 2.2.2.2

Zodra bijv. locatie 1.1.1.1 offline gaat past de server op locatie 2.2.2.2 de dns aan en verwijderd het 1.1.1.1 record. Zodra de locatie weer online komt dan voegt hij het a record weer toe aan de DNS en dit verhaal visa versa.

Zinvol of niet ? Ik was namelijk aan het testen hiermee en merkte dat toen ik allebei de a-records in de DNS had staan en ik haalde 1 server offline dat ik met geen mogelijkheid naar de andere server verwezen werd. ( browser gesloten - ipconfig /flusdns gedaan enzv ) Toen ik de record voor server 1 weghaalde werkte het binnen een paar seconden en werd ik naar server 2 gestuurd ( getest vanaf huis ).

Dat van mysql begrijp ik ook dat het net raid is. Foutje op server 1 word gelijk naar server 2 doorgestuurd. Daarom worden er natuurlijk ook backups gemaakt. Omdat alle betalingen ( denk aan iDeal ) continue door gaan word er elk uur een backup van de database gemaakt en naar een aparte server weg geschreven. Op deze manier heb ik backups van een week oud en dan van elke uur van de dag van deze week.

Ok, maar denk eens aan het volgende: Wanneer besluit je dat een machine dood is?

Als deze poort 80 niet meer open heeft staan? Of als een PHP-script geen OK meer geeft tegen je monitoring?

Wat ik meer bedoel, hoe complexer je de boel maakt, hoe meer er fout kan gaan.

In principe zou ik gokken op 1 goed netwerk en 2 servers die beide redundant stroom hebben en via aparte switches naar de routers lopen.

Hier kan je via DRBD en Heartbeat een hele mooie setup maken.

Het beschermd je alleen nog steeds niet tegen het niet goed meer functioneren van een service. "httpd" kan dan nog wel draaien, maar wie zegt dat deze intern nog goed functioneert?

Wat ik alleen wil zeggen, hoe complexer, hoe meer er fout kan gaan. 1 enkele server met goede hardware kan hele goede uptimes halen. Sync de data realtime naar een tweede server via DRBD en doe desnoods de failover handmatig, want zó vaak vallen servers nu ook weer niet uit.

Ik ben ook absoluut voor een handmatige failover. Het zal niet de eerste keer zijn dat er een server hikt, de failover in werking is en ze op dat moment allebei de baas zijn en ruzie krijgen.