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

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

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

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

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

בדיקות תקינות שמיושמות על ידי משימות תוכנה ייעודיות משתמשות בנתיבים מיוחדים שלא מוגדרים ברשת הענן הווירטואלי הפרטי (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. למידע נוסף על דרישות היציאה של בדיקות התקינות לכל מאזן עומסים, ראו דגלים של הגדרת יציאה.

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

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

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

מאזן עומסים	קטגוריה והיקף של בדיקת תקינות
‫Global external Application Load Balancer ‫Classic Application Load Balancer ‫^* ‫Global external proxy מאזן עומסי רשת ‫Classic proxy מאזן עומסי רשת ‫Cross-region internal Application Load Balancer ‫Cross-region internal proxy מאזן עומסי רשת	בדיקת תקינות (גלובלית)
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מאזן עומסים פנימי אזורי של אפליקציות (ALB) מאזן עומסי רשת אזורי פנימי בשרת proxy מאזן עומסי רשת אזורי חיצוני בשרת proxy	בדיקת תקינות (אזורית)
מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי	מאזן עומסים שמבוסס על שירות לקצה העורפי: בדיקת תקינות (אזורית) מאזן עומסים שמבוסס על מאגר יעדים: בדיקת תקינות מדור קודם (גלובלי עם פרוטוקול HTTP)
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי	בדיקת תקינות (גלובלית או אזורית)

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

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

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

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

• מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי שמבוסס על מאגר יעדים חייב להשתמש בבדיקת תקינות HTTP מדור קודם. אי אפשר להשתמש בבדיקת תקינות של HTTPS מדור קודם או בכל בדיקת תקינות שאינה מדור קודם. אם אתם משתמשים במאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי שמבוסס על מאגר כתובות יעד כדי לאזן תעבורת 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, אי אפשר להגדיר בדיקת תקינות בשירות הקצה העורפי.

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

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

Probes

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

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

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

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

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

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

מוצר	טווחי כתובות IP של מקור בדיקת התקינות
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) מאזן עומסי רשת גלובלי חיצוני בשרת proxy	35.191.0.0/16 130.211.0.0/22 לתנועת IPv6 אל השרתים העורפיים: 2600:2d00:1:b029::/64 2600:2d00:1:1::/64
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) ^1, 2 מאזן עומסים פנימי של אפליקציות (ALB) בין אזורים ^1 מאזן עומסים פנימי אזורי של אפליקציות (ALB) ^1, 2 מאזן עומסי רשת אזורי חיצוני בשרת proxy^1, 2 מאזן עומסי רשת אזורי פנימי בשרת proxy^1, 2 מאזן עומסי רשת פנימי בשרת proxy בין אזורים ^1	35.191.0.0/16 130.211.0.0/22 לתנועת IPv6 אל השרתים העורפיים: 2600:2d00:1:b029::/64
מאזן עומסי רשת קלאסי בשרת proxy מאזן עומסים קלאסי של אפליקציות (ALB) ‫Cloud Service Mesh, למעט קצה עורפי של NEG לאינטרנט וקצה עורפי של NEG היברידי	35.191.0.0/16 130.211.0.0/22
מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי ^3	לתנועת IPv4 לשרתי הקצה העורפיים: 35.191.0.0/16 209.85.152.0/22 209.85.204.0/22 לתנועת IPv6 אל השרתים העורפיים: 2600:1901:8001::/48
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי	לתנועת IPv4 לשרתי הקצה העורפיים: 35.191.0.0/16 130.211.0.0/22 לתנועת IPv6 אל השרתים העורפיים: 2600:2d00:1:b029::/64
Cloud Service Mesh עם עורפי NEG באינטרנט ועורפי NEG היברידיים	כתובות ה-IP של המכונות הווירטואליות שבהן פועלת תוכנת Envoy דוגמה להגדרה מופיעה במאמר בנושא Cloud Service Mesh.

^‫1 אין צורך לאפשר תנועה מטווחים של בדיקות תקינות של Google עבור קבוצות מעורבות של נקודות קצה ברשת (NEGs). עם זאת, אם אתם משתמשים בשילוב של NEGs היברידיים ואזוריים בשירות לקצה העורפי יחיד, אתם צריכים לאפשר תנועה מטווחים של בדיקות תקינות של Google עבור ה-NEGs האזוריים.

‫² ב-NEGs אזוריים של אינטרנט, בדיקות התקינות הן אופציונליות. תעבורת נתונים ממאזני עומסים שמשתמשים ב-NEGs של אינטרנט אזורי מגיעה מרשת המשנה של שרת ה-proxy בלבד, ואז מתבצעת תרגום NAT (באמצעות Cloud NAT) לכתובות IP של NAT שהוקצו באופן ידני או אוטומטי. התנועה הזו כוללת גם בדיקות תקינות וגם בקשות של משתמשים ממאזן העומסים אל השרתים העורפיים. פרטים נוספים זמינים במאמר בנושא קבוצות אזוריות של נקודות קצה ברשת: שימוש בשער Cloud NAT.

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

שיקולי אבטחה לגבי טווחי כתובות 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 יכולה להטמיע בודקים חדשים באופן אוטומטי בלי לשלוח התראה.

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

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

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

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

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

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

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

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

    ‫¹⁄_(interval)

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

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

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

• כללי העברה מרובים למאזנים חיצוניים של עומסי רשת להעברת סיגנל ללא שינוי. אם הגדרתם כמה כללי העברה שמפנים לאותו שירות קצה עורפי או לאותו מאגר יעדים,מערכת 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 אזוריות. לא בהכרח יש לאזורי ה-NEG האלה את אותה קבוצה של נקודות קצה, ונקודות קצה שונות יכולות להצביע על אותו קצה עורפי.

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

בטבלה הבאה מוצגים ממשק הרשת וכתובות ה-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 של כלל ההעברה החיצוני. אם כמה כללי העברה מצביעים על אותו שירות לקצה העורפי (עבור מאזני עומסים חיצוניים מסוג Network Load Balancer עם העברת נתונים שקופה שמבוססת על מאגר כתובות יעד, אותו מאגר כתובות יעד), Google Cloud שולח בדיקות לכתובת ה-IP של כל כלל העברה. הדבר עלול להוביל לעלייה במספר הבדיקות.
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי	גם עבור קצה עורפי של קבוצת מופעים וגם עבור קצה עורפי של NEG אזורי עם נקודות קצה של GCE_VM_IP, ממשק הרשת שבו נעשה שימוש תלוי באופן שבו שירות הקצה העורפי מוגדר. לפרטים נוספים, אפשר לעיין במאמר בנושא שירותי קצה עורפי וממשקי רשת.	כתובת ה-IP של כלל ההעברה הפנימי. אם כמה כללי העברה מצביעים על אותו שירות קצה עורפי, Google Cloud מערכת Google שולחת בדיקות לכתובת ה-IP של כל כלל העברה. הדבר עלול להוביל לעלייה במספר הבדיקות.

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

בבדיקות תקינות של HTTP,‏ HTTPS ו-HTTP/2 תמיד נדרש קוד תגובה של HTTP 200 (OK) לפני שהזמן הקצוב לתפוגה של בדיקת התקינות מסתיים. כל תגובות ה-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_TLS משמשות לבדיקת תקינות של קצה עורפי של 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	סף הבעיה מציין את מספר התוצאות הרצופות של בקשות לבדיקת תקינות (probe) שנכשלו עבור קצה עורפי שהיה תקין בעבר^2, כדי שהקצה העורפי ייחשב כבעייתי. ‫Google Cloud מחשיב קצוות עורפיים כלא תקינים כשמגיעים לסף של קצוות עורפיים לא תקינים. שרתי קצה עורפיים לא תקינים לא יכולים לקבל חיבורים חדשים, אבל חיבורים קיימים לא מסתיימים באופן מיידי. במקום זאת, החיבור נשאר פתוח עד שמתרחש זמן קצוב לתפוגה או עד שהתנועה נפסקת.	סף של 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.

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

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

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

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

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

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

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

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

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

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

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

בדוגמה הזו, כל בודק יוזם חיבור כל 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.

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

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