หลักการออกแบบ Migration (Design General Rules)

บทนำ

การออกแบบ Migration เป็นขั้นตอนวางแผนและ Solutioning ที่นำข้อมูลจาก Phase เตรียมการมาประเมินความเสี่ยง เลือกวิธี Migration ที่เหมาะสม และจัดทำแผนที่ลดผลกระทบต่อธุรกิจให้มากที่สุด บทความนี้สรุปหลักการสำคัญ 6 ข้อในการออกแบบ Migration

ข้อกำหนดเบื้องต้น (Prerequisites)

• ข้อมูล Summarize จาก Migration Preparation Phase
• Application Dependency Map
• Business Cutover Window ที่ได้รับการอนุมัติ

หลักการออกแบบ Migration 6 ข้อ

1. Minimize Performance Impact During Migration: ระหว่าง Migration ประสิทธิภาพ Storage และ Network ของระบบเดิมอาจได้รับผลกระทบ ต้องมั่นใจว่า User Access ไม่ถูกรบกวน โดยทำ Migration ในช่วง Off-peak และระมัดระวังสำหรับ Migration ที่มี Concurrency สูงหรือ Source VM มี Bottleneck อยู่แล้ว
2. Control Downtime: แต่ละวิธี Migration ทำให้เกิด Downtime ต่างกัน ต้องประเมินก่อน แนะนำให้ทำ Incremental Sync ก่อน Change Window เพื่อลด Data Sync ระหว่าง Cutover และเตรียมขั้นตอน Start/Stop Service รวมถึง Business Verification Plan ล่วงหน้า
3. Ensure Data Integrity: การย้ายข้อมูลระหว่าง Site หรือ Hardware อาจเกิด Transmission Loss แผน Migration ต้องมี Data Verification ครบวงจร และควรเก็บ VM เดิมไว้อย่างน้อย 1 เดือนเพื่อรองรับ Rollback
4. Choose Migration Method According to Specific Scenarios: Application แต่ละประเภทมีลักษณะต่างกัน Database Migration ซับซ้อนและควรให้ DBA/DMP มืออาชีพดูแล ไม่ใช้วิธีเดียวกับ Application ทั่วไป
5. Estimate Migration Time: กรณี Data Volume มากหรือ Bandwidth จำกัด Migration อาจใช้เวลานาน แนะนำให้ทำ Migration Simulation Test ก่อน เพื่อประเมินความเร็วและเผื่อเวลาสำหรับ Unknown Risks
6. Post-Migration Performance: HCI Target ต้องตอบสนอง Performance Requirement หลัง Migration โดยในกรณี V2V การตั้งค่า VM บน HCI ไม่ควรต่ำกว่า VMware เดิม (CPU Frequency, Number of Cores, Memory Size, Memory Frequency) และ Database Performance ควรประเมินแยก

การตรวจสอบ (Verification)

แผน Migration ที่ออกแบบเสร็จควรผ่านการทบทวนว่าครอบคลุมทั้ง 6 หลักการ, มีแผนสำรอง (Contingency Plan), และได้รับการอนุมัติจากเจ้าของธุรกิจและทีม Operations

หมายเหตุ

• ต้องจัดการความเสี่ยงให้เร็วที่สุดในช่วง KCP Steps ก่อน Migration โดยเฉพาะระหว่างการ Validate แผน
• สำหรับระบบที่ยอมรับ Downtime ไม่ได้ ให้พิจารณา Hot Standby Migration
• ควรมี Rollback Plan ที่ชัดเจนก่อนเริ่ม Migration จริง