मेरे पास कई लिनक्स सर्वर (SUSE 9 और 10) वेब सेवाओं को चलाने के लिए उपयोग किए जाते हैं जो बड़ी गणना ग्रिड को डेटा प्रदान करते हैं। हाल ही में हमें आउटेज की व्याख्या करने में कुछ मुश्किल हुई है (यानी हार्डवेयर और सॉफ्टवेयर लॉग कोई स्पष्ट त्रुटि नहीं दिखा रहे हैं) और हमें आश्चर्य है कि क्या लंबे समय तक (आमतौर पर 200-300 दिन) यह मुद्दा है। यह देखते हुए कि इन सर्वरों का भारी उपयोग किया जाता है, क्या मुझे एक नियमित रिबूट चक्र पर विचार करना चाहिए?
जवाबों:
आपको कर्नेल अपडेट के बाद रिबूट करना होगा (जब तक आप केएसप्लिस का उपयोग नहीं कर रहे हैं), कुछ भी वैकल्पिक है। व्यक्तिगत रूप से मैं एक मासिक चक्र पर एक रखरखाव विंडो के दौरान रिबूट करता हूं ताकि यह सुनिश्चित हो सके कि सर्वर और सभी सेवाएं अपेक्षित रूप से वापस आ सकें। इस तरह मैं यथोचित रूप से निश्चित हो सकता हूं अगर मुझे एक शेड्यूल रिबूट (यानी क्रिटिकल कर्नेल अपडेट) करना है जो सिस्टम ठीक से वापस आ जाएगा। सर्वर और सेवाओं की स्वचालित निगरानी (यानी नागियोस) भी इस प्रक्रिया में मदद करने के लिए एक लंबा रास्ता तय करती है (रिबूट, रोशनी को लाल देखें और फिर उम्मीद है कि सभी वापस हरे रंग में जाएं)।
पुनश्च यदि आप नियमित रूप से रिबूट करते हैं, तो आप यह सुनिश्चित करना चाहेंगे कि आप अपने fsck चेक्स को ट्यून करें (यानी चेक के बीच अधिकतम माउंट गणना, अन्यथा सर्वर को डेटा के एक जोड़े टेराबाइट्स को fsck'ing शुरू करने पर त्वरित 2 मिनट रिबूट में 30 मिनट लग सकते हैं। मैं आम तौर पर अपने माउंट काउंट को 0 (धुन 2 एफसी -सी 0) और चेक के बीच के अंतराल को 6 महीने या उससे अधिक समय के लिए सेट करता हूं और फिर मैन्युअल रूप से एक बार में हर बार एक फॉस्क को मजबूर करता हूं और गिनती को रीसेट करता हूं।
मैं वास्तव में काफी नियमित रूप से अपने सर्वर को रिबूट करता हूं, किसी भी समय बड़े कॉन्फ़िगरेशन परिवर्तन किए जाते हैं। यह जानना महत्वपूर्ण है कि आपातकालीन स्थिति में सर्वर सॉफ्टवेयर बिना किसी परेशानी के आएगा। आखिरी चीज जो आप चाहते हैं वह ऐसी स्थिति में है जहां आप एक आउटेज से उबरने की कोशिश कर रहे हैं, लेकिन अपने सर्वर कॉन्फ़िगरेशन के साथ गड़बड़ कर रहे हैं क्योंकि आपने इसे सेट करते समय पूरी तरह से परीक्षण नहीं किया था।
लिनक्स सर्वर को कभी भी रिबूट करने की आवश्यकता नहीं है जब तक कि आपको चलने वाले कर्नेल संस्करण को बदलने की बिल्कुल आवश्यकता नहीं है। अधिकांश समस्याओं को एक कॉन्फ़िगरेशन फ़ाइल को बदलकर और init स्क्रिप्ट के साथ सेवा को पुनरारंभ करके हल किया जा सकता है।
आपको रिबूट के लिए बाहर देखने की जरूरत है ... यदि आपने सेवा के कॉन्फ़िगरेशन फ़ाइल में आपके परिवर्तनों को प्रतिबिंबित किए बिना "फ्लाई पर" कुछ भी बदल दिया, तो रिबूट के बाद उन परिवर्तनों को लागू नहीं किया जाएगा।
मैं आमतौर पर निर्धारित सिस्टम अपडेट के बाद रिबूट करता हूं, हालांकि। यह आम तौर पर आवश्यक नहीं है, लेकिन मैं उन्हें करता हूं जब कोई भी कार्यालय में नहीं होता है, तो क्यों नहीं? जब भी मुझे अपडेट करने के लिए मिलता है, अक्सर कर्नेल अपग्रेड होते हैं।
वास्तव में आवश्यक नहीं, लिनक्स मेमोरी हैंडलिंग उत्कृष्ट है। लेकिन अगर आप उस लंबाई से परेशान हैं, तो आप शायद गुठली चला रहे हैं, जो कमजोरियों को जानते हैं - जिसे आप देखना चाहते हैं।
मुझे लगता है कि अगर आपको हाल ही में कर्नेल अपडेट या एक libc अपडेट किया गया है तो आपको रिबूट करना चाहिए। बहुत सारी चीजें लिबक से जुड़ी होती हैं और यह वास्तव में मेमोरी से लिबास को पूरी तरह से उतारने और नए संस्करण के साथ बदलने की नहीं है जब तक कि आप रिबूट नहीं करते हैं।
उदाहरण के लिए, यहां तक कि बुनियादी चीजें जैसे / बिन / एलएस और अन्य चीजें / बिन का उपयोग करते हैं। यदि आप केवल कंसोल चला रहे हैं और बैश का उपयोग कर रहे हैं, तो आप लिबास का उपयोग कर रहे हैं।
$ ldd /bin/bash
linux-gate.so.1 => (0xffffe000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0xb8029000)
libdl.so.2 => /lib/libdl.so.2 (0xb8025000)
libc.so.6 => /lib/libc.so.6 (0xb7ed9000)
/lib/ld-linux.so.2 (0xb804b000)
$ ldd /bin/ls
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib/librt.so.1 (0xb7f3a000)
libacl.so.1 => /lib/libacl.so.1 (0xb7f33000)
libc.so.6 => /lib/libc.so.6 (0xb7de7000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7dd0000)
/lib/ld-linux.so.2 (0xb7f61000)
libattr.so.1 => /lib/libattr.so.1 (0xb7dcc000)
और हाँ, यदि आप /etc/init.d में फ़ाइलों को बदलते हैं जो किसी तरह स्टार्टअप को प्रभावित करते हैं, तो मैं एक रिबूट की सिफारिश करूंगा। आप यह नहीं पता लगाना चाहते हैं कि आपने स्टार्टअप फ़ाइल में एक छोटी सी गलती की है जब आपको चीजों की आवश्यकता होती है और जल्दी से फिर से चलती है।
यदि कोई सर्वर रिबूट के बिना कई दिनों तक चला गया है तो इसका वास्तव में मतलब है कि यह सुनिश्चित करने का कोई तरीका नहीं है कि यह फिर से ठीक से आएगा। एक बार फिर ऐसा इसलिए है क्योंकि बहुत सारी कॉन्फिग फाइल्स को इस पर बदला जा सकता है, और यह सुनिश्चित करने के लिए किसी ने इसे लंबे समय तक रिबूट नहीं किया है। इसके अलावा, यदि सर्वर में बहुत सारे अपडेट होने के कारण और आपने लंबे समय तक रिबूट नहीं किया है, तो अपडेट अपडेट करने से पहले रिबूट करें, अन्यथा यदि कोई समस्या है, तो आप सुनिश्चित नहीं कर सकते कि यह कॉन्फ़िगरेशन त्रुटि के कारण हुआ है बहुत समय पहले या आपके द्वारा लागू किए गए नए अपडेट।
अंत में, यदि आप एक महत्वपूर्ण सर्वर को बहुत लंबे समय के बाद रिबूट करते हैं, तो इसका मतलब यह हो सकता है कि आपको वापस आने के लिए अभी बहुत लंबा समय इंतजार करना होगा। इससे बचने के लिए आप ट्यून 2 एफ का उपयोग कर सकते हैं, लेकिन यह एक अच्छा विचार है कि मैं इसे नियमित रूप से जांचता हूं। यही कारण है कि आपको उस स्थिति में नहीं होना चाहिए जहां आप सिर्फ 1 सर्वर पर निर्भर हैं और यदि वह जाता है, तो आपकी पूरी वेबसाइट चली गई है। आपके पास स्टैंडबाय पर एक और होना चाहिए।
इस अप्रत्याशित डाउनटाइम के दौरान देखने के लिए एक और बात, यह देखना है कि मेमोरी और प्रोसेसर का उपयोग किस तरह से और किन कार्यक्रमों द्वारा किया जा रहा है।
topयह निर्धारित करने में सक्षम होना चाहिए कि संसाधनों के नुकसान के लिए कौन सी प्रक्रियाएं दोषी हैं, और फिर उन्हें सीधे प्रबंधित करने में सक्षम हो। एक और विचार एक क्रोनजोब को बंद करने और एक विशिष्ट समय पर अपनी प्रक्रियाओं को फिर से शुरू करने के लिए होगा।
यह रिबूट करने के लिए एक बुरा विचार नहीं है अगर यह लंबे समय से है तो आप रूट विभाजन पर डिस्क चेक (fsck) चला सकते हैं। आपका तर्क यह हो सकता है कि इससे डेटा अखंडता सुनिश्चित करने में मदद मिलती है।
ठीक से चलने वाले लिनक्स सर्वर को केवल कर्नेल अपडेट के लिए रिबूट करने की आवश्यकता होनी चाहिए। उसी को हमेशा कुछ सॉफ्टवेयर के लिए नहीं कहा जा सकता है - उदाहरण के लिए, मुझे कभी-कभी एपाचे 2 या मेलमैन को फिर से शुरू करना पड़ता है।
मेरी अवसंरचना में दो डेटा साइटें हैं, अल्फा (जहां संचालन दैनिक आधार पर होता है) और बीटा (बैकअप साइट, अगर अल्फा में खराब चीजें गलत हैं)। हालाँकि यह वर्तमान में ऐसा नहीं है, मैं हर 6 महीने में अल्फा साइट पर शेड्यूल डाउन करने पर जोर दे रहा हूं, ताकि हम सभी सेवाओं को बीटा से चला सकें।
यह दो चीजों को पूरा करेगा। सबसे पहले, यह साबित होगा कि हमारी आपदा वसूली साइट पूरी तरह से व्यवहार्य है। दूसरा, यह मुझे अल्फा पर संचित cruft को हटाने के लिए एक सप्ताह का समय देगा।
जैसा कि है, मैं अपने सर्वर को बार-बार रिबूट नहीं करना चाहिए। मैं अन्य पोस्टरों से सहमत हूं जिन्होंने कहा कि यह जानना महत्वपूर्ण है कि आपके सर्वर को आपकी आवश्यकता होने पर वापस आ जाएगा। आप "सोचना" नहीं चाहते कि वे करेंगे, केवल यह पता लगाने के लिए कि आपने कुछ बदल दिया है और इसे सही तरीके से नहीं किया है, या इसे दस्तावेज नहीं किया है।
आप अतिरिक्त रूप से कुछ स्क्रिप्ट लिख सकते हैं जो जांच करेगी (जितना संभव हो सके), यदि आपकी मशीन की वर्तमान स्थिति, मशीन पोस्ट-रिबूट की स्थिति होने जा रही है।
इससे मेरा मतलब क्या है ...
/etc/init.d/*
/etc/fstab
/etc/mtab) में एक समान प्रविष्टि है/etc/fstab/etc/fstabभी वर्तमान में आरोहित हैं।यह निश्चित रूप से किसी भी तरह से पूरी तरह से जाँच नहीं है, लेकिन यह रिबूट के बाद की परेशानियों के जोखिम को कम करता है।
इसके अतिरिक्त, आपको सर्वर पैकेज अपडेट के लिए एक नीति निर्धारित करनी चाहिए, कुछ समझदार क्रम में, प्रति सप्ताह 1 समूह कहें ...
इसके अलावा एक समग्र योजना है, जैसे "सभी सर्वर हर 6 महीने में एक बार पूर्ण ओएस अपग्रेड के माध्यम से जाएंगे"।
सर्वर पर चल रहे कार्यों पर निर्भर करता है। कुछ वर्चुअल सर्वर के लिए हम अक्सर अपाचेक्टल रीस्टार्ट के बजाय रिबूट का उपयोग करते हैं और इसमें केवल 5-10 सेकंड अधिक समय लगता है। लेकिन कुछ भारी भरी हुई मशीनों को प्रति वर्ष कई बार रिबूट किया जाता है, इस प्रक्रिया की पूरी निगरानी करने वाले चालक दल के साथ।