סקירה כללית על בדיקות תקינות

‫Google Cloud Cloud Load Balancing מציע בדיקות תקינות שניתנות להגדרה עבור קצה עורפי של Google Cloud מאזן עומסים, קצה עורפי של Cloud Service Mesh ותיקון תוכנה אוטומטי (autohealing) מבוסס-אפליקציה לקבוצות של מכונות מנוהלות. במסמך הזה מוסברים מושגי מפתח בנושא בדיקות תקינות.

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

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

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

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

קטגוריות, פרוטוקולים ויציאות של בדיקות תקינות

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

• בדיקות תקינות

  • אזורי (gRPC,‏ gRPC (עם TLS),‏ TCP,‏ SSL,‏ HTTP,‏ HTTPS או HTTP/2)
  • גלובלי (gRPC,‏ gRPC (עם TLS),‏ TCP,‏ SSL,‏ HTTP,‏ HTTPS או HTTP/2)

• בדיקות תקינות מדור קודם:

  • גלובלי מדור קודם (HTTP)
  • גלובלי מדור קודם (HTTPS)

הפרוטוקול והיציאה קובעים איך מתבצעות בדיקות התקינות. לדוגמה, בדיקת תקינות יכולה להשתמש בפרוטוקול HTTP ביציאת TCP 80, או בפרוטוקול TCP ביציאה עם שם בקבוצת מופעים.

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

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

בחירת בדיקת תקינות

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

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

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

מדריך למאזן עומסים

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

מאזן עומסים	קטגוריה והיקף של בדיקת תקינות
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) מאזן עומסים קלאסי של אפליקציות ^* מאזן עומסי רשת גלובלי חיצוני בשרת proxy מאזן עומסי רשת קלאסי בשרת proxy מאזן עומסים פנימי של אפליקציות (ALB) בכמה אזורים מאזן עומסי רשת פנימי בשרת proxy בכמה אזורים	בדיקת תקינות (גלובלית)
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מאזן עומסים פנימי אזורי של אפליקציות (ALB) מאזן עומסי רשת אזורי פנימי בשרת proxy מאזן עומסי רשת אזורי חיצוני בשרת proxy	בדיקת תקינות (אזורית)
מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי	מאזן עומסים שמבוסס על שירות לקצה העורפי: בדיקת תקינות (אזורית) מאזן עומסים שמבוסס על מאגר יעדים: בדיקת תקינות מדור קודם (גלובלי עם פרוטוקול HTTP)
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי	בדיקת תקינות (גלובלית או אזורית)

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

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

הערות נוספות לגבי שימוש

• עבור קבוצות של שרתי עורף, NEGs אזוריים עם נקודות קצה מסוג GCE_VM_IP ו-NEGs אזוריים עם נקודות קצה מסוג GCE_VM_IP_PORT, בודקי הקישוריות מנסים להתחבר רק למכונות וירטואליות (או למכונות וירטואליות שמכילות נקודות קצה) אם המכונות הווירטואליות פועלות. הכלי Prober לא מנסה להתחבר למופעים (או למופעי VM שמכילים נקודות קצה) אם הם מושבתים.

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

• בשירותי קצה עורפי שמשתמשים בפרוטוקול gRPC, צריך להשתמש רק בבדיקות תקינות של gRPC או TCP. אל תשתמשו בבדיקות תקינות של HTTP(S) או HTTP/2.

• מאזני עומסים מסוימים שמבוססים על Envoy ומשתמשים בשרתי קצה עורפיים היברידיים של NEG לא תומכים בבדיקות תקינות של gRPC. מידע נוסף זמין במאמר בנושא סקירה כללית של קבוצות משולבות של נקודות קצה ברשת.

בדיקות תקינות באמצעות Cloud Service Mesh

חשוב לשים לב להבדלים הבאים בהתנהגות כשמשתמשים בבדיקות תקינות עם Cloud Service Mesh.

• ב-Cloud Service Mesh, אופן הפעולה של בדיקות תקינות של נקודות קצה ברשת מהסוגים INTERNET_FQDN_PORT ו-NON_GCP_PRIVATE_IP_PORT שונה מאופן הפעולה של בדיקות תקינות של סוגים אחרים של נקודות קצה ברשת. במקום להשתמש במשימות תוכנה ייעודיות, Cloud Service Mesh מתכנת את שרתי ה-proxy של Envoy כדי לבצע בדיקות תקינות עבור NEGs באינטרנט (נקודות קצה של INTERNET_FQDN_PORT) ו-NEGs היברידיים (נקודות קצה של NON_GCP_PRIVATE_IP_PORT).

  ‫Envoy תומך בפרוטוקולים הבאים לבדיקת תקינות:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

• כש-Cloud Service Mesh משולב עם Service Directory ואתם מקשרים שירות Service Directory לשירות קצה עורפי של Cloud Service Mesh, אתם לא יכולים להגדיר בדיקת תקינות בשירות הקצה העורפי.

טווחים של כתובות IP של בדיקות

Google Cloud מחייב אתכם ליצור את כללי חומת האש הנחוצים של allowתעבורת נתונים נכנסת (ingress) כדי לאפשר תעבורת נתונים מבודקי הקישוריות לשרתים העורפיים או למשאבים אחרים. כשיוצרים את הכללים האלה של חומת האש, חשוב לשים לב לנקודות הבאות:

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

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

אם אין לכם כללי חומת אש של תעבורת נתונים נכנסת (ingress) שמאפשרים לבוחני בדיקות תקינות להתחבר לשרתים העורפיים (backend) של מאזן העומסים, פעולת חומת האש של תעבורת נתונים נכנסת (ingress) שמוגדרת כברירת מחדל לחסימה תחסום את התעבורה, והשרתים העורפיים לא יהיו תקינים.allow מידע נוסף זמין במאמר מדיניות וכללים של חומת אש.

בדיקת טווחי כתובות IP לקצה העורפי של מאזן עומסים שמבוסס על GFE

מאזני עומסים חיצוניים של אפליקציות (ALB) ומאזני עומסי רשת חיצוניים לשרת proxy שמשתמשים ב-Google Front Ends‏ (GFE):

• מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB)
• מאזני עומסים קלאסיים של אפליקציות (ALB)
• מאזני עומסי רשת גלובליים חיצוניים לשרת proxy
• מאזני עומסי רשת קלאסיים בשרת proxy

בדיקות התקינות של השרתים העורפיים של מאזני העומסים האלה מגיעות מטווח כתובות ה-IP שבטבלה הבאה:

סוג הקצה העורפי	טווחי כתובות IP של מקור בדיקת התקינות
קבוצות של מכונות ‫NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה ‫NEGs של קישוריות היברידית (נקודות קצה של NON_GCP_PRIVATE_IP_PORT )	בדיקות תקינות של IPv4 לשרתי הקצה העורפיים: 35.191.0.0/16 לגבי בדיקות תקינות של IPv6 לשרתי קצה עורפיים: 2600:2d00:1:b029::/64
NEG גלובלי לאינטרנט (עם נקודות קצה מסוג INTERNET_IP_PORT או INTERNET_FQDN_PORT) ‫NEG ללא שרת (נקודת קצה SERVERLESS) ‫Private Service Connect NEG (נקודת קצה PRIVATE_SERVICE_CONNECT)	לא רלוונטי (הקצוות העורפיים האלה לא תומכים בבדיקות תקינות)

בדיקת טווחי כתובות IP עבור קצה עורפי של Cloud Service Mesh

בדיקות תקינות של קצה עורפי ב-Cloud Service Mesh מגיעות מטווחים של כתובות IP שמפורטים בטבלה הבאה:

סוג הקצה העורפי	טווחי כתובות IP של מקור בדיקת התקינות
קבוצות של מכונות ‫NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה	בדיקות תקינות של IPv4 לשרתי הקצה העורפיים: 35.191.0.0/16 לגבי בדיקות תקינות של IPv6 לשרתי קצה עורפיים: 2600:2d00:1:b029::/64
NEG גלובלי לאינטרנט (עם נקודות קצה מסוג INTERNET_IP_PORT או INTERNET_FQDN_PORT) ‫NEGs של קישוריות היברידית (נקודות קצה של NON_GCP_PRIVATE_IP_PORT )	בדיקות תקינות מבוזרות של Envoy מכתובות ה-IP של פרוקסי Envoy בניהול עצמי

טווחי כתובות IP של בדיקות תקינות לשרתי בק-אנד של מאזן עומסים מנוהל שמבוסס על Envoy

מאזני עומסים של אפליקציות (ALB) ומאזני עומסי רשת לשרת proxy שמשתמשים בשרתי proxy מנוהלים של Envoy:

• מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB)
• מאזני עומסים פנימיים אזוריים של אפליקציות (ALB)
• מאזני עומסים פנימיים של אפליקציות (ALB) חוצי-אזורים
• מאזני עומסי רשת אזוריים חיצוניים בשרת proxy
• מאזני עומסים פנימיים אזוריים בשרת proxy
• מאזני עומסים פנימיים בשרת proxy חוצה אזורים

בדיקות התקינות של השרתים העורפיים של מאזני העומסים האלה מגיעות מטווח כתובות ה-IP שבטבלה הבאה:

סוג הקצה העורפי	טווחי כתובות IP של מקור בדיקת התקינות
קבוצות של מכונות ‫NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה	בדיקות תקינות של IPv4 לשרתי הקצה העורפיים: 35.191.0.0/16 לגבי בדיקות תקינות של IPv6 לשרתי קצה עורפיים: 2600:2d00:1:b029::/64
‫NEGs של קישוריות היברידית (נקודות קצה של NON_GCP_PRIVATE_IP_PORT ) ‫NEG אזורי באינטרנט (עם נקודות קצה מסוג INTERNET_IP_PORT או INTERNET_FQDN_PORT)	בדיקות תקינות מבוזרות של Envoy מכתובות ה-IP של תת-הרשת של Proxy בלבד
‫NEG ללא שרת (נקודת קצה SERVERLESS) ‫Private Service Connect NEG (נקודת קצה PRIVATE_SERVICE_CONNECT)	לא רלוונטי (הקצוות העורפיים האלה לא תומכים בבדיקות תקינות)

בדיקת טווחי כתובות IP בחלק מהחזיתות של מאזני עומסים מנוהלים שמבוססים על Envoy

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

• מאזני עומסים פנימיים אזוריים של אפליקציות (ALB)

• מאזני עומסים פנימיים של אפליקציות (ALB) שפועלים בכמה אזורים

• מאזני עומסים פנימיים אזוריים בשרת proxy

• מאזני עומסים פנימיים לשרת proxy חוצי-אזורים

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

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

לכללי העברה של בדיקות תקינות ב-IPv4:

• 35.191.0.0/16

לכללי העברה של בדיקות תקינות של IPv6:

• 2600:2d00:1:b029::/64

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

טווח כתובות ה-IP של בדיקות תקינות לשרתי backend של מאזן עומסי רשת להעברת סיגנל ללא שינוי

בדיקות תקינות של קצה עורפי במאזני עומסי רשת להעברת סיגנל ללא שינוי מגיעות מטווח כתובות ה-IP שמופיע בטבלה הבאה:

מאזן עומסים וסוג קצה עורפי	טווחי כתובות IP של מקור בדיקת התקינות
מאזני עומסים אזוריים חיצוניים של רשת להעברת סיגנל ללא שינוי שמשתמשים באחד מסוגי הבק-אנד הבאים^1: קבוצות של מכונות ‫NEGs אזוריים עם GCE_VM_IP נקודות קצה	לגבי בדיקות תקינות של IPv4 לשרתי הקצה העורפיים: 35.191.0.0/16 ‫209.85.152.0/22 (למאגרי יעד) 209.85.204.0/22 לגבי בדיקות תקינות של IPv6 לשרתי קצה עורפיים: 2600:1901:8001::/48
מאזני עומסים פנימיים מסוג העברת סיגנל ללא שינוי שמשתמשים באחד מהקצוות העורפיים הבאים: קבוצות של מכונות ‫NEGs אזוריים עם GCE_VM_IP נקודות קצה	לגבי בדיקות תקינות של IPv4 לשרתי הקצה העורפיים: 35.191.0.0/16 לגבי בדיקות תקינות של IPv6 לשרתי קצה עורפיים: 2600:2d00:1:b029::/64

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

איך פועלות בדיקות התקינות

בקטעים הבאים מוסבר איך בדיקות תקינות פועלות.

Probes

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

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

דגל הגדרה	מטרה	ערך ברירת המחדל
מרווח הבדיקה check-interval	מרווח הבדיקה הוא משך הזמן שחל מתחילת בקשה לבדיקת תקינות (probe) אחת שמונפקת על ידי בודק אחד ועד לתחילת בקשה לבדיקת תקינות (probe) הבאה שמונפקת על ידי אותו בודק. היחידות הן שניות.	‫5s (5 שניות)
פסק זמן timeout	הזמן הקצוב לתפוגה הוא משך הזמן שבו Google Cloud ממתין לתגובה לבקשה לבדיקת תקינות (probe). הערך שלו חייב להיות קטן או שווה למרווח הבדיקה. היחידות הן שניות.	‫5s (5 שניות)

שיקולי אבטחה לגבי טווחי כתובות IP של בדיקות

כשמתכננים בדיקות תקינות ואת כללי חומת האש הנדרשים, חשוב לקחת בחשבון את המידע הבא:

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

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

  • נתבים של Google edge משמיטים מנות מהאינטרנט אם המנות מזייפות כתובות IP של מקור מטווח IP של בדיקה.

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

חשיבות הכללים של חומת האש

Google Cloud מחייב ליצור את כללי חומת האש הנחוצים של תעבורת נתונים נכנסת (ingress) allow כדי לאפשר תעבורת נתונים מהבודקים לשרתים העורפיים:

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

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

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

מספר בדיקות ותדירות

‫Google Cloud שולח בדיקות תקינות ממערכות מיותרות מרובות שנקראות בודקים. הבודקים משתמשים בטווחים ספציפיים של כתובות IP של מקור. ‫Google Cloud לא מסתמך רק על בודק אחד כדי לבצע בדיקת תקינות – כמה בודקים מעריכים בו-זמנית את המופעים בעורפי קבוצת המופעים או את נקודות הקצה בעורפי NEG אזוריים. אם בדיקה אחת נכשלת, Google Cloud ממשיך לעקוב אחרי מצבי תקינות של ה-Backend.

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

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

• כדי לאמוד את תדירות הבקשה לבדיקת תקינות (probe) לכל שירות לקצה העורפי, צריך לקחת בחשבון את הפרטים הבאים:

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

    ‫¹⁄_(interval)

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

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

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

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

• כמה שרתי proxy ליעד למאזני עומסים חיצוניים של אפליקציות (ALB). אם יש לכם כמה שרתי proxy ליעד שמפנים תנועה לאותה מפת כתובות URL,‏ Google Cloud משתמשים בכמה בודקים כדי לבדוק את כתובת ה-IP שמשויכת לכל שרת proxy ליעד. תדירות הבדיקה לכל שירות לקצה העורפי מוכפלת במספר שרתי proxy של היעד שהוגדרו.

• כמה שרתי proxy ליעד למאזני עומסי רשת חיצוניים לשרת proxy ולמאזני עומסי רשת פנימיים אזוריים לשרת proxy. אם הגדרתם כמה שרתי proxy ליעד שמפנים תנועה לאותו שירות לקצה העורפי,‏Google Cloud משתמש בכמה בודקים כדי לבדוק את כתובת ה-IP שמשויכת לכל שרת proxy ליעד. תדירות הבדיקה לכל שירות לקצה העורפי מוכפלת במספר שרתי ה-proxy שהוגדרו.

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

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

יעד לחבילות בדיקה

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

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

מאזן עומסים	ממשק רשת של יעד	כתובת ה-IP של היעד
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) מאזן עומסי רשת גלובלי חיצוני בשרת proxy	בממשקי קצה של קבוצות מופעים, ממשק הרשת הראשי (nic0). עבור קצה עורפי של NEG אזורי עם נקודות קצה של GCE_VM_IP_PORT, ממשק הרשת ברשת ה-VPC שמשויך ל-NEG. עבור קצוות עורפיים של NEG אזוריים עם NON_GCP_PRIVATE_IP_PORT נקודות קצה, נקודת הקצה צריכה לייצג ממשק של משאב מקומי שאפשר להגיע אליו באמצעות מסלול ברשת ה-VPC שמשויכת ל-NEG ובאזור שמכיל את ה-NEG.	עבור קצה עורפי של קבוצת מופעים, כתובת ה-IPv4 או ה-IPv6 הפנימית הראשית שמשויכת לממשק הרשת הראשי (nic0) של כל מופע. עבור קצוות עורפיים של NEG אזורי עם נקודות קצה מסוג GCE_VM_IP_PORT, כתובת ה-IP של נקודת הקצה: כתובת IPv4 או IPv6 פנימית ראשית של ממשק הרשת, או כתובת IPv4 או IPv6 פנימית מתוך טווח כתובות IP של כינוי של ממשק הרשת. עבור קצה עורפי של NEG אזורי עם נקודות קצה NON_GCP_PRIVATE_IP_PORT, כתובת ה-IP של נקודת הקצה.
מאזן עומסים קלאסי של אפליקציות (ALB) מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים מאזן עומסים פנימי אזורי של אפליקציות (ALB) מאזן עומסי רשת קלאסי בשרת proxy מאזן עומסי רשת אזורי חיצוני בשרת proxy מאזן עומסי רשת פנימי בשרת proxy בין אזורים ^1 מאזן עומסי רשת אזורי פנימי בשרת proxy Cloud Service Mesh	בממשקי קצה של קבוצות מופעים, ממשק הרשת הראשי (nic0). עבור קצה עורפי של NEG אזורי עם נקודות קצה של GCE_VM_IP_PORT, ממשק הרשת ברשת ה-VPC שמשויך ל-NEG. עבור קצוות עורפיים של NEG אזורי עם נקודות קצה NON_GCP_PRIVATE_IP_PORT, נקודת הקצה חייבת לייצג ממשק של משאב מקומי שאפשר להגיע אליו דרך נתיב ברשת ה-VPC שמשויכת ל-NEG ובאזור שמכיל את ה-NEG.	עבור קצה עורפי של קבוצת מופעים, כתובת ה-IPv4 הפנימית הראשית שמשויכת לממשק הרשת הראשי (nic0) של כל מופע. עבור קצוות עורפיים של NEG אזוריים עם נקודות קצה מסוג GCE_VM_IP_PORT, כתובת ה-IP של נקודת הקצה: כתובת IPv4 פנימית ראשית של ממשק הרשת או כתובת IPv4 פנימית מטווח כתובות IP של כינוי של ממשק הרשת. עבור קצה עורפי של NEG אזורי עם נקודות קצה NON_GCP_PRIVATE_IP_PORT, כתובת ה-IP של נקודת הקצה.
מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי	ממשק רשת ראשי (nic0)	כתובת ה-IP של כלל ההעברה החיצוני. אם כמה כללי העברה מצביעים על אותו שירות לקצה העורפי (במאזני עומסי רשת אזוריים חיצוניים להעברת סיגנל ללא שינוי שמבוססים על מאגרי יעד, אותו מאגר יעד), Google Cloud שולח בדיקות לכתובת ה-IP של כל כלל העברה. כתוצאה מכך, יכול להיות שמספר הבדיקות יגדל.
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי	גם עבור קצה עורפי של קבוצת מופעים וגם עבור קצה עורפי של NEG אזורי עם נקודות קצה GCE_VM_IP, ממשק הרשת שבו נעשה שימוש תלוי באופן שבו שירות הקצה העורפי מוגדר. לפרטים נוספים, אפשר לעיין במאמר בנושא שירותי קצה עורפי וממשקי רשת.	כתובת ה-IP של כלל ההעברה הפנימי. אם כמה כללי העברה מצביעים על אותו שירות לקצה העורפי, Google Cloud שולח בדיקות לכתובת ה-IP של כל כלל העברה. הדבר עלול להוביל לעלייה במספר הבדיקות.

קריטריונים להצלחה של HTTP,‏ HTTPS ו-HTTP/2

בדיקות תקינות של HTTP,‏ HTTPS ו-HTTP/2 תמיד דורשות קבלת קוד תגובה 200 (OK) של HTTP לפני שהזמן הקצוב לתפוגה של בדיקת התקינות מסתיים. כל קודי תגובת ה-HTTP האחרים, כולל קודי תגובה של הפניה כמו 301 ו-302, נחשבים כלא תקינים.

בנוסף לדרישה לקוד תגובה מסוג HTTP 200 (OK), אפשר:

• מגדירים כל כלי לבדיקת תקינות לשליחת בקשות HTTP לנתיב בקשה ספציפי במקום לנתיב הבקשה שמוגדר כברירת מחדל, /.

• מגדירים כל בודק תקינות כך שיבדוק אם מחרוזת תגובה צפויה מופיעה בגוף תגובת ה-HTTP. מחרוזת התגובה הצפויה צריכה להכיל רק תווים מסוג ASCII שניתנים להדפסה, באורך בייט אחד, והיא צריכה להיות ממוקמת ב-1,024 הבייטים הראשונים של גוף תגובת ה-HTTP.

בטבלה הבאה מפורטים שילובים תקינים של נתיב הבקשה וסימני התגובה שזמינים לבדיקות תקינות של HTTP,‏ HTTPS ו-HTTP/2.

דגלי הגדרה	התנהגות של כלי הבדיקה	קריטריונים להצלחה
לא צוין --request-path ולא --response	הכלי לבדיקת תקינות משתמש ב-/ כנתיב הבקשה.	קוד תגובה של HTTP 200 (OK) בלבד.
צוינו גם --request-path וגם --response	הכלי לבדיקת הקישוריות משתמש בנתיב הבקשה שהוגדר.	קוד התגובה של HTTP 200 (OK) ועד 1,024 התווים הראשונים של ASCII בגוף תגובת ה-HTTP צריכים להיות זהים למחרוזת התגובה הצפויה.
רק --response צוין	הכלי לבדיקת תקינות משתמש ב-/ כנתיב הבקשה.	קוד התגובה של HTTP 200 (OK) ועד 1,024 התווים הראשונים של ASCII בגוף תגובת ה-HTTP צריכים להיות זהים למחרוזת התגובה הצפויה.
רק --request-path צוין	הכלי לבדיקת הקישוריות משתמש בנתיב הבקשה שהוגדר.	קוד תגובה של HTTP 200 (OK) בלבד.

קריטריונים להצלחה של SSL ו-TCP

בדיקות התקינות של TCP ו-SSL כוללות את הקריטריונים הבסיסיים הבאים להצלחה:

• בבדיקות תקינות של TCP, בודק התקינות צריך לפתוח חיבור TCP לשרת העורפי לפני שפג הזמן הקצוב לתפוגה של בדיקת התקינות.

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

• בבדיקות תקינות של TCP, צריך לסגור את חיבור ה-TCP באחת מהדרכים הבאות:

  • על ידי בדיקת תקינות של בדיקה ששולחת מנת FIN או מנת RST (איפוס), או
  • הקצה העורפי שולח חבילת FIN. אם קצה עורפי שולח חבילת TCP RST, יכול להיות שהבדיקה תיחשב כלא מוצלחת אם כלי הבדיקה של בדיקת תקינות כבר שלח חבילת FIN.

בטבלה הבאה מפורטים שילובים תקינים של דגלי בקשה ותגובה שזמינים לבדיקות תקינות של TCP ו-SSL. הדגלים של הבקשה והתגובה חייבים להכיל רק תווים של ASCII שניתנים להדפסה וכל מחרוזת לא יכולה להיות ארוכה מ-1,024 תווים.

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

קריטריונים להצלחה של gRPC

בדיקות תקינות של gRPC משמשות רק עם אפליקציות gRPC, Google Cloud מאזני עומסים ו-Cloud Service Mesh. Google Cloud יש שני סוגים של בדיקות תקינות של gRPC:

• בדיקות התקינות של grpc_with_tlc משמשות לבדיקת התקינות של קצה עורפי של gRPC עם TLS מופעל. הם תומכים בהצפנת TLS לא מאומתת, כלומר בדיקות התקינות לא מאמתות את הזהות של השרת.
• grpc בדיקות תקינות משמשות לבדיקת תקינות של שרתי קצה עורפיים לא מאובטחים של gRPC. הם לא תומכים באימות ובהצפנה, ולכן אי אפשר להשתמש בהם בשרתי קצה של gRPC עם TLS מופעל.

אם אתם משתמשים בבדיקות תקינות של gRPC (עם או בלי TLS), אתם צריכים לוודא ששירות gRPC שולח את תגובת ה-RPC עם הסטטוס OK וששדה הסטטוס מוגדר ל-SERVING או ל-NOT_SERVING בהתאם.

למידע נוסף, קראו את המאמרים הבאים:

• דגל נוסף לבדיקות תקינות של gRPC
• מאמרי עזרה בנושא בדיקות תקינות ב-gRPC

קריטריונים להצלחה של בדיקות תקינות מדור קודם

אם התגובה שמתקבלת מהבקשה לבדיקת תקינות (probe) מדור קודם היא HTTP 200 OK, הבקשה לבדיקת תקינות (probe) נחשבת מוצלחת. כל קודי תגובת ה-HTTP האחרים, כולל הפניה אוטומטית (301, 302), נחשבים כלא תקינים.

מצב תקינות

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

דגל הגדרה	מטרה	ערך ברירת המחדל
סף בריא healthy-threshold	סף תקינות המערכת מציין את מספר התוצאות הרצופות של בדיקות תקינות שהתקבלו בהצלחה עבור קצה עורפי שהיה לא תקין^1 כדי שייחשב כתקין. קצוות עורפיים לא תקינים יכולים לחזור להיות תקינים אם הם עומדים שוב בסף התקינות. ‫Google Cloud מחשיב קצוות עורפיים כקצוות עורפיים תקינים אחרי שהושג הסף הזה. שרתי קצה תקינים יכולים לקבל חיבורים חדשים. יכול להיות שמערכות עורפיות שנוספו לאחרונה ייחשבו תקינות אחרי בדיקה מוצלחת אחת.	סף של 2 בדיקות.
סף לא בריא unhealthy-threshold	סף הבעיה מציין את מספר התוצאות הרצופות של בדיקות הקישוריות שנכשלו, שבעקבותיהן עורף בריא בעבר^2 ייחשב כעורף בעייתי. ‫Google Cloud consider backends to be unhealthy when the unhealthy threshold has been met. שרתי קצה עורפיים לא תקינים לא יכולים לקבל חיבורים חדשים, אבל חיבורים קיימים לא מסתיימים באופן מיידי. במקום זאת, החיבור נשאר פתוח עד שמתרחש זמן קצוב לתפוגה או עד שתעבורת הנתונים נפסקת.	סף של 2 בדיקות.

‫¹ Previously unhealthy backend מתייחס לקצוות עורפיים שהיו במצבי בדיקת תקינות מפורטים UNHEALTHY או TIMEOUT.

‫² קצה עורפי תקין בעבר מתייחס לקצוות עורפיים שהיו במצבי בדיקת תקינות מפורטת HEALTHY או DRAINING.

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

מאזן עומסים	התנהגות כשכל השרתים העורפיים לא תקינים
מאזן עומסים קלאסי של אפליקציות (ALB)	מחזירה ללקוחות קוד סטטוס HTTP ‏ `502` כשכל השרתים העורפיים לא תקינים.
‫ מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) מאזן עומסים פנימי של אפליקציות (ALB) בין אזורים מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מאזן עומסים פנימי אזורי של אפליקציות (ALB)	מחזיר קוד מצב HTTP ‏ `503` ללקוחות כשכל השרתים העורפיים לא תקינים.
מאזני עומסים של רשת בשרת proxy	מפסיק חיבורי TCP חדשים של לקוחות כשכל השרתים העורפיים לא תקינים.
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי מאזני עומסי רשת אזוריים חיצוניים להעברת סיגנל ללא שינוי שמבוססים על שירות לקצה העורפי	מפיץ חיבורים חדשים בהתאם להגדרת יתירות כשל, המשקל של הבק-אנד והסטטוס של הבק-אנד. פרטים נוספים זמינים במאמרים בנושאים הבאים: חלוקת התנועה במאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי חלוקת התנועה במאזני עומסים אזוריים חיצוניים להעברת סיגנל ללא שינוי שמבוססים על שירותים לקצה העורפי
מאזני עומסים אזוריים חיצוניים של רשת להעברת סיגנל ללא שינוי שמבוססים על מאגר יעד	מבזר את תעבורת הנתונים בין כל מכונות ה-VM של הקצה העורפי כמוצא אחרון כשכל הקצוות העורפיים לא תקינים.

הערות נוספות

בקטעים הבאים מופיעות הערות נוספות לגבי השימוש בבדיקות תקינות ב- Google Cloud.

אישורים ובדיקות תקינות

Google Cloud הבודקים של בדיקות תקינות לא מבצעים אימות של אישורים, גם לא עבור פרוטוקולים שדורשים שהשרתים העורפיים ישתמשו באישורים (SSL,‏ HTTPS ו-HTTP/2) – לדוגמה:

• אפשר להשתמש באישור בחתימה עצמית או באישור שחתום על ידי רשות אישורים (CA).
• אפשר להשתמש באישורים שתוקפם פג או שעדיין לא נכנסו לתוקף.
• המאפיינים CN ו-subjectAlternativeName לא צריכים להתאים לכותרת Host או לרשומת PTR של DNS.

כותרות

בבדיקות תקינות שמשתמשות בפרוטוקול כלשהו, אבל לא בבדיקות תקינות מדור קודם, אפשר להגדיר כותרת proxy באמצעות הדגל --proxy-header.

בבדיקות תקינות שמשתמשות בפרוטוקולים HTTP,‏ HTTPS או HTTP/2, ובבדיקות תקינות מדור קודם, אפשר לציין כותרת HTTP Host באמצעות הדגל --host.

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

דוגמה לבדיקת תקינות

נניח שהגדרתם בדיקת תקינות עם ההגדרות הבאות:

• מרווח: 30 שניות
• זמן קצוב לתפוגה: 5 שניות
• פרוטוקול: HTTP
• סף לא תקין: 2 (ברירת מחדל)
• סף בריא: 2 (ברירת מחדל)

ההגדרות האלה גורמות לבדיקת התקינות להתנהג באופן הבא:

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

2. כל בודק תקינות מבצע את הפעולות הבאות:

   1. יוזם חיבור HTTP מאחד מכתובות ה-IP של המקור לשרת העורפי כל 30 שניות.
   2. ההמתנה היא עד חמש שניות לקוד סטטוס HTTP 200 (OK) (קריטריון ההצלחה לפרוטוקולים HTTP,‏ HTTPS ו-HTTP/2).

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

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

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

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

בדוגמה הזו, התזמון של כל בודק נראה כך, בשניות:

1. ‫t=0: התחלת בדיקה A.
2. ‫t=5: עצירת בדיקה A.
3. ‫t=30: התחלת בדיקה B.
4. ‫t=35: הפסקת בדיקה B.
5. ‫t=60: מתחילים את בדיקת C.
6. ‫t=65: עצירת בדיקה C.

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

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