Den omvända pyramiden av undergång

3-2-1-modellen för systemarkitektur är extremt vanlig idag och nästan alltid raka motsatsen till vad en verksamhet behöver eller ens önskar om de tog sig tiden att skriva ner sina affärsmål i stället för att närma sig en arkitektur ur ett teknikfokuserat perspektiv. Att utforma en lösning kräver att man utgår från affärskrav, annars riskerar vi inte bara att arkitekturen blir olämpligt utformad för verksamheten, utan vi bör snarare förvänta oss det.

Namnet syftar på tre (detta är en flytande punkt, det är ofta två eller fler) redundanta virtualiseringsvärdservrar anslutna till två (eller potentiellt fler) redundanta switchar anslutna till en enda lagringsenhet, vanligtvis ett SAN (men DAS eller NAS är giltiga här också). Det är en omvänd pyramid eftersom den del som har betydelse, virtualiseringsvärdarna, är helt beroende av nätverket som i sin tur är helt beroende av det enda SAN:et eller den alternativa lagringsenheten. Så allt vilar på en enskild felkälla (single point of failure) och allt skydd och all redundans byggs mer och mer ovanpå den ömtåliga grunden. Till skillnad från en riktig pyramid med en bred, stabil bas och en spets på toppen är denna byggd med all svaghet i botten. (Ofta dyker marknadsföringsmodellen om ‘enhörningsfjärtar’ – “SAN:er är magiska och kan inte haverera tack vare dubbla styrenheter” – upp här när folk försöker förklara hur detta inte är en enskild felkälla, men det är en enskild felkälla i alla bemärkelser.)

Så lösningen, som ofta kallas en 3-2-1-design, kan också kallas “Den omvända pyramiden av undergång” eftersom det är en uppochnervänd pyramid som är alltför ömtålig för att köras och extremt dyr i förhållande till vad som levereras. Så till skillnad från många andra ömtåliga modeller är den mycket kostsam, inte särskilt flexibel och inte lika tillförlitlig som att helt enkelt inte göra något utöver att ha en enda kvalitetsserver.

Det finns tillfällen då en 3-2-1 är vettig, men oftast är dessa extrema gränsfall där en ömtålig miljö är önskvärd och höga nivåer av delad lagring med massiv processorkapacitet behövs – inte sådant man skulle se i SMB-världen och mycket sällan någon annanstans.

Den omvända pyramiden ser fantastisk ut för dem som inte är medvetna om hela arkitekturen, såsom chefer och affärsfolk. Det finns många lådor, många kablar, det finns vanligtvis mjukvarukomponenter som är märkta “HA” vilket för den utomstående betraktaren får det att låta som att hela lösningen måste vara mycket tillförlitlig. Omvända pyramider är populära eftersom de erbjuder “HA” ur ett marknadsföringsperspektiv som får allt att låta underbart, och de håller den totala kostnaden inom rimliga gränser så att det nästan verkar som ett mirakel – löften om hög tillgänglighet utan de traditionella kostnaderna. Den extra “redundansen” hos vissa av komponenterna är utmärkt för marknadsföring. Eftersom tillförlitlighet är svårt att mäta tar affärsfolk och tekniker likväl ofta till att tala om redundans i stället för tillförlitlighet eftersom det är lätt att se redundans. Den omvända pyramiden tilltalar dessa personer väl eftersom den tillhandahåller redundans utan tillförlitlighet. Redundansen finns inte där den betyder mest. Det är absolut avgörande att komma ihåg att redundans inte är en kryssruta, och redundans är inte heller ett mål, det är ett verktyg att använda för att uppnå förbättringar i tillförlitlighet. Felaktig redundans har inget värde. Vad är nyttan med en bil med en redundant ratt i bagageutrymmet? Vad är nyttan med ett redundant flygplan om du dör när det första kraschar? Vad är nyttan med en redundant server om din verksamhet ligger nere och datan är förlorad när det enda SAN:et gick upp i rök?

Den omvända pyramiden är ett av de mest uppenbara och allestädes närvarande exemplen på “Kejsarens nya kläder” som används inom teknikförsäljning. Eftersom den uppfyller återförsäljarnas och leverantörernas behov genom att främja försäljning med hög marginal och minimera sådan med låg marginal, och eftersom nästan varje leverantör marknadsför den på grund av dess ekonomiska fördelar för säljaren, har den blivit allmänt accepterad som en utmärkt lösning eftersom den är precis tillräckligt komplicerad och teknisk för att utbrett avståndstagande inte ska uppstå, och med det enorma marknadstryck från den stora skaran leverantörer som drar nytta av arkitekturen har den blivit status quo, och få personer stannar upp och ifrågasätter om hela arkitekturen har någon förtjänst alls. Detta, i kombination med det faktum att alla system idag är mycket tillförlitliga jämfört med system från bara ett decennium sedan, vilket gör att fel är tillräckligt ovanliga för att det faktum att de är vanligare än de borde vara, och att statistiska felfrekvenser inte delas mellan SMB-företag, innebär att arkitekturen frodas och har blivit den de facto-lösning för de flesta SMB-företag.

Slutsatsen är att den omvända pyramid-ansatsen inte är vettig – den är långt mindre tillförlitlig än enklare lösningar, till och med bara en enda server som står på egna ben, samtidigt som den kostar många gånger mer. Om kostnad är en nyckelfaktor bör den uteslutas helt. Om tillförlitlighet är en nyckelfaktor bör den uteslutas helt. Endast om kostnad och tillförlitlighet får ta en mycket undanskymd plats i förhållande till flexibilitet bör den ens läggas på bordet, och även då är det sällsynt att en lösning med lägre kostnad och högre tillförlitlighet inte matchar den i total flexibilitet inom det förväntade flexibilitetsomfånget. Den är bäst att undvika helt och hållet.

Ursprungligen publicerad på Spiceworks i förkortad form: http://community.spiceworks.com/topic/312493-the-inverted-pyramid-of-doom