תת-רשתות של שרת proxy בלבד למאזני עומסים מבוססי Envoy

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

ה-proxies מסיימים את החיבורים הנכנסים ואז מעריכים לאן כל בקשה צריכה להגיע על סמך מפת URL, זיקה לסשן (session affinity) של שירות לקצה העורפי, מצב האיזון של כל קבוצת שרתים עורפיים (backend instances) או NEG וגורמים אחרים.

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

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

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

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

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

מאזני עומסים ומוצרים נתמכים

מוצרים של Cloud Load Balancing ו-Secure Web Proxy שמבוססים על Envoy דורשים רשתות משנה של שרת Proxy בלבד:

איך תת-רשתות של שרת proxy בלבד משתלבות בארכיטקטורה של מאזן העומסים

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

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

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

  • המכונות הווירטואליות של הבק-אנד ונקודות הקצה של הבק-אנד במאזן העומסים משתמשות ברשת משנה אחת, שטווח כתובות ה-IP הראשי שלה הוא 10.1.2.0/24 (בדוגמה הזו). רשת משנה זו אינה רשת המשנה של השרת proxy בלבד. אתם יכולים להשתמש בכמה רשתות משנה עבור מכונות ה-VM של הקצה העורפי ונקודות הקצה, אם רשתות המשנה נמצאות באותו אזור כמו מאזן העומסים. במאזני עומסים פנימיים של אפליקציות, כתובת ה-IP של מאזן העומסים שמשויכת לכלל ההעברה יכולה להיות גם בתת-הרשת הזו (אבל לא חייבת).
  • רשת המשנה של ה-proxy בלבד היא 10.129.0.0/23 (בדוגמה הזו).

תכנון הגודל של רשת המשנה לשרת proxy בלבד

תת-רשת של שרת proxy בלבד צריכה לספק 64 כתובות IP או יותר. המשמעות היא שאורך הקידומת הוא /26 או פחות. מומלץ להתחיל עם רשת משנה (subnet) של פרוקסי בלבד עם קידומת /23 (512 כתובות של פרוקסי בלבד) ולשנות את הגודל בהתאם לשינויים בצרכים של תנועת הגולשים.

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

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

  • מספר השרתים הפרוקסי שנדרשים כדי לספק את רוחב הפס שנדרש לתנועה. כל מופע של שרת proxy יכול לטפל בעד 18MB לשנייה. אנחנו עוקבים אחרי רוחב הפס הכולל שנדרש ומחלקים את הסכום הזה ברוחב הפס שמופע של שרת proxy יכול לתמוך בו.

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

    • ‫600 (HTTP) או 150 (HTTPS) חיבורים חדשים בשנייה
    • ‫3,000 חיבורים פעילים

    • ‫1,400 בקשות לשנייה

      מופע של שרת proxy יכול לטפל ב-1,400 בקשות בשנייה אם Cloud Logging מושבת. אם מפעילים את האפשרות Logging (רישום ביומן), מופע ה-proxy יכול לטפל בפחות בקשות בשנייה. לדוגמה: אם מתבצעת רישום ביומן של 100% מהבקשות, יכולת הטיפול בבקשות של ה-proxy יורדת ל-700 בקשות בשנייה. אפשר להגדיר את Logging כך שידגום אחוז קטן יותר של תעבורה. כך תוכלו לענות על צורכי הנראות שלכם ולשלוט בעלויות.

כל פרוקסי נוסף כרוך בחיוב נוסף לשעה. בקטע חיוב על מופע proxy במסמכי התמחור של Cloud Load Balancing מוסבר איך מתבצע החיוב על רשתות משנה של proxy בלבד.

מאזני עומסים מבוססי Envoy ושרתי proxy של Secure Web Proxy Envoy

כשמגדירים גם מאזן עומסים מבוסס-Envoy וגם Secure Web Proxy באותו VPC, חשוב לשים לב לנקודות הבאות:

  • גם מאזן העומסים שמבוסס על Envoy וגם Secure Web Proxy משתמשים בכתובות IP מאותה רשת משנה של שרת proxy בלבד.

  • כדי לעמוד בדרישות של כתובות ה-IP בשני השירותים, כדאי לשקול להשתמש בתת-רשת גדולה יותר של פרוקסי בלבד, למשל תת-רשת /22. כך אפשר לוודא שיש מספיק מרחב כתובות לשתי ההגדרות.

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

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

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

בתת-רשת של שרת proxy בלבד, הערך של --purpose צריך להיות REGIONAL_MANAGED_PROXY או GLOBAL_MANAGED_PROXY, בהתאם למאזן העומסים (LB).

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

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

המסוף

  1. נכנסים לדף VPC networks במסוף Google Cloud .
    לדף VPC networks
  2. לוחצים על השם של רשת ה-VPC המשותפת שרוצים להוסיף לה רשת משנה מסוג proxy בלבד.
  3. לוחצים על הוספת רשת משנה.
  4. מזינים שם.
  5. בוחרים אזור.
  6. מגדירים את המטרה לאחת מהאפשרויות הבאות:
    • למאזני עומסים אזוריים: שרת proxy מנוהל אזורי
    • למאזני עומסים בכמה אזורים: שרת proxy מנוהל בכמה אזורים
    • מזינים טווח כתובות IP.
    • לוחצים על הוספה.

gcloud

הפקודה gcloud compute networks subnets create יוצרת רשת משנה מסוג proxy בלבד.

gcloud compute networks subnets create SUBNET_NAME \
    --purpose=SUBNET_PURPOSE \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK_NAME \
    --range=CIDR_RANGE

השדות מוגדרים כך:

  • ‫SUBNET_NAME הוא השם של רשת המשנה שמוגדרת רק לשרת proxy.
  • ‫SUBNET_PURPOSE היא המטרה של רשת המשנה. מגדירים את הערך ל-או ל-REGIONAL_MANAGED_PROXY או ל-GLOBAL_MANAGED_PROXY, בהתאם למאזן העומסים.
  • ‫REGION הוא האזור של תת-הרשת של שרת ה-proxy בלבד.
  • ‫VPC_NETWORK_NAME הוא השם של רשת ה-VPC שמכילה את רשת המשנה.
  • ‫CIDR_RANGE הוא טווח כתובות ה-IP הראשי של רשת המשנה. חובה להשתמש במסכה של רשת משנה באורך של 26 לכל היותר, כדי שיהיו לפחות 64 כתובות IP זמינות לשרתי proxy באזור. האורך המומלץ של מסכה של רשת משנה הוא /23.

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

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

זמינות ה-Proxy

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

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

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

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

אי אפשר להרחיב את טווח כתובות ה-IPv4 הראשי של תת-רשת מסוג proxy-only באותו אופן שבו מרחיבים את טווח כתובות ה-IPv4 הראשי של תת-רשת רגילה (באמצעות הפקודה expand-ip-range). במקום זאת, צריך להחליף את רשת המשנה של ה-proxy ברשת משנה חדשה. תהליך ההחלפה פועל כך:

  • יוצרים רשת משנה חדשה מסוג proxy-only, באותו אזור ובאותה רשת VPC כמו רשת המשנה הקיימת (המקורית) מסוג proxy-only. כשיוצרים את רשת המשנה החדשה הזו שהיא רק פרוקסי, מגדירים את role שלה ל-BACKUP. לכל מטרה של תת-רשת מסוג proxy בלבד, Google Cloud אפשר להגדיר תת-רשת אחת מסוג ACTIVE ותת-רשת אחת מסוג BACKUP proxy בלבד באזור נתון וברשת VPC נתונה).

  • משנים את כללי חומת האש שחלים על השרתים העורפיים (backend) כך שיאפשרו חיבורים מטווחי כתובות ה-IPv4 הראשיים של תתי-הרשתות המקוריות ושל תתי-הרשתות החדשות של שרתי proxy בלבד.

  • מגדירים את התפקיד של תת-הרשת החדשה של שרת ה-proxy ל-ACTIVE ומציינים תקופת ניקוז כדי לאפשר לחיבורים בין השרתים העורפיים (backend) לבין שרתי ה-proxy של Envoy בתת-הרשת המקורית של שרת ה-proxy להסתיים. ‫(Google Cloud automatically sets the role of the original proxy-only subnet to BACKUP when you set the role of the new proxy-only subnet to ACTIVE.)

  • עוקבים אחרי הסטטוס של רשת המשנה המקורית של ה-proxy בלבד (מידע נוסף על מעקב זמין בכרטיסייה gcloud). אחרי שהסטטוס שלו יהיה READY, לא יהיה יותר שימוש ברשת המשנה, בתנאי שהתפקיד שלה הוא BACKUP. בשלב הזה, אפשר לשנות את כללי חומת האש של תעבורת נתונים נכנסת כדי לאפשר חיבורים רק מטווחי כתובות ה-IPv4 הראשיות של תת-הרשת החדשה של שרת ה-proxy בלבד, ולמחוק את תת-הרשת המקורית של שרת ה-proxy בלבד.

המסוף

  1. יוצרים את רשת המשנה החדשה מסוג proxy בלבד באותו אזור ובאותה רשת VPC, ומציינים טווח כתובות IPv4 ראשי שמתאים לצרכים שלכם. מגדירים את התפקיד של רשת המשנה החדשה לגיבוי בלבד.

    1. נכנסים לדף VPC networks במסוף Google Cloud .
      לדף VPC networks
    2. לוחצים על השם של רשת ה-VPC המשותפת שרוצים להוסיף לה רשת משנה מסוג proxy בלבד.
    3. לוחצים על הוספת רשת משנה.
    4. מזינים שם.
    5. בוחרים אזור.
    6. מגדירים את המטרה לאחת מהאפשרויות הבאות:
      • למאזני עומסים אזוריים: שרת proxy מנוהל אזורי
      • למאזני עומסים בכמה אזורים: שרת proxy מנוהל בכמה אזורים
      • בשדה Role (תפקיד), בוחרים באפשרות Backup (גיבוי).
      • מזינים טווח כתובות IP.
      • לוחצים על הוספה.

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

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

    1. נכנסים לדף VPC networks במסוף Google Cloud .
      לדף VPC networks
    2. לוחצים על השם של רשת ה-VPC המשותפת שרוצים לשנות.
    3. בקטע Reserved proxy-only subnets for load balancing (רשתות משנה שמורות לשימוש פרוקסי בלבד לצורך איזון עומסים), מאתרים את רשת המשנה לגיבוי שנוצרה בשלב הקודם.
    4. לוחצים על הפעלה.
    5. מציינים זמן קצוב לתפוגה של התרוקנות (אופציונלי).
    6. לוחצים על הפעלת רשת המשנה.

  4. אחרי זמן להשלמת תהליך (connection draining), או אחרי שאתם בטוחים שהחיבורים למכונות הווירטואליות או לנקודות הקצה של ה-Backend לא מגיעים משרתי proxy ברשת המשנה המקורית של ה-proxy בלבד, אתם יכולים לבצע את הפעולות הבאות:

    • מעדכנים את כללי חומת האש של תעבורת נתונים נכנסת (ingress) שחלים על מכונות וירטואליות או על נקודות קצה של בק-אנד (backend) כדי שיכללו את טווח כתובות ה-IPv4 הראשי של רשת המשנה החדשה של שרת proxy בלבד.
    • מוחקים את רשת המשנה המקורית שמוגדרת רק כפרוקסי.

gcloud

בשלבים הבאים מוסבר איך להחליף רשת משנה קיימת מסוג proxy-only ברשת משנה חדשה מסוג proxy-only. בכל השלבים הבאים:

  • ‫ORIGINAL_PROXY_ONLY_SUBNET_NAME: השם של רשת המשנה הקיימת מסוג proxy בלבד
  • ‫ORIGINAL_PROXY_ONLY_SUBNET_RANGE: טווח כתובות ה-IPv4 הראשי של תת-הרשת הקיימת של פרוקסי בלבד בפורמט CIDR. זהו טווח כתובות שבחרתם בעבר.
  • ‫NEW_PROXY_ONLY_SUBNET_NAME: השם של תת-הרשת החדשה מסוג proxy בלבד
  • ‫NEW_PROXY_ONLY_SUBNET_RANGE: טווח כתובות ה-IPv4 הראשי של תת-הרשת החדשה מסוג proxy-only בפורמט CIDR. בוחרים טווח כתובות IPv4 שמתאים לצרכים שלכם.
  • ‫PROXY_ONLY_SUBNET_FIREWALL_RULE: השם של כלל חומת אש של VPC שמאפשר תעבורת נתונים נכנסת (ingress) ומאפשר חיבורים מתת-רשתות של שרת proxy בלבד
  • ‫REGION: האזור שמכיל את רשתות המשנה המקוריות והחדשות מסוג proxy בלבד
  • ‫VPC_NETWORK_NAME: השם של רשת ה-VPC שמכילה את רשתות המשנה המקוריות והחדשות מסוג proxy בלבד

  1. יוצרים רשת משנה חדשה מסוג proxy-only באותו אזור ובאותה רשת VPC באמצעות הפקודה gcloud compute networks subnets create עם הדגל --role=BACKUP.

    gcloud compute networks subnets create NEW_PROXY_ONLY_SUBNET_NAME \
   --purpose=SUBNET_PURPOSE \
   --role=BACKUP \
   --region=REGION \
   --network=VPC_NETWORK_NAME \
   --range=NEW_PROXY_ONLY_SUBNET_RANGE

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

    • ‫SUBNET_PURPOSE: REGIONAL_MANAGED_PROXY או GLOBAL_MANAGED_PROXY, בהתאם למאזן העומסים שצריך להשתמש בתת-הרשת של שרת proxy בלבד. מידע נוסף זמין במאמר בנושא מאזני עומסים נתמכים.

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

    gcloud compute firewall-rules update PROXY_ONLY_SUBNET_FIREWALL_RULE \
  --source-ranges=ORIGINAL_PROXY_ONLY_SUBNET_RANGE,NEW_PROXY_ONLY_SUBNET_RANGE

  3. מגדירים את התפקיד של תת-הרשת החדשה של שרת ה-proxy ל-ACTIVE, ומציינים זמן קצוב לתפוגה של ניתוק החיבורים (--drain-timeout) כדי לאפשר את סיום החיבורים בין השרתים העורפיים לבין תת-הרשת המקורית של שרת ה-proxy. כשמגדירים את התפקיד של תת-הרשת החדשה של שרת ה-proxy ל-ACTIVE,‏Google Cloud מגדיר אוטומטית את התפקיד של תת-הרשת המקורית של שרת ה-proxy ל-BACKUP.

    כדי לנתק באופן מיידי את החיבורים בין השרתים העורפיים לבין שרתי ה-Proxy של Envoy ברשת המשנה המקורית של ה-Proxy בלבד, מגדירים את --drain-timeout לערך 0s.

    gcloud compute networks subnets update NEW_PROXY_ONLY_SUBNET_NAME \
   --region=REGION \
   --role=ACTIVE \
   --drain-timeout=CONNECTION_DRAINING_TIMEOUT

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

    • ‫CONNECTION_DRAINING_TIMEOUT: משך הזמן, בשניות, שבו יסתיימו החיבורים הקיימים בין השרתים העורפיים לבין שרתי ה-proxy של Envoy בתת-הרשת המקורית של שרתי ה-proxy בלבד.

  4. כדי לעקוב אחרי הסטטוס של רשת המשנה המקורית מסוג proxy בלבד, משתמשים בפקודה gcloud compute networks subnets describe.

    gcloud compute networks subnets describe ORIGINAL_PROXY_ONLY_SUBNET_NAME \
   --region=REGION

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

  5. אחרי שרשת המשנה המקורית של ה-proxy בלבד היא READY עם התפקיד BACKUP, רשת המשנה כבר לא בשימוש. מעדכנים את כללי חומת האש של תעבורת נתונים נכנסת (ingress) שחלים על מכונות וירטואליות או על נקודות קצה של שרתים עורפיים (backend) כדי שיכללו את טווח כתובות ה-IPv4 הראשי של תת-הרשת החדשה של שרת proxy בלבד.

    gcloud compute firewall-rules update PROXY_ONLY_SUBNET_FIREWALL_RULE \
  --source-ranges=NEW_PROXY_ONLY_SUBNET_RANGE

  6. מוחקים את רשת המשנה המקורית של ה-proxy בלבד.

    gcloud compute networks subnets delete ORIGINAL_PROXY_ONLY_SUBNET_NAME \
  --region=REGION

העברת המטרה של תת-רשת לשרת proxy בלבד

אם יצרתם בעבר תת-רשת מסוג proxy-only באמצעות --purpose=INTERNAL_HTTPS_LOAD_BALANCER, תצטרכו להעביר את הייעוד של תת-הרשת ל-REGIONAL_MANAGED_PROXY לפני שתוכלו ליצור מאזני עומסים אחרים שמבוססים על Envoy באותו אזור של רשת ה-VPC.

המסוף

אם אתם משתמשים במסוף Google Cloud כדי ליצור את מאזן העומסים, תתבקשו להעביר את הייעוד של רשת משנה שנוצרה בעבר רק בשביל פרוקסי מ---purpose=INTERNAL_HTTPS_LOAD_BALANCER ל-REGIONAL_MANAGED_PROXY במהלך יצירת מאזן העומסים.

gcloud

כדי לשנות את הייעוד של רשת משנה קיימת מסוג proxy-only מ---purpose=INTERNAL_HTTPS_LOAD_BALANCER ל-REGIONAL_MANAGED_PROXY, משתמשים בפקודה הבאה:

gcloud compute networks subnets update PROXY_ONLY_SUBNET \
    --purpose=REGIONAL_MANAGED_PROXY \
    --region=REGION

העברת הייעוד של רשת משנה שמשמשת רק כפרוקסי מ---purpose=INTERNAL_HTTPS_LOAD_BALANCER ל-REGIONAL_MANAGED_PROXY לא גורמת להשבתה. השינוי ייכנס לתוקף כמעט באופן מיידי.

מחיקה של תת-רשת לשרת proxy בלבד

מחיקת רשת משנה ל-Proxy בלבד משחררת את טווח כתובות ה-IP הראשי שלה, כך שאפשר להשתמש בטווח הזה למטרה אחרת. Google Cloud המערכת אוכפת את הכללים הבאים כשהיא מקבלת בקשה למחיקת רשת משנה ל-Proxy בלבד:

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

  • אי אפשר למחוק תת-רשת פעילה מסוג proxy-only אם יש תת-רשת גיבוי מסוג proxy-only באותו אזור ובאותה רשת VPC.

    אם מנסים למחוק רשת משנה פעילה מסוג proxy-only לפני שמוחקים את הגיבוי, מופיעה הודעת השגיאה הבאה: "Invalid resource usage: Cannot delete ACTIVE subnetwork because a BACKUP subnetwork exists" (שימוש לא תקין במשאבים: אי אפשר למחוק רשת משנה פעילה כי קיימת רשת משנה לגיבוי).

בפועל, הכללים האלה משפיעים כך:

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

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

מידע נוסף זמין במאמר בנושא מחיקת רשתות משנה בתיעוד של רשתות VPC.

מגבלות

ההגבלות הבאות חלות על רשתות משנה של שרת proxy בלבד:

  • אי אפשר להשתמש גם ברשת משנה INTERNAL_HTTPS_LOAD_BALANCER וגם ברשת משנה REGIONAL_MANAGED_PROXY באותה רשת ובאותו אזור, בדיוק כמו שאי אפשר להשתמש בשני שרתי proxy מסוג REGIONAL_MANAGED_PROXY או בשני שרתי proxy מסוג INTERNAL_HTTPS_LOAD_BALANCER.

  • בכל אזור בכל רשת VPC אפשר ליצור רק תת-רשת אחת פעילה של שרת proxy ותת-רשת אחת של שרת proxy לגיבוי.

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

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

  • במהלך זמן להשלמת תהליך (connection draining) של רשת משנה מסוג proxy בלבד (--drain-timeout), אי אפשר לשנות את התפקיד של רשת משנה מסוג proxy בלבד מגיבוי לפעיל.

  • רשתות משנה של שרת proxy בלבד לא תומכות ב-VPC Flow Logs.

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