Å gjøre det beste ut av din omvendte pyramid of doom

Den 3-2-1 eller omvendte pyramid of doom-arkitekturen har blitt en paria i IT-bransjen av mange grunner. Dessverre lærer mange selskaper om farene forbundet med dette designet først etter at komponentene har ankommet og pengene har forlatt kontoen.

Noen selskaper er heldige og oppdager denne feilen tidlig nok til å kunne returnere kjøpene sine og starte på nytt med en ordentlig design- og beslutningsfase før anskaffelse av ny maskinvare og programvare. Dette er imidlertid en ideell og svært sjelden situasjon. I beste fall kan vi normalt forvente restlagergebyrer og, langt mer vanlig, kan utstyret overhodet ikke returneres eller gebyrene er så store at det er meningsløst.

Det de fleste selskaper møter er et behov for å «gjøre det beste» ut av situasjonen fremover. En av de største bekymringene er at berørte parter, enten det er de finansielle interessentene som nettopp har brukt mye penger på den nye maskinvaren, eller de tekniske interessentene som nå ser dårlig ut for å ha tillatt at dette utstyret ble kjøpt inn, gir etter for en emosjonell reaksjon ved å gi etter for den tapte kostnadens feilslutning. Det er avgjørende at denne emosjonelle, ulogiske reaksjonen ikke får fotfeste, da den vil undergrave kritisk beslutningstaking.

Det må forstås at pengene som ble brukt på den omvendte pyramid of doom allerede er brukt og borte. At pengene ble kastet bort eller hvor mye som ble kastet bort er irrelevant for beslutningstaking på dette tidspunktet. Om systemet var en gave eller om det kostet en milliard dollar spiller ingen rolle, disse pengene er borte og nå må vi klare oss med det vi har. Et potensielt «triks» her ville være å hente inn en finansiell beslutningstaker som en CFO, forklare at det er i ferd med å komme en emosjonell reaksjon på penger som allerede er brukt og diskutere den tapte kostnadens feilslutning før man snakker om det faktiske problemet, slik at folk er bevisste og logiske, og personen som er opplært (vi håper) til best å håndtere denne typen situasjon er til stede og klar til å dempe de tapte kostnadenes emosjonelle reaksjoner. Forsiktig håndtering av en potensielt følelsesdrevet reaksjon er viktig. Dette er ikke tidspunktet for å forsøke å dekke over verken de finansielle eller tekniske feiltrinnene, noe som er det den emosjonelle reaksjonen skaper. Det er nødvendig at alle parter kommuniserer og forblir løsrevet og logiske for å imøtekomme behovene. Noen selskaper håndterer dette godt, mange gjør det ikke og blir fanget i forsøket på å gå videre med dårlige beslutninger som allerede ble tatt, sannsynligvis i håp om at ingenting skjer og at ingen husker eller legger merke til det. Bekjemp den reaksjonen. Alle har den, det er den naturlige amygdala-«kjemp eller flykt»-emosjonelle responsen.

Nå som vi er klare til å bekjempe de emosjonelle reaksjonene på problemet, kan vi begynne å adressere «hvor går vi herfra.» Den gode nyheten er at der vi er, er generelt en posisjon av å ha «for mye» snarere enn «for lite.» Så vi har en mulighet til å være litt kreative. Heldigvis finnes det generelt gode alternativer som kan la oss bevege oss i flere retninger.

En ting som er svært viktig å merke seg er at vi ser på løsninger utelukkende som er mer pålitelige, ikke mindre pålitelige, enn den tiltenkte omvendte pyramid of doom-arkitekturen vi erstatter. En IPOD er et svært skjørt og farlig design, og vi kunne gå langt i å demonstrere konsepter som risikoanalyse, enkeltfeilpunkter, feilslutninger om falsk redundans, å se på redundans i stedet for pålitelighet, avhengighetskjeder osv. Men det som er absolutt kritisk for alle parter å forstå er at en enkelt server som kjører med lokal lagring er mer pålitelig enn hele IPOD-infrastrukturen ville vært. Dette er så viktig at det må sies igjen: hvis en enkelt server er «standard tilgjengelighet», er IPOD lavere enn det. Mer risikabelt. Hvis noen på dette stadiet frykter «mangel på redundans» eller «mangel på kompleksitet» i de resulterende løsningene, må vi komme tilbake til dette – ingenting av det vi vil diskutere er like risikabelt som det som allerede var designet og kjøpt inn. Hvis det er noen frykt for risiko fremover, burde frykten ha vært større før vi forbedret påliteligheten til designet. Dette kan ikke overdrives. IPOD-er selger fordi de lett forvirrer de som ikke er opplært i risikoanalyse og ser pålitelige ut når de i virkeligheten er alt annet enn det.

Å forstå ovenstående og bruke en teknikk kalt «tilbakelinking» til den aksepterte IPOD-arkitekturen forteller oss at selskapet det gjelder aksepterte å ikke ha høy tilgjengelighet (eller endog standard tilgjengelighet) på tidspunktet for kjøp av IPOD. Kanskje trodde de at de fikk det, men arkitekturen kunne ikke levere det, og så fremover har vi muligheten til å «klare oss» med ikke mer enn en enkelt server som kjører på sin egen lokale lagring. Dette er enkelt og greit og forbedrer nesten alle aspekter av det tiltenkte IPOD-designet. Det koster mindre å drive og vedlikeholde, er ofte raskere og er mye mindre komplekst samtidig som det er litt mer pålitelig.

Men å bare gå ned til en enkelt server og håpe på å finne bruk for resten av det innkjøpte utstyret «andre steder» vil sannsynligvis ikke være vårt beste alternativ. I situasjoner der IPOD var ment å kun brukes til en enkelt arbeidsbelastning eller sett av arbeidsbelastninger og andre deler av virksomheten også har behov for utstyr, kan det være svært fordelaktig å gå til «enkeltserver»-tilnærmingen for den tiltenkte IPOD-arbeidsbelastningen og bruke det gjenværende utstyret andre steder i virksomheten.

Den vanligste tilnærmingen for å gjenbruke en IPOD-stabel er å konfigurere om de to (eller flere) beregningsnodene til å være full-stabel noder som inneholder sin egen lagring. Dette trinnet kan kreve ingen kjøp, avhengig av hva slags lagring som allerede er kjøpt inn, en flytting av stasjoner mellom systemer eller ofte det relativt lille kjøpet av ekstra harddisker for dette formålet.

Disse nodene kan da konfigureres til en av to høy-tilgjengelighetsmodeller. Tidligere var et vanlig designvalg, av kostnadsmessige årsaker, å bruke en asynkron replikeringsmodell (ofte kjent som Veeam-tilnærmingen) som vil replikere virtuelle maskiner mellom nodene og tillate virtuelle maskiner å bli slått på svært raskt, noe som gir en nedetid fra øyeblikket for beregningsnodefeil til gjenoppretting på så lite som bare noen få minutter.

I dag er fullt synkron feiltoleranse tilgjengelig så vanlig og gratis at den i praksis har erstattet den asynkrone modellen i nesten alle tilfeller. I denne modellen replikeres lagring i fullstendig sanntid mellom beregningsnodene, noe som gjør at failover skjer umiddelbart, i stedet for med noen minutters forsinkelse, og med null datatap i stedet for et lite datatapvindu (f.eks. RPO på null).

På dette punktet virker det å være vanlig at folk reagerer på replikering med en frykt for tap av lagringskapasitet forårsaket av replikeringen. Selvfølgelig er dette sant. Det er nødvendig at det forstås at det er denne replikeringen, som mangler fra det opprinnelige IPOD-designet, som gir det solide grunnlaget for høy pålitelighet. Hvis denne replikeringen hoppes over, er høy tilgjengelighet en uoppnåelig drøm og individuelle beregningsnoder som bruker lokal lagring i en «frittstående» modus er det mest pålitelige potensielle alternativet. Høy tilgjengelighetsløsninger er avhengige av replikering og redundans for å bygge den nødvendige påliteligheten for å kvalifisere for høy tilgjengelighet.

Dette løser spørsmålet om hva vi skal gjøre med beregningsnodene våre, men etterlater oss med hva vi kan gjøre med vår eksterne delte lagringsenhet, det enkle feilpunktet eller «spissen» på det omvendte pyramidedesignet. For å svare på dette spørsmålet bør vi starte med å se på hva denne lagringen kan være.

Det er tre vanlige typer lagringsenheter som ville bli brukt i et omvendt pyramidedesign: DAS, SAN og NAS. Vi kan slå DAS og SAN sammen da de begge er to forskjellige aspekter av blokklagring og kan brukes i praksis om hverandre i vår diskusjon – de er bare differensiert av eksistensen av svitsjing som kan legges til eller fjernes etter behov i våre design. NAS skiller seg ut ved å være fillagring snarere enn blokklagring.

I begge tilfeller, blokklagring (DAS eller SAN) eller fillagring (NAS), er en av de vanligste bruksområdene for denne nå overflødige enheten som et sikkerhetskopimål for vår nye virtualiseringsinfrastruktur. I mange tilfeller kan enheten være overkill for denne oppgaven, generelt med mer ytelse og mange flere funksjoner enn nødvendig for et enkelt sikkerhetskopimål, men god sikkerhetskopieringslagring er viktig for enhver kritisk forretningsinfrastruktur og å feile på siden av overkill er ikke nødvendigvis en dårlig ting. Bedrifter forsøker ofte å spare på sikkerhetskopieringsinfrastrukturen sin, og dette er en mulighet til å investere tungt i den uten å bruke ekstra penger.

I samme ånd som sikkerhetskopieringslagring kan den eksterne lagringsenheten gjenbrukes som arkivlagring eller andre «lavere nivå» av lagring der høy tilgjengelighet ikke er berettiget. Dette er en mindre vanlig tilnærming, generelt fordi hver bedrift trenger et godt sikkerhetskopieringssystem, men bare noen har en måte å utnytte et arkivlagringssjikt på.

Utover disse to vanlige og universelle lagringsmodellene er et vanlig bruksområde for eksterne lagringsenheter, spesielt hvis enheten er en NAS, å bruke den i sin naturlige rolle som en filserver separat fra virtualiseringsinfrastrukturen. For mange bedrifter er ikke filtjenester like oppetidskritiske som kjernevirtualiseringsinfrastrukturen, og sikkerhetskopier er langt enklere å vedlikeholde og administrere. Ved å avlaste filtjenester til en allerede innkjøpt NAS-enhet kan dette redusere filtjenestebehovene fra virtualiseringsinfrastrukturen, både ved å redusere antallet virtuelle maskiner som må kjøres der, samt ved å flytte det som typisk er en av de største brukerne av lagring til en separat enhet, noe som kan senke ytelseskravene til virtualiseringsinfrastrukturen samt dens kapasitetskrav. Ved å gjøre dette reduserer vi potensielt kostnaden ved å anskaffe nødvendige ekstra harddisker for lokal lagring på beregningsnodene som vi nevnte tidligere, og dette kan dermed være en svært populær metode for mange selskaper for å adressere gjenbruksbehovene.

Hvert selskap er unikt og det er potensielt mange steder der reservelagringsutstyr kan brukes effektivt, fra laboratorier til arkiver til lagring i nivåer. Å bruke litt kreativitet og tenke utenfor boksen kan utnyttes til å ta ditt unike sett med tilgjengelig utstyr og virksomhetens unike sett med behov og krav og finne det beste stedet å bruke dette utstyret der det er frakoblet fra kjerne, kritisk virtualiseringsinfrastruktur, men likevel kan bringe verdi til organisasjonen. Ved å unngå den omvendte pyramid of doom kan vi oppnå maksimal verdi fra utstyret vi allerede har investert i, i stedet for å implementere fersk teknisk gjeld som vi deretter må arbeide oss gjennom unødvendig.