19.03.01 - सार्वजनिक क्लाउड के रिलीज़ नोट के लिए Apigee Edge

लोड बैलेंसिंग - काम न करने वाले सर्वर को हटाने के लिए ज़्यादा कंट्रोल

एपीआई प्रॉक्सी के लिए लोड बैलेंसर को कॉन्फ़िगर करते समय, यह तय किया जा सकता है कि लोड बैलेंसिंग रोटेशन से किसी सर्वर को हटाने से पहले, कितनी बार जवाब नहीं मिला. जवाब न मिलने का मतलब है कि Apigee को टारगेट सर्वर से कोई जवाब नहीं मिला. ऐसा होने पर, गड़बड़ी काउंटर एक से बढ़ जाता है. जब Apigee को टारगेट से कोई जवाब मिलता है, तब उसे टारगेट सर्वर से मिला जवाब माना जाता है. भले ही, वह जवाब एचटीटीपी गड़बड़ी (जैसे कि 500) वाला हो. साथ ही, गड़बड़ी काउंटर रीसेट हो जाता है. यह पक्का करने के लिए कि खराब एचटीटीपी रिस्पॉन्स (जैसे कि 500) से भी गड़बड़ी का काउंटर बढ़ जाए, ताकि खराब सर्वर को लोड बैलेंसिंग रोटेशन से जल्द से जल्द हटाया जा सके, अपने लोड बैलेंसर कॉन्फ़िगरेशन में <ResponseCode> चाइल्ड एलिमेंट के साथ एक नया <ServerUnhealthyResponse> एलिमेंट जोड़ा जा सकता है. Edge, उन कोड वाले जवाबों को भी गड़बड़ी के तौर पर गिनेगा.

<HTTPTargetConnection>
  <LoadBalancer>
    <Algorithm>RoundRobin</Algorithm>
    <Server name="target1" />
    <Server name="target2" />
    <ServerUnhealthyResponse>
        <ResponseCode>500</ResponseCode>
        <ResponseCode>502</ResponseCode>
        <ResponseCode>503</ResponseCode>
    </ServerUnhealthyResponse>
    <MaxFailures>5</MaxFailures>
  </LoadBalancer>
</HTTPTargetConnection>
  
  

AccessControl नीति में किए गए सुधार

AccessControl नीति यह तय करती है कि कौनसे आईपी पते, एपीआई प्रॉक्सी को कॉल कर सकते हैं. नीति में जोड़े गए नए एलिमेंट की मदद से, एपीआई डेवलपर को यह तय करने का ज़्यादा कंट्रोल मिलता है कि किन आईपी पतों का आकलन करना है.

<IgnoreTrueClientIPHeader>: ज़रूरी नहीं (डिफ़ॉल्ट वैल्यू false है). इस नीति को 'सही है' पर सेट करने पर, यह True-Client-IP हेडर को अनदेखा करती है. साथ ही, X-Forwarded-For हेडर में मौजूद आईपी पतों का आकलन करती है. इसके लिए, यह X-Forwarded-For के आकलन के तरीके का इस्तेमाल करती है, जिसे आपने कॉन्फ़िगर किया है.

<AccessControl async="false" continueOnError="false"
    enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

ज़्यादा जानकारी के लिए, यह कम्यूनिटी पोस्ट देखें.

FaultRules को ज़्यादा बेहतर तरीके से हैंडल करने के लिए, RaiseFault नीति में दो नए एलिमेंट उपलब्ध हैं.

• ShortFaultReason एक बूलियन है. इसे 'सही है' पर सेट करने पर, नीति का नाम fault.reason वैरिएबल में डाल दिया जाता है.
• AssignVariable, FaultResponse में उपलब्ध होता है. इसकी मदद से, गड़बड़ी की जानकारी देने वाले रिस्पॉन्स को किसी वैरिएबल को असाइन किया जा सकता है. इससे एपीआई प्रॉक्सी फ़्लो में मौजूद अन्य नीतियां, उस वैरिएबल का इस्तेमाल कर सकती हैं.

अब होस्ट किए गए टारगेट के लिए सीमाएं लागू की जा रही हैं. सीमाओं के बारे में ज़्यादा जानकारी के लिए, सीमाएं देखें.

अब मैसेज टेंप्लेट वैरिएबल का इस्तेमाल करके, AccessControl नीति पर आईपी पते और सीआईडीआर मास्क सेट किए जा सकते हैं. उदाहरण के लिए, अगर आपको किसी आईपी पते को स्टोर करना है और उसे की वैल्यू मैप (केवीएम) में मास्क करना है, तो एपीआई प्रॉक्सी फ़्लो में सेट किए गए किसी वैरिएबल से उन वैल्यू को वापस पाया जा सकता है. इससे, नीति के कॉन्फ़िगरेशन में बदलाव किए बिना, रनटाइम में आईपी वैल्यू को आसानी से बदला जा सकता है.

उदाहरण के लिए, इसके बजाय:

<MatchRule action="DENY">
    <SourceAddress mask="24">198.51.100.1</SourceAddress>
</MatchRule>
     

नीति को इस तरह कॉन्फ़िगर किया जा सकता है. मान लें कि वैल्यू को केवीएम में सेव किया गया है. साथ ही, वैल्यू को वापस पाने और उन्हें यहां दिखाए गए वैरिएबल को असाइन करने के लिए, KeyValueMapOperations नीति का इस्तेमाल किया जाता है:

<MatchRule action="DENY">
    <SourceAddress mask="{kvm.mask.ref}">{kvm.ip.ref}</SourceAddress>
</MatchRule>
     

एपीआई मॉनिटरिंग में दो भूमिकाएं होती हैं: एपीआई मॉनिटरिंग एडमिन और एपीआई मॉनिटरिंग उपयोगकर्ता. इनके बारे में एपीआई मॉनिटरिंग ऐक्सेस करना लेख में बताया गया है. ये सुविधाएं दिसंबर 2018 में उपलब्ध कराई गई थीं.

Edge अब हर अनुरोध में X-Apigee.Message-Timeout हेडर जोड़ता है. इस हेडर का इस्तेमाल Edge सिर्फ़ अंदरूनी तौर पर करता है. अपनी एपीआई प्रॉक्सी में X-Apigee.* हेडर में मौजूद वैल्यू पर भरोसा न करें. ऐसा इसलिए, क्योंकि ये हेडर ग्राहकों के इस्तेमाल के लिए नहीं हैं. साथ ही, Apigee इन्हें कभी भी हटा सकता है या बदल सकता है.

कीस्टोर मिटाने से जुड़ी गड़बड़ियों को ठीक करें, ताकि एपीआई कॉल पूरा हो सके

x-apigee.edge.execution.sense.action हमेशा null पर सेट होता है

In ResponseCache policy, NIOTheread is executing without rejection from the thread pool

Apigee राऊटर पर कई लॉग एक्सपोर्टर की वजह से, सीपीयू का इस्तेमाल ज़्यादा होता है

कुछ संगठनों में, समय-समय पर 404 गड़बड़ियां दिखना

शेयर किए गए डिप्लॉय किए गए फ़्लो, कुछ मैसेज प्रोसेसर पर काम नहीं कर रहे हैं

इस समस्या को ठीक करने वाला अपडेट, Edge for Private Cloud के अगले वर्शन में शामिल किया जाएगा.

इस समस्या को ठीक करने वाला अपडेट, Edge for Private Cloud की अगली रिलीज़ में शामिल किया जाएगा.

इस समस्या को ठीक करने वाला अपडेट, Edge for Private Cloud की अगली रिलीज़ में शामिल किया जाएगा.