OpenVPN ট্রাফিক কাউন্টার বনাম ডিস্ক I/O: তিনটি ভিন্ন সংখ্যা
ইন্টারফেস বাইট, প্রসেসের অক্ষর কাউন্টার আর স্টোরেজ লেখা আলাদা কাজ মাপে। টানেলের আয়তন থেকে ডিস্কের আকার নির্ধারণের আগে এগুলো তুলনা করুন।
একটি বড় ফাইল টানেলের ভেতর দিয়ে পাঠান, ইন্টারফেস কাউন্টার ফাইলের আকারের সমান বেড়ে যাবে। সেই সংখ্যায় এমন কিছু নেই যা বলে একই পরিমাণ ডিস্কে পৌঁছেছে। এই আলোচনায় তিনটি ভিন্ন পরিমাপ তুলনা করা হয়, আর তারা তিনটি ভিন্ন প্রশ্নের উত্তর দেয়: কত ট্রাফিক একটি নেটওয়ার্ক স্তর অতিক্রম করেছে, একটি প্রসেস সিস্টেম কলের মাধ্যমে কত বাইট পড়েছে ও লিখেছে, এবং কত কাজ স্টোরেজ স্তরে পৌঁছেছে।
প্রথমটিকে তৃতীয়টির সাথে তুলনা করাই সাধারণ ভুল, আর তা হয় একটি ভুতুড়ে ডিস্ক সমস্যা তৈরি করে, নয়তো এমন ধারণক্ষমতার পরিকল্পনা দেয় যা সত্যি ঘটে যাওয়া লেখাগুলো উপেক্ষা করে। তিনটিই আলাদা করা যায়, এবং প্রত্যেকটির সঠিক ব্যবহার আছে।
তিনটি সংখ্যা যা মিশিয়ে ফেলা হয়
ইন্টারফেস কাউন্টার নেটওয়ার্ক স্তরে হ্যান্ডল করা ট্রাফিক বর্ণনা করে। ব্যান্ডউইথ, টানেলের আকার এবং ট্রানজিটের দাম নির্ধারণ করা বিলিং মডেলের জন্য এটাই সঠিক সংখ্যা।
প্রসেসের অক্ষর কাউন্টার পাইপ, টার্মিনাল ও ক্যারেক্টার ডিভাইসসহ যেকোনো ডেসক্রিপ্টরে পড়া ও লেখার কলে সরে যাওয়া বাইট বর্ণনা করে। প্রসেস সিস্টেম কলের সীমানায় কতটা ব্যস্ত তা জানতে এটাই সঠিক সংখ্যা, আর এটা কোনো স্টোরেজ বিল নয়।
স্টোরেজ কাউন্টার ব্লক ডিভাইসে বা সেখান থেকে কার্নেল যে বাইট সরানোর চেষ্টা করেছে তা বর্ণনা করে। ধারণক্ষমতার পরিকল্পনার জন্য এটাই সঠিক সংখ্যা, তবে শর্ত থাকে যে কার্নেল তার নিজের হিসাবের সীমা নথিভুক্ত করে: ক্যাশে করা পড়া স্টোরেজ পড়ায় পরিণত হয় না, আর যে লেখা পরে বাতিল হয় তা সম্পূর্ণ ডিভাইস লেখায় পরিণত হয় না।
| Measurement | Question it answers |
|---|---|
| Interface bytes | How much traffic crossed this layer |
rchar and wchar | How much data the process moved through system calls |
read_bytes and write_bytes | How much work reached the storage layer |
কেন একটি ফাইল ডেসক্রিপ্টর ডিস্ক লেখা নয়
ইউজারস্পেসে চলা VPN একটি TUN ডিভাইসের মাধ্যমে কার্নেলের সাথে প্যাকেট বিনিময় করে, যা নিয়মিত ফাইল নয় বরং ক্যারেক্টার ডিভাইস। সেখান থেকে পড়া একটি প্যাকেট হস্তান্তর করে; সেখানে লেখা একটি প্যাকেট ঢোকায়। স্টোরেজের জন্য প্রস্তুত করা ফাইল কনটেন্টের কোনো পাতা নেই, আর কোনো ফাইলসিস্টেম পাথও জড়িত নয়।
এই কারণেই ব্যস্ত একটি টানেল প্রায় কোনো স্টোরেজ কাউন্টার ছাড়াই বিশাল অক্ষর কাউন্টার দেখাতে পারে। প্রসেস সত্যিই সেই বাইট সরিয়েছে, আর কার্নেলের সত্যিই তা করার জন্য ডিস্কের প্রয়োজন হয়নি।
cat /proc/$(pgrep -n openvpn)/io
ip -s link show tun0প্রথম আউটপুটটি প্রসেস শুরু হওয়ার পর থেকে সঞ্চিত হিসেবে পড়ুন, হার হিসেবে নয়। দ্বিতীয়টি একই ট্রাফিকের ইন্টারফেস দৃশ্য দেয়। দুটির মধ্যে বড় ব্যবধান প্রত্যাশিত এবং তা লিক, সারি বা ভুল কনফিগারেশন বোঝায় না।
বাইটগুলো আসলে কোথা থেকে আসে
স্থায়ী আউটপুটের নিজস্ব বাজেট আছে, আর তা চালিত হয় অপারেশন দিয়ে, পেলোড দিয়ে নয়। ভার্বোজ লগ স্তর, ঘন ঘন বদলানো ক্লায়েন্ট তালিকা, বা আঁটসাঁট লুপে বারবার ঘটা একটি ত্রুটি টানেল খুব কম বহন করলেও যথেষ্ট লেখা তৈরি করতে পারে।
স্ট্যাটাস ফাইল হলো একটি ব্যবধানে পুনর্লিখিত স্ন্যাপশট, তাই এর খরচ নির্ভর করে ব্যবধান এবং এতে কত রেকর্ড আছে তার ওপর। এটি প্রতিটি ক্লায়েন্টের ট্রাফিকের চলমান কপি নয়, আর ব্যবধান ছোট করলে ট্রাফিকের পরিমাণ না বদলিয়েই লেখার পরিমাণ বদলায়।
সেই লেখাগুলো খুঁজতে গেলে মালিকানা গুরুত্বপূর্ণ। যদি সার্ভিস বার্তাগুলো একটি লগিং ডেমনে দেয়, তবে জার্নাল বা লগ ফাইল সেই ডেমনই লেখে, আর বাইটগুলো VPN প্রসেসের নিজের কাউন্টারে নয়, ডেমনের হিসাবে দেখা যায়। শুধু VPN প্রসেসের দিকে তাকালে ডিস্কের কার্যকলাপ বা তার অনুপস্থিতি কোনোটাই ব্যাখ্যা হয় না।
অন্য অবদানকারীদের চোখ এড়িয়ে যাওয়া সহজ: শুরুর সময় সার্টিফিকেট ও কনফিগারেশন পড়া, নিজের রেকর্ড লেখা হুক, অ্যাকাউন্টিং প্লাগইন, ক্র্যাশ ডাম্প এবং একই হোস্টে অসম্পর্কিত কাজের চাপ। টানেল ট্রাফিককে লেখা বাইটের সমান ধরে এদের কোনোটিকেই অনুমান করা উচিত নয়।
প্রতিটি কাউন্টার সঠিকভাবে পড়া
তিনটি বিবরণ ঠিক করে তুলনাটি অর্থবহ কি না। প্রসেসের পরিচয় গুরুত্বপূর্ণ, কারণ পুনরায় চালু হওয়া সার্ভিস তার কাউন্টার রিসেট করে। সময়ের ব্যবধান গুরুত্বপূর্ণ, কারণ সঞ্চিত সংখ্যা আর প্রতি সেকেন্ডের চার্ট আলাদা পরিমাপ। আর একক গুরুত্বপূর্ণ, কারণ লগ ফাইলের বর্তমান আকারও কোনো হার নয়।
grep -E 'rchar|wchar|read_bytes|write_bytes' /proc/$(pgrep -n openvpn)/io
du -sh /var/log/openvpn 2>/dev/null
journalctl --disk-usageসত্যিকারের পেলোড লেখার সন্দেহ হলে এমন উপাদান খুঁজুন যার কাজ পেলোড সংরক্ষণ করা: প্যাকেট ক্যাপচার টুল, বডি ক্যাশে করা প্রক্সি, আর্কাইভ করা প্লাগইন। এগুলো স্টোরেজ ট্রাফিক তৈরি করে যা তাদের যতটুকু রেকর্ড করতে বলা হয় তার সাথে বাড়ে, আর এগুলো ধারণ ও প্রবেশাধিকার নিয়ে আলাদা নীতিগত সিদ্ধান্তের অংশ।
সঠিক সংখ্যা দিয়ে ধারণক্ষমতা পরিকল্পনা
প্যাকেট পথের আকার নির্ধারণ করুন নেটওয়ার্কের সংখ্যা দিয়ে: থ্রুপুট, ক্রিপ্টোগ্রাফিক প্রসেসিং ও মেমোরি চলাচল। স্টোরেজের আকার নির্ধারণ করুন আপনি সত্যিই যে অবজারভেবিলিটি সিদ্ধান্ত নিয়েছেন তা দিয়ে: লগ স্তর, ধারণকাল, স্ট্যাটাস ব্যবধান এবং ইচ্ছাকৃতভাবে চালু করা যেকোনো ক্যাপচার।
এই দুটি বাজেট আলাদা রাখলে ঘটনাগুলো পড়াও সহজ হয়। সাধারণ টানেল ট্রাফিকের সাথে ভরা ডিস্ক লগ, ক্যাপচার বা অসম্পর্কিত কিছুর দিকে ইঙ্গিত করে, আর ইন্টারফেস কাউন্টার তা কখনো ব্যাখ্যা করবে না। শান্ত লগের সাথে পরিপূর্ণ লিংক উল্টো দিকে ইঙ্গিত করে।
যে তুলনাটি করা মূল্যবান তা একই ধরনের পরিমাপের মধ্যে। সময়ের সাথে ইন্টারফেস বাইট বনাম ইন্টারফেস বাইট আপনাকে পথ সম্পর্কে বলে। স্টোরেজ লেখা বনাম স্টোরেজ ধারণক্ষমতা আপনাকে ধারণকাল সম্পর্কে বলে। আড়াআড়ি তুলনা, ট্রাফিক বনাম ডিস্ক, শুধু অর্থবহ দেখায় আর কখনোই তা হয় না।