Bekijk Volledige Versie : Opstelling met hoge uptime garantie
Beste lezer,
Binnenkort wil ik zelf een opstelling gaan maken voor een website die ik ga lanceren. Aan de opstelling heb ik de volgende eis gesteld :
2 (replicerende?) servers. voor als er 1 ongemerkt uitvalt of hardware storing heeft moet deze automatisch overgenomen worden
Heb al wat onderzoek gedaan en geadviseerd werd een extra NAS server erbij te plaatsen. Echter wil ik liever niet een derde server erbij, tenzij het natuurlijk noodzakelijk is.
Is er een andere oplossing, of zal ik toch aan een NAS server moeten gaan denken?
Mvg,
Rick
De NAS is dan weer SPOF dus moet je de NAS ook weer dubbel uitvoeren....
PimEffting
15/08/08, 17:01
Rick, zoiets kun je zo gek maken als je zelf wilt. Denk eerst eens na over je budget en afhankelijk daarvan zijn altijd wel diverse oplossingen mogelijk.
Denk aan iets als DRBD en Heartbeat, daar moet je een heel eind mee kunnen komen.
Wido, de vraag is hierbij wat gebeurt er zodra 1 server faalt en de software DRBD en Heartbeat niet meer kan draaien op die ene 1 server.
Ook zie ik een probleem met DNS die nog verwijst naar 1 server.
Of is het mogelijk via DNS een secundaire server IP in te stellen bij downtime van de andere?
Wido, de vraag is hierbij wat gebeurt er zodra 1 server faalt en de software DRBD en Heartbeat niet meer kan draaien op die ene 1 server.
Als de heartbeat het niet meer doet, zal de tweede server tot de conclusie komen dat de eerste dood is/probleem heeft. De tweede zal het op dat moment dus willen over nemen.
Ook zie ik een probleem met DNS die nog verwijst naar 1 server.
Je configged het zo dat de 2e het ip adres van de eerste overneemt. zorgen voor een goede STONITH methode.
Of is het mogelijk via DNS een secundaire server IP in te stellen bij downtime van de andere?
nee
Afhankelijk van het soort data wat er op de website komt te staan kun je kijken naar NLB en IIS. Vrij simpel om op te zetten als je net begint.
Het heeft hier wel eens gedraaid in een test opstelling (intern), maar op het moment dat er een node werd uitschakeld, werden de requests keurig verdeeld over de overige nodes.
Verder weinig mee bezig geweest, dus mensen met meer ervaring hierover kunnen je vast de voor en nadelen schetsen.
hostlogic.nl
15/08/08, 23:09
Helemaal met Wido en Bakkerl eens. DRBD en heartbeat is voldoende om de data synchroon te houden en in geval van een storing het IP adres over te nemen op de 2e server. Zorg er wel voor dat je kiest voor een goed datacenter en netwerk, en dat je dit laat inrichten en beheren door mensen die hier ervaring mee hebben. Hoe redundant je setup ook is, 1 slechte beheerder kan meer schade aanrichten dan technische maatregelen kunnen opvangen.
MaxxLan BV
15/09/08, 16:22
Eventueel de boel virtualiseren met high availability?
@rickie: Volgens mij kun je in de DNS meer dan 1 ip adres opgeven voor één en hetzelfde A record. De meeste browsers proberen eerst IP adres 1, en als dat geen resultaat geeft, nummer 2. Als je vervolgens de DNS servers op dezelfde machines laat draaien, dan kun je met deze configuratie het verkeer wat sneller naar de juiste machine sturen, door op machine 1, een DNS record in te stellen die als eerste het A record met het IP van machine 1 teruggeeft, en als tweede het IP adres van machine 2; en op machine 2 stel je de DNS precies omgekeerd in: eerst het IP adres van machine 2 en dan pas van machine 1 retourneren; dan zal de browser in veel gevallen (niet in alle, door caching) het IP adres retourneren van dezelfde machine als waarop de DNS aanvraag is gedaan. Daarbij kun je er dus redelijk vanuit gaan dat de machine het in ieder geval doet. Wat dan eigenlijk nog zou moeten gebeuren is de DNS service aan de http/https service koppelen; draait de webserver/site niet, dan de DNS uitschakelen, zodat het verkeer naar de andere machine geleidt wordt, in de hoop dat het daar op dat moment wel functioneert. Globule <http://www.globule.org/> doet dat bijvoorbeeld door de DNS server als plugin in apache te integreren, dus als Apache niet draait, dan draait ook de DNS op de machine niet.
@rickie: Volgens mij kun je in de DNS meer dan 1 ip adres opgeven voor één en hetzelfde A record. De meeste browsers proberen eerst IP adres 1, en als dat geen resultaat geeft, nummer 2.
Volgens mij niet
Als je vervolgens de DNS servers op dezelfde machines laat draaien, dan kun je met deze configuratie het verkeer wat sneller naar de juiste machine sturen, door op machine 1, een DNS record in te stellen die als eerste het A record met het IP van machine 1 teruggeeft, en als tweede het IP adres van machine 2; en op machine 2 stel je de DNS precies omgekeerd in: eerst het IP adres van machine 2 en dan pas van machine 1 retourneren; dan zal de browser in veel gevallen (niet in alle, door caching) het IP adres retourneren van dezelfde machine als waarop de DNS aanvraag is gedaan.
Nee, dns cache zou dan een groot probleem zijn. Bovendien moeten primary en secondary dns dezelfde records hebben.
Zoals bakkerl al zei, gewoon zorgen dat 2e machine het ip overneemt van de eerste, simpel. Beejte oud topic overigens.
Wouter-Ospito
19/09/08, 10:45
Volgens mij niet
Jullie hebben allebei een beetje gelijk. Je kan niet voor hetzelfde A-record een extra IP-adres opgeven. Wel kan je nog een extra A-record toevoegen. Bijvoorbeeld:
www.ospito.nl. 14400 IN A 77.243.226.77
www.ospito.nl. 14400 IN A 77.243.226.78
Op het moment dat iemand www.ospito.nl bezoekt gaat die de ene keer naar 77.243.226.77 en de volgende keer naar 77.243.226.78. Dit is niet helemaal 50/50, maar verspreid de load al wel standaard over de twee machines zonder dat je een load balancer hoeft te gebruiken.
Deze IP's maak je virtueel aan op beide servers. IP-adres 77.243.226.77 is bijv. op server01 primair en ip-adres 77.243.226.78 is secondair. Op server02 precies omgedraaid. Stel nu dat server01 het begeeft, dan neemt server02 het virtuele IP-adres over van server01. Waardoor alle verzoeken uitkomen op server02.
Wij hebben enkele van deze setup's draaien op basis van FreeBSD i.c.m. CARP.
Tim.Bracquez
19/09/08, 12:33
Op het moment dat iemand www.ospito.nl bezoekt gaat die de ene keer naar 77.243.226.77 en de volgende keer naar 77.243.226.78. Dit is niet helemaal 50/50, maar verspreid de load al wel standaard over de twee machines zonder dat je een load balancer hoeft te gebruiken.
Round robin noemt dit: http://en.wikipedia.org/wiki/Round_robin_DNS
Via de DNS dit systeem opbouwen lijkt me wel wat teveel werk, gewoon 1 A recordje, 1 IP en zoals ze hierboven zeggen, gewoon zorgen bij uitval van server dat de andere het IP over neemt.
Vergeet wel niet je sessions etc, best lastig als er uitval is en je zit met een vol winkelmandje dat je dan ineens helemaal moet herbeginnen... (als voorbeeld)
Wouter-Ospito
19/09/08, 13:00
Round robin noemt dit: http://en.wikipedia.org/wiki/Round_robin_DNS
Via de DNS dit systeem opbouwen lijkt me wel wat teveel werk, gewoon 1 A recordje, 1 IP en zoals ze hierboven zeggen, gewoon zorgen bij uitval van server dat de andere het IP over neemt.
Vergeet wel niet je sessions etc, best lastig als er uitval is en je zit met een vol winkelmandje dat je dan ineens helemaal moet herbeginnen... (als voorbeeld)
Nadeel van 1 A-record en dus 1 IP-adres is dat de tweede server 99% van de tijd uit z'n neus aan het eten is. Op mijn manier spreid je de load nog. Zeker op eventuele drukke tijden heb je op mijn manier meer capaciteit achter de hand.
Tim.Bracquez
19/09/08, 13:05
Nadeel van 1 A-record en dus 1 IP-adres is dat de tweede server 99% van de tijd uit z'n neus aan het eten is. Op mijn manier spreid je de locatie nog. Zeker op eventuele drukke tijden heb je op mijn manier meer capaciteit achter de hand.
Dat klopt, maar mijn punt was dat je puur op DNS het niet echt 'eenvoudig' haalbaar is. Zoals gezegd dan met een virtual interface werken op de beide servers en die het laten over nemen.
Wel best goed idee er load balancing bij te nemen, aangezien je dan toch al bezig bent is dit een klein stapje verder.
Laat dit wel door iemand opzetten met ervaring!
hostlogic.nl
19/09/08, 14:32
Vergeet wel niet je sessions etc, best lastig als er uitval is en je zit met een vol winkelmandje dat je dan ineens helemaal moet herbeginnen... (als voorbeeld)
Bij een goed opgezette load-balanced omgeving, worden je sessies centraal opgeslagen (NFS of database). Daarnaast kun je bij een dubbel uitgevoerde load-balancer ook connection states laten synchroniseren, waardoor een standby load-balancer gewoon alle connecties overneemt. Dit zit volgens mij standaard in CARP en LVS.
Welke oplossing(gen) zijn er mogelijk als je niet alle eieren in hetzelfde provider/datacentrum mandje wilt leggen? Oftewel machine 1 moet in een ander datacentrum en een ander netwerk staan dan machine 2.
Bovendien moeten primary en secondary dns dezelfde records hebben.
Wie bepaalt dat primary en secondary dezelfde records moeten hebben? Hebben records bij gebruik van de PowerDNS geobackend (http://en.wikipedia.org/wiki/PowerDNS#PowerDNS_and_Wikimedia) identieke primary en secondary records?
Welke oplossing(gen) zijn er mogelijk als je niet alle eieren in hetzelfde provider/datacentrum mandje wilt leggen? Oftewel machine 1 moet in een ander datacentrum en een ander netwerk staan dan machine 2.
Als je geen eigen AS heb , kom je al snel uit op dns failover (dit kan bijvoorbeeld met een cisco global site-selector etc).
Wij hebben dit ook laatst gebouwd voor een klant , in elk datacenter een (authorized) dns server , en de A records daarop verwijzen naar de servers in dat DC.
Mocht iemand dus een dns lookup doen en het dc is niet bereikbaar dan zal hij automatisch de andere DNS server van ons proberen.
Je moet echter nog wel de servers zelf monitoren , anders kan het zijn dat een webserver niet werkt maar het DC gewoon te bereiken is.
Wij monitoren de servers , en bij uitval wordt er binnen de seconden een script gerunt wat de A records op de DNS server update of verwijderd voor de uitgevallen server.
Bovenstaande is slechts de oplossing in grote lijnen , hiernaast moet je kijken naar de TTL's van de dns servers en nog wat andere 'truukjes' om het helemaal goed te krijgen.
Als je geen eigen AS heb , kom je al snel uit op dns failover (dit kan bijvoorbeeld met een cisco global site-selector etc).
Wij hebben dit ook laatst gebouwd voor een klant , in elk datacenter een (authorized) dns server , en de A records daarop verwijzen naar de servers in dat DC.
Maar dan houdt je toch altijd het probleem van DNS-Caching, of ben ik nu gek?
Het een sluit het ander niet uit. ;)
Maar je hebt gelijk, als ik besluit TTL's te negeren, zoals een aantal ISP's doet, dan werkt het niet.
Dit kan zeker voor een laag budget ook gerealiseerd worden door middel van bijv. ucarp.
Je hebt een master en een slave server. Op beide servers is de data steeds hetzelfde door bijvoorbeeld rsync te gebruiken. De slave server pingt als het ware de master server met een configureerbaar interval. Als de slave server "merkt" dat de master onbereikbaar is zal het IP adres van de netwerkkaart in de slave server worden verandert naar het IP van de master server, waardoor alle requests etc. automatisch bij de slave server aankomen.
Alles gebeurt via bashscripts, dus in feite zijn alle acties bij een storing mogelijk (sms sturen, mailtje sturen, bepaald programma runnen etc.).
Denk erom dat de servers op deze manier wél in hetzelfde netwerk moeten staan, en dat komt de redundantie niet echt ten goede...
MediaServe
11/11/08, 17:15
Mocht je kiezen voor het Windows besturingssysteem, dan kun je alles out-of-the-box realiseren zonder 3th party software. Network Load Balancing, failover clustering, SQL replication, IIS replication en File replication. Het is redelijk eenvoudig op te zetten en het werkt perfect. Het werkt met minimaal 2 en maximaal 32 nodes per cluster. Een NAS of SAN is niet nodig.
@Diedx
DNS-Caching is inderdaad nog een probleem, maar je zou voor één lookup 2 A records terug kunnen geven, de meeste browsers proberen eerste het eerste IP adres, en als dat niet lukt het tweede IP adres. Dus voor een http gebaseerde omgeving kan de DNS methode een oplossing zijn.
Carp en MS Windows vallen in mijn beleving niet onder hoge beschikbaarheid, omdat beide oplossingen alleen functioneren als alle machines zich in hetzelfde netwerk bevinden, en dat betekent doorgaans hetzelfde gebouw.