It-managers dienen zeer kritisch te bepalen wat de Business vraagt. Op basis van een juiste functionele analyse wordt de technishe inrichting pas interessant. Veel it-organisaties eisen een volledig synchroon gerepliceerd storage-platform om de beschikbaarheid van alle data te waarborgen. Deze eis staat veelal centraal in de aanvraag van organisaties.
Betreffende organisaties claimen vaak door deze storage-eis in de aanvraag op te nemen dat, na of tijdens een onvoorziene calamiteit binnen het datacenter, het storageplatform de absolute zekerheid biedt ten aanzien het behoud van data en met name de gehele operatie.
Soms wordt deze eis kracht bijgezet door de stelling dat het storage-platform moet voldoen aan een ‘active-active’ opzet. De vraag hierbij is, of bovenstaande veronderstellingen daadwerkelijk antwoord geven op de doelstelling van absolute beschikbaarhied zoals door de organistaie wordt beoogt. Een organisatie moet zich realiseren dat de vraag om technische eigenschappen vanuit het storage-platform niet een doel zijn maar middelen om een doel te behalen. Daarbij is het evident, kritisch te zijn naar de daadwerkelijke voordelen van de middelen die hierin worden gevraagd. Maar al te vaak bieden marktpartijen niet de juiste support die klanten zouden moeten helpen in te gaan op de daadwerkelijke behoefte gezien vnauit de business van de klant. Te vaak wordt de klant in het advies beperkt doordat gestuurd wordt op traditionele oplossingen.
Wanneer wordt verondersteld dat een organisatie een hoge beschikbaarhied (99,999 procent) moet eisen omwille de bedrijfsvoering, is een storageplatform binnen de volledige it-infrastructuur slechts een component en biedt slechts een relatieve zekerheid. Het is van belang dat een organisatie zich realiseert dat functionele eisen en wensen ten aanzien van de diverse processen veelal direct van invloed zijn op alle disciplines binnen de datacenter omgeving en dit bepalend moet zijn voor de uiteindelijke configuratie van de gehele omgeving. De zaken die een organisatie dient te onderzoeken zijn de mate van en de hoogte van het Recovery Time Objective (RTO – de maximum toelaatbare tijd dat een systeem, applicatie of netwerk onbeschikbaar mag zijn volgens het Business Continuity Plan (BCP) -en het Recovery Point Objective (RPO) – het in het BCP gestelde tijdvak waarin welke gegevens hersteld moeten kunnen worden – voor alle data en applicaties.
Voorafgaand het ontwerp van een storage-infrastructuur te kunnen bepalen is het van essentieel belang dat betreffende organisaties over een Business Impact Analyse (BIA) beschikken. Hierin zijn functionele eisen en wensen ten aanzien van de volledige omgeving duidelijk gekwalificeerd en gecategoriseerd. Een dergelijke categorische indeling van onder andere applicaties, databases en andere disciplines hebben een directe relatie met een Business Continuity Plan (BCP). Als het afdekken van een risico reeds is belegd binnen de organisatie, hoeft deze niet meer te worden meegenomen in het BCP.
Het is belangrijk te bepalen wat de risico’s zijn die moeten worden gedekt en wat de impact van een mogelijke calamiteit is op de operatie. Het niet of gedeeltelijk operationeel zijn van een bepaald proces heeft een invloed op de bedrijfvoering. De mate van impact op de bedrijfvoering wordt voornamelijk voor een groot gedeelte bepaald ten aanzien de kritisiteit van het proces. Het gaat hierbij dus niet om de calamiteit zelf, maar om het effect dat een calamiteit heeft op de bedrijfsvoering van de organisatie. Daarbij is het evident zich als organisatie te realiseren welke neven-effect(en) een voorafgedefinieerde calamiteit heeft op de bedrijfsvoering en op het proces dat primair van invloed is.
Wanneer zich binnen het datacenter een onvoorziene calamiteit voordoet zoals een alles vernietigende brand of anderzins, zal de it-organisatie voorbereidt moeten zijn en derhalve willen kunnen handelen naar de gestelde RTO en RPO zoals in het beleidsplan zijn bepaald. Bovendien dient een organisatie zich te realiseren dat een BCP zich niet richt op enkel preventieve maatregelen maar evenzeer op repressieve maatregelen.
De kans dat een omvangrijke calamiteit zelfs de geboden beschikbaarheid van de oplossing zal overkomen, is heel klein. Bovendien zijn dit soort calamiteiten vaak zo desastreus dat rekening gehouden dient te worden met andere aangelegenheden die niet direct een technologische relatie hebben zoals huisvesting, werknemers et cetera.
Een set aan repressieve maatregelingen kunnen voorkomen dat een calamiteit uitgroeit tot een verstoring van de continuïteit van de organisatie. Hiervoor is het raadzaam om tesamen met de huidige- of toekomstige leverancier een communicatieprotocol, een afsprakenlijst én plan van aanpak voor mogelijke incidenten vast te stellen Elk jaar kunnen deze procedures gesimuleerd worden en tesamen met de levarancier beoordeeld of alles wat is afgesproken nog steeds van toepassing is. In tegenstelling tot de traditionele aanpak om beschikbaarheid te koppelen aan een gerepliceerde storage oplossing, is het betrekken van de organisatie in het opstellen van een BIA een must om een juiste en kosten efficiente oplossing te kunnen aanschaffen.
Kuddegedrag is niet de beste weg naar verstandig dataopslag. It-oragnisaties moeten zich goed beseffen dat gedegen advies, dat ingaat op de business behoefte, noodzakelijk is voor het juist kunnen bepalen van een nieuwe of aanpassing van een storage-infrastructuur.
Marcel,
Terecht dat je aandacht vraagt voor de soms absurde eisen rond beschikbaarheid. Wat ik echter een beetje mis zijn mogelijkheden als Cloud (eventueel in een container) welke een oplossing geven voor het huisvestingsprobleem. Het nieuwe werken en mobiliteit maken dat probleem dan ook minder urgent. Mogelijk meer problematisch zijn echter de datalijnen die nodig zijn voor replicatie maar ook voor remote werken.
Verder zie ik dat organisaties soms zoveel vertrouwen in hun opslag stellen dat ze het regelmatig maken van een backup achterwege laten. Synchronisatie en replicatie dekt echter niet het risico van corrupt raken van data door malware, virussen, menselijke fouten of sabotage. De kans en mate van optreden is vaak groter dan een alles verwoestende brand.
Dat kuddegedrag niet de beste weg is naar de goede oplossing is juist. Maar ook angst is vaak een slechte raadgever en juist daar wordt nogal vaak gebruik van gemaakt. En dus wordt alles dubbel genaaid omdat extra stiknaden steviger lijken. Maar als de afhechting niet goed is zal het ‘storage breiwerk’ gauw uit elkaar vallen.
Regelmatig herzien en testen van de bedachte oplossing is dan ook goed advies. Een nog beter advies is om dat niet te laten doen door de leverancier. Want vreemde ogen dwingen niet alleen maar zien ook vaak sneller de tekortkomingen.
Marcel,
Ik neem aan dat je onderstaand net andersom bedoeld:
” De zaken die een organisatie dient te onderzoeken zijn de mate van en de hoogte van het Recovery Time Objective (RTO – de maximum toelaatbare tijd dat een systeem, applicatie of netwerk onbeschikbaar mag zijn volgens het Business Continuity Plan (BCP) -en het Recovery Point Objective (RPO) – het in het BCP gestelde tijdvak waarin welke gegevens hersteld moeten kunnen worden – voor alle data en applicaties”
RPO = Hoeveel data verlies kan je maximaal overleven
RTO = De tijd die nodig is voor dat alles weer up and running is
Maar dit zal denk ik wel een schoonheidsfoutje zijn 🙂
“Soms wordt deze eis kracht bijgezet door de stelling dat het storage-platform moet voldoen aan een ‘active-active’ opzet”
Active-active is natuurlijk leuk aangezien er (bijna) geen dataverlies optreedt. Echter neem je in zo’n opzet wel gelijk alle kinderziektes van de andere kant over. Is de Exchange DB aan de ene kant corrupt dan heb je dezelfde corrupte DB gelijk aan de andere kant. En het kan uiteindelijk wel uren duren voor dat je zo’n corrupte DB weer aan de praat hebt.
Echter is active-active voor (financiele) organisaties waar geen enkel dataverlies mag optreden nog steeds een must.
De andere way to go is om te kiezen voor een active-passive setup door middel vaN bijvoorbeeld A-Synch replicatie. Je neemt dan niet de kinderziektes mee maar je hebt wel altijd dataverlies afhankelijk van de replicatie frequentie
En je hebt natuurlijk nog de tussenoplossing op basis van CDP technologie ( Continuous Data Protection ) Dit is eigenlijk best of both worlds. Je verliest een minimale hoeveelheid aan data. En de data die gerepliceerd is, is consistent. Ook kan er terug en weer vooruit gegaan worden in snapshots.
Afhankelijk van de wensen en eisen ( lees RPO/RTO ) van de klant kan er gekozen worden voor de oplossing welke het beste hier bij past.
Ik deel je mening dat een BCP iets is wat je enkele keren per jaar moet reviewen en testen. Ook is geregeld preventief onderhoud hier geen overbodige luxe. Doe je dit niet dan loop je achter de feiten aan met alle risico’s van dien.
Wat een leuk artikel Marcel!
Ik heb laatst een stuk gelezen over beschikbaarheid van 99,999999%. In dat artikel werd gekeken naar gehele ICT-keten en liet zien dat je alleen deze beschikbaarheid kan halen als je een berg geld hebt om deze aan middelen uit te geven die de hoge beschikbaarheid in de verschillende lagen binnen je infrastructuur en architectuur kunnen waarborgen. Veel organisaties zijn niet bewust van dit feit en zoals je aangaf ze denken dat met en SAN-replicatie het probleem opgelost is.
Volgens mij het modulair opbouwen van je ICT architectuur, prioriteren en consolideren van je business applicaties en databronnen naast een BC/DR plan zijn de eerste stappen in deze richting.
Bijvoorbeeld door het inzetten van een ERP oplossing zou je de functionaliteit van een aantal applicaties in een applicatie kunnen opnemen (lees consolideren).Hierdoor zou je een aantal afhankelijkheden en processen in de keten weg kunnen halen en bijdragen aan een lagere investering en realisatie van een DR oplossing.
BC/DR is een maatwerk, daarvoor moet de organisatie genoeg kennis en ervaring in huis hebben.
Aardig artikel. Het begint met een storage platform en voor je het weet heb je brand in je datacenter als calamiteit. Dat ligt natuurlijk mijlenver uit elkaar en daarom ga je niet synchroon active-active repliceren.
Het is ook een verkeerde aanname dat gebruikers synchroon willen repliceren, de industrie heeft dit opgedrongen als de oplossing tegen data verlies. Dat je met synchrone replicatie tegen allerlei problemen aanloopt, dat is een gegeven.
Er zijn tegenwoordig ook weer andere methoden voorhanden om dataverlies te voorkomen, zoals Ruud Mulder noemt met Continous Data Protection en Database mirroring met log shopping. De cloud in dit soort scenario’s een grote rol kan spelen. De snapshot’s of logships kan je in de cloud opslaan en samenvoegen met de overgebleven kopie.
Andere ontwikkelingen zijn object gebaseerde storage, denk aan Openstack, waarbij de storage applicatie gaat zorgdragen voor de resilience van de data door deze over meerdere schijven, arrays en site te kopiëren. Dit is “cloud” technologie, die overigens al 30 jaar bestaat. Nadeel van deze technieken is het ontbreken van automatische tiering, dus performance kan een probleem vormen.
Andere ontwikkelingen zijn de migratie van storage specifieke functies naar de andere infrastructuur lagen. Dat zie je bij VMware vanaf 5.0 en ook Hyper-V gaat de virtualisatie van storage besturen. Hierdoor is de onderste storage laag niet meer leidend en kan je op andere manieren en met andere technieken de storage behoeften invullen.
Synchrone replicatie begint old-skool te worden en daar speelt het artikel op in door aan te geven dat er meer moet worden ingespeeld op de functionele behoeften en niet de technische specs van een oplossing.
Hallo Marcel,
Goed verhaal…, dit is waar we ’t al zo vaak met elkaar over gehad hebben.
Zodra een organisatie onder ogen durft (of wil) te zien wat belangrijk is en wat niet en zich niet laat leiden door wat anderen doen of door angst, dan ben ik ervan overtuigd dat de organisaties oplossingen krijgen aangeboden welke zowel technisch als financieel veel efficienter zullen zijn.
de term active-active danwel active-passive wordt trouwens toch ook vaak op verschillende wijzes geinterpreteerd.
hebben we ’t dan over de arrays zelf of zijn ‘slechts’ de sites active/active.
arrays over sites verdeeld in een ‘active/passive site setup’ kunnen ook synchroon repliceren, met alle voor- en nadelen. twee sites waar op iedere site een array staat met ‘eigen’ data die bi-directioneel data repliceren, zijn als site beide actief, maar kunnen gerust a-synchroon repliceren.
in ’t kader van dit artikel ga ik even uit van een transparante, volledige site failover (dus niet alleen storage) zonder downtime voor de applicaties. daarmee een RPO en RTO van beide 0. benieuwd naar de eerste organisatie die dit echt kan realiseren.