लिनक्स के साथ डाउनटाइम से कैसे बचें?


13

उबंटू में बार-बार सॉफ़्टवेयर अपडेट के लिए रिबूट की आवश्यकता होती है (जो साइड इफेक्ट्स जैसे डाउनटाइम हो सकता है)।

मुझे लगता है कि उबंटू में https://www.ubuntu.com/livepatch है जो रिबूट के बिना कर्नेल अपडेट की अनुमति देता है, हालांकि, यह एक भुगतान सेवा है। Ksplice भी है ।

क्या लिनक्स वितरण / प्रक्रियाएं हैं जहां उन्नयन / पैच को कभी रिबूट की आवश्यकता नहीं होती है?

(मुझे पता है कि उच्च उपलब्धता (एचए) सर्वर स्थापित करना और डिस्पोजेबल सर्वर होना सर्वोत्तम प्रथाएं हैं - इसलिए मैं किसी सेवा को चालू रखने के बारे में नहीं पूछ रहा हूं , बल्कि वास्तविक सर्वर पर।


1
क्या एक एयर-गैप्ड सर्वर एक मशीन के रूप में काम करेगा जिसे कभी रिबूट करने की आवश्यकता नहीं है? आखिरकार, यदि कोई इसे एक्सेस नहीं कर सकता है, तो आपको इसे रीबूट करने की आवश्यकता नहीं है? ;) - उदाहरण के लिए, एक परमाणु ऊर्जा संयंत्र पर एक निगरानी सर्वर, कि बस एक अलार्म लगता है अगर कुछ गलत है। (हाँ, मुझे पता है कि यह एक यादृच्छिक सर्वर के बजाय एक समर्पित प्रणाली होगी, लेकिन मैं उदाहरण का उपयोग सिर्फ इस बिंदु पर करने के लिए कर रहा हूं कि ऐसे अवसर हैं जब 'सुरक्षा अपडेट' के लिए रिबूट करना शायद एक पूरी तरह से
विचारशील

3
@ djsmiley2k यह उन मामलों में से एक है जहां एक मशीन जिसे आप कभी भी रिबूट नहीं करते हैं वह आपको पर्याप्त उपलब्धता नहीं देता है। इसके बजाय आपको अतिरेक की जरूरत है।
15

@kasperd ठीक है, तो कभी रिबूट की गई मशीनों का एक समूह?
djsmiley2k TMW

3
@ djsmiley2k इस सवाल का मेरा जवाब पहले से ही तर्क है कि मैं उन मशीनों का एक समूह क्यों मानता हूं जिन्हें एक बार में रिबूट किया गया है जो एक से अधिक विश्वसनीय हैं जो आप कभी भी रिबूट नहीं करते हैं।
कास्परड

2
क्या आपको लगता है कि व्यक्तिगत सिस्टम डाउनटाइम से बचना बेहतर है?
वॉरेन

जवाबों:


12

आपके प्रश्न के लिए, "क्या लिनक्स वितरण / प्रक्रियाएं हैं, जहां उन्नयन / पैच को कभी भी रिबूट की आवश्यकता नहीं होती है?", मुझे किसी के बारे में पता नहीं है, और मुझे अत्यधिक संदेह है कि कभी भी कोई भी होगा जो वास्तव में रिबूट-मुक्त हैं। माइकल हैम्पटन की टिप्पणी के अलावा कि लाइव पैचिंग कहीं भी एक आउट-ऑफ-द-बॉक्स अनुभव नहीं है, लाइव पैचिंग भी रिबूटिंग के समान परिणाम प्राप्त नहीं करता है।

इसका वर्णन करने का एक किस्सा: मैंने हाल ही में एक समस्या की जांच की है जहाँ एक विशेष उपयोगिता ने बड़ी संख्या में मशीनों पर सीगफॉल्टिंग शुरू कर दी थी। मैंने साझा पुस्तकालयों को देखने की कोशिश की, जो यह देखते थे कि क्या हाल ही में उन्नत किए गए कुछ ने इसे तोड़ दिया है; ldd ने कहा कि यह एक निष्पादन योग्य नहीं था (तब भी जब मैंने उसी बाइनरी को अपने लैपटॉप पर खींच लिया था, ldd साझा लाइब्रेरी निर्भरता को बस ठीक देख सकता था)। मैंने इसके माध्यम से gdb में कदम रखने की कोशिश की; इससे पहले कि वह पहले हिदायत पर पहुंचता उससे पहले ही यह हमला हो गया।

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

एक अन्य उदाहरण: मेल्टडाउन / स्पेक्टर पैच इतने आक्रामक थे कि उबंटू कर्नेल टीम ने फैसला किया कि लाइव पैचिंग अव्यावहारिक थी और लोगों को फिर से लाइव पैच प्राप्त करने से पहले अपने सिस्टम को निश्चित कर्नेल में रिबूट करने की आवश्यकता थी।

हम काम पर भौतिक और आभासी सर्वरों का एक बड़ा बेड़ा चलाते हैं, जिसमें बड़ी संख्या में Ksplice और Canonical Livepatch सिस्टम हैं। वे दोनों अन्य सॉफ़्टवेयर की तुलना में कहीं अधिक विश्वसनीय हैं, लेकिन मैं अभी भी हमारी सेवाओं को रिबूट-अनुकूल वास्तुकला के साथ डिज़ाइन किया गया देखूंगा जो कर्नेल लाइव पैचिंग पर भरोसा करते हैं।


30

एक सेवा को अत्यधिक उपलब्ध कराने और एक व्यक्तिगत मशीन को अत्यधिक उपलब्ध बनाने के बीच एक महत्वपूर्ण अंतर है।

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

यहां तक ​​कि अगर आप सॉफ्टवेयर को अपडेट करने की आवश्यकता के कारण सभी डाउनटाइम को दूर कर सकते हैं, तब भी व्यक्तिगत मशीनें 100% उपलब्ध नहीं होंगी। इस प्रकार व्यक्तिगत मशीनों की उपलब्धता से ऊपर सेवा की उपलब्धता बढ़ाने के लिए आपको उच्च स्तर पर अतिरेक को डिजाइन करना होगा। आपके प्रश्न का अंतिम वाक्य बताता है कि कम से कम सिद्धांत रूप में आप यह जानते हैं।

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

एक बार उच्च स्तरीय प्रणाली व्यक्तिगत हार्डवेयर घटकों के मामले में विश्वसनीय होने के लिए डिज़ाइन की गई है, जो कि कर्नेल के लाइव पैचिंग को एक जोखिम बनने के लिए एक लाभ होने से बदल देती है।

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

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

उन कारणों के लिए एक अत्यधिक उपलब्ध सेवा वास्तव में धीमी गति से पर्याप्त दर पर व्यक्तिगत मशीनों के नियमित रिबूट के साथ प्राप्त करना आसान हो सकती है, जिससे आप समस्याओं का पता लगा सकते हैं और एक बार समस्या होने पर रिबूट के अनुक्रम को रोक सकते हैं।


मुझे आपके जोखिम का वर्णन पसंद आया; "नवीनतम कर्नेल के साथ बूट किया गया पैच" .. हालाँकि, आपने मेरे प्रश्न का उत्तर नहीं दिया .. जिसे मैं पुनः प्रकाशित कर सकता हूं, क्या लिनेक्स डिस्ट्रोस हैं जो 'लाइवपॉच' आउट-ऑफ-द-बॉक्स के साथ जहाज करते हैं?
user75126

@ user75126 मैं इसे एक ऐसी सुविधा के रूप में देखता हूं जो सर्वर के लिए क्लाइंट मशीनों के लिए अधिक उपयुक्त है। इसके अलावा यह पूछना कि कौन सा वितरण समर्थन करता है यह एक उत्पाद अनुशंसा प्रश्न जैसा लगता है। मेरे लिए यह दो कारणों से लगता है कि क्यों इस तरह के सवाल को इस साइट के लिए ऑफ-टॉपिक बना दिया जाएगा।
19

3
@ user75126 Oracle के Ksplice का एक नि: शुल्क परीक्षण है, और उबंटू और फेडोरा डेस्कटॉप के लिए एक निशुल्क स्तरीय (केवल, लेकिन वे वास्तव में इसे लागू नहीं करते हैं)। समस्या यह है कि लाइव पैच बनाने के लिए स्वचालित करना मुश्किल है, और यहां तक ​​कि जिन भागों को स्वचालित किया जा सकता है, वे भी समय लेने वाले हैं। इन पैच को बनाना एक अपेक्षाकृत श्रम गहन ऑपरेशन है, और कंपनियों के लिए यह उचित है कि वे इसके लिए शुल्क लें। मैंने इस बात पर ध्यान दिया कि इसे लाइव पैच बनाने के लिए क्या करना होगा, और इसे वहां से हटा दिया जाएगा। मुझे अपने दिन में उस तरह का समय नहीं मिला है।
माइकल हैम्पटन

12
@ user75126 इस साइट पर प्रश्न शीर्षक और शरीर को एक मौजूदा उत्तर को अमान्य करने वाले तरीके को बदलने के लिए वास्तव में बुरा व्यवहार है। यदि आप एक अलग प्रश्न पूछना चाहते हैं, तो एक अलग प्रश्न पूछें।
ग्रेग स्मिट

2
@ user75126 धन्यवाद। मैंने आपका प्रश्न पढ़ा, और मुझे नहीं लगा कि यह वास्तव में इसका उत्तर था। मैं केवल इस पर टिप्पणी कर रहा था कि यह एक भुगतान सेवा क्यों है।
माइकल हैम्पटन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.