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

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

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

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

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

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

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

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

הגדרה ובדיקה של ניהול תנועת הגולשים

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

כדי לקבל עזרה בכתיבת קובצי ה-YAML האלה, אפשר להשתמש בדוגמאות שבדף הזה ובמאמרי העזרה של ה-API של Cloud Load Balancing.

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

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

שימוש בדוגמאות של YAML במסוף Google Cloud

כדי להשתמש בדוגמאות של YAML במסוף Google Cloud :

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

כניסה לדף איזון עומסים
לוחצים על Create load balancer (יצירת מאזן עומסים).
כדי ליצור global external Application Load Balancer, מבצעים את השלבים באשף.
בהגדרות כללי הניתוב, בוחרים באפשרות כלל מתקדם של מארח ונתיב.
לוחצים על הוספת כלל של מארח ונתיב.
מבצעים אחת מהפעולות הבאות:

בתיבה Path matcher (התאמת נתיבים), מדביקים את דוגמאות ה-YAML מהמסמך הזה.
לוחצים על הקישור הנחיות לגבי קוד.

Path matcher YAML examples

דוגמאות ל-YAML של כלי ההתאמה לנתיבים

כלי ההתאמה לנתיבים

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

מיפוי תנועה לשירות יחיד

שליחת כל תעבורת הנתונים לשירות יחיד. חשוב להקפיד להחליף את ה-placeholder.

    defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: /PREFIX
        priority: PRIORITY  # 0 is highest
        routeAction:
          weightedBackendServices:
          - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
            weight: 100

פיצול התנועה בין שני שירותים

פיצול התנועה בין שני שירותים או יותר. חשוב להקפיד להחליף את ה-placeholders.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
           weight: 5

הגדרת הפניה אוטומטית לכתובת URL

בדוגמה הבאה מוחזר קוד תגובה 301 MOVED_PERMANENTLY_DEFAULT שאפשר להגדיר. בדוגמה מוגדרת גם כותרת התגובה Location עם מזהה המשאבים האחיד (URI) המתאים, והמארח והנתיב מוחלפים בהתאם למה שצוין בפעולת ההפניה.

כדי ליצור הפניה אוטומטית לקטגוריית קצה עורפי, משתמשים ב-projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET בשדה defaultService.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: <var>URL_MAP_NAME</var>
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     defaultUrlRedirect:
       hostRedirect: "HOST TO REDIRECT TO" # Omit to keep the requested host
       pathRedirect: "PATH TO REDIRECT TO" # Omit to keep the requested path
       redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
       stripQuery: True

תנועה משתקפת

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

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

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
             mirrorPercent: 50.0

אם יש לכם כמה שירותי קצה עורפיים עם משקלים שונים ואתם רוצים לתעד באיזה שירות קצה עורפי נעשה שימוש כדי למלא את הבקשה המקורית, אתם יכולים להוסיף לכל הבקשות כותרת בהתאמה אישית שכוללת את המידע הזה. בדוגמה הבאה מוסיפים כותרת מותאמת אישית בשם x-weighted-picked-backend לכל הבקשות של הלקוח. לערך של הכותרת, משתמשים בשם של שירות ה-Backend שטיפל בבקשה המקורית.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
              weight: 95
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_1
                  replace: True
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
              weight: 5
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_2
                  replace: True
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_3

חשוב לשים לב למגבלות הבאות כשמשתמשים בשיקוף תנועה:

שיקוף תנועה נתמך אם לשני שירותי הקצה העורפי יש קבוצות מופעי מכונה מנוהלים, קצה עורפי של NEGs אזוריים או קצה עורפי של NEGs היברידיים. אין תמיכה ב-NEGs לאינטרנט, ב-NEGs בלי שרת (serverless) ובקצה עורפי (backend) של Private Service Connect.
בקשות לשירות לקצה העורפי המשוכפל לא יוצרות יומנים או מדדים עבור Cloud Logging ו-Cloud Monitoring.

לשכתב את כתובת ה-URL המבוקשת

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

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           urlRewrite:
             hostRewrite: "new-host-name.com" # Omit to keep the requested host
             pathPrefixRewrite: "/new-path/" # Omit to keep the requested path

הערה: הפעולה pathPrefixRewrite route מתאימה במיוחד לשימוש עם כללי prefixMatch, כי היא יכולה לשנות ביעילות רק את הקידומת התואמת. אנחנו לא ממליצים להשתמש בכללי fullPathMatch עם pathPrefixRewrite.

ניסיון חוזר לשליחת בקשה

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

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

ציון הזמן הקצוב לתפוגה של המסלול

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

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 0

הגדרת הזרקת תקלות

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

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           faultInjectionPolicy:
             delay:
               fixedDelay:
                 seconds: 10
                 nanos: 0
               percentage: 25
             abort:
               httpStatus: 503
               percentage: 50

הגדרת CORS

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

מדיניות CORS שחלה ברמה של התאמת נתיבים

בהגדרה הזו, מדיניות ה-CORS מוגדרת ב-defaultRouteAction של התאמת הנתיבים (pathMatchers[].defaultRouteAction.corsPolicy). המשמעות היא שהמדיניות חלה על כל הבקשות שמופנות דרך התאמת הנתיבים שמוגדרת כברירת מחדל, ללא קשר לנתיב או למסלול הספציפיים.

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

defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
  - '*'
  pathMatcher: path-matcher-1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
  name: path-matcher-1
- defaultRouteAction:
    corsPolicy:
      allowCredentials: true
      allowOrigins: [ "http://example.com" ]
      allowMethods: [ "GET", "POST" ]
      allowHeaders: [ "Authorization", "Content-Type" ]

איך זה עובד

מאזן העומסים אוכף את מדיניות ה-CORS לכל הבקשות שמטופלות על ידי הכלי להתאמת נתיבים.
מותרות רק בקשות מהמארח example.com באמצעות שיטות GET או POST, ועם הכותרות המותרות (Authorization,‏ Content-Type).
מותר להשתמש בפרטי כניסה (כמו קובצי Cookie או כותרות הרשאות) בבקשות חוצות מקורות.
השירות לקצה העורפי מקבל רק בקשות שעומדות בדרישות של מדיניות ה-CORS הזו.

מדיניות CORS חלה ברמת כלל הניתוב

בהגדרה הזו, מדיניות ה-CORS מוגדרת בתוך routeAction עבור כלל ניתוב ספציפי (pathMatchers[].routeRules[].routeAction.corsPolicy). כך אפשר להחיל מדיניות CORS שונה על מסלולים שונים או על קידומות נתיבים שונות.

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

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: [ "http://example.com" ]
               allowMethods: [ "GET", "POST" ]
               allowHeaders: [ "Authorization", "Content-Type" ]
               maxAge: 1200
               allowCredentials: true

איך זה עובד

מדיניות ה-CORS נאכפת רק לגבי בקשות שתואמות לקידומת הנתיב שצוינה (לדוגמה, /PREFIX).
רק בקשות מהמארח example.com באמצעות שיטות GET או POST, ועם הכותרות המותרות, מורשות עבור המסלול הזה.
השדה maxAge מציין למשך כמה זמן הדפדפן יכול לשמור במטמון את התוצאות של בקשת קדם-הפעלה (בשניות).
אפשר להשתמש בפרטי כניסה בבקשות חוצות-דומיינים.
למסלולים אחרים יכולים להיות כללי מדיניות שונים של CORS או שלא יהיו כלל.

אפשר גם להגדיר מדיניות CORS ברמות הבאות של מפת URL:

defaultRouteAction.corsPolicy
pathMatchers[].pathRules[].routeAction.corsPolicy

הוספה והסרה של כותרות בקשה ותגובה

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

יש הגבלות על הערכים התקינים של headerName ו-headerValue. לפרטים, ראו איך כותרות בהתאמה אישית פועלות.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               headerAction:
                 requestHeadersToAdd:
                 - headerName: header-1-name
                   headerValue: header-1-value
                   replace: True
                 requestHeadersToRemove:
                 - header-2-name
                 - header-3-name
                 responseHeadersToAdd:
                 - headerName: header-4-name
                   headerValue: header-4-value
                   replace: True
                responseHeadersToRemove:
                - header-5-name
                - header-6-name

הגדרת זיהוי חריגות

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

    loadBalancingScheme: EXTERNAL_MANAGED
    localityLbPolicy: RANDOM
    name: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
    outlierDetection:
      baseEjectionTime:
        nanos: 0
        seconds: 30
      consecutiveErrors: 5
      consecutiveGatewayFailure: 3
      enforcingConsecutiveErrors: 2
      enforcingConsecutiveGatewayFailure: 100
      enforcingSuccessRate: 100
      interval:
        nanos: 0
        seconds: 1
      maxEjectionPercent: 50
      successRateMinimumHosts: 5
      successRateRequestVolume: 100
      successRateStdevFactor: 1900

הגדרת פיצול תנועת הגולשים: שלבים מפורטים

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

ליצור תבניות נפרדות לשירותים שונים.
יוצרים קבוצות של מופעים עבור התבניות האלה.
יוצרים כללי ניתוב שמגדירים פיצול תנועה של 95% / 5%.
תשלח פקודות curl שיראו שאחוזי חלוקת התנועה תואמים בערך להגדרה.

במסגרת ההנחיות האלה, אנחנו מניחים:

נוצרו שרת proxy של יעד וכלל העברה, וגם מפת URL בשם global-lb-map.
מפת ה-URL שולחת את כל התעבורה לשירות קצה עורפי אחד, שנקרא red-service, והוא שירות הקצה העורפי שמוגדר כברירת מחדל.
הגדרתם נתיב חלופי שמעביר 5% מהתעבורה אל blue-service ו-95% מהתעבורה אל green-service.
נעשה שימוש ב-path matcher.
אתם משתמשים ב-Cloud Shell או בסביבה אחרת שבה מותקן bash.

הגדרת השירותים

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

ההוראות האלה מניחות שיצרתם בדיקת תקינות של HTTP ‏ (global-lb-basic-check). הוראות מפורטות מופיעות באחד מהדפים הבאים:

function make_service() {
  local name="$1"
  local region="$2"
  local zone="$3"
  local network="$4"
  local subnet="$5"
  local subdir="$6"

  www_dir="/var/www/html/$subdir"

  (set -x; \
  gcloud compute instance-templates create "${name}-template" \
    --region="$region" \
    --network="$network" \
    --subnet="$subnet" \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  apt-get update
  apt-get install apache2 -y
  a2ensite default-ssl
  a2enmod ssl
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee ${www_dir}index.html
  systemctl restart apache2"; \
  gcloud compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud compute backend-services create "${name}-service" \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=global-lb-basic-check \
    --global \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --global)
}

יצירת השירותים

מתקשרים לפונקציה כדי ליצור שלוש שירותים, red, green ו-blue. השירות red פועל כשירות ברירת המחדל לבקשות אל /. השירותים green ו-blue מוגדרים ב-/prefix לטיפול ב-95% ו-5% מהתנועה, בהתאמה.

make_service red us-west1 us-west1-a lb-network backend-subnet ""
make_service green us-west1 us-west1-a lb-network backend-subnet /prefix
make_service blue us-west1 us-west1-a lb-network backend-subnet /prefix

יצירת מפת URL

המסוף

נכנסים לדף איזון עומסים במסוף Google Cloud .
כניסה לדף איזון עומסים
לוחצים על הקישור global-lb-map.
לוחצים על עריכה .

הגדרת כללי הניתוב החדשים

בקטע כללי ניתוב, בוחרים באפשרות כלל מתקדם של מארח ונתיב.
בקטע New hosts and path matcher (מארחים חדשים והתאמה לנתיבים), כדי ליצור את פעולת ברירת המחדל, מגדירים את Service (שירות) ל-red-service.
לוחצים על סיום.
לוחצים על הוספת כלל של מארחים ונתיבים.
בשדה Hosts, מזינים את כתובת ה-IP של כלל ההעברה של איזון העומסים.

בתיבה Path matcher (התאמת נתיבים), מדביקים את תוכן ה-YAML הבא:

defaultService: projects/PROJECT_ID/global/backendServices/red-service
name: matcher1
routeRules:
- priority: 2
  matchRules:
    - prefixMatch: /PREFIX
  routeAction:
    weightedBackendServices:
      - backendService: projects/PROJECT_ID/global/backendServices/green-service
        weight: 95
      - backendService: projects/PROJECT_ID/global/backendServices/blue-service
        weight: 5

לוחצים על סיום.
לוחצים על עדכון.

gcloud

מייצאים את מפת ה-URL הקיימת באמצעות הפקודה gcloud compute url-maps export:
```
gcloud compute url-maps export global-lb-map \
  --destination=global-lb-map-config.yaml \
  --global
```

מעדכנים את קובץ מפת ה-URL‏ global-lb-map-config.yaml על ידי הוספת הטקסט הבא לסוף הקובץ:

hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/red-service
  name: matcher1
  routeRules:
  - priority: 2
    matchRules:
      - prefixMatch: /PREFIX
    routeAction:
      weightedBackendServices:
        - backendService: projects/PROJECT_ID/global/backendServices/green-service
          weight: 95
        - backendService: projects/PROJECT_ID/global/backendServices/blue-service
          weight: 5

מעדכנים את מפת ה-URL באמצעות הפקודה gcloud compute url-maps import:

gcloud compute url-maps import global-lb-map \
   --global \
   --source=global-lb-map-config.yaml

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

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

לאחר מכן בודקים שהבקשות שנשלחות אל FORWARDING_RULE_IP_ADDRESS/prefix מפולגות כצפוי.

הגדרת זיקה לסשן על סמך `HTTP_COOKIE`

התכונה 'בקרת תנועה' מאפשרת להגדיר זיקה לסשן (session affinity) על סמך קובץ Cookie שסופק. כדי להגדיר זיקה לסשן (session affinity) מבוסס-HTTP_COOKIE לשירות לקצה העורפי בשם red-service, פועלים לפי ההוראות הבאות.

משתמשים בפקודה gcloud compute backend_services export כדי לקבל את הגדרת השירות של הקצה העורפי.
```
gcloud compute backend-services export red-service \
    --destination=red-service-config.yaml \
    --global
```

מעדכנים את הקובץ red-service-config.yaml באופן הבא:

sessionAffinity: 'HTTP_COOKIE'
localityLbPolicy: 'RING_HASH'
consistentHash:
 httpCookie:
  name: 'http_cookie'
  path: '/cookie_path'
  ttl:
    seconds: 100
    nanos: 0
 minimumRingSize: 10000

בקבצים red-service-config.yaml, מוחקים את השורה הבאה:
```
sessionAffinity: NONE
```

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

gcloud compute backend-services import red-service \
    --source=red-service-config.yaml \
    --global

פתרון בעיות

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

מידע על רישום ביומן ומעקב זמין במאמר רישום ביומן ומעקב אחרי מאזן עומסים חיצוני מסוג HTTP(S).

תסמינים:

התנועה לשירותים בכללים שמעל הכלל הרלוונטי גדלה.
עלייה לא צפויה במספר תגובות HTTP מסוג 4xx ו-5xx לכלל מסוים של ניתוב תנועה.

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

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

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

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

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

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

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

הגדרה ובדיקה של ניהול תנועת הגולשים

שימוש בדוגמאות של YAML במסוף Google Cloud

מיפוי תנועה לשירות יחיד

פיצול התנועה בין שני שירותים

הגדרת הפניה אוטומטית לכתובת URL

תנועה משתקפת

לשכתב את כתובת ה-URL המבוקשת

ניסיון חוזר לשליחת בקשה

ציון הזמן הקצוב לתפוגה של המסלול

הגדרת הזרקת תקלות

הגדרת CORS

מדיניות CORS שחלה ברמה של התאמת נתיבים

איך זה עובד

מדיניות CORS חלה ברמת כלל הניתוב

איך זה עובד

הוספה והסרה של כותרות בקשה ותגובה

הגדרת זיהוי חריגות

הגדרת פיצול תנועת הגולשים: שלבים מפורטים

הגדרת השירותים

יצירת השירותים

יצירת מפת URL

המסוף

הגדרת כללי הניתוב החדשים

gcloud

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

הגדרת זיקה לסשן על סמך HTTP_COOKIE

פתרון בעיות

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

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

הגדרת זיקה לסשן על סמך `HTTP_COOKIE`