अपने इनवर्टेड पिरामिड ऑफ डूम का सर्वोत्तम उपयोग कैसे करें

3-2-1 या इनवर्टेड पिरामिड ऑफ डूम आर्किटेक्चर कई कारणों से IT उद्योग में बदनाम हो चुकी है। दुर्भाग्यवश, कई कंपनियों को इस डिज़ाइन से जुड़े खतरों का पता तब चलता है जब उपकरण आ चुके होते हैं और पैसा खातों से जा चुका होता है।

कुछ कंपनियाँ भाग्यशाली होती हैं और इस गलती को इतनी जल्दी पकड़ लेती हैं कि वे अपनी खरीदारी वापस कर सकती हैं और नए hardware और software की खरीद से पहले एक उचित डिज़ाइन और निर्णय चरण के साथ फिर से शुरुआत कर सकती हैं। हालाँकि, यह एक आदर्श और बहुत दुर्लभ स्थिति है। अधिक से अधिक हम आमतौर पर restocking fees की उम्मीद कर सकते हैं और, बहुत अधिक सामान्यतः, उपकरण बिल्कुल भी वापस नहीं किया जा सकता या fees इतनी अधिक होती हैं कि यह बेकार हो जाता है।

अधिकांश कंपनियों के सामने आगे बढ़ते हुए स्थिति का "सर्वोत्तम उपयोग" करने की जरूरत होती है। सबसे बड़ी चिंताओं में से एक यह है कि संबंधित पक्ष — चाहे वे वित्तीय हितधारक हों जिन्होंने नए hardware पर बहुत पैसा खर्च किया है, या तकनीकी हितधारक जो अब इस उपकरण को खरीदे जाने देने के लिए बुरे दिखते हैं — sunk cost fallacy के आगे झुककर भावनात्मक प्रतिक्रिया का शिकार हो जाते हैं। यह अत्यंत महत्वपूर्ण है कि इस भावनात्मक, अतार्किक प्रतिक्रिया को जड़ पकड़ने न दिया जाए क्योंकि यह महत्वपूर्ण निर्णय लेने को कमजोर कर देगी।

यह समझना आवश्यक है कि इनवर्टेड पिरामिड ऑफ डूम पर खर्च किया गया पैसा पहले ही खर्च हो चुका है और जा चुका है। पैसा बर्बाद हुआ या कितना बर्बाद हुआ यह इस बिंदु पर निर्णय लेने के लिए अप्रासंगिक है। चाहे system उपहार में मिला हो या उस पर एक अरब डॉलर खर्च हुए हों, कोई फर्क नहीं पड़ता, वह पैसा जा चुका है और अब हमें जो है उससे काम चलाना होगा। यहाँ एक संभावित "तरकीब" यह होगी कि किसी वित्तीय निर्णय निर्माता जैसे CFO को बुलाएं, समझाएं कि पहले से खर्च हुए पैसे पर भावनात्मक प्रतिक्रिया होने वाली है और वास्तविक समस्या के बारे में बात करने से पहले sunk cost fallacy पर चर्चा करें ताकि लोग जागरूक और तार्किक रहें और जिस व्यक्ति को (हम उम्मीद करते हैं) इस तरह की स्थिति को सर्वोत्तम तरीके से संभालने के लिए प्रशिक्षित किया गया है, वह वहाँ हो और sunk cost भावनाओं को रोकने के लिए तैयार हो। संभावित रूप से भावनात्मक प्रतिक्रिया का सावधानीपूर्वक प्रबंधन महत्वपूर्ण है। यह वित्तीय या तकनीकी गलतियों को छुपाने का प्रयास करने का समय नहीं है, जो भावनात्मक प्रतिक्रिया उत्पन्न कर रही है। सभी पक्षों के लिए संवाद करना और जरूरतों को पूरा करने के लिए तटस्थ और तार्किक रहना आवश्यक है। कुछ कंपनियाँ इसे अच्छी तरह संभालती हैं, कई नहीं संभालती और पहले से की गई बुरी निर्णयों के साथ आगे बढ़ने की कोशिश में फंस जाती हैं, शायद इस उम्मीद में कि कुछ बुरा न हो और कोई याद न रखे या न देखे। उस प्रतिक्रिया से लड़ें। सभी के पास यह होती है, यह प्राकृतिक amygdala "fight or flight" भावनात्मक प्रतिक्रिया है।

अब जब हम समस्या की भावनात्मक प्रतिक्रियाओं से लड़ने के लिए तैयार हैं तो हम "आगे कहाँ जाएं" को संबोधित करना शुरू कर सकते हैं। अच्छी खबर यह है कि हम जहाँ हैं वह आम तौर पर "बहुत कम" के बजाय "बहुत अधिक" होने की स्थिति है। तो हमारे पास थोड़ा रचनात्मक होने का अवसर है। सौभाग्य से आम तौर पर अच्छे विकल्प होते हैं जो हमें कई दिशाओं में आगे बढ़ने की अनुमति दे सकते हैं।

एक बात जो नोट करना बहुत महत्वपूर्ण है वह यह है कि हम विशेष रूप से ऐसे समाधान देख रहे हैं जो हम जिस इनवर्टेड पिरामिड ऑफ डूम आर्किटेक्चर को बदल रहे हैं उससे अधिक विश्वसनीय हैं, कम नहीं। एक IPOD एक बहुत नाजुक और खतरनाक डिज़ाइन है और हम risk analysis, single points of failure, false redundancy की भ्रांतियाँ, reliability के बजाय redundancy देखना, dependency chains आदि जैसी अवधारणाओं को प्रदर्शित करने में बहुत समय लगा सकते हैं, लेकिन सभी पक्षों के लिए जो बिल्कुल महत्वपूर्ण है वह यह है कि local storage के साथ चलने वाला एक single server पूरे IPOD infrastructure से अधिक विश्वसनीय है। यह इतना महत्वपूर्ण है कि इसे फिर से कहना होगा: यदि एक single server "standard availability" है, तो IPOD उससे नीचे है। अधिक जोखिम भरा। यदि इस चरण में कोई भी परिणामी समाधानों में "redundancy की कमी" या "complexity की कमी" से डरता है तो हमें इस पर वापस आना होगा — जो भी हम चर्चा करेंगे वह उतना जोखिम भरा नहीं है जितना पहले से डिज़ाइन और खरीदा गया था। यदि आगे जाने पर जोखिम का कोई डर है, तो डर design की reliability में सुधार करने से पहले और भी अधिक होना चाहिए था। इसे अतिरंजित नहीं किया जा सकता। IPOD बिकते हैं क्योंकि वे आसानी से उन लोगों को भ्रमित करते हैं जो risk analysis में प्रशिक्षित नहीं हैं और विश्वसनीय दिखते हैं जबकि वास्तव में, वे कुछ भी नहीं हैं।

उपरोक्त को समझना और स्वीकृत IPOD आर्किटेक्चर को "reading back" नामक तकनीक का उपयोग करके हमें बताता है कि प्रश्नवाचक कंपनी IPOD खरीदते समय high availability (या standard availability भी) न होने के लिए स्वीकार्य थी। शायद उन्हें विश्वास था कि उन्हें वह मिल रहा है, लेकिन आर्किटेक्चर इसे प्रदान नहीं कर सकती थी और इसलिए आगे बढ़ते हुए हमारे पास अपने स्वयं के local storage पर चलने वाले एक single server से अधिक कुछ नहीं के साथ "काम चलाने" का विकल्प है। यह सरल और आसान है और इच्छित IPOD डिज़ाइन के लगभग हर पहलू में सुधार करता है। इसे चलाने और बनाए रखने में कम लागत आती है, अक्सर तेज़ होता है और थोड़ा अधिक विश्वसनीय होते हुए बहुत कम जटिल होता है।

लेकिन संभवतः केवल एक single server पर आना और खरीदे गए बाकी उपकरण के लिए "कहीं और" उपयोग खोजने की उम्मीद करना हमारा सबसे अच्छा विकल्प नहीं होगा। उन स्थितियों में जहाँ IPOD का उद्देश्य केवल एक workload या workloads के समूह के लिए उपयोग किया जाना था और व्यवसाय के अन्य क्षेत्रों को भी उपकरण की आवश्यकता है, इच्छित IPOD workload के लिए "single server" दृष्टिकोण अपनाना और व्यवसाय में अन्य जगहों पर शेष उपकरण का उपयोग करना बहुत फायदेमंद हो सकता है।

IPOD stack को repurpose करने के लिए सबसे सामान्य दृष्टिकोण दो (या अधिक) compute nodes को अपने स्वयं के storage वाले full stack nodes के रूप में पुनः configure करना है। इस चरण में कोई खरीदारी की आवश्यकता नहीं हो सकती है, यह इस पर निर्भर करता है कि पहले से क्या storage खरीदी गई है, systems के बीच drives का स्थानांतरण हो सकता है या अक्सर इस उद्देश्य के लिए अतिरिक्त hard drives की अपेक्षाकृत छोटी खरीद हो सकती है।

इन nodes को फिर दो high availability models में से एक में configure किया जा सकता है। पहले, लागत कारणों से, एक सामान्य डिज़ाइन विकल्प एक asynchronous replication model (जिसे अक्सर Veeam approach के रूप में जाना जाता है) का उपयोग करना था जो nodes के बीच virtual machines को replicate करेगा और VMs को बहुत तेज़ी से power up करने की अनुमति देगा जिससे compute node failure के क्षण से लेकर recovery तक केवल कुछ मिनटों का downtime होगा।

आज पूरी तरह से synchronous fault tolerance इतनी सामान्यतः मुफ्त में उपलब्ध है कि इसने लगभग सभी मामलों में asynchronous model को प्रभावी रूप से बदल दिया है। इस model में storage को compute nodes के बीच पूरी तरह से real time में replicate किया जाता है जिससे failover कुछ मिनटों की देरी के बजाय तुरंत हो सकता है, और एक छोटी data loss window के बजाय शून्य data loss के साथ (जैसे RPO of zero)।

इस बिंदु पर यह सामान्य लगता है कि लोग replication से storage capacity के नुकसान के डर से प्रतिक्रिया करते हैं जो replication के कारण होती है। बेशक यह सच है। यह समझना आवश्यक है कि यही replication, जो मूल IPOD डिज़ाइन में अनुपस्थित थी, high reliability के लिए मजबूत आधार प्रदान करती है। यदि इस replication को छोड़ दिया जाए, तो high availability एक अप्राप्य स्वप्न है और local storage का उपयोग करने वाले individual compute nodes "stand alone" mode में सबसे विश्वसनीय संभावित विकल्प हैं। High availability solutions आवश्यक reliability बनाने के लिए replication और redundancy पर निर्भर करते हैं जो high availability के लिए qualify करती है।

यह हमारे compute nodes के साथ क्या करें इस प्रश्न को हल करता है लेकिन हमें यह छोड़ देता है कि हम अपने external shared storage device के साथ क्या कर सकते हैं, single point of failure या inverted pyramid डिज़ाइन का "point"। इस प्रश्न का उत्तर देने के लिए हमें यह देखना शुरू करना चाहिए कि यह storage क्या हो सकती है।

तीन सामान्य प्रकार के storage devices हैं जो inverted pyramid डिज़ाइन में उपयोग किए जाएंगे: DAS, SAN और NAS। हम DAS और SAN को एक साथ जोड़ सकते हैं क्योंकि वे दोनों block storage के दो अलग-अलग पहलू हैं और हमारी चर्चा में अनिवार्य रूप से एक दूसरे के स्थान पर उपयोग किए जा सकते हैं — वे केवल switching के अस्तित्व से अलग होते हैं जिसे हमारे designs में आवश्यकतानुसार जोड़ा या हटाया जा सकता है। NAS इससे भिन्न है क्योंकि यह block storage के बजाय file storage है।

दोनों मामलों में, block (DAS या SAN) या file (NAS) storage के लिए इस अब अनावश्यक device के सबसे सामान्य उपयोगों में से एक हमारे नए virtualization infrastructure के लिए backup target के रूप में है। कई मामलों में device इस कार्य के लिए overkill हो सकती है, आम तौर पर एक simple backup target के लिए आवश्यक से अधिक performance और कई अधिक features के साथ, लेकिन किसी भी महत्वपूर्ण business infrastructure के लिए अच्छी backup storage महत्वपूर्ण है और overkill की तरफ गलती करना जरूरी नहीं बुरी बात है। Businesses अक्सर अपने backup infrastructures पर कंजूसी करने की कोशिश करते हैं और यह बिना अतिरिक्त पैसा खर्च किए उसमें भारी निवेश करने का अवसर है।

Backup storage के समान ही, external storage device को archival storage या storage के अन्य "lower tier" के रूप में repurpose किया जा सकता है जहाँ high availability warranted नहीं है। यह एक कम सामान्य दृष्टिकोण है, आम तौर पर इसलिए क्योंकि हर business को एक अच्छे backup system की जरूरत है लेकिन केवल कुछ के पास ही archival storage tier का लाभ उठाने का तरीका है।

इन दो सामान्य और universal storage models से परे, external storage devices के लिए एक सामान्य use case, विशेष रूप से यदि device एक NAS है, इसे virtualization infrastructure से अलग file server के रूप में इसकी native role में leverage करना है। कई businesses के लिए file serving core virtualization infrastructure जितनी uptime critical नहीं है और backups बनाए रखना और manage करना बहुत आसान है। पहले से खरीदी गई NAS device पर file serving को offload करके यह virtualization infrastructure से file serving requirements को कम कर सकता है, VMs की संख्या को कम करके जो वहाँ run करने की आवश्यकता है और साथ ही आमतौर पर storage के सबसे बड़े उपयोगकर्ताओं में से एक को एक अलग device पर ले जाकर जो virtualization infrastructure की performance requirements के साथ-साथ इसकी capacity requirements को कम कर सकता है। ऐसा करने से हम संभावित रूप से compute nodes पर local storage के लिए आवश्यक अतिरिक्त hard drives प्राप्त करने की लागत को कम करते हैं जैसा हमने पहले बताया था और इसलिए यह कई कंपनियों के लिए repurposing needs को address करने का एक बहुत लोकप्रिय तरीका हो सकता है।

प्रत्येक कंपनी अनोखी है और संभावित रूप से कई जगह हैं जहाँ spare storage equipment का प्रभावी ढंग से उपयोग किया जा सकता है labs से archives से tiered storage तक। थोड़ी रचनात्मकता का उपयोग करके और box के बाहर सोचकर आप अपने उपलब्ध उपकरण के अनोखे सेट और अपने business की अनोखी जरूरतों और मांगों को leverage कर सकते हैं और उस उपकरण के लिए सबसे अच्छी जगह ढूंढ सकते हैं जहाँ यह core, critical virtualization infrastructure से decoupled है लेकिन फिर भी organization को value ला सकता है। Inverted pyramid of doom से बचकर हम उस उपकरण से अधिकतम मूल्य प्राप्त कर सकते हैं जिसमें हम पहले से निवेश कर चुके हैं, बजाय fresh technical debt implement करने के जिसे हमें फिर अनावश्यक रूप से overcome करने के लिए काम करना होगा।