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

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

כדי להגדיר איזון עומסים לשירותים שפועלים בקבוצות Pod של Google Kubernetes Engine‏ (GKE), אפשר לעיין במאמר איזון עומסים מקורי של קונטיינרים באמצעות קבוצות NEG עצמאיות ובקטע צירוף של מאזן עומסים פנימי של אפליקציות (ALB) לקבוצות NEG עצמאיות.

כדי להגדיר איזון עומסים לגישה לממשקי API ולשירותים של Google באמצעות Private Service Connect, אפשר לעיין במאמר גישה לממשקי Google API אזוריים דרך קצה עורפי.

ההגדרה של מאזני עומסים פנימיים של אפליקציות (ALB) כוללת שני חלקים:

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

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

הרשאות

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

משימה התפקיד הנדרש
יצירת רשתות, רשתות משנה ורכיבים של מאזן עומסים אדמין של רשתות מחשוב (roles/compute.networkAdmin)
הוספה והסרה של כללים לחומת האש אדמין לענייני אבטחה ב-Compute (roles/compute.securityAdmin)
יצירת מופעים אדמין מכונות של Compute (roles/compute.instanceAdmin.v1)

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

סקירה כללית של ההגדרה

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

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

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

הדיאגרמה מציגה את הפריטים הבאים:

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

    • תת-רשת אחת משמשת לשרתי בק-אנד (קבוצות של מופעי מכונה) ולכלל ההעברה. טווח כתובות ה-IP הראשי שלה הוא 10.1.2.0/24.

    • תת-רשת אחת היא תת-רשת של שרת proxy בלבד באזור us-west1. צריך ליצור רשת משנה ל-proxy בלבד בכל אזור ברשת VPC שבה משתמשים במאזני עומסים פנימיים של אפליקציות. רשת המשנה של ה-proxy בלבד באזור משותפת לכל מאזני העומסים הפנימיים של האפליקציות באזור. כתובות המקור של מנות הנתונים שנשלחות ממאזן העומסים של אפליקציות (ALB) הפנימי לקצה העורפי של השירות מוקצות מרשת המשנה של proxy בלבד. בדוגמה הזו, לתת-הרשת של האזור שמוגדרת רק לשימוש פרוקסי יש טווח כתובות IP ראשי של 10.129.0.0/23, שהוא הגודל המומלץ של תת-הרשת. מידע נוסף זמין במאמר בנושא רשתות משנה של פרוקסי בלבד למאזני עומסים מבוססי Envoy.

  2. שני כללים לחומת האש:

    • כלל חומת אש שמאפשר זרימת תעבורת נתונים מתת-רשת של שרת proxy בלבד ברשת. כלומר, צריך להוסיף כלל אחד שמאפשר תעבורת נתונים ביציאות TCP‏ 80, 443 ו-8080 מ-10.129.0.0/23 (הטווח של רשת המשנה של שרת proxy בלבד בדוגמה הזו).
    • כלל חומת אש נוסף עבור בקשות לבדיקת תקינות.

  3. מכונות וירטואליות של Compute Engine בקצה העורפי.

  4. קבוצות של מופעי מכונה מנוהלים או לא מנוהלים לפריסות של מכונות וירטואליות ב-Compute Engine.

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

  5. בדיקת תקינות אזורית שמדווחת על המוכנות של שרתי הקצה העורפי.

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

  7. מפת URL אזורית שמנתחת את כתובת ה-URL של בקשה ומעבירה בקשות לשירותי קצה עורפיים ספציפיים על סמך המארח והנתיב של כתובת ה-URL של הבקשה.

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

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

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

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

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

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

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

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

  • רשת. הרשת היא רשת VPC במצב מותאם אישית בשם lb-network.

  • רשת משנה לשרתי קצה עורפיים. רשת משנה בשם backend-subnet באזור us-west1 משתמשת ב-10.1.2.0/24 כטווח ה-IP הראשי שלה.

  • רשת משנה עבור שרתי proxy. רשת משנה בשם proxy-only-subnet באזור us-west1 משתמשת ב-10.129.0.0/23 כטווח ה-IP הראשי שלה.

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

  • אזור: europe-west1
  • רשת משנה: europe-subnet, עם טווח כתובות IP ראשי 10.3.4.0/24

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

המסוף

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

    מעבר לרשתות VPC

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

  3. בשדה Name (שם), מזינים lb-network.

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

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

    • Name (שם): backend-subnet
    • אזור: us-west1
    • טווח כתובות IP: 10.1.2.0/24

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

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

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

    • Name (שם): europe-subnet
    • אזור: europe-west1
    • טווח כתובות IP: 10.3.4.0/24

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

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

gcloud

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

    gcloud compute networks create lb-network --subnet-mode=custom

  2. יוצרים תת-רשת ברשת lb-network באזור us-west1 באמצעות הפקודה gcloud compute networks subnets create:

    gcloud compute networks subnets create backend-subnet \
    --network=lb-network \
    --range=10.1.2.0/24 \
    --region=us-west1

  3. יוצרים תת-רשת ברשת lb-network באזור europe-west1 באמצעות הפקודה gcloud compute networks subnets create:

    gcloud compute networks subnets create europe-subnet \
    --network=lb-network \
    --range=10.3.4.0/24 \
    --region=europe-west1

API

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

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

{
 "routingConfig": {
   "routingMode": "REGIONAL"
 },
 "name": "lb-network",
 "autoCreateSubnetworks": false
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

{
 "name": "backend-subnet",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/us-west1",
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/europe-west1/subnetworks

{
 "name": "europe-subnet",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.3.4.0/24",
 "region": "projects/PROJECT_ID/regions/europe-west1",
}

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

רשת המשנה הזו, שכוללת רק פרוקסי, מיועדת לכל מאזני העומסים האזוריים שמבוססים על Envoy באזור us-west1 של lb-network.

המסוף

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

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

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

    מעבר לרשתות VPC

  2. לוחצים על השם של רשת ה-VPC: ‏ lb-network.

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

  4. בשדה Name (שם), מזינים proxy-only-subnet.

  5. בשדה אזור, בוחרים באפשרות us-west1.

  6. מגדירים את Purpose (מטרה) לערך Regional Managed Proxy (שרת proxy מנוהל אזורי).

  7. בשדה IP address range (טווח כתובות IP), מזינים 10.129.0.0/23.

  8. לוחצים על הוספה.

gcloud

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

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=us-west1 \
    --network=lb-network \
    --range=10.129.0.0/23

API

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

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "region": "projects/PROJECT_ID/regions/us-west1",
  "purpose": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

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

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

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

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

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

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

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

המסוף

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

    לדף Firewall policies

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

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

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

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

    • Name (שם): fw-allow-health-check
    • רשת: lb-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-allow-proxies
    • רשת: lb-network
    • כיוון התנועה: כניסה
    • פעולה במקרה של התאמה: אישור
    • יעדים: תגי יעד שצוינו
    • תגי טירגוט: load-balanced-backend
    • מסנן מקור: טווחים של IPv4
    • טווחים של כתובות IPv4 של המקור: 10.129.0.0/23
    • פרוטוקולים ויציאות:
      • בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
      • מסמנים את התיבה TCP ומזינים את הערך 80, 443, 8080 עבור מספרי היציאות.

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

gcloud

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

    gcloud compute firewall-rules create fw-allow-ssh \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  2. יוצרים את הכלל fw-allow-health-check כדי לאפשר Google Cloudבדיקות תקינות. בדוגמה הזו, כל תנועת ה-TCP מבודקי בדיקת תקינות מורשית, אבל אפשר להגדיר קבוצה מצומצמת יותר של יציאות בהתאם לצרכים שלכם.

    gcloud compute firewall-rules create fw-allow-health-check \
    --network=lb-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-allow-proxies כדי לאפשר לשרתי ה-proxy של מאזן העומסים הפנימי של האפליקציה להתחבר לשרתים העורפיים (backend) שלכם. מגדירים את source-ranges לטווחים שהוקצו לתת-הרשת של שרת ה-proxy בלבד – לדוגמה, 10.129.0.0/23.

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

API

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

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

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

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

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

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

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

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

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

שמירת כתובת ה-IP של מאזן העומסים

כברירת מחדל, כתובת IP אחת משמשת לכל כלל העברה. אתם יכולים לשריין כתובת IP משותפת, כדי להשתמש באותה כתובת IP עם כמה כללי העברה. עם זאת, אם רוצים לפרסם את מאזן העומסים באמצעות Private Service Connect, לא משתמשים בכתובת IP משותפת לכלל ההעברה.

לכתובת ה-IP של כלל ההעברה, משתמשים ב-backend-subnet. אם תנסו להשתמש ברשת משנה מסוג proxy בלבד, יצירת כלל ההעברה תיכשל.

המסוף

אפשר לשמור כתובת IP פנימית עצמאית באמצעות מסוףGoogle Cloud .

  1. עוברים לדף VPC networks.

    מעבר לרשתות VPC

  2. לוחצים על הרשת ששימשה להגדרת קישוריות היברידית בין הסביבות.
  3. לוחצים על כתובות IP פנימיות סטטיות ואז על שמירת כתובת סטטית.
  4. בשדה Name (שם), מזינים l7-ilb-ip-address.
  5. בשדה רשת משנה, בוחרים באפשרות backend-subnet.
  6. אם רוצים לציין איזו כתובת IP להזמין, בקטע כתובת IP סטטית בוחרים באפשרות אני רוצה לבחור וממלאים כתובת IP מותאמת אישית. אחרת, המערכת מקצה לכם באופן אוטומטי כתובת IP בתת-הרשת.
  7. אם רוצים להשתמש בכתובת ה-IP הזו עם כמה כללי העברה, בקטע מטרה בוחרים באפשרות משותפת.
  8. כדי לסיים את התהליך, לוחצים על שמירה.

gcloud

  1. מריצים את הפקודה gcloud compute addresses create ב-CLI של gcloud:

    gcloud compute addresses create l7-ilb-ip-address \
    --region=us-west1 \
    --subnet=backend-subnet

    אם רוצים להשתמש באותה כתובת IP עם כמה כללי העברה, צריך לציין --purpose=SHARED_LOADBALANCER_VIP.

  2. משתמשים בפקודה gcloud compute addresses describe כדי לראות את כתובת ה-IP שהוקצתה:

    gcloud compute addresses describe l7-ilb-ip-address \
    --region=us-west1

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

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

המסוף

  1. יוצרים תבנית של הגדרות מכונה. נכנסים לדף Instance templates במסוף Google Cloud .

    כניסה לדף Instance templates

    1. לוחצים על Create instance template.
    2. בשדה Name (שם), מזינים l7-ilb-backend-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 (ממשקי רשת), בוחרים באפשרויות הבאות:
        • רשת: lb-network
        • Subnet: backend-subnet

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

      #! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://metadata.google.internal/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2

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

  2. יוצרים קבוצה של מופעי מכונה מנוהלים. נכנסים לדף Instance groups במסוף Google Cloud .

    כניסה לדף Instance groups

    1. לוחצים על יצירת קבוצת מופעים.
    2. בוחרים באפשרות New managed instance group (stateless) (קבוצת מופעי מכונה מנוהלים חדשה (בלי שמירת מצב)). מידע נוסף מופיע במאמר בנושא קבוצות של מופעים מנוהלים עם שמירת מצב.
    3. בשדה Name (שם), מזינים l7-ilb-backend-example.
    4. בקטע מיקום, בוחרים באפשרות אזור יחיד.
    5. בשדה אזור, בוחרים באפשרות us-west1.
    6. בשדה Zone, בוחרים באפשרות us-west1-a.
    7. בשדה תבנית של הגדרות מכונה, בוחרים באפשרות l7-ilb-backend-template.

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

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

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

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

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

gcloud

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

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

     gcloud compute instance-templates create l7-ilb-backend-template \
     --region=us-west1 \
     --network=lb-network \
     --subnet=backend-subnet \
     --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://metadata.google.internal/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 l7-ilb-backend-example \
      --zone=us-west1-a \
      --size=2 \
      --template=l7-ilb-backend-template

API

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates
{
  "name":"l7-ilb-backend-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://metadata.google.internal/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/lb-network",
         "subnetwork":"regions/us-west1/subnetworks/backend-subnet",
         "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": "l7-ilb-backend-example",
  "zone": "projects/PROJECT_ID/zones/us-west1-a",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/l7-ilb-backend-template",
  "baseInstanceName": "l7-ilb-backend-example",
  "targetSize": 2
}

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

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

  • בדיקת תקינות של HTTP
  • שירות קצה עורפי עם קבוצת מופעי מכונה מנוהלים כקצה עורפי
  • מפת URL
    • אם הוגדר אזור לשרת ה-proxy של HTTP(S) ביעד, חשוב להפנות למפת URL אזורית. מפת URL אזורית מעבירה בקשות לשירות לקצה העורפי אזורי על סמך כללים שאתם מגדירים עבור המארח והנתיב של כתובת URL נכנסת. אפשר להפנות למפת URL אזורית רק מכלל אזורי של שרת proxy ליעד באותו אזור.
  • אישור SSL (ל-HTTPS)
  • שרת proxy יעד
  • כלל העברה

זמינות ה-Proxy

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

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

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

המסוף

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

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

    כניסה לדף איזון עומסים

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

הגדרה בסיסית

  1. בשדה Name של מאזן העומסים, מזינים l7-ilb-map.
  2. בשדה אזור, בוחרים באפשרות us-west1.
  3. בקטע רשת, בוחרים באפשרות lb-network.

הזמנת רשת משנה לשרת proxy בלבד

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

  1. לוחצים על שמירת רשת משנה.
  2. בשדה Name (שם), מזינים proxy-only-subnet.
  3. בשדה IP address range (טווח כתובות IP), מזינים 10.129.0.0/23.
  4. לוחצים על הוספה.

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

  1. לוחצים על Backend configuration.
  2. בתפריט Create or select backend services (יצירה או בחירה של שירותי קצה עורפי), בוחרים באפשרות Create a backend service (יצירת שירות קצה עורפי).
  3. מגדירים את שם השירות לקצה העורפי ל-l7-ilb-backend-service.
  4. מגדירים את Backend type (סוג הבק-אנד) בתור Instance group (קבוצת מכונות).
  5. ברשימה בדיקת תקינות, לוחצים על יצירת בדיקת תקינות ומזינים את הפרטים הבאים:
    1. Name (שם): l7-ilb-basic-check
    2. Protocol: HTTP
    3. יציאה: 80
  6. לוחצים על יצירה.
  7. בקטע New backend (מערכת עורפית חדשה):
    1. מגדירים את Instance group ל-l7-ilb-backend-example.
    2. מגדירים את ניוד מספרים ל-80.
    3. מגדירים את Balancing mode (מצב איזון) לערך Utilization (ניצול).
    4. לוחצים על סיום.

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

    1. כדי לבטל את ההצטרפות למדיניות האבטחה שמוגדרת כברירת מחדל ב-Cloud Armor, בוחרים באפשרות None ברשימה Cloud Armor backend security policy.
    2. כדי להגדיר את מדיניות האבטחה שמוגדרת כברירת מחדל ב-Cloud Armor, בוחרים באפשרות Default security policy (מדיניות האבטחה שמוגדרת כברירת מחדל) ברשימה Cloud Armor backend security policy (מדיניות האבטחה של העורף האחורי ב-Cloud Armor).
    3. בשדה Policy name, מאשרים את השם שנוצר באופן אוטומטי או מזינים שם למדיניות האבטחה.
    4. בשדה Request count (מספר הבקשות), מאשרים את מספר הבקשות שמוגדר כברירת מחדל או מזינים מספר שלם בין 1 ל-10,000.
    5. בשדה Interval, בוחרים מרווח.
    6. בשדה Enforce on key (החלת האכיפה על מפתח), בוחרים באחד מהערכים הבאים: All (הכול), IP address (כתובת IP) או X-Forwarded-For IP address (כתובת ה-IP של X-Forwarded-For). מידע נוסף על האפשרויות האלה זמין במאמר בנושא זיהוי לקוחות להגבלת קצב.
  9. לוחצים על יצירה.

הגדרת מפת URL

  1. לוחצים על Host and path rules (כללים לגבי מארח ונתיב).

  2. בקטע Mode (מצב), בוחרים באפשרות Simple host and path rule (כלל פשוט של מארח ונתיב).

  3. מוודאים ש-l7-ilb-backend-service הוא השירות היחיד לקצה עורפי לכל מארח שלא תואם ולכל נתיב שלא תואם.

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

הגדרת הקצה הקדמי

ל-HTTP:

  1. לוחצים על Frontend configuration.
  2. מגדירים את השם של כלל ההעברה ל-l7-ilb-forwarding-rule.
  3. מגדירים את Protocol לערך HTTP.
  4. מגדירים את Subnetwork לערך backend-subnet.
  5. מגדירים את Port ל-80.
  6. ברשימה כתובת IP, בוחרים באפשרות l7-ilb-ip-address.
  7. לוחצים על סיום.

ל-HTTPS:

  1. לוחצים על Frontend configuration.
  2. מגדירים את השם של כלל ההעברה ל-l7-ilb-forwarding-rule.
  3. מגדירים את Protocol לערך HTTPS (includes HTTP/2).
  4. מגדירים את Subnetwork לערך backend-subnet.
  5. מוודאים שהיציאה מוגדרת ל-443, כדי לאפשר תנועה ב-HTTPS.
  6. ברשימה כתובת IP, בוחרים באפשרות l7-ilb-ip-address.

  7. כדי להקצות אישור SSL לשרת ה-proxy של HTTPS של מאזן העומסים, אפשר להשתמש באישור SSL של Compute Engine או באישור של Certificate Manager.

    1. כדי לצרף אישור של Certificate Manager ל-Proxy היעד של HTTPS במאזן העומסים, בקטע Choose certificate repository בוחרים באפשרות Certificates.

      אם כבר יש לכם אישור קיים של Certificate Manager שאתם רוצים לבחור, אתם צריכים לפעול באופן הבא:

      1. לוחצים על הוספת אישור.
      2. לוחצים על Select an existing certificate (בחירת אישור קיים) ובוחרים את האישור מתוך רשימת האישורים.
      3. לוחצים על בחירה.

      אחרי שבוחרים את האישור החדש של Certificate Manager, הוא מופיע ברשימת האישורים.

      כדי ליצור אישור חדש ב-Certificate Manager:

      1. לוחצים על הוספת אישור.
      2. לוחצים על יצירת אישור חדש.

      3. כדי ליצור אישור חדש, פועלים לפי השלבים שמתחילים משלב 3, כפי שמתואר באחת משיטות ההגדרה הבאות במסמכי התיעוד של Certificate Manager:

      אחרי שיוצרים את האישור החדש ב-Certificate Manager, הוא מופיע ברשימת האישורים.

    2. כדי לצרף אישור SSL של Compute Engine לשרת ה-proxy של HTTPS של מאזן העומסים, בקטע Choose certificate repository בוחרים באפשרות Classic Certificates.

      1. ברשימה Certificate (אישור), מבצעים את הפעולות הבאות:
        1. אם כבר יש לכם משאב של אישור SSL בניהול עצמי ב-Compute Engine, בוחרים את אישור ה-SSL הראשי.
        2. לוחצים על יצירת אישור חדש.
          1. בשדה שם מזינים l7-ilb-cert.
          2. בשדות המתאימים, מעלים את הקבצים בפורמט PEM:
            • אישור
            • מפתח פרטי
          3. לוחצים על יצירה.
        3. אופציונלי: כדי להוסיף אישורים בנוסף לאישור ה-SSL הראשי:
          1. לוחצים על הוספת אישור.
          2. אם כבר יש לכם אישור, בוחרים אותו מהרשימה אישורים.
          3. אופציונלי: לוחצים על יצירת אישור חדש ופועלים לפי ההוראות שצוינו בשלב הקודם.

  8. בוחרים מדיניות SSL מהרשימה מדיניות SSL. אופציונלי: כדי ליצור מדיניות SSL, מבצעים את הפעולות הבאות:

    1. ברשימה SSL policy (מדיניות SSL), בוחרים באפשרות Create a policy (יצירת מדיניות).
    2. מזינים שם למדיניות ה-SSL.
    3. בוחרים גרסת TLS מינימלית. ערך ברירת המחדל הוא TLS 1.0.
    4. בוחרים אחד מהפרופילים המנוהלים על ידי Google שהוגדרו מראש, או בוחרים פרופיל בהתאמה אישית שמאפשר לבחור תכונות SSL בנפרד. מוצגות האפשרויות תכונות מופעלות ותכונות מושבתות.
    5. לוחצים על Save.

    אם לא יצרתם מדיניות SSL, תחול מדיניות SSL שמוגדרת כברירת מחדל Google Cloud .

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

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

  1. לוחצים על Review and finalize.
  2. בודקים את הגדרות ההגדרה של מאזן העומסים.
  3. אופציונלי: לוחצים על Equivalent code (קוד מקביל) כדי לראות את בקשת API בארכיטקטורת REST שתשמש ליצירת מאזן העומסים.
  4. לוחצים על יצירה.

gcloud

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

     gcloud compute health-checks create http l7-ilb-basic-check \
     --region=us-west1 \
     --use-serving-port

  2. מגדירים את שירות לקצה העורפי באמצעות הפקודה gcloud compute backend-services create.

    gcloud compute backend-services create l7-ilb-backend-service \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-basic-check \
    --health-checks-region=us-west1 \
    --region=us-west1

  3. מוסיפים קצה עורפי לשירות הקצה העורפי באמצעות הפקודה gcloud compute backend-services add-backend.

    gcloud compute backend-services add-backend l7-ilb-backend-service \
    --balancing-mode=UTILIZATION \
    --instance-group=l7-ilb-backend-example \
    --instance-group-zone=us-west1-a \
    --region=us-west1

  4. יוצרים את מפת ה-URL באמצעות הפקודה gcloud compute url-maps create.

    gcloud compute url-maps create l7-ilb-map \
    --default-service=l7-ilb-backend-service \
    --region=us-west1

  5. יוצרים את שרת ה-proxy של היעד.

    ל-HTTP:

    כדי ליצור שרת proxy ליעד עבור מאזן עומסים פנימי של HTTP, משתמשים בפקודה gcloud compute target-http-proxies create.

    gcloud compute target-http-proxies create l7-ilb-proxy \
    --url-map=l7-ilb-map \
    --url-map-region=us-west1 \
    --region=us-west1

    ל-HTTPS:

    אתם יכולים ליצור אישורים של Compute Engine או של Certificate Manager. אפשר להשתמש בכל אחת מהשיטות הבאות כדי ליצור אישורים באמצעות Certificate Manager:

    אחרי שיוצרים אישורים, מצרפים אותם ישירות לשרת ה-proxy של היעד.

    מקצים את נתיבי הקבצים לשמות של משתנים.

    export LB_CERT=path to PEM-formatted file

    export LB_PRIVATE_KEY=path to PEM-formatted file

    יוצרים אישור SSL אזורי באמצעות הפקודה gcloud compute ssl-certificates create.

    gcloud compute ssl-certificates create l7-ilb-cert \
    --certificate=$LB_CERT \
    --private-key=$LB_PRIVATE_KEY \
    --region=us-west1

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

    gcloud compute target-https-proxies create l7-ilb-proxy \
    --url-map=l7-ilb-map \
    --region=us-west1 \
    --ssl-certificates=l7-ilb-cert

  6. יוצרים את כלל ההעברה.

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

    ל-HTTP:

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

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=l7-ilb-ip-address \
    --ports=80 \
    --region=us-west1 \
    --target-http-proxy=l7-ilb-proxy \
    --target-http-proxy-region=us-west1

    ל-HTTPS:

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

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=l7-ilb-ip-address \
    --ports=443 \
    --region=us-west1 \
    --target-https-proxy=l7-ilb-proxy \
    --target-https-proxy-region=us-west1

API

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/{region}/healthChecks

{
"name": "l7-ilb-basic-check",
"type": "HTTP",
"httpHealthCheck": {
  "portSpecification": "USE_SERVING_PORT"
}
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices

{
"name": "l7-ilb-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/us-west1-a/instanceGroups/l7-ilb-backend-example",
    "balancingMode": "UTILIZATION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/us-west1/healthChecks/l7-ilb-basic-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/urlMaps

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/regions/us-west1/backendServices/l7-ilb-backend-service"
}

ל-HTTP:

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/targetHttpProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"region": "us-west1"
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
"name": "l7-ilb-forwarding-rule",
"IPAddress": "IP_ADDRESS",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/regions/us-west1/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/us-west1/subnetworks/backend-subnet",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"networkTier": "PREMIUM"
}

ל-HTTPS:

אתם יכולים ליצור אישורים של Compute Engine או של Certificate Manager. אפשר להשתמש בכל אחת מהשיטות הבאות כדי ליצור אישורים באמצעות Certificate Manager:

אחרי שיוצרים אישורים, מצרפים אותם ישירות לשרת ה-proxy של היעד.

קוראים את קובצי האישור והמפתח הפרטי, ואז יוצרים את אישור ה-SSL. בדוגמה הבאה אפשר לראות איך עושים את זה באמצעות Python.

from pathlib import Path
from pprint import pprint
from typing import Union

from googleapiclient import discovery


def create_regional_certificate(
    project_id: str,
    region: str,
    certificate_file: Union[str, Path],
    private_key_file: Union[str, Path],
    certificate_name: str,
    description: str = "Certificate created from a code sample.",
) -> dict:
    """
    Create a regional SSL self-signed certificate within your Google Cloud project.

    Args:
        project_id: project ID or project number of the Cloud project you want to use.
        region: name of the region you want to use.
        certificate_file: path to the file with the certificate you want to create in your project.
        private_key_file: path to the private key you used to sign the certificate with.
        certificate_name: name for the certificate once it's created in your project.
        description: description of the certificate.

        Returns:
        Dictionary with information about the new regional SSL self-signed certificate.
    """
    service = discovery.build("compute", "v1")

    # Read the cert into memory
    with open(certificate_file) as f:
        _temp_cert = f.read()

    # Read the private_key into memory
    with open(private_key_file) as f:
        _temp_key = f.read()

    # Now that the certificate and private key are in memory, you can create the
    # certificate resource
    ssl_certificate_body = {
        "name": certificate_name,
        "description": description,
        "certificate": _temp_cert,
        "privateKey": _temp_key,
    }
    request = service.regionSslCertificates().insert(
        project=project_id, region=region, body=ssl_certificate_body
    )
    response = request.execute()
    pprint(response)

    return response

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/regionTargetHttpsProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/regions/us-west1/urlMaps/l7-ilb-map",
"sslCertificates": /projects/PROJECT_ID/regions/us-west1/sslCertificates/SSL_CERT_NAME
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
"name": "l7-ilb-forwarding-rule",
"IPAddress": "IP_ADDRESS",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/regions/us-west1/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/us-west1/subnetworks/backend-subnet",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"networkTier": "PREMIUM",
}

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

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

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

המסוף

  1. נכנסים לדף VM instances במסוף Google Cloud .

    כניסה לדף VM instances

  2. לוחצים על Create instance.

  3. מגדירים את Name לערך l7-ilb-client-us-west1-a.

  4. מגדירים את Zone לערך us-west1-a.

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

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

    1. בשדה Network tags (תגי רשת), מזינים allow-ssh.
    2. בקטע Network interfaces (ממשקי רשת), בוחרים באפשרויות הבאות:
      1. רשת: lb-network
      2. Subnet: backend-subnet

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

gcloud 

  gcloud compute instances create l7-ilb-client-us-west1-a \
      --image-family=debian-12 \
      --image-project=debian-cloud \
      --network=lb-network \
      --subnet=backend-subnet \
      --zone=us-west1-a \
      --tags=allow-ssh

הפניית תנועה למאזן העומסים

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

מתחברים לכל מופע לקוח באמצעות SSH

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

איך מוצאים את כתובת ה-IP של מאזן העומסים

משתמשים בפקודה gcloud compute addresses describe כדי לראות את כתובת ה-IP שהוקצתה:

gcloud compute addresses describe l7-ilb-ip-address \
    --region=us-west1

אימות כתובת ה-IP שמשרתת את שם המארח

מחליפים את IP_ADDRESS בכתובת ה-IP של מאזן העומסים.

בבדיקות HTTP:

curl IP_ADDRESS

לצורך בדיקת HTTPS:

curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:IP_ADDRESS:443

מחליפים את DOMAIN_NAME בשם הדומיין של האפליקציה, לדוגמה, test.example.com.

הדגל -k גורם ל-curl לדלג על אימות האישור.

מריצים 100 בקשות ומוודאים שהן מאוזנות

מחליפים את IP_ADDRESS בכתובת ה-IP של מאזן העומסים.

ל-HTTP:

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

ל-HTTPS:

מחליפים את DOMAIN_NAME בשם הדומיין של האפליקציה, לדוגמה, test.example.com.

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

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

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

הפעלה של גישה גלובלית

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

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

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

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

המסוף

יוצרים כלל העברה חדש למאזן העומסים:

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

    כניסה לדף איזון עומסים

  2. בעמודה Name (שם), לוחצים על מאזן העומסים.

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

  4. לוחצים על Add frontend IP and port.

  5. מזינים את השם ואת פרטי רשת המשנה של כלל ההעברה החדש.

  6. בשדה רשת משנה, בוחרים באפשרות backend-subnet.

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

  8. בשדה מספר היציאה, מזינים 110.

  9. בקטע גישה גלובלית, בוחרים באפשרות הפעלה.

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

  11. לוחצים על עדכון.

gcloud

  1. יוצרים כלל העברה חדש למאזן העומסים עם הדגל --allow-global-access.

    ל-HTTP:

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule-global-access \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=10.1.2.99 \
    --ports=80 \
    --region=us-west1 \
    --target-http-proxy=l7-ilb-proxy \
    --target-http-proxy-region=us-west1 \
    --allow-global-access

    ל-HTTPS:

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule-global-access \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=10.1.2.99 \
    --ports=443 \
    --region=us-west1 \
    --target-https-proxy=l7-ilb-proxy \
    --target-https-proxy-region=us-west1 \
    --allow-global-access

  2. אפשר להשתמש בפקודה gcloud compute forwarding-rules describe כדי לבדוק אם הגישה הגלובלית מופעלת בכלל העברה. לדוגמה:

     gcloud compute forwarding-rules describe l7-ilb-forwarding-rule-global-access \
     --region=us-west1 \
     --format="get(name,region,allowGlobalAccess)"

    כשהגישה הגלובלית מופעלת, המילה True מופיעה בפלט אחרי השם והאזור של כלל ההעברה.

יצירת מכונה וירטואלית של לקוח לבדיקת גישה גלובלית

המסוף

  1. נכנסים לדף VM instances במסוף Google Cloud .

    כניסה לדף VM instances

  2. לוחצים על Create instance.

  3. מגדירים את Name לערך europe-client-vm.

  4. מגדירים את Zone לערך europe-west1-b.

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

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

    1. בשדה Network tags (תגי רשת), מזינים allow-ssh.
    2. בקטע Network interfaces (ממשקי רשת), בוחרים באפשרויות הבאות:
      • רשת: lb-network
      • Subnet: europe-subnet

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

gcloud

יוצרים מכונה וירטואלית של לקוח באזור europe-west1-b.

gcloud compute instances create europe-client-vm \
    --zone=europe-west1-b \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=europe-subnet

התחברות ללקוח ה-VM ובדיקת הקישוריות

  1. משתמשים ב-ssh כדי להתחבר למכונת הלקוח.

    gcloud compute ssh europe-client-vm \
    --zone=europe-west1-b

  2. בודקים את החיבורים למאזן העומסים כמו שעשיתם מ-vm-client באזור us-west1.

    curl http://10.1.2.99

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

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

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

כשהזיקה לשדה הכותרת מופעלת, מאזן העומסים מנתב בקשות למכונות וירטואליות (VM) או לנקודות קצה בעורף הרשת בקבוצת נקודות קצה ברשת (NEG) על סמך הערך של כותרת ה-HTTP שצוינה בדגל --custom-request-header. הזיקה לשדה כותרת תקפה רק אם מדיניות המיקום של איזון העומסים היא RING_HASH או MAGLEV, וגיבוב עקבי של שירות לקצה העורפי מציין את השם של כותרת ה-HTTP.

כשמפעילים את ההגדרה 'שמירת העדפות (Affinity) של קובצי Cookie מסוג HTTP', מאזן העומסים מנתב בקשות למכונות וירטואליות או לנקודות קצה בעורף הרשת ב-NEG, על סמך קובץ Cookie מסוג HTTP ששמו מצוין בדגל HTTP_COOKIE עם הדגל האופציונלי --affinity-cookie-ttl. אם הלקוח לא מספק את קובץ ה-Cookie בבקשת ה-HTTP שלו, ה-proxy יוצר את קובץ ה-Cookie ומחזיר אותו ללקוח בכותרת Set-Cookie. הזיקה לקובץ Cookie של HTTP תקפה רק אם מדיניות המיקום של איזון העומסים היא RING_HASH או MAGLEV, וגיבוב עקבי של שירות הקצה העורפי מציין את קובץ ה-Cookie של HTTP.

המסוף

כדי להפעיל או לשנות את הזיקה לסשן (session affinity) בשירות לקצה העורפי:

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

    כניסה לדף איזון עומסים

  2. לוחצים על Backends.
  3. לוחצים על l7-ilb-backend-service (השם של שירות ה-Backend שיצרתם בדוגמה הזו) ואז על Edit.
  4. בדף Backend service details (פרטי שירות לקצה העורפי), לוחצים על Advanced configuration (הגדרות מתקדמות).
  5. בקטע Session affinity (העדפה לסשן), בוחרים את סוג ההעדפה לסשן שרוצים.
  6. לוחצים על עדכון.

gcloud

משתמשים בפקודות הבאות של Google Cloud CLI כדי לעדכן את שירות הקצה העורפי לסוגים שונים של זיקה לסשן (session affinity):

    gcloud compute backend-services update l7-ilb-backend-service \
        --session-affinity=[GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | CLIENT_IP] \
        --region=us-west1

API

כדי להגדיר את הזיקה לסשן, שולחים בקשת `PATCH` אל ה-method‏ backendServices/patch.

    PATCH https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/regionBackendServices/l7-ilb-backend-service
    {
      "sessionAffinity": ["GENERATED_COOKIE" | "HEADER_FIELD" | "HTTP_COOKIE" | "CLIENT_IP" ]
    }

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

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

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

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

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

המסוף

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

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

כלל חומת אש יחיד לתעבורת נתונים יוצאת

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

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

    מעבר לכללי חומת אש

  2. לוחצים על יצירת כלל חומת אש כדי ליצור את הכלל לדחיית תעבורת נתונים יוצאת (egress) ממכונות וירטואליות של לקוחות עם תגים אל כתובת ה-IP הווירטואלית של מאזן העומסים.

    • Name (שם): fr-deny-access
    • רשת: lb-network
    • עדיפות: 100
    • כיוון התנועה: תעבורת נתונים יוצאת
    • פעולה לגבי התאמה: דחייה
    • יעדים: תגי יעד שצוינו
    • תגי טירגוט: TARGET_TAG
    • מסנן יעד: טווחי כתובות IP
    • טווחי כתובות IP של היעד: 10.1.2.99
    • פרוטוקולים ויציאות:
      • בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
      • מסמנים את התיבה tcp ומזינים את מספר היציאה 80.

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

מספר כללים לחומת אש לתעבורת נתונים יוצאת

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

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

    מעבר לכללי חומת אש

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

    • Name (שם): fr-deny-all-access-low-priority
    • רשת: lb-network
    • עדיפות: 200
    • כיוון התנועה: תעבורת נתונים יוצאת
    • פעולה לגבי התאמה: דחייה
    • יעדים: תגי יעד שצוינו
    • תגי טירגוט: TARGET_TAG
    • מסנן יעד: טווחי כתובות IP
    • טווחי כתובות IP של היעד: 10.1.2.99
    • פרוטוקולים ויציאות:
      • בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
      • מסמנים את התיבה TCP ומזינים 80 כמספר היציאה.

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

  4. לוחצים על יצירת כלל לחומת האש כדי ליצור את הכלל עם העדיפות הגבוהה יותר, שיאפשר תעבורה ממופעים מסוימים עם תגים.

    • Name (שם): fr-allow-some-access-high-priority
    • רשת: lb-network
    • עדיפות: 100
    • כיוון התנועה: תעבורת נתונים יוצאת
    • פעולה במקרה של התאמה: אישור
    • יעדים: תגי יעד שצוינו
    • תגי טירגוט: TARGET_TAG
    • מסנן יעד: טווחי כתובות IP
    • טווחי כתובות IP של היעד: 10.1.2.99
    • פרוטוקולים ויציאות:
      • בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
      • מסמנים את התיבה TCP ומזינים 80 כמספר היציאה.

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

gcloud

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

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

כלל חומת אש יחיד לתעבורת נתונים יוצאת

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

gcloud compute firewall-rules create fr-deny-access \
    --network=lb-network \
    --action=deny \
    --direction=egress \
    --rules=tcp \
    --priority=100 \
    --destination-ranges=10.1.2.99 \
    --target-tags=TARGET_TAG

מספר כללים לחומת אש לתעבורת נתונים יוצאת

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

  1. יוצרים את הכלל עם העדיפות הנמוכה יותר:

    gcloud compute firewall-rules create fr-deny-all-access-low-priority \
    --network=lb-network \
    --action=deny \
    --direction=egress \
    --rules=tcp \
    --priority=200 \
    --destination-ranges=10.1.2.99

  2. יוצרים את הכלל עם העדיפות הגבוהה יותר:

    gcloud compute firewall-rules create fr-allow-some-access-high-priority \
    --network=lb-network \
    --action=allow \
    --direction=egress \
    --rules=tcp \
    --priority=100 \
    --destination-ranges=10.1.2.99 \
    --target-tags=TARGET_TAG

כדי להשתמש בחשבונות שירות במקום בתגים כדי לשלוט בגישה, משתמשים באפשרות --target-service-accounts במקום בדגל --target-tags כשיוצרים כללי חומת אש.

הגבלת הגישה לשרתי קצה עורפיים של מאזן עומסים פנימי של אפליקציות (ALB) על סמך רשתות משנה

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

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

gcloud

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

    gcloud compute networks subnets create l7-ilb-restricted-subnet \
    --network=lb-network \
    --region=us-west1 \
    --range=10.127.0.0/24

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

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule-restricted \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=l7-ilb-restricted-subnet \
    --address=10.127.0.1 \
    --ports=80 \
    --region=us-west1 \
    --target-http-proxy=l7-ilb-proxy \
    --target-http-proxy-region=us-west1

  3. יוצרים כלל חומת אש שמגביל את התעבורה שמיועדת לטווח כתובות ה-IP ברשת המשנה של כלל ההעברה (l7-ilb-restricted-subnet):

    gcloud compute firewall-rules create restrict-traffic-to-subnet \
    --network=lb-network \
    --action=deny \
    --direction=egress \
    --rules=tcp:80 \
    --priority=100 \
    --destination-ranges=10.127.0.0/24 \
    --target-tags=TARGET_TAG

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

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

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

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

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

  1. משתמשים בהגדרת הדוגמה כדי ליצור שירות קצה עורפי אזורי l7-ilb-backend-service.

  2. מפעילים חלוקה למערכי משנה של ה-backend על ידי הגדרת הדגל --subsetting-policy לערך CONSISTENT_HASH_SUBSETTING. מגדירים את סכימת איזון העומסים לערך INTERNAL_MANAGED.

    gcloud

    משתמשים בפקודה gcloud הבאה כדי לעדכן את l7-ilb-backend-service עם חלוקת משנה של ה-Backend:

    gcloud beta compute backend-services update l7-ilb-backend-service \
    --region=us-west1 \
    --subsetting-policy=CONSISTENT_HASH_SUBSETTING

    API

    שולחים בקשת PATCH אל ה-method‏ regionBackendServices/patch.

    PATCH https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/regions/us-west1/backendServices/l7-ilb-backend-service

{
 "subsetting":
{
 "policy": CONSISTENT_HASH_SUBSETTING
}
}

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

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

עדכון פסק הזמן של שמירת החיבור ב-HTTP

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

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

המסוף

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

    כניסה לדף איזון עומסים

  2. לוחצים על השם של מאזן העומסים שרוצים לשנות.
  3. לוחצים על עריכה.
  4. לוחצים על Frontend configuration.
  5. מרחיבים את תכונות מתקדמות. בשדה HTTP keepalive timeout, מזינים ערך של זמן קצוב לתפוגה.
  6. לוחצים על עדכון.
  7. כדי לבדוק את השינויים, לוחצים על בדיקה וסיום ואז על עדכון.

gcloud

במאזן עומסים מסוג HTTP, מעדכנים את ה-proxy של יעד ה-HTTP באמצעות הפקודה gcloud compute target-http-proxies update.

      gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --region=REGION

במאזן עומסים מסוג HTTPS, מעדכנים את שרת ה-proxy של HTTPS באמצעות הפקודה gcloud compute target-https-proxies update.

      gcloud compute target-https-proxies update TARGET_HTTP_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --region REGION

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

  • ‫TARGET_HTTP_PROXY_NAME: השם של ה-proxy ל-HTTP של היעד.
  • ‫TARGET_HTTPS_PROXY_NAME: השם של שרת ה-proxy ל-HTTPS של היעד.
  • ‫HTTP_KEEP_ALIVE_TIMEOUT_SEC: ערך הזמן הקצוב לתפוגה של HTTP keepalive, מ-5 עד 600 שניות.

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