פתרון בעיות בקישוריות פנימית בין מכונות וירטואליות
במסמך הזה מפורטים השלבים לפתרון בעיות של קישוריות בין מכונות וירטואליות של Compute Engine שנמצאות באותה רשת של ענן וירטואלי פרטי (VPC) (יכול להיות VPC משותף או נפרד), או בין שתי רשתות VPC שמקושרות באמצעות קישור בין רשתות VPS שכנות (peering). נקודת המוצא היא שמכונות וירטואליות מתקשרות באמצעות כתובות ה-IP הפנימיות של בקרי הממשק של הרשת הווירטואלית (vNICs).
ההוראות במדריך הזה רלוונטיות למכונות וירטואליות של Compute Engine ולצמתים של Google Kubernetes Engine.
אם אתם רוצים לראות תרחישים ספציפיים נוספים לפתרון בעיות, אתם יכולים ללחוץ על הקישור שליחת משוב בתחתית הדף ולעדכן אותנו.
ההגדרות הבאות של מכונות וירטואליות ו-VPC רלוונטיות למדריך הזה:
- חיבורים ממכונה וירטואלית למכונה וירטואלית באמצעות כתובות IP פנימיות ברשת VPC אחת.
- חיבורים ממכונה וירטואלית למכונה וירטואלית באמצעות כתובות IP פנימיות ברשת VPC משותפת.
- חיבורים בין מכונות וירטואליות באמצעות כתובות IP פנימיות ברשתות VPC שונות שמקושרות לרשתות שכנות באמצעות קישור בין רשתות שכנות (peering) של VPC.
הפקודות שמופיעות במדריך הזה זמינות בכל תמונות מערכת ההפעלה ש-Google מספקת. אם אתם משתמשים בתמונת מערכת הפעלה משלכם, יכול להיות שתצטרכו להתקין את הכלים.
כימות הבעיה
- אם לדעתכם יש אובדן מנות מלא, כדאי לעבור אל פתרון בעיות של כשל מלא בחיבור.
- אם אתם נתקלים בזמן אחזור, באובדן חלקי של מנות או בפסק זמן שמתרחש באמצע החיבור, כדאי לעבור אל פתרון בעיות של זמן אחזור או אובדן ברשת שגורמים לבעיות ברוחב הפס.
פתרון בעיות של כשל מלא בחיבור
בקטעים הבאים מפורטים שלבים לפתרון בעיות של כשל מלא בקישוריות פנימית בין מכונות וירטואליות. אם אתם נתקלים במקום זאת בזמן אחזור מוגבר או בפסקות בחיבור, דלגו אל פתרון בעיות שקשורות לזמן אחזור או לאובדן נתונים ברשת שגורמים לבעיות ברוחב הפס.
קביעת ערכי החיבור
קודם אוספים את הפרטים הבאים:
- בדף VM instances, אוספים את הפרטים הבאים לגבי שתי המכונות הווירטואליות:
- שמות של מכונות וירטואליות
- אזורי VM
- כתובות IP פנימיות של כרטיסי ה-vNIC שמתקשרים
מתוך ההגדרה של תוכנת שרת היעד, אוספים את המידע הבא:
- פרוטוקול שכבה 4
- יציאת היעד
לדוגמה, אם היעד הוא שרת HTTPS, הפרוטוקול הוא TCP והיציאה היא בדרך כלל
443, אבל יכול להיות שההגדרה הספציפית שלכם משתמשת ביציאה אחרת.
אם אתם נתקלים בבעיות בכמה מכונות וירטואליות, בוחרים מכונת מקור אחת ומכונת יעד אחת שבהן יש בעיות ומשתמשים בערכים האלה. בדרך כלל לא צריך את יציאת המקור של החיבור.
אחרי שתאספו את המידע הזה, תוכלו להמשיך אל בדיקת בעיות ברשת Google הבסיסית.
בדיקת בעיות ברשת הבסיסית של Google
אם ההגדרה שלכם היא קיימת ולא השתנתה לאחרונה, יכול להיות שהבעיה היא ברשת הבסיסית של Google. בודקים את לוח בקרה לביצועי הענן ב-Network Intelligence Center כדי לראות אם יש אובדן מנות בין האזורים של המכונות הווירטואליות. אם יש עלייה באובדן מנות בין האזורים במהלך פרק הזמן שבו נתקלתם בפסק זמן ברשת, יכול להיות שהבעיה הייתה ברשת הפיזית שמתחת לרשת הווירטואלית שלכם. לפני ששולחים בקשת תמיכה, כדאי לבדוק את לוח הבקרה של סטטוס שירותי Google Cloud כדי לראות אם יש בעיות ידועות.
אם נראה שהבעיה לא קשורה לרשת הבסיסית של Google, צריך לעבור אל בדיקה של כללים של חומת האש שהוגדרו באופן שגוי. Google Cloud
בדיקת כללים של חומת אש שהוגדרו בצורה שגויה ב Google Cloud
הכלי 'בדיקות קישוריות' מנתח את הגדרות הנתיב של רשת ה-VPC בין שתי מכונות וירטואליות, ומראה אם ההגדרות המתוכנתות אמורות לאפשר את תעבורת הנתונים או לא. אם התעבורה לא מורשית, בתוצאות יופיע אם כלל חומת אש ליציאה או לכניסה חוסם את התעבורה, או אם נתיב לא זמין. Google Cloud
בדיקות הקישוריות יכולות גם לבדוק באופן דינמי את הנתיב על ידי שליחת מנות בין ההיפר-ויזורים של המכונות הווירטואליות. אם הבדיקות האלה מתבצעות, מוצגות התוצאות שלהן.
בדיקות הקישוריות בודקות רק את ההגדרה של רשת ה-VPC. הבדיקה לא כוללת את חומת האש של מערכת ההפעלה, את הנתיבים של מערכת ההפעלה או את תוכנת השרת במכונה הווירטואלית.
ההליך הבא מריץ בדיקות קישוריות ממסוףGoogle Cloud . במאמר הרצת בדיקות קישוריות מוסבר על דרכים נוספות להרצת בדיקות.
כדי ליצור ולהריץ בדיקה:
נכנסים לדף בדיקות קישוריות במסוף Google Cloud .
בתפריט הנפתח של הפרויקט, מוודאים שאתם בפרויקט הנכון או מציינים את הפרויקט הנכון.
לוחצים על יצירת בדיקת קישוריות.
נותנים שם לבדיקה.
צריך לציין את הפרטים הבאים:
- פרוטוקול
- כתובת ה-IP של נקודת הקצה של המקור
- פרויקט מקור ורשת VPC
- כתובת ה-IP של נקודת הקצה של היעד
- פרויקט יעד ורשת VPC
- יציאת היעד
לוחצים על יצירה.
הבדיקה תתחיל לפעול באופן מיידי. כדי לראות את דיאגרמת התוצאות, לוחצים על הצגה בעמודה פרטי התוצאות.
- אם בתוצאות מצוין שכלל חומת אש של Google Cloudגרם לניתוק החיבור, צריך לקבוע אם הגדרת האבטחה הרצויה אמורה לאפשר את החיבור. יכול להיות שתצטרכו לבקש פרטים מהאדמין של האבטחה או הרשת. אם רוצים לאפשר את התנועה, צריך לבדוק את הדברים הבאים:
- בודקים את הרשימה Always blocked traffic (תנועה שנחסמת תמיד). אם התנועה נחסמת על ידי Google Cloud כפי שמתואר ברשימת התנועה שנחסמת תמיד, ההגדרה הקיימת לא תפעל.
- עוברים לדף Firewall policies (מדיניות חומת האש) ובודקים את כללי חומת האש. אם חומת האש לא מוגדרת בצורה נכונה, צריך ליצור או לשנות כלל של חומת האש כדי לאפשר את החיבור. הכלל יכול להיות כלל חומת אש ב-VPC או כלל של מדיניות חומת אש היררכית.
- אם יש כלל חומת אש מוגדר כראוי שחוסם את התנועה הזו, צריך לבדוק עם מנהל האבטחה או מנהל הרשת. אם דרישות האבטחה של הארגון שלכם מחייבות שהמכונות הווירטואליות לא יוכלו לגשת זו לזו, יכול להיות שתצטרכו לתכנן מחדש את ההגדרה.
- אם התוצאות מצביעות על כך שאין בעיות בנתיב הקישוריות של ה-VPC, יכול להיות שהבעיה היא אחת מהבאות.
- בעיות בהגדרות של מערכת ההפעלה של האורח, כמו בעיות בתוכנת חומת האש.
- בעיות באפליקציות של הלקוח או השרת, כמו אפליקציה קפואה או אפליקציה שהוגדרה להאזין ליציאה שגויה.
בשלבים הבאים מוסבר איך לבדוק כל אחת מהאפשרויות האלה. ממשיכים אל בדיקת קישוריות TCP מתוך המכונה הווירטואלית.
בדיקת קישוריות TCP מתוך מכונת ה-VM
אם בדיקת הקישוריות בין מכונות וירטואליות לא זיהתה בעיה בהגדרת VPC, צריך להתחיל לבדוק את הקישוריות בין מערכות הפעלה. השלבים הבאים יעזרו לכם לקבוע את הדברים הבאים:
- אם שרת TCP מאזין ביציאה שצוינה
- אם תוכנת חומת האש בצד השרת מאפשרת חיבורים ליציאה הזו מהמכונה הווירטואלית של הלקוח
- אם תוכנת חומת האש בצד הלקוח מאפשרת חיבורים ליציאה הזו בשרת
- אם טבלת הניתוב בצד השרת מוגדרת בצורה נכונה להעברת מנות
- אם טבלת הניתוב בצד הלקוח מוגדרת בצורה נכונה להעברת מנות
אפשר לבדוק את לחיצת היד של TCP באמצעות curl עם Linux או Windows 2019, או באמצעות הפקודה New-Object System.Net.Sockets.TcpClient עם Windows PowerShell. תהליך העבודה שמתואר בקטע הזה אמור להסתיים באחת מהתוצאות הבאות: חיבור מוצלח, פסק זמן לחיבור או איפוס חיבור.
- הצלחה: אם לחיצת היד של TCP מסתיימת ללא בעיות, המשמעות היא שכלל חומת אש במערכת ההפעלה לא חוסם את החיבור, מערכת ההפעלה מעבירה את החבילות בצורה נכונה ויש שרת שמאזין ביציאת היעד. אם זה המצב, יכול להיות שהבעיה היא באפליקציה עצמה. כדי לבדוק, אפשר לעיין במאמר בדיקת יומני השרת כדי לקבל מידע על התנהגות השרת.
- פג הזמן הקצוב לתפוגה: אם החיבור שלכם פג, בדרך כלל זה אומר אחד מהדברים הבאים:
- אין מכונה בכתובת ה-IP הזו
- חומת אש כלשהי משליכה בשקט את המנות שלכם
- ניתוב מנות של מערכת ההפעלה שולח את המנות ליעד שלא יכול לעבד אותן, או שניתוב אסימטרי שולח את מנת ההחזרה בנתיב לא תקין
איפוס: אם החיבור מאופס, המשמעות היא שכתובת ה-IP של היעד מקבלת חבילות, אבל מערכת הפעלה או אפליקציה דוחות את החבילות. המשמעות יכולה להיות אחת מהאפשרויות הבאות:
- החבילות מגיעות למכונה הלא נכונה והיא לא מוגדרת להגיב לפרוטוקול הזה ביציאה הזו
- החבילות מגיעות למכונה הנכונה, אבל אין שרת שמקשיב ביציאה הזו
- החבילות מגיעות למכונה ולפורט הנכונים, אבל פרוטוקולים ברמה גבוהה יותר (כמו SSL) לא משלימים את לחיצת היד שלהם
- חומת אש מאפסת את החיבור. הסיכוי לכך נמוך יותר מאשר שהחומת אש תבטל את החבילות בלי להודיע, אבל זה יכול לקרות.
Linux
נכנסים לדף Firewall policies במסוף Google Cloud .
מוודאים שיש כלל חומת אש שמאפשר חיבורי SSH מ-IAP למכונה הווירטואלית, או יוצרים כלל חדש.
נכנסים לדף VM instances במסוף Google Cloud .
מאתרים את מכונת ה-VM של המקור.
לוחצים על SSH בעמודה Connect בשורה של המכונה הווירטואלית הרלוונטית.
מריצים את הפקודה הבאה בשורת הפקודה של מכונת הלקוח. מחליפים את DEST_IP:DEST_PORT בכתובת ה-IP והיציאה של היעד.
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
Windows
נכנסים לדף VM instances במסוף Google Cloud .
מאתרים את מכונת ה-VM של המקור.
משתמשים באחת מהשיטות שמתוארות במאמר התחברות למכונות VM של Windows כדי להתחבר ל-VM.
מריצים את הפקודה הבאה משורת הפקודה במכונת הלקוח:
- Windows 2019:
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
- Windows 2012 או Windows 2016 Powershell:
PS C:> New-Object System.Net.Sockets.TcpClient('DEST_IP',DEST_PORT)`
- Windows 2019:
ההתחברות הושלמה בהצלחה
התוצאות הבאות מציינות שלחיצת היד של TCP הסתיימה ללא בעיות. כשלחיצת היד של TCP מסתיימת ללא בעיות, המשמעות היא שהבעיה לא קשורה לזמן קצוב לתפוגה או לאיפוס של חיבור TCP. במקום זאת, הבעיה של פסק זמן מתרחשת בשכבות האפליקציה. אם החיבור מתבצע בהצלחה, ממשיכים אל בדיקת רישום בשרת כדי לקבל מידע על התנהגות השרת.
Linux ו-Windows 2019
$ curl -vso /dev/null --connect-timeout 5 192.168.0.4:443
השורה 'Connected to' (מחובר אל) מציינת שלחיצת היד של TCP הסתיימה ללא בעיות.
Expire in 0 ms for 6 (transfer 0x558b3289ffb0) Expire in 5000 ms for 2 (transfer 0x558b3289ffb0) Trying 192.168.0.4... TCP_NODELAY set Expire in 200 ms for 4 (transfer 0x558b3289ffb0) Connected to 192.168.0.4 (192.168.0.4) port 443 (#0) > GET / HTTP/1.1 > Host: 192.168.0.4:443 > User-Agent: curl/7.64.0 > Accept: */* > Empty reply from server Connection #0 to host 192.168.0.4 left intact
Windows 2012 ו-2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
תוצאה של חיבור מוצלח. השורה 'Connected: True' רלוונטית.
Available : 0 Client : System.Net.Sockets.Socket Connected : True ExclusiveAddressUse : False ReceiveBufferSize : 131072 SendBufferSize : 131072 ReceiveTimeout : 0 SendTimeout : 0 LingerState : System.Net.Sockets.LingerOption NoDelay : False
תם הזמן הקצוב לחיבור
התוצאות הבאות מצביעות על כך שחלף הזמן הקצוב לתפוגת החיבור. אם החיבור נכשל בגלל פסק זמן, צריך לעבור אל אימות כתובת ה-IP והיציאה של השרת.
Linux ו-Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
תוצאה של הזמן הקצוב לחיבור:
Trying 192.168.0.4:443... Connection timed out after 5000 milliseconds Closing connection 0
Windows 2012 ו-2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
תוצאה של הזמן הקצוב לחיבור:
New-Object: Exception calling ".ctor" with "2" argument(s): "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. 192.168.0.4:443"
החיבור אופס
איפוס הוא מצב שבו מכשיר שולח חזרה ללקוח חבילת RST, כדי להודיע ללקוח שהחיבור הסתיים. יכול להיות שהחיבור יאופס בגלל אחת מהסיבות הבאות:
- השרת המקבל לא הוגדר לקבל חיבורים לפרוטוקול הזה ביציאה הזו. יכול להיות שהחבילה נשלחה לשרת או ליציאה הלא נכונים, או שהייתה הגדרה שגויה של תוכנת השרת.
- תוכנת חומת האש דחתה את ניסיון החיבור
אם החיבור אופס, צריך לעבור אל אימות הגישה לכתובת ה-IP ולפורט הנכונים.
Linux ו-Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
תוצאה של איפוס החיבור:
Trying 192.168.0.4:443... connect to 192.168.0.4 port 443 failed: Connection refused Failed to connect to 192.168.0.4 port 443: Connection refused Closing connection 0
Windows 2012 ו-2016
PS C:\> New-Object System.Net.Sockets.TcpClientt('DEST_IP_ADDRESS', PORT)
תוצאה של איפוס החיבור:
New-Object: Exception calling ".ctor" with "2" argument(s): "No connection could be made because the target machine actively refused it. 192.168.0.4:443"
אימות כתובת ה-IP והיציאה של השרת
מריצים אחת מהפקודות הבאות בשרת. הם מציינים אם יש שרת שמקשיב ליציאה הנדרשת.
Linux
$ sudo netstat -ltuvnp
הפלט מראה ששרת TCP מאזין לכל כתובת IP של יעד (0.0.0.0) ביציאה 22, ומקבל חיבורים מכל כתובת מקור (0.0.0.0) ומכל יציאת מקור (*). בעמודה PID/Program name מצוין קובץ ההפעלה שמשויך לשקע.
Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 588/sshd tcp6 0 0 :::22 :::* LISTEN 588/sshd udp 0 0 0.0.0.0:68 0.0.0.0:* 334/dhclient udp 0 0 127.0.0.1:323 0.0.0.0:* 429/chronyd udp6 0 0 ::1:323 :::* 429/chronyd
Windows
PS C:\> Get-NetTcpConnection -State "LISTEN" -LocalPort DEST_PORT
הפלט מציג את התוצאות של הפעלת הפקודה עם הערך DEST_PORT שמוגדר ל-443.
מהפלט הזה אפשר לראות ששרת TCP מאזין לכל כתובת (0.0.0.0) ביציאה 443, ומקבל חיבורים מכל כתובת מקור (0.0.0.0) ומכל יציאת מקור (0). בעמודה OwningProcess מצוין מזהה התהליך של התהליך שמאזין לשקע.
LocalAddress LocalPort RemoteAddress RemotePort State AppliedSetting OwningProcess ------------ --------- ------------- ---------- ----- -------------- ------------- :: 443 :: 0 Listen 928 0.0.0.0 443 0.0.0.0 0 Listen 928
אם אתם רואים שהשרת לא משויך ליציאה או לכתובת ה-IP הנכונות, או שהקידומת המרוחקת לא תואמת ללקוח, צריך לעיין במאמרי העזרה של השרת או לפנות לספק כדי לפתור את הבעיה. השרת צריך להיות קשור לכתובת ה-IP של ממשק מסוים או ל-0.0.0.0, והוא צריך לאפשר חיבורים מקידומת ה-IP הנכונה של הלקוח או מ-0.0.0.0.
אם שרת האפליקציות קשור לכתובת ה-IP והיציאה הנכונות, יכול להיות שהלקוח ניגש ליציאה הלא נכונה, שפרוטוקול ברמה גבוהה יותר (לרוב TLS) דוחה באופן פעיל את החיבור, או שיש חומת אש שדוחה את החיבור.
בודקים שהלקוח והשרת משתמשים באותה גרסת TLS ובאותה הצפנה.
בודקים שלקוח ניגש ליציאה הנכונה.
אם השלבים הקודמים לא פותרים את הבעיה, צריך להמשיך אל בדיקת חומת האש בלקוח ובשרת כדי לראות אם יש השמטות של מנות.
בדיקה של חומת האש בלקוח ובשרת כדי לראות אם יש מנות שנמחקו
אם אי אפשר להגיע לשרת ממכונת הלקוח הווירטואלית, אבל השרת מאזין ביציאה הנכונה, יכול להיות שאחת מהמכונות הווירטואליות מריצה תוכנת חומת אש שמשליכה חבילות שמשויכות לחיבור. בודקים את חומת האש ב-VM של הלקוח וב-VM של השרת באמצעות הפקודות הבאות.
אם כלל מסוים חוסם את התעבורה, אפשר לעדכן את תוכנת חומת האש כדי לאפשר את התעבורה. אם אתם מעדכנים את חומת האש, עליכם לפעול בזהירות כשאתם מכינים ומריצים את הפקודות, כי חומת אש שההגדרה שלה שגויה עלולה לחסום תנועה לא צפויה. לפני שממשיכים, כדאי להגדיר גישה למסוף הטורי של ה-VM.
Linux iptables
בודקים את מספר המנות כדי לראות כמה מנות עברו עיבוד בכל שרשרת וכלל של iptables שהותקנו. כדי לקבוע אילו כללי DROP מתאימים, צריך להשוות בין כתובות ה-IP והיציאות של המקור והיעד לבין הקידומות והיציאות שצוינו בכללי iptables.
אם כלל תואם מציג יותר ויותר הודעות שנמחקו בגלל פסק זמן לחיבור, כדאי לעיין בתיעוד של iptables כדי להחיל את הכלל allow הנכון על החיבורים המתאימים.
$ sudo iptables -L -n -v -x
בדוגמה הזו של שרשרת INPUT אפשר לראות שמנות מכל כתובת IP לכל כתובת IP באמצעות יציאת TCP של היעד 5000 יימחקו בחומת האש.
העמודה pkts מציינת שהכלל השליך 10,342 מנות. כדי לבדוק את זה, אם תיצרו חיבורים שהכלל הזה יבטל, תראו שהמונה pkts יגדל, וכך תוכלו לוודא שאופן הפעולה תקין.
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 10342 2078513 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5000
אפשר להוסיף כלל לתעבורת נתונים נכנסת (ingress) או יוצאת (egress) ל-iptables באמצעות הפקודות הבאות:
כלל לתעבורת נתונים נכנסת (ingress):
$ sudo iptables -A INPUT -p tcp -s SOURCE_IP_PREFIX --dport SERVER_PORT -j ACCEPT
כלל לתעבורת נתונים יוצאת (egress):
$ sudo iptables -A OUTPUT -p tcp -d DEST_IP_PREFIX --dport DEST_PORT -j ACCEPT
חומת האש של Windows
בודקים בחומת האש של Windows שהחיבור מורשה לצאת מהלקוח ולהיכנס לשרת. אם כלל חוסם את התעבורה, צריך לבצע את התיקונים הנדרשים בחומת האש של Windows כדי לאפשר את החיבורים. אפשר גם להפעיל את הרישום ביומן של חומת האש של Windows.
התנהגות ברירת המחדל של חומת האש של Windows היא השמטה שקטה של מנות שנדחו, מה שגורם לפסק זמן.
הפקודה הזו בודקת את השרת. כדי לבדוק את כללי התעבורה היוצאת במכונה הווירטואלית של הלקוח, משנים את הערך -match ל-Outbound.
PS C:\> Get-NetFirewallPortFilter | `
>> Where-Object LocalPort -match "PORT" | `
>> Get-NetFirewallRule | `
>> Where-Object {$_.Direction -match "Inbound" -and $_.Profile -match "Any"}
Name : {80D79988-C7A5-4391-902D-382369B4E4A3}
DisplayName : iperf3 udp
Description :
DisplayGroup :
Group :
Enabled : True
Profile : Any
Platform : {}
Direction : Inbound
Action : Allow
EdgeTraversalPolicy : Block
LooseSourceMapping : False
LocalOnlyMapping : False
Owner :
PrimaryStatus : OK
Status : The rule was parsed successfully from the store. (65536)
EnforcementStatus : NotApplicable
PolicyStoreSource : PersistentStore
PolicyStoreSourceType : Local
אפשר להוסיף כללים חדשים לחומת האש ב-Windows באמצעות הפקודות הבאות.
כלל לתעבורת נתונים יוצאת (egress):
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=out action=allow protocol=TCP remoteport=DEST_PORT
כלל לתעבורת נתונים נכנסת (ingress):
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=in action=allow protocol=TCP localport=PORT
תוכנת צד שלישי
חומות אש או תוכנות אנטי-וירוס של אפליקציות צד שלישי יכולות גם להפיל או לדחות חיבורים. כדאי לעיין בתיעוד שסופק על ידי הספק.
אם מצאתם בעיה בכללי חומת האש ותיקנתם אותה, בדקו מחדש את הקישוריות. אם נראה שכללי חומת האש לא גורמים לבעיה, עוברים אל בדיקת ההגדרה של ניתוב מערכת ההפעלה.
בדיקת הגדרות הניתוב של מערכת ההפעלה
בעיות בניתוב במערכת ההפעלה יכולות לנבוע מאחת מהסיבות הבאות:
- בעיות בקביעת מסלול הן נפוצות ביותר במכונות וירטואליות עם כמה ממשקי רשת, בגלל המורכבות הנוספת של קביעת המסלול.
- במכונה וירטואלית שנוצרה ב- Google Cloud עם ממשק רשת יחיד, בעיות ניתוב קורות בדרך כלל רק אם מישהו שינה באופן ידני את טבלת הניתוב שמוגדרת כברירת מחדל.
- במכונה וירטואלית שהועברה משרת מקומי, יכול להיות שהמכונה תעביר הגדרות ניתוב או MTU שהיו נחוצות בשרת המקומי, אבל גורמות לבעיות ברשת ה-VPC.
אם אתם משתמשים במכונת VM עם כמה ממשקי רשת, צריך להגדיר מסלולים כדי לצאת אל ה-vNIC והרשת המשנית הנכונים. לדוגמה, יכול להיות שבמכונה וירטואלית מוגדרים נתיבים כך שתעבורה שמיועדת לרשתות משנה פנימיות נשלחת לממשק רשת וירטואלי אחד, אבל שער ברירת המחדל (יעד 0.0.0.0/0) מוגדר בממשק רשת וירטואלי אחר שיש לו כתובת IP חיצונית או גישה ל-Cloud NAT.
אתם יכולים לבדוק מסלולים בודדים בנפרד או לעיין בטבלת הניתוב של מכונת ה-VM כולה. אם אחת מהגישות האלה חושפת בעיות בטבלת הניתוב, אפשר להיעזר בהוראות שבקטע עדכון טבלאות ניתוב לפי הצורך.
בדיקת כל המסלולים
כדאי לרשום את כל המסלולים כדי להבין אילו מסלולים כבר קיימים במכונה הווירטואלית.
Linux
$ ip route show table all
default via 10.3.0.1 dev ens4 10.3.0.1 dev ens4 scope link local 10.3.0.19 dev ens4 table local proto kernel scope host src 10.3.0.19 broadcast 10.3.0.19 dev ens4 table local proto kernel scope link src 10.3.0.19 broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 ::1 dev lo proto kernel metric 256 pref medium fe80::/64 dev ens4 proto kernel metric 256 pref medium local ::1 dev lo table local proto kernel metric 0 pref medium local fe80::4001:aff:fe03:13 dev ens4 table local proto kernel metric 0 pref medium multicast ff00::/8 dev ens4 table local proto kernel metric 256 pref medium
Windows
PS C:\> Get-NetRoute
ifIndex DestinationPrefix NextHop RouteMetric ifMetric PolicyStore ------- ----------------- ------- ----------- -------- ----------- 4 255.255.255.255/32 0.0.0.0 256 5 ActiveStore 1 255.255.255.255/32 0.0.0.0 256 75 ActiveStore 4 224.0.0.0/4 0.0.0.0 256 5 ActiveStore 1 224.0.0.0/4 0.0.0.0 256 75 ActiveStore 4 169.254.169.254/32 0.0.0.0 1 5 ActiveStore 1 127.255.255.255/32 0.0.0.0 256 75 ActiveStore 1 127.0.0.1/32 0.0.0.0 256 75 ActiveStore 1 127.0.0.0/8 0.0.0.0 256 75 ActiveStore 4 10.3.0.255/32 0.0.0.0 256 5 ActiveStore 4 10.3.0.31/32 0.0.0.0 256 5 ActiveStore 4 10.3.0.1/32 0.0.0.0 1 5 ActiveStore 4 10.3.0.0/24 0.0.0.0 256 5 ActiveStore 4 0.0.0.0/0 10.3.0.1 0 5 ActiveStore 4 ff00::/8 :: 256 5 ActiveStore 1 ff00::/8 :: 256 75 ActiveStore 4 fe80::b991:6a71:ca62:f23f/128 :: 256 5 ActiveStore 4 fe80::/64 :: 256 5 ActiveStore 1 ::1/128 :: 256 75 ActiveStore
בדיקת מסלולים ספציפיים
אם נראה שבעיה מסוימת קשורה לקידומת IP מסוימת, צריך לבדוק אם קיימים נתיבים מתאימים לכתובות ה-IP של המקור והיעד במכונות הווירטואליות של הלקוח והשרת.
Linux
$ ip route get DEST_IP
תוצאה טובה:
מוצג מסלול תקין. במקרה הזה, המנות יוצאות מהממשק ens4.
10.3.0.34 via 10.3.0.1 dev ens4 src 10.3.0.26 uid 1000 cache
תוצאה לא טובה:
התוצאה הזו מאשרת שחבילות נמחקות כי אין נתיב לרשת היעד. מוודאים שטבלת הניתוב מכילה נתיב לממשק היציאה הנכון.
**RTNETLINK answers: Network is unreachable
Windows
PS C:\> Find-NetRoute -RemoteIpAddress "DEST_IP"
תוצאה טובה:
IPAddress : 192.168.0.2 InterfaceIndex : 4 InterfaceAlias : Ethernet AddressFamily : IPv4 Type : Unicast PrefixLength : 24 PrefixOrigin : Dhcp SuffixOrigin : Dhcp AddressState : Preferred ValidLifetime : 12:53:13 PreferredLifetime : 12:53:13 SkipAsSource : False PolicyStore : ActiveStore Caption : Description : ElementName : InstanceID : ;:8=8:8:9<>55>55:8:8:8:55; AdminDistance : DestinationAddress : IsStatic : RouteMetric : 256 TypeOfRoute : 3 AddressFamily : IPv4 CompartmentId : 1 DestinationPrefix : 192.168.0.0/24 InterfaceAlias : Ethernet InterfaceIndex : 4 InterfaceMetric : 5 NextHop : 0.0.0.0 PreferredLifetime : 10675199.02:48:05.4775807 Protocol : Local Publish : No State : Alive Store : ActiveStore ValidLifetime : 10675199.02:48:05.4775807 PSComputerName : ifIndex : 4
תוצאה לא טובה:
Find-NetRoute : The network location cannot be reached. For information about network troubleshooting, see Windows Help.
At line:1 char:1
+ Find-NetRoute -RemoteIpAddress "192.168.0.4"
+ ----------------------------------------
+ CategoryInfo : NotSpecified: (MSFT_NetRoute:ROOT/StandardCimv2/MSFT_NetRoute) [Find-NetRoute], CimException
+ FullyQualifiedErrorId : Windows System Error 1231,Find-NetRoute
הפקודה הזו מאשרת שהמנות נפסלות כי אין נתיב לכתובת ה-IP של היעד. מוודאים שיש שער ברירת מחדל, ושהשער חל על vNIC ועל רשת נכונים.
עדכון טבלאות הניתוב
אם צריך, אפשר להוסיף מסלול לטבלת המסלולים של מערכת ההפעלה. לפני שמריצים פקודה לעדכון טבלת הניתוב של מכונת הניתוב הווירטואלית, מומלץ להכיר את הפקודות ולפתח הבנה של ההשלכות האפשריות. שימוש לא נכון בפקודות לעדכון נתיבים עלול לגרום לבעיות לא צפויות או לניתוק מהמכונה הווירטואלית. לפני שממשיכים, כדאי להגדיר גישה למסוף הטורי של ה-VM.
הוראות לעדכון מסלולים מופיעות במסמכי מערכת ההפעלה.
אם מצאתם בעיה במסלולים ותיקנתם אותה, בדקו שוב את הקישוריות. אם נראה שהבעיה לא קשורה לנתיבים, עוברים אל בדיקת MTU של הממשק.
בדיקת MTU
ערך ה-MTU של הממשק של מכונת ה-VM צריך להיות זהה לערך ה-MTU של רשת ה-VPC שאליה היא מצורפת. באופן אידיאלי, למכונות וירטואליות שמתקשרות ביניהן יש גם ערכי MTU תואמים. בדרך כלל, ערכי MTU לא תואמים לא מהווים בעיה עבור TCP, אבל הם יכולים להוות בעיה עבור UDP.
בודקים את ה-MTU של ה-VPC. אם המכונות הווירטואליות נמצאות בשתי רשתות שונות, צריך לבדוק את שתי הרשתות.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
בודקים את הגדרת ה-MTU בממשקי הרשת של הלקוח והשרת.
Linux
$ netstat -i
לממשק lo (loopback) יש תמיד MTU של 65536, ואפשר להתעלם ממנו בשלב הזה.
Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg ens4 1460 8720854 0 0 0 18270406 0 0 0 BMRU lo 65536 53 0 0 0 53 0 0 0 LRU
Windows
PS C:\> Get-NetIpInterface
לממשקי פסאודו של Loopback תמיד יש MTU של 4294967295, ואפשר להתעלם מהם בשלב הזה.
ifIndex InterfaceAlias Address NlMtu(Bytes) Interface Dhcp Connection PolicyStore
Family Metric State
------- -------------- ------- ------------ --------- ---- ---------- -----------
4 Ethernet IPv6 1500 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
4 Ethernet IPv4 1460 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected Active
אם ערכי ה-MTU של הממשק והרשת לא זהים, אפשר להגדיר מחדש את ה-MTU של הממשק. מידע נוסף זמין במאמר מכונות וירטואליות והגדרות MTU. אם הם תואמים, וביצעתם את השלבים לפתרון בעיות עד עכשיו, כנראה שהבעיה היא בשרת עצמו. הוראות לפתרון בעיות בשרת זמינות במאמר בדיקת יומן השרת כדי לקבל מידע על התנהגות השרת.
בדיקת יומני השרת כדי לקבל מידע על התנהגות השרת
אם השלבים הקודמים לא פותרים את הבעיה, יכול להיות שהאפליקציה גורמת לפסק זמן. בודקים את יומני השרת והאפליקציה כדי לראות אם יש התנהגות שיכולה להסביר את מה שרואים.
מקורות יומנים שכדאי לבדוק:
- Cloud Logging למכונה הווירטואלית
- VM Serial Logs
- syslog ו-kern.log ב-Linux, או 'מציג האירועים' ב-Windows
אם הבעיות נמשכות
אם הבעיות נמשכות, אפשר לעבור אל קבלת תמיכה כדי לקבל מידע על השלבים הבאים. כדאי לשתף את הפלט משלבי פתרון הבעיות הקודמים עם משתפי פעולה אחרים.
פתרון בעיות שקשורות לזמן טעינה או לאובדן נתונים ברשת שגורמות לבעיות ברוחב הפס
בעיות של השהיית רשת או אובדן נתונים נגרמות בדרך כלל ממיצוי משאבים או מנקודות צוואר בקבוק במכונה וירטואלית או בנתיב רשת. לפעמים, אובדן רשת יכול לגרום לפסק זמן לחיבור לסירוגין. גורמים כמו מיצוי של vCPU או רוויה של vNIC מובילים לעלייה בזמן האחזור ולאובדן מנות, וכתוצאה מכך לירידה בביצועי הרשת.
ההנחיות הבאות מבוססות על ההנחה שהחיבורים לא נקטעים באופן עקבי בגלל חוסר זמן תגובה, אלא שאתם נתקלים בבעיות של קיבולת או ביצועים מוגבלים. אם אתם רואים אובדן מנות מלא, כדאי לעיין במאמר בנושא פתרון בעיות של כשל מלא בחיבור.
תנודות קלות בזמן האחזור, כמו שינויים של כמה אלפיות השנייה, הן תופעה נורמלית. זמני האחזור משתנים בגלל עומס ברשת או תורים בתוך המכונה הווירטואלית.
קביעת ערכי החיבור
קודם אוספים את הפרטים הבאים:
- בדף VM instances, אוספים את הפרטים הבאים לגבי שתי המכונות הווירטואליות:
- שמות של מכונות וירטואליות
- אזורי VM
- כתובות IP פנימיות של כרטיסי ה-vNIC שמתקשרים
- מתוך ההגדרה של תוכנת שרת היעד, אוספים את הפרטים הבאים:
- פרוטוקול שכבה 4
- יציאת היעד
אם אתם נתקלים בבעיות בכמה מכונות וירטואליות, בוחרים מכונת מקור אחת ומכונת יעד אחת שבהן יש בעיות ומשתמשים בערכים האלה. באופן כללי, לא צריך את יציאת המקור של החיבור.
אחרי שתאספו את המידע הזה, תוכלו להמשיך אל בדיקת בעיות ברשת Google הבסיסית.
בדיקת בעיות ברשת הבסיסית של Google
אם ההגדרה שלכם היא קיימת ולא השתנתה לאחרונה, יכול להיות שהבעיה היא ברשת הבסיסית של Google. בודקים את לוח בקרה לביצועי הענן ב-Network Intelligence Center כדי לראות אם יש אובדן מנות בין האזורים של המכונות הווירטואליות. אם יש עלייה באובדן מנות בין האזורים במהלך פרק הזמן שבו נתקלתם בפסק זמן ברשת, יכול להיות שהבעיה היא ברשת הפיזית שעליה מבוססת הרשת הווירטואלית שלכם. לפני ששולחים בקשת תמיכה, כדאי לבדוק את לוח הבקרה של סטטוס שירותי Google Cloud כדי לראות אם יש בעיות ידועות.
אם נראה שהבעיה לא קשורה לרשת הבסיסית של Google, עוברים אל בדיקת זמן האחזור של לחיצת היד.
בדיקת זמן האחזור של לחיצת היד
כל הפרוטוקולים שמבוססים על חיבור גורמים להשהיה מסוימת בזמן שהם מבצעים את לחיצת היד של הגדרת החיבור. כל לחיצת יד של פרוטוקול מוסיפה לתקורה. לדוגמה, בחיבורי SSL/TLS, לחיצת היד ב-TCP צריכה להסתיים לפני שלחיצת היד ב-SSL/TLS יכולה להתחיל, ואז לחיצת היד ב-TLS צריכה להסתיים לפני שניתן להעביר נתונים.
השהיית ההתקשרות באותו אזור Google Cloud היא בדרך כלל זניחה, אבל התקשרויות עם מיקומים מרוחקים בעולם עלולות להוסיף עיכובים גדולים יותר בתחילת יצירת החיבור. אם יש לכם משאבים באזורים מרוחקים, תוכלו לבדוק אם השהייה שאתם רואים נובעת משיטת אימות (handshake) של פרוטוקול.
Linux ו-Windows 2019
$ curl -o /dev/null -Lvs -w 'tcp_handshake: %{time_connect}s, application_handshake: %{time_appconnect}s' DEST_IP:PORT
tcp_handshake: 0.035489s, application_handshake: 0.051321s
- tcp_handshake הוא משך הזמן מהרגע שבו הלקוח שולח את חבילת ה-SYN הראשונית ועד שהלקוח שולח את ה-ACK של לחיצת היד של ה-TCP.
- application_handshake הוא הזמן שחל מהמנה הראשונה של SYN של לחיצת היד בפרוטוקול TCP ועד לסיום לחיצת היד בפרוטוקול TLS (בדרך כלל).
- זמן נוסף של לחיצת יד = application_handshake - tcp_handshake
Windows 2012 ו-2016
לא זמין עם כלי ברירת המחדל של מערכת ההפעלה. אפשר להשתמש בזמן הלוך ושוב של ICMP כהפניה אם כללי חומת האש מאפשרים זאת.
אם זמן האחזור ארוך יותר ממה שאפשר לצפות לו בהתבסס על תהליך הלחיצה, צריך להמשיך אל קביעת התפוקה המקסימלית של סוג מכונת ה-VM.
קביעת התפוקה המקסימלית של סוג ה-VM
התפוקה של תעבורת נתונים יוצאת (egress) רשת של VM מוגבלת על ידי ארכיטקטורת מעבד (CPU) של ה-VM ומספר ה-vCPU. כדי לברר מה רוחב הפס הפוטנציאלי של ה-VM ליציאת נתונים, אפשר לעיין בדף רוחב פס ברשת.
אם המכונה הווירטואלית לא עומדת בדרישות שלכם לגבי תעבורת נתונים יוצאת (egress), כדאי לשדרג למכונה וירטואלית עם קיבולת גדולה יותר. הוראות מפורטות זמינות במאמר שינוי סוג המכונה של מופע.
אם סוג המכונה אמור לאפשר רוחב פס מספיק ליציאה, צריך לבדוק אם השימוש ב-Persistent Disk מפריע ליציאה מהרשת. לפעולות של Persistent Disk מותר לתפוס עד 60% מרוחב הפס הכולל של הרשת במכונה הווירטואלית. כדי לבדוק אם פעולות של דיסק אחסון מתמיד (persistent disk) עלולות להפריע לרוחב הפס של הרשת, אפשר לעיין במאמר בנושא בדיקת הביצועים של דיסק אחסון מתמיד.
תעבורת נתונים נכנסת (ingress) לרשת של VM לא מוגבלת על ידי רשת ה-VPC או סוג המכונה הווירטואלית. במקום זאת, היא נקבעת לפי הביצועים של תור המנות ושל העיבוד של מערכת ההפעלה או האפליקציה של המכונה הווירטואלית. אם רוחב הפס של תעבורת הנתונים היוצאת (egress) מספיק אבל יש בעיות בתעבורת הנתונים הנכנסת (ingress), כדאי לעיין במאמר בדיקת יומני שרת כדי לקבל מידע על התנהגות השרת.
בדיקת ה-MTU של הממשק
אפשר להגדיר את ה-MTU של רשת VPC. ערך ה-MTU של הממשק במכונה הווירטואלית צריך להיות זהה לערך ה-MTU של רשת ה-VPC שאליה הממשק מחובר. במצב של צימוד רשתות VPC, למכונות וירטואליות ברשתות שונות יכולים להיות ערכי MTU שונים. במקרה כזה, צריך להחיל את ערך ה-MTU הקטן יותר על הממשקים המשויכים. בדרך כלל, אי התאמות של MTU לא מהוות בעיה עבור TCP, אבל הן יכולות להוות בעיה עבור UDP.
בודקים את ה-MTU של ה-VPC. אם המכונות הווירטואליות נמצאות בשתי רשתות שונות, צריך לבדוק את שתי הרשתות.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
בודקים את הגדרת ה-MTU של ממשק הרשת.
Linux
לממשק lo (loopback) יש תמיד MTU של 65536, ואפשר להתעלם ממנו בשלב הזה.
$ netstat -i
Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg ens4 1460 8720854 0 0 0 18270406 0 0 0 BMRU lo 65536 53 0 0 0 53 0 0 0 LRU
Windows
PS C:\> Get-NetIpInterface
לממשקי פסאודו של Loopback יש תמיד MTU של 4294967295, ואפשר להתעלם מהם בשלב הזה.
ifIndex InterfaceAlias Address NlMtu(Bytes) Interface Dhcp Connection PolicyStore
Family Metric State
------- -------------- ------- ------------ --------- ---- ---------- -----------
4 Ethernet IPv6 1500 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
4 Ethernet IPv4 1460 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected Active
אם ערכי ה-MTU של הממשק והרשת לא זהים, אפשר להגדיר מחדש את ה-MTU של הממשק. הוראות לעדכון MTU במכונות וירטואליות של Windows זמינות במאמר מכונות וירטואליות והגדרות MTU. אם הם תואמים, סביר שהבעיה היא זמינות השרת. השלב הבא הוא בדיקת היומנים כדי לראות אם בוצעה הפעלה מחדש של מכונה וירטואלית, אם היא הופסקה או אם בוצעה העברה שלה בזמן אמת, כדי לראות אם קרה משהו למכונה הווירטואלית במהלך הזמן הרלוונטי.
בדיקת היומנים כדי לראות אם מכונה וירטואלית הופעלה מחדש, נעצרה או הועברה בשידור חי
במהלך מחזור החיים של מכונה וירטואלית, המשתמש יכול להפעיל אותה מחדש, לבצע העברה פעילה לצורך תחזוקה, או שבמקרים נדירים, המכונה הווירטואלית עלולה להיעלם ולהיווצר מחדש אם יש כשל במארח הפיזי שמכיל אותה.Google Cloud האירועים האלה עלולים לגרום לעלייה קצרה בזמן האחזור או לפסק זמן בחיבור. אם אחד מהדברים האלה קורה למכונה הווירטואלית, האירוע מתועד.
כדי לראות את היומנים של מכונת ה-VM:
נכנסים לדף Logging במסוף Google Cloud .
בוחרים את מסגרת הזמן שבה התרחש זמן האחזור.
כדי לבדוק אם אירוע של VM התרחש בסמוך לפרק הזמן שבו התרחשה ההשהיה, משתמשים בשאילתת הרישום ביומן הבאה:
resource.labels.instance_id:"INSTANCE_NAME" resource.type="gce_instance" ( protoPayload.methodName:"compute.instances.hostError" OR protoPayload.methodName:"compute.instances.OnHostMaintenance" OR protoPayload.methodName:"compute.instances.migrateOnHostMaintenance" OR protoPayload.methodName:"compute.instances.terminateOnHostMaintenance" OR protoPayload.methodName:"compute.instances.stop" OR protoPayload.methodName:"compute.instances.reset" OR protoPayload.methodName:"compute.instances.automaticRestart" OR protoPayload.methodName:"compute.instances.guestTerminate" OR protoPayload.methodName:"compute.instances.instanceManagerHaltForRestart" OR protoPayload.methodName:"compute.instances.preempted" )
אם מכונות וירטואליות לא הופעלו מחדש או הועברו במהלך הזמן הרלוונטי, יכול להיות שהבעיה היא מחסור במשאבים. כדי לבדוק, עוברים אל בדיקת נתוני הרשת ומערכת ההפעלה לגבי מנות שנמחקו בגלל ניצול יתר של משאבים.
בדיקת נתונים סטטיסטיים של הרשת ומערכת ההפעלה לגבי מנות שנמחקו בגלל מיצוי משאבים
תשישות משאבים הוא מונח כללי שאומר שמשאב מסוים במכונה הווירטואלית, כמו רוחב פס של תעבורת נתונים יוצאת, נדרש לטפל ביותר נתונים ממה שהוא יכול. ניצול יתר של משאבים עלול לגרום להשלכת מנות באופן מחזורי, מה שגורם לזמן אחזור של חיבור או לפסק זמן. יכול להיות שלא תראו את פסק הזמן הזה בהפעלה של הלקוח או השרת, אבל הוא עשוי להופיע עם הזמן כשהמערכת ממצה את המשאבים.
בהמשך מופיעה רשימה של פקודות שמציגות את מוני החבילות ואת הנתונים הסטטיסטיים. חלק מהפקודות האלה משכפלות את התוצאות של פקודות אחרות. במקרים כאלה, אפשר להשתמש בפקודה שהכי מתאימה לכם. כדאי לעיין בהערות בכל קטע כדי להבין טוב יותר את התוצאה הרצויה של הפעלת הפקודה. יכול להיות שימושי להריץ את הפקודות בזמנים שונים כדי לראות אם השמטות או השגיאות מתרחשות באותו זמן שבו הבעיה מתרחשת.
Linux
משתמשים בפקודה
netstatכדי לראות את הנתונים הסטטיסטיים של הרשת.$ netstat -sTcpExt: 341976 packets pruned from receive queue because of socket buffer overrun 6 ICMP packets dropped because they were out-of-window 45675 TCP sockets finished time wait in fast timer 3380 packets rejected in established connections because of timestamp 50065 delayed acks sent
הפלט של הפקודה netstat כולל נתונים סטטיסטיים של הרשת, שמכילים ערכים של מנות שהושלכו לפי פרוטוקול. יכול להיות שהמנות נפסלו בגלל שהאפליקציה או ממשק הרשת מיצו את המשאבים שלהם. בודקים את הסיבה לשינוי הערך של המונה כדי להבין למה הוא עלה.
בודקים את היומנים שמתאימים ל-
nf_conntrack: table full, dropping packetב-kern.log.Debian:
cat /var/log/kern.log | grep "dropping packet"CentOS:
sudo cat /var/log/dmesg | grep "dropping packet"היומן הזה מציין שטבלת מעקב החיבורים של המכונה הווירטואלית הגיעה למספר החיבורים המקסימלי שאפשר לעקוב אחריהם. יכול להיות שחיבורים נוספים ל-VM הזה וממנו יסתיימו בטיימאאוט. אם האפשרות conntrack הופעלה, אפשר למצוא את מספר החיבורים המקסימלי באמצעות הפקודה:
sudo sysctl net.netfilter.nf_conntrack_maxכדי להגדיל את הערך של מספר החיבורים המקסימלי למעקב, אפשר לשנות את sysctl
net.netfilter.nf_conntrack_maxאו לפצל את עומס העבודה של המכונות הווירטואליות בין כמה מכונות וירטואליות כדי להפחית את העומס.
ממשק המשתמש של Windows
Perfmon
- בתפריט Windows, מחפשים את האפשרות perfmon ופותחים את התוכנה.
- בתפריט הימני, בוחרים באפשרות ביצועים > כלי מעקב > כלי מעקב אחר ביצועים.
- בתצוגה הראשית, לוחצים על סימן הפלוס הירוק "+" כדי להוסיף מוני ביצועים לתרשים המעקב. המונים הבאים רלוונטיים:
- מתאם רשת
- אורך תור הפלט
- מנות יוצאות שנמחקו
- שגיאות במנות יוצאות
- חבילות שהתקבלו ונמחקו
- שגיאות בחבילות שהתקבלו
- חבילות שהתקבלו לא ידועות
- ממשק רשת
- אורך תור הפלט
- מנות יוצאות שנמחקו
- שגיאות במנות יוצאות
- חבילות שהתקבלו ונמחקו
- שגיאות בחבילות שהתקבלו
- חבילות שהתקבלו לא ידועות
- פעילות של כרטיס רשת לכל מעבד
- מספר נמוך של אינדיקציות לקבלת משאבים לשנייה
- מספר נמוך של מנות שהתקבלו לשנייה
- מעבד
- % Interrupt Time (אחוז הזמן שבו התרחשו הפרעות)
- % זמן מועדף
- % Processor Time (זמן מעבד)
- % מהזמן של המשתמש
- מתאם רשת
הכלי Pefmon מאפשר לכם לשרטט את המונים הקודמים בתרשים של פעולות על ציר הזמן. הנתונים האלה יכולים להיות שימושיים כשמבצעים בדיקות או כששרת מושפע. עליות פתאומיות במונים שקשורים ל-CPU, כמו Interrupt Time ו-Privileged Time, יכולות להעיד על בעיות רוויה כשהמכונה הווירטואלית מגיעה למגבלות של תפוקת ה-CPU. יכול להיות שיהיו השלכות על מנות ועל שגיאות אם המעבד יהיה עמוס מדי, מה שיגרום לאובדן מנות לפני שהן יעובדו על ידי שקעי הלקוח או השרת. לבסוף, גם אורך התור של הפלט יגדל במהלך רוויית המעבד, ככל שיותר מנות יתווספו לתור לעיבוד.
Windows Powershell
PS C:\> netstat -s
IPv4 Statistics Packets Received = 56183 Received Header Errors = 0 Received Address Errors = 0 Datagrams Forwarded = 0 Unknown Protocols Received = 0 Received Packets Discarded = 25 Received Packets Delivered = 56297 Output Requests = 47994 Routing Discards = 0 Discarded Output Packets = 0 Output Packet No Route = 0 Reassembly Required = 0 Reassembly Successful = 0 Reassembly Failures = 0 Datagrams Successfully Fragmented = 0 Datagrams Failing Fragmentation = 0 Fragments Created = 0
הפלט של הפקודה netstat כולל נתונים סטטיסטיים של הרשת, שמכילים ערכים של מנות שהושלכו לפי פרוטוקול. יכול להיות שהמנות נפסלו בגלל שהאפליקציה או ממשק הרשת מיצו את המשאבים שלהם.
אם אתם רואים שנגמרים המשאבים, אתם יכולים לנסות לפצל את עומס העבודה בין יותר מופעים, לשדרג את המכונה הווירטואלית למכונה עם יותר משאבים, לכוונן את מערכת ההפעלה או את האפליקציה בהתאם לצרכים ספציפיים של ביצועים, להזין את הודעת השגיאה במנוע חיפוש כדי לחפש פתרונות אפשריים או לבקש עזרה באחת מהשיטות שמתוארות בקטע אם הבעיות נמשכות.
אם נראה שהבעיה לא קשורה לניצול יתר של משאבים, יכול להיות שהיא קשורה לתוכנת השרת עצמה. הוראות לפתרון בעיות בתוכנת שרת זמינות במאמר בדיקת יומני השרת לקבלת מידע על התנהגות השרת.
בדיקת יומני השרת כדי לקבל מידע על התנהגות השרת
אם השלבים הקודמים לא חושפים בעיה, יכול להיות שפסק הזמן נגרם בגלל התנהגות של האפליקציה, כמו עיבודים תקועים שנגרמים בגלל מיצוי של vCPU. צריך לבדוק את היומנים של השרת והאפליקציות כדי לראות אם יש בהם סימנים להתנהגות שאתם חווים.
לדוגמה, שרת שחווה עלייה בזמן האחזור בגלל מערכת במעלה הזרם, כמו מסד נתונים שנמצא תחת עומס, עשוי להוסיף לתור כמות מוגזמת של בקשות, מה שעלול לגרום לעלייה בשימוש בזיכרון ולזמני המתנה ארוכים יותר של המעבד. הגורמים האלה עלולים לגרום לחיבורים שנכשלו או לחריגה ממאגר הנתונים הזמני של השקע.
מדי פעם מתרחש אובדן מנות בחיבורי TCP, אבל בדרך כלל אישור סלקטיבי ושידור מחדש של מנות משחזרים את המנות שאבדו, וכך נמנעת תפוגת הזמן הקצוב לתפוגה של החיבור. במקום זאת, כדאי לקחת בחשבון שפסק זמן יכול להיות תוצאה של כשל בשרת האפליקציות או של פריסה מחדש שלו, שגורמת לכשל זמני בחיבורים.
אם אפליקציית השרת שלכם מסתמכת על חיבור למסד נתונים או לשירות אחר, צריך לוודא שהשירותים המשולבים לא פועלים בצורה לא תקינה. יכול להיות שהאפליקציה שלכם תעקוב אחרי המדדים האלה.
אם הבעיות נמשכות
אם הבעיות נמשכות, אפשר לעבור אל קבלת תמיכה כדי לקבל מידע על השלבים הבאים. כדאי לשתף את הפלט של השלבים לפתרון בעיות עם משתפי פעולה אחרים.
המאמרים הבאים
- אם הבעיה נמשכת, אפשר לעיין בדף מקורות מידע.