למה העתקה ב-SMB מאטה כששני המחשבים מתחברים לאותו VPN

SMB3 Multichannel יכול להוסיף ערוץ מנהר להעתקה ברשת LAN ולגרור אותה למסלול האיטי יותר. אשרו את הערוץ, ואז בטלו את הכריכה או השביתו אותו ובדקו שוב.

העתקת קובץ בין שני מחשבי Windows ברשת LAN של גיגה-ביט יורדת לזחילה ברגע ששניהם מתחברים לאותו VPN, בעוד שבדיקת תפוקה בין אותו זוג עדיין מדווחת על כמעט מהירות הקו. הבעיה אינה בקישור וגם לא בדיסק. SMB3 Multichannel הוסיף בשקט חיבור TCP שני שעובר דרך המנהרה, וההעתקה ממתינה לערוץ האיטי ביותר. הסרת המסלול הזה מ-SMB מחזירה את מהירות ה-LAN.

שיתוף אחד יכול לנסוע על כמה חיבורי TCP

Multichannel מאפשר ללקוח לפתוח חיבורים בלתי תלויים לשרת אחד, אחד לכל זוג כתובות מתאים. ברשת LAN רגילה ייתכן שיש רק זוג אחד, כך ששום דבר מפתיע לא קורה. הוסיפו מתאם VPN בשני המחשבים ו-Windows רואה זוג שני, כתובת מנהרה מול כתובת מנהרה, ופותח ערוץ דרכו.

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

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

הוכיחו שערוץ המנהרה קיים לפני שמשנים משהו

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

Get-SmbMultichannelConnection | Where-Object Selected -eq $true | Format-Table ServerName, ClientIPAddress, ServerIPAddress
Get-SmbConnection | Format-Table ServerName, Dialect, NumOpens

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

Get-NetIPAddress -IPAddress 10.8.0.6 | Format-List IPAddress, InterfaceAlias

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

הוציאו את המנהרה מ-SMB והפעילו מחדש את שני הקצוות

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

Set-SmbClientConfiguration -EnableMultiChannel $false -Force
Set-SmbServerConfiguration -EnableMultiChannel $false -Force
Get-SmbClientConfiguration | Select-Object EnableMultiChannel

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

Get-SmbServerNetworkInterface | Format-List Name, InterfaceAlias, LinkSpeed

כאשר המטרה צרה יותר מכיבוי Multichannel בכל מקום, ביטול הכריכה של רכיב השרת ממתאם המנהרה מפסיק את השיתוף דרכו ומשאיר את שאר ה-VPN ללא פגע.

Get-NetAdapterBinding -Name "<vpn adapter>" -ComponentID ms_server
Disable-NetAdapterBinding -Name "<vpn adapter>" -ComponentID ms_server

העדיפו את ה-LAN ומדדו פעמיים באותה דרך

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

Get-NetIPInterface | Sort-Object InterfaceMetric | Select-Object InterfaceAlias, InterfaceMetric
Set-NetIPInterface -InterfaceAlias "<vpn adapter>" -AutomaticMetric Disabled -InterfaceMetric 9000

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

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

מאמרים קשורים