Bekijk Volledige Versie : Failover server - Hoe regelen?
cyberbrain
17/05/08, 20:01
Ik heb sinds een half jaar een web+mail server met circa 25 websites draaien in een datacentrum in A'dam. Gisterochtend kwam ik erachter dat mijn server totaal onbereikbaar was. Ik heb de ISP daar gebeld, die hebben wat controles uitgevoerd en volgens hun zou het allemaal goed moeten werken. Het vreemde is dat ik wel ping's terugkreeg van mijn server, maar verder niets.
Toch maar naar het datacentrum gereden (geen feest vanuit Nijmegen) en daar kwam ik erachter dat iemand anders 'mijn' ip adressen op zijn server heeft ingesteld en ik ze dus na een reboot kwijt was. Ping replies kwamen dus ook niet van mijn server, maar van die andere server.
Na wat overleg met mijn ISP, die er niet 123 achter kwam wie de boosdoener was, heb ik 2 nieuwe IP-adressen gekregen. Op zich natuurlijk geen punt, behalve dat ik mijn eigen nameserver draai. Plesk heeft gelukkig een tool om in 1 keer alle IP adressen in de systeemconfig te wijzigen en voert ook alle nodige wijzigingen aan de DNS server uit. En als de nameserver updates bij SIDN rond zijn werkt alles weer zoals het hoort.
Uiteraard ga je over dit soort dingen pas nadenken als het een keer fout is gegaan, maar ik wil binnenkort een 2e server aanschaffen en deze in een ander datacentrum plaatsen. Nu kan ik dmv cronjobs een volledig plesk-systeem backuppen en op de tweede server importeren, maar hoe regel ik dit in de DNS? Bij MX records kun je een prioriteit opgeven, bij A records volgens mij niet. Mijn idee was dus om de eerste server als primary DNS te registreren en de 2e als secondary. De tweede server zou dan records hebben die naar zijn eigen IP verwijzen, zodat een website bezoeker automatisch naar de tweede webserver 'kijkt' op het moment dat de eerste nameserver niet reageert.
Dit lijkt me alleen geen correcte oplossing. Hoe kan ik dit oplossen, zodat ik (liefst automatisch) kan overschakelen op de tweede server op het moment dat de eerste offline gaat?
Alvast bedankt!
Ik zou je host wat meer onderdruk zetten, een beetje host moet vrij eenvoudig kunnen uitvinden waar een IP zich bevindt.
Je kan meerdere A records aanmaken met dezelfde naam die naar een ander IP verwijzen. De browser zou dit moeten zien en automatisch een andere pakket mocht het mislukken echter geen garanties.
Dat is inderdaad geen correcte oplossing, mede omdat een client niet per definitie alleen naar de primary DNS kijkt en pas bij de secundary aanklopt als de primary niet reageert. Als simpele oplossing kan je round-robin DNS gebruiken; je maakt dan voor hetzelfde domein 2 A-records maar met een ander IP-adres. Wil je een betere oplossing dan wordt het ook een stuk ingewikkelder. Overweeg ook eens om niet alles dubbel te draaien, maar bijvoorbeeld alleen DNS en mail. Dat is wel relatief eenvoudig op te zetten. Dan zijn misschien bij een storing de websites offline, maar mail blijft wel doorwerken.
cyberbrain
17/05/08, 22:45
Ik zou je host wat meer onderdruk zetten, een beetje host moet vrij eenvoudig kunnen uitvinden waar een IP zich bevindt.
Je kan meerdere A records aanmaken met dezelfde naam die naar een ander IP verwijzen. De browser zou dit moeten zien en automatisch een andere pakket mocht het mislukken echter geen garanties.
Aha, dat vroeg ik me dus af. Ik had het al eens eerder gehoord, maar ik dacht dat ik ergens had gelezen dat het niet 'hoort'. Maar pakt de browser dan willekeurig een IP uit de lijst met A-records, of gaat dat op volgorde? Want als de tweede server bijvoorbeeld eens in de 12 uur wordt gesychroniseerd en de browser kijkt op de tweede server kan het gebeuren dat een email of webpagina nog niet op de tweede server staat.
PimEffting
17/05/08, 22:59
Wat je nu beschrijft heet "round robin" en is niet geschikt voor redundancy.
http://en.wikipedia.org/wiki/Round_robin_DNS
Redundancy over meerdere datacentra kun je bereiken met "global load balancing'' bijvoorbeeld, maar dat zijn erg kostbare oplossingen. Beter kun je een eigen subnet bij je provider vragen in een eigen VLAN waar anderen geen toegang toe hebben. Dan heb je dat probleem in ieder geval opgelost.
Even verder bordurend op deze discussie..
Ik heb in een datacenter 2 server staan, die volledig aan elkaar gelijk zijn (rsync van vhosts, mail en mysql) Ook ik loop met het probleem dat ik niet weet hoe ik de server direct kan laten overpakken zodra er iets op de "master server" fout gaat.
Zijn er nog goeie ideeen??
Tim.Bracquez
11/02/09, 18:09
kijk eens naar heartbeat...
kijk eens naar heartbeat...
HB is een mogelijkeid om te zien of je server nog online is (in leven is). Ik zoek een manier om dedowntime te minimaliseren..
(ip adressen omzetten, DNS switch etc)
HB is een mogelijkeid om te zien of je server nog online is (in leven is). Ik zoek een manier om dedowntime te minimaliseren..
(ip adressen omzetten, DNS switch etc)
En wat denk je dat je kunt verbinden aan een melding van heartbeat die ziet dat server #1 down is? Juist! Een ip/dns switch.
tada: http://www.linuxjournal.com/article/9074
Een beginnetje...
Nou is drbd in 2 verschillende DC's misschien een beetje moeilijk (niet onmogelijk) maar wat je wel kunt doen is heartbeat gebruiken om vanaf DC2 te monitoren en zodra server1 onbereikbaar is, laat je server2 de DNS aanpassen bij je domeinboer.
Let dan wel op dat het niet een tijdelijke storing is in het netwerk van een van beide dc's en dat hij het niet aanpast bij 1 failed check.
En wat denk je dat je kunt verbinden aan een melding van heartbeat die ziet dat server #1 down is? Juist! Een ip/dns switch.
En DNS info wordt nergens op internet in een cache gezet ofzo? En als de geldigheid te kort zet, negeren sommige provides de settings en houden 24 uur aan ofzo.... Kun jij zoveel dns switches wat je wilt, is het nog niet meteen overal bekent...
En DNS info wordt nergens op internet in een cache gezet ofzo? En als de geldigheid te kort zet, negeren sommige provides de settings en houden 24 uur aan ofzo.... Kun jij zoveel dns switches wat je wilt, is het nog niet meteen overal bekent...
Dat heeft niet zozeer met de TTL te maken die te kort is. Sommige providers hanteren een grens van 24 uur voordat ze hun cache bijwerken. Doe je niets aan, het is alleen niet conform de RFC's.
hostlogic.nl
16/02/09, 11:40
Het hierboven beschreven probleem kun je niet zelf met technische maatregelen voorkomen. Dit is een verantwoordelijkheid die bij je provider hoort te liggen, zij zijn immers verantwoordelijk voor de uitgifte van IP adressen en de controle hierop.
Met heartbeat, drbd, rr-dns e.d. kun je een technisch probleem op een van je servers redelijk goed oplossen. Een probleem met dubbele IP adressen lost het echter niet voor je op. Let er echter wel op dat je alle componenten in je setup dan ook high-available moet uitvoeren. Daarnaast vereisen deze oplossingen over het algemeen ook weer extra kennis, niet alleen bij het inrichten maar ook in geval van eventuele problemen.
Mijn advies zou zijn: keep it simple, zeker omdat het een server met slechts 25 websites betreft. Een slecht doordachte redundante omgeving gaat waarschijnlijk meer downtime veroorzaken dan deze incidentele menselijke foutjes.
En DNS info wordt nergens op internet in een cache gezet ofzo? En als de geldigheid te kort zet, negeren sommige provides de settings en houden 24 uur aan ofzo.... Kun jij zoveel dns switches wat je wilt, is het nog niet meteen overal bekent...
Net als dat beide DC's op hetzelfde tijdstip down zijn: sommige problemen kun je niet 100% ondervangen, je kunt wel proberen het zo dicht mogelijk in de buurt van die 100% te krijgen.
Wat hostlogic hierboven zegt klopt ook; IP's die aan 2 servers worden toegewezen kun je niet afvangen, dat is de verantwoordelijkheid van de netwerkboer. Echter kan heartbeat hier wel werken. HB kijkt namelijk niet alleen of het IP online is, het kijkt of de juiste server dat is. Zo niet voert HB het noodplan uit en wordt alles dus omgezet.
hostlogic.nl
16/02/09, 15:57
Echter kan heartbeat hier wel werken. HB kijkt namelijk niet alleen of het IP online is, het kijkt of de juiste server dat is. Zo niet voert HB het noodplan uit en wordt alles dus omgezet.
Dat werkt natuurlijk alleen als beide servers van jezelf zijn. Ik begrijp uit het bericht van de TS dat een andere klant van zijn provider zijn IP's had "ingepikt". Daar doe je als klant helaas weinig aan.
Dat werkt natuurlijk alleen als beide servers van jezelf zijn. Ik begrijp uit het bericht van de TS dat een andere klant van zijn provider zijn IP's had "ingepikt". Daar doe je als klant helaas weinig aan.
Ehm.. nee. Nogmaals lezen in context van bovenstaande situatie en gegeven suggesties aub.
hostlogic.nl
16/02/09, 23:16
ok, point taken. In dat geval wordt een opzet waarbij je heartbeat over meerdere lokaties wilt laten werken zeer complex. Je ontkomt er niet aan om meerdere netwerkpaden tussen beide lokaties te gebruiken, bij voorkeur zelfs 1 non-ip link, om valse down-meldingen te voorkomen en toch snel genoeg te kunnen overnemen in geval van een echter storing. Daarnaast MOET je stonith inrichten om een split-brain cluster te voorkomen, iets wat ook niet meevalt als een netwerkstoring optreedt op 1 van beide lokaties.
Ik zeg niet dat het onmogelijk is, maar nogmaals, de kosten lopen flink op.
soulshepard
17/02/09, 10:42
om even wat semi offtopic ruis te creeren..
Na wat overleg met mijn ISP, die er niet 123 achter kwam wie de boosdoener was, heb ik 2 nieuwe IP-adressen gekregen.
Alvast bedankt!
?!?!?
je kan toch op switches zoals cisco heel duidelijk en snel zien op welke switch poort, welk ip adres in gebruik is met commando's zoals show arp & mac-adres table.. .. ik noem maar een voorbeeld.
apart..
je zou je klanten het maar moeten vertellen als het nu 25, 250 of meer zijn. het is en blijft een kwalijke zaak.
redundancy over verschillende netwerken en datacenters is en blijft duur, en in feite alleen goed te doen met een AS en of DNS load balance technieken.
zaken die niet echt rendabel zijn voor de wat "kleinere" hoster. je zou je dan in kunnen kopen met een rack of een deel rack om dan mee te liften op de infrastructuur en netwerk van je hoster. (wat je in feitte al doet) maar als die je niet serieeus neemt en je zomaar ip adressen laat veranderen..?!?! :unsure:
je kan ook je daarop voorbereiden met een tweede server in het zelfde datacenter / hoster en netwerk. zodat je twee servers hebt met allebei wat ip adressen. als je elke dag een backup naar elkaar maakt kan je in geval van nood, handmatig en relatief snel ingrijpen (denk ook aan kapotte hardware) omdat je een recente backup op de tweede server hebt kan je remote ingrijpen en de websites draaien op het "oude" of als het niet anders kan zelfs een nieuw ip adress..
het is dan wel niet volautomatisch maar je bent wat sneller en hebt het zelf in de hand. en een stuk goedkoper lijkt me.... de kans dat iemand dan al je ip adressen inpikt zou heel klein zijn (of je moet het doel zijn van iemand die je servers echt down wil brengen lijkt mij)
los daarvan had je in dit geval misschien zelfs het macadress gezien van de server die je ip adress heeft/had overgenomen (of de switch die dat weer weet)
maar goed ik heb niet alle reply posts gelezen.. werd getriggerd door het zomaar moeten aanpassen van ip adressen.. dus als ik dubbele dingen heb gezegd. sorry :)
Soul
om even wat semi offtopic ruis te creeren..
je kan ook je daarop voorbereiden met een tweede server in het zelfde datacenter / hoster en netwerk. zodat je twee servers hebt met allebei wat ip adressen. als je elke dag een backup naar elkaar maakt kan je in geval van nood, handmatig en relatief snel ingrijpen (denk ook aan kapotte hardware) omdat je een recente backup op de tweede server hebt kan je remote ingrijpen en de websites draaien op het "oude" of als het niet anders kan zelfs een nieuw ip adress..
het is dan wel niet volautomatisch maar je bent wat sneller en hebt het zelf in de hand. en een stuk goedkoper lijkt me.... de kans dat iemand dan al je ip adressen inpikt zou heel klein zijn (of je moet het doel zijn van iemand die je servers echt down wil brengen lijkt mij)
Soul
Hoe stel je je dit scenario voor (2 server gelijk aan elkaar in hetzelfde DC)
Zou het dan mogelijk zijn om de IP's van server 1 (bij een storing) om te zetten naar server 2?
Dit is namelijk mijn situatie (2 servers, zelfde DC, zelfde data middels rsinc) zoek alleen naar een geautomatiseerde oplossing als er problemen zijn.
hostlogic.nl
18/02/09, 09:56
Hoe stel je je dit scenario voor (2 server gelijk aan elkaar in hetzelfde DC)
Zou het dan mogelijk zijn om de IP's van server 1 (bij een storing) om te zetten naar server 2?
Dit is namelijk mijn situatie (2 servers, zelfde DC, zelfde data middels rsinc) zoek alleen naar een geautomatiseerde oplossing als er problemen zijn.
Dit is heel eenvoudig te realiseren met Heartbeat (http://www.linux-ha.org/). Of Plesk hiermee overweg kan weet ik echter niet.
Hou er rekening mee dat je na een uitwijk ook terug zult moeten naar de oorspronkelijke server, dus denk vooraf na hoe je de data weer terug gaat syncen.
soulshepard
18/02/09, 13:46
Hoe stel je je dit scenario voor (2 server gelijk aan elkaar in hetzelfde DC)
Zou het dan mogelijk zijn om de IP's van server 1 (bij een storing) om te zetten naar server 2?
Dit is namelijk mijn situatie (2 servers, zelfde DC, zelfde data middels rsinc) zoek alleen naar een geautomatiseerde oplossing als er problemen zijn.
het is mogelijk als je in dezelfde switch / vlan zit om dan op de tweede server het ip nummer over te nemen ik zit zelf in een niet automatisch scenario
server1
ip1
floating ip2 voor hosting op server 1
server2
ip3
floating ip4 voor hosting op server 2
als iemand ip1 of ip2 overneemt dan kan je je hosting ip dus ip2 naar server 2 verhuizen handmatig en een import restopre backup draaien op deze server en klaar. het is dan niet automatisch maar wel snel up
als je het automatisch wilt dan heb je twee zaken een service die draait en de storage die gesynced moet zijn. dan kom ik in mijn view al bij twee servers of op een een of andere manier een volume/partitie die tussen beide server gesynced word en dat 1 node daar actief op draait. mogelijk een clustering services kan je dan plesk heen en weer de nodes laten opstarten. maar op linux heb ik nog nooit clustering gedaan, kan daar weinig overzeggen. veel uitzoek en test werk.
wat ook een mogelijkheid is zijn 3 servers waar van twee met publieke ip adressen en daaronder een Iscsi doos ala openfiler. je beide servers hebben dan allebei toegang tot deze storage, via een cluster of vmware / xen cq een virtualisatie laag zou je dan van 1 node naar de andere kunnen verhuizen al dan niet handmatig of automatisch. al met al er is geen quick en easy oplossing voor dit. veel mogelijkheden en technieken, maar allemaal foutgevoelig met hun afhankelijkheden en kosten.
daarom heb ik zelf gekozen voor twee servers die allebei in het zelfde datacenter zitten wel in dezelfde switch/vlan/netwerk allebei draaien ze directadmin en worden naar elkaar toe gebackuped met de backup methode van directadmin, daarmee zou ik als het echt moet het ip adres configureren (of ander) op de andere server en de websites/databases en mail kunnen importeren/restoren op een andere server, we praten dan over minimaal een paar uur of een dag aan dataverlies. je praat dan ook over een kleine disaster recovery.
linux clustering zou kunnen werken tussen twee servers volgens mij en een heel goed punt maar plesk of directadmin cluster aware maken lijkt een uitdaging en veel uitzoek werk.. wat minder tijd zou kosten is volgens mij een virtueele machine automatisch heen en weer gooien. maar goed my 2 cents
het is mogelijk als je in dezelfde switch / vlan zit om dan op de tweede server het ip nummer over te nemen ik zit zelf in een niet automatisch scenario
server1
ip1
floating ip2 voor hosting op server 1
server2
ip3
floating ip4 voor hosting op server 2
als iemand ip1 of ip2 overneemt dan kan je je hosting ip dus ip2 naar server 2 verhuizen handmatig en een import restopre backup draaien op deze server en klaar. het is dan niet automatisch maar wel snel up
als je het automatisch wilt dan heb je twee zaken een service die draait en de storage die gesynced moet zijn. dan kom ik in mijn view al bij twee servers of op een een of andere manier een volume/partitie die tussen beide server gesynced word en dat 1 node daar actief op draait. mogelijk een clustering services kan je dan plesk heen en weer de nodes laten opstarten. maar op linux heb ik nog nooit clustering gedaan, kan daar weinig overzeggen. veel uitzoek en test werk.
wat ook een mogelijkheid is zijn 3 servers waar van twee met publieke ip adressen en daaronder een Iscsi doos ala openfiler. je beide servers hebben dan allebei toegang tot deze storage, via een cluster of vmware / xen cq een virtualisatie laag zou je dan van 1 node naar de andere kunnen verhuizen al dan niet handmatig of automatisch. al met al er is geen quick en easy oplossing voor dit. veel mogelijkheden en technieken, maar allemaal foutgevoelig met hun afhankelijkheden en kosten.
daarom heb ik zelf gekozen voor twee servers die allebei in het zelfde datacenter zitten wel in dezelfde switch/vlan/netwerk allebei draaien ze directadmin en worden naar elkaar toe gebackuped met de backup methode van directadmin, daarmee zou ik als het echt moet het ip adres configureren (of ander) op de andere server en de websites/databases en mail kunnen importeren/restoren op een andere server, we praten dan over minimaal een paar uur of een dag aan dataverlies. je praat dan ook over een kleine disaster recovery.
linux clustering zou kunnen werken tussen twee servers volgens mij en een heel goed punt maar plesk of directadmin cluster aware maken lijkt een uitdaging en veel uitzoek werk.. wat minder tijd zou kosten is volgens mij een virtueele machine automatisch heen en weer gooien. maar goed my 2 cents
Klinkt goed.. (in jou geval zou ik eens naar rsync (of iets dergelijks) gaan kijken. Hiermee kan je het dataverlies eenvoudig terugbrengen naar minuten ipv uren).
Voor het omzetten van de ip's heb ik alleen nog een script nodig, en dan is het proces (hopelijk) helemaal geautomatiseerd.
Dus als er nog mensen zijn die creatief met eth's (middels script) opstarten zijn, hou ik me aanbevolen.