איזון עומסים בין שרתים לקצה העורפי

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

‫Apigee Edge משפר את הזמינות של ה-API באמצעות תמיכה מובנית באיזון עומסים ובמעבר אוטומטי לגיבוי (failover) בכמה מופעים של שרת קצה עורפי.

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

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

סרטונים

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

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

הקוד הבא מגדיר שרת יעד:

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

רכיבי ההגדרה של TargetServer

בטבלה הבאה מפורטים הרכיבים שמשמשים ליצירה ולהגדרה של TargetServer:

ניהול שרתי היעד באמצעות ממשק המשתמש

מנהלים את שרתי היעד, כמו שמתואר בהמשך.

ניהול שרתי היעד באמצעות ה-API

אתם יכולים להשתמש ב-Edge API כדי ליצור, למחוק, לעדכן, לקבל ולרשום שרתי יעד. מידע נוסף זמין במאמר TargetServers.

כדי ליצור שרת יעד, משתמשים בקריאה הבאה ל-API:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

דוגמה לתשובה:

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

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

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

דוגמה לתשובה:

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

כדי לאחזר רשימה של TargetServer בסביבה, משתמשים בקריאה הבאה ל-API:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

דוגמה לתשובה:

[ "target2", "target1" ]

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

יש מגבלה של 500 שרתי יעד לכל סביבה, כפי שמתואר במאמר בנושא מגבלות.

הגדרת TargetEndpoint לאיזון עומסים בין TargetServers עם שמות

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

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

ההגדרה שלמעלה היא ההגדרה הבסיסית ביותר האפשרית לאיזון עומסים. מאזן העומסים תומך בשלושה אלגוריתמים לאיזון עומסים: Round Robin,‏ Weighted ו-Least Connection. האלגוריתם שמוגדר כברירת מחדל הוא Round Robin. מכיוון שלא צוין אלגוריתם בהגדרה שלמעלה, בקשות יוצאות משרת ה-API proxy לשרתי הקצה העורפי יתחלפו, אחת אחת, בין target1 ל-target2.

רכיב <Path> יוצר את נתיב הבסיס של ה-URI של TargetEndpoint לכל שרתי היעד. היא בשימוש רק כשמשתמשים ב-<LoadBalancer>. אחרת, המערכת תתעלם ממנו. בדוגמה שלמעלה, בקשה שמגיעה אל target1 תהיה http://target1/test, וכך גם לגבי שרתי יעד אחרים.

הגדרת אפשרויות של מאזן עומסים

אפשר לשפר את הזמינות באמצעות אפשרויות לאיזון עומסים וליתרות כשל ברמת מאזן העומסים וברמת TargetServer. בקטע הזה מפורטות האפשרויות האלה.

אלגוריתם

מגדירה את האלגוריתם שמשמש את <LoadBalancer>. האלגוריתמים הזמינים הם RoundRobin, Weighted ו-LeastConnections, וכל אחד מהם מתואר בהמשך.

סדר אקראי

אלגוריתם ברירת המחדל, round robin, מעביר בקשה לכל TargetServer לפי הסדר שבו השרתים מופיעים בחיבור ה-HTTP של נקודת היעד. לדוגמה:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

שקלול

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

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

בדוגמה הזו, כל בקשה שמופנית אל target1 תגרום להפניית שתי בקשות אל target2.

Least Connection

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

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

מספר הכשלים המקסימלי

המספר המקסימלי של בקשות שנכשלו מ-proxy ל-API ל-TargetServer שגורם להפניה של הבקשה ל-TargetServer אחר.

כשל בתגובה פירושו שלא מתקבלת תגובה משרת יעד ב-Apigee. במקרה כזה, מוסיפים 1 למונה הכשלים.

עם זאת, כש-Apigee מקבל תגובה מיעד, גם אם התגובה היא שגיאת HTTP (למשל 500), היא נחשבת כתגובה משרת היעד, והמונה של הכשלים מתאפס. כדי לוודא שתגובות HTTP לא תקינות (כמו 500) יגרמו גם להגדלת מונה הכשלים, כך ששרת לא תקין יוצא מרוטציית איזון העומסים בהקדם האפשרי, אפשר להוסיף את הרכיב <ServerUnhealthyResponse> עם רכיבי צאצא <ResponseCode> להגדרת מאזן העומסים. דפדפן Edge יספור גם תגובות עם הקודים האלה ככשלים.

בדוגמה הבאה, target1 יוסר מהרוטציה אחרי חמש בקשות שנכשלו, כולל כמה תגובות 5XX מהשרת היעד.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

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

מומלץ להשתמש ב-MaxFailures > 0 עם HealthMonitor. אם מגדירים MaxFailures > 0, שרת היעד מוסר מהרוטציה כשהיעד נכשל במספר הפעמים שצוין. כש-HealthMonitor מוגדר, Apigee מחזיר אוטומטית את TargetServer לרוטציה אחרי שהיעד חוזר לפעולה, בהתאם להגדרות של HealthMonitor. מידע נוסף זמין במאמר בנושא מעקב אחר תקינות.

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

ניסיון חוזר

אם האפשרות 'ניסיון חוזר' מופעלת, המערכת תנסה לשלוח שוב בקשה בכל פעם שמתרחשת שגיאה בתגובה (שגיאת קלט/פלט (I/O) או זמן קצוב לתפוגה של HTTP) או שהתגובה שהתקבלה תואמת לערך שהוגדר על ידי <ServerUnhealthyResponse>. מידע נוסף על הגדרת <ServerUnhealthyResponse> מופיע בקטע מספר מקסימלי של ניסיונות כושלים שלמעלה.

כברירת מחדל, הערך של <RetryEnabled> הוא true. מגדירים את הערך false כדי להשבית את הניסיון החוזר. לדוגמה:

<RetryEnabled>false</RetryEnabled>

IsFallback

אפשר להגדיר שרת יעד אחד (ורק אחד) כשרת ברירת המחדל. שרת היעד לגיבוי לא נכלל בשגרות איזון העומסים עד שמאזן העומסים מזהה שכל שרתי היעד האחרים לא זמינים. כשמאזן העומסים קובע שכל שרתי היעד לא זמינים, כל התנועה מנותבת לשרת הגיבוי. לדוגמה:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

ההגדרה שלמעלה גורמת לאיזון עומסים בשיטת סדר סיבובי בין יעדים 1 ו-2 עד ששני היעדים האלה לא זמינים. אם היעדים 1 ו-2 לא זמינים, כל התנועה מנותבת ליעד 3.

נתיב

הנתיב מגדיר קטע URI שיתווסף לכל הבקשות שמונפקות על ידי TargetServer לשרת העורפי.

האלמנט הזה מקבל נתיב מחרוזת מילולי או תבנית הודעה. תבנית של הודעה מאפשרת לבצע החלפה של מחרוזת משתנה בזמן הריצה. לדוגמה, בהגדרת נקודת הקצה הבאה של היעד, הערך של {mypath} משמש לנתיב:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

הגדרת שרת יעד עבור TLS/SSL

אם אתם משתמשים ב-TargetServer כדי להגדיר את שירות לקצה העורפי, ושירות לקצה העורפי דורש שהחיבור ישתמש בפרוטוקול HTTPS, אתם צריכים להפעיל TLS/SSL בהגדרה של TargetServer. הדבר נדרש כי התג <Host> לא מאפשר לציין את פרוטוקול החיבור. בהמשך מוצגת ההגדרה של TargetServer עבור TLS/SSL חד-כיווני, שבו Edge שולח בקשות HTTPS לשירות לקצה העורפי:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

אם שירות לקצה העורפי דורש Mutual TLS (mTLS)/SSL דו-כיווני או הדדי, צריך להגדיר את TargetServer באמצעות אותן הגדרות תצורה של TLS/SSL כמו TargetEndpoints:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

מידע על המאפיינים של <SSLInfo>, כמו <Ciphers> ו-<ClientAuthEnabled>, זמין במאמר הגדרת גישת TLS ל-API בענן פרטי.

הוראות מלאות להגדרת TLS/SSL יוצא זמינות במאמר הגדרת TLS מ-Edge לקצה העורפי (Cloud ו-Private Cloud).

סכימת TargetServer

תוכלו לראות את הסכימה של TargetServer וישויות אחרות ב- GitHub.

מעקב אחר בריאות

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

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

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

ה-HealthMonitor פועל כלקוח פשוט שמפעיל שירות לקצה העורפי באמצעות TCP או HTTP:

• לקוח TCP פשוט מוודא שאפשר לפתוח שקע.
• מגדירים את צד הלקוח ב-HTTP לשליחת בקשת HTTP תקפה לשירות לקצה העורפי. אפשר להגדיר פעולות HTTP GET,‏ PUT,‏ POST או DELETE. התגובה של קריאת הניטור של HTTP צריכה להתאים להגדרות שהוגדרו בבלוק <SuccessResponse>.

הצלחות וכישלונות

כשמפעילים את המעקב אחר תקינות, Edge מתחיל לשלוח בדיקות תקינות לשרת היעד. בדיקת תקינות היא בקשה שנשלחת לשרת היעד כדי לקבוע אם הוא תקין או לא.

בדיקת תקינות יכולה להניב אחת משתי תוצאות אפשריות:

• הצלחה: השרת היעד נחשב תקין כשמתבצעת בדיקת תקינות מוצלחת. בדרך כלל זה קורה בגלל אחת או יותר מהסיבות הבאות:
  • שרת היעד מקבל חיבור חדש ליציאה שצוינה, מגיב לבקשה ביציאה הזו ואז סוגר את היציאה בתוך מסגרת הזמן שצוינה. התגובה משרת היעד מכילה את המחרוזת Connection: close
  • שרת היעד מגיב לבקשת בדיקת תקינות עם קוד 200 (OK) או עם קוד סטטוס אחר של HTTP שאתם קובעים שהוא קביל.
  • שרת היעד מגיב לבקשת בדיקת תקינות עם גוף הודעה שתואם לגוף ההודעה הצפוי.

  כש-Edge קובע שהשרת תקין, הוא ממשיך או מחדש את שליחת הבקשות אליו.

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

  כששרת יעד נכשל בבדיקת תקינות, Edge מגדיל את מספר הכשלים של השרת. אם מספר הכשלים בשרת הזה מגיע לסף מוגדר מראש או עובר אותו (<MaxFailures>), ‏ Edge מפסיק לשלוח בקשות לשרת הזה.

הפעלת HealthMonitor

כדי ליצור HealthMonitor, מוסיפים את הרכיב <HealthMonitor> להגדרת HTTPConnection של TargetEndpoint עבור שרת proxy. אי אפשר לעשות את זה בממשק המשתמש. במקום זאת, יוצרים הגדרת proxy ומעלים אותה כקובץ ZIP ל-Edge. הגדרת שרת proxy היא תיאור מובנה של כל ההיבטים של proxy ל-API. הגדרות ה-Proxy מורכבות מקובצי XML במבנה ספריות מוגדר מראש. מידע נוסף זמין במאמר הפניית הגדרות של API Proxy.

ב-HealthMonitor פשוט מוגדר IntervalInSec בשילוב עם TCPMonitor או HTTPMonitor. רכיב <MaxFailures> מציין את המספר המקסימלי של בקשות שנכשלו מ-proxy ל-API אל TargetServer, שמוביל להפניה של הבקשה אל TargetServer אחר. כברירת מחדל, הערך של <MaxFailures> הוא 0, כלומר Edge לא מבצע פעולת תיקון. כשמגדירים את הכלי למעקב אחר תקינות, צריך לוודא שהערך של <MaxFailures> בתג <HTTPTargetConnection> של התג <TargetEndpoint> הוא ערך שונה מאפס.

TCPMonitor

ההגדרה הבאה מגדירה HealthMonitor ששולח שאילתות לכל TargetServer על ידי פתיחת חיבור ביציאה 80 כל חמש שניות. (היציאה היא אופציונלית. אם לא מציינים את היציאה, היציאה של TCPMonitor היא היציאה של TargetServer).

• אם החיבור נכשל או שנמשך יותר מ-10 שניות, מוסיפים 1 לספירת הכשלים של אותו TargetServer.
• אם החיבור מצליח, מונה הכשלים של TargetServer מאופס ל-0.

אפשר להוסיף HealthMonitor כאלמנט צאצא של האלמנט HTTPTargetConnetion של TargetEndpoint, כמו בדוגמה הבאה:

<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>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

‫HealthMonitor עם רכיבי הגדרה של TCPMonitor

בטבלה הבאה מתוארים רכיבי ההגדרה של TCPMonitor:

HTTPMonitor

דוגמה ל-HealthMonitor שמשתמש ב-HTTPMonitor תשלח בקשת GET לשירות הקצה העורפי פעם בחמש שניות. בדוגמה שלמטה מוסיפים כותרת של אימות בסיסי ב-HTTP להודעת הבקשה. הגדרת התגובה מגדירה הגדרות שיושוו לתגובה בפועל משירות הקצה העורפי. בדוגמה שלמטה, התשובה הצפויה היא קוד תשובה 200 של HTTP וכותרת HTTP מותאמת אישית ImOK שהערך שלה הוא YourOK. אם התשובה לא תואמת, הבקשה תטופל כבקשה שנכשלה בהגדרות של איזון העומסים.

הכלי HTTPMonitor תומך בשירותי בק-אנד שהוגדרו לשימוש בפרוטוקולים HTTP ו-HTTPS חד-כיווני. עם זאת, אין תמיכה ב:

• ‫HTTPS דו-כיווני (נקרא גם TLS/SSL דו-כיווני)
• אישורים בחתימה עצמית

שימו לב שכל ההגדרות של בקשות ותגובות במוניטור HTTP יהיו ספציפיות לשירות הקצה העורפי שצריך להפעיל.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

‫HealthMonitor עם רכיבי הגדרה של HTTPMonitor

בטבלה הבאה מפורטים רכיבי ההגדרה של HTTPMonitor: