การย้ายข้อมูลไปยังเราเตอร์และตัวจัดสรรภาระงาน NGINX

คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ Apigee X
ข้อมูล

ตลอดเดือนสิงหาคมและกันยายน 2015 เราจะย้ายข้อมูลเราเตอร์ระบบคลาวด์และตัวจัดสรรภาระงาน Apigee Edge ไปยัง NGINX (อ่านว่า "Engine X") NGINX ซึ่งเป็นเว็บเซิร์ฟเวอร์โอเพนซอร์สที่มอบประสิทธิภาพที่ดียิ่งขึ้นและการเกิดขึ้นพร้อมกันสูงกว่าตัวจัดสรรภาระงานและเราเตอร์ที่มีอยู่

ผลกระทบต่อลูกค้าระบบคลาวด์

แต่ที่สำคัญที่สุดคือการเปลี่ยนแปลงนี้ควรโปร่งใสและคุณไม่จำเป็นต้องดำเนินการใดๆ นอกจากการตรวจสอบว่าระบบของคุณทำงานได้ตามที่คาดไว้ ต่อไปนี้เป็นคำอธิบายขั้นตอนที่เราจะดำเนินการ รวมถึงคำตอบสำหรับคำถามที่พบบ่อย

ขั้นตอนที่ 1 - การอัปเดตซอฟต์แวร์

เราจะอัปเกรดเราเตอร์ทั้งหมดเป็นเราเตอร์แบบใหม่ที่อิงตาม NGINX โดยใช้ประโยชน์จากโมเดลการทำให้ใช้งานได้เป็นระยะเพื่อให้มั่นใจว่าบริการจะไม่ได้รับผลกระทบจากกิจกรรมนี้

ขั้นตอนที่ 2 - นำระดับของตัวจัดสรรภาระงานออกในสภาพแวดล้อมที่ไม่ได้ใช้งานจริง

เราจะเริ่มขั้นตอนการนำระดับตัวจัดสรรภาระงานที่มีอยู่ในสภาพแวดล้อมที่ไม่ได้ใช้งานจริงออกก่อน เมื่อมีเราเตอร์ NGINX ใหม่ที่จัดการฟังก์ชันการจัดสรรภาระงาน ตัวจัดสรรภาระงานเวอร์ชันที่ใช้งานจริงจะยังคงเหมือนเดิมและไม่มีการเปลี่ยนแปลงในระหว่างขั้นตอนนี้ ก่อนที่จะนำตัวจัดสรรภาระงานที่มีอยู่ออก เราจะใช้วิธีการที่ละเอียดรอบคอบเพื่อทำให้การรับส่งข้อมูลทำงานได้ตามที่คาดไว้ คุณไม่จำเป็นต้องดำเนินการใดๆ เพื่อทำขั้นตอนนี้ให้เสร็จสมบูรณ์ อย่างไรก็ตาม คุณควรรายงานปัญหาใดๆ ไปยัง Apigee และเราจะช่วยคุณแก้ปัญหาเหล่านั้นก่อนที่จะดำเนินการต่อในขั้นตอนที่ 3

ขั้นตอนที่ 3 - นำระดับของตัวจัดสรรภาระงานในสภาพแวดล้อมที่ใช้งานจริงออก

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

การเปลี่ยนแปลงฟังก์ชันการทำงานของผลิตภัณฑ์

ต่อไปนี้เป็นการเปลี่ยนแปลงฟังก์ชันการทำงานของผลิตภัณฑ์เมื่อเปลี่ยนไปใช้ NGINX

เลิกใช้

ระบบไม่รองรับพร็อพเพอร์ตี้ต่อไปนี้ใน ProxyEndpoints อีกต่อไป

  • allow.http10
  • allow.http11
  • allow.http.method.*
  • allow.POST.without.content.length
  • allow.PUT.without.content.length

หากต้องการหลีกเลี่ยงการเลิกใช้งานนี้ โปรดดูบทความของชุมชน https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html

คำถามที่พบบ่อย

ต่อไปนี้เป็นคำตอบสำหรับคำถามที่พบบ่อยเกี่ยวกับการย้ายข้อมูล NGINX

การดำเนินการนี้อาจเปลี่ยนแปลง IP สาธารณะไหม ผู้ขายบางรายของเราอนุญาตเฉพาะการเข้าถึงจาก IP ที่รู้จัก และเมื่อมีการเปลี่ยนแปลงช่วงพักของผู้ขาย
ในขั้นตอนที่ 1 คำตอบคือ "ไม่" เนื่องจากเราไม่ได้สัมผัสกับตัวจัดสรรภาระงานที่มีอยู่ ซึ่งจะไม่เปลี่ยนแปลงการรับส่งข้อมูลของ IP ใดๆ โดยตรง อย่างไรก็ตาม ด้วยลักษณะของบริการจัดสรรภาระงานของ Amazon Web Services (AWS) จะมีการใช้กฎการปรับขนาดตามปกติ ซึ่งหมายความว่า IP อาจเปลี่ยนแปลงตามตรรกะการปรับขนาด (ฟังก์ชันที่มีอยู่) ด้วยเหตุนี้ เราจึงไม่แนะนำให้ใช้การกำหนดค่าการอนุญาตที่ขอบเขต Northbound กับชุดผลิตภัณฑ์ Apigee Edge ในขั้นตอนที่ 2 และ 3 จะมีผลกระทบกับรายการที่อนุญาตในการนำตัวจัดสรรภาระงานและที่อยู่ IP ที่เชื่อมโยงออก ด้วยเหตุนี้ เราจึงประสานงานกับคุณอย่างใกล้ชิดในระหว่างขั้นตอนเหล่านี้เพื่อให้การเปลี่ยนเป็นไปอย่างราบรื่นโดยการระบุที่อยู่ IP ชุดใหม่เพื่อให้คุณเข้าถึงได้
การดำเนินการนี้จะส่งผลต่อข้อจำกัด IP ที่เราใช้ในเซิร์ฟเวอร์ต้นทางไหม
ไม่ต้องทำการเปลี่ยนแปลงใดๆ โดยถือว่าเซิร์ฟเวอร์ต้นทางเป็นเซิร์ฟเวอร์ปลายทางเป้าหมาย (เซิร์ฟเวอร์ที่เรียกจากแพ็กเกจพร็อกซี) การเปลี่ยนแปลงนี้อยู่ทางด้านทิศเหนือของ Apigee หรือจุดขาเข้าไปยัง Apigee
CNAME ที่มีอยู่จะต้องมีการเปลี่ยนแปลงไหม
ไม่ได้ รายการ CNAME ที่มีอยู่จะยังคงทำงานตามที่คาดไว้
การย้ายข้อมูลใบรับรอง SSL เป็นเรื่องยุ่งยาก คุณจะจัดการกับเรื่องนี้อย่างไร
หากใช้ SSL อยู่ ขั้นตอนเริ่มต้นจะไม่ส่งผลต่อการกำหนดค่า SSL ที่มีอยู่ อย่างไรก็ตาม เราจะต้องประสานงานกับคุณอย่างใกล้ชิดเพื่อให้แน่ใจว่าได้ตั้งค่า SSL ในเราเตอร์ใหม่อย่างถูกต้องก่อนทำตามขั้นตอนที่ 2 และ 3
จะเกิดอะไรขึ้นหากแอป/ไคลเอ็นต์ของฉันไม่รองรับ SNI
ขั้นตอนที่ 2 และ 3 จะล่าช้าจนกว่าจะมีการยืนยันการรองรับ SNI
จะมีช่วงพักไหม
เราคาดว่าจะไม่มีช่วงพักการใช้งาน เราจะนำการเปลี่ยนแปลงไปใช้โดยใช้โมเดลการทำให้ใช้งานได้มาตรฐานในช่วงกรอบเวลาการเผยแพร่ปัจจุบัน