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

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

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

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

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

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

גם אם השרת TargetServer ‏target1 חוזר למצב תקין ויכול לשלוח תגובות מוצלחות, הבקשות ל-API Proxy ימשיכו להחזיר שגיאות 503. הסיבה לכך היא ש-Edge לא מחזיר את TargetServer באופן אוטומטי לרוטציה גם אחרי שהיעד חוזר לפעולה. כדי לפתור את הבעיה, צריך לפרוס מחדש את ה-API Proxy כדי שמערכת Edge תחזיר את 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 מבטיח ש-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 תמיד מנסה להתחבר ליעד לכל בקשה, ולעולם לא מסירה את שרת היעד מהרוטציה.

קריאה נוספת