VPN ফাইল শেয়ারের জন্য BranchCache: কখন কাজে লাগে, কখন লাগে না

দলের কেউ বলছেন VPN-এর ওপর ফাইল শেয়ার ধীর, আর প্রথম পরামর্শ সবসময় ক্যাশ। রিমোট-অ্যাক্সেস ডিজাইনে BranchCache যোগ করার আগে অভিযোগটিকে তিনটি রূপের একটিতে আলাদা করুন: অপরিবর্তিত কন্টেন্টের বারবার ডাউনলোড, আপলোড, অথবা হাজার হাজার এন্ট্রি আছে এমন ফোল্ডার দিয়ে মেটাডেটা-ভারী ব্রাউজিং। BranchCache সমর্থিত কন্টেন্টে প্রথম রূপটির সমাধান করে এবং বাকি দুটির জন্য কার্যকর কিছুই করে না। এটি এড়িয়ে যাওয়ার মতো সীমাবদ্ধতা নয়; এক সপ্তাহ ডিপ্লয়মেন্টে ব্যয় করার আগে এটাই সেই তুলনা যা আপনাকে করতে হবে।

একই শেয়ার, তিনটি আলাদা অভিযোগ

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

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

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

বিতরণকৃত ক্যাশ: VPN পুল কোনো ব্র্যাঞ্চ LAN নয়

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

ক্লায়েন্ট-থেকে-ক্লায়েন্ট ট্রাফিক অনুমোদন করে পুলটিকে ব্র্যাঞ্চ LAN-এর মতো আচরণ করানো যায়, কিন্তু সেটি নিরাপত্তার সিদ্ধান্ত, ক্যাশিংয়ের নয়। অধিকাংশ রিমোট-অ্যাক্সেস ডিজাইন ক্লায়েন্টদের একে অপর থেকে বিচ্ছিন্ন রাখে ঠিক যাতে একটি আপসকৃত ল্যাপটপ অন্য একটিতে পৌঁছাতে না পারে, এবং যদি পিয়াররা ইতিমধ্যে বিশ্বস্ত সমকক্ষ না হয় তবে সেই বিচ্ছিন্নতা ক্যাশ হিটের বিনিময়ে বদলানো খারাপ লেনদেন।

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

হোস্টেড ক্যাশ: প্লেসমেন্টই ঠিক করে এটি কাজে লাগবে কি না

হোস্টেড ক্যাশ শেয়ার করা ক্যাশ একটি সার্ভারে রাখে, যা সাবনেটের মধ্যে অর্থবহ একমাত্র মোড এবং ক্লায়েন্টরা একে অপরের সাথে কথা বলতে না পারলে কাজ করে একমাত্র এটিই। তাৎক্ষণিক প্রশ্ন হলো সেই সার্ভারটি কোথায় বসবে। উৎসের মতো একই সীমিত লিংক পার হয়ে পৌঁছানো হোস্টেড ক্যাশ বাইট সরিয়েছে, সমস্যা নয়।

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

ডিপ্লয়মেন্ট হলো একসাথে পরিকল্পিত তিনটি ভূমিকা, একটি চেকবক্স নয়। উৎস সার্ভার কন্টেন্টের জন্য হ্যাশ প্রকাশ করে, হোস্টেড ক্যাশ সক্রিয় ও আবিষ্কারযোগ্য থাকে, আর ক্লায়েন্টরা এটি ব্যবহার করতে কনফিগার করা থাকে। সার্ভার দিকে এটি PowerShell-এ চেনা যায়:

Enable-BCHostedServer -RegisterSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode, HostedCacheServerList

ক্লায়েন্টে হয় এটিকে নামযুক্ত সার্ভারের দিকে নির্দেশ করুন, নয়তো সার্ভিস কানেকশন পয়েন্টের মাধ্যমে সেগুলো আবিষ্কার করতে দিন; তারপর পলিসি প্রয়োগ হয়েছে ধরে নেওয়ার বদলে সে আসলে কোন মোড বেছে নিয়েছে তা নিশ্চিত করুন:

Enable-BCHostedClient -ServerNames cache1.corp.example -UseSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode

উৎস পর্যন্ত এখনো কী পৌঁছায়

ক্যাশিং অনুমোদন দূর করে না। ফাইল পড়ার অনুমতি নেই এমন ক্লায়েন্ট অন্য কেউ ক্যাশ করেছে বলে প্রবেশাধিকার পায় না, আর উৎস এখনো অনুমোদনের প্রশ্নের উত্তর দেয় এবং ক্যাশ লুকআপ সম্ভব করে এমন কন্টেন্ট তথ্য দেয়। উৎসে পৌঁছানো না গেলে কেবল ক্যাশ করা কপি নিজে থেকে অফলাইন শেয়ার হয়ে যায় না।

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

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

দুটি রিট্রিভাল ও একটি আপলোড দিয়ে এটি মেনে নিন

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

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

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