Veel grote bedrijven hebben een dubbel datacentrum. Tegen rampen en tegen uitval. Maar vliegtuigen crashen niet zo heel vaak en de praktijk toont aan dat de toename in complexiteit een averechtse werking heeft op de beschikbaarheid.
Vaak als een klant vraagt naar oplossingen voor de verbetering van de beschikbaarheid, komt de optie van een dubbel datacentrum ter tafel. Als er iets mis gaat in het eerste datacentrum kan er worden doorgedraaid in het tweede. Als ze de bedrijfsvoering echt belangrijk vinden komt de optie van een derde naar boven. En als de bedrijfsvoeringen echt heel, heel erg belangrijk is, dan moeten beide datacentra allebei actief zijn.
Ok, werkt dit?
Nee, maar laat me deze ‘nee’ in perspectief plaatsen. Als het om een statische webpagina gaat dan kan het. Als er een bijna ongelimiteerd budget, een perfecte architectuur, mensen en beheer is, dan wel. Maar dit is niet realistisch. Dus, waar gaat het mis? Om twee datacentra samen te laten werken als één, waarbij de één de taken van de andere overneemt als er wat mis gaat, vraagt om een extreem simpele opzet dan wel eentje die nagenoeg perfect gebouwd is.
Een voorbeeld uit de natuur: als een platworm in tweeën gesneden wordt, zal elke helft het onbrekende verloren deel regenereren. Meer complexe soorten krijgen het maar niet voor elkaar zich deze handige feature eigen te maken. Het zelfde gaat op voor je infrastructuur. Twee harde schijven elkaar laten spiegelen werkt perfect, twee netwerkkabels als een team werkt vloeiend. Gedistribueerde file systemen worden al wat moeilijker. En als je er aan begint om meerdere systemen je toegang te laten geven tot één enkele database, weet iedereen dat je op je vingers kan natellen wanneer het mis gaat. De complexiteit die nodig is om met een dubbel datacentrum de beschikbaarheid te verhogen is zo enorm dat als het eerste omvalt, de andere er waarschijnlijk achter aan gaat.
Hoe sterk is de behoefte aan hoog beschikbaarheid?
Er is een theoretisch maximum aan de beschikbaarheid die je kan bereiken met één datacentrum. Maar paradoxaal genoeg hebben de meeste grote organisaties al een dubbel datacentrum en de praktijk leert dat deze extra complexiteit juist de beschikbaarheid ondermijnt. Alle grote organisaties hebben gaten in hun beschikbaarheid gehad. Zelfs de meeste banken hadden niet werkende websites. Dit dubbele datacentrum, dat werkt dus niet.
Maar al die banken, isp’s, cloud leveranciers, auto fabrieken en wat zo meer, zijn ze verdwenen? Zijn ze failliet gegaan omdat ze er een half uur uit lagen? Nee, ze zijn er allemaal nog! Het is dus veilig om te zeggen dat de meeste organisaties een uitval overleven. En aangezien vliegtuigen niet meerdere keren per jaar het datacentrum in vliegen, is het dus ook veilig om aan te nemen dat als het noodlot toeslaat, deze langere tijd van onbeschikbaarheid ook overleefd wordt (waarschijn zit dan toch iedereen voor de tv).
Hoe maak je dan je infrastructuur ‘meer beschikbaar’
Met de kennis van dit alles kan je de beschikbaarheid van je infrastructuur verhogen door de complexiteit terug te dringen. En accepteer onbeschikbaarheid. Ja, accepteer ‘wat’ onbeschikbaarheid. Gebruik dit bijvoorbeeld om van datacentrum om te schakelen om onderhoud te doen. Er is nauwelijks complexiteit in het stoppen van een systeem op één locatie en die vervolgens op een andere locatie weer te starten. Kost hooguit tien minuten, als je het handmatig doet. En om twee uur ‘s nachts maakt niemand zich hier druk over, als ze vooraf geïnformeerd zijn. Met als resultaat, als puntje bij paaltje komt, je bijgewerkt op niveau en beschikbaar bent.
Wat is dan het nut van een tweede datacentrum?
Natuurlijk moet er een uitwijk zijn voor de infrastructuur en grote organisaties zouden hun eigen tweede datacentrum moeten hebben voor beschikbaarheid. Maar hoe gebruik je deze zinvol? Ten eerste sla al je gegeven op beide locaties op. Verspreid dan de systemen die geen onderlinge afhankelijkheid hebben, in ieder geval geen kritische, over beide datacentra. Zorg dat er reserve capaciteit is om alle systemen op één locatie te kunnen draaien. Gebruik deze reserve capaciteit onder normale omstandigheden voor test en acceptatie.
Conclusie
Het is het simpele principe: Keep It Simple Stupid of een andere voor de Bingo: Minder is meer. We weten het allemaal, dus laten we de daad bij het woord voegen en eenvoudig betere infrastructuur bouwen.
Beste Alex,
Je titel sprak mij erg aan vanwege de gewaagde titel. Ondanks dat je je in je artikel wat nuanceert ben ik het niet met je eens. Ja, je kan je oplossing zo complex maken als je wil, maar in de basis gaat het, als je naar de infrastructuur kijkt, om de interconnectie tussen de datacenters en de manier waarop je je (IP) bereikbaarheid configureert. Of je je omgeving nu active-active of acitve-passive configureert, in mijn ogen is het beide prima mogelijk. Nu is wat ik ervan denk niet zo belangrijk, maar we hebben ook klanten die naar volle tevredenheid zulke oplossingen inzetten.
Een twin of dubbel datacenter oplossing is altijd maatwerk, maar je hoeft het niet heel moeilijk te maken. Je moet goed nadenken over een stukje routering, firewalling en datareplicatie en dan hoef je niet eens handmatig om te schakelen.
Ik ben het absoluut met je eens dat je dingen niet moeilijker moet maken dan nodig, en een twin datacenter oplossing is ook niet voor iedereen noodzakelijk, maar kan wel degelijk toegevoegd waarde hebben. Over publiceren wij binnenkort een whitepaper over twin datacenter. Wellicht vind je het leuk om die t.z.t. te ontvangen.
Ik ben benieuwd naar de verdere discussie!
Alex,
Ik denk dat dit nog een interesante discussie gaat worden omdat de meningen hier nogal sterk over verschillen.
Het meest belangrijke is om eerst in kaart te brengen wat de wensen en eisen zijn vanuit de business. Definieer samen met het management je RPO/RTO en SLA’s. Creeer ook een aantal scenario’s. Wat moet er nog beschikbaar zijn als er een bepaalde escalatie zich voordoet? En kan ik dan ook met bijvoorbeeld minder performantie en capaciteit uit de voeten?
Stap 2 is het classificeren van je data en applicaties. Niet alles hoeft hoog beschikbaar te zijn. En op deze manier kan een mogelijk 2e locatie of platform intern/extern kosten effectief uitgevoerd worden.
Doe je dit niet en zet je een kopie van alles op een 2e locatie neer dan is dit in mijn ogen een zeer duur betaalde verzekeringspremie.
Pas als deze discussies zijn gevoerd kan er gekeken worden naar de techniek. Nog te vaak wordt er direct naar de techniek gekeken zonder dat de randvoorwaarden duidelijk zijn.
Kiezen voor een active-active setup is een oplossing die ik steeds vaker zie. Een groot voordeel van active-active is door dat je actief van beide omgevingen gebruik maakt, en je zeker weet dat een omgeving ook echt werkt. Bij een active-passive setup komt het helaas nog te veel voor dat de DR-site niet up to date is of zelfs nog erger helemaal niet werkt.
Ik wil ook nog even kort terug komen op enkele uitspraken die je doet.
“Maar al die banken, isp’s, cloud leveranciers, auto fabrieken en wat zo meer, zijn ze verdwenen? Zijn ze failliet gegaan omdat ze er een half uur uit lagen? Nee, ze zijn er allemaal nog! Het is dus veilig om te zeggen dat de meeste organisaties een uitval overleven”
Natuurlijk worden we bang gemaakt door de desbetreffende leveranciers. Maar het verschilt per organisatie hoe lang een bepaald proces niet beschikbaar mag zijn en wat de kosten daar van zijn.
“Er is nauwelijks complexiteit in het stoppen van een systeem op één locatie en die vervolgens op een andere locatie weer te starten. Kost hooguit tien minuten, als je het handmatig doet. En om twee uur ‘s nachts maakt niemand zich hier druk over, als ze vooraf geïnformeerd zijn. Met als resultaat, als puntje bij paaltje komt, je bijgewerkt op niveau en beschikbaar bent”
Ook dit verschilt per omgeving. Tien minuten is in sommige gevallen erg ambitieus. En niet iedere organisatie kan om 2 uur ’s nachts even plat. Voor creditcardmaatschappijen, banken en andere online diensten is dit niet wenselijk.
Ook ik heb al heel wat ‘hoog-beschikbare’ oplossingen gezien waarbij de complexiteit van het geheel de beschikbaarheid eerder verlaagt dan verhoogt. Teruggaan naar de meest simpele oplossing – die echter wel aan de eisen voldoet! – is dus altijd verstandig. Het is daarom toch een interessante ontwikkeling dat twee datacenters tegenwoordig een stuk simpeler te realiseren zijn dan vroeger. Server virtualisatie heeft daar belangrijk aan bijgedragen, echter ook betaalbare breedbandige verbindingen. Met twee ‘lokale’ datacenters is het dus relatief simpel om bijvoorbeeld een stretched Oracle RAC cluster en een stretched VMware cluster te bouwen. Dat levert een active-active situatie op, met zowel hoge beschikbaarheid als hoge performance. Dat ene vliegtuig dat eens in de tienduizend jaar op beide datacenters tegelijkertijd neerstort moet je dan inderdaad maar voor lief nemen…
Je hebt een die simpele theorie om te bereken wat verdubbeling in een keten betekent.
Datacenters worden parallel geschakeld vanuit de systemen gezien en dan krijg je te maken met de reciproque. Deze reciproque zorgt ervoor dat de beschikbaarheid van beide datacenters extreem hoog moet zijn om bij parallel schakeling dezelfde beschikbaarheid te kunne waarmaken. Omdat de kans dat een datacenter uitvalt dan afneemt, -je neemt allemaal maatregelen om de uptime van beide datacenters te verhogen-, zal een twin datacenter concept het gevoel geven van betrouwbaarheid.
Bij omschakelmomenten is een datacenter kritisch, maar aan de andere kant kan je ook zoveel maatregelen nemen dat het niet meer uitmaakt wat er uitvalt en is uiteindelijk alleen een samenstelsel van calamiteiten doorslaggevend.
Twin datacenters zijn vaak individueel in staat om enkele fouten op te vangen, bij een aaneenschakeling van fouten, bijvoorbeeld de spanning valt weg en de koelsystemen restarten niet na inschakeling van het nood-aggregraat, dan is er “grande malheur”. Dus bij de 2e of derde fout gaat een 2e datacenter pas een rol spelen en dan kan er zoveel mis gaan dat het hele systeem faalt en er downtime ontstaat. In testscenario;s wordt meestal maar 1 fout getest. Lees de kranten er maar op na onder de kop rampen, meestal zijn 2 factoren of meer de oorzaak.
Je moet als organisatie goed kijken waar je je geld in investeert, wat je verzekert en welke premie je betaald.
Onbeschikbaarheid accepteren zou wat mij betreft geen uitgangspunt zijn, maar zorg ervoor dat je reële risico’s verzekerd en case-by-case kijkt wat wel en niet acceptabel is. Eens in de zoveel jaar moet je toch iets vervangen en dat kan vaak niet zonder downtime.
Om een betrouwbaar en beschikbaar systeem te bouwen is een twin datacenter trouwens geen uitgangspunt, daarbij ga ik grotendeels mee met het artikel van Alex.
Interessante discussie.
Wat mij hierin opvalt is dat we bij dergelijke constructies steeds blijven focussen op het falen van het ‘ijzer’. Opslagcapaciteit welke stuk gaat, netwerkverbindingen die eruit vliegen etc. Tegelijkertijd is er m.i. te weinig aandacht voor andere bedreigingen, die een dergelijke omgeving kunnen bedreigen. Logische fouten bijvoorbeeld. Of ‘human error’ tijdens upgrades, installaties, wijzigingen. Daar helpt een Dual Datacenter concept je dus niet. Typisch een onderbelicht risico, waar ik eerder rendement uit zou verwachten dan uit vergaande maatregelen om ‘alleen’ de infrastructuur te beschermen.
Leuk artikel, goed voor dialoog!
Voor degenen die denken dat het toch wel te doen is om met max 10 minuten down een heel datacenter uit te wijken, heb ik maar een advies: test het.
Ga op een weekend eens gepland uitwijken, en dan niet 1 systeem, maar het hele datacentrum. Simuleer een crash van een vliegtuig:
– eerst is er ontzettend veel paniek en alle management-lagen gaan iedereen van alles vragen. juist op het moment dat de techneuten geconcentreerd moeten werken.
– vele systemen gaan niet automatisch over en hebben een duwtje in de rug nodig door een techneut. De beschikbaarheid van het systeem is dus afhankelijk van de beschikbaarheid van een techneut. En vergeet het fabeltje dat een collega ‘het ook wel kan’. Ja, meestal kan hij het wel, maar doet dat 2-200 keer langzamer vanwege gebrek aan domeinkennis.
– vaak is de capaciteit van het uitwijkcentrum onvoldoende. Uit kostenbesparing is een disk array met minder interfaces uitgerust. Of kunnen er er geen backups gemaakt worden. Of is de internet bandwidth te laag.
– In grote organisaties komt het voor dat sommige systemen bij een uitwijk data loss hebben. Recovery van data – indien mogelijk – is vaak erg moeilijk en tijdrovend.
– en er gebeurt nog veel meer onheil die anderen in hun reacties hebben opgesomd.
Houd op met discussieren en filosoferen. Je kunt pas autorijden als je het theoretisch examen en het praktijkexamen succesvol hebt afgerond en je bent pas uitwijkbaar als je het in de praktijk hebt aangetoond.
Doe eens voorzichtig het voorstel om een heel datacentrum uit te wijken en als er veel weerstand is weet je zeker dat je niet uitwijkbaar bent. Immers, als je uitwijkbaar bent en iedereen is daarvan overtuigd, dan zou een uitwijktest gewoon jaarlijks plaatsvinden.
Als er een vliegtuig op je datacentrum valt, zullen klanten begrip hebben en is downtijd geaccepteerd. 10 minuten is te weinig… dus we geven het bedrijf met pech 24 uur om uit te wijken.
Is er uberhaupt wereldwijd een groot bedrijf dat binnen 24 uur een succesvolle totale uitwijk gerealiseerd heeft? Ik ken het niet.
Beste Alex,
Wat je hier beweert is de reinste kolder. Ik ben dan al vier jaar niet meer actief in de IT (pensioen) maar het dubbel en meervoudig uitvoeren van systemen kan de beschikbaarheid voor de gebruiker tot nagenoeg 100% brengen.
Voorwaarde is wel dat je naast dat je de juiste omgevingen kies, een IBM P serie systeem is wat betreft hardware en besturing systeem honderden malen betrouwbaarder als een eenvoudige enkelvoudige Intel of AMD Server.
Maar ook met eenvoudige servers kan je een hele hoge beschikbaarheid bereiken, indien je de juiste infrastructuur ontwerp en installeren.
Hiernaast moet zowel de infrastructuur, beheer middelen, applicaties , netwerk en opslagsystemen zodanig op elkaar af gestemd zijn dat een hoge beschikbaarheid gegarandeerd kan worden.
Bij mijn laatste werkgever EDS ben ik een van de auteurs geweest van de internationale EDS richtlijnen om hoge beschikbaarheid te garanderen. Hiernaast was hoge beschikbaarheid voor EDS dagelijkse kost. Het schaduwen van immense databases via eigen netwerken was dagelijks werk en werd vaak gebruikt om grote systemen fysiek te verhuizen. Dit konden langdurige processen zijn, want een operationele database van enkele Terabyte heeft nogal wat tijd nodig om te kopiëren en gesynchroniseerd te raken.
Het geheim van hoge beschikbaarheid is eenvoudig:
Of je gaat voor veel en eenvoudig of voor weinig en zeer complex.
( VMware farm versus een mainframe).
Hiernaast moet je op alle niveaus van hardware, beheer, middelen en software alles op elkaar afstemmen.
Dit is veelal geen eenvoudige klus, omdat het vaak heel moeilijk is om management en gebruikers te overtuigen van de noodzaak.
Het is vaak een overweging van welk risico men wilt lopen, weet je dat je als Web winkel dat een uitval van enkele uren je heel veel omzet kost en je aan de rand van de afgrond kan brengen, kies dan voor de veilige weg en investeer in beschikbaarheid.
Wens je vanwege de kosten en dus hogere opbrengsten dit niet te doen, dan maak je nu misschien veel winst, maar ga je bij een storing misschien wel failliet.
Als je de krant leest zie je dagelijks voorbeelden van bedrijven en mensen die voor de geldelijke winst gingen en nu in de problemen zitten.
Beste Alex,
Eén, twee of nog meer datacentra is een keus die niet lichtzinnig gemaakt wordt. Noodzaak hiervoor wordt weloverwogen gemaakt op basis van een risico analyse. Hierbij moeten, zoals Ruud al aangeeft kritieke bedrijfsprocessen geïdentificeerd worden. Daarbij moet aangegeven worden wat de maximale acceptabele tijd (RTO) is dat systemen niet functioneren. Hoe korter de verstoring mag zijn hoe minder keus je uiteindelijk hebt in oplossingen.
Een dubbel en geografisch datacenter is dan misschien niet expliciet verplicht of optimaal maar kijkend naar de risico factoren wel vaak aan te bevelen. Al was het alleen maar om het verlies aan gegevens (RPO) zo klein mogelijk te houden. Want wat als vlak voor de door jouw voorgestelde nachtelijke synchronisatie en net op de dag dat je salaris gestort is er een ramp plaats vindt?
Inderdaad leidt het niet beschikbaar zijn van een service direct tot een faillissement maar kijkend naar het verloop van de aandelenkoers van RIM na de verstoringen met de Blackberry lijkt het me niet goed voor het bedrijfsresultaat. Uit ervaringscijfers blijkt dat als de kritische bedrijfsprocessen niet binnen 72 uur hersteld zijn klanten weglopen.
Je betoog snijdt echter op sommige punten wel hout maar komt wat mij betreft niet helemaal goed uit de verf. Voorbeelden met websites die niet beschikbaar zijn hebben namelijk niet zoveel te maken met dubbele datacentra maar meer met menselijke fouten. Want mislukte IT projecten kunnen evengoed tot afbreuk leiden en daarmee het bedrijfsresultaat beïnvloeden. En inderdaad fouten repliceren naar tweede datacenter verbeterd de beschikbaar van de service niet.
Vanuit mijn ervaring met uitwijken van een grote bank, kan ik zeggen dat het wel heel goed kan werken als er uitgeweken wordt. Het is goed om te bepalen welke processen zeer kritisch zijn v.w.b. klantenwelbevinden en deze te borgen. Andere processen hebben misschien wat slack en kunnen met enige vertraging bijgezet worden. Als dit goed in kaart kan worden gebracht.(niet de business die het hardste schreeuwt maar de business die het meeste geld kan verliezen bij uitval) Dit vereist dus een apart uitwijkmanagement met mensen die bij voorkeur veel ervaring hebben. (in de markt de o zo dure medewerkers) Het hebben van deze kennisbommen maakt het in geval van uitval opstarten van de backup systemen tot een kort durend proces. Als je uitgaat van de mensen die daartoe certificaten en diploma’s hebben zal blijken dat het nog niet altijd zo heel vlot verloopt. Het heeft dus de voorkeur om hier mensen voor op te leiden die gedegen weten wat ze doen en waar op te letten in geval van calamiteit. Ook moet er continu worden nagedacht of de huidige structuur nog voldoet en of het wellicht nog beter zou zijn om sommige zaken over nog veel meer lokaties te verspreiden. In dit geval zou ik willen aanhalen de uitval bij de NS simpel omdat de noodaccu’s van de systemen maar op 1 locatie stonden en laat daar nou net een brandje zijn geweest…. geen vliegtuig maar een redelijk onschuldig evenement met zeer grote gevolgen. Het zou goed zijn als daar goed over wordt nagedacht en wellicht betaal je dan wat geld voor een toekomst zonder zorgen en een toekomst waarin de service geborgd is zodat het klantwelbevinden met sprongen omhoog gaat. Simpel betekent niet altijd goedkoop maar goed. Bedenk dus waar je in investeert als het om het draaiend houden van een bedrijf en het leveren van de service naar klanten. En het lijdt geen twijfel dat uitwijk altijd geoefend moet worden. Al was het alleen maar om de downtijd tot een minimum te beperken en ook ervaren te raken met dit fenomeen wat wellicht nooit nodig is. Het is als een airbag. Kostbaar en hopelijk nooit nodig, maar de vraag is zou je het risico willen nemen…
Zeker een zeer interessante discussie die kennelijk hier een hoop losmaakt.
Absoluut ben ik het er mee eens dat er zeer mooie technologische oplossingen zijn, maar Alex heeft absoluut een punt. Hoe erg is het om een keertje wat minder beschikbaar te zijn. Met andere woorden: Wat zijn bedrijven bereid om voor al deze mooie oplossingen te betalen? Het is altijd een afweging van kosten versus risico. Deze businesscase zal niet altijd positief uitvallen. Keep it simple dus.
Daarnaast heb ik in de praktijk vaak genoeg meegemaakt dat als het echt erop aankomt de mooie oplossingen niet functioneren. Wat Marcus terecht opmerkt: Test het!! Dat gebeurd in de praktijk te weinig. Heb het lef om een keer echt de stekker eruit te trekken en evalueer wat er gebeurd.