‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

הדף הזה רלוונטי ל-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" ]

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

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

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

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

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

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

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

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

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

אלגוריתם

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

סדר אקראי

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

בדוגמה הבאה, המערכת תסיר את 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.

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

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

ניסיון חוזר

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

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

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

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

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

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

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

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

הצלחה: השרת היעד נחשב תקין כשבדיקת התקינות מצליחה. בדרך כלל זה קורה בגלל אחת או יותר מהסיבות הבאות:
- שרת היעד מקבל חיבור חדש ליציאה שצוינה, מגיב לבקשה ביציאה הזו ואז סוגר את היציאה בתוך מסגרת הזמן שצוינה. התגובה משרת היעד מכילה Connection: close
- שרת היעד מגיב לבקשת בדיקת תקינות עם קוד סטטוס HTTP‏ 200 (OK) או קוד אחר שאתם קובעים שהוא קביל.
- שרת היעד מגיב לבקשת בדיקת תקינות עם גוף הודעה שתואם לגוף ההודעה הצפוי.
כשמערכת 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> משמש לציון המספר המקסימלי של בקשות שנכשלו משרת ה-API proxy לשרת היעד, שיכולות להתרחש לפני שהבקשה מופנית מחדש לשרת יעד אחר.

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

רכיבי ההגדרה <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. דוגמה ל-request header שמתקקבל: `X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123`	FALSE	לא
`Payload`	גוף ה-HTTP שנוצר לכל בקשת HTTP מסוג polling. שימו לב שהרכיב הזה לא נדרש בבקשות `GET`.	לא רלוונטי	לא
`Header`	כותרות HTTP וערכים אחד או יותר שאמורים להתקבל משירות לקצה העורפי שנבדק. אם יש כותרות או ערכים של HTTP בתגובה ששונים מאלה שצוינו, הבדיקה תיכשל והמונה של שרת היעד שנבדק יוגדל ב-1. אפשר להגדיר כמה רכיבי Header.	לא רלוונטי	לא
`IsSSL`	אם הערך הוא true, הבקשה של כלי הבקרה של תקינות המערכת תישלח באמצעות HTTPS.	לא נכון	לא
`TrustAllSSL`	ההגדרה הזו קובעת אם הבדיקה של כלי המעקב אחרי HTTP תיתן אמון אוטומטי בכל אישורי ה-SSL.	לא נכון	לא

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

(אופציונלי) אפשרויות התאמה להודעת תגובת HTTP נכנסת שנוצרה על ידי שירות ה-backend שנבדק. אם התשובות לא תואמות, מספר הכשלים גדל ב-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>` רכיבי הגדרה