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

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

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

    מעבר אל Environments

  2. בוחרים את הסביבה שבה רוצים להגדיר שרת יעד חדש.
  3. לוחצים על Target Servers (שרתי יעד) בחלק העליון של החלונית.
  4. לוחצים על + יצירת שרת יעד.

  5. מזינים שם, מארח, פרוטוקול ויציאה בשדות שמוצגים. האפשרויות של פרוטוקול הן: HTTP לשרתי יעד מבוססי REST, ‏ gRPC – יעד לשרתי יעד מבוססי gRPC, או gRPC – קריאה חיצונית. מידע על תמיכה ב-proxy של gRPC זמין במאמר בנושא יצירת שרתי proxy של gRPC API.

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

  6. לוחצים על יצירה.

Apigee API

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

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

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

ניסיון חוזר

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

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

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

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

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

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

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 מסוג polling. שימו לב שהרכיב הזה לא נדרש בבקשות GET. לא רלוונטי לא
Header כותרת HTTP אחת או יותר וערכים שצפויים להתקבל משירות הקצה העורפי שנבדק. אם יש בכותרת או בערכים בתגובה הבדלים מאלה שצוינו, הבדיקה תיכשל והמונה של שרת היעד שנבדק יוגדל ב-1. אפשר להגדיר כמה רכיבי Header. לא רלוונטי לא
IsSSL אם הערך הוא true, מציין שהבקשה של כלי המעקב אחר תקינות תישלח באמצעות HTTPS. לא נכון לא
TrustAllSSL מציינת אם בדיקת הניטור של HTTP תבטח אוטומטית בכל אישורי ה-SSL. לא נכון לא

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

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

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