De omgekeerde piramide des onheils

Het 3-2-1-model van systeemarchitectuur is tegenwoordig uiterst gangbaar en bijna altijd precies het tegenovergestelde van wat een bedrijf nodig heeft of zelfs wil, als het de tijd zou nemen om zijn bedrijfsdoelen op te schrijven in plaats van een architectuur vanuit een technology-first-perspectief te benaderen. Het ontwerpen van een oplossing vereist dat men begint met de bedrijfseisen; anders lopen we niet alleen het risico dat de architectuur ongeschikt voor het bedrijf wordt ontworpen, maar mogen we dat zelfs verwachten.

De naam verwijst naar drie (dit is een soepel punt; het zijn vaak er twee of meer) redundante virtualisatiehostservers die verbonden zijn met twee (of mogelijk meer) redundante switches, die verbonden zijn met één enkel opslagapparaat, normaal gesproken een SAN (maar DAS of NAS zijn hier ook geldig). Het is een omgekeerde piramide omdat het deel dat ertoe doet, de virtualisatiehosts, volledig afhankelijk is van het netwerk, dat op zijn beurt volledig afhankelijk is van de ene SAN of een alternatief opslagapparaat. Alles rust dus op één enkel apparaat dat een single point of failure vormt, en alle bescherming en redundantie wordt steeds verder bovenop dat broze fundament gebouwd. Anders dan een echte piramide met een breed, stabiel grondvlak en een punt bovenaan, is deze gebouwd met alle zwakte onderaan. (Vaak komt hier het marketingmodel van de ‘eenhoornscheten’ naar voren — “SAN's zijn magisch en kunnen niet falen dankzij dubbele controllers” — wanneer mensen proberen uit te leggen waarom dit geen single point of failure is, maar het is in alle opzichten een single point of failure.)

De oplossing, vaak een 3-2-1-ontwerp genoemd, kan dus ook de “omgekeerde piramide des onheils” worden genoemd, omdat het een ondersteboven gekeerde piramide is die te broos is om te draaien en buitensporig duur is voor wat hij oplevert. Anders dan veel andere broze modellen is hij dus zeer kostbaar, niet erg flexibel en niet zo betrouwbaar als simpelweg niets doen behalve over één enkele kwaliteitsserver beschikken.

Er zijn momenten waarop een 3-2-1 zinvol is, maar dit zijn vooral extreme uitzonderingsgevallen waarin een broze omgeving gewenst is en er behoefte is aan hoge niveaus van gedeelde opslag met enorme verwerkingscapaciteit — geen dingen die je in de mkb-wereld zou zien en die elders zeer zelden voorkomen.

De omgekeerde piramide oogt geweldig voor mensen die zich niet bewust zijn van de volledige architectuur, zoals managers en bedrijfsmensen. Er zijn veel kasten, veel kabels, en er zijn doorgaans softwarecomponenten met het label “HA” die het voor de buitenstaander doen klinken alsof de hele oplossing wel zeer betrouwbaar moet zijn. Omgekeerde piramides zijn populair omdat ze vanuit marketingoogpunt “HA” bieden, waardoor alles prachtig klinkt, en omdat ze de totale kosten binnen de perken houden, zodat het bijna een wonder lijkt — beloften van hoge beschikbaarheid zonder de traditionele kosten. De extra “redundantie” van een aantal van de componenten is geweldig voor de marketing. Aangezien betrouwbaarheid moeilijk te meten is, nemen zowel bedrijfsmensen als technici vaak hun toevlucht tot het spreken over redundantie in plaats van betrouwbaarheid, omdat redundantie eenvoudig te zien is. De omgekeerde piramide spreekt deze mensen goed aan omdat hij redundantie biedt zonder betrouwbaarheid. De redundantie zit niet op de plek waar die het meest van belang is. Het is absoluut cruciaal om te onthouden dat redundantie geen vinkje is en evenmin een doel; het is een hulpmiddel om verbeteringen in de betrouwbaarheid te bereiken. Onjuiste redundantie heeft geen waarde. Wat heb je aan een auto met een redundant stuur in de kofferbak? Wat heb je aan een redundant vliegtuig als je sterft wanneer het eerste neerstort? Wat heb je aan een redundante server als je bedrijf plat ligt en de gegevens verloren zijn toen de ene SAN in rook opging?

De omgekeerde piramide is een van de meest in het oog springende en alomtegenwoordige voorbeelden van “De nieuwe kleren van de keizer” in de technologieverkoop. Omdat hij voorziet in de behoeften van de resellers en leveranciers door verkopen met een hoge marge te bevorderen en die met een lage marge te minimaliseren, en omdat vrijwel elke leverancier hem promoot vanwege de financiële voordelen voor de verkoper, is hij algemeen aanvaard als een uitstekende oplossing. Hij is namelijk net ingewikkeld en technisch genoeg dat er geen brede afwijzing plaatsvindt, en door de enorme marktdruk vanuit het brede scala aan leveranciers dat van de architectuur profiteert, is hij de status quo geworden en stoppen weinig mensen om zich af te vragen of de hele architectuur enige waarde heeft. Dat, gecombineerd met het feit dat alle systemen tegenwoordig zeer betrouwbaar zijn vergeleken met systemen van slechts tien jaar geleden, waardoor storingen zeldzaam genoeg zijn dat het feit dat ze vaker voorkomen dan zou mogen en dat statistische faalpercentages niet tussen mkb-bedrijven worden gedeeld, betekent dat de architectuur floreert en de facto het standaardoplossingsgeheel voor de meeste mkb-bedrijven is geworden.

De kern van de zaak is dat de benadering met de omgekeerde piramide nergens op slaat — hij is veel onbetrouwbaarder dan eenvoudigere oplossingen, zelfs dan slechts één enkele server die op zichzelf staat, terwijl hij vele malen meer kost. Als kosten een belangrijke drijfveer zijn, moet hij volledig worden uitgesloten. Als betrouwbaarheid een belangrijke drijfveer is, moet hij volledig worden uitgesloten. Alleen als kosten en betrouwbaarheid een zeer ondergeschikte rol spelen ten opzichte van flexibiliteit, zou hij überhaupt op tafel moeten komen, en zelfs dan is het zeldzaam dat een goedkopere, betrouwbaardere oplossing er niet aan tippen kan in algehele flexibiliteit binnen de verwachte reikwijdte van flexibiliteit. Hij kan het best volledig vermeden worden.

Oorspronkelijk in verkorte vorm gepubliceerd op Spiceworks: http://community.spiceworks.com/topic/312493-the-inverted-pyramid-of-doom