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

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

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

הגדרות של targetServer מפרידות בין כתובות URL קונקרטיות של נקודות קצה מ-TargetEndpoint הגדרות אישיות. בנקודת קצה קצה (TargetEndpoint) יש הפניה לכל שרת targetServer HTTPConnection. במקום להגדיר כתובת URL קונקרטית בתצורה, אפשר להגדיר כתובת או בשם TargetServers, כפי שמתואר בקטע 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
}

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

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

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

[ "target2", "target1" ]

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

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

הגדרת TargetEndpoint לטעינת יתרה ב-TargetServers בעלי שם

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

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

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

הרכיב <Path> יוצר את הנתיב הבסיסי של ה-URI של נקודת הקצה של יעד עבור את כל שרתי היעד. היא בשימוש רק כשנעשה שימוש ב-<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>

שקלול

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

חיבור מינימלי

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

ניסיון חוזר

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

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

<RetryEnabled>false</RetryEnabled>

IsFallback

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

<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.

נתיב

הנתיב מגדיר קטע 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 ו-Private Cloud).

סכימת TargetServer

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

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

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