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>
     

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

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

API Monitoring में दो भूमिकाएं होती हैं: API Monitoring एडमिन और API Monitoring उपयोगकर्ता. इनके बारे में API Monitoring को ऐक्सेस करना लेख में बताया गया है. ये दिसंबर 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 की अगली रिलीज़ में शामिल किया जाएगा.