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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סוג הקצה העורפי	טווח כתובות ה-IP של המקור של בדיקת התקינות
קבוצות של מכונות ‫NEGs אזוריים עם GCE_VM_IP_PORT נקודות קצה	לגבי בדיקות תקינות של IPv4 לשרתי הקצה העורפיים: 177.222.80.0/23 לגבי בדיקות תקינות של IPv6 לשרתי הקצה העורפיים: 2a13:7500:8301:b029:0:2b::/96
‫NEGs של קישוריות היברידית (נקודות קצה של NON_GCP_PRIVATE_IP_PORT ) קבוצת נקודות קצה ברשת באינטרנט אזורית (עם נקודות קצה מסוג INTERNET_IP_PORT או INTERNET_FQDN_PORT)	בדיקות תקינות מבוזרות של Envoy מכתובות ה-IP של תת-הרשת של Proxy בלבד
‫NEG ללא שרת (נקודת קצה SERVERLESS) ‫Private Service Connect NEG (נקודת קצה PRIVATE_SERVICE_CONNECT)	לא רלוונטי (הקצוות העורפיים האלה לא תומכים בבדיקות תקינות)

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

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

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

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

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

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

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

• 177.222.80.0/23

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

• 2a13:7500:8301:b029:0:2b::/96

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

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

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

מאזן עומסים וסוג קצה עורפי	טווח כתובות ה-IP של המקור של בדיקת התקינות
מאזני עומסים גלובליים חיצוניים של רשת להעברת סיגנל ללא שינוי שמשתמשים באחד מהקצוות העורפיים הבאים: קבוצות של מכונות ‫NEGs אזוריים עם GCE_VM_IP נקודות קצה	לגבי בדיקות תקינות של IPv4 לשרתי הקצה העורפיים: 136.124.104.0/22 136.124.108.0/22 לגבי בדיקות תקינות של IPv6 לשרתי הקצה העורפיים: 2600:1904:7::/48 2600:1904:8::/48
מאזני עומסים אזוריים חיצוניים של רשת להעברת סיגנל ללא שינוי שמשתמשים באחד מסוגי הבק-אנד הבאים1: קבוצות של מכונות ‫NEGs אזוריים עם GCE_VM_IP נקודות קצה	לגבי בדיקות תקינות של IPv4 לשרתי הקצה העורפיים: 177.222.87.64/26 ‫177.222.87.0/26 (למאגרי יעד) לגבי בדיקות תקינות של IPv6 לשרתי הקצה העורפיים: 2a13:7500:241:30::/64
מאזני עומסים פנימיים מסוג העברת סיגנל ללא שינוי שמשתמשים באחד מהקצוות העורפיים הבאים: קבוצות של מכונות ‫NEGs אזוריים עם GCE_VM_IP נקודות קצה	לגבי בדיקות תקינות של IPv4 לשרתי הקצה העורפיים: 177.222.80.0/23 לגבי בדיקות תקינות של IPv6 לשרתי הקצה העורפיים: 2a13:7500:8301:b029:0:2b::/96

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

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

Probes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    ‫¹⁄_{(מרווח הבדיקה)}

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

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

• כללי העברה מרובים למאזנים של עומסי רשת להעברת סיגנל ללא שינוי. אם הגדרתם כמה כללי העברה (עם כתובות IP שונות) שיש להם את אותה קבוצת מופעים או את אותו NEG אזורי כבק-אנד,מערכת Cloud de Confiance משתמשת בכמה בודקים כדי לבדוק את תקינות כל כתובת IP בבק-אנד. תדירות הבדיקה בכל שרת עורפי (backend instance) או נקודת קצה של קצה עורפי מוכפלת במספר כתובות ה-IP הייחודיות של כלל ההעברה שהיא משרתת. לדוגמה:

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

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

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

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

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

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

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

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

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

מאזן עומסים	ממשק רשת של יעד	כתובת ה-IP של היעד
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מאזן עומסים פנימי אזורי של אפליקציות (ALB) מאזן עומסי רשת אזורי חיצוני בשרת proxy מאזן עומסי רשת אזורי פנימי בשרת proxy	בבק-אנד של קבוצת מופעים, ממשק הרשת הראשי (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). עבור קצוות עורפיים של NEG אזורי עם נקודות קצה של GCE_VM_IP, ממשק הרשת בתת-הרשת של ה-VPC שמשויכת ל-NEG.	כתובות ה-IP שמשויכות לכלל ההעברה. אם מגדירים כמה כללי העברה (עם כתובות IP שונות) שיש להם את אותה קבוצת מופעים או את אותו NEG אזורי כקצה עורפי, Cloud de Confiance משתמש בכמה בודקים כדי לבדוק את תקינות כל כתובת IP, וכך מגדיל את תדירות הבדיקה בכל שרת עורפי (backend instance) או בכל נקודת קצה של קצה עורפי. פרטים נוספים זמינים במאמר בדיקות מרובות ותדירות.
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי	ממשק הרשת ברשת ה-VPC שתואם ל מפרט הרשת של שירות הקצה העורפי.	כתובת ה-IP שמשויכת לכלל ההעברה. אם מגדירים כמה כללי העברה (עם כתובות IP שונות) שיש להם את אותה קבוצת מופעים או את אותו NEG אזורי כקצה עורפי, Cloud de Confiance משתמש בכמה בודקים כדי לבדוק את תקינות כל כתובת IP, וכך מגדיל את תדירות הבדיקה בכל שרת עורפי (backend instance) או בכל נקודת קצה של קצה עורפי. פרטים נוספים זמינים במאמר בדיקות מרובות ותדירות.

קריטריונים להצלחה של 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, Cloud de Confiance מאזני עומסים ו-Cloud Service Mesh. Cloud de Confiance יש שני סוגים של בדיקות תקינות של gRPC:

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

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

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

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

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

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

מצב תקינות

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

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

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

הערות נוספות

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

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

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

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

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

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