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

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

ตลอดเดือนสิงหาคมและกันยายน 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

หากต้องการหลีกเลี่ยงการเลิกใช้ฟีเจอร์นี้ โปรดดูบทความในชุมชนต่อไปนี้: Proxy Endpoint HTTP allow method properties not working

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

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

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