सबसे कमज़ोर कड़ी: Chained Dependencies सिस्टम जोखिम को कैसे प्रभावित करती हैं
System risk scenarios का assessment करते समय “chained” dependencies को अनदेखा करना बहुत आसान होता है। हमें risk को “node” level पर देखने के लिए train किया गया है — यह पूछते हुए कि “यह एक चीज़ fail होने की कितनी संभावना है।” लेकिन system risk उससे कहीं अधिक complicated है।
अधिकांश systems में कुछ components होते हैं जो अन्य components पर निर्भर करते हैं। सबसे सामान्य जगह जहाँ हम इसे देखते हैं वह servers के लिए storage का design है, लेकिन यह किसी भी system design में होता है। एक और अच्छा example यह है कि web applications को function करने के लिए application hosts और database hosts दोनों की ज़रूरत होती है।
Chained dependencies को एक example के साथ explain करना सबसे आसान है। हम SAN storage के साथ एक standard virtualization design को देखेंगे ताकि यह समझ सकें कि failure domain boundaries कहाँ exist करती हैं और chained dependencies कहाँ exist करती हैं और system level risk mitigation में redundancy क्या role play करती है।
Virtualization के लिए एक standard SAN (storage area network) design में आपके पास virtualization hosts (जिन्हें हम simplicity के लिए “servers” कहेंगे), SAN switches (storage network के लिए dedicated switches) और disk arrays खुद होते हैं। इन तीन “layers” में से प्रत्येक system के overall function करने के लिए दूसरों पर dependent है। यदि हमारे पास सबसे simple possible set हो — एक server, एक switch और एक disk array — तो हमारे पास clearly तीन devices हैं जो failure के तीन distinct points represent करते हैं। तीनों में से कोई एक fail होने पर पूरा system fail हो जाता है। कोई एक piece अपने आप उपयोगी नहीं है। यह एक chained dependency है और chain केवल उतनी ही strong है जितनी उसकी सबसे कमज़ोर कड़ी।
हमारे simplistic example में, प्रत्येक device एक failure domain represent करती है। हम प्रत्येक domain की reliability improve करके risk को mitigate कर सकते हैं। हम एक second server add कर सकते हैं और server failure के risk को कम करने के लिए एक virtualization layer high availability या fault tolerance strategy implement कर सकते हैं। यह एक failure domain की reliability improve करता है लेकिन दो को untouched छोड़ता है जो पहले जितनी risky हैं। हम फिर switching layer को address कर सकते हैं एक redundant switch add करके और उस layer पर risk को कम करने के लिए एक multi-pathing strategy configure करके जो single switching path के loss को handle कर सके। अब दो failure domains address हो गई हैं। अंत में हमें storage failure domain को address करना होगा जो similarly किया जाता है, एक second disk array के माध्यम से redundancy add करके जो first के mirror है और failure की event में transparently failover करने में capable है।
अब जब हमने अपना system beefed up कर लिया है, हमारे पास अभी भी dependency chain में तीन failure domains हैं। हमने जो किया है वह प्रत्येक “link” को chain में, प्रत्येक failure domain को, अपने आप पर extra resilient बनाया है। लेकिन chain अभी भी exists करती है। इसका मतलब है कि system, as a whole, chain के भीतर किसी भी single failure domain की तुलना में far less reliable है। हमने कुछ बनाया है जो जहाँ से हमने शुरू किया था उससे far better है, लेकिन हमारे पास अभी भी कई failure domains हैं। ये risks add up होते हैं।
Overall risk determine करने में जो difficult है वह यह है कि हमें प्रत्येक item के risk को assess करना होगा, फिर mitigation (redundancy की addition के through) के बाद new risk determine करना होगा और फिर overall system के total risk को determine करने के लिए एक chain में सभी failure domains के cumulative risk को find करना होगा। प्रत्येक failure domain के भीतर risk determine करना extremely difficult है क्योंकि risk mitigation का तरीका एक significant role play करता है। उदाहरण के लिए storage disk arrays का एक cluster जो too slowly fail over करता है, overall system failure में result हो सकता है भले ही storage cluster खुद properly worked करता दिखता हो। इसलिए even एक clear failure define करना challenging हो सकता है।
Risk का “from the top” view assessment करना often tempting होता है जो बहुत dangerous है, लेकिन उन लोगों के लिए बहुत common है जो regular risk assessment practitioners नहीं हैं। यहाँ tendency यह है कि risk को केवल “top most” failure domain देखते हुए देखा जाए — generally इस case में servers — और उस point के नीचे बैठे किसी भी risks को ignore किया जाए, उन्हें “under the hood” मानते हुए risk assessment का हिस्सा न मानते हुए। Relatively easy to understand और heavily marketed top layer के reliability aspects पर focus करते हुए networking और storage जैसे more technical, less exposed और more poorly understood components को ignore करना easy होता है। यह “top view” का मतलब है कि top level के नीचे के risks obscured हो जाते हैं और generally ignored हो जाते हैं जिससे high risk होता है बिना यह अच्छी तरह समझे कि क्यों।
Chained dependencies की concept को समझने से यह explain होता है कि complex systems, यहाँ तक कि complex risk mitigation strategies के साथ भी, often simpler systems की तुलना में far more fragile क्यों होते हैं। हमारे ऊपर के example में, हम chain को “collapse” करने के लिए कई चीज़ें कर सकते थे जिसके result में overall system अधिक reliable होता।
सबसे obvious component जिसे collapse किया जा सकता है वह networking failure domain है। यदि हम switches को entirely remove करके storage को directly servers से connect कर दें (हमेशा possible नहीं, बेशक) तो हम effectively एक पूरी failure domain eliminate कर देंगे और हमारी chain से एक link remove कर देंगे। अब तीन chains के बजाय, जिनमें से प्रत्येक में fail होने की कुछ potential है, हमारे पास केवल दो हैं। Simpler बेहतर है, सभी अन्य चीज़ें equal होने पर।
हम, theory में, storage failure domain को भी collapse कर सकते थे external storage से servers के लिए local storage की ओर जाकर — essentially हमें दो failure domains से एक single failure domain तक ले जाकर — remaining domain, बेशक, collapsing से पहले की तुलना में अधिक complexity carry कर रहा है, लेकिन overall system complexity greatly reduced है। फिर से, यह सभी अन्य factors equal remaining के साथ है।
Consider करने के लिए एक और approach है single nodes को अपने आप पर अधिक reliable बनाना। आज larger systems को देखना और redundant, low cost nodes add करके failure domains में reliability add करने के तरीके से risk mitigation approach करना trendy है। लेकिन traditionally यह reliability के लिए default path नहीं था। पुराने समय में, जैसा कि mainframe और similar classed systems की former prevalence में दिखाया जाता है, एक single node में high degrees of reliability build in करना far more common था। Mainframe और high end storage systems, उदाहरण के लिए, आज भी यह करते हैं। यह actually एक extremely effective approach हो सकता है लेकिन कई scenarios को address करने में fail होता है और generally extremely costly है, जो अक्सर vendor द्वारा systems को partially या completely maintain करने की ज़रूरत से magnified होती है। यह केवल special niche circumstances में work out होता है और more general scope पर practical नहीं है।
तो इस nature के किसी भी system में हमारे पास consider करने के लिए तीन key risk mitigation strategies हैं: एक single node की reliability improve करें, एक single domain की reliability improve करें, या dependency chain में failure domains (links) की संख्या कम करें। इन्हें together put करना, जैसा prudent है, हमें अपने business scenario के लिए appropriate risk mitigation level achieve करने में help कर सकता है।
जहाँ true difficulty exists है, और रहेगी, वह different risk mitigation strategies की comparison में है। एक single node के risk को generally कुछ level of confidence के साथ estimate किया जा सकता है। एक single domain के भीतर redundancy strategy को estimate करने की far less ability होती है — कुछ redundancy strategies highly effective हैं, extremely reliable failure domains create करती हैं जबकि अन्य actually backfire कर सकती हैं और एक domain की reliability reduce कर सकती हैं! Redundancy strategies के साथ जो complexity अक्सर आती है वह कभी भी caveat के बिना नहीं होती और हालाँकि यह typically pay off करेगी, यह शायद ही कभी उस degree की reliability benefit carry करती है जो initially expected थी। इसलिए एक dependency chain के risk को estimate करना उतना ही अधिक difficult है क्योंकि इसके लिए individually failure domains के साथ associated risks की clear understanding की ज़रूरत है साथ ही domain boundaries पर exist करने वाले failure opportunity की understanding (जैसे earlier noted storage failover delay failure।)
चलिए ऊपर जो discuss किया है उस पर build करते हुए same scenario के दो बहुत common approaches के आसपास risk determine करने के issues explore करते हैं।
Same situation के दो extreme examples जो हम discuss कर रहे हैं वे हैं: virtual machines host करने के लिए internal storage के साथ एक single server बनाम server layer पर high availability solution के साथ दो servers, switching layer पर redundancy के साथ दो switches और storage layer पर high availability provide करने वाले दो disk arrays के साथ एक six device “chain।” यदि हम यहाँ किसी large factor को switch करते हैं तो हम generally relative risk का pretty clear estimate provide कर सकते हैं — यदि failure domains में से कोई भी reliable redundancy lack करती है, उदाहरण के लिए — हम pretty clearly determine कर सकते हैं कि single server overall more reliable system है सिवाय उन cases के जहाँ किसी single node पर extreme amount of single node reliability assign की गई हो, जो generally financially impractical strategy है। लेकिन प्रत्येक failure domain redundancy maintain करने के साथ हमें intra-domain reliability (redundant chain) बनाम inter-domain reliability (collapsed chain, single server) के relative risks compare करने के लिए forced किया जाता है।
दो entirely different approaches के साथ risk mitigation के दो means के comparative risks assess करने का कोई reasonable way नहीं है। यह generally accepted है कि extensive intra-domain risk mitigation के साथ six (या अधिक) node approach दो approaches में more reliable है और यह almost certainly, generally true है। लेकिन यह हमेशा true नहीं है और शायद ही यह approach single node strategy को truly significant margin से outperform करती है जबकि commonly single server strategy की तुलना में four to ten fold अधिक cost आती है। यह संभावित रूप से reliability में likely small gain के लिए और reliability में small potential loss के लिए बहुत high cost है। Redundancy का प्रत्येक additional piece complexity add करता है जिसे एक human को implement, monitor और maintain करना होगा और complexity और human interaction के साथ अधिक से अधिक risk आता है। Human error से बचना often mechanical failure से बचने से अधिक important हो सकता है।
हमें recovery की cost भी consider करनी होगी। यदि failure occur होनी है तो generally एक simple system की failure से recover करना trivial है। एक extremely complex system, जो fail हुआ है, उसे working condition में restore करने के लिए great degree of effort की ज़रूरत हो सकती है। Complex systems को maintain करने के लिए भी बहुत broader और deeper degrees of experience और confidence की ज़रूरत होती है।
Systems की reliability determine करने का कोई easy answer नहीं है। Modern information delivery systems simply too large और too complex हैं, जिनमें too many indeterminable factors हैं, सभी cases में evaluate करने के लिए। Chained dependencies की अच्छी understanding के साथ, हालाँकि, और risk mitigation strategies की understanding के साथ हम practical steps ले सकते हैं roughly relative risk levels determine करने के लिए, देख सकते हैं कि similar risk scenarios cost में कैसे compare करते हैं, fragility के points identify कर सकते हैं, failure domains और dependency chains पहचान सकते हैं, और appreciate कर सकते हैं कि system design में changes हमें clearly reliability की ओर या उससे दूर कैसे move करेंगे।
विज्ञापन
