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

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

המסמך מכיל דוגמאות למאזני העומסים הבאים:

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

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

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

מאזני עומסים חיצוניים אזוריים של אפליקציות משתמשים ב-EXTERNAL_MANAGED.
מאזני עומסים פנימיים אזוריים של אפליקציות משתמשים ב-INTERNAL_MANAGED.

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

מאזני עומסים אזוריים פנימיים של אפליקציות משתמשים ב-regional URL map API . במסמכי התיעוד של regional backend service API מופיעה רשימה מלאה של השדות, כולל סמנטיקה לגבי קשרים, הגבלות וקרדינליות.
מאזני עומסים פנימיים של אפליקציות חוצות-אזורים משתמשים ב-global URL map API , ובמסמכי התיעוד של global backend service API מופיעה רשימה מלאה של השדות, כולל סמנטיקה לגבי קשרים, הגבלות וקרדינליות.

הערה: במאזני עומסים פנימיים של אפליקציות (ALB) שפועלים בכמה אזורים, אפשר להשתמש בדוגמאות שמופיעות במסמך הזה ולהחליף את regions/REGION/backendServices ב-global/backendServices.

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

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

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

הגדרת ניהול טראפיק

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

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

אין תמיכה במסוף Google Cloud .

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

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

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

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

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

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

Path matcher YAML examples

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

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

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

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

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

    defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
        - matchRules:
            - prefixMatch: /PREFIX
          priority: 1
          routeAction:
            weightedBackendServices:
              - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
                weight: 100

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

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

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

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

בדוגמה הבאה מוחזר קוד תגובה מסוג 3xx שאפשר להגדיר. בדוגמה הזו מוגדרת גם כותרת התגובה Location עם ה-URI המתאים, והמארח והנתיב מוחלפים בהתאם לפעולת ההפניה.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: URL_MAP_NAME
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/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/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: 1
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_2
             mirrorPercent: 50.0

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

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

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

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

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/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/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

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

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

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

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

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

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

הגדרת CORS

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

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: my-domain.com
               allowMethods: GET, POST
               allowHeaders: Authorization, Content-Type
               maxAge: 1200
               allowCredentials: True

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

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

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

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
               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: LOAD_BALANCING_SCHEME
    localityLbPolicy: RANDOM
    name: projects/PROJECT_ID/regions/REGION/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
    region: region/REGION

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

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

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

    loadBalancingScheme: LOAD_BALANCING_SCHEME # EXTERNAL_MANAGED or INTERNAL_MANAGED
    localityLbPolicy: RANDOM
    affinityCookieTtlSec: 0
    backends:
    - balancingMode: UTILIZATION
      capacityScaler: 1.0
      group: region/REGION/instanceGroups/INSTANCE_GROUP
      maxUtilization: 0.8
    circuitBreakers:
      maxConnections: 1000
      maxPendingRequests: 200
      maxRequests: 1000
      maxRequestsPerConnection: 100
      maxRetries: 3
    connectionDraining:
      drainingTimeoutSec: 0
    healthChecks:
    - region/REGION/healthChecks/HEALTH_CHECK

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

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

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

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

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

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

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

ההוראות האלה מניחות שיצרתם בדיקת תקינות של HTTP ‏ (regional-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=LOAD_BALANCING_SCHEME\
    --protocol=HTTP \
    --health-checks=regional-lb-basic-check \
    --health-checks-region="$region" \
    --region="$region"; \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --region="$region")
}

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

מתקשרים לפונקציה כדי ליצור שלוש שירותים, 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

המסוף

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

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

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

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

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

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

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

gcloud

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

gcloud compute url-maps export regional-lb-map \
  --destination=regional-lb-map-config.yaml \
  --region=us-west1

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

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

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

gcloud compute url-maps import regional-lb-map \
   --region=us-west1 \
   --source=regional-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 \
    --region=us-west1
```

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

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

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

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

gcloud compute backend-services import red-service \
    --source=red-service-config.yaml \
    --region=us-west1

פתרון בעיות

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

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

תסמינים:

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

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

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

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

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

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

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

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

הגדרת ניהול טראפיק

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

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

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

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

תנועה משתקפת

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

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

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

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

הגדרת CORS

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

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

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

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

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

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

יצירת מפת URL

המסוף

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

gcloud

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

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

פתרון בעיות

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

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

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