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

Apigee Edge का दस्तावेज़ देखा जा रहा है.
Apigee X के दस्तावेज़ पर जाएं. info

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 की सीमा तय की गई है. इस बारे में, सीमाएं विषय में बताया गया है.

TargetEndpoint को कॉन्फ़िगर करना, ताकि TargetServers के बीच लोड बैलेंस किया जा सके

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

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

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

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

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

सेहत की निगरानी करने की सुविधा, <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 के लिए कनेक्शन नहीं हो पाने की संख्या में एक की बढ़ोतरी हो जाती है.
• कनेक्ट हो जाने पर, 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

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 कॉन्फ़िगरेशन एलिमेंट के बारे में बताया गया है: