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

מוצג התיעוד של Apigee Edge.
נכנסים למסמכי התיעוד של Apigee X.
מידע

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

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

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

סרטונים

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

וידאו תיאור
איזון עומסים באמצעות שרתי יעד ממשקי API של איזון עומסים בשרתי יעד.
ניתוב API על סמך סביבה באמצעות שרתי יעד נתב API לשרת יעד אחר על סמך הסביבה.
ניתוב API ואיזון עומסים באמצעות שרתי יעד (Classic Edge) ניתוב API לשרת יעד אחר על סמך הסביבה ואיזון העומסים ב-API בין שרתי היעד בממשק המשתמש של Classic Edge.

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

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

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

רכיבי התצורה של שרת היעד

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

שם תיאור ברירת המחדל חובה?
name השם של תצורת TargetServer, שחייב להיות ייחודי בסביבה. שם שרת היעד יכול להכיל תווים אלפאנומריים בלבד. לא רלוונטי כן
Host

כתובת ה-URL של המארח של השירות לקצה העורפי (ללא הפרוטוקול).

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

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

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

Edge

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

  1. נכנסים לאתר apigee.com/edge.
  2. בסרגל הניווט הימני בוחרים באפשרות ניהול > סביבות > שרתי יעד.
  3. בוחרים את הסביבה הרצויה, כמו test או prod.
  4. כדי ליצור שרת יעד:
    1. לוחצים על + שרת יעד.
    2. צריך להזין שם, מארח ויציאה לשרת היעד.

      למשל:

      • שם: target1
      • מארח: 1.mybackendservice.com
      • יציאה: 80
    3. בוחרים באפשרות SSL, אם צריך.
    4. בוחרים באפשרות מופעל כדי להפעיל את שרת היעד.
    5. לוחצים על Add.
  5. כדי לערוך את שרת היעד:
    1. מעבירים את סמן העכבר מעל שרת היעד שרוצים לערוך כדי להציג את תפריט הפעולות.
    2. לוחצים על .
    3. עריכת הערכים של שרת targer.
    4. לוחצים על עדכון.
  6. כדי למחוק את שרת היעד:
    1. מעבירים את סמן העכבר מעל שרת היעד שרוצים למחוק כדי להציג את תפריט הפעולות.
    2. לוחצים על .
    3. לוחצים על מחיקה כדי לאשר את הפעולה.

Classic Edge (ענן פרטי)

כדי לגשת לאשף יצירת שרת proxy באמצעות ממשק המשתמש Classic Edge:

  1. נכנסים אל http://ms-ip:9000, כאשר ms-ip הוא כתובת ה-IP או שם ה-DNS של הצומת של שרת הניהול.
  2. בסרגל הניווט הימני בוחרים באפשרות APIs > Environment Configuration > Target Servers (שרתי יעד).
  3. בוחרים את הסביבה הרצויה, כמו test או prod.
  4. כדי ליצור שרת יעד:
    1. לוחצים על עריכה.
    2. לוחצים על + שרת יעד.
    3. צריך להזין שם, מארח ויציאה לשרת היעד.

      למשל:

      • שם: target1
      • מארח: 1.mybackendservice.com
      • יציאה: 80
    4. בוחרים באפשרות מופעל כדי להפעיל את שרת היעד.
    5. לוחצים על שמירה.
  5. כדי לערוך את שרת היעד:
    1. לוחצים על עריכה.
    2. עריכת הערכים של שרת targer.
    3. לוחצים על שמירה.
  6. כדי למחוק את שרת היעד:
    1. לוחצים על עריכה.
    2. לוחצים על מחיקה.

ניהול שרתי היעד באמצעות ה-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
}

השתמש בקריאה הבאה ל-API על מנת לאחזר רשימה של TargetServers בסביבה:

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

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

[ "target2", "target1" ]

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

יש מגבלה של 500 TargetServers לכל סביבה, כפי שמצוין בנושא Limits.

הגדרת TargetEndpoint כדי לטעון יתרה בין שרתי TargetServers בעלי שם

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

הרכיב <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>

שקלול

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

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

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

הסכימה של שרת היעד

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

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

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

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

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

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

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

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

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

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

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

    כש-Edge מזהה ששרת מסוים תקין, היא ממשיכה לשלוח אליו בקשות או ממשיכה לשלוח אליו בקשות.

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

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

הפעלת HealthMonitor

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

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

TCPMonitor

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

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

שם תיאור ברירת המחדל חובה?
IsEnabled ערך בוליאני שמפעיל או משבית את HealthMonitor. false לא
IntervalInSec מרווח הזמן בשניות, בין כל בקשת TCP של תשאול. 0 כן
ConnectTimeoutInSec השעה שבה צריך ליצור חיבור ליציאת ה-TCP כדי שהסטטוס ייחשב כמוצלח. אם ההתחברות במרווחי הזמן שצוין לא מתחברת, היא נספרת ככישלון, ולכן מספר הכישלונות של מאזן העומסים ל-TargetServer גדל. 0 כן
Port אפשרות. היציאה שבה יוגדר חיבור ה-TCP. אם לא צוינה יציאת TCPMonitor, יציאת TargetServer. 0 לא

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:

שם תיאור ברירת המחדל חובה?
IsEnabled ערך בוליאני שמפעיל או משבית את HealthMonitor. false לא
IntervalInSec מרווח הזמן בשניות, בין כל בקשת תשאול. 0 כן
Request

אפשרויות הגדרה של הודעת הבקשה היוצאת שנשלחת על ידי HealthMonitor לשרתי היעד בסבב.

הנתיב אינו תומך במשתנים.

לא רלוונטי כן
IsSSL המדיניות קובעת אם להשתמש ב-HTTPS (HTTP מאובטח) למעקב אחרי חיבורים.

ערכים פוטנציאליים:
  • true: נעשה שימוש בפרוטוקולי HTTP.
  • false: נעשה שימוש ב-HTTP.
  • לא צוין: משתמש בתצורת שרת היעד.
false לא
ConnectTimeoutInSec הזמן, בשניות, שבו לחיצת היד של חיבור TCP לשירות ה-HTTP חייבת להסתיים כדי להיחשב כמוצלחת. אם לא מתחברים במרווח הזמן שצוין, המערכת נחשבת ככשל, וכתוצאה מכך נספר מספר הכישלונות של Load Balancer ל-TargetServer. 0 לא
SocketReadTimeoutInSec הזמן, בשניות, שבו יש לקרוא את הנתונים משירות ה-HTTP כדי להיחשב להצלחה. אם הקריאה במרווח הזמן שצוין לא נקראה, הדבר נחשב ככשל, וכתוצאה מכך נספר מספר הכישלונות של Load Balancer ל-TargetServer. 0 לא
Port היציאה שבה יוגדר חיבור ה-HTTP לשירות הקצה העורפי. לא רלוונטי לא
Verb פועל ה-HTTP המשמש לכל בקשת HTTP של תשאול אל שירות הקצה העורפי . לא רלוונטי לא
Path הנתיב שמצורף לכתובת ה-URL שהוגדרה ב-TargetServer. צריך להשתמש ברכיב הנתיב כדי להגדיר 'נקודת קצה של סקר' בשירות ה-HTTP. לא רלוונטי לא

IncludeHealthCheckIdHeader

ההגדרה הזו מאפשרת לעקוב אחרי בקשות לבדיקת תקינות במערכות upstream. הערך IncludeHealthCheckIdHeader מקבל ערך בוליאני וברירת המחדל שלו היא false. אם המדיניות מוגדרת לערך true, יש Header בשם X-Apigee-Healthcheck-Id שמוזרק לבקשת בדיקת התקינות. הערך של הכותרת מוקצה באופן דינמי, בצורה ORG/ENV/SERVER_UUID/N, שבו ORG הוא שם הארגון, ENV הוא שם הסביבה, SERVER_UUID הוא מזהה ייחודי שמזהה את ה-MP, ו-N הוא מספר אלפיות השנייה שחלפו מאז 1 בינואר 1970.

דוגמה לכותרת בקשה שמתקבלת:

X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123
false לא
Payload גוף ה-HTTP שנוצר לכל בקשת HTTP לתשאול. שימו לב שהרכיב הזה לא נדרש עבור בקשות GET. לא רלוונטי לא
SuccessResponse אפשרויות התאמה להודעת תגובת HTTP הנכנסת שנוצרה על ידי השירות לקצה העורפי שנדגם. תשובות שלא תואמות מגדילות את מספר הכשלים ב-1. לא רלוונטי לא
ResponseCode קוד תגובת ה-HTTP שאמור להתקבל משרת היעד שנדגם. קוד ששונה מהקוד שצוין יוביל לכשל, והמספר יתווסף לשירות לקצה העורפי של הסקר. ניתן להגדיר מספר רכיבים של ResponseCode. לא רלוונטי לא
Headers רשימה של כותרת HTTP וערכים אחד או יותר שצפויים להתקבל מהשירות לקצה העורפי שנדגם. כל כותרת HTTP או ערכי HTTP בתגובה ששונים מאלה שצוינו גורמים לכשל, והספירה של TargetServer שנבדק עולה ב-1. ניתן להגדיר מספר רכיבי כותרת. לא רלוונטי לא