VPN সার্ভারের ডিস্ক বৃদ্ধি কোথা থেকে আসে এবং কীভাবে তা সীমিত করবেন

টানেল আর সংযোগ নেয় না, সার্ভিসটি দুইবার রিস্টার্ট হয়, তারপর তার লগে কিছুই দেখা যায় না। ওই নীরবতাই সূত্র, কারণ ডিস্কটি ভরিয়েছে লগই, আর যে ত্রুটির জন্য আপনি অপেক্ষা করছেন তা লেখার জায়গা ডেমনের নেই। যেকোনো দীর্ঘদিন চলা সার্ভিস এই অবস্থায় পৌঁছাতে পারে, আর logs নামের একটি ডিরেক্টরি মুছে ফেললে তা খুব কমই ঠিক হয়। টেকসই সমাধান হলো জানা কোন ভান্ডারটি বেড়েছে, তার ধরে রাখার নীতি কার, আর লেখক সত্যিই জায়গাটি ছেড়ে দিয়েছে কি না।

যে ভান্ডারটি বেড়েছে এবং যে হারে বেড়েছে তা খুঁজুন

সহজে ভুলে যাওয়া দুটি সংখ্যা দিয়ে শুরু করুন: মুক্ত ব্লক আর মুক্ত inode। একটি ফাইলসিস্টেম প্রচুর জায়গা জানিয়ে দিয়েও লেখা প্রত্যাখ্যান করতে পারে, কারণ আর inode বাকি নেই, আর এটি ঘটে যখন একটি সার্ভিস প্রতি সেশনে একটি করে ফাইল তৈরি করে। একই ভলিউমে দুটো পাঠই চান, কারণ একই বিকেলেই উত্তর দুটি মিলতে নাও পারে। হোস্ট সুস্থ থাকার সময় এটি করুন, যাতে সংখ্যাগুলো স্বাভাবিক কাজ বোঝায়, কোনো বিভ্রাট নয়।

df -h /var
df -i /var

তারপর বৃদ্ধিটিকে একটি মালিকের নামে চিহ্নিত করুন। জার্নালের নিজস্ব ব্যবহারের সংখ্যা শুধু জার্নালকেই ধরে, আর এটি কনফিগারেশন ফাইলের কোনো পথে লেখা ডেমনকে কখনো দেখবে না।

journalctl --disk-usage

সময়ের সঙ্গে বৃদ্ধি যেকোনো একক পাঠের চেয়ে বেশি বলে। চালু রেখে দেওয়া ডিবাগ স্তর, প্রতিটি চেষ্টা লগ করা রিট্রাই লুপ, বা কেউ বন্ধ না করা ক্যাপচার ফাইল: প্রত্যেকটিই এক মুহূর্তে সাধারণ, এক ঘণ্টা পরে উদ্বেগজনক দেখাতে পারে। একটি পাঠ নিন, ব্যস্ত সময় পার হওয়া পর্যন্ত অপেক্ষা করুন, আরেকটি নিন, এবং ব্যবধান দিয়ে ভাগ করুন। যে হার বলতে পারেন, তা ধারণক্ষমতাকে আগুন নয়, সিদ্ধান্তে পরিণত করে।

রোটেশন একটি খোলা ফাইলে কী করে

লগ ফাইল হলো inode-এর দিকে নির্দেশ করা একটি নাম, আর জায়গা ফেরে কেবল তখনই যখন শেষ খোলা হ্যান্ডেল বন্ধ হয়। ফাইলের নাম বদলান, লেখক একই inode ভরাতেই থাকে; মুছে ফেলুন, লেখক নামহীন একটি inode ভরাতেই থাকে। এই অবস্থার কারণেই ‘ফাইলটি মুছেছি, তবু ডিস্ক পূর্ণ রইল’ কথাটি ভাঙা ফাইলসিস্টেম নয়, ফাইল ডেসক্রিপ্টর বোঝায়। লেখক রিস্টার্ট করা, বা এমন রোটেশন মোড বেছে নেওয়া যা ফাইলটি আবার খোলে, সেটাই ব্লকগুলো সত্যিই ফেরায়।

lsof +L1 | head

নীতি ফাইলটি যে উপাদান লেখে তারই। জার্নাল নিজের কনফিগারেশন ফাইল থেকে নিজের স্টোরেজ সীমা প্রয়োগ করে, আর ফাইলভিত্তিক সার্ভিস সাধারণত logrotate-এর উপর নির্ভর করে: হয় তৈরি করার নিয়ম আর পুনরায় খোলার সিগন্যাল, নয়তো লেখক আবার খুলতে না পারলে জায়গাতেই ছেঁটে দেওয়ার মোড। প্রথমে কিছু না বদলেই সিদ্ধান্তটি নিশ্চিত করুন:

logrotate -d /etc/logrotate.conf

সীমাটি কোথায় থাকা উচিত এবং কত বড় হওয়া উচিত

সীমাটি সেখানে রাখুন যেখানে লেখক কনফিগার করা, মাউন্ট পয়েন্টে নয়। পুরো ভলিউমের কোটা হোস্টকে রক্ষা করে, কিন্তু কোন সার্ভিস আগে ব্যর্থ হবে তা বলে না, আর একটি বৈশ্বিক পরিষ্কার স্ক্রিপ্ট পরের ঘটনার জন্য প্রয়োজনীয় প্রমাণ মুছে ফেলার দিকে ঝোঁকে। জার্নাল সীমা, সর্বোচ্চ আকারসহ রোটেট সংখ্যা, আর অ্যাপ্লিকেশন-স্তরের ধরে রাখা: প্রত্যেকটি একটি উৎপাদককে সীমিত করে। একসাথে তারা মোটটিকে সীমিত করে; আলাদা আলাদা প্রত্যেকটি একটি অনুমান।

সীমাটি নির্ধারণ করুন সেই ধরে রাখার মেয়াদ থেকে যা আপনি যুক্তি দিয়ে রক্ষা করতে পারেন, খালি জায়গা থেকে নয়। যদি পর্যালোচনার জন্য এক সপ্তাহের সংযোগ-চেষ্টা দরকার হয়, জার্নালকে ব্যস্ততম প্রত্যাশিত হারে এক সপ্তাহ ধরে রাখতে হবে, আর সেই হারই আগে মাপা সংখ্যা।

ডিবাগ লগিং একটি অস্থায়ী মোড, যার শুরু করার সময় লিপিবদ্ধ থাকে, এটি স্টোরেজ পরিকল্পনা নয়। গোপনীয়তার প্রশ্নটি একই সিদ্ধান্তের ভেতরে রাখুন, কারণ সংযোগ লগে ঠিকানা আর শনাক্তকারী থাকে। দীর্ঘতর ধরে রাখাও তথ্য পরিচালনার সিদ্ধান্ত, এবং এটি এমন কারও নেওয়া উচিত যিনি দুটো সীমাবদ্ধতাই জানেন।

রিস্টার্টের পরে সীমাটি যাচাই করুন

যে ধরে রাখার পরিবর্তন পরের রিবুট পর্যন্ত টেকে, তা পরিবর্তন নয়। লেখক রিস্টার্ট করুন, নতুন সীমা কার্যকর হয়েছে নিশ্চিত করুন, এবং পরে রোটেশন এখনো চলে কি না দেখুন। জার্নালের জন্য একটি রিস্টার্ট আর একটি ব্যবহার-পাঠ দুটো প্রশ্নেরই উত্তর দেয়:

systemctl restart systemd-journald
journalctl --disk-usage

ফাইলভিত্তিক সার্ভিসের জন্য রোটেশন কাজটি একবার হাতে চালান এবং ফাইলটি প্রতিস্থাপিত হয়েছে ও ডেসক্রিপ্টর আবার খুলেছে নিশ্চিত করুন। পুরোনো হ্যান্ডেল ধরে রাখা লেখক উপরিতলের পরীক্ষায় পাশ করে, আর পরেরবার ভলিউম ভরে গেলে ব্যর্থ হয়। পরীক্ষার সময় খালি জায়গা লক্ষ্য করুন, কারণ ফাইল ছোট হয়েছে অথচ জায়গা ফেরেনি মানে পুরোনো inode এখনো ধরে রাখা আছে।

পরের পাঠটিকে এই পাঠের সঙ্গে তুলনা করুন

এক সপ্তাহ পরে ফিরে এসে বৃদ্ধির হার লিপিবদ্ধ হারের সঙ্গে তুলনা করুন। মিলে যাওয়া হার মানে সীমা টিকছে আর কাজের চাপ স্থিতিশীল; দ্বিগুণ হার মানে কিছু বদলেছে, আর উপকারী প্রশ্নটি হলো কী বদলেছে। প্রথমে বারবার ব্যর্থতার জন্য লগের বিষয়বস্তু পড়ুন, কারণ রিট্রাই লুপ একইসঙ্গে উপসর্গ আর আয়তনের কারণ। তারপর নতুনভাবে চালু হওয়া সবকিছু দেখুন, যার মধ্যে ঘটনার সময় চালু হয়ে কখনো বন্ধ না হওয়া ডিবাগ স্তরও আছে।

ব্যাকআপ একই ভলিউমের বাইরে রাখুন, নয়তো মেনে নিন একটি পূর্ণ ডিস্ক ব্যাকআপটিকেও নিয়ে যাবে। যে হোস্টকে এটি রক্ষা করে সেই হোস্টেই লেখা কপি পুনরুদ্ধার পরিকল্পনা নয়, আর তার ধরে রাখার আলাদা উত্তর দরকার।

কী ধরে রাখা হয়, কোথায়, কতদিন, আর কে তা সরায়—এটি লিখে রাখুন। ওই বাক্যটিই প্রদেয় ফল, আর এটি এই কাজের একমাত্র অংশ যা পরের রিস্টার্টেও টিকে থাকে।