Onderwerp: Datacenter failover/Load Balacing

Oorspronkelijk geplaatst door w3media

Dit is het round robin gedeelte, is goed te gebruiken als je wat (http) load wil balancen maar niet echt optimaal voor wat jij zoekt. Ik zou kijken naar bijv. Baracuda Load balancers, deze redundant opstellen. Voordeel hiervan is dat bij downtime van 1 locatie zelf automatisch schakeld!

Hardware gaat het probleem hier niet oplossen, als je in 2 ip spaces zit gaat hardware dit niet oplossen, dan krijg je nog steeds 2 ips voor de load balancers en als 1 dc uitvalt dan nog steeds requests naar het ip dat er niet is.
Leuk dat de load balancer op locatie A ingesteld is dat bij de uitval van locatie A B gebruikt moet worden, helaas is de load balancer zelf ook niet bereikbaar.

Ik zie overigens technisch gezien geen enkel probleem om 1 ip space in 2 dcs te hebben, er zit waarschijnlijk een prijskaartje aan, redudancy kost best wel wat, echter op het moment dat het nodig is, zijn de inkomsten er meestal ook naar.

Round robin is eigenlijk alleen maar goed voor damage control. Stel je zet in 2 DC's je website die je met db en alles mirrored. Daarnaast pak je een mini vpsje in 6 andere DC's.
In je dns zet je 8 records onder 'www' naar de 8 verschillende vpssen. Daarnaast maak je een www1, www2...www8 met het specifieke ipadres.
De laatste 6 vpssen doen niet meer dan ieder 1/8 van je traffic vangen en dit redirecten naar je www1 of www2.
Als nu je www1 DC óf www2 DC uitvalt, dan laat je die laatste 6 vpssen gewoon naar de live www(1/2) redirecten.
Tegelijkertijd deactiveer je het dns record van het betreffende vps in het DC dat down ging.

Op die manier hou je 7/8 van je traffic in stand en al het nieuwe traffic komt op de live server uit. Blijft zoals Alan zegt een houtje-touwtje oplossing maar 6 mini linux vpsjes (hoeft geen windows te zijn tenslotte) die niks anders hoeven te doen dan web bezoekers redirecten, kosten geen drol natuurlijk.

Uiteraard is het mooier als je gewoon je ip kunt overstampen naar een ander dc. Nadeel is dat 99% van de hosters dat niet kan dus de keus daarin is een beetje beperkt.

Edit: Dat percentage roep ik overigens zomaar, geen idee of het zo is maar er zit inderdaad een prijskaartje aan voor zover ik nog weet uit mijn speurtijd naar ip space

Zoals iedereen al noemt zitten er vaak flinke kosten aan een IP takeover naar een ander DC en er zijn niet veel aanbieders die dit kunnen bieden. Naast deze feiten vraag ik me af of het uberhaubt wenselijk is. De volgende single point of failures los je er namelijk nog steeds niet mee op:
- Ernstige netwerk problemen bij je provider (waarschijnlijk zullen beide locaties hier last van hebben)
- Administratieve problemen bij je provider (failissement, afsluiting door conflict, enz)

In mijn ogen blijft een tweede DC bij een andere aanbieder op een ander netwerk de meest veilige oplossing. Wij doen dit voor een web-applicatie high available moet zijn ook op deze manier, een 'pain in the ass' blijft je DNS cache. Als het voor een web-applicatie is kun je je klanten aanbieden jullie DNS servers te laten gebruiken zodat je dit probleem kunt ondervangen.

De door enkelen al genoemde DNS-gebaseerde oplossing is inderdaad de manier die je zo onafhankelijk mogelijk maakt van welke problemen bij welke provider dan ook. Wij hebben daarbij goede ervaringen met Citrix NetScalers.
Daarmee zet je je web/sql/whatever servers achter de NetScalers. Daarbij kan de NetScaler bij falen van één/meerdere (wat jij maar wilt) servers dat betrefeende datacenter niet meer naar buiten 'publiceren' en alle requests naar het andere DC sturen (op basis van DNS). Daarbij zijn de NetScalers zelf de DNS server voor de zone waar je servers in zitten. Zij 'spelen' met de TTL waarden om een failover zo optimaal mogelijk te laten verlopen. Op het moment dat er een netwerkstoring is dan merkt de 'overgebleven NetScaler dat zijn broertje er niet meer is en zet alle bijbehorende records in DNS op pauze. Daardoor zal dus alleen het overgebleven DC nog door clients geraadpleegd worden.

Misschien niet helemaal een volledige en duidelijke uitleg, maar volgens mij is dat wat je hebben wilt.
Wil je details weten, vraag gerust.

Oorspronkelijk geplaatst door netwerkprutser

De door enkelen al genoemde DNS-gebaseerde oplossing is inderdaad de manier die je zo onafhankelijk mogelijk maakt van welke problemen bij welke provider dan ook. Wij hebben daarbij goede ervaringen met Citrix NetScalers.
Daarmee zet je je web/sql/whatever servers achter de NetScalers. Daarbij kan de NetScaler bij falen van één/meerdere (wat jij maar wilt) servers dat betrefeende datacenter niet meer naar buiten 'publiceren' en alle requests naar het andere DC sturen (op basis van DNS). Daarbij zijn de NetScalers zelf de DNS server voor de zone waar je servers in zitten. Zij 'spelen' met de TTL waarden om een failover zo optimaal mogelijk te laten verlopen. Op het moment dat er een netwerkstoring is dan merkt de 'overgebleven NetScaler dat zijn broertje er niet meer is en zet alle bijbehorende records in DNS op pauze. Daardoor zal dus alleen het overgebleven DC nog door clients geraadpleegd worden.

Misschien niet helemaal een volledige en duidelijke uitleg, maar volgens mij is dat wat je hebben wilt.
Wil je details weten, vraag gerust.

Blijft het probleem als netscaler A onbereikbaar is (bijvb netwerk plat) dat deze je niet naar netscaler op locatie B kan doorsturen omdat de IP space niet op beide locaties aanwezig is.

Ik ben dit eens tegen gekomen..



Maar dat gaat niet lukken zonder directe verbinding tussen de datacenters onderling.

Ik hoop dat xls hosting het niet erg vindt dat ik hun plaatje heb gebruikt

Oorspronkelijk geplaatst door cfmweb

Maar dat gaat niet lukken zonder directe verbinding tussen de datacenters onderling.

Zelfs al heb je een eigen vlan, mpls, dark fiber, etc tussen de 2 locaties dan lost dit het probleem nog niet op als je datacenter zonder bvb stroom zit. En dan nog moet je de ip range op beide locaties announcen. Dit werkt dus enkel als je een provider hebt die dit wil/kan doen voor je of je zelf LIR bent en/of je eigen (AS) routing doet.

De clou met de netscaler-oplossing is dat de nog-wel-bereikbare netscaler zijn (eigen/authoritive) DNS records aanpast op het moment dat het andere DC niet meer bereikbaar is. Daardoor zullen (na een korte tijd ivm DNS-caching) alle clients alleen nog maar een DNS-reply krijgen met IP-adressen van het nog-wel-levende DC. Uiteraard zijn beide netscalers ingesteld als authoritive DNS-servers voor de betreffende zone.
Stel dat je één DC in NL hebt en één DC in BE, dan kunnen de netsclaers zo worden ingesteld dat bv clients uit NL normaal zullen resolven naar het DC in NL, en clients in BE krijgen een IP adres in het BE-DC. Als je dat zou willen uiteraard, je kunt ook gewoon compleet active-passive doen, of gewoon random loadbalancing. Maar die geografische loadbalancing is ook erg mooi.

Voor alle duidelijkheid: je hebt op die manier geen 'interne verbinding' ofzo nodig tussen de beide sites, de hele constructie met de netscalers gebruikt gewoon 'het normale internet' om de beschikbaarheid van het andere DC (en van de servers op het eigen DC) te monitoren. Dat kunnen twee totaal verschillende providers zijn, met onafhankelijke IP-reeksen, op geografisch (en netwerk-technisch) totaal gescheiden lokaties. Dat je voor synchronisatie van je backend-servers misschien wél een 'interne verbinding' tussen beide sites wilt hebben is een ander verhaal, en niet relevant voor de netscaler-setup.
En stel dat er bv een HTTP-daemon een individuele server failt, dan wil je ook dat de clients naar een andere webserver op dezelfde lokatie of zelfs naar een server in het andere DC geredirect worden; al dat soort zaken zijn ook te regelen.

Oorspronkelijk geplaatst door netwerkprutser

De clou met de netscaler-oplossing is dat de nog-wel-bereikbare netscaler zijn (eigen/authoritive) DNS records aanpast op het moment dat het andere DC niet meer bereikbaar is. Daardoor zullen (na een korte tijd ivm DNS-caching) alle clients alleen nog maar een DNS-reply krijgen met IP-adressen van het nog-wel-levende DC. Uiteraard zijn beide netscalers ingesteld als authoritive DNS-servers voor de betreffende zone.
Stel dat je één DC in NL hebt en één DC in BE, dan kunnen de netsclaers zo worden ingesteld dat bv clients uit NL normaal zullen resolven naar het DC in NL, en clients in BE krijgen een IP adres in het BE-DC. Als je dat zou willen uiteraard, je kunt ook gewoon compleet active-passive doen, of gewoon random loadbalancing. Maar die geografische loadbalancing is ook erg mooi.

Voor alle duidelijkheid: je hebt op die manier geen 'interne verbinding' ofzo nodig tussen de beide sites, de hele constructie met de netscalers gebruikt gewoon 'het normale internet' om de beschikbaarheid van het andere DC (en van de servers op het eigen DC) te monitoren. Dat kunnen twee totaal verschillende providers zijn, met onafhankelijke IP-reeksen, op geografisch (en netwerk-technisch) totaal gescheiden lokaties. Dat je voor synchronisatie van je backend-servers misschien wél een 'interne verbinding' tussen beide sites wilt hebben is een ander verhaal, en niet relevant voor de netscaler-setup.
En stel dat er bv een HTTP-daemon een individuele server failt, dan wil je ook dat de clients naar een andere webserver op dezelfde lokatie of zelfs naar een server in het andere DC geredirect worden; al dat soort zaken zijn ook te regelen.

Voor zoiets simpels kan je vast wel iets anders gebruiken dan het dure netscaler. Maar dan is dit alsnog niet de beste oplossing, daarbij komt dat ik vaak genoeg meegemaakt heb sommige DNS servers de lak hebben aan de TTL.

Er zijn ongetwijfeld vergelijkbare/concurrerende manieren die goedkoper zijn dan een netscaler (waar je de duurste licentie nodig hebt voor dit soort grappen). Feit blijft dat je voor een provider- en netwerk-onafhankelijke oplossing mijns inziens altijd op een DNS-gebaseerde oplossing uit zult komen. Dat kan ook een soort DynDNS achtige constructie zijn ofzo. En ook daarbij ben je afhankelijk van andere caching-DNS servers die jouw TTL mogelijk niet willen volgen.
Een niet DNS-gebonden oplossing zie ik zo 1-2-3 niet, omdat je dan afhankelijk blijft van de bereikbaarheid van beide DC's.
Wellicht is het een optie om al je records gewoon voor beide DC's in DNS zetten en dan hopen dat alle clients beide IP-adressen zullen proberen. Volgens mij is de officiele standaard dat bv een webbrowser alleen het eerste IP-adres probeert, maar moderne browsers zullen ook het tweede adres uit de DNS-reply wel proberen. Maar dat lijkt me niet echt 'degelijk'...

Ook al zou je met welke routing-protocol dan ook je IP-reeks in beide DC's kunnen gebruiken: zodra er in die routing 'iets mis gaat' ben je alsnog down.
En ik had het idee dat de TS iets zocht wat zo onafhankelijk mogelijk is van de onderliggende netwerken.

Disclaimer: Mijn werkgever is Citrix Platinum Solutions Advisor, ik ben zelf ook gecertificeerd voor NetScaler en aanverwante producten.
De omschrijving van TS is precies waar wij de NetScaler vaak voor inzetten. Een alternatief op basis van netwerk-apparatuur (dus zonder DNS en met Cisco/Juniper) waarbij je dezelfde onafhankelijkheid hebt mbt de onderliggende netwerken, kan ik niet bedenken. Er is ongetwijfeld wel een combinatie van OpenSource tools te bedenken die hetzelfde resultaat heeft, maar daar ben ik niet in thuis.

Oorspronkelijk geplaatst door netwerkprutser

Er zijn ongetwijfeld vergelijkbare/concurrerende manieren die goedkoper zijn dan een netscaler (waar je de duurste licentie nodig hebt voor dit soort grappen). Feit blijft dat je voor een provider- en netwerk-onafhankelijke oplossing mijns inziens altijd op een DNS-gebaseerde oplossing uit zult komen. Dat kan ook een soort DynDNS achtige constructie zijn ofzo. En ook daarbij ben je afhankelijk van andere caching-DNS servers die jouw TTL mogelijk niet willen volgen.
Een niet DNS-gebonden oplossing zie ik zo 1-2-3 niet, omdat je dan afhankelijk blijft van de bereikbaarheid van beide DC's.
Wellicht is het een optie om al je records gewoon voor beide DC's in DNS zetten en dan hopen dat alle clients beide IP-adressen zullen proberen. Volgens mij is de officiele standaard dat bv een webbrowser alleen het eerste IP-adres probeert, maar moderne browsers zullen ook het tweede adres uit de DNS-reply wel proberen. Maar dat lijkt me niet echt 'degelijk'...

Ook al zou je met welke routing-protocol dan ook je IP-reeks in beide DC's kunnen gebruiken: zodra er in die routing 'iets mis gaat' ben je alsnog down.
En ik had het idee dat de TS iets zocht wat zo onafhankelijk mogelijk is van de onderliggende netwerken.

Disclaimer: Mijn werkgever is Citrix Platinum Solutions Advisor, ik ben zelf ook gecertificeerd voor NetScaler en aanverwante producten.
De omschrijving van TS is precies waar wij de NetScaler vaak voor inzetten. Een alternatief op basis van netwerk-apparatuur (dus zonder DNS en met Cisco/Juniper) waarbij je dezelfde onafhankelijkheid hebt mbt de onderliggende netwerken, kan ik niet bedenken. Er is ongetwijfeld wel een combinatie van OpenSource tools te bedenken die hetzelfde resultaat heeft, maar daar ben ik niet in thuis.

Inderdaad als het niet anders kan dan is DNS de enige oplossing.

@TS wel eens gedacht aan een andere provider voor een dergelijke oplossing die het wel kan aanbieden?

Een goed DC gaat helemaal niet zo snel down. Een oplossing (my 2 cents) is om te zorgen dat je een goede HA oplossing in minstens 1 DC hebt. Met goede HA bedoel ik dan dat je replicatie op ander powerlijnen, uplinks of zelfs een andere 'straat' in het dc (of leveranciers daarbinnen) hebt.
En daarnaast draai je als het echt moet een failover op een ander dc.

Problemen met je main servers worden door de lokale HA opgevangen en een totale DC meltdown resulteert dan in een beperkte bezoekersdrop. (dit is afhankelijk van je aantal 'entrypoints' voor je sites)

Concreet betekent dit dat slechts een deel van je bekende bezoekers (die reeds een www[x].domein.nl hebben resolved) problemen ervaart voor de duur van a) het minimumtijd van de TTL van je dns record+dns caching van tussenpartijen of b) de daadwerkelijke storing van het DC (wat in de trant van slechts minuten kan liggen).

De kans dat het extreemste gebeurd en dit ook nog op een belangrijk moment is, is meestal wel erg klein als je een beetje fatsoenlijke hardware hebt en de 'damage' (verlies aan inkomsten/image voor die tijdsduur) weegt vaak niet op tegen de kosten voor de magische 5 negens.

En ook niet onbelangrijk... als je niet reeds erg goed bekent bent met die materie en het in stand houden van een HA setup, kun je in het begin bij een storing best nog wel eens méér downtijd hebben dan zonder HA setup

Bij de waarschuwing van systemdeveloper kan ik me alleen maar aansluiten.

Welke redundantie-oplossing je ook toe gaat passen: je moet je realiseren dat die redundantie-oplossing op zichzelf (de oplossing als geheel) waarschijnlijk een single point of failure zal worden. Dus die zul je zo mogelijk nóg alerter moeten monitoren dan je al met je normale omgeving doet, en je moet een oplossing kiezen (of in het geval van TS: aanbevelen) die je begrijpt, waarvan je de risico's kent en waar je je 'veilig' bij voelt.

De simpelste failover is waarschijnlijk dat je op beide lokaties een DNS-server hebt draaien, en dat je in geval van een 'probleem' met een DC, in de DNS server van je overgebleven DC handmatig alle records weghaalt die naar het falende DC wijzen. Je downtime is dan ongetwijfeld wat meer dan een paar minuten, maar je failover-systeem zal nooit 'per ongeluk' in werking treden, en als je documentatie goed en up-to-date is dan is het redelijk fool-proof.
Het is maar net wat je precies hebt draaien, welke snelheid van failover je (je klant) wilt hebben, en wat je daarvoor overhebt (in termen van geld, maar ook extra beheer).

De oplossing die ik beschreef is 'de ultieme geografisch gescheiden HA' die ik me kan bedenken, maar afhankelijk van de eisen mogelijk ook duur en complex. Voor het gemak had ik maar impliciet aangenomen dat je de overwegingen al gemaakt had zoals systemdeveloper die erg duidelijk omschrijft. Je hebt het immers expliciet over een failover+loadbalancing over meerdere DC's; en hoe je het ook doet, dat is geen goedkope wens. :-)

Het gebeurt niet zelden dat een klant verwacht dat 'redundant == geen downtime'. En dat lijkt me een onmogelijke opgave, hoeveel geld je ook uitgeeft.

Oorspronkelijk geplaatst door netwerkprutser

Ook al zou je met welke routing-protocol dan ook je IP-reeks in beide DC's kunnen gebruiken: zodra er in die routing 'iets mis gaat' ben je alsnog down.

Tja dan kan je dit ook doortrekken op netscaller, switches, dns, etc. Wat als je dan je dns (A, MX, ..) query's verkloot dan werkt het ook niet meer, dat zijn menselijke fouten net zoals je routing verkloten en menselijke fouten blijven nu ook eenmaal SPOF tenzij je eerst een heel team de configs laat doorlezen en dan nog.

Verder heeft je (eerste) bericht wel een zeer hoog SPAM gehalte aangezien je even komt verkondigen dat netscaler de perfecte oplossing is terwijl je voor citrix zelf werkt. Dat is zoals zeggen dat juniper brol is en cisco beter is als je voor cisco werkt.

Oorspronkelijk geplaatst door The-BosS

Verder heeft je (eerste) bericht wel een zeer hoog SPAM gehalte aangezien je even komt verkondigen dat netscaler de perfecte oplossing is terwijl je voor citrix zelf werkt. Dat is zoals zeggen dat juniper brol is en cisco beter is als je voor cisco werkt.

Wil je alsjeblieft wel goed lezen voordat je beschuldigingen uit !
Ik heb die melding in een volgende post er inderdaad bijgezet omdat ik toen merkte dat ik 'mijn oplossing' ging verdedigen. Ik werk ABSOLUUT NIET voor Citrix zelf; mijn werkgever is onder andere Citrix partner (ook VMware/Cisco/Juniper/MS/...) en ik probeer TS niks te verkopen. Ik geef alleen maar aan dat zijn vraag mij sterk aan de NetScaler-achtige oplossing deed denken. Ik ken in alle eerlijkheid geen vergelijkbare oplossing, maar die zal er met een slimme combinatie van opensource tools ongetwijfeld te maken zijn.
Ik leg de kwalificatie spam dan ook naast me neer: TS vraagt om mogelijke oplossingen (vraagt zelfs expliciet naar 'echte loadbalancers'), ik noem er één en omschrijf waarom. Niet ongevraagd en zeker niet commercieel bedoeld. Ik ben niet namens mijn werkgever op dit forum actief, maar puur omdat ik in het verleden bij een provider gewerkt heb en tegenwoordig af en toe hier nog wel eens rondkijk.

on-topic: over de SPOF... daarom sluit ik me ook bij systemdeveloper aan: je moet uitkijken dat je geen 'te mooie' extra laag ertussen gaat leggen die de boel zo complex maakt dat het risico op fouten toeneemt. De kans op failure zit dan vooral in de toenemende complexiteit van het totale systeem.
Dat ik inschat dat het dynamisch routeren een relatief hoge failkans heeft komt, omdat TS aangeeft dat de provider dat niet ondersteunt. Nou kun je misschien met wat truuctjes (en/of wat langer aandringen bij de hoster) wel wat verzinnen om je IP-reeks op twee lokaties te krijgen, maar dat leek mij geen betrouwbare weg. Whatever je verzint voor je failover, dat zal [een beetje | heel veel] extra complexiteit toevoegen. En de klant zal zich van die keuze bewust moeten zijn; is dat het waard.