BranchCache برای اشتراک فایل‌ها روی VPN: کجا کمک می‌کند، کجا نه
BranchCache دانلودهای تکراری محتوای بدون تغییر را سریع می‌کند، نه بارگذاری‌ها یا فهرست‌کردن پوشه را. نخست جایگاه، دسترس‌پذیری و حالت کلاینت را بررسی کنید.
یکی از اعضای تیم می‌گوید اشتراک فایل روی 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چه چیزی هنوز به مبدأ می‌رسد
کش کردن مجوزدهی را حذف نمی‌کند. کلاینتی که اجازه خواندن فایل را ندارد به این دلیل دسترسی پیدا نمی‌کند که کس دیگری آن را کش کرده است، و مبدأ همچنان به پرسش مجوزدهی پاسخ می‌دهد و اطلاعات محتوایی را فراهم می‌کند که جست‌وجوی کش را ممکن می‌سازد. اگر مبدأ در دسترس نباشد، نسخه کش‌شده به‌تنهایی به اشتراک برون‌خط تبدیل نمی‌شود.
تغییرات محتوا هم این فرض را بی‌صدا می‌شکنند. فایلی که دوباره ذخیره، دوباره کدگذاری یا توسط محصول پشتیبان لمس شده باشد ممکن است دیگر با هش کش‌شده مطابقت نداشته باشد و خواندن بعدی به مبدأ برمی‌گردد. این رفتار درست است و به همین دلیل کشی که مجموعه کاری‌اش هر ساعت تغییر می‌کند کم سود می‌دهد.
حذف سومین محدودیت است. کش متناهی است، پس مجموعه کاری بزرگ محتوای قدیمی‌تر را بیرون می‌راند و سود به این بستگی دارد که بازخوانی‌ها پیش از حذف رخ دهند نه پس از آن. اندازه‌گیری کش برای کل اشتراک راه معمول ناامید شدن از استقراری است که از نظر فنی درست بوده است.
آن را با دو بازیابی و یک بارگذاری بپذیرید
سه جریان درست را آزمایش کنید و بنویسید هر کدام چه نشان می‌دهد. نخستین بازیابی یک فایل نمونه از یک کلاینت، اندازه‌گیری‌شده روی پیوند مبدأ و همچنین روی ساعت کاربر. دومین بازیابی همان فایل بدون تغییر از کلاینت دومی در همان گروه جایگاه. یک بارگذاری فایل تازه، که نباید بهبودی نشان دهد و تأیید می‌کند که به کش چیزی نسبت داده نمی‌شود که هرگز انجام نداده است.
اگر دومین بازیابی هنوز برای بخش عمده بایت‌ها از پیوند مبدأ عبور می‌کند، کش استفاده نمی‌شود و علت معمولاً کلاینتی در حالت اشتباه، انتشار نبود هش روی مبدأ یا کش میزبان‌شده در سمت اشتباه پیوند محدود است. این‌ها سه اصلاح متفاوت‌اند و تنها یکی از آن‌ها درباره جایگاه شبکه است.
سپس نتیجه را با همان شکل شکایت اصلی بیان کنید: دانلودهای تکراری محتوای بدون تغییر از این مبدأ به این خوانندگان را همین کش ارائه می‌کند. هر چیز دیگر درباره اشتراک دست‌نخورده است، از جمله بارگذاری‌ها، فهرست‌کردن پوشه و ماجرای برون‌خط، که هنوز پاسخ خودش را می‌خواهد.