एंटीपैटर्न: एक टारगेट सर्वर के साथ लोड बैलेंस को ज़ीरो वैल्यू पर सेट करने के लिए, MaxFailures को सेट करें

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

TargetEndpoint का कॉन्फ़िगरेशन तय करता है कि Apigee Edge, बैकएंड सेवा या एपीआई से कैसे कनेक्ट होता है. यह बैकएंड सेवा को अनुरोध भेजता है और उससे जवाब पाता है. बैकएंड सेवा, एचटीटीपी/एचटीटीपीएस सर्वर, NodeJS या Hosted Target हो सकती है.

TargetEndpoint में, बैकएंड सेवा को इनमें से किसी एक तरीके से शुरू किया जा सकता है:

  • एचटीटीपी या एचटीटीपीएस सर्वर का डायरेक्ट यूआरएल
  • Edge पर होस्ट की गई Node.js स्क्रिप्ट के लिए, ScriptTarget
  • Hosted Target एनवायरमेंट पर डिप्लॉय किए गए NodeJS के लिए, HostedTarget
  • TargetServer का कॉन्फ़िगरेशन

इसी तरह, एपीआई प्रॉक्सी फ़्लो से किसी भी बाहरी सेवा को कॉल करने के लिए, Service Callout नीति का इस्तेमाल किया जा सकता है. इस नीति में, एचटीटीपी/एचटीटीपीएस टारगेट यूआरएल को सीधे नीति में या TargetServer के कॉन्फ़िगरेशन का इस्तेमाल करके तय किया जा सकता है.

TargetServer का कॉन्फ़िगरेशन

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

यहां TargetServer के कॉन्फ़िगरेशन का एक उदाहरण दिया गया है:

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

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

यहां TargetServer का इस्तेमाल करके, TargetEndpoint के कॉन्फ़िगरेशन का एक उदाहरण दिया गया है:

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

MaxFailures

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

MaxFailures के साथ कॉन्फ़िगरेशन का एक उदाहरण:

<TargetEndpoint name="default">
    <HTTPTargetConnection>
      <LoadBalancer>
        <Server name="target1"/>
       <Server name="target2"/>
       <MaxFailures>5</MaxFailures>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

ऊपर दिए गए उदाहरण में, अगर "target1" के लिए लगातार पांच अनुरोध फ़ेल हो जाते हैं, तो "target1" को रोटेशन से हटा दिया जाएगा. इसके बाद, सभी अनुरोध सिर्फ़ target2 को भेजे जाएंगे.

ऐंटीपैटर्न

TargetEndpoint या Service Callout नीति के LoadBalancer कॉन्फ़िगरेशन में, सिर्फ़ एक TargetServer का इस्तेमाल करने की सलाह नहीं दी जाती. ऐसा तब किया जाता है, जब MaxFailures की वैल्यू शून्य के अलावा कोई और वैल्यू सेट की गई हो. ऐसा इसलिए, क्योंकि इससे समस्याएं आ सकती हैं.

यहां कॉन्फ़िगरेशन का एक उदाहरण दिया गया है, जिसमें "target1" नाम का सिर्फ़ एक TargetServer है. साथ ही, MaxFailures की वैल्यू 5 (शून्य के अलावा कोई और वैल्यू) सेट की गई है: 

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
  </HTTPTargetConnection>

अगर TargetServer "target1" को भेजे गए अनुरोध पांच बार फ़ेल हो जाते हैं (MaxFailures में तय की गई संख्या), तो TargetServer को रोटेशन से हटा दिया जाता है. फ़ेलओवर के लिए कोई अन्य TargetServer न होने की वजह से, इस कॉन्फ़िगरेशन वाले एपीआई प्रॉक्सी को भेजे गए सभी अनुरोध, 503 Service Unavailable गड़बड़ी के साथ फ़ेल हो जाएंगे.

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

अगर Service Callout नीति में भी यही कॉन्फ़िगरेशन इस्तेमाल किया जाता है, तो TargetServer "target1" को भेजे गए अनुरोध पांच बार फ़ेल होने के बाद, एपीआई अनुरोधों में 500 गड़बड़ी दिखेगी.

असर

TargetEndpoint या Service Callout नीति के LoadBalancer कॉन्फ़िगरेशन में, सिर्फ़ एक TargetServer का इस्तेमाल करने पर, MaxFailures की वैल्यू शून्य के अलावा कोई और वैल्यू सेट करने पर, ये समस्याएं होती हैं:

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

सबसे सही तरीका

  1. ज़्यादा उपलब्धता के लिए, LoadBalancer के कॉन्फ़िगरेशन में एक से ज़्यादा TargetServer का इस्तेमाल करें.

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

    यह पक्का करने के लिए कि हेल्थ चेक उसी पोर्ट नंबर पर किया जाए जिसका इस्तेमाल Edge, टारगेट सर्वर से कनेक्ट करने के लिए करता है, Apigee का सुझाव है कि आप <Port> चाइल्ड एलिमेंट को <TCPMonitor> के तहत छोड़ दें. ऐसा तब करें, जब यह TargetServer के पोर्ट से अलग न हो. डिफ़ॉल्ट रूप से, <Port> वही होता है जो TargetServer का पोर्ट होता है.

    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>
      </TCPMonitor>
    </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>

  3. अगर कोई ऐसी पाबंदी है कि सिर्फ़ एक TargetServer का इस्तेमाल किया जा सकता है और HealthMonitor का इस्तेमाल नहीं किया जाता है, तो LoadBalancer के कॉन्फ़िगरेशन में MaxFailures तय न करें.

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

इस बारे में और पढ़ें