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

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

לפני שמתחילים

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

התקנת Google Cloud CLI

חלק מההוראות במדריך הזה אפשר לבצע רק באמצעות Google Cloud CLI. הוראות להתקנה מופיעות במאמר התקנת ה-CLI של gcloud.

אפשר למצוא פקודות שקשורות לאיזון עומסים במסמך הפניות ל-API ול-CLI של gcloud.

הרשאות

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

משימה	התפקיד הנדרש
יצירת רשתות, רשתות משנה ורכיבים של מאזן עומסים	התפקיד Compute Network Admin (roles/compute.networkAdmin)
הוספה והסרה של כללים לחומת האש	התפקיד אדמין לענייני אבטחה ב-Compute (roles/compute.securityAdmin)
יצירת קטגוריות ב-Cloud Storage	התפקיד 'אדמין של אובייקטים באחסון' (roles/storage.objectAdmin)

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

• בקרת גישה
• תנאים ב-IAM

הגדרת משאב של אישור SSL

כדי ליצור מאזן עומסים פנימי של אפליקציות (ALB) בין אזורים שמשתמש ב-HTTPS כפרוטוקול של הבקשה והתגובה, צריך ליצור משאב של אישור SSL באמצעות Certificate Manager, כמו שמתואר באחד מהמסמכים הבאים:

• פריסה של אישור חוצה אזורים שמנוהל על ידי Google והונפק על ידי מופע של שירות CA
• פריסת אישור חוצה אזורים שמנוהל על ידי Google עם הרשאת DNS
• פריסת אישור בניהול עצמי בכמה אזורים

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

מומלץ להשתמש באישור שמנוהל על ידי Google.

מגבלות

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

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

• אי אפשר להשתמש בכתובות URL חתומות.

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

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

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

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

חלוקת התנועה ל-Cloud Storage (לחצו כדי להגדיל).

כפי שמוצג בתרשים הארכיטקטורה, בדוגמה הזו נוצר מאזן עומסים פנימי של אפליקציות בין אזורים ברשת VPC עם שתי קטגוריות קצה עורפי, כאשר כל קטגוריית קצה עורפי מפנה לקטגוריה של Cloud Storage. הקטגוריות של Cloud Storage ממוקמות באזור us-east1 ובאזור asia-east1.

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

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

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

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

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

• Subnets for load balancer (תת-רשתות למאזן העומסים). רשת משנה בשם subnet-us באזור us-east1 משתמשת ב-10.1.2.0/24 כטווח ה-IP הראשי שלה. רשת משנה בשם subnet-asia באזור asia-east1 משתמשת ב-10.1.3.0/24 כטווח ה-IP הראשי שלה.

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

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

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

המסוף

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

   מעבר לרשתות VPC

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

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

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

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

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

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

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

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

   • Name (שם): subnet-asia
   • אזור: asia-east1
   • טווח כתובות IP: 10.1.3.0/24

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

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

gcloud

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

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

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

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

3. יוצרים תת-רשת ברשת ה-VPC‏ lb-network באזור asia-east1 באמצעות הפקודה gcloud compute networks subnets create.

   gcloud compute networks subnets create subnet-asia \
       --network=lb-network \
       --range=10.1.3.0/24 \
       --region=asia-east1
   

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

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

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

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

המסוף

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

   מעבר לרשתות VPC

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

3. בכרטיסייה Subnet, לוחצים על Add subnet.

4. הזן את פריטי המידע הבאים:

   • בשדה Name (שם), מזינים proxy-only-subnet-us.
   • בשדה Region (אזור), מזינים us-east1.
   • בשדה Purpose (מטרה), בוחרים באפשרות Cross-region Managed Proxy (שרת proxy מנוהל חוצה אזורים).
   • בשדה IP address range (טווח כתובות IP), מזינים 10.129.0.0/23.

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

6. יוצרים עוד תת-רשת לשרתי proxy בלבד באזור asia-east1. בכרטיסייה Subnet, לוחצים על Add subnet.

7. הזן את פריטי המידע הבאים:

   • בשדה Name (שם), מזינים proxy-only-subnet-asia.
   • בשדה Region (אזור), מזינים asia-east1.
   • בשדה Purpose (מטרה), בוחרים באפשרות Cross-region Managed Proxy (שרת proxy מנוהל חוצה אזורים).
   • בשדה IP address range (טווח כתובות IP), מזינים 10.130.0.0/23.

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

gcloud

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

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

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

   gcloud compute networks subnets create proxy-only-subnet-asia \
       --purpose=GLOBAL_MANAGED_PROXY \
       --role=ACTIVE \
       --region=asia-east1 \
       --network=lb-network \
       --range=10.130.0.0/23
   

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

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

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

המסוף

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. לוחצים על יצירה.

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
   

הגדרת קטגוריות של Cloud Storage

תהליך ההגדרה של קטגוריות Cloud Storage הוא כדלקמן:

• יוצרים את הקטגוריות.
• מעתיקים את התוכן לקטגוריות.

יצירת קטגוריות ב-Cloud Storage

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

המסוף

1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.
   

   כניסה לדף Buckets

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

3. בתיבה Name your bucket, מזינים שם ייחודי גלובלית שעומד בהנחיות למתן שמות.

4. לוחצים על בחירת המיקום לאחסון הנתונים.

5. מגדירים את סוג המיקום לאזור.

6. ברשימת האזורים, בוחרים באפשרות us-east1.

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

8. לוחצים על Buckets כדי לחזור לדף Cloud Storage Buckets. כדי ליצור קטגוריה שנייה, פועלים לפי ההוראות האלה, אבל מגדירים את המיקום ל-asia-east1.

gcloud

1. יוצרים את הקטגוריה הראשונה באזור us-east1 באמצעות הפקודה gcloud storage buckets create.

   gcloud storage buckets create gs://BUCKET1_NAME \
       --default-storage-class=standard \
       --location=us-east1 \
       --uniform-bucket-level-access
   

2. יוצרים את הקטגוריה השנייה באזור asia-east1 באמצעות הפקודה gcloud storage buckets create.

   gcloud storage buckets create gs://BUCKET2_NAME \
       --default-storage-class=standard \
       --location=asia-east1 \
       --uniform-bucket-level-access
   

מחליפים את המשתנים BUCKET1_NAME ו-BUCKET2_NAME בשמות של הקטגוריות שלכם ב-Cloud Storage.

העתקת קובצי גרפיקה לקטגוריות של Cloud Storage

כדי שתוכלו לבדוק את ההגדרה, אתם יכולים להעתיק קובץ גרפי מקטגוריה ציבורית של Cloud Storage לקטגוריות שלכם ב-Cloud Storage.

מריצים את הפקודות הבאות ב-Cloud Shell, ומחליפים את משתני שם הקטגוריה בשמות הייחודיים של הקטגוריות של Cloud Storage:

gcloud storage cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET1_NAME/never-fetch/

gcloud storage cp gs://gcp-external-http-lb-with-bucket/two-dogs.jpg gs://BUCKET2_NAME/love-to-fetch/

הגדרת קטגוריות של Cloud Storage כקריאות באופן ציבורי

כדי שכל האובייקטים בקטגוריה יהיו קריאים לכולם באינטרנט הציבורי, צריך להעניק לחשבון הראשי allUsers את התפקיד 'צפייה באובייקט אחסון' (roles/storage.objectViewer).

המסוף

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

1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.
   

   כניסה לדף Buckets

2. ברשימת הקטגוריות, לוחצים על השם של הקטגוריה שרוצים להגדיר כציבורית.

3. לוחצים על הכרטיסייה Permissions בחלק העליון של הדף.

4. בקטע Permissions, לוחצים על הלחצן Grant access. מופיעה תיבת הדו-שיח Grant access.

5. בשדה New principals, מזינים allUsers.

6. בשדה Select a role, מזינים Storage Object Viewer בתיבת הסינון ובוחרים Storage Object Viewer מהתוצאות המסוננות.

7. לוחצים על Save.

8. לוחצים על Allow public access.

gcloud

כדי להעניק לכל המשתמשים גישה לצפייה באובייקטים בקטגוריות, מריצים את הפקודה buckets add-iam-policy-binding.

gcloud storage buckets add-iam-policy-binding gs://BUCKET1_NAME --member=allUsers --role=roles/storage.objectViewer

gcloud storage buckets add-iam-policy-binding gs://BUCKET2_NAME --member=allUsers --role=roles/storage.objectViewer

מחליפים את משתני שמות הקטגוריות בשמות הייחודיים של הקטגוריות שלכם ב-Cloud Storage.

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

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

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

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

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

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

1. יוצרים שתי קטגוריות עורפיות, אחת לכל קטגוריה של Cloud Storage, באמצעות הפקודה gcloud compute backend-buckets create. לקטגוריות הקצה העורפי יש סכמת איזון עומסים של INTERNAL_MANAGED.

   gcloud compute backend-buckets create backend-bucket-cats \
       --gcs-bucket-name=BUCKET1_NAME \
       --load-balancing-scheme=INTERNAL_MANAGED
   

   gcloud compute backend-buckets create backend-bucket-dogs \
       --gcs-bucket-name=BUCKET2_NAME \
       --load-balancing-scheme=INTERNAL_MANAGED
   

   הערה: כשיוצרים קטגוריית קצה עורפי למאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים, אי אפשר להפעיל את Cloud CDN. במילים אחרות, אי אפשר לשלב את Cloud CDN כשמשתמשים ב---load-balancing-scheme=INTERNAL_MANAGED.

2. יוצרים מפת URL כדי לנתב בקשות נכנסות לקטגוריית קצה עורפי באמצעות הפקודה gcloud compute url-maps create.

   gcloud compute url-maps create lb-map \
       --default-backend-bucket=backend-bucket-cats \
       --global
   

3. מגדירים את כללי המארח והנתיב של מפת URL באמצעות הפקודה gcloud compute url-maps add-path-matcher.

   בדוגמה הזו, קטגוריית הקצה העורפי שמוגדרת כברירת מחדל היא backend-bucket-cats, שמטפלת בכל הנתיבים שקיימים בתוכה. עם זאת, כל בקשה שמכוונת אל http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg משתמשת בבק-אנד backend-bucket-dogs. לדוגמה, אם התיקייה /love-to-fetch/ קיימת גם בקצה העורפי שמוגדר כברירת מחדל (backend-bucket-cats), מאזן העומסים נותן עדיפות לקצה העורפי backend-bucket-dogs כי יש כלל נתיב ספציפי ל-/love-to-fetch/*.

   gcloud compute url-maps add-path-matcher lb-map \
       --path-matcher-name=path-matcher-pets \
       --new-hosts=* \
       --backend-bucket-path-rules="/love-to-fetch/*=backend-bucket-dogs" \
       --default-backend-bucket=backend-bucket-cats
   

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

   לתנועת HTTP, יוצרים שרת proxy של HTTP ליעד כדי להפנות בקשות למפת URL:

   gcloud compute target-http-proxies create http-proxy \
       --url-map=lb-map \
       --global
   

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

   gcloud compute target-https-proxies create https-proxy \
       --url-map=lb-map \
       --certificate-manager-certificates=CERTIFICATE_NAME \
       --global
   

   מחליפים את CERTIFICATE_NAME בשם של אישור ה-SSL שיצרתם באמצעות Certificate Manager.

5. יוצרים שני כללי העברה גלובליים, אחד עם כתובת IP באזור us-east1 ואחד עם כתובת IP באזור asia-east1 באמצעות הפקודה gcloud compute forwarding-rules create.

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

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

   לתנועת HTTP, יוצרים את כללי ההעברה הגלובליים כדי לנתב בקשות נכנסות אל שרת ה-proxy של יעד ה-HTTP:

   gcloud compute forwarding-rules create http-fw-rule-1 \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=subnet-us \
       --subnet-region=us-east1 \
       --ports=80 \
       --target-http-proxy=http-proxy \
       --global-target-http-proxy \
       --global
   

   gcloud compute forwarding-rules create http-fw-rule-2 \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=subnet-asia \
       --subnet-region=asia-east1 \
       --ports=80 \
       --target-http-proxy=http-proxy \
       --global-target-http-proxy \
       --global
   

   לתנועת HTTPS, יוצרים את כללי ההעברה הגלובליים כדי לנתב בקשות נכנסות אל ה-Proxy של יעד HTTPS:

   gcloud compute forwarding-rules create https-fw-rule-1 \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=subnet-us \
       --subnet-region=us-east1 \
       --address=RESERVED_IP_ADDRESS \
       --ports=443 \
       --target-https-proxy=https-proxy \
       --global-target-https-proxy \
       --global
   

   gcloud compute forwarding-rules create https-fw-rule-2 \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=subnet-asia \
       --subnet-region=asia-east1 \
       --address=RESERVED_IP_ADDRESS \
       --ports=443 \
       --target-https-proxy=https-proxy \
       --global-target-https-proxy \
       --global
   

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

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

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

1. מקבלים את כתובת ה-IP של כלל ההעברה של מאזן העומסים (http-fw-rule-1), שנמצא באזור us-east1.

   gcloud compute forwarding-rules describe http-fw-rule-1 \
       --global
   

2. מקבלים את כתובת ה-IP של כלל ההעברה של מאזן העומסים (http-fw-rule-2), שנמצא באזור asia-east1.

   gcloud compute forwarding-rules describe http-fw-rule-2 \
       --global
   

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

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

   gcloud compute instances create client-a \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --network=lb-network \
       --subnet=subnet-us \
       --zone=us-east1-c \
       --tags=allow-ssh
   

2. יוצרים חיבור SSH למכונה הווירטואלית של הלקוח.

   gcloud compute ssh client-a --zone=us-east1-c
   

3. בדוגמה הזו, למאזן עומסים פנימי של אפליקציות (ALB) בין אזורים יש כתובות IP וירטואליות (VIP) של קצה קדמי באזורים us-east1 ו-asia-east1 ברשת ה-VPC. שליחת בקשת HTTP ל-VIP באחד מהאזורים באמצעות curl.

   curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
   

   curl http://FORWARDING_RULE_IP_ADDRESS/never-fetch/three-cats.jpg --output three-cats.jpg
   

בדיקת זמינות גבוהה

1. מוחקים את כלל ההעברה (http-fw-rule-1) באזור us-east1 כדי לדמות הפסקה זמנית בשירות אזורית, ובודקים אם הלקוח באזור us-east עדיין יכול לגשת לנתונים מקטגוריית הקצה העורפי.

   gcloud compute forwarding-rules delete http-fw-rule-1 \
       --global
   

2. שליחת בקשת HTTP לכתובת ה-VIP של כלל ההעברה באחד מהאזורים באמצעות curl.

   curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
   

   curl http://FORWARDING_RULE_IP_ADDRESS/never-fetch/three-cats.jpg --output three-cats.jpg
   

   אם שולחים בקשת HTTP ל-VIP באזור us-east1, מדיניות הניתוב של DNS מזהה שה-VIP הזה לא מגיב ומחזירה ללקוח את ה-VIP האופטימלי הבא (בדוגמה הזו, asia-east1). ההתנהגות הזו עוזרת לוודא שהאפליקציה שלכם תמשיך לפעול גם במהלך הפסקות שירות אזוריות.

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

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