XCP-ng ท้าชน Proxmox: เลือกแพลตฟอร์ม Virtualization อย่างไรให้ตรงงาน

ถ้าจะเปลี่ยนแพลตฟอร์ม virtualization คำถามว่า “XCP-ng ท้าชน Proxmox แล้วใครชนะ” อาจชวนให้เลือกจากหน้าตาหรือรายการฟีเจอร์ แต่ความต่างที่กระทบงานจริงอยู่ที่สถาปัตยกรรมและวิธีดูแลหลังติดตั้ง XCP-ng สร้างบน Xen hypervisor พร้อม XAPI และนิยมจัดการหลายโฮสต์ผ่าน Xen Orchestra ส่วน Proxmox Virtual Environment (PVE) รวม KVM สำหรับ VM กับ LXC สำหรับ Linux container ไว้บนฐาน Debian และมีเว็บจัดการอยู่ในแพลตฟอร์มเดียว บทความนี้เทียบเอกสารทางการที่ตรวจเมื่อ 12 ตุลาคม 2026 เพื่อช่วยออกแบบการทดลอง ไม่ใช่ผล benchmark บนฮาร์ดแวร์เดียวกันหรือข่าวประกาศเวอร์ชันใหม่

เริ่มจากชนิด workload ก่อนเลือก hypervisor

XCP-ng เป็นแพลตฟอร์มสำหรับ VM บน Xen ถ้าทีมมี Windows Server, Linux VM, appliance หรือระบบที่ต้องแยกเคอร์เนลอย่างชัดเจน โมเดล VM ตรงกับงานนี้ ส่วน Proxmox VE มีทั้ง KVM VM และ LXC container ในหน้าจอเดียวกัน LXC ใช้เคอร์เนลร่วมกับโฮสต์ จึงเหมาะกับ Linux workload ที่ยอมรับขอบเขตการแยกแบบ container ได้ แต่ไม่ใช่ตัวแทน VM ทุกกรณี เช่นระบบที่ต้องใช้เคอร์เนลของตัวเองหรือซอฟต์แวร์ที่รับรองเฉพาะ VM หากนำจำนวน guest หรือความหนาแน่นของ LXC ไปเทียบกับ VM ของ XCP-ng ตรง ๆ จะได้ข้อสรุปที่ผิดโจทย์

จุดเด่นของ XCP-ng คือแนวทางโฮสต์เฉพาะทาง: ลง ISO บน bare metal แล้วให้ Xen Orchestra (XO) จัดการ pool, VM, งานสำรองข้อมูล และนโยบายจากส่วนกลาง เอกสาร XCP-ng ระบุว่า XO Lite ฝังมากับ XCP-ng 8.3 สำหรับจัดการ pool เดียวผ่านเบราว์เซอร์ แต่ถ้าดูแลหลายโฮสต์หรือหลาย pool, ทำ backup และงานอัตโนมัติ XO ตัวเต็มคือชั้นบริหารหลัก ส่วน Proxmox ให้เว็บจัดการจากแต่ละ node ตั้งแต่ต้น และรวม node เป็น cluster เพื่อจัดการ VM, container, storage และ HA ในมุมมองเดียว วิธีไหน “ง่ายกว่า” จึงขึ้นกับจำนวนโฮสต์ ทักษะทีม และงานที่ต้องทำรายวัน

ภาพ: Xen Orchestra ที่เผยแพร่ผ่านเอกสาร XCP-ng; หน้าตาอาจเปลี่ยนตามรุ่นและวิธีติดตั้ง

ภาพ: Proxmox Server Solutions GmbH; เป็นภาพสาธิตรุ่น 9.2 จากเว็บไซต์ทางการ

Storage: อย่าตัดสินจากชื่อระบบไฟล์อย่างเดียว

Proxmox VE รองรับทางเลือกอย่าง local storage, ZFS, NFS และ Ceph ตามรูปแบบ deployment การมี ZFS ในโฮสต์เดียวช่วยทำ snapshot และจัดการดิสก์ได้สะดวก ส่วน Ceph ใช้กระจาย storage ระหว่างหลาย node แต่เพิ่มภาระด้านเครือข่าย, จำนวนดิสก์, quorum และการติดตามสุขภาพของ cluster จึงไม่ใช่ของแถมที่เปิดแล้วจบ ใน XCP-ng สิ่งที่ผูก VM เข้ากับ storage เรียกว่า Storage Repository (SR) มีทั้งแบบ local และ shared; โครงการยังมี XOSTOR ที่ใช้ LINSTOR/DRBD ทำ replicated storage ซึ่งเอกสารกำหนดเงื่อนไขเรื่องจำนวนโฮสต์และเครือข่ายไว้อย่างชัดเจน

รายละเอียดที่ผู้ย้ายงานต้องตรวจเป็นพิเศษคือขนาดดิสก์และรูปแบบ snapshot เอกสาร XCP-ng ระบุว่า VHD มีเพดานราว 2 TiB ต่อดิสก์ และ XCP-ng 8.3 เพิ่ม QCOW2 สำหรับดิสก์ใหญ่บน SR ส่วนมาก แต่มีข้อยกเว้นอย่าง XOSTOR และ SMB อย่าสรุปว่า “XCP-ng จำกัดดิสก์ 2 TiB” แบบเหมารวม และอย่าสรุปว่าไฟล์ VM ที่มีชื่อ QCOW2 จะย้ายข้ามระบบได้ทันทีโดยไม่ตรวจ metadata, driver และ firmware การเลือก storage ควรเริ่มจาก VM ตัวอย่างที่มีดิสก์ใหญ่ที่สุดกับรูปแบบ snapshot/backup ที่จะใช้จริง

Backup และการกู้คืนเป็นตัวชี้ขาดที่เห็นชัดกว่า benchmark

ฝั่ง XCP-ng เอกสารแนะนำ Xen Orchestra สำหรับ backup แบบ agentless มี full/incremental backup, replication และการสำรอง metadata ของ pool กับ XO เอง ปลายทาง backup รองรับ NFS, SMB และ S3-compatible ตามเอกสาร ฝั่ง Proxmox VE มีงาน backup ในแพลตฟอร์ม และเมื่อใช้ Proxmox Backup Server (PBS) จะได้ deduplication, incremental backup, encryption และ remote sync ทั้งสองระบบจึงต้องออกแบบ “restore” ไม่ใช่เพียงเห็นงาน backup สำเร็จ: ควรลองกู้ VM ไปยังโฮสต์อื่น บูตแอป ตรวจข้อมูลล่าสุด และจับเวลา recovery ให้ตรงกับข้อกำหนดธุรกิจ

ความต่างด้านการจัดการ backup มีผลต่อจำนวนระบบที่ทีมต้องดูแลด้วย XO เป็นทั้ง console และศูนย์กลาง backup ในฝั่ง XCP-ng ส่วน PBS เป็นเซิร์ฟเวอร์สำรองข้อมูลแยกจาก Proxmox VE ในงานที่ใช้ความสามารถขั้นสูง วิธีใดคุ้มกว่าขึ้นอยู่กับพื้นที่เก็บข้อมูล, retention, ความเร็วเครือข่าย, สถานที่สำรองข้อมูล และค่าแรงดูแล ไม่ควรใช้ราคาซอฟต์แวร์อย่างเดียวเป็นตัวตัดสิน

Cluster, live migration และ HA ต้องทดสอบกับเงื่อนไขจริง

ทั้งสองฝั่งมีแนวทางจัดกลุ่มโฮสต์และย้าย VM ขณะทำงาน แต่การ live migration สำเร็จขึ้นกับ CPU compatibility, network, storage และสถานะของ guest ไม่ใช่เพียงกดปุ่มแล้วรับประกันว่าไม่มี downtime เสมอ เอกสาร XCP-ng อธิบาย resource pool และการทำ rolling pool update ผ่าน XO ส่วนเอกสาร Proxmox ระบุ cluster, HA, live migration และ Ceph/ZFS ใน ecosystem ของตัวเอง ถ้าทีมต้องการ HA ให้ทดลองตัด node จริงใน lab แล้วตรวจว่า VM กลับมาบน node อื่นเมื่อไร และ storage ยังมี quorum หรือไม่ การปิดเครื่องอย่างเป็นระเบียบไม่เท่ากับการจำลองเครื่องดับกะทันหัน

อีกเรื่องคือการย้าย ระหว่าง XCP-ng กับ Proxmox ไม่ใช่ live migration ภายในแพลตฟอร์มเดียวกัน สองระบบใช้ toolstack และ metadata ต่างกัน จึงต้องวางแผน export/import หรือวิธีย้ายระบบปฏิบัติการกับข้อมูล โดยสำรองก่อน ตรวจ BIOS/UEFI, controller, network interface, guest tools และลิขสิทธิ์ซอฟต์แวร์หลังบูตเครื่องใหม่ สำหรับฐานข้อมูล ให้กำหนดช่วงหยุดเขียนและวิธีตรวจความสอดคล้องก่อนสลับ DNS หรือ IP

วิธีทดลองให้ได้คำตอบของทีมตัวเอง

1. เลือก VM จริงสองแบบ: ตัวเล็กที่เปิดตลอด และตัวที่ใช้ดิสก์หรือ I/O หนัก เก็บค่า CPU, RAM, disk latency, boot time และปริมาณข้อมูลก่อนย้าย
2. ใช้โฮสต์ระดับเดียวกันและ network แยกสำหรับ management, migration, storage ตามความจำเป็น ติดตั้ง XCP-ng/XO กับ Proxmox VE/PBS ใน lab คนละชุด
3. สร้าง VM ด้วยจำนวน vCPU, RAM และชนิดดิสก์ใกล้กัน ทดสอบการติดตั้ง guest tools, snapshot, backup, restore และ live migration โดยจับเวลาทั้งตอนสำเร็จและตอนเกิดข้อผิดพลาด
4. ทดสอบสถานการณ์เสีย: ถอดสาย network storage, ปิด node, ให้ backup repository เต็ม, ลอง restore หลังลบ VM ทดสอบ แล้วจดขั้นตอนที่ผู้ดูแลต้องทำจริง
5. คำนวณค่าใช้จ่ายสามปีรวม server, disk, network, backup capacity, ไฟฟ้า, subscription/support และเวลาที่ทีมใช้ดูแล พร้อมเผื่อการขยายระบบ

ผลทดสอบจะบอกทิศทางได้ดีกว่าการอ่านตารางฟีเจอร์: หากเน้น VM ล้วน, ชอบการบริหารหลาย pool และต้องการ workflow backup/replication ผ่าน XO, XCP-ng เป็นตัวเลือกที่ควรทดลองจริง หากทีมต้องวาง VM และ LXC ร่วมกัน มีความคุ้นเคยกับ Debian/ZFS/Ceph และต้องการบริหาร cluster จากเว็บเดียว Proxmox VE อาจเข้ากับงานกว่า นี่เป็นข้อสรุปเชิงสถาปัตยกรรมจากเอกสาร ไม่ใช่คำรับรองว่าระบบใดเร็วหรือเสถียรกว่าบนทุกฮาร์ดแวร์

อ่านเพิ่มเติม: เอกสาร XCP-ng · Xen Orchestra · Storage XCP-ng · Backup XCP-ng · Proxmox VE · Proxmox Backup Server