हम Servers को क्यों Reboot करते हैं

एक ऐसा प्रश्न जो काफी नियमित आधार पर सामने आता है वह यह है कि servers को नियमित रूप से reboot किया जाना चाहिए — जैसे सप्ताह में एक बार — या उन्हें अधिकतम “uptime” प्राप्त करने के लिए जितना संभव हो उतना लंबे समय तक चलने दिया जाना चाहिए। मेरे लिए जवाब सरल है — दुर्लभ अपवाद के साथ, servers के लिए नियमित reboots सबसे उपयुक्त विकल्प हैं।

किसी भी नियम की तरह, ऐसे मामले हैं जब यह लागू नहीं होता। उदाहरण के लिए, critical systems चलाने वाले कुछ व्यवसायों में downtime के लिए कोई allotment नहीं है और उन्हें 24/7 उपलब्ध होना चाहिए। जाहिर है इस तरह के systems को routine तरीके से बस reboot नहीं किया जा सकता। हालाँकि, यदि कोई system इतना critical है कि वह कभी बंद नहीं हो सकता तो यह स्थिति एक red flag trigger करती है कि यह system failure का एक बिंदु है और शायद इस बारे में विचार शुरू होना चाहिए कि planned या unplanned downtime को कैसे handle किया जाए।

एक और अपवाद यह है कि कुछ AIX systems को maximum efficiency प्राप्त करने के लिए कुछ हफ्तों से अधिक significant uptime की जरूरत होती है क्योंकि system self-tuning है और उपयोग की जानकारी प्राप्त करने और खुद को तदनुसार adjust करने के लिए समय की जरूरत होती है। यह आम तौर पर बड़े, कम बदलने वाले database servers और इसी तरह के उपयोग परिदृश्यों तक सीमित होता है जो अन्य platforms की तुलना में कम सामान्य हैं।

IT में हम अक्सर “uptime” की अवधारणा की पूजा करते हैं — कोई system restart की जरूरत के बिना कितने समय तक चल सकता है। लेकिन “uptime” एक ऐसी अवधारणा नहीं है जो business को value लाती है और IT को हमेशा artificial metrics पर ध्यान केंद्रित करने के बजाय business की जरूरतों को ध्यान में रखना चाहिए। Business इस बात से concerned नहीं है कि एक server reboot किए बिना कितने समय तक online रहने में कामयाब रहा — वे केवल इस बात की परवाह करते हैं कि server business processing के लिए जरूरत पड़ने पर available और ready हो। ये बहुत अलग अवधारणाएँ हैं।

किसी भी सामान्य business server के लिए, एक window होती है जब server business उद्देश्यों के लिए available होने की जरूरत होती है और एक window होती है जब इसकी जरूरत नहीं होती। ये windows daily, weekly या monthly हो सकती हैं लेकिन यह एक दुर्लभ server है जो वास्तव में बिना किसी अपवाद के चौबीसों घंटे उपयोग में हो।

मैं अक्सर लोगों को यह कहते सुनता हूँ कि चूँकि वे operating system X की बजाय Y चलाते हैं इसलिए उन्हें अब reboot करने की जरूरत नहीं है, लेकिन यह सच नहीं है। नियमित रूप से reboot करने के दो मुख्य कारण हैं: server की सफलतापूर्वक reboot करने की क्षमता को verify करना और वे patches लागू करना जो reboot किए बिना लागू नहीं किए जा सकते।

Patches लागू करना ही वह कारण है जिसके लिए अधिकांश businesses reboot करते हैं। लगभग सभी operating systems को नियमित updates मिलते हैं जिन्हें प्रभावी होने के लिए reboot की जरूरत होती है। चूँकि अधिकांश patches security और stability उद्देश्यों के लिए जारी किए जाते हैं — विशेष रूप से वे जिनके लिए reboot की जरूरत होती है — उन्हें लागू करने का महत्व काफी अधिक है। Uptime बनाए रखने के लिए एक server को अनावश्यक रूप से vulnerable बनाना बुद्धिमानी नहीं है।

Server की सफलतापूर्वक reboot करने की क्षमता का परीक्षण करना वह है जो अक्सर अनदेखा किया जाता है। अधिकांश servers पर नियमित आधार पर changes लागू किए जाते हैं। Changes patches, नए applications, configuration changes, updates या इसी तरह की हो सकती हैं। कोई भी change जोखिम पेश करती है। सिर्फ इसलिए कि change लागू होने के तुरंत बाद server स्वस्थ है इसका मतलब यह नहीं है कि server या उस पर चलने वाले applications reboot पर expected रूप से start होंगे।

यदि server को कभी reboot नहीं किया जाता तो हम कभी नहीं जानते कि वह सफलतापूर्वक reboot कर सकता है या नहीं। समय के साथ last reboot के बाद से लागू किए गए changes की संख्या बढ़ती जाएगी। यह बहुत खतरनाक है। हम जो डरते हैं वह यह है कि बड़ी संख्या में changes की गई हों — संभवतः उनमें से कई undocumented — और फिर reboot fail हो जाए। उस बिंदु पर यह पहचानना कि कौन सी change system को fail करा रही है एक insurmountable process हो सकती है। Roll back करने के लिए कोई single change नहीं, recoverability के लिए कोई ज्ञात path नहीं। यही वह समय है जब घबराहट शुरू होती है। बेशक, एक box जो जानबूझकर कभी reboot नहीं किया जाता वह अनजाने में reboot होने की अधिक संभावना है — जिसका अर्थ है कि failed reboot की संभावना दोनों अधिक होने और active use के दौरान होने की अधिक संभावना है।

जबकि नियमित reboots का उद्देश्य failed reboots की आवृत्ति को कम करना नहीं है — वास्तव में वे failures की घटना को बढ़ाते हैं — उद्देश्य उन failures को “known change” दृष्टिकोण से easily manageable बनाना है और, इससे भी अधिक महत्वपूर्ण, उन reboots को control करना है ताकि यह सुनिश्चित हो सके कि वे उस समय होते हैं जब server maintenance के लिए available के रूप में designated है और इस तरह से designed है कि समस्याएँ उस समय मिलें जब उन्हें business impact के बिना mitigate किया जा सकता है।

मैंने कई system administrators को यह कहते सुना है कि वे weekend reboots से बचते हैं क्योंकि वे रविवार को reboot के बाद servers के back up न आने के कारण काम नहीं करना चाहते। मुझे खुद भी failed reboot से कई बार रविवार की सुबह page किया गया है, लेकिन हर बार जब मुझे वह call आती है तो मुझे राहत का एहसास होता है। मुझे पता है कि हमने बस एक ऐसे समय में एक issue पकड़ा है जब business financially impact नहीं हो रहा है। यदि उस server को off hours के दौरान restart नहीं किया गया होता, तो हो सकता है कि active business hours के दौरान fail होने तक इसे “unbootable” के रूप में discovered न किया गया होता और revenue की loss हुई होती।

नियमित weekend reboots के लिए धन्यवाद, हम pending disasters को safely catch कर सकते हैं और, यह जानने के कारण कि हमारे पास investigate करने के लिए केवल एक सप्ताह की changes हैं, हम आम तौर पर generally कम effort और इस बारे में बड़े confidence के साथ समस्याओं को ठीक करने में सक्षम होते हैं कि failure से पहले कौन सी changes की गई थीं।

नियमित reboots business को ऐसे outages और downtime से बचाने के बारे में हैं जिन्हें बहुत simple और reliable processes के माध्यम से mitigate किया जा सकता है।