Att göra det bästa av din omvända undergångspyramid

3-2-1-arkitekturen eller den omvända undergångspyramiden har blivit en paria inom IT-branschen av många skäl. Sorgligt nog för många företag får de inte kännedom om farorna som är förknippade med denna design förrän komponenterna har anlänt och pengarna har lämnat kontona.

Vissa företag har tur och upptäcker detta misstag tillräckligt tidigt för att kunna returnera sina inköp och börja om med en korrekt design- och beslutsfas innan ny hårdvara och mjukvara anskaffas. Detta är dock ett idealiskt och mycket sällsynt scenario. I bästa fall kan vi normalt räkna med returavgifter och, betydligt vanligare, kan utrustningen inte returneras alls eller så är avgifterna så stora att det blir meningslöst.

Vad de flesta företag står inför är ett behov av att ”göra det bästa” av situationen framåt. En av de största farhågorna är att berörda parter, vare sig det rör sig om de finansiella intressenterna som just har spenderat mycket pengar på den nya hårdvaran eller de tekniska intressenterna som nu framstår i dålig dager för att ha tillåtit att denna utrustning köptes in, ger efter för en känslomässig reaktion som resulterar i att de faller offer för sunk cost-felslutet. Det är avgörande att denna känslomässiga, ologiska reaktion inte tillåts få fäste eftersom den kommer att undergräva ett kritiskt beslutsfattande.

Man måste förstå att pengarna som spenderats på den omvända undergångspyramiden redan är spenderade och borta. Att pengarna slösades bort eller hur mycket som slösades bort är irrelevant för beslutsfattandet i detta skede. Om systemet var en gåva eller om det kostade en miljard dollar spelar ingen roll, de pengarna är borta och nu måste vi klara oss med det vi har. Ett potentiellt ”knep” här skulle vara att ta in en finansiell beslutsfattare som en CFO, förklara att det är på väg att uppstå en känslomässig reaktion på pengar som redan spenderats och diskutera sunk cost-felslutet innan man talar om det faktiska problemet, så att människor är medvetna och logiska och så att den person som (förhoppningsvis) tränats för att bäst hantera denna typ av situation är på plats och redo att avvärja sunk cost-känslor. En varsam hantering av en potentiellt känslodriven reaktion är viktig. Detta är inte tillfället att försöka mörka vare sig de finansiella eller de tekniska felstegen, vilket är vad den känslomässiga reaktionen skapar. Det är nödvändigt att alla parter kommunicerar och förblir distanserade och logiska för att kunna tillgodose behoven. Vissa företag hanterar detta väl, många gör det inte och fastnar i att försöka driva vidare med dåliga beslut som redan fattats, troligen i hopp om att inget illa händer och att ingen kommer ihåg eller lägger märke till det. Bekämpa den reaktionen. Alla har den, det är amygdalans naturliga känslomässiga ”kamp eller flykt”-respons.

Nu när vi är redo att bekämpa de känslomässiga reaktionerna på problemet kan vi börja ta itu med ”vart går vi härifrån”. Den goda nyheten är att den situation vi befinner oss i i allmänhet är en position av att ha ”för mycket” snarare än ”för lite”. Så vi har en möjlighet att vara lite kreativa. Lyckligtvis finns det i allmänhet goda alternativ som kan låta oss röra oss i flera riktningar.

En sak som är mycket viktig att notera är att vi uteslutande tittar på lösningar som är mer tillförlitliga, inte mindre tillförlitliga, än den tilltänkta omvända undergångspyramidsarkitektur som vi ersätter. En IPOD är en mycket bräcklig och farlig design och vi skulle kunna gå mycket långt för att demonstrera koncept som riskanalys, enskilda felpunkter, felsluten kring falsk redundans, att titta på redundans i stället för tillförlitlighet, beroendekedjor och så vidare, men vad som är absolut avgörande för alla parter att förstå är att en enskild server som körs med lokal lagring är mer tillförlitlig än hela IPOD-infrastrukturen skulle vara. Detta är så viktigt att det måste sägas igen: om en enskild server är ”standardtillgänglighet” är IPOD:en lägre än så. Mer riskfylld. Om någon i detta skede fruktar en ”brist på redundans” eller en ”brist på komplexitet” i de resulterande lösningarna måste vi återkomma till detta – ingenting av det vi kommer att diskutera är så riskfyllt som det som redan hade designats och köpts in. Om det finns någon rädsla för risk framåt borde rädslan ha varit större innan vi förbättrade designens tillförlitlighet. Detta kan inte nog understrykas. IPOD:er säljer för att de lätt förvirrar dem som inte är utbildade i riskanalys och ser tillförlitliga ut när de i själva verket är allt annat än det.

Att förstå ovanstående och använda en teknik kallad att ”läsa tillbaka” den accepterade IPOD-arkitekturen säger oss att företaget i fråga accepterade att inte ha hög tillgänglighet (eller ens standardtillgänglighet) vid tidpunkten för köpet av IPOD:en. Kanske trodde de att de fick det, men arkitekturen kunde inte tillhandahålla det och så framåt har vi alternativet att ”klara oss” med inget mer än en enskild server som körs på sin egen lokala lagring. Detta är enkelt och okomplicerat och förbättrar nästan varje aspekt av den tilltänkta IPOD-designen. Det kostar mindre att driva och underhålla, är ofta snabbare och är mycket mindre komplext samtidigt som det är något mer tillförlitligt.

Men troligen kommer det inte att vara vårt bästa alternativ att bara gå ner till en enskild server och hoppas på att hitta användningsområden för resten av den inköpta utrustningen ”någon annanstans”. I situationer där IPOD:en endast var avsedd att användas för en enda arbetsbelastning eller uppsättning arbetsbelastningar och andra delar av verksamheten också har behov av utrustning kan det vara mycket fördelaktigt att gå över till ”enskild server”-ansatsen för den tilltänkta IPOD-arbetsbelastningen och utnyttja den återstående utrustningen på andra håll i verksamheten.

Den vanligaste ansatsen att ta vid återanvändning av en IPOD-stack är att konfigurera om de två (eller flera) beräkningsnoderna till fullstacksnoder som innehåller sin egen lagring. Detta steg kan kräva inga inköp alls, beroende på vilken lagring som redan har köpts in, en förflyttning av diskar mellan system eller ofta det relativt lilla inköpet av ytterligare hårddiskar för detta ändamål.

Dessa noder kan sedan konfigureras enligt en av två modeller för hög tillgänglighet. Tidigare var ett vanligt designval, av kostnadsskäl, att använda en asynkron replikeringsmodell (ofta känd som Veeam-ansatsen) som replikerar virtuella maskiner mellan noderna och låter virtuella maskiner startas upp mycket snabbt, vilket möjliggör en driftstopp från det ögonblick en beräkningsnod fallerar till återställning på så lite som bara några minuter.

Idag finns fullt synkron feltolerans så vanligt förekommande utan kostnad att den i praktiken har ersatt den asynkrona modellen i nästan alla fall. I denna modell replikeras lagring i helt realtid mellan beräkningsnoderna, vilket gör att failover kan ske omedelbart i stället för med några minuters fördröjning, och med noll dataförlust i stället för ett litet dataförlustfönster (t.ex. RPO på noll).

Vid det här laget tycks det vara vanligt att människor reagerar på replikering med en rädsla för en förlust av lagringskapacitet orsakad av replikeringen. Detta är förstås sant. Det är nödvändigt att man förstår att det är just denna replikering, som saknades i den ursprungliga IPOD-designen, som utgör den fasta grunden för hög tillförlitlighet. Om denna replikering hoppas över är hög tillgänglighet en ouppnåelig dröm och enskilda beräkningsnoder som använder lokal lagring i ett ”fristående” läge är det mest tillförlitliga möjliga alternativet. Lösningar för hög tillgänglighet förlitar sig på replikering och redundans för att bygga den tillförlitlighet som krävs för att kvalificera för hög tillgänglighet.

Detta löser frågan om vad vi ska göra med våra beräkningsnoder men lämnar oss med vad vi kan göra med vår externa delade lagringsenhet, den enskilda felpunkten eller ”spetsen” i den omvända pyramiddesignen. För att besvara denna fråga bör vi börja med att titta på vad denna lagring kan vara.

Det finns tre vanliga typer av lagringsenheter som skulle användas i en omvänd pyramiddesign: DAS, SAN och NAS. Vi kan klumpa ihop DAS och SAN eftersom de båda är två olika aspekter av blocklagring och kan användas i princip utbytbart i vår diskussion – de skiljer sig endast åt genom förekomsten av växling som kan läggas till eller tas bort efter behov i våra designer. NAS skiljer sig genom att vara fillagring snarare än blocklagring.

I båda fallen, block (DAS eller SAN) eller fil (NAS), är en av de vanligaste användningarna för denna nu överflödiga enhet som ett backupmål för vår nya virtualiseringsinfrastruktur. I många fall kan enheten vara överdimensionerad för denna uppgift, i allmänhet med mer prestanda och många fler funktioner än vad som behövs för ett enkelt backupmål, men bra backuplagring är viktig för all kritisk affärsinfrastruktur och att fela på sidan av överdimensionering är inte nödvändigtvis något dåligt. Företag försöker ofta snåla med sina backupinfrastrukturer och detta är en möjlighet att investera tungt i den utan att spendera några extra pengar.

I samma anda som backuplagring skulle den externa lagringsenheten kunna återanvändas som arkivlagring eller någon annan ”lägre nivå” av lagring där hög tillgänglighet inte är motiverad. Detta är en mindre vanlig ansats, i allmänhet eftersom varje verksamhet behöver ett bra backupsystem men endast vissa har ett sätt att utnyttja en arkivlagringsnivå.

Utöver dessa två vanliga och universella lagringsmodeller är ett vanligt användningsfall för externa lagringsenheter, särskilt om enheten är en NAS, att utnyttja den i dess inhemska roll som en filserver skild från virtualiseringsinfrastrukturen. För många verksamheter är filservering inte lika kritisk för drifttiden som den centrala virtualiseringsinfrastrukturen och backuper är mycket enklare att underhålla och hantera. Genom att avlasta filservering till en redan inköpt NAS-enhet kan detta minska kraven på filservering från virtualiseringsinfrastrukturen både genom att minska antalet virtuella maskiner som behöver köras där och genom att flytta vad som vanligtvis är en av de största förbrukarna av lagring till en separat enhet, vilket kan sänka prestandakraven på virtualiseringsinfrastrukturen liksom dess kapacitetskrav. Genom att göra detta minskar vi potentiellt kostnaden för att anskaffa nödvändiga ytterligare hårddiskar för den lokala lagringen på beräkningsnoderna som vi nämnde tidigare och därför kan detta vara en mycket populär metod för många företag att tillgodose återanvändningsbehoven.

Varje företag är unikt och det finns potentiellt många platser där överbliven lagringsutrustning skulle kunna användas effektivt, från labb till arkiv till nivåindelad lagring. Genom att använda lite kreativitet och tänka utanför ramarna kan man utnyttja sin unika uppsättning tillgänglig utrustning och sin verksamhets unika uppsättning behov och krav och hitta den bästa platsen att använda denna utrustning där den är frikopplad från den centrala, kritiska virtualiseringsinfrastrukturen men ändå kan tillföra värde till organisationen. Genom att undvika den omvända undergångspyramiden kan vi få ut maximalt värde av den utrustning som vi redan har investerat i i stället för att implementera ny teknisk skuld som vi sedan måste arbeta för att övervinna i onödan.