KVM เครื่องเสมือน คอนเทนเนอร์ และฮาร์ดแวร์เฉพาะอธิบายขอบเขตการดำเนินงานที่แตกต่างกัน เลือกขอบเขตที่โครงการของคุณต้องการ ตรวจสอบคุณสมบัติที่ข้อเสนอเปิดเผย และดูแลซอฟต์แวร์ภายในสภาพแวดล้อมนั้น
เครื่องเสมือนคือสภาพแวดล้อม guest
เครื่องเสมือนนำเสนอระบบปฏิบัติการพร้อมฮาร์ดแวร์เสมือน เช่น โปรเซสเซอร์ ดิสก์ และอินเทอร์เฟซเครือข่าย โฮสต์ทางกายภาพรันกลไกที่ทำให้ guest เหล่านั้นเป็นไปได้ VPS เป็นผลิตภัณฑ์โฮสติ้งที่สร้างขึ้นรอบเซิร์ฟเวอร์เสมือน โดยมีการจัดสรรทรัพยากรที่ระบุไว้และสภาพแวดล้อมการดำเนินงานที่ลูกค้าสามารถใช้ได้ อ่านการจัดสรรเป็นส่วนหนึ่งของข้อเสนอ แทนที่จะจินตนาการถึงเครื่องทางกายภาพเบื้องหลัง CPU เสมือนทุกเครื่อง
เซิร์ฟเวอร์เฉพาะให้ขอบเขตเครื่องทางกายภาพแก่โครงการ สามารถรันระบบปฏิบัติการหนึ่งระบบหรือโฮสต์เครื่องเสมือนของตนเองได้เมื่อฮาร์ดแวร์และการติดตั้งใช้งานรองรับการออกแบบนั้น สิ่งนี้เปลี่ยนความเป็นเจ้าของทรัพยากรและการดูแลระบบ แต่ไม่ได้ลบช่องโหว่ของซอฟต์แวร์ งานอัปเดต หรือความจำเป็นในการสำรองข้อมูล เลือกขอบเขตจากความต้องการด้านการแยกหรือความจุที่แท้จริง
KVM ระบุเทคโนโลยีการจำลองเสมือน
KVM ให้การสนับสนุนการจำลองเสมือนในเคอร์เนล Linux QEMU จัดหาแบบจำลองเครื่องและสามารถใช้ KVM เป็นตัวเร่งการจำลองเสมือน ในขณะที่ซอฟต์แวร์จัดการเช่น libvirt สามารถจัดระเบียบคอนฟิกูเรชันและวงจรชีวิตของ guest องค์ประกอบเหล่านี้อธิบายว่าสภาพแวดล้อมสามารถสร้างขึ้นได้อย่างไร ตัวอักษร KVM ไม่ได้ระบุการจัดตารางเวลา CPU ประสิทธิภาพการจัดเก็บ หรือความพร้อมใช้งานของบริการ
เอกสารการจำลองเสมือนบางครั้งแยกไฮเปอร์ไวเซอร์ Type 1 และ Type 2 ตามความสัมพันธ์กับแพลตฟอร์มโฮสต์ สำหรับการตัดสินใจด้านโฮสติ้ง ป้ายกำกับมีประโยชน์น้อยกว่าการรู้ขอบเขต guest ความรับผิดชอบในการบำรุงรักษา และฮาร์ดแวร์ที่เปิดเผย ถามว่าระบบปฏิบัติการ guest และไดรเวอร์ที่ต้องการได้รับการสนับสนุนหรือไม่ คุณสมบัติที่อธิบายโดยโครงการซอฟต์แวร์ไม่ได้เปิดใช้งานโดยอัตโนมัติในผลิตภัณฑ์ของผู้ให้บริการทุกราย
อย่าสับสนระหว่างการควบคุม guest กับการควบคุม host
การเข้าถึง root หรือผู้ดูแลภายใน guest ให้คุณจัดการ guest นั้น ไม่ได้ให้คุณเข้าถึงไฮเปอร์ไวเซอร์ทางกายภาพ ผู้เช่ารายอื่น หรือคุณสมบัติโฮสต์ที่เป็นไปได้ทั้งหมด การจำลองเสมือนแบบซ้อน การส่งผ่านอุปกรณ์ และการตั้งค่าเครือข่ายเฉพาะทางต้องได้รับการสนับสนุนอย่างชัดเจน อย่าเลือก VPS โดยสมมติว่าความสามารถที่มีในแล็ปท็อปของคุณจะถูกเปิดเผยเหมือนกันโดยสภาพแวดล้อมโฮสติ้ง
เปรียบเทียบ CPU หน่วยความจำ การจัดเก็บ เครือข่าย และใบอนุญาตของแผนจริง สังเกตความหน่วงและแรงกดดันด้านทรัพยากรของแอปพลิเคชันด้วยงานที่เป็นตัวแทนหลังการส่งมอบ เทคโนโลยีการจำลองเสมือนสามารถสร้างขอบเขตการแยกที่มีประโยชน์ในขณะที่ยังใช้ทรัพยากรฮาร์ดแวร์พื้นฐานร่วมกันตามนโยบายของผู้ให้บริการ ทั้งป้ายกำกับ guest หรือป้ายกำกับเฉพาะไม่ใช่สิ่งทดแทนการวัดและการระบุการดำเนินงานที่ครบถ้วน
| ขอบเขต | สิ่งที่โครงการจัดการ | ความสามารถที่ต้องตรวจสอบ |
|---|---|---|
| เครื่องเสมือน | ระบบปฏิบัติการ guest และบริการของระบบ | ระบบปฏิบัติการ ไดรเวอร์ และคุณสมบัติที่เปิดเผยซึ่งได้รับการสนับสนุน |
| คอนเทนเนอร์ | การกำหนดค่ากระบวนการและอิมเมจ | คุณสมบัติเคอร์เนล ขีดจำกัด และขอบเขตการเมานต์ |
| เซิร์ฟเวอร์เฉพาะ | สภาพแวดล้อมเครื่องทางกายภาพที่เลือก | ข้อกำหนดด้านฮาร์ดแวร์และการจำลองเสมือน |
คอนเทนเนอร์จัดระเบียบกระบวนการภายในสภาพแวดล้อม
คอนเทนเนอร์โดยทั่วไปใช้เคอร์เนลของโฮสต์ร่วมกันในขณะที่จัดกลุ่มกระบวนการและทรัพยากรของกระบวนการเหล่านั้น เครื่องเสมือนรันเคอร์เนล guest คุณสามารถรันคอนเทนเนอร์ภายใน VPS ได้เมื่อระบบปฏิบัติการและรันไทม์รองรับคอนฟิกูเรชันที่ตั้งใจไว้ การรวมกันนั้นสามารถทำให้การแพ็กเกจ dependencies ง่ายขึ้นโดยไม่แทนที่การบำรุงรักษาความปลอดภัยหรือแผนการกู้คืนของ guest
การควบคุมทรัพยากรของ Docker ต้องมีการตั้งค่าอย่างตั้งใจ โดยค่าเริ่มต้น รันไทม์ไม่ได้กำหนดขีดจำกัด CPU และหน่วยความจำให้กับแต่ละคอนเทนเนอร์ จำกัดการใช้ทรัพยากรและหลีกเลี่ยงสิทธิ์พิเศษหรือการเมานต์โฮสต์ที่ไม่จำเป็น แยกเวิร์กโหลดที่มีข้อกำหนดความเชื่อถือต่างกันออกจากกันเมื่อทำได้ ดูแลโฮสต์และอิมเมจให้ได้รับการบำรุงรักษา ปฏิบัติต่ออิมเมจคอนเทนเนอร์เป็นซอฟต์แวร์ที่คุณต้องตรวจสอบ ไม่ใช่เป็นการตัดสินใจด้านความปลอดภัยโดยอัตโนมัติเพียงเพราะเริ่มต้นได้ง่าย
เชลล์เป็นตัวแปลคำสั่ง ไม่ใช่เซิร์ฟเวอร์เอง
เทอร์มินัลให้พื้นผิวสำหรับการโต้ตอบ เชลล์ตีความคำสั่งและเริ่มโปรแกรม บน Linux Bash เป็นเชลล์ทั่วไป ในขณะที่เชลล์อื่นมีไวยากรณ์และคุณสมบัติการโต้ตอบที่แตกต่างกัน สคริปต์ต้องกำหนดเป้าหมายไปยังตัวแปลคำสั่งที่คาดไว้ การเปลี่ยนเชลล์เข้าสู่ระบบไม่ได้เปลี่ยนตัวแปลคำสั่งของทุกแอปพลิเคชันหรือทำให้สคริปต์ที่เขียนสำหรับเชลล์อื่นเข้ากันได้
อินพุตของเชลล์อาจผ่านการขยาย การเปลี่ยนเส้นทาง และการแทนที่คำสั่งก่อนที่โปรแกรมจะได้รับอาร์กิวเมนต์ เข้าใจการประมวลผลนั้นก่อนสร้างคำสั่งบำรุงรักษาจากชื่อไฟล์หรือข้อมูลผู้ใช้ เก็บอินพุตที่ไม่น่าเชื่อถือออกจากข้อความคำสั่งที่เรียกใช้งานได้ ใส่เครื่องหมายคำพูดกับอาร์กิวเมนต์อย่างถูกต้อง และเลือกใช้อินเทอร์เฟซแบบมีโครงสร้างของโปรแกรมสำหรับงานอัตโนมัติ ประวัติ บันทึก และอาร์กิวเมนต์ของกระบวนการอาจเก็บค่าที่ละเอียดอ่อนไว้ ดังนั้นให้ใช้กลไกข้อมูลรับรองส่วนตัวที่เหมาะสมกับแอปพลิเคชัน
ดำเนินการกับขอบเขตที่คุณเลือก
หลังการส่งมอบ ให้ระบุระบบปฏิบัติการ guest เส้นทางการเข้าถึง และกลไกการกู้คืน ใช้การอัปเดต สร้างบัญชีผู้ดูแลแบบจำกัด และเปิดเผยเฉพาะบริการที่โครงการต้องการ ทดสอบการติดตั้งใช้งานขนาดเล็กก่อนโอนข้อมูลสำคัญ บันทึก runtime อิมเมจ และคอนฟิกูเรชันที่จำเป็นในการสร้างใหม่ ขอบเขตไม่ได้บอกคุณว่าสถานะของแอปพลิเคชันกู้คืนได้หรือไม่
ใช้การเปรียบเทียบ SwissOctet เพื่อคัดเลือก Vector, DeskLink หรือช่วง Metal ตามเวิร์กโหลดและสภาพแวดล้อมการดำเนินงาน ยืนยันความสามารถเฉพาะทางก่อนเตรียมคำสั่งซื้อ แยกงานระบบปฏิบัติการ งานแอปพลิเคชัน และงานผู้ให้บริการออกจากกันอย่างชัดเจนใน runbook ขอบเขตที่ชัดเจนมีประโยชน์เพราะบอกคุณว่าคุณกำหนดค่าอะไรได้และต้องถามเกี่ยวกับอะไร ในขณะที่ยังคงเส้นทางปฏิบัติสำหรับการย้ายและการกู้คืน
รายการตรวจสอบปฏิบัติของคุณ
- แยกแยะการเข้าถึง guest จากการเข้าถึง host
- ตรวจสอบข้อกำหนดด้านฮาร์ดแวร์เฉพาะทางและการจำลองเสมือน
- วัดคอนฟิกูเรชันทั้งหมด ไม่ใช่ป้ายกำกับไฮเปอร์ไวเซอร์
- กำหนดค่าขีดจำกัดและสิทธิ์ของคอนเทนเนอร์
- ใช้เชลล์ที่ตั้งใจไว้และปกป้องอินพุตของคำสั่ง
รายละเอียดที่สำคัญ
KVM หมายความว่าฉันได้รับคอร์ CPU ทางกายภาพเฉพาะหรือไม่+
ไม่ใช่ KVM ระบุเทคโนโลยีการจำลองเสมือน อ่านการจัดสรร CPU และนโยบายทรัพยากรของผลิตภัณฑ์แยกต่างหาก
คอนเทนเนอร์สามารถแทนที่การบำรุงรักษา guest ได้หรือไม่+
ไม่ใช่ สภาพแวดล้อมโฮสต์ รันไทม์คอนเทนเนอร์ และอิมเมจทั้งหมดต้องได้รับการบำรุงรักษา สิทธิ์ที่เหมาะสม และการวางแผนการกู้คืน
เทอร์มินัลและเชลล์เป็นสิ่งเดียวกันหรือไม่+
ไม่ใช่ เทอร์มินัลให้อินเทอร์เฟซ เชลล์ตีความอินพุตคำสั่งและเปิดโปรแกรมภายในอินเทอร์เฟซนั้น
ไปที่ต้นทาง
แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน
- โครงการ KVM: Kernel Virtual Machine www.linux-kvm.org
- QEMU: บทนำการจำลองระบบ www.qemu.org
- Docker: ข้อจำกัดทรัพยากร docs.docker.com
- GNU Bash: การขยายของเชลล์ www.gnu.org
คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก