کش فراداده Azure Files در برابر کش محلی شعبه
کش فراداده در سمت سرویس کار سرور را کم می‌کند. اما رفت‌وبرگشت‌ها را از WAN شما بیرون نمی‌برد. این دو را با آنچه واقعاً کوتاه می‌کنند مقایسه کنید.
برای دسترسی کند به Azure Files از طریق VPN دو تغییر پیشنهاد می‌شود و هر کدام چیز متفاوتی را کوتاه می‌کنند. کش فراداده در سمت سرویس، عملیات واجد شرایط را برای سرور ارزان‌تر می‌کند. کش محلی شعبه، بایت‌ها و عملیات را به کاربر نزدیک‌تر می‌کند. انتخاب بین این دو بر اساس فهرست قیمت یا بیانیه مطبوعاتی، همان راهی است که یک اشتراک در بنچمارک سریع‌تر می‌شود و ساعت نه صبح بدون تغییر می‌ماند.
دو کش، دو تأخیر متفاوت
هر دو گزینه زیر واژه کش می‌آیند و سردرگمی از همان‌جا شروع می‌شود. آن‌ها در دو سوی مقابل شبکه قرار دارند.
| 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 |
راهنمای عملکرد SMB از مایکروسافت، کش فراداده را برای اشتراک‌های SSD واجد شرایط همراه با مرحله ثبت مربوط به آن توصیف می‌کند. واجد شرایط بودن و وضعیت این قابلیت به حساب ذخیره‌سازی واقعی بستگی دارد، پس صفحه کنونی را بخوانید نه اعلان پیش‌نمایشی از دو سال پیش.
انتظار را به سه بخش تقسیم کنید
هر فهرست‌گیری کند از پوشه سه مؤلفه هزینه دارد و آن‌ها به اصلاح‌های متفاوت پاسخ می‌دهند. زمان پردازش درخواست در سمت سرویس وجود دارد، تعداد رفت‌وبرگشت‌های وابسته از طریق VPN و باری که باید جابه‌جا شود. کش سمت سرویس به اولی حمله می‌کند. هیچ چیز در سمت سرور به دومی حمله نمی‌کند.
به همین دلیل یک اشتراک می‌تواند معیارهای سرویس بهتری نشان دهد در حالی که انتخابگر فایل کاربر هنوز هشت ثانیه معطل می‌ماند.
هر گزینه کجا جای خود را به دست می‌آورد
اگر بار کاری سنگین از نظر فراداده باشد، با بازکردن‌های فراوان، فراخوانی‌های stat و فهرست‌گیری پوشه‌ها روی یک اشتراک SSD واجد شرایط، کش سمت سرویس آزمایش ارزان است. به زیرساخت جدید و به تغییر شیوه دسترسی کاربران به اشتراک نیازی ندارد.
اگر بار کاری تعاملی و محدود به تأخیر باشد، گزینه صادقانه طراحی سرور محلی پشتیبانی‌شده با مدل همگام‌سازی مستند است. این معماری متفاوتی با هزینه‌های اجرایی خودش است، نه یک کلید.
چیزی که هیچ‌یک از دو گزینه تغییر نمی‌دهد
امضا و رمزنگاری SMB همچنان اعمال می‌شوند و همچنان هزینه خودشان را دارند. کنترل دسترسی همچنان برای هر کاربر حل می‌شود، بنابراین نسخه کش‌شده مجوزدهی را ساده نمی‌کند. سازگاری بین سایت‌ها همچنان به مدلی تعریف‌شده نیاز دارد، زیرا خواندن‌های محلی شعبه و نوشتن‌های سمت ابر باید روی چیزی توافق کنند. و دسترسی آفلاین همچنان تنطیمی در سمت کلاینت می‌ماند، نه اثر جانبی یک قابلیت سرور.
وقتی کسی وعده می‌دهد که یک قابلیت سرویس رفت‌وبرگشت‌های WAN را حذف می‌کند، همان ادعایی است که باید اول آزمایش شود.
در برابر عملیاتی که کاربران از آن شکایت دارند اندازه بگیرید
عملیات دقیق را زمان بگیرید نه یک کپی مصنوعی. Measure-Command { Get-ChildItem \\files\projects -Recurse } روی یک کلاینت شعبه عددی می‌دهد که می‌توانید قبل و بعد مقایسه کنید، و Get-SmbMultichannelConnection نشان می‌دهد آیا کلاینت از بیش از یک مسیر استفاده می‌کند. آن را کنار معیارهای تأخیر سمت سرویس برای همان بازه بگذارید.
اشتراک، مکان کلاینت، مسیر VPN و سیاست امنیتی را ثابت نگه دارید، وگرنه بازه تغییر خود را اندازه می‌گیرید نه قابلیت را. تعداد فایل‌ها و توزیع اندازه‌ها را هم ثبت کنید، زیرا بارهای کاری فایل‌های کوچک و کپی‌های انبوه به اهرم‌های کاملاً متفاوت پاسخ می‌دهند.
نتیجه‌ای که ارزش داشتن دارد تغییری است هم‌راستا با مرزی که واقعاً کند بود، همراه با هزینه‌های اجرایی و سازگاری نوشته‌شده‌اش. عدد بزرگ‌تر IOPS ذخیره‌سازی روی یک اسلاید آن نتیجه نیست.