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

מה עדיין מגיע למקור

שמירה במטמון אינה מסירה הרשאה. לקוח בלי הרשאה לקרוא קובץ אינו מקבל גישה מפני שמישהו אחר שמר אותו במטמון, והמקור עדיין עונה על שאלת ההרשאה ומספק את מידע התוכן שמאפשר את החיפוש במטמון. אם המקור אינו זמין, העותק שבמטמון לבדו אינו הופך לשיתוף לא מקוון.

שינויים בתוכן שוברים את ההנחה בשקט. קובץ שנשמר מחדש, קודד מחדש או שנגע בו מוצר גיבוי עשוי כבר לא להתאים לגיבוב שבמטמון, והקריאה הבאה חוזרת למקור. זו התנהגות נכונה, ולכן מטמון שמערך העבודה שלו משתנה כל שעה מספק מעט.

פינוי הוא הגבול השלישי. המטמון סופי, ולכן מערך עבודה גדול דוחף תוכן ישן החוצה, והתועלת תלויה בקריאות חוזרות שמתרחשות לפני הפינוי ולא אחריו. מדידת המטמון לכל השיתוף היא הדרך הרגילה להתאכזב מפריסה שהייתה נכונה מבחינה טכנית.

קבלו את זה בשני אחזורים והעלאה אחת

בדקו את שלושת הזרמים הנכונים ורשמו מה כל אחד מראה. אחזור ראשון של קובץ מייצג מלקוח, נמדד בקישור המקור וגם בשעון המשתמש. אחזור שני של אותו קובץ שלא השתנה מלקוח שני באותה קבוצת מיקום. העלאה אחת של קובץ חדש, שלא אמורה להראות שיפור ומאשרת שאין זיכוי למטמון על משהו שהוא מעולם לא עשה.

אם האחזור השני עדיין חוצה את קישור המקור עבור רוב הבתים, המטמון אינו בשימוש, והסיבה היא בדרך כלל לקוח במצב שגוי, פרסום גיבוב חסר במקור, או מטמון מתארח בצד הלא נכון של הקישור המוגבל. אלו שלושה תיקונים שונים, ורק אחד מהם עוסק במיקום ברשת.

ואז נסחו את המסקנה באותה צורה כמו התלונה המקורית: הורדות חוזרות של תוכן שלא השתנה מהמקור הזה לקוראים האלה מוגשות על ידי המטמון הזה. כל השאר בשיתוף נשאר ללא שינוי, כולל העלאות, ספירת תיקיות וסיפור הלא-מקוון, שעדיין צריך תשובה משלו.