Den omvendte dommedagspyramide

3-2-1-modellen for systemarkitektur er ekstremt udbredt i dag og er næsten altid det stik modsatte af, hvad en virksomhed har brug for eller endog ønsker, hvis de tog sig tid til at nedskrive deres forretningsmål frem for at tilgå en arkitektur fra et teknologi-først-perspektiv. At designe en løsning kræver, at man starter med forretningskravene; ellers risikerer vi ikke blot, at arkitekturen er uhensigtsmæssigt designet til virksomheden – vi bør forvente det.

Navnet refererer til tre (dette er et blødt punkt; det er ofte to eller flere) redundante virtualiseringshost-servere tilsluttet to (eller potentielt flere) redundante switches tilsluttet en enkelt lagerenhed, normalt en SAN (men DAS eller NAS er også gyldige her). Det er en omvendt pyramide, fordi den del, der betyder noget – virtualiseringshost-serverne – er fuldstændig afhængige af netværket, som igen er fuldstændig afhængigt af den enkelte SAN eller alternative lagerenhed. Så alt hviler på en enkelt fejlpunkts-enhed, og al beskyttelse og redundans er bygget mere og mere oven på dette skrøbelige fundament. I modsætning til en ordentlig pyramide med en bred, stabil base og en spids på toppen, er denne bygget med al svagheden i bunden. (Ofte kommer ‘einhornsprutserne’-marketingmodellen om “SAN'er er magiske og kan ikke fejle på grund af dobbelte controllere” frem, når folk forsøger at forklare, hvorfor dette ikke er et enkelt fejlpunkt – men det er et enkelt fejlpunkt i enhver forstand.)

Så løsningen, der ofte kaldes et 3-2-1-design, kan også kaldes “Den omvendte dommedagspyramide”, fordi det er en omvendt pyramide, der er for skrøbelig til at drive og ekstremt dyr for det, den leverer. I modsætning til mange andre skrøbelige modeller er den altså meget kostbar, ikke særligt fleksibel og ikke så pålidelig som simpelthen at have en enkelt kvalitetsserver.

Der er tidspunkter, hvor et 3-2-1-setup giver mening, men disse er for det meste ekstreme kanttilfælde, hvor et skrøbeligt miljø er ønsket, og høje niveauer af delt lagring med massive behandlingskapaciteter er nødvendige – ikke noget man ville se i SMB-verdenen og meget sjældent andre steder.

Den omvendte pyramide ser fantastisk ud for folk, der ikke er bekendt med den samlede arkitektur, såsom ledere og forretningsmæssige interessenter. Der er mange bokse, mange kabler, der er typisk softwarekomponenter mærket “HA”, som for den udenforstående observer lyder som om, at hele løsningen må være meget pålidelig. Omvendte pyramider er populære, fordi de tilbyder “HA” fra et marketingperspektiv og får alt til at lyde vidunderligt, og de holder den samlede omkostning inden for rimelighedens rammer, så det næsten virker som et mirakel – løfter om høj tilgængelighed uden de traditionelle omkostninger. Den yderligere “redundans” i nogle af komponenterne er god for markedsføringen. Da pålidelighed er vanskelig at måle, tyer forretningsmæssige og tekniske folk ofte til at tale om redundans i stedet for pålidelighed, da det er let at se redundans. Den omvendte pyramide taler godt til disse mennesker, da den giver redundans uden pålidelighed. Redundansen er ikke der, hvor den betyder mest. Det er absolut afgørende at huske, at redundans ikke er en afkrydsningsboks, og redundans er ikke et mål – det er et værktøj til at opnå pålidelhedsforbedringer. Ukorrekt redundans har ingen værdi. Hvad nytter en bil med et redundant rat i bagagerummet? Hvad nytter et redundant fly, hvis du dør, når det første styrter ned? Hvad nytter en redundant server, hvis din virksomhed er nede og data tabt, da den enkle SAN gik op i røg?

Den omvendte pyramide er et af de mest åbenlyse og allestedsnærværende eksempler på “Kejserens nye klæder” brugt i teknologisalg. Fordi det opfylder behovene hos forhandlere og leverandører ved at fremme salg med høj margen og minimere dem med lav margen, og fordi næsten enhver leverandør fremmer det på grund af dets finansielle fordele for sælgeren, er det blevet bredt accepteret som en god løsning, fordi det er akkurat kompliceret og teknisk nok til, at udbredt afvisning ikke forekommer, og det enorme markedspres fra den store vifte af leverandører, der drager fordel af arkitekturen, har gjort det til status quo. Få stopper op og spørger, om hele arkitekturen har nogen merit. Hertil kommer, at alle systemer i dag er meget pålidelige sammenlignet med systemer fra blot et årti siden, hvilket medfører, at fejl er sjældne nok til, at det faktum, at de er hyppigere end de burde være, og at statistiske fejlrater ikke deles mellem SMB'er, betyder, at arkitekturen trives og er blevet de-facto-løsningssættet for de fleste SMB'er.

Konklusionen er, at den omvendte pyramide-tilgang ikke giver mening – den er langt mere upålidelig end enklere løsninger, selv blot en enkelt server stående alene, og koster mange gange mere. Hvis omkostninger er en central drivkraft, bør den udelukkes fuldstændigt. Hvis pålidelighed er en central drivkraft, bør den udelukkes fuldstændigt. Kun hvis omkostninger og pålidelighed tager meget langt bagud i forhold til fleksibilitet, bør den overhovedet komme på bordet, og selv da er det sjældent, at en lavere omkostning og mere pålidelig løsning ikke matcher den i samlet fleksibilitet inden for det forventede omfang af fleksibilitet. Den undgås bedst fuldstændigt.

Oprindeligt udgivet på Spiceworks i forkortet form: http://community.spiceworks.com/topic/312493-the-inverted-pyramid-of-doom