जब कोई redundancy नहीं होना अधिक विश्वसनीय हो – Redundancy का मिथक

Risk एक कठिन अवधारणा है और दिए गए परिदृश्यों का उचित मूल्यांकन करने के लिए बहुत प्रशिक्षण, सोच और विश्लेषण की आवश्यकता होती है। अक्सर, क्योंकि risk assessments इतने कठिन होते हैं, हम risk analysis को केवल basic redundancy जोड़कर और यह मानकर बदल देते हैं कि हमने risk को appropriately कम कर दिया है। लेकिन बहुत बार ऐसा नहीं होता। complexity या अतिरिक्त failure modes का परिचय अक्सर redundancy के अतिरिक्त के साथ आता है और failure के ये नए रूप उतना जोखिम जोड़ने की क्षमता रखते हैं जितना added redundancy हटाती है। Storage systems विशेष रूप से इन decision processes के प्रति prone हैं जो दुर्भाग्यपूर्ण है क्योंकि कुछ, यदि कोई, systems इतने failure के प्रति susceptible और protect करने के लिए अधिक महत्वपूर्ण हैं।

RAID एक अच्छा उदाहरण है जहां holistic risk thinking की कमी कुछ strange decision making की ओर ले जा सकती है। अगर हम एक असामान्य नहीं scenario को देखें तो हम देखेंगे कि drive failure से बचाने का लक्ष्य वास्तव में risk में वृद्धि कर सकता है, यहां तक कि जब अतिरिक्त redundancy लागू की जाती है। इस scenario में हम एक single array में बारह तीन terabyte SATA hard drives वाले बारह drive array की तुलना करेंगे। लोगों को RAID 5 “maximum capacity और performance” पाने के लिए और “failure के विरुद्ध adequate protection” रखते हुए इस scenario के लिए चुनते सुनना असामान्य नहीं है।

यहां विचार यह है कि RAID 5 एक single drive के नुकसान से बचाता है जिसे replace किया जा सकता है और array दूसरी drive के विफल होने से पहले खुद को rebuild करेगा। यह सिद्धांत में बढ़िया है, लेकिन इस size के array के वास्तविक जोखिम, छत्तीस terabyte की drive capacity, multiple drive failures से नहीं आते जैसा लोग आमतौर पर सोचते हैं, बल्कि single drive failure के बाद array को reliably rebuild करने में असमर्थता से या कोई individual drives विफल हुए बिना array की विफलता से आते हैं। एक दूसरी drive विफल होने का जोखिम कम है, non-existent नहीं, लेकिन काफी कम। आज की drives अत्यधिक reliable हैं। एक drive के विफल होने के बाद यह दूसरी drive के विफल होने की संभावना बढ़ाता है, जो well documented है, लेकिन मैं नहीं चाहता कि यह जोखिम हमें सच्चे जोखिमों – एक failed resilvering operation के जोखिम – को देखने से भटकाए।

RAID 5 resilver operation के दौरान हमें जो डराता है वह यह है कि एक unrecoverable read error (URE) हो सकता है। जब ऐसा होता है तो resilver operation रुक जाती है और array एक बेकार अवस्था में छूट जाती है – array का सारा डेटा खो जाता है। सामान्य SATA drives पर URE की दर 10^14 है, या हर बारह terabyte read operations में एक बार। इसका मतलब है कि six terabyte array को resilver करने पर URE होने और विफल होने की लगभग पचास प्रतिशत संभावना है। पचास प्रतिशत विफलता की संभावना अत्यधिक रूप से अधिक है। कल्पना करें अगर आपकी कार के wheels हर बार जब आप उसे चलाते हैं पचास प्रतिशत संभावना से गिर जाते। तो 10^14 URE SATA drives का उपयोग करते हुए एक छोटे (आज के मानकों से) छह terabyte RAID 5 array के साथ, अगर हम एक single drive खो दें, तो हमारे पास केवल पचास प्रतिशत संभावना है कि array recover करेगी, यह मानते हुए कि drive तुरंत replace हो जाती है। इसमें दूसरी drive विफल होने का जोखिम शामिल नहीं है, केवल URE failure का जोखिम। यह यह भी मानता है कि resilver operation के अलावा drive पूरी तरह idle है। अगर drives उसी समय अन्य tasks के लिए व्यस्त रूप से उपयोग की जा रही हैं तो कुछ बुरा होने की संभावना, या तो URE या दूसरी drive विफलता, नाटकीय रूप से बढ़ने लगती है।

बारह terabyte array के साथ resilver operation के दौरान complete data loss की संभावना एक सौ प्रतिशत के करीब पहुंचने लगती है – मतलब RAID 5 उस मामले में बिल्कुल भी काम नहीं करती। जीवित रहने की हमेशा संभावना होती है, लेकिन यह बहुत कम है। छह terabyte पर आप resilver operation की तुलना एक गोली और छह chambers के साथ Russian roulette से कर सकते हैं और आपको तीन बार trigger खींचना है। बारह terabyte पर आपको छह बार खींचना है! वे अच्छे odds नहीं हैं।

लेकिन हम बारह terabyte array की बात नहीं कर रहे। हम छत्तीस terabyte array की बात कर रहे हैं – जो बड़ी लगती है लेकिन यह एक ऐसा आकार है जो कोई आज घर पर आसानी से रख सकता है, व्यवसाय में तो बिल्कुल। हर major server manufacturer, साथ ही लगभग सभी low cost storage vendors, आज इस capacity range में sub $10,000 storage systems बनाते हैं। छत्तीस terabyte array पर single drive failure के साथ RAID 5 array को resilver करना Russian roulette खेलने जैसा है, एक गोली, छह chambers और trigger अठारह बार खींचना! आपके डेटा को ज़्यादा मौका नहीं मिलता। उस size के array को resilver करने के लिए आवश्यक अविश्वसनीय समय जोड़ें और उस resilver window के दौरान दूसरी disk विफल होने का जोखिम काफी significant threat बनने लगता है। मैंने कुछ systems पर resilver times हफ्तों या महीनों तक पहुंचने के अनुमान देखे हैं। यह बिना दूसरी drive खोने की अनुमति दिए लंबा समय है। जब हम घंटों या दिनों की बात करते हैं तो जोखिम काफी कम हैं, लेकिन अभी भी मौजूद हैं। जब हम हफ्तों या महीनों के निरंतर दुरुपयोग की बात करते हैं, क्योंकि resilver operations अत्यधिक drive intensive हैं, तो failure rates नाटकीय रूप से बढ़ती हैं।

इस size के array के साथ हम effectively मान सकते हैं कि एक single drive का नुकसान complete array के नुकसान का मतलब है जो हमें कोई drive failure protection के बिना छोड़ता है। अब अगर हम समान या बेहतर performance वाली drive देखें जिसमें RAID 0 के तहत समान या बेहतर capacity है, जिसमें drive नुकसान के विरुद्ध कोई protection भी नहीं है, हमें अपने RAID 5 array के लिए जिन बारह drive की जरूरत थी उनमें से केवल ग्यारह की जरूरत है। इसका मतलब यह है कि बारह hard drives की बजाय, जिनमें से प्रत्येक में वार्षिक विफलता की लगभग तीन प्रतिशत संभावना है, हमारे पास केवल ग्यारह हैं। यह अकेले हमारी RAID 0 array को अधिक reliable बनाता है क्योंकि कम drives विफल हो सकती हैं। न केवल हमारे पास कम drives हैं बल्कि parity block लिखने या पढ़ते समय parity blocks skip करने की जरूरत नहीं है जो उसी utilization के लिए RAID 0 array पर mechanical wear and tear को बहुत थोड़ा कम करती है जिससे उसे बहुत थोड़ा अतिरिक्त reliability edge मिलता है। ग्यारह drives की RAID 0 array बारह drive RAID 5 array के समान capacity में identical होगी लेकिन थोड़ा बेहतर throughput और latency होगी। हर तरफ से जीत। साथ ही अतिरिक्त drive की जरूरत न होने से लागत बचत।

तो हम यहां देखते हैं कि बड़े arrays में (capacity में बड़े, spindle count में नहीं) RAID 0 actually कुछ scenarios में RAID 5 को पास कर लेती है। Common SATA drives का उपयोग करते समय यह उन capacities पर होता है जो home power users और कई small businesses के लिए भी अनुभव किए जाते हैं। अगर हम enterprise SATA drives या SAS drives पर जाते हैं तो जिस capacity number पर यह होता है वह बहुत अधिक हो जाती है और आज चिंता का विषय नहीं है लेकिन बस कुछ वर्षों में जब drive capacities और बड़ी हो जाएंगी तब होगा। लेकिन यह highlight करता है कि आज हम जिन sizes में देखते हैं उनमें RAID 5 कितनी खतरनाक है। हर कोई RAID 0 के अविश्वसनीय जोखिमों को समझता है लेकिन यह perspective में रखना मुश्किल हो सकता है कि RAID 5 की समस्याएं इतनी extreme हैं कि यह actually RAID 0 से कम reliable हो सकती है।

कि RAID 5 इस size के array में केवल resilver operations के आधार पर RAID 0 से कम reliable हो सकती है यह केवल शुरुआत है। इस size के massive array में resilver time इतना लंबा हो सकता है और drives पर इतना toll लगा सकता है कि second drive failure भी एक measurable risk बनने लगती है। और फिर array controller errors के कारण अतिरिक्त जोखिम हैं जो resilver algorithms का उपयोग करके एक पूरी array को destroy कर सकते हैं, यहां तक कि जब कोई drive failure नहीं हुई हो। क्योंकि RAID 0 (या RAID 1 या RAID 10) में resilver algorithms नहीं हैं, वे इस अतिरिक्त जोखिम से पीड़ित नहीं हैं। ये quantify करने में कठिन जोखिम हैं लेकिन जो महत्वपूर्ण है वह यह है कि ये अतिरिक्त जोखिम हैं जो एक अधिक complex system का उपयोग करते समय जमा होते हैं जब एक simpler system, redundancy के बिना, शुरू से ही अधिक reliable था।

अब जब हमने स्थापित किया है कि RAID 5, RAID 0 से कम reliable हो सकती है, मैं RAID 0 के obvious dangers की ओर इशारा करूंगा। RAID सामान्य रूप से एक अकेली hard drive के विफल होने के जोखिम को कम करने के लिए उपयोग किया जाता है। हम सभी एक single drive के विफल होने और सारा डेटा खो जाने से डरते हैं। RAID 0, किसी भी form of redundancy के बिना drives की एक बड़ी stripe होने के कारण, एक single drive विफल होने के data loss के जोखिम को कई drives में गुणा करती है जहां कोई भी drive विफल होने से सभी drives का total data loss होता है। तो हमारे ग्यारह disk उदाहरण में, अगर ग्यारह disks में से कोई भी एक विफल होती है तो सब कुछ खो जाता है। यह स्पष्ट रूप से देखा जा सकता है कि यह केवल एक single drive, अकेले, का उपयोग करने से नाटकीय रूप से अधिक खतरनाक है।

मैं यहां जो point करने की कोशिश कर रहा हूं वह यह है कि redundancy का मतलब reliability नहीं है। सिर्फ इसलिए कि कुछ redundant है, जैसे RAID 5, यह कोई guarantee नहीं देता कि यह हमेशा उससे अधिक reliable होगा जो redundant नहीं है।

यहां मेरा पसंदीदा analogy tornado में घरों को देखना है। एक scenario में हम brick और mortar का घर बनाते हैं। दूसरे scenario में हम दो redundant घर बनाते हैं, हर एक straw से (हमारे builders apparently सुअर हैं।) जब tornado (या big bad wolf) आता है तो कौन सा हमें एक खड़ा घर छोड़ने की अधिक संभावना रखता है? स्पष्ट रूप से एक brick और mortar घर के redundant straw के घरों पर कुछ significant reliability advantages हैं। Redundancy से कोई फर्क नहीं पड़ा, अंत में reliability ने मायने रखी।

Redundancy अक्सर misleading होती है क्योंकि यह quantify करना आसान है लेकिन qualify करना मुश्किल है। Redundancy एक black या white question है: क्या यह redundant है? हां या नहीं। Simple। Reliability इतनी simple नहीं है। Reliability failure rates और likelihoods के बारे में है। यह statistics और analysis के बारे में है। जैसा कि meaningful तरीके से reliability को quantify करना मुश्किल है, विशेषकर जब एक project को business people के सामने sell करना हो, redundancy अक्सर इस complex concept का एक simple substitute बन जाती है।

Reliability के सवालों को मिथ्या दिशा देने के लिए redundancy का उपयोग करने की अवधारणा भी बहुत convoluted तरीकों से subsystems पर लागू होती है। एक “system” को redundant बनाने की बजाय एक highly reliable और low cost subsystem को redundant बनाना और subsystem redundancy को पूरे system पर लागू मानना आम हो गया है। इसका सबसे common example SAN products में RAID controllers है। एक redundant SAN (meaning दो SANs) होने की बजाय manufacturers अक्सर उस एक component को जो सामान्य servers में अक्सर redundant नहीं होता, redundant बनाते हैं और फिर SAN को redundant कहते हैं – meaning एक SAN जिसमें redundancy है, जो बिल्कुल भी same चीज़ नहीं है।

यहां एक अच्छा analogy redundant cars meaning दो complete working cars होने और trunk में spare water pump के साथ एक single car होने की तुलना करना होगा। स्पष्ट रूप से एक spare water pump बुरी बात नहीं है। लेकिन यह दूसरी car होने की तुलना में car failure से बहुत trivial amount की protection भी है। एक case में पूरी system redundant है, chassis सहित। दूसरे में हम chassis के अंदर केवल एक, highly reliable component को redundant बना रहे हैं। यह spare tire होने के भी बराबर नहीं है, जो कम से कम, उच्च failure likelihood वाला एक car component है।

RAID 5 reliability और system/subsystem reliability के मिथक की तरह, shared storage technologies जैसे SANs और NAS को अक्सर उसी तरह treat किया जाता है, विशेष रूप से virtualization के संदर्भ में। एक सामान्य scenario है जहां एक virtualization project किया जाता है और लोग instinctively घबरा जाते हैं क्योंकि एक single virtualization host एक single point of failure represents करता है जहां, अगर यह विफल होता है, तो कई systems एक साथ विफल हो जाएंगे।

“single point of failure” शब्द का उपयोग एक panic feeling पैदा करता है और एक conversation को steer करने का एक बढ़िया साधन है। लेकिन एक SPOF, जैसा हम इसे कहना पसंद करते हैं, हालांकि कुछ ऐसा जिसे हम possible होने पर remove करना पसंद करते हैं, दुनिया का अंत नहीं हो सकता। हमारे brick house के बारे में सोचें। यह एक SPOF है। हमारे दो straw के घर नहीं हैं। फिर भी एक single breeze हमारे redundant solutions को हमारे reliable SPOF से तेज़ी से बाहर कर देती है। SPOFs ढूंढना एक system में fragility के points खोजने का एक अच्छा तरीका है, लेकिन यह न मानें कि हर SPOF को हर scenario में redundant बनाया जाना चाहिए। अधिकांश businesses अपना सबसे अच्छा value कई SPOFs के साथ पाएंगे। हमारा वास्तविक लक्ष्य appropriate cost पर reliability है, redundancy, जैसा हमने देखा है, reliability का substitute नहीं है, यह केवल एक tool है जिसका उपयोग हम reliability प्राप्त करने के लिए कर सकते हैं।

जो theory कई लोग virtualizing करते समय follow करते हैं वह है कि वे अपना virtualization host लेते हैं और कहते हैं “यह host एक SPOF है, इसलिए मुझे इनमें से दो चाहिए और transparent failover की अनुमति देने के लिए High Availability features का उपयोग करना चाहिए!” यह leading virtualization vendor द्वारा पहले महंगे HA add on products बेचकर और दूसरे एक large storage vendor के स्वामित्व में होने से – इसलिए unnecessary या यहां तक कि dangerous additional shared storage बेचना उनके लिए एक बड़ी monetary win है और आसानी से वह कारण हो सकता है कि उन्होंने शुरू से virtualization space को champion किया है। Redundant virtualization hosts के साथ shared storage बढ़िया लगती है लेकिन कई कारणों से अत्यंत misguided हो सकती है।

पहला कारण यह है कि initial SPOF, virtualization host, को हटाने की जगह एक नया SPOF, shared storage, आ जाता है। यह कुछ भी accomplish नहीं करता। यह मानते हुए कि हम comparable quality servers और shared storage उपयोग कर रहे हैं, हमने केवल जोखिम को shift किया है, बदला नहीं है। Storage system के विफल होने की likelihood roughly उतनी ही है जितनी original server के विफल होने की। लेकिन SPOF को shell game में shuffle करने के अलावा हमने कुछ far worse भी किया है – हमने chained या cascading failure dependencies introduce की हैं।

हमारे original scenario में हमारे पास एक single server था। अगर server working रहा तो हम ठीक हैं, अगर यह विफल हुआ तो हम नहीं थे। Simple। अब हमारे पास दो virtualization hosts, एक single storage server (SAN, NAS, जो भी) और एक network है जो उन्हें जोड़ता है। हम पहले ही determine कर चुके हैं कि shared storage के विफल होने का जोखिम roughly हमारे original scenario में total system risk के बराबर है। लेकिन अब हमारे पास network और दो front end virtualization nodes की additional dependencies हैं। इनमें से प्रत्येक component fragile shared storage (mechanical drives वाली कोई भी चीज़ fragile होगी) से अधिक reliable है लेकिन यह कि वे lower risk हैं issue नहीं है, issue यह है कि risks combinatorial हैं।

अगर इन तीन components (storage, network या front end nodes) में से कोई भी विफल होता है तो सब कुछ विफल होता है। इसका समाधान यह है कि shared storage को अपने आप redundant बनाएं और network को अपने आप redundant बनाएं। पर्याप्त काम से हम fragility और जोखिम को overcome कर सकते हैं जो shared storage जोड़कर introduce किया, लेकिन shared storage अपने आप में risk mitigation का एक रूप नहीं है बल्कि एक risk है जिसे mitigate करना होगा। Complexity का spiral शुरू होता है और इस नई system को original single server system की reliability के बराबर लाने से जुड़ी लागत astronomical हो सकती है।

अब जब हमारे पास यह सारी redundancy है तो हमें एक और risk की चिंता करनी है। इस सारी redundancy, इन सभी moving parts को manage करने के लिए एक simple single server manage करने की तुलना में बहुत अधिक knowledge, skill और preparation की आवश्यकता होती है। हम एक simple solution से एक बहुत complex solution की ओर चले गए हैं। मेरे अपने anecdotal experience में इस तरह के solutions के वास्तविक dangers hardware के विफल होने से नहीं बल्कि human error से आते हैं। न केवल इस नई system को विफल करने से human error को बचाने के लिए बहुत कम किया गया है, बल्कि हमने countless ऐसे points जोड़े हैं जहां एक human गलती से पूरी system, redundancy और सब, को नीचे ला सकता है। मैंने इसे पहले हाथ देखा है; मैंने horror stories सुनी हैं। System जितना complex होता है, उतना ही अधिक likely है कि एक human गलती से सब कुछ तोड़ दे।

यह critical है कि IT professionals के रूप में हम पीछे हटें और complete systems को देखें और reliability और risk पर विचार करें और redundancy को केवल reliability की खोज में उपयोग करने के tool के रूप में सोचें। Redundancy अपने आप में कोई panacea नहीं है। Simplicity भी नहीं है। Reliability एक complex problem है जिससे निपटना है। Simplistic replacements से बचना reliability issues को cover करने से face करने और solve करने की दिशा में एक महत्वपूर्ण पहला कदम है।