‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

למרות שהמסמך הזה מתאר תצורת Cloud Run, קבוצת נקודות קצה ברשת (NEG) בלי שרת (serverless) ב-Cloud Run יכולה להצביע על משאב Cloud Run או על משאב פונקציות Cloud Run (דור שני).

קבוצות של נקודות קצה ברשת (NEGs) בלי שרת מאפשרות לכם להשתמש בשירותי Cloud Run עם מאזן העומסים. אחרי שמגדירים מאזן עומסים עם קצה עורפי של NEG בלי שרת (serverless), בקשות למאזן העומסים מנותבות לקצה העורפי של Cloud Run.

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

אם שירותי Cloud Run מרובי-אזורים מוגדרים באותו אזור כמו Envoy, עדיף להשתמש ב-NEG שנמצא באותו אזור כמו Envoy. תעבורת הנתונים נשלחת לאזור הגיבוי רק אם זיהוי חריגות מופעל וה-NEG המקומי לא תקין.
אם שירותי Cloud Run מרובי-אזורים לא מוגדרים באותו אזור כמו Envoy, התעבורה מתחלקת באופן שווה בין כל ה-NEG. ה-NEGs שנמצאים קרוב יותר לא מועדפים.
אם האפשרות שרת proxy לאימות זהויות (IAP) מופעלת, נתמך רק NEG אחד בלי שרת (serverless). עם זאת, אפשר להגדיר שירותים נוספים של Cloud Run, אבל מאזן העומסים לא ישלח אליהם תנועה.

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

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

פריסת שירות Cloud Run

ההוראות בדף הזה מניחות שכבר יש לכם שירות Cloud Run שפועל.

כדי לפרוס שירות Cloud Run, אפשר להשתמש בכל אחד מהמדריכים למתחילים של Cloud Run.

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

מיקום שירות Cloud Run בכמה אזורים עוזר למנוע כשלים באזור אחד. כדי לפרוס את שירות Cloud Run באזורים REGION_A ו-REGION_B, מריצים את הפקודות הבאות:

gcloud

gcloud run deploy CLOUD_RUN_SERVICE_NAMEA \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_A \
   --image=IMAGE_URLA

gcloud run deploy CLOUD_RUN_SERVICE_NAMEB \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_B \
   --image=IMAGE_URLB

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

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

יוצרים משאב של אישור SSL ב-Certificate Manager באופן הבא:

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

הרשאות

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

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

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

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

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

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

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

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

רשת VPC עם רשתות המשנה הבאות:
- תת-רשת SUBNET_A ותת-רשת של שרת proxy בלבד ב-REGION_A.
- תת-רשת SUBNET_B ותת-רשת של שרת proxy בלבד ב-REGION_B.
אתם צריכים ליצור רשתות משנה ל-proxy בלבד בכל אזור של רשת VPC שבה אתם משתמשים במאזני עומסים פנימיים של אפליקציות (ALB) בין אזורים. תת-הרשת של ה-proxy באזור משותפת לכל מאזני העומסים הפנימיים של האפליקציות באזור. כתובות המקור של מנות שנשלחות ממאזן העומסים לקצה העורפי של השירות מוקצות מרשת המשנה של ה-proxy בלבד. בדוגמה הזו, לרשת המשנה של אזור REGION_A יש טווח כתובות IP ראשיות של 10.129.0.0/23, ולרשת המשנה של אזור REGION_B יש טווח כתובות IP ראשיות של 10.130.0.0/23, שהוא הגודל המומלץ של רשת משנה.
כלל חומת אש שמאפשר זרימת תעבורת נתונים מתת-רשת של שרת proxy בלבד ברשת. כלומר, צריך להוסיף כלל אחד שמאפשר תנועה ביציאות TCP ‏80, 443 ו-8080 מ-10.129.0.0/23 ומ-10.130.0.0/23 (טווח תת-הרשתות של שרת ה-proxy בלבד בדוגמה הזו).
כלל נוסף בחומת האש עבור בדיקות התקינות.
הגדרה של זמינות גבוהה עם קצה עורפי ללא שרת לפריסות של Cloud Run באזורים REGION_A ו-REGION_B. אם השרתים העורפיים באזור מסוים מושבתים, התעבורה מועברת לאזור אחר.
שירות לקצה עורפי גלובלי שעוקב אחרי השימוש בקצה העורפי והתקינות שלו. חשוב לוודא שהפעלתם את זיהוי החריגים בשירות הקצה העורפי.
מפת URL גלובלית שמנתחת את כתובת ה-URL של בקשה ומעבירה בקשות לשירותי קצה עורפיים ספציפיים על סמך המארח והנתיב של כתובת ה-URL של הבקשה.
שרת proxy גלובלי של HTTP או HTTPS, שמקבל בקשה מהמשתמש ומעביר אותה למיפוי כתובות ה-URL. ל-HTTPS, מגדירים משאב אזורי של אישור SSL. אם מגדירים איזון עומסים של HTTPS, שרת ה-proxy של היעד משתמש באישור ה-SSL כדי לפענח את תעבורת ה-SSL. שרת ה-Proxy של היעד יכול להעביר תנועה למופעים שלכם באמצעות HTTP או HTTPS.
כללי העברה גלובליים, שכוללים את כתובת ה-IP הפנימית של איזון העומסים, כדי להעביר כל בקשה נכנסת אל שרת ה-proxy של היעד.

כתובת ה-IP הפנימית שמשויכת לכלל ההעברה יכולה להגיע מכל תת-רשת באותה רשת ואותו אזור. חשוב לשים לב לתנאים הבאים:
- כתובת ה-IP יכולה להיות (אבל לא חייבת) מאותה תת-רשת כמו קבוצות שרתי העורף (backend instance).
- כתובת ה-IP לא יכולה להיות מתת-רשת שמורה של שרת proxy בלבד, שמוגדרת עם הדגל --purpose GLOBAL_MANAGED_PROXY.
- אם רוצים להשתמש באותה כתובת IP פנימית עם כמה כללי העברה, צריך להגדיר את הדגל של כתובת ה-IP‏ --purpose לערך SHARED_LOADBALANCER_VIP.
אופציונלי: מגדירים מדיניות ניתוב DNS מסוג GEO כדי לנתב את תעבורת הלקוחות לכתובת ה-VIP של מאזן העומסים באזור הקרוב ביותר ללקוח.

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

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

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

רשת. הרשת היא רשת VPC במצב מותאם אישית בשם NETWORK.
תת-רשתות לשרתי קצה עורפיים. רשת משנה בשם SUBNET_A באזור REGION_A משתמשת ב-10.1.2.0/24 כטווח ה-IP הראשי שלה. רשת המשנה שנקראת SUBNET_B באזור REGION_B משתמשת ב-10.1.3.0/24 כטווח ה-IP הראשי שלה.
תת-רשת לשרתי proxy. רשת משנה בשם PROXY_SN_A באזור REGION_A משתמשת ב-10.129.0.0/23 כטווח ה-IP הראשי שלה. רשת משנה בשם PROXY_SN_B באזור REGION_B משתמשת ב-10.130.0.0/23 כטווח ה-IP הראשי שלה.

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

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

המסוף

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

מעבר לרשתות VPC
לוחצים על יצירת רשת VPC.
מזינים שם לרשת.
בקטע רשתות משנה, מגדירים את מצב יצירת רשתות משנה למותאם אישית.
יוצרים רשת משנה לשרתי הבק-אנד של מאזן העומסים. בקטע New subnet (רשת משנה חדשה), מזינים את הפרטים הבאים:
- מזינים שם לרשת המשנה.
- בוחרים אזור: REGION_A
- מזינים טווח כתובות IP: 10.1.2.0/24
לוחצים על סיום.
לוחצים על הוספת רשת משנה.
יוצרים רשת משנה לשרתי הבק-אנד של מאזן העומסים. בקטע New subnet, מזינים את הפרטים הבאים:
- מזינים שם לרשת המשנה.
- בוחרים אזור: REGION_B
- מזינים טווח כתובות IP: 10.1.3.0/24
לוחצים על סיום.
לוחצים על יצירה.

gcloud

יוצרים את רשת ה-VPC המותאמת אישית באמצעות הפקודה gcloud compute networks create:
```
gcloud compute networks create NETWORK --subnet-mode=custom
```

יוצרים תת-רשת ברשת NETWORK באזור REGION_A באמצעות הפקודה gcloud compute networks subnets create:

gcloud compute networks subnets create SUBNET_A \
    --network=NETWORK \
    --range=10.1.2.0/24 \
    --region=REGION_A

יוצרים תת-רשת ברשת NETWORK באזור REGION_B באמצעות הפקודה gcloud compute networks subnets create:

gcloud compute networks subnets create SUBNET_B \
    --network=NETWORK \
    --range=10.1.3.0/24 \
    --region=REGION_B

API

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

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

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

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

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

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

המסוף

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

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

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

מעבר לרשתות VPC
לוחצים על השם של רשת ה-VPC.
בכרטיסייה Subnets (רשתות משנה), לוחצים על Add subnet (הוספת רשת משנה).
מזינים שם לרשת המשנה של ה-proxy בלבד.
ברשימה Region בוחרים באזור REGION_A.
ברשימה Purpose בוחרים באפשרות Cross-region Managed Proxy.
בשדה טווח כתובות IP, מזינים 10.129.0.0/23.
לוחצים על הוספה.

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

לוחצים על הוספת רשת משנה.
מזינים שם לרשת המשנה של ה-proxy בלבד.
ברשימה Region בוחרים באזור REGION_B.
ברשימה Purpose בוחרים באפשרות Cross-region Managed Proxy.
בשדה טווח כתובות IP, מזינים 10.130.0.0/23.
לוחצים על הוספה.

gcloud

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

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23

    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23

API

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

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": "PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }

יצירת קבוצות של נקודות קצה ברשת (NEG) ללא שרת

יוצרים NEG ללא שרת בשביל שירות Cloud Run:

gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-a \
   --region=REGION_A \
   --network-endpoint-type=serverless  \
   --cloud-run-service=CLOUD_RUN_SERVICE_NAMEA

gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-b \
   --region=REGION_B \
   --network-endpoint-type=serverless  \
   --cloud-run-service=CLOUD_RUN_SERVICE_NAMEB

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

התעבורה שיוצאת ממאזן העומסים אל קצה העורף של ה-NEG מסוג serverless עוברת בנתיבים מיוחדים שמוגדרים מחוץ ל-VPC, ולא חלים עליהם כללי חומת האש. לכן, אם למאזן העומסים שלכם יש רק שרתים עורפיים (backend) של NEG ללא שרתים, אתם לא צריכים ליצור כללי חומת אש כדי לאפשר תעבורת נתונים מתת-רשת של שרת proxy בלבד לשרת עורפי ללא שרת.

המסוף

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

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

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

הגדרה בסיסית

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

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

ל-HTTP:

לוחצים על Frontend configuration.

מזינים שם לכלל ההעברה.
ברשימה Subnetwork region, בוחרים באפשרות REGION_A.
שמירת תת-רשת של שרת proxy בלבד

ברשימה Subnetwork בוחרים באפשרות SUBNET_A.
ברשימה IP address, לוחצים על Create IP address. ייפתח הדף שמירת כתובת IP פנימית סטטית.

מזינים שם לכתובת ה-IP הסטטית.
ברשימה Static IP address (כתובת IP סטטית), בוחרים באפשרות Let me choose (אני רוצה לבחור).
בשדה כתובת IP מותאמת אישית, מזינים 10.1.2.99.
לוחצים על הזמנה.

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

מזינים שם לכלל ההעברה.
ברשימה Subnetwork region, בוחרים באפשרות REGION_B.
שמירת תת-רשת של שרת proxy בלבד

ברשימה Subnetwork בוחרים באפשרות SUBNET_B.
ברשימה IP address, לוחצים על Create IP address. ייפתח הדף שמירת כתובת IP פנימית סטטית.

מזינים שם לכתובת ה-IP הסטטית.
ברשימה Static IP address (כתובת IP סטטית), בוחרים באפשרות Let me choose (אני רוצה לבחור).
בשדה כתובת IP מותאמת אישית, מזינים 10.1.3.99.
לוחצים על הזמנה.

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

ל-HTTPS:

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

לוחצים על Frontend configuration.

מזינים שם לכלל ההעברה.
בשדה Protocol, בוחרים באפשרות HTTPS (includes HTTP/2).
מוודאים שהיציאה Port מוגדרת ל-443.
ברשימה Subnetwork region, בוחרים באפשרות REGION_A.
שמירת תת-רשת של שרת proxy בלבד

ברשימה Subnetwork בוחרים באפשרות SUBNET_A.
ברשימה IP address, לוחצים על Create IP address. ייפתח הדף שמירת כתובת IP פנימית סטטית.

מזינים שם לכתובת ה-IP הסטטית.
ברשימה Static IP address (כתובת IP סטטית), בוחרים באפשרות Let me choose (אני רוצה לבחור).
בשדה כתובת IP מותאמת אישית, מזינים 10.1.3.99.
לוחצים על הזמנה.

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

כדי ליצור אישור חדש ב-Certificate Manager:
1. לוחצים על הוספת אישור.
2. לוחצים על יצירת אישור חדש.
3. כדי ליצור אישור חדש, פועלים לפי השלבים שמתחילים משלב 3 באחת משיטות ההגדרה הבאות שמופיעות במסמכי התיעוד של Certificate Manager:
בוחרים מדיניות SSL מהרשימה מדיניות SSL. אם לא יצרתם מדיניות SSL, תחול מדיניות SSL שמוגדרת כברירת מחדל Google Cloud .
לוחצים על סיום.

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

נותנים שם לתצורת הקצה הקדמי.
בשדה Protocol, בוחרים באפשרות HTTPS (includes HTTP/2).
מוודאים שהיציאה Port מוגדרת ל-443.
ברשימה Subnetwork region, בוחרים באפשרות REGION_B.
שמירת תת-רשת של שרת proxy בלבד

ברשימה Subnetwork בוחרים באפשרות SUBNET_B.
ברשימה IP address, לוחצים על Create IP address. ייפתח הדף שמירת כתובת IP פנימית סטטית.

מזינים שם לכתובת ה-IP הסטטית.
ברשימה Static IP address (כתובת IP סטטית), בוחרים באפשרות Let me choose (אני רוצה לבחור).
בשדה כתובת IP מותאמת אישית, מזינים 10.1.3.99.
לוחצים על הזמנה.

לוחצים על Add certificate ובוחרים אישור קיים או יוצרים אישור חדש.
בוחרים מדיניות SSL מהרשימה מדיניות SSL. אם לא יצרתם מדיניות SSL, תחול מדיניות SSL שמוגדרת כברירת מחדל Google Cloud .
לוחצים על סיום.

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

לוחצים על Backend configuration.
ברשימה Create or select backend services לוחצים על Create a backend service.
מזינים שם לשירות הקצה העורפי.
בשדה Protocol, בוחרים באפשרות HTTP.
בשדה Named Port (יציאה עם שם), מזינים http.
ברשימה סוג ה-Backend, בוחרים באפשרות קבוצה של נקודות קצה ברשת ללא שרת.
בקטע New backend:

ברשימה Serverless network endpoint group, בוחרים באפשרות gl7ilb-serverless-neg-a.
לוחצים על סיום.
כדי להוסיף עוד קצה עורפי, לוחצים על הוספת קצה עורפי.
ברשימה Serverless network endpoint group, בוחרים באפשרות gl7ilb-serverless-neg-b.
לוחצים על סיום.

הגדרת כללי הניתוב

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

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

לוחצים על Review and finalize.
בודקים את הגדרות התצורה של מאזן העומסים.
לוחצים על יצירה.

gcloud

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

gcloud compute backend-services create gil7-backend-service \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --global

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

gcloud compute backend-services add-backend gil7-backend-service \
  --network-endpoint-group=gl7ilb-serverless-neg-a \
  --network-endpoint-group-region=REGION_A \
  --global

gcloud compute backend-services add-backend gil7-backend-service \
  --network-endpoint-group=gl7ilb-serverless-neg-b \
  --network-endpoint-group-region=REGION_B \
  --global

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

gcloud compute url-maps create gil7-map \
  --default-service=gil7-backend-service \
  --global

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

ל-HTTP:

יוצרים את שרת ה-proxy של היעד באמצעות הפקודה gcloud compute target-http-proxies create.
```
gcloud compute target-http-proxies create gil7-http-proxy \
  --url-map=gil7-map \
  --global
```
ל-HTTPS:

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

כדי ליצור אישור בניהול עצמי, אפשר לעיין במסמכים הבאים:
- יצירת מפתח פרטי ותעודה
מקצים את נתיבי הקבצים לשמות משתנים.
```
export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
```
```
export LB_PRIVATE_KEY=PATH_TO_LB_PRIVATE_KEY_FILE
```
יוצרים אישור SSL לכל האזורים באמצעות הפקודה gcloud certificate-manager certificates create.
```
gcloud certificate-manager certificates create gilb-certificate \
  --private-key-file=$LB_PRIVATE_KEY \
  --certificate-file=$LB_CERT \
  –-scope=all-regions
```
משתמשים באישור SSL כדי ליצור שרת proxy ליעד באמצעות הפקודה gcloud compute target-https-proxies create
```
gcloud compute target-https-proxies create gil7-https-proxy \
  --url-map=gil7-map \
  --certificate-manager-certificates=gilb-certificate
```

יוצרים שני כללי העברה: אחד עם כתובת VIP‏ (10.1.2.99) באזור REGION_B, ואחד עם כתובת VIP‏ (10.1.3.99) באזור REGION_A.

ברשתות מותאמות אישית, צריך להפנות לרשת המשנה בכלל ההעברה. שימו לב: זוהי רשת המשנה של המכונה הווירטואלית (VM), ולא רשת המשנה של השרת הפרוקסי.

ל-HTTP:

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

gcloud compute forwarding-rules create gil7-forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --subnet-region=REGION_B \
  --address=10.1.3.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

gcloud compute forwarding-rules create gil7-forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --subnet-region=REGION_A \
  --address=10.1.2.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

ל-HTTPS:

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

gcloud compute forwarding-rules create gil7-forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --address=10.1.3.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

gcloud compute forwarding-rules create gil7-forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --address=10.1.2.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

API

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

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

{
"name": "gil7-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl7ilb_serverless_negwest",
    "balancingMode": "UTILIZATION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl7ilb_serverless_negeast",
  }
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

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

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

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/global/backendServices/gil7-backend-service"
}

ל-HTTP:

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

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

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

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

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

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

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

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

ל-HTTPS:

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

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

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

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

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

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

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

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

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

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

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

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

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

gcloud

יוצרים את כלל חומת האש fw-allow-ssh כדי לאפשר קישוריות SSH למכונות וירטואליות עם תג הרשת allow-ssh. אם לא מציינים את source-ranges, Google Cloud הכלל יפורש כאילו הוא מתייחס לכל מקור.
```
gcloud compute firewall-rules create fw-allow-ssh \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22
```

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

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

gcloud compute instances create l7-ilb-client-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_A \
    --zone=ZONE_A \
    --tags=allow-ssh

gcloud compute instances create l7-ilb-client-b \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_B \
    --zone=ZONE_B \
    --tags=allow-ssh

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

gcloud compute ssh l7-ilb-client-a \
   --zone=ZONE_A

gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B

מוודאים שכתובת ה-IP משרתת את שם המארח שלה.
- מוודאים שהמכונה הווירטואלית של הלקוח יכולה להגיע לשתי כתובות ה-IP. הפקודה מצליחה ומחזירה את השם של המכונה הווירטואלית של ה-Backend שטיפלה בבקשה:
  
  לגבי בדיקות HTTP:
```
curl 10.1.2.99
```
```
curl 10.1.3.99
```
  לבדוק HTTPS:
```
curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:10.1.2.99:443
```
```
curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:10.1.3.99:443
```
  מחליפים את DOMAIN_NAME בשם הדומיין של האפליקציה, לדוגמה, test.example.com.
  
  הדגל -k גורם ל-curl לדלג על אימות האישור.
- אופציונלי: משתמשים ברשומת ה-DNS שהוגדרה כדי לפתור את כתובת ה-IP.
```
curl service.example.com
```

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

ל-HTTP:

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

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

ל-HTTPS:

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

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

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

בדיקת מעבר לגיבוי (failover)

לוודא שמתבצע מעבר לגיבוי (failover) לשרתי קצה עורפיים באזור REGION_A כשהשרתים באזורים REGION_B לא תקינים או לא נגישים. אנחנו מדמים את זה על ידי הסרת כל השרתים העורפיים מ-REGION_B:
```
gcloud compute backend-services remove-backend gil7-backend-service \
   --network-endpoint-group=gl7ilb-serverless-neg-b \
   --network-endpoint-group-zone=ZONE_B
```
מתחברים באמצעות SSH למכונה וירטואלית של לקוח ב-REGION_B.
```
gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B
```
שולחים בקשות לכתובת ה-IP של מאזן העומסים באזור REGION_B. פלט הפקודה מציג תשובות ממכונות וירטואליות של קצה עורפי ב-REGION_A.

מחליפים את DOMAIN_NAME בשם הדומיין של האפליקציה, לדוגמה, test.example.com.
```
{
RESULTS=
for i in {1..100}
do
  RESULTS="$RESULTS:$(curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:10.1.3.99:443)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.3.99: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}
```

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

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

שימוש במסכת כתובות URL

כשיוצרים NEG בלי שרת (serverless), במקום לבחור שירות ספציפי ב-Cloud Run, אפשר להשתמש במסכת כתובות URL כדי להפנות לכמה שירותים שפועלים באותו דומיין. מסכת כתובת URL היא תבנית של סכימת כתובות ה-URL שלכם. ה-NEG בלי שרת (serverless) משתמש בתבנית הזו כדי לחלץ את שם השירות מכתובת ה-URL של הבקשה הנכנסת ולמפות את הבקשה לשירות המתאים.

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

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

יצירת מסכת כתובת URL

כדי ליצור מסכת כתובת URL למאזן העומסים, מתחילים עם כתובת ה-URL של השירות. בדוגמה הזו נשתמש באפליקציה לדוגמה ללא שרת שפועלת בכתובת https://example.com/login. זו כתובת ה-URL שבה מוצג השירות של אפליקציית login.

מסירים את http או https מכתובת ה-URL. נותרו לך example.com/login.
מחליפים את שם השירות בפלייסלודר של מסכת כתובת ה-URL.
- ‫Cloud Run: מחליפים את שם השירות ב-Cloud Run במחזיק המקום <service>. אם שירות Cloud Run משויך לתג, מחליפים את שם התג במחזיק המקום <tag>. בדוגמה הזו, מסכת כתובות ה-URL שנותרה היא example.com/<service>.
אופציונלי: אם אפשר לחלץ את שם השירות מחלק הנתיב של כתובת ה-URL, אפשר להשמיט את הדומיין. החלק של הנתיב במסכת כתובת ה-URL מובחן על ידי התו הראשון של הקו הנטוי (/). אם אין לוכסן (/) במסכת כתובת ה-URL, המסכה מייצגת רק את המארח. לכן, בדוגמה הזו, אפשר לצמצם את מסכת כתובת ה-URL ל-/<service>.

באופן דומה, אם אפשר לחלץ את הערך <service> מחלק המארח של כתובת ה-URL, אפשר להשמיט את הנתיב לחלוטין ממסכת כתובת ה-URL.

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

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

בטבלה הזו מניחים שיש לכם דומיין מותאם אישית בשם example.com ושכל שירותי Cloud Run ממופים לדומיין הזה.

שירות, שם התג	כתובת URL של דומיין מותאם אישית ב-Cloud Run	אנונימיזציה של כתובת URL
service: login	https://login-home.example.com/web	<service>-home.example.com
service: login	https://example.com/login/web	example.com/<service> או /<service>
service: login, tag: test	https://test.login.example.com/web	<tag>.<service>.example.com
service: login, tag: test	https://example.com/home/login/test	example.com/home/<service>/<tag> or /home/<service>/<tag>
service: login, tag: test	https://test.example.com/home/login/web	‪<tag>.example.com/home/<service>

יצירת NEG ללא שרת עם מסכת כתובת URL

המסוף

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

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

כדי להוסיף ל-NEG קיים של שרתים וירטואליים ללא שרתים, שמבוסס על מסכת כתובות URL, לשירות קיים של קצה עורפי:

נכנסים לדף Load balancing במסוף Google Cloud .
כניסה לדף Load balancing
לוחצים על השם של מאזן העומסים שכולל את שירות לקצה העורפי שרוצים לערוך.
בדף Load balancer details (פרטי איזון העומסים), לוחצים על Edit (עריכה).
בדף Edit global external Application Load Balancer, לוחצים על Backend configuration.
בדף Backend configuration (הגדרות ה-Backend), לוחצים על Edit (עריכה) בשירות לקצה העורפי שרוצים לשנות.
לוחצים על הוספת קצה עורפי.
בוחרים באפשרות יצירת קבוצה של נקודות קצה ברשת ללא שרת.

בשדה Name (שם), מזינים helloworld-serverless-neg.
בקטע אזור מוצג האזור של מאזן העומסים.
בקטע סוג קבוצת נקודות קצה ברשת ללא שרת, Cloud Run הוא הסוג היחיד של קבוצת נקודות קצה ברשת שנתמך.

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

בקצה העורפי החדש, לוחצים על סיום.
לוחצים על עדכון.

gcloud

כדי ליצור NEG בלי שרת (serverless) עם מסכת כתובת URL לדוגמה של example.com/<service>:

gcloud compute network-endpoint-groups create SERVERLESS_NEG_MASK_NAME \
    --region=REGION \
    --network-endpoint-type=serverless \
    --cloud-run-url-mask="example.com/<service>"

שימוש באותה כתובת IP בכמה כללי העברה פנימיים

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

gcloud

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP

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

הגדרת כללי מדיניות לניתוב DNS

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

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

gcloud

כדי ליצור רשומת DNS עם TTL של 30 שניות, משתמשים בפקודה gcloud dns record-sets create.

gcloud dns record-sets create DNS_ENTRY --ttl="30" \
  --type="A" --zone="service-zone" \
  --routing-policy-type="GEO" \
  --routing-policy-data="REGION_A=gil7-forwarding-rule-a@global;REGION_B=gil7-forwarding-rule-b@global" \
  --enable-health-checking

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

‫DNS_ENTRY: DNS או שם הדומיין של קבוצת הרשומות
לדוגמה, service.example.com
‫REGION_A ו-REGION_B: האזורים שבהם הגדרתם את מאזן העומסים

API

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

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/SERVICE_ZONE/rrsets
{
  "name": "DNS_ENTRY",
  "type": "A",
  "ttl": 30,
  "routingPolicy": {
    "geo": {
      "items": [
        {
          "location": "REGION_A",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        },
        {
          "location": "REGION_B",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS_B",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        }
      ]
    }
  }
}

הפעלת זיהוי חריגות

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

התכונה 'זיהוי חריגות' מופעלת בשירות העורפי באחת מהשיטות הבאות:

השיטה consecutiveErrors (outlierDetection.consecutiveErrors), שבה קוד סטטוס של HTTP מסדרה 5xx נחשב לשגיאה.
השיטה consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), שבה רק קודי הסטטוס 502, 503 ו-504 של HTTP נחשבים לשגיאה.

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

המסוף

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

כניסה לדף Load balancing
לוחצים על השם של מאזן העומסים שרוצים לערוך את שירות לקצה העורפי שלו.
בדף Load balancer details (פרטי איזון העומסים), לוחצים על Edit (עריכה).
בדף Edit cross-region internal Application Load Balancer, לוחצים על Backend configuration.
בדף Backend configuration (הגדרות ה-Backend), לוחצים על Edit (עריכה) בשירות לקצה העורפי שרוצים לשנות.
גוללים למטה ומרחיבים את הקטע הגדרות מתקדמות.
בקטע Outlier detection (זיהוי חריגות), מסמנים את תיבת הסימון Enable (הפעלה).

לוחצים על עריכה כדי להגדיר זיהוי של חריגים.

מוודאים שהאפשרויות הבאות מוגדרות עם הערכים האלה:

מאפיין (property)	ערך
שגיאות עוקבות	5
Interval	1000
זמן בסיסי להוצאת כרטיס	30000
אחוז ההסרה המקסימלי	50
אכיפה של רצף שגיאות	100

בדוגמה הזו, ניתוח זיהוי החריגים מופעל כל שנייה. אם מספר קודי הסטטוס של HTTP‏ 5xx שמתקבלים ברצף על ידי שרת proxy של Envoy הוא חמישה או יותר, נקודת הקצה של ה-backend מוצאת ממאגר איזון העומסים של אותו שרת proxy של Envoy למשך 30 שניות. כשמגדירים את אחוז האכיפה ל-100%, שירות ה-Backend אוכף את ההוצאה של נקודות קצה לא תקינות ממאגרי איזון העומסים של אותם שרתי proxy ספציפיים של Envoy בכל פעם שהניתוח של זיהוי החריגים מופעל. אם התנאים להוצאה מתקיימים, אפשר להוציא עד 50% מנקודות הקצה בעורף מרשימת נקודות הקצה של מאגר איזון העומסים.

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

gcloud

מייצאים את שירות ה-Backend לקובץ YAML.
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
  --destination=BACKEND_SERVICE_NAME.yaml --global
```
מחליפים את BACKEND_SERVICE_NAME בשם של שירות לקצה העורפי.
עורכים את הגדרת ה-YAML של שירות הקצה העורפי כדי להוסיף את השדות של זיהוי חריגות, כמו שמודגש בהגדרת ה-YAML הבאה, בקטע outlierDetection:

בדוגמה הזו, ניתוח זיהוי החריגים מופעל כל שנייה. אם מספר קודי הסטטוס של HTTP‏ 5xx שמתקבלים ברצף על ידי שרת proxy של Envoy הוא חמישה או יותר, נקודת הקצה של ה-backend מוצאת ממאגר איזון העומסים של אותו שרת proxy של Envoy למשך 30 שניות. כשמגדירים את אחוז האכיפה ל-100%, שירות ה-Backend אוכף את ההוצאה של נקודות קצה לא תקינות ממאגרי איזון העומסים של אותם שרתי proxy ספציפיים של Envoy בכל פעם שהניתוח של זיהוי החריגים מופעל. אם התנאים להוצאה מתקיימים, אפשר להוציא עד 50% מנקודות הקצה בעורף מרשימת נקודות הקצה של מאגר איזון העומסים.
```
name: BACKEND_SERVICE_NAME
backends:
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2
outlierDetection:
  baseEjectionTime:
    nanos: 0
    seconds: 30
  consecutiveErrors: 5
  enforcingConsecutiveErrors: 100
  interval:
    nanos: 0
    seconds: 1
  maxEjectionPercent: 50
port: 80
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
sessionAffinity: NONE
timeoutSec: 30
...
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend
- ‫PROJECT_ID: מזהה הפרויקט
- ‫REGION_A ו-REGION_B: האזורים שבהם הוגדר מאזן העומסים.
- ‫SERVERLESS_NEG_NAME: השם של ה-NEG הראשון ללא שרת
- ‫SERVERLESS_NEG_NAME_2: השם של ה-NEG השני ללא שרת
כדי לעדכן את שירות הקצה העורפי, מייבאים את ההגדרות העדכניות.
```
gcloud compute backend-services import BACKEND_SERVICE_NAME \
  --source=BACKEND_SERVICE_NAME.yaml --global
```
התכונה 'זיהוי חריגות' מופעלת עכשיו בשירות הקצה העורפי.

מחיקה של NEG ללא שרת

אי אפשר למחוק קבוצת נקודות קצה ברשת אם היא מצורפת לשירות קצה עורפי. לפני שמוחקים NEG, מוודאים שהוא מנותק משירות לקצה העורפי.

המסוף

כדי לוודא ש-NEG בלי שרת שרוצים למחוק לא נמצא בשימוש על ידי אף שירות לקצה העורפי, עוברים לכרטיסייה Backend services בדף Load balancing components.
כניסה לדף Backend services
אם ה-NEG בלי שרת (serverless) נמצא בשימוש, מבצעים את הפעולות הבאות:

לוחצים על השם של שירות הקצה העורפי שמשתמש ב-NEG ללא שרת.
לוחצים על עריכה.
ברשימה Backends, לוחצים על כדי להסיר את ה-NEG של ה-backend ללא שרת מהשירות של ה-backend.
לוחצים על Save.

נכנסים לדף Network endpoint group במסוף Google Cloud .
מעבר אל 'קבוצת נקודות קצה ברשת'
מסמנים את התיבה שלצד ה-NEG ללא שרת שרוצים למחוק.
לוחצים על Delete.
כדי לאשר, לוחצים שוב על מחיקה.

gcloud

כדי להסיר NEG בלי שרת (serverless) משירות לקצה העורפי, צריך לציין את האזור שבו נוצר ה-NEG.

gcloud compute backend-services remove-backend BACKEND_SERVICE_NAME \
    --network-endpoint-group=SERVERLESS_NEG_NAME \
    --network-endpoint-group-region=REGION \
    --region=REGION

כדי למחוק את ה-NEG בלי שרת (serverless):

gcloud compute network-endpoint-groups delete SERVERLESS_NEG_NAME \
    --region=REGION

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

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

פריסת שירות Cloud Run

gcloud

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

הרשאות

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

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

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

המסוף

gcloud

API

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

המסוף

gcloud

API

יצירת קבוצות של נקודות קצה ברשת (NEG) ללא שרת

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

המסוף

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

gcloud

API

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

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

gcloud

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

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

בדיקת מעבר לגיבוי (failover)

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

שימוש במסכת כתובות URL

יצירת מסכת כתובת URL

יצירת NEG ללא שרת עם מסכת כתובת URL

המסוף

gcloud

שימוש באותה כתובת IP בכמה כללי העברה פנימיים

gcloud

הגדרת כללי מדיניות לניתוב DNS

gcloud

API

הפעלת זיהוי חריגות

המסוף

gcloud

מחיקה של NEG ללא שרת

המסוף

gcloud

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

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