অফিসের VPN-এর জন্য Raspberry Pi কি যথেষ্ট? কাজটি নির্ধারণ করুন

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

প্রশ্নটিকে গ্রহণযোগ্যতা পরীক্ষায় বদলান

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

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

ফলাফল Raspberry Pi-কে, অন্য কোনো যন্ত্রকে বা পরিচালিত সেবাকে ন্যায্যতা দিতে পারে। তিনটিই একই প্রশ্নের বৈধ উত্তর। পরীক্ষাই এদের মধ্যে সিদ্ধান্ত নেয়, স্পেসিফিকেশন শিট নয়।

কাজ লিখুন, লোকসংখ্যা নয়

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

দিকটিও লিখে রাখুন। দূরবর্তী ব্যবহারকারীরা অফিসের ফাইল সার্ভার থেকে ডাউনলোড করলে অফিসের আপলিংক ব্যবহার হয়, আর দ্রুত ক্লায়েন্ট সংযোগ দূর প্রান্তের সীমিত পথের ঘাটতি পূরণ করতে পারে না।

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

জোড়া দেওয়া যন্ত্রটি মাপুন

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

বোর্ডটি যে সেবাগুলো ভাগ করবে সেগুলো অন্তর্ভুক্ত করুন। DNS ফিল্টারিং, মনিটরিং বা স্টোরেজ সবই একই প্রসেসর ও মেমরির জন্য প্রতিযোগিতা করে, আর একা মাপা গেটওয়ে সেই গেটওয়ে নয় যা আপনি চালাবেন।

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

হার্ডওয়্যারের আগে বিভ্রাটের বাজেট ঠিক করুন

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

প্রশাসক যদি একই টানেল দিয়েই গেটওয়েতে পৌঁছান, তবে একটি স্বাধীন পুনরুদ্ধার পথের পরিকল্পনা করুন। যে অতিরিক্ত বোর্ডের কনফিগারেশন ও চাবি পুনরুদ্ধার করা যায় না এবং যার মালিক কেউ নেই, তা পুনরুদ্ধার পরিকল্পনা নয়।

দলের বদলে ব্যক্তির নাম বলুন। যে পুনরুদ্ধার দলের উপর নির্ভর করে, তা সেই পুনরুদ্ধার যা দল উপলব্ধ হওয়ার জন্য অপেক্ষা করে। নামই পরিকল্পনাটিকে পরীক্ষাযোগ্য করে।

যে ক্ষুদ্রতম সিস্টেম উত্তীর্ণ হয় তা বাছুন

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

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