Azure Files মেটাডেটা ক্যাশিং বনাম স্থানীয় শাখা ক্যাশ
সেবা-পক্ষের মেটাডেটা ক্যাশ সার্ভারের কাজ কমায়। এটি আপনার WAN থেকে রাউন্ড ট্রিপ সরায় না। দুটিকে আসলে কী সংক্ষিপ্ত করে তার ভিত্তিতে তুলনা করুন।
VPN-এর মাধ্যমে ধীর Azure Files অ্যাক্সেসের জন্য দুটি পরিবর্তন প্রস্তাব করা হয়, এবং তারা ভিন্ন ভিন্ন জিনিস সংক্ষিপ্ত করে। সেবা-পক্ষের মেটাডেটা ক্যাশ যোগ্য অপারেশনগুলোকে সার্ভারের জন্য সস্তা করে। স্থানীয় শাখা ক্যাশ বাইটগুলো এবং অপারেশনগুলোকে ব্যবহারকারীর কাছাকাছি নিয়ে যায়। মূল্যতালিকা বা প্রেস রিলিজ দেখে এদের মধ্যে বেছে নেওয়া মানে হলো শেয়ারটি বেঞ্চমার্কে দ্রুত দেখায় আর সকাল নটায় অপরিবর্তিত থাকে।
দুটি ক্যাশ, দুটি ভিন্ন বিলম্ব
দুটি বিকল্পই ক্যাশ শব্দের অধীনে আসে, আর ঠিক সেখানেই বিভ্রান্তি শুরু। তারা নেটয়ার্কের বিপরীত দিকে অবস্থান করে।
| Change | Where it acts | What it does not imply |
|---|---|---|
| Azure Files service metadata caching | The service's handling of supported metadata operations on eligible shares | No removal of the client's network round trips |
| A supported local server or cache design | Some content and operations placed nearer the users | No universal offline access or instant cross-site consistency |
| Application batching or limited copy concurrency | The number and overlap of remote operations | No automatic speedup for every workload |
Microsoft-এর SMB পারফর্ম্যান্স নির্দেশিকা যোগ্য SSD শেয়ারের জন্য মেটাডেটা ক্যাশিং এবং তার সঙ্গে থাকা নিবন্ধন ধাপ বর্ণনা করে। যোগ্যতা ও ফিচারের অবস্থা প্রকৃত স্টোরেজ অ্যাকাউন্টের অধীন, তাই দুই বছর আগের প্রিভিউ ঘোষণার বদলে বর্তমান পৃষ্ঠাটি পড়ুন।
অপেক্ষাকে তিন ভাগে ভাগ করুন
প্রতিটি ধীর ডিরেক্টরি তালিকার তিনটি ব্যয় উপাদান থাকে এবং সেগুলো ভিন্ন সমাধানে সাড়া দেয়। প্রতি অনুরোধে সেবা প্রক্রিয়াকরণের সময়, VPN জুড়ে নির্ভরশীল রাউন্ড ট্রিপের সংখ্যা এবং যে পেলোড সরাতে হয়। সেবা-পক্ষের ক্যাশ প্রথমটিতে আঘাত করে। সার্ভার পক্ষে কিছুই দ্বিতীয়টিতে আঘাত করে না।
এই কারণেই একটি শেয়ার আরও ভালো সেবা মেট্রিক দেখাতে পারে, অথচ ব্যবহারকারীর ফাইল পিকার এখনও আট সেকেন্ড ঝুলে থাকে।
কোথায় প্রতিটি বিকল্প তার জায়গা পায়
যদি কাজের চাপ মেটাডেটা-ভারী হয়, যোগ্য SSD শেয়ারের বিরুদ্ধে প্রচুর ওপেন, stat কল এবং ডিরেক্টরি গণনা থাকে, তবে সেবা-পক্ষের ক্যাশিং হলো সস্তা পরীক্ষা। এতে নতুন অবকাঠামো লাগে না এবং ব্যবহারকারীরা কীভাবে শেয়ারে পৌঁছায় তাতে কোনো পরিবর্তন লাগে না।
যদি কাজের চাপ ইন্টারঅ্যাকটিভ এবং বিলম্ব-সীমাবদ্ধ হয়, তবে নথিভুক্ত সিঙ্ক্রোনাইজেশন মডেলসহ একটি সমর্থিত স্থানীয় সার্ভার ডিজাইনই সত্ বিকল্প। এটি নিজস্ব পরিচালন ব্যয়সহ ভিন্ন একটি আর্কিটেকচার, কোনো সুইচ নয়।
কোনো বিকল্পই যা বদলায় না
SMB সাইনিং ও এনক্রিপশন এখনও প্রযোজ্য, এবং সেগুলো এখনও যত খরচ তার খরচই করে। অ্যাক্সেস নিয়ন্ত্রণ এখনও প্রতি ব্যবহারকারীর ভিত্তিতে নির্ধারিত হয়, তাই ক্যাশ করা কপি অনুমোদনকে সরল করে না। সাইটগুলোর মধ্যে সামঞ্জস্যের জন্য এখনও একটি নির্দিষ্ট মডেল দরকার, কারণ শাখা-স্থানীয় পাঠ এবং ক্লাউড-পক্ষের লেখাকে কোনো এক বিষয়ে একমত হতে হয়। আর অফলাইন অ্যাক্সেস ক্লায়েন্ট সেটিংই থাকে, সার্ভার ফিচারের পার্শ্বপ্রতিক্রিয়া নয়।
কেউ যখন প্রতিশ্রুতি দেয় যে একটি সেবা ফিচার WAN রাউন্ড ট্রিপ সরিয়ে দয়, তখন প্রথমে পরীক্ষা করার দাবি সেটিই।
ব্যবহারকারীরা যে অপারেশনের অভিযোগ করেন তার বিপরীতে মাপুন
কৃত্রিম কপির বদলে সঠিক অপারেশনটি সময় মাপুন। শাখা ক্লায়েন্টে Measure-Command { Get-ChildItem \\files\projects -Recurse } একটি সংখ্যা দেয় যা আপনি আগে ও পরে তুলনা করতে পারেন, এবং Get-SmbMultichannelConnection দেখায় ক্লায়েন্ট একাধিক পথ ব্যবহার করছে কিনা। একই সময়সীমার জন্য সেবা-পক্ষের বিলম্ব মেট্রিকের পাশে এটি রাখুন।
শেয়ার, ক্লায়েন্টের অবস্থান, VPN পথ এবং নিরাপত্তা নীতি স্থির রাখুন, নইলে আপনি ফিচারের বদলে আপনার পরিবর্তন-সময় মাপছেন। ফাইলের সংখ্যা ও আকারের বণ্টনও লিপিবদ্ধ করুন, কারণ ছোট ফাইলের কাজের চাপ ও বাল্ক কপি সম্পূর্ণ ভিন্ন লিভারে সাড়া দেয়।
যে ফলাফলটি রাখার যোগ্য তা হলো আসলে যে সীমানা ধীর ছিল তার সঙ্গে মিলানো একটি পরিবর্তন, যার পরিচালন ও সামঞ্জস্য ব্যয় লিখিত। স্লাইডে বড় স্টোরেজ IOPS সংখ্যা সেই ফলাফল নয়।