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

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

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

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

• כתובת URL ישירה לשרת HTTP או HTTPS
• הגדרת TargetServer

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

הגדרת TargetServer

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

הנה דוגמה להגדרת TargetServer:

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

ה-TargetServer מאפשר לכם להגדיר תצורות שונות לכל סביבה. אפשר להגדיר מדיניות TargetEndpoint/Service Callout עם שרת Target אחד או יותר שנקראים באמצעות LoadBalancer. התמיכה המובנית באיזון עומסים משפרת את הזמינות של ממשקי ה-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 של מדיניות TargetEndpoint או Service Callout עם 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 מוסר מהרוטציה. מכיוון שאין שרתי יעד אחרים שאפשר לעבור אליהם במקרה של כשל, כל הבקשות הבאות ל-API Proxy עם ההגדרה הזו ייכשלו עם השגיאה 503 Service Unavailable.

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

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

השפעה

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

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

שיטה מומלצת

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

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

   כדי לוודא שבדיקת תקינות מתבצעת באותו מספר יציאה שבו 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. המשמעות היא שמערכת Apigee תמיד מנסה להתחבר ליעד עבור כל בקשה, ואף פעם לא מסירה את שרת היעד מהרוטציה.

קריאה נוספת

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