बैकएंड सर्वर पर लोड बैलेंसिंग

आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी

Apigee Edge, आपके एपीआई की उपलब्धता को बेहतर बनाता है. इसके लिए, यह कई बैकएंड सर्वर इंस्टेंस पर लोड बैलेंसिंग और फ़ेलओवर के लिए, पहले से मौजूद सहायता उपलब्ध कराता है.

TargetServer कॉन्फ़िगरेशन, एंडपॉइंट यूआरएल को TargetEndpoint कॉन्फ़िगरेशन से अलग करते हैं. हर TargetServer को TargetEndpoint HTTPConnection में नाम से रेफ़रंस किया जाता है. कॉन्फ़िगरेशन में किसी यूआरएल को तय करने के बजाय, TargetEndpoint सेक्शन में बताए गए तरीके से, एक या उससे ज़्यादा TargetServer कॉन्फ़िगर किए जा सकते हैं.

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 तय करके, दो ऐसे यूआरएल दिए जाते हैं जिनका इस्तेमाल 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
}

किसी एनवायरमेंट में TargetServer की सूची पाने के लिए, इस एपीआई कॉल का इस्तेमाल करें:

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

जवाब का उदाहरण:

[ "target2", "target1" ]

अब टेस्ट एनवायरमेंट में डिप्लॉय की गई एपीआई प्रॉक्सी के लिए, दो TargetServer उपलब्ध हैं. इन TargetServers पर ट्रैफ़िक को लोड बैलेंस करने के लिए, एपीआई प्रॉक्सी के टारगेट एंडपॉइंट में एचटीटीपी कनेक्शन कॉन्फ़िगर करें, ताकि TargetServers का इस्तेमाल किया जा सके.

हर एनवायरमेंट के लिए, 500 TargetServer की सीमा होती है. इस बारे में, सीमाएं विषय में बताया गया है.

नाम वाले TargetServers के बीच लोड बैलेंस करने के लिए, TargetEndpoint को कॉन्फ़िगर करना

अब आपके पास दो TargetServer उपलब्ध हैं. इसलिए, TargetEndpoint के एचटीटीपी कनेक्शन की सेटिंग में बदलाव करके, उन दोनों 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 को अनुरोध भेजता है. उदाहरण के लिए:

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

वेटेड

वेटेड लोड बैलेंसिंग एल्गोरिदम की मदद से, अपने TargetServer के लिए ट्रैफ़िक लोड को कॉन्फ़िगर किया जा सकता है. वेटेड LoadBalancer, TargetServer को अनुरोधों को सीधे तौर पर इस तरह से बांटता है कि हर TargetServer का वेट एक जैसा हो. इसलिए, वेटेड एल्गोरिदम के लिए आपको हर 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 पर दो अनुरोध भेजे जाएंगे.

सबसे कम कनेक्शन

सबसे कम कनेक्शन वाले एल्गोरिदम का इस्तेमाल करने के लिए कॉन्फ़िगर किए गए LoadBalancer, आउटबाउंड अनुरोधों को उस TargetServer पर भेजते हैं जिसमें सबसे कम खुले एचटीटीपी कनेक्शन होते हैं. उदाहरण के लिए:

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

ज़्यादा से ज़्यादा गड़बड़ियां

एपीआई प्रॉक्सी से TargetServer को भेजे गए अनुरोधों के पूरे न हो पाने की ज़्यादा से ज़्यादा संख्या. इससे अनुरोध को किसी दूसरे TargetServer पर रीडायरेक्ट किया जाता है.

जवाब न मिलने का मतलब है कि Apigee को टारगेट सर्वर से कोई जवाब नहीं मिला. ऐसा होने पर, फ़ेल होने की संख्या में एक की बढ़ोतरी हो जाती है.

हालांकि, जब Apigee को किसी टारगेट से जवाब मिलता है, तब उसे टारगेट सर्वर से मिला जवाब माना जाता है. भले ही, वह जवाब एचटीटीपी गड़बड़ी (जैसे कि 500) हो. साथ ही, गड़बड़ी का काउंटर रीसेट हो जाता है. यह पक्का करने के लिए कि खराब एचटीटीपी रिस्पॉन्स (जैसे कि 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, हर अनुरोध के लिए हमेशा टारगेट से कनेक्ट करने की कोशिश करता है. साथ ही, टारगेट सर्वर को रोटेशन से कभी नहीं हटाता.

HealthMonitor के साथ MaxFailures > 0 का इस्तेमाल करना सबसे सही होता है. अगर आपने MaxFailures > 0 को कॉन्फ़िगर किया है, तो टारगेट सर्वर को रोटेशन से हटा दिया जाता है. ऐसा तब होता है, जब टारगेट सर्वर उतनी बार फ़ेल हो जाता है जितनी बार आपने बताया है. HealthMonitor चालू होने पर, Apigee टारगेट सर्वर को रोटेशन में अपने-आप वापस डाल देता है. ऐसा तब होता है, जब टारगेट फिर से चालू हो जाता है. यह कार्रवाई, HealthMonitor के कॉन्फ़िगरेशन के हिसाब से होती है. ज़्यादा जानकारी के लिए, सेहत की निगरानी लेख पढ़ें.

इसके अलावा, अगर आपने MaxFailures > 0 कॉन्फ़िगर किया है और आपने हेल्थ मॉनिटर कॉन्फ़िगर नहीं किया है, तो पहली गड़बड़ी का पता चलने पर Apigee, टारगेट सर्वर को रोटेशन से अपने-आप हटा देगा. Apigee, हर पांच मिनट में टारगेट सर्वर की स्थिति की जांच करेगा. अगर सर्वर सामान्य तरीके से काम कर रहा है, तो उसे रोटेशन में वापस ला दिया जाएगा.

फिर से कोशिश करें

अगर फिर से कोशिश करने की सुविधा चालू है, तो अनुरोध को तब फिर से भेजा जाएगा, जब रिस्पॉन्स नहीं मिलता (I/O गड़बड़ी या एचटीटीपी टाइमआउट) होता है या मिला हुआ रिस्पॉन्स, <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 पर रीडायरेक्ट कर दिया जाता है.

पथ

पाथ, यूआरआई फ़्रैगमेंट को तय करता है. इसे TargetServer से बैकएंड सर्वर को भेजे गए सभी अनुरोधों में जोड़ा जाएगा.

यह एलिमेंट, लिटरल स्ट्रिंग पाथ या मैसेज टेंप्लेट को स्वीकार करता है. मैसेज टेंप्लेट की मदद से, रनटाइम के दौरान वैरिएबल स्ट्रिंग को बदला जा सकता है. उदाहरण के लिए, टारगेट एंडपॉइंट की यहां दी गई परिभाषा में, पाथ के लिए {mypath} की वैल्यू का इस्तेमाल किया गया है:

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

TLS/SSL के लिए टारगेट सर्वर कॉन्फ़िगर करना

अगर बैकएंड सेवा को तय करने के लिए TargetServer का इस्तेमाल किया जा रहा है और बैकएंड सेवा के लिए, कनेक्शन को एचटीटीपीएस प्रोटोकॉल का इस्तेमाल करना ज़रूरी है, तो आपको TargetServer की परिभाषा में टीएलएस/एसएसएल चालू करना होगा. यह ज़रूरी है, क्योंकि <Host> टैग में कनेक्शन प्रोटोकॉल के बारे में जानकारी नहीं दी जा सकती. यहां एकतरफ़ा टीएलएस/एसएसएल के लिए TargetServer की परिभाषा दी गई है. इसमें Edge, बैकएंड सेवा को एचटीटीपीएस अनुरोध भेजता है:

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

अगर बैकएंड सेवा के लिए, दोनों तरफ़ से या आपसी सहमति से टीएलएस/एसएसएल की ज़रूरत होती है, तो TargetServer को कॉन्फ़िगर करें. इसके लिए, टीएलएस/एसएसएल कॉन्फ़िगरेशन की वही सेटिंग इस्तेमाल करें जो 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>, प्राइवेट क्लाउड के लिए, एपीआई के टीएलएस ऐक्सेस को कॉन्फ़िगर करना में जाकर, वर्चुअल होस्ट के लिए उन प्रॉपर्टी को सेट करने के बारे में जानकारी देखें.

आउटबाउंड टीएलएस/एसएसएल को कॉन्फ़िगर करने के बारे में पूरी जानकारी के लिए, Edge से बैकएंड (क्लाउड और प्राइवेट क्लाउड) तक टीएलएस कॉन्फ़िगर करना लेख पढ़ें.

TargetServer स्कीमा

GitHub पर TargetServer और अन्य इकाइयों का स्कीमा देखें.

सेहत की देखभाल करने से जुड़े ऐप्लिकेशन

हेल्थ मॉनिटरिंग की मदद से, लोड बैलेंसिंग कॉन्फ़िगरेशन को बेहतर बनाया जा सकता है. इसके लिए, TargetServer कॉन्फ़िगरेशन में तय किए गए बैकएंड सेवा के यूआरएल को लगातार पोल किया जाता है. परफ़ॉर्मेंस पर नज़र रखने की सुविधा चालू होने पर, टारगेटसर्वर के काम न करने पर उसे अपने-आप रोटेशन में वापस डाल दिया जाता है. ऐसा तब होता है, जब HealthMonitor यह तय करता है कि TargetServer चालू है.

सेहत की निगरानी करने की सुविधा, <MaxFailures> के साथ काम करती है. स्वास्थ्य की निगरानी की सुविधा चालू न होने पर, <MaxFailures> से पता चलता है कि एपीआई प्रॉक्सी से TargetServer को भेजे गए कितने अनुरोध पूरे नहीं हो सके. इसकी वजह से, अनुरोध को किसी दूसरे TargetServer पर रीडायरेक्ट किया गया. इसके बाद, गड़बड़ी करने वाले TargetServer को रोटेशन से हटा दिया जाता है. ऐसा तब तक होता है, जब तक कि प्रॉक्सी को फिर से डिप्लॉय नहीं किया जाता.

सेहत की निगरानी की सुविधा चालू होने पर, काम न करने वाले TargetServer को अपने-आप रोटेशन में वापस डाल दिया जाता है. इसके लिए, किसी प्रॉक्सी को फिर से डिप्लॉय करने की ज़रूरत नहीं होती.

HealthMonitor, एक सामान्य क्लाइंट के तौर पर काम करता है. यह टीसीपी या एचटीटीपी पर बैकएंड सेवा शुरू करता है:

• टीसीपी क्लाइंट सिर्फ़ यह पक्का करता है कि सॉकेट खोला जा सकता है.
• एचटीटीपी क्लाइंट को कॉन्फ़िगर करके, बैकएंड सेवा को मान्य एचटीटीपी अनुरोध सबमिट किया जाता है. एचटीटीपी GET, PUT, POST या DELETE ऑपरेशनों को तय किया जा सकता है. एचटीटीपी मॉनिटर कॉल का जवाब, <SuccessResponse> ब्लॉक में कॉन्फ़िगर की गई सेटिंग से मेल खाना चाहिए.

सफलताएं और असफलताएं

परफ़ॉर्मेंस पर नज़र रखने की सुविधा चालू करने पर, Edge आपके टारगेट सर्वर को परफ़ॉर्मेंस की जांच भेजना शुरू कर देता है. हेल्थ चेक, टारगेट सर्वर को भेजा गया एक अनुरोध होता है. इससे यह पता चलता है कि टारगेट सर्वर सही तरीके से काम कर रहा है या नहीं.

परफ़ॉर्मेंस की जांच के नतीजे, इनमें से कोई एक हो सकता है:

• सफल: टारगेट सर्वर को तब सही माना जाता है, जब हेल्थ चेक सफल हो जाता है. आम तौर पर, ऐसा इनमें से किसी एक या एक से ज़्यादा वजहों से होता है:
  • टारगेट सर्वर, तय किए गए पोर्ट पर नए कनेक्शन को स्वीकार करता है. साथ ही, उस पोर्ट पर किए गए अनुरोध का जवाब देता है. इसके बाद, तय की गई समयावधि के अंदर पोर्ट को बंद कर देता है. टारगेट सर्वर से मिले जवाब में “Connection: close” शामिल है
  • टारगेट सर्वर, हेल्थ चेक के अनुरोध का जवाब 200 (OK) या किसी अन्य एचटीटीपी स्टेटस कोड के साथ देता है. यह कोड, आपकी ज़रूरत के हिसाब से होना चाहिए.
  • टारगेट सर्वर, हेल्थ चेक के अनुरोध का जवाब ऐसे मैसेज के मुख्य हिस्से के साथ देता है जो अनुमानित मैसेज के मुख्य हिस्से से मेल खाती है.

  जब Edge को पता चलता है कि कोई सर्वर ठीक से काम कर रहा है, तो Edge उस सर्वर को अनुरोध भेजना जारी रखता है या फिर से शुरू कर देता है.

• फ़ेल: टारगेट सर्वर, अलग-अलग तरीकों से हेल्थ चेक में फ़ेल हो सकता है. यह इस बात पर निर्भर करता है कि किस तरह का चेक किया जा रहा है. टारगेट सर्वर में गड़बड़ी तब लॉग की जा सकती है, जब:
  • यह कुकी, Edge को हेल्थ चेक पोर्ट से कनेक्ट करने की अनुमति नहीं देती.
  • तय समयसीमा में, हेल्थ चेक के अनुरोध का जवाब नहीं देता है.
  • अनचाहा एचटीटीपी स्टेटस कोड दिखाता है.
  • जवाब में ऐसा मैसेज शामिल होता है जिसका मुख्य हिस्सा अनुमानित मैसेज के मुख्य हिस्से से मेल नहीं खाता.

  जब कोई टारगेट सर्वर, हेल्थ चेक में फ़ेल हो जाता है, तो Edge उस सर्वर के फ़ेल होने की संख्या बढ़ा देता है. अगर किसी सर्वर के लिए, गड़बड़ियों की संख्या पहले से तय की गई थ्रेशोल्ड (<MaxFailures>) के बराबर या उससे ज़्यादा हो जाती है, तो Edge उस सर्वर को अनुरोध भेजना बंद कर देता है.

HealthMonitor को चालू करना

HealthMonitor बनाने के लिए, प्रॉक्सी के TargetEndpoint के HTTPConnection कॉन्फ़िगरेशन में <HealthMonitor> एलिमेंट जोड़ें. यूज़र इंटरफ़ेस (यूआई) में ऐसा नहीं किया जा सकता. इसके बजाय, प्रॉक्सी कॉन्फ़िगरेशन बनाएं और उसे Edge पर ZIP फ़ाइल के तौर पर अपलोड करें. प्रॉक्सी कॉन्फ़िगरेशन, एपीआई प्रॉक्सी के सभी पहलुओं का स्ट्रक्चर्ड ब्यौरा होता है. प्रॉक्सी कॉन्फ़िगरेशन में, पहले से तय किए गए डायरेक्ट्री स्ट्रक्चर में एक्सएमएल फ़ाइलें होती हैं. ज़्यादा जानकारी के लिए, एपीआई प्रॉक्सी कॉन्फ़िगरेशन रेफ़रंस देखें.

एक सामान्य HealthMonitor, IntervalInSec को TCPMonitor या HTTPMonitor के साथ जोड़कर बनाया जाता है. <MaxFailures> एलिमेंट से, एपीआई प्रॉक्सी से TargetServer को भेजे गए उन अनुरोधों की ज़्यादा से ज़्यादा संख्या तय होती है जो पूरे नहीं हो पाते. इससे अनुरोध को किसी दूसरे TargetServer पर रीडायरेक्ट किया जाता है. डिफ़ॉल्ट रूप से <MaxFailures> की वैल्यू 0 होती है. इसका मतलब है कि Edge, कोई सुधार करने के लिए कार्रवाई नहीं करता. हेल्थ मॉनिटर कॉन्फ़िगर करते समय, पक्का करें कि आपने <TargetEndpoint> टैग के <HTTPTargetConnection> टैग में <MaxFailures> को शून्य के अलावा किसी अन्य वैल्यू पर सेट किया हो.

TCPMonitor

नीचे दिए गए कॉन्फ़िगरेशन में, एक HealthMonitor के बारे में बताया गया है. यह हर पांच सेकंड में पोर्ट 80 पर कनेक्शन खोलकर, हर TargetServer को पोल करता है. (पोर्ट ज़रूरी नहीं है. अगर यह जानकारी नहीं दी जाती है, तो TCPMonitor पोर्ट, TargetServer पोर्ट होता है.)

• अगर कनेक्शन नहीं हो पाता है या कनेक्ट होने में 10 सेकंड से ज़्यादा समय लगता है, तो उस TargetServer के लिए कनेक्शन नहीं हो पाने की संख्या में 1 की बढ़ोतरी हो जाती है.
• कनेक्ट हो जाने पर, TargetServer के लिए कनेक्शन फ़ेल होने की संख्या 0 पर रीसेट हो जाती है.

नीचे दिए गए उदाहरण में, TargetEndpoint के HTTPTargetConnetion एलिमेंट के चाइल्ड एलिमेंट के तौर पर HealthMonitor को जोड़ा गया है:

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

TCPMonitor कॉन्फ़िगरेशन एलिमेंट के साथ HealthMonitor

यहां दी गई टेबल में, TCPMonitor कॉन्फ़िगरेशन एलिमेंट के बारे में बताया गया है:

HTTPMonitor

एचटीटीपी मॉनिटर का इस्तेमाल करने वाला HealthMonitor का एक सैंपल, हर पांच सेकंड में बैकएंड सेवा को जीईटी अनुरोध सबमिट करेगा. यहां दिए गए सैंपल में, अनुरोध के मैसेज में एचटीटीपी बेसिक ऑथराइज़ेशन हेडर जोड़ा गया है. रिस्पॉन्स कॉन्फ़िगरेशन में ऐसी सेटिंग तय की जाती हैं जिनकी तुलना, बैकएंड सेवा से मिले असल रिस्पॉन्स से की जाएगी. नीचे दिए गए उदाहरण में, उम्मीद के मुताबिक रिस्पॉन्स, एचटीटीपी रिस्पॉन्स कोड 200 और कस्टम एचटीटीपी हेडर ImOK है. इसकी वैल्यू YourOK है. अगर जवाब मैच नहीं होता है, तो लोड बैलेंसर कॉन्फ़िगरेशन, अनुरोध को फ़ेल के तौर पर मार्क करेगा.

HTTPMonitor, एचटीटीपी और एकतरफ़ा एचटीटीपीएस प्रोटोकॉल का इस्तेमाल करने के लिए कॉन्फ़िगर की गई बैकएंड सेवाओं के साथ काम करता है. हालांकि, यह सुविधा इन मामलों में काम नहीं करती:

• दोनों तरफ़ से एचटीटीपीएस (इसे दोनों तरफ़ से टीएलएस/एसएसएल भी कहा जाता है)
• खुद हस्ताक्षर किए हुए सर्टिफ़िकेट.

ध्यान दें कि एचटीटीपी मॉनिटर में अनुरोध और जवाब की सभी सेटिंग, उस बैकएंड सेवा के लिए खास होंगी जिसे शुरू करना है.

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

HTTPMonitor कॉन्फ़िगरेशन एलिमेंट के साथ HealthMonitor

यहां दी गई टेबल में, HTTPMonitor कॉन्फ़िगरेशन एलिमेंट के बारे में बताया गया है: