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

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

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 הוא משך הזמן שחלף מתחילת החיבור של בקשה לבדיקת תקינות אחת ועד לתחילת החיבור של הבקשה הבאה. היחידות הן שניות. אם לא מציינים ערך,המערכת משתמשת בערך 5s (5 שניות). Google Cloud
‫TIMEOUT הוא משך הזמן שבו Google Cloud ממתינה לתגובה לבקשה לבדיקת תקינות (probe). הערך של TIMEOUT חייב להיות קטן מהערך של CHECK_INTERVAL או שווה לו. היחידות הן שניות. אם לא מציינים ערך, מערכתGoogle Cloud משתמשת בערך 5s (5 שניות).
‫HEALTHY_THRESHOLD ו-UNHEALTHY_THRESHOLD מציינים את מספר הבדיקות הרצופות שצריכות להצליח או להיכשל כדי שמכונת ה-VM תיחשב תקינה או לא תקינה. אם אחד מהם לא מצוין,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`: משתמשים באותה קבוצת מופעים בשם port שאליה שירות ה-Backend רשום.

אם לא מציינים את היציאה כשיוצרים את בדיקת התקינות,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 משמש 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, בקשה לבדיקת תקינות (probe) מחזירה UNHEALTHY כי הסטטוס של השירות הוא NOT_SERVING.

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

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

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

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

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

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

המסוף

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

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

כדי להציג רשימה של בדיקות תקינות מדור קודם:
- משתמשים ב-httpHealthChecks.list כדי להציג רשימה של בדיקות תקינות HTTP מדור קודם.
- משתמשים ב-httpsHealthChecks.list כדי להציג רשימה של בדיקות תקינות מדור קודם של HTTPS.
כדי לתאר בדיקת תקינות מדור קודם:
- משתמשים ב-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 .
מעבר אל Firewall policies
לוחצים על יצירת כלל לחומת האש.
בדף Create a firewall rule (יצירת כלל לחומת האש), מזינים את הפרטים הבאים:
- שם: נותנים שם לכלל. בדוגמה הזו, נשתמש בפקודה 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.

מסמכים קשורים:

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

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

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

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

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

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

המסוף

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

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

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

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

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

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

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

המסוף

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

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

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

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

המסוף

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

gcloud

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

משתמשים בפקודה 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

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

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