אנטי-דפוס: איזון עומסים עם שרת יעד יחיד שבו מוגדר MaxFailures לערך שאינו אפס

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

בהגדרות האישיות של TargetEndpoint מוגדר האופן שבו Apigee Edge מתחבר לשירות או ל-API בקצה העורפי. הוא שולח את הבקשות ומקבל את התשובות לשירות לקצה העורפי או ממנו. השירות לקצה העורפי יכול להיות שרת HTTP/HTTPS, NodeJS או יעד מתארח.

ניתן להפעיל את השירות לקצה העורפי ב-TargetEndpoint באחת מהדרכים הבאות:

• הפניית כתובת URL לשרת HTTP או HTTPS
• ScriptTarget לסקריפט Node.js המתארח ב-Edge
• HostedTarget ל-NodeJS שנפרסה בסביבת היעד המתארחת
• הגדרת שרת יעד

באופן דומה, אפשר להשתמש במדיניות בנושא יתרונות מרכזיים של שירות כדי לבצע קריאה לכל שירות חיצוני דרך התהליך של שרת ה-API של שרת ה-proxy. במדיניות הזו יש תמיכה בהגדרת כתובות URL של יעד HTTP/HTTPS ישירות במדיניות עצמה או באמצעות הגדרת TargetServer.

הגדרת שרת יעד

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

זוהי דוגמה לתצורת TargetServer:

<TargetServer name="target1">
  <Host>www.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>

שרת היעד מאפשר לקבוע הגדרות שונות לכל סביבה. אפשר להגדיר מדיניות של TargetEndpoint/הסבר על שירות עם שם אחד או יותר מסוג TargetServers באמצעות Load Balancer. התמיכה המובנית באיזון העומסים משפרת את הזמינות של ממשקי ה-API ויתירות הכשל במכונות המוגדרות של שרת הקצה העורפי.

הנה דוגמה לתצורת TargetEndpoint באמצעות TargetServers:

<TargetEndpoint name="default">
    <HTTPTargetConnection>>
      <LoadBalancer>
        <Server name="target1"/>
      <Server name="target2"/>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

MaxFailures

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

מערך הגדרות אישיות לדוגמה שצוין בשדה MaxFailures:

<TargetEndpoint name="default">
    <HTTPTargetConnection>
      <LoadBalancer>
        <Server name="target1"/>
       <Server name="target2"/>
       <MaxFailures>5</MaxFailures>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

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

דוגמת עיצוב

לא מומלץ להגדיר שרת יעד יחיד בתצורה LoadBalancer של המדיניות TargetEndpoint או היתרונות המרכזיים של השירות, כאשר MaxFailures מוגדר לערך שאינו אפס, כי עלולות להיות לכך השלכות שליליות.

נשתמש בתצורה לדוגמה הבאה, עם TargetServer אחד בשם "target1" שבו MaxFailures מוגדר ל-5 (ערך שאינו אפס):

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
  </HTTPTargetConnection>

אם הבקשות ל-TargetServer [יעד1] נכשלות חמש פעמים (המספר שצוין ב-MaxFailures), שרת היעד מוסר מהסבב. מאחר שאין שרתי TargetServer אחרים שלא יכשלו בהם המעבר, כל הבקשות שיישלחו לשרת ה-Proxy של API עם ההגדרה הזו ייכשלו ותוצג השגיאה 503 Service Unavailable.

גם אם ה-TargetServer "target1" חוזר למצב הרגיל והוא יכול לשלוח תשובות מוצלחות, הבקשות ל-API מסוג שרת proxy ימשיכו להחזיר שגיאות 503. הסיבה לכך היא ש-Edge לא מחזיר באופן אוטומטי את TargetServer לסבב, גם לאחר שהיעד פועל שוב. כדי לפתור את הבעיה, צריך לפרוס מחדש את שרת ה-Proxy של API כדי ש-Edge תחזיר את שרת היעד לרוטציה.

אם משתמשים באותה הגדרה במדיניות 'יתרונות מרכזיים של שירות', בקשות ה-API יקבלו שגיאה 500 אחרי שבקשות ל-'target1' שיישלחו ל-TargetServer ייכשלו 5 פעמים.

השפעה

אם משתמשים ב-TargetServer יחיד בתצורה LoadBalancer של המדיניות TargetEndpoint או היתרונות המרכזיים של השירות, כאשר MaxFailures מוגדר לערך שאינו אפס:

• בקשות API נכשלות באופן רציף עם שגיאות 503/500 (לאחר שהבקשות נכשלות עבור מספר מקסימלי של פעמים) עד לפריסה מחדש של שרת ה-proxy של ה-API.
• הפסקה זמנית בשירות ארוכה יותר, מאחר שהיא מורכבת באופן מסובך ונדרש זמן רב יותר לאבחון הגורם לבעיה הזו (ללא מידע מוקדם על התבנית הזו).

שיטה מומלצת

1. יש יותר משרת TargetServer אחד בתצורה של LoadBalancer לזמינות גבוהה יותר.

2. יש להגדיר תמיד מעקב אחר Health כאשר MaxFailures מוגדר לערך שאינו אפס. שרת היעד יוסר מהסבב כשמספר הכישלונות יגיע למספר שצוין ב-MaxFailures. שימוש ב-HealthMonitor מבטיח ששרת היעד יוחזר לסבב ברגע ששרת היעד יהיה זמין שוב, כלומר אין צורך לפרוס מחדש את שרת ה-Proxy.

   כדי לוודא שבדיקת התקינות מתבצעת באותו מספר יציאה שבו משתמשים ב-Edge כדי להתחבר לשרתי היעד, ההמלצה של Apigee היא להשמיט את רכיב הצאצא <Port> שב-<TCPMonitor>, אלא אם הוא שונה מיציאת TargetServer. כברירת מחדל, <Port> זהה ליציאת TargetServer.

   הגדרה לדוגמה באמצעות HealthMonitor:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <LoadBalancer>
         <Algorithm>RoundRobin</Algorithm>
         <Server name="target1" />
         <Server name="target2" />
         <MaxFailures>5</MaxFailures>
       </LoadBalancer>
       <Path>/test</Path>
       <HealthMonitor>
         <IsEnabled>true</IsEnabled>
         <IntervalInSec>5</IntervalInSec>
         <TCPMonitor>
           <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         </TCPMonitor>
       </HealthMonitor>
     </HTTPTargetConnection>
   </TargetEndpoint>
   

3. אם קיים אילוץ מסוים שרק שרת יעד אחד ולא נעשה בו שימוש ב-HealthMonitor, אסור לציין MaxFailures בהגדרה של LoadBalancer.

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

קריאה נוספת

• איזון עומסים בין שרתים עורפיים
• איך משתמשים בשרתי יעד בשרתי proxy ל-API