Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Disaster recovery bij een public cloud (IaaS)

 

Computable Expert

Bart M. Veldhuis
Cloud Architect, ReasonNet. Expert van Computable voor de topics Cloud Computing, Infrastructuur en Security.

Stel, de provider waar je al jouw bedrijfsapplicaties hebt ondergebracht ondervindt een heftige storing. Het is inmiddels dag zes van de storing en de bedrijfsapplicaties zijn nog steeds offline. De provider is telefonisch en per e-mail volstrekt onbereikbaar en communiceert geen oplostermijn. Als dat het moment is waarop jij je realiseert dat je een plan had moeten hebben voor dit soort scenario’s, ben je te laat. Er zit niets anders op dan te wachten tot de provider de storing weer onder controle heeft en de dienstverlening wordt hervat.

De afgelopen weken heeft een dergelijk situatie zich voorgedaan bij een provider in Nederland. Ik heb diverse klanten van deze provider aan de telefoon gehad, met de paniek doorklinkend in hun stem. Voor deze klanten kon ik alleen iets betekenen als ze zelf over een kopie van de data en de applicaties beschikten, voor de meesten zat er niets anders op dan te wachten en ervan te leren. In dit artikel lees je welke mogelijkheden je hebt als afnemer van IaaS en waar jouw beperkingen liggen.

Er zijn diverse methodieken beschikbaar om de continuïteit van de applicaties te waarborgen in het geval van een storing in de infrastructuur van de provider. Het nadeel van de meeste van deze oplossingen is dat ze de medewerking van de provider vereisen voor de inrichting, het beheer en onderhoud, maar bovenal voor de daadwerkelijke uitwijk. En dat is nou precies het punt: de provider is onbereikbaar.

Private cloud

Idealiter kun je als klant zelf beslissen over de inzet van een disaster recovery (dr)-oplossing en kun je de daadwerkelijke uitwijk ook zelf initiëren. Bij het gebruik van een private cloud (IaaS) zijn er diverse mogelijkheden om een betrouwbare dr-oplossing te implementeren. Denk hierbij bijvoorbeeld aan:

  • Stretched virtualisatie clusters (EMC Vplex / NetApp Metro Clusters).
  • Storage gebaseerde replicatie in combinatie met geautomatiseerdedr- tooling (EMC Recoverpoint, HP Lefthand in combinatie met VMware vSphere Site Recovery Manager).
  • Replicatie op virtualisatie niveau (Veeam Backup & Replication/Zerto Virtual Replication/Novell Platespin Migrate).

Public cloud

Bij public cloud (IaaS), waar er meerdere klanten op dezelfde fysieke infrastructuur draaien, zijn de mogelijkheden aanzienlijk beperkter en bovendien lastiger te realiseren. De professionelere providers hebben een dr-oplossing in het standaard product portfolio (wees bedacht op goed bedoelde specials). Zijn deze er niet, dan ben je aangewezen op de oplossingen die binnen het controledomein van jou als klant liggen. Meestal behelst dit alles vanaf de virtuele laag tot aan de applicatie. Replicatie op virtualisatie niveau is dan een mogelijkheid. Deze oplossingen zijn echter (op dit moment) nog onvolwassen als het gaat om public cloud (IaaS). Het resultaat is dus dat de disaster recovery in zo’n geval ingeregeld moet worden vanaf de operating system- en applicatie-lagen. Mogelijkheden zijn bijvoorbeeld het inrichten van replicatie op dataniveau en het clusteren van applicaties over meerdere cloud-providers. Dit vereist complexere ontwerpen voor data-synchronisatie en applicatie-clustering.

Wat me bevreemd is dat de meeste gebruikers van (public en private) cloud IaaS diensten ten onrechte denken dat de provider zorg draagt voor dr-diensten terwijl toch duidelijk uit het sla blijkt dat dit niet het geval is. De inrichting van dr is klant-specifiek en vereist een gedegen kennis van de infrastructuur van de klant. Providers die hierin excelleren hebben bij de inrichting van hun infrastructuur de juiste keuzes gemaakt en daarmee het fundament gelegd voor een goede recovery.

Mijn advies: leer van de situaties zoals die zich recent hebben voorgedaan en test of jouw huidige dr-plan voldoet aan de eisen van vandaag. Het is daarbij prima om te vertrouwen op de dr van je provider, maar test dan tenminste wel minimaal elke zes maanden. Besteed dan speciaal aandacht aan recente wijzigingen, gemaakt aan de applicaties en infrastructuur. Een veel gemaakte fout is dat wijzigingen aan de infrastructuur niet doorwerken in de dr-oplossing, met catastrofale gevolgen bij een werkelijke uitwijk.

Zelf volledig in control zijn? Richt dan een dr-oplossing in die binnen je controledomein ligt. De continuïteit van de onderneming ligt op de weegschaal. Handel snel maar vooral zorgvuldig.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5003076). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Bart,
Hiermee mijn 1000e reactie op Computable.nl :-)

Leuk artikel en misschien een "eye opener" voor sommige klanten!

Als je 6 dagen zonder je infrastructuur zit omdat je IaaS provider een probleem heeft dan moet je ff nadenken wat je met je ict gedaan hebt!
Wees blij dat je een telefoonnummer van je provider hebt. Als je je omgeving bij grote jongens neerzet dan krijg je eens geen telefoonnummer. Is de omgeving in de lucht dan krijg je als compensatie een deel van je huur (van 1 maand) terug! En hoe zit het met het verlies dat je business geleden heeft?

In je artikel geef je terecht aan dat de public cloud geen/niet voldoende ondersteuning biedt voor recovery zaken. Afhankelijk van wie je provider is heb je wel of geen recovery maatregelen in je dienstpakket.

Je voorstel/oplossing is gebaseerd op cloud escrow. Zeer terecht! Maar als je de kosten van cloud escrow in je business case meeneemt dan zou je zien dat je er helemaal niet voordelig uit bent.

Uitwijk in het geval van cloud behoeft een goede architectuur. Dwz dat je in ontwerpfase heel goed over cloud escrow moet nadenken. Het gaat niet alleen om de zaken aan de kant van je escrow-leverancier maar nog meer.

Ik probeer mijn reactie kort te houden. Je zal zeker voldoende reacties van andere mensen op dit artikel krijgen.

Tip: een mooie discussie over dit onderwerp (escrow):

Klant kan gevaar zijn voor je cloudleverancier

http://www.computable.nl/artikel/opinie/cloud_computing/4573553/2333364/klant-kan-gevaar-zijn-voor-cloudleverancier.html

Bart,

"Als dat het moment is waarop jij je realiseert dat je een plan had moeten hebben voor dit soort scenario’s, ben je te laat."

Dat is een correcte opmerking, evenals dat je het moet testen maar grappige is dat deze uitwijktesten soms op een zodanige manier gedaan worden dat het niet representatief is voor een crisissituatie. En op het 'moment suprême' blijken vaak de sleutelpersonen niet bereikbaar, zijn er dingen niet goed overgegaan en nog een paar van die details die steeds vergeten worden.

Nu zie ik dat je vooral technische oplossingen opsomt vanuit de opslag die veel mogelijkheden bieden met ieder zijn eigenaardigheden en prijs. Maar juist hier gaat het vaak mis want het mag meestal niets kosten, classificatie van data en services ontbreekt meestal. Je haalt terecht aan dat IaaS provider niet zonder meer de DR inricht maar desondanks wordt dit wel verwacht, de cloud is toch het ultieme ontzorgen?

Dat is tenminste wat ons wijs gemaakt wordt door de 'tought leaders' van sommige bedrijven en dus spreekt je afsluiting me aan, beheersbare kosten betekenen nog niet altijd een beheerbare bedrijfsvoering. Zeker niet als organisatie A de gehele ICT uitbesteed aan organisatie B die het werk verdeeld onder organisaties C en D welke vervolgens alles weer gaan hosten bij organisatie E.

Jij lijkt geïnspireerd door een recent voorbeeld met provider, ik door wat andere incidenten want BCM bestaat uit iets meer dan enkel Disaster Recovery op de technologie laag en mijn tip is dus het voorkomen van eilanden met daarop ieder zijn een eigen stam(hoofd).

@Reza
Je punt is genoteerd, heb binnenkort gesprekken hierover want volgens mij vergeet je nog wat. Kijkend naar hierboven gegeven lijntje van organisaties is de cloud namelijk een abstractie waarin nog een paar andere 'schaduwen' zitten. Vraag in deze is wat belangrijker is, de data of de applicatie?

Bart,

Leuk en zeer valide en actueel stuk. Waar voor dank.

@ Ewout,

Tja het is een beetje kip en het ei discussie. Zonder data is de applicatie nutteloos en vice versa ook.

Bart haalt goede oplossingen aan. Maar buiten de technologie speelt hier natuurlijk ook een discussie op politiek gebied. De organisatie moet het wel inzien en er voor willen betalen. En deze discussie duurt meestal langer dan de technologie keuze. En vaak wordt deze discussie pas gevoerd als men een keer uit de lucht is geweest. Dan komt het pas op de agenda te staan. Voorkomen is in dit geval beter dan genezen.

Reza,

Gefeliciteerd! 1000 reacties is een mooie mijlpaal.

Even doen waar ik goed in ben: de domme eindgebruiker spelen:

Iedereen roept dat ik alles in de cloud moet draaien, want dat is zo handig, goedkoop, alles wordt voor me geregeld en ga zo maar door. Lofzangen over de cloud en alles wat eindigt op AAS te over op deze site.
Dus als domme eindgebruiker geloof ik dit, en wil me laten ontzorgen en kies een cloud-leverancier voor al mijn diensten.

En dan lees ik nu dat ik me als eindgebruiker ineens druk moet gaan maken over disaster recovery, replicatie lagen en weet ik veel wat voor moeilijke technieken.

Als klant zou ik me dan alles behalve geholpen voelen met de cloud-oplossingen.

Misschien toch maar weer mijn eigen omgeving inrichten?

@reza

ik sluit me aan bij Ruud, een mooie mijlpaal bereikt, met vooral veel zinnige reacties

@Pa Va Ke, ik snap dat je je zorgen gaat maken bij al deze horrorverhalen, maar bovenstaande artikel gaat over je eigen bedrijfsapplicaties in een cloud-omgeving draaien, in plaats van bedrijfsapplicaties als dienst afnemen, wat Software as a Service wordt genoemd. De meeste bedrijfsmatige SaaS oplossingen hebben real-time replicatie in meerdere datacenters, dus daar speelt dit probleem niet, er valt zelf namelijk weinig te recoveren, mocht de dienst niet beschikbaar zijn.

@Ruud

*zucht*
Ga nou eens die cursus ITIL doen, want volgens mij staat in de SLA niet hoe je iets bereikt maar wat je bereikt, liefst tegen laagst mogelijke kosten want vaak is IT gewoon een costcenter. Mag ik het even 'plat' slaan naar RPO/RTO per dienst?

En betreffende politiek kan ik simpel zijn, if you pay peanuts you get monkeys.

Pa Va Ke speelt de domme eindgebruiker, als ik me niet vergis hoeft hij daar niet zoveel moeite voor te doen want wat hij naar voren brengt is ongeveer het niveau van de gemiddelde IT regiseur waarover tegenwoordig zoveel gesproken wordt. En deze 'digitale nitwits' hebben echt geen idee van wat er allemaal aan de onderkant van de architectuur gebeurt, meesten maken niet eens een back-up want ze vertrouwen volledig op de beloften die gedaan worden door de provider.

Leuk dat Lennart ook mee doet in de discussie maar juist hier zie je de ruis ontstaan doordat gedacht wordt dat er SaaS afgenomen wordt terwijl het uiteindelijk om IaaS gaat. Zie mijn eerdere reactie aangaande het lijntje van organisaties want sommige SaaS providers hebben namelijk de techniek gewoon uitbesteed. Een reversed IP lookup laat al gauw zien waar de data precies landt, wie er ook op de server zitten en onder welke voorwaarden de 'back-end' geleverd wordt. Been there, seen that and done IT....

*bonkt met hoofd op tafel*
Als je er niks voor wilt betalen moet je er niets van verwachten, de cloud is namelijk niet goedkoper alleen maar sneller. Helaas geldt dit ook voor de replicatie van fouten want om een eerdere uitspraak nog maar eens te herhalen: 'History doesn't repeat itself, but it does rhyme' - Mark Twain.

@Ewout: het goede nieuws: het is vooral gespeeld :)

Maar de beloften van de provider zoals jij ze noemt is wel hetgeen de MKB-er, die een betaalbare oplossing zoekt voor zijn IT omgeving, doet besluiten voor een bepaalde oplossing te kiezen. Terecht of niet, hij gaat er dan van uit dat e.e.a. goed geregeld is. Met uitzondering van de groenteboer wellicht wil hij zich niet druk maken over wat voor SLA dan ook. Als IT professional ben je misschien met dit soort dingen bezig omdat dit tot je (kern-)competenties hoort, maar voor veel anderen in IT een hulpmiddel.

De gemiddelde IT regisseur die jij noemt is misschien wel een heel ander punt van zorg. Steeds meer diensten, ook IT diensten, worden ingekocht door commerciële afdelingen op basis van prijs en SLA's. Wat aan de onderkant zit weten ze inderdaad vaak niet. Zij betalen het liefst de peanuts, want dat begrijpen ze, en daar worden ze op afgerekend.


Ik ken ITIL (en heb er mee gewerkt), ik ken SLA's, maar mijn ervaringen met dit soort bouwwerken is vooral dat men dit gebruikt om zich achter te verschuilen. Als ik NU een probleem heb, maar de IT-regisseur een SLA bedongen heeft waarin 5 werkdagen staat om mijn probleem op te lossen, dan wordt ik niet vrolijk als ik daardoor 5 dagen moet wachten.
De service- en help-desk nachtmerries zijn bij menigeen bekend, en dit soort overhead wordt in stand gehouden door de bureaucratie.

Misschien ben ik hierin ouderwets, maar doe mij maar de systeembeheerder die je rechtstreeks kunt bellen, die snapt wat jou probleem is en je kan helpen of even langs kan komen. Dat werkt toch echt wel een stuk lekkerder dan de helpdesk in verweggistan, de 2e lijns helpdesk in weer een ander land en het excuus dat het niet kan omdat dit niet in de SLA staat.

Maar dat terzijde

@Pa Va Ke
Misschien ben jij geen kritische component in de keten, jouw probleem is niet urgent genoeg voor de business?

Ewout,

Ik heb het woord SLA voor zover ik kan terug lezen niet gebruikt. Dus ik snap je reactie niet helemaal. Maar misschien had je je leesbril niet op :-)

En het plat slaan naar een RPO/RTO per dienst ligt politiek altijd gevoelig. Als je deze discussie aan gaat met de klant is alles super belangrijk. Maar hier komt men snel op terug als men ziet welk prijskaartje er aan vast hangt. Dit is in mijn optiek 1 van de meest tijdrovende discussies die je maar kan hebben.

Classificeren van de applicatie en de daarbijhorende data is en blijft hier key. Niet alles hoeft namelijk even snel weer up and running te zijn. En vergeet hierbij niet de hele keten. Want er hoeft maar 1 zwakke schakel tussen te zitten en je bent de pineut.

@Ewout, dank voor je hartelijke welkom. Noem eens wat enterprise saas omgevingen die je gereversed lookup hebt? En noem eens een SaaS die langer dan zes dagenn uit de lucht is geweest? Waar de data heen gaan zegt natuurlijk niks over de beschik baarheid of disaster recovery van de diensten namelijk! Ik ben wel benieuwd waarover je het dan hebt, ook omdat je vindt dat ik altijd naar salesforce.com verwijs, maar ik noem iig het beestje bij naam! :-)

@Ewout

Laten we het er op houden dat de meningen over daarover zijn verdeeld. Zoals ik al ooit schreef "DE" bestaat niet, en dat geldt ook voor SLA's.

In een organisatie waarin je zowel productie, verkoop, kantoor, management, onderhoud, service en R&D hebt dan zijn er altijd afdelingen wier wensen niet binnen de SLA passen. In het geval waar ik op doel zijn de SLA's vooral afgestemd op de kantoor-omgeving; voor een R&D omgeving is dit soms niet toereikend. De bedrijfskritische applicaties (SAP etc) zijn goed afgedekt, maar daar heeft R&D weinig mee van doen.
Wat je daarnaast dus ziet ontstaan is dat fabriek en R&D hun eigen omgevingen op beginnen te zetten zodat ze minder gebonden zijn aan de beheersorganisatie. Eigenlijk iets wat je niet wil, maar "the show must go on"

@Ruud & PaVaKe
Dank heren. Zonder jullie was het zeker niet zo gezellig om 1000 keer (nu 1001 dus) op deze site een reactie achter te laten :-)

@Lennart
Ik denk dat je (in)direct doelt op grote SaaS spelers die misschien meer dc`s hebben. Maar als klant heb ik geen zin om altijd een dienst bij die grote leveranciers af te nemen. Dat komt o.a. doordat ik 1) hun SLA moet accepteren, 2) alleen via mail met hen mag communiceren, 3) geen maatwerk kan krijgen en nog meer.

Er zijn ook kleine spelers die me juist niet alleen deze punten geven maar ook kennis van mij sector hebben en applicaties aanbieden die goed bij mij business passen en ook nog verder op maat gemaakt kunnen worden. Denk aan SaaS-leveranciers van zorg-applicaties of onderwijs-applicaties.
Die jongens passen goed bij mijn business, cultuur, sector etc maar ze hebben de benodigde vermogen niet om hun diensten zoals die bij Google of AWS veilig te stellen.
In dit geval moet ik rekening houden met enorme kosten van een uitwijk, lees SaaS-escrow

@Ewout:
Ik snap je vraag niet! Wat heb ik aan mijn applicaties als data niet beschikbaar is en ook omgekeerd? Beschikbaarheid van een "dienst" kent op verschillende niveau`s verwevenheden en afhankelijkheden die je bij uitwijk moet realiseren. Dus of/of is geen optie, het moet en/en zijn.

@ Reza, Gefeliciteerd. Well Done.

Ik hik hier wat het artikel betreft een beetje op twee gedachten. Maar dat is meer de non-commercialist in mij. Als je niet de IT keten en de 'eventualiteitn' op je netvlies hebt, iets wat steeds meer en vaker gemeengoed blijkt te worden, dan moet je jezelf eens heel goed in de spiegel aankijken.

Disaster Recovery moet en mag niets meer zijn dan eenvoudigweg even doordenken, als gewoon standaard onderdeel van de gehele IT keten, welke maatregelen en scenario's je kunt opstellen, gevallen zoals dit voorbeeld het hoofd te kunnen bieden.

Meer dan 24 uur....?
Ik denk dat de betreffende cloudleverancier dan al ten onder zal gaan aan schadeclaims. Tenminste, een beetje klant zal dat jruidisch goed dicht en aftimmeren me dunkt.

Redundancy
Die geld niet alleen zo zeer hardware matig maar juist procesmatig en procedureel voor elke onderneming. Toegegeven, vaak denkt men er niet zo over na maar komt men het tegen als het hen overkomt. Dan rijst meteen de vraag,'Wat zijn de kosten van Disaster Recovery'.... vs het verlies dat je loopt op het moment dat je vrijwel geheel afhankelijk opstelt van een cloud leverancier?'

Iets om weer eens terdege over na te denken gevolge dit artikel.

Dank Bart....

@Reza; ik kan kan je wel helpen denk ik, bij welke saas leverancier mag je alleen met mail communiceren en kan er geen maatwerk?

Nouja, mijn reactie kan hier ook nog wel bij :-) En Reza gefeliciteerd met je 1000+ reacties, en niet één zonder liefde!

- DR is een veelkoppig monster, een fuckupje in de DNS kan op afstand het zelfde aanvoelen als een vliegtuig op je datacenter.

- Uitwijken is één, terugkeren is een onderdeel wat zelden besproken wordt terwijl daar toch een 1 op 1 relatie is met het uitwijken!

- Een voorbeeldje SaaS bij Google. Stel het hele bedrijf gebruikt Google Apps. Google heeft een mega fuck-up, wat doe je dan? Zonder DR plan ben je het haasje. Door een externe dienst af te nemen (check de SLA en voorwaarden) kun je een 1 op 1 backup maken van al je data, bijvoorbeeld backupify. Daarmee heb je het verhaal meteen goed afgedekt. DNS van je mail omzetten naar bijv. O365, import wizards voor mail boxen, download en upload naar SkyDrive (rechten? Oops) en je hebt in ieder geval een plan. Is het perfect? Nee.

Wat betreft IAAS is het een stuk lastiger, maar geen DR plan is niet acceptabel. Als het misgaat kun je dat niet verdedigen. Dat een goed DR duur is mag duidelijk zijn, de meeste bedrijven zullen toch voor een tussenvorm kiezen waar haken en ogen aan zitten, maar die de kosten behapbaar houden.

Reza je drie punten in laatste reactie ben ik het oneens.
1) SLA is voor schildpadden (dank PaVaKe) dat geldt vaak ook voor kleine providers
2)Volstrekte onzin, pertinent, gewoon niet waar en is uit de lucht gegrepen.
3) Geen maatwerk klopt ook niet. definieer maatwerk.

@Henri; verbaast mij ook, er worden hier aannames als waarheid gedeponeerd die ongefundeerd zijn, maar ik zie dat Reza in de onderwijs en zorg actief is, daar is vaak On-Premise een groot goed, qua zorg kan ik me dat nog wel voorstellen qua data. Je kan trouwens inderdaad bij SaaS diensten zelf op elk moment je dataset exporteren, gescheduled en wel, ook hebben SaaS leveranciers alleen toegang tot meta data. Er hier gaat dit jaar nog heel veel ten goede veranderen!!

En @Reza; qua SLA, 99,xxx% zegt nog helemaal niks over de kwaliteit van de dienstverlening, daarom zie je ook andere metrics ontstaan zoals responsetijd, querysnelheid en aantallen transacties, SLA's sterven ook uit in de SaaS / Cloud wereld, want de systemen zijn altijd up, maar dat zegt dus niks...

Dat is toch wel heel naief om te denken dat bij IaaS een provider voor recovery gaat zorgen. IaaS is niet anders dan je eigen datacenter maar dan op een andere plek en andere manier afgenomen. Aan de afnemer om iets met die IaaS te doen.

Goed stuk en fijne discussies! Toevallig gaat mijn volgende opinie (waarschijnlijk ma of di online) over beschikbaarheid en schijnveiligheid.

Dank @NumoQuest & @Henri.

@Henri:

A) Ik zie weer enorme verschil tussen hoe jij naar een ict-verschijnsel zoals BC/DR kijkt en hoe ik (of Ewout) het doe.
Heb je weleens met BC/DR van organisaties zoals ING te maken gehad? Zo ja dan ga je niet denken dat je met back-up / restore van data een BC/DR plan hebt of eens in dichtbij in de buurt komt.

B) je hebt verschillende scenario`s bij uitwijk zoals uitwijk van 1 dienst ( bijvoorbeeld mail of telefonie etc), uitwijk van een deel van je diensten en uitwijk van totale diensten/platform. Bij 1e en 2e vorm heb je te maken met verwevenheid van verschillende componenten, applicaties en diensten. Leuk dat je een mailbox export/import doet maar je hebt de betreffende dienst nog niet helemaal goed in elkaar gezet.
Bovendien je kunt sommige delen van een dienst bij andere dienst niet aanbieden. Denk aan PublicFolder van O365 die je in Google maildienst wilt inpassen! Heb je dat weleens geprobeerd?
Over PublicFolder O365 gesproken, heb je weleens geprobeerd de data van interne Exchange naar O365 te kopiëren? Zo ja, is het je iets opgevallen?
Je mag alles wat ik zeg onzin vinden maar ik baseer mijn reactie op zaken die ik meegemaakt heb.

B)Een klant maakte gebruik van een SaaS oplossing. Ze wilden een andere SaaS oplossing aanschaffen die met deze op verschillende niveaus moest kunnen communiceren. Sommige interface-delen van de nieuwe applicatie dienen voor sommige AD gebruikers onzichtbaar of grijs te zijn. Sommige functionaliteiten moesten of onzichtbaar worden of Only View of All-in rechten krijgen gebaseerd op 1) je AD groep 2) je locatie [ vesteging A, vesteging B, of thuis]
Gebaseerd op deze indicators en nog wat andere zaken (geen lange verhaal maken) moest er kunnen bepaald worden of een gebruiker bijvoorbeeld iets mag printen of exporteren of niet (op vestiging A en B mag en thuis niet)

Kortom een maatwerk voor een financiële instelling. na het opstellen van PvE zijn we snel erachter gekomen dat de betreffende SaaS oplossing niet de benodigde flexibiliteit kon aanbieden en de leverancier was ook niet in staat om daar maatwerk van te maken.

Heb ik nu antwoord op je 3e punt?

@Lennart
A) Als jij veel aannames hier ziet, kom jij maar dan met namen, feiten, referenties etc. Je vertel ook hier eea zonder duidelijke referenties.
Over aannames gesproken, wie zegt dat ik in onderwijs en zorg actief ben?

B) Als jij ook het exporteren van een database bij een Saas-leverancier als oplossing ziet voor DR/BC, dan adviseer ik je om een uitwijktest gebaseerd op deze oplossing uit te voeren.
Bovendien, een Saas-leverancier bepaalt zelf van welke soort database (bijvoorbeeld een exotische opensource) en ook indeling binnen de database gebruik gaat worden gemaakt. Dit betekent niet dat de geëxporteerde data altijd 1 op 1 bij een andere leverancier bruikbaar is.

C) Zoals je weet (!) een SLA beschrijft niet alleen de up-time maar ook nog veel andere zaken zoals reactietijden, oplostijden, escalatiezaken, kwaliteiten (snelheid, bruikbaarheid, etc)en nog andere componenten die de basis vormen voor de afspraken rondom de dienstverlening.

" SLA`s sterven ook uit in de SaaS / Cloud wereld, want de systemen zijn altijd up"

Ai, ai, ai, je schiet hiermee in je eigen voet. Zeer merkwaardig dat je in je uitspraak een SLA alleen aan de uptime koppelt.

Ben benieuwd hoe je me gaat helpen (je reactie van 10:38). Ja graag!

Het artikel is een schot in de roos. De problemen met IAAS zijn veel ICTers nog niet duidelijk laat staan de "managers" die de kontrakten tekenen.

Voorbeelden als Google Apps vindt ik niet zo passen bij het beschreven probleem, office-gebruik heeft een behoorlijke backup nodig en dat moet ook nog zonder internet kunnen werken (voor mij dus geen google . . ).
Reza heeft gelijk dat ING een andere dimensie is.

Het geschetst probleem met 6 dagen down is wel erg extreem, het toont hoe onrijp "cloud" is, technisch kan veel, maar rijpheid betekent ook een behoorlijke DR en juridisch behoorlijke kontrakten.

Kijkend naar het MKB zie ik nog veel problemen voor cloud-gebaseerd werken (IAAS). Waarschuwingen als dit artikel zijn nodig, met dank aan Lennart.

En Reza, 1000+, een echte Milestone, proficiat!

@Reza : kan je mij de partijen toesturen waar je alleen per mail mee kan communiceren, en welk maatwerk hebben we het dan over?

Reza,

Jij wilt ook geen lange verhalen schrijven waarmee je alle punten volledig afdekt, ik doe dat (deze keer) ook niet.

Ik zet nadrukkelijk bij dat het voorbeeld SaaS is, en ik ben niet in staat om voor een ING een DR strategie te ontwikkelen, aangezien we het niet over scope en grootte gehad hebben zou mijn reactie daar niet op afgerekend moeten worden.

Ook vermeld ik dat mijn voorbeeld niet perfect is noch compleet. Ieder bedrijf moet een risico analyse doen. Hoe groot is de kans dat een grote provider down gaat? En wat betekent dat dan? In mijn voorbeeld over Google ga ik er vanuit dat de kans dat er echt een disaster optreedt erg klein is, maar *als* het gebeurd is er in ieder geval een mogelijkheid om door te kunnen gaan. Die is niet compleet, die zal een hoop gepiel met zich meebrengen, maar je data heb je. Niemand heeft gezegd dat je disaster recovery super de luxe en compleet hoeft te zijn.

Dat er bedrijven zijn die in onwetendheid diensten af nemen en laks zijn in het maken van een risico analyse en een plan, tja "la gente esta muy loca"

Je reactie B heeft precies aan waar het manco zit. Je noemt een voorbeeld van een SaaS die geen maatwerk had en daarmee trek je die conclusie door naar alle SaaS. Overigens betekent het inderdaad wel dat als je gaat migreren je wellicht een organisatie verandering nodig hebt. Maar ik kan een hele berg maatwerk voorbeelden noemen. Net als mensen die ik kan bellen 24/7.

Het zwaartepunt van disaster recovery is dat je risico analyses doet en in ieder geval benul hebt hoe je in bepaalde scenario's zou kunnen handelen. Perfect DR plannen bestaan niet en als ze zouden bestaan zijn ze onbetaalbaar.

En dat terugkerende SLA discussie. Natuurlijk wil je afspraken maken, maar een SLA voorkomt geen problemen en lost ze ook niet op. Het is iets wat er nu eenmaal bij hoort, maar het is verder niet zo heel interessant en vaak schijnveiligheid. Beschikbaarheid heeft zoveel gezichten, daar kun je boeken over schrijven.... Maar ook responsetijd is vaak een wassen neus. Je wilt gewoon een capabele leverancier met een goede mentaliteit en trackrecord aangevuld met "bewijs" (certificering en audit). De rest is koffie dik kijken.

Deze partijen bedoel ik, @Reza:

Ik denk dat je (in)direct doelt op grote SaaS spelers die misschien meer dc`s hebben. Maar als klant heb ik geen zin om altijd een dienst bij die grote leveranciers af te nemen. Dat komt o.a. doordat ik 1) hun SLA moet accepteren, 2) alleen via mail met hen mag communiceren, 3) geen maatwerk kan krijgen en nog meer.


Ik weet niet wat jij met maatwerk bedoelt, maar bij de SaaS oplossingen die ik ken kan je in hoge mate je eigen wensen uitbouwen (NetSuite, salesforce.com, Microsoft CRM Online, Workday); kortom, waar hebben we t over? Jouw drie punten zie ik daar niet.

Read more: http://www.computable.nl/artikel/opinie/cloud_computing/5003076/2333364/disaster-recovery-bij-een-public-cloud-iaas.html#ixzz2u3PMt2Na

Deze partijen bedoel ik, @Reza:

Ik denk dat je (in)direct doelt op grote SaaS spelers die misschien meer dc`s hebben. Maar als klant heb ik geen zin om altijd een dienst bij die grote leveranciers af te nemen. Dat komt o.a. doordat ik 1) hun SLA moet accepteren, 2) alleen via mail met hen mag communiceren, 3) geen maatwerk kan krijgen en nog meer.


Ik weet niet wat jij met maatwerk bedoelt, maar bij de SaaS oplossingen die ik ken kan je in hoge mate je eigen wensen uitbouwen (NetSuite, salesforce.com, Microsoft CRM Online, Workday); kortom, waar hebben we t over? Jouw drie punten zie ik daar niet.

Read more: http://www.computable.nl/artikel/opinie/cloud_computing/5003076/2333364/disaster-recovery-bij-een-public-cloud-iaas.html#ixzz2u3PMt2Na

De cloud timmermannen (Lennart & Henri) zouden er goed aan doen om bij de les te blijven, het gaat om IaaS en dus wordt er ruis ingebracht door de verwachtingen van SaaS te noemen:

"Cloud providers may find that making high-reaching promises around service delivery is the easy part; following up when things go bad is where it gets tricky."

Betreffende SLA's zijn inderdaad vele dingen mogelijk alleen dus niet bij de grote jongens waar het voor 99,999% toch 'take IT or leave IT' is als ik leveringsvoorwaarden doorneem waarin opvallend vaak clausules aangaande overmacht zijn opgenomen. Cloud timmermannen zouden er goed aan doen om nog eens de lessen van Katrina te lezen:

"Everybody knows things break - it's the nature of life. It's how you respond to things breaking that sets you apart as a cloud service provider" - Chris Drumgoole, vice president of global operations Terremark

Dat sommige bedrijven afspraken maken die 'Crap' zijn wil nog niet zeggen dat dat SLA's uitsterven, het lijkt me nogal ongefundeerd als ik kijk naar de initiatieven hierin om tot een 'template' te komen voor cloud computing.

@Ruud
Als je het over 'hot-pluggable RAID-units' hebt met unieke 'sellingpoints' dan heeft het verder geen uitleg nodig wat bedoeld wordt. Als je stelt dat organisatie het moet inzien en er voor willen betalen dan heb je het naar mijn mening toch over een soort van overeenkomst;-)

@Pa Va Ke
Je hebt het over rigide (ridicule) contracten versus de wens van flexibilteit wat grote overeenkomsten heeft met je verhaal over de keus van legacy en welke zich niet alleen beperkt tot technologie. Vergeet niet dat vooral de hierarchische organisaties vanuit de 'verkeerstoren' visie werken met SLA's. En inderdaad worden deze dus niet altijd opgesteld door de piloten die door de cloud moeten vliegen maar door verkeersleiders die alleen een blik werpen op de landingsbaan.

@Reza
Je denkt te moeilijk, neem bijvoorbeeld hele hype rond big data waar het niet om de applicaties maar de analyses gaat. Stellen dat applicatie en data onlosmakkelijk met elkaar verbonden zijn geldt zeker niet voor alle ongestructureerde data.

Dankjewel, Ewout, a.k.a. mister edge case, er werd over *AAS veel geroepen wat onjuist is (alleen per mail communiceren en geen maatwerk), daar reageerde ik op. Dit gaat inderdaad over IaaS.

Hi, een korte reactie op het artikel van Bart:

Als ik het goed heb doel jij in dit artikel op bedrijven die 3rd party cloud providers (IaaS) gebruiken als origin infrastructure en je wilt de mogelijkheden en beperkingen in kaart brengen m.b.t. Disaster Recovery (DR).

Los van het artikel en voor de goede orde:
a) Data Backup is geen DR
b) Data Backup zonder DR brengt traditioneel een RTO met zich mee van dagen/weken afhankelijk van hoeveelheid data, complixiteit en vooral beschikbaarheid en kunde van human resources.
c) DR geldt als een verzekering en wordt vaak enkel ingezet bij mission critical hosting

Mission critical applications worden in de meeste gevallen niet op public IaaS gedraaid, daar public IaaS gestandardiseerd is(incl. commodity servers (x86 wintel/linux) en bedoelt zijn voor de massa. Daarnaast hebben bedrijven met mission critical applicaties te maken met regulaties. Dus als DR bedoelt is voor mission critical apps en mission critical apps zelden op public IaaS draait is DR 9 vd 10 keer niet benodigd met public IaaS als origin. Een data backup is vaak afdoende, vooral als je beseft dat de primaire karakteristiek van cloud (IaaS) "on-demand" provisioning is en een infrastructuur dus in minuten kan worden opgezet; uiteraard afhankelijk van hoeveelheid data.

Voorbeeld bij Cloud IaaS provider Softlayer: Origin draait bij Softlayer Amsterdam, Quantastor (private dedicated backup server) staat in een van de andere 24 datacenters wereldwijd naar keuze en er wordt een automatische backup gemaakt van de origin. Daar er interconnectie is tussen alle datacenters betreft het interne traffic en is traffic daardoor kosteloos. In geval van een disaster in Amsterdam, wordt de data van de quantastor in de andere datacenter retrieved om binnen een paar minuten/uren een nieuwe infrastructuur te provisionen (ook hier in een datacenter naar keuze). Zodra datacenter in Amsterdam weer is hersteld zal er een migratie plaatsvinden naar Amsterdam.

In geval van "echte" DR m.b.t. zelf gecontroleerde origins dan geldt de volgende hamvraag:

"Hoeveel kost het als ik een dergelijke DR solution gebruik? En hoeveel kost het als ik deze DR solution niet gebruik en mijn origin ligt plat?" Calculeren...RTO/RPO bepalen...Solution kiezen. De kortste RTO/RPO komen momenteel voort uit cloud based DR solutions zoals SmartCloud VSR (Virtual Server Recovery) van IBM. Vanwege continue replicatie van computing servers, storage servers, Databases waarin elke minuscule wijziging in real-time wordt gerepliceerd naar een private dedicated omgeving in een Tier 3+ datacenter van IBM brengt het een RTO met zich mee van seconden. Vanwege 94 snapshots per dag brengt het een RPO met zich mee van 15 minuten. Alles kan worden gemonitord en gemanaged vanaf een enkele webportal waar o.a. een onbeperkt aantal testen kunnen worden geinitieerd wanneer je maar wilt.

Staat deze oplossing in de kinderschoenen? Nee totaal niet. Deze oplossing wordt door duizenden klanten wereldwijd gebruikt. Sterker nog, er bestaat alweer een nieuwere solution binnen het portfolio van IBM BCRS waarin we het geen DR meer kunnen noemen omdat er geen recovery aan te pas komt (negatieve RTO laten we maar zeggen) en is gebaseerd op predictive analytics (big data) o.b.v. parameters die IBM BCRS de afgelopen 25 jaar heeft verworven (BCRS bestaat sinds 1989) in combinatie met de parameters van de klant. Valt veel over te vertellen maar dan wordt het allemaal veel te lang ;-)

Excuus als het commercieel overkomt, dit is niet de bedoeling. Ik werk voor IBM en ken de details van IBM en niet zozeer van andere providers.

PS Bart: ik vind onderstaande quote wel erg vreemd:

"Een veel gemaakte fout is dat wijzigingen aan de infrastructuur niet doorwerken in de dr-oplossing, met catastrofale gevolgen bij een werkelijke uitwijk."

Als een DR oplossing niet alle wijzigingen doorwerkt, dan is het naar mijn mening simpelweg geen DR oplossing. Dat is namelijk wat een DR oplossing doet in de kern...repliceren.




@Lennart,
Je denkt toch niet dat ik hier (public website) iets ga roepen over de tekortkomingen van onze business partners en hun producten/diensten? We gaan zeker in een traject onze kennis, ervaring en advies met onze klanten delen maar sommige van onze business partners hier afkraken lijkt me niet handig!

Voor de rest kun je ook zelf aan de hand van mijn case hierboven nagaan tot hoeverre de door jou benoemde leveranciers aan die behoefte kunnen voldoen.

@Henri,
Je reactie vind ik een mooie aanvulling. Op een punt na, ik heb geen conclusie door getrokken naar "alle" SaaS leverancier.
Verder het realiseren van een BC/DR op papier is zeker heel anders dan dat ook in praktijk brengen. Pas bij BC/DR test komen lijken uit de kast. Dit is juist het doel van BC/DR test om onzichtbare zaken inzichtelijk te krijgen.


Maar............... we zijn circa 31 reacties verder en ik zie nog steeds geen reactie, bemoeienis, begeleiding etc van de auteurzelf die Cloud Architect is en in 10x "ik" op zijn profiel heeft mooi uitgelegd wat hij allemaal kan!

@Reza; flauw, dan zijn het holle kreten als je geen vendors kan noemen, of het zijn niche spelers blijkbaar, jammer dat er slechts abstracte ervaringen door je worden benoemd...daar was ik al bang voor, dat t nooit echt concreet wordt. Ik vind ook weleens een website niet zo goed, maar dat maakt niet het hele internet waardeloos!

Lennart,
Als ik tegen mijn jongste kind zeg dat ze niet krijgt wat ze vraagt (om een bepaalde reden) dan probeert ze mij met alle middelen te manipuleren om haar zin te krijgen. Herkenbaar dit gedrag?

Lees aub nog een keer mijn reactie. Dan zou je moeten weten dat ik gebonden ben aan bepaalde bedrijfspolicies en afspraken.

Lennart,
Mooi gevonden dat 'Edge case' en heel toepasselijk bij het onderwerp, vaak is een spiegel contractueel wel afgesproken maar blijkt deze in de praktijk gebroken. Zo bleek eens bij organisatie (we noemen geen namen) de service wel keurig automatisch overgegaan naar de uitwijk maar was dit niet geconstateerd. En omdat daardoor de conditie die hiervoor zorgde ook niet opgelost werd bleek er effectief dus geen uitwijk meer te zijn, al weken niet meer.

Dat deze zaken minder breed in het nieuws komen is meestal het gevolg van mister 'Corner case' waardoor het niet makkelijk is om van vendor te wisselen. Kijkend naar de cloud zie ik telkens wel definitie wijzigingen maar nog niet echt de verbeteringen in techniek die zorgen dat alle beloften ook ingelost kunnen worden. Ik kan het mis hebben maar gaat het er in de wetenschap niet om de verhouding van theorie en werkelijkheid te toetsen?

Ligt het aan mij of wordt af en toe vergeten dat "cloud" ook een berg hardware betekent?

Hardware die kapot kan gaan en ondanks clusters, virtualisatie, replicatie, mirrorring etc. etc. toch net dat ene komponentje die wolk als een ballon laat klappen.

Uit mijn ervaringen en die van kollega's weet ik dat niemand kon verwachten dat de bliksem-inslag de kabelboom in de kabelschacht tot een perfect brandende schoorsteen maakte, en ach, zonder kabels weinig ICT!

Het begrip "restrisiko" is ook bij cloud-oplossingen van toepassing.
Je kunt je juridisch nog zo goed indekken, wanneer kalamiteiten gebeuren helpt dat niets.
Een uitwijk voor een uitwijk vind ik wat overdreven, een termijn voor herstel is de betere optie zodat de oorspronkelijke uitwijk weer zijn funktie krijgt.

Bij een groeiende komplexiteit in het algemeen, zullen dit soort systemen, cloud of niet, af en toe plat gaan, dat was zo, is zo en zal wel zo blijven om het even of IAAS, SAAS of wat dan ook.

Geachte collega Experts van Computable,

Sinds het publiceren van het artikel op vrijdagavond, en nu zondag avond, is er een heuse discussie ontstaan die veel verder reikt dan de scope van het initiële artikel.

Zoals jullie terecht concludeerden en de titel deed vermoeden: mijn stuk was ge-ent op mijn ervaringen met het IaaS portfolio van cloud providers. SaaS is een geheel ander spel waarbij hele andere dimensies een rol spelen. Ik vind het vervelend te moeten melden, maar mijn ervaring is dat de meeste SaaS diensten (behoudens die van hele grote corporaties) helemaal niet ingesteld zijn op het mitigeren van een calamiteit, laat staan dat ze beschikken over meerdere datacenters waar active/active dienstverlening vanuit geboden wordt. De meeste SaaS providers die ik begeleid gebruiken op hun beurt gewoon weer IaaS (of PaaS) providers om hun diensten bij onder te brengen. Hierbij moet ik wel vermelden dat ik voornamelijk in Nederland actief ben dus hoofdzakelijk over Nederlandse SaaS providers spreek. SaaS leveranciers staan onder enorme druk om op prijs/functionaliteit te concurreren en een goed DR-plan past simpelweg niet in dat plaatje.

Als klant van SaaS doe je er dus goed aan om zelf op regelmatige basis een backup te vervaardigen van de data die je bij de SaaS provider hebt ondergebracht. Denk er daarbij wel om dat je dit doet in een format wat zo veel mogelijk applicatie onafhankelijk is. Bij een calamiteit bij de SaaS provider is de applicatie natuurlijk niet meer beschikbaar wat het teruglezen van de backup lastig maakt.

Om verder in te zoomen op het probleem wat veel IaaS klanten onbewust lopen; dit is een probleem wat voornamelijk ingegeven wordt door het gebrek aan vaardigheden om een juist en volledig SLA te onderhandelen en om de maatregelen die de IaaS provider heeft genomen te beoordelen. Helaas is het zo dat een afgegeven garantie voor beschikbaarheid (negenennegentig komma veel) gebaseerd op operaties onder normale omstandigheden. Du moment dat er zich een calamiteit van enige omvang voordoet kan de IaaS provider zich conform overeenkomst (niet SLA!) beroepen op het Force Majeur artikel. De afgegeven beschikbaarheidsgarantie komt in dat geval te vervallen, de verzekeraar van de IaaS leverancier gaat hopelijk tot uitkeren over en de klant heeft recht op een vergoeding van de (directe) schade tot maximaal het bedrag van de maandfactuur. Uiteindelijk zal de dienstverlening hersteld worden, maar niet voordat er serieuze schade is geleden.

Als afnemer van IaaS dien je er dus van bewust te zijn dat een SLA met een Force Majeur clausule geen dekking biedt in het geval van een calamiteit. Er zijn diverse mogelijkheden om daar mee om te gaan, maar de strekking van mijn artikel was juist: regel het op zo’n manier in dat je als afnemer van de IaaS dienst zelfstandig(!) de DR oplossing kunt initiëren. Dit kan door middel van een bij de IaaS provider afgenomen DR-dienst of een zelfstandig ingerichte DR-oplossing bij een andere provider.

Ik hoop hiermee wat aanvullende informatie verschaft te hebben over de achtergrond van het artikel.

Met vriendelijke groeten,
Bart M. Veldhuis

@Reza; ja dat hebben we allemaal, maar je spreekt over een grote SaaS leverancier die je niet kan bellen en geen maatwerk toestaat en waar je de naam niet van kan noemen, dat kan nooit een serieuze SaaS club zijn IMHO, want dan zou ik em kennen, en alle serieuze SaaS leveranciers hebben grote support-afdelingen, die je gerust mag bellen...

Maar ik laat het erbij, het voegt aan dit artikel niks toe,

Bart,
Het heeft even geduurd maar leuk dat je op je artikel terug bent gekomen.
Ik denk dat deze reactie een wake up call moet zijn voor mensen die door cloud betoverd zijn. "Denk in oplossingen, denk in mogelijkheden denk in...." zijn leuke praatjes die niet altijd realistisch zijn.

Korte reactie op je toelichting, zoals in de reacties boven besproken is, het maken van een back-up lost je probleem niet op als je moet uitwijken. Een uitwijkscenario behoeft nog meer dan alleen een restore van data.
Voor de rest zie ik je reactie in lijn met reacties hierboven van reageerders die nuchter met beide benen op de grond staan.



@Bart
Dank voor je aanvulling en misschien dat reacties verder reiken dan je intentie was maar volgens mij zitten er toch interessante lijntjes in het zand bij.

Je zegt dat wijzigingen in infrastructuur impact hebben op DR plannen, correct opgemerkt maar hoe zit het met configuration management?
Je zegt dat de afnemers van IaaS in hosted public cloud oplossing zelf hun DR moeten initieren maar hoe zit het dan met event management?

De twee bovenstaande maar niet limitatieve punten komen uit de ervaringen met data center migraties, in de prakijk vaak gewoon een DR test. En juist dan blijken iedere keer weer verrassingen naar boven te komen omdat er wat achterstallige administratie is. Betreffende event management is dat trwouens vaak een intern gericht proces waardoor dus uiteindelijk een incident de trigger is voor uitwijk.

Natuurlijk maken software defined oplossingen de replicatie en migratie eenvoudiger maar uiteindelijk gaat het gewoon om een proces, de techniek is maar een onderdeel hiervan. Oja, als je applicatie hiervoor niet geschikt is dan blijft het uiteindelijk gewoon meer geluk dan wijsheid. Dat sommige SaaS oplossingen gewoon een database met prefix zijn herken ik ook wel - het is maar net vanaf welke kant je naar oplossingen kijkt;-)

@Reza
Ik ben het niet met je eens, cloud computing biedt mogelijkheden om de DR kosteneffectief te verbeteren. Juist door in oplossingen te denken met een kennis van de techniek. Zo kun je heel goed uitwijken naar de cloud, niet alleen als herstel van je business maar ook om tijdelijke pieken op te vangen of een tijdelijk service te hosten.

Bart geeft een aantal mogelijkheden om middels de storagelaag de portabiliteit van je workload te vergroten, ik heb hier alleen nog wat vragen over de beheer(s)laag. En dat is geen 'Edge Case' maar 'Boundary Edge' want wat ik ontzettend mis is de opkomende ontwikkeling van Community cloud. Deze samenwerking adresseert naar mijn opinie namelijk een heleboel van de openstaande punten die Bart nu mogelijk bij één afnemer legt.

Lennart of Henri nog aanvullingen?

Hier hebben onze Oosterburen het perfecte woord voor uitgevonden.
Schadenfreude.

Als je als professional nog in dit soort vallen trapt dan mag je je serieus afvragen of je die titel nog langer verdiend.

Ewout,
Waar ben je het niet met mij eens? Ik heb het niet vastgelegd dat cloud computing als je DR oplossing per definitie duurder is. Dat hangt van je situatie en case af. Bijvoorbeeld twee gemeenten die samen gaan werken kunnen van elkaars locatie en middelen gebruik maken voor DR zaken. In dat geval zou cloud duurder zijn dan misschien wanneer je geen samenwerkingsverband hebt. Dit is iets wat er per geval bekeken moet worden.

P.s. leuk te zien dat je aan de kennis van andere mensen ook een plek geeft :-)

Ewout, ja, ik heb nog wat verder nagedacht over IaaS en DR en hier zijn mijn laatste twee centen over het onderwerp.

- Amazon Webservices en Windows Azure hebben standaard technieken ingebouwd voor fail-over naar een ander data center. Testen daarvan is nogal moeilijk al zijn er nu wat API calls mogelijk waarmee je een fail kunt simuleren. Pest met echte rampen is dat ik sterk twijfel of het echt goed zal functioneren en zoals gezegd, het is slechts op een aantal lagen (database,storage,dns), en als het massaal gebeurd door een ramp moet je nog maar zien dat het werkt zoals beloofd. Testen op grote schaal... de eerste moet nog plaatsvinden op het publieke domein.

- Het is evident dat SDI en Virtualisatie in combinatie met images en DNS het maken van een DR plan (voor Iaas wat eigenlijk altijd op basis van virtualisatie gaat) makkelijker maken.

- Een DR plan is altijd op een schaal van niets tot perfect (en denk aan classificatie) waarbij de kosten niet lineair oplopen, het is zoeken naar de balans van acceptabel en betaalbaar. Bij een ramp zullen mensen aan de bak moeten en zal er downtime bestaan en er zullen onverwachte zaken optreden.

- Een aantal scenario's bij rampen is oneindig. Het failliet gaan, gehackt worden of afgesloten worden van je provider is er in ieder geval één van, dus in het geval van IaaS mag je niet bouwen op één provider. Laat dit een startpunt zijn van ieder bedrijf dat Iaas, Paas of SaaS afneemt.

- Salesforce in de volle breedte inzetten (Saas en Paas) neemt een vervelend probleem met zich mee. Een goed DR plan is nagenoeg niet mogelijk, de vendor lock-in is bijna net zo sterk als bij het adopteren van SAP (kan een goede en gegronde beslissing zijn), omdat het platform adopteren functioneel maatwerk inhoudt wat je volgens mij niet kunt verplaatsen naar een alternatief. Controle houden over je data betekent goede exports maken van je data op basis van een goed domein model zodat je in geval van een ramp in ieder geval een migratie mogelijk maakt. Daarbij moet ik wel opmerken dat Salesforce zijn product goed onder controle lijkt te hebben. Zo ver ik weet kun je salesforce niet on-premises draaien en ben je qua ramp afhankelijk van Salesforce.

Reza & Henri

Ik denk dat ik jullie alle 2 in 1 kan beantwoorden: Meten is weten!

Natuurlijk zijn er mogelijkheden om op opslag gebied een 'data reductie' te doen maar heel vaak werkt dat maar één kant op, iets met 'journal sizes' ofzo. Heb al eens het voorbeeld van Nirvanix genoemd, de stress-test voor cloud migratie en Henri is juist door te zeggen dat er vele oorzaken zijn waardoor je moet uitwijken. Wel grappig dat hij dingetjes naar voren welke ik naar ik meen al in een opinie van bijna 2 jaar geleden genoemd heb:

http://www.computable.nl/artikel/opinie/cloud_computing/4546441/2333364/cloud-beheersbaar-maar-niet-beheerbaar.html

Elk nadeel heeft dan ook zijn voordeel want soms werkt een uitvallende cloud oplossing heel genezend doordat de 'IT regiseurs' erachter komen dat die 'Nieuwe IT' uiteindelijk gewoon oud gedrag vertoont waardoor in één keer alle 'Schaduw IT' inzichtelijk wordt. Johan brengt de term Schadefreude in maar we hebben in het Nederlands daar volgens mij gewoon het woord leedvermaak voor want vaak wordt pas weer aandacht aan dingen gegeven als het bij de buren mis gaat maar of het gras ook altijd groener is bij de buren;-)

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×