Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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 המערכת ממתינה לתגובה לבדיקה. הערך של 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` בבדיקת תקינות שמשויכת למאזן עומסים פנימי מסוג passthrough, כי שירותי הבק-אנד של מאזן העומסים הזה לא רשומים ליציאות עם שמות. הסיבה לכך היא שמדובר במאזני עומסים מסוג passthrough שמעבירים מנות ישירות לשרתי קצה עורפיים, במקום ליצור חיבורים חדשים ממאזן העומסים לשרת הקצה העורפי.
מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי	מאגרי יעד	בדיקות תקינות מדור קודם שתומכות בהגדרת מספר היציאה (`--port`) .
מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי	קבוצות של מכונות וקבוצות NEG נתמכות	‫`--port`: מציינים מספר יציאת TCP, מ-`1` עד `65535` המערכת מתעלמת מהדגל `--use-serving-port` בבדיקת תקינות שמשויכת למאזן עומסים פנימי מסוג passthrough, כי שירותי הבק-אנד של מאזן העומסים הזה לא רשומים ליציאות עם שמות. הסיבה לכך היא שמדובר במאזני עומסים מסוג passthrough שמעבירים מנות ישירות לשרתי קצה עורפיים, במקום ליצור חיבורים חדשים ממאזן העומסים לשרת הקצה העורפי.
מאזן עומסים גלובלי חיצוני של אפליקציות (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 לשליחת בקשות לבדיקת תקינות. אם לא מציינים כתובת, הבקשה לבדיקת תקינות נשלחת אל /.
‫RESPONSE מגדיר תשובה צפויה אופציונלית. מחרוזות התשובה צריכות לעמוד בכללים הבאים:
- מחרוזת התשובה חייבת לכלול אותיות ASCII, מספרים ורווחים.
- מחרוזת התשובה יכולה להכיל עד 1,024 תווים.
- אין תמיכה בהתאמה של תווים כלליים לחיפוש.
- בבדיקה מבוססת-תוכן אין תמיכה בהיפוך; לדוגמה, אין תמיכה באופרטורים כמו ! ב-HAProxy.

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

הדגלים --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 (NLB) עם העברת תעבורה (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 תמתין תגובה לבדיקה. הערך של 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
כדי לתאר בדיקת תקינות מדור קודם:
- משתמשים ב-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.

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

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

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

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

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

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

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

המסוף

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

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

gcloud

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

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

gcloud

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

משתמשים בפקודה compute backend-services get-health, מחליפים את NAME בשם של שירות ה-Backend ואת 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

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