יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

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

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

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

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

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

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

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

מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) משתמשים ב-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 האלה, אפשר להשתמש בדוגמאות שבדף הזה ובמסמכי התיעוד של Cloud Load Balancing API.

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

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

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

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

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

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

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

Path matcher YAML examples

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

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

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

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

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

    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

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

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

   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

תנועה משוכפלת

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

כברירת מחדל, שירות הקצה העורפי המשוכפל מקבל את כל הבקשות, גם אם התנועה המקורית מפולחת בין כמה שירותי קצה עורפי משוקללים. אתם יכולים להגדיר את שירות ה-backend המשוכפל כך שיקבל רק אחוז מסוים מהבקשות באמצעות האפשרות 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 ובקצה העורפי של 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

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

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

   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

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

הוספה והסרה של כותרות בקשה לפני שליחת בקשה לשירות backend. אפשר גם להוסיף ולהסיר כותרות של תגובות אחרי שמקבלים תגובה משירות ה-Backend.

מאזני עומסים חיצוניים אזוריים של אפליקציות (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

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

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

    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

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

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

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

    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 במסוף Cloud de Confiance .

כניסה לדף Load balancing
לוחצים על הקישור regional-lb-map.
לוחצים על עריכה .

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

בקטע כללי ניתוב, בוחרים באפשרות כלל מתקדם של מארח ונתיב.
בקטע Hosts and path rule (כלל של מארחים ונתיבים), כדי ליצור את פעולת ברירת המחדל, מגדירים את Service (שירות) ל-red-service.
לוחצים על סיום.
לוחצים על הוספת כלל של מארח ונתיב.
בשדה מארחים, מזינים את כתובת ה-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 מפולחות כצפוי.

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

התכונה 'בקרת תנועה' מאפשרת להגדיר שיוך של סשנים על סמך קובץ Cookie שסופק. כדי להגדיר שיוך סשנים מבוסס-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 במסוף Cloud de Confiance

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

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

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

תנועה משוכפלת

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

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

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

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

הגדרת CORS

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

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

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

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

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

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

יצירת מפת URL

המסוף

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

gcloud

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

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

פתרון בעיות

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

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