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

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

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

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

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

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

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

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

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

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

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

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

כדי למנוע גישה לשירות Cloud Run מהאינטרנט, מגבילים את התנועה הנכנסת ל-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

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

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

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

מאזן עומסים פנימי של אפליקציות (ALB) בין אזורים עם פריסת Cloud Run. — מאזן עומסים פנימי של אפליקציות (ALB) חוצה אזורים עם פריסה של 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 באזור משותפת לכל מאזני העומסים הפנימיים של אפליקציות (ALB) חוצי-אזורים באזור. כתובות המקור של מנות שנשלחות ממאזן העומסים לקצה העורפי של השירות מוקצות מרשת המשנה של ה-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 בלבד בדוגמה הזו).
כלל חומת אש נוסף עבור בקשות לבדיקת תקינות.
הגדרה של זמינות גבוהה עם קצה עורפי בלי שרת (serverless) לפריסות של Cloud Run באזורים REGION_A ו-REGION_B. אם השרתים העורפיים באזור מסוים מושבתים, התעבורה מועברת לאזור אחר.
שירות גלובלי לקצה העורפי שעוקב אחרי השימוש בקצה העורפי והתקינות שלו. חשוב להפעיל זיהוי של חריגים בשירות לקצה העורפי.
מפת URL גלובלית שמנתחת את כתובת ה-URL של בקשה ומעבירה בקשות לשירותי קצה עורפיים ספציפיים על סמך המארח והנתיב של כתובת ה-URL של הבקשה.
שרת proxy גלובלי של HTTP או HTTPS, שמקבל בקשה מהמשתמש ומעביר אותה למפת URL. ל-HTTPS, מגדירים משאב אזורי של אישור SSL. אם מגדירים איזון עומסים של HTTPS, שרת ה-proxy של היעד משתמש באישור ה-SSL כדי לפענח את תעבורת ה-SSL. שרת ה-Proxy של היעד יכול להעביר תנועה למופעים שלכם באמצעות HTTP או HTTPS.
כללי העברה גלובליים, שכוללים את כתובת ה-IP הפנימית של איזון העומסים, כדי להעביר כל בקשה נכנסת לפרוקסי היעד.

כתובת ה-IP הפנימית שמשויכת לכלל ההעברה יכולה להיות מכל תת-רשת באותה רשת ואותו אזור. חשוב לשים לב לתנאים הבאים:
- כתובת ה-IP יכולה להיות (אבל לא חייבת) מאותה רשת משנה כמו קבוצות השרתים העורפיים.
- כתובת ה-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 הראשי שלה.

אפשר לגשת למאזני עומסים פנימיים של אפליקציות (ALB) בין אזורים מכל אזור ב-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-only לכל מטרה נתונה, לכל אזור ולכל רשת.

המסוף

אם אתם משתמשים במסוף 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 .

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

יוצרים שני כללי העברה: אחד עם כתובת IP וירטואלית (10.1.2.99) באזור REGION_B, ואחד עם כתובת IP וירטואלית (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 ללא שרת, במקום לבחור שירות ספציפי ב-Cloud Run, אפשר להשתמש במסכת כתובות URL כדי להפנות לכמה שירותים שפועלים באותו דומיין. מסכת כתובת URL היא תבנית של סכימת כתובות ה-URL שלכם. ה-NEG בלי שרת (serverless) משתמש בתבנית הזו כדי לחלץ את שם השירות מכתובת ה-URL של הבקשה הנכנסת ולמפות את הבקשה לשירות המתאים.

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

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

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

כדי ליצור מסכת כתובת URL למאזן העומסים, מתחילים עם כתובת ה-URL של השירות. בדוגמה הזו נשתמש באפליקציה לדוגמה בלי שרת (serverless) שפועלת בכתובת 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 balancer details (פרטי איזון העומסים), לוחצים על Edit (עריכה).
בדף Edit global external Application Load Balancer, לוחצים על Backend configuration.
בדף Backend configuration (הגדרות ה-Backend), לוחצים על Edit (עריכה) בשירות לקצה העורפי שרוצים לשנות.
לוחצים על הוספת קצה עורפי.
בוחרים באפשרות יצירת קבוצה של נקודות קצה ברשת ללא שרת.

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

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

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

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

המסוף

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

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

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

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

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

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

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

gcloud

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

בדוגמה הזו, ניתוח זיהוי החריגים מופעל כל שנייה. אם מספר קודי הסטטוס 5xx‏ HTTP הרצופים שמתקבלים על ידי שרת proxy של Envoy הוא חמישה או יותר, נקודת הקצה של השרת העורפי מוצאת ממאגר איזון העומסים של אותו שרת proxy של Envoy למשך 30 שניות. כשמגדירים את אחוז האכיפה ל-100%, שירות לקצה העורפי אוכף את ההוצאה של נקודות קצה לא תקינות ממאגרי איזון העומסים של אותם שרתי 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 בלי שרת (serverless) משירות לקצה העורפי.
לוחצים על Save.

נכנסים לדף Network endpoint group במסוף Google Cloud .
מעבר אל 'קבוצת נקודות קצה ברשת'
מסמנים את התיבה שלצד קבוצת ה-NEG בלי שרת (serverless) שרוצים למחוק.
לוחצים על 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