Redudante oplossing, hoe?

[Glenn]

Beste collega's,

Een klant stelt de eis dat hij bij problemen aan de webserver niet langer dan 15 minuten offline wilt zijn. Dat is iets wat wij hem in onze normale omgeving niet kunnen garanderen. Daarom zijn we op zoek naar een oplossing.

Zijn site draait op Windows 2003 en hij gebruikt een MS SQL 2000 database. Replicatie van database en files gaat opzich best lukken maar ik vraag me af hoe ik het beste alles redudant kan maken. Mijn idee in eerste instantie was:

switch @ redbus -> server 1
indien server 1 offline dan switch @ redbus routeren naar server 2 @ ander DC
Het probleem is echter, wanneer we problemen bij onze netwerkleverancier hebben dan is die switch een single point of failure. Dat moet dus niet zo zijn. Hoe kan ik er voor zorgen dat een systeem (automatisch, maar dat is niet zozeer een eis) een andere server raadpleegt op het moment van downtime van 1 van de servers? Het is de bedoeling dat de servers in verschillende netwerken in verschillende DC staan.

Ik heb zitten denken aan het wijzigen van een DNS entry, maar dat wordt niet binnen 15 minuten opgepakt. Lijkt me dus ook geen goede oplossing.

Kan iemand mij een slinger de goede kant op geven?

[starfix]

Dit vraag ik me zelf ook al een tijdje af.

Ik dacht zelf aan de nameservers:

ns1.domein.nl = normaal
ns2.domein.nl = backup

dus op bijde servers:

ns1.domein.nl a 123.123.123.123 (normaal)
ns2.domein.nl a 124.124.124.124 (backupserver)

Werkt dit op deze manier, of...?

[Glenn]

Dus je bedoelt het www-record 2 IP's meegeven?

[starfix]

Dus je bedoelt het www-record 2 IP's meegeven?

Nee, beide servers normaal instellen, alleen de NS records anders.

Ik weet niet of dit werkt nogmaals.

Dus op de normale server:

ns1.domein.nl a 123.123.123.123 (normaal)
ns2.domein.nl a 124.124.124.124 (backupserver)
domeinnaam.nl a 123.123.123.123

En op de backupserver:
ns1.domein.nl a 123.123.123.123 (normaal)
ns2.domein.nl a 124.124.124.124 (backupserver)
domeinnaam.nl a 124.124.124.124

Lijkt me dat dit werkt, kan iemand dit bevestigen?

[ErikKosters]

Is dat ook acceptabel middels ripe dan?

[jobsnijders]

<snip>
Lijkt me dat dit werkt, kan iemand dit bevestigen?

Buiten dat het totaal niet een nette oplossing is heb je nog steeds het zelfde probleem als wat je hebt met 'snel het A record van een domein omgooien' -> de caches van de nameservers van providers e.d.

Wat ik zelf overweeg: je serverpark dubbeluitvoeren zodat de helft van je servers kan uitvallen en er geen probleem is, dan de ene helft van de servers in een ander DC zetten met minimaal 2 glasvezel verbindingen (via verschillende routes) tussen de lokaties voor het syncen van de data en dataverkeer. Dan in beide DC routers neer zetten die elk hun eigen transit/peering verbindingen hebben naar diverse partijen. Deze routers moeten wel in een soort active/active configuratie zitten.

Dan als DC-1 compleet van de aardbodem verdwijnt heb je nog: de helft van je servers, een router, een switch (of meerdere) en transit verbindingen. Ofwel, dan zou er geen probleem zijn.

[t.bloo]

Dit werkt niet om de doodeenvoudige reden dat nameservers at random worden gecontacteerd. De ene klant pakt van ns1 en de andere van ns2. Hier zijn al meer draadjes over geweest, en de uitkomst is ongeveer dat het internet systeem hier geen antwoord op heeft. Het enige dat je kunt doen is een loadbalancer achtige constructie, maar dan heb je weer een spof.

[jobsnijders]

Het enige dat je kunt doen is een loadbalancer achtige constructie, maar dan heb je weer een spof.

Waarom? je kan makkelijk twee loadbalancers in active/standby config neer zetten. LVS of een windows-oplossing bieden dat al geruime tijd.

[Glenn]

Buiten dat het totaal niet een nette oplossing is heb je nog steeds het zelfde probleem als wat je hebt met 'snel het A record van een domein omgooien' -> de caches van de nameservers van providers e.d.

Wat ik zelf overweeg: je serverpark dubbeluitvoeren zodat de helft van je servers kan uitvallen en er geen probleem is, dan de ene helft van de servers in een ander DC zetten met minimaal 2 glasvezel verbindingen (via verschillende routes) tussen de lokaties voor het syncen van de data en dataverkeer. Dan in beide DC routers neer zetten die elk hun eigen transit/peering verbindingen hebben naar diverse partijen. Deze routers moeten wel in een soort active/active configuratie zitten.

Dan als DC-1 compleet van de aardbodem verdwijnt heb je nog: de helft van je servers, een router, een switch (of meerdere) en transit verbindingen. Ofwel, dan zou er geen probleem zijn.

<offtopic>Job ook hier, wat een verrassing </offtopic

Punt is dat wij zelf geen netwerk hebben en dus niet kunnen peeren. Zo groot zijn we namelijk niet. We moeten het dus doen met de beschikbare hardware. Naar mijn idee houdt je altijd een SPOF, tenzij je vanuit de bezoeker een actie kan initieeren.

Waarom? je kan makkelijk twee loadbalancers in active/standby config neer zetten. LVS of een windows-oplossing bieden dat al geruime tijd.

En wat als je netwerk/uplinkprovider er uit ligt? Daar gaat het me namelijk ook om

[jobsnijders]

Punt is dat wij zelf geen netwerk hebben en dus niet kunnen peeren. Zo groot zijn we namelijk niet. We moeten het dus doen met de beschikbare hardware. Naar mijn idee houdt je altijd een SPOF, tenzij je vanuit de bezoeker een actie kan initieeren.

En wat als je netwerk/uplinkprovider er uit ligt? Daar gaat het me namelijk ook om

Als je zelf geen redudant netwerk kan bouwen dan moet je dat uitbesteden en eens vragen of je colo-aanbieder niet je op twee locaties een rack kan bieden met een vlan er tussen over redudante verbindingen en vanaf beiden lokaties redudantie wat betreft je transit. Maar het zonder eigen netwerk doen is denk ik vrij lastig of erg duur gezien een andere partij het dan voor je moet doen.

Een andere oplossing zou het volgende zijn: ookal zijn hier behoorlijke haken en ogen aan verbonden: je vind twee colo-boeren die allebei bereid zijn om jouw ip-range te announcen, dan zullen clients compleet at random bij 1 van de lokaties terecht komen, en misschien halverwege de tcpsessie switchen van lokatie (dit heet ook wel anycast). Je moet dan -heel- -erg- -goed- je syncing tussen de twee lokaties regelen, want als die uitvalt ben je nergens. Eigenlijk werkt anycast alleen voor dingen als DNS (bijvoorbeeld de K-rootserver doet het zo). Ik ken niemand die het zo met web doet. Ookal zou het voor 'read-only' websites wel kunnen.

Wat je trouwens ook kan doen dat wat simpeler is dan colo-boeren en ip-range announce bla bla bla:

2 lokaties, servers op beide lokatie met syncing heen en weer. en als magische middel: twee dns servers, 1 op beide lokaties, en dan split view dns met hele lage ttl's doen. zo doet akamai het ook. Op basis van de client zal de nameserver een bepaald IP (van lokatie a of lokatie b) terug geven, zo heb je dat een client gedurende een sessie de hele tijd wel op dezelfde lokatie komt. En als er een lokatie uitvalt moet je op de nameserver op de levende lokatie even de dns updaten (door de lage ttl zal deze wijziging erg snel gaan) en is voor de helft van de clients het even vervelend tot ze dns wijziging door hebben gekregen. de andere helft van de clients die op de levende lokatie al zat merkt niets. Zo doet akamai het geloof ik.

[Glenn]

Om maar even uit te gaan van het laatste wat in mijn ogen een stuk makkelijker is: meerdere malen wordt genoemd dat je dan met de caching van je provider zit. Of is dat te realiseren in 15 minuten?

[lifeforms]

Het probleem met lage TTL's is dat bijna alle gangbare browsers (MSIE, Firefox) dit negeren in bepaalde gevallen en toch het IP-adres cachen. Daarnaast zijn er ook providers die lage TTL negeren op hun resolvers. TTL's is dus geen volledige oplossing.

VRRP/CARP is een mooie oplossing om het IP-adres te delen, er is vast wel een equivalent voor Windows. Dan moeten de servers wel in hetzelfde subnet staan. Je kan de servers ook elk op hun eigen switch aansluiten, met elk een uplink, een kabel ertussen en STP o.i.d. Dan nog twee stroomfeeds om het echt af te maken.

[jobsnijders]

Om maar even uit te gaan van het laatste wat in mijn ogen een stuk makkelijker is: meerdere malen wordt genoemd dat je dan met de caching van je provider zit. Of is dat te realiseren in 15 minuten?

Door meerdere 'levels' van nameservers te gebruiken kun je een heel eind komen: http://cgi.di.uoa.gr/~ad/MDE519.docs/Akamai-How.pdf en http://www.edos-project.org/xwiki/bi...rable+4/Akamai

[hostlogic.nl]

2 lokaties, servers op beide lokatie met syncing heen en weer. en als magische middel: twee dns servers, 1 op beide lokaties, en dan split view dns met hele lage ttl's doen. zo doet akamai het ook. Op basis van de client zal de nameserver een bepaald IP (van lokatie a of lokatie b) terug geven, zo heb je dat een client gedurende een sessie de hele tijd wel op dezelfde lokatie komt. En als er een lokatie uitvalt moet je op de nameserver op de levende lokatie even de dns updaten (door de lage ttl zal deze wijziging erg snel gaan) en is voor de helft van de clients het even vervelend tot ze dns wijziging door hebben gekregen. de andere helft van de clients die op de levende lokatie al zat merkt niets. Zo doet akamai het geloof ik.

Met als probleem dat niet elke nameserver deze lage ttl honoreert.

Een redundante opzet over meerdere lokaties gaat alleen werken als je zelf het netwerk volledig redundant kunt configureren en tevens over beide lokaties volledig redundante storage hebt staan die ook nog eens in sync blijft. Ik denk dat je beter je klant kunt uitleggen hoeveel zoiets gaat kosten. Hij kan dan zelf uitrekenen hoeveel 15 minuten downtime hem kosten (bijvoorbeeld een aantal gemiste bestellingen of reclame inkomsten). Een cluster op 1 lokatie met dubbel uitgevoerde load-balancers, webservers en storage servers is wel te doen en kost een stuk minder.

[Glenn]

Ik dank u allen voor de reacties en het leesvoer, ik kan weer even vooruit