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

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

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

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

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

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

הגדרת TargetServer

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

דוגמה לתצורה של TargetServer:

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

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

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

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

MaxFailures

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

הגדרה לדוגמה עם MaxFailures שצוינה:

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

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

נגד דוגמת עיצוב

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

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

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

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

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

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

השפעה

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

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

שיטה מומלצת

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

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

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

קריאה נוספת

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