विफलता का एकल बिंदु (एसपीओएफ) क्या है?

सिस्टम डिजाइन में सिंगल पॉइंट ऑफ फेलियर (एसपीओएफ) एक सामान्य जोखिम है, जहां एक घटक, प्रक्रिया या निर्भरता के विफल होने पर पूरा सिस्टम काम करना बंद कर सकता है।

सिंगल पॉइंट ऑफ फेलियर का क्या अर्थ है?

किसी सिस्टम में कोई भी ऐसा घटक या निर्भरता जिसकी विफलता से सिस्टम द्वारा इच्छित सेवा प्रदान करने की क्षमता बाधित या पूरी तरह से बंद हो सकती है, उसे सिंगल पॉइंट ऑफ़ फेलियर कहा जाता है। यह भौतिक हो सकता है, जैसे कि एक सिंगल स्विचपावर फीड, स्टोरेज कंट्रोलर, या नेटवर्क अपलिंक, या लॉजिकल, जैसे कि एक डेटाबेस इंस्टेंस, एक प्रमाणीकरण प्रदाता, एक डीएनएस क्षेत्र, एक भार संतुलनया फिर कॉन्फ़िगरेशन डेटा का एक ऐसा एकल भाग जिस पर सब कुछ निर्भर करता है।

किसी चीज़ को SPOF (स्पेयर ऑफ़ फेस) इसलिए नहीं कहा जाता कि वह महत्वपूर्ण है, बल्कि इसलिए कहा जाता है कि उसका कोई प्रभावी वैकल्पिक मार्ग, रिडंडेंट इंस्टेंस या स्वचालित समाधान मौजूद नहीं है। विफलता जब यह अनुपलब्ध हो जाता है, तो सिस्टम स्वीकार्य स्तर पर काम करना जारी नहीं रख सकता। SPOF इसके बाहर भी मौजूद हो सकते हैं। हार्डवेयर और सॉफ्टवेयर, उदाहरण के लिए परिचालन प्रक्रियाओं में जहां सेवा बहाल करने के लिए केवल एक व्यक्ति, एक अनुमोदन चरण, या एक रनबुक ज्ञान धारक की आवश्यकता होती है।

व्यवहार में, एक SPOF की पहचान महत्वपूर्ण प्रवाहों को शुरू से अंत तक ट्रैक करके और उन स्थानों को ढूंढकर की जाती है जहां एक विफलता डोमेन पूरी सेवा को ठप करने की क्षमता रखता है क्योंकि डिजाइन अतिरेक, अलगाव या पुनर्प्राप्ति तंत्र के बिना निर्भरता को केंद्रित करता है।

सिंगल पॉइंट ऑफ़ फेलियर कैसे होता है?

सिंगल पॉइंट ऑफ़ फ़ेलियर तब होता है जब किसी सेवा के कई हिस्से एक ही घटक या निर्भरता पर निर्भर होते हैं, इसलिए जब वह एक चीज़ खराब हो जाती है, तो आगे की सभी सेवाओं को काम करने के लिए आवश्यक चीज़ें खोनी पड़ती हैं। यह स्थिति इस प्रकार सामने आ सकती है:

1. एक महत्वपूर्ण निर्भरता प्रस्तुत की गई है। यह प्रणाली एक विशिष्ट घटक (जैसे कि एक) पर निर्भर करती है। डेटाबेस, एक रूटरसामान्य अनुरोधों को पूरा करने के लिए किसी एक पहचान प्रदाता (या किसी एक पहचान प्रदाता) का उपयोग करना पड़ता है, जिससे जोखिम एक ही स्थान पर केंद्रित हो जाता है।
2. कई रास्ते मिलकर इस पर आकर मिलते हैं। अधिक सेवाएं, वर्कफ़्लो या उपयोगकर्ता उसी निर्भरता के माध्यम से रूट किए जाते हैं, जो डिज़ाइन को सरल बनाता है लेकिन यदि वह निर्भरता विफल हो जाती है तो इसके प्रभाव का दायरा बढ़ जाता है।
3. कोई समतुल्य नहीं backup पथ मौजूद है। कोई रिडंडेंट इंस्टेंस, फेलओवर टारगेट या वैकल्पिक रूट नहीं है, इसलिए सिस्टम अनुपलब्ध होने पर निर्भरता को दरकिनार नहीं कर सकता है।
4. निर्भरता में विफलता या रुकावट आ गई है। यह क्रैश, बिजली की कमी, नेटवर्क विभाजन, गलत कॉन्फ़िगरेशन, प्रमाणपत्र की समय सीमा समाप्त होना, क्षमता की कमी या रखरखाव त्रुटि, कुछ भी हो सकता है जो इसे अनुरोधों को पूरा करने में असमर्थ बनाता है।
5. अपस्ट्रीम कंपोनेंट्स तेजी से फेल होने लगते हैं या टाइम आउट हो जाते हैं। निर्भरता से संबंधित कॉल में त्रुटि आने लगती है या वे रुक जाती हैं, जिससे आश्रित सेवाएं धीमी हो जाती हैं या बाधित हो जाती हैं और पुनः प्रयास और कतार निर्माण के कारण भार और विलंबता बढ़ जाती है।
6. इस विफलता के परिणामस्वरूप सेवा स्तर पर व्यवधान उत्पन्न होता है। क्योंकि यह निर्भरता प्रमुख कार्यों के लिए आवश्यक है, इसलिए समग्र सेवा आंशिक रूप से खराब हो जाती है या पूरी तरह से अनुपलब्ध हो जाती है, जिससे अक्सर उन असंबंधित सुविधाओं पर भी असर पड़ता है जो एक ही अवरोध बिंदु को साझा करती हैं।
7. पुनर्प्राप्ति उस एक बिंदु को बहाल करने पर निर्भर करती है। सेवा तभी बहाल होती है जब विफल घटक की मरम्मत या प्रतिस्थापन हो जाता है, या जब कोई आपातकालीन समाधान लागू किया जाता है, यही कारण है कि SPOF अक्सर लंबी और अधिक व्यवधानकारी घटनाओं में परिणत होते हैं।

सिंगल पॉइंट ऑफ फेलियर का एक उदाहरण क्या है?

सिंगल पॉइंट ऑफ़ फेलियर का एक उत्कृष्ट उदाहरण एक रनिंग है। आवेदन एक पर server बिना फ़ेलओवर के। अगर ऐसा है तो। serverयदि हार्डवेयर खराब हो जाता है, तो OS यदि ऐप क्रैश हो जाता है, बिजली आपूर्ति बंद हो जाती है, या नेटवर्क इंटरफ़ेस काम करना बंद कर देता है, तो पूरा ऐप अनुपलब्ध हो जाता है क्योंकि कार्यभार संभालने के लिए कोई दूसरा इंस्टेंस नहीं होता है और उपयोगकर्ताओं के लिए सेवा तक पहुंचने का कोई वैकल्पिक मार्ग नहीं होता है।

एकल विफलता बिंदु जोखिम

सिंगल पॉइंट ऑफ़ फेलियर से आउटेज की संभावना और प्रभाव दोनों बढ़ जाते हैं क्योंकि ये महत्वपूर्ण कार्यक्षमता को एक ही स्थान पर केंद्रित कर देते हैं और कोई विश्वसनीय बैकअप उपलब्ध नहीं होता। मुख्य जोखिमों में शामिल हैं:

• पूर्ण सेवा बाधित। यदि एसपीओएफ काम करना बंद कर देता है, तो पूरी सेवा अनुपलब्ध हो सकती है, न कि केवल एक सुविधा, क्योंकि प्रमुख अनुरोध पथ पूरे नहीं हो सकते।
• क्रमिक विफलताएँ। विफल निर्भरता के विरुद्ध टाइमआउट और पुनः प्रयास अपस्ट्रीम सेवाओं, कतारों और नेटवर्कों पर अत्यधिक भार डालते हैं, जिससे घटना मूल घटक से परे फैल जाती है।
• ठीक होने में अधिक समय लगना (उच्च एमटीटीआर)। फेलओवर पाथ न होने के कारण, सेवा को बहाल करने के लिए अक्सर क्षतिग्रस्त घटक की मरम्मत या मैन्युअल हस्तक्षेप की आवश्यकता होती है, जिससे रिकवरी धीमी हो जाती है।
• छोटे-छोटे बदलावों से भी विस्फोट का दायरा बढ़ जाता है। एसपीओएफ पर एक नियमित पैच, कॉन्फ़िगरेशन अपडेट, प्रमाणपत्र रोटेशन या रखरखाव विंडो उस पर निर्भर हर चीज़ को ठप कर सकती है।
• डेटा हानि या असंगति। यदि एसपीओएफ एक है भंडारण यदि डेटाबेस लेयर में प्रतिकृति नहीं है, तो विफलताओं के कारण लेखन का नुकसान, भ्रष्टाचार या आंशिक लेनदेन हो सकते हैं।
• प्रदर्शन संबंधी बाधाएं. विफल होने से पहले भी, एक एसपीओएफ थ्रूपुट और लेटेंसी के लिए सीमित कारक बन सकता है क्योंकि सारा ट्रैफिक एक सीमित संसाधन से होकर गुजरता है।
• सुरक्षा और पहुंच संबंधी प्रतिबंध। केंद्रीकृत पहचान, डीएनएसया, मुख्य प्रबंधन बिना अतिरेक के सभी लॉगिन अवरुद्ध हो सकते हैं। API किसी आउटेज के दौरान कॉल करना, या आंतरिक सेवा-से-सेवा प्रमाणीकरण।
• परिचालन संबंधी कमजोरी. एक अनुमोदक, एक ऑन-कॉल विशेषज्ञ, या एक अलिखित रनबुक जैसे "लोग/प्रक्रिया" संबंधी SPOFs में देरी हो सकती है। घटना की प्रतिक्रिया और वृद्धि स्र्कना.

किसी एक त्रुटि के स्रोत की पहचान कैसे करें?

किसी एक विफलता बिंदु की पहचान करने का अर्थ है व्यवस्थित रूप से यह पता लगाना कि कहाँ कोई एक घटक, निर्भरता या प्रक्रिया पूरे सिस्टम को रोक सकती है। इसे पहचानने का तरीका यहाँ दिया गया है:

• महत्वपूर्ण कार्यप्रवाहों को शुरू से अंत तक मैप करें। लॉगिन, चेकआउट या क्लाइंट से एप्लिकेशन, नेटवर्क, स्टोरेज और बाहरी सेवाओं के माध्यम से डेटा लिखने जैसी उपयोगकर्ता गतिविधियों को ट्रैक करें ताकि यह पता चल सके कि प्रत्येक चरण किस पर निर्भर करता है।
• प्रत्येक घटक के लिए यह प्रश्न पूछें कि "यदि यह विफल हो जाता है तो क्या टूटेगा?" प्रत्येक के लिए serverयदि कोई सेवा, डेटाबेस, कतार, एपीआई या तृतीय-पक्ष निर्भरता अनुपलब्ध है, तो मान लें कि यह अनुपलब्ध है और देखें कि क्या सिस्टम अभी भी कम गुणवत्ता वाले लेकिन स्वीकार्य तरीके से काम कर सकता है।
• केवल डुप्लिकेट की नहीं, बल्कि वास्तविक अतिरेक की जाँच करें। सत्यापित करो कि backupsप्रतिकृतियां या द्वितीयक उदाहरण सक्रिय, पहुंच योग्य होते हैं और विफलताओं के दौरान स्वचालित रूप से उपयोग किए जाते हैं, न कि केवल कागज़ पर मौजूद होते हैं।
• विभिन्न सेवाओं में साझा निर्भरताओं की तलाश करें। DNS, पहचान प्रदाता, कॉन्फ़िगरेशन स्टोर, या जैसे घटकों की पहचान करें संदेश दलाल कई प्रणालियाँ इन पर निर्भर करती हैं, क्योंकि ये अक्सर SPOF को छुपाती हैं।
• विफलता के क्षेत्रों और अलगाव की समीक्षा करें। सुनिश्चित करें कि अतिरिक्त घटक बिजली, नेटवर्क आदि द्वारा अलग किए गए हैं। उपलब्धता क्षेत्र, प्रदेश या प्रशासनिक डोमेन इसलिए एक घटना उन सभी को खत्म नहीं कर सकती।
• घटनाओं के इतिहास और बाल-बाल बचने की घटनाओं का विश्लेषण करें। पिछली रुकावटें, खराब प्रदर्शन की घटनाएं और "लगभग विफलताएं" अक्सर छिपे हुए SPOF को उजागर करती हैं जो डिजाइन के दौरान स्पष्ट नहीं थे।
• विफलता परिदृश्यों के साथ परीक्षण करें। कैओस टेस्टिंग, फॉल्ट इंजेक्शन या नियोजित आउटेज का उपयोग करके जानबूझकर घटकों को निष्क्रिय करें और देखें कि क्या सिस्टम अपेक्षा के अनुसार कार्य करना जारी रखता है।

किसी एक ही स्थान पर विफलता होने से कैसे बचा जाए?

किसी एक घटक, निर्भरता या प्रक्रिया के कारण पूरी सेवा ठप्प न होने देने का अर्थ है सिस्टम को इस प्रकार डिज़ाइन करना कि कोई भी घटक, निर्भरता या प्रक्रिया इस प्रकार पूरी सेवा को ठप्प न कर सके। इसे इस प्रकार रोका जा सकता है:

• महत्वपूर्ण घटकों के लिए अतिरिक्त सुरक्षा व्यवस्था जोड़ें। प्रमुख सेवाओं (ऐप नोड्स, डेटाबेस, आदि) के कम से कम दो इंस्टेंस चलाएँ। भारोत्तोलक, फायरवॉल, स्विच(बिजली आपूर्ति) ताकि सेवा को रोके बिना कोई एक विफल हो सके।
• स्वचालित फ़ेलओवर सक्षम करें। स्वास्थ्य जांच और फेलओवर तंत्र (क्लस्टरिंग, लीडर इलेक्शन, मैनेज्ड फेलओवर, डीएनएस फेलओवर) का उपयोग करें ताकि मैन्युअल हस्तक्षेप की प्रतीक्षा करने के बजाय ट्रैफिक स्वचालित रूप से स्थानांतरित हो जाए।
• अलग-अलग विफलता क्षेत्र। किसी एक स्थानीय घटना से प्राथमिक और दोनों घटकों के ठप होने से बचाने के लिए, अतिरिक्त घटकों को अलग-अलग रैक, पावर सर्किट, स्विच, उपलब्धता क्षेत्र या क्षेत्रों में रखें। backup.
• छिपी हुई साझा निर्भरताओं को हटाएँ। सिंगल DNS ज़ोन, आइडेंटिटी प्रोवाइडर, सीक्रेट्स स्टोर जैसे सामान्य अवरोधों की पहचान करें। NAT गेटवे या कॉन्फ़िगरेशन सेवा को हटा दें या उनके विकल्प उपलब्ध कराएं।
• सुंदर ढंग से विघटित होने के लिए डिज़ाइन। आउटेज के दौरान गैर-महत्वपूर्ण सुविधाओं को वैकल्पिक बनाएं (रीड-ओनली मोड, कैश्ड रिस्पॉन्स, बाद में उपयोग के लिए क्यू राइट्स, फीचर फ्लैग) ताकि मुख्य कार्यक्षमता चालू रह सके।
• आंशिक विफलताओं के दौरान ओवरलोड को रोकें। किसी विफल निर्भरता को व्यापक व्यवधान में तब्दील होने से रोकने के लिए टाइमआउट, सर्किट ब्रेकर, बल्कहेड, दर सीमा और सीमित पुनःप्रयास का उपयोग करें।
• डेटा का सही तरीके से बैकअप लें और उसकी प्रतिकृति बनाएं। नोड्स/ज़ोन में प्रतिकृति का उपयोग करें, नियमित रूप से पुनर्स्थापना का परीक्षण करें, और सुनिश्चित करें कि सिस्टम डेटा भ्रष्टाचार या लंबे समय तक डाउनटाइम के बिना प्रतिकृतियों को बढ़ावा दे सकता है।
• परिचालन संबंधी एसपीओएफ को समाप्त करें। रनबुक को दस्तावेज़ित करें, सामान्य रिकवरी कार्यों को स्वचालित करें, साझा पहुंच का उपयोग करें आई ए एमऔर यह सुनिश्चित करें कि एक से अधिक व्यक्ति महत्वपूर्ण प्रक्रियाओं को अंजाम दे सकें।
• परीक्षण करके इसे सिद्ध करें। नियमित रूप से फेलओवर ड्रिल और गेम डे आयोजित करें ताकि यह सत्यापित किया जा सके कि रिडंडेंसी और रिकवरी वास्तविक परिस्थितियों में वास्तव में काम करती हैं।

एकल विफलता बिंदु संबंधी अक्सर पूछे जाने वाले प्रश्न

यहां सिंगल पॉइंट ऑफ फेलियर के बारे में सबसे अधिक पूछे जाने वाले प्रश्नों के उत्तर दिए गए हैं।

सिंगल पॉइंट ऑफ़ फेलियर बनाम मल्टीपल

आइए, विफलता के एकल बिंदु और विफलता के कई बिंदुओं की तुलना करके उनकी विशिष्ट विशेषताओं के बारे में जानें:

क्या लोड बैलेंसर एक सिंगल पॉइंट ऑफ फेलियर है?

यदि लोड बैलेंसर को बिना रिडंडेंसी या फेलओवर के सिंगल इंस्टेंस के रूप में तैनात किया जाता है, तो यह विफलता का एक बिंदु हो सकता है, क्योंकि सारा ट्रैफिक इस पर निर्भर करता है। बैकेंड सेवाओं.

लचीले डिज़ाइनों में, इस जोखिम से बचने के लिए कई लोड बैलेंसर इंस्टेंस चलाए जाते हैं, एक्टिव-एक्टिव या एक्टिव-पैसिव सेटअप का उपयोग किया जाता है, हेल्थ चेक किए जाते हैं और स्वचालित फेलओवर लागू किया जाता है, या फिर प्रबंधित लोड बैलेंसिंग सेवाओं पर निर्भर रहा जाता है जो स्वयं वितरित और दोष सहिष्णु होती हैं।

क्या सिंगल पॉइंट ऑफ़ फेलियर अच्छा है या बुरा?

किसी एक घटक के विफल होने पर प्रणाली में खराबी आना आमतौर पर बुरा माना जाता है क्योंकि इससे प्रणाली नाजुक हो जाती है और उस एक घटक के विफल होने पर पूरी सेवा बाधित होने का खतरा बढ़ जाता है।

हालांकि एसपीओएफ डिजाइन को सरल बना सकते हैं, लागत कम कर सकते हैं, या गैर-महत्वपूर्ण या प्रारंभिक चरण की प्रणालियों में स्वीकार्य हो सकते हैं, वे विश्वसनीयता, उपलब्धता और लचीलेपन के लक्ष्यों के विरुद्ध काम करते हैं, यही कारण है कि अधिकांश उत्पादन प्रणालियां समय के साथ उनकी पहचान करने, उन्हें कम करने या समाप्त करने का लक्ष्य रखती हैं।