أنت تطّلع على مستندات Apigee Edge.
انتقِل إلى مستندات
Apigee X. info
تحسِّن Apigee Edge من مدى توفّر واجهة برمجة التطبيقات من خلال توفير دعم مضمّن لموازنة الحمولة والتحويل إلى وضع الاستبدال على مستوى نُسخ متعددة من خادم الخلفية.
تفصل إعدادات TargetServer عناوين URL لنقاط النهاية المحدّدة عن إعدادات TargetEndpoint. تتم الإشارة إلى كل TargetServer بالاسم في TargetEndpoint HTTPConnection. بدلاً من تحديد عنوان URL محدّد في الإعدادات، يمكنك ضبط واحد أو أكثر من الخوادم المستهدفة المُسمّاة كما هو موضّح في القسم TargetEndpoint.
يتألّف تعريف TargetServer من اسم ومضيف ومنفذ، مع عنصر إضافي لتحديد ما إذا كان TargetServer مفعّلاً أو غير مفعّل.
الفيديوهات
يمكنك مشاهدة الفيديوهات التالية لمعرفة مزيد من المعلومات عن توجيه واجهة برمجة التطبيقات وموازنة التحميل باستخدام ملف .target servers
فيديو | الوصف |
---|---|
موازنة التحميل باستخدام الخوادم المستهدَفة | واجهات برمجة التطبيقات لموازنة التحميل على مستوى الخوادم المستهدَفة |
توجيه واجهة برمجة التطبيقات استنادًا إلى البيئة باستخدام الخوادم المستهدَفة | يمكنك توجيه واجهة برمجة تطبيقات إلى خادم مستهدَف مختلف استنادًا إلى البيئة. |
توجيه واجهة برمجة التطبيقات و موازنة التحميل باستخدام الخوادم المستهدَفة (Classic Edge) | توجيه واجهة برمجة تطبيقات إلى خادم مستهدَف مختلف استنادًا إلى البيئة وموازنة التحميل توجيه واجهة برمجة التطبيقات على مستوى الخوادم المستهدَفة في واجهة مستخدم Edge الكلاسيكية |
مثال على إعدادات TargetServer
تحدِّد التعليمة البرمجية التالية خادمًا مستهدَفًا:
<TargetServer name="target1"> <Host>1.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer >
عناصر إعدادات TargetServer
يوضّح الجدول التالي العناصر المستخدَمة لإنشاء TargetServer وضبطه:
الاسم | الوصف | تلقائي | مطلوب؟ |
---|---|---|---|
name |
اسم إعدادات TargetServer، والذي يجب أن يكون فريدًا في البيئة يمكن أن يحتوي اسم TargetServer على أحرف أبجدية رقمية فقط. | لا ينطبق | نعم |
Host |
عنوان URL للمضيف لخدمة الخلفية (بدون البروتوكول) | لا ينطبق | نعم |
Port |
المنفذ الذي تستمع إليه خدمة الخلفية | لا ينطبق | نعم |
IsEnabled |
قيمة منطقية تشير إلى ما إذا كانت إعدادات TargetServer مفعّلة أو غير مفعّلة يتيح لك ذلك إيقاف ميزة "تبديل الخوادم المستهدَفة" بدون تعديل إعدادات وكيل واجهة برمجة التطبيقات. ومن الاستخدامات الشائعة كتابة تطبيق أو نص برمجي يفعّل أو يوقف TargetServers تلقائيًا استنادًا إلى متطلبات السعة المتوقّعة وجداول الصيانة وغيرها. | true |
نعم |
إدارة الخوادم المستهدَفة باستخدام واجهة المستخدم
إدارة الخوادم المستهدَفة، كما هو موضّح أدناه
Edge
لإدارة الخوادم المستهدَفة باستخدام واجهة مستخدم Edge:
- سجِّل الدخول إلى apigee.com/edge.
- اختَر المشرف > البيئات > الخوادم المستهدَفة في شريط التنقّل الأيمن.
- اختَر البيئة المطلوبة، مثل test أو prod.
- لإنشاء خادم مستهدَف:
- انقر على + الخادم المستهدَف.
- أدخِل اسمًا ومضيفًا ومنفذًا للخادم المستهدَف.
على سبيل المثال:
- الاسم: target1
- المضيف: 1.mybackendservice.com
- المنفذ: 80
- اختَر SSL، إذا لزم الأمر.
- اختَر مفعَّل لتفعيل الخادم المستهدَف.
- انقر على إضافة.
- لتعديل الخادم المستهدَف:
- ضع مؤشر الماوس فوق الخادم المستهدَف الذي تريد تعديله لعرض قائمة الإجراءات.
- انقر على
.
- عدِّل قيم الخادم المستهدَف.
- انقر على تعديل.
- لحذف الخادم المستهدَف:
- ضع المؤشر فوق الخادم المستهدَف الذي تريد حذفه لعرض قائمة الإجراءات.
- انقر على
.
- انقر على حذف لتأكيد العملية.
Classic Edge (سحابة خاصة)
للوصول إلى معالج "إنشاء خادم وكيل" باستخدام واجهة مستخدم Edge الكلاسيكية:
- سجِّل الدخول إلى
http://ms-ip:9000
، حيث يكون ms-ip هو عنوان IP أو اسم نظام أسماء النطاقات الخاص بعقدة "خادم الإدارة". - اختَر واجهات برمجة التطبيقات > إعداد البيئة > الخوادم المستهدَفة في شريط التنقّل الأيمن.
- اختَر البيئة المطلوبة، مثل test أو prod.
- لإنشاء خادم مستهدَف:
- انقر على تعديل.
- انقر على + الخادم المستهدَف.
- أدخِل اسمًا ومضيفًا ومنفذًا للخادم المستهدَف.
على سبيل المثال:
- الاسم: target1
- المضيف: 1.mybackendservice.com
- المنفذ: 80
- اختَر مفعَّل لتفعيل الخادم المستهدَف.
- انقر على حفظ.
- لتعديل الخادم المستهدَف:
- انقر على تعديل.
- عدِّل قيم الخادم المستهدَف.
- انقر على حفظ.
- لحذف الخادم المستهدَف:
- انقر على تعديل.
- انقر على حذف.
إدارة الخوادم المستهدَفة باستخدام واجهة برمجة التطبيقات
يمكنك استخدام Edge API لإنشاء الخوادم المستهدَفة وحذفها وتعديلها والحصول عليها وعرضها. لمزيد من المعلومات، يُرجى الاطّلاع على TargetServers.
استخدِم طلب البيانات التالي من واجهة برمجة التطبيقات لإنشاء خادم مستهدَف:
$ 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 الأول، استخدِم طلب البيانات التالي من واجهة برمجة التطبيقات لإنشاء 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 }
استخدِم طلب البيانات التالي من واجهة برمجة التطبيقات لاسترداد قائمة بـ TargetServers في بيئة معيّنة:
$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers
مثال على الردّ:
[ "target2", "target1" ]
يتوفّر الآن خادمان TargetServer لاستخدامهما من قِبل الخوادم الوكيلة لواجهات برمجة التطبيقات التي تم نشرها في بيئة الاختبار. لموازنة عدد الزيارات على مستوى خوادم TargetServer هذه، عليك ضبط اتصال HTTP في نقطة نهاية مستهدفة لواجهة برمجة التطبيقات لوكيل لواجهة برمجة التطبيقات لاستخدام خوادم TargetServer.
يبلغ الحدّ الأقصى لعدد "خوادم الاستهداف" 500 خادم لكلّ بيئة، كما هو موثّق في موضوع الحدود.
ضبط TargetEndpoint لموازنة الحمل على مستوى TargetServers المُسمّاة
الآن بعد أن أصبح لديك خادمان TargetServer متاحان، يمكنك تعديل إعداد اتصال TargetEndpoint HTTP للإشارة إلى هذين الخادمَين TargetServer بالاسم:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
الإعدادات أعلاه هي أبسط إعدادات موازنة التحميل الممكنة. يتوافق موازن الحمّل مع ثلاث خوارزميات لتوزيع الحمل، وهي "التوزيع بالتناوب" و"التوزيع حسب الوزن" و"التوزيع حسب عدد الاتصالات الأقل". "الترتيب الدوار" هو الخوارزمية التلقائية. بما أنّه لم يتم تحديد أي خوارزمية في الإعدادات أعلاه، سيتم تبديل الطلبات الصادرة من خادم وكيل واجهة برمجة التطبيقات إلى خوادم الخلفية، كل طلب تلو الآخر، بين target1 وtarget 2.
يشكّل العنصر <Path>
المسار الأساسي لمعرّف الموارد المنتظم TargetEndpoint لكل من
جميع الخوادم المستهدَفة. ولا يتم استخدامها إلا عند استخدام <LoadBalancer>
. وبخلاف ذلك، يتم تجاهله. في المثال أعلاه، سيكون الطلب الذي يصل إلى "target1" هو
http://target1/test
وهكذا بالنسبة إلى الخوادم المستهدَفة الأخرى.
ضبط خيارات موازنة الحمل
يمكنك ضبط مدى التوفّر باستخدام خيارات توزيع الحمل والاستبدال في حال حدوث تعذّر في مستوى جهاز موازنة الحمل وTargetServer. يوضّح هذا القسم هذه الخيارات.
خوارزمية
لضبط الخوارزمية المستخدَمة في <LoadBalancer>
تتوفر RoundRobin
وWeighted
وLeastConnections
كخوارزميات،
وقد تم توثيق كل منها أدناه.
جولة الدوري بين جميع اللاعبين
تعيد الخوارزمية التلقائية، وهي أسلوب "الدور الدوّري"، توجيه الطلب إلى كلّ TargetServer بالترتيب الذي يتم فيه إدراج الخوادم في اتصال HTTP لنقطة النهاية المستهدَفة. على سبيل المثال:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
موزون
تتيح لك خوارزمية موازنة الحمولة المرجحة ضبط أحمال الزيارات النسبية للخدمة
TargetServers. توزّع أداة LoadBalancer ذات التقييم الموزّع الطلبات على الخوادم المستهدَفة وفقًا لتناسبٍ مباشر
مع التقييم الموزّع لكل خادم مستهدَف. لذلك، تتطلّب الخوارزمية المستندة إلى الوزن منك ضبط
سمة weight
لكل TargetServer. على سبيل المثال:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>Weighted</Algorithm> <Server name="target1"> <Weight>1</Weight> </Server> <Server name="target2"> <Weight>2</Weight> </Server> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
في هذا المثال، سيتم توجيه طلبَين إلى الهدف 2 مقابل كل طلب يتم توجيهه إلى الهدف 1.
الأقل صلة
تعمل خدمات LoadBalancer التي تم ضبطها لاستخدام خوارزمية الاتصال الأقل عددًا على توجيه الطلبات الصادرة إلى TargetServer الذي يتضمّن أقل عدد من اتصالات HTTP المفتوحة. على سبيل المثال:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>LeastConnections</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> </HTTPTargetConnection> <Path>/test</Path> </TargetEndpoint>
الحد الأقصى للأعطال
الحد الأقصى لعدد الطلبات التي تعذّر إرسالها من خادم وكيل واجهة برمجة التطبيقات إلى 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، تتم إزالة TargetServer من التناوب عندما يتعذّر الوصول إلى الهدف عدد المرات التي تحدّدها. عند استخدام HealthMonitor، تعيد Apigee تلقائيًا إدراج TargetServer في عملية التناوب بعد بدء تشغيل الهدف مرة أخرى، وفقًا لإعدادات HealthMonitor. اطّلِع على مراقبة الصحة للحصول على مزيد من المعلومات.
بدلاً من ذلك، إذا ضبطت MaxFailures > 0 ولم تضبط أداة مراقبة حالة، ستُخرج Apigee الخادم المستهدَف تلقائيًا من عملية التناوب عند رصد الخطأ الأول. ستتحقّق Apigee من حالة الخادم المستهدَف كل خمس دقائق وستعيده إلى عملية التناوب عندما يستجيب بشكلٍ طبيعي.
إعادة المحاولة
في حال تفعيل إعادة المحاولة، ستتم إعادة محاولة إرسال الطلب عند حدوث خطأ في الاستجابة (خطأ في الإدخال/الإخراج أو مهلة HTTP)
أو إذا كان الردّ الذي تم تلقّيه يتطابق مع قيمة تم ضبطها بواسطة <ServerUnhealthyResponse>
.
اطّلِع على الحد الأقصى للأعطال أعلاه للحصول على مزيد من المعلومات عن الإعداد
<ServerUnhealthyResponse>
.
يتم ضبط <RetryEnabled>
تلقائيًا على true
. اضبط القيمة على false
لإيقاف إعادة المحاولة.
على سبيل المثال:
<RetryEnabled>false</RetryEnabled>
IsFallback
يمكن ضبط خادم TargetServer واحد (واحد فقط) كخادم "احتياطي". لا يتم تضمين خادم TargetServer الاحتياطي في إجراءات موازنة الحمل إلى أن يحدد موازن الحمل أنّ جميع خوادم TargetServer الأخرى غير متاحة. عندما يحدِّد موازن الحمولة أنّ جميع خوادم TargetServer غير متاحة، يتم توجيه جميع الزيارات إلى الخادم الاحتياطي. على سبيل المثال:
<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) لواجهة برمجة التطبيقات
في "سحابة خاصة".
للحصول على تعليمات كاملة حول ضبط بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) الصادرَين، يُرجى الاطّلاع على مقالة ضبط بروتوكول أمان طبقة النقل (TLS) من Edge إلى الخلفية (Cloud و"سحابة خاصة").
مخطّط TargetServer
اطّلِع على مخطّط TargetServer والكيانات الأخرى على GitHub.
مراقبة الحالة الصحية
تتيح لك مراقبة حالة الخدمة تحسين إعدادات موازنة الحمل من خلال إجراء عمليات بحث نشطة عن عناوين URL لخدمات الخلفية المحدّدة في إعدادات TargetServer. عند تفعيل مراقبة الصحة، يُعاد تلقائيًا إدراج خادم TargetServer الذي تعذّر عليه إكمال عملية الربط في عملية التناوب عندما يحدِّد HealthMonitor أنّ خادم TargetServer نشط.
تعمل ميزة "مراقبة الحالة الصحية" مع <MaxFailures>
. في حال عدم تفعيل ميزة "مراقبة الصحة"، يحدِّد العنصر
<MaxFailures>
عدد الطلبات التي تعذّر إكمالها من خادم الوكيل لواجهة برمجة التطبيقات إلى
TargetServer، ما يؤدي إلى إعادة توجيه الطلب إلى TargetServer آخر.
بعد ذلك، يتم إيقاف TargetServer الذي يتضمّن خطأ إلى أن تتم إعادة نشر الخادم الوكيل.
عند تفعيل ميزة "مراقبة الحالة"، تتم إعادة إدراج TargetServer الذي تعذّر عليه إكمال عملية الربط تلقائيًا في عملية التناوب، ولا يلزم إعادة نشر الوكيل.
يعمل HealthMonitor كعميل بسيط يستدعي خدمة خلفية عبر بروتوكول TCP أو HTTP:
- يضمن برنامج TCP العميل ببساطة إمكانية فتح مقبس.
- يمكنك ضبط برنامج HTTP لتلقّي طلب HTTP صالح وإرساله إلى خدمة الخلفية. يمكنك
تحديد عمليات HTTP GET أو PUT أو POST أو DELETE. يجب أن تتطابق استجابة طلب HTTP مع
الإعدادات التي تم ضبطها في القسم
<SuccessResponse>
.
النجاحات والإخفاقات
عند تفعيل ميزة "مراقبة الحالة"، يبدأ Edge بإرسال عمليات التحقّق من الحالة إلى خادم الهدف. فحص الحالة هو طلب يتم إرساله إلى الخادم المستهدَف لتحديد ما إذا كان الخادم المستهدَف يعمل بشكل سليم أم لا.
يمكن أن تؤدي عملية التحقّق من الصحة إلى إحدى نتيجتين محتملتَين:
- النجاح: يُعتبر الخادم المستهدَف في حالة جيدة عند إجراء عملية التحقّق من الحالة بنجاح. ويحدث ذلك عادةً لسبب واحد أو أكثر مما يلي:
- يقبل الخادم المستهدَف اتصالاً جديدًا بالمنفذ المحدّد، ويستجيب لطلب على هذا المنفذ، ثم يغلق المنفذ خلال الإطار الزمني المحدّد. تحتوي الاستجابة من الخادم المستهدَف على "Connection: close"
- يستجيب الخادم المستهدَف لطلب التحقّق من الصحة برمز الحالة 200 (OK) أو رمز حالة HTTP آخر تحدّده على أنّه مقبول.
- يردّ الخادم المستهدَف على طلب التحقّق من الصحة من خلال نص رسالة يتطابق مع نص الرسالة المتوقّع.
عندما يرصد Edge أنّ الخادم يعمل بشكل سليم، يواصل Edge إرسال الطلبات إليه أو يستأنف إرسالها.
- تعذُّر الإجراء: يمكن أن يتعذّر على الخادم المستهدَف إجراء فحص للصحة بطرق مختلفة،
استنادًا إلى نوع الفحص. يمكن تسجيل تعذّر في حال كان الخادم المستهدَف:
- يرفض الاتصال من Edge بمنفذ التحقّق من الصحة.
- عدم الاستجابة لطلب التحقّق من الصحة خلال فترة زمنية محدّدة
- تعرِض رمز حالة HTTP غير متوقّع.
- يتم الردّ باستخدام نص رسالة لا يتطابق مع نص الرسالة المتوقّع.
عندما يتعذّر على خادم مستهدَف اجتياز فحص الحالة، يزيد Edge من عدد حالات تعذُّر اجتياز الفحص لهذا الخادم. إذا بلغ عدد حالات تعذُّر الاتصال بهذا الخادم الحدّ الأقصى المحدَّد مسبقًا أو تجاوزه (
<MaxFailures>
)، يتوقف Edge عن إرسال الطلبات إلى هذا الخادم.
تفعيل أداة HealthMonitor
لإنشاء HealthMonitor، يمكنك إضافة العنصر <HealthMonitor>
إلى إعدادات HTTPConnection
في TargetEndpoint لوكيل. لا يمكنك إجراء ذلك في واجهة المستخدم. بدلاً من ذلك، يمكنك إنشاء إعدادات خادم وكيل وتحميلها كملف ZIP إلى Edge. إعداد الخادم الوكيل هو وصف منظَّم لجميع جوانب
خادم وكيل واجهة برمجة التطبيقات. تتألف إعدادات الخادم الوكيل من ملفات XML في بنية دليل محدّدة مسبقًا. لمزيد من
المعلومات، يُرجى الاطّلاع على مرجع إعدادات
واجهة برمجة التطبيقات الوكيلة.
يحدِّد HealthMonitor بسيط IntervalInSec
مع إما
TCPMonitor أو HTTPMonitor. يحدِّد العنصر <MaxFailures>
الحد الأقصى
لعدد الطلبات التي تعذّر تنفيذها من خادم API الوكيل إلى TargetServer، ما يؤدي إلى إعادة توجيه الطلب
إلى TargetServer آخر. تكون القيمة التلقائية للمتغيّر <MaxFailures>
هي 0، ما يعني أنّه
لا يتّخذ Edge أي إجراء تصحيحي. عند ضبط أداة مراقبة الحالة، تأكَّد من ضبط
<MaxFailures>
في
علامة <HTTPTargetConnection>
من علامة <TargetEndpoint>
على قيمة غير صفرية.
TCPMonitor
تحدِّد الإعدادات أدناه أداة HealthMonitor التي تُجري استطلاعات على كل TargetServer من خلال فتح اتصال على المنفذ 80 كل خمس ثوانٍ. (المنفذ اختياري. إذا لم يتم تحديده، يكون منفذ TCPMonitor هو منفذ TargetServer.)
- إذا تعذّر الاتصال أو استغرق أكثر من 10 ثوانٍ، يزداد عدد حالات الفشل بمقدار 1 للخادم المستهدَف هذا.
- إذا تم الاتصال بنجاح، تتم إعادة ضبط عدد حالات الفشل لخادم TargetServer على 0.
يمكنك إضافة HealthMonitor كعنصر فرعي لعنصر HTTPTargetConnetion في TargetEndpoint، كما هو موضّح أدناه:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> </LoadBalancer> <Path>/test</Path> <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <TCPMonitor> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <Port>80</Port> </TCPMonitor> </HealthMonitor> </HTTPTargetConnection> . . .
عناصر ضبط HealthMonitor مع TCPMonitor
يوضّح الجدول التالي عناصر إعدادات TCPMonitor:
الاسم | الوصف | تلقائي | مطلوب؟ |
---|---|---|---|
IsEnabled |
قيمة منطقية لتفعيل HealthMonitor أو إيقافه | خطأ | لا |
IntervalInSec |
الفاصل الزمني، بالثواني، بين كل طلب TCP للفحص | 0 | نعم |
ConnectTimeoutInSec |
الوقت الذي يجب فيه إنشاء اتصال بمنفذ TCP ليُعتبر ناتجًا عن عملية ناجحة. ويُحتسَب تعذُّر الاتصال خلال الفاصل الزمني المحدَّد كخطأ، ما يؤدي إلى زيادة عدد أخطاء موزّع الحمولة لـ TargetServer. | 0 | نعم |
Port |
اختيارية: المنفذ الذي سيتم إنشاء اتصال TCP عليه. إذا لم يتم تحديده، يكون منفذ TCPMonitor هو منفذ TargetServer. | 0 | لا |
HTTPMonitor
سيُرسِل نموذج HealthMonitor الذي يستخدم HTTPMonitor طلب GET إلى خدمة الخلفي
مرة واحدة كل خمس ثوانٍ. يضيف المثال أدناه رأس HTTP Basic Authorization إلى رسالة طلب. تحدِّد إعدادات الاستجابة الإعدادات التي ستتم مقارنتها بالاستجابة
الفعلية من خدمة الخلفية. في المثال أدناه، الاستجابة المتوقّعة هي رمز استجابة HTTP
200
وعنوان HTTP مخصّص ImOK
قيمته
YourOK
. في حال عدم تطابق الردّ، سيتم التعامل مع الطلب على أنّه تعذّر
تنفيذه وفقًا لإعدادات موازن الحمولة.
يتوافق HTTPMonitor مع خدمات الخلفية التي تم ضبطها لاستخدام بروتوكولَي HTTP وHTTPS في اتجاه واحد. ومع ذلك، لا يتيح هذا الإجراء ما يلي:
- بروتوكول HTTPS ثنائي الاتجاه (يُعرف أيضًا باسم بروتوكول TLS/SSL ثنائي الاتجاه)
- الشهادات الموقَّعة ذاتيًا.
يُرجى العلم أنّ جميع إعدادات الطلب والاستجابة في أداة مراقبة HTTP ستكون خاصة بخدمة الخلفية التي يجب استدعاؤها.
<HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <HTTPMonitor> <Request> <IsSSL>true</IsSSL> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec> <Port>80</Port> <Verb>GET</Verb> <Path>/healthcheck</Path> <Header name="Authorization">Basic 12e98yfw87etf</Header> <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader> </Request> <SuccessResponse> <ResponseCode>200</ResponseCode> <Header name="ImOK">YourOK</Header> </SuccessResponse> </HTTPMonitor> </HealthMonitor>
عناصر إعداد HealthMonitor مع HTTPMonitor
يوضّح الجدول التالي عناصر إعدادات HTTPMonitor:
الاسم | الوصف | تلقائي | مطلوب؟ |
---|---|---|---|
IsEnabled |
قيمة منطقية لتفعيل HealthMonitor أو إيقافه | خطأ | لا |
IntervalInSec |
الفاصل الزمني، بالثواني، بين كل طلب فحص | 0 | نعم |
Request |
خيارات الضبط لرسالة الطلب الصادر التي يرسلها HealthMonitor إلى TargetServers في التناوب لا يتوافق "المسار" مع المتغيّرات. |
لا ينطبق | نعم |
IsSSL |
لتحديد ما إذا كان سيتم استخدام بروتوكول HTTPS (بروتوكول HTTP الآمن) لمراقبة عمليات الاتصال. القيم المحتملة:
|
خطأ | لا |
ConnectTimeoutInSec |
الوقت، بالثواني، الذي يجب فيه اكتمال عملية مصافحة اتصال بروتوكول النقل المتعدّد (TCP) بخدمة HTTP ليكون الأمر ناجحاً يُحتسَب تعذُّر الاتصال خلال الفاصل الزمني المحدَّد على أنّه خطأ، ما يؤدي إلى زيادة عدد حالات الخطأ في LoadBalancer للخادم TargetServer. | 0 | لا |
SocketReadTimeoutInSec |
الوقت، بالثواني، الذي يجب قراءة البيانات فيه من خدمة HTTP لاعتباره عملية ناجحة. يتم احتساب تعذُّر القراءة في الفاصل الزمني المحدَّد كخطأ، ما يؤدي إلى زيادة عدد أخطاء LoadBalancer للخادم TargetServer. | 0 | لا |
Port |
المنفذ الذي سيتم من خلاله إنشاء اتصال HTTP بخدمة الخلفية. | لا ينطبق | لا |
Verb |
يشير ذلك إلى فعل HTTP المستخدَم لكل طلب HTTP لفحص الخدمة الخلفية . | لا ينطبق | لا |
Path |
المسار الذي يتم إلحاقه بعنوان URL المحدّد في TargetServer استخدِم عنصر المسار ل ضبط "نقطة نهاية الاستطلاع" في خدمة HTTP. | لا ينطبق | لا |
| يتيح لك
تتبُّع طلبات التحقّق من الصحة على الأنظمة المصدر. يأخذ العنصر
IncludeHealthCheckIdHeader قيمة منطقية، وتكون القيمة التلقائية
هي false . إذا تم ضبطه على true ،
سيكون هناك Header باسم X-Apigee-Healthcheck-Id
يتم
إدراجه في طلب التحقّق من الصحة. يتم تحديد قيمة العنوان
ديناميكيًا، وتتخذ الشكل
ORG/ENV/SERVER_UUID/N، حيث يكون ORG هو
اسم المؤسسة، وENV هو اسم البيئة،
SERVER_UUID هو معرّف فريد يحدِّد وحدة إدارة الحملة، و
N هو عدد المللي ثانية التي انقضت منذ 1 كانون الثاني (يناير) 1970.
مثال على عنوان الطلب الناتج: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123
|
خطأ | لا |
Payload |
نص HTTP الذي تم إنشاؤه لكل طلب HTTP لفحص حالة الاتصال يُرجى العِلم أنّ هذا العنصر ليس مطلوبًا لطلبات GET. | لا ينطبق | لا |
SuccessResponse |
خيارات المطابقة لرسالة استجابة HTTP الواردة التي أنشأتها خدمة فحص الخلفية تؤدي الردود التي لا تتطابق إلى زيادة عدد حالات الفشل بمقدار 1. | لا ينطبق | لا |
ResponseCode |
رمز استجابة HTTP المتوقّع أن يتم تلقّيه من الخادم المستخدَم في الاستطلاع (TargetServer) يؤدي إدخال رمز مختلف عن الرمز المحدّد إلى حدوث خطأ، ويتمّ زيادة العدد المرتبط بخدمة الخلفية التي يتمّ الاستعلام عنها. يمكنك تحديد عناصر ResponseCode متعددة. | لا ينطبق | لا |
Headers |
قائمة برأس HTTP واحد أو أكثر والقيم المتوقّعة من خدمة الخلفي ة التي يتمّ الاستعلام عنها يؤدي أيّ رؤوس أو قيم HTTP في الاستجابة تختلف عن تلك المحدّدة إلى حدوث خطأ، ويتمّ زيادة عدد TargetServer الذي يتمّ الاستعلام عنه بمقدار 1. يمكنك تحديد عناصر Header متعددة. | لا ينطبق | لا |