Proxmox VE: วาง Cluster, HA, Ceph และ Backup

Proxmox VE cluster ที่ทนต่อเครื่องเสียได้ต้องมีอย่างน้อยสาม node ให้ cluster รักษา quorum ได้ (ขั้นต่ำที่เอกสาร HA กำหนด ส่วน cluster สอง node ใช้ QDevice เป็นเสียงที่สามได้) มีเครือข่าย corosync แยกพร้อม link สำรอง และมี storage ที่ทุก node เข้าถึงหรือ replicate ข้ามกันได้

HA จะตัด node ที่ล่มออกจากระบบ (fence) แล้วเปิด guest ใหม่บน node อื่น แต่ไม่ได้แทน backup ที่ทดสอบกู้คืนแล้ว

Proxmox VE คือแพลตฟอร์ม virtualization แบบ open source บน Debian ที่รันทั้ง virtual machine ด้วย KVM และ container ด้วย LXC และเปิด source code ภายใต้สัญญาอนุญาต AGPLv3 ตามเอกสารแนะนำ Proxmox VE บทความนี้ต่อจากบทความเรื่องย้ายออกจาก VMware ซึ่งอธิบายการแปลง VM ไว้แล้ว ส่วนนี้ว่าด้วยการออกแบบ cluster ปลายทางให้ใช้งาน production ได้

ส่วนประกอบของ Proxmox VE ที่กำหนดความทนทานของ cluster

ส่วนที่ตัดสินว่า cluster อยู่รอดเมื่อเครื่องเสียหรือไม่มีสามส่วน คือ corosync ที่ทำให้ node รู้จักกันและนับเสียง (quorum) ระบบไฟล์ pmxcfs ที่เก็บ config ของทั้ง cluster และ HA manager ที่ย้าย VM เมื่อ node ล่ม ทั้งสามส่วนพึ่งเครือข่าย cluster ตัวเดียวกัน

• ไม่มีเครื่องจัดการกลาง: เอกสารแนะนำระบุว่า node ใดก็จัดการทั้ง cluster ได้ผ่าน web UI หรือ REST API และ HA stack มาพร้อม Proxmox VE โดยไม่ต้องใช้เครื่องมือภายนอกอย่าง Pacemaker
• pmxcfs: ตามเอกสาร pmxcfs เป็นระบบไฟล์ที่เก็บ config ในฐานข้อมูลและ replicate ไปทุก node แบบ real time ผ่าน corosync เมานต์ที่ /etc/pve และจะเป็น read-only เมื่อ node เสีย quorum ผลที่เห็นได้คือ node ที่หลุดจาก cluster จะเปลี่ยน config ของ VM ไม่ได้
• corosync: ชั้นสื่อสารของ cluster ซึ่งเอกสาร cluster manager เรียกว่าเป็นงานที่ไวต่อเวลา (time-critical) จึงกำหนดเงื่อนไขเครือข่ายไว้ชัดเจน ดูในหัวข้อเครือข่ายด้านล่าง

ถ้าองค์กรต้องการให้หลายทีมสร้างและจัดการเครื่องเองแบบ self-service พร้อมแบ่ง quota ตามโครงการ งานนั้นใกล้กับ private cloud มากกว่า ดูเพิ่มเติมที่หน้า OpenStack

Cluster ต้องมีกี่ node: quorum, QDevice และ cluster สองเครื่อง

สำหรับ HA ให้เริ่มที่สาม node เพราะเอกสาร HA กำหนดอย่างน้อยสาม node เพื่อให้ได้ quorum ที่เชื่อถือได้ ส่วน cluster สองเครื่องต้องเพิ่ม QDevice เป็นเสียงที่สาม

Quorum คือการนับเสียงว่าฝั่งไหนของ cluster มีสิทธิ์ทำงานต่อ ตามเอกสาร cluster manager แต่ละ node ได้หนึ่งเสียงเป็นค่าเริ่มต้น เมื่อเครือข่ายแยกเป็นส่วน การเปลี่ยนสถานะต้องมี node ออนไลน์เป็นเสียงข้างมาก และฝั่งที่เสีย quorum จะเป็น read-only ผลที่ตามมาคือ cluster สองเครื่องที่เสียไปหนึ่งเครื่องจะเหลือเสียงไม่ถึงข้างมาก node ที่เหลือจึงเปลี่ยนสถานะอะไรไม่ได้ จนกว่าจะมีเสียงที่สาม

QDevice ใช้ daemon qnetd ที่รันบน server อิสระซึ่งติดตั้งแพ็กเกจ corosync-qnetd และต่อกับ cluster ผ่าน TCP/IP จึงวางนอก LAN ของ cluster ได้ ควรเลือกเครื่องที่ไม่ล่มพร้อม node ใด node หนึ่ง

เอกสารไม่ได้จำกัดจำนวน node ใน cluster ไว้ตายตัว แต่ยิ่ง node มาก เงื่อนไข latency ของ corosync ก็ยิ่งเข้ม ตามหัวข้อถัดไป

วางเครือข่ายของ cluster อย่างไร

แยกเครือข่ายตามประเภท traffic อย่างน้อยเป็น corosync, storage (เช่น Ceph), migration และ management/VM โดย corosync ควรอยู่บน NIC ของตัวเองและมี link สำรอง เพราะเครือข่ายที่แน่นจาก traffic อื่นทำให้ node หลุดจาก quorum ได้

• Latency: เอกสาร cluster manager ระบุว่า cluster stack ต้องการเครือข่ายที่เชื่อถือได้และ latency ต่ำกว่า 5 มิลลิวินาที (ระดับ LAN) ระหว่างทุก node และเมื่อเกินสาม node กับ latency ราว 10 มิลลิวินาที โอกาสทำงานได้จะลดลงมาก
• NIC แยก: เอกสารแนะนำ NIC กายภาพเฉพาะสำหรับ traffic ของ cluster และเตือนเป็นพิเศษว่าอย่าใช้เครือข่ายร่วมกันระหว่าง corosync กับ storage
• Link สำรอง: corosync รองรับได้สูงสุด 8 link เพิ่ม link ที่สองบนเครือข่ายอื่นไว้ใช้เมื่อเครือข่ายหลักล่ม เอกสารระบุด้วยว่าการใช้ link เดียวบน bond อาจมีปัญหาในบางกรณีความล้มเหลว
• Migration: ค่าเริ่มต้นใช้เครือข่าย cluster ซึ่งเอกสารบอกว่าไม่เหมาะ ตั้งเครือข่าย migration แยกได้ที่ /etc/pve/datacenter.cfg และเอกสารแนะนำอย่างยิ่งให้ใช้ช่องทางแบบเข้ารหัส (secure) เว้นแต่ควบคุมเครือข่ายได้ทั้งหมด เพราะแบบ insecure ส่ง RAM ของ guest โดยไม่เข้ารหัส
• Ceph: เอกสาร Ceph ของ Proxmox VE แนะนำแบนด์วิดท์อย่างน้อย 10 Gbps ที่ใช้เฉพาะ Ceph และยกตัวอย่างการแยกสามเครือข่ายกายภาพ คือ Ceph cluster network 25 Gbps ขึ้นไป, Ceph public network 10 Gbps ขึ้นไป และ 1 Gbps สำหรับ corosync โดยเฉพาะ

สังเกตว่า corosync ไม่ได้ต้องการแบนด์วิดท์สูง ตัวอย่างของ Proxmox ใช้แค่ 1 Gbps สิ่งที่ corosync ต้องการคือ latency ต่ำและสม่ำเสมอ การแยก NIC จึงสำคัญกว่าความเร็วของพอร์ต

HA ของ Proxmox VE ทำงานอย่างไร

ตามเอกสาร HA HA manager เฝ้า VM และ container ที่ตั้งเป็น HA resource เมื่อ node หนึ่งหลุดจาก quorum จะ fence node นั้นด้วย watchdog แล้วเปิด guest ที่เคยรันอยู่ใหม่บน node อื่น ซึ่งเป็นการ restart ไม่ใช่ live migration เครื่องจึงดับไประยะหนึ่งเสมอ

เงื่อนไขก่อนเปิด HA

เอกสาร HA ระบุ requirement ไว้ คือ cluster อย่างน้อยสาม node, storage ที่ VM และ container ใช้ร่วมกันได้ (shared storage), hardware ที่มีส่วนสำรองทุกจุด, ชิ้นส่วนเซิร์ฟเวอร์ที่เชื่อถือได้ และ watchdog แบบ hardware ซึ่งไม่บังคับ ถ้าไม่มีจะใช้ softdog ของ Linux kernel แทน เอกสารระบุว่าเมนบอร์ดเซิร์ฟเวอร์รุ่นใหม่มักมี hardware watchdog แต่ต้องตั้งค่าก่อนจึงใช้ได้ และ softdog ไม่เป็นอิสระจาก hardware ของเครื่องจึงเชื่อถือได้น้อยกว่า ทางเลือกที่ไม่ใช้ shared storage คือ ZFS replication ซึ่งเอกสาร replication ระบุว่าใช้คู่กับ HA ได้ แต่มีข้อแลกเปลี่ยนเรื่องข้อมูลตามหัวข้อ storage

Fencing คืออะไร และใช้เวลาเท่าไร

Fencing คือการรับประกันว่า node ที่มีปัญหาออฟไลน์จริงก่อนจะเปิด guest เดียวกันที่อื่น เพื่อไม่ให้ VM เดียวกันรันสองที่พร้อมกันจนข้อมูลเสีย Proxmox VE ทำ fencing ด้วยตัวเอง (self-fencing) ผ่าน watchdog: HA manager รีเซ็ต watchdog เป็นระยะ ถ้า node เสีย quorum จะรีเซ็ตไม่ได้ และเครื่องจะ reboot เมื่อ watchdog หมดเวลา ซึ่งเอกสารระบุว่าเกิดหลัง 60 วินาที

เอกสาร HA ระบุว่าเวลาตรวจพบปัญหาและ failover โดยทั่วไปอยู่ราว 2 นาที ตัวเลขนี้เป็นค่าทั่วไปตามเอกสาร ไม่ใช่ค่าที่รับประกัน ให้วัดเวลาจริงของระบบคุณระหว่างทดสอบก่อนขึ้น production และใช้ตัวเลขที่วัดได้นั้นตั้ง RTO (เวลาที่ยอมให้ระบบหยุด) ของแต่ละระบบ

HA rules แทน HA groups

คู่มือเก่าหลายฉบับยังสอนตั้ง HA groups แต่เอกสาร HA ระบุว่า HA groups เลิกใช้แล้ว (deprecated) และถูกแปลงเป็น HA node affinity rules ตั้งแต่ Proxmox VE 9.0 กฎมีสองแบบ คือ node affinity สำหรับให้ resource อยู่บน node ที่กำหนด และ resource affinity สำหรับให้ resource ชุดหนึ่งอยู่ด้วยกันหรือแยกกันคนละ node เช่น แยก database primary กับ replica ไม่ให้อยู่บน node เดียวกัน เอกสารระบุว่า resource affinity เป็นแบบ strict เป็นค่าเริ่มต้น

HA ไม่ได้ป้องกันอะไร

HA ป้องกันกรณี node ทั้งเครื่องล่มหรือหลุดจาก cluster เท่านั้น สิ่งที่เกิดภายใน guest หรือกับตัวข้อมูล HA ไม่เห็นและแก้ไม่ได้ ข้อสรุปนี้มาจากวิธีที่ HA ทำงานตามเอกสาร คือดูสถานะของ node และ resource แล้ว restart guest ไม่ได้ตรวจแอปพลิเคชัน

• แอปพลิเคชันค้างหรือ service ใน VM ล่ม: VM ยังรันอยู่ HA จึงไม่ย้ายให้ ต้องอาศัย monitoring ระดับแอป เอกสาร HA เองบอกว่าทางที่ดีที่สุดคือซอฟต์แวร์ที่รันบนหลายเครื่องพร้อมกันและตรวจจับปัญหาเองได้ ในทางปฏิบัติคือ เช่น database replication หรือ load balancer หน้าแอปหลายตัว
• ข้อมูลเสียหาย ถูกลบ หรือถูกเข้ารหัสโดย ransomware: Ceph และ replication คัดลอกสิ่งที่เขียนลงไปทั้งหมด รวมถึงข้อมูลที่เสียแล้ว ทางแก้คือ backup ที่อยู่นอก cluster
• ช่วงที่ HA ถูก disarm (สั่งพัก HA ทั้ง cluster ชั่วคราว โดยปล่อย watchdog ของทุก node เช่นระหว่างปรับเครือข่ายหรือ corosync): เอกสาร HA ระบุว่าระหว่าง disarm HA จะไม่ป้องกัน service และความล้มเหลวในช่วงนั้นจะไม่ถูกกู้คืนอัตโนมัติ
• Resource ไม่พอหลัง failover: guest จาก node ที่ล่มจะไปรันบน node ที่เหลือ เอกสารเตือนว่า cluster ขนาดเล็กอาจรับโหลดสูง ให้เผื่อ CPU และ RAM ให้ node ที่เหลือรับงานของ node ที่หายไปได้
• VM ที่ผูกกับ hardware: guest ที่ใช้ hardware passthrough ผูกกับเครื่องนั้น ย้ายด้วยนโยบาย migrate ตอนปิดเครื่องไม่ได้ตามเอกสาร HA

เลือก storage: Ceph, ZFS replication หรือ shared storage

เลือกจากจำนวน node เครือข่ายที่มี และข้อมูลที่ยอมเสียได้เมื่อ node ล่ม (RPO) Ceph ให้สำเนาครบก่อนตอบรับการเขียนแต่ต้องการสามเครื่องขึ้นไปกับเครือข่ายเร็ว ZFS replication ใช้ได้กับเครื่องน้อยกว่าแต่ข้อมูลที่เขียนหลังรอบ sync สุดท้ายอาจหาย ส่วน SAN หรือ NAS เดิมใช้ต่อได้ถ้าตัว storage มีส่วนสำรองของตัวเอง

ทั้ง Ceph RBD, NFS, iSCSI และ LVM บน LUN ที่แชร์ เป็น shared storage ตามเอกสาร storage ซึ่งระบุว่าข้อดีหลักคือ live migrate เครื่องที่กำลังรันได้โดยไม่ต้องหยุด เพราะทุก node เข้าถึง disk image ได้โดยตรง

ขั้นต่ำของ Ceph ที่เอกสารแนะนำ

• จำนวนเครื่องและดิสก์: อย่างน้อยสามเครื่องที่ควรสเปกเหมือนกัน เอกสารแนะนำอย่างน้อยสาม node และ 12 OSD กระจายเท่า ๆ กัน (OSD คือ daemon ที่ดูแลดิสก์หนึ่งลูก) ใช้หนึ่ง OSD ต่อหนึ่งดิสก์
• ไม่ใช้ RAID controller: เอกสารให้ใช้ HBA (host bus adapter) แทน เพราะ Ceph จัดการสำเนาเอง
• หน่วยความจำ: เอกสารแนะนำ OSD ละอย่างน้อย 8 GiB เพื่อประสิทธิภาพที่ดี ขณะที่ค่าเริ่มต้นของ daemon คือ 4 GiB และควรมีอย่างน้อยหนึ่ง CPU core ต่อ Ceph service
• size และ min_size: pool ค่าเริ่มต้นเก็บ 3 สำเนาและต้องมีอย่างน้อย 2 สำเนาจึงรับ I/O ถ้า placement group (กลุ่มย่อยภายใน pool ที่ Ceph ใช้จัดวาง object ลงบนชุด OSD) ใดมีสำเนาต่ำกว่านั้น เอกสาร Ceph ของ Proxmox VE ระบุว่า Ceph จะปฏิเสธ I/O ของ pool นั้น ค่าเริ่มต้นนี้ตั้งไว้เพื่อไม่ให้ข้อมูลหายเมื่อ OSD ตัวใดเสีย และเอกสารเตือนว่าอย่าตั้ง min_size เป็น 1 เพราะอาจทำให้ข้อมูลหาย, placement group ไม่สมบูรณ์ หรือหา object ไม่พบ

Backup และ restore: vzdump กับ Proxmox Backup Server

Proxmox VE สำรอง VM และ container ได้เองด้วย vzdump แต่เอกสาร backup แนะนำให้ใช้ Proxmox Backup Server บนเครื่องแยก เพราะมีความสามารถมากกว่า backup ของ Proxmox VE เป็น full backup ที่มี config และข้อมูลทั้งหมดเสมอ ต่างกันที่การเก็บ บน Proxmox Backup Server เก็บเป็น chunk ที่ตัดส่วนซ้ำออก ส่วน storage แบบไฟล์เก็บเป็นไฟล์ archive ปกติ

• โหมดของ vzdump: stop ให้ความสอดคล้องของข้อมูลสูงสุดแลกกับเครื่องหยุดช่วงสั้น ๆ, snapshot หยุดเครื่องน้อยที่สุดแต่มีความเสี่ยงเล็กน้อยเรื่องข้อมูลไม่สอดคล้อง, suspend มีไว้เพื่อความเข้ากันได้
• Proxmox Backup Server: ตามเอกสารแนะนำ ส่งเฉพาะส่วนที่เปลี่ยน (incremental) ตัดข้อมูลซ้ำ (deduplication) บีบอัดด้วย Zstandard เข้ารหัสฝั่ง client ด้วย AES-256-GCM และตรวจความถูกต้องด้วย SHA-256
• Verify job: เอกสาร maintenance แนะนำให้ตรวจ backup ทั้งหมดซ้ำอย่างน้อยเดือนละครั้งแม้ครั้งก่อนผ่านแล้ว ส่วน prune เลือกชุดที่จะเก็บ และ garbage collection คืนพื้นที่จาก chunk ที่ไม่ได้ใช้
• สำเนานอก site: ตามเอกสาร remotes และ sync jobs sync ข้อมูลไปยัง Proxmox Backup Server อีกเครื่องได้ทั้งแบบ pull และ push
• Live-restore: สำหรับ backup ของ VM ที่เก็บบน Proxmox Backup Server เปิด VM ขณะยังกู้คืนอยู่ได้ แต่เอกสารระบุว่า VM จะอ่านดิสก์ได้ช้าลงระหว่างนั้น

การทำให้ backup ทนต่อการถูกลบหรือ ransomware การป้องกัน snapshot ใน Proxmox Backup Server และวิธีซ้อมกู้คืน อธิบายไว้แล้วในบทความ backup กัน ransomware เราแนะนำให้ซ้อม restore VM ที่สำคัญจริงอย่างน้อยหนึ่งเครื่องก่อนเปิดใช้งาน cluster และจดเวลาที่ใช้ไว้เทียบกับ RTO ที่องค์กรตั้ง

อัปเดตทีละ node และอัปเกรดเวอร์ชันหลัก

อัปเดตทีละ node: ย้าย guest ออกด้วย live migration อัปเดตแล้ว reboot แล้วย้ายกลับ ก่อนเริ่มให้กำหนดว่า production รับแพ็กเกจจาก repository ใด เพราะ Proxmox แยก repository ตามระดับการทดสอบ

Ceph มี repository แยกที่แบ่งแบบเดียวกัน ตามหน้า Package Repositories ถ้าองค์กรเลือกใช้ no-subscription repository กับ production เราแนะนำให้มีเครื่องทดสอบรับอัปเดตก่อนทุกครั้ง และบันทึกการตัดสินใจนี้ไว้

• Maintenance mode: ตามเอกสาร HA โหมดนี้ทำเครื่องหมายว่า node ไม่พร้อมสำหรับ HA และย้าย HA resource ออก โหมดที่สั่งเองจะไม่ถูกยกเลิกอัตโนมัติเมื่อ reboot ต้องปิดเองหลังงานเสร็จ
• Shutdown policy: เอกสาร HA กำหนดว่าเมื่อสั่ง shutdown หรือ reboot node ที่มี HA resource ระบบจะทำตาม shutdown policy ค่าเริ่มต้นคือ conditional ซึ่งเลือกพฤติกรรมตามว่าเป็น shutdown หรือ reboot ค่าอื่นคือ freeze (หยุด service และไม่กู้คืนจนกว่า node จะกลับมา), failover (หยุด service และกู้คืนบน node อื่นถ้า node นี้ไม่กลับมาเร็ว) และ migrate (ย้าย HA service ไป node อื่นก่อนปิดเครื่อง)
• ถอด node ออกจาก cluster: เอกสาร cluster manager ให้ปิดเครื่องก่อนถอด และห้ามเปิดเครื่องนั้นกลับเข้าเครือข่ายเดิมด้วย config เดิม เพราะ cluster อาจเสียหาย ถ้าจะนำเครื่องกลับเข้า cluster เดิม ให้ติดตั้ง Proxmox VE ใหม่ก่อนแล้วจึง join
• ทิศทางการย้าย: หน้าอัปเกรดจาก 8 เป็น 9 ระบุว่าย้าย VM หรือ CT จากเวอร์ชันเก่าไปเวอร์ชันใหม่ได้เสมอ แต่จากใหม่ไปเก่าโดยทั่วไปไม่รองรับ จึงควรอัปเกรด node ที่ว่างก่อนแล้วย้ายงานไปข้างหน้า และเอกสาร cluster manager ระบุว่า live migration รองรับเฉพาะ node ที่ใช้ CPU ผู้ผลิตเดียวกัน จึงควรใช้ CPU ผู้ผลิตเดียวทั้ง cluster และทดสอบ live migration ระหว่าง CPU ต่างรุ่น
• Major upgrade: Proxmox มีสคริปต์ checklist ชื่อ pveXtoY สำหรับแต่ละรอบ (เช่น pve8to9) ที่แจ้งปัญหาที่อาจเกิดก่อน ระหว่าง และหลังอัปเกรด หน้าเดียวกันให้รัน pve8to9 --full อย่างน้อยหนึ่งครั้งก่อนเริ่ม ต้องมี backup ที่ทดสอบแล้วเสมอ ควรทดลองบนเครื่องแยกก่อน และ cluster ที่ใช้ Ceph ต้องอัปเกรด Ceph ตามลำดับที่หน้านั้นกำหนดก่อน

ต้อง monitor อะไรบ้าง

อย่างน้อยให้เฝ้า quorum ของ cluster, สถานะ Ceph, ผลของ backup และ verify job, ทรัพยากรของแต่ละ node และอายุ certificate โดยส่งไปยังระบบ monitoring ที่อยู่นอก cluster เพื่อให้ยังแจ้งเตือนได้เมื่อ cluster มีปัญหา

• Metric: Proxmox VE ส่งสถิติของ host, guest และ storage ไปยัง external metric server ได้เป็นระยะ หน้าExternal Metric Server ระบุว่ารองรับ Graphite, InfluxDB และ OpenTelemetry
• Quorum และ link ของ corosync: แจ้งเตือนเมื่อ node หลุดหรือ link สำรองล่ม เพราะ link สำรองที่เสียไปเงียบ ๆ จะไม่ช่วยในวันที่ link หลักล่ม
• Ceph: แจ้งเตือนเมื่อสถานะไม่ใช่ปกติ, OSD ล่ม หรือพื้นที่ใกล้เต็ม
• Certificate: ตามหน้า Certificate Management แต่ละ cluster สร้าง CA ของตัวเองซึ่ง browser ไม่เชื่อถือโดยอัตโนมัติ ถ้าใช้ ACME (Let's Encrypt) ระบบจะพยายามต่ออายุผ่าน pve-daily-update.service เมื่อ certificate จะหมดอายุภายใน 30 วัน ควรตั้งแจ้งเตือนกรณีต่ออายุไม่สำเร็จ

ถ้าองค์กรใช้ Zabbix อยู่แล้ว ดูแนวทางวาง monitoring ได้ในบทความ Zabbix

เช็กลิสต์ก่อนขึ้น production

ใช้รายการนี้เป็นเกณฑ์ตรวจรับ cluster ก่อนย้ายระบบจริง ไม่ว่าทีมภายในหรือผู้รับจ้างเป็นคนติดตั้ง ทุกข้อควรมีหลักฐาน เช่น ผลคำสั่ง ภาพหน้าจอ หรือบันทึกการทดสอบพร้อมวันที่

• มีอย่างน้อยสาม node ตามที่เอกสาร HA กำหนด (ถ้ามีสอง node อย่างน้อยต้องเพิ่ม QDevice บนเครื่องอิสระ) และตรวจแล้วว่า cluster มี quorum
• corosync อยู่บน NIC แยกจาก storage, latency ระหว่าง node อยู่ในเกณฑ์ที่เอกสารกำหนด และมี link สำรองบนเครือข่ายอื่น
• ทดสอบถอดสาย link หลักแล้ว cluster ยังมี quorum ผ่าน link สำรอง
• ทดสอบ fencing: ตัด node ที่มี HA resource ออกจากเครือข่าย cluster แล้วยืนยันว่า node นั้น reboot ตัวเองและ guest ไปเริ่มบน node อื่น บันทึกเวลาที่ใช้จริง
• คำนวณแล้วว่าเมื่อขาด node ที่ใหญ่ที่สุดไปหนึ่งเครื่อง node ที่เหลือยังมี CPU และ RAM พอรัน HA resource ทั้งหมด และยืนยันจากการทดสอบ fencing ข้างต้น
• ถ้าใช้ Ceph: เครือข่าย Ceph แยกและเร็วตามเอกสาร, ไม่มี RAID controller ในเส้นทางของ OSD, pool ไม่มี min_size 1, สถานะ Ceph ปกติ
• ถ้าใช้ ZFS replication: ตั้งรอบ replication ตาม RPO ที่องค์กรยอมรับ และผู้ใช้ระบบรับทราบว่าข้อมูลช่วงสุดท้ายอาจหาย
• ตั้งเครือข่าย migration และใช้ช่องทางแบบเข้ารหัส
• มี Proxmox Backup Server แยกเครื่อง, verify job ตั้งรอบไว้, มีสำเนานอก site และซ้อม restore VM สำคัญแล้วพร้อมเวลาที่ใช้
• กำหนด repository ที่ production ใช้, ขั้นตอนอัปเดตทีละ node และ runbook สำหรับ major upgrade
• Metric ส่งออกไปยังระบบ monitoring นอก cluster และมีแจ้งเตือน quorum, Ceph, backup และ certificate
• ส่งมอบเอกสาร: แผนผังเครือข่าย, IP และ VLAN, รหัสผ่านและ key ที่เก็บอย่างปลอดภัย และวิธีเข้าเครื่องเมื่อเครือข่ายหลักล่ม เช่น IPMI

ถ้าจ้างผู้ดูแลต่อ การเขียนเกณฑ์เหล่านี้และเป้า RTO/RPO ที่องค์กรตั้งเองลงในสัญญา ดูได้ในเช็กลิสต์สัญญา MA และ SLA

ข้อมูลที่เปลี่ยนตามเวอร์ชัน

ตัวเลขและชื่อฟีเจอร์ด้านล่างผูกกับเวอร์ชัน ให้ตรวจกับลิงก์ต้นทางอีกครั้งก่อนนำไปใช้

UNIXDEV ช่วยวางและดูแล Proxmox VE cluster ได้อย่างไร

UNIXDEV ออกแบบ ติดตั้ง และดูแล Proxmox VE cluster ตั้งแต่กำหนดจำนวน node เครือข่าย corosync และ storage ให้ตรงกับ RPO/RTO ที่องค์กรตั้ง ติดตั้ง Ceph หรือ ZFS replication วาง Proxmox Backup Server และ monitoring แล้วทดสอบตามเช็กลิสต์ข้างต้นก่อนส่งมอบ ถ้าย้ายมาจาก VMware เราวางแผนและย้าย VM เป็นระลอกตามแนวทางในบทความย้ายออกจาก VMware หลังใช้งานจริง ดูแลต่อได้ทั้งการอัปเดต อัปเกรดเวอร์ชัน และซ้อมกู้คืน ผ่าน DevOps & SRE Managed Services ตามขอบเขตที่ตกลง ดูงานด้าน cloud และ virtualization ที่หน้า Cloud Services และงานดูแลเซิร์ฟเวอร์ที่หน้า Linux

แหล่งอ้างอิงและอ่านต่อ

• Proxmox VE — Introduction
• Proxmox VE — Cluster Manager · Proxmox Cluster File System (pmxcfs)
• Proxmox VE — High Availability
• Proxmox VE — Storage · Storage Replication
• Proxmox VE — Deploy Hyper-Converged Ceph Cluster · Ceph (Squid) — Architecture
• Proxmox VE — Backup and Restore
• Proxmox Backup Server — Introduction · Maintenance Tasks · Managing Remotes & Sync
• Proxmox VE wiki — Package Repositories · Upgrade from 8 to 9
• Proxmox VE wiki — Roadmap · FAQ
• Proxmox VE wiki — External Metric Server · Certificate Management
• บทความที่เกี่ยวข้อง: ย้ายออกจาก VMware: ทางเลือกหลังเปลี่ยน License
• บทความที่เกี่ยวข้อง: Backup กัน Ransomware: Immutable หรือ Offline?
• บทความที่เกี่ยวข้อง: Zabbix คืออะไร
• บทความที่เกี่ยวข้อง: เช็กลิสต์สัญญา MA และ SLA
• บทความทั้งหมดในหมวด Cloud และการย้ายระบบ

ตรวจข้อมูล ณ วันที่ 2026-11-14

วิธีจัดทำ: อ้างอิงจากเอกสารต้นทางข้างต้น ตรวจโดยทีม UNIXDEV