failover (website) naar andere colocation

Pagina: 1
Acties:

  • DDX
  • Registratie: April 2001
  • Laatst online: 23:35
ik heb een website lopen die eigenlijk 100% up moet zijn
binnen de colocation is dit al opgelost door de website te loadbalancen

maar het kan natuurlijk altijd voorkomen dat de colocation een probleem heeft
(stroom uitval oid (of erger brand))

nu kan ik ergens anders dezelfde website neerzetten (via rsync etc, allemaal geen probleem)
alleen hoe zorg ik ervoor dat de bezoerks bij downtime automatisch op de failover server uitkomen ?

heeft iemand hier ervaring mee/tips ?

ik weet dat f5 networks oplossing heeft hiervoor, maar volgens mij zijn die erg overkill/duur (ik heb via google een prijs proberen te zoeken en kwam prijzen tegen in de tientallen k's)

nu dacht ik zelf aan de oplossing door op beide servers een dns server te configureren
(en de TTL erg laag zetten) voor het domein en bij downtime (hoe bepaal ik dat, want misschien heeft de backupserver wel netwerkproblemen?) de dns service starten op de backupserver.
als hoofdserver (dus dns) down is zullen dns requests automatisch uitkomen bij de backupserver.

https://www.strava.com/athletes/2323035


  • _-= Erikje =-_
  • Registratie: Maart 2000
  • Laatst online: 22-12-2025
Helaas let niet iedereen op de TTL van DNS records waardoor het soms dus nog een dag kan duren eer je op het juiste IP uitkomt

  • Coen Rosdorff
  • Registratie: Januari 2000
  • Niet online
_-= Erikje =-_ schreef op woensdag 08 december 2004 @ 23:27:
Helaas let niet iedereen op de TTL van DNS records waardoor het soms dus nog een dag kan duren eer je op het juiste IP uitkomt
Dit valt reuzachtig mee. Het valt zelfs zo mee dat het in de pratijk een uitstekend bruikbare oplossing is.

Probleem is wel: Je hebt een dns server nodig in een 3e colo. Die server zal met met ping of connecten naar poort 80 moeten bepalen of er een server down is, en zo ja overschakelen naar de andere colo.

Ik pas deze constructie toe. Niet voor 100% uptime maar vanwege 2 low-budget projecten. Servers staan op adsl lijnen dus dan is de kans op downtime wat groter. Als de primaire server niet bereikbaar is dan gaan de alle requests binnen 10 minuten naar de backup server.

  • DDX
  • Registratie: April 2001
  • Laatst online: 23:35
little_soundman schreef op donderdag 09 december 2004 @ 02:37:
[...]
Probleem is wel: Je hebt een dns server nodig in een 3e colo. Die server zal met met ping of connecten naar poort 80 moeten bepalen of er een server down is, en zo ja overschakelen naar de andere colo.
en hoe bepaal je dan of colo3 niet een probleem met de nw verbinding heeft richting 1 van de 2 andere colo's ?
(dus eigenlijk dat er geen problemen zijn bij 1 of 2)

TTL probleem zal volgens mij ook wel meevallen
want ook 3-DNS (van F5) maakt hier volgens mij gebruik van

https://www.strava.com/athletes/2323035


  • ReLight
  • Registratie: Augustus 2001
  • Laatst online: 19-02 15:02

ReLight

echo("What Now ? !")

Je hebt dus een cross constructie nodig.
2 dns's en 2 website locaties fysiek.

Mijn zoon & dochter zijn de toekomst, de rest is tijdsvermaak. Home assistant & & Nibe S2125-12/SMO-S40, RMU-s40 & Tado - Volvo C40 ER, SE


  • Koffie
  • Registratie: Augustus 2000
  • Laatst online: 20:24

Koffie

Koffiebierbrouwer

Braaimeneer

Voordat we nu weer een ellenlang welles/nietus discussie over TTL krijgen; gebruik de serach eens zou ik zeggen ;)
redundancy, snelheid van dns of dyn. dns

Tijd voor een nieuwe sig..


  • DDX
  • Registratie: April 2001
  • Laatst online: 23:35
ReLight schreef op donderdag 09 december 2004 @ 09:02:
Je hebt dus een cross constructie nodig.
2 dns's en 2 website locaties fysiek.
ok dat lijkt me duidelijk
plan was dus om 2 colocations te doen :

1:
-main dns server / main webserver

2:
-main dns server (die dus up komt met ander ip voor de website / sec webserver

eventueel heb ik ergens anders nog sec dns (draait het nu ook voor andere domeinen) dit zou ik eventueel via rsync oid vanaf de op dat moment primary dns server kunnen copyen naar de sec. server

maar op welke manier besluit ik wanneer een colocation down is
(en hoe vertel ik dat eventueel aan de andere colocation)

ik zat vandaag te denken aan een modem connectie (of huurlijn) tussen beide locaties
en als die verbinding eruit ligt (of afgelopen x tijd geen signaal gehad) besluiten dat de colocation down is
maargoed ook in dat geval kan het natuurlijk ook een lijn probleem zijn

iemand nog ideeen ?

https://www.strava.com/athletes/2323035


  • silvans
  • Registratie: Juni 2004
  • Laatst online: 22-02 09:40
Is het een suggestie om je standby lokatie identiek in te richten als je hoofdlokatie, en dat je vervolgens (al dan niet met hulp van een ISP) een routing protocol als BGP inzet om je ip verkeer te kunnen uitwijken als dat nodig mocht blijken?

Silvan

[ Voor 20% gewijzigd door silvans op 09-12-2004 21:48 ]


  • DDX
  • Registratie: April 2001
  • Laatst online: 23:35
het gaat hier slecht om 1 website
dus ik denk niet dat ripe wilt meewerken om een PI adres range te geven hiervoor

daarnaast vraag ik mij af of bgp hiervoor een oplossing kan zijn
hoe zorg je ervoor dat er normaal gesproken nooit verkeer naar de backupwebserver gaat (die nml niet 100% sync loopt ivm niet continu backups)

https://www.strava.com/athletes/2323035


Verwijderd

Eigenlijk moet je niet zeuren over geld als je echte redundancy wilt. Mocht er toch geen investeringsgeld aanwezig zijn, dan zou je een hele goedkope oplossing kunnen bedenken, nameljk: Host je site ook bij een ISP, en laat in de dns 2 A-records aanmaken voor de www host. Dit is niet waterdicht, maar als je dan echt een keer stroomuitval hebt, en je UPS-jes zijn leeg, dan heeft een bezoeker in ieder geval nog 50% kans op het goed bereiken van de website. Als je er dan ook nog voor kunt zorgen dat je zelf de DNS kunt beheren, en je de TTL op 5 minuten mag zetten (al dan niet op je eigen dns servers als bij een DNS service provider), dan heb je op het moment van nood nog altijd de mogelijkheid om het foute a-record te verwijderen. Ik geef toe dit is niet 100% waterdicht is, maar het is wel een supergoedkope semi-redundante oplossing.

  • DDX
  • Registratie: April 2001
  • Laatst online: 23:35
meph: het hoeft allemaal niet super goedkoop
maar de f5 3-dns oplossing gaat richting de 50k euro zover ik zo snel heb kunnen zien
en dat is best wel extreem voor 1 website

en gewoon RR dns is geen optie
de 2e webserver is puur een standby

https://www.strava.com/athletes/2323035


Verwijderd

Kan je dan niet beter gewoon een webserver bij een isp plaatsen waar een aggregaat aanwezig is e.d.? Met daarvoor eventueel een loadbalancer naar je eigen locatie toe?

  • DDX
  • Registratie: April 2001
  • Laatst online: 23:35
Meph: huidige webserver draait al bij een colocation waar noodstoom etc is (en heeft daar ook een failover webserver staan via een loadbalancer)

ik nu een 2e colocation gebruiken voor het geval er bij de 1e colocation problemen zijn
brand bijvoorbeeld
(ok komt als het goed is nooit voor, maar is in het verleden wel eens gebeurd (level3 problemen met noodstroom))

[ Voor 4% gewijzigd door DDX op 11-12-2004 12:11 ]

https://www.strava.com/athletes/2323035


  • DJSmiley
  • Registratie: Mei 2000
  • Laatst online: 20-02 10:59
DDX schreef op zaterdag 11 december 2004 @ 12:10:
Meph: huidige webserver draait al bij een colocation waar noodstoom etc is (en heeft daar ook een failover webserver staan via een loadbalancer)

ik nu een 2e colocation gebruiken voor het geval er bij de 1e colocation problemen zijn
brand bijvoorbeeld
(ok komt als het goed is nooit voor, maar is in het verleden wel eens gebeurd (level3 problemen met noodstroom))
Je DNS draait ook bij 2 verschillende providers, in verschillende datacenters?

zonder werkende DNS servers kun je wel een hoop failover-servers hebben maar komt een bezoeker daar uiteindelijk nooit.

  • DDX
  • Registratie: April 2001
  • Laatst online: 23:35
ja dns draait op dit moment al op 3 verschillende locaties

https://www.strava.com/athletes/2323035


  • ijdod
  • Registratie: April 2000
  • Laatst online: 17:44
DNS misbruiken kan, maar het blijft een lapmiddel. Als je echte redundantie wil, dan zul je dat op laag 2 en 3 moeten oplossen, naast de benodigde redundantie op de gewenste service zelf, bv door een (redundante) load balancer. Allemaal niet zo heel erg spannend, op zich. Simpelweg het elimineren van elke single point of failure.

Root don't mean a thing, if you ain't got that ping...


  • DDX
  • Registratie: April 2001
  • Laatst online: 23:35
ijdod: ok maar hoe doe ik dat ?
een PI range bij ripe krijg je niet zomaar zover ik weet
dus bgp naar 2 providers (vanaf 2 verschillende plekken) gaat niet zomaar lukken....

(oplossing van f5 gaat ook op basis van dns)

https://www.strava.com/athletes/2323035


  • ijdod
  • Registratie: April 2000
  • Laatst online: 17:44
DDX schreef op zondag 12 december 2004 @ 11:17:
ijdod: ok maar hoe doe ik dat ?
een PI range bij ripe krijg je niet zomaar zover ik weet
dus bgp naar 2 providers (vanaf 2 verschillende plekken) gaat niet zomaar lukken....

(oplossing van f5 gaat ook op basis van dns)
Een eigen AS is de fraaiste oplossing, maar is niet noodzakelijk. De meeste zakelijke providers kunnen datzelfde ook leveren. Je blijft dan binnen de AS van die privider.

Het is net hoe belangrijk de redundantie is, en de snelheid van failover voor alle gebruikers. DNS verliest met name bij die laatste punten. Niet alle DNS servers honoreren erg korte TTL's. Je eigen DNS is dan wel om, maar als je doelgroep nog steeds oude data uit hun DNS krijgen, is je site voor hen nog steeds plat.

Weet overigens niet wat de nettiquette hier eventueel nog over te zeggen heeft.

Root don't mean a thing, if you ain't got that ping...


  • DDX
  • Registratie: April 2001
  • Laatst online: 23:35
ijdod schreef op zondag 12 december 2004 @ 19:50:
[...]


Een eigen AS is de fraaiste oplossing, maar is niet noodzakelijk. De meeste zakelijke providers kunnen datzelfde ook leveren. Je blijft dan binnen de AS van die privider.
mja dat is leuk
een PA range hebben we al
maar dit blijft toch binnen 1 colocation

lost niets op als de colocation in de fik vliegt oid
Het is net hoe belangrijk de redundantie is, en de snelheid van failover voor alle gebruikers. DNS verliest met name bij die laatste punten. Niet alle DNS servers honoreren erg korte TTL's. Je eigen DNS is dan wel om, maar als je doelgroep nog steeds oude data uit hun DNS krijgen, is je site voor hen nog steeds plat.

Weet overigens niet wat de nettiquette hier eventueel nog over te zeggen heeft.

https://www.strava.com/athletes/2323035

Pagina: 1