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

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

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

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

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

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

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

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

    • רשת המשנה SUBNET_A ורשת משנה מסוג proxy-only ב-REGION_A.
    • רשת המשנה SUBNET_B ורשת משנה מסוג proxy-only ב-REGION_B.

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

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

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

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

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

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

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

הרשאות

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

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

    כניסה לדף VPC networks

  2. לוחצים על Create VPC network.

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

  4. בקטע Subnets, מגדירים את Subnet creation mode ל-Custom.

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

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

  6. לוחצים על סיום.

  7. לוחצים על Add subnet.

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

    • מזינים Name לרשת המשנה.
    • בוחרים אזור: 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./compute/v1/projects/PROJECT_ID/global/networks

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

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

POST https://compute./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./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 בלבד

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

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

המסוף

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

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

  1. במסוף Google Cloud , נכנסים לדף רשתות VPC.

    כניסה לדף VPC networks

  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./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./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 ממערכות בדיקת התקינות של Google Cloud(ב-130.211.0.0/22 וב-35.191.0.0/16). בדוגמה הזו, תג היעד load-balanced-backend משמש לזיהוי המכונות הווירטואליות שכלל חומת האש חל עליהן.

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

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

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

המסוף

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

    כניסה לדף Firewall policies

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

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

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

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

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

    • פרוטוקולים ויציאות:

      • בוחרים באפשרות Specified protocols and ports.
      • מסמנים את התיבה TCP ומזינים את מספר היציאה 80.

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

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

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

    • שם: fw-backends
    • רשת: NETWORK
    • כיוון התנועה: Ingress
    • פעולה במקרה של התאמה: אישור
    • יעדים: תגי יעד שצוינו
    • תגי יעד: load-balanced-backend
    • מסנן מקור: טווחי IPv4
    • טווחי IPv4 של המקור: 10.129.0.0/23 ו-10.130.0.0/23
    • פרוטוקולים ויציאות:
      • בוחרים באפשרות Specified protocols and ports.
      • מסמנים את התיבה 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./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./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./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. במסוף Google Cloud , נכנסים לדף תבניות של הגדרות מכונה.

    כניסה לדף Instance templates

    1. לוחצים על יצירת תבנית של הגדרות מכונה.
    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_B

    6. לוחצים על ניהול. מזינים את הסקריפט הבא בשדה 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

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

    8. לוחצים על יצירת תבנית של הגדרות מכונה.

    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_A

    13. לוחצים על ניהול. מזינים את הסקריפט הבא בשדה 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

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

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

    כניסה לדף Instance groups

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

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

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

      • בקטע Autoscaling mode, בוחרים באפשרות Off:do not autoscale.
      • בשדה Maximum number of instances, מזינים 2.

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

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

    10. לוחצים על Create instance group.

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

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

    13. בשדה Location, בוחרים באפשרות Single zone.

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

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

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

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

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

      • בקטע Autoscaling mode, בוחרים באפשרות Off:do not autoscale.
      • בשדה Maximum number of instances, מזינים 2.

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

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

gcloud

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

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

  • צריך להמתין עד שהבעיה תיפתר.

המסוף

התחלת ההגדרה

  1. במסוף Google Cloud , עוברים לדף איזון עומסים.

    כניסה לדף Load balancing

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

הגדרה בסיסית

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

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

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

      הקצאת תת-רשת של שרת proxy בלבד

    3. ברשימה Subnetwork, בוחרים באפשרות SUBNET_A.
    4. ברשימת כתובות IP, לוחצים על Create IP address. ייפתח הדף Reserve a static internal IP address.
      • מזינים שם לכתובת ה-IP הסטטית.
      • ברשימה כתובת IP סטטית, בוחרים באפשרות אני רוצה לבחור.
      • בשדה כתובת IP בהתאמה אישית, מזינים 10.1.2.99.
      • לוחצים על הזמנה.
  2. לוחצים על סיום.
  3. כדי להוסיף את כלל ההעברה השני, לוחצים על Add frontend IP and port.
    1. מזינים שם לכלל ההעברה.
    2. ברשימה Subnetwork region, בוחרים באפשרות REGION_B.

      הקצאת תת-רשת של שרת proxy בלבד

    3. ברשימה Subnetwork, בוחרים באפשרות SUBNET_B.
    4. ברשימת כתובות IP, לוחצים על Create IP address. ייפתח הדף Reserve a static internal IP address.
      • מזינים שם לכתובת ה-IP הסטטית.
      • ברשימה כתובת IP סטטית, בוחרים באפשרות אני רוצה לבחור.
      • בשדה כתובת 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, בוחרים באפשרות Instance group.
  7. ברשימה Health check, לוחצים על Create a health check ומזינים את הפרטים הבאים:
    • בשדה Name, מזינים global-http-health-check.
    • ברשימה Protocol, בוחרים באפשרות HTTP.
    • בשדה יציאה, מזינים 80.
    • לוחצים על יצירה.
  8. בקטע New backend:
    1. ברשימה Instance group, בוחרים את gl4-ilb-miga ב-REGION_A.
    2. מגדירים את מספרי היציאות לערך 80.
    3. בשדה Balancing mode, בוחרים באפשרות Connection.
    4. לוחצים על סיום.
    5. כדי להוסיף עוד קצה עורפי, לוחצים על Add backend.
    6. ברשימה Instance group, בוחרים את gl4-ilb-migb ב-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./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./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"
}

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

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

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

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

POST https://compute./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./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./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./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. יוצרים מכונה וירטואלית של לקוח באזורים 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. הפקודה אמורה להצליח ולהחזיר את השם של ה-VM לקצה העורפי שטיפל בבקשה:

      curl 10.1.2.99

      curl 10.1.3.99

בדיקת יתירות כשל

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

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

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

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

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

ההוראות ל-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 https HTTPS_HEALTH_CHECK_NAME \
    --global \
    --port=HC_PORT

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

    • ‫HTTPS_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 \
    --enable-logging \
    --logging-sample-rate=1.0 \
    --logging-optional=INCLUDE_ALL_OPTIONAL \
    --global

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

    • ‫BACKEND_SERVICE_NAME: שם לשירות לקצה העורפי.
    • ‫PORT_NAME: שם היציאה של שירות הקצה העורפי. משתמשים באותה יציאה בעלת שם שהוגדרה בקבוצת המכונות, לדוגמה 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 בשם של שרת ה-proxy ל-TCP לטירגוט.

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

    cat <<EOF | tee YAML_FILE_NAME
name: TLS_ROUTE_NAME
targetProxies:
- projects/PROJECT_NUMBER/locations/global/targetTcpProxies/TARGET_TCP_PROXY_NAME
rules:
- matches:
  - sniHost:
    - example.com
  action:
    destinations:
    - serviceName: projects/PROJECT_NUMBER/locations/global/backendServices/BACKEND_SERVICE_NAME
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 של היעד ומספרי היציאות, כחלק מהבקשה.

חשוב לוודא שבמכונות העורפיות של מאזן עומסי הרשת הפנימי של שרת ה-Proxy פועלים שרתי HTTP או HTTPS שתומכים בכותרות של פרוטוקול PROXY. אם שרתי ה-HTTP או ה-HTTPS לא מוגדרים לתמוך בכותרות של פרוטוקול PROXY, המכונות העורפיות מחזירות תשובות ריקות. לדוגמה, פרוטוקול PROXY לא פועל עם תוכנת השרת Apache HTTP. אפשר להשתמש בתוכנת שרת אינטרנט אחרת, כמו 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 בשרת proxy קיים ל-TCP, פועלים לפי השלבים הבאים:

המסוף

  1. במסוף Google Cloud , עוברים לדף איזון עומסים.

    כניסה לדף Load balancing

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

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

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

המסוף

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

  1. במסוף Google Cloud , עוברים לדף איזון עומסים.
    כניסה לדף Load balancing
  2. לוחצים על Backends.
  3. לוחצים על השם של שירות הקצה העורפי שיצרתם בדוגמה הזו, ואז על Edit.
  4. בדף פרטי שירות לקצה העורפי, לוחצים על 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

הפעלת זמן להשלמת תהליך (connection draining)

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

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