تعادل بار در سرورهای باطن

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

Apigee Edge با ارائه پشتیبانی داخلی برای متعادل‌سازی بار و failover در چندین نمونه سرور backend، دسترسی‌پذیری API شما را افزایش می‌دهد.

پیکربندی‌های TargetServer، URLهای نقطه پایانی مشخص را از پیکربندی‌های TargetEndpoint جدا می‌کنند. هر TargetServer با نام در یک TargetEndpoint HTTPConnection ارجاع داده می‌شود. به جای تعریف یک URL مشخص در پیکربندی، می‌توانید یک یا چند TargetServer با نام را همانطور که در بخش TargetEndpoint توضیح داده شده است، پیکربندی کنید.

تعریف TargetServer شامل یک نام، یک میزبان و یک پورت است، به همراه یک عنصر اضافی که نشان می‌دهد TargetServer فعال است یا غیرفعال.

ویدیوها

برای کسب اطلاعات بیشتر در مورد مسیریابی API و متعادل‌سازی بار با استفاده از سرورهای هدف، ویدیوهای زیر را تماشا کنید.

نمونه پیکربندی TargetServer

کد زیر یک سرور هدف را تعریف می‌کند:

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

عناصر پیکربندی TargetServer

جدول زیر عناصر مورد استفاده برای ایجاد و پیکربندی TargetServer را شرح می‌دهد:

مدیریت سرورهای هدف با استفاده از رابط کاربری

سرورهای هدف را طبق توضیحات زیر مدیریت کنید.

مدیریت سرورهای هدف با استفاده از 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
}

برای بازیابی لیستی از TargetServers در یک محیط، از فراخوانی API زیر استفاده کنید:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

نمونه پاسخ:

[ "target2", "target1" ]

اکنون دو TargetServer برای استفاده توسط پروکسی‌های API مستقر در محیط آزمایشی در دسترس هستند. برای بارگذاری ترافیک متعادل در سراسر این TargetServerها، اتصال HTTP را در نقطه پایانی هدف یک پروکسی API برای استفاده از TargetServerها پیکربندی می‌کنید.

همانطور که در مبحث محدودیت‌ها مستند شده است، محدودیت ۵۰۰ سرور هدف برای هر محیط وجود دارد.

پیکربندی یک 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 الگوریتم پیش‌فرض است. از آنجایی که هیچ الگوریتمی در پیکربندی بالا مشخص نشده است، درخواست‌های خروجی از پروکسی API به سرورهای backend، یکی پس از دیگری، بین target1 و target2 جابجا می‌شوند.

عنصر <Path> مسیر پایه‌ی URI مربوط به TargetEndpoint را برای تمام سرورهای هدف تشکیل می‌دهد. این عنصر فقط زمانی استفاده می‌شود که <LoadBalancer> استفاده شود. در غیر این صورت، نادیده گرفته می‌شود. در مثال بالا، درخواستی که به "target1" می‌رسد http://target1/test خواهد بود و برای سایر سرورهای هدف نیز به همین ترتیب.

تنظیم گزینه‌های متعادل‌کننده بار

شما می‌توانید با استفاده از گزینه‌هایی برای متعادل‌سازی بار و failover در سطح متعادل‌کننده بار و 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 وزن‌دار، درخواست‌ها را به نسبت مستقیم با وزن هر TargetServer به 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>

در این مثال، به ازای هر درخواستی که به target1 ارسال می‌شود، دو درخواست به target2 ارسال خواهد شد.

کمترین اتصال

متعادل‌کننده‌های بار (LoadBalancers) که طوری پیکربندی شده‌اند که از الگوریتم کمترین اتصال (Leaking Connection Algorithm) استفاده کنند، درخواست‌های خروجی را به سرور هدف (TargetServer) با کمترین اتصالات HTTP باز هدایت می‌کنند. برای مثال:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

حداکثر شکست‌ها

حداکثر تعداد درخواست‌های ناموفق از پروکسی 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 برابر با ۰ است. این یعنی Edge همیشه سعی می‌کند برای هر درخواست به سرور هدف متصل شود و هرگز سرور هدف را از چرخه حذف نمی‌کند.

بهتر است از MaxFailures > 0 به همراه HealthMonitor استفاده کنید. اگر MaxFailures > 0 را پیکربندی کنید، TargetServer زمانی که هدف به تعداد دفعاتی که شما مشخص می‌کنید، دچار خطا شود، از چرخه خارج می‌شود. وقتی HealthMonitor وجود دارد، Apigee به طور خودکار TargetServer را پس از راه‌اندازی مجدد هدف، طبق پیکربندی آن HealthMonitor، دوباره به چرخه برمی‌گرداند. برای اطلاعات بیشتر به Health monitoring مراجعه کنید.

از طرف دیگر، اگر MaxFailures را روی ۰ تنظیم کنید و مانیتور سلامت را پیکربندی نکنید، Apigee به طور خودکار سرور هدف را با تشخیص اولین خرابی از چرخه خارج می‌کند. Apigee هر پنج دقیقه سلامت سرور هدف را بررسی می‌کند و وقتی به طور عادی پاسخ داد، آن را به چرخه برمی‌گرداند.

دوباره امتحان کنید

اگر تلاش مجدد فعال باشد، هر زمان که یک خطای پاسخ (خطای I/O یا زمان انقضای HTTP) رخ دهد یا پاسخ دریافتی با مقداری که توسط <ServerUnhealthyResponse> تعیین شده است مطابقت داشته باشد، درخواست دوباره تلاش خواهد شد. برای اطلاعات بیشتر در مورد تنظیم <ServerUnhealthyResponse> به حداکثر شکست‌ها در بالا مراجعه کنید.

به طور پیش‌فرض <RetryEnabled> روی true تنظیم شده است. برای غیرفعال کردن تلاش مجدد، آن را روی false تنظیم کنید. برای مثال:

<RetryEnabled>false</RetryEnabled>

ایس‌فال‌بک

یک (و فقط یک) سرور هدف می‌تواند به عنوان سرور جایگزین تنظیم شود. سرور هدف جایگزین تا زمانی که تمام سرورهای هدف دیگر توسط متعادل‌کننده بار به عنوان غیرقابل دسترس شناسایی نشوند، در روال‌های متعادل‌سازی بار گنجانده نمی‌شود. هنگامی که متعادل‌کننده بار تشخیص دهد که همه سرورهای هدف در دسترس نیستند، تمام ترافیک به سرور جایگزین هدایت می‌شود. به عنوان مثال:

<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>

پیکربندی فوق منجر به ایجاد تعادل بار به صورت چرخشی بین اهداف ۱ و ۲ می‌شود تا زمانی که هر دو هدف ۱ و ۲ از دسترس خارج شوند. هنگامی که اهداف ۱ و ۲ از دسترس خارج شوند، تمام ترافیک به سمت هدف ۳ هدایت می‌شود.

مسیر

مسیر (Path) یک قطعه URI را تعریف می‌کند که به تمام درخواست‌های ارسالی از TargetServer به سرور backend اضافه خواهد شد.

این عنصر یک مسیر رشته‌ای تحت‌اللفظی یا یک الگوی پیام را می‌پذیرد. یک الگوی پیام به شما امکان می‌دهد جایگزینی رشته متغیر را در زمان اجرا انجام دهید. برای مثال، در تعریف نقطه پایانی هدف زیر، مقدار {mypath} برای مسیر استفاده می‌شود:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

پیکربندی سرور هدف برای TLS/SSL

اگر از TargetServer برای تعریف سرویس backend استفاده می‌کنید و سرویس backend نیاز به اتصال برای استفاده از پروتکل HTTPS دارد، باید TLS/SSL را در تعریف TargetServer فعال کنید. این امر ضروری است زیرا تگ <Host> به شما اجازه نمی‌دهد پروتکل اتصال را مشخص کنید. در زیر تعریف TargetServer برای TLS/SSL یک طرفه نشان داده شده است که در آن Edge درخواست‌های HTTPS را به سرویس backend ارسال می‌کند:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

اگر سرویس backend به 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 به backend (Cloud و Private Cloud) مراجعه کنید.

طرحواره سرور هدف

طرحواره TargetServer و سایر موجودیت‌ها را در GitHub ببینید.

نظارت بر سلامت

نظارت بر سلامت به شما این امکان را می‌دهد که با بررسی فعال URLهای سرویس backend که در پیکربندی‌های TargetServer تعریف شده‌اند، پیکربندی‌های متعادل‌سازی بار را بهبود بخشید. با فعال بودن نظارت بر سلامت، یک TargetServer از کار افتاده، هنگامی که HealthMonitor تشخیص دهد که TargetServer فعال است، به طور خودکار به چرخه‌ی کار خود باز می‌گردد.

نظارت بر سلامت با <MaxFailures> کار می‌کند. بدون فعال بودن نظارت بر سلامت، <MaxFailures> تعداد درخواست‌های ناموفق از پروکسی API به TargetServer را مشخص می‌کند که منجر به هدایت درخواست به TargetServer دیگری می‌شود. سپس TargetServer ناموفق از چرخه خارج می‌شود تا زمانی که پروکسی را مجدداً مستقر کنید.

با فعال بودن نظارت بر سلامت، یک TargetServer از کار افتاده به طور خودکار دوباره به چرخه برمی‌گردد و نیازی به استقرار مجدد پروکسی نیست.

HealthMonitor به عنوان یک کلاینت ساده عمل می‌کند که یک سرویس backend را از طریق TCP یا HTTP فراخوانی می‌کند:

• یک کلاینت TCP به سادگی تضمین می‌کند که یک سوکت می‌تواند باز شود.
• شما کلاینت HTTP را طوری پیکربندی می‌کنید که یک درخواست HTTP معتبر به سرویس backend ارسال کند. می‌توانید عملیات HTTP GET، PUT، POST یا DELETE را تعریف کنید. پاسخ فراخوانی HTTP monitor باید با تنظیمات پیکربندی شده در بلوک <SuccessResponse> مطابقت داشته باشد.

موفقیت‌ها و شکست‌ها

وقتی نظارت بر سلامت را فعال می‌کنید، Edge شروع به ارسال بررسی‌های سلامت به سرور هدف شما می‌کند. بررسی سلامت ، درخواستی است که به سرور هدف ارسال می‌شود و مشخص می‌کند که آیا سرور هدف سالم است یا خیر.

یک بررسی سلامت می‌تواند یکی از دو نتیجه ممکن را داشته باشد:

• موفقیت: سرور هدف زمانی سالم در نظر گرفته می‌شود که بررسی سلامت آن با موفقیت انجام شود. این معمولاً نتیجه یک یا چند مورد از موارد زیر است:
  • سرور هدف یک اتصال جدید به پورت مشخص شده را می‌پذیرد، به درخواستی در آن پورت پاسخ می‌دهد و سپس پورت را در بازه زمانی مشخص شده می‌بندد. پاسخ از سرور هدف شامل "اتصال: بستن" است.
  • سرور هدف به درخواست بررسی سلامت با کد ۲۰۰ (OK) یا کد وضعیت HTTP دیگری که شما آن را قابل قبول می‌دانید، پاسخ می‌دهد.
  • سرور هدف به درخواست بررسی سلامت با متن پیامی که با متن پیام مورد انتظار مطابقت دارد، پاسخ می‌دهد.

  وقتی Edge تشخیص می‌دهد که یک سرور سالم است، ارسال درخواست‌ها به آن را ادامه می‌دهد یا از سر می‌گیرد.

• شکست: بسته به نوع بررسی، سرور هدف می‌تواند به روش‌های مختلف در بررسی سلامت شکست بخورد. یک شکست می‌تواند زمانی ثبت شود که سرور هدف:
  • اتصال از Edge به پورت بررسی سلامت را رد می‌کند.
  • در مدت زمان مشخص شده به درخواست بررسی سلامت پاسخ نمی‌دهد.
  • یک کد وضعیت HTTP غیرمنتظره را برمی‌گرداند.
  • با متن پیامی پاسخ می‌دهد که با متن پیام مورد انتظار مطابقت ندارد.

  وقتی یک سرور هدف در بررسی سلامت با شکست مواجه می‌شود، Edge تعداد خرابی‌های آن سرور را افزایش می‌دهد. اگر تعداد خرابی‌ها برای آن سرور به یک آستانه از پیش تعریف شده ( <MaxFailures> ) برسد یا از آن بیشتر شود، Edge ارسال درخواست به آن سرور را متوقف می‌کند.

فعال کردن HealthMonitor

برای ایجاد یک HealthMonitor، عنصر <HealthMonitor> را به پیکربندی HTTPConnection در TargetEndpoint برای یک پروکسی اضافه می‌کنید. نمی‌توانید این کار را در رابط کاربری انجام دهید. در عوض، یک پیکربندی پروکسی ایجاد می‌کنید و آن را به عنوان یک فایل ZIP در Edge آپلود می‌کنید. پیکربندی پروکسی، شرح ساختاریافته‌ای از تمام جنبه‌های یک پروکسی API است. پیکربندی‌های پروکسی شامل فایل‌های XML در یک ساختار دایرکتوری از پیش تعریف شده هستند. برای اطلاعات بیشتر، به مرجع پیکربندی پروکسی API مراجعه کنید.

یک HealthMonitor ساده، یک IntervalInSec همراه با TCPMonitor یا HTTPMonitor تعریف می‌کند. عنصر <MaxFailures> حداکثر تعداد درخواست‌های ناموفق از پروکسی API به TargetServer را مشخص می‌کند که منجر به هدایت درخواست به TargetServer دیگری می‌شود. به طور پیش‌فرض <MaxFailures> برابر با 0 است، به این معنی که Edge هیچ اقدام اصلاحی انجام نمی‌دهد. هنگام پیکربندی یک مانیتور سلامت، مطمئن شوید که <MaxFailures> در تگ <HTTPTargetConnection> از تگ <TargetEndpoint> روی مقداری غیر صفر تنظیم کرده‌اید.

تی‌سی‌پی‌مانیتور

پیکربندی زیر یک HealthMonitor را تعریف می‌کند که با باز کردن یک اتصال روی پورت ۸۰ هر پنج ثانیه، از هر TargetServer نظرسنجی می‌کند. (پورت اختیاری است. اگر مشخص نشود، پورت 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 را شرح می‌دهد:

HTTPمانیتور

یک نمونه HealthMonitor که از HTTPMonitor استفاده می‌کند، هر پنج ثانیه یک بار یک درخواست GET به سرویس backend ارسال می‌کند. نمونه زیر یک هدر HTTP Basic Authorization به پیام درخواست اضافه می‌کند. پیکربندی Response تنظیماتی را تعریف می‌کند که با پاسخ واقعی از سرویس backend مقایسه می‌شوند. در مثال زیر، پاسخ مورد انتظار یک کد پاسخ HTTP 200 و یک هدر HTTP سفارشی ImOK است که مقدار آن YourOK است. اگر پاسخ مطابقت نداشته باشد، درخواست توسط پیکربندی متعادل‌کننده بار به عنوان یک شکست خورده در نظر گرفته می‌شود.

HTTPMonitor از سرویس‌های backend که برای استفاده از پروتکل‌های HTTP و HTTPS یک‌طرفه پیکربندی شده‌اند، پشتیبانی می‌کند. با این حال، از موارد زیر پشتیبانی نمی‌کند:

• HTTPS دوطرفه (همچنین TLS/SSL دوطرفه نامیده می‌شود)
• گواهی‌های خودامضا.

توجه داشته باشید که تمام تنظیمات درخواست و پاسخ در یک مانیتور HTTP مختص سرویس backend است که باید فراخوانی شود.

    <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 را شرح می‌دهد: