למה שיתוף קבצים דרך VPN מרגיש איטי: הליכות הלוך ושוב, לא Mbps

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

עותק העבודה המרוחק הוא בצורה הלא נכונה

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

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

ספרו הליכות הלוך ושוב לפני מגה־בייטים

מדדו את ההשהיה לפני שאתם קונים קיבולת. פינג אחד אומר לכם מה כל החלפה משלמת.

ping -c 10 fileserver.example.net

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

העבירו את העבודה, לא את הבתים

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

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

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

תקיעות סביב אותו גודל היא תסמין MTU

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

ping -M do -s 1400 -c 3 fileserver.example.net

בדיקה מוצלחת פירושה שחבילת IP בגודל 1428 בייט עוברת את הנתיב ללא פיצול, שכן כותרות ICMP ו־IP מוסיפות 28 בייט. כשל עם דגל אי־פיצול מרמז שה־MTU השמיש של המנהרה קטן ממה שהשרת מניח. שרת ששולח מאגרים של 9000 בייט לנתיב של 1500 בייט כופה פיצול או נפילות, וגילוי MTU של הנתיב עלול להיכשל בשקט כשמסננים ICMP. הנמיכו את ה־MTU של המנהרה, הפעילו mssfix ב־OpenVPN, או הקטנו את מאגרי השרת, ואז הריצו שוב את אותה העברה כדי לאשר.

מדדו את הפער שחשוב

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

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