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 عدد وہ نتیجہ نہیں ہے۔