איזון עומסים בין שרתים עורפיים

אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info

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 שני. הגדרת שני TargetServers מספקת שתי כתובות 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
}

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

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

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

[ "target2", "target1" ]

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

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

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

עכשיו, כשיש לכם שני שרתי 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 הוא האלגוריתם שמוגדר כברירת מחדל. מאחר שלא צוין אלגוריתם בהגדרה שלמעלה, בקשות יוצאות משרת ה-proxy של ה-API לשרתים לקצה העורפי יתחלפו, אחת לאחת, בין target1 ל-target 2.

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

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

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

אלגוריתם

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

סדר אקראי

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

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

שקלול

האלגוריתם של איזון העומסים המשוקללים מאפשר להגדיר עומסי תנועה יחסיים בשרתים היעד. ה-LoadBalancer המשוקל מחלק את הבקשות ל-TargetServers ביחס ישיר למשקל של כל 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>

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

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 לא מקבלת תגובה משרת יעד. במקרה כזה, מונה הכשלים יגדל באחד.

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

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

ניסיון חוזר

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

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

<RetryEnabled>false</RetryEnabled>

IsFallback

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

<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 לא יהיו זמינים. כשהיעדים 1 ו-2 לא זמינים, כל התנועה מנותבת ליעד 3.

נתיב

Path מגדיר קטע 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>

אם שירות הקצה העורפי מחייב TLS/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 וענן פרטי).

הסכימה של TargetServer

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

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

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

מעקב אחר בריאות פועל עם <MaxFailures>. אם לא מפעילים את מעקב התקינות, הערך של <MaxFailures> מציין את מספר הבקשות שנכשלו מהשרת המתווך של ה-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 במבנה ספרייה מוגדר מראש. למידע נוסף, ראו חומר עזר בנושא הגדרת שרת proxy ל-API.

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

TCPMonitor

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

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

אפשר להוסיף את 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 Basic Authorization להודעת הבקשה. בתצורת התגובה מוגדרות ההגדרות שיושוו לתגובה בפועל משירות הקצה העורפי. בדוגמה הבאה, התגובה הצפויה היא קוד תגובה של HTTP‏ 200 וכותרת 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: