विनाश का उल्टा पिरामिड

System architecture का 3-2-1 model आज अत्यंत सामान्य है और लगभग हमेशा उस business की ज़रूरतों के बिल्कुल विपरीत होता है जो वे चाहते या चाहते यदि वे technology-first perspective से architecture को approach करने की बजाय अपने business goals लिखने का समय लेते। एक solution design करने के लिए business requirements से शुरू करना ज़रूरी है, अन्यथा हम न केवल architecture के business के लिए inappropriately designed होने का जोखिम उठाते हैं बल्कि इसकी expect करते हैं।

नाम तीन (यह एक soft point है, यह अक्सर दो या अधिक होते हैं) redundant virtualization host servers को संदर्भित करता है जो दो (या potentially अधिक) redundant switches से connect हैं जो एक single storage device से connected हैं, normally एक SAN (लेकिन DAS या NAS भी यहाँ valid हैं)। यह एक inverted pyramid है क्योंकि जो matter करता है, virtualization hosts, completely network पर depend करते हैं जो, बदले में, completely single SAN या alternative storage device पर depend करता है। इसलिए सब कुछ एक single point of failure device पर टिका है और सारी protection और redundancy उस fragile foundation के ऊपर बनाई गई है। एक proper pyramid के विपरीत जिसका एक wide, stable base है और ऊपर एक point है, यह सारी कमज़ोरी को नीचे रखकर बना है। (अक्सर SANs के “unicorn farts” marketing model “SANs जादुई हैं और dual controllers की वजह से fail नहीं हो सकते” यहाँ सामने आता है जब लोग यह explain करने की कोशिश करते हैं कि यह single point of failure नहीं है, लेकिन यह हर sense में single point of failure है।)

तो solution, जिसे अक्सर 3-2-1 design कहा जाता है, को “Inverted Pyramid of Doom” भी कहा जा सकता है क्योंकि यह एक उल्टा pyramid है जो run करने के लिए बहुत fragile है और जो deliver किया जाता है उसके लिए अत्यधिक महंगा है। इसलिए कई अन्य fragile models के विपरीत, यह बहुत costly है, बहुत flexible नहीं है और simply एक single quality server रखने से भी कम reliable है।

ऐसे समय होते हैं जब 3-2-1 sense बनाता है, लेकिन ज़्यादातर ये extreme edge cases हैं जहाँ fragile environment desired है और massive processing capabilities के साथ high levels of shared storage की ज़रूरत है – ऐसी चीज़ें जो आप SMB world में नहीं देखते और कहीं और भी बहुत rare हैं।

Inverted pyramid उन लोगों को अच्छा लगता है जो पूरी architecture से aware नहीं हैं, जैसे managers और business people। बहुत सारे boxes हैं, बहुत सारे wires हैं, typically software components हैं जिन्हें “HA” label किया गया है, जो outside observer को लगता है कि पूरा solution highly reliable होना चाहिए। Inverted Pyramids लोकप्रिय हैं क्योंकि वे marketing perspective से “HA” offer करते हैं जो सब कुछ wonderful लगाता है और वे overall cost को reasonable range में रखते हैं इसलिए यह लगभग एक miracle लगता है – traditional costs के बिना High Availability promises। कुछ components की additional “redundancy” marketing के लिए great है। जैसा कि reliability को measure करना मुश्किल है, business people और technical people दोनों अक्सर reliability की बजाय redundancy की बात करते हैं क्योंकि redundancy आसानी से दिखती है। Inverted pyramid इन लोगों से अच्छी तरह से बात करता है क्योंकि यह reliability के बिना redundancy प्रदान करता है। Redundancy वहाँ नहीं है जहाँ यह सबसे ज़्यादा matter करती है। यह absolutely critical है कि याद रखें कि redundancy एक check box नहीं है और न ही redundancy एक goal है, यह reliability improvements प्राप्त करने के लिए उपयोग करने का एक tool है। Improper redundancy का कोई value नहीं है। Trunk में redundant steering wheel वाली car का क्या फायदा? Redundant aircraft का क्या फायदा जब पहला crash होने पर आप मर जाते हैं? एक redundant server का क्या फायदा यदि single SAN के जलने पर आपका business down है और data lost है?

Inverted pyramid technology sales में उपयोग होने वाले “The Emperor's New Clothes” के सबसे obvious और ubiquitous examples में से एक है। क्योंकि यह resellers और vendors की ज़रूरतों को पूरा करता है high margin sales को promote करके और low margin ones को minimize करके और क्योंकि architecture के financial advantages की वजह से लगभग हर vendor इसे promote करता है, यह widely accepted हो गया है एक great solution के रूप में क्योंकि यह बस इतना complicated और technical है कि widespread repudiation नहीं होती और architecture से benefit करने वाले vendors के विशाल array के incredible market pressure ने इसे status quo बना दिया है और कम लोग रुककर यह question करते हैं कि क्या पूरी architecture में कोई merit है। यह, combined with इस fact के साथ कि आज सभी systems एक दशक पहले के systems की तुलना में highly reliable हैं जिससे failures uncommon हो गई हैं, इस तथ्य को overlook करते हुए कि वे उससे अधिक common हैं जितनी होनी चाहिए और statistical failure rates SMBs के बीच share नहीं होते, इसका मतलब है कि architecture thrive करती है और अधिकांश SMBs के लिए de facto solution set बन गई है।

Bottom line यह है कि Inverted Pyramid approach का कोई sense नहीं है – यह simpler solutions से, यहाँ तक कि simply एक अकेले खड़े single server से भी, far more unreliable है, जबकि कई गुना अधिक खर्चीला है। यदि cost एक key driver है, तो इसे completely rule out किया जाना चाहिए। यदि reliability एक key driver है, तो इसे completely rule out किया जाना चाहिए। केवल तभी जब cost और reliability flexibility के पीछे बहुत दूर हों तो इसे table पर रखा जाए और यहाँ तक कि तब भी यह rare है कि anticipated flexibility के scope के भीतर overall flexibility में एक lower cost, more reliable solution इससे match न करे। इसे altogether avoid करना सबसे अच्छा है।

Originally Spiceworks पर abridged form में published: http://community.spiceworks.com/topic/312493-the-inverted-pyramid-of-doom