כרגע מוצג התיעוד של Apigee Edge.
נכנסים למסמכי התיעוד של
Apigee X. מידע
Apigee Edge משפרת את הזמינות של ה-API באמצעות תמיכה מובנית באיזון עומסים ויתירות כשל במכונות מרובות של שרת קצה עורפי.
ההגדרות של TargetServer מפרידות כתובות URL קונקרטיות של נקודות קצה מהגדרות TargetEndpoint. ב-TargetEndpoint HTTPConnection יש הפניה לכל שרת TargetServer. במקום להגדיר כתובת URL קונקרטית בתצורה, אפשר להגדיר שרת אחד או יותר בשם TargetServers, כפי שמתואר בקטע TargetEndpoint.
הגדרת TargetServer כוללת שם, מארח ויציאה, עם רכיב נוסף שמציין אם שרת היעד מופעל או מושבת.
סרטונים
בסרטונים הבאים אפשר למצוא מידע נוסף על ניתוב API ועל איזון עומסים באמצעות שרתי יעד
וידאו | תיאור |
---|---|
איזון עומסים באמצעות שרתי יעד | ממשקי API של איזון עומסים בשרתי יעד. |
ניתוב API המבוסס על סביבה באמצעות שרתי יעד | ניתוב API לשרת יעד אחר על סמך הסביבה. |
ניתוב API ואיזון עומסים באמצעות שרתי יעד (Classic Edge) | ניתוב API לשרת יעד אחר בהתאם לסביבה ולמאזן העומסים של ה-API בין שרתי היעד בממשק המשתמש הקלאסי של Edge. |
דוגמה של תצורת שרת יעד
הקוד הבא מגדיר שרת יעד:
<TargetServer name="target1"> <Host>1.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer >
רכיבי התצורה של TargetServer
הטבלה הבאה מתארת את הרכיבים המשמשים ליצירה ולהגדרה של TargetServer:
שם | תיאור | ברירת המחדל | חובה? |
---|---|---|---|
name |
השם של הגדרת ה-TargetServer, שחייב להיות ייחודי בסביבה. שם TargetServer יכול להכיל תווים אלפאנומריים בלבד. | לא רלוונטי | כן |
Host |
כתובת ה-URL של המארח של השירות לקצה העורפי (ללא הפרוטוקול). | לא רלוונטי | כן |
Port |
היציאה שבה מאזין השירות לקצה העורפי | לא רלוונטי | כן |
IsEnabled |
ערך בוליאני שמציין אם תצורת שרת היעד מופעלת או מושבתת. כך אפשר להוציא את TargetServers מהסבב בלי לשנות את ההגדרה של שרת ה-API. אחד השימושים הנפוצים הוא לכתוב אפליקציה או סקריפט שמאפשרים או משביתים אוטומטית שרתי TargetServers באופן אוטומטי על סמך דרישות הקיבולת הצפויה, לוחות זמנים של תחזוקה וכו'. | true |
כן |
ניהול שרתי היעד באמצעות ממשק המשתמש
ניהול שרתי היעד, כפי שמתואר בהמשך.
Edge
כדי לנהל שרתי יעד באמצעות ממשק המשתמש של Edge:
- נכנסים לאתר apigee.com/edge.
- בסרגל הניווט הימני בוחרים באפשרות ניהול > סביבות > שרתי יעד.
- בוחרים את הסביבה הרצויה, למשל test או prod.
- כדי ליצור שרת יעד:
- לוחצים על + שרת יעד.
- מזינים שם, מארח ויציאה לשרת היעד.
לדוגמה:
- שם: target1
- מארח: 1.mybackendservice.com
- יציאה: 80
- בוחרים באפשרות SSL, אם נדרש.
- בוחרים באפשרות מופעל כדי להפעיל את שרת היעד.
- לוחצים על הוספה.
- כדי לערוך את שרת היעד:
- מציבים את הסמן מעל שרת היעד שרוצים לערוך כדי להציג את תפריט הפעולות.
- לוחצים על
.
- עריכת הערכים של שרת היעד.
- לוחצים על עדכון.
- כדי למחוק את שרת היעד:
- מציבים את הסמן מעל שרת היעד שרוצים למחוק כדי להציג את תפריט הפעולות.
- לוחצים על
.
- לוחצים על מחיקה כדי לאשר את הפעולה.
Classic Edge (ענן פרטי)
כדי לגשת לאשף יצירת שרת proxy באמצעות ממשק המשתמש הקלאסי של Edge:
- צריך להיכנס אל
http://ms-ip:9000
, כאשר ms-ip הוא כתובת ה-IP או שם ה-DNS של הצומת של שרת הניהול. - בסרגל הניווט הימני בוחרים באפשרות APIs > Environment Configuration (הגדרת סביבה) > Target Servers (שרתי יעד).
- בוחרים את הסביבה הרצויה, למשל test או prod.
- כדי ליצור שרת יעד:
- לוחצים על עריכה.
- לוחצים על + שרת יעד.
- מזינים שם, מארח ויציאה לשרת היעד.
לדוגמה:
- שם: target1
- מארח: 1.mybackendservice.com
- יציאה: 80
- בוחרים באפשרות מופעל כדי להפעיל את שרת היעד.
- לוחצים על שמירה.
- כדי לערוך את שרת היעד:
- לוחצים על עריכה.
- עריכת הערכים של שרת היעד.
- לוחצים על שמירה.
- כדי למחוק את שרת היעד:
- לוחצים על עריכה.
- לוחצים על מחיקה.
ניהול שרתי היעד באמצעות ה-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" ]
עכשיו יש שני שרתי TargetServers שזמינים לשימוש על ידי שרתי proxy של API שפרוסים בסביבת הבדיקה. כדי לטעון את תעבורת הנתונים ב-TargetServers האלה, צריך להגדיר את חיבור ה-HTTP בנקודת הקצה (endpoint) של שרת ה-proxy של API, ולהשתמש ב-TargetServers.
יש מגבלה של 500 TargetServers לכל סביבה, כפי שמצוין בנושא Limits.
הגדרת TargetEndpoint למאזן עומסים ב-TargetServers שמות
עכשיו שיש לך שני שרתי TargetServers זמינים, אפשר לשנות את ההגדרה של חיבור ה-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' הוא אלגוריתם ברירת המחדל. מאחר שלא צוין אלגוריתם בהגדרה שלמעלה, בקשות יוצאות משרת ה-API של ה-API לשרתי הקצה העורפי יעברו לסירוגין, אחת מהן, בין יעד 1 ליעד 2.
הרכיב <Path>
יוצר את הנתיב הבסיסי של ה-URI של TargetEndpoint עבור כל שרתי היעד. הוא נמצא בשימוש רק כאשר נעשה שימוש ב-<LoadBalancer>
. אחרת, המערכת תתעלם ממנה. בדוגמה שלמעלה, בקשה שתגיע אל "target1" תהיה
http://target1/test
וכך גם לגבי שרתי יעד אחרים.
הגדרת האפשרויות של מאזן העומסים
אפשר להתאים את הזמינות באמצעות אפשרויות של איזון עומסים ויתירות כשל ברמת מאזן העומסים וברמה של TargetServer. בקטע הזה מתוארות האפשרויות האלה.
אלגוריתם
מגדיר את האלגוריתם המשמש את <LoadBalancer>
. האלגוריתמים הזמינים הם RoundRobin
, Weighted
ו-LeastConnections
,
וכל אחד מהם מתועד בהמשך.
כולם נגד כולם
אלגוריתם ברירת המחדל, Robin robin, מעביר בקשה לכל TargetServer לפי הסדר שבו השרתים רשומים בחיבור ה-HTTP של נקודת הקצה (endpoint). לדוגמה:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
נשקל
האלגוריתם המשוקלל של איזון העומסים מאפשר להגדיר עומסי תנועה יחסיים עבור
TargetServers. ה-Load Balancer המשוקלל מחלק בקשות לשרתי TargetServers שלך באופן ישיר ביחס למשקל של כל TargetServer. לכן, האלגוריתם המשוקלל מחייב להגדיר מאפיין 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>
בדוגמה הזו, שתי בקשות ינותבו אל target2 לגבי כל בקשה אחת שתנותב אל target1.
הכי פחות חיבור
Load Balancers מוגדרים לשימוש באלגוריתם של החיבור הנמוך ביותר, לניתוב בקשות יוצאות אל TargetServer עם מספר חיבורי ה-HTTP הפתוחים הנמוך ביותר. לדוגמה:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>LeastConnections</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> </HTTPTargetConnection> <Path>/test</Path> </TargetEndpoint>
מקסימום כשלים
המספר המקסימלי של בקשות שנכשלו משרת ה-API של ה-API אל TargetServer, שיובילו להפניה מחדש של הבקשה ל-TargetServer אחר.
המשמעות של כשל בתגובה היא ש-Apigee לא מקבל תגובה משרת יעד. במקרה כזה, מונה הכשל יגדל באחד.
עם זאת, כש-Apigee מקבל תגובה מיעד,
גם אם התשובה היא שגיאת HTTP (כמו 500
), נספרת כתגובה
משרת היעד, ומונה הכשל מתאפס. כדי לוודא שתגובות HTTP לא טובות (כמו 500
) גם מגבירות את מונה הכשל ובכך מוציאות שרת לא תקין
מסבב איזון עומסים בהקדם האפשרי, אפשר להוסיף להגדרה של מאזן העומסים את הרכיב <ServerUnhealthyResponse>
עם רכיבי צאצא <ResponseCode>
. Edge גם תספור תשובות עם הקודים האלה ככשלים.
בדוגמה הבאה, המערכת תסיר את target1
מהסבב אחרי חמש בקשות שנכשלו, כולל כ-5XX
תגובות משרת היעד.
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> <ServerUnhealthyResponse> <ResponseCode>500</ResponseCode> <ResponseCode>502</ResponseCode> <ResponseCode>503</ResponseCode> </ServerUnhealthyResponse> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
ברירת המחדל של MaxFailures היא 0. כלומר, Edge תמיד מנסה להתחבר ליעד עבור כל בקשה, ואף פעם לא מסירה את שרת היעד מהסבב.
מומלץ להשתמש ב-MaxFailures > 0 עם HealthMonitor. אם מגדירים את MaxFailures > 0, שרת היעד מוסר מהסבב כאשר היעד נכשל במספר הפעמים שציינתם. אחרי התקנה של HealthMonitor, Apigee מחזיר את TargetServer באופן אוטומטי אחרי שהיעד מופעל ופועל שוב, בהתאם לתצורה של HealthMonitor. אפשר לקרוא מידע נוסף במעקב אחר בריאות.
לחלופין, אם מגדירים את MaxFailures > 0 ולא מגדירים HealthMonitor, Apigee לא תכלל מחדש את TargetServer בסבב לאחר ש-Apigee מזהה כשל. במקרה כזה, צריך לפרוס מחדש את שרת ה-API של ה-API לפני ש-Apigee יחזיר את TargetServer בחזרה לסבב. למידע נוסף, ראו פריסת שרת proxy ל-API.
ניסיון נוסף
אם מופעל ניסיון חוזר, יבוצע ניסיון חוזר של בקשה בכל פעם שמתרחש כשל בתגובה (שגיאת קלט/פלט או זמן קצוב לתפוגה של HTTP)
או אם התשובה שהתקבלה תואמת לערך שהוגדר על ידי <ServerUnhealthyResponse>
.
בקטע מספר מקסימלי של כשלים למעלה יש מידע נוסף על הגדרת
<ServerUnhealthyResponse>
.
ערך ברירת המחדל של <RetryEnabled>
הוא true
. כדי להשבית את הניסיון החוזר, יש להגדיר את הערך false
.
לדוגמה:
<RetryEnabled>false</RetryEnabled>
IsFallback
אפשר להגדיר שרת יעד אחד (ואחד בלבד) כשרת 'fallback'. ה-TargetServer החלופי לא נכלל בתרחישי איזון העומסים עד שכל שאר שרתי TargetServer יזוהו כלא זמינים על ידי מאזן העומסים. כשמאזן העומסים קובע שכל שרתי TargetServers לא זמינים, כל התעבורה מנותבת לשרת החלופי. לדוגמה:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <Server name="target3"> <IsFallback>true</IsFallback> </Server> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
ההגדרה שלמעלה מובילה לאיזון עומסים בסבב רובין בין יעדים 1 ו-2 עד שיעדים 1 ו-2 לא זמינים. כשיעדים 1 ו-2 לא זמינים, כל התנועה מנותבת אל יעד 3.
נתיב
הנתיב מגדיר מקטע URI שיצורף לכל הבקשות שהונפקו על ידי TargetServer לשרת הקצה העורפי.
הרכיב הזה יכול לקבל נתיב מחרוזת מילולי או תבנית הודעה. תבנית הודעה מאפשרת להחליף מחרוזת משתנה בזמן הריצה.
לדוגמה, בהגדרה הבאה של נקודת הקצה של היעד, הערך של {mypath}
משמש לנתיב:
<HTTPTargetConnection> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> <LoadBalancer> <Server name="testserver"/> </LoadBalancer> <Path>{mypath}</Path> </HTTPTargetConnection>
הגדרה של שרת יעד ל-TLS/SSL
אם בחרת להשתמש ב-TargetServer כדי להגדיר את השירות לקצה העורפי, והשירות לקצה העורפי דורש חיבור כדי להשתמש בפרוטוקול HTTPS, עליך להפעיל TLS/SSL בהגדרת TargetServer. הפעולה הזו נדרשת כי התג <Host>
לא מאפשר לציין את פרוטוקול החיבור. בהמשך מוצגת הגדרת TargetServer עבור TLS/SSL חד-כיווני, כאשר Edge שולח בקשות HTTPS לשירות הקצה העורפי:
<TargetServer name="target1"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
אם השירות לקצה העורפי דורש TLS/SSL דו-כיווני או הדדי, עליכם להגדיר את TargetServer באמצעות אותן הגדרות TLS/SSL כמו אלה של TargetEndpoints:
<TargetServer name="TargetServer 1"> <IsEnabled>true</IsEnabled> <Host>www.example.com</Host> <Port>443</Port> <SSLInfo> <Ciphers/> <ClientAuthEnabled>true</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <KeyAlias>keystore-alias</KeyAlias> <KeyStore>keystore-name</KeyStore> <Protocols/> <TrustStore>truststore-name</TrustStore> </SSLInfo> </TargetServer >
למידע על מאפייני <SSLInfo>
, כמו <Ciphers>
ו-<ClientAuthEnabled>
, תוכלו לקרוא את המאמר על הגדרת המאפיינים האלה למארח וירטואלי במאמר הגדרת גישה באמצעות TLS ל-API בענן הפרטי.
להוראות מלאות להגדרת TLS/SSL יוצא, ראו הגדרת TLS מ-Edge לקצה העורפי (Cloud וענן פרטי).
סכימה של שרת היעד
אפשר לעיין בסכימה של 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 חייבת להתאים להגדרות שנקבעו בבלוק
<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>
מציין את המספר המקסימלי של בקשות שנכשלו משרת ה-API של ה-API לשרת TargetServer, וכתוצאה מכך הבקשה מפנה אוטומטית לשרת TargetServer אחר. ערך ברירת המחדל של <MaxFailures>
הוא 0, כלומר
Edge לא מבצעת פעולה מתקנת. כשמגדירים מעקב תקינות, חשוב להקפיד להגדיר את הערך <MaxFailures>
בתג <HTTPTargetConnection>
של התג <TargetEndpoint>
לערך שאינו אפס.
TCPMonitor
בהגדרה שמופיעה בהמשך מוגדר HealthMonitor שבודקת כל TargetServer על ידי פתיחת חיבור ביציאה 80 כל חמש שניות. (היציאה היא אופציונלית. אם לא מציינים שום אפשרות, יציאת TCPMonitor היא יציאת TargetServer.)
- אם החיבור נכשל או שנדרש יותר מ-10 שניות כדי להתחבר, ספירת הכשלים גדלה ב-1 עבור אותו TargetServer.
- אם החיבור מצליח, ספירת הכשלים עבור TargetServer מתאפסת ל-0.
אפשר להוסיף רכיב HealthMonitor כרכיב צאצא של רכיב HTTPTargetEndpoint של 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 לשירות הקצה העורפי פעם ב-5 שניות. בדוגמה הבאה מוסיפה כותרת HTTP Basic Authorization להודעת הבקשה. ההגדרה של 'תגובה' קובעת הגדרות שיושוו לעומת התגובה בפועל מהשירות לקצה העורפי. בדוגמה הבאה, התגובה הצפויה היא קוד תגובת HTTP 200
, וכותרת HTTP מותאמת אישית ImOK
שהערך שלה הוא YourOK
. אם התשובה לא תואמת, הבקשה תטופל ככשל בהגדרות של מאזן העומסים.
HTTPMonitor תומך בשירותים לקצה עורפי שהוגדרו לשימוש בפרוטוקולי HTTP ו-HTTPS חד-כיווניים. עם זאת, הוא לא תומך בפלטפורמות הבאות:
- HTTPS דו-כיווני (נקרא גם TLS דו-כיווני או SSL)
- אישורים בחתימה עצמית
שימו לב שכל ההגדרות של 'בקשה' ו'תגובה' בניטור HTTP יהיו ספציפיות לשירות הקצה העורפי שיש להפעיל.
<HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <HTTPMonitor> <Request> <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 ל-TargetServers בסבב. הנתיב לא תומך במשתנים. |
לא רלוונטי | כן |
ConnectTimeoutInSec |
זמן, בשניות, שבו לחיצת היד של חיבור TCP לשירות ה-HTTP חייבת להסתיים כדי להיחשב כהצלחה. אם החיבור במרווח הזמן שצוין לא מתחבר, נספר ככשל, וכתוצאה מכך עולה מספר הכשלים של Load Balancer עבור TargetServer. | 0 | לא |
SocketReadTimeoutInSec |
זמן, בשניות, שבו יש לקרוא את הנתונים משירות ה-HTTP כדי להיחשב להצלחה. אי קריאה במרווח הזמן שצוין נספרת ככשל, וכתוצאה מכך עולה מספר הכשלים של Load Balancer עבור TargetServer. | 0 | לא |
Port |
היציאה שבה ייקבע חיבור ה-HTTP לשירות הקצה העורפי. | לא רלוונטי | לא |
Verb |
פועל ה-HTTP המשמש לכל דגימה של בקשת HTTP לשירות הקצה העורפי . | לא רלוונטי | לא |
Path |
הנתיב שמצורף לכתובת ה-URL שהוגדרה ב-TargetServer. צריך להשתמש ברכיב הנתיב כדי להגדיר 'נקודת קצה (endpoint)' בשירות ה-HTTP. | לא רלוונטי | לא |
| מאפשרת לעקוב
אחרי הבקשות לבדיקת תקינות במערכות 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 שצפוי להתקבל מ-TargetServer שנדגם. קוד השונה מהקוד שצוין יוביל לכשל, והספירה מתווספת לשירות הקצה העורפי שנבדק. ניתן להגדיר מספר רכיבים של ResponseCode. | לא רלוונטי | לא |
Headers |
רשימה של כותרת HTTP אחת או יותר וערכים שצפויים להתקבל מהשירות לקצה העורפי שנדגם. כל כותרות או ערכי HTTP בתגובה, השונים מאלה שצוינו, יובילו לכשל, והספירה של TargetServer שנדגם מתווספת ב-1. ניתן להגדיר מספר רכיבי כותרת. | לא רלוונטי | לא |