BranchCache لمشاركات الملفات عبر VPN: متى يفيد ومتى لا يفيد

يقول أحد أعضاء الفريق إن مشاركة الملفات عبر VPN بطيئة، والاقتراح الأول دائمًا ذاكرة تخزين مؤقت. قبل إضافة BranchCache إلى تصميم الوصول عن بُعد، قسّم الشكوى إلى واحد من ثلاثة أشكال: تنزيلات متكررة لمحتوى غير متغيّر، أو عمليات رفع، أو تصفّح كثيف للبيانات الوصفية عبر مجلدات تضم آلاف المدخلات. يعالج BranchCache الشكل الأول على المحتوى المدعوم ولا يفعل شيئًا مفيدًا للشكلين الآخرين. هذا ليس قيدًا يجب الالتفاف حوله؛ بل هو المقارنة التي ينبغي إجراؤها قبل إنفاق أسبوع على النشر.

المشاركة نفسها، ثلاث شكاوى مختلفة

مكتب فرعي يفتح فيه ثمانية أشخاص الفيديو التدريبي نفسه غير المتغيّر هو الحالة التي صُمّمت الميزة من أجلها. أول استرجاع يعبر WAN، ويُخزَّن المحتوى قرب القرّاء، ثم تُخدم الاسترجاعات اللاحقة للملف نفسه غير المتغيّر محليًا. الفائدة حقيقية وهي ضيقة: المحتوى نفسه، غير متغيّر، عدة قرّاء.

حاسوب محمول يرفع تسجيلًا جديدًا عبر اتصال منزلي هو الحالة المعاكسة. لا توجد نسخة مخزّنة مسبقًا لملف لم يوجد بعد، لذا يتبع الرفع المسار المقيّد نفسه الذي اتبعه دائمًا. ذاكرة التنزيل المؤقتة لا تلغي الرفع، ولا يغيّر أي اختيار للموضع ذلك.

الشكل الثالث هو الذي يخيّب الآمال لأنه يبدو مشكلة تنزيل. فتح مجلد يضم عشرات الآلاف من الملفات وفرزه وقراءة البيانات الوصفية هو سيل من العمليات الصغيرة، لا نقل متكرر لجسم واحد كبير. تخزين أجسام الملفات مؤقتًا لا يفعل شيئًا للتعداد.

ذاكرة التخزين المؤقت الموزّعة: مجموعة VPN ليست شبكة LAN فرعية

في الوضع الموزّع، تتبادل أجهزة العميل المحتوى المخزّن مؤقتًا فيما بينها، وتوثّق Microsoft هذا الوضع على أنه يعمل داخل شبكة فرعية واحدة. مجموعة عملاء VPN ليست شبكة فرعية بهذا المعنى حتى عندما تبدو جميع العناوين متجاورة: اكتشاف الأقران، وإمكانية الوصول بين العملاء، والإذن بتبادل بيانات التخزين المؤقت أسئلة منفصلة، والتصميم المعتاد للوصول عن بُعد يجيب عن الثلاثة بـ«لا».

يمكنك جعل المجموعة تتصرف مثل شبكة LAN فرعية بالسماح بحركة المرور بين العملاء، لكن ذلك قرار أمني لا قرار تخزين مؤقت. معظم تصاميم الوصول عن بُعد تعزل العملاء عن بعضهم تحديدًا كي لا يصل حاسوب مخترق إلى آخر، ومقايضة هذا العزل بإصابة في ذاكرة التخزين المؤقت مقايضة سيئة ما لم يكن الأقران متساوين موثوقين بالفعل.

بالنسبة لمستخدم متجوّل واحد، لا يوجد في الوضع الموزّع من يشاركه. يمكن لذاكرة التخزين المؤقت أن تخدم قراءات ذلك العميل المتكررة، لكن هذه فائدة تخزين مؤقت على جانب العميل، لا فائدة موضع فرعي، ويجدر قول ذلك قبل أن يتوقع أحد أن يصبح المكتب أسرع.

ذاكرة التخزين المؤقت المستضافة: الموضع يحدد ما إذا كانت تفيد

تضع ذاكرة التخزين المؤقت المستضافة الذاكرة المشتركة على خادم، وهو الوضع الوحيد المنطقي عبر الشبكات الفرعية والوحيد الذي يعمل عندما لا يستطيع العملاء التحدث إلى بعضهم. السؤال المباشر هو أين يقف ذلك الخادم. ذاكرة مستضافة يُوصل إليها عبر الرابط المقيّد نفسه الذي يصل إلى الأصل تكون قد نقلت البايتات، لا المشكلة.

ضعها قرب القرّاء، وأعطها مالكًا، وحدّد حجم قرصها لمجموعة العمل بدلًا من المشاركة بأكملها. إن نظرة عامة على BranchCache الخاصة بـ Microsoft تصف الوضعين وسلوك العميل، بما في ذلك الجزء الذي ينساه الناس: لا يزال العملاء يتصلون بالأصل للتفويض ومعلومات المحتوى قبل استخدام البيانات المخزّنة مؤقتًا.

النشر ثلاث أدوار تُخطَّط معًا، لا مربع اختيار واحد. ينشر خادم الأصل تجزئات المحتوى، وتُفعَّل ذاكرة التخزين المؤقت المستضافة وتكون قابلة للاكتشاف، ويُهيَّأ العملاء لاستخدامها. على جانب الخادم يُعرف ذلك في PowerShell:

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

على العميل، إما أن توجّهه إلى خوادم مسمّاة أو تدعه يكتشفها عبر نقطة اتصال الخدمة؛ ثم أكّد الوضع الذي اختاره فعليًا بدلًا من افتراض أن النهج طُبِّق:

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

ما يصل إلى الأصل مع ذلك

التخزين المؤقت لا يزيل التفويض. العميل الذي لا يملك إذن قراءة ملف لا يحصل على وصول لأن غيره خزّنه مؤقتًا، ولا يزال الأصل يجيب عن سؤال التفويض ويوفّر معلومات المحتوى التي تجعل البحث في الذاكرة ممكنًا. إذا تعذّر الوصول إلى الأصل، لا تصبح النسخة المخزّنة وحدها مشاركة غير متصلة.

تغييرات المحتوى تكسر الافتراض أيضًا بهدوء. الملف الذي يُحفظ من جديد أو يُعاد ترميزه أو يمسّه منتج نسخ احتياطي قد لا يطابق التجزئة المخزّنة بعد الآن، فتذهب القراءة التالية إلى الأصل. هذا سلوك صحيح، ولهذا فإن ذاكرة تخزين مؤقت تتغيّر مجموعة عملها كل ساعة تقدّم القليل.

الإخلاء هو الحد الثالث. الذاكرة محدودة، فمجموعة العمل الكبيرة تدفع المحتوى الأقدم إلى الخارج، وتعتمد الفائدة على حدوث إعادات القراءة قبل الإخلاء لا بعده. تحديد حجم الذاكرة للمشاركة بأكملها هو الطريق المعتاد لخيبة الأمل من نشر كان صحيحًا تقنيًا.

اقبله باسترجاعين ورفع واحد

اختبر التدفقات الثلاث الصحيحة واكتب ما يُظهره كل منها. الاسترجاع الأول لملف ممثّل من عميل، مقيسًا عند رابط الأصل وكذلك عند ساعة المستخدم. الاسترجاع الثاني للملف نفسه غير المتغيّر من عميل ثانٍ في مجموعة الموضع نفسها. رفع واحد لملف جديد، وينبغي ألا يُظهر أي تحسّن ويؤكد أن الذاكرة لا تُنسب إليها فضيلة شيء لم تفعله قط.

إذا كان الاسترجاع الثاني لا يزال يعبر رابط الأصل لمعظم البايتات، فالذاكرة لا تُستخدم، والسبب عادة عميل في الوضع الخطأ، أو تجزئة غير منشورة على الأصل، أو ذاكرة مستضافة على الجانب الخطأ من الرابط المقيّد. تلك ثلاثة إصلاحات مختلفة، وواحد منها فقط يتعلق بموضع الشبكة.

ثم صُغ الاستنتاج بالشكل نفسه الذي جاءت به الشكوى الأصلية: التنزيلات المتكررة للمحتوى غير المتغيّر من هذا الأصل إلى هؤلاء القرّاء تُخدم بهذه الذاكرة. كل ما عدا ذلك في المشاركة لم يُمسّ، بما في ذلك عمليات الرفع وتعداد المجلدات وقصة العمل دون اتصال، التي لا تزال تحتاج إجابة خاصة بها.