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

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

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

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

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

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

किसी 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. वेटेड लोड बैलेंसर, आपके TargetServers को सीधे तौर पर अनुरोध बांटता है हर 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>

इस उदाहरण में, को भेजे जाने वाले हर एक अनुरोध के लिए दो अनुरोध target2 को रूट किए जाएंगे टारगेट 1.

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

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

यहां दिए गए उदाहरण में, पांच बजे के बाद 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>

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

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

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

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

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

डिफ़ॉल्ट रूप से, <RetryEnabled>, true पर सेट होता है. फिर से कोशिश करने की सुविधा को बंद करने के लिए, इसे false पर सेट करें. उदाहरण के लिए:

<RetryEnabled>false</RetryEnabled>

IsFallback

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

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

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

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

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

TargetServer स्कीमा

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HealthMonitor चालू करना

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

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

TCPMonitor

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

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

आपके पास TargetEndpoint के एचटीटीपीTargetConnetion के चाइल्ड एलिमेंट के तौर पर 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 का इस्तेमाल

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

HTTPMonitor

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

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

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

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

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