פתרון בעיות בקישוריות פנימית בין מכונות וירטואליות
במסמך הזה מפורטים השלבים לפתרון בעיות של קישוריות בין מכונות וירטואליות של 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 כפי שמתואר ב 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 .
מאתרים את מכונת המקור הווירטואלית.
לוחצים על SSH בעמודה Connect בשורה של המכונה הווירטואלית הרלוונטית.
מריצים את הפקודה הבאה בשורת הפקודה של מכונת הלקוח. מחליפים את DEST_IP:DEST_PORT בכתובת ה-IP והיציאה של היעד.
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
Windows
נכנסים לדף VM instances במסוף Google Cloud .
מאתרים את מכונת המקור הווירטואלית.
משתמשים באחת מהשיטות שמתוארות במאמר התחברות למכונות 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
השורה 'מחובר אל' מציינת שלחיצת היד של 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
הפלט מציג את התוצאות של הפעלת הפקודה עם הערך 443 שהוגדר ל-DEST_PORT.
מהפלט הזה אפשר לראות ששרת 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 Firewall
בודקים בחומת האש של 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
תוכנת צד שלישי
חומות אש או תוכנות אנטי-וירוס של צד שלישי יכולות גם להפיל או לדחות חיבורים. כדאי לעיין בתיעוד שסופק על ידי הספק.
אם מצאתם בעיה בכללי חומת האש ותיקנתם אותה, בדקו מחדש את הקישוריות. אם נראה שכללי חומת האש לא גורמים לבעיה, עוברים אל בדיקת ההגדרה של ניתוב מערכת ההפעלה.
בדיקה של הגדרות הניתוב במערכת ההפעלה
בעיות בניתוב במערכת ההפעלה יכולות לנבוע מאחד מהמקרים הבאים:
- בעיות בקביעת מסלול נפוצות בעיקר במכונות וירטואליות עם כמה ממשקי רשת, בגלל המורכבות הנוספת של קביעת המסלול.
- במכונת VM שנוצרה ב- 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
תוצאה לא טובה:
התוצאה הזו מאשרת שהמערכת מבטלת חבילות (packets) כי אין נתיב לרשת היעד. מוודאים שטבלת הניתוב מכילה נתיב לממשק היציאה הנכון.
**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)
- syslog ו-kern.log ב-Linux, או 'מציג האירועים' ב-Windows
אם הבעיות נמשכות
אם הבעיות נמשכות, אפשר לעבור אל קבלת תמיכה כדי לקבל מידע על השלבים הבאים. כדאי לשתף את הפלט משלבי פתרון הבעיות הקודמים עם משתפי פעולה אחרים.
פתרון בעיות שקשורות לזמן האחזור ברשת או לאובדן נתונים שגורמים לבעיות ברוחב הפס
בדרך כלל, בעיות של השהיה או אובדן נתונים ברשת נגרמות ממיצוי משאבים או מנקודות צוואר בקבוק במכונה וירטואלית או בנתיב רשת. לפעמים, אובדן רשת יכול לגרום לפסק זמן לחיבור לסירוגין. גורמים כמו מיצוי של מעבדים וירטואליים או רוויה של כרטיסי רשת וירטואליים גורמים לעלייה בזמן האחזור ולאובדן מנות, וכתוצאה מכך לירידה בביצועי הרשת.
ההנחיות הבאות מבוססות על ההנחה שהחיבורים לא נסגרים באופן עקבי בגלל חוסר זמן תגובה, אלא שאתם נתקלים בבעיות של קיבולת או ביצועים מוגבלים. אם אתם רואים אובדן מנות מלא, כדאי לעיין במאמר בנושא פתרון בעיות של כשל מלא בחיבור.
תנודות קלות בזמן האחזור, כמו שינויים של כמה אלפיות שנייה, הן תופעה נורמלית. זמני האחזור משתנים בגלל עומס ברשת או תורים בתוך המכונה הווירטואלית.
קביעת ערכי החיבור
קודם אוספים את הפרטים הבאים:
- בדף VM instances, אוספים את הפרטים הבאים לגבי שתי המכונות הווירטואליות:
- שמות של מכונות וירטואליות
- אזורי VM
- כתובות IP פנימיות של כרטיסי ה-vNIC שמתקשרים
- מתוך ההגדרה של תוכנת שרת היעד, אוספים את הפרטים הבאים:
- פרוטוקול שכבה 4
- יציאת היעד
אם אתם רואים בעיות בכמה מכונות וירטואליות, בוחרים מכונה וירטואלית אחת כמקור ומכונה וירטואלית אחת כיעד שבהן יש בעיות, ומשתמשים בערכים האלה. בדרך כלל, לא צריך את יציאת המקור של החיבור.
אחרי שתאספו את המידע הזה, תוכלו להמשיך אל בדיקת בעיות ברשת Google הבסיסית.
בדיקת בעיות ברשת הבסיסית של Google
אם ההגדרה שלכם היא קיימת ולא השתנתה לאחרונה, יכול להיות שהבעיה היא ברשת Google הבסיסית. בודקים את לוח בקרה לביצועי הענן ב-Network Intelligence Center כדי לראות אם יש אובדן מנות בין אזורי המכונות הווירטואליות. אם יש עלייה באובדן המנות בין האזורים במהלך פרק הזמן שבו נתקלתם בפסק זמן ברשת, יכול להיות שהבעיה היא ברשת הפיזית שעליה מבוססת הרשת הווירטואלית שלכם. לפני ששולחים בקשת תמיכה, כדאי לבדוק את לוח הבקרה של סטטוס שירותי Google Cloud כדי לראות אם יש בעיות ידועות.
אם נראה שהבעיה לא קשורה לרשת הבסיסית של Google, עוברים אל בדיקת זמן האחזור של לחיצת היד.
בדיקת זמן האחזור של לחיצת היד
כל הפרוטוקולים שמבוססים על חיבור גורמים להשהיה מסוימת בזמן שהם מבצעים את לחיצת היד של הגדרת החיבור. כל לחיצת יד של פרוטוקול מוסיפה לתקורה. לדוגמה, בחיבורי SSL/TLS, לחיצת היד ב-TCP צריכה להסתיים לפני שלחיצת היד ב-SSL/TLS יכולה להתחיל, ואז לחיצת היד ב-TLS צריכה להסתיים לפני שניתן להעביר נתונים.
ההשהיה של לחיצת היד באותו אזור בדרך כלל זניחה, אבל לחיצות יד למיקומים מרוחקים בעולם עשויות להוסיף עיכובים גדולים יותר בהפעלת החיבור. Google Cloud אם יש לכם משאבים באזורים מרוחקים, תוכלו לבדוק אם זמן האחזור שאתם רואים נובע משימוש ב-protocol 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 (בדרך כלל).
- זמן נוסף של לחיצת יד = לחיצת יד של האפליקציה – לחיצת יד של TCP
Windows 2012 ו-2016
לא זמין עם כלי ברירת המחדל של מערכת ההפעלה. אפשר להשתמש בזמן הלוך ושוב של ICMP כהפניה אם הכללים בחומת האש מאפשרים זאת.
אם זמן האחזור ארוך יותר ממה שצפוי בגלל תהליך הלחיצת יד, צריך להמשיך אל קביעת התפוקה המקסימלית של סוג מכונת ה-VM.
קביעת התפוקה המקסימלית של סוג מכונת ה-VM
התפוקה של תעבורת נתונים יוצאת (egress) הרשת של המכונה הווירטואלית מוגבלת על ידי ארכיטקטורת מעבד (CPU) של המכונה הווירטואלית ומספר ה-vCPU. כדי לברר מה רוחב הפס הפוטנציאלי של תעבורת הנתונים היוצאת (egress) מהמכונה הווירטואלית, אפשר לעיין בדף רוחב פס ברשת.
אם המכונה הווירטואלית לא עומדת בדרישות תעבורת הנתונים היוצאת (egress), כדאי לשדרג למכונה וירטואלית עם קיבולת גדולה יותר. הוראות מפורטות זמינות במאמר שינוי סוג המכונה של מופע.
אם סוג המכונה אמור לאפשר רוחב פס מספיק ליציאה, כדאי לבדוק אם השימוש ב-Persistent Disk מפריע ליציאה מהרשת. לפעולות של Persistent Disk מותר לתפוס עד 60% מרוחב הפס הכולל של הרשת של המכונה הווירטואלית. כדי לבדוק אם פעולות של דיסק אחסון מתמיד (persistent disk) עלולות להפריע לתפוקת הרשת, אפשר לעיין במאמר בנושא בדיקת הביצועים של דיסק אחסון מתמיד.
תנועה נכנסת ברשת למכונה וירטואלית לא מוגבלת על ידי רשת ה-VPC או סוג המכונה הווירטואלית. במקום זאת, היא נקבעת לפי הביצועים של תור המנות ושל עיבוד המנות במערכת ההפעלה או באפליקציה של המכונה הווירטואלית. אם רוחב הפס של התעבורה היוצאת מספיק אבל יש בעיות בתעבורה הנכנסת, כדאי לעיין במאמר בדיקת רישום השרת ביומן כדי לקבל מידע על התנהגות השרת.
בדיקת 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 .
בוחרים את מסגרת הזמן שבה התרחשה ההשהיה.
כדי לקבוע אם אירוע של מכונה וירטואלית התרחש בסמוך לפרק הזמן שבו התרחשה ההשהיה, משתמשים בשאילתת הרישום הבאה:
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 כולל נתונים סטטיסטיים של הרשת, עם ערכים של מנות שהושלכו לפי פרוטוקול. יכול להיות שהמנות נפסלו בגלל שהאפליקציה או ממשק הרשת מיצו את המשאבים שלהם. הסיבה לשינוי הערך של המונה.
בודקים את kern.log כדי למצוא יומנים שתואמים ל-
nf_conntrack: table full, dropping packet.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 (זמן ההרשאות), יכולות להצביע על בעיות של עומס יתר, כי מכונת ה-VM מגיעה למגבלות של תפוקת ה-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, אבל בדרך כלל מתבצע שחזור של המנות שאבדו באמצעות אישור סלקטיבי ושידור חוזר של מנות, וכך נמנעת תפוגת הזמן הקצוב לתפוגה של החיבור. במקום זאת, יכול להיות שהזמן הקצוב לתפוגה נגרם בגלל כשל בשרת האפליקציות או בגלל פריסה מחדש שלו, מה שגרם לכשל זמני בחיבורים.
אם אפליקציית השרת שלכם מסתמכת על חיבור למסד נתונים או לשירות אחר, צריך לוודא שהשירותים המשולבים לא פועלים בצורה לא תקינה. יכול להיות שהאפליקציה שלכם תעקוב אחרי המדדים האלה.
אם הבעיות נמשכות
אם הבעיות נמשכות, אפשר לעבור אל קבלת תמיכה כדי לקבל מידע על השלבים הבאים. כדאי לשתף את הפלט של השלבים לפתרון בעיות עם משתפי פעולה אחרים.
המאמרים הבאים
- אם הבעיה נמשכת, אפשר לעיין בדף מקורות מידע.