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

המאמר הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

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

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

סרטונים

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

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

מידע על הגדרת שרת היעד

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

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

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

מידע נוסף על TargetServers API זמין במאמר בנושא organizations.environments.targetservers.

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

יצירת שרתי יעד

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

ממשק המשתמש של Apigee

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

במסוף Google Cloud , עוברים לדף Apigee > Management > Environments.

מעבר אל Environments
בוחרים את הסביבה שבה רוצים להגדיר שרת יעד חדש.
לוחצים על Target Servers (שרתי יעד) בחלק העליון של החלונית.
לוחצים על + יצירת שרת יעד.
מזינים שם, מארח, פרוטוקול ויציאה בשדות שמופיעים. האפשרויות לפרוטוקול הן: HTTP לשרתי יעד מבוססי REST,‏ gRPC – יעד לשרתי יעד מבוססי gRPC או gRPC – קריאה חיצונית. מידע על תמיכה ב-gRPC proxy זמין במאמר בנושא יצירת שרתי proxy של gRPC API.
אפשר גם לבחור באפשרות הפעלה של SSL. מידע נוסף זמין במאמר סקירה כללית על אישורי SSL.
לוחצים על יצירה.

Apigee API

בסעיפים הבאים מופיעות דוגמאות לשימוש ב-Apigee API כדי ליצור שרתי יעד ולפרט אותם.

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

מידע נוסף זמין במאמר בנושא TargetServers API.

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

כדי ליצור שרת יעד בשם target1 שמתחבר ל-1.mybackendservice.com ביציאה 80, משתמשים בקריאה הבאה ל-API:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

‫$TOKEN מוגדר לאסימון הגישה מסוג OAuth 2.0, כפי שמתואר במאמר קבלת אסימון גישה מסוג OAuth 2.0. מידע על האפשרויות curl שבהן נעשה שימוש בדוגמה הזו מופיע במאמר שימוש ב-curl. תיאור של משתני הסביבה שבהם אפשר להשתמש מופיע במאמר בנושא הגדרת משתני סביבה לבקשות API של Apigee.

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

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

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

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target2",
  "host": "2.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

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

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

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

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

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

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

[ "target2", "target1" ]

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

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

עכשיו שיש לכם שני שרתי יעד זמינים, אתם יכולים לשנות את רכיב <HTTPTargetConnection> של נקודת הקצה של היעד כדי להפנות לשני שרתי היעד האלה לפי שם:

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

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

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

למידע נוסף, אפשר לעיין במאמר בנושא TargetEndpoint.

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

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

אלגוריתם

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

סדר אקראי

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

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

משוקלל

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לחלופין, אם מגדירים את 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>

ההגדרה שלמעלה גורמת לאיזון עומסים מסוג סדר סיבובי בין target1 לבין target2 עד שגם target1 וגם target2 לא זמינים. אם target1 ו-target2 לא זמינים, כל התנועה מנותבת אל target3.

אם השרת לגיבוי לא תקין, Apigee לא ינתב אליו תנועה. במקום זאת, קריאות ל-API יחזירו את השגיאה 503 'השירות לא זמין באופן זמני'.

נתיב

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

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

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

הגדרת שרת יעד ל-TLS/SSL

אם אתם משתמשים בשרת יעד כדי להגדיר את שירות לקצה העורפי, ושירות לקצה העורפי דורש שהחיבור ישתמש בפרוטוקול HTTPS, אתם צריכים להפעיל TLS/SSL בהגדרת שרת היעד. הדבר נחוץ כי התג host לא מאפשר לציין את פרוטוקול החיבור.

הערה: אם מגדירים את הבלוק sSLInfo גם בנקודת הקצה של היעד וגם בהגדרת שרת היעד, ההגדרה בשרת היעד מקבלת עדיפות.

הגדרת TLS/SSL חד-כיווני

משתמשים בהגדרה הבאה כדי להגדיר שרת יעד עם TLS/SSL חד-כיווני. בדוגמה הזו, Apigee שולח בקשות HTTPS לשירות לקצה העורפי:

{
  "name": "target1",
  "host": "mocktarget.apigee.net",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true"
  }
}

הגדרת אכיפה מחמירה של SSL

כדי לציין אכיפה מחמירה של SSL בהגדרת שרת היעד, מגדירים את enforce ל-true בבלוק sSLInfo, כמו בדוגמה הבאה:

  {
    "name": "target1",
    "host": "mocktarget.apigee.net",
    "protocol": "http",
    "port": "443",
    "isEnabled": "true",
    "sSLInfo": {
      "enabled": "true",
      "enforce": "true"
    }
  }

הגדרת TLS/SSL דו-כיווני

אם שירות הקצה העורפי דורש TLS/SSL דו-כיווני או הדדי, אפשר להגדיר את שרת היעד עם אותן הגדרות של TLS/SSL כמו נקודות קצה של היעד:

{
  "name": "TargetServer 1",
  "host": "www.example.com",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true",
    "clientAuthEnabled": "true",
    "keyStore": "keystore-name",
    "keyAlias": "keystore-alias",
    "trustStore": "truststore-name",
    "ignoreValidationErrors": "false",
    "ciphers": []
  }
}

הגדרת SSL מחמיר באמצעות ה-API

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

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json"  \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
    "name": "TargetServer 1",
    "host": "www.example.com",
    "protocol": "http",
    "port": 443,
    "isEnabled": true,
    "sSLInfo":
    {
      "enabled":true,
      "enforce":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

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

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

כשמשתמשים בכלי לניטור תקינות, צריך להגדיר את <MaxFailures> כערך גדול מ-0. אם הערך של <MaxFailures> מוגדר כ-0,‏ Apigee תמיד תנסה להתחבר ליעד עבור כל בקשה, ולא תסיר את שרת היעד מהרוטציה.

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

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

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

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

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

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

הפעלת כלי תקינות

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

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

`<HealthMonitor>` רכיבי הגדרה

בטבלה הבאה מתוארים רכיבי ההגדרה <HealthMonitor>:

שם	תיאור	ברירת מחדל	חובה?
`IsEnabled`	ערך בוליאני שמפעיל או משבית את כלי המעקב אחר תקינות המכשיר.	FALSE	לא
`IntervalInSec`	מרווח הזמן, בשניות, בין כל בקשת TCP או HTTP של דגימה.	0	כן
‫`HTTPMonitor` או `TCPMonitor`	הגדרה של לקוח TCP או HTTP שישמש לבדיקת השרת היעד.	לא רלוונטי	כן

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

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

מעקב אחר תקינות באמצעות TCP monitor

הדוגמה לניטור תקינות שמתוארת בהגדרה הבאה משתמשת בניטור TCP כדי לבצע סקר של כל שרת יעד על ידי פתיחת חיבור ביציאה 80 כל חמש שניות. (היציאה היא אופציונלית. אם לא מציינים את היציאה, יציאת המעקב של TCP היא יציאת שרת היעד).

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

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

אפשר להוסיף כלי לניטור תקינות כרכיב צאצא של רכיב <HTTPTargetConnection> של נקודת הקצה של היעד, כמו שמוצג בהמשך:

<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>
</TargetEndpoint>

`<TCPMonitor>` רכיבי הגדרה

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

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

כלי מעקב אחר תקינות באמצעות כלי מעקב אחר HTTP

בבדיקת תקינות לדוגמה שמתוארת בהגדרה הבאה נעשה שימוש בבדיקת תקינות מסוג HTTP, ששולחת בקשת GET לשירות העורפי כל חמש שניות ומוסיפה כותרת של הרשאת HTTP בסיסית להודעת הבקשה.

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

התגובה הצפויה משירות לקצה העורפי היא קוד תגובת HTTP 200.
הערך הצפוי של כותרת ההרשאה הבסיסית המותאמת אישית של HTTP‏ ImOK הוא YourOK.
הרכיב <UseTargetServerSSLInfo> מוגדר לערך true כדי להשתמש בפרמטרים של SSL מהבלוק <SSLInfo> של שרת היעד.

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

כברירת מחדל, למערכות לניטור תקינות אין גישה למאגרי מפתחות, למאגרי אישורים או לפרמטרים אחרים של SSL משרתי היעד שלהן. כדי לאפשר גישה לפרמטרים האלה לניטור הבריאות שלכם כדי לתמוך ב-TLS הדדי, למשל, מוסיפים <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo> לבלוק <Request>.

    <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>
          <HTTPMonitor>
            <Request>
              <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>
              <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>
      </HTTPTargetConnection>
    </TargetEndpoint>

`<HTTPMonitor>` רכיבי הגדרה

בטבלה הבאה מפורטים רכיבי ההגדרה ברמה העליונה:<HTTPMonitor>

שם	תיאור	ברירת מחדל	חובה?
`Request`	הודעת הבקשה לדואר יוצא שנשלחת על ידי כלי המעקב אחר תקינות השרתים לשרתי היעד ברוטציה.	לא רלוונטי	כן
`SuccessResponse`	(אופציונלי) אפשרויות התאמה להודעת תגובת HTTP נכנסת שנוצרה על ידי שירות לקצה העורפי שנבדק.	לא רלוונטי	לא

רכיבי ההגדרה <HTTPMonitor>/<Request>

אפשרויות ההגדרה של הודעת הבקשה לדואר יוצא שנשלחת על ידי כלי הבדיקה לשרתי היעד ברוטציה. שימו לב, <Request> הוא רכיב חובה.

שם	תיאור	ברירת מחדל	חובה?
`ConnectTimeoutInSec`	הזמן בשניות שבו לחיצת היד של חיבור ה-TCP לשירות ה-HTTP צריכה להסתיים כדי להיחשב להצלחה. אם החיבור לא מצליח במרווח הזמן שצוין, הוא נספר ככישלון, ומספר הכישלונות של איזון העומסים עבור שרת היעד גדל. הערה: אם הערך שצוין הוא 0, מערכת Apigee תשתמש בערך ברירת מחדל של זמן קצוב לתפוגה של 30 שניות.	0	לא
`SocketReadTimeoutInSec`	הזמן, בשניות, שבו צריך לקרוא נתונים משירות ה-HTTP כדי שהפעולה תיחשב כהצלחה. אם לא מתבצעת קריאה במרווח הזמן שצוין, זה נחשב ככישלון, ומספר הכישלונות של איזון העומסים עבור שרת היעד גדל. הערה: אם הערך שצוין הוא 0, מערכת Apigee תשתמש בערך ברירת מחדל של זמן קצוב לתפוגה של 30 שניות.	0	לא
`Port`	היציאה שבה יתבצע חיבור ה-HTTP לשירות לקצה העורפי.	יציאה בשרת היעד	לא
`Verb`	פועל ה-HTTP שמשמש לכל בקשת HTTP של דגימה לשירות לקצה העורפי.	לא רלוונטי	לא
`Path`	הנתיב שמצורף לכתובת ה-URL שמוגדרת בשרת היעד. משתמשים ברכיב `Path` כדי להגדיר 'נקודת קצה של סקר' בשירות HTTP. שימו לב: האלמנט `Path` לא תומך במשתנים.	לא רלוונטי	לא
`UseTargetServerSSLInfo`	אם הערך של `UseTargetServerSSLInfo` הוא true, בקשות של כלי לניטור תקינות לשרת יעד ישתמשו בפרמטרים של SSL מבלוק ה-SSLInfo ‏ ("sSLInfo") של שרת היעד. אחרת, פרמטרים של SSL כמו הפרוטוקול, מאגר המפתחות, מאגר האישורים וכו' לא יהיו זמינים לכלי לבדיקת תקינות.	FALSE	לא
`IncludeHealthCheckIdHeader`	ההרשאה מאפשרת לכם לעקוב אחרי בקשות לבדיקת תקינות במערכות במעלה הזרם. המאפיין `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`.	לא רלוונטי	לא
`Header`	כותרת HTTP אחת או יותר וערכים שצפויים להתקבל משירות לקצה העורפי שנבדק. אם יש כותרות או ערכים של HTTP בתגובה ששונים מאלה שצוינו, הבדיקה תיכשל והמונה של שרת היעד שנבדק יוגדל ב-1. אפשר להגדיר כמה רכיבי Header.	לא רלוונטי	לא
`IsSSL`	אם הערך הוא true, מציין שהבקשה של כלי הבדיקה של תקינות השרת תישלח באמצעות HTTPS.	לא נכון	לא
`TrustAllSSL`	ההגדרה קובעת אם בדיקת הניטור של HTTP תיתן אמון אוטומטי בכל אישורי ה-SSL.	לא נכון	לא

רכיבי ההגדרה <HTTPMonitor>/<SuccessResponse>

(אופציונלי) אפשרויות התאמה להודעת תגובת HTTP נכנסת שנוצרה על ידי שירות קצה עורפי שנבדק. אם התשובות לא תואמות, מספר הכשלים גדל ב-1.

שם	תיאור	ברירת מחדל	חובה?
`ResponseCode`	קוד התגובה של HTTP שצפוי להתקבל מהשרת של היעד שנבדק. אם הקוד שונה מהקוד שצוין, הפעולה תיכשל והספירה תגדל בשביל שירות לקצה העורפי שנבדק. אפשר להגדיר כמה רכיבי ResponseCode.	לא רלוונטי	לא
`Header`	כותרת HTTP אחת או יותר וערכים שצפויים להתקבל משירות לקצה העורפי שנבדק. אם יש כותרות או ערכים של HTTP בתגובה ששונים מאלה שצוינו, הבדיקה תיכשל והמונה של שרת היעד שנבדק יוגדל ב-1. אפשר להגדיר כמה רכיבי Header.	לא רלוונטי	לא

איזון עומסים בין שרתים עורפיים קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

סרטונים

מידע על הגדרת שרת היעד

יצירת שרתי יעד

ממשק המשתמש של Apigee

Apigee API

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

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

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

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

אלגוריתם

סדר אקראי

משוקלל

Least Connections

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

ניסיון חוזר

IsFallback

נתיב

הגדרת שרת יעד ל-TLS/SSL

הגדרת TLS/SSL חד-כיווני

הגדרת אכיפה מחמירה של SSL

הגדרת TLS/SSL דו-כיווני

הגדרת SSL מחמיר באמצעות ה-API

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

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

הפעלת כלי תקינות

<HealthMonitor> רכיבי הגדרה

מעקב אחר תקינות באמצעות TCP monitor

<TCPMonitor> רכיבי הגדרה

כלי מעקב אחר תקינות באמצעות כלי מעקב אחר HTTP

<HTTPMonitor> רכיבי הגדרה

רכיבי ההגדרה <HTTPMonitor>/<Request>

רכיבי ההגדרה <HTTPMonitor>/<SuccessResponse>

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

`<HealthMonitor>` רכיבי הגדרה

`<TCPMonitor>` רכיבי הגדרה

`<HTTPMonitor>` רכיבי הגדרה