ปัญหาที่ทราบเกี่ยวกับ Apigee

เมื่อใช้ตัวแปรโฟลว์ cachehit หลังนโยบาย LookupCache เนื่องจากลักษณะการส่งจุดแก้ไขข้อบกพร่องสำหรับลักษณะการทำงานแบบไม่สอดคล้องกัน LookupPolicy จะสร้างออบเจ็กต์ DebugInfo ก่อนการเรียกกลับทำงาน จึงทำให้เกิดข้อผิดพลาด

วิธีแก้ปัญหาเฉพาะหน้า: ทำตามกระบวนการ (โทรครั้งที่ 2) ซ้ำอีกครั้งทันทีหลังจากโทรครั้งแรก

การตั้งค่า PurgeChildEntries ในนโยบาย InvalidateCache ควรล้างค่าองค์ประกอบ KeyFragment เท่านั้น แต่ล้างแคชทั้งหมด

วิธีแก้ปัญหา: ใช้นโยบาย KeyValueMapOperations เพื่อทําซ้ำการกำหนดเวอร์ชันแคชและไม่ต้องทำให้แคชใช้งานไม่ได้

กรณีนี้อาจเกิดขึ้นได้ เช่น เมื่อมีการเรียกใช้ไปป์ไลน์การติดตั้งใช้งาน CI/CD พร้อมกันโดยใช้การแก้ไขที่แตกต่างกัน เพื่อป้องกันปัญหานี้ โปรดหลีกเลี่ยงการติดตั้งใช้งานพร็อกซี API หรือ SharedFlow ก่อนการติดตั้งใช้งานปัจจุบันเสร็จสมบูรณ์

วิธีแก้ปัญหา: หลีกเลี่ยงการติดตั้งใช้งานพร็อกซี API หรือ SharedFlow พร้อมกัน

บางครั้ง Analytics ของ Edge API อาจมีข้อมูลที่ซ้ำกันสำหรับการเรียก API ในกรณีนี้ จํานวนการเรียก API ที่แสดงใน Analytics ของ Edge API จะสูงกว่าค่าที่เปรียบเทียบได้ซึ่งแสดงในเครื่องมือวิเคราะห์ของบุคคลที่สาม

วิธีแก้ปัญหา: ส่งออกข้อมูลวิเคราะห์และใช้ช่อง gateway_flow_id เพื่อกรองข้อมูลซ้ำออก

• Apigee Edge รองรับข้อกำหนดเฉพาะของ OpenAPI 3.0 เมื่อคุณสร้างข้อกำหนดเฉพาะโดยใช้เครื่องมือแก้ไขข้อกำหนด และเผยแพร่ API โดยใช้ SmartDocs ในพอร์ทัล แต่ยังไม่รองรับฟีเจอร์บางส่วน

  เช่น ระบบยังไม่รองรับฟีเจอร์ต่อไปนี้จากข้อกําหนดของ OpenAPI 3.0

  • พร็อพเพอร์ตี้ allOf สำหรับรวมและสคีมาเพิ่มเติม
  • ข้อมูลอ้างอิงระยะไกล

  หากมีการอ้างอิงถึงฟีเจอร์ที่ไม่รองรับในข้อกำหนด OpenAPI ในบางกรณี เครื่องมือจะละเว้นฟีเจอร์นั้นแต่ยังคงแสดงผลเอกสารอ้างอิง API ในกรณีอื่นๆ ฟีเจอร์ที่ไม่รองรับจะทำให้เกิดข้อผิดพลาดซึ่งทำให้แสดงผลเอกสารอ้างอิง API ไม่สำเร็จ ไม่ว่าในกรณีใด คุณจะต้องแก้ไขข้อกำหนด OpenAPI เพื่อหลีกเลี่ยงการใช้ฟีเจอร์ที่ไม่รองรับจนกว่าจะมีการรองรับฟีเจอร์ดังกล่าวในรุ่นถัดไป

  หมายเหตุ: เนื่องจากเครื่องมือแก้ไขข้อกำหนดมีข้อจำกัดน้อยกว่า SmartDocs เมื่อแสดงผลเอกสารอ้างอิง API คุณจึงอาจเห็นผลลัพธ์ที่แตกต่างกันระหว่างเครื่องมือ

• เมื่อใช้ "ลองใช้ API นี้" ในพอร์ทัล ระบบจะตั้งค่าส่วนหัว Accept เป็น application/json ไม่ว่าค่าที่กําหนดไว้สําหรับ consumes ในข้อกําหนดของ OpenAPI จะเป็นอย่างไรก็ตาม
• 138438484: ระบบไม่รองรับเซิร์ฟเวอร์หลายเครื่อง

• ปัจจุบันระบบยังไม่รองรับการอัปเดตพอร์ทัลพร้อมกัน (เช่น การแก้ไขหน้าเว็บ ธีม CSS หรือสคริปต์) โดยผู้ใช้หลายคน
• หากคุณลบหน้าเอกสารประกอบอ้างอิง API ออกจากพอร์ทัล คุณจะสร้างหน้าดังกล่าวอีกครั้งไม่ได้ โดยจะต้องลบและเพิ่มผลิตภัณฑ์ API อีกครั้ง รวมถึงสร้างเอกสารประกอบอ้างอิง API อีกครั้ง
• เมื่อกำหนดค่านโยบายความปลอดภัยของเนื้อหา ระบบอาจใช้เวลาถึง 15 นาทีเพื่อให้การเปลี่ยนแปลงมีผล
• เมื่อปรับแต่งธีมพอร์ทัล ระบบอาจใช้เวลาถึง 5 นาทีจึงจะเปลี่ยนธีมให้เสร็จสมบูรณ์

• เราจะผสานรวม Search เข้ากับพอร์ทัลแบบรวมในรุ่นต่อๆ ไป

มีการเปิดเผยช่องโหว่ (CVE-2026-42945) ที่ส่งผลต่อ ngx_http_rewrite_module ใน NGINX เครื่องมือสแกนความปลอดภัยอาจแจ้งว่าไบนารี NGINX ที่รวมอยู่ใน Apigee Edge สำหรับ Private Cloud มีปัญหา เนื่องจากโมดูลนี้คอมไพล์แบบคงที่ลงใน NGINX

ผลกระทบต่อ Apigee Edge สำหรับ Private Cloud:

Apigee Edge สำหรับ Private Cloud ไม่ได้รับผลกระทบจากช่องโหว่นี้ในการกำหนดค่าเริ่มต้นที่จัดส่ง ความสามารถในการใช้ประโยชน์จาก CVE-2026-42945 ขึ้นอยู่กับรูปแบบการกำหนดค่า NGINX ที่เฉพาะเจาะจง โดยเฉพาะการใช้คำสั่ง rewrite ในลำดับที่เฉพาะเจาะจง รูปแบบเหล่านี้ไม่มีอยู่ในการกำหนดค่า NGINX มาตรฐานของ Apigee Edge สำหรับ Private Cloud

ขอให้ดำเนินการ:

• สำหรับการกำหนดค่า Apigee Edge สำหรับ Private Cloud เริ่มต้น: ไม่จำเป็นต้องใช้แพตช์ อัปเกรด หรือการเปลี่ยนแปลงการดำเนินงาน ผลการสแกนที่เกี่ยวข้องกับ CVE-2026-42945 สามารถถือเป็นผลบวกลวงสำหรับการติดตั้งเริ่มต้นได้ คุณใช้ข้อความต่อไปนี้เพื่อบันทึกข้อยกเว้นนี้ในระบบการจัดการช่องโหว่ได้

  CVE-2026-42945 — Accepted exception (false positive for Apigee Edge for Private Cloud). Apigee Edge for Private Cloud does not use the rewrite directive in any shipped NGINX configuration. The vulnerable code path in ngx_http_rewrite_module is configuration-gated and is not reachable in the default Apigee Edge for Private Cloud deployment.

• สำหรับการกำหนดค่า NGINX ที่กำหนดเอง: หากคุณได้แก้ไขไฟล์การกำหนดค่า NGINX ด้วยตนเองในการติดตั้ง Apigee Edge สำหรับ Private Cloud (เช่น ใน /opt/nginx) คุณควรทำการตรวจสอบด้วยตนเองต่อไปนี้เพื่อให้แน่ใจว่าการปรับแต่งไม่ได้ทำให้เกิดรูปแบบที่มีช่องโหว่โดยไม่ตั้งใจ
  1. ตรวจสอบคําสั่งการเขียนใหม่: เรียกใช้คําสั่งต่อไปนี้ในแต่ละโหนด NGINX

     sudo grep -rnI '^\s*rewrite\b' /opt/nginx

  2. วิเคราะห์ผลลัพธ์:
     • หากคำสั่งไม่แสดงเอาต์พุตใดๆ แสดงว่าระบบไม่ได้รับผลกระทบ
     • หากพบรายการที่ตรงกัน ให้ตรวจสอบแต่ละอินสแตนซ์ ช่องโหว่จะเกิดขึ้นเฉพาะในกรณีที่บล็อกหนึ่งๆ มีคุณสมบัติตรงตามเงื่อนไขต่อไปนี้ทั้งหมด
       • มีการใช้คำสั่ง rewrite
       • ตามด้วยคําสั่ง rewrite if หรือ set อื่นทันทีภายในบล็อกการกําหนดค่าเดียวกัน
       • ใช้กลุ่มแคปเจอร์ PCRE ที่ไม่มีชื่อ (เช่น $1, $2 ฯลฯ) ในคำสั่ง
       • สตริงการแทนที่ในคําสั่งมีเครื่องหมายคําถาม (?)
  3. การลดความเสี่ยง (หากมีช่องโหว่): หากเงื่อนไขข้างต้นทั้งหมดเป็นจริงสำหรับส่วนใดส่วนหนึ่งของการกำหนดค่าที่กำหนดเอง ให้ลดความเสี่ยงโดยทำดังนี้
     • นำเครื่องหมายคำถาม (?) ออกจากสตริงการแทนที่
     • การใช้กลุ่มจับภาพ PCRE ที่มีชื่อแทนกลุ่มที่ไม่มีชื่อ
     • การประเมินความจำเป็นของคำสั่งที่เชื่อมโยงกันอีกครั้ง

ใน Edge for Private Cloud 4.53.00 ขึ้นไป UI จะแสดง ป๊อปอัปคำเตือน"สิ้นสุดอายุการใช้งาน" (EOL) คำเตือนนี้ จะปรากฏ
ซ้ำๆ และไม่สามารถป้องกันหรือลดความถี่ได้

ปัจจุบันยังไม่มีวิธีที่ผู้ใช้จะปิดใช้หรือลดความถี่ ของคำเตือน EOL นี้

ปัญหานี้จะส่งผลเฉพาะผู้ที่ใช้ MINT หรือเปิดใช้ MINT ใน Edge สำหรับการติดตั้ง Private Cloud

คอมโพเนนต์ที่ได้รับผลกระทบ: edge-message-processor

ปัญหา: หากเปิดใช้การสร้างรายได้และติดตั้ง 4.52.01 เป็นการติดตั้งใหม่หรืออัปเกรดจาก Private Cloud เวอร์ชันก่อนหน้า คุณจะพบปัญหาเกี่ยวกับตัวประมวลผลข้อความ จำนวนเธรดที่เปิดจะค่อยๆ เพิ่มขึ้นจนทำให้ทรัพยากรหมด ข้อยกเว้นต่อไปนี้จะปรากฏใน system.log ของ edge-message-processor

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

เมื่อเร็วๆ นี้มีการค้นพบช่องโหว่การปฏิเสธการให้บริการ (DoS) ในการติดตั้งใช้งานโปรโตคอล HTTP/2 (CVE-2023-44487) หลายรายการ ซึ่งรวมถึงใน Apigee Edge สำหรับ Private Cloud ช่องโหว่อาจทำให้เกิดการโจมตีแบบ DoS ต่อฟังก์ชันการจัดการ Apigee API ดูรายละเอียดเพิ่มเติมได้ที่กระดานข่าวสารด้านความปลอดภัยของ Apigee GCP-2023-032

คอมโพเนนต์เราเตอร์และเซิร์ฟเวอร์การจัดการของ Edge สำหรับ Private Cloud จะแสดงต่ออินเทอร์เน็ตและอาจมีช่องโหว่ แม้ว่าจะมีการเปิดใช้ HTTP/2 ในพอร์ตการจัดการ ของคอมโพเนนต์อื่นๆ ที่เฉพาะเจาะจง Edge ของ Edge สำหรับ Private Cloud แต่ไม่มีคอมโพเนนต์ใดที่ แสดงต่ออินเทอร์เน็ต ในคอมโพเนนต์ที่ไม่ใช่ Edge เช่น Cassandra, Zookeeper และอื่นๆ จะไม่ได้เปิดใช้ HTTP/2 เราขอแนะนำให้คุณทำตามขั้นตอนต่อไปนี้เพื่อแก้ไขช่องโหว่ของ Edge for Private Cloud

• ขั้นตอนสำหรับ Edge สำหรับ Private Cloud เวอร์ชัน 4.51.00.11 ขึ้นไป
• ขั้นตอนสำหรับ Edge for Private Cloud เวอร์ชันเก่ากว่า 4.51.00.11

ทำตามขั้นตอนต่อไปนี้หากคุณใช้ 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 สำหรับ Private Cloud เวอร์ชันเก่ากว่า 4.51.00.11

1. อัปเดตเซิร์ฟเวอร์การจัดการ

   1. ในโหนดเซิร์ฟเวอร์การจัดการแต่ละรายการ ให้เปิด /opt/apigee/customer/application/management-server.properties
   2. เพิ่ม 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. เพิ่ม 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. เพิ่ม 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. เพิ่ม 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. เพิ่ม 2 บรรทัดต่อไปนี้ลงในไฟล์พร็อพเพอร์ตี้

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. รีสตาร์ทคอมโพเนนต์ตัวประมวลผลข้อความ

      apigee-service edge-postgres-server restart

Apigee-postgresql มีปัญหาในการอัปเกรดจาก Edge สำหรับ 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

149245401: การตั้งค่าพูลการเชื่อมต่อ LDAP สำหรับ JNDI ที่กำหนดค่าผ่าน ทรัพยากร LDAP จะไม่แสดง และค่าเริ่มต้นของ JNDI จะทำให้เกิดการเชื่อมต่อแบบใช้ครั้งเดียวในแต่ละครั้ง ด้วยเหตุนี้ การเชื่อมต่อจึงเปิด และปิดทุกครั้งสำหรับการใช้งานครั้งเดียว ทำให้เกิดการเชื่อมต่อจำนวนมาก ต่อชั่วโมงกับเซิร์ฟเวอร์ LDAP

วิธีแก้ปัญหาเฉพาะหน้า:

หากต้องการเปลี่ยนพร็อพเพอร์ตี้ของพูลการเชื่อมต่อ LDAP ให้ทำตามขั้นตอนต่อไปนี้เพื่อตั้งค่าการเปลี่ยนแปลงส่วนกลางในนโยบาย LDAP ทั้งหมด

1. สร้างไฟล์พร็อพเพอร์ตี้การกำหนดค่าหากยังไม่มี

   /opt/apigee/customer/application/message-processor.properties

2. เพิ่มข้อมูลต่อไปนี้ลงในไฟล์ (แทนที่ค่าของ พร็อพเพอร์ตี้ Java Naming and Directory Interface (JNDI) ตามข้อกำหนดการกำหนดค่าทรัพยากร LDAP)

   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 ของ Connection Pool มีผล คุณสามารถ เรียกใช้ tcpdump เพื่อสังเกตลักษณะการทำงานของ Connection Pool ของ LDAP เมื่อเวลาผ่านไป

139051927: พบเวลาในการตอบสนองในการประมวลผลพร็อกซีสูงใน Message Processor ซึ่งส่งผลต่อ API Proxy ทั้งหมด อาการรวมถึงเวลาในการประมวลผลที่ล่าช้า 200-300 มิลลิวินาทีเมื่อเทียบกับเวลาในการตอบสนองของ API ปกติ และอาจเกิดขึ้นแบบสุ่มแม้ว่า TPS จะต่ำก็ตาม ปัญหานี้อาจเกิดขึ้นเมื่อมีเซิร์ฟเวอร์เป้าหมายมากกว่า 50 เครื่องที่ตัวประมวลผลข้อความเชื่อมต่อ

สาเหตุหลัก: ตัวประมวลผลข้อความจะเก็บแคชที่แมป URL ของเซิร์ฟเวอร์เป้าหมายกับออบเจ็กต์ HTTPClient สำหรับ การเชื่อมต่อขาออกกับเซิร์ฟเวอร์เป้าหมาย โดยค่าเริ่มต้น การตั้งค่านี้จะตั้งไว้ที่ 50 ซึ่งอาจต่ำเกินไปสำหรับการติดตั้งใช้งานส่วนใหญ่ เมื่อการติดตั้งใช้งานมีการผสมผสานองค์กร/สภาพแวดล้อมหลายรายการในการตั้งค่า และมีเซิร์ฟเวอร์เป้าหมายจํานวนมากที่เกิน 50 รายการ URL ของเซิร์ฟเวอร์เป้าหมาย จะถูกนําออกจากแคชอย่างต่อเนื่อง ซึ่งทําให้เกิดเวลาในการตอบสนอง

การตรวจสอบ: หากต้องการดูว่าการนำ URL ของเซิร์ฟเวอร์เป้าหมายออกทำให้เกิดปัญหาเวลาในการตอบสนองหรือไม่ ให้ค้นหาคำหลัก "onEvict" หรือ "Eviction" ใน system.logs ของ Message Processor การมีอยู่ของ URL ในบันทึกบ่งชี้ว่า URL ของเซิร์ฟเวอร์เป้าหมาย ถูกนำออกจากแคช 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 สำหรับ Private Cloud เวอร์ชัน 50.00 มีการตั้งค่าเริ่มต้นเป็น 500

157933959: การแทรกและการอัปเดตพร้อมกันไปยังแมปค่าคีย์ (KVM) เดียวกันที่กำหนดขอบเขตไว้ที่ระดับองค์กรหรือสภาพแวดล้อมจะทำให้ข้อมูลไม่สอดคล้องกันและอัปเดตหายไป

หมายเหตุ: ขีดจำกัดนี้ใช้กับ Edge สำหรับ Private Cloud เท่านั้น Edge สำหรับระบบคลาวด์สาธารณะ และไฮบริดไม่มีข้อจำกัดนี้

หากต้องการแก้ปัญหาชั่วคราวใน Edge for Private Cloud ให้สร้าง KVM ที่ขอบเขต apiproxy