กลุ่มวอลุ่ม LVM แบ่งใช้ระหว่างโฮสต์ KVM / libvirt และแขก: นี่เป็นความคิดที่ไม่ดีใช่หรือไม่

ฉันเพิ่งสร้างโฮสต์เครื่องเสมือนใหม่ที่ใช้ KVM / libvirt ซึ่งประกอบด้วยฮาร์ดไดรฟ์ SATA II 4 ตัวและใช้งาน CentOS 5.5 x86_64

ฉันตัดสินใจที่จะสร้างดิสก์เครื่องเสมือนเป็นโลจิคัลวอลุ่มในกลุ่มวอลุ่ม LVM ที่จัดการเป็นพูลหน่วยเก็บข้อมูล libvirt แทนที่จะใช้วิธีสร้างดิสก์เป็นรูปภาพ qcow

สิ่งที่ฉันไม่สามารถตัดสินใจได้คือฉันควรสร้างโลจิคัลวอลุ่มของเครื่องเสมือนในกลุ่มวอลุ่มของโฮสต์ VM หรือในกลุ่มวอลุ่มเฉพาะ

ฉันควรเลือกวิธีใดและทำไม

วิธีที่ 1: ใช้กลุ่มวอลุ่มของโฮสต์ VM

การดำเนินงาน:

• RAID1 ขนาดเล็กmd0ที่มี/bootระบบไฟล์
• RAID10 ขนาดใหญ่ครอบครองพื้นที่ที่เหลือซึ่งมีกลุ่มปริมาณmd1 LVM มีระบบไฟล์รูทและพาร์ติชั่นการแลกเปลี่ยนของโฮสต์ VMvghostvghost
• สร้างดิสก์เครื่องเสมือนเป็นโลจิคัลวอลุ่มในvghostตามต้องการ

ข้อดี:

• หากระบบไฟล์รูทของโฮสต์ VM ไม่มีพื้นที่ว่างฉันสามารถจัดสรรพื้นที่เพิ่มเติมvghostได้อย่างง่ายดาย
• ระบบใช้งานแล้ว (แต่ไม่ใช่เรื่องใหญ่สำหรับการเริ่มต้นใหม่)

จุดด้อย:

ความจริงที่ว่าวิธีนี้ใช้งานได้นอกสถานที่ฉันไม่สามารถสั่นคลอนความรู้สึกว่านี่เป็นความคิดที่ไม่ดี ฉันรู้สึกว่า:

• นี่อาจเป็นความเสี่ยงด้านความปลอดภัย
• ในบางจุดในอนาคตฉันอาจพบข้อ จำกัด บางอย่างเกี่ยวกับการตั้งค่าและหวังว่าฉันจะใช้กลุ่มเฉพาะ
• ระบบ (CentOS, libvirt, ฯลฯ ) อาจไม่ได้รับการออกแบบมาให้ใช้เช่นนี้และในบางครั้งฉันอาจเกิดความเสียหาย / สูญเสียไฟล์และ / หรือระบบโฮสต์ของ VM โฮสต์

วิธีที่ 2: ใช้กลุ่มวอลุ่มเฉพาะ

การดำเนินงาน:

• เหมือนกันmd0และmd1ในวิธีที่ 1 ยกเว้นทำให้md1ใหญ่พอที่จะบรรจุสำหรับโฮสต์ VM (เช่น 5 ถึง 10GB)
• RAID10 ขนาดใหญ่md2ครอบครองพื้นที่ที่เหลือ md2มีกลุ่มวอลุ่ม LVM vgvmsซึ่งโลจิคัลวอลุ่มจะถูกใช้โดยเครื่องเสมือนเท่านั้น

ข้อดี:

• ฉันสามารถคนจรจัดvgvmsโดยไม่ต้องกลัวที่จะทำลายโฮสต์ระบบปฏิบัติการ
• ดูเหมือนว่าจะเป็นทางออกที่สวยงามและปลอดภัยกว่า

จุดด้อย:

• หากระบบไฟล์ของโฮสต์ VM ไม่มีพื้นที่ว่างฉันจะต้องย้ายบางส่วนของระบบไฟล์ (เช่น. / usr หรือ / var) ไปvgvmsที่ซึ่งดูเหมือนจะไม่ค่อยดี
• ฉันต้องติดตั้งโฮสต์ระบบปฏิบัติการใหม่ (ซึ่งตามที่ระบุไว้ก่อนหน้านี้ฉันไม่รังเกียจที่จะทำ)

อัปเดต # 1:

เหตุผลหนึ่งที่ฉันกังวลเกี่ยวกับการหมดพื้นที่ดิสก์โฮสต์ VM ในวิธีที่ 2 เป็นเพราะฉันไม่รู้ว่าโฮสต์ VM มีประสิทธิภาพเพียงพอที่จะเรียกใช้บริการทั้งหมดในเครื่องเสมือนหรือไม่ ฉันอาจต้องย้ายบริการบางส่วน / ทั้งหมดจากเครื่องเสมือนไปยังโฮสต์ระบบปฏิบัติการ

ข้อมูลจำเพาะฮาร์ดแวร์โฮสต์ VM:

• โปรเซสเซอร์ Phenom II 955 X4 Black Edition (3.2GHz, ซีพียู 4 คอร์)
• Kingston PC3-10600 DDR3 RAM ขนาด 2x4GB
• Gigabyte GA-880GM-USB3 เมนบอร์ด
• 4x WD Caviar RE3 500GB SATA II HDDs (7200rpm)
• Antec BP500U Basiq 500W ATX พาวเวอร์ซัพพลาย
• เคส CoolerMaster CM 690

อัปเดต # 2:

เหตุผลหนึ่งที่ฉันรู้สึกว่าระบบอาจไม่ได้รับการออกแบบให้ใช้โฮสต์ VG เป็นพูลหน่วยเก็บข้อมูล libvirt ในวิธีที่ 1 คือพฤติกรรมบางอย่างที่ฉันสังเกตเห็นใน virt-manager:

• เมื่อมีการเพิ่มก็บ่นว่ามันไม่สามารถเปิดใช้งาน VG (เห็นได้ชัดเพราะโฮสต์ระบบปฏิบัติการได้เปิดใช้งานแล้ว)
• เมื่อทำการลบมันปฏิเสธที่จะทำเช่นนั้นเพราะไม่สามารถปิดการใช้งาน VG ได้ (เห็นได้ชัดว่าเนื่องจากโฮสต์ระบบปฏิบัติการยังคงใช้รูทและสลับ LVs)

คำถามที่คิดออกดี!

ฉันจะใช้วิธีที่ 2 แต่นั่นเป็นเรื่องส่วนตัวมากกว่า สำหรับฉันแล้ววิธีที่ 2 ข้อเสียนั้นไม่ค่อยมีปัญหาอะไร ฉันไม่เห็นโฮสต์ของระบบปฏิบัติการที่โตกว่าพาร์ทิชัน 5-10GB เว้นแต่ว่าคุณจะเริ่มติดตั้งสิ่งเพิ่มเติมในนั้นซึ่งคุณไม่ควรทำ เพื่อความเรียบง่ายและความปลอดภัยระบบปฏิบัติการของโฮสต์นั้นควรติดตั้งแบบเปลือยขั้นต่ำไม่ต้องรันอะไรเลยยกเว้นขั้นต่ำเปล่าที่จำเป็นสำหรับการจัดการ (เช่น sshd)

วิธีที่ 1 ข้อเสียไม่ใช่ปัญหาอย่างแท้จริง IMO ฉันไม่คิดว่าจะมีความเสี่ยงด้านความปลอดภัยเพิ่มเติมใด ๆ เนื่องจากถ้า VM ที่รูทแล้วสามารถแบ่งพาร์ติชั่นและพาร์ติชั่น / ทำลายพาร์ติชั่นอื่น ๆ ได้การมีระบบปฏิบัติการโฮสต์บน VG แยกอาจไม่สร้างความแตกต่างใด ๆ ข้อเสียอีกสองข้อไม่ใช่สิ่งที่ฉันสามารถพูดได้จากประสบการณ์ตรง แต่ฉันอุตของฉันบอกว่า CentOS, LVM และ libvirt มีความยืดหยุ่นและแข็งแกร่งพอที่จะไม่ต้องกังวลเกี่ยวกับพวกเขา

แก้ไข - ตอบสนองต่อการปรับปรุง 1

ทุกวันนี้ประสิทธิภาพของ virtualization ต่ำมากโดยเฉพาะการใช้โปรเซสเซอร์ที่มีอยู่แล้วดังนั้นฉันไม่คิดว่าจะย้ายบริการจาก guest VM ไปยังโฮสต์ OS คุณอาจได้รับความเร็วเพิ่มขึ้น 10% โดยการใช้งานบน "โลหะเปลือย" แต่คุณจะสูญเสียผลประโยชน์จากการมีระบบปฏิบัติการโฮสต์ขนาดเล็กแน่นและปลอดภัยและอาจส่งผลกระทบต่อเสถียรภาพของเซิร์ฟเวอร์ทั้งหมด ไม่คุ้มค่า IMO

ด้วยเหตุนี้ฉันจะยังคงชอบวิธีที่ 2

ตอบสนองต่อการปรับปรุง 2

ดูเหมือนว่าวิธีเฉพาะที่ libvirt ถือว่าการจัดเก็บข้อมูลถูกจัดวางยังเป็นอีกจุดหนึ่งในความโปรดปรานวิธีที่ 2 คำแนะนำของฉันคือ: ไปกับวิธีที่ 2

ตราบใดที่ระบบเดียวพยายามใช้ LV ที่กำหนดในโหมดอ่าน / เขียนได้ทุกเวลามันเป็นไปได้ที่จะใช้ VG เดียวกันสำหรับโฮสต์และแขก หากหลายระบบพยายามเขียนลงใน LV เดียวกันความเสียหายของระบบไฟล์จะส่งผล

คุณอาจต้องการดูสิ่งนี้บางทีคนจรจัด & ดูว่าโครงการนี้ทำในสิ่งที่คุณพูดถึงอย่างไร

ProxmoxVE เป็นโฮสต์ KVM โลหะเปลือยที่ใช้ perl implememtation ของ libvirt มากกว่า RHEL ที่หนักกว่า มันใช้ทั้งสองสถานการณ์

ดิสก์เสมือนคือ. raw และ sparse คล้ายกับ. qcow แต่เร็วกว่า

สนับสนุนรูปแบบดิสก์อิมเมจของ qcow & vmdk แต่ฉันคิดว่าอาจมีข้อ จำกัด ของ LVM ฉันไม่ได้ใช้มันดังนั้นฉันจึงพูดอะไรไม่ออก

ที่เก็บข้อมูล LVM ถูกแชร์ระหว่าง VM บนโหนดและสามารถเป็นอุปกรณ์ DRBD

สำหรับการแบ่งปันพื้นที่ VG ของระบบปฏิบัติการข้อ จำกัด เพียงอย่างเดียวที่ต้องคำนึงถึงคือขนาดสแน็ปช็อตระหว่างการสำรองข้อมูล ค่านี้สามารถเปลี่ยนแปลงได้ในไฟล์กำหนดค่าและฉันเห็นบางครั้งในฟอรัมที่ผู้คนต้องเปลี่ยน แต่ค่าเริ่มต้นให้บริการฉันดีเป็นเวลาสองปีแล้ว - แม้จะมีดิสก์เสมือนขนาดใหญ่

รายละเอียดการจัดเก็บ LVM ของ PVE:

http://pve.proxmox.com/wiki/Storage_Model#LVM_Groups_with_Network_Backing

นี่คือวิธีการวาง VGs:

พบกลุ่มวอลุ่ม "LDatastore1" โดยใช้ metadata type lvm2

พบกลุ่มวอลุ่ม "LDatastore0" โดยใช้ metadata type lvm2

พบกลุ่มวอลุ่ม "pve" โดยใช้ metadata type lvm2

นี่คือ LVs ของฉัน:

ใช้งาน '/ dev / LDatastore1 / vm-9098-disk-1' [4.00 GB] สืบทอด

ACTIVE '/ dev / LDatastore1 / vm-7060-disk-1' [2.00 GB] สืบทอด

ใช้งาน '/ dev / LDatastore1 / vm-5555-disk-1' [8.00 GB] สืบทอด

ใช้งาน '/ dev / LDatastore0 / vm-4017-disk-1' [8.00 GB] สืบทอด

ใช้งาน '/ dev / LDatastore0 / vm-4017-disk-2' [512.00 GB] สืบทอด

ใช้งาน '/ dev / LDatastore0 / vm-7057-disk-1' [32.00 GB] สืบทอด

ใช้งาน '/ dev / LDatastore0 / vm-7055-disk-1' [32.00 GB] สืบทอด

ใช้งาน '/ dev / LDatastore0 / vm-6030-disk-1' [80.01 GB] สืบทอด

ACTIVE '/ dev / pve / swap' [3.62 GB] สืบทอดมา

ACTIVE '/ dev / pve / root' [7.25 GB] สืบทอดมา

ACTIVE '/ dev / pve / data' [14.80 GB] สืบทอดมา

นี่คือ LVM บน RAID10 ที่ทำจากไดรฟ์ Seagate Barracuda SATA 6 7200 rpm:

CPU BOGOMIPS: 53199.93

REGEX / SECOND: 824835

ขนาด HD: 19.69 GB (/ dev / mapper / LDatastore0-testlv)

BUFFERED READS: 315.17 MB / วินาที

เวลาเฉลี่ยที่ค้นหา: 7.18 ms

FSYNCS / SECOND: 2439.31

และนี่คือ LVM บน Intel X25-E SATA SSD เดียว VG เดียวกับข้อมูล / dev / pve / data ดังกล่าวที่ VMs อาศัยอยู่:

CPU BOGOMIPS: 53203.97

REGEX / SECOND: 825323

ขนาด HD: 7.14 GB (/ dev / mapper / pve-root)

BUFFERED READS: 198.52 MB / วินาที

เวลาโดยเฉลี่ยที่ค้นหา: 0.26 ms

FSYNCS / วินาที: 1867.56