At gøre det bedste ud af din omvendte dommedagspyramide

Den 3-2-1 eller omvendte dommedagspyramide-arkitektur er blevet en torn i øjet på IT-branchen af mange årsager. Desværre er det for mange virksomheders vedkommende først, efter at komponenterne er ankommet og pengene har forladt kontiene, at de opdager farerne ved dette design.

Nogle virksomheder er heldige og opdager fejlen tidligt nok til at returnere deres indkøb og starte forfra med en ordentlig design- og beslutningsfase, inden der anskaffes ny hardware og software. Dette er dog en ideel og meget sjælden situation. I bedste fald kan vi normalt forvente returneringsgebyrer og, langt hyppigere, kan udstyret slet ikke returneres, eller gebyrerne er så store, at det er meningsløst.

Det, de fleste virksomheder står over for, er et behov for at "gøre det bedste" ud af situationen fremadrettet. En af de største bekymringer er, at de berørte parter – hvad enten det er de finansielle interessenter, der netop har brugt mange penge på den nye hardware, eller de tekniske interessenter, der nu ser dårlige ud, fordi de tillod dette udstyr at blive købt – bukker under for en følelsesmæssig reaktion og giver efter for den tabte-investering-fejlslutning. Det er afgørende, at denne følelsesmæssige, ulogiske reaktion ikke får fodfæste, da den vil underminere kritisk beslutningstagning.

Det skal forstås, at pengene brugt på den omvendte dommedagspyramide allerede er brugt og er væk. At pengene blev spildt, eller hvor meget der blev spildt, er irrelevant for beslutningstagning på dette tidspunkt. Om systemet var en gave, eller om det kostede en milliard dollars, er ligegyldigt – de penge er væk, og nu må vi klare os med det, vi har. Et potentielt "trick" her kunne være at inddrage en finansiel beslutningstagere som en CFO, forklare, at der er ved at komme en følelsesmæssig reaktion på allerede brugte penge, og diskutere tabte-investering-fejlslutningen, inden man taler om det egentlige problem, så folk er opmærksomme og logiske, og den person, der (forhåbentlig) er bedst trænet til at håndtere denne slags situationer, er til stede og klar til at afværge sunk cost-følelser. Omhyggelig håndtering af en potentielt følelsesdrevet reaktion er vigtig. Dette er ikke tidspunktet til at forsøge at dække over hverken de finansielle eller de tekniske fejltrin, hvilket er præcis, hvad den følelsesmæssige reaktion skaber. Det er nødvendigt, at alle parter kommunikerer og forbliver afkoblede og logiske for at imødekomme behovene. Nogle virksomheder håndterer dette godt, mange gør det ikke og ender med at forsøge at presse videre med dårlige beslutninger, der allerede er truffet – sandsynligvis i håbet om, at intet går galt, og at ingen husker det eller bemærker det. Bekæmp den reaktion. Alle har den – det er den naturlige amygdala-baserede "kæmp eller flygt"-reaktion.

Nu da vi er klar til at bekæmpe de følelsesmæssige reaktioner på problemet, kan vi begynde at adressere "hvor går vi herfra." Den gode nyhed er, at vi generelt befinder os i en position med "for meget" snarere end "for lidt." Vi har altså mulighed for at være lidt kreative. Heldigvis er der generelt gode muligheder, der kan lade os bevæge os i flere retninger.

Noget, der er meget vigtigt at bemærke, er, at vi udelukkende ser på løsninger, der er mere pålidelige, ikke mindre pålidelige, end den tilsigtede omvendte dommedagspyramide-arkitektur, vi erstatter. En IPOD er et meget skrøbeligt og farligt design, og vi kunne bruge megen tid på at demonstrere begreber som risikoanalyse, single points of failure, fejlslutninger om falsk redundans, redundans kontra pålidelighed, afhængighedskæder osv. – men det, der er absolut kritisk for alle parter at forstå, er, at en enkelt server med lokal lagring er mere pålidelig end hele IPOD-infrastrukturen ville være. Dette er så vigtigt, at det skal siges igen: hvis en enkelt server er "standard-tilgængelighed", er IPOD lavere end det. Mere risikabel. Hvis nogen på dette tidspunkt frygter en "mangel på redundans" eller en "mangel på kompleksitet" i de resulterende løsninger, må vi vende tilbage til dette – intet af det, vi vil diskutere, er så risikabelt som det, der allerede var designet og købt. Hvis der er nogen frygt for risiko fremadrettet, burde frygten have været større, inden vi forbedrede pålideligheden af designet. Dette kan ikke understreges nok. IPOD'er sælger, fordi de let forvirrer dem, der ikke er trænet i risikoanalyse, og ser pålidelige ud, når de i virkeligheden er alt andet end det.

At forstå ovenstående og bruge en teknik kaldet "tilbagelæsning" af den accepterede IPOD-arkitektur fortæller os, at den pågældende virksomhed accepterede ikke at have høj tilgængelighed (eller endog standard-tilgængelighed) på tidspunktet for købet af IPOD. Måske troede de, at de fik det, men arkitekturen kunne ikke levere det, og så har vi fremadrettet muligheden for at "klare os" med intet mere end en enkelt server, der kører med sin egen lokale lagring. Dette er simpelt og nemt og forbedrer næsten alle aspekter af det tiltænkte IPOD-design. Det koster mindre at drive og vedligeholde, er ofte hurtigere og er langt mindre komplekst, mens det er lidt mere pålideligt.

Men at blot falde ned til en enkelt server og håbe på at finde anvendelse for resten af det indkøbte udstyr "andre steder" vil sandsynligvis ikke være vores bedste mulighed. I situationer, hvor IPOD'en var tiltænkt at blive brugt til en enkelt arbejdsbyrde eller et sæt arbejdsbyrder, og andre dele af virksomheden også har behov for udstyr, kan det være meget fordelagtigt at gå til "enkeltserver"-tilgangen til den tiltænkte IPOD-arbejdsbyrde og udnytte det resterende udstyr andre steder i virksomheden.

Den mest almindelige tilgang til genanvendelse af en IPOD-stak er at rekonfigurere de to (eller flere) compute-noder til at være full-stack-noder med deres egen lagring. Dette trin kræver måske ingen indkøb, afhængigt af hvilken lagring der allerede er købt, en flytning af drev mellem systemer, eller oftest det relativt lille indkøb af yderligere harddiske til dette formål.

Disse noder kan derefter konfigureres i én af to modeller for høj tilgængelighed. Tidligere var et almindeligt designvalg, af omkostningsårsager, at bruge en asynkron replikeringsmodel (ofte kendt som Veeam-tilgangen), der replikerer virtuelle maskiner mellem noderne og giver mulighed for, at VM'er kan startes meget hurtigt op, hvilket muliggør en nedetid fra det øjeblik, en compute-node fejler, til genopretning på så lidt som blot få minutter.

I dag er fuldt synkron fejltolerance så almindeligt tilgængelig gratis, at den effektivt har erstattet den asynkrone model i næsten alle tilfælde. I denne model replikeres lagring i fuldt realtid mellem compute-noderne, hvilket giver mulighed for øjeblikkelig failover frem for med et par minutters forsinkelse og med nul datatab i stedet for et lille datatabsvindue (f.eks. RPO på nul).

På dette tidspunkt ser det ud til at være almindeligt, at folk reagerer på replikering med en frygt for tab af lagerkapacitet forårsaget af replikeringen. Dette er naturligvis sandt. Det er nødvendigt at forstå, at det er denne replikering, der manglede i det originale IPOD-design, der udgør det faste fundament for høj pålidelighed. Hvis denne replikering springes over, er høj tilgængelighed en uopnåelig drøm, og individuelle compute-noder med lokal lagring i en "standalone"-tilstand er den mest pålidelige potentielle mulighed. Løsninger med høj tilgængelighed er afhængige af replikering og redundans for at opbygge den nødvendige pålidelighed til at kvalificere sig til høj tilgængelighed.

Dette løser spørgsmålet om, hvad vi skal gøre med vores compute-noder, men efterlader os med, hvad vi kan gøre med vores eksterne delte lagerenhed, single point of failure eller "spidsen" af det omvendte pyramidedesign. For at besvare dette spørgsmål bør vi starte med at se på, hvad denne lagring kan være.

Der er tre almindelige typer lagerenheder, der ville blive brugt i et omvendt pyramidedesign: DAS, SAN og NAS. Vi kan gruppere DAS og SAN sammen, da de begge er to forskellige aspekter af bloklagring og kan bruges i det væsentlige udskifteligt i vores diskussion – de adskilles kun ved tilstedeværelsen af switching, som kan tilføjes eller fjernes efter behov i vores designs. NAS adskiller sig ved at være fillagring frem for bloklagring.

I begge tilfælde – blok (DAS eller SAN) eller fil (NAS) – er en af de mest almindelige anvendelser for denne nu overflødige enhed at bruge den som backup-mål for vores nye virtualiseringsinfrastruktur. I mange tilfælde kan enheden være overdreven til denne opgave, generelt med mere ydeevne og mange flere funktioner end nødvendigt for et simpelt backup-mål, men god backup-lagring er vigtig for enhver kritisk forretningsinfrastruktur, og at fejle på siden af overkill er ikke nødvendigvis en dårlig ting. Virksomheder forsøger ofte at spare på deres backup-infrastrukturer, og dette er en mulighed for at investere kraftigt i den uden at bruge ekstra penge.

I samme ånd som backup-lagring kan den eksterne lagerenhed genbruges som arkivlagring eller andet "lavere niveau" af lagring, hvor høj tilgængelighed ikke er begrundet. Dette er en mindre almindelig tilgang, generelt fordi enhver virksomhed har brug for et godt backup-system, men kun nogle har en måde at udnytte et arkivlagringsniveau på.

Ud over disse to almindelige og universelle lagermodeller er en almindelig anvendelse af eksterne lagerenheder, især hvis enheden er en NAS, at udnytte den i sin native rolle som en filserver adskilt fra virtualiseringsinfrastrukturen. For mange virksomheder er filservering ikke så driftskritisk som kernevirtualiseringsinfrastrukturen, og sikkerhedskopier er langt lettere at vedligeholde og administrere. Ved at flytte filservering til en allerede indkøbt NAS-enhed kan dette reducere filserveringskravene fra virtualiseringsinfrastrukturen, dels ved at reducere antallet af VM'er, der skal køres der, og dels ved at flytte det, der typisk er en af de største brugere af lagring, til en separat enhed, hvilket kan sænke ydeevnekravene til virtualiseringsinfrastrukturen såvel som dens kapacitetskrav. Ved at gøre dette reducerer vi potentielt omkostningerne ved at anskaffe nødvendige yderligere harddiske til den lokale lagring på compute-noderne, som vi nævnte tidligere, og dette kan derfor være en meget populær metode for mange virksomheder til at imødekomme genbrugsbehov.

Enhver virksomhed er unik, og der er potentielt mange steder, hvor ekstra lagerudstyr kan bruges effektivt – fra laboratorier til arkiver til lagring i niveauer. Ved at bruge lidt kreativitet og tænke ud af boksen kan man udnytte sit unikke sæt af tilgængeligt udstyr og virksomhedens unikke sæt af behov og krav og finde det bedste sted at bruge dette udstyr, hvor det er afkoblet fra kernen, den kritiske virtualiseringsinfrastruktur, men stadig kan bringe værdi til organisationen. Ved at undgå den omvendte dommedagspyramide kan vi opnå den maksimale værdi fra det udstyr, vi allerede har investeret i, frem for at implementere frisk teknisk gæld, som vi derefter unødvendigt skal arbejde os ud af.