VPN सर्वर की डिस्क वृद्धि कहाँ से आती है और उसे कैसे सीमित करें

टनल कनेक्शन स्वीकार करना बंद कर देता है, सेवा दो बार फिर से शुरू होती है, और फिर उसके लॉग में कुछ नहीं दिखता। वही चुप्पी सुराग है, क्योंकि डिस्क को भरने वाला लॉग ही है और डेमन के पास वह त्रुटि लिखने की जगह नहीं है जिसका आप इंतज़ार कर रहे हैं। कोई भी लंबे समय तक चलने वाली सेवा उस स्थिति तक पहुँच सकती है, और logs नाम की डायरेक्टरी हटाना उसे शायद ही ठीक करता है। टिकाऊ समाधान यह जानना है कि कौन-सा भंडार बढ़ा, उसके प्रतिधारण का स्वामी कौन है, और क्या लेखक ने वास्तव में जगह छोड़ी है।

जो भंडार बढ़ा और जिस दर से बढ़ा, उसे खोजें

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

df -h /var
df -i /var

फिर वृद्धि को किसी स्वामी से जोड़ें। journal का अपना उपयोग आँकड़ा केवल journal को ही कवर करता है, और वह कभी उस डेमन को नहीं देखेगा जो अपनी कॉन्फ़िगरेशन फ़ाइल के किसी पथ पर लिख रहा है।

journalctl --disk-usage

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

रोटेशन किसी खुली फ़ाइल के साथ क्या करता है

लॉग फ़ाइल एक नाम है जो किसी inode की ओर इशारा करता है, और जगह तभी लौटती है जब अंतिम खुला हैंडल बंद होता है। फ़ाइल का नाम बदलें तो लेखक उसी inode को भरता रहता है; उसे हटा दें तो लेखक बिना किसी नाम वाले inode को भरता रहता है। यही स्थिति बताती है कि ‘मैंने फ़ाइल हटा दी और डिस्क भरी रही’ वाक्य फ़ाइल डिस्क्रिप्टर का वर्णन करता है, टूटे फ़ाइलसिस्टम का नहीं। लेखक को फिर से शुरू करना, या ऐसा रोटेशन मोड चुनना जो फ़ाइल को फिर से खोले, वही ब्लॉक वास्तव में लौटाता है।

lsof +L1 | head

नीति उसी घटक की है जो फ़ाइल लिखता है। journal अपनी कॉन्फ़िगरेशन फ़ाइल से अपनी भंडारण सीमाएँ लागू करता है, जबकि फ़ाइल-आधारित सेवा आमतौर पर logrotate पर निर्भर करती है, या तो बनाने के नियम और पुनः खोलने के संकेत के साथ, या जब लेखक फिर से न खोल सके तो मौके पर ही काटने के मोड के साथ। पहले कुछ भी बदले बिना निर्णय की पुष्टि करें:

logrotate -d /etc/logrotate.conf

सीमा कहाँ होनी चाहिए और कितनी बड़ी होनी चाहिए

सीमा वहाँ रखें जहाँ लेखक कॉन्फ़िगर है, माउंट पॉइंट पर नहीं। पूरे वॉल्यूम पर कोटा होस्ट की रक्षा करता है पर यह नहीं बताता कि कौन-सी सेवा पहले विफल होगी, और वैश्विक सफ़ाई स्क्रिप्ट अगली घटना को जरूरी सबूत हटा देती है। journal की सीमा, अधिकतम आकार के साथ रोटेशन संख्या, और एप्लिकेशन-स्तरीय प्रतिधारण, हर एक एक उत्पादक को बाँधता है। साथ मिलकर वे कुल को बाँधते हैं; अकेले में हर एक अनुमान है।

उस सीमा को उस प्रतिधारण से तय करें जिसका आप बचाव कर सकते हैं, उपलब्ध खाली जगह से नहीं। अगर समीक्षा को एक सप्ताह के कनेक्शन प्रयास चाहिए, तो journal को सबसे व्यस्त अपेक्षित दर पर एक सप्ताह रखना होगा, और वह दर पहले मापी गई संख्या है।

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

रीस्टार्ट के बाद सीमा जाँचें

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

systemctl restart systemd-journald
journalctl --disk-usage

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

अगली रीडिंग की इससे तुलना करें

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

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

लिख लें कि क्या रखा जाता है, कहाँ, कितने समय तक, और कौन उसे हटाता है। वही वाक्य परिणाम है, और यह इस काम का एकमात्र हिस्सा है जो अगले रीस्टार्ट में बचता है।