פתרון בעיות בבדיקות קישוריות

ההנחיות הבאות יעזרו לכם לפתור בעיות נפוצות בבדיקות הקישוריות.

מידע נוסף על בדיקות קישוריות זמין במאמר סקירה כללית.

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

בעיות כלליות

הזמן לקבלת תוצאות הבדיקה ארוך מדי

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

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

ניתוח ההגדרה של הבדיקה שלי לא מזהה את שינוי ההגדרה שביצעתי

אחרי שמבצעים שינוי בהגדרות של משאבי Google Cloud נתיב הבדיקה, כדאי להשתמש בניתוח ההגדרות של הבדיקה כדי לאמת את השינוי. עם זאת, לוקח בין 20 ל-120 שניות עד שבדיקות קישוריות מקבלות עדכון של ההגדרות ומשלבות אותו בניתוח. למשאבי Google Kubernetes Engine‏ (GKE), התהליך הזה יכול להימשך עד 15 דקות. חשוב להמתין את הזמן הנוסף הזה לפני שמריצים את הבדיקות.

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

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

בעיות במצב הבדיקה

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

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

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

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

הבדיקה שלי מראה שסטטוס ניתוח ההגדרה הסופי הוא Deliver, אבל הקישוריות לא תקינה

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

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

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

  • במכונה הווירטואלית של המקור או היעד יש בעיות במערכת ההפעלה של האורח, כמו תגובה לשגיאת ליבה קריטית של מערכת ההפעלה של האורח, בקר ממשק רשת (NIC) שלא אותחל או מנהלי התקנים לא תואמים של הרשת. בודקים את מצב ה-VM ואת ההגדרות של כרטיס הרשת.
  • בעיה נרחבת משפיעה על מישור הנתונים ברשת. כדאי לעיין בלוח הבקרה לביצועי הענן של הפרויקט, ולשים לב במיוחד לאובדן מנות עבור זוג התחומים הרלוונטי. בנוסף, כדאי לבדוק את Google Cloud לוח הבקרה של הסטטוס.
  • ברשת שלכם יש בעיות ספורדיות בתכנות הרשת, כמו בעיות בהפצה של הגדרות הרשת לישויות ספציפיות של Google Cloud. כדאי להריץ מחדש את הבדיקה אחרי עיכוב של חמש דקות. אם הבעיה נמשכת, צריך לעצור ולהפעיל את מכונת ה-VM של המקור או היעד, כמו שמתואר במאמר עצירה והפעלה של מופע, ואז להריץ מחדש את הבדיקה.

התוצאה הכוללת של ניתוח ההגדרות שקיבלתי מהבדיקה היא Undetermined

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

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

התוצאה הכוללת של ניתוח ההגדרות שקיבלתי מהבדיקה היא Ambiguous

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

בטבלה הבאה מפורטות כמה סיבות נפוצות למצב הזה ופתרונות אפשריים.

סיבה דוגמה איך לפתור את הבעיה
מיקום המקור לא ייחודי. ציינתם כתובת IP פנימית של מקור בלי לציין גם את רשת ה-VPC שבה כתובת ה-IP ממוקמת (כתובת IP פנימית של מקור היא כתובת שאי אפשר לגשת אליה מהאינטרנט). מכיוון שאפשר לגשת לכתובת הזו מכמה רשתות VPC, בדיקות הקישוריות יכולות להתחיל מעקב מכל מיקום. מעדכנים את הבדיקה עם רשת ה-VPC שבה נמצאת כתובת ה-IP הזו.
יש כמה יעדים אפשריים למעקב. יעד ה-Trace הוא מאזן עומסים עם כמה קצה עורפי או קצה עורפי עם מדיניות לבחירת כתובת IP מסוג PREFER_IPV6, ולא לכל הקצה העורפי יש יכולת הגעה לכל גרסאות ה-IP שהוגדרו. צריך לבדוק למה זה קורה ולתקן את הבעיות לפי הצורך לפני שמריצים את הבדיקה מחדש.

בבדיקה שלי התקבלה תוצאת ניתוח כללית של ההגדרה Abort עם ההודעה Invalid Argument

אלה כמה סיבות נפוצות להודעה Invalid Argument:

  • כתובת ה-IP שסיפקת לא נתמכת. לדוגמה, כתובת לולאה חוזרת, כתובת IP של שידור מרובה או כתובת IPv6 למכונה וירטואלית שהוקצתה לה רק כתובת IPv4.
  • מופע המכונה הווירטואלית או הרשת שצוינו לא קיימים. המצב הזה יכול לקרות אם מוחקים את מופע ה-VM או את רשת ה-VPC בזמן שיוצרים את הבדיקה.

כשמשתמשים ב-Network Management API, ההודעה Invalid Argument מוחזרת בדרך כלל בגלל אחת מהסיבות הבאות:

  • שם עם שגיאת איות או מיקום שגוי של המכונה הווירטואלית או של ה-URI של הרשת.
  • מזהה פרויקט שצוין בצורה שגויה. הטעות הזו מתרחשת אם השתמשתם בשם הפרויקט במקום במזהה הפרויקט.
  • חוסר התאמה בין כתובת ה-IP הפנימית שצוינה לבין הרשת שנבחרה. למרות שבמסוף של בדיקות הקישוריות מתבצע אימות קפדני של מופע Compute Engine, רשת ופרויקט שצוינו, עדיין יכול להיות חוסר התאמה מהסוג הזה. Google Cloud

תוצאת ניתוח ההגדרה היא Packet could not be delivered, אבל ניתוח של מישור הנתונים בזמן אמת מצביע על כך שכל החבילות נמסרו

יכולות להיות כמה סיבות לכך שאין התאמה בין הנתונים. אלה הסיבות האפשריות והפתרונות:

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

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

תוצאת ניתוח ההגדרה היא Packet could be delivered, אבל ניתוח של מישור הנתונים בזמן אמת מצביע על אובדן חלקי של מנות

יכולות להיות כמה סיבות לכך שאין התאמה בין הנתונים. סיבות אפשריות ופתרונות:

  • הגבלת קצב העברת הנתונים (throttling) מופעלת במכונה הווירטואלית של המקור או היעד, כי רוחב הפס של התנועה היוצאת או הנכנסת חורג מהמותר. כדי לנתח את נפח התנועה של המכונה הווירטואלית, עוברים לדף VM instance details ובודקים את הפרטים בכרטיסייה Monitoring. בודקים את המדד Network Bytes ומשווים אותו למגבלות רוחב הפס שמתוארות עבור סוג המכונה בקטע Network bandwidth.

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

תוצאת ניתוח ההגדרה היא Packet could be delivered וניתוח מישור הנתונים בזמן אמת מראה מסירה מלאה, אבל יש אובדן באפליקציה שלי

יכולות להיות כמה סיבות לכך שאין התאמה בין הנתונים. סיבות אפשריות ופתרונות:

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

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

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

‫Network Management API החזיר INTERNAL_ERROR

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

סיבות ספציפיות לביטול

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

אין טווחי IP בלי שרת (serverless)

הבדיקה בוטלה כי לא הוקצו כתובות יציאה ישירות מ-VPC לגרסה שלא מקבלת תנועה.

סיבה אפשרית

כתובות ה-IP שמוקצות לגרסאות של Cloud Run באמצעות יציאה ישירה מ-VPC הן זמניות. הכתובות האלה מוקצות רק כשהגרסה שלכם מציגה תנועה באופן פעיל. אם הבעיה הזו מתרחשת, סביר להניח שלא נשלח תנועה פעילה לגרסה של Cloud Run.

מידע נוסף על משך השמירה של כתובות IP זמין במאמר צריכת כתובות IP בשירותים ובמאגרי עובדים.

המלצות

  1. בודקים את כתובות ה-IP שהוקצו לגרסה שלכם, כמו שמתואר במאמר בנושא הצגת כתובות IP שהוקצו.
  2. מוודאים שטווח כתובות ה-IP נמצא בשימוש על ידי Serverless ומשויך לרשת המשנה שהוגדרה לגרסה של Cloud Run. אם לא קיים טווח כתובות IP כזה, שולחים תנועה לגרסה של Cloud Run כדי להפעיל את ההקצאה.

Google Cloud בעיות במסוף

המסוף של בדיקות הקישוריות קרס Google Cloud

בדרך כלל, המסוף Google Cloud לא אמור לקרוס. אם כן, צריך לדווח על הבעיה לתמיכה ולתאר איך לשחזר אותה.

המאמרים הבאים