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

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

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

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

TargetServer की परिभाषा में एक नाम, होस्ट, और पोर्ट शामिल है. साथ ही, इसमें एक अतिरिक्त एलिमेंट भी होता है, जो बताता है कि TargetServer चालू है या बंद है.

वीडियो

टारगेट सर्वर का इस्तेमाल करके, एपीआई रूटिंग और लोड बैलेंसिंग के बारे में ज़्यादा जानने के लिए, ये वीडियो देखें

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

टारगेट सर्वर कॉन्फ़िगरेशन का सैंपल

यह कोड, टारगेट सर्वर के बारे में बताता है:

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

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

नीचे दी गई टेबल में, TargetServer बनाने और उसे कॉन्फ़िगर करने के लिए इस्तेमाल किए जाने वाले एलिमेंट के बारे में बताया गया है:

नाम	ब्यौरा	डिफ़ॉल्ट	ज़रूरी है?
name	TargetServer कॉन्फ़िगरेशन का नाम, जो एनवायरमेंट में यूनीक होना चाहिए. TargetServer के नाम में सिर्फ़ अक्षर और अंक हो सकते हैं.	लागू नहीं	हां
Host	बैकएंड सेवा का होस्ट यूआरएल (प्रोटोकॉल के बिना).	लागू नहीं	हां
Port	वह पोर्ट जिस पर बैकएंड सेवा सुन रही है	लागू नहीं	हां
IsEnabled	एक बूलियन, जिससे पता चलता है कि TargetServer कॉन्फ़िगरेशन चालू है या बंद. यह आपको एपीआई प्रॉक्सी कॉन्फ़िगरेशन में बदलाव किए बिना, TargetServers के रोटेशन से बाहर ले जाने की सुविधा देता है. आम तौर पर, ऐसा ऐप्लिकेशन या स्क्रिप्ट लिखना होता है जो अनुमानित क्षमता की ज़रूरतों, रखरखाव के शेड्यूल वगैरह के आधार पर, टारगेट सर्वर को अपने-आप चालू या बंद करता है.	true	हां

यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके टारगेट सर्वर मैनेज करना

नीचे बताए गए तरीके के मुताबिक टारगेट सर्वर मैनेज करें..

एपीआई का इस्तेमाल करके टारगेट सर्वर मैनेज करना

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

हर एनवायरमेंट के लिए ज़्यादा से ज़्यादा 500 TargetServers हो सकते हैं, जैसा कि सीमाएं विषय में बताया गया है.

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

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

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

वेटेड

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

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

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

MaxFailares की डिफ़ॉल्ट वैल्यू 0 है. इसका मतलब है कि Edge हमेशा हर अनुरोध के लिए टारगेट से कनेक्ट करने की कोशिश करता है और टारगेट सर्वर को रोटेशन से कभी कनेक्ट नहीं करता है.

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

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

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

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

पाथ

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

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

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

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

अगर बैकएंड सेवा तय करने के लिए 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>

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

<Ciphers> और <ClientAuthEnabled> जैसी <SSLInfo> प्रॉपर्टी की जानकारी के लिए, निजी क्लाउड के लिए, TLS को एपीआई का ऐक्सेस कॉन्फ़िगर करना पर जाकर, वर्चुअल होस्ट के लिए इन प्रॉपर्टी को सेट करने से जुड़ी जानकारी देखें.

आउटबाउंड TLS/एसएसएल को कॉन्फ़िगर करने से जुड़े सभी निर्देशों के लिए, एज से बैकएंड (क्लाउड और निजी क्लाउड) में TLS को कॉन्फ़िगर करना देखें.

TargetServer स्कीमा

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

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

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

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

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

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

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

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

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

स्वास्थ्य जांच के इन दो संभावित नतीजों में से एक हो सकता है:

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

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

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

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

HealthMonitor की सुविधा चालू करना

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

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

TCPMonitor

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

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

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

नाम	ब्यौरा	डिफ़ॉल्ट	ज़रूरी है?
IsEnabled	एक बूलियन जो HealthMonitor को चालू या बंद करता है.	false	नहीं
IntervalInSec	हर पोलिंग टीसीपी अनुरोध के बीच का समय, सेकंड में.	0	हां
ConnectTimeoutInSec	वह समय जब टीसीपी पोर्ट से कनेक्शन स्थापित किया जाना चाहिए. तय इंटरवल में कनेक्ट न कर पाने पर, इसे गड़बड़ी के तौर पर गिना जाता है. इससे TargetServer के लिए लोड बैलेंसर फ़ेलियर की संख्या बढ़ जाती है.	0	हां
Port	ज़रूरी नहीं. वह पोर्ट जिस पर टीसीपी कनेक्शन बनाया जाएगा. अगर इसके बारे में नहीं बताया गया है, तो टीसीपी मॉनिटर पोर्ट, TargetServer पोर्ट है.	0	नहीं

HTTPMonitor

HealthMonitor का एक सैंपल, जो HTTPMonitor का इस्तेमाल करता है, हर पांच सेकंड में एक बार बैकएंड सेवा को GET अनुरोध सबमिट करता है. नीचे दिए गए सैंपल में, अनुरोध वाले मैसेज में एचटीटीपी बेसिक ऑथराइज़ेशन हेडर जोड़ा गया है. रिस्पॉन्स कॉन्फ़िगरेशन, ऐसी सेटिंग तय करता है जिनकी तुलना बैकएंड सेवा से मिलने वाले असल रिस्पॉन्स से की जाती है. नीचे दिए गए उदाहरण में, अनुमानित रिस्पॉन्स एक एचटीटीपी रिस्पॉन्स कोड 200 और एक कस्टम एचटीटीपी हेडर 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 कॉन्फ़िगरेशन एलिमेंट के बारे में बताया गया है:

नाम	ब्यौरा	डिफ़ॉल्ट	ज़रूरी है?
IsEnabled	एक बूलियन जो HealthMonitor को चालू या बंद करता है.	false	नहीं
IntervalInSec	हर पोलिंग अनुरोध के बीच का समय, सेकंड में.	0	हां
Request	HealthMonitor से भेजे गए आउटबाउंड अनुरोध के मैसेज के लिए, कॉन्फ़िगरेशन के विकल्प. इन्हें रोटेशन में, TargetServers को भेजा जाता है. पाथ, वैरिएबल के साथ काम नहीं करता.	लागू नहीं	हां
IsSSL	इससे पता चलता है कि कनेक्शन को मॉनिटर करने के लिए, एचटीटीपीएस (सुरक्षित एचटीटीपी) का इस्तेमाल करना है या नहीं. संभावित वैल्यू: true: एचटीटीपी का इस्तेमाल किया जाता है. false: एचटीटीपी का इस्तेमाल किया गया है. तय नहीं किया गया है: टारगेट सर्वर कॉन्फ़िगरेशन का इस्तेमाल करता है.	false	नहीं
ConnectTimeoutInSec	समय (सेकंड में). यह ज़रूरी है कि एचटीटीपी सेवा से जुड़े टीसीपी कनेक्शन को कामयाब माना जाए. तय किए गए इंटरवल में कनेक्ट न हो पाने पर, इसे गड़बड़ी के तौर पर गिना जाता है. इससे TargetServer के लिए Load Balancer की गड़बड़ी की संख्या बढ़ जाती है.	0	नहीं
SocketReadTimeoutInSec	समय (सेकंड में), जिसमें एचटीटीपी सेवा से डेटा को पढ़ा जाना ज़रूरी है. दिए गए इंटरवल में पढ़ने में गड़बड़ी को, गड़बड़ी के तौर पर गिना जाता है. इस वजह से, TargetServer के लिए Load Balancer की गड़बड़ी की संख्या बढ़ जाती है.	0	नहीं
Port	वह पोर्ट जिस पर बैकएंड सेवा के साथ एचटीटीपी कनेक्शन बनाया जाएगा.	लागू नहीं	नहीं
Verb	बैकएंड सेवा से किए गए हर पोलिंग एचटीटीपी अनुरोध के लिए, एचटीटीपी क्रिया का इस्तेमाल किया जाता है .	लागू नहीं	नहीं
Path	टारगेट सर्वर में तय किए गए यूआरएल से जुड़ा पाथ. अपनी एचटीटीपी सेवा पर 'पोलिंग एंडपॉइंट' कॉन्फ़िगर करने के लिए, पाथ एलिमेंट का इस्तेमाल करें.	लागू नहीं	नहीं
IncludeHealthCheckIdHeader	इसकी मदद से, अपस्ट्रीम सिस्टम पर सेहत की जांच के अनुरोधों को ट्रैक किया जा सकता है. इसमें IncludeHealthCheckIdHeader बूलियन वैल्यू लेता है और डिफ़ॉल्ट तौर पर false पर सेट होता है. अगर इसे true पर सेट किया जाता है, तो X-Apigee-Healthcheck-Id नाम का एक Header होगा, जिसे हेल्थ चेक अनुरोध में इंजेक्ट किया जाता है. हेडर की वैल्यू डाइनैमिक रूप से असाइन की जाती है और ORG/ENV/SERVER_UUID/N फ़ॉर्मैट में होती है. इसमें ORG संगठन का नाम, ENV एनवायरमेंट का नाम, SERVER_UUID एक यूनीक आईडी है, जो एमपी की पहचान करता है. साथ ही, N 1 जनवरी, 1970 से अब तक बीत चुके मिलीसेकंड की संख्या है. अनुरोध के हेडर का उदाहरण: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123	false	नहीं
Payload	हर पोलिंग एचटीटीपी अनुरोध के लिए जनरेट किया गया एचटीटीपी का मुख्य हिस्सा. ध्यान दें कि जीईटी अनुरोधों के लिए यह एलिमेंट ज़रूरी नहीं है.	लागू नहीं	नहीं
SuccessResponse	पोल की गई बैकएंड सेवा से जनरेट किए गए इनबाउंड एचटीटीपी रिस्पॉन्स मैसेज के लिए, मिलते-जुलते विकल्प. अगर कोई जवाब मेल नहीं खाता है, तो गड़बड़ी की संख्या को एक से बढ़ा दिया जाता है.	लागू नहीं	नहीं
ResponseCode	एचटीटीपी रिस्पॉन्स कोड, पोल किए गए TargetServer से मिलना चाहिए. कोड से अलग कोड होने पर, गड़बड़ी हो जाती है और पोल की गई बैकएंड सेवा के लिए संख्या बढ़ जाती है. आपके पास एक से ज़्यादा ResponseCode एलिमेंट तय करने का विकल्प होता है.	लागू नहीं	नहीं
Headers	पोल की गई बैकएंड सेवा से मिलने वाले एक या उससे ज़्यादा एचटीटीपी हेडर और वैल्यू की सूची. किसी एचटीटीपी हेडर या रिस्पॉन्स पर मौजूद वैल्यू से अलग होने पर, गड़बड़ी हो जाती है. साथ ही, पोल किए गए TargetServer की संख्या एक बढ़ जाती है. आपके पास हेडर के एक से ज़्यादा एलिमेंट तय करने का विकल्प होता है.	लागू नहीं	नहीं