ذاكرة 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 من Microsoft التخزين المؤقت للبيانات الوصفية للمشاركات SSD المؤهلة، إلى جانب خطوة التسجيل المرافقة له. تعود أهلية الميزة وحالتها إلى حساب التخزين الفعلي، لذا اقرأ الصفحة الحالية بدلاً من إعلان معاينة صدر قبل عامين.
قسّم الانتظار إلى ثلاثة أجزاء
لكل عرض دليل بطيء ثلاثة مكوّنات للتكلفة، وهي تستجيب لإصلاحات مختلفة. هناك زمن معالجة الخدمة لكل طلب، وعدد رحلات الذهاب والإياب التابعة عبر VPN، والحمولة التي يجب نقلها. تهاجم ذاكرة من جهة الخدمة المكوّن الأول. ولا شيء على جانب الخادم يهاجم الثاني.
لهذا السبب قد تُظهر مشاركة مقاييس خدمة أفضل بينما يظل منتقي الملفات لدى المستخدم معلقاً لثماني ثوانٍ.
أين يستحق كل خيار مكانه
إذا كان عبء العمل كثيف البيانات الوصفية، مع كثرة عمليات الفتح واستدعاءات stat وتعداد الأدلة على مشاركة SSD مؤهلة، فإن التخزين المؤقت من جهة الخدمة هو التجربة الرخيصة. لا يحتاج إلى بنية تحتية جديدة ولا إلى تغيير طريقة وصول المستخدمين إلى المشاركة.
إذا كان عبء العمل تفاعلياً ومقيداً بزمن الوصول، فإن تصميم خادم محلي مدعوم مع نموذج مزامنة موثّق هو الخيار الصادق. هذه بنية مختلفة لها تكاليف تشغيل خاصة بها، وليست مفتاحاً.
ما لا يغيّره أي من الخيارين
لا يزال توقيع SMB وتشفيره ساريين، ولا يزالان يكلّفان ما يكلّفانه. ولا يزال التحكم في الوصول يُحسم لكل مستخدم، لذا لا تبسّط النسخة المخزنة مؤقتاً التفويض. ولا يزال الاتساق بين المواقع يحتاج إلى نموذج محدد، لأن القراءات المحلية في الفرع والكتابات من جانب السحابة يجب أن تتفقا على شيء. ويبقى الوصول دون اتصال إعداداً على العميل، لا أثراً جانبياً لميزة خادم.
عندما يعِد أحدهم بأن ميزة خدمة تُزيل رحلات WAN، فهذا هو الادعاء الذي يجب اختباره أولاً.
قِس مقابل العملية التي يشكو منها المستخدمون
قِس العملية الدقيقة بدلاً من نسخة اصطناعية. Measure-Command { Get-ChildItem \\files\projects -Recurse } على عميل فرع يعطي رقماً يمكنك مقارنته قبل وبعد، ويُظهر Get-SmbMultichannelConnection ما إذا كان العميل يستخدم أكثر من مسار. ضع ذلك بجانب مقاييس زمن الوصول من جهة الخدمة للنافذة الزمنية نفسها.
أبقِ المشاركة وموقع العميل ومسار VPN وسياسة الأمان ثابتة، وإلا فأنت تقيس نافذة التغيير لديك بدلاً من الميزة. سجّل أيضاً عدد الملفات وتوزيع أحجامها، لأن أعباء الملفات الصغيرة والنسخ الضخمة تستجيب لروافع مختلفة تماماً.
النتيجة التي تستحق العناء هي تغيير مطابق للحد الذي كان بطيئاً فعلاً، مع تدوين تكاليف تشغيله واتساقه. ورقم IOPS تخزين أكبر على شريحة عرض ليس تلك النتيجة.