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

אתם צופים במסמכי התיעוד של 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" ]

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

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

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

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

החיבור הכי פחות פעיל

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

ניסיון חוזר

אם האפשרות 'ניסיון חוזר' מופעלת, המערכת תנסה לשלוח שוב בקשה בכל פעם שמתרחש כשל בתגובה (שגיאת קלט/פלט או פסק זמן של 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>

אם שירות לקצה העורפי דורש 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 אל ה-Backend (Cloud ו-Private Cloud).

סכימת TargetServer

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

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

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

המעקב אחר הבריאות פועל עם <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 ממשיך או מחדש את שליחת הבקשות אליו.

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