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

يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستند Apigee X. المعلومات

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

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

يتألف تعريف TargetServer من اسم ومضيف ومنفذ، مع عنصر إضافي للإشارة إلى ما إذا كان TargetServer مفعَّلاً أو غير مفعّل.

الفيديوهات

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

حملة فيديو	الوصف
موازنة التحميل باستخدام الخوادم الهدف	واجهات برمجة تطبيقات موازنة التحميل في جميع الخوادم المستهدفة.
توجيه واجهة برمجة التطبيقات استنادًا إلى البيئة باستخدام الخوادم المستهدفة	وجِّه واجهة برمجة التطبيقات إلى خادم مستهدف مختلف بناءً على البيئة.
توجيه واجهة برمجة التطبيقات وموازنة التحميل باستخدام الخوادم المستهدفة (الإصدار الكلاسيكي من Edge)	يمكنك توجيه واجهة برمجة تطبيقات إلى خادم مستهدف مختلف بناءً على البيئة وزيادة توازن التحميل في واجهة برمجة التطبيقات على الخوادم المستهدفة في واجهة مستخدم Classic 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 بدون تعديل إعدادات الخادم الوكيل لواجهة برمجة التطبيقات. ومن الاستخدامات الشائعة كتابة تطبيق أو نص برمجي يفعّل أو يوقِف ميزة TargetServers تلقائيًا استنادًا إلى متطلبات السعة المتوقّعة والجداول الزمنية للصيانة وما إلى ذلك.	true	نعم

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

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

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

يمكنك استخدام واجهة برمجة تطبيقات Edge لإنشاء الخوادم المستهدفة وحذفها وتحديثها والحصول عليها وإدراجها. لمزيد من المعلومات، يُرجى الاطّلاع على 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 ثانٍ. من خلال تحديد خادمي TargetServers، يمكنك توفير عنوانَي 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" ]

يتوفّر الآن خادمان TargetServers لاستخدامهما من خلال الخوادم الوكيلة لواجهة برمجة التطبيقات التي تم نشرها في بيئة الاختبار. لتحميل حركة بيانات الرصيد في هذه الخادمات، يجب ضبط اتصال HTTP في نقطة النهاية المستهدفة للخادم الوكيل لواجهة برمجة التطبيقات لاستخدام TargetServers.

هناك حد أقصى يبلغ 500 خادم TargetServers لكل بيئة، كما هو موثّق في موضوع limits (الحدود).

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

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

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

يمكنك ضبط مدى التوفّر باستخدام خيارات موازنة التحميل وتجاوز الإخفاق على مستوى موازن التحميل وعلى مستوى TargetServer. ويوضّح هذا القسم هذين الخيارَين.

خوارزمية

تحدِّد الخوارزمية المستخدَمة في <LoadBalancer>. الخوارزميات المتاحة هي RoundRobin وWeighted وLeastConnections، وقد تم توثيق كلّ منها أدناه.

الترتيب الدوري

تعيد الخوارزمية التلقائية، Round robin، توجيه الطلب إلى كل 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>

في هذا المثال، سيتم توجيه طلبَين إلى الهدف 2 لكل طلب يتم توجيهه إلى الهدف 1.

أقل اتصال

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

بدلاً من ذلك، إذا ضبطت MaxFailures > 0 ولم تضبط Health Monitor، لن تعيد Apigee تضمين عناصر TargetServer في عملية التناوب تلقائيًا بعد رصد حدوث عطل في Apigee. في هذه الحالة، يجب إعادة نشر الخادم الوكيل لواجهة برمجة التطبيقات قبل أن يعيد Apigee تفعيل TargetServer مرة أخرى. يُرجى الاطّلاع على نشر خادم وكيل لواجهة برمجة التطبيقات.

إعادة المحاولة

في حال تفعيل ميزة "إعادة المحاولة"، ستتم إعادة محاولة إرسال الطلب كلما حدثت مشكلة في الاستجابة (خطأ في وحدات الإدخال والإخراج أو انتهاء مهلة 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) أو طبقة المقابس الآمنة أحادية الاتجاه حيث يُجري 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 و Private 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> الحدّ الأقصى لعدد الطلبات التي تعذّر تنفيذها من الخادم الوكيل لواجهة برمجة التطبيقات إلى خادم 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:

الاسم	الوصف	تلقائي	مطلوب؟
IsEnabled	يشير ذلك المصطلح إلى قيمة منطقية تفعّل ميزة HealthMonitor أو توقفها.	false	لا
IntervalInSec	الفاصل الزمني بالثواني بين كل طلب بروتوكل التحكم في الإرسال (TCP).	0	نعم
ConnectTimeoutInSec	الوقت الذي يجب أن يتم فيه الاتصال بمنفذ TCP ليتم اعتباره ناجحًا. يُعد الفشل في الاتصال خلال الفاصل الزمني المحدد بمثابة إخفاق، مما يؤدي إلى زيادة عدد إخفاقات جهاز موازنة الحمل لـ TargetServer.	0	نعم
Port	اختياريّ. المنفذ الذي سيتم إنشاء اتصال TCP عليه. في حال عدم تحديد ذلك، يكون منفذ TCPMonitor هو منفذ TargetServer.	0	لا

HTTPMonitor

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

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

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

تجدر الإشارة إلى أنّ جميع إعدادات الطلب والاستجابة في شاشة 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 أو توقفها.	false	لا
IntervalInSec	الفاصل الزمني بالثواني بين كل طلب استطلاع رأي.	0	نعم
Request	خيارات الإعداد لرسالة الطلب الصادرة التي تم إرسالها من خلال HealthMonitor إلى خوادم TargetServers بالتناوب. لا يدعم المسار المتغيرات.	لا ينطبق	نعم
IsSSL	تحدِّد هذه السياسة ما إذا كان سيتم استخدام HTTPS (بروتوكول HTTP آمن) لمراقبة الاتصالات. القيم المحتملة: true: يتم استخدام بروتوكول HTTPs. false: يتم استخدام بروتوكول HTTP. غير محدد: يستخدم هذا الإعداد إعدادات الخادم الهدف.	false	لا
ConnectTimeoutInSec	الوقت بالثواني الذي يجب فيه أن تكتمل عملية تأكيد اتصال اتصال بروتوكول التحكم بالنقل بخدمة HTTP ليتم اعتبارها ناجحة. يُعد الفشل في الاتصال خلال الفاصل الزمني المحدد بمثابة إخفاق، مما يؤدي إلى زيادة عدد إخفاقات LoadBalancer لـ TargetServer.	0	لا
SocketReadTimeoutInSec	الوقت بالثواني الذي يجب فيه قراءة البيانات من خدمة HTTP ليتم اعتبارها ناجحة. تُعتبر عدم القراءة خلال الفاصل الزمني المحدد بمثابة إخفاق، ما يؤدي إلى زيادة عدد إخفاقات LoadBalancer في TargetServer.	0	لا
Port	المنفذ الذي سيتم إنشاء اتصال HTTP بخدمة الخلفية عليه.	لا ينطبق	لا
Verb	فعل HTTP المستخدم لكل استقصاء لطلب HTTP إلى خدمة الخلفية .	لا ينطبق	لا
Path	المسار الملحق بعنوان URL المحدّد في TargetServer. ويمكنك استخدام عنصر المسار لضبط "نقطة نهاية الاستطلاع" على خدمة HTTP.	لا ينطبق	لا
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 للاستقصاء. يُرجى العِلم أنّ هذا العنصر غير مطلوب لطلبات GET.	لا ينطبق	لا
SuccessResponse	خيارات مطابقة لرسالة استجابة HTTP الواردة التي تم إنشاؤها بواسطة خدمة الواجهة الخلفية التي تم إجراء استطلاع لها. وتؤدي الردود غير المطابقة إلى زيادة عدد الأخطاء بمقدار 1.	لا ينطبق	لا
ResponseCode	رمز استجابة HTTP المتوقع أن يتم استلامه من TargetServer الذي تم فحصه. يؤدي استخدام رمز مختلف عن الرمز المحدّد إلى حدوث خطأ، وتتم زيادة العدد لخدمة الخلفية التي تم إجراء استطلاع لها. يمكنك تحديد عناصر ResponseCode متعددة.	لا ينطبق	لا
Headers	قائمة تتضمّن عنوان HTTP واحدًا أو أكثر من القيم المتوقّعة أن يتم تلقّيها من الخدمة الخلفية التي تم إجراء استطلاع لها. يؤدي استخدام أي عناوين أو قيم HTTP في الاستجابة مختلفة عن تلك المحدّدة يمكنك تحديد عناصر عنوان متعددة.	لا ينطبق	لا