แพ็กเกจ VPS สองแบบบนหน้าเดียวกัน สี่ vCPU, RAM 8 GB, พื้นที่เก็บข้อมูล 160 GB, ราคาแทบไม่ต่างกัน แบบหนึ่งเขียนว่า KVM อีกแบบเขียนว่า OpenVZ ไม่มีหน้าไหนอธิบายว่าคำนั้นเปลี่ยนอะไรบ้าง
มันเปลี่ยนสิ่งที่คุณได้รับอนุญาตให้รัน ประเภทการจำลองเสมือนของ VPS ไม่ใช่แค่เชิงอรรถเรื่องประสิทธิภาพ แต่เป็นตัวกำหนดว่าคุณควบคุมเคอร์เนลหรือไม่ ใช้ Windows ได้หรือไม่ และ Docker ทำงานได้โดยไม่ต้องพึ่งผู้ให้บริการหรือไม่ KVM, OpenVZ และ LXC เป็นคำถามเรื่องความสามารถก่อนจะเป็นคำถามเรื่องความเร็ว
คู่มือนี้ครอบคลุมสามชื่อเรียกที่เกี่ยวข้องมากที่สุดกับการตัดสินใจซื้อครั้งนี้ Xen, VMware, Hyper-V และแพลตฟอร์มการจำลองเสมือนอื่น ๆ ก็มีอยู่ แต่อยู่นอกขอบเขตการเปรียบเทียบสามทางนี้
TL;DR (สรุปย่อ)
- KVM ให้ VPS แต่ละเครื่องมีเคอร์เนลเกสต์ของตัวเอง Docker ทำงานได้ตามปกติ Windows เป็นไปได้ในทางเทคนิค และโดยทั่วไปคุณสามารถโหลดโมดูลเคอร์เนลหรือบูตเคอร์เนลที่กำหนดเองได้ อย่างไรก็ตาม KVM เพียงอย่างเดียวไม่ได้รับประกัน CPU หรือ RAM แบบเฉพาะ การรับประกันทรัพยากรยังขึ้นอยู่กับผู้ให้บริการและแพ็กเกจ
- OpenVZ แพ็กเกจ VPS มักเป็นคอนเทนเนอร์ Linux ที่ใช้เคอร์เนลของโฮสต์ร่วมกัน Docker จะรันบน OpenVZ 7 ได้ก็ต่อเมื่อผู้ให้บริการใช้เคอร์เนลและการตั้งค่าเทมเพลตที่รองรับ คุณไม่สามารถเปลี่ยนเคอร์เนลของโฮสต์ได้ และหน่วยความจำที่เกินจาก RAM จะถูกจัดการผ่าน VSwap ที่ผู้ให้บริการควบคุม แทนที่จะเป็นสว็อปบนดิสก์ตามปกติที่เกสต์จัดการเอง
- LXC ก็ใช้เคอร์เนลของโฮสต์ร่วมกันเช่นกัน แต่สร้างขึ้นบนคุณสมบัติการกักกันของ Linux สายหลัก Docker จะรันได้เมื่อโฮสต์เปิดใช้คุณสมบัติที่จำเป็น แม้ว่า Proxmox จะแนะนำให้ซ้อนคอนเทนเนอร์ไว้ในเครื่องเสมือน QEMU สำหรับงานที่ต้องการการแยกส่วนสูงสุดและการย้ายแบบสด
- โดยทั่วไปคอนเทนเนอร์ปรับขนาดขณะทำงานได้ง่ายกว่า KVM เองก็รองรับการเพิ่ม CPU และหน่วยความจำแบบ hot-plug ได้ ดังนั้น "KVM ต้องรีบูตเสมอ" จึงไม่ใช่กฎการซื้อที่ปลอดภัย ควรถามผู้ให้บริการว่าแพลตฟอร์มของเขารองรับอะไรจริง ๆ
- สำหรับเว็บไซต์แบบสแตติกหรือ LAMP stack ขนาดเล็กที่ไม่เคยต้องใช้ Docker, Windows หรือการปรับแต่งระดับเคอร์เนล ความแตกต่างในทางปฏิบัติอาจน้อยมาก แต่การแยกส่วน วงจรชีวิต และนโยบายทรัพยากรก็ยังต่างกันได้
ความต่างเพียงข้อเดียวที่ทำให้เกิดความต่างอื่นทั้งหมด
KVM ให้ VPS ทุกเครื่องบนโฮสต์มีเคอร์เนลเกสต์ของตัวเอง ส่วนคอนเทนเนอร์ OpenVZ และ LXC ใช้เคอร์เนลที่โฮสต์บูตขึ้นมา
KVM คือโซลูชันการจำลองเสมือนเต็มรูปแบบสำหรับฮาร์ดแวร์ x86 ที่มีส่วนขยายด้านการจำลองเสมือน โดยถูกรวมเข้าเคอร์เนล Linux สายหลักตั้งแต่เวอร์ชัน 2.6.20 เกสต์แต่ละตัวจะเห็นฮาร์ดแวร์เสมือนและบูตระบบปฏิบัติการกับเคอร์เนลของตัวเอง
ประเภทคอนเทนเนอร์ทำงานต่างออกไป LXC คือ อินเทอร์เฟซระดับ userspace สำหรับคุณสมบัติการกักกันของเคอร์เนล Linux ซึ่งรวมถึง namespace, cgroups, capabilities, seccomp และโปรไฟล์ความปลอดภัย โดยมุ่งให้ได้สภาพแวดล้อมที่ใกล้เคียงกับการติดตั้ง Linux ปกติ โดยไม่ต้องบูตเคอร์เนลแยกต่างหาก
คอนเทนเนอร์ OpenVZ ใช้โมเดลเคอร์เนลร่วมแบบเดียวกันในภาพรวม แม้ว่า OpenVZ จะมีแพลตฟอร์มและสแตกเคอร์เนลของตัวเอง OpenVZ 7 จัดการได้ทั้งคอนเทนเนอร์และเครื่องเสมือน KVM แต่เมื่อแพ็กเกจ VPS ที่ขายทั่วไประบุว่า "OpenVZ" สินค้าที่ขายมักเป็นแบบคอนเทนเนอร์
ความต่างด้านความสามารถทั้งหมดข้างล่างนี้ล้วนมาจากจุดนั้น โมดูลเคอร์เนลต้องถูกโหลดเข้าเคอร์เนลที่คุณควบคุม ระบบปฏิบัติการที่ต่างกันก็ต้องใช้เคอร์เนลที่ต่างกัน Docker ต้องการ namespace ระดับเคอร์เนล ซึ่งต้องมีอยู่ในที่ที่เคอร์เนลนั้นอยู่ ในฝั่ง KVM ของเส้นแบ่งนี้ ชั้นไฮเปอร์ไวเซอร์เป็นไปตามสถาปัตยกรรมที่มักแบ่งออกเป็น ไฮเปอร์ไวเซอร์ Type 1 และ Type 2.
LXC ปรากฏบ่อยในสภาพแวดล้อม Proxmox รวมถึงเซิร์ฟเวอร์ที่ดูแลเองและแพลตฟอร์มโฮสติ้งบางแห่ง ส่วนคุณจะเปิดใช้คุณสมบัติขั้นสูงของ LXC ได้หรือไม่นั้นขึ้นอยู่กับว่าใครควบคุมโฮสต์นั้น
แต่ละประเภทให้คุณรันอะไรได้บ้าง
แกนที่กำหนดการตัดสินใจซื้อคือการควบคุมเคอร์เนล การรองรับระบบปฏิบัติการเกสต์ ความเข้ากันได้กับ Docker พฤติกรรมของหน่วยความจำ การปรับขนาด และนโยบายทรัพยากร
| ความสามารถ | KVM | OpenVZ | LXC |
|---|---|---|---|
| Docker | ได้ โดยตรง | มีเงื่อนไข: เฉพาะ OpenVZ 7 และผู้ให้บริการต้องใช้เทมเพลต EZ หรือเทมเพลตกำหนดเองที่เหมาะสม พร้อมคุณสมบัติเคอร์เนลของโฮสต์ที่จำเป็น | มีเงื่อนไข: โฮสต์ต้องเปิดใช้ nesting และ keyctl |
| เคอร์เนลที่กำหนดเองหรือโมดูลที่โหลดได้ | โดยทั่วไปได้ | ไม่ได้ ถูกล็อกไว้กับเคอร์เนลของโฮสต์ | ไม่ได้ ใช้เคอร์เนลของโฮสต์ร่วมกัน |
| Windows เป็นระบบปฏิบัติการเกสต์ | ได้ เมื่อผู้ให้บริการรองรับอิมเมจและเส้นทางการออกใบอนุญาต | ไม่ได้ เฉพาะ Linux | ไม่ได้ เฉพาะ Linux |
| โมดูลเคอร์เนลสำหรับ VPN (WireGuard, OpenVPN) | เกสต์เป็นผู้ควบคุม | ขึ้นอยู่กับผู้ให้บริการ: ต้องเปิด TUN/TAP ให้ใช้งาน | ขึ้นอยู่กับผู้ให้บริการ: ขึ้นกับคุณสมบัติเคอร์เนลที่โฮสต์เปิดใช้ |
| การควบคุมสว็อป | เกสต์เป็นผู้ควบคุม | VSwap ที่โฮสต์จัดการ แทนสว็อปบนดิสก์ตามปกติ | นโยบายของโฮสต์ ใช้ cgroup v2 รุ่นใหม่ |
| ปรับขนาดทรัพยากรขณะทำงานโดยไม่ต้องรีบูต | ขึ้นอยู่กับแพลตฟอร์ม สามารถ hot-plug CPU และหน่วยความจำได้ | มักทำได้ | มักทำได้ |
| การรับประกันทรัพยากรเฉพาะ | ไม่ได้มีมาในตัว ขึ้นอยู่กับนโยบายของผู้ให้บริการ | ไม่ได้มีมาในตัว และความหนาแน่นของคอนเทนเนอร์ทำให้ขายเกินได้ง่ายขึ้น | ไม่ได้มีมาในตัว |
ควรเลือกแบบไหนดี KVM คือคำตอบที่ชัดเจนที่สุดเมื่อคุณต้องการ Windows เคอร์เนลที่กำหนดเอง โมดูลที่เกสต์โหลดเอง หรือโฮสต์ Docker ที่คาดเดาได้ ส่วน OpenVZ และ LXC อาจเป็นสภาพแวดล้อม Linux ที่มีประสิทธิภาพ แต่ปล่อยให้การตัดสินใจระดับเคอร์เนลอยู่ในมือผู้ให้บริการ
นี่คือแผนที่ความสามารถ ไม่ใช่ผลการวัดประสิทธิภาพ มันไม่ได้บอกอะไรเลยเกี่ยวกับความหน่วงของสตอเรจ คุณภาพเครือข่าย รุ่นของ CPU อัตราการใช้งานโฮสต์ หรือนโยบายการจัดสรรทรัพยากรของผู้ให้บริการ ผู้ให้บริการสองรายที่ใช้การจำลองเสมือนแบบเดียวกันอาจส่งมอบเครื่องที่ต่างกันมาก
ช่องที่เป็นเงื่อนไขนี่แหละที่ทำให้ผู้ซื้อเสียเวลา ผมเคยติดตั้ง VPN บน VPS แบบคอนเทนเนอร์ที่ฟีเจอร์เครือข่ายฝั่งโฮสต์ซึ่งจำเป็นนั้นไม่ได้ถูกเปิดไว้ อินเทอร์เฟซไม่ยอมขึ้น และการแก้ไขต้องเปิดทิกเก็ตหาฝ่ายสนับสนุน ไม่ใช่แค่แก้คอนฟิกภายในเกสต์ หากเลือกแพ็กเกจแบบคอนเทนเนอร์ ให้ถามว่าผู้ให้บริการเปิดอุปกรณ์หรือคุณสมบัติเคอร์เนลที่ VPN ของคุณต้องใช้จริง ๆ หรือไม่ ส่วนกับ KVM คุณมักควบคุมสิ่งนั้นได้เองจากภายในเกสต์
ทำไม Docker จึงเป็นคำถามที่ชี้ขาดการซื้อส่วนใหญ่
VPS แบบคอนเทนเนอร์เทียบกับ VPS แบบ KVM เลิกเป็นการเปรียบเทียบเชิงนามธรรมทันทีที่ Docker ปรากฏในความต้องการของคุณ ตัว Docker เองใช้ namespace ของเคอร์เนล, cgroups, ระบบเครือข่าย และไดรเวอร์สตอเรจ ภายใน KVM คุณสมบัติเหล่านั้นเป็นของเคอร์เนลเกสต์ที่คุณควบคุม ส่วนภายใน OpenVZ หรือ LXC สุดท้ายแล้วก็ขึ้นอยู่กับโฮสต์
Docker บน OpenVZ
การรองรับ Docker บน OpenVZ เป็นการตัดสินใจเรื่องการจัดเตรียมระบบที่เกิดขึ้นเหนือคุณ บทความสนับสนุนของ SolusVM ระบุว่า Docker สามารถรันภายใน OpenVZ 7 ได้ตั้งแต่เคอร์เนลรุ่นฐาน 3.10 รุ่นหนึ่งเป็นต้นไป แต่ก็บอกด้วยว่า Docker ใช้กับเทมเพลตสำเร็จรูปแบบเก่ามาตรฐานไม่ได้ คอนเทนเนอร์ต้องใช้เทมเพลต EZ หรือเทมเพลตกำหนดเองที่เหมาะสม บทความเดียวกันนี้ยังไม่รวมเกสต์ที่ใช้ CentOS 8
แล้ว Docker ทำงานบน OpenVZ ได้หรือไม่ บางครั้งก็ได้ ผู้ให้บริการต้องสร้างบริการขึ้นบนเคอร์เนล OpenVZ 7 ที่รองรับและเส้นทางเทมเพลตที่เหมาะสม หากหน้าแพ็กเกจไม่ได้ระบุไว้ชัดเจน ให้สอบถามฝ่ายสนับสนุนก่อนซื้อ และเก็บคำตอบไว้เป็นลายลักษณ์อักษร
เมื่อการตั้งค่าของโฮสต์ไม่เข้ากัน การเปลี่ยนแฟล็กของ Docker ภายใน VPS จะไม่แก้ปัญหาที่ต้นเหตุ คุณต้องให้ผู้ให้บริการเปลี่ยนการตั้งค่าคอนเทนเนอร์ หรือย้ายคุณไปยังการจำลองเสมือนประเภทอื่น
Docker บน LXC
Docker รันภายใน LXC ได้เมื่อโฮสต์เปิดคุณสมบัติที่จำเป็น ใน Proxmox มักหมายถึงการซ้อนคอนเทนเนอร์ และ keyctl สำหรับคอนเทนเนอร์แบบไม่มีสิทธิพิเศษ
สัญญาณที่สำคัญกว่าในการตัดสินใจซื้อคือคำแนะนำจากเจ้าของแพลตฟอร์มเอง เอกสารของ Proxmox ระบุว่า การซ้อนคอนเทนเนอร์ไว้ในเครื่องเสมือน QEMU ของ Proxmox ยังคงเป็นแนวปฏิบัติที่แนะนำ สำหรับกรณีใช้งานที่ต้องการการแยกส่วนสูงสุดและความสามารถในการย้ายแบบสด แทนที่จะรันไว้ในคอนเทนเนอร์ระบบ LXC โดยตรง
หากคุณควบคุมโฮสต์ LXC เอง คุณสามารถชั่งน้ำหนักข้อแลกเปลี่ยนนั้นและทดสอบการอัปเกรดตามจังหวะของคุณเองได้ แต่ถ้าคุณเช่า VPS แบบ LXC ผู้ให้บริการคือผู้ควบคุมเคอร์เนล โปรไฟล์ความปลอดภัย และแฟล็กของคุณสมบัติขั้นสูง จงยืนยันการตั้งค่าที่รองรับ แทนที่จะคิดเอาเองว่าการมีสิทธิ์ root ภายในคอนเทนเนอร์นั้นเพียงพอแล้ว
Docker บน KVM
โดยปกติ Docker ทำงานได้เพราะเกสต์ Linux ควบคุมสภาพแวดล้อมเคอร์เนลของตัวเอง ไม่มีสวิตช์ nesting ของ LXC หรือข้อกำหนดเรื่องเทมเพลตของ OpenVZ อยู่เหนือเกสต์ แต่คุณก็ยังต้องมีดิสโทร Linux ที่รองรับ เคอร์เนลที่เข้ากันได้ และ RAM กับพื้นที่จัดเก็บที่เพียงพอต่อภาระงาน
การเป็นเจ้าของเคอร์เนลเกสต์ยังหมายถึงต้องดูแลรักษามันด้วย บน VPS แบบไม่มีการจัดการให้ การอัปเดต กฎไฟร์วอลล์ ความปลอดภัยของ Docker และการสำรองข้อมูล ยังคงเป็นความรับผิดชอบของคุณ
ประเด็นสำคัญ: Docker ไม่ได้ทำให้ OpenVZ หรือ LXC เป็นไปไม่ได้ แต่ทำให้การตั้งค่าของผู้ให้บริการกลายเป็นส่วนหนึ่งของความน่าเชื่อถือของแอปพลิเคชันคุณ สำหรับโฮสต์ Docker ระดับใช้งานจริงที่เช่ามา KVM ตัดการพึ่งพาส่วนเกินนั้นออกไป
"4 vCPU" หมายถึงซีพียูสี่คอร์แบบเฉพาะจริงหรือไม่
VPS ที่รู้สึกช้าแต่ระบบมอนิเตอร์ของตัวเองกลับแสดงว่า CPU ว่างอยู่ คืออาการที่ผู้คนเล่าถึงบ่อยที่สุด สิ่งที่ทำให้เกิดเรื่องนี้ได้คือการจำลองเสมือนแบบคอนเทนเนอร์ การแย่งทรัพยากรเกิดขึ้นในชั้นที่อยู่ต่ำกว่าที่เกสต์จะมองเห็น ตัวชี้วัดของเกสต์เองจึงไม่แสดงความผิดปกติใด ๆ
กลไกก็คือค่าใช้จ่ายแฝงที่ต่ำนั่นเอง คอนเทนเนอร์กินทรัพยากรของโฮสต์น้อยกว่าเครื่องเสมือนเต็มรูปแบบมาก จึงยัดคอนเทนเนอร์ลงบนฮาร์ดแวร์เดียวกันได้มากกว่า ความหนาแน่นแบบนี้สร้างได้ถูกและตรวจจับจากภายในเกสต์ได้ยาก ทำให้การขายเกินทำได้ง่ายกว่าเชิงโครงสร้างบน OpenVZ มากกว่าบน KVM ทั้งนี้ KVM ไม่ได้ห้ามผู้ให้บริการยัดเครื่องให้แน่น แต่มันจองหน่วยความจำจริงและส่วนแบ่ง CPU จริงให้เกสต์แต่ละตัว ซึ่งเป็นเพดานทางคณิตศาสตร์ว่าจะยัดได้มากแค่ไหน ส่วนด้านการวินิจฉัยนั้นมีคู่มือเฉพาะเรื่อง วิธีดูว่าผู้ให้บริการของคุณขายเกินหรือไม่.
หน่วยความจำก็ทำงานต่างออกไปเช่นกัน บน OpenVZ คุณใช้สว็อปบนดิสก์เป็นหน่วยความจำเพิ่มเติมไม่ได้ ตัวเลข RAM บนหน้าแพ็กเกจจึงเป็นกำแพง ไม่ใช่ทางลาด เกสต์ KVM ที่เจอแรงกดดันด้านหน่วยความจำจะช้าลง ส่วนคอนเทนเนอร์ OpenVZ ที่เจอแรงกดดันเดียวกันจะถูกฆ่าโปรเซสทิ้ง
ยังมีผลด้านการแยกส่วนด้วย และนี่คือสิ่งที่ผู้คนประเมินต่ำเกินไป หน่วยความจำของคอนเทนเนอร์สามารถเข้าถึงได้จากโฮสต์ในแบบที่หน่วยความจำของเกสต์ KVM ทำไม่ได้ การเข้ารหัสดิสก์ภายในเกสต์ยังคงปกป้องคุณจากการถูกขโมยดิสก์ แต่ไม่ได้ปกป้องกุญแจของคอนเทนเนอร์ที่กำลังทำงานจากเครื่องที่รันมันอยู่ หากแบบจำลองภัยคุกคามของคุณรวมถึงผู้ดำเนินการโฮสต์ด้วย เคอร์เนลที่ใช้ร่วมกันก็เป็นฐานที่ผิด และไม่มีการตั้งค่าใดภายในเกสต์ที่จะเปลี่ยนเรื่องนี้ได้
ประเด็นสำคัญ: ตัวเลขเดียวกันบนหน้าแพ็กเกจคือคำสัญญาคนละแบบ ขึ้นอยู่กับประเภท บน KVM มันคือการจัดสรร ส่วนบน OpenVZ มันคือเพดานที่คุณต้องแบ่งกับคนอื่น
OpenVZ ยังเหมาะกับงานแบบไหน และกำลังมุ่งไปทางใด
หากคุณรันเว็บไซต์แบบสแตติกหรือ LAMP stack ที่ทราฟฟิกต่ำ คุณอาจไม่เคยแตะความสามารถที่ OpenVZ จำกัดไว้เลย ไม่ต้องใช้ Windows ไม่ต้องใช้เคอร์เนลกำหนดเอง ไม่ต้องโหลดโมดูลจากฝั่งเกสต์ และไม่ต้องรัน Docker ในระบบจริง สำหรับภาระงานแคบ ๆ แบบนั้น คอนเทนเนอร์ OpenVZ ที่ดูแลอย่างดีก็ยังทำงานได้
วงจรชีวิตต้องการความใส่ใจมากกว่าเมื่อสิบปีก่อน OpenVZ 7 อิงกับสายเคอร์เนลของ RHEL 7 เวอร์ชัน 3.10 ตัวเลขเวอร์ชันเพียงอย่างเดียวไม่ได้พิสูจน์ว่าเคอร์เนลระดับองค์กรที่ยังได้รับการดูแลนั้นขาดการแก้ไขด้านความปลอดภัย เพราะผู้จำหน่ายจะ backport แพตช์ให้ แต่มันหมายความว่าคุณควรตรวจสอบความเข้ากันได้กับซอฟต์แวร์ที่คาดหวังอินเทอร์เฟซเคอร์เนลรุ่นใหม่กว่า
The open-source OpenVZ project and the commercial Virtuozzo product are on separate tracks, and the commercial one has published dates. Virtuozzo Hybrid Server 7 reached end of maintenance in July 2024 and is listed for end of life in December 2027 in the นโยบายวงจรชีวิตอย่างเป็นทางการ.
เรื่องนี้ไม่ได้ทำให้เว็บไซต์ OpenVZ ที่ใช้งานอยู่ตอนนี้พังลง แต่ทำให้แผนการย้ายระบบของผู้ให้บริการมีความสำคัญ ก่อนที่คุณจะฝากภาระงานใหม่ที่ต้องอยู่ยาวไว้กับมัน ให้ถามว่าใช้ OpenVZ หรือ Virtuozzo เวอร์ชันใด ส่งมอบการแก้ไขด้านความปลอดภัยอย่างไร และมีเส้นทางการย้ายระบบแบบใดบ้าง
เมื่อหน้าแพ็กเกจไม่ได้ระบุประเภทการจำลองเสมือน ให้ถามฝ่ายสนับสนุนแทนที่จะเดาจากราคา คำตอบนั้นควรเก็บไว้เป็นลายลักษณ์อักษร
เลือกตามลักษณะภาระงาน
เริ่มจากความต้องการ ไม่ใช่จากเทคโนโลยี
เลือก KVM เมื่อภาระงานต้องการเคอร์เนลของตัวเอง
KVM คือตัวเลือกตรงไปตรงมาเมื่อคุณต้องการสิ่งใดสิ่งหนึ่งต่อไปนี้:
- Windows เป็นระบบปฏิบัติการของเกสต์
- เคอร์เนลที่กำหนดเอง
- โมดูลเคอร์เนลที่เกสต์โหลดเอง
- Docker ระดับใช้งานจริงโดยไม่ต้องพึ่งการซ้อนคอนเทนเนอร์ในคอนเทนเนอร์
- การจำลองเสมือนซ้อนชั้น เมื่อผู้ให้บริการเปิดให้ใช้
- สว็อปและการปรับจูนเคอร์เนลที่เกสต์ควบคุมเอง
Windows เป็นตัวชี้ขาด เพราะทั้งคอนเทนเนอร์ OpenVZ และ LXC ต่างใช้เคอร์เนลโฮสต์ที่เป็น Linux ส่วนการเลือกระหว่าง Linux กับ Windows สำหรับตัวแอปพลิเคชันเองเป็นคนละคำถาม ซึ่งเกี่ยวกับความเข้ากันได้ของซอฟต์แวร์ การดูแลระบบ และการออกใบอนุญาต ดู การเปรียบเทียบ VPS แบบ Linux กับ Windows สำหรับการตัดสินใจนั้น
เลือก LXC เมื่อคุณต้องการคอนเทนเนอร์ระบบ Linux ที่มีประสิทธิภาพ
LXC สมเหตุสมผลเมื่อภาระงานใช้เฉพาะ Linux ไม่ต้องการเคอร์เนลแยก และได้ประโยชน์จากค่าใช้จ่ายแฝงที่ต่ำหรือการเปลี่ยนแปลงที่โฮสต์จัดการได้อย่างรวดเร็ว มันมีประโยชน์เป็นพิเศษเมื่อคุณควบคุมโฮสต์ Proxmox หรือ LXC ด้วยตัวเอง
สำหรับ VPS แบบ LXC ที่เช่ามา ให้ตรวจสอบการรองรับ Docker อุปกรณ์ที่จำเป็น โหมดความปลอดภัย พฤติกรรมการสำรองข้อมูล และว่าจะเปิดใช้คุณสมบัติขั้นสูงได้หรือไม่
พิจารณา OpenVZ สำหรับภาระงาน Linux ที่เรียบง่ายและตรวจสอบแล้ว
OpenVZ ยังพอรับได้สำหรับเว็บไซต์พื้นฐาน LAMP stack ขนาดเล็ก บริการ DNS หรือภาระงาน Linux ทั่วไปในลักษณะเดียวกัน เมื่อ:
- ผู้ให้บริการระบุเวอร์ชันของแพลตฟอร์มไว้ชัดเจน
- ซอฟต์แวร์ของคุณรองรับสภาพแวดล้อมเคอร์เนลที่มีอยู่
- คุณไม่จำเป็นต้องใช้ Windows หรือปรับแต่งเคอร์เนล
- ไม่จำเป็นต้องใช้ Docker หรือไม่ก็มีการรองรับอย่างชัดเจน
- ผู้ให้บริการมีแผนด้านความปลอดภัยและการย้ายระบบที่น่าเชื่อถือ
- ราคาหรือรูปแบบการดำเนินงานให้เหตุผลที่แท้จริงแก่คุณในการเลือกมัน
อย่าเลือกมันเพียงเพราะบทเปรียบเทียบเก่า ๆ บอกว่า OpenVZ ถูกกว่าเสมอ ให้เปรียบเทียบแพ็กเกจปัจจุบัน การสนับสนุน นโยบายทรัพยากร และตัวเลือกในการย้ายระบบ
หากคำตอบของคุณลงเอยที่ KVM นั่นคือข้อจำกัดเป็นตัวตัดสิน ไม่ใช่ความชอบส่วนตัว KVM VPS ของ Cloudzy บูตได้ใน 60 วินาทีบน AMD EPYC พร้อม NVMe ล้วน และทุกอินสแตนซ์ได้เคอร์เนลเกสต์ของตัวเอง โมดูลเคอร์เนลโหลดได้ เคอร์เนลที่กำหนดเองบูตได้ และรองรับเกสต์ทั้ง Linux และ Windows Docker มีให้ในมาร์เก็ตเพลส หากคุณไม่อยากติดตั้งเอง
คำถามที่พบบ่อย
ฉันรัน Docker บน VPS แบบ OpenVZ ได้ไหม
ได้ก็ต่อเมื่อผู้ให้บริการตั้งค่าสภาพแวดล้อม OpenVZ 7 ที่รองรับไว้แล้ว SolusVM ระบุการรองรับบนเคอร์เนล OpenVZ 7 ที่ใหม่พอ ร่วมกับเทมเพลต EZ หรือเทมเพลตกำหนดเองที่เหมาะสม ขณะที่เทมเพลตรุ่นเก่ามาตรฐานใช้ไม่ได้ ให้ถือว่า Docker ไม่รองรับ จนกว่าผู้ให้บริการจะยืนยันการตั้งค่าที่แน่ชัด
OpenVZ รัน Windows ได้ไหม
ไม่ได้ ถ้าเป็นคอนเทนเนอร์ OpenVZ เพราะคอนเทนเนอร์ใช้เคอร์เนล Linux ของโฮสต์ร่วมกัน ส่วน KVM รันเกสต์ Windows ได้ เพราะเครื่องเสมือนบูตเคอร์เนลของระบบปฏิบัติการตัวเอง แม้ผู้ให้บริการจะยังต้องรองรับอิมเมจ ไฟล์ ISO และเส้นทางการออกใบอนุญาตด้วย
LXC เหมือนกับ Docker หรือไม่
ไม่เหมือนกัน LXC มักใช้ทำคอนเทนเนอร์ระบบที่คล้ายเครื่อง Linux ขนาดเบา มีระบบ init และหลายโปรเซส ส่วน Docker เป็นแพลตฟอร์มคอนเทนเนอร์แอปพลิเคชันที่สร้างขึ้นรอบอิมเมจและบริการเดี่ยว ๆ ทั้งคู่ใช้คุณสมบัติของเคอร์เนล Linux อย่าง namespace และ cgroups จึงเป็นเหตุให้คำสองคำนี้ถูกสับสนกันบ้าง
VPS แบบ LXC คืออะไร
VPS แบบ LXC คือคอนเทนเนอร์ระบบ Linux ที่ให้บริการผ่าน LXC หรือแพลตฟอร์มที่สร้างบน LXC อย่าง Proxmox มันดูและทำงานคล้ายเซิร์ฟเวอร์ Linux ขนาดเล็ก แต่ใช้เคอร์เนลของโฮสต์ร่วมกันแทนที่จะบูตเคอร์เนลของตัวเอง จึงเบาแต่ก็จำกัดการควบคุมในระดับเคอร์เนล
จะรู้ได้อย่างไรว่าผู้ให้บริการใช้การจำลองเสมือนประเภทใด
ตรวจดูที่หน้าแพ็กเกจหรือสอบถามฝ่ายสนับสนุน ภายในอินสแตนซ์ Linux คำสั่งนี้มักระบุสภาพแวดล้อมได้:
systemd-detect-virtมันอาจรายงานค่าอย่างเช่น kvm, openvzหรือ lxc การตรวจจับจากภายในเกสต์นั้นมีประโยชน์ แต่ก่อนตัดสินใจซื้อ ข้อกำหนดที่ผู้ให้บริการเขียนไว้เป็นลายลักษณ์อักษรยังคงเป็นแหล่งข้อมูลที่ดีกว่า
KVM รับประกัน CPU และ RAM แบบเฉพาะหรือไม่
ไม่ KVM รองรับการจัดสรร CPU และหน่วยความจำเกินจริง ผู้ให้บริการอาจเสนอทรัพยากรแบบสำรองไว้ แบบใช้ร่วมกัน หรือผสมทั้งสองแบบ ให้มองหาถ้อยคำที่ชัดเจน เช่น RAM แบบเฉพาะ, CPU แบบปักหมุด, vCPU ที่สำรองไว้ หรือไม่มีการจัดสรรเกิน แทนที่จะคิดเอาเองว่าไฮเปอร์ไวเซอร์รับประกันให้
KVM เป็นตัวเลือกที่ดีกว่าเสมอไปหรือไม่
ไม่ KVM เป็นตัวเลือกเดียวสำหรับ Docker เคอร์เนลที่กำหนดเอง และ Windows แต่สำหรับภาระงานที่ไม่เคยแตะสิ่งเหล่านี้เลย ความต่างในทางปฏิบัติแทบมองไม่เห็น
การสนทนา
ความคิดเห็น
เข้าสู่ระบบเพื่อร่วมสนทนา