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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יצירת רשתות משנה לשרתי proxy בלבד

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

  • ‫IPV4_ONLY: אתם צריכים להשתמש ברשת משנה עם שרת proxy בלבד אם מאזן העומסים צריך לסיים תנועה ב-IPv4.
  • ‫IPV4_IPV6: אתם צריכים להשתמש בתת-רשת של שרת proxy בלבד עם תמיכה בשני הפרוטוקולים אם מאזן העומסים צריך להפסיק תנועה מסוג IPv4 או IPv6. כדי לתמוך בכלל העברה של IPv6, תת-הרשת של שרת ה-Proxy בלבד צריכה להיות בעלת תמיכה כפולה (dual-stack).

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

בתת-רשת של שרת proxy בלבד, צריך להגדיר את --purpose לערך REGIONAL_MANAGED_PROXY.

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

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

יצירת תת-רשת IPV4-ONLY proxy-only

כדי להגדיר רשת משנה (subnet) של IPV4-ONLY proxy בלבד, פועלים לפי השלבים הבאים:

המסוף

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

gcloud

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

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.
  • ‫REGION: האזור של תת-הרשת של ה-proxy בלבד.
  • ‫VPC_NETWORK_NAME: השם של רשת ה-VPC שמכילה את תת-הרשת.
  • ‫CIDR_RANGE: טווח כתובות ה-IP הראשי של רשת המשנה. חובה להשתמש במסכה של רשת משנה באורך של 26 לכל היותר, כדי שלפחות 64 כתובות IP יהיו זמינות לשרתי proxy באזור. האורך המומלץ של מסכת רשת המשנה הוא /23.

יצירת תת-רשת עם פרוקסי בלבד בתצורת dual-stack

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

  1. יוצרים רשת VPC במצב מותאם אישית עם תת-רשת כפולה. חשוב לוודא את הדברים הבאים:

    • רשת ה-VPC צריכה להשתמש במצב רשת משנה מותאם אישית, --subnet-mode custom.
    • צריך להפעיל את IPv6 פנימי ברשת באמצעות הדגל --enable-ula-internal-ipv6.

  2. יוצרים תת-רשת עם פרוטוקול כפול לשרת proxy בלבד:

    gcloud compute networks subnets create NEW_PROXY_ONLY_SUBNET_NAME \
   --purpose=SUBNET_PURPOSE \
   --role=ACTIVE \
   --region=REGION \
   --network=VPC_NETWORK_NAME \
   --range=NEW_PROXY_ONLY_SUBNET_RANGE \
   --stack-type=IPV4_IPV6

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

    • ‫NEW_PROXY_ONLY_SUBNET_NAME: השם של רשת המשנה של ה-proxy בלבד.
    • ‫SUBNET_PURPOSE: המטרה של תת-הרשת. מגדירים את הערך ל-REGIONAL_MANAGED_PROXY.
    • ‫REGION: האזור של תת-הרשת של ה-proxy בלבד.
    • ‫VPC_NETWORK_NAME: השם של רשת ה-VPC שמכילה את תת-הרשת.
    • ‫NEW_PROXY_ONLY_SUBNET_RANGE: טווח כתובות ה-IPv4 הראשי של רשת המשנה, בסימון CIDR. לדוגמה, 10.1.2.0/24. אי אפשר לציין טווח כתובות IPv6. הטווח מוקצה באופן אוטומטי מתוך טווח ה-ULA (כתובת מקומית ייחודית) של הרשת.

הגדרת כללים לחומת האש של הקצה העורפי

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

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

זמינות ה-Proxy

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

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

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

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

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

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

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

  • מגדירים את התפקיד של תת-הרשת החדשה של שרת proxy בלבד ל-ACTIVE ומציינים תקופת ניתוק כדי לאפשר לחיבורים בין השרתים העורפיים (backend) לבין שרתי ה-proxy של Envoy בתת-הרשת המקורית של שרת proxy בלבד להסתיים. ‫(Cloud de Confiance 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.)

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

המסוף

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

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

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

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

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

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

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

gcloud

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

  • ‫ORIGINAL_PROXY_ONLY_SUBNET_NAME: השם של תת-הרשת הקיימת מסוג proxy בלבד
  • ‫ORIGINAL_PROXY_ONLY_SUBNET_RANGE: טווח כתובות ה-IPv4 הראשי של תת-הרשת הקיימת לשרתי proxy בלבד בפורמט CIDR. זהו טווח כתובות שבחרתם בעבר.
  • ‫NEW_PROXY_ONLY_SUBNET_NAME: השם של תת-הרשת החדשה מסוג proxy בלבד
  • ‫NEW_PROXY_ONLY_SUBNET_RANGE: טווח כתובות ה-IPv4 הראשי של תת-הרשת החדשה מסוג proxy-only בפורמט CIDR. בוחרים טווח כתובות IPv4 שמתאים לצרכים שלכם.
  • ‫PROXY_ONLY_SUBNET_FIREWALL_RULE: השם של כלל חומת אש של VPC שמאפשר תנועה נכנסת ומאפשר חיבורים מרשתות משנה מסוג proxy-only
  • ‫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,‏Cloud de Confiance מגדיר אוטומטית את התפקיד של תת-הרשת המקורית של שרת ה-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, כבר לא נעשה שימוש ברשת המשנה. מעדכנים את כללי חומת האש שחלים על מכונות וירטואליות או על נקודות קצה של שרתים עורפיים (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.

המסוף

אם אתם משתמשים במסוף Cloud de Confiance כדי ליצור את מאזן העומסים, תתבקשו להעביר את הייעוד של רשת משנה שנוצרה בעבר רק לשרתי proxy מ---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 בלבד

מחיקת תת-רשת של פרוקסי בלבד משחררת את טווח כתובות ה-IP הראשי שלה, כך שאפשר להשתמש בטווח למטרה אחרת. Cloud de Confiance המערכת אוכפת את הכללים הבאים כשהיא מקבלת בקשה למחיקת תת-רשת של פרוקסי בלבד:

  • אי אפשר למחוק רשת משנה פעילה מסוג 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.

מגבלות

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

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

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

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

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

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

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

  • רשתות משנה של פרוקסי בלבד לא תומכות ב-VPC Flow Logs.

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