Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

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

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

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

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

יצירת Google Cloud פרויקטים

יוצרים Google Cloud פרויקטים: פרויקט מארח אחד ושני פרויקטים של שירותים.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות להגדרת מאזן עומסים חיצוני של אפליקציות ברמה אזורית בסביבת VPC משותף עם קטגוריות של Cloud Storage, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

כדי להגדיר VPC משותף: אדמין של VPC משותף ב-Compute (roles/compute.xpnAdmin) בפרויקט המארח
כדי לתת לאדמין של פרויקט שירות גישה לשימוש ברשת VPC משותפת: משתמש ברשת Compute (roles/compute.networkUser) בפרויקט המארח
כדי ליצור קטגוריות ב-Cloud Storage: Storage Object Admin (roles/storage.objectAdmin) בפרויקט השירות
כדי ליצור את משאבי איזון העומסים: אדמין של רשת Compute (roles/compute.networkAdmin) בפרויקט השירות
כדי ליצור מכונות של Compute Engine: אדמין מכונות של Compute (roles/compute.instanceAdmin.v1) בפרויקט השירות
כדי ליצור ולשנות אישורי SSL ב-Certificate Manager: Certificate Manager Owner (roles/certificatemanager.owner) on the service project
כדי להפנות אל בקטנד באקטים בפרויקטים אחרים של שירותים: Compute Load Balancer Services User (roles/compute.loadBalancerServiceUser) בפרויקט השירות

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

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

הגדרת סביבת VPC משותפת

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

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

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

פרויקט המארח משתמש ברשת ה-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 networks במסוף Google Cloud .

מעבר לרשתות VPC
לוחצים על יצירת רשת VPC.
בשדה Name (שם), מזינים lb-network.
בקטע Subnets (רשתות משנה), בוחרים באפשרות Custom (מותאם אישית) בשדה Subnet creation mode (מצב יצירת רשת משנה).
בקטע New subnet (רשת משנה חדשה), מזינים את הפרטים הבאים:
- Name (שם): subnet-us
- בוחרים אזור: us-east1
- טווח כתובות IP: 10.1.2.0/24
לוחצים על סיום.
לוחצים על הוספת רשת משנה.
יוצרים רשת משנה נוספת לכלל ההעברה של מאזן העומסים באזור אחר. בקטע New subnet, מזינים את הפרטים הבאים:
- Name (שם): subnet-asia
- אזור: asia-east1
- טווח כתובות IP: 10.1.3.0/24
לוחצים על סיום.
לוחצים על יצירה.

gcloud

יוצרים רשת VPC מותאמת אישית בשם lb-network באמצעות הפקודה gcloud compute networks create.
```
gcloud compute networks create lb-network \
    --subnet-mode=custom \
    --project=HOST_PROJECT_ID
```

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

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

יוצרים תת-רשת בשם subnet-asia ברשת ה-VPC באזור asia-east1 באמצעות הפקודה gcloud compute networks subnets create.lb-network
```
gcloud compute networks subnets create subnet-asia \
    --network=lb-network \
    --range=10.1.3.0/24 \
    --region=asia-east1 \
    --project=HOST_PROJECT_ID
```
מחליפים את HOST_PROJECT_ID בGoogle Cloud מזהה הפרויקט שהוקצה לפרויקט שמופעל כפרויקט מארח בסביבת VPC משותף.

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

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

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

המסוף

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

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

gcloud

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

בדוגמה הזו, שם רשת המשנה שמוגדרת רק לשרת proxy הוא proxy-only-subnet-us.
```
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 \
    --project=HOST_PROJECT_ID
```
יוצרים תת-רשת לשרת proxy בלבד באזור asia-east1 באמצעות הפקודה gcloud compute networks subnets create.

בדוגמה הזו, שם רשת המשנה שמוגדרת רק לשרת proxy הוא proxy-only-subnet-asia.
```
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 \
    --project=HOST_PROJECT_ID
```
מחליפים את HOST_PROJECT_ID במזהה הפרויקטGoogle Cloud שהוקצה לפרויקט המארח.

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

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

המסוף

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

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

gcloud

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

בדוגמה הזו, שם הכלל לחומת האש הוא fw-allow-ssh.
```
gcloud compute firewall-rules create fw-allow-ssh \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22 \
    --project=HOST_PROJECT_ID
```
מחליפים את HOST_PROJECT_ID במזהה הפרויקטGoogle Cloud שהוקצה לפרויקט המארח.

הגדרת VPC משותף בפרויקט המארח

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

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

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

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

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

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

Figure 1. מאזן עומסים פנימי חוצה אזורים של אפליקציות (ALB) בסביבת VPC משותף עם קטגוריות של Cloud Storage — **איור 1.** מאזן עומסים פנימי אזורי של אפליקציות (ALB) בסביבת VPC משותף עם קטגוריות של Cloud Storage

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

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

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

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

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

יצירת קטגוריות של Cloud Storage

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

המסוף

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

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

gcloud

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

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

יוצרים את הקטגוריה השנייה באזור asia-east1 באמצעות הפקודה gcloud storage buckets create.
```
gcloud storage buckets create gs://BUCKET2_NAME \
    --default-storage-class=standard \
    --location=asia-east1 \
    --uniform-bucket-level-access \
    --project=SERVICE_PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫BUCKET1_NAME ו-BUCKET2_NAME: שמות של קטגוריות ב-Cloud Storage
- ‫SERVICE_PROJECT_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות

העתקת התוכן לקטגוריות של 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/love-to-purr/

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

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

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

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

המסוף

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

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

כניסה לדף Buckets
ברשימת הקטגוריות, לוחצים על השם של הקטגוריה שרוצים להגדיר כציבורית.
לוחצים על הכרטיסייה הרשאות.
בקטע Permissions, לוחצים על הלחצן Grant access. מופיעה תיבת הדו-שיח Grant access.
בשדה New principals, מזינים allUsers.
בשדה Select a role, מזינים Storage Object Viewer בתיבת הסינון ובוחרים Storage Object Viewer מהתוצאות המסוננות.
לוחצים על Save.
לוחצים על Allow public access.

gcloud

כדי להעניק לכל המשתמשים גישה לצפייה באובייקטים בקטגוריות, מריצים את הפקודה gcloud storage 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

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

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

שמירת כתובת IP פנימית סטטית למטרות הבאות:

כלל העברה באזור us-east1
כלל העברה באזור asia-east1

המסוף

נכנסים לדף IP addresses במסוף Google Cloud .

מעבר אל 'שמירת כתובת סטטית'
לוחצים על הזמנה פנימית.
בשדה שם, מזינים שם לכתובת החדשה.
בשביל IP version, בוחרים IPv4.
לוחצים על שמירה כדי לשמור את כתובת ה-IP.
פועלים שוב לפי השלבים האלה כדי לשריין כתובת IP באזור asia-east1.

gcloud

כדי לשמור כתובת IP פנימית סטטית באזור us-east1, משתמשים בפקודה gcloud compute addresses create.
```
gcloud compute addresses create ADDRESS1_NAME  \
   --region=us-east1 \
   --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
   --project=SERVICE_PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ADDRESS1_NAME: השם שרוצים להקצות לכתובת ה-IP הזו
- ‫HOST_PROJECT_ID: מזהה הפרויקט שהוקצה לפרויקט המארח Google Cloud
- ‫SERVICE_PROJECT_ID: מזהה הפרויקט שהוקצה לפרויקט השירות Google Cloud
כדי לשמור כתובת IP פנימית סטטית באזור asia-east1, משתמשים בפקודה gcloud compute addresses create.
```
gcloud compute addresses create ADDRESS2_NAME  \
   --region=asia-east1 \
   --subnet=projects/HOST_PROJECT_ID/regions/asia-east1/subnetworks/subnet-asia \
   --project=SERVICE_PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ADDRESS2_NAME: השם שרוצים להקצות לכתובת ה-IP הזו
- ‫HOST_PROJECT_ID: מזהה הפרויקט שהוקצה לפרויקט המארח Google Cloud
- ‫SERVICE_PROJECT_ID: מזהה הפרויקט שהוקצה לפרויקט השירות Google Cloud
משתמשים בפקודה gcloud compute addresses describe כדי לראות את התוצאה:
```
gcloud compute addresses describe ADDRESS1_NAME \
   --project=SERVICE_PROJECT_ID
```
```
gcloud compute addresses describe ADDRESS2_NAME \
   --project=SERVICE_PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ADDRESS1_NAME ו-ADDRESS2_NAME: השם שהקציתם לכתובות ה-IP
- ‫SERVICE_PROJECT_ID: מזהה הפרויקט שהוקצה לפרויקט השירות Google Cloud
כתובת ה-IP שמוחזרת נקראת RESERVED_IP_ADDRESS בקטעים הבאים.

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

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

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

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

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

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

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

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

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

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

בדוגמה הזו, קטגוריות ה-backend נקראות backend-bucket-cats ו-backend-bucket-dogs, שמות שמעידים על התוכן בקטגוריות Cloud Storage.
```
gcloud compute backend-buckets create backend-bucket-cats \
    --gcs-bucket-name=BUCKET1_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --project=SERVICE_PROJECT_ID
```
```
gcloud compute backend-buckets create backend-bucket-dogs \
    --gcs-bucket-name=BUCKET2_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --project=SERVICE_PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫BUCKET1_NAME ו-BUCKET2_NAME: שמות של קטגוריות ב-Cloud Storage
- ‫SERVICE_PROJECT_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות
יוצרים מפת URL כדי לנתב בקשות נכנסות לקטגוריית קצה עורפי באמצעות הפקודה gcloud compute url-maps create.

בדוגמה הזו, מפת ה-URL נקראת lb-map.
```
gcloud compute url-maps create lb-map \
    --default-backend-bucket=backend-bucket-cats \
    --global \
    --project=SERVICE_PROJECT_ID
```
מחליפים את SERVICE_PROJECT_ID בGoogle Cloud מזהה הפרויקט שהוקצה לפרויקט השירות.
מגדירים את כללי המארח והנתיב של מפת 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
    --project=SERVICE_PROJECT_ID
```
מחליפים את SERVICE_PROJECT_ID בGoogle Cloud מזהה הפרויקט שהוקצה לפרויקט השירות.
יוצרים שרת proxy ליעד באמצעות הפקודה gcloud compute target-http-proxies create.

לתנועה מסוג HTTP, יוצרים שרת proxy של יעד HTTP בשם http-proxy כדי להפנות בקשות למפת URL:
```
gcloud compute target-http-proxies create http-proxy \
    --url-map=lb-map \
    --global \
    --project=SERVICE_PROJECT_ID
```
מחליפים את SERVICE_PROJECT_ID בGoogle Cloud מזהה הפרויקט שהוקצה לפרויקט השירות.

לתנועה מסוג HTTPS, יוצרים שרת proxy ליעד HTTPS בשם https-proxy כדי להפנות בקשות למפת URL. ה-proxy הוא החלק במאזן העומסים שמכיל את אישור ה-SSL של מאזן עומסים ב-HTTPS. אחרי שיוצרים את האישור, אפשר לצרף אותו לשרת ה-proxy של יעד ה-HTTPS.
```
gcloud compute target-https-proxies create https-proxy \
    --url-map=lb-map \
    --certificate-manager-certificates=CERTIFICATE_NAME \
    --global \
    --project=SERVICE_PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CERTIFICATE_NAME: השם של אישור ה-SSL שיצרתם באמצעות Certificate Manager
- ‫SERVICE_PROJECT_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות

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

לתנועת HTTP, יוצרים את כללי ההעברה הגלובליים (http-fw-rule-1 ו-http-fw-rule-2) כדי לנתב בקשות נכנסות אל שרת ה-proxy של יעד HTTP:

gcloud compute forwarding-rules create http-fw-rule-1 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
    --subnet-region=us-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=80 \
    --target-http-proxy=http-proxy \
    --global-target-http-proxy \
    --global \
    --project=SERVICE_PROJECT_ID

gcloud compute forwarding-rules create http-fw-rule-2 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/asia-east1/subnetworks/subnet-asia \
    --subnet-region=asia-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=80 \
    --target-http-proxy=http-proxy \
    --global-target-http-proxy \
    --global \
    --project=SERVICE_PROJECT_ID

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

‫HOST_PROJECT_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט המארח
RESERVED_IP_ADDRESS: כתובת ה-IP שהזמנתם
‫SERVICE_PROJECT_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות

לתנועת HTTPS, יוצרים את כללי ההעברה הגלובליים (https-fw-rule-1 ו-https-fw-rule-2) כדי לנתב בקשות נכנסות אל ה-Proxy של יעד HTTPS:

gcloud compute forwarding-rules create https-fw-rule-1 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
    --subnet-region=us-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=443 \
    --target-https-proxy=https-proxy \
    --global-target-https-proxy \
    --global \
    --project=SERVICE_PROJECT_ID

gcloud compute forwarding-rules create https-fw-rule-2 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/asia-east1/subnetworks/subnet-asia \
    --subnet-region=asia-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=443 \
    --target-https-proxy=https-proxy \
    --global-target-https-proxy \
    --global \
    --project=SERVICE_PROJECT_ID

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

‫HOST_PROJECT_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט המארח
RESERVED_IP_ADDRESS: כתובת ה-IP שהזמנתם
‫SERVICE_PROJECT_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות

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

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

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

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

מקבלים את כתובת ה-IP של כלל ההעברה של מאזן העומסים (http-fw-rule-1), שנמצא באזור us-east1.
```
gcloud compute forwarding-rules describe http-fw-rule-1 \
    --global \
    --project=SERVICE_PROJECT_ID
```
מקבלים את כתובת ה-IP של כלל ההעברה של מאזן העומסים (http-fw-rule-2), שנמצא באזור asia-east1.
```
gcloud compute forwarding-rules describe http-fw-rule-2 \
    --global \
    --project=SERVICE_PROJECT_ID
```
מחליפים את SERVICE_PROJECT_ID בGoogle Cloud מזהה הפרויקט שהוקצה לפרויקט השירות.

מעתיקים את כתובת ה-IP שמוחזרת כדי להשתמש בה כ-FORWARDING_RULE_IP_ADDRESS בשלבים הבאים.

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

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

יוצרים מכונה וירטואלית של לקוח בשם client-a באזור us-east1.
```
gcloud compute instances create client-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
    --zone=us-east1-c \
    --tags=allow-ssh \
    --project=SERVICE_PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫HOST_PROJECT_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט המארח
- ‫SERVICE_PROJECT_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות
יוצרים חיבור SSH למכונה הווירטואלית של הלקוח.
```
 gcloud compute ssh client-a \
     --zone=us-east1-c \
     --project=SERVICE_PROJECT_ID
```
מחליפים את SERVICE_PROJECT_ID בGoogle Cloud מזהה הפרויקט שהוקצה לפרויקט השירות.
בדוגמה הזו, למאזן עומסים פנימי של אפליקציות (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/love-to-purr/three-cats.jpg --output three-cats.jpg
```
מחליפים את FORWARDING_RULE_IP_ADDRESS בכתובת ה-IP של כלל ההעברה של מאזן העומסים.

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

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

מוחקים את כלל ההעברה (http-fw-rule-1) באזור us-east1 כדי לדמות הפסקה זמנית בשירות אזורית, ובודקים אם הלקוח באזור us-east עדיין יכול לגשת לנתונים מקטגוריית הקצה העורפי.
```
gcloud compute forwarding-rules delete http-fw-rule-1 \
    --global \
    --project=SERVICE_PROJECT_ID
```
מחליפים את SERVICE_PROJECT_ID בGoogle Cloud מזהה הפרויקט שהוקצה לפרויקט השירות.
שליחת בקשת 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/love-to-purr/three-cats.jpg --output three-cats.jpg
```
מחליפים את FORWARDING_RULE_IP_ADDRESS בכתובת ה-IP של כלל ההעברה.

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

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

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

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

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

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

בקטע הזה נציג את ההגדרה השנייה כדוגמה.

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

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

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

הגדרת התפקידים הנדרשים
הגדרת סביבת VPC משותף

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

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

צריך לבצע את כל השלבים בקטע הזה בפרויקט שירות ב'

כדי ליצור את קטגוריית קצה עורפי, צריך לבצע את הפעולות הבאות:

יצירת קטגוריות של Cloud Storage

המסוף

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

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

gcloud

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

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

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

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

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

‫BUCKET1_NAME ו-BUCKET2_NAME: שמות של קטגוריות ב-Cloud Storage.
‫SERVICE_PROJECT_B_ID: מזהה הפרויקט ב- Google Cloud שהוקצה לפרויקט השירות B.

העתקת התוכן לקטגוריות של 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/love-to-purr/

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

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

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

המסוף

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

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

כניסה לדף Buckets
ברשימת הקטגוריות, לוחצים על השם של הקטגוריה שרוצים להגדיר כציבורית.
לוחצים על הכרטיסייה הרשאות.
בקטע Permissions, לוחצים על הלחצן Grant access. מופיעה תיבת הדו-שיח Grant access.
בשדה New principals, מזינים allUsers.
בשדה Select a role, מזינים Storage Object Viewer בתיבת הסינון ובוחרים Storage Object Viewer מהתוצאות המסוננות.
לוחצים על Save.
לוחצים על Allow public access.

gcloud

כדי להעניק לכל המשתמשים גישה לצפייה באובייקטים בקטגוריות, מריצים את הפקודה gcloud storage 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

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

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

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

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

בדוגמה הזו, הקטגוריות של ה-Backend נקראות backend-bucket-cats ו-backend-bucket-dogs, וזה מעיד על התוכן בקטגוריות של Cloud Storage.
```
gcloud compute backend-buckets create backend-bucket-cats \
    --gcs-bucket-name=BUCKET1_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --project=SERVICE_PROJECT_B_ID
```
```
gcloud compute backend-buckets create backend-bucket-dogs \
    --gcs-bucket-name=BUCKET2_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --project=SERVICE_PROJECT_B_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫BUCKET1_NAME ו-BUCKET2_NAME: שמות של קטגוריות ב-Cloud Storage.
- ‫SERVICE_PROJECT_B_ID: מזהה הפרויקט ב- Google Cloud שהוקצה לפרויקט השירות B.

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

צריך לבצע את כל השלבים בקטע הזה בפרויקט השירות א'

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

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

כדי ליצור את רכיבי ה-Frontend:

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

בדוגמה הזו, מפת ה-URL נקראת lb-map.
```
gcloud compute url-maps create lb-map \
    --default-backend-bucket=projects/SERVICE_PROJECT_B_ID/global/backendBuckets/backend-bucket-cats \
    --global \
    --project=SERVICE_PROJECT_A_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SERVICE_PROJECT_B_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות ב'
- ‫SERVICE_PROJECT_A_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות א'
מגדירים את כללי המארח והנתיב של מפת 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/*=projects/SERVICE_PROJECT_B_ID/global/backendBuckets/backend-bucket-dogs" \
    --default-backend-bucket=projects/SERVICE_PROJECT_B_ID/global/backendBuckets/backend-bucket-cats \
    --project=SERVICE_PROJECT_A_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SERVICE_PROJECT_B_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות ב'
- ‫SERVICE_PROJECT_A_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות א'
יוצרים שרת proxy ליעד באמצעות הפקודה gcloud compute target-http-proxies create.

לתנועה מסוג HTTP, יוצרים שרת proxy של יעד HTTP בשם http-proxy כדי להפנות בקשות למפת URL:
```
gcloud compute target-http-proxies create http-proxy \
    --url-map=lb-map \
    --global \
    --project=SERVICE_PROJECT_A_ID
```
מחליפים את SERVICE_PROJECT_A_ID בGoogle Cloud מזהה הפרויקט שהוקצה לפרויקט השירות A.

לתנועה מסוג HTTPS, יוצרים שרת proxy ליעד HTTPS בשם https-proxy כדי להפנות בקשות למפת URL. ה-proxy הוא החלק במאזן העומסים שמכיל את אישור ה-SSL של מאזן עומסים ב-HTTPS. אחרי שיוצרים את האישור, אפשר לצרף אותו לשרת ה-proxy של יעד ה-HTTPS.
```
gcloud compute target-https-proxies create https-proxy \
    --url-map=lb-map \
    --certificate-manager-certificates=CERTIFICATE_NAME \
    --global \
    --project=SERVICE_PROJECT_A_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CERTIFICATE_NAME: השם של אישור ה-SSL שיצרתם באמצעות Certificate Manager
- ‫SERVICE_PROJECT_A_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות א'

לתנועת HTTP, יוצרים את כללי ההעברה הגלובליים (http-fw-rule-1 ו-http-fw-rule-2) כדי לנתב בקשות נכנסות אל שרת ה-proxy של יעד ה-HTTP:

  gcloud compute forwarding-rules create http-fw-rule-1 \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
      --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
      --subnet-region=us-east1 \
      --address=RESERVED_IP_ADDRESS \
      --ports=80 \
      --target-http-proxy=http-proxy \
      --global-target-http-proxy \
      --global \
      --project=SERVICE_PROJECT_A_ID

  gcloud compute forwarding-rules create http-fw-rule-2 \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
      --subnet=projects/HOST_PROJECT_ID/regions/asia-east1/subnetworks/subnet-asia \
      --subnet-region=asia-east1 \
      --address=RESERVED_IP_ADDRESS \
      --ports=80 \
      --target-http-proxy=http-proxy \
      --global-target-http-proxy \
      --global \
      --project=SERVICE_PROJECT_A_ID

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

‫HOST_PROJECT_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט המארח
RESERVED_IP_ADDRESS: כתובת ה-IP שהזמנתם
‫SERVICE_PROJECT_A_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות א'

לתנועת HTTPS, יוצרים את כללי ההעברה הגלובליים (https-fw-rule-1 ו-https-fw-rule-2) כדי לנתב בקשות נכנסות אל ה-Proxy של יעד HTTPS:

gcloud compute forwarding-rules create https-fw-rule-1 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
    --subnet-region=us-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=443 \
    --target-https-proxy=https-proxy \
    --global-target-https-proxy \
    --global \
    --project=SERVICE_PROJECT_A_ID

gcloud compute forwarding-rules create https-fw-rule-2 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/asia-east1/subnetworks/subnet-asia \
    --subnet-region=asia-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=443 \
    --target-https-proxy=https-proxy \
    --global-target-https-proxy \
    --global \
    --project=SERVICE_PROJECT_A_ID

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

‫HOST_PROJECT_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט המארח
RESERVED_IP_ADDRESS: כתובת ה-IP שהזמנתם
‫SERVICE_PROJECT_A_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות א'

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

אם רוצים שמאזני עומסים יפנו לקטגוריות של קצה עורפי בפרויקטים אחרים של שירותים, לאדמין של מאזן העומסים צריכה להיות הרשאה compute.backendBuckets.use. כדי להעניק את ההרשאה הזו, אפשר להשתמש בתפקיד המוגדר מראש ב-IAM שנקרא Compute Load Balancer Services User (משתמש בשירותי איזון עומסים של Compute) ‏(roles/compute.loadBalancerServiceUser). התפקיד הזה צריך להיות מוענק על ידי אדמין של פרויקט השירות, ואפשר להחיל אותו ברמת פרויקט השירות או ברמת קטגוריית קצה עורפי ספציפית.

בדוגמה הזו, אדמין בפרויקט שירות ב' צריך להריץ אחת מהפקודות הבאות כדי להעניק את ההרשאה compute.backendBuckets.use לאדמין של מאזן עומסים מפרויקט שירות א'. אפשר לעשות את זה ברמת הפרויקט (לכל קטגוריות הקצה העורפי בפרויקט) או לכל קטגוריית קצה עורפי בנפרד.

המסוף

הרשאות ברמת הפרויקט

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

כדי להשלים את השלב הזה, צריך את ההרשאות compute.backendBuckets.setIamPolicy ו-resourcemanager.projects.setIamPolicy.

נכנסים לדף IAM במסוף Google Cloud .

כניסה לדף IAM
בוחרים את הפרויקט הרצוי.
לוחצים על Grant access.
בשדה New principals, מזינים את כתובת האימייל או מזהה אחר של החשבון הראשי.
בקטע הקצאת תפקידים, לוחצים על הוספת תפקידים.
בתיבת הדו-שיח Select roles (בחירת תפקידים), בשדה Search for roles (חיפוש תפקידים), מזינים את התפקיד Compute Load Balancer Services User.
מסמנים את התיבה Compute Load Balancer Services User.
לוחצים על אישור.
אם רוצים, מוסיפים תנאי לתפקיד.
לוחצים על Save.

הרשאות ברמת המשאב לקטגוריות ספציפיות של backend

כדי להעניק הרשאות לקטגוריות ספציפיות של backend בפרויקט:

כדי להשלים את השלב הזה, נדרשת ההרשאה compute.backendBuckets.setIamPolicy.

נכנסים לדף Backends במסוף Google Cloud .

כניסה לדף Backends
ברשימת ה-backends, בוחרים את קטגוריית הקצה העורפי שרוצים לתת לה גישה ולוחצים על Permissions.
לוחצים על Add principal.
בשדה New principals, מזינים את כתובת האימייל או מזהה אחר של החשבון הראשי.
ברשימה Select a role בוחרים באפשרות Compute Load Balancer Services User.
לוחצים על Save.

gcloud

הרשאות ברמת הפרויקט

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

כדי להשלים את השלב הזה, צריך את ההרשאות compute.backendBuckets.setIamPolicy ו-resourcemanager.projects.setIamPolicy.

  gcloud projects add-iam-policy-binding SERVICE_PROJECT_B_ID \
      --member="user:LOAD_BALANCER_ADMIN" \
      --role="roles/compute.loadBalancerServiceUser"

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

‫SERVICE_PROJECT_B_ID: מזהה הפרויקט שהוקצה לפרויקט השירות B Google Cloud
‫LOAD_BALANCER_ADMIN: החשבון הראשי שרוצים להוסיף לו את הקישור

הרשאות ברמת המשאב לקטגוריות ספציפיות של backend

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

משתמשים בפקודה gcloud projects add-iam-policy-binding כדי להעניק את התפקיד 'משתמש בשירותים של מאזן עומסים של Compute'.

כדי להשלים את השלב הזה, צריך את ההרשאה compute.backendBuckets.setIamPolicy.

  gcloud projects add-iam-policy-binding SERVICE_PROJECT_B_ID \
      --member="user:LOAD_BALANCER_ADMIN" \
      --role="roles/compute.loadBalancerServiceUser" \
      --condition='expression=resource.name=="projects/SERVICE_PROJECT_B_ID/global/backendBuckets/BACKEND_BUCKET_NAME",title=Shared VPC condition'

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

‫SERVICE_PROJECT_B_ID: מזהה הפרויקט שהוקצה לפרויקט השירות B Google Cloud
‫LOAD_BALANCER_ADMIN: החשבון הראשי שרוצים להוסיף לו את הקישור
‫BACKEND_BUCKET_NAME: השם של קטגוריית קצה עורפי

אפשר גם להשתמש בפקודה gcloud compute backend-buckets add-iam-policy-binding כדי להקצות את התפקיד 'משתמש בשירותי מאזן עומסים ב-Compute'.

  gcloud compute backend-buckets add-iam-policy-binding BACKEND_BUCKET_NAME \
      --member="user:LOAD_BALANCER_ADMIN" \
      --role="roles/compute.loadBalancerServiceUser" \
      --project=SERVICE_PROJECT_B_ID \

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

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

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

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

מקבלים את כתובת ה-IP של כלל ההעברה של מאזן העומסים (http-fw-rule-1), שנמצא באזור us-east1.
```
gcloud compute forwarding-rules describe http-fw-rule-1 \
    --global \
    --project=SERVICE_PROJECT_A_ID
```
מקבלים את כתובת ה-IP של כלל ההעברה של מאזן העומסים (http-fw-rule-2), שנמצא באזור asia-east1.
```
gcloud compute forwarding-rules describe http-fw-rule-2 \
    --global \
    --project=SERVICE_PROJECT_A_ID
```
מחליפים את SERVICE_PROJECT_A_ID בGoogle Cloud מזהה הפרויקט שהוקצה לפרויקט השירות A.

מעתיקים את כתובת ה-IP שמוחזרת כדי להשתמש בה כ-FORWARDING_RULE_IP_ADDRESS בשלבים הבאים.

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

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

יוצרים מכונה וירטואלית של לקוח בשם client-a באזור us-east1.
```
gcloud compute instances create client-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
    --zone=us-east1-c \
    --tags=allow-ssh \
    --project=SERVICE_PROJECT_A_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫HOST_PROJECT_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט המארח
- ‫SERVICE_PROJECT_A_ID: Google Cloud מזהה הפרויקט שהוקצה לפרויקט השירות א'
יוצרים חיבור SSH למכונה הווירטואלית של הלקוח.
```
 gcloud compute ssh client-a \
     --zone=us-east1-c \
     --project=SERVICE_PROJECT_A_ID
```
מחליפים את SERVICE_PROJECT_A_ID בGoogle Cloud מזהה הפרויקט שהוקצה לפרויקט השירות A.
בדוגמה הזו, למאזן עומסים פנימי של אפליקציות (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/love-to-purr/three-cats.jpg --output three-cats.jpg
```
מחליפים את FORWARDING_RULE_IP_ADDRESS בכתובת ה-IP של כלל ההעברה של מאזן העומסים.

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

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

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

יצירת Google Cloud פרויקטים

התפקידים הנדרשים

הגדרת סביבת VPC משותפת

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

המסוף

gcloud

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

המסוף

gcloud

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

המסוף

gcloud

הגדרת VPC משותף בפרויקט המארח

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

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

יצירת קטגוריות של Cloud Storage

המסוף

gcloud

העתקת התוכן לקטגוריות של Cloud Storage

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

המסוף

gcloud

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

המסוף

gcloud

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

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

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

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

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

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

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

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

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

יצירת קטגוריות של Cloud Storage

המסוף

gcloud

העתקת התוכן לקטגוריות של Cloud Storage

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

המסוף

gcloud

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

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

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

המסוף

הרשאות ברמת הפרויקט

הרשאות ברמת המשאב לקטגוריות ספציפיות של backend

gcloud

הרשאות ברמת הפרויקט

הרשאות ברמת המשאב לקטגוריות ספציפיות של backend

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

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

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

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

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