‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

שימוש בבדיקות תקינות

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

בדף הזה אנחנו מניחים שאתם מכירים את המושגים הבאים:

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

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

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

המסוף

נכנסים לדף Health checks במסוף Google Cloud .
לדף Health checks
לוחצים על יצירת בדיקת תקינות.
בדף Create a health check, מספקים את הפרטים הבאים:
- Name: נותנים שם לבדיקת התקינות.
- תיאור: אפשר להוסיף תיאור.
- היקף: בוחרים היקף, גלובלי או אזורי, בהתאם לסוג מאזן העומסים.
  - אם בחרתם באפשרות אזורי, בוחרים אזור מהתפריט הנפתח.
- פרוטוקול: בוחרים פרוטוקול לבדיקת תקינות.
- יציאה: מציינים מספר יציאה. כשיוצרים בדיקת תקינות במסוף Google Cloud , צריך לציין את היציאה באמצעות מספר יציאה.
- פרוטוקול Proxy: אפשר להוסיף כותרת Proxy לבקשות שמוגשות על ידי מערכות בדיקת התקינות.
- נתיב הבקשה והתגובה: בפרוטוקולים HTTP, ‏ HTTPS ו-HTTP2, אפשר לספק נתיב של כתובת URL לבדיקת תקינות, כדי שמערכות הבדיקה יוכלו ליצור קשר. מידע נוסף זמין במאמר בנושא דגלים נוספים לבדיקות תקינות של HTTP,‏ HTTPS ו-HTTP/2.
- בקשה ותגובה: בפרוטוקולים TCP ו-SSL, אפשר לציין מחרוזת טקסט ASCII לשליחה ומחרוזת טקסט של תגובה צפויה. מידע נוסף זמין במאמר דגלים נוספים לבדיקות תקינות של SSL ו-TCP.
- מרווח הבדיקה: הגדרת משך הזמן שחלף מתחילת בדיקה אחת עד תחילת הבדיקה הבאה.
- זמן קצוב לתפוגה: הגדרת משך הזמן שבו Google Cloud המערכת ממתינה לתגובה לבקשה לבדיקת תקינות (probe). הערך שלו צריך להיות קטן או שווה למרווח הבדיקה.
- סף תקינות: מגדירים את מספר הבדיקות הרצופות שצריכות להצליח כדי שהמכונה הווירטואלית תיחשב תקינה.
- סף לא תקין: מגדירים את מספר הבדיקות הרצופות שצריכות להיכשל כדי שהמכונה הווירטואלית תיחשב לא תקינה.
לוחצים על יצירה.

gcloud

כדי ליצור בדיקת תקינות גלובלית, משתמשים בפקודה המתאימה compute health-checks create:

gcloud compute health-checks create PROTOCOL NAME \
    --global \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

כדי ליצור בדיקת תקינות אזורית, משתמשים בפקודה המתאימה compute health-checks create:

gcloud compute health-checks create PROTOCOL NAME \
    --region=REGION \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

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

‫PROTOCOL מגדיר את הפרוטוקול שמשמש לבדיקת תקינות. האפשרויות התקפות הן grpc,‏ grpc-with-tls,‏ http,‏ https,‏ http2,‏ ssl ו-tcp.
‫NAME הוא השם של בדיקת התקינות. בפרויקט נתון: לכל בדיקת תקינות גלובלית צריך להיות שם ייחודי, ולבדיקות תקינות אזוריות צריך להיות שם ייחודי באזור נתון.
‫REGION: האזור של בדיקת תקינות. במאזני עומסים אזוריים, האזור של בדיקת תקינות צריך להיות זהה לאזור של השירות לקצה העורפי.
‫DESCRIPTION הוא תיאור אופציונלי.
‫CHECK_INTERVAL הוא משך הזמן שחלף מהתחלת החיבור של בקשה לבדיקת תקינות אחת ועד להתחלת החיבור של הבקשה הבאה. היחידות הן שניות. אם לא מציינים ערך,מערכת Google Cloud משתמשת בערך 5s (5 שניות).
‫TIMEOUT הוא משך הזמן ש Google Cloudממתין לתגובה לבקשה לבדיקת תקינות (probe). הערך של TIMEOUT חייב להיות קטן מהערך של CHECK_INTERVAL או שווה לו. היחידות הן שניות. אם לא מציינים ערך, מערכתGoogle Cloud משתמשת בערך 5s (5 שניות).
‫HEALTHY_THRESHOLD ו-UNHEALTHY_THRESHOLD מציינים את מספר הבדיקות הרצופות שצריכות להצליח או להיכשל כדי שהמכונה הווירטואלית תיחשב תקינה או לא תקינה. אם לא מציינים את אחד מהם, Google Cloud משתמש בסף ברירת מחדל של 2.
‫PORT_SPECIFICATION: הגדרת מפרט היציאה באמצעות אחד מהדגלים של מפרט היציאה.
‫ADDITIONAL_FLAGS הן דגלים אחרים לציון יציאות ואפשרויות שספציפיות ל-PROTOCOL. אפשר לעיין במאמרים Additional flags for HTTP, HTTPS, and HTTP/2 health checks,‏ Additional flags for SSL and TCP health checks או Additional flag for gRPC health checks.

Terraform

כדי ליצור בדיקת תקינות גלובלית, משתמשים במשאב google_compute_health_check.

resource "google_compute_health_check" "health_check_tcp_with_logging" {
  provider = google-beta

  name = "health-check-tcp"

  timeout_sec        = 1
  check_interval_sec = 1

  tcp_health_check {
    port = "22"
  }

  log_config {
    enable = true
  }
}

כדי ליצור בדיקת תקינות אזורית, משתמשים במשאב google_compute_region_health_check.

resource "google_compute_region_health_check" "default" {
  name               = "tcp-health-check-region-west"
  timeout_sec        = 5
  check_interval_sec = 5
  tcp_health_check {
    port = "80"
  }
  region = "us-west1"
}

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

API

כדי ליצור בדיקת תקינות גלובלית, משתמשים ב-healthChecks.insert
כדי ליצור בדיקת תקינות אזורית, משתמשים ב-regionHealthChecks.insert

שינוי בדיקות תקינות

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

המסוף

נכנסים לדף Health checks במסוף Google Cloud .
לדף Health checks
לוחצים על בדיקת תקינות כדי לראות את הפרטים שלה.
אם צריך לשנות את בדיקת תקינות, לוחצים על עריכה ואז:
- מבצעים שינויים בפרמטרים לפי הצורך.
- לוחצים על Save.

gcloud

מזהים את השם וההיקף של בדיקת התקינות. הוראות מפורטות מופיעות במאמר רשימת בדיקות תקינות.
אפשר לשנות את כל הדגלים הנפוצים, את דגלי הגדרת היציאה ואת הדגלים הנוספים האחרים, למעט השם, הפרוטוקול וההיקף של בדיקת תקינות. כדי לשנות בדיקת תקינות קיימת, משתמשים בפקודה המתאימה compute health-checks update. ההגדרות שהוגדרו מראש נשמרות לגבי דגלים שמשמיטים.
- דוגמה לשינוי של בדיקת תקינות גלובלית: הפקודה הבאה משנה בדיקת תקינות גלובלית מסוג HTTP בשם hc-http-port-80 על ידי שינוי מרווח הבדיקה, הזמן הקצוב לתפוגה ונתיב הבקשה:
```
gcloud compute health-checks update http hc-http-port-80 \
    --global \
    --check-interval=20s \
    --timeout=15s \
    --request-path="/health"
```
- דוגמה לשינוי של בדיקת תקינות אזורית: הפקודה הבאה משנה בדיקת תקינות אזורית של TCP ב-us-west1 בשם hc-west1-tcp-ldap על ידי שינוי מפרט היציאה שלה:
```
gcloud compute health-checks update tcp hc-west1-tcp-ldap \
    --region=us-west1 \
    --port=631
```

API

מזהים את השם וההיקף של בדיקת התקינות. הוראות מופיעות במאמר הצגת בדיקות תקינות.
אפשר לשנות את כל הדגלים הנפוצים, את הדגלים של הגדרת היציאה ואת הדגלים הנוספים האחרים באמצעות קריאות ה-API האלה, למעט השם, הפרוטוקול וההיקף של בדיקת תקינות. משתמשים בקריאות ל-API‏ patch כדי לשמור הגדרות שהוגדרו מראש ולא צוינו במפורש בבקשה.
- כדי לשנות בדיקת תקינות גלובלית, משתמשים ב-healthChecks.update או ב-healthChecks.patch.
- כדי לשנות בדיקת תקינות אזורית, משתמשים ב-regionHealthChecks.update או ב-regionHealthChecks.patch.

הצגת רשימה של בדיקות תקינות

המסוף

נכנסים לדף Health checks במסוף Google Cloud .
לדף Health checks
לוחצים על בדיקת תקינות כדי לראות את הפרטים שלה.

gcloud

כדי לראות את רשימת בדיקות התקינות, משתמשים בפקודה compute health-checks list:

כדי להציג רשימה של בדיקות תקינות גלובליות:
```
gcloud compute health-checks list \
    --global
```
כדי להציג רשימה של בדיקות תקינות אזוריות: מחליפים את REGION_LIST ברשימה מופרדת בפסיקים של Google Cloud אזורים לשליחת שאילתה.
```
gcloud compute health-checks list \
    --regions=REGION_LIST
```

אחרי שמגלים את השם וההיקף של בדיקת תקינות, משתמשים בפקודה compute health-checks describe כדי לראות את ההגדרה הנוכחית שלה.

כדי לתאר בדיקת תקינות גלובלית, מחליפים את NAME בשם שלה.
```
gcloud compute health-checks describe NAME \
    --global
```
כדי לתאר בדיקת תקינות אזורית, מחליפים את NAME בשם שלה ואת REGION באזור שלה.
```
gcloud compute health-checks describe NAME \
    --region=REGION
```

API

כדי להציג רשימה של בדיקות תקינות, משתמשים בקריאות ה-API הבאות:

כדי להציג רשימה של בדיקות תקינות גלובליות: healthChecks.list
כדי להציג רשימה של בדיקות תקינות אזוריות: regionHealthChecks.list

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

כדי לתאר בדיקת תקינות גלובלית: healthChecks.get
כדי לתאר בדיקת תקינות אזורית: regionHealthChecks.get

סימונים נוספים

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

דגלים של מפרט ניוד

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

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

מוצר	סוג הבק-אנד	אפשרויות של מפרט הניוד
מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי	קבוצות של מכונות וקבוצות NEG נתמכות	‫`--port`: מציינים מספר יציאת TCP, מ-`1` עד `65535` המערכת מתעלמת מהדגל `--use-serving-port` בבדיקת תקינות שמשויכת למאזן עומסי רשת פנימי מסוג Network Load Balancer, כי שירותי הקצה העורפי של מאזן העומסים הזה לא רשומים לאף יציאה עם שם. הסיבה לכך היא שמדובר במאזני עומסים מסוג passthrough שמעבירים חבילות ישירות לקצה העורפי, במקום ליצור חיבורים חדשים ממאזן העומסים לקצה העורפי.
מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי	מאגרי יעד	בדיקות תקינות מדור קודם שתומכות בהגדרת מספר היציאה (`--port`) .
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי	קבוצות של מכונות וקבוצות NEG נתמכות	‫`--port`: מציינים מספר יציאת TCP, מ-`1` עד `65535` המערכת מתעלמת מהדגל `--use-serving-port` בבדיקת תקינות שמשויכת למאזן עומסי רשת פנימי מסוג Network Load Balancer, כי שירותי הקצה העורפי של מאזן העומסים הזה לא רשומים לאף יציאה עם שם. הסיבה לכך היא שמדובר במאזני עומסים מסוג passthrough שמעבירים חבילות ישירות לקצה העורפי, במקום ליצור חיבורים חדשים ממאזן העומסים לקצה העורפי.
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) מאזן עומסים קלאסי של אפליקציות (ALB) מאזן עומסים אזורי חיצוני של אפליקציות (ALB) מאזן עומסים פנימי חוצה אזורים של אפליקציות (ALB) מאזן עומסים אזורי פנימי של אפליקציות (ALB) מאזן עומסי רשת גלובלי חיצוני בשרת proxy מאזן עומסי רשת קלאסי בשרת proxy מאזן עומסי רשת אזורי חיצוני בשרת proxy מאזן עומסי רשת פנימי חוצה אזורים בשרת proxy מאזן עומסי רשת אזורי פנימי בשרת proxy Cloud Service Mesh	קבוצות NEG נתמכות	‫`--port`: מציינים מספר יציאת TCP, מ-`1` עד `65535` ‫`--use-serving-port`: שימוש ביציאה של כל נקודת קצה בקבוצת נקודות הקצה ברשת.
	קבוצות של מכונות	‫`--port`: מציינים מספר יציאת TCP, מ-`1` עד `65535` ‫`--use-serving-port`: משתמשים באותו שם של קבוצת מופעים, שאליה שירות לקצה העורפי רשום.

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

אם הפרוטוקול של בדיקת תקינות הוא tcp או http, נעשה שימוש ב---port=80.
אם הפרוטוקול של בדיקת תקינות הוא ssl,‏ https או http2, נעשה שימוש ב---port=443.
אם הפרוטוקול של בדיקת תקינות הוא grpc או grpc_with_tls, אין ברירת מחדל משתמעת, ולכן צריך לכלול את הגדרת היציאה.

דגלים נוספים לבדיקות תקינות של HTTP,‏ HTTPS ו-HTTP/2

בנוסף לדגלים הנפוצים ולציון היציאה, אפשר להשתמש בדגלים האופציונליים הבאים לבדיקות תקינות של HTTP,‏ HTTPS ו-HTTP/2. בדוגמה הזו נוצרת בדיקת תקינות מסוג HTTP בשם hc-http-port-80 באמצעות יציאה 80 עם קריטריונים של ברירת מחדל למרווח, לזמן קצוב לתפוגה ולסף התקינות.

gcloud compute health-checks create HTTP_PROTOCOL hc-http-port-80 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --host=HOST \
    --proxy-header=PROXY_HEADER \
    --request-path=REQUEST_PATH \
    --response=RESPONSE

‫HTTP_PROTOCOL: יכול להיות http (HTTP/1.1 בלי TLS),‏ https (HTTP/1.1 עם TLS) או http2 (HTTP/2 עם TLS).
‫COMMON_FLAGS: מגדיר את הדגלים הנפוצים. איך יוצרים קמפיינים
‫PORT_SPECIFICATION: הגדרת מפרט היציאה באמצעות אחד מדגלי מפרט היציאה.
‫HOST מאפשרת לספק כותרת HTTP‏ Host. אם לא מציינים כתובת IP, המערכת משתמשת בכתובת ה-IP של כלל ההעברה של מאזן העומסים.
הערך של PROXY_HEADER צריך להיות NONE או PROXY_V1. אם לא מציינים ערך,Google Cloud משתמש ב-NONE. הערך של PROXY_V1 מוסיף את הכותרת PROXY UNKNOWN\r\n.
‫REQUEST_PATH מציין את נתיב כתובת ה-URL שמשמש Google Cloud לשליחת בקשות לבדיקת תקינות. אם לא מציינים כתובת, הבקשה לבדיקת תקינות נשלחת אל /.
‫RESPONSE מגדיר תשובה צפויה אופציונלית. מחרוזות התשובה צריכות לעמוד בכללים הבאים:
- מחרוזת התשובה חייבת לכלול אותיות ASCII, מספרים ורווחים.
- מחרוזת התשובה יכולה להכיל עד 1,024 תווים.
- אין תמיכה בהתאמה של תווים כלליים לחיפוש.
- בבדיקה מבוססת-תוכן אין תמיכה בהיפוך; לדוגמה, אין תמיכה באופרטורים כמו ! ב-HAProxy.

אם Google Cloud מוצא את מחרוזת התגובה הצפויה בכל מקום ב-1,024 הבייטים הראשונים של גוף התגובה שהתקבל, ואם סטטוס ה-HTTP הוא 200 (OK), הבקשה לבדיקת תקינות (probe) נחשבת מוצלחת.

הדגלים --request-path ו---response משנים את הקריטריונים להצלחה של בדיקת התקינות.

דגלים נוספים לבדיקות תקינות של SSL ו-TCP

בנוסף לדגלים הנפוצים ולמפרט היציאה, אפשר להשתמש בדגלים האופציונליים הבאים לבדיקות תקינות של SSL ו-TCP. בדוגמה הזו נוצרת בדיקת תקינות של TCP בשם hc-tcp-3268 באמצעות יציאה 3268 עם מרווח זמן, זמן קצוב לתפוגה וקריטריונים של סף תקינות שמוגדרים כברירת מחדל.

gcloud compute health-checks create tcp hc-tcp-3268 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --proxy-header=PROXY_HEADER \
    --request=REQUEST_STRING \
    --response=RESPONSE_STRING

הפרוטוקול יכול להיות tcp (בדוגמה הזו) או ssl.
‫COMMON_FLAGS: מגדיר את הדגלים הנפוצים. איך יוצרים קמפיינים
‫PORT_SPECIFICATION: הגדרת מפרט היציאה באמצעות אחד מדגלי מפרט היציאה.
הערך של PROXY_HEADER צריך להיות NONE או PROXY_V1. אם לא מציינים ערך,Google Cloud משתמש ב-NONE. הערך של PROXY_V1 מוסיף את הכותרת PROXY UNKNOWN\r\n.
‫REQUEST_STRING: אפשר לספק מחרוזת באורך של עד 1,024 תווים ב-ASCII, שתשלח אחרי שנוצר סשן TCP או SSL.
‫RESPONSE_STRING: אפשר לספק מחרוזת באורך של עד 1,024 תווים ב-ASCII, לתגובה הצפויה.

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

תג נוסף לבדיקות תקינות של gRPC

שרת ה-gRPC שלכם צריך להטמיע את שירות הבדיקה של gRPC, כפי שמתואר בפרוטוקול בדיקת התקינות של gRPC. ‫Google Cloud שולח הודעת HealthCheckRequest לשרתי הקצה העורפיים שלכם על ידי קריאה לשיטת Check של שירות הבדיקה בשרת הקצה העורפי. פרמטר השירות בבקשה מוגדר למחרוזת ריקה, אלא אם מצוין שם שירות gRPC.

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

--grpc-service-name=GRPC_SERVICE_NAME

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

MyPackage.ServiceA עם סטטוס הצגת המודעות SERVING
MyPackage.ServiceB עם סטטוס הצגת המודעות NOT_SERVING
שם שירות ריק עם סטטוס ההצגה NOT_SERVING

אם יוצרים בדיקת תקינות מול MyPackage.ServiceA, כמו בדוגמה הבאה, בדיקת התקינות מחזירה HEALTHY, כי הסטטוס של השירות הוא SERVING.

gcloud compute health-checks create grpc MyGrpcHealthCheckServiceA \
    --grpc-service-name=MyPackage.ServiceA

אם יוצרים בדיקת תקינות מול MyPackage.ServiceB, בדיקת התקינות מחזירה UNHEALTHY כי הסטטוס של השירות הוא NOT_SERVING.

אם תיצרו בדיקת תקינות מול MyPackage.ServiceC, שלא רשום בשירות התקינות של gRPC, בדיקת התקינות תחזיר את סטטוס gRPC‏ NOT_FOUND, ששווה ל-UNHEALTHY.

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

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

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

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

יצירת בדיקות תקינות מדור קודם

המסוף

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

אפשר ליצור בדיקת תקינות מדור קודם ב Google Cloud מסוף רק כש יוצרים מאזן עומסים אזורי חיצוני מסוג Network Load Balancer (מאזן עומסים ברשת) שמבוסס על מאגר יעדים. כדי ליצור את בדיקת התקינות מדור קודם לבד, משתמשים בהוראות של gcloudאו של API שבסעיף הזה.

gcloud

כדי ליצור בדיקת תקינות מדור קודם, משתמשים בפקודה compute http-health-checks create:

gcloud compute LEGACY_CHECK_TYPE create NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --host=HOST \
    --port=PORT \
    --request-path=REQUEST_PATH

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

‫LEGACY_CHECK_TYPE הוא http-health-checks לבדיקת תקינות מדור קודם של HTTP או https-health-checks לבדיקת תקינות מדור קודם של HTTPS. אם אתם יוצרים בדיקת תקינות מדור קודם למאזן עומסים אזורי חיצוני של רשת להעברת סיגנל ללא שינוי שמבוסס על מאגר יעדים, אתם צריכים להשתמש ב-http-health-checks.
‫NAME הוא השם של בדיקת תקינות מדור קודם. בפרויקט נתון, לכל בדיקת תקינות מדור קודם צריך להיות שם ייחודי.
‫DESCRIPTION הוא תיאור אופציונלי.
‫CHECK_INTERVAL הוא משך הזמן שחלף מתחילת בדיקה אחת ועד לתחילת הבדיקה הבאה. היחידות הן שניות. אם לא מציינים ערך, מערכתGoogle Cloud משתמשת בערך 5s (5 שניות).
‫TIMEOUT הוא משך הזמן שבו Google Cloud תמתין לתגובה לבדיקה. הערך של TIMEOUT צריך להיות קטן מהערך של CHECK_INTERVAL או שווה לו. היחידות הן שניות. אם לא מציינים ערך, Google Cloud משתמש בערך 5s (5 שניות).
‫HEALTHY_THRESHOLD ו-UNHEALTHY_THRESHOLD מציינים את מספר הבדיקות הרציפות שצריכות להצליח או להיכשל כדי שייחשב שהמכונה הווירטואלית תקינה או לא תקינה. אם לא מציינים את אחד מהם, Google Cloud משתמש בסף ברירת מחדל של 2.
‫HOST מאפשרת לכם לספק כותרת HTTP של מארח. אם לא מציינים כתובת IP, נעשה שימוש בכתובת ה-IP של כלל ההעברה של מאזן העומסים.
‫PORT מאפשר לציין מספר יציאה. אם לא מציינים ערך,Google Cloud משתמש ב-80.
השדה REQUEST_PATH מציין את נתיב כתובת ה-URL שמשמש Google Cloud לשליחת בקשות לבדיקת תקינות. אם לא מציינים כתובת, בקשת בדיקת תקינות נשלחת אל /.

API

כדי ליצור בדיקת תקינות HTTP מדור קודם, משתמשים בקריאה ל-API‏ httpHealthChecks.insert.
כדי ליצור בדיקת תקינות מדור קודם ב-HTTPS, משתמשים ב-httpsHealthChecks.insert

Terraform

כדי ליצור משאב בדיקת תקינות HTTP מדור קודם, משתמשים במשאב google_compute_http_health_check.
כדי ליצור משאב בדיקת תקינות ב-HTTPS מדור קודם, משתמשים במשאב google_compute_https_health_check.

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

המסוף

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

gcloud

כדי לשנות בדיקת תקינות HTTP מדור קודם, משתמשים בפקודה compute http-health-checks update ומחליפים את NAME בשם שלה. כשמשנים בדיקת תקינות מדור קודם באמצעות gcloud, ההגדרות שנקבעו מראש לדגלים שהושמטו נשמרות. OTHER_OPTIONS הן האפשרויות שמתוארות במאמר בנושא יצירת בדיקת תקינות מדור קודם.
```
gcloud compute http-health-checks update NAME \
  OTHER_OPTIONS
```
כדי לשנות בדיקת תקינות של HTTPS מדור קודם, משתמשים בפקודה compute https-health-checks update ומחליפים את NAME בשם שלה. כשמשנים בדיקת תקינות מדור קודם באמצעות gcloud, ההגדרות שנקבעו מראש לדגלים שהושמטו נשמרות. OTHER_OPTIONS הן האפשרויות שמתוארות במאמר בנושא יצירת בדיקת תקינות מדור קודם.
```
gcloud compute https-health-checks update NAME \
  OTHER_OPTIONS
```

API

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

כדי לשנות בדיקת תקינות מסוג HTTP מדור קודם, משתמשים ב-method‏ httpHealthChecks.update או ב-method‏ httpHealthChecks.patch.
כדי לשנות בדיקת תקינות מדור קודם של HTTPS, משתמשים ב-method‏ httpsHealthChecks.update או ב-method‏ httpsHealthChecks.patch.

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

המסוף

נכנסים לדף Health checks במסוף Google Cloud .
לדף Health checks
לוחצים על בדיקת תקינות מדור קודם כדי לראות את הפרטים שלה.

gcloud

כדי לראות את רשימת בדיקות תקינות HTTP מדור קודם, משתמשים בפקודה compute http-health-checks list:
```
gcloud compute http-health-checks list
```
כדי לראות את רשימת בדיקות תקינות של HTTPS מדור קודם, משתמשים בפקודה compute https-health-checks list:
```
gcloud compute https-health-checks list
```
כדי להוסיף תיאור לבדיקת תקינות HTTP מדור קודם, משתמשים בפקודה compute http-health-checks describe ומחליפים את NAME בשם שלה.
```
gcloud compute http-health-checks describe NAME
```
כדי להוסיף תיאור לבדיקת תקינות של HTTPS מדור קודם, משתמשים בפקודה compute https-health-checks describe ומחליפים את NAME בשם שלה.
```
gcloud compute https-health-checks describe NAME
```

API

כדי להציג רשימה של בדיקות תקינות מדור קודם:
- משתמשים ב-method‏ httpHealthChecks.list כדי להציג רשימה של בדיקות תקינות HTTP מדור קודם.
- כדי להציג רשימה של בדיקות תקינות מדור קודם של HTTPS, משתמשים ב-httpsHealthChecks.list
כדי לתאר בדיקת תקינות מדור קודם:
- משתמשים ב-method‏ httpHealthChecks.get כדי לתאר בדיקת תקינות HTTP מדור קודם.
- אפשר להשתמש ב-httpsHealthChecks.get כדי לתאר בדיקת תקינות מדור קודם של HTTPS.

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

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

בדוגמה הזו, כל תעבורת TCP ממערכות בדיקת התקינות Google Cloud מורשית למכונות הווירטואליות. (תנועת TCP כוללת תנועת SSL,‏ HTTP,‏ HTTPS ו-HTTP/2). אם אתם מעדיפים, אתם יכולים לציין יציאות יחד עם פרוטוקול TCP, אבל אם תציינו יציאות, יכול להיות שכללי חומת האש יהיו ספציפיים לבדיקת תקינות מסוימת. אם משתמשים ב-tcp:80 בשביל הפרוטוקול והיציאה, תנועת TCP מותרת ביציאה 80, כך ש- Google Cloud יכול ליצור קשר עם מכונות וירטואליות באמצעות HTTP ביציאה 80, אבל לא באמצעות HTTPS ביציאה 443.

המסוף

נכנסים לדף Firewall policies במסוף Google Cloud .
מעבר למדיניות חומת האש
לוחצים על יצירת כלל חומת אש.
בדף יצירת כלל חומת אש, מספקים את הפרטים הבאים:
- Name: נותנים שם לכלל. בדוגמה הזו, נשתמש ב-fw-allow-health-checks.
- רשת: בוחרים רשת VPC.
- עדיפות: מזינים מספר לעדיפות. מספרים נמוכים יותר מייצגים עדיפות גבוהה יותר. חשוב לוודא שלכלל חומת האש יש עדיפות גבוהה יותר מכללים אחרים שעשויים לדחות תעבורת נתונים נכנסת.
- כיוון התנועה: בוחרים באפשרות תנועה נכנסת (ingress).
- פעולה בהתאמה: בוחרים באפשרות אישור.
- יעדים: בוחרים באפשרות תגי יעד ספציפיים ומזינים תגים בשדה תגי יעד. בדוגמה הזו, נשתמש ב-allow-health-checks.
- מסנן מקור: בוחרים באפשרות טווח כתובות IP.
- טווח כתובות ה-IP של המקור: מזינים את טווח כתובות ה-IP של המקור בהתאם לסוג איזון העומסים, סוג התנועה וסוג בדיקת התקינות. מידע על טווחי כתובות IP של בדיקות וכללים של חומת אש
- פרוטוקולים ויציאות מותרים: משתמשים ב-tcp וביציאה שהוגדרה בבדיקת התקינות. פרוטוקול TCP הוא פרוטוקול הבסיס לכל פרוטוקולי בדיקות התקינות.
- לוחצים על יצירה.
בכל אחת מהמכונות הווירטואליות שמוגדר בהן איזון עומסים, מוסיפים את תג הרשת כדי שכלל חומת האש החדש של תעבורת הכניסה יחול עליהן. בדוגמה הזו נעשה שימוש ב-allow-health-checks לתג הרשת.

gcloud

משתמשים בפקודה gcloud הבאה כדי ליצור כלל חומת אש בשם fw-allow-health-checks שמאפשר חיבורי TCP נכנסים ממערכות בדיקת תקינותGoogle Cloud למופעים ברשת ה-VPC עם התג allow-health-checks. בהתאם לסוג מאזן העומסים, יש קבוצה שונה של טווחים של כתובות IP לבדיקה וכללי חומת אש שנתמכים לתנועת IPv6 אל השרתים העורפיים.

מחליפים את NETWORK_NAME בשם רשת ה-VPC ואת PORT ביציאות שבהן נעשה שימוש במאזן העומסים.
```
gcloud compute firewall-rules create fw-allow-health-checks \
    --network=NETWORK_NAME \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=SOURCE_IP_RANGE \
    --target-tags=allow-health-checks \
    --rules=tcp:PORT
```
הערך של SOURCE_IP_RANGE תלוי בסוג איזון העומסים, בסוג התנועה ובסוג בדיקת תקינות. מידע על טווחי כתובות IP של בדיקות וכללים של חומת אש
בכל אחת מהמכונות הווירטואליות שמוגדר בהן איזון עומסים, מוסיפים את תג הרשת כדי שכלל חומת האש החדש של תעבורת הכניסה יחול עליהן. בדוגמה הזו נעשה שימוש ב-allow-health-checks לתג הרשת.

פרטים נוספים זמינים במסמכי התיעוד של הכללים של חומת האש של gcloud ובמסמכי התיעוד של ה-API.

מסמכי תיעוד קשורים:

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

שיוך בדיקות תקינות למאזני עומסים

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

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

בקטע הזה אנחנו יוצאים מנקודת הנחה שכבר:

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

המסוף

כדי לשייך בדיקת תקינות למאזן עומסים קיים:

נכנסים לדף Load balancing במסוף Google Cloud .
כניסה לדף Load balancing
לוחצים על מאזן עומסים כדי לראות את הפרטים שלו.
לוחצים על עריכה ואז על Backend configuration.
בוחרים בדיקת תקינות מהתפריט Health check (בדיקת תקינות).
לוחצים על עדכון.

gcloud

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

מציינים את השם וההיקף של שירות לקצה העורפי. למאזני עומסי רשת להעברת סיגנל ללא שינוי ולמאזני עומסי רשת לשרת proxy יש רק שירות קצה עורפי אחד לכל מאזן עומסים. מאזני העומסים של האפליקציות כוללים שירות לקצה העורפי אחד או יותר שמשויכים למפת URL יחידה.
- כדי להציג רשימה של שירותים לקצה העורפי למאזני עומסי רשת פנימיים להעברת סיגנל ללא שינוי, מריצים את הפקודה הבאה.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=INTERNAL"
```
- כדי להציג רשימה של שירותים לקצה העורפי למאזנים אזוריים חיצוניים של עומסי רשת להעברת סיגנל ללא שינוי, מריצים את הפקודה הבאה.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=EXTERNAL"
```
- כדי להציג רשימה של שירותים לקצה העורפי למאזנים גלובליים חיצוניים של עומסי רשת בשרת proxy, מריצים את הפקודה הבאה.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=EXTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- כדי להציג רשימה של שירותים לקצה העורפי למאזני עומסי רשת קלאסיים בשרת proxy, מריצים את הפקודה הבאה.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=EXTERNAL" \
    --filter="protocol=(SSL,TCP)"
```
- כדי להציג רשימה של שירותים לקצה העורפי במאזני עומסי רשת פנימיים חוצי-אזורים לשרת proxy, מריצים את הפקודה הבאה.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=INTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- כדי להציג רשימה של שירותים לקצה העורפי למאזנים אזוריים חיצוניים של עומסי רשת בשרת proxy, מריצים את הפקודה הבאה.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=EXTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- כדי להציג רשימה של שירותים לקצה העורפי למאזנים אזוריים פנימיים של עומסי רשת לשרת proxy, מריצים את הפקודה הבאה.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=INTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- כדי לזהות שירות לקצה העורפי למאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), למאזני עומסים קלאסיים של אפליקציות ולמאזני עומסים פנימיים של אפליקציות (ALB) בין אזורים, צריך קודם לזהות מפת URL ואז לתאר את המפה. מיפויי כתובות URL ושירותי קצה עורפיים של מאזני העומסים האלה הם תמיד גלובליים, ללא קשר לרמת שירות הרשת. מחליפים את URL_MAP_NAME בשם של מפת URL. השירותים לקצה העורפי שבהם נעשה שימוש במאזן העומסים מפורטים בתשובה.
```
gcloud compute url-maps list \
    --global
```
```
gcloud compute url-maps describe URL_MAP_NAME \
    --global
```
- כדי לזהות שירותי בק-אנד למאזן עומסים אזורי חיצוני של אפליקציות (ALB) או למאזן עומסים אזורי פנימי של אפליקציות (ALB), צריך קודם לזהות מפת URL ואז לתאר את המפה. גם מיפויי כתובות ה-URL וגם השירותים לקצה העורפי של מאזני העומסים האלה הם אזוריים. מחליפים את REGION_LIST ברשימה מופרדת בפסיקים שלGoogle Cloud אזורים לביצוע שאילתה. מחליפים את URL_MAP_NAME בשם של מפת ה-URL ואת REGION באזור שלו. השירותים לקצה העורפי שבהם נעשה שימוש במאזן העומסים מפורטים בתשובה.
```
gcloud compute url-maps list \
    --regions=REGION_LIST
```
```
gcloud compute url-maps describe URL_MAP_NAME \
    --region=REGION
```
מזהים בדיקת תקינות. בדיקות תקינות של כרטיסי מוצר
משייכים בדיקת תקינות לשירות לקצה העורפי באמצעות הפקודה compute backend-services update. כל שירות לקצה העורפי חייב להפנות לבדיקת תקינות אחת. בפקודות הבאות, מחליפים את BACKEND_SERVICE_NAME בשם של שירות לקצה העורפי, את HEALTH_CHECK_NAME בשם של בדיקת תקינות, ואם צריך, את REGION בGoogle Cloud אזור של שירות לקצה העורפי, של בדיקת התקינות או של שניהם.
- כדי לשנות את בדיקת התקינות של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי: שירות הקצה העורפי של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי הוא אזורי. הוא יכול להתייחס לבדיקת תקינות גלובלית או אזורית. בדוגמה הבאה מוצגת הפניה לבדיקת תקינות אזורית. אם אתם משתמשים בבדיקת תקינות גלובלית עם מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, אתם צריכים להשתמש ב---global-health-checks במקום ב---health-checks-region.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```
- כדי לשנות את בדיקת תקינות של מאזן עומסים אזורי חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות קצה עורפי: שירות הקצה העורפי של מאזן עומסים אזורי חיצוני להעברת סיגנל ללא שינוי הוא אזורי. יכול להיות שהיא תפנה לבדיקת תקינות אזורית.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```
- כדי לשנות את בדיקת התקינות של מאזן עומסים גלובלי חיצוני בשרת proxy, מאזן עומסי רשת קלאסי בשרת proxy, מאזן עומסים גלובלי חיצוני של אפליקציות (ALB), מאזן עומסים קלאסי של אפליקציות (ALB) או מאזן עומסים פנימי של אפליקציות (ALB) בכמה אזורים: גם שירות הקצה העורפי וגם בדיקת התקינות הם גלובליים במאזני העומסים האלה. מאזני עומסים של אפליקציות יכולים להפנות ליותר מבדיקת תקינות אחת אם הם מפנים ליותר משירות קצה עורפי אחד.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --global \
    --health-checks HEALTH_CHECK_NAME \
    --global-health-checks
```
- כדי לשנות את בדיקת התקינות של מאזן עומסים חיצוני אזורי של אפליקציות (ALB), מאזן עומסי רשת אזורי חיצוני בשרת proxy, מאזן עומסים פנימי אזורי של אפליקציות (ALB) או מאזן עומסי רשת אזורי פנימי בשרת proxy: גם שירות הקצה העורפי וגם בדיקת התקינות הם אזוריים. יכול להיות שמאזני עומסים מסוימים יתייחסו ליותר מבדיקת תקינות אחת, אם הם יכולים להתייחס ליותר משירות קצה עורפי אחד.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```

API

אפשר להציג רשימה של שירותי קצה עורפי באמצעות קריאה ל-API‏ backendServices.list.
צפייה בבדיקות תקינות
כדי לשייך בדיקת תקינות לשירות קצה עורפי, משתמשים באחת מקריאות ה-API הבאות:
- backendServices.update
- backendServices.patch

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

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

בקטע הזה אנחנו יוצאים מנקודת הנחה שכבר:

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

המסוף

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

נכנסים לדף Load balancing במסוף Google Cloud .
כניסה לדף Load balancing
לוחצים על מאזן עומסים כדי לראות את הפרטים שלו.
לוחצים על עריכה ואז על Backend configuration.
בוחרים בדיקת תקינות מדור קודם מהתפריט Health check (בדיקת תקינות). (מוצגים רק בדיקות תקינות מדור קודם שעומדות בדרישות).
לוחצים על עדכון.

gcloud

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

מזהים את מאגרי היעד. למאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי יש לפחות מאגר יעד אחד, ויכול להיות שיש לו מאגר גיבוי משני.
```
gcloud compute target-pools list
```
זיהוי בדיקת תקינות מדור קודם באמצעות פרוטוקול HTTP. במקרה הצורך, אפשר לצפות בבדיקות תקינות מדור קודם.
משייכים את בדיקת התקינות מדור קודם למאגר היעדים. בפקודות הבאות, מחליפים את TARGET_POOL_NAME בשם של מאגר היעד, את REGION באזור שלו ואת LEGACY_CHECK_NAME בשם של בדיקת תקינות מדור קודם. בבדיקת תקינות מדור קודם צריך להשתמש בפרוטוקול HTTP.
- כדי להסיר בדיקת תקינות HTTP מדור קודם ממאגר יעדים:
```
gcloud compute target-pools remove-health-checks TARGET_POOL_NAME \
    --region=REGION \
    --http-health-check LEGACY_CHECK_NAME
```
- כדי להוסיף בדיקת תקינות HTTP מדור קודם למאגר יעדים:
```
gcloud compute target-pools add-health-checks TARGET_POOL_NAME \
    --region=REGION \
    --http-health-check LEGACY_CHECK_NAME
```

API

אפשר להציג רשימה של מאגרי יעד באמצעות קריאה ל-API‏ targetPools.list.
צפייה בבדיקות תקינות מדור קודם וזיהוי בדיקת תקינות HTTP מדור קודם.
כדי לשייך בדיקת תקינות HTTP מדור קודם למאגר יעדים, משתמשים בקריאת ה-API‏ targetPools.addHealthCheck.

בדיקת הסטטוס של בדיקת התקינות

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

המסוף

עוברים לדף הסיכום של איזון העומסים.
כניסה לדף Load balancing
לוחצים על השם של מאזן העומסים.
בקטע Backend, בודקים את העמודה Healthy. סטטוס תקינות מדווח לכל קבוצת שרתי עורף (backend instance) או קבוצה של נקודות קצה ברשת.

gcloud

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

משתמשים בפקודה compute backend-services get-health, מחליפים את NAME בשם של שירות לקצה העורפי ואת REGION באזור שלו, אם צריך.
- כדי לקבל את מצב התקינות המיידי של שירות לקצה עורפי גלובלי:
```
gcloud compute backend-services get-health GLOBAL_BACKEND_SERVICE_NAME \
    --global
```
- כדי לקבל את מצב התקינות המיידי של שירות קצה עורפי אזורי:
```
gcloud compute backend-services get-health REGIONAL_BACKEND_SERVICE_NAME \
    --region=REGION
```
במאזנים אזוריים חיצוניים של עומסי רשת להעברת סיגנל ללא שינוי שמבוססים על מאגרי יעד, צריך לזהות את השם והאזור של מאגר היעד של מאזן העומסים, ואז להשתמש בפקודה compute target-pools get-health ולהחליף את NAME בשם של מאגר היעד ואת REGION באזור שלו.
```
gcloud compute target-pools get-health TARGET_POOL_NAME \
    --region=REGION
```

API

לכל מאזני העומסים, מלבד מאזני עומסים אזוריים חיצוניים של רשתות להעברת סיגנל ללא שינוי שמבוססים על מאגרי יעד, צריך לציין את השם וההיקף (גלובלי או אזורי) של שירות הקצה העורפי. רשימה מלאה של מאזני עומסים והיקפים מופיעה במאמר Backend services.
- כדי לקבל את מצב התקינות המיידי של שירות קצה עורפי גלובלי, משתמשים ב-backendServices.getHealth
- כדי לקבל את מצב התקינות המיידי של שירות קצה עורפי אזורי, משתמשים ב-regionBackendServices.getHealth
למאזני עומסי רשת אזוריים חיצוניים להעברת סיגנל ללא שינוי שמבוססים על מאגרי יעד, משתמשים ב-targetPools.getHealth

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

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

המסוף

gcloud

Terraform

API

שינוי בדיקות תקינות

המסוף

gcloud

API

הצגת רשימה של בדיקות תקינות

המסוף

gcloud

API

סימונים נוספים

דגלים של מפרט ניוד

דגלים נוספים לבדיקות תקינות של HTTP,‏ HTTPS ו-HTTP/2

דגלים נוספים לבדיקות תקינות של SSL ו-TCP

תג נוסף לבדיקות תקינות של gRPC

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

יצירת בדיקות תקינות מדור קודם

המסוף

gcloud

API

Terraform

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

המסוף

gcloud

API

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

המסוף

gcloud

API

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

המסוף

gcloud

שיוך בדיקות תקינות למאזני עומסים

המסוף

gcloud

API

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

המסוף

gcloud

API

בדיקת הסטטוס של בדיקת התקינות

המסוף

gcloud

API

שימוש בבדיקות תקינות