Apigee की आम समस्याएं

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

यहां दिए गए सेक्शन में, Apigee से जुड़ी समस्याओं के बारे में बताया गया है. ज़्यादातर मामलों में, सूची में दी गई समस्याओं को आने वाले समय में रिलीज़ होने वाले वर्शन में ठीक कर दिया जाएगा.

Miscellaneous Edge known issues

The following sections describe miscellaneous known issues with Edge.

Area/Summary Known issues
Cache expire results in incorrect cachehit value

When the cachehit flow variable is used after the LookupCache policy, due to the way debug points are dispatched for asynchronous behavior, the LookupPolicy populates the DebugInfo object before the call back has executed, resulting in an error.

Workaround: Repeat the process (make second call) again right after the first call.

Setting InvalidateCache Policy PurgeChildEntries to true does not work correctly

Setting PurgeChildEntries in the InvalidateCache policy should purge the KeyFragment element values only but clears the entire cache.

Workaround: Use the KeyValueMapOperations policy to iterate cache versioning and bypass the need for cache invalidation.

Concurrent deployment requests for a SharedFlow or API proxy can result in an inconsistent state in the Management Server where multiple revisions are shown as deployed.

This can happen, for example, when concurrent runs of a CI/CD deployment pipeline occur using different revisions. To avoid this problem, avoid deploying API proxies or SharedFlows before the current deployment is complete.

Workaround: Avoid concurrent API proxy or SharedFlow deployments.

API call counts shown in Edge API Analytics might contain duplicate data.

Edge API Analytics can sometimes contain duplicate data for API calls. In that case the counts shown for API calls in Edge API Analytics are higher than the comparable values shown in third-party analytics tools.

Workaround: Export the analytics data and use the gateway_flow_id field to de-duplicate the data.

Known issues with the Edge UI

The following sections describe the known issues with the Edge UI.

Area Known issues
Can't access Edge SSO Zone Administration page from navigation bar after organization is mapped to an identity zone When you connect an organization to an identity zone, you can no longer access the Edge SSO Zone Administration page from the left navigation bar by selecting Admin > SSO. As a workaround, navigate to the page directly using the following URL: https://apigee.com/sso

इंटिग्रेट किए गए पोर्टल से जुड़ी समस्याएं

यहां दिए गए सेक्शन में, इंटिग्रेट किए गए पोर्टल से जुड़ी समस्याओं के बारे में बताया गया है.

क्षेत्र ज्ञात समस्याएं
SmartDocs
  • Apigee Edge, OpenAPI Specification 3.0 के साथ काम करता है. ऐसा तब होता है, जब आपके पोर्टल पर स्पेसिफ़िकेशन एडिटर का इस्तेमाल करके स्पेसिफ़िकेशन बनाए जाते हैं और SmartDocs का इस्तेमाल करके एपीआई पब्लिश किए जाते हैं. हालांकि, कुछ सुविधाओं के सबसेट अभी काम नहीं करते.

    उदाहरण के लिए, OpenAPI Specification 3.0 की ये सुविधाएं फ़िलहाल काम नहीं करतीं:

    • स्कीमा को जोड़ने और बढ़ाने के लिए allOf प्रॉपर्टी
    • रिमोट रेफ़रंस

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

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

  • पोर्टल में 'इस एपीआई को आज़माएं' सुविधा का इस्तेमाल करते समय, Accept हेडर को application/json पर सेट किया जाता है. भले ही, OpenAPI स्पेसिफ़िकेशन में consumes के लिए कोई भी वैल्यू सेट की गई हो.
  • 138438484: एक से ज़्यादा सर्वर इस्तेमाल नहीं किए जा सकते.
एसएएमएल आइडेंटिटी प्रोवाइडर कस्टम डोमेन के लिए, पहचान की सुविधा देने वाली SAML कंपनी की मदद से एक बार में लॉग आउट करने (एसएलओ) की सुविधा काम नहीं करती. एसएएमएल आइडेंटिटी प्रोवाइडर के साथ कस्टम डोमेन चालू करने के लिए, एसएएमएल सेटिंग कॉन्फ़िगर करते समय, साइन-आउट यूआरएल फ़ील्ड को खाली छोड़ें.
पोर्टल एडमिन
  • फ़िलहाल, एक से ज़्यादा उपयोगकर्ताओं के लिए, पोर्टल में एक साथ बदलाव करने की सुविधा उपलब्ध नहीं है. जैसे, पेज, थीम, सीएसएस या स्क्रिप्ट में बदलाव करना.
  • अगर पोर्टल से एपीआई रेफ़रंस दस्तावेज़ का पेज मिटाया जाता है, तो उसे फिर से बनाने का कोई तरीका नहीं है. इसके लिए, आपको एपीआई प्रॉडक्ट को मिटाकर फिर से जोड़ना होगा और एपीआई रेफ़रंस दस्तावेज़ को फिर से जनरेट करना होगा.
  • कॉन्टेंट की सुरक्षा से जुड़ी नीति को कॉन्फ़िगर करने पर, बदलावों को पूरी तरह लागू होने में 15 मिनट तक लग सकते हैं.
  • पोर्टल की थीम को पसंद के मुताबिक बनाने पर, बदलावों को पूरी तरह लागू होने में पांच मिनट लग सकते हैं.
पोर्टल की सुविधाएं
  • आने वाले समय में रिलीज़ होने वाले वर्शन में, Search को इंटिग्रेट किए गए पोर्टल में इंटिग्रेट किया जाएगा.

Edge for Private Cloud से जुड़ी समस्याएं

यहां दिए गए सेक्शन में, Edge for Private Cloud से जुड़ी समस्याओं के बारे में बताया गया है.

क्षेत्र ज्ञात समस्याएं
Edge for Private Cloud 4.52.02 और 4.53.00

SetOauthV2Info नीति का इस्तेमाल करने पर, अगर AccessToken को वैरिएबल में बदला नहीं जा सकता या वह शून्य है, तो नीति की वजह से डेटास्टोर में गड़बड़ी होती है:

{
              "fault": {
                "faultstring": "Error while accessing datastore;Please retry later",
                "detail": {
                  "errorcode": "datastore.ErrorWhileAccessingDataStore"
                }
              }
            }

यह व्यवहार, Apigee के पिछले वर्शन से अलग है. इस तरह की स्थिति में, "invalid_access_token" गड़बड़ी ट्रिगर होती थी:

{
              "fault": {
                "faultstring": "Invalid Access Token",
                "detail": {
                  "errorcode": "keymanagement.service.invalid_access_token"
                }
              }
            }

इस समस्या को कम करने के लिए, अपने प्रॉक्सी में RaiseFault नीति जोड़ें, ताकि गड़बड़ी के पुराने मैसेज को सिम्युलेट किया जा सके. RaiseFault नीति तब लागू की जा सकती है, जब ऐक्सेस टोकन वैरिएबल का कोई वैल्यू न हो. नीचे दिया गया उदाहरण देखें:

<!-- Sample Raise Fault Policy --->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" name="RaiseFault-MissingAccessToken">
    <DisplayName>RaiseFault-MissingAccessToken</DisplayName>
    <Properties/>
    <FaultResponse>
        <Set>
            <Headers/>
            <Payload contentType="application/json">{"fault":{"faultstring":"Invalid Access Token","detail":{"errorcode":"keymanagement.service.invalid_access_token"}}}</Payload>
            <StatusCode>500</StatusCode>
            <ReasonPhrase>Internal Server Error</ReasonPhrase>
        </Set>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

RaiseFault नीति को आपके प्रॉक्सी फ़्लो में, SetOauthV2Info नीति से पहले शर्त के साथ जोड़ा जा सकता है. इसका उदाहरण यहां दिया गया है:

<Step>
  <!-- Execute RaiseFault policy if access_token flow variable is null -->
  <Condition>access_token = null</Condition>
  <Name>RaiseFault-MissingAccessToken</Name>
</Step>
<Step>
  <!-- Execute SetOAuthV2Info policy if access_token flow variable is null -->
  <Condition>access_token != null</Condition>
  <Name>SetOAuthV2Info</Name>
</Step>

Apigee, Edge For Private Cloud के 4.52.02 और 4.53.00 वर्शन के लिए, ऊपर बताए गए व्यवहार को पहले जैसा करने के लिए एक पैच रिलीज़ करेगा.
Edge for Private Cloud 4.52.02 अपडेट

Edge for Private Cloud को 4.51.00, 4.52.00 या 4.52.01 से 4.52.02 पर अपडेट करने पर, रनटाइम और मैनेजमेंट एपीआई पर ज़्यादा असर पड़ सकता है.

यह असर, Cassandra नोड अपडेट होने के बाद होता है और तब तक रहता है, जब तक सभी मैसेज प्रोसेसर और मैनेजमेंट सर्वर नोड अपडेट नहीं हो जाते.

ऐसा होने पर, इनमें से किसी एक चीज़ पर असर पड़ सकता है:

  • रनटाइम एपीआई, OAuth टोकन को रीफ़्रेश कर रहे हैं
  • डेवलपर के ऐप्लिकेशन की सूची दिखाने वाले मैनेजमेंट एपीआई
  • प्रॉडक्ट की लिस्टिंग दिखाने वाले मैनेजमेंट एपीआई

Apigee, Edge for Private Cloud 4.52.02 के लिए अपडेट किया गया दस्तावेज़ पब्लिश करेगा. इसमें इस समस्या को हल करने के बारे में बताया गया है.
Edge for Private Cloud 4.52.01 Mint अपडेट

इस समस्या का असर सिर्फ़ उन लोगों पर पड़ता है जो MINT का इस्तेमाल कर रहे हैं या जिन्होंने निजी क्लाउड इंस्टॉलेशन के लिए Edge में MINT चालू किया है.

इस पर असर पड़ने वाला कॉम्पोनेंट: edge-message-processor

समस्या: अगर आपने कमाई करने की सुविधा चालू की है और 4.52.01 को नए सिरे से इंस्टॉल किया जा रहा है या Private Cloud के पिछले वर्शन से अपग्रेड किया जा रहा है, तो आपको मैसेज प्रोसेसर से जुड़ी समस्या का सामना करना पड़ेगा. ओपन थ्रेड की संख्या धीरे-धीरे बढ़ती जाएगी, जिससे संसाधनों की कमी हो जाएगी. edge-message-processor system.log में यह अपवाद दिखता है:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread
Apigee के एचटीटीपी/2 वर्शन में मौजूद जोखिम

हाल ही में, एचटीटीपी/2 प्रोटोकॉल (CVE-2023-44487) के कई लागू होने की वजह से, सेवा के अस्वीकार होने (डीओएस) की एक समस्या का पता चला है. इसमें, निजी क्लाउड के लिए Apigee Edge भी शामिल है. इस जोखिम की वजह से, Apigee API मैनेजमेंट की सुविधा को डीओएस (डिनायल ऑफ़ सर्विस) किया जा सकता है. ज़्यादा जानकारी के लिए, Apigee का सुरक्षा बुलेटिन GCP-2023-032 देखें.

Edge for Private Cloud के राऊटर और मैनेजमेंट सर्वर कॉम्पोनेंट, इंटरनेट से जुड़े होते हैं और इनमें संभावित तौर पर जोखिम हो सकता है. हालांकि, Edge for Private Cloud के अन्य Edge-specific कॉम्पोनेंट के मैनेजमेंट पोर्ट पर एचटीटीपी/2 चालू है, लेकिन उनमें से कोई भी कॉम्पोनेंट इंटरनेट से कनेक्ट नहीं होता. Cassandra, Zookeeper वगैरह जैसे नॉन-एज कॉम्पोनेंट पर, HTTP/2 चालू नहीं होता. हमारा सुझाव है कि आप Edge for Private Cloud की इस समस्या को ठीक करने के लिए, ये काम करें:

अगर Edge Private Cloud के 4.51.00.11 या उसके बाद के वर्शन का इस्तेमाल किया जा रहा है, तो यह तरीका अपनाएं:

  1. मैनेजमेंट सर्वर को अपडेट करना:

    1. हर मैनेजमेंट सर्वर नोड पर, /opt/apigee/customer/application/management-server.properties खोलें
    2. प्रॉपर्टी फ़ाइल में यह लाइन जोड़ें: 
      conf_webserver_http2.enabled=false
    3. मैनेजमेंट सर्वर कॉम्पोनेंट को रीस्टार्ट करें: 
      apigee-service edge-management-server restart

  2. मैसेज प्रोसेसर को अपडेट करना:

    1. हर मैसेज प्रोसेसर नोड पर, /opt/apigee/customer/application/message-processor.properties खोलें
    2. प्रॉपर्टी फ़ाइल में यह लाइन जोड़ें: 
      conf_webserver_http2.enabled=false
    3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें: 
      apigee-service edge-message-processor restart

  3. राउटर को अपडेट करना:

    1. हर राउटर नोड पर, /opt/apigee/customer/application/router.properties खोलें
    2. प्रॉपर्टी फ़ाइल में यह लाइन जोड़ें: 
      conf_webserver_http2.enabled=false
    3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें: 
      apigee-service edge-router restart

  4. QPID अपडेट करें:

    1. हर QPID नोड पर, /opt/apigee/customer/application/qpid-server.properties खोलें
    2. प्रॉपर्टी फ़ाइल में यह लाइन जोड़ें: 
      conf_webserver_http2.enabled=false
    3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें: 
      apigee-service edge-qpid-server restart

  5. Postgres को अपडेट करना:

    1. हर Postgres नोड पर, /opt/apigee/customer/application/postgres-server.properties खोलें
    2. प्रॉपर्टी फ़ाइल में यह लाइन जोड़ें: 
      conf_webserver_http2.enabled=false
    3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें: 
      apigee-service edge-postgres-server restart

अगर आपने Edge for Private Cloud के 4.51.00.11 से पहले के वर्शन का इस्तेमाल किया है, तो यह तरीका अपनाएं:

  1. मैनेजमेंट सर्वर को अपडेट करना:

    1. हर मैनेजमेंट सर्वर नोड पर, /opt/apigee/customer/application/management-server.properties खोलें
    2. प्रॉपर्टी फ़ाइल में ये दो लाइनें जोड़ें: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. मैनेजमेंट सर्वर कॉम्पोनेंट को रीस्टार्ट करें: 
      apigee-service edge-management-server restart

  2. मैसेज प्रोसेसर को अपडेट करना:

    1. हर मैसेज प्रोसेसर नोड पर, /opt/apigee/customer/application/message-processor.properties खोलें
    2. प्रॉपर्टी फ़ाइल में ये दो लाइनें जोड़ें: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें: 
      apigee-service edge-message-processor restart

  3. राउटर को अपडेट करना:

    1. हर राउटर नोड पर, /opt/apigee/customer/application/router.properties खोलें
    2. प्रॉपर्टी फ़ाइल में ये दो लाइनें जोड़ें: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें: 
      apigee-service edge-router restart

  4. QPID अपडेट करें:

    1. हर QPID नोड पर, /opt/apigee/customer/application/qpid-server.properties खोलें
    2. प्रॉपर्टी फ़ाइल में ये दो लाइनें जोड़ें: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें: 
      apigee-service edge-qpid-server restart

  5. Postgres को अपडेट करना:

    1. हर Postgres नोड पर, /opt/apigee/customer/application/postgres-server.properties खोलें
    2. प्रॉपर्टी फ़ाइल में ये दो लाइनें जोड़ें: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. मैसेज प्रोसेसर कॉम्पोनेंट को रीस्टार्ट करें: 
      apigee-service edge-postgres-server restart
4.52 वर्शन पर अपडेट करते समय Postgresql अपग्रेड करना

Apigee-postgresql को Edge for Private Cloud के वर्शन 4.50 या 4.51 से 4.52 पर अपग्रेड करने में समस्याएं आ रही हैं. ये समस्याएं मुख्य रूप से तब होती हैं जब टेबल की संख्या 500 से ज़्यादा हो.

Postgres में टेबल की कुल संख्या देखने के लिए, नीचे दी गई SQL क्वेरी चलाएं:

select count(*) from information_schema.tables

इस समस्या को हल करने का तरीका: Apigee Edge 4.50.00 या 4.51.00 को 4.52.00 पर अपडेट करते समय, Apigee-postgresql को अपग्रेड करने से पहले, शुरुआती चरण ज़रूर पूरा करें.
LDAP नीति

149245401: LDAP रिसॉर्स के ज़रिए कॉन्फ़िगर किए गए JNDI के लिए, LDAP कनेक्शन पूल की सेटिंग नहीं दिखती हैं. साथ ही, JNDI के डिफ़ॉल्ट तौर पर सेट होने की वजह से, हर बार सिंगल-यूज़ कनेक्शन बनते हैं. इस वजह से, हर बार एक बार इस्तेमाल करने के लिए कनेक्शंस खोले और बंद किए जा रहे हैं. इससे हर घंटे LDAP सर्वर से बड़ी संख्या में कनेक्शंस बन रहे हैं.

इस समस्या को हल करने का तरीका:

LDAP कनेक्शन पूल प्रॉपर्टी बदलने के लिए, सभी LDAP नीतियों में ग्लोबल बदलाव सेट करने के लिए, यह तरीका अपनाएं.

  1. अगर कॉन्फ़िगरेशन प्रॉपर्टी फ़ाइल पहले से मौजूद नहीं है, तो उसे बनाएं: 
    /opt/apigee/customer/application/message-processor.properties
  2. फ़ाइल में यह जानकारी जोड़ें (LDAP रिसॉर्स कॉन्फ़िगरेशन की ज़रूरत के आधार पर, Java Naming and Directory Interface (JNDI) प्रॉपर्टी की वैल्यू बदलें). 
    bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
-Dcom.sun.jndi.ldap.connect.pool.prefsize=2
-Dcom.sun.jndi.ldap.connect.pool.initsize=2
-Dcom.sun.jndi.ldap.connect.pool.timeout=120000
-Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"
  3. पक्का करें कि फ़ाइल /opt/apigee/customer/application/message-processor.properties का मालिक apigee:apigee हो.
  4. हर मैसेज प्रोसेसर को रीस्टार्ट करें.

यह पुष्टि करने के लिए कि आपके कनेक्शन पूल की JNDI प्रॉपर्टी काम कर रही हैं या नहीं, समय के साथ LDAP कनेक्शन पूल के व्यवहार को देखने के लिए, आपके पास एक tcpdump करने का विकल्प है.
अनुरोध प्रोसेस होने में ज़्यादा समय लगना

139051927: मैसेज प्रोसेसर में प्रॉक्सी प्रोसेस करने में लगने वाला ज़्यादा समय, सभी एपीआई प्रॉक्सी पर असर डाल रहा है. इसके लक्षणों में, एपीआई के सामान्य रिस्पॉन्स समय के मुकाबले, प्रोसेसिंग में 200 से 300 मिलीसेकंड की देरी शामिल है. यह देरी, कम टीपीएस के साथ भी कभी भी हो सकती है. ऐसा तब हो सकता है, जब मैसेज प्रोसेसर 50 से ज़्यादा टारगेट सर्वर से कनेक्ट करता हो.

मूल वजह: मैसेज प्रोसेसर एक कैश मेमोरी सेव रखते हैं. यह कैश मेमोरी, टारगेट सर्वर के यूआरएल को HTTPClient ऑब्जेक्ट से मैप करती है. ऐसा, टारगेट सर्वर से आउटगोइंग कनेक्शन के लिए किया जाता है. डिफ़ॉल्ट रूप से, यह सेटिंग 50 पर सेट होती है. यह ज़्यादातर डिप्लॉयमेंट के लिए बहुत कम हो सकती है. जब किसी डिप्लॉयमेंट के सेटअप में कई संगठन/एनवायरमेंट कॉम्बिनेशन होते हैं और टारगेट सर्वर की संख्या 50 से ज़्यादा होती है, तो टारगेट सर्वर के यूआरएल कैश मेमोरी से हटते रहते हैं. इस वजह से, इंतज़ार का समय बढ़ जाता है.

पुष्टि करना: यह पता लगाने के लिए कि टारगेट सर्वर यूआरएल को हटाने की वजह से, इंतज़ार का समय बढ़ रहा है या नहीं, मैसेज प्रोसेसर के system.logs में "onEvict" या "Eviction" कीवर्ड खोजें. लॉग में उनकी मौजूदगी से पता चलता है कि टारगेट सर्वर के यूआरएल, HTTPClient कैश मेमोरी से हटा दिए जा रहे हैं, क्योंकि कैश मेमोरी का साइज़ बहुत छोटा है.

इस समस्या को हल करने का तरीका: Edge for Private Cloud के 19.01 और 19.06 वर्शन के लिए, HTTPClient कैश मेमोरी में बदलाव किया जा सकता है और उसे कॉन्फ़िगर किया जा सकता है, /opt/apigee/customer/application/message-processor.properties:

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

इसके बाद, मैसेज प्रोसेसर को रीस्टार्ट करें. सभी मैसेज प्रोसेसर के लिए एक जैसे बदलाव करें.

वैल्यू 500 एक उदाहरण है. आपके सेटअप के लिए, ऑप्टिमम वैल्यू, उन टारगेट सर्वर की संख्या से ज़्यादा होनी चाहिए जिनसे मैसेज प्रोसेसर कनेक्ट होगा. इस प्रॉपर्टी को ज़्यादा सेट करने से कोई साइड इफ़ेक्ट नहीं होता. इसका सिर्फ़ एक असर होगा, मैसेज प्रोसेसर के प्रॉक्सी अनुरोध को प्रोसेस करने में लगने वाला समय कम हो जाएगा.

ध्यान दें: Edge for Private Cloud के वर्शन 50.00 में, डिफ़ॉल्ट सेटिंग 500 पर सेट होती है.
की-वैल्यू मैप के लिए एक से ज़्यादा एंट्री

157933959: संगठन या एनवायरमेंट लेवल के दायरे में आने वाले एक ही की वैल्यू मैप (KVM) में एक साथ डेटा डालने और अपडेट करने की वजह से, डेटा में अंतर होता है और अपडेट नहीं होते.

ध्यान दें: यह पाबंदी सिर्फ़ Edge for Private Cloud पर लागू होती है. Public Cloud और हाइब्रिड के लिए Edge पर यह पाबंदी नहीं है.

Edge for Private Cloud में समस्या को हल करने के लिए, apiproxy स्कोप में KVM बनाएं.