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

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

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

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

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

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

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

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

वेटेड

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

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

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

<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) भी गड़बड़ी के काउंटर को बढ़ाएं, ताकि खराब सर्वर को लोड बैलेंसिंग रोटेशन से जल्द से जल्द हटाया जा सके, अपने लोड बैलेंसर कॉन्फ़िगरेशन में <ResponseCode> चाइल्ड एलिमेंट के साथ <ServerUnhealthyResponse> एलिमेंट जोड़ा जा सकता है. 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 को कॉन्फ़िगर किया है, तो टारगेट के तय किए गए समय तक काम न करने पर, TargetServer को रोटेशन से हटा दिया जाता है. जब कोई 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 की परिभाषा में TLS/SSL चालू करना होगा. ऐसा करना ज़रूरी है, क्योंकि <Host> टैग की मदद से, कनेक्शन प्रोटोकॉल की जानकारी नहीं दी जा सकती. यहां एकतरफ़ा TLS/एसएसएल के लिए TargetServer की परिभाषा दी गई है. इसमें Edge, बैकएंड सेवा के लिए एचटीटीपीएस अनुरोध करता है:

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

अगर बैकएंड सेवा के लिए, दोतरफ़ा या म्यूच्यूअल टीएलएस/एसएसएल की ज़रूरत है, तो TargetEndpoints की तरह ही टीएलएस/एसएसएल कॉन्फ़िगरेशन सेटिंग का इस्तेमाल करके, TargetServer को कॉन्फ़िगर करें:

<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 ऐक्सेस को कॉन्फ़िगर करना पर जाकर, वर्चुअल होस्ट के लिए उन प्रॉपर्टी को सेट करने के बारे में जानकारी देखें.

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

TargetServer स्कीमा

TargetServer और अन्य इकाइयों के स्कीमा के बारे में जानने के लिए, GitHub पर जाएं.

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

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

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

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

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

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

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

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

परफ़ॉर्मेंस की जांच के दो संभावित नतीजे हो सकते हैं:

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

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

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

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

HealthMonitor चालू करना

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

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

TCPMonitor

नीचे दिए गए कॉन्फ़िगरेशन में, एक हेल्थ मॉनिटर की जानकारी दी गई है. यह हर पांच सेकंड में पोर्ट 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

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

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

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

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

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