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

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

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

בדוגמה הזו, מגדירים את הפריסה שמוצגת בתרשים הבא.

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

הפעולה הזו יוצרת מאזן עומסי רשת פנימי בשרתי Proxy בין אזורים ברשת VPC, עם שירות לקצה העורפי אחד ושתי קבוצות מופעי מכונה מנוהלים (MIG) בקצה העורפי באזורים REGION_A ו-REGION_B.

מאזני עומסים פנימיים בשרת proxy שפועלים בכמה אזורים דורשים את המשאבים הבאים:

  1. רשת VPC עם רשתות המשנה הבאות:

    • תת-רשת SUBNET_A ותת-רשת של שרת proxy בלבד ב-REGION_A.
    • תת-רשת SUBNET_B ותת-רשת של שרת proxy בלבד ב-REGION_B.

    צריך ליצור רשתות משנה מסוג proxy-only בכל אזור של רשת VPC שבה משתמשים במאזני עומסים פנימיים ברשת חוצי-אזורים מסוג proxy. תת-הרשת של ה-proxy בלבד באזור משותפת לכל מאזני העומסים הפנימיים של הרשת לשרת proxy באזור. כתובות המקור של מנות שנשלחות ממאזן העומסים לקצה העורפי של השירות מוקצות מרשת המשנה של ה-proxy בלבד. בדוגמה הזו, לתת-הרשת של שרת proxy בלבד באזור REGION_B יש טווח כתובות IP ראשי של 10.129.0.0/23, ולתת-הרשת באזור REGION_A יש טווח כתובות IP ראשי של 10.130.0.0/23, שהוא הגודל המומלץ של תת-הרשת.

  2. הגדרת זמינות גבוהה כוללת קצוות עורפיים של קבוצות מופעי מכונה מנוהלים לפריסות של מכונות וירטואליות ב-Compute Engine באזורים REGION_A ו-REGION_B. אם השרתים העורפיים באזור מסוים מושבתים, התעבורה מועברת לאזור אחר.

  3. שירות לקצה עורפי גלובלי שעוקב אחרי השימוש בקצה העורפי והתקינות שלו.

  4. שרת proxy של TCP ביעד גלובלי, שמקבל בקשה מהמשתמש ומעביר אותה לשירות הקצה העורפי.

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

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

    • כתובת ה-IP יכולה להיות (אבל לא חייבת) מאותה תת-רשת כמו קבוצות שרתי העורף (backend instance).
    • כתובת ה-IP לא יכולה להיות מתת-רשת שמורה של שרת proxy בלבד, שמוגדרת עם הדגל --purpose GLOBAL_MANAGED_PROXY. אם תנסו להשתמש ברשת המשנה של ה-proxy בלבד, יצירת כלל ההעברה תיכשל.
    • אם רוצים להשתמש באותה כתובת IP פנימית עם כמה כללי העברה, צריך להגדיר את הדגל של כתובת ה-IP‏ --purpose לערך SHARED_LOADBALANCER_VIP.

הרשאות

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

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

מידע נוסף זמין במדריכים הבאים:

הגדרת הרשת ורשתות המשנה

ברשת ה-VPC, מגדירים רשת משנה בכל אזור שבו השרתים העורפיים מוגדרים. בנוסף, צריך להגדיר proxy-only-subnetבכל אזור שבו רוצים להגדיר את מאזן העומסים.

בדוגמה הזו נעשה שימוש ברשת ה-VPC, באזור ובתת-רשתות הבאים:

  • רשת. הרשת היא רשת VPC במצב מותאם אישית בשם NETWORK.

  • תת-רשתות לשרתי קצה עורפיים.

    • רשת משנה בשם SUBNET_A באזור REGION_A משתמשת ב-10.1.2.0/24 כטווח ה-IP הראשי שלה.
    • רשת משנה בשם SUBNET_B באזור REGION_B משתמשת ב-10.1.3.0/24 כטווח ה-IP הראשי שלה.
  • תת-רשתות לשרתי Proxy.

    • רשת משנה בשם PROXY_SN_A באזור REGION_A משתמשת ב-10.129.0.0/23 כטווח ה-IP הראשי שלה.
    • רשת משנה בשם PROXY_SN_B באזור REGION_B משתמשת ב-10.130.0.0/23 כטווח כתובות ה-IP הראשי שלה.

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

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

המסוף

  1. נכנסים לדף VPC networks במסוף Google Cloud .

    מעבר לרשתות VPC

  2. לוחצים על יצירת רשת VPC.

  3. מזינים שם לרשת.

  4. בקטע רשתות משנה, מגדירים את מצב יצירת רשתות משנה למותאם אישית.

  5. יוצרים רשת משנה לשרתי הבק-אנד של מאזן העומסים. בקטע New subnet (רשת משנה חדשה), מזינים את הפרטים הבאים:

    • מזינים שם לרשת המשנה.
    • בוחרים אזור: REGION_A
    • מזינים טווח כתובות IP: 10.1.2.0/24
  6. לוחצים על סיום.

  7. לוחצים על הוספת רשת משנה.

  8. יוצרים רשת משנה לשרתי הבק-אנד של מאזן העומסים. בקטע New subnet, מזינים את הפרטים הבאים:

    • מזינים שם לרשת המשנה.
    • בוחרים אזור: REGION_B
    • מזינים טווח כתובות IP: 10.1.3.0/24
  9. לוחצים על סיום.

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

gcloud

  1. יוצרים את רשת ה-VPC המותאמת אישית באמצעות הפקודה gcloud compute networks create:

    gcloud compute networks create NETWORK \
        --subnet-mode=custom
    
  2. יוצרים תת-רשת ברשת NETWORK באזור REGION_A באמצעות הפקודה gcloud compute networks subnets create:

    gcloud compute networks subnets create SUBNET_A \
        --network=NETWORK \
        --range=10.1.2.0/24 \
        --region=REGION_A
    
  3. יוצרים תת-רשת ברשת NETWORK באזור REGION_B באמצעות הפקודה gcloud compute networks subnets create:

    gcloud compute networks subnets create SUBNET_B \
        --network=NETWORK \
        --range=10.1.3.0/24 \
        --region=REGION_B
    

Terraform

כדי ליצור את רשת ה-VPC, משתמשים במשאב google_compute_network.

resource "google_compute_network" "default" {
  auto_create_subnetworks = false
  name                    = "lb-network-crs-reg"
  provider                = google-beta
}

כדי ליצור את תת-הרשתות של ה-VPC ברשת lb-network-crs-reg, משתמשים במשאב google_compute_subnetwork.

resource "google_compute_subnetwork" "subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.1.2.0/24"
  name          = "lbsubnet-uswest1"
  network       = google_compute_network.default.id
  region        = "us-west1"
}
resource "google_compute_subnetwork" "subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.1.3.0/24"
  name          = "lbsubnet-useast1"
  network       = google_compute_network.default.id
  region        = "us-east1"
}

API

שולחים בקשת POST אל ה-method‏ networks.insert. מחליפים את PROJECT_ID במזהה הפרויקט.

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

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

שולחים בקשת POST אל ה-method‏ subnetworks.insert. מחליפים את PROJECT_ID במזהה הפרויקט.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/lb-network-crs-reg",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

שולחים בקשת POST אל ה-method‏ subnetworks.insert. מחליפים את PROJECT_ID במזהה הפרויקט.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

הגדרת רשת המשנה ל-proxy בלבד

תת-רשת של פרוקסי בלבד מספקת קבוצה של כתובות IP ש- Google Cloud משתמש בהן כדי להפעיל פרוקסי של Envoy בשמכם. הפרוקסיים מסיימים חיבורים מהלקוח ויוצרים חיבורים חדשים לשרתי הקצה.

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

המסוף

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

כדי ליצור עכשיו את רשת המשנה של ה-proxy בלבד, פועלים לפי השלבים הבאים:

  1. נכנסים לדף VPC networks במסוף Google Cloud .

    מעבר לרשתות VPC

  2. לוחצים על השם של רשת ה-VPC.
  3. בכרטיסייה Subnet, לוחצים על Add subnet.
  4. מזינים שם לרשת המשנה של ה-proxy בלבד.
  5. בוחרים אזור: REGION_A
  6. ברשימה Purpose בוחרים באפשרות Cross-region Managed Proxy.
  7. בשדה טווח כתובות IP, מזינים 10.129.0.0/23.
  8. לוחצים על הוספה.

יצירת תת-רשת של שרת proxy בלבד ב-REGION_B

  1. בכרטיסייה Subnet, לוחצים על Add subnet.
  2. מזינים שם לרשת המשנה של ה-proxy בלבד.
  3. בוחרים אזור: REGION_B
  4. ברשימה Purpose בוחרים באפשרות Cross-region Managed Proxy.
  5. בשדה טווח כתובות IP, מזינים 10.130.0.0/23.
  6. לוחצים על הוספה.

gcloud

יוצרים את רשתות המשנה של ה-proxy בלבד באמצעות הפקודה gcloud compute networks subnets create.

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23
    
    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23
    

Terraform

כדי ליצור את תת-הרשת של ה-proxy בלבד ב-VPC ברשת lb-network-crs-reg, משתמשים במשאב google_compute_subnetwork.

resource "google_compute_subnetwork" "proxy_subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.129.0.0/23"
  name          = "proxy-only-subnet1"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-west1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}
resource "google_compute_subnetwork" "proxy_subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.130.0.0/23"
  name          = "proxy-only-subnet2"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-east1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}

API

יוצרים את רשתות המשנה של ה-proxy בלבד באמצעות השיטה subnetworks.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": " PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   
    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   

הגדרת כללים לחומת אש

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

  • fw-ilb-to-backends. כלל תעבורה נכנסת (ingress) שחל על המכונות שמתבצע עליהן איזון עומסים, שמאפשר קישוריות SSH נכנסת ביציאת TCP‏ 22 מכל כתובת. אפשר לבחור טווח מצומצם יותר של כתובות IP של המקור בשביל הכלל הזה. לדוגמה, אפשר לציין רק את טווחי כתובות ה-IP של המערכת שממנה מתחילים סשנים של SSH. בדוגמה הזו, תג היעד allow-ssh משמש לזיהוי המכונות הווירטואליות שכלל חומת האש חל עליהן.

  • fw-healthcheck. כלל כניסה (ingress) שחל על המופעים שמתבצע איזון העומסים שלהם, שמאפשר את כל תעבורת ה-TCP ממערכות בדיקת התקינות (ב-130.211.0.0/22 וב-35.191.0.0/16). בדוגמה הזו נעשה שימוש בתג היעד load-balanced-backend כדי לזהות את המכונות הווירטואליות שהכלל של חומת האש חל עליהן. Google Cloud

  • fw-backends. כלל תעבורת נתונים נכנסת (ingress) שחל על המכונות שעוברות איזון עומסים, שמאפשר תעבורת TCP ביציאות 80, 443 ו-8080 משרתי ה-proxy המנוהלים של מאזן העומסים הפנימי של הרשת לשרת proxy. בדוגמה הזו נעשה שימוש בתג היעד load-balanced-backend כדי לזהות את המכונות הווירטואליות שכלל חומת האש חל עליהן.

בלי כללי חומת האש האלה, הכלל default deny ingress חוסם תנועה נכנסת למופעי ה-Backend.

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

המסוף

  1. נכנסים לדף Firewall policies במסוף Google Cloud .

    לדף Firewall policies

  2. לוחצים על יצירת כלל חומת אש כדי ליצור את הכלל שיאפשר חיבורי SSH נכנסים:

    • Name (שם): fw-ilb-to-backends
    • רשת: NETWORK
    • כיוון התנועה: כניסה
    • פעולה במקרה של התאמה: אישור
    • יעדים: תגי יעד שצוינו
    • תגי טירגוט: allow-ssh
    • מסנן מקור: טווחים של כתובות IPv4
    • טווחי IPv4 של המקור: 0.0.0.0/0
    • פרוטוקולים ויציאות:
      • בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
      • מסמנים את תיבת הסימון TCP ומזינים 22 כמספר היציאה.
  3. לוחצים על יצירה.

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

    • Name (שם): fw-healthcheck
    • רשת: NETWORK
    • כיוון התנועה: כניסה
    • פעולה במקרה של התאמה: אישור
    • יעדים: תגי יעד שצוינו
    • תגי טירגוט: load-balanced-backend
    • מסנן מקור: טווחים של כתובות IPv4
    • טווחי IPv4 של המקור: 130.211.0.0/22 ו-35.191.0.0/16
    • פרוטוקולים ויציאות:

      • בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
      • מסמנים את תיבת הסימון TCP ומזינים 80 כמספר היציאה.

      מומלץ להגביל את הכלל הזה רק לפרוטוקולים ולפורטים שתואמים לאלה שמשמשים את בדיקת התקינות. אם משתמשים ב-tcp:80 לפרוטוקול וליציאה, Google Cloud יכול להשתמש ב-HTTP ביציאה 80 כדי ליצור קשר עם המכונות הווירטואליות, אבל הוא לא יכול להשתמש ב-HTTPS ביציאה 443 כדי ליצור איתן קשר.

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

  6. לוחצים על Create firewall rule (יצירת כלל חומת אש) בפעם השלישית כדי ליצור את הכלל שיאפשר לשרתי ה-Proxy של מאזן העומסים להתחבר לשרתי הקצה:

    • Name (שם): fw-backends
    • רשת: NETWORK
    • כיוון התנועה: כניסה
    • פעולה במקרה של התאמה: אישור
    • יעדים: תגי יעד שצוינו
    • תגי טירגוט: load-balanced-backend
    • מסנן מקור: טווחים של כתובות IPv4
    • טווחי IPv4 של המקור: 10.129.0.0/23 ו-10.130.0.0/23
    • פרוטוקולים ויציאות:
      • בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
      • מסמנים את תיבת הסימון TCP ומזינים את הערך 80, 443, 8080 עבור מספרי היציאות.
  7. לוחצים על יצירה.

gcloud

  1. יוצרים את כלל חומת האש fw-ilb-to-backends כדי לאפשר קישוריות SSH למכונות וירטואליות עם תג הרשת allow-ssh. אם לא מציינים את source-ranges, Google Cloud הכלל יפורש כאילו הוא מתייחס לכל מקור.

    gcloud compute firewall-rules create fw-ilb-to-backends \
        --network=NETWORK \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  2. יוצרים את הכלל fw-healthcheck כדי לאפשר Google Cloudבדיקות תקינות. בדוגמה הזו, כל תנועת ה-TCP מבודקי בדיקת תקינות מורשית, אבל אתם יכולים להגדיר קבוצה מצומצמת יותר של יציאות בהתאם לצרכים שלכם.

    gcloud compute firewall-rules create fw-healthcheck \
        --network=NETWORK \
        --action=allow \
        --direction=ingress \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --target-tags=load-balanced-backend \
        --rules=tcp
    
  3. יוצרים את כלל fw-backends כדי לאפשר לשרתי ה-proxy של מאזן עומסי הרשת הפנימי לשרת proxy להתחבר לשרתים העורפיים. מגדירים את source-ranges לטווחים שהוקצו לתת-הרשת של שרת ה-proxy בלבד, לדוגמה, 10.129.0.0/23 ו-10.130.0.0/23.

    gcloud compute firewall-rules create fw-backends \
        --network=NETWORK \
        --action=allow \
        --direction=ingress \
        --source-ranges=SOURCE_RANGE \
        --target-tags=load-balanced-backend \
        --rules=tcp:80,tcp:443,tcp:8080
    

API

יוצרים את כלל חומת האש fw-ilb-to-backends על ידי שליחת בקשת POST ל-method‏ firewalls.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.

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

{
 "name": "fw-ilb-to-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS"
}

יוצרים את כלל חומת האש fw-healthcheck על ידי שליחת בקשת POST ל-method‏ firewalls.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.

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

{
 "name": "fw-healthcheck",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "130.211.0.0/22",
   "35.191.0.0/16"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   }
 ],
 "direction": "INGRESS"
}

יוצרים את כלל חומת האש fw-backends כדי לאפשר תעבורת TCP בתת-הרשת של ה-proxy עבור השיטה firewalls.insert. מחליפים את PROJECT_ID במזהה הפרויקט.

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

{
 "name": "fw-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "10.129.0.0/23",
   "10.130.0.0/23"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "80"
     ]
   },
 {
     "IPProtocol": "tcp",
     "ports": [
       "443"
     ]
   },
   {
     "IPProtocol": "tcp",
     "ports": [
       "8080"
     ]
   }
 ],
 "direction": "INGRESS"
}

יצירת קבוצות של מופעי מכונה מנוהלים

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

המסוף

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

    כניסה לדף Instance templates

    1. לוחצים על Create instance template.
    2. בשדה Name (שם), מזינים gil4-backendeast1-template.
    3. מוודאים שדיסק האתחול מוגדר לקובץ אימג' של Debian, כמו Debian GNU/Linux 12 (bookworm)‎. בהוראות האלה נעשה שימוש בפקודות שזמינות רק ב-Debian, כמו apt-get.
    4. לוחצים על אפשרויות מתקדמות.
    5. לוחצים על Networking ומגדירים את השדות הבאים:
      1. בשדה Network tags (תגי רשת), מזינים את הערכים allow-ssh ו-load-balanced-backend.
      2. בקטע Network interfaces (ממשקי רשת), בוחרים באפשרויות הבאות:
        • רשת: NETWORK
        • Subnet (רשת משנה): SUBNET_B
    6. לוחצים על ניהול. מזינים את הסקריפט הבא בשדה סקריפט לטעינה בזמן ההפעלה.

      #! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://169.254.169.254/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2
      
    7. לוחצים על יצירה.

    8. לוחצים על Create instance template.

    9. בשדה Name (שם), מזינים gil4-backendwest1-template.

    10. מוודאים שדיסק האתחול מוגדר לקובץ אימג' של Debian, כמו Debian GNU/Linux 12 (bookworm)‎. בהוראות האלה נעשה שימוש בפקודות שזמינות רק ב-Debian, כמו apt-get.

    11. לוחצים על אפשרויות מתקדמות.

    12. לוחצים על Networking ומגדירים את השדות הבאים:

      1. בשדה Network tags (תגי רשת), מזינים את הערכים allow-ssh ו-load-balanced-backend.
      2. בקטע Network interfaces (ממשקי רשת), בוחרים באפשרויות הבאות:
        • רשת: NETWORK
        • Subnet (רשת משנה): SUBNET_A
    13. לוחצים על ניהול. מזינים את הסקריפט הבא בשדה סקריפט לטעינה בזמן ההפעלה.

      #! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://169.254.169.254/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2
      
    14. לוחצים על יצירה.

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

    כניסה לדף Instance groups

    1. לוחצים על יצירת קבוצת מופעים.
    2. בוחרים באפשרות New managed instance group (stateless) (קבוצת מופעי מכונה מנוהלים חדשה (בלי שמירת מצב)). מידע נוסף מופיע במאמר קבוצות של מכונות וירטואליות בלי שמירת מצב או עם שמירת מצב.
    3. בשדה Name (שם), מזינים gl4-ilb-miga.
    4. בקטע מיקום, בוחרים באפשרות אזור יחיד.
    5. בשדה אזור, בוחרים באפשרות REGION_A.
    6. בשדה Zone, בוחרים באפשרות ZONE_A.
    7. בשדה תבנית של הגדרות מכונה, בוחרים באפשרות gil4-backendwest1-template.
    8. מציינים את מספר המופעים שרוצים ליצור בקבוצה.

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

      • בקטע מצב שינוי גודל אוטומטי, בוחרים באפשרות Off:do not autoscale.
      • בשדה מספר מופעים מקסימלי, מזינים 2.

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

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

    10. לוחצים על יצירת קבוצת מופעים.

    11. בוחרים באפשרות New managed instance group (stateless) (קבוצת מופעי מכונה מנוהלים חדשה (בלי שמירת מצב)). מידע נוסף מופיע במאמר קבוצות של מכונות וירטואליות בלי שמירת מצב או עם שמירת מצב.

    12. בשדה Name (שם), מזינים gl4-ilb-migb.

    13. בקטע מיקום, בוחרים באפשרות אזור יחיד.

    14. בשדה אזור, בוחרים באפשרות REGION_B.

    15. בשדה Zone, בוחרים באפשרות ZONE_B.

    16. בשדה תבנית של הגדרות מכונה, בוחרים באפשרות gil4-backendeast1-template.

    17. מציינים את מספר המופעים שרוצים ליצור בקבוצה.

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

      • בקטע מצב שינוי גודל אוטומטי, בוחרים באפשרות Off:do not autoscale.
      • בשדה מספר מופעים מקסימלי, מזינים 2.

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

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

gcloud

ההוראות ל-gcloud CLI במדריך הזה מבוססות על ההנחה שאתם משתמשים ב-Cloud Shell או בסביבה אחרת שבה מותקן bash.

  1. יוצרים תבנית של הגדרות מכונה עם שרת HTTP באמצעות הפקודה gcloud compute instance-templates create.

    gcloud compute instance-templates create gil4-backendwest1-template \
       --region=REGION_A \
       --network=NETWORK \
       --subnet=SUBNET_A \
       --tags=allow-ssh,load-balanced-backend \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --metadata=startup-script='#! /bin/bash
         apt-get update
         apt-get install apache2 -y
         a2ensite default-ssl
         a2enmod ssl
         vm_hostname="$(curl -H "Metadata-Flavor:Google" \
         http://169.254.169.254/computeMetadata/v1/instance/name)"
         echo "Page served from: $vm_hostname" | \
         tee /var/www/html/index.html
         systemctl restart apache2'
    
    gcloud compute instance-templates create gil4-backendeast1-template \
        --region=REGION_B \
        --network=NETWORK \
        --subnet=SUBNET_B \
        --tags=allow-ssh,load-balanced-backend \
        --image-family=debian-12 \
        --image-project=debian-cloud \
        --metadata=startup-script='#! /bin/bash
          apt-get update
          apt-get install apache2 -y
          a2ensite default-ssl
          a2enmod ssl
          vm_hostname="$(curl -H "Metadata-Flavor:Google" \
          http://169.254.169.254/computeMetadata/v1/instance/name)"
          echo "Page served from: $vm_hostname" | \
          tee /var/www/html/index.html
          systemctl restart apache2'
    
  2. יוצרים קבוצת מופעי מכונה מנוהלים באזור באמצעות הפקודה gcloud compute instance-groups managed create.

    gcloud compute instance-groups managed create gl4-ilb-miga \
        --zone=ZONE_A \
        --size=2 \
        --template=gil4-backendwest1-template
    
    gcloud compute instance-groups managed create gl4-ilb-migb \
        --zone=ZONE_B \
        --size=2 \
        --template=gil4-backendeast1-template
    

API

יוצרים את תבנית המכונה באמצעות השיטה instanceTemplates.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.

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

{
  "name":"gil4-backendwest1-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/NETWORK",
         "subnetwork":"regions/REGION_A/subnetworks/SUBNET_A",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates

{
  "name":"gil4-backendeast1-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/NETWORK",
         "subnetwork":"regions/REGION_B/subnetworks/SUBNET_B",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}

יוצרים קבוצת מופעי מכונה מנוהלים בכל אזור באמצעות השיטה instanceGroupManagers.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl4-ilb-miga",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-miga",
  "targetSize": 2
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl4-ilb-migb",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-migb",
  "targetSize": 2
}

הגדרת מאזן העומסים

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

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

זמינות ה-Proxy

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

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

המסוף

התחלת ההגדרה

  1. נכנסים לדף Load balancing במסוף Google Cloud .

    כניסה לדף Load balancing

  2. לוחצים על Create load balancer (יצירת מאזן עומסים).
  3. בקטע Type of load balancer (סוג מאזן העומסים), בוחרים באפשרות Network Load Balancer (TCP/UDP/SSL) (מאזן עומסים ברשת (TCP/UDP/SSL)) ולוחצים על Next (הבא).
  4. בקטע Proxy or passthrough (פרוקסי או העברה), בוחרים באפשרות Proxy load balancer (מאזן עומסים של פרוקסי) ולוחצים על Next (הבא).
  5. בקטע Public facing or internal (פנימי או גלוי לכולם), בוחרים באפשרות Internal (פנימי) ולוחצים על Next (הבא).
  6. בקטע פריסה חוצה אזורים או פריסה באזור יחיד, בוחרים באפשרות הכי טוב לעומסי עבודה חוצי אזורים ולוחצים על הבא.
  7. לוחצים על Configure (הגדרה).

הגדרה בסיסית

  1. מזינים שם למאזן העומסים.
  2. בשדה רשת, בוחרים באפשרות NETWORK.

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

  1. לוחצים על Frontend configuration.
    1. מזינים שם לכלל ההעברה.
    2. ברשימה Subnetwork region, בוחרים באפשרות REGION_A.

      שמירת תת-רשת של שרת proxy בלבד

    3. ברשימה Subnetwork בוחרים באפשרות SUBNET_A.
    4. ברשימה IP address, לוחצים על Create IP address. ייפתח הדף שמירת כתובת IP פנימית סטטית.
      • מזינים שם לכתובת ה-IP הסטטית.
      • ברשימה Static IP address (כתובת IP סטטית), בוחרים באפשרות Let me choose (אני רוצה לבחור).
      • בשדה כתובת IP מותאמת אישית, מזינים 10.1.2.99.
      • לוחצים על הזמנה.
  2. לוחצים על סיום.
  3. כדי להוסיף את כלל ההעברה השני, לוחצים על הוספת כתובת IP ופורט של קצה קדמי.
    1. מזינים שם לכלל ההעברה.
    2. ברשימה Subnetwork region, בוחרים באפשרות REGION_B.

      שמירת תת-רשת של שרת proxy בלבד

    3. ברשימה Subnetwork בוחרים באפשרות SUBNET_B.
    4. ברשימה IP address, לוחצים על Create IP address. ייפתח הדף שמירת כתובת IP פנימית סטטית.
      • מזינים שם לכתובת ה-IP הסטטית.
      • ברשימה Static IP address (כתובת IP סטטית), בוחרים באפשרות Let me choose (אני רוצה לבחור).
      • בשדה כתובת IP מותאמת אישית, מזינים 10.1.3.99.
      • לוחצים על הזמנה.
  4. לוחצים על סיום.
הגדרת שירות הקצה העורפי
  1. לוחצים על Backend configuration.
  2. ברשימה Create or select backend services לוחצים על Create a backend service.
  3. מזינים שם לשירות הקצה העורפי.
  4. בשדה Protocol, בוחרים באפשרות TCP.
  5. בשדה Named Port (יציאה עם שם), מזינים http.
  6. ברשימה Backend type (סוג ה-Backend), בוחרים באפשרות Instance group (קבוצת מופעים).
  7. ברשימה Health check, לוחצים על Create a health check ומזינים את הפרטים הבאים:
    • בשדה שם מזינים global-http-health-check.
    • ברשימה Protocol, בוחרים באפשרות HTTP.
    • בשדה יציאה, מזינים 80.
    • לוחצים על יצירה.
  8. בקטע New backend:
    1. ברשימה Instance group בוחרים באפשרות gl4-ilb-miga in REGION_A.
    2. מגדירים את ניוד מספרים לערך 80.
    3. בקטע מצב איזון, בוחרים באפשרות Connection.
    4. לוחצים על סיום.
    5. כדי להוסיף עוד קצה עורפי, לוחצים על הוספת קצה עורפי.
    6. ברשימה Instance group בוחרים באפשרות gl4-ilb-migb in REGION_B.
    7. מגדירים את ניוד מספרים לערך 80.
    8. לוחצים על סיום.

בדיקת ההגדרות

  1. לוחצים על Review and finalize.
  2. בודקים את הגדרות התצורה של מאזן העומסים.
  3. לוחצים על יצירה.

gcloud

  1. מגדירים את בדיקת התקינות של TCP באמצעות הפקודה gcloud compute health-checks create tcp.

    gcloud compute health-checks create tcp global-health-check \
       --use-serving-port \
       --global
    
  2. מגדירים את שירות הקצה העורפי באמצעות הפקודה gcloud compute backend-services create.

    gcloud compute backend-services create gl4-gilb-backend-service \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=TCP \
      --enable-logging \
      --logging-sample-rate=1.0 \
      --health-checks=global-health-check \
      --global-health-checks \
      --global
    
  3. מוסיפים קצה עורפי לשירות הקצה העורפי באמצעות הפקודה gcloud compute backend-services add-backend.

    gcloud compute backend-services add-backend gl4-gilb-backend-service \
      --balancing-mode=CONNECTION \
      --max-connections=50 \
      --instance-group=gl4-ilb-miga \
      --instance-group-zone=ZONE_A \
      --global
    
    gcloud compute backend-services add-backend gl4-gilb-backend-service \
      --balancing-mode=CONNECTION \
      --max-connections=50 \
      --instance-group=gl4-ilb-migb \
      --instance-group-zone=ZONE_B \
      --global
    
  4. יוצרים את שרת ה-proxy של היעד.

    יוצרים את שרת ה-proxy של היעד באמצעות הפקודה gcloud compute target-tcp-proxies create.

    gcloud compute target-tcp-proxies create gilb-tcp-proxy \
      --backend-service=gl4-gilb-backend-service \
      --global
    
  5. יוצרים שני כללי העברה, אחד עם כתובת VIP‏ (10.1.2.99) ב-REGION_B ואחד עם כתובת VIP‏ (10.1.3.99) ב-REGION_A. מידע נוסף זמין במאמר בנושא שמירת כתובת IPv4 פנימית סטטית.

    ברשתות מותאמות אישית, צריך להפנות לרשת המשנה בכלל ההעברה. חשוב לדעת: זוהי רשת המשנה של המכונה הווירטואלית, ולא רשת המשנה של ה-proxy.

    משתמשים בפקודה gcloud compute forwarding-rules create עם הדגלים המתאימים.

    gcloud compute forwarding-rules create gil4forwarding-rule-a \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=NETWORK \
      --subnet=SUBNET_A \
      --subnet-region=REGION_A \
      --address=10.1.2.99 \
      --ports=80 \
      --target-tcp-proxy=gilb-tcp-proxy \
      --global
    
    gcloud compute forwarding-rules create gil4forwarding-rule-b \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=NETWORK \
      --subnet=SUBNET_B \
      --subnet-region=REGION_B \
      --address=10.1.3.99 \
      --ports=80 \
      --target-tcp-proxy=gilb-tcp-proxy \
      --global
    

API

כדי ליצור את בדיקת תקינות, שולחים בקשת POST אל ה-method‏ healthChecks.insert ומחליפים את PROJECT_ID במזהה הפרויקט.

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

{
"name": "global-health-check",
"type": "TCP",
"httpHealthCheck": {
  "portSpecification": "USE_SERVING_PORT"
}
}

כדי ליצור את שירות לקצה העורפי הגלובלי, שולחים בקשת POST ל-method‏ backendServices.insert ומחליפים את PROJECT_ID במזהה הפרויקט.

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

{
"name": "gl4-gilb-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl4-ilb-miga",
    "balancingMode": "CONNECTION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl4-ilb-migb",
    "balancingMode": "CONNECTION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/global/healthChecks/global-health-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

יוצרים את שרת ה-TCP Proxy ביעד על ידי שליחת בקשת POST ל-method‏ targetTcpProxies.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.

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

{
"name": "l4-ilb-proxy",
}

יוצרים את כלל ההעברה על ידי שליחת בקשת POST ל-method‏ forwardingRules.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.

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

{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

יוצרים את כלל ההעברה על ידי שליחת בקשת POST ל-method‏ globalForwardingRules.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.

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

{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

בדיקת מאזן העומסים

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

  1. יצירת מכונה וירטואלית (VM) של לקוח באזורים REGION_B ו-REGION_A:

    gcloud compute instances create l4-ilb-client-a \
        --image-family=debian-12 \
        --image-project=debian-cloud \
        --network=NETWORK \
        --subnet=SUBNET_A \
        --zone=ZONE_A \
        --tags=allow-ssh
    
    gcloud compute instances create l4-ilb-client-b \
        --image-family=debian-12 \
        --image-project=debian-cloud \
        --network=NETWORK \
        --subnet=SUBNET_B \
        --zone=ZONE_B \
        --tags=allow-ssh
    
  2. משתמשים ב-SSH כדי להתחבר לכל מכונת לקוח.

    gcloud compute ssh l4-ilb-client-a --zone=ZONE_A
    
    gcloud compute ssh l4-ilb-client-b --zone=ZONE_B
    
  3. אימות כתובת ה-IP שמשרתת את שם המארח

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

      curl 10.1.2.99
      
      curl 10.1.3.99
      

בדיקת מעבר לגיבוי (failover)

  1. מוודאים שהמעבר לגיבוי (failover) לשרתי קצה עורפיים באזור REGION_A מתבצע כששרתי קצה עורפיים באזור REGION_B לא תקינים או שלא ניתן להגיע אליהם. כדי לדמות מעבר לגיבוי, מסירים את כל השרתים העורפיים מ-REGION_B:

    gcloud compute backend-services remove-backend gl4-gilb-backend-service \
      --instance-group=gl4-ilb-migb \
      --instance-group-zone=ZONE_B \
      --global
    
  2. מתחברים באמצעות SSH למכונה וירטואלית של לקוח ב-REGION_B.

    gcloud compute ssh l4-ilb-client-b \
       --zone=ZONE_B
    
  3. שולחים בקשות לכתובת ה-IP של מאזן העומסים באזור REGION_B. פלט הפקודה מציג תשובות ממכונות וירטואליות בעורף הדף ב-REGION_A:

    {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl 10.1.3.99)"
    done
    echo "***"
    echo "*** Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
    }
    

אפשרויות הגדרה נוספות

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

יצירת מאזן עומסים עם נתיבי TLS

בקטע הזה מוסבר איך ליצור מאזן עומסים שיכול להשתמש בניתוב מבוסס SNI. ניתוב מבוסס-SNI מאפשר למאזני עומסים מסוג proxy לנתב תנועה לשירותי קצה עורפיים ספציפיים על סמך שם המארח של Server Name Indication ‏ (SNI) שסופק במהלך לחיצת היד של TLS.

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

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

יצירת קצה עורפי של קבוצת מופעי מכונה מנוהלים

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

ההוראות ל-Google Cloud CLI במדריך הזה מבוססות על ההנחה שאתם משתמשים ב-Cloud Shell או בסביבה אחרת שבה מותקן bash.

  1. יוצרים תבנית של הגדרות מכונה עם שירות HTTPS מסוג echo שנחשף ביציאה 443.

    gcloud compute instance-templates create INSTANCE_TEMPLATE_NAME \
    --region=REGION_A \
    --network=NETWORK \
    --subnet=SUBNET_A \
    --stack-type=IPv4_ONLY \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --metadata=startup-script='#! /bin/bash
    sudo sed -i "s/^#DNS=.*/DNS=8.8.8.8 8.8.4.4/" /etc/systemd/resolved.conf
    sudo systemctl restart systemd-resolved
    sudo rm -rf /var/lib/apt/lists/*
    sudo apt-get -y clean
    sudo apt-get -y update
    sudo apt-get -y install ca-certificates curl gnupg software-properties-common
    sudo curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -
    sudo add-apt-repository -y "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
    sudo apt-get -y update
    sudo apt-get -y install docker-ce
    sudo which docker
    echo "{ \"registry-mirrors\": [\"https://mirror.gcr.io\"] }" | sudo tee -a /etc/docker/daemon.json
    sudo service docker restart
    sudo docker run -e HTTPS_PORT=9999 -p 443:9999 --rm -dt mendhak/http-https-echo:22'
    

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

    • INSTANCE_TEMPLATE_NAME: שם לתבנית של הגדרות המכונה.
    • REGION_A: האזור של תבנית של הגדרות מכונה.
    • NETWORK: שם הרשת.
    • SUBNET_A: השם של רשת המשנה.
  2. יוצרים קבוצה של מופעי מכונה מנוהלים על סמך תבנית המכונה:

    gcloud compute instance-groups managed create INSTANCE_GROUP_NAME \
      --zone=ZONE_A \
      --size=2 \
      --template=INSTANCE_TEMPLATE_NAME
    

    מחליפים את ZONE_A באזור של קבוצת המופעים.

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

    gcloud compute instance-groups managed set-named-ports INSTANCE_GROUP_NAME \
      --named-ports=PORT_NAME:PORT_NUMBER \
      --zone=ZONE_A
    

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

    • PORT_NAME: שם של יציאת ההגשה – לדוגמה, tcp443.
    • PORT_NUMBER: מספר היציאה של יציאת ההגשה, לדוגמה 443.

הגדרת חומת האש

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

gcloud compute firewall-rules create FIREWALL_RULE_NAME \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --source-ranges=35.191.0.0/16 \
    --target-tags=allow-health-check \
    --rules=tcp:443

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

הגדרת מאזן העומסים

  1. יוצרים בדיקת תקינות ב-HTTPS:

    gcloud compute health-checks create http HTTPS_HEALTH_CHECK_NAME \
        --global \
        --port=HC_PORT
    

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

    • HTTP_HEALTH_CHECK_NAME: שם לבדיקת תקינות.
    • HC_PORT: היציאה לבדיקת תקינות.
  2. יוצרים שירות לקצה העורפי:

    gcloud compute backend-services create BACKEND_SERVICE_NAME \
        --load-balancing-scheme=INTERNAL_MANAGED \
        --protocol=TCP \
        --port-name=PORT_NAME \
        --health-checks=global-health-check \
        --global-health-checks \
        --global
    

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

    • BACKEND_SERVICE_NAME: שם לשירות העורפי.
    • PORT_NAME: שם היציאה של שירות ה-Backend. משתמשים באותו פורט עם שם שהוגדר בקבוצת המכונות – לדוגמה, tcp443.
    • HTTPS_HEALTH_CHECK_NAME: השם של בדיקת תקינות HTTPS.
  3. מוסיפים את קבוצת המכונות לקצה העורפי לשירות הקצה העורפי:

    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
        --balancing-mode=UTILIZATION \
        --max-utilization=0.8 \
        --instance-group=INSTANCE_GROUP_NAME \
        --instance-group-zone=ZONE_A \
        --global
    

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

    • INSTANCE_GROUP_NAME: השם של קבוצת השרתים העורפיים.
    • ZONE_A: האזור של קבוצת המכונות.
  4. יוצרים שרת proxy של TCP ביעד.

    gcloud beta compute target-tcp-proxies create TARGET_TCP_PROXY_NAME \
        --load-balancing-scheme=INTERNAL_MANAGED \
        --proxy-header=NONE \
        --global
    

    מחליפים את TARGET_TCP_PROXY_NAME בשם של פרוקסי TCP היעד.

  5. יוצרים מפרט של נתיב TLS ושומרים אותו בקובץ YAML.

    cat <<EOF | tee YAML_FILE_NAME
    name: TLS_ROUTE_NAME
    targetProxies:
    - projects/PROJECT_NUMBER/locations/global/targetTcpProxies/TARGET_TCP_PROXY
    rules:
    - matches:
      - sniHost:
        - example.com
      action:
      destinations:
      - serviceName: projects/PROJECT_NUMBER/locations/global/backendServices/BACKEND_SERVICE
    EOF
    

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

    • YAML_FILE_NAME: שם לקובץ ה-YAML, לדוגמה tls-route.yaml.
    • TLS_ROUTE_NAME: שם של נתיב TLS.
    • PROJECT_NUMBER: מספר הפרויקט.
  6. משתמשים בקובץ המפרט של YAML כדי ליצור את משאב נתיב ה-TLS.

    gcloud network-services tls-routes import TLS_ROUTE_NAME \
      --source=YAML_FILE_NAME \
      --global
    
  7. יוצרים את כלל ההעברה.

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=NETWORK \
      --subnet=SUBNET_A \
      --subnet-region=REGION_A \
      --address=IP_ADDRESS \
      --ports=PORT \
      --target-tcp-proxy=TARGET_TCP_PROXY_NAME \
      --global
    

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

    • FORWARDING_RULE_NAME: שם לכלל ההעברה.
    • NETWORK: שם הרשת.
    • SUBNET_A: השם של רשת המשנה באותו אזור כמו מאזן העומסים.
    • IP_ADDRESS: כתובת ה-IP של מאזן העומסים.
    • PORT_NUMBER: היציאה שמשמשת את כלל ההעברה, לדוגמה 443.

בדיקת מאזן העומסים

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

  1. מוודאים שיש לכם גישה לשירות ה-HTTPS דרך מאזן העומסים.

    curl https://example.com --resolve example.com:443:IP_ADDRESS -k
    

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

    "path": "/",
    "headers": {
      "host": "example.com",
      "user-agent": "curl/7.81.0",
      "accept": "*/*"
    },
    "method": "GET",
    "body": "",
    "fresh": false,
    "hostname": "example.com",
    "ip": "::ffff:10.142.0.2",
    "ips": [],
    "protocol": "https",
    "query": {},
    "subdomains": [],
    "xhr": false,
    "os": {
      "hostname": "0cd3aec9b351"
    },
    "connection": {
      "servername": "example.com"
    }
    

    כדי לוודא זאת, אפשר לספק שם מארח SNI שונה שלא תואם לנתיב TLS, או לא לספק שם מארח SNI בכלל, ואז הבקשה תידחה.

    • מריצים בדיקה עם שם מארח של SNI שלא תואם ל-example.com, כדי לוודא שהחיבור נדחה.
    curl https://unknown.com --resolve unknown.com:443:IP_ADDRESS -k
    
    • מריצים בדיקה עם חיבור טקסט פשוט ללא TLS, כדי לוודא שהחיבור נדחה.
    curl example.com:443 --resolve example.com:443:IP_ADDRESS -k
    

    הפקודות האלה מחזירות את השגיאה הבאה.

    curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection
    

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

פרוטוקול PROXY לשמירת פרטי החיבור של הלקוח

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

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

מוודאים שמופעלים במופעי ה-Backend של מאזן העומסים הפנימי של שרת ה-proxy שרתים מסוג HTTP או HTTPS שתומכים בכותרות של פרוטוקול PROXY. אם שרתי ה-HTTP או ה-HTTPS לא מוגדרים לתמיכה בכותרות של פרוטוקול PROXY, המופעים העורפיים מחזירים תגובות ריקות. לדוגמה, פרוטוקול ה-PROXY לא פועל עם תוכנת Apache HTTP Server. אפשר להשתמש בתוכנות שרת אינטרנט שונות, כמו Nginx.

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

כותרת פרוטוקול ה-PROXY היא בדרך כלל שורה אחת של טקסט שקריא למשתמשים בפורמט הבא:

PROXY TCP4 <client IP> <load balancing IP> <source port> <dest port>\r\n

דוגמה לפרוטוקול PROXY:

PROXY TCP4 192.0.2.1 198.51.100.1 15221 110\r\n

בדוגמה שלמעלה, כתובת ה-IP של הלקוח היא 192.0.2.1, כתובת ה-IP של איזון העומסים היא 198.51.100.1, יציאת הלקוח היא 15221 ויציאת היעד היא 110.

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

PROXY UNKNOWN\r\n

עדכון כותרת פרוטוקול ה-PROXY עבור שרת proxy של TCP ביעד

ההגדרה לדוגמה של מאזן העומסים בדף הזה מראה איך להפעיל את כותרת פרוטוקול ה-PROXY בזמן יצירת מאזן עומסי רשת פנימי לשרת proxy. כדי לשנות את כותרת פרוטוקול ה-PROXY עבור שרת TCP Proxy קיים, פועלים לפי השלבים הבאים.

המסוף

  1. נכנסים לדף Load balancing במסוף Google Cloud .

    כניסה לדף Load balancing

  2. לוחצים על Edit ליד מאזן העומסים.

  3. לוחצים על Frontend configuration.

  4. משנים את הערך של השדה Proxy protocol (פרוטוקול שרת Proxy) ל-On (מופעל).

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

gcloud

בפקודה הבאה, עורכים את השדה --proxy-header ומגדירים אותו לערך NONE או PROXY_V1 בהתאם לדרישה.

gcloud compute target-ssl-proxies update int-tcp-target-proxy \
    --proxy-header=[NONE | PROXY_V1]

שימוש באותה כתובת IP בכמה כללי העברה פנימיים

כדי שכמה כללי העברה פנימיים ישתמשו באותה כתובת IP פנימית, צריך לשמור את כתובת ה-IP ולהגדיר את הדגל --purpose שלה לערך SHARED_LOADBALANCER_VIP.

gcloud

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP

הפעלת זיקה לסשן

ההגדרה לדוגמה יוצרת שירות לקצה העורפי ללא זיקה לסשן (session affinity).

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

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

המסוף

כדי להפעיל זיקה לסשן לפי כתובת IP של לקוח:

  1. נכנסים לדף Load balancing במסוף Google Cloud .
    כניסה לדף Load balancing
  2. לוחצים על Backends.
  3. לוחצים על השם של שירות לקצה העורפי שיצרתם בדוגמה הזו ואז על עריכה.
  4. בדף Backend service details (פרטי שירות לקצה העורפי), לוחצים על Advanced configuration (הגדרה מתקדמת).
  5. בקטע Session affinity, בוחרים באפשרות Client IP מהתפריט.
  6. לוחצים על עדכון.

gcloud

משתמשים בפקודת gcloud הבאה כדי לעדכן את BACKEND_SERVICEשירות לקצה העורפי, ומציינים את זיקה לסשן (session affinity) של כתובת ה-IP של הלקוח:

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --session-affinity=CLIENT_IP

הפעלת ניתוק הדרגתי של חיבורים

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

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