एकाधिक टीमों में काम करने के कानों में, मैंने कई बुनियादी ढांचे प्रबंधकों से मुलाकात की है जो साप्ताहिक सर्वर रीबूट की नीति स्थापित करते हैं। एक डेवलपर के रूप में, मैं हमेशा नीति के खिलाफ था - ऐसा लगता है कि यह सॉफ़्टवेयर कीड़े और हार्डवेयर अस्थिरता के आसपास काम करने के बजाय एक हैक है।नियमित सर्वर रीबूट के लाभ और हिंसा
नीति के संबंध में लोगों की राय, सकारात्मक और नकारात्मक अंक क्या हैं?
आप कभी कभी अपने सर्वर रिबूट हैं, तो आप यकीन है कि वे वापस ऊपर आ जाएगा हो सकता है। हालांकि साप्ताहिक लगता है कि एक गंभीर ओवरकिल की तरह, मैंने इस समस्या को लंबे समय तक लिनक्स मशीनों पर देखा है।
किसी ने एक महत्वपूर्ण सेवा बूट पर स्वचालित रूप से शुरू करने के लिए स्थापित करने के लिए परेशान नहीं किया। या आने वाली सेवाओं का आदेश गलत है। या किसी ने पुस्तकालयों को अपग्रेड किया, जोड़ा/हटाया सॉफ़्टवेयर इत्यादि और निष्पादन योग्य अब काम नहीं करता है (यह पुराने पुस्तकालयों के साथ शुरू हुआ था, और उनका उपयोग जारी रखा गया था; अब यह एक गतिशील लिंकर त्रुटि प्राप्त करता है)। या यह पता चला है कि सेवा ए सेवा बी पर निर्भर करता है और सेवा बी सेवा ए (ओओएस) पर निर्भर करता है।
किसी बिंदु पर, जब आप कम से कम चाहते हैं, तो आप रीबूट लेंगे। कोलो आपके ऊपर बिजली छोड़ देगा; सर्वर की बिजली की आपूर्ति असफल हो जाएगी; कोई गलत सर्वर पर रीड बटन को कॉर्ड खींच देगा/हिट करेगा; इत्यादि। अब, जब आप कम से कम डाउनटाइम ले सकते हैं, तो आपका खूनी सर्वर वापस नहीं आएगा।
बस सॉफ्टवेयर की तरह, सिस्टम कॉन्फ़िगरेशन को परीक्षण की आवश्यकता होती है। आपको यह परीक्षण करने की कितनी बार आवश्यकता होती है कि आपके बक्से कैसे प्रबंधित किए जाते हैं।
हमारे सर्वर काम पर सभी लिनक्स सर्वर हैं, और हम कभी भी रीबूट नहीं करते हैं और कोई समस्या नहीं है। मैं मानता हूं कि यह सबसे अच्छा हैक है, और मुझे यह भी लगता है कि विंडोज़ के मुद्दों का समर्थन करते समय हमेशा उन लोगों को पहली प्रतिक्रिया देने के लिए कुछ करना पड़ता है: "क्या आपने अपने कंप्यूटर को रिबूट किया है?"
अब यह क्यों फायदेमंद हो सकता है, आपके पास ऐसे अनुप्रयोग हो सकते हैं जो अजीब स्थिति में आते हैं या जिनके पास स्मृति पुनरारंभ होता है, जो पुनरारंभ होता है।
मेरे लिए एक बड़ा नकारात्मक यह है कि आपको सर्वर के लिए साप्ताहिक डाउनटाइम शेड्यूल करना होगा। कुछ ऐसे लोगों के लिए जो कोई मुद्दा नहीं है, और दूसरों के लिए जो एक बड़ी समस्या है।
जाहिर है कि किसी समस्या का स्रोत समय-समय पर तय नहीं किया जा सकता है, इसे आसपास काम करना होगा। इसे ठीक करने के लिए रीबूट शेड्यूल करना व्यवसाय को बचाने के लिए एक आसान तरीका है यदि यह काम करता है।
निश्चित रूप से, यह मानसिक रूप से दर्द होता है और इसकी आवश्यकता नहीं होनी चाहिए और ऐसे समाधान के खिलाफ काम करना सबसे अच्छा होगा, खासकर अगर कोई समस्याग्रस्त सॉफ़्टवेयर के नियंत्रण में है या किसी फिक्स के लिए निर्माता को कुचलने की स्थिति में है या बस इसे प्रतिस्थापित करें। लेकिन अगर नहीं ..?
मुझे सिट्रिक्स फार्म में सर्वर के लिए ऐसा करना याद है, अंत में उन्हें उपयोगकर्ताओं को लॉग ऑफ करने, विशिष्ट सर्वर पर लॉग इन लॉक करने और फिर मुक्त करने के लिए प्रतीक्षा करने के लिए आधा जटिल स्क्रिप्ट के साथ हर रात रिबूट किया गया था। कारण एक पुराना 16 बिट 4 जीएल क्लाइंट एप्लिकेशन था जिसे हम केवल उस समय से छुटकारा नहीं पा रहे थे, जो अपटाइम के कुछ दिनों के बाद समग्र उपयोगकर्ता प्रतिक्रिया को अलग करने के लिए प्रेरित था।
मैं मानता हूं कि अधिकतर यह कारण समझने और इसे ठीक करने के लिए पर्याप्त स्मार्ट नहीं होने पर आधारित है - हर कोई रखरखाव या प्रेरित के रूप में अच्छी तरह से ज्ञात नहीं है जैसा हम चाहते हैं।
यह एक मूर्ख नीति है।
आप (और किसी भी तरह यह अपने बुनियादी ढांचे की स्थिरता के लिए कहते हैं) साप्ताहिक एक सर्वर रिबूट करने की आवश्यकता है, तो आप वास्तविक समस्या किसी सर्वर या अपने सॉफ्टवेयर के साथ कवर कर रहे हैं:
यहां इसका कारण बताया। एक स्मृति रिसाव? एक बुरा चालक? इन समस्याओं का समाधान को ठीक करें, उन्हें आलसी नीति के साथ कवर न करें।
सर्वर अक्सर कम से कम विंडोज़ दुनिया में अपडेट के लिए रीबूट हो जाते हैं। महत्वपूर्ण कर्नेल अद्यतनों के लिए रीबूटिंग वैसे भी होता है।
डेटाबेस सर्वर रैम में बहुत सारी जानकारी कैश करते हैं। जब आप अपने सर्वर को रीबूट करते हैं, तो यह कैश खाली और बहुत ठंडा हो जाता है। मान लें कि आपके पास एक सामान्य उपयोग पैटर्न है, एक ठंडा, खाली कैश उपयोगकर्ताओं के लिए धीमे प्रदर्शन के परिणामस्वरूप होगा जब वे रीबूट के बाद अपने प्रश्नों का प्रयास करेंगे। यह बैकअप जैसे कुछ प्रकार के रखरखाव करने के लिए आवश्यक समय भी बढ़ा सकता है क्योंकि डिस्क को और अधिक एक्सेस करने की आवश्यकता हो सकती है।
आपके सर्वर नीचे जायें!बैकअप और अन्य चीजों के लिए आपकी रखरखाव विंडो कम हो जाती है क्योंकि आपका सर्वर कुछ nonzero अवधि के लिए बंद है। आप अपने सिस्टम के आर्किटेक्चर के आधार पर अपने उपयोगकर्ताओं को यह बताना भी समाप्त कर सकते हैं कि आपके पास डाउनटाइम होगा।
आप यह मानते हुए चेतावनी के लिए सूचना प्रणाली के कुछ प्रकार की है, तो आप इसे कॉन्फ़िगर करने के लिए अपने डाउनटाइम खिड़की की अनदेखी करना होगा। यह आपके सर्वर रीबूट होने के दौरान होने वाली समस्याओं को मुखौटा कर सकता है, और कॉन्फ़िगरेशन की मात्रा में जोड़ता है जो आपको अपने सर्वर पर करने की आवश्यकता होगी।
कहा जा रहा है, कभी कभी संसाधनों है कि आप जरूरी पूर्ण नियंत्रण अपने हाथ में नहीं है पर एक अंतिम उपाय के रूप में फायदेमंद होते हैं रीबूट को (पुराने विक्रेता से लिखा सॉफ्टवेयर, "ब्लैक बॉक्स" जिन उपकरणों पर स्पष्ट रूप से विक्रेता द्वारा निर्धारित, आदि...)। लेकिन इसे मामले के आधार पर मामले में संभाला जाना चाहिए, न कि एक बेवकूफ कंबल नीति के साथ।
यह वास्तव में एक हैक है लेकिन यह सबसे कुशल हैक हो सकता है। यह एक 80:20 प्रकार की समस्या है जहां आप 20% प्रयास के साथ समस्या का 80% हल कर सकते हैं। यदि आप डाउनटाइम या डाउनटाइम से बच सकते हैं तो आप वास्तव में मूल कारण को ठीक करने से कम खर्च करते हैं तो यह एक अच्छा समाधान है। मैं व्यक्तिगत रूप से इसे पसंद नहीं करता लेकिन यह केवल इसलिए है क्योंकि यह एक साफ समाधान नहीं है।
मेरे अपने प्रश्न का उत्तर देना: लाभ है कि मैं नीति से देख रहा है, जब यह एक सर्वर क्लस्टर के लिए लागू किया जाता है में से एक, और प्रक्रियाओं एक से दूसरे नोड से विफल रहा है कर रहे हैं। इस तरह सभी नोड्स को सही सॉफ़्टवेयर इंस्टॉल के लिए लगातार परीक्षण किया जाता है।
एक और संभावना पर विचार करना है कि इस तरह के खुदरा स्टोर है कि दिन के 24 घंटे, एक "पास की दुकान" घटना खुले हैं के रूप में कुछ वातावरण में इतना है कि सर्वर अद्यतन किया जा सकता, बैक-अप, आदि
भीहालांकि सर्वर को "24x7" चलाने की आवश्यकता है, वे वास्तव में कम से कम कुछ मिनटों के लिए ऑफ़लाइन हैं।
प्रभावी रूप से हर दिन एक सर्वर रिबूट बनाता है यही कारण है कि, भले ही दुकान अभी भी काम कर रहा है जब ऐसा होता है।
पुराने धागे को धूलने के लिए माफ़ी।
मुझे लगता है कि हर कोई इस बिंदु को याद कर रहा है, खासकर मरने वाले 'रीबूट? मैं अपने कमोडोर को बेच दूंगा! निक्स प्रशासकों।
बिंदु यह है कि एक साप्ताहिक खिड़की अनुसूची होनी चाहिए।इसका मतलब यह नहीं है कि इसका उपयोग किया जाना चाहिए, वास्तव में वरीयता यह है कि इसका उपयोग सुबह के कुछ समय के लिए अनिवार्य रूप से नहीं किया जाता है।
लेकिन यदि यह वहां है, तो आप इसका उपयोग कर सकते हैं।
व्यक्तिगत रूप से, मुझे लगता है कि एक त्रैमासिक रीबूट एक बहुत अच्छा विचार है - यह आपको समस्याओं (हार्डवेयर और सॉफ्टवेयर) पर एक सिर दे सकता है, और अन्य पोस्टर की ओर इशारा करते हुए सबसे आगे की सोच के रूप में, आपको उन परिवर्तनों से अवगत कराता है जो आपको रोकते हैं चिकनी स्टार्टअप जो रीबूट के बाद ही स्पष्ट हो जाता है। बल्कि इस स्थिति को देखकर 4HR बिजली कटौती के बाद पैदा होती है जब एक और 2hrs लेने अपने बॉक्स को वास्तव में काफी शर्मनाक .... हो जाता है लाने के लिए की तुलना में
वहाँ अन्य upsides हैं ..
यह प्रयोग किया जाता है प्रबंधन हो जाता है रीबूट करने के लिए, और जब आपको वास्तव में रीबूट की आवश्यकता होती है (जैसे भौतिक रूप से इसे स्थानांतरित करना) तो आपका आत्मविश्वास होता है। यदि आप कभी भी बॉक्स को रीबूट नहीं करते हैं, तो जब आप कहते हैं कि इसे 4yrs के बाद रीबूट करने की आवश्यकता है और डाउनटाइम नहीं है तो आपका प्रबंधक बहुत परेशान हो जाएगा।
आप स्वयं को रीबूट करने के लिए उपयोग करते हैं, और जानते हैं कि ऑफ़लाइन होने पर क्या गलत हो सकता है।
आप जानते हैं कि कितनी देर तक रीबूट लेते हैं, इसलिए जब यह वापस आ रहा है और सामान्य से 10 मिनट लंबा लगता है, तो आप सीधे लॉग में हैं।
तुम कल एक बस से नीचे गिरा दिया हो जाता है, वहाँ क्या होता है जब एक रिबूट होता है पर वर्तमान (4yr नहीं पुराने) प्रलेखन (यह मानते हुए आप एक अच्छा व्यवस्थापक हैं और चीजों को लिख)
एक 30minute प्रति तिमाही रीबूट 99.9% अपटाइम एसएलए के भीतर अच्छी तरह से फिट बैठता है।
अंततः यह प्रोवर्बियल कोबवेज़ को साफ़ करता है।
एक बुरा ड्राइवर \ स्मृति रिसाव आदि को छुपाने के बारे में एक हास्य है नियमित रूप से रिबूट के खिलाफ कुछ बातों का उत्तर देने के ..
। जब तक आप सर्वर को रीबूट नहीं करते हैं, तब तक आप कैसे जानते हैं कि यह एक स्मृति रिसाव \ खराब ड्राइवर है? इतना ही नहीं, लेकिन अगर आप इसे अपने नियोजित डाउनटाइम में ठीक करने का प्रबंधन नहीं करते हैं तो क्या होगा? यदि आपके पास साप्ताहिक अनुसूचित विंडो है तो इसमें कोई समस्या नहीं है! आप बस अगले हफ्ते फिर कोशिश करें ....
अधिसूचना प्रणाली - यदि आपके पास योजनाबद्ध विंडो है, तो आप एक नियोजित अपवाद सेट कर सकते हैं। यदि आपका सॉफ़्टवेयर \ स्क्रिप्ट ऐसा नहीं करता है, तो मैं आधुनिक सॉफ्टवेयर \ बेहतर स्क्रिप्ट लेखन का सुझाव देता हूं।
योजनाबद्ध अपवाद विंडो के लिए 'योजनाबद्ध अपवाद विंडो के दौरान होने वाली समस्याएं' छिपाने वाली समस्याओं के लिए जो कि बस हंसने योग्य है। यदि आप उनकी समीक्षा करते हैं तो आपके अन्य सर्वर आंकड़े इस समस्या को बहुत जल्दी दिखाएंगे।
बेशक एक कंबल नीति अनुशंसित नहीं है, और आप अपवाद के लिए मापदंड
(एक निश्चित आकार आदि से अधिक डिस्क स्थान जैसे) ने कहा करने के बाद कि, लब्बोलुआब यह है होना चाहिए सिर्फ इसलिए कि अपने सर्वर shouldn रीबूट करने की आवश्यकता नहीं है, यह सोचने के लिए अविश्वसनीय रूप से निष्पक्ष है कि आपको इसे रीबूट नहीं करना चाहिए ....
संपादित करें:
मुझे यकीन है कि मैं यह पर्याप्त स्पष्ट कर दिया नहीं कर रहा हूँ, लेकिन रिबूट नहीं एक समस्या के ऊपर प्लास्टर के लिए इस्तेमाल किया जाना चाहिए। खिड़की साप्ताहिक होनी चाहिए ताकि आप इस मुद्दे को हल करने के प्रयासों को दोहरा सकें, न कि 'इसके साथ रहना'।
सर्वर पर किसी समस्या से निपटने की विधि के रूप में रीबूटिंग खराब sysadmin है। कुछ भी नहीं सीखा है और यह लोगों के मूल्यवान समय को बर्बाद कर देता है और (सही) आपके प्रबंधन की राय को कम करता है।
मेरे बिंदु
आप सही हैं, अनुसूचित रीबूट आलसी के लिए हैं –