เตรียมและทดสอบเซิร์ฟเวอร์ใหม่ก่อน คัดลอกข้อมูลด้วยวิธีรักษาความสอดคล้องที่แอปพลิเคชันรองรับ กำหนดช่วงเวลาตัดเปลี่ยน และเก็บสภาพแวดล้อมเดิมไว้ การย้อนกลับต้องคำนึงถึงการเขียนที่ได้รับการยอมรับบนเซิร์ฟเวอร์ใหม่ ไม่ใช่แค่การเปลี่ยน DNS
สำรวจบริการก่อนย้ายเครื่อง
การย้ายมีมากกว่าไฟล์แอปพลิเคชัน ระบุฐานข้อมูล ไฟล์อัปโหลด งานตามกำหนดการ เวิร์กเกอร์คิว ใบรับรอง โดเมน ความลับ และการเชื่อมต่อขาออก บันทึกเวอร์ชันซอฟต์แวร์และสมมติฐานการดำเนินงานที่สำคัญ เช่น สิทธิ์ของไฟล์และเส้นทางจัดเก็บ เซิร์ฟเวอร์เฉพาะเครื่องใหม่ที่ยังสดอยู่อาจเปิดเผย dependency ที่ถูกลืม ซึ่งเคยติดตั้งเงียบๆ ไว้บนสภาพแวดล้อมเดิมเมื่อหลายปีก่อน
มอบหมายผู้รับผิดชอบการตัดสินใจตัดเปลี่ยนและนิยามว่าความสำเร็จมีหน้าตาอย่างไร รวมการตรวจสอบที่ผู้ใช้มองเห็น ความสอดคล้องของข้อมูล และความสามารถในการกู้คืนการเข้าถึง ยืนยันว่าการตั้งค่าใหม่ถูกส่งมอบและใช้งานได้ก่อนประกาศวันย้าย การยืนยันคำสั่งซื้อหรือสเปกฮาร์ดแวร์ที่ระบุไว้ไม่เหมือนกับปลายทางที่ใช้งานได้พร้อมรับข้อมูลโปรดักชัน
สร้างปลายทางเป็นสภาพแวดล้อมแยกต่างหาก
ติดตั้งสแตกที่จำเป็น ตั้งค่าการดูแลระบบ และกำหนดไฟร์วอลล์ตามที่ตั้งใจ เก็บความลับไว้เป็นส่วนตัวและกำหนดสิทธิ์ของบริการอย่างตั้งใจ ตรวจสอบชื่อโฮสต์และพฤติกรรมใบรับรองที่แอปพลิเคชันคาดหวังก่อนย้ายทราฟฟิกสาธารณะ เอกสาร virtual-host ของ Apache แสดงให้เห็นว่าการกำหนดเส้นทางตามชื่อโฮสต์เป็นการตัดสินใจตั้งค่าที่แยกจากที่อยู่ของเซิร์ฟเวอร์ หน้าเริ่มต้นที่ใช้งานได้ไม่ได้พิสูจน์ว่าโฮสต์แอปพลิเคชันที่ถูกต้องถูกตั้งค่าไว้
ใช้ชุดข้อมูลที่กู้คืนมาเป็นตัวแทนสำหรับการซ้อม โดยปิดหรือเปลี่ยนเส้นทางอีเมลขาออก การชำระเงิน และงานตามกำหนดการไปยังระบบทดสอบที่ปลอดภัย วิธีนี้ป้องกันไม่ให้สภาพแวดล้อมทดสอบไปดำเนินการกับผู้ใช้จริง ฝึกใช้การเข้าสู่ระบบ การอัปโหลด งานเบื้องหลัง และการกู้คืน บันทึกขั้นตอนและระยะเวลา เพื่อให้ช่วงเวลาจริงอ้างอิงจากกระบวนการที่สังเกตได้ ไม่ใช่จากความหวัง
เลือกขอบเขตข้อมูลที่สอดคล้องกัน
ใช้วิธีสำรองข้อมูลหรือทำสำเนาที่ฐานข้อมูลและแอปพลิเคชันรองรับ PostgreSQL แยกความแตกต่างระหว่าง SQL dump การสำรองข้อมูลระดับไฟล์ระบบ และ continuous archiving ซึ่งแต่ละวิธีมีสมมติฐานของตัวเอง คำแนะนำเรื่อง dump ระบุว่า dump ฐานข้อมูลอาจสอดคล้องกันภายในตัวเอง แต่บทบาทระดับคลัสเตอร์และรายละเอียดอื่นๆ ต้องจัดการแยกต่างหาก อ่านข้อกำหนดสำหรับระบบที่คุณใช้อยู่จริง แทนที่จะคัดลอกไฟล์ข้อมูลที่เปิดอยู่โดยไม่เลือก
วางแผนว่าฐานข้อมูลเกี่ยวข้องกับไฟล์อัปโหลดและสถานะคิวอย่างไร หากระเบียนชี้ไปยังไฟล์ที่ถูกคัดลอกในเวลาต่างกัน แอปพลิเคชันที่กู้คืนมาอาจไม่สมบูรณ์แม้ว่าการคัดลอกทั้งสองสำเร็จแยกกันก็ตาม ตัดสินใจว่าจะหยุดการเขียนชั่วครู่ ใช้การทำสำเนาที่ทดสอบแล้ว หรือทำการส่งออกเฉพาะแอปพลิเคชัน ทำให้การตัดสินใจเรื่องความสอดคล้องนั้นชัดเจนในคู่มือ
| ขั้นตอน | หลักฐานที่ต้องมี | การตัดสินใจ |
|---|---|---|
| การซ้อม | แอปพลิเคชันและข้อมูลที่กู้คืนผ่านการตรวจสอบ | ปลายทางสามารถพิจารณาสำหรับการตัดเปลี่ยนได้ |
| การซิงโครไนซ์ครั้งสุดท้าย | จุดกู้คืนที่สอดคล้องกันซึ่งกำหนดไว้ | ดำเนินการต่อเฉพาะเมื่อเข้าใจการเปลี่ยนแปลงที่เหลืออยู่ |
| การสลับทราฟฟิก | การกำหนดเส้นทางและพฤติกรรมใบรับรองที่ถูกต้อง | เฝ้าติดตามทั้งสองปลายทาง |
| การย้อนกลับ | ตำแหน่งของการเขียนใหม่ทั้งหมดที่ได้รับการยอมรับ | กระทบยอดข้อมูลก่อนคืนทราฟฟิก |
เตรียมการกำหนดเส้นทางทราฟฟิกโดยไม่สัญญาว่าจะเปลี่ยนทันที
DNS time-to-live ควบคุมระยะเวลาที่ระเบียนอาจถูกแคชไว้ ตามที่อธิบายในเอกสาร DNS ของ Cloudflare ตรวจสอบ TTL แต่เนิ่นๆ หาก DNS เป็นส่วนหนึ่งของการย้าย และปล่อยให้ระเบียนที่แคชไว้อยู่ภายใต้การตั้งค่าเดิมจนหมดอายุ การเปลี่ยนค่าในขณะตัดเปลี่ยนไม่สามารถย่นระยะเวลาของคำตอบที่แคชไว้ทุกอันย้อนหลังได้ ลูกค้าที่แตกต่างกันอาจไปถึงปลายทางที่ต่างกันในช่วงเปลี่ยนผ่าน
เก็บสภาพแวดล้อมเดิมไว้ให้ใช้ได้ขณะที่การเปลี่ยนแปลงเส้นทางยังเข้าที่ โดยมีนโยบายชัดเจนว่าจะยังรับการเขียนได้หรือไม่ หลีกเลี่ยงการรันผู้บริโภคคิวหรืองานตามกำหนดการซ้ำซ้อน เว้นแต่แอปพลิเคชันถูกออกแบบมารองรับ เฝ้าติดตามคำขอทั้งสองฝั่ง และยืนยันชื่อโฮสต์ ใบรับรอง TLS และเวอร์ชันแอปพลิเคชันที่ตั้งใจไว้จากไคลเอนต์อิสระ
นิยามการย้อนกลับหลังจากเริ่มมีการเขียน
ก่อนที่ระบบใหม่จะยอมรับการเปลี่ยนแปลง การเปลี่ยนเส้นทางกลับมาอาจค่อนข้างง่าย หลังจากนั้น การย้อนกลับ DNS เพียงอย่างเดียวอาจทำให้งานสูญหายหรือสร้างประวัติที่ขัดแย้งกันสองชุด กำหนดว่าเรกคอร์ดและไฟล์อัปโหลดที่สร้างขึ้นใหม่จะถูกเก็บรักษาหรือกระทบยอดอย่างไร หากแอปพลิเคชันไม่สามารถรวมเข้าด้วยกันได้อย่างปลอดภัย ช่วงเวลาบำรุงรักษาแบบควบคุมอาจเป็นทางเลือกที่ดีกว่าการย้อนกลับไปยังสำเนาเก่าอย่างไม่เป็นระบบ
กำหนดเงื่อนไขที่ต้องหยุดการโยกย้ายชั่วคราว และให้ผู้ตัดสินใจสามารถติดต่อได้ เก็บรักษาบันทึกและหลักฐานที่เป็นประโยชน์ตามกฎการเก็บรักษาของโครงการ อย่าลบเครื่องเก่าหรือสำเนากู้คืนอิสระเพียงเพราะหน้าแรกโหลดได้ครั้งเดียว ระยะเวลาการเก็บรักษาควรครอบคลุมความต้องการด้านการตรวจสอบและย้อนกลับที่ตกลงกันไว้
ปิดการย้ายด้วยการตรวจสอบด้านการดำเนินงาน
หลังการสลับระบบ ตรวจสอบการสำรองข้อมูล การแจ้งเตือน การต่ออายุใบรับรอง งานตามกำหนดเวลา และการกู้คืนการเข้าถึง ยืนยันว่าโฮสต์ที่ถูกตรวจสอบคือปลายทางใหม่ และไม่มีอินทิเกรชันทดสอบหลงเหลืออยู่ในโปรดักชัน ตรวจสอบข้อผิดพลาดของแอปพลิเคชันและเวลาที่ผู้ใช้มองเห็นภายใต้ปริมาณการใช้งานปกติ อัปเดตทะเบียนทรัพยากรและคู่มือปฏิบัติงานเพื่อให้ผู้ดูแลระบบคนถัดไปไม่ต้องคาดเดาว่ามีอะไรเปลี่ยนแปลงไป
ตระกูลเฉพาะของ SwissOctet มีการกำหนดค่าทางกายภาพที่แตกต่างกัน แต่งานโยกย้ายและความช่วยเหลือแบบจัดการต้องได้รับการยืนยันสำหรับบริการที่เลือก ใช้แค็ตตาล็อกเพื่อเลือกทรัพยากรที่เหมาะสม จากนั้นสร้างการย้ายที่ผ่านการทดสอบโดยอิงตามข้อมูลของแอปพลิเคชันของคุณ การโยกย้ายจะเสร็จสมบูรณ์เมื่อบริการและกระบวนการกู้คืนทำงานบนปลายทาง ไม่ใช่เพียงเมื่อไฟล์ถูกถ่ายโอนแล้ว
รายการตรวจสอบปฏิบัติของคุณ
- จัดทำทะเบียนข้อมูล งาน ข้อมูลลับ และอินทิเกรชัน
- ตรวจสอบปลายทางที่ส่งมอบก่อนกำหนดเวลา
- ซ้อมกับอินทิเกรชันภายนอกที่ปลอดภัย
- กำหนดความสอดคล้องของฐานข้อมูลและการอัปโหลด
- วางแผนการเปลี่ยนเส้นทางและป้องกันงานซ้ำซ้อน
- ระบุการย้อนกลับสำหรับการเขียนใหม่
- ตรวจสอบการสำรองข้อมูลและการตรวจสอบหลังการสลับระบบ
รายละเอียดที่สำคัญ
ฉันสามารถโยกย้ายโดยคัดลอกไดเรกทอรีแอปพลิเคชันได้หรือไม่+
เฉพาะเมื่อการคัดลอกนั้นเก็บทุกสิ่งที่บริการต้องการและรักษาความสอดคล้องไว้ ฐานข้อมูล ไฟล์อัปโหลด งาน ข้อมูลลับ และการกำหนดค่ามักต้องดูแลแยกต่างหาก
การลด TTL ของ DNS ทำให้การสลับระบบเกิดขึ้นทันทีหรือไม่+
ไม่ คำตอบที่แคชไว้ก่อนหน้าอาจคงอยู่จนกว่าอายุการใช้งานเดิมจะสิ้นสุด และไคลเอนต์อาจอัปเดตในเวลาที่ต่างกัน
การย้อนกลับเป็นเพียงการชี้ DNS ไปยังเซิร์ฟเวอร์เก่าหรือไม่+
ไม่ใช่หลังจากเซิร์ฟเวอร์ใหม่ยอมรับการเขียนแล้ว คุณต้องจัดการกับเรกคอร์ดและไฟล์เหล่านั้นก่อนเปลี่ยนเส้นทางกลับ
ไปที่ต้นทาง
แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน
- PostgreSQL: การสำรองและกู้คืนข้อมูล www.postgresql.org
- PostgreSQL: ความสอดคล้องและการกู้คืนของ SQL Dump www.postgresql.org
- Apache: เอกสาร Virtual Host httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก