موازنة الحمل عبر خوادم الخلفية

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

تعزّز Apigee Edge مدى توفّر واجهة برمجة التطبيقات من خلال توفير دعم مدمج لموازنة الحمل والتبديل التلقائي بين مثيلات خادم الخلفية المتعددة.

تعمل إعدادات TargetServer على فصل عناوين URL المحدّدة لنقاط النهاية عن إعدادات TargetEndpoint. يتم الرجوع إلى كل TargetServer بالاسم في TargetEndpoint HTTPConnection. بدلاً من تحديد عنوان URL ملموس في الإعدادات، يمكنك ضبط خادم TargetServer واحد أو أكثر باسم، كما هو موضّح في القسم TargetEndpoint.

يتألف تعريف TargetServer من اسم ومضيف ومنفذ، مع عنصر إضافي لتحديد ما إذا كان TargetServer مفعّلاً أو غير مفعّل.

الفيديوهات

شاهِد الفيديوهات التالية لمعرفة المزيد حول توجيه طلبات البيانات إلى واجهة برمجة التطبيقات وموازنة التحميل باستخدام الخوادم المستهدَفة

مثال على إعدادات TargetServer

يحدّد الرمز التالي خادمًا مستهدفًا:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

عناصر إعدادات TargetServer

يوضّح الجدول التالي العناصر المستخدَمة لإنشاء TargetServer وضبط إعداداته:

إدارة الخوادم المستهدَفة باستخدام واجهة المستخدم

إدارة الخوادم المستهدَفة، كما هو موضّح أدناه.

إدارة الخوادم المستهدَفة باستخدام واجهة برمجة التطبيقات

يمكنك استخدام 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، عليك ضبط اتصال HTTP في نقطة نهاية مستهدَفة لخادم وكيل API لاستخدام الخوادم TargetServer.

يبلغ الحدّ الأقصى لعدد TargetServer‏ 500 لكل بيئة، كما هو موضّح في موضوع الحدود.

إعداد TargetEndpoint لموازنة الحمل على مستوى TargetServers المسماة

بعد توفّر خادمي TargetServer، يمكنك تعديل إعداد اتصال 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 هي الخوارزمية التلقائية. بما أنّه لم يتم تحديد أي خوارزمية في الإعدادات أعلاه، سيتم بالتناوب إرسال الطلبات الصادرة من خادم وكيل واجهة برمجة التطبيقات إلى خوادم الخلفية، واحدًا تلو الآخر، بين target1 وtarget2.

يشكّل العنصر <Path> المسار الأساسي لمعرّف الموارد المنتظم (URI) الخاص بـ TargetEndpoint لجميع الخوادم المستهدَفة. يتم استخدامها فقط عند استخدام <LoadBalancer>. وإلا سيتم تجاهله. في المثال أعلاه، سيتم http://target1/test الطلب الذي يصل إلى "target1"، وينطبق الأمر نفسه على خوادم الاستهداف الأخرى.

ضبط خيارات موازنة الحمل

يمكنك ضبط مدى التوفّر باستخدام خيارات موازنة الحمل والتبديل الاحتياطي على مستوى موازن الحمل و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 المرجّح الطلبات على TargetServers بما يتناسب طرديًا مع وزن كل TargetServer. لذلك، تتطلّب الخوارزمية المرجّحة منك ضبط سمة 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>

في هذا المثال، سيتم توجيه طلبَين إلى target2 مقابل كل طلب يتم توجيهه إلى target1.

Least Connection

توجّه أجهزة موازنة الحمل التي تم ضبطها لاستخدام خوارزمية أقل اتصال الطلبات الصادرة إلى 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 الأخرى غير متاحة. عندما يحدّد موازن التحميل أنّ جميع 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) في السحابة الإلكترونية الخاصة.

للحصول على تعليمات كاملة حول إعداد بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) الصادر، يُرجى الاطّلاع على إعداد بروتوكول أمان طبقة النقل (TLS) من Edge إلى الخلفية (السحابة الإلكترونية والسحابة الإلكترونية الخاصة).

مخطط 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"
  • يستجيب الخادم المستهدف لطلب التحقّق من الصحة برمز حالة HTTP 200 (OK) أو رمز آخر تحدّده على أنّه مقبول.
  • يستجيب الخادم المستهدف لطلب التحقّق من الصحة من خلال نص رسالة يتطابق مع نص الرسالة المتوقّع.

  عندما يحدّد Edge أنّ الخادم سليم، يواصل إرسال الطلبات إليه أو يستأنفها.

• تعذُّر: يمكن أن يتعذّر على الخادم المستهدف اجتياز عملية التحقّق من السلامة بطرق مختلفة، وذلك حسب نوع عملية التحقّق. يمكن تسجيل حالة تعذُّر عند حدوث أي مما يلي في الخادم المستهدف:
  • يرفض اتصالاً من Edge بمنفذ فحص الصحة.
  • عدم الاستجابة لطلب التحقّق من الحالة خلال فترة زمنية محدّدة
  • تعرض رمز حالة HTTP غير متوقّع.
  • الردّ بنص رسالة لا يتطابق مع نص الرسالة المتوقّع

  عندما يتعذّر على خادم مستهدف اجتياز عملية التحقّق من الصحة، يزيد Edge عدد مرات تعذّر هذا الخادم. إذا كان عدد حالات التعذّر لهذا الخادم يبلغ الحدّ الأدنى المحدّد مسبقًا أو يتجاوزه (<MaxFailures>)، يتوقف Edge عن إرسال الطلبات إلى هذا الخادم.

تفعيل HealthMonitor

لإنشاء HealthMonitor، عليك إضافة العنصر <HealthMonitor> إلى إعداد HTTPConnection الخاص بـ TargetEndpoint للوكيل. لا يمكنك إجراء ذلك في واجهة المستخدم. بدلاً من ذلك، يمكنك إنشاء إعدادات خادم وكيل وتحميلها كملف ZIP إلى Edge. إعدادات الخادم الوكيل هي وصف منظَّم لجميع جوانب خادم وكيل لواجهة برمجة التطبيقات. تتألف إعدادات الخادم الوكيل من ملفات XML في بنية دليل محدّدة مسبقًا. لمزيد من المعلومات، يُرجى الاطّلاع على مرجع إعداد خادم وكيل لواجهة برمجة التطبيقات.

يحدّد HealthMonitor بسيط IntervalInSec مع TCPMonitor أو HTTPMonitor. يحدّد العنصر <MaxFailures> الحد الأقصى لعدد الطلبات التي تعذّر تنفيذها من خادم وكيل لواجهة برمجة التطبيقات إلى TargetServer، ما يؤدي إلى إعادة توجيه الطلب إلى TargetServer آخر. القيمة التلقائية <MaxFailures> هي 0، ما يعني أنّ Edge لا يتّخذ أي إجراء تصحيحي. عند ضبط أداة مراقبة السلامة، تأكَّد من ضبط <MaxFailures> في علامة <HTTPTargetConnection> الخاصة بعلامة <TargetEndpoint> على قيمة غير صفرية.

TCPMonitor

يحدّد الإعداد أدناه HealthMonitor الذي يستقصي كل TargetServer من خلال فتح اتصال على المنفذ 80 كل خمس ثوانٍ. (المنفذ اختياري. في حال عدم تحديدها، يكون منفذ TCPMonitor هو منفذ TargetServer.)

• إذا تعذّر الاتصال أو استغرق أكثر من 10 ثوانٍ، سيزيد عدد حالات التعذّر بمقدار 1 لخادم TargetServer هذا.
• في حال نجاح الاتصال، تتم إعادة ضبط عدد حالات التعذّر في 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:

HTTPMonitor

سيُرسل نموذج HealthMonitor الذي يستخدم HTTPMonitor طلب استرداد بيانات باستخدام GET إلى خدمة الخلفية مرة كل خمس ثوانٍ. يضيف المثال أدناه ترويسة HTTP Basic Authorization إلى رسالة الطلب. يحدّد إعداد الردّ الإعدادات التي ستتم مقارنتها بالردّ الفعلي من خدمة الخلفية. في المثال أدناه، الاستجابة المتوقّعة هي رمز استجابة HTTP 200 وعنوان HTTP مخصّص ImOK قيمته YourOK. إذا لم يتطابق الردّ، سيتعامل جهاز موازنة الحمل مع الطلب على أنّه غير ناجح.

تتيح أداة HTTPMonitor استخدام خدمات الخلفية التي تم ضبطها لاستخدام بروتوكولَي HTTP وHTTPS أحادي الاتجاه. ومع ذلك، لا يتيح ما يلي:

• بروتوكول HTTPS ثنائي الاتجاه (يُعرف أيضًا باسم بروتوكول أمان طبقة النقل/طبقة المقابس الآمنة ثنائي الاتجاه)
• الشهادات الموقَّعة ذاتيًا.

يُرجى العِلم أنّ جميع إعدادات "الطلب" و"الرد" في أداة مراقبة 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: