הגדרה של בדיקת תקינות מבוססת-אפליקציה ותיקון אוטומטי

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

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

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

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

לפני שמתחילים

  • אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא התהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Google Cloud . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים האלה:

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

    המסוף

    כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים ולממשקי ה-API של Google Cloud , לא צריך להגדיר אימות.

    gcloud

    1. התקינו את ה-CLI של Google Cloud. אחר כך, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה: 

      gcloud init

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

  • הגדרת אזור ותחום כברירת מחדל.

    • Terraform

    כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של Terraform שבדף הזה, מתקינים ומפעילים את ה-CLI של gcloud, ואז מגדירים את Application Default Credentials באמצעות פרטי הכניסה של המשתמש.

    1. התקינו את ה-CLI של Google Cloud.

    2. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

      gcloud auth application-default login

      אם אתם משתמשים ב-Cloud Shell, אתם לא צריכים לעשות את זה.

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

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

    REST

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

      התקינו את ה-CLI של Google Cloud.

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

    מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

תמחור

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

הגדרת בדיקת תקינות ותיקון אוטומטי מבוססי-אפליקציה

כדי להגדיר בדיקת תקינות מבוססת-אפליקציה ותיקון תוכנה אוטומטי (autohealing) בקבוצת MIG, צריך לבצע את הפעולות הבאות:

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

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

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

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

המסוף

  1. צרו בדיקת תקינות לתיקון תוכנה אוטומטי (autohealing) שהיא שמרנית יותר מבדיקת תקינות של איזון עומסים.

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

    1. נכנסים לדף Create a health check במסוף Google Cloud .

      כניסה לדף Create a health check

    2. נותנים שם לבדיקת התקינות, למשל example-check.

    3. בוחרים היקף. אפשר לבחור באפשרות Regional או Global. בדוגמה הזו, בוחרים באפשרות Global.

    4. בשדה Protocol, מוודאים שהאפשרות HTTP מסומנת.

    5. בשדה יציאה, מזינים 80.

    6. בקטע Health criteria, מזינים את הערכים הבאים:

      1. בשדה Check interval, מזינים 5.
      2. בשדה Timeout, מזינים 5.
      3. מגדירים Healthy threshold כדי לקבוע כמה בדיקות תקינות רצופות צריכות להחזיר תוצאה תקינה לפני שהמכונה הווירטואלית הלא תקינה תסומן כתקינה. בדוגמה הזו, מזינים 1.
      4. מגדירים Unhealthy threshold כדי לקבוע כמה בדיקות תקינות רצופות צריכות להיכשל לפני שהמכונה הווירטואלית התקינה תסומן כלא תקינה. בדוגמה הזו, מזינים 3.

    7. לוחצים על Create כדי ליצור את בדיקת התקינות.

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

    הבדיקות של תקינות השירות מגיעות מכתובות בטווחים 130.211.0.0/22 ו-35.191.0.0/16, לכן חשוב לוודא שהכללים של חומת האש ברשת מאפשרים לבדיקת התקינות להתחבר. בדוגמה הזו, קבוצת ה-MIG משתמשת ברשת default והמכונות הווירטואליות שלה מאזינות ליציאה 80. אם יציאה 80 לא פתוחה ברשת ברירת המחדל, יוצרים כלל חומת אש.

    1. במסוף Google Cloud , עוברים לדף מדיניות חומת אש.

      כניסה לדף Firewall policies

    2. לוחצים על Create firewall rule.

    3. מזינים שם לכלל של חומת האש. לדוגמה, allow-health-check.

    4. בשדה Network, בוחרים את הרשת default.

    5. בקטע Targets, בוחרים באפשרות All instances in the network.

    6. בקטע מסנן מקור, בוחרים באפשרות IPv4 ranges.

    7. בשדה Source IPv4 ranges, מזינים את הערכים 130.211.0.0/22 ו-35.191.0.0/16.

    8. בקטע Protocols and ports, בוחרים באפשרות Specified protocols and ports ומבצעים את הפעולות הבאות:

      1. בוחרים באפשרות TCP.
      2. בשדה Ports, מזינים 80.

    9. לוחצים על יצירה.

gcloud

  1. צרו בדיקת תקינות לתיקון תוכנה אוטומטי (autohealing) שהיא שמרנית יותר מבדיקת תקינות של איזון עומסים.

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

    gcloud compute health-checks create http example-check --port 80 \
   --check-interval 30s \
   --healthy-threshold 1 \
   --timeout 10s \
   --unhealthy-threshold 3 \
   --global

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

    הבדיקות של בדיקת התקינות מגיעות מכתובות בטווחים 130.211.0.0/22 ו-35.191.0.0/16, לכן חשוב לוודא שכללי חומת האש מאפשרים לבדיקת התקינות להתחבר. בדוגמה הזו, ה-MIG משתמש ברשת default, והמכונות הווירטואליות שלה מאזינות ליציאה 80. אם יציאה 80 לא פתוחה כבר ברשת ברירת המחדל, יוצרים כלל של חומת אש.

    gcloud compute firewall-rules create allow-health-check \
    --allow tcp:80 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default

Terraform

  1. יוצרים בדיקת תקינות באמצעות המשאב google_compute_http_health_check.

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

    resource "google_compute_http_health_check" "default" {
  name                = "example-check"
  timeout_sec         = 10
  check_interval_sec  = 30
  healthy_threshold   = 1
  unhealthy_threshold = 3
  port                = 80
}

  2. יוצרים חומת אש באמצעות המשאב google_compute_firewall.

    בדיקות התקינות מגיעות מכתובות בטווחים 130.211.0.0/22 ו-35.191.0.0/16, לכן חשוב לוודא שהכללים של חומת האש מאפשרים לבדיקת התקינות להתחבר. בדוגמה הזו, קבוצת ה-MIG משתמשת ברשת default והמכונות הווירטואליות שלה מאזינות ליציאה 80. אם יציאה 80 לא פתוחה ברשת ברירת המחדל, יוצרים כלל חומת אש.

    resource "google_compute_firewall" "default" {
  name          = "allow-health-check"
  network       = "default"
  source_ranges = ["130.211.0.0/22", "35.191.0.0/16"]
  allow {
    protocol = "tcp"
    ports    = [80]
  }
}

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

REST

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

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

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks

{
 "name": "example-check",
 "type": "http",
 "port": 80,
 "checkIntervalSec": 30,
 "healthyThreshold": 1,
 "timeoutSec": 10,
 "unhealthyThreshold": 3
}

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

    הבדיקות של בדיקת התקינות מגיעות מכתובות בטווחים 130.211.0.0/22 ו-35.191.0.0/16, לכן חשוב לוודא שהכללים של חומת האש מאפשרים לבדיקת התקינות להתחבר. בדוגמה הזו, קבוצת ה-MIG משתמשת ברשת default והמכונות הווירטואליות שלה מאזינות ליציאה 80. אם יציאה 80 לא פתוחה ברשת ברירת המחדל, יוצרים כלל חומת אש.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "allow-health-check",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default",
 "sourceRanges": [
  "130.211.0.0/22",
  "35.191.0.0/16"
 ],
 "allowed": [
  {
   "ports": [
    "80"
   ],
   "IPProtocol": "tcp"
  }
 ]
}

    מחליפים את PROJECT_ID במזהה הפרויקט.

הגדרת מדיניות תיקון תוכנה אוטומטי (autohealing) בקבוצת MIG

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

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

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

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

המסוף

  1. נכנסים לדף Instance groups במסוף Google Cloud .

    כניסה לדף Instance groups

  2. בעמודה Name שברשימה, לוחצים על השם של קבוצת ה-MIG שרוצים להחיל עליה את בדיקת התקינות.

  3. לוחצים על Edit כדי לשנות את קבוצת ה-MIG.

  4. לוחצים על Instance lifecycle and autohealing כדי להרחיב את הקטע.

    1. בקטע Autohealing, בוחרים בדיקת תקינות גלובלית או אזורית בשדה Health check.
    2. בשדה Initial delay, משתמשים בערך ברירת המחדל או משנים אותו לפי הצורך.

      ההשהיה הראשונית היא מספר השניות שנדרשות למכונה וירטואלית חדשה כדי לאתחל ולהריץ את הסקריפט לטעינה בזמן ההפעלה. במהלך תקופת ההשהיה הראשונית של מכונה וירטואלית, קבוצת המכונות הווירטואליות המנוהלת מתעלמת מבדיקות תקינות שנכשלו, כי יכול להיות שהמכונה הווירטואלית נמצאת בתהליך הפעלה. כך מונעים מה-MIG ליצור מחדש מכונה וירטואלית לפני הזמן. אם בדיקת התקינות מקבלת תגובה תקינה במהלך ההשהיה הראשונית, סימן שתהליך ההפעלה הושלם והמכונה הווירטואלית מוכנה. טיימר ההשהיה הראשוני מתחיל כשהשדה currentAction של המכונה הווירטואלית משתנה ל-VERIFYING. הטיימר מפסיק כשהזמן שהוגדר מסתיים או כשבדיקת התקינות מצליחה. הערך של ההשהיה הראשונית צריך להיות בין 0 ל-3600 שניות. במסוף, ערך ברירת המחדל הוא 300 שניות.

  5. לוחצים על Save כדי לעדכן את השינויים.

gcloud

כדי להגדיר מדיניות תיקון תוכנה אוטומטי בקבוצת MIG קיימת, משתמשים בפקודה update. לדוגמה, כדי להגדיר מדיניות תיקון תוכנה אוטומטי בקבוצת MIG אזורית קיימת, משתמשים בפקודה הבאה:

gcloud compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

כדי להגדיר מדיניות תיקון אוטומטי כשיוצרים קבוצת MIG, משתמשים בפקודה create. לדוגמה, אפשר להשתמש בפקודה הבאה כדי להגדיר מדיניות תיקון תוכנה אוטומטי כשיוצרים קבוצת MIG אזורית:

gcloud compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

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

  • ‫MIG_NAME: שם ה-MIG שבו רוצים להגדיר תיקון תוכנה אוטומטי.
  • ‫SIZE: מספר המכונות הווירטואליות בקבוצה.
  • ‫INSTANCE_TEMPLATE_URL: כתובת ה-URL של תבנית של הגדרות מכונה שבה רוצים להשתמש כדי ליצור מכונות ב-MIG. כתובת ה-URL יכולה להכיל את המזהה או את השם של תבנית של הגדרות מכונה. מציינים אחד מהערכים הבאים:
    • לתבנית של הגדרות מכונה אזורית: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • לתבנית גלובלית של הגדרות מכונה: INSTANCE_TEMPLATE_ID
  • ‫HEALTH_CHECK_URL: כתובת ה-URL החלקית של בדיקת התקינות שרוצים להגדיר לתיקון אוטומטי. לדוגמה:
    • בדיקת תקינות אזורית: projects/example-project/regions/us-central1/healthChecks/example-health-check.
    • בדיקת תקינות גלובלית: projects/example-project/global/healthChecks/example-health-check.
  • INITIAL_DELAY: מספר השניות שלוקח למכונה וירטואלית חדשה לאתחל ולהריץ את הסקריפט לטעינה בזמן ההפעלה. במהלך תקופת ההשהיה הראשונית של מכונה וירטואלית, קבוצת המכונות הווירטואליות המנוהלת מתעלמת מבדיקות תקינות שנכשלו, כי יכול להיות שהמכונה הווירטואלית נמצאת בתהליך הפעלה. כך מונעים מה-MIG ליצור מחדש מכונה וירטואלית לפני הזמן. אם בדיקת התקינות מקבלת תגובה תקינה במהלך ההשהיה הראשונית, סימן שתהליך ההפעלה הושלם והמכונה הווירטואלית מוכנה. טיימר ההשהיה הראשוני מתחיל כשהשדה currentAction של המכונה הווירטואלית משתנה ל-VERIFYING. הטיימר מפסיק כשהזמן שהוגדר מסתיים או כשבדיקת התקינות מצליחה. הערך של ההשהיה הראשונית צריך להיות בין 0 ל-3600 שניות. ערך ברירת המחדל הוא 0.
  • ‫ZONE: האזור שבו נמצאת קבוצת ה-MIG. בשביל קבוצת MIG אזורית, משתמשים בדגל --region.

Terraform

כדי להגדיר מדיניות של תיקון תוכנה אוטומטי ב-MIG, משתמשים בבלוק auto_healing_policies.

בדוגמה הבאה מוגדרת מדיניות תיקון תוכנה אוטומטי (autohealing) בקבוצת MIG אזורית. למידע נוסף על המשאב שמופיע בדוגמה, קראו את המאמר google_compute_instance_group_manager. לקבוצת MIG אזורית, משתמשים במשאב google_compute_region_instance_group_manager.

resource "google_compute_instance_group_manager" "default" {
  name               = "igm-with-hc"
  base_instance_name = "test"
  target_size        = 3
  zone               = "us-central1-f"
  version {
    instance_template = google_compute_instance_template.default.id
    name              = "primary"
  }
  auto_healing_policies {
    health_check      = google_compute_http_health_check.default.id
    initial_delay_sec = 30
  }
}

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

REST

כדי להגדיר מדיניות תיקון אוטומטי בקבוצת MIG קיימת, משתמשים ב-method ‏patch באופן הבא:

לדוגמה, כדי להגדיר תיקון תוכנה אוטומטי בקבוצת MIG אזורית קיימת, מבצעים את הקריאה הבאה:

  PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME
  {
    "autoHealingPolicies": [
      {
        "healthCheck": "HEALTH_CHECK_URL",
        "initialDelaySec": INITIAL_DELAY
      }
    ]
  }

כדי להגדיר מדיניות תיקון אוטומטי כשיוצרים MIG, משתמשים ב-method ‏insert באופן הבא:

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

  POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers
  {
    "name": "MIG_NAME",
    "targetSize": SIZE,
    "instanceTemplate": "INSTANCE_TEMPLATE_URL",
    "autoHealingPolicies": [
      {
        "healthCheck": "HEALTH_CHECK_URL",
        "initialDelaySec": INITIAL_DELAY
      }
    ]
  }

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

  • ‫PROJECT_ID: מזהה הפרויקט.
  • ‫MIG_NAME: שם ה-MIG שבו רוצים להגדיר תיקון תוכנה אוטומטי.
  • ‫SIZE: מספר המכונות הווירטואליות בקבוצה.
  • ‫INSTANCE_TEMPLATE_URL: כתובת ה-URL של תבנית של הגדרות מכונה שבה רוצים להשתמש כדי ליצור מכונות ב-MIG. כתובת ה-URL יכולה להכיל את המזהה או את השם של תבנית של הגדרות מכונה. מציינים אחד מהערכים הבאים:
    • לתבנית של הגדרות מכונה אזורית: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • לתבנית גלובלית של הגדרות מכונה: INSTANCE_TEMPLATE_ID
  • ‫HEALTH_CHECK_URL: כתובת ה-URL החלקית של בדיקת התקינות שרוצים להגדיר לתיקון אוטומטי. לדוגמה:
    • בדיקת תקינות אזורית: projects/example-project/regions/us-central1/healthChecks/example-health-check.
    • בדיקת תקינות גלובלית: projects/example-project/global/healthChecks/example-health-check.
  • INITIAL_DELAY: מספר השניות שלוקח למכונה וירטואלית חדשה לאתחל ולהריץ את הסקריפט לטעינה בזמן ההפעלה. במהלך תקופת ההשהיה הראשונית של מכונה וירטואלית, קבוצת המכונות הווירטואליות המנוהלת מתעלמת מבדיקות תקינות שנכשלו, כי יכול להיות שהמכונה הווירטואלית נמצאת בתהליך הפעלה. כך מונעים מה-MIG ליצור מחדש מכונה וירטואלית לפני הזמן. אם בדיקת התקינות מקבלת תגובה תקינה במהלך ההשהיה הראשונית, סימן שתהליך ההפעלה הושלם והמכונה הווירטואלית מוכנה. טיימר ההשהיה הראשוני מתחיל כשהשדה currentAction של המכונה הווירטואלית משתנה ל-VERIFYING. הטיימר מפסיק כשהזמן שהוגדר מסתיים או כשבדיקת התקינות מצליחה. הערך של ההשהיה הראשונית צריך להיות בין 0 ל-3600 שניות. ערך ברירת המחדל הוא 0.
  • ‫ZONE: האזור שבו נמצאת קבוצת ה-MIG. לקבוצת MIG אזורית, משתמשים ב-regions/REGION בכתובת ה-URL.

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

  • השהיה של 10 דקות לפני שתיקון התוכנה האוטומטי (autohealing) מתחיל לעקוב אחרי המכונות הווירטואליות בקבוצה
  • + 5 דקות להשהיה הראשונית שהוגדרה
  • + דקה אחת למרווח הזמן של הבדיקה * סף התקינות (60 שניות * 1)
  • = 16 דקות לפני שהמכונה הווירטואלית מסומנת כתקינה או נוצרת מחדש

הגדרת בדיקת תקינות ללא תיקון תוכנה אוטומטי (autohealing)

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

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

המסוף

  1. נכנסים לדף Instance groups במסוף Google Cloud .

    כניסה לדף Instance groups

  2. בעמודה Name שברשימה, לוחצים על השם של קבוצת ה-MIG שרוצים להחיל עליה את בדיקת התקינות.

  3. לוחצים על Edit כדי לשנות את קבוצת ה-MIG.

  4. לוחצים על Instance lifecycle and autohealing כדי להרחיב את הקטע.

    1. בקטע Autohealing, בוחרים בדיקת תקינות גלובלית או אזורית בשדה Health check.
    2. בשדה Initial delay, משתמשים בערך ברירת המחדל או משנים אותו לפי הצורך.

      ההשהיה הראשונית היא מספר השניות שנדרשות למכונה וירטואלית חדשה כדי לאתחל ולהריץ את הסקריפט לטעינה בזמן ההפעלה. במהלך תקופת ההשהיה הראשונית של מכונה וירטואלית, קבוצת המכונות הווירטואליות המנוהלת מתעלמת מבדיקות תקינות שנכשלו, כי יכול להיות שהמכונה הווירטואלית נמצאת בתהליך הפעלה. כך מונעים מה-MIG ליצור מחדש מכונה וירטואלית לפני הזמן. אם בדיקת התקינות מקבלת תגובה תקינה במהלך ההשהיה הראשונית, סימן שתהליך ההפעלה הושלם והמכונה הווירטואלית מוכנה. טיימר ההשהיה הראשוני מתחיל כשהשדה currentAction של המכונה הווירטואלית משתנה ל-VERIFYING. הטיימר מפסיק כשהזמן שהוגדר מסתיים או כשבדיקת התקינות מצליחה. הערך של ההשהיה הראשונית צריך להיות בין 0 ל-3600 שניות. במסוף, ערך ברירת המחדל הוא 300 שניות.

    1. ברשימה On failed health check, בוחרים באפשרות No action.

  5. לוחצים על Save כדי לעדכן את השינויים.

gcloud

כדי להגדיר בדיקת תקינות בלי תיקון תוכנה אוטומטי, כשמציינים את הגדרת בדיקת התקינות צריך גם להגדיר את הדגל --action-on-vm-failed-health-check לערך do-nothing, באופן הבא:

  • בקבוצת מכונות מנוהלת קיימת, משתמשים בפקודה update.

    לדוגמה, משתמשים בפקודה הבאה בקבוצת MIG קיימת ברמת האזור:

    gcloud compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --action-on-vm-failed-health-check do-nothing \
    --zone ZONE

  • כשיוצרים קבוצת MIG, משתמשים בפקודה create.

    לדוגמה, משתמשים בפקודה הבאה כשיוצרים קבוצת MIG אזורית:

    gcloud compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --action-on-vm-failed-health-check do-nothing \
    --zone ZONE

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

  • ‫MIG_NAME: שם ה-MIG שבו רוצים להגדיר תיקון תוכנה אוטומטי.
  • ‫SIZE: מספר המכונות הווירטואליות בקבוצה.
  • ‫INSTANCE_TEMPLATE_URL: כתובת ה-URL של תבנית של הגדרות מכונה שבה רוצים להשתמש כדי ליצור מכונות ב-MIG. כתובת ה-URL יכולה להכיל את המזהה או את השם של תבנית של הגדרות מכונה. מציינים אחד מהערכים הבאים:
    • לתבנית של הגדרות מכונה אזורית: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • לתבנית גלובלית של הגדרות מכונה: INSTANCE_TEMPLATE_ID
  • ‫HEALTH_CHECK_URL: כתובת ה-URL החלקית של בדיקת התקינות שרוצים להגדיר לתיקון אוטומטי. לדוגמה:
    • בדיקת תקינות אזורית: projects/example-project/regions/us-central1/healthChecks/example-health-check.
    • בדיקת תקינות גלובלית: projects/example-project/global/healthChecks/example-health-check.
  • INITIAL_DELAY: מספר השניות שלוקח למכונה וירטואלית חדשה לאתחל ולהריץ את הסקריפט לטעינה בזמן ההפעלה. במהלך תקופת ההשהיה הראשונית של מכונה וירטואלית, קבוצת המכונות הווירטואליות המנוהלת מתעלמת מבדיקות תקינות שנכשלו, כי יכול להיות שהמכונה הווירטואלית נמצאת בתהליך הפעלה. כך מונעים מה-MIG ליצור מחדש מכונה וירטואלית לפני הזמן. אם בדיקת התקינות מקבלת תגובה תקינה במהלך ההשהיה הראשונית, סימן שתהליך ההפעלה הושלם והמכונה הווירטואלית מוכנה. טיימר ההשהיה הראשוני מתחיל כשהשדה currentAction של המכונה הווירטואלית משתנה ל-VERIFYING. הטיימר מפסיק כשהזמן שהוגדר מסתיים או כשבדיקת התקינות מצליחה. הערך של ההשהיה הראשונית צריך להיות בין 0 ל-3600 שניות. ערך ברירת המחדל הוא 0.
  • ‫ZONE: האזור שבו נמצאת קבוצת ה-MIG. בשביל קבוצת MIG אזורית, משתמשים בדגל --region.

REST

כדי להגדיר בדיקת תקינות בלי תיקון תוכנה אוטומטי, כשמציינים את הגדרת בדיקת התקינות צריך גם להגדיר את השדה onFailedHealthCheck לערך DO_NOTHING, באופן הבא:

  • בקבוצת MIG קיימת, משתמשים ב-method‏ patch באופן הבא:

    לדוגמה, אפשר לבצע את הקריאה הבאה בקבוצת MIG אזורית קיימת:

    PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME
{
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
  "instanceLifecyclePolicy": {
    "onFailedHealthCheck": "DO_NOTHING"
  }
}

  • כשיוצרים MIG, משתמשים ב-method‏ insert באופן הבא:

    לדוגמה, מבצעים את הקריאה הבאה כשיוצרים קבוצת MIG אזורית:

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers
{
  "name": "MIG_NAME",
  "targetSize": SIZE,
  "instanceTemplate": "INSTANCE_TEMPLATE_URL",
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
  "instanceLifecyclePolicy": {
    "onFailedHealthCheck": "DO_NOTHING"
  }
}

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

  • ‫PROJECT_ID: מזהה הפרויקט.
  • ‫MIG_NAME: שם ה-MIG שבו רוצים להגדיר תיקון תוכנה אוטומטי.
  • ‫SIZE: מספר המכונות הווירטואליות בקבוצה.
  • ‫INSTANCE_TEMPLATE_URL: כתובת ה-URL של תבנית של הגדרות מכונה שבה רוצים להשתמש כדי ליצור מכונות ב-MIG. כתובת ה-URL יכולה להכיל את המזהה או את השם של תבנית של הגדרות מכונה. מציינים אחד מהערכים הבאים:
    • לתבנית של הגדרות מכונה אזורית: projects/PROJECT_ID/regions/REGION/instanceTemplates/INSTANCE_TEMPLATE_ID
    • לתבנית גלובלית של הגדרות מכונה: INSTANCE_TEMPLATE_ID
  • ‫HEALTH_CHECK_URL: כתובת ה-URL החלקית של בדיקת התקינות שרוצים להגדיר לתיקון אוטומטי. לדוגמה:
    • בדיקת תקינות אזורית: projects/example-project/regions/us-central1/healthChecks/example-health-check.
    • בדיקת תקינות גלובלית: projects/example-project/global/healthChecks/example-health-check.
  • INITIAL_DELAY: מספר השניות שלוקח למכונה וירטואלית חדשה לאתחל ולהריץ את הסקריפט לטעינה בזמן ההפעלה. במהלך תקופת ההשהיה הראשונית של מכונה וירטואלית, קבוצת המכונות הווירטואליות המנוהלת מתעלמת מבדיקות תקינות שנכשלו, כי יכול להיות שהמכונה הווירטואלית נמצאת בתהליך הפעלה. כך מונעים מה-MIG ליצור מחדש מכונה וירטואלית לפני הזמן. אם בדיקת התקינות מקבלת תגובה תקינה במהלך ההשהיה הראשונית, סימן שתהליך ההפעלה הושלם והמכונה הווירטואלית מוכנה. טיימר ההשהיה הראשוני מתחיל כשהשדה currentAction של המכונה הווירטואלית משתנה ל-VERIFYING. הטיימר מפסיק כשהזמן שהוגדר מסתיים או כשבדיקת התקינות מצליחה. הערך של ההשהיה הראשונית צריך להיות בין 0 ל-3600 שניות. ערך ברירת המחדל הוא 0.
  • ‫ZONE: האזור שבו נמצאת קבוצת ה-MIG. לקבוצת MIG אזורית, משתמשים ב-regions/REGION בכתובת ה-URL.

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

הסרת בדיקת תקינות

כדי להסיר בדיקת תקינות שהוגדרה במדיניות תיקון תוכנה אוטומטי:

המסוף

  1. נכנסים לדף Instance groups במסוף Google Cloud .

    כניסה לדף Instance groups

  2. לוחצים על השם של קבוצת ה-MIG שרוצים להסיר ממנה את בדיקת התקינות.

  3. לוחצים על Edit כדי לשנות את קבוצת ה-MIG.

  4. לוחצים על Instance lifecycle and autohealing כדי להרחיב את הקטע.

  5. בקטע Autohealing, בוחרים באפשרות No health check בשדה Health check.

  6. לוחצים על שמירה כדי להחיל את השינויים.

gcloud

כדי להסיר את ההגדרה של בדיקת התקינות במדיניות של תיקון תוכנה אוטומטי, משתמשים בדגל --clear-autohealing בפקודה update באופן הבא:

gcloud compute instance-groups managed update MIG_NAME \
    --clear-autohealing

מחליפים את MIG_NAME בשם של קבוצת MIG.

REST

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

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

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
    {}
  ]
}

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

  • ‫PROJECT_ID: מזהה הפרויקט.
  • ‫MIG_NAME: שם ה-MIG שבו רוצים להגדיר תיקון תוכנה אוטומטי.
  • ‫ZONE: האזור שבו נמצאת קבוצת ה-MIG. לקבוצת MIG אזורית, משתמשים ב-regions/REGION.

הצגת מדיניות התיקון האוטומטי בקבוצת MIG

כדי לראות את מדיניות התיקון האוטומטי של קבוצת MIG:

המסוף

  1. נכנסים לדף Instance groups במסוף Google Cloud .

    כניסה לדף Instance groups

  2. לוחצים על השם של קבוצת ה-MIG שרוצים לראות את מדיניות התיקון האוטומטי שלה.

  3. עוברים לכרטיסייה פרטים.

    בקטע VM instance lifecycle מוצגות בדיקת התקינות וההשהיה הראשונית שהוגדרו במדיניות התיקון האוטומטי.

gcloud

כדי לראות את מדיניות התיקון האוטומטי ב-MIG, משתמשים בפקודה הבאה:

gcloud compute instance-groups managed describe MIG_NAME \
    --format="(autoHealingPolicies)"

מחליפים את MIG_NAME בשם של קבוצת MIG.

הפלט לדוגמה: 

autoHealingPolicies:
  healthCheck: https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check
  initialDelaySec: 300

REST

כדי לראות את מדיניות התיקון האוטומטי בקבוצת MIG, משתמשים בשיטות REST באופן הבא:

לדוגמה, כדי לראות את מדיניות התיקון האוטומטי בקבוצת MIG אזורית, שולחים את הבקשה הבאה:

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

בגוף התשובה, מחפשים את האובייקט autoHealingPolicies[].

זוהי דוגמה לתשובה:

{
  ...
  "autoHealingPolicies": [
    {
      "healthCheck": "https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check",
      "initialDelaySec": 300
    }
  ],
  ...
}

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

  • ‫PROJECT_ID: מזהה הפרויקט.
  • ‫MIG_NAME: שם ה-MIG שבו רוצים להגדיר תיקון תוכנה אוטומטי.
  • ‫ZONE: האזור שבו נמצאת קבוצת ה-MIG. לקבוצת MIG אזורית, משתמשים ב-regions/REGION.

בדיקת הסטטוס

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

בדיקה אם המכונות הווירטואליות תקינות

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

כדאי לבדוק את מצבי התקינות של המכונות המנוהלות כדי:

  • זיהוי מכונות וירטואליות לא תקינות שלא מתוקנות. יכול להיות שהמכונה הווירטואלית לא תתוקן באופן מיידי גם אם היא אובחנה כלא תקינה במצבים הבאים:
    • המכונה הווירטואלית עדיין מופעלת, וההשהיה הראשונית שלה לא חלפה.
    • חלק משמעותי מהמכונות הלא תקינות נמצאות בתיקון. קבוצת ה-MIG מעכבת את תיקון התוכנה האוטומטי כדי לוודא שהקבוצה ממשיכה להריץ קבוצת משנה של מכונות.
  • זיהוי שגיאות בהגדרות של בדיקת התקינות. לדוגמה, אם המכונה מדווחת על מצב תקינות של TIMEOUT, אפשר לזהות כללים של חומת אש שהוגדרו באופן שגוי או נקודת קצה לא תקינה לבדיקת תקינות של אפליקציה.
  • כדי לקבוע את ערך ההשהיה הראשונית שצריך להגדיר, מודדים את משך הזמן בין המעבר של ה-VM לRUNNING status לבין המעבר של ה-VM למצב תקינות HEALTHY. כדי למדוד את הפער הזה, אפשר לדגום את השיטה list-instances או לבדוק את הזמן בין הפעולה instances.insert לבין האות התקין הראשון שמתקבל.

כדי לראות את מצבי התקינות, אפשר להשתמש במסוף, בכלי שורת הפקודה gcloud או ב-REST.

המסוף

  1. נכנסים לדף Instance groups במסוף Google Cloud .

    נכנסים לדף Instance groups.

  2. בעמודה Name של הרשימה, לוחצים על השם של קבוצת ה-MIG שרוצים לבדוק. ייפתח דף עם המאפיינים של קבוצת המכונות ורשימה של המכונות הווירטואליות שכלולות בקבוצה.

  3. אם המכונה הווירטואלית לא תקינה, אפשר לראות את מצב התקינות שלה בעמודה Health check status.

gcloud

משתמשים בפקודת המשנה list-instances.

gcloud compute instance-groups managed list-instances MIG_NAME
    --zone ZONE

הפלט של הפקודה אמור להיראות כך: בשדה HEALTH_STATE מוצג מצב התקינות של כל מכונה וירטואלית.

NAME: igm-with-hc-fvz6
ZONE: europe-west1-b
STATUS: RUNNING
HEALTH_STATE: HEALTHY
ACTION: NONE
INSTANCE_TEMPLATE: my-template
VERSION_NAME:
LAST_ERROR:

NAME: igm-with-hc-gtz3
ZONE: europe-west1-b
STATUS: RUNNING
HEALTH_STATE: HEALTHY
ACTION: NONE
INSTANCE_TEMPLATE: my-template
VERSION_NAME:
LAST_ERROR:

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

  • ‫MIG_NAME: שם ה-MIG.
  • ‫ZONE: האזור שבו נמצאת קבוצת ה-MIG. לקבוצת MIG אזורית, משתמשים ב---region REGION.

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

REST

כדי ליצור קבוצת MIG אזורית, שולחים בקשת POST ל-method‏ listManagedInstances:

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/MIG_NAME/listManagedInstances

כדי ליצור קבוצת MIG אזורית, משתמשים ב-method‏ listManagedInstances:

POST https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/MIG_NAME/listManagedInstances

בתגובה לבקשה מוחזרת תשובה שדומה לדוגמה הבאה, שכוללת את השדה instanceHealth לכל מכונה מנוהלת.

{
  "managedInstances": [
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/sproject-id/zones/zone/instances/igm-with-hc-fvz6",
      "instanceStatus": "RUNNING",
      "currentAction": "NONE",
      "id": "6159431761228150698",
      "version": {
        "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/my-template"
      },
      "instanceHealth": [
        {
          "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/example-check-01",
          "detailedHealthState": "HEALTHY"
        }
      ],
      "name": "igm-with-hc-fvz6"
    },
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/igm-with-hc-gtz3",
      "instanceStatus": "RUNNING",
      "currentAction": "NONE",
      "id": "6622324799312181783",
      "version": {
        "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/my-template"
      },
      "instanceHealth": [
        {
          "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/example-check-01",
          "detailedHealthState": "HEALTHY"
        }
      ],
      "name": "igm-with-hc-gtz3"
    }
  ]
}

מצבי תקינות

אלה מצבי התקינות של ה-VM:

  • ‫HEALTHY: אפשר להגיע למכונה הווירטואלית, ליצור חיבור לנקודת הקצה של בדיקת התקינות של האפליקציה, והתגובה תואמת לדרישות שהוגדרו בבדיקת התקינות.
  • ‫DRAINING: המכונה הווירטואלית מרוקנת. חיבורים קיימים למכונה הווירטואלית יכולים להסתיים, אבל חיבורים חדשים נדחים.
  • ‫UNHEALTHY: אפשר להגיע למכונה הווירטואלית, אבל היא לא עומדת בדרישות שהוגדרו בבדיקת התקינות.
  • ‫TIMEOUT: אי אפשר להגיע למכונה הווירטואלית, אי אפשר להתחבר לנקודת הקצה של בדיקת התקינות של האפליקציה, או שהשרת במכונה הווירטואלית לא מגיב במסגרת הזמן הקצוב שצוין. לדוגמה, יכול להיות שהסיבה לכך היא הגדרה שגויה של כללי חומת האש או עומס יתר באפליקציית השרת במכונה הווירטואלית.
  • ‫UNKNOWN: מערכת בדיקת התקינות לא מודעת למכונה הווירטואלית, או שהתקינות שלה לא ידועה כרגע. יכול להיות שיעברו 10 דקות עד שהמעקב יתחיל במכונות וירטואליות חדשות ב-MIG.

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

התיקון של מכונה וירטואלית תלוי במצב התקינות שלה:

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

יכול להיות עיכוב בניסיונות לתיקון תוכנה אוטומטי במקרים הבאים:

  • המכונה הווירטואלית נשארת לא תקינה אחרי כמה תיקונים רצופים.
  • חלק משמעותי מהמכונות הווירטואליות בקבוצה לא תקינות.

נשמח לשמוע על תרחישי השימוש שלכם, על האתגרים שנתקלתם בהם או על המשוב שלכם לגבי ערכי מצב התקינות של המכונות הווירטואליות. אתם יכולים לשלוח משוב לצוות שלנו בכתובת mig-discuss@google.com.

בדיקת הפעולות הנוכחיות במכונות וירטואליות

כשקבוצת MIG יוצרת מכונה וירטואלית, היא מגדירה את השדה currentAction של המכונה לקריאה בלבד כ-CREATING. אם לקבוצה מצורפת מדיניות תיקון אוטומטי, אחרי שהמכונה הווירטואלית נוצרת ופועלת, קבוצת המכונות המנוהלות מגדירה את הפעולה הנוכחית של המכונה כ-VERIFYING ובודק התקינות מתחיל לבדוק את האפליקציה של המכונה הווירטואלית. אם האפליקציה עוברת את בדיקת התקינות הראשונית הזו בזמן שלוקח לה להתחיל, המכונה הווירטואלית מאומתת וה-MIG משנה את השדה currentAction של המכונה הווירטואלית ל-NONE.

כדי לבדוק את הפעולות הנוכחיות במכונות וירטואליות, קראו את המאמר הצגת הפעולות הנוכחיות במכונות וירטואליות.

בדיקה אם ה-MIG יציב

ברמת הקבוצה, Compute Engine מאכלס שדה לקריאה בלבד שנקרא status ומכיל דגל isStable.

אם כל המכונות הווירטואליות בקבוצה פועלות ותקינות (כלומר, השדה currentAction של כל מכונה מנוהלת מוגדר כ-NONE), קבוצת ה-MIG מגדירה את השדה status.isStable כ-true. חשוב לזכור שהיציבות של MIG תלויה בהגדרות הקבוצה, ולא רק במדיניות תיקון התוכנה האוטומטי (autohealing); לדוגמה, אם הקבוצה מוגדרת להתאמה אוטומטית לעומס (autoscale), והגודל שלה משתנה, ה-MIG מגדיר את השדה status.isStable לערך false בגלל פעולת המידרוג האוטומטי.

כדי לבדוק את הערכים של השדה status.isStable של ה-MIG, קראו את המאמר בדיקה אם ה-MIG יציב.

הצגת פעולות היסטוריות של תיקון תוכנה אוטומטי (autohealing)

אפשר להשתמש ב-CLI של gcloud או ב-REST כדי לראות אירועים קודמים של תיקון תוכנה אוטומטי.

gcloud

משתמשים בפקודה gcloud compute operations list עם מסנן כדי לראות רק את אירועי התיקון האוטומטי בפרויקט.

gcloud compute operations list --filter='operationType~compute.instances.repair.*'

כדי לקבל מידע נוסף על פעולת תיקון ספציפית, משתמשים בפקודה describe. לדוגמה:

gcloud compute operations describe repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5 --zone us-east1-b

REST

בקבוצות MIG אזוריות, שולחים בקשת GET למשאב regionOperations וכוללים מסנן כדי לצמצם את רשימת הפלט לאירועי compute.instances.repair.*.

GET https://compute.googleapis.com/compute/v1/projects/project-id/region/region/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

בקבוצות MIG אזוריות, משתמשים במשאב zoneOperations.

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

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

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5

מה הופך בדיקת תקינות של תיקון תוכנה אוטומטי לטובה

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

  • unhealthy-threshold. צריך להיות יותר מ-1. מומלץ להגדיר ערך של 3 או יותר. כך אפשר למנוע כשלים נדירים כמו אובדן מנות ברשת.
  • healthy-threshold. ערך של 2 מספיק לרוב האפליקציות.
  • ‫timeout. הגדירו ערך זמן נדיב (פי חמישה או יותר מזמן התגובה הצפוי). זמן הקצוב לתפוגה חייב להיות קטן או שווה ל-check-interval. כך אפשר למנוע עיכובים לא צפויים, כמו מכונות וירטואליות עמוסות או חיבור איטי לרשת.
  • ‫check-interval. הערך הזה צריך להיות בין שנייה אחת לבין פי שניים מהזמן הקצוב לתפוגה (לא ארוך מדי ולא קצר מדי). כשהערך ארוך מדי, מופע שנכשל לא מזוהה מספיק מהר. אם הערך קצר מדי, המכונות והרשת עלולות להיות עמוסות מאוד, בגלל המספר הגבוה של בדיקות תקינות שנשלחות בכל שנייה.

סיבות אפשריות לעיכובים בתיקון תוכנה אוטומטי (autohealing)

כדי לשמור על היציבות של ה-MIG במהלך תיקון התוכנה האוטומטי, Compute Engine מחיל את המגבלות הבאות. בגלל המגבלות האלה, יכול להיות שיהיו עיכובים בתיקון התוכנה האוטומטי.

  • מספר מקסימלי של תיקונים בו-זמנית: כשמכונות וירטואליות בקבוצת MIG נכשלות בבדיקות תקינות, קבוצת ה-MIG מנסה לתקן באופן אוטומטי עד 30% מהמכונות בכל אזור (מעוגל כלפי מעלה) בכל זמן נתון. לדוגמה, אם בקבוצת MIG אזורית יש 10 מכונות וירטואליות ו-4 מהן נכשלות בבדיקות התקינות, קבוצת ה-MIG תנסה לתקן לכל היותר 3 מכונות וירטואליות (30% מתוך 10 מכונות וירטואליות). אם מדובר בקבוצת MIG אזורית, היא תנסה לתקן עד 30% מהמכונות בכל אזור שבו המכונות הווירטואליות נכשלו. לדוגמה, אם יש לכם 3 מכונות באזור מסוים, קבוצת ה-MIG יכולה לתקן לכל היותר מכונה אחת באותו אזור.

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

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