หน้านี้ได้รับการแปลโดย Cloud Translation API

อัปเดต Apigee Edge 4.51.00 หรือ 4.52.00 หรือ 4.52.01 เป็น 4.52.02

Apigee รองรับการอัปเกรด Edge สำหรับ Private Cloud จากเวอร์ชัน 4.51.00, 4.52.00 หรือ 4.52.01 เป็นเวอร์ชัน 4.52.02 โดยตรง หน้านี้จะอธิบายวิธีอัปเกรดดังกล่าว

ข้อควรระวัง: Edge for Private Cloud 4.52.02 มีการอัปเกรด Cassandra เป็นเวอร์ชันหลัก โปรดใช้ความระมัดระวังเมื่ออัปเกรด Cassandra เนื่องจากฐานข้อมูลจะจัดเก็บข้อมูลที่สําคัญต่อการทํางานของ Apigee โปรดทดสอบการอัปเกรดนี้อย่างละเอียดในสภาพแวดล้อมที่ต่ำกว่าก่อนที่จะนำไปใช้กับเวอร์ชันที่ใช้งานจริง นอกจากนี้ โปรดทําตามทุกขั้นตอนอย่างถูกต้องเพื่อให้การอัปเกรดเป็นไปอย่างราบรื่น

ผู้ที่จะอัปเดตได้

บุคคลที่ทำการอัปเดตควรเป็นคนเดียวกับที่ติดตั้ง Edge ไว้ตั้งแต่แรก หรือเป็นบุคคลที่เรียกใช้ในฐานะรูท

หลังจากติดตั้ง RPM ของ Edge แล้ว ทุกคนจะกำหนดค่า RPM ได้

คอมโพเนนต์ใดบ้างที่คุณต้องอัปเดต

คุณต้องอัปเดตคอมโพเนนต์ Edge ทั้งหมด Edge ไม่รองรับการตั้งค่าที่มีคอมโพเนนต์จากหลายเวอร์ชัน

อัปเดตข้อกําหนดเบื้องต้น

ตรวจสอบว่าคุณมีคุณสมบัติตามข้อกําหนดเบื้องต้นต่อไปนี้ก่อนอัปเกรด Apigee Edge

สํารองข้อมูลโหนดทั้งหมด
ก่อนอัปเดต เราขอแนะนําให้สํารองข้อมูลโหนดทั้งหมดอย่างสมบูรณ์เพื่อความปลอดภัย ใช้ขั้นตอนสำหรับ Edge เวอร์ชันปัจจุบันเพื่อทำการสำรองข้อมูล
ซึ่งจะช่วยให้คุณมีแผนสำรองในกรณีที่การอัปเดตเป็นเวอร์ชันใหม่ไม่ทำงานอย่างถูกต้อง ดูข้อมูลเพิ่มเติมเกี่ยวกับการสำรองข้อมูลได้ที่การสำรองและกู้คืนข้อมูล
ตรวจสอบว่า Edge ทำงานอยู่
ตรวจสอบว่า Edge ทำงานอยู่ในระหว่างกระบวนการอัปเดตโดยใช้คำสั่งต่อไปนี้
```
/opt/apigee/apigee-service/bin/apigee-all status
```
ตรวจสอบว่ากลยุทธ์การบีบอัดข้อมูล Cassandra เป็น LeveledCompactionStrategy
ทําการเปลี่ยนแปลงที่จําเป็นกับกลยุทธ์การบีบอัดข้อมูล Cassandra โดยขึ้นอยู่กับเวอร์ชันปัจจุบัน ทำตามขั้นตอนด้านล่าง แล้วกลับไปที่กระบวนการอัปเกรดหลัก
- หากคุณจะอัปเกรดจากเวอร์ชัน 4.51.00 โปรดดูเอกสารกลยุทธ์การบีบอัดของ Cassandra สำหรับ v4.51.00
- หากคุณอัปเกรดจากเวอร์ชัน 4.52.00 โปรดดูเอกสารกลยุทธ์การบีบอัด Cassandra สำหรับ v4.52.00
- หากคุณอัปเกรดจากเวอร์ชัน 4.52.01 โปรดดูเอกสารกลยุทธ์การบีบอัด Cassandra สำหรับ v4.52.01

ขั้นตอนพิเศษที่ควรพิจารณาสำหรับการอัปเกรด

หากต้องการอัปเกรดเป็น Edge for Private Cloud 4.52.02 ให้ลองทำตามขั้นตอนเฉพาะสำหรับการอัปเกรดซอฟต์แวร์บางรายการ ขั้นตอนที่จำเป็นจะขึ้นอยู่กับเวอร์ชันปัจจุบันของคุณ โปรดดูตารางด้านล่างสำหรับซอฟต์แวร์ต่างๆ ที่ต้องดำเนินการเพิ่มเติม และทําตามวิธีการโดยละเอียดของแต่ละรายการ หลังจากทํางานที่จำเป็นเสร็จแล้ว ให้กลับไปที่ขั้นตอนการอัปเกรดหลักเพื่อดําเนินการอัปเกรดต่อ

เวอร์ชันปัจจุบัน	ซอฟต์แวร์ที่ต้องดำเนินการพิเศษเพื่ออัปเกรดเป็น 4.52.02
4.52.01	Cassandra
4.52.00	Zookeeper, Cassandra, Qpid
4.51.00	Zookeeper, Postgres, Cassandra, Qpid

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

การนำไปใช้งานการตั้งค่าที่พักโดยอัตโนมัติ

หากคุณตั้งค่าพร็อพเพอร์ตี้โดยการแก้ไขไฟล์ .properties ใน /opt/apigee/customer/application ระบบจะเก็บค่าเหล่านั้นไว้หลังจากการอัปเดต

อัปเกรดเป็น Zookeeper 3.8.3

Edge for Private Cloud 4.52.02 ไม่รวมการอัปเกรด Zookeeper อย่างไรก็ตาม หากคุณจะอัปเกรดจากเวอร์ชันที่เก่ากว่า 4.52.01 คุณต้องทําตามขั้นตอนการอัปเกรด Zookeeper ที่ระบุไว้ด้านล่าง

หากจะอัปเกรดจาก Edge for Private Cloud เวอร์ชัน 4.51.00 หรือ 4.52.00 โปรดดูขั้นตอนในการอัปเกรดเป็น Zookeeper 3.8.3 ที่จำเป็นเพื่ออัปเกรด Zookeeper
หากจะอัปเกรดจาก Edge for Private Cloud เวอร์ชัน 4.52.01 คุณควรใช้ Zookeeper เวอร์ชัน 3.8.3 อยู่แล้ว และไม่จำเป็นต้องทำตามขั้นตอนพิเศษใดๆ เพื่ออัปเกรด Zookeeper

หมายเหตุ:

การอัปเกรดจาก Edge for Private Cloud 4.52.01 เป็น 4.52.02 นั้นง่ายขึ้นเนื่องจากโดยทั่วไป Zookeeper และ Cassandra จะอยู่ในโฮสต์หรือเครื่องเสมือนเดียวกัน ซึ่งทำให้ไม่จำเป็นต้องใช้ขั้นตอนการอัปเกรด Zookeeper แยกต่างหากควบคู่ไปกับอัปเกรด Cassandra ที่สำคัญ

หาก Zookeeper ต้องมีการอัปเดตด้วยขั้นตอนที่เฉพาะเจาะจง ให้อัปเกรด Zookeeper ในศูนย์ข้อมูลทั้งหมดโดยการอัปเดตโหนดทีละโหนด เมื่ออัปเดตโหนด Zookeeper ทั้งหมดทั่วโลกแล้ว ให้อัปเกรด Cassandra ทีละศูนย์ข้อมูล โดยทำตามขั้นตอนที่ระบุไว้ในส่วนถัดไปของบทความนี้

คำสั่งต่อไปนี้ช่วยในการอัปเกรด Zookeeper แยกต่างหาก

/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile

สําหรับการย้อนกลับ Zookeeper ให้ใช้ขั้นตอนการย้อนกลับ Zookeeper มาตรฐาน หากจำเป็นต้องมีการย้อนกลับสำหรับ Cassandra หรือคอมโพเนนต์อื่นๆ ก็ควรย้อนกลับคอมโพเนนต์เหล่านั้น แต่ไม่จำเป็นต้องย้อนกลับ Zookeeper

อัปเกรดเป็น Postgres 14

หากจะอัปเกรดจาก Edge for Private Cloud 4.51.00 เป็น 4.52.02 คุณต้องทําตามขั้นตอนเพื่ออัปเกรด Postgres แม้ว่า Edge for Private Cloud 4.52.02 จะไม่รวมการอัปเกรด Postgres ก็ตาม การอัปเกรดจาก Edge for Private Cloud 4.51.00 เป็น 4.52.02 ต้องใช้ขั้นตอนการอัปเกรด Postgres เพิ่มเติม โปรดดูส่วนการอัปเกรดเป็น Postgres 14 ที่จำเป็น
หากจะอัปเกรดจาก Edge for Private Cloud 4.52.00 หรือ 4.52.01 เป็น 4.52.02 คุณไม่จําเป็นต้องทําตามขั้นตอนการอัปเกรด Postgres เพิ่มเติม

หมายเหตุ:

หาก Postgres ต้องมีการอัปเดตด้วยขั้นตอนพิเศษ ให้ดำเนินการนี้แยกต่างหากก่อนอัปเกรด Cassandra เราขอแนะนำให้อัปเกรด Cassandra ทีละศูนย์ข้อมูล อย่างไรก็ตาม ควรอัปเดต Postgres ในศูนย์ข้อมูลทั้งหมดโดยการอัปเดตโหนด Postgres ทีละโหนด หลังจากอัปเดต Postgres แล้ว ให้ตรวจสอบว่าคลัสเตอร์ทํางานได้อย่างสมบูรณ์ก่อนดำเนินการอัปเกรด Cassandra และคอมโพเนนต์อื่นๆ ต่อ

สำหรับการย้อนกลับ Postgres ให้ทำตามขั้นตอนการย้อนกลับ Postgres มาตรฐาน หากจำเป็นต้องมีการย้อนกลับสำหรับ Cassandra หรือคอมโพเนนต์อื่นๆ ให้ย้อนกลับคอมโพเนนต์เหล่านั้น ไม่จำเป็นต้องย้อนกลับ Postgres

อัปเกรดเป็น Cassandra 3.11.16

Apigee Edge สําหรับ Private Cloud 4.52.02 มีการอัปเกรด Cassandra เป็นเวอร์ชัน 3.11.16 Cassandra เป็นคอมโพเนนต์ที่สําคัญของ Apigee และการอัปเกรดนี้ยังรวมถึงการอัปเดตซอฟต์แวร์ไดรเวอร์ในรันไทม์และคอมโพเนนต์การจัดการต่างๆ ที่ใช้เพื่อค้นหาและเขียนลงใน Cassandra ด้วย

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

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

หมายเหตุ: Cassandra 3.X ไม่รองรับเครื่องมือ cassandra-cli อีกต่อไปและเครื่องมือดังกล่าวไม่พร้อมให้บริการแก่คุณ

พอร์ทัลนักพัฒนาแอป - เอกสารประกอบ API

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

เมื่อคุณอัปเกรด Apigee เป็นเวอร์ชัน 4.52.02 ระบบจะไม่ย้ายข้อมูลโมเดล API ที่สร้างขึ้นโดยใช้ฟีเจอร์ SmartDocs ของพอร์ทัลนักพัฒนาซอฟต์แวร์ Drupal 7 ไปยังเวอร์ชันใหม่โดยอัตโนมัติ คุณจะต้องส่งออกแต่ละรูปแบบด้วยตนเองโดยใช้พอร์ทัลนักพัฒนาแอปและนําเข้าอีกครั้งหลังจากการอัปเกรดเสร็จสมบูรณ์

คําศัพท์ที่ใช้ด้านล่าง

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

การจัดการ: การจัดการรวมถึงการดูแลระบบ Apigee Edge ซึ่งรวมถึงแต่ไม่จํากัดเพียงการติดตั้งใช้งาน การแก้ไขแอป ผลิตภัณฑ์ เซิร์ฟเวอร์เป้าหมาย คีย์สโตร์ ฯลฯ API การจัดการทั้งหมด (และไคลเอ็นต์ เช่น UI ของ Apigee และพอร์ทัลนักพัฒนาแอป) จะรวมอยู่ในขอบเขตนี้

ในระหว่างการอัปเกรดนี้ รันไทม์และปริมาณการเข้าชมการจัดการจะได้รับผลกระทบในภูมิภาคหรือศูนย์ข้อมูล (DC) ที่ดำเนินการอัปเดต ไม่ว่าจะอัปเดตศูนย์ข้อมูลใดก็ตาม การดำเนินการนี้จะส่งผลต่อ Management API บางรายการในศูนย์ข้อมูลทั้งหมด ระบบจะบันทึกผลกระทบนี้ไว้หลังจากแต่ละขั้นตอน

ในแต่ละขั้นตอนด้านล่างจะอธิบายสถานะรันไทม์และการจัดการขณะที่คุณดำเนินการตามขั้นตอนต่างๆ ของการอัปเกรด

อัปเกรดกลยุทธ์

ศูนย์ข้อมูลหลายแห่ง

คุณต้องทำการอัปเกรดทีละศูนย์ข้อมูลเพื่อให้การเข้าชมมีความต่อเนื่องและหลีกเลี่ยงการหยุดทำงาน ก่อนอัปเกรด DC คุณควรเปลี่ยนเส้นทางการรับส่งข้อมูลไปยัง DC อื่นๆ ที่ใช้งานได้

หมายเหตุ:

เพื่อป้องกันไม่ให้การเข้าชมได้รับผลกระทบระหว่างการอัปเกรด ให้ทำตามแนวทางแบบศูนย์ข้อมูลต่อศูนย์ข้อมูล (DC ต่อ DC) โดยเปลี่ยนเส้นทางการเข้าชมออกจากศูนย์ข้อมูลที่อัปเกรดชั่วคราว วิธีนี้ช่วยให้มั่นใจได้ว่ากระบวนการอัปเกรด Cassandra, เซิร์ฟเวอร์การจัดการ และโหนดรันไทม์จะควบคุมได้ ในขณะที่บริการยังคงพร้อมใช้งาน

สำหรับการตั้งค่าศูนย์ข้อมูล 2 แห่ง ให้ทำตามขั้นตอนระดับสูงต่อไปนี้

เปลี่ยนเส้นทางการรับส่งข้อมูลจาก DC-1 ไปยัง DC-2 และบล็อกการรับส่งข้อมูลขาเข้าไปยัง DC-1
อัปเกรด DC-1 ซึ่งรวมถึง Cassandra, เซิร์ฟเวอร์การจัดการ และคอมโพเนนต์รันไทม์
เปลี่ยนเส้นทางการรับส่งข้อมูลกลับไปยัง DC-1 และบล็อกการรับส่งข้อมูลขาเข้าไปยัง DC-2
อัปเกรด DC-2 ซึ่งรวมถึง Cassandra, เซิร์ฟเวอร์การจัดการ และคอมโพเนนต์รันไทม์

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

ศูนย์ข้อมูลแห่งเดียว

สำหรับการตั้งค่าศูนย์ข้อมูลเดียว ขั้นตอนการอัปเกรดจะส่งผลกระทบอย่างมากต่อการเข้าชมรันไทม์และ API การจัดการบางรายการ ตัวเลือกต่อไปนี้มีไว้สําหรับการตั้งค่าศูนย์ข้อมูลเดียว

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

เราขอแนะนำให้ขยายไปยังศูนย์ข้อมูลเพิ่มเติมเพื่อหลีกเลี่ยงผลกระทบต่อการเข้าชมรันไทม์และ API การจัดการ ในระหว่างการอัปเกรด ผลกระทบต่อศูนย์ข้อมูลที่อัปเกรดรวมถึงแต่ไม่จำกัดเพียงด้านต่อไปนี้

API รันไทม์ที่รีเฟรชโทเค็น OAuth
API รันไทม์ที่ใช้นโยบายการเข้าถึงเอนทิตี
API การจัดการที่แสดงแอปของนักพัฒนาแอป
API การจัดการที่แสดงผลิตภัณฑ์

ผลกระทบที่อธิบายข้างต้นนอกเหนือจาก API การจัดการที่เฉพาะเจาะจงซึ่งจะยังคงไม่ทำงานในศูนย์ข้อมูลทั้งหมดจนกว่าจะมีการอัปเกรดศูนย์ข้อมูลทั้งหมด API การจัดการดังกล่าวแสดงอยู่ในขั้นตอนในส่วนถัดไป

Rollback - ระดับสูง

ผลกระทบระหว่างการย้อนกลับ
การย้อนกลับจาก Cassandra 3.11.x เป็น 2.1.x จะส่งผลต่อทั้งรันไทม์และการเข้าชมการจัดการภายในศูนย์ข้อมูล (DC) ที่มีการย้อนกลับ นอกจากนี้ Management API บางรายการอาจหยุดชะงักในศูนย์ข้อมูลทั้งหมด ไม่ว่าขณะนี้จะมีการย้อนกลับศูนย์ข้อมูลใดก็ตาม
ทำตามแนวทางการย้อนกลับ DC โดย DC
คุณต้องดำเนินการย้อนกลับทีละศูนย์ข้อมูลเพื่อรักษาความต่อเนื่องของบริการและป้องกันช่วงเวลาที่หยุดทำงาน ก่อนที่จะเริ่มการย้อนกลับใน DC ที่เฉพาะเจาะจง ให้ตรวจสอบว่ามีการเปลี่ยนเส้นทางการรับส่งข้อมูลของแอปพลิเคชันไปยังศูนย์ข้อมูลอื่นที่ใช้งานได้อย่างเต็มรูปแบบ
การย้อนกลับคลัสเตอร์ที่อัปเกรดบางส่วน
หากมีศูนย์ข้อมูลอย่างน้อย 1 แห่งที่ยังคงทํางานได้อย่างเต็มรูปแบบใน Cassandra เวอร์ชันเก่า (2.1.22) คุณจะย้อนกลับ DC อื่นๆ ที่อัปเกรดแล้วได้โดยการสร้างใหม่จาก DC Cassandra 2.1.X ที่ทํางานได้อย่างเต็มรูปแบบ
การย้อนกลับทั้งคลัสเตอร์
หากมีการอัปเกรดคลัสเตอร์ Cassandra ทั้งหมดและจำเป็นต้องมีการย้อนกลับ การดำเนินการดังกล่าวจะต้องทำโดยใช้ข้อมูลสำรองหรือสแนปชอต VM แนวทางนี้มีความซับซ้อนและอาจทําให้ระบบหยุดทํางานชั่วคราวหรือข้อมูลสูญหาย
ข้อควรพิจารณาก่อนการอัปเกรด
คุณควรทำความเข้าใจขั้นตอนการย้อนกลับก่อนที่จะพยายามอัปเกรด คุณควรพิจารณารายละเอียดปลีกย่อยของการย้อนกลับขณะอัปเกรดเพื่อให้มีเส้นทางการย้อนกลับที่เหมาะสม

ย้อนกลับคลัสเตอร์ที่มีศูนย์ข้อมูลเดียว

การอัปเกรด Cassandra จากเวอร์ชัน 2.1.x เป็น 3.11.x อาจส่งผลต่อการเข้าชมรันไทม์และ API การจัดการบางอย่างอย่างมาก ผลกระทบเหล่านี้จะมีผลในระหว่างการย้อนกลับด้วย และอาจส่งผลให้เกิดช่วงหยุดทำงานหรือข้อมูลสูญหาย

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

หากเพิ่มศูนย์ข้อมูลใหม่ไม่สามารถทำได้แต่ยังคงต้องใช้ความสามารถในการย้อนกลับ โปรดตรวจสอบว่าได้ทำการสำรองข้อมูลที่เชื่อถือได้ก่อนการอัปเกรด คุณสามารถกู้คืน Cassandra 2.1.x จากข้อมูลสํารองได้ แต่วิธีนี้อาจทําให้บริการหยุดชะงักและข้อมูลอาจสูญหาย

ย้อนกลับคลัสเตอร์ที่มีศูนย์ข้อมูลหลายแห่ง

การย้อนกลับศูนย์ข้อมูลหลายแห่งจะเป็นไปตามแนวทางศูนย์ข้อมูลต่อศูนย์ข้อมูล (DC ต่อ DC) วิธีการนี้จะเปลี่ยนเส้นทางการรับส่งข้อมูลจากศูนย์ข้อมูลที่ทำการย้อนกลับไปยังศูนย์ข้อมูลอื่นๆ ที่ใช้งานได้ เพื่อให้มั่นใจว่ากระบวนการย้อนกลับของ Cassandra, Management Server และโหนดรันไทม์จะควบคุมและแยกออกจากกันได้เพื่อไม่ให้การรับส่งข้อมูลหยุดชะงัก

ดูรายละเอียดได้ที่ส่วนการอัปเดตเปลี่ยนกลับเป็น Cassandra 3.11.16

ขั้นตอนที่ 0: สถานะเริ่มต้น

คอมโพเนนต์ Zookeeper, Postgres และ LDAP ได้รับการอัปเกรดเป็นเวอร์ชัน 4.52.02 แล้ว Edge สำหรับคลัสเตอร์ระบบคลาวด์ส่วนตัวทำงานได้อย่างเสถียร หากจำเป็นต้องมีการย้อนกลับ ระบบจะย้อนกลับคลัสเตอร์ไปยังสถานะนี้
Cassandra ใน Apigee ที่ใช้เวอร์ชัน 2.1.22
คอมโพเนนต์ Edge

เซิร์ฟเวอร์การจัดการที่สื่อสารกับ Cassandra ผ่านโปรโตคอล Thrift เวอร์ชันเก่า
เซิร์ฟเวอร์รันไทม์ (โปรแกรมประมวลผลข้อความและเราเตอร์) ที่สื่อสารกับ Cassandra ผ่านโปรโตคอล Thrift เวอร์ชันเก่า

สถานะรันไทม์ในขั้นตอนนี้	สถานะการจัดการในขั้นตอนนี้
รันไทม์ทํางานได้เต็มรูปแบบ	การจัดการทํางานได้เต็มรูปแบบ

ขั้นตอนที่ 1: เตรียมพร้อมสำหรับการอัปเกรด

ขั้นตอนด้านล่างนี้นอกเหนือจากไฟล์มาตรฐานที่คุณสร้างโดยทั่วไป เช่น ไฟล์การกําหนดค่ามาตรฐานของ Apigee เพื่อเปิดใช้การอัปเกรดคอมโพเนนต์

เปลี่ยน Cassandra ให้ใช้ LeveledCompactionStrategy
สํารองข้อมูล Cassandra โดยใช้ Apigee
ถ่ายภาพหน้าจอ VM ของโหนด Cassandra (หากเป็นไปได้)
สร้างไฟล์การกําหนดค่าการอัปเกรด Cassandra ในโหนด Cassandra แต่ละโหนดที่ /opt/apigee/apigee-cassandra/cass_upgrade.conf โดยมีเนื้อหาดังต่อไปนี้
```
# IP Address of node
HOSTIP=10.0.0.1

# Username for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_USERNAME=<cassuser>

# Password for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_PASSWORD=<casspass>

# Port for connecting to Cassandra via thrift. Optional. Defaults to 9160 if skipped.
CASS_PORT=9160

# Port for connecting to Cassandra via CQL. Optional. Defaults to 9042 if skipped.
CASS_CQL_PORT=9042

# Directory to be used by Cassandra upgrade scripts. Optional. Defaults to /tmp/cass_upgrade_scripts if skipped.
# Note that if upgrade is successful, this directory is deleted via root user - so provide a directory accordingly.
CASS_TMP_DIR=/tmp/cass_upgrade_scripts
    
```
หากสร้างไฟล์ที่ /opt/apigee/apigee-cassandra/cass_upgrade.conf ไม่ได้ ให้สร้างไฟล์ /opt/silent.conf ที่มีเนื้อหาเดียวกันในแต่ละโหนด Cassandra
ข้อควรระวัง: โปรแกรมติดตั้งการอัปเกรดของ Apigee จะค้นหาไฟล์ในตำแหน่งที่ระบุไว้ข้างต้น หากไฟล์ไม่อยู่ในตำแหน่งใดตำแหน่งหนึ่งที่ระบุไว้ข้างต้น การอัปเกรดจะไม่สำเร็จพร้อมแสดงข้อความดังต่อไปนี้
```
could not read env location: '/opt/apigee/apigee-cassandra/cass_upgrade.conf'
file does not exist or cannot be sourced
could not read env location: '/opt/silent.conf'
file does not exist or cannot be sourced
```
ในกรณีนี้ การอัปเกรดจะล้มเหลว แต่บริการ Cassandra ในโหนดมีแนวโน้มที่จะอยู่ในสถานะหยุดทำงาน คุณสามารถเริ่มบริการ Cassandra ได้ตามปกติและลองอัปเกรดอีกครั้งโดยวางไฟล์การกําหนดค่าไว้ในตําแหน่งใดก็ได้ตามที่คาดไว้ นอกจากนี้ หากพบไฟล์แต่การกําหนดค่าที่ระบุไม่ถูกต้อง (เช่น ข้อมูลเข้าสู่ระบบ Cassandra ไม่ถูกต้อง) การอัปเกรดจะล้มเหลวพร้อมข้อผิดพลาดดังต่อไปนี้
```
Error in PREIN scriptlet in rpm package apigee-cassandra-X.XX.XX-X.X.XXXX.noarch
```
ในกรณีนี้ ให้เริ่มบริการ Cassandra ในทำนองเดียวกันหากหยุดทำงานเมื่อการอัปเกรดไม่สำเร็จ แล้วลองอัปเกรดอีกครั้งหลังจากแก้ไขการกําหนดค่าในไฟล์
หากคุณใช้ฟีเจอร์ SmartDocs ของพอร์ทัลนักพัฒนาแอป Apigee Drupal 7 ให้ส่งออกโมเดลแต่ละรายการโดยดาวน์โหลดในรูปแบบ JSON จาก UI ของพอร์ทัลนักพัฒนาแอป คุณจะต้องนำเข้าโมเดลเหล่านี้กลับไปยัง Apigee หลังจากที่อัปเดตเซิร์ฟเวอร์การจัดการแล้ว
ตรวจสอบว่าพอร์ต 9160 และ 9042 เข้าถึงได้จากคอมโพเนนต์ Edge ทั้งหมดไปยังโหนด Cassandra หากยังไม่มี ดูข้อมูลเพิ่มเติมได้ที่ข้อกำหนดเกี่ยวกับพอร์ต

ข้อควรระวัง: ขั้นตอนเหล่านี้ทั้งหมดมีความสำคัญต่อการอัปเกรด Cassandra เป็นเวอร์ชัน 3 เพื่อให้มั่นใจว่าข้อมูลจะสูญหายน้อยที่สุดหากจำเป็นต้องมีการย้อนกลับระหว่างการอัปเกรด และเพื่อให้มั่นใจว่าคุณจะสูญเสียข้อมูลหลังจากการอัปเกรด เช่น เอกสารประกอบ API ใน SmartDocs โปรดทำตามขั้นตอนเหล่านี้อย่างละเอียดและอย่าข้ามขั้นตอนใดขั้นตอนหนึ่ง

ขั้นตอนที่ 2: เปลี่ยนเส้นทางการรับส่งข้อมูลออกจากศูนย์ข้อมูลแห่งแรก

บล็อกรันไทม์ขาเข้าและการรับส่งข้อมูลการจัดการจากศูนย์ข้อมูลแห่งแรก
เปลี่ยนเส้นทางการรับส่งข้อมูลรันไทม์และ API การจัดการทั้งหมดไปยังศูนย์ข้อมูลอื่นๆ ที่ใช้งานได้
ตรวจสอบว่า DC อื่นๆ จัดการรันไทม์และการรับส่งข้อมูลการจัดการได้สําเร็จ

ขั้นตอนที่ 3: อัปเกรดโหนด Cassandra ทั้งหมดในศูนย์ข้อมูลแห่งแรก

อัปเกรดโหนด Cassandra ทั้งหมดในศูนย์ข้อมูลทีละโหนด เรียกใช้คําสั่งต่อไปนี้ทีละโหนด
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
เมื่ออัปเดตโหนดแล้ว ให้เรียกใช้คําสั่งต่อไปนี้ในโหนดเพื่อเรียกใช้การตรวจสอบบางอย่างก่อนดําเนินการต่อ
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
```
คำสั่งข้างต้นจะแสดงผลประมาณนี้
```
Cassandra version is verified - [cqlsh 5.0.1 | Cassandra 3.11.16 | CQL spec 3.4.4 | Native protocol v3] Metadata is verified
```
เรียกใช้คำสั่ง post_upgrade ต่อไปนี้ในโหนด Cassandra แต่ละโหนดทีละโหนดหลังจากการอัปเกรดเสร็จสมบูรณ์
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
```

สถานะรันไทม์ในขั้นตอนนี้	สถานะการจัดการในขั้นตอนนี้
การเข้าชมรันไทม์ที่ถูกบล็อกในศูนย์ข้อมูลที่อัปเกรด รันไทม์ทํางานได้อย่างสมบูรณ์ในศูนย์ข้อมูลอื่นๆ	การเข้าชมเพื่อการจัดการถูกบล็อกในศูนย์ข้อมูลที่อัปเกรด ฟังก์ชันการจัดการต่อไปนี้จะมีประสิทธิภาพลดลงหลังจากอัปเกรด Cassandra ในศูนย์ข้อมูลอื่นๆ Management API เพื่อสร้างผลิตภัณฑ์ API ที่มีสภาพแวดล้อม Management API เพื่ออัปเดตผลิตภัณฑ์ API ที่มีสภาพแวดล้อม Management API เพื่อลบองค์กร

สถานะรันไทม์ในขั้นตอนนี้

สถานะการจัดการในขั้นตอนนี้

การเข้าชมรันไทม์ที่ถูกบล็อกในศูนย์ข้อมูลที่อัปเกรด
รันไทม์ทํางานได้อย่างสมบูรณ์ในศูนย์ข้อมูลอื่นๆ

การเข้าชมเพื่อการจัดการถูกบล็อกในศูนย์ข้อมูลที่อัปเกรด
ฟังก์ชันการจัดการต่อไปนี้จะมีประสิทธิภาพลดลงหลังจากอัปเกรด Cassandra ในศูนย์ข้อมูลอื่นๆ

ขั้นตอนที่ 4: อัปเกรดโหนดการจัดการทั้งหมดในศูนย์ข้อมูลแห่งแรก

คำเตือน: ในระหว่างการอัปเกรดโหนดเซิร์ฟเวอร์การจัดการ คุณอาจเห็นข้อความคำเตือนด้านล่าง และการอัปเกรดเซิร์ฟเวอร์การจัดการอาจใช้เวลานานขึ้น อย่างไรก็ตาม คุณไม่จำเป็นต้องสนใจคำเตือนดังกล่าว

Warning:schema version mismatch detected; check the schema versions of your nodes in system.local and system.peers.

ในขั้นตอนต่อๆ ไป คุณจะต้องเรียกใช้การตั้งค่าโหนดเซิร์ฟเวอร์การจัดการอีกครั้ง ซึ่งจะไม่เกิดคำเตือนดังกล่าว

อัปเกรดโหนดการจัดการทั้งหมดในศูนย์ข้อมูล โดยทำดังนี้

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

สถานะรันไทม์ในขั้นตอนนี้	สถานะการจัดการในขั้นตอนนี้
การเข้าชมรันไทม์ที่ถูกบล็อกในศูนย์ข้อมูลที่อัปเกรด รันไทม์ทํางานได้เต็มรูปแบบ	การเข้าชมเพื่อการจัดการถูกบล็อกในศูนย์ข้อมูลที่อัปเกรด ฟังก์ชันการจัดการต่อไปนี้จะมีประสิทธิภาพลดลงหลังจากอัปเกรด Cassandra Management API เพื่อสร้างผลิตภัณฑ์ API ที่มีสภาพแวดล้อม Management API เพื่ออัปเดตผลิตภัณฑ์ API ที่มีสภาพแวดล้อม Management API เพื่อลบองค์กร

สถานะรันไทม์ในขั้นตอนนี้

สถานะการจัดการในขั้นตอนนี้

การเข้าชมรันไทม์ที่ถูกบล็อกในศูนย์ข้อมูลที่อัปเกรด
รันไทม์ทํางานได้เต็มรูปแบบ

การเข้าชมเพื่อการจัดการถูกบล็อกในศูนย์ข้อมูลที่อัปเกรด
ฟังก์ชันการจัดการต่อไปนี้จะมีประสิทธิภาพลดลงหลังจากอัปเกรด Cassandra

ขั้นตอนที่ 5: อัปเกรดโหนดรันไทม์ทั้งหมดในศูนย์ข้อมูลแห่งแรก

อัปเกรดเราเตอร์และโหนดโปรแกรมประมวลผลข้อความทั้งหมดในศูนย์ข้อมูลทีละรายการ ดังนี้

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

สถานะรันไทม์ในขั้นตอนนี้	สถานะการจัดการในขั้นตอนนี้
การเข้าชมรันไทม์ที่ถูกบล็อกในศูนย์ข้อมูลที่อัปเกรด รันไทม์ทํางานได้อย่างสมบูรณ์ในศูนย์ข้อมูลอื่นๆ	บล็อกการรับส่งข้อมูลการจัดการในศูนย์ข้อมูลที่อัปเกรด ฟังก์ชันการจัดการต่อไปนี้จะมีประสิทธิภาพลดลงหลังจากอัปเกรด Cassandra ในศูนย์ข้อมูลอื่นๆ Management API เพื่อสร้างผลิตภัณฑ์ API ที่มีสภาพแวดล้อม Management API เพื่ออัปเดตผลิตภัณฑ์ API ที่มีสภาพแวดล้อม Management API เพื่อลบองค์กร

สถานะรันไทม์ในขั้นตอนนี้

สถานะการจัดการในขั้นตอนนี้

การเข้าชมรันไทม์ที่ถูกบล็อกในศูนย์ข้อมูลที่อัปเกรด
รันไทม์ทํางานได้อย่างสมบูรณ์ในศูนย์ข้อมูลอื่นๆ

บล็อกการรับส่งข้อมูลการจัดการในศูนย์ข้อมูลที่อัปเกรด
ฟังก์ชันการจัดการต่อไปนี้จะมีประสิทธิภาพลดลงหลังจากอัปเกรด Cassandra ในศูนย์ข้อมูลอื่นๆ

ขั้นตอนที่ 6: เปลี่ยนเส้นทางการเข้าชมกลับไปที่ศูนย์ข้อมูลแห่งแรก

เมื่ออัปเกรดศูนย์ข้อมูลแรกด้วย Cassandra, คอมโพเนนต์รันไทม์ และเซิร์ฟเวอร์การจัดการแล้ว ให้เปิดใช้รันไทม์และการรับส่งข้อมูลการจัดการไปยังศูนย์ข้อมูลแรกอีกครั้ง
ตรวจสอบว่ารันไทม์และการรับส่งข้อมูลการจัดการใน DC ต่างๆ ทำงานสำเร็จ

ขั้นตอนที่ 7: อัปเกรดศูนย์ข้อมูลอื่นๆ

ทำซ้ำขั้นตอนที่ 1 ถึงขั้นตอนที่ 6 ในศูนย์ข้อมูลที่เหลือทีละแห่งโดยเปลี่ยนเส้นทางการรับส่งข้อมูลออกจากศูนย์ข้อมูลดังกล่าว อัปเดตซอฟต์แวร์ Apigee และเปิดใช้การรับส่งข้อมูลในศูนย์ข้อมูลดังกล่าวอีกครั้ง

ขั้นตอนที่ 8: เรียกใช้ขั้นตอนการอัปเกรดอีกครั้งในโหนดการจัดการทั้งหมด

เรียกใช้คำสั่งอัปเกรดต่อไปนี้อีกครั้งในโหนดการจัดการทั้งหมดในศูนย์ข้อมูล

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

ขั้นตอนที่ 9 - [ไม่บังคับ] นําเข้า SmartDocs ที่ส่งออกก่อนหน้านี้

เมื่ออัปเกรดเซิร์ฟเวอร์การจัดการทั้งหมดแล้ว คุณจะนําเข้าโมเดลเอกสารอัจฉริยะที่ส่งออกในขั้นตอนที่ 1 ได้ คุณตัดสินใจดำเนินการในภายหลังได้

คุณต้องทำขั้นตอนนี้เฉพาะในกรณีที่ใช้พอร์ทัลนักพัฒนาซอฟต์แวร์ Drupal 7 และใช้ฟีเจอร์ SmartDocs

สถานะรันไทม์ในขั้นตอนนี้	สถานะการจัดการในขั้นตอนนี้
รันไทม์ทํางานได้เต็มรูปแบบ	การจัดการทํางานได้เต็มรูปแบบ

ขั้นตอนที่ 10 - วางตารางที่ไม่ได้ใช้

เรียกใช้คําสั่งต่อไปนี้เพื่อลบตารางเก่าที่ไม่ได้ใช้ออกจากคลัสเตอร์ Cassandra จนกว่าระบบจะเรียกใช้ คุณจะไม่สามารถใช้งานฟีเจอร์บางอย่างของ Cassandra (เช่น การตั้งค่าการตรวจสอบสิทธิ์ใหม่ - กลไกการตรวจสอบสิทธิ์แบบเก่าจะยังคงทำงานต่อไป) คำสั่งนี้จะทำงานได้บนโหนดเดียวในคลัสเตอร์เท่านั้น

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra drop_old_tables -f configFile

ขั้นตอนที่ 11 - อัปเกรด Edge และคอมโพเนนต์อื่นๆ ที่เหลือทั้งหมดสำหรับ Private Cloud 4.52.02

อัปเกรดโหนด edge-qpid-server และ edge-postgres-server ที่เหลือทั้งหมดในทุกภูมิภาคทีละโหนด

ในขั้นตอนนี้ หากคุณจะอัปเกรดจากเวอร์ชันที่เก่ากว่า Edge for Private Cloud 4.52.01 ให้ทำตามขั้นตอนเพิ่มเติมด้านล่างเพื่ออัปเกรด Qpid และ Postgres ตามลำดับ และอัปเกรดคอมโพเนนต์ที่เหลือตามขั้นตอนเหล่านี้

อัปเกรดเป็น Qpid J-Broker

แม้ว่า Edge for Private Cloud 4.52.02 จะไม่รวมการอัปเกรด Qpid แต่หากคุณอัปเกรดจากเวอร์ชันที่เก่ากว่า 4.52.01 คุณต้องทําตามขั้นตอนเพื่ออัปเกรด QPID

หากจะอัปเกรดจาก Edge for Private Cloud 4.51.00 หรือ 4.52.00 เป็น 4.52.02 คุณต้องทำตามขั้นตอนการอัปเกรด Qpid เพิ่มเติม โปรดดูส่วนอัปเกรด Qpid หากคุณจะอัปเกรดจากเวอร์ชัน 4.51.00 หรือ 4.52.00 เป็น 4.52.02
หากคุณจะอัปเกรดจาก Edge for Private Cloud 4.52.01 เป็น 4.52.02 คุณควรใช้ Qpid Broker เวอร์ชันล่าสุดอยู่แล้ว และไม่จำเป็นต้องทำตามขั้นตอนเพิ่มเติมในการอัปเกรด Qpid

UI ของ Edge เวอร์ชันใหม่

ส่วนนี้จะแสดงข้อควรพิจารณาเกี่ยวกับ UI ของ Edge ดูข้อมูลเพิ่มเติมได้ที่UI ใหม่ของ Edge สำหรับระบบคลาวด์ส่วนตัว

ติดตั้ง UI ของ Edge

หลังจากการติดตั้งครั้งแรกเสร็จสมบูรณ์แล้ว Apigee ขอแนะนำให้คุณติดตั้ง Edge UI ซึ่งเป็นอินเทอร์เฟซผู้ใช้ที่ปรับปรุงแล้วสำหรับนักพัฒนาซอฟต์แวร์และผู้ดูแลระบบของ Apigee Edge สําหรับระบบคลาวด์ส่วนตัว

โปรดทราบว่า UI ของ Edge กำหนดให้คุณปิดใช้การตรวจสอบสิทธิ์พื้นฐานและใช้ IDP เช่น SAML หรือ LDAP

ดูข้อมูลเพิ่มเติมได้ที่ติดตั้ง UI ใหม่ของ Edge

อัปเดต UI ของ Edge

หากต้องการอัปเดตคอมโพเนนต์ UI ของ Edge ให้พิจารณาเวอร์ชันของ Edge สำหรับระบบคลาวด์ส่วนตัวที่คุณอัปเกรดจาก

จาก 4.51.00 เป็น 4.52.00 (ติดตั้ง UI ใหม่ของ Edge ไว้แล้ว): ใช้วิธีการอัปเกรดในส่วนนี้สำหรับคอมโพเนนต์ edge-management-ui

อัปเดตด้วย mTLS ของ Apigee

หากต้องการอัปเดต Apigee mTLS ให้ทําตามขั้นตอนต่อไปนี้

การย้อนกลับการอัปเดต

ในกรณีที่อัปเดตไม่สำเร็จ คุณสามารถลองแก้ไขปัญหา แล้วเรียกใช้ update.sh อีกครั้ง คุณเรียกใช้การอัปเดตได้หลายครั้งและระบบจะอัปเดตต่อจากจุดที่ค้างไว้

หากการอัปเดตไม่สำเร็จและคุณต้องย้อนกลับไปใช้เวอร์ชันก่อนหน้า โปรดดูวิธีการโดยละเอียดที่หัวข้อย้อนกลับไปใช้ 4.52.00

หมายเหตุ: โทโปโลจี แบบรวมทั้งหมด (AIO) และแบบสแตนด์อโลน (2 โฮสต์) ของ Edge ออกแบบมาเพื่อเริ่มต้นใช้งานและสร้างต้นแบบสภาพแวดล้อม ไม่ใช่สำหรับการใช้งานจริง ดังนั้นจึงไม่มีขั้นตอนการย้อนกลับสำหรับโทโปโลยี แบบรวมทั้งหมด (AIO) และแบบสแตนด์อโลน (2 โหนด) ในกรณีที่การอัปเดตโทโปโลยีเหล่านี้ไม่สำเร็จ และการอัปเดตอีกครั้งไม่สามารถแก้ปัญหาได้ ตัวเลือกที่ง่ายที่สุดคือการติดตั้ง 4.52.02 ใหม่

การบันทึกข้อมูลอัปเดต

โดยค่าเริ่มต้น ยูทิลิตี update.sh จะเขียนข้อมูลบันทึกไปยังตำแหน่งต่อไปนี้

/opt/apigee/var/log/apigee-setup/update.log

หากผู้ใช้ยูทิลิตี update.sh ไม่มีสิทธิ์เข้าถึงไดเรกทอรีดังกล่าว ระบบจะเขียนบันทึกลงในไดเรกทอรี /tmp เป็นไฟล์ชื่อ update_username.log

หากไม่มีสิทธิ์เข้าถึง /tmp ยูทิลิตี update.sh จะใช้งานไม่ได้

การอัปเดตแบบไม่มีช่วงพัก

การอัปเดตแบบไม่มีเวลาหยุดทำงานหรือการอัปเดตแบบต่อเนื่องช่วยให้คุณอัปเดตการติดตั้ง Edge ได้โดยไม่ต้องหยุดให้บริการ Edge

การอัปเดตแบบไม่มีเวลาหยุดทำงานทำได้เฉพาะกับการกำหนดค่าที่มีโหนด 5 ตัวขึ้นไป

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

อัปเดตเครื่องตามลำดับที่ถูกต้องสำหรับการติดตั้งตามที่อธิบายไว้ลําดับการอัปเดตเครื่อง
เมื่อถึงเวลาอัปเดตเราเตอร์ ให้เลือกเราเตอร์เครื่องใดเครื่องหนึ่งและทำให้เข้าถึงไม่ได้ ตามที่อธิบายไว้ในการเปิด/ปิดการเข้าถึงเซิร์ฟเวอร์ (Message Processor/Router)
อัปเดตเราเตอร์ที่เลือกและคอมโพเนนต์ Edge อื่นๆ ทั้งหมดในเครื่องเดียวกับเราเตอร์ การกําหนดค่า Edge ทั้งหมดจะแสดงเราเตอร์และโปรแกรมประมวลผลข้อความในโหนดเดียวกัน
ทำให้เราเตอร์เข้าถึงได้อีกครั้ง
ทำตามขั้นตอนที่ 2 ถึง 4 ซ้ำสำหรับเราเตอร์ที่เหลือ
อัปเดตเครื่องที่เหลือในการติดตั้งต่อ

โปรดดำเนินการต่อไปนี้ก่อนและหลังการอัปเดต

ในโหนดเราเตอร์และตัวประมวลผลข้อความแบบรวม
- ก่อนอัปเดต ให้ทำดังนี้
  1. ทำให้เข้าถึงเราเตอร์ไม่ได้
  2. ทำให้เข้าถึง Message Processor ไม่ได้
- หลังจากอัปเดตแล้ว ให้ทำดังนี้
  1. ทำให้ Message Processor เข้าถึงได้
  2. ทำให้เข้าถึงเราเตอร์ได้
ในโหนดเราเตอร์เดียว ให้ทำดังนี้
- ก่อนอัปเดต ให้ทำให้เราเตอร์เข้าถึงไม่ได้
- หลังจากอัปเดตแล้ว ให้ทำให้เข้าถึงเราเตอร์ได้
ในโหนดผู้ประมวลผลข้อความเดี่ยว ให้ทำดังนี้
- ก่อนอัปเดต ให้ทำให้ไม่สามารถเข้าถึงโปรแกรมประมวลผลข้อความได้
- หลังจากอัปเดตแล้ว ให้ทำให้ผู้ประมวลผลข้อความเข้าถึงได้

ใช้ไฟล์การกําหนดค่าแบบเงียบ

คุณต้องส่งไฟล์การกําหนดค่าแบบเงียบไปยังคําสั่งอัปเดต ไฟล์การกำหนดค่าแบบเงียบควรเป็นไฟล์เดียวกับที่คุณใช้ติดตั้ง Edge 4.50.00 หรือ 4.51.00

อัปเดตเป็น 4.52.02 ในโหนดที่มีการเชื่อมต่ออินเทอร์เน็ตภายนอก

ใช้ขั้นตอนต่อไปนี้เพื่ออัปเดตคอมโพเนนต์ Edge ในโหนด

หากมี ให้ปิดใช้งานงาน cron ที่กําหนดค่าให้ดําเนินการซ่อมใน Cassandra จนกว่าการอัปเดตจะเสร็จสมบูรณ์
เข้าสู่ระบบโหนดในฐานะรูทเพื่อติดตั้ง RPM ของ Edge
หมายเหตุ: แม้ว่าการติดตั้ง RPM จะต้องใช้สิทธิ์เข้าถึงระดับรูท แต่คุณก็กำหนดค่า Edge ได้โดยไม่ต้องมีสิทธิ์เข้าถึงระดับรูท
ติดตั้ง yum-utils และ yum-plugin-priorities โดยทำดังนี้
หมายเหตุ: หากระบบปฏิบัติการเป็น RHEL 8.0 - 8.6 ให้ข้ามขั้นตอนนี้
```
sudo yum install yum-utils
sudo yum install yum-plugin-priorities
```
ปิดใช้ SELinux ตามที่อธิบายไว้ในติดตั้งยูทิลิตี apigee-setup ของ Edge
หากติดตั้งใน Oracle 7.x ให้ใช้คำสั่งต่อไปนี้
```
sudo yum-config-manager --enable ol7_optional_latest
```

หากติดตั้งใน AWS ให้เรียกใช้คำสั่งต่อไปนี้ yum-configure-manager

yum update rh-amazon-rhui-client.noarch
sudo yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

หากคุณใช้ Edge 4.51.00 อยู่ ให้ทำดังนี้
1. ดาวน์โหลดไฟล์ bootstrap_4.52.02.sh ของ Edge ไปยัง /tmp/bootstrap_4.52.02.sh
```
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
```
2. ติดตั้งยูทิลิตีและทรัพยากร Dependency ของ Edge 4.52.02 apigee-service โดยเรียกใช้คำสั่งต่อไปนี้
```
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
```
  โดยที่ uName:pWord คือชื่อผู้ใช้และรหัสผ่านที่คุณได้รับจาก Apigee หากละเว้น pWord ระบบจะแจ้งให้คุณป้อน
  
  โดยค่าเริ่มต้น โปรแกรมติดตั้งจะตรวจสอบว่าคุณได้ติดตั้ง Java 1.8 แล้ว หากไม่ โปรแกรมติดตั้งจะติดตั้งให้คุณ
  
  ใช้ตัวเลือก JAVA_FIX เพื่อระบุวิธีจัดการการติดตั้ง Java JAVA_FIX จะใช้ค่าต่อไปนี้
  - I: ติดตั้ง OpenJDK 1.8 (ค่าเริ่มต้น)
  - C: ดำเนินการต่อโดยไม่ติดตั้ง Java
  - Q: ออก สำหรับตัวเลือกนี้ คุณต้องติดตั้ง Java ด้วยตนเอง
3. ใช้ apigee-service เพื่ออัปเดตยูทิลิตี apigee-setup ดังที่แสดงในตัวอย่างต่อไปนี้
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
4. อัปเดตยูทิลิตี apigee-validate ในเซิร์ฟเวอร์การจัดการ ดังที่แสดงในตัวอย่างต่อไปนี้
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
5. อัปเดตยูทิลิตี apigee-provision ในเซิร์ฟเวอร์การจัดการ ดังที่แสดงในตัวอย่างต่อไปนี้
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
6. เรียกใช้ยูทิลิตี update ในโหนดโดยดำเนินการตามคำสั่งต่อไปนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
  โดยทําตามลําดับที่อธิบายไว้ในลําดับการอัปเดตเครื่อง
  
  สถานที่:
  - component คือคอมโพเนนต์ Edge ที่จะอัปเดต ค่าที่เป็นไปได้ ได้แก่
    - cs: Cassandra
    - edge: คอมโพเนนต์ Edge ทั้งหมดยกเว้น UI ของ Edge: เซิร์ฟเวอร์การจัดการ, โปรแกรมประมวลผลข้อความ, รูทเตอร์, เซิร์ฟเวอร์ Qpid, เซิร์ฟเวอร์ Postgres
    - ldap: OpenLDAP
    - ps: postgresql
    - qpid: qpidd
    - sso: Apigee SSO (หากคุณติดตั้ง SSO)
    - ue: UI ของ Edge เวอร์ชันใหม่
    - ui: UI ของ Edge แบบคลาสสิก
    - zk: Zookeeper
  - configFile คือไฟล์การกําหนดค่าเดียวกับที่คุณใช้กําหนดคอมโพเนนต์ Edge ในระหว่างการติดตั้ง 4.50.00 หรือ 4.51.00
  คุณสามารถเรียกใช้ update.sh กับคอมโพเนนต์ทั้งหมดได้โดยตั้งค่า component เป็น "all" แต่ต้องมีโปรไฟล์การติดตั้งแบบ "All-in-One" (AIO) ของ Edge เท่านั้น เช่น
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config
```
7. รีสตาร์ทคอมโพเนนต์ UI ของ Edge ในโหนดทั้งหมดที่ใช้คอมโพเนนต์ดังกล่าว หากยังไม่ได้ดำเนินการ
```
/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
```
8. ทดสอบการอัปเดตโดยเรียกใช้ยูทิลิตี apigee-validate ในเซิร์ฟเวอร์การจัดการ ตามที่อธิบายไว้ในทดสอบการติดตั้ง

หากในภายหลังคุณตัดสินใจที่จะเปลี่ยนกลับไปใช้เวอร์ชันก่อนหน้า ให้ทำตามขั้นตอนที่อธิบายไว้ในเปลี่ยนกลับไปใช้ 4.52.02

อัปเดตเป็น 4.52.02 จากที่เก็บข้อมูลในเครื่อง

หากโหนด Edge อยู่หลังไฟร์วอลล์ หรือไม่ได้รับอนุญาตให้เข้าถึงที่เก็บ Apigee ผ่านอินเทอร์เน็ต คุณจะอัปเดตได้จากที่เก็บข้อมูลในเครื่องหรือมิเรอร์ของที่เก็บ Apigee#heading

หลังจากสร้างที่เก็บข้อมูล Edge ในพื้นที่แล้ว คุณจะมี 2 ตัวเลือกในการอัปเดต Edge จากที่เก็บข้อมูลในเครื่อง ดังนี้

สร้างไฟล์ .tar ของที่เก็บ คัดลอกไฟล์ .tar ไปยังโหนด แล้วอัปเดต Edge จากไฟล์ .tar
ติดตั้งเว็บเซิร์ฟเวอร์บนโหนดที่มีที่เก็บข้อมูลในเครื่องเพื่อให้โหนดอื่นๆ เข้าถึงได้ Apigee มีเว็บเซิร์ฟเวอร์ Nginx ให้ใช้งาน หรือคุณจะใช้เว็บเซิร์ฟเวอร์ของคุณเองก็ได้

วิธีอัปเดตจากที่เก็บข้อมูล 4.52.02 ในพื้นที่

สร้างที่เก็บข้อมูล 4.52.02 ในพื้นที่ตามที่อธิบายไว้ใน "สร้างที่เก็บข้อมูล Apigee ในพื้นที่" ที่ ติดตั้งยูทิลิตี apigee-setup ของ Edge
หมายเหตุ: หากมีที่เก็บอยู่แล้ว คุณสามารถเพิ่มที่เก็บ 4.52.02 ลงในที่เก็บดังกล่าวได้ ตามที่อธิบายไว้ใน "อัปเดตที่เก็บ Apigee ในพื้นที่" ที่หัวข้อติดตั้งยูทิลิตี apigee-setup ของ Edge
วิธีติดตั้ง apigee-service จากไฟล์ .tar
1. ในโหนดที่มีที่เก็บข้อมูลในเครื่อง ให้ใช้คำสั่งต่อไปนี้เพื่อจัดแพ็กเกจที่เก็บข้อมูลในเครื่องเป็นไฟล์ .tar ไฟล์เดียวชื่อ /opt/apigee/data/apigee-mirror/apigee-4.52.02.tar.gz
```
/opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
```
2. คัดลอกไฟล์ .tar ไปยังโหนดที่ต้องการอัปเดต Edge เช่น คัดลอกไปยังไดเรกทอรี /tmp ในโหนดใหม่
3. ในโหนดใหม่ ให้แตกไฟล์ไปยังไดเรกทอรี /tmp โดยทำดังนี้
```
tar -xzf apigee-4.52.02.tar.gz
```
  คำสั่งนี้จะสร้างไดเรกทอรีใหม่ชื่อ repos ในไดเรกทอรีที่มีไฟล์ .tar เช่น /tmp/repos
4. ติดตั้งยูทิลิตี apigee-service ของ Edge และไลบรารีต่อไปนี้จาก /tmp/repos
```
sudo bash /tmp/repos/bootstrap_4.52.02.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
```
  โปรดทราบว่าคุณใส่เส้นทางไปยังไดเรกทอรี repos ในคําสั่งนี้
วิธีติดตั้ง apigee-service โดยใช้เว็บเซิร์ฟเวอร์ Nginx
1. กำหนดค่าเว็บเซิร์ฟเวอร์ Nginx ตามที่อธิบายไว้ใน "ติดตั้งจากรีโปโดยใช้เว็บเซิร์ฟเวอร์ Nginx" ที่หัวข้อติดตั้งยูทิลิตี apigee-setup
2. ในโหนดระยะไกล ให้ดาวน์โหลดไฟล์ bootstrap_4.52.02.sh ของ Edge ไปยัง /tmp/bootstrap_4.52.02.sh
```
/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
```
  โดยที่ uName:pWord คือชื่อผู้ใช้และรหัสผ่านที่คุณตั้งไว้ก่อนหน้านี้สําหรับที่เก็บ และ remoteRepo คือที่อยู่ IP หรือชื่อ DNS ของโหนดที่เก็บ
3. ในโหนดระยะไกล ให้ติดตั้งยูทิลิตี apigee-setup ของ Edge และข้อกําหนดต่อไปนี้
```
sudo bash /tmp/bootstrap_4.52.02.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
```
  โดยที่ uName:pWord คือชื่อผู้ใช้และรหัสผ่านของรีโป
ใช้ apigee-service เพื่ออัปเดตยูทิลิตี apigee-setup ดังที่แสดงในตัวอย่างต่อไปนี้
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update 
```
อัปเดตยูทิลิตี apigee-validate ในเซิร์ฟเวอร์การจัดการ ดังที่แสดงในตัวอย่างต่อไปนี้
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
อัปเดตยูทิลิตี apigee-provision ในเซิร์ฟเวอร์การจัดการ ดังที่แสดงในตัวอย่างต่อไปนี้
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
เรียกใช้ยูทิลิตี update ในโหนดตามลำดับที่อธิบายไว้ในลำดับการอัปเดตเครื่อง
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
สถานที่:
- component คือคอมโพเนนต์ Edge ที่จะอัปเดต โดยทั่วไปแล้ว คุณจะต้องอัปเดตคอมโพเนนต์ต่อไปนี้
  - cs: Cassandra
  - edge: คอมโพเนนต์ Edge ทั้งหมดยกเว้น UI ของ Edge: เซิร์ฟเวอร์การจัดการ เครื่องประมวลผลข้อความ รูทเตอร์ เซิร์ฟเวอร์ Qpid และเซิร์ฟเวอร์ Postgres
  - ldap: OpenLDAP
  - ps: postgresql
  - qpid: qpidd
  - sso: Apigee SSO (หากคุณติดตั้ง SSO)
  - ue UI ของ Edge ใหม่
  - ui: UI ของ Edge แบบคลาสสิก
  - zk: Zookeeper
- configFile คือไฟล์การกําหนดค่าเดียวกับที่คุณใช้กําหนดคอมโพเนนต์ Edge ในระหว่างการติดตั้ง 4.50.00 หรือ 4.51.00
  หมายเหตุ: ผู้ใช้ "apigee" ต้องอ่านไฟล์การกําหนดค่าได้ หากต้องการเปลี่ยนเจ้าของ ให้ใช้คำสั่งต่อไปนี้
```
chown apigee:apigee configFile
```
คุณสามารถเรียกใช้ update.sh กับคอมโพเนนต์ทั้งหมดได้โดยตั้งค่า component เป็น "all" แต่ต้องมีโปรไฟล์การติดตั้งแบบ "All-in-One" (AIO) ของ Edge เท่านั้น เช่น
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config
```
รีสตาร์ทคอมโพเนนต์ UI ในโหนดทั้งหมดที่ใช้อยู่ หากยังไม่ได้ดำเนินการ
```
/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
```
ทดสอบการอัปเดตโดยเรียกใช้ยูทิลิตี apigee-validate ในเซิร์ฟเวอร์การจัดการ ตามที่อธิบายไว้ในทดสอบการติดตั้ง

หากในภายหลังคุณตัดสินใจที่จะเปลี่ยนกลับการอัปเดต ให้ทำตามขั้นตอนที่อธิบายไว้ในเปลี่ยนกลับเป็น 4.52.02

ลำดับการอัปเดตเครื่อง - อัปเกรดจาก 4.51.00 (หรือ) 4.52.00 (หรือ) 4.52.01

ลำดับที่คุณอัปเดตเครื่องในการติดตั้ง Edge มีความสำคัญ ดังนี้

คุณต้องอัปเดตโหนด ZooKeeper ทั้งหมดในศูนย์ข้อมูลก่อนอัปเกรดคอมโพเนนต์อื่นๆ ทั้งหมด หากจะอัปเกรดจาก Edge Private Cloud 4.51.00 (หรือ) 4.52.00 คุณจะต้องทําตามขั้นตอนเพิ่มเติมเพื่ออัปเกรด zookeeper ด้วย
คุณต้องอัปเดต Postgresql ในศูนย์ข้อมูลทั้งหมด หากอัปเกรดจาก Edge Private Cloud 4.51.00 คุณจะต้องทําตามขั้นตอนเพิ่มเติมเพื่ออัปเกรด postgres ด้วย
คุณต้องอัปเดตโหนด LDAP ในศูนย์ข้อมูลทั้งหมด
คุณต้องอัปเดตโหนด Cassandra, เซิร์ฟเวอร์การจัดการ, โปรแกรมประมวลผลข้อความ และเราเตอร์ทั้งหมดทีละศูนย์ข้อมูลจนกว่าศูนย์ข้อมูลทั้งหมดจะได้รับการอัปเกรด
คุณต้องอัปเดตคอมโพเนนต์ edge-qpid-server และ edge-postgres-server ในศูนย์ข้อมูลทั้งหมด
คุณต้องอัปเกรดโหนด Qpid ในศูนย์ข้อมูลทั้งหมด หากจะอัปเกรดจาก Edge Private Cloud 4.51.00 (หรือ) 4.52.00 คุณจะต้องทําตามขั้นตอนเพิ่มเติมเพื่ออัปเกรด Qpid ด้วย
อัปเดต UI ของ Edge และ UI ของ Edge เวอร์ชันใหม่ รวมถึงโหนด SSO ในศูนย์ข้อมูลทั้งหมด
คุณไม่จำเป็นต้องอัปเดตการสร้างรายได้แยกต่างหาก ระบบจะอัปเดตเมื่อคุณระบุตัวเลือก -c edge
หมายเหตุ: หลังจากอัปเดตคอมโพเนนต์ UI ของ Edge แล้ว คุณต้องรีสตาร์ทบริการ UI ของ Edge ตามที่อธิบายไว้ในวิธีการติดตั้งการอัปเดต

การอัปเกรดแบบสแตนด์อโลน 1 โหนด

วิธีอัปเกรดการกำหนดค่าแบบสแตนด์อโลน 1 โ nod เป็น 4.52.02

อัปเดตคอมโพเนนต์ทั้งหมด
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
```
(หากคุณติดตั้ง apigee-adminapi) อัปเดตยูทิลิตี apigee-adminapi โดยทำดังนี้
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

การอัปเกรดแบบสแตนด์อโลน 2 โหนด

อัปเดตคอมโพเนนต์ต่อไปนี้สําหรับการติดตั้งแบบสแตนด์อโลน 2 โหนด

ดูรายการโทโพโลยี Edge และจำนวนโหนดได้ที่โทโพโลยีการติดตั้ง

อัปเดต Zookeeper ในเครื่องที่ 1
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
```
อัปเดต Postgres ในเครื่องที่ 2 โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
อัปเดต LDAP ในเครื่องที่ 1 โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
อัปเดต Cassandra ในเครื่องที่ 1
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
อัปเดตคอมโพเนนต์ Edge ในเครื่องที่ 1 และ 2
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
อัปเดต Qpid ในเครื่องที่ 2
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
อัปเดต UI ในเครื่องที่ 1 โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
```
(หากคุณติดตั้ง apigee-adminapi) อัปเดตยูทิลิตี apigee-adminapi ในเครื่องที่ 1 แล้ว โดยทำดังนี้
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(หากคุณติดตั้ง Apigee SSO) อัปเดต Apigee SSO ในเครื่องที่ 1 โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
โดยที่ sso_config_file คือไฟล์การกําหนดค่าที่คุณสร้างเมื่อติดตั้ง SSO
รีสตาร์ทคอมโพเนนต์ UI ของ Edge ในเครื่องที่ 1 โดยทำดังนี้
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```

การอัปเกรด 5 โหนด

อัปเดตคอมโพเนนต์ต่อไปนี้สําหรับการติดตั้ง 5 โ nod

ดูรายการโทโพโลยี Edge และจำนวนโหนดได้ที่โทโพโลยีการติดตั้ง

อัปเดต ZooKeeper ในเครื่องที่ 1, 2 และ 3
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
```
อัปเดต Postgres ในเครื่องที่ 4
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```

อัปเดต Postgres ในเครื่อง 5

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

อัปเดต LDAP ในเครื่องที่ 1 โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
อัปเดต Cassandra ในเครื่องที่ 1, 2 และ 3
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
อัปเดตคอมโพเนนต์ Edge ในเครื่อง 1, 2, 3, 4, 5
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
อัปเดต Qpid ในเครื่องที่ 4
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```

อัปเดต Qpid ในเครื่อง 5

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

อัปเดต UI ของ Edge โดยทำดังนี้
- UI แบบคลาสสิก: หากคุณใช้ UI แบบคลาสสิก ให้อัปเดตคอมโพเนนต์ ui ในเครื่อง 1 ดังตัวอย่างต่อไปนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
```
- UI ของ Edge ใหม่: หากคุณติดตั้ง UI ของ Edge ใหม่ ให้อัปเดตคอมโพเนนต์ ue ในเครื่องที่เหมาะสม (อาจไม่ใช่เครื่องที่ 1)
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf
```
(หากคุณติดตั้ง apigee-adminapi) อัปเดตยูทิลิตี apigee-adminapi ในเครื่องที่ 1 แล้ว โดยทำดังนี้
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(หากคุณติดตั้ง Apigee SSO) อัปเดต Apigee SSO ในเครื่องที่ 1 โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
โดยที่ sso_config_file คือไฟล์การกําหนดค่าที่คุณสร้างขึ้นเมื่อติดตั้ง SSO
รีสตาร์ทคอมโพเนนต์ UI โดยทำดังนี้
- UI แบบคลาสสิก: หากคุณใช้ UI แบบคลาสสิก ให้รีสตาร์ทคอมโพเนนต์ edge-ui ในเครื่อง 1 ดังที่แสดงในตัวอย่างต่อไปนี้
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- UI ของ Edge ใหม่: หากคุณติดตั้ง UI ของ Edge ใหม่ ให้รีสตาร์ทคอมโพเนนต์ edge-management-ui ในเครื่องที่เหมาะสม (อาจไม่ใช่เครื่องที่ 1)
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```

การอัปเกรดคลัสเตอร์ 9 โหนด

อัปเดตคอมโพเนนต์ต่อไปนี้สําหรับการติดตั้งคลัสเตอร์ 9 นอต

ดูรายการโทโพโลยี Edge และจำนวนโหนดได้ที่โทโพโลยีการติดตั้ง

อัปเดต ZooKeeper ในเครื่องที่ 1, 2 และ 3
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
```

อัปเดต Postgres ในเครื่อง 8

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

อัปเดต Postgres ในเครื่อง 9

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

อัปเดต LDAP ในเครื่องที่ 1 โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
อัปเดต Cassandra ในเครื่องที่ 1, 2 และ 3
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
อัปเดตคอมโพเนนต์ Edge ในเครื่อง 1, 4, 5, 6, 7, 8 และ 9 ตามลําดับนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
อัปเดต Qpid ในเครื่อง 6 และ 7
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
อัปเดต UI ใหม่ (ue) หรือ UI แบบคลาสสิก (ui) ในเครื่องที่ 1 โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
```
(หากคุณติดตั้ง apigee-adminapi) อัปเดตยูทิลิตี apigee-adminapi ในเครื่องที่ 1 โดยทำดังนี้
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(หากคุณติดตั้ง Apigee SSO) อัปเดต Apigee SSO ในเครื่องที่ 1 โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
โดยที่ sso_config_file คือไฟล์การกําหนดค่าที่คุณสร้างขึ้นเมื่อติดตั้ง SSO
รีสตาร์ทคอมโพเนนต์ UI โดยทำดังนี้
- UI แบบคลาสสิก: หากคุณใช้ UI แบบคลาสสิก ให้รีสตาร์ทคอมโพเนนต์ edge-ui ในเครื่อง 1 ดังที่แสดงในตัวอย่างต่อไปนี้
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- UI ของ Edge ใหม่: หากคุณติดตั้ง UI ของ Edge ใหม่ ให้รีสตาร์ทคอมโพเนนต์ edge-management-ui ในเครื่องที่เหมาะสม (อาจไม่ใช่เครื่องที่ 1)
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```

การอัปเกรดคลัสเตอร์ 13 โหนด

อัปเดตคอมโพเนนต์ต่อไปนี้สําหรับการติดตั้งคลัสเตอร์ 13 นอต

ดูรายการโทโพโลยี Edge และจำนวนโหนดได้ที่โทโพโลยีการติดตั้ง

อัปเดต ZooKeeper ในเครื่องที่ 1, 2 และ 3
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
```

อัปเดต Postgres ในเครื่อง 8

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

อัปเดต Postgres ในเครื่อง 9

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

อัปเดต LDAP ในเครื่องที่ 4 และ 5 โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
อัปเดต Cassandra ในเครื่องที่ 1, 2 และ 3
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
อัปเดตคอมโพเนนต์ Edge ในเครื่อง 6, 7, 10, 11, 12, 13, 8 และ 9 ตามลําดับนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
อัปเดต Qpid ในเครื่อง 12 และ 13
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
อัปเดต UI ใหม่ (ue) หรือ UI แบบคลาสสิก (ui) ในเครื่องที่ 6 และ 7 โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
```
(หากคุณติดตั้ง apigee-adminapi) อัปเดตยูทิลิตี apigee-adminapi ในเครื่องที่ 6 และ 7
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(หากคุณติดตั้ง Apigee SSO) อัปเดต Apigee SSO ในเครื่องที่ 6 และ 7 โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
โดยที่ sso_config_file คือไฟล์การกําหนดค่าที่คุณสร้างขึ้นเมื่อติดตั้ง SSO
รีสตาร์ทคอมโพเนนต์ UI โดยทำดังนี้
- UI แบบคลาสสิก: หากคุณใช้ UI แบบคลาสสิก ให้รีสตาร์ทคอมโพเนนต์ edge-ui ในเครื่องที่ 6 และ 7 ดังที่แสดงในตัวอย่างต่อไปนี้
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- UI ของ Edge ใหม่: หากคุณติดตั้ง UI ของ Edge ใหม่ ให้รีสตาร์ทคอมโพเนนต์ edge-management-ui ในเครื่องที่ 6 และ 7 โดยทำดังนี้
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```

การอัปเกรดคลัสเตอร์ 12 โหนด

อัปเดตคอมโพเนนต์ต่อไปนี้สําหรับการติดตั้งคลัสเตอร์ 12 โหนด

ดูรายการโทโพโลยี Edge และจำนวนโหนดได้ที่โทโพโลยีการติดตั้ง

อัปเดต ZooKeeper ในเครื่อง 1,2,3,7,8,9 ในทั้ง 2 DC โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
```
อัปเดต Postgres ในเครื่อง 6,12 ในทั้ง 2 DC
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
อัปเดต LDAP ในเครื่อง 1,7 ในทั้ง 2 DC
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
บล็อกการรับส่งข้อมูลใน DC-1 และตรวจสอบว่าการรับส่งข้อมูลทั้งหมดเปลี่ยนเส้นทางไปยัง DC-2 อื่นแล้ว
อัปเดต Cassandra ในเครื่อง 1,2,3 ใน DC-1
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
อัปเดตเซิร์ฟเวอร์การจัดการในเครื่องที่ 1 ใน DC-1
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
อัปเดตเราเตอร์และโปรแกรมประมวลผลข้อความในเครื่อง 2,3 ใน DC-1
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
เลิกบล็อกการรับส่งข้อมูลใน DC-1 และตรวจสอบ DC-1 จากนั้นดำเนินการกับ DC-2 โดยบล็อกการรับส่งข้อมูลใน DC-2 และเปลี่ยนเส้นทางการรับส่งข้อมูลไปยัง DC-1
อัปเดต Cassandra ในเครื่อง 7,8,9 ใน DC-2
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
อัปเดตเซิร์ฟเวอร์การจัดการในเครื่อง 7 ใน DC-2
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
อัปเดตเราเตอร์และโปรแกรมประมวลผลข้อความในเครื่อง 8,9 ใน DC-2
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
เลิกบล็อกการรับส่งข้อมูลใน DC-2 และตอนนี้ทั้ง 2 DC จะจัดการการรับส่งข้อมูล
เรียกใช้คำสั่งอัปเดตอีกครั้งในเซิร์ฟเวอร์การจัดการทั้งหมดใน DC บนเครื่อง 1 และ 7
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
อัปเดต edge-qpid-server และ edge-postgres-server ในเครื่อง 4,5,6,10,11,12 ในทั้ง 2 DC
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
อัปเดต Qpid ในเครื่อง 4,5,10,11 ในทั้ง 2 DC
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
อัปเดต UI ใหม่ (ue) หรือ UI แบบคลาสสิก (ui) ในทั้ง 2 DC ดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c  [ui|ue] -f configFile
```
(หากคุณติดตั้ง apigee-adminapi) อัปเดต apigee-adminapi ในทั้ง 2 DC โดยทำดังนี้
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(หากคุณติดตั้ง Apigee SSO) อัปเดตโหนด Apigee SSO ในทั้ง 2 DC โดยทำดังนี้
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f configFile
```
รีสตาร์ทคอมโพเนนต์ UI ของ Edge ใหม่ (edge-management-ui) หรือ UI ของ Edge แบบคลาสสิก (edge-ui) ในทั้ง 2 DC ดังนี้
```
/opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart
```

เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ

อัปเดตล่าสุด 2025-05-07 UTC