Het beste maken van uw Omgekeerde Piramide des Onheils

De 3-2-1- of Omgekeerde Piramide des Onheils-architectuur is om vele redenen een paria binnen de IT-branche geworden. Helaas leren veel bedrijven pas over de gevaren van dit ontwerp nadat de componenten zijn gearriveerd en het geld van de rekeningen is verdwenen.

Sommige bedrijven hebben geluk en ontdekken deze fout vroeg genoeg om hun aankopen te kunnen retourneren en opnieuw te beginnen met een degelijke ontwerp- en besluitvormingsfase voorafgaand aan de aanschaf van nieuwe hardware en software. Dit is echter een ideale en zeer zeldzame situatie. In het beste geval kunnen we normaal gesproken herbevoorradingskosten verwachten en, veel vaker, kan de apparatuur helemaal niet geretourneerd worden of zijn de kosten zo hoog dat het zinloos wordt.

Waar de meeste bedrijven mee te maken krijgen, is de noodzaak om er vanaf dat moment “het beste van te maken”. Een van de grootste zorgen is dat de betrokken partijen – of het nu de financiële belanghebbenden zijn die zojuist veel geld aan de nieuwe hardware hebben uitgegeven, of de technische belanghebbenden die er nu slecht uitzien omdat zij de aanschaf van deze apparatuur hebben toegestaan – bezwijken voor een emotionele reactie die ertoe leidt dat zij toegeven aan de drogreden van de verzonken kosten (sunk cost fallacy). Het is van vitaal belang dat deze emotionele, onlogische reactie geen vaste voet krijgt, aangezien zij de kritieke besluitvorming zal ondermijnen.

Men moet begrijpen dat het geld dat aan de omgekeerde piramide des onheils is uitgegeven, reeds is uitgegeven en weg is. Of het geld verspild is of hoeveel ervan verspild is, is op dit punt irrelevant voor de besluitvorming. Of het systeem nu een geschenk was of een miljard dollar kostte, maakt niet uit; dat geld is weg en nu moeten we het doen met wat we hebben. Een mogelijke “truc” hier zou zijn om een financiële besluitvormer zoals een CFO erbij te halen, uit te leggen dat er een emotionele reactie op reeds uitgegeven geld op het punt staat te ontstaan en de drogreden van de verzonken kosten te bespreken voordat het feitelijke probleem ter sprake komt, zodat mensen zich ervan bewust en logisch zijn en de persoon die (naar wij hopen) getraind is om dit soort situaties het beste te hanteren, aanwezig en gereed is om emoties rond verzonken kosten af te wenden. Een zorgvuldige aanpak van een potentieel emotioneel gedreven reactie is belangrijk. Dit is niet het moment om te proberen de financiële of technische misstappen te verdoezelen, wat juist datgene is wat de emotionele reactie teweegbrengt. Het is noodzakelijk dat alle partijen communiceren en afstandelijk en logisch blijven om de behoeften te kunnen aanpakken. Sommige bedrijven gaan hier goed mee om, veel doen dat niet en raken verstrikt in pogingen om voort te bouwen op slechte beslissingen die al genomen zijn, waarschijnlijk in de hoop dat er niets ergs gebeurt en dat niemand het zich herinnert of opmerkt. Bestrijd die reactie. Iedereen heeft hem; het is de natuurlijke “vecht-of-vlucht”-reactie van de amygdala.

Nu we klaar zijn om de emotionele reacties op het probleem te bestrijden, kunnen we beginnen met de vraag “waar gaan we vanaf hier naartoe”. Het goede nieuws is dat we ons over het algemeen in een positie van “te veel” bevinden in plaats van “te weinig”. We hebben dus de gelegenheid om wat creatief te zijn. Gelukkig zijn er over het algemeen goede opties die ons in verschillende richtingen kunnen laten bewegen.

Iets wat zeer belangrijk is om op te merken, is dat we uitsluitend kijken naar oplossingen die betrouwbaarder zijn, niet minder betrouwbaar, dan de beoogde omgekeerde piramide des onheils-architectuur die we vervangen. Een IPOD is een zeer kwetsbaar en gevaarlijk ontwerp en we zouden tot in detail concepten kunnen demonstreren zoals risicoanalyse, single points of failure, de drogredenen van valse redundantie, het kijken naar redundantie in plaats van betrouwbaarheid, afhankelijkheidsketens, enzovoort, maar wat absoluut cruciaal is voor alle partijen om te begrijpen, is dat één enkele server met lokale opslag betrouwbaarder is dan de gehele IPOD-infrastructuur zou zijn. Dit is zo belangrijk dat het nogmaals gezegd moet worden: als één enkele server “standaardbeschikbaarheid” biedt, dan ligt de IPOD daaronder. Risicovoller. Als iemand in dit stadium vreest voor een “gebrek aan redundantie” of een “gebrek aan complexiteit” in de resulterende oplossingen, moeten we hierop terugkomen – niets van wat we zullen bespreken is zo risicovol als wat reeds was ontworpen en aangeschaft. Als er enige vrees voor risico bestaat bij het voortgaan, dan had die vrees groter moeten zijn voordat we de betrouwbaarheid van het ontwerp verbeterden. Dit kan niet genoeg benadrukt worden. IPOD’s verkopen goed omdat ze gemakkelijk degenen misleiden die niet getraind zijn in risicoanalyse en betrouwbaar lijken terwijl ze dat in werkelijkheid allerminst zijn.

Het begrijpen van het bovenstaande en het gebruik van een techniek genaamd het “teruglezen” van de aanvaarde IPOD-architectuur vertelt ons dat het betreffende bedrijf aanvaardde dat het geen hoge beschikbaarheid (of zelfs standaardbeschikbaarheid) had op het moment van aanschaf van de IPOD. Misschien geloofden ze dat ze dit kregen, maar de architectuur kon het niet leveren en dus hebben we vanaf nu de optie om “genoegen te nemen” met niets meer dan één enkele server, draaiend op zijn eigen lokale opslag. Dit is eenvoudig en gemakkelijk en verbetert vrijwel elk aspect van het beoogde IPOD-ontwerp. Het kost minder om te draaien en te onderhouden, is vaak sneller en veel minder complex, terwijl het iets betrouwbaarder is.

Maar eenvoudigweg terugvallen op één enkele server en hopen elders gebruik te vinden voor de rest van de aangeschafte apparatuur zal waarschijnlijk niet onze beste optie zijn. In situaties waarin de IPOD alleen bedoeld was om te worden gebruikt voor één enkele werklast of set werklasten en andere delen van het bedrijf ook behoefte hebben aan apparatuur, kan het zeer voordelig zijn om de “enkele server”-benadering te hanteren voor de beoogde IPOD-werklast en de resterende apparatuur elders in het bedrijf in te zetten.

De meest gangbare benadering bij het herbestemmen van een IPOD-stack is om de twee (of meer) compute-nodes te herconfigureren tot volledige-stack-nodes die hun eigen opslag bevatten. Deze stap vereist mogelijk geen aankopen, afhankelijk van welke opslag reeds is aangeschaft, een verplaatsing van schijven tussen systemen of vaak de relatief kleine aanschaf van extra harde schijven voor dit doel.

Deze nodes kunnen vervolgens worden geconfigureerd in een van twee modellen voor hoge beschikbaarheid. In het verleden was een gangbare ontwerpkeuze, om kostenredenen, het gebruik van een asynchroon replicatiemodel (vaak bekend als de Veeam-benadering) dat virtuele machines tussen de nodes repliceert en het mogelijk maakt om VM’s zeer snel op te starten, waardoor een downtime mogelijk wordt vanaf het moment van het falen van een compute-node tot herstel van slechts enkele minuten.

Tegenwoordig is volledig synchrone foutbestendigheid (fault tolerance) zo vaak gratis beschikbaar dat het in vrijwel alle gevallen het asynchrone model effectief heeft vervangen. In dit model wordt opslag volledig in realtime tussen de compute-nodes gerepliceerd, waardoor failover onmiddellijk kan plaatsvinden, in plaats van met enkele minuten vertraging, en met nul dataverlies in plaats van een klein dataverliesvenster (bijvoorbeeld een RPO van nul).

Op dit punt lijkt het gangbaar dat mensen op replicatie reageren met een vrees voor een verlies van opslagcapaciteit veroorzaakt door de replicatie. Dit is natuurlijk waar. Het is noodzakelijk te begrijpen dat het juist deze replicatie, die ontbrak in het oorspronkelijke IPOD-ontwerp, is die de stevige basis vormt voor hoge betrouwbaarheid. Als deze replicatie wordt overgeslagen, is hoge beschikbaarheid een onbereikbare droom en zijn individuele compute-nodes die lokale opslag in een “stand-alone”-modus gebruiken de meest betrouwbare mogelijke optie. Oplossingen voor hoge beschikbaarheid steunen op replicatie en redundantie om de noodzakelijke betrouwbaarheid op te bouwen om in aanmerking te komen voor hoge beschikbaarheid.

Dit lost de vraag op wat we met onze compute-nodes moeten doen, maar laat ons achter met de vraag wat we kunnen doen met ons externe gedeelde opslagapparaat, het single point of failure ofwel de “punt” van het omgekeerde-piramide-ontwerp. Om deze vraag te beantwoorden, zouden we moeten beginnen met te kijken naar wat deze opslag zou kunnen zijn.

Er zijn drie gangbare typen opslagapparaten die in een omgekeerde-piramide-ontwerp gebruikt zouden worden: DAS, SAN en NAS. We kunnen DAS en SAN samen nemen, aangezien het beide twee verschillende aspecten van blokopslag zijn en in onze bespreking in wezen onderling uitwisselbaar gebruikt kunnen worden – ze worden alleen onderscheiden door het bestaan van switching, dat naar behoefte in onze ontwerpen kan worden toegevoegd of verwijderd. NAS verschilt doordat het bestandsopslag is in plaats van blokopslag.

In beide gevallen, blokopslag (DAS of SAN) of bestandsopslag (NAS), is een van de meest gangbare toepassingen voor dit nu overbodige apparaat als back-updoel voor onze nieuwe virtualisatie-infrastructuur. In veel gevallen kan het apparaat overdreven zijn voor deze taak, doorgaans met meer prestaties en veel meer functies dan nodig voor een eenvoudig back-updoel, maar goede back-upopslag is belangrijk voor elke kritieke bedrijfsinfrastructuur en aan de kant van overdaad gaan zitten is niet noodzakelijkerwijs een slechte zaak. Bedrijven proberen vaak te bezuinigen op hun back-upinfrastructuren en dit is een gelegenheid om er fors in te investeren zonder extra geld uit te geven.

In dezelfde lijn als back-upopslag zou het externe opslagapparaat herbestemd kunnen worden als archiveringsopslag of een andere “lagere laag” van opslag waar hoge beschikbaarheid niet gerechtvaardigd is. Dit is een minder gangbare benadering, doorgaans omdat elk bedrijf een goed back-upsysteem nodig heeft, maar slechts sommige een manier hebben om een archiveringsopslaglaag te benutten.

Naast deze twee gangbare en universele opslagmodellen is een veelvoorkomend gebruiksscenario voor externe opslagapparaten, vooral als het apparaat een NAS is, om het in zijn oorspronkelijke rol te benutten als bestandsserver, gescheiden van de virtualisatie-infrastructuur. Voor veel bedrijven is bestandsdeling niet zo kritiek voor de uptime als de kern-virtualisatie-infrastructuur en zijn back-ups veel gemakkelijker te onderhouden en te beheren. Door bestandsdeling te verplaatsen naar een reeds aangeschaft NAS-apparaat kan dit de vereisten voor bestandsdeling van de virtualisatie-infrastructuur verminderen, zowel door het aantal VM’s dat daar moet draaien te verlagen als door het verplaatsen van wat doorgaans een van de grootste gebruikers van opslag is naar een apart apparaat, wat zowel de prestatievereisten van de virtualisatie-infrastructuur als de capaciteitsvereisten ervan kan verlagen. Door dit te doen verlagen we mogelijk de kosten van het verkrijgen van de noodzakelijke extra harde schijven voor de lokale opslag op de compute-nodes, zoals we eerder stelden, en dit kan dus een zeer populaire methode zijn voor veel bedrijven om in de herbestemmingsbehoeften te voorzien.

Elk bedrijf is uniek en er zijn potentieel veel plaatsen waar overtollige opslagapparatuur effectief gebruikt zou kunnen worden, van labs tot archieven tot gelaagde opslag. Met een beetje creativiteit en denken buiten de gebaande paden kan uw unieke set beschikbare apparatuur en de unieke set behoeften en eisen van uw bedrijf worden benut om de beste plaats te vinden om deze apparatuur in te zetten, waar zij losgekoppeld is van de kritieke kern-virtualisatie-infrastructuur, maar nog steeds waarde kan toevoegen aan de organisatie. Door de omgekeerde piramide des onheils te vermijden, kunnen we de maximale waarde halen uit de apparatuur waarin we reeds hebben geïnvesteerd, in plaats van verse technische schuld te creëren die we vervolgens onnodig moeten zien weg te werken.