Nhóm khối lượng LVM được chia sẻ giữa chủ nhà KVM / libvirt và khách: đây có phải là ý tưởng tồi không?

Tôi vừa mới xây dựng một máy chủ ảo dựa trên KVM / libvirt mới, chứa 4 ổ cứng SATA II và chạy CentOS 5.5 x86_64.

Tôi đã quyết định tạo các đĩa máy ảo dưới dạng các khối logic trong một nhóm âm lượng LVM được quản lý như một kho lưu trữ libvirt, thay vì thực hành thông thường là tạo các đĩa như hình ảnh qcow.

Điều tôi không thể quyết định là liệu tôi nên tạo các khối logic của máy ảo trong nhóm âm lượng của máy chủ VM hay trong một nhóm âm lượng chuyên dụng.

Tôi nên chọn phương pháp nào, và tại sao?

Phương pháp 1: Sử dụng nhóm âm lượng của máy chủ VM

Thực hiện:

• RAID1 nhỏ md0chứa /boothệ thống tập tin
• RAID10 lớn md1chiếm không gian còn lại, chứa nhóm âm lượng LVM vghost. vghostchứa hệ thống tập tin gốc của máy chủ VM và phân vùng trao đổi
• tạo đĩa máy ảo dưới dạng khối lượng logic vghosttheo yêu cầu

Ưu điểm:

• nếu hệ thống tập tin gốc của máy chủ VM hết dung lượng, tôi có thể phân bổ nhiều không gian hơn vghostmột cách dễ dàng
• Hệ thống đã hoạt động và đang hoạt động (nhưng không có vấn đề gì lớn để bắt đầu lại)

Nhược điểm:

Thay đổi thực tế rằng phương pháp này dường như có hiệu quả, tôi không thể lay chuyển được cảm giác rằng đây là một ý tưởng tồi. Tôi cảm thấy rằng:

• điều này bằng cách nào đó có thể là một rủi ro bảo mật
• tại một số điểm trong tương lai tôi có thể tìm thấy một số hạn chế với thiết lập và muốn rằng tôi đã sử dụng một nhóm dành riêng
• hệ thống (CentOS, libvirt, v.v.) có thể không thực sự được thiết kế để được sử dụng như thế này, và do đó, tại một số điểm tôi có thể buộc tội hỏng / mất các tệp và / hoặc hệ thống tệp của máy chủ VM

Phương pháp 2: Sử dụng nhóm âm lượng chuyên dụng

Thực hiện:

• tương tự md0và md1như trong Phương pháp 1, ngoại trừ md1chỉ đủ lớn để chứa máy chủ VM (ví dụ: 5 đến 10 GB)
• RAID10 lớn chiếm md2không gian còn lại. md2chứa một nhóm âm lượng LVM vgvms, có khối lượng logic được sử dụng riêng cho các máy ảo

Ưu điểm:

• Tôi có thể tinker vgvmsmà không sợ phá vỡ hệ điều hành máy chủ
• đây có vẻ là một giải pháp thanh lịch và an toàn hơn

Nhược điểm:

• nếu hệ thống tệp của máy chủ VM hết dung lượng, tôi sẽ phải di chuyển các phần của hệ thống tệp của nó (ví dụ: / usr hoặc / var) lên vgvms, có vẻ không đẹp lắm.
• Tôi phải cài đặt lại hệ điều hành máy chủ (như đã nói trước đây tôi không thực sự bận tâm)

CẬP NHẬT # 1:

Một lý do khiến tôi lo lắng về việc hết dung lượng đĩa máy chủ VM trong Phương thức 2 là vì tôi không biết máy chủ VM có đủ mạnh để chạy tất cả các dịch vụ trong máy ảo hay không. Tôi có thể phải di chuyển một số / tất cả các dịch vụ từ máy ảo sang HĐH máy chủ.

Đặc tả phần cứng máy chủ VM:

• Bộ xử lý Phenom II 955 X4 Black Edition (3.2GHz, CPU 4 nhân)
• Bộ nhớ RAM DDR3 Kingston PC3-10600 DDR3
• Bo mạch chủ Gigabyte GA-880GM-USB3
• 4x Ổ cứng WD Caviar RE3 500GB SATA II (7200 vòng / phút)
• Bộ nguồn Antec BP500U Basiq 500W ATX
• Vỏ máy làm mát CM 690

CẬP NHẬT # 2:

Một lý do tại sao tôi cảm thấy rằng hệ thống có thể không được thiết kế để sử dụng máy chủ VG làm kho lưu trữ libvirt trong Phương pháp 1 là một số hành vi tôi nhận thấy ở người quản lý tài năng:

• khi thêm vào, nó phàn nàn rằng nó không thể kích hoạt VG (rõ ràng, vì hệ điều hành máy chủ đã kích hoạt nó)
• khi gỡ bỏ, nó đã từ chối làm như vậy vì không thể hủy kích hoạt VG (rõ ràng, vì hệ điều hành máy chủ vẫn đang sử dụng LV gốc và hoán đổi)

Câu hỏi được suy nghĩ kỹ!

Tôi sẽ sử dụng Phương pháp 2, nhưng đó là sở thích cá nhân nhiều hơn. Đối với tôi, Nhược điểm của Phương pháp 2 không phải là vấn đề. Tôi không thấy HĐH máy chủ vượt quá phân vùng 5-10 GB của nó, trừ khi bạn bắt đầu cài đặt thêm các thứ trên đó, điều mà bạn thực sự không nên làm. Để đơn giản và bảo mật, hệ điều hành máy chủ thực sự phải là một bản cài đặt tối thiểu, không chạy bất cứ thứ gì ngoại trừ mức tối thiểu cần thiết cho quản trị (ví dụ: sshd).

Nhược điểm của Phương pháp 1 cũng không thực sự là một vấn đề, IMO. Tôi không nghĩ sẽ có thêm bất kỳ rủi ro bảo mật nào, vì nếu một máy ảo gốc có thể thoát ra khỏi phân vùng của nó và lây nhiễm / làm hỏng các phân vùng khác, thì hệ điều hành máy chủ trên VG riêng biệt có thể không tạo ra bất kỳ sự khác biệt nào. Hai khuyết điểm khác không phải là thứ tôi có thể nói từ kinh nghiệm trực tiếp, nhưng tôi cho rằng CentOS, LVM và libvirt đủ linh hoạt và mạnh mẽ để không phải lo lắng về chúng.

EDIT - Phản hồi cập nhật 1

Ngày nay, hiệu năng ảo hóa rất thấp, đặc biệt là sử dụng các bộ xử lý được tích hợp hỗ trợ cho nó, vì vậy tôi không nghĩ việc chuyển một dịch vụ từ máy khách VM sang hệ điều hành máy chủ sẽ đáng làm. Bạn có thể tăng tốc 10% bằng cách chạy trên "kim loại trần", nhưng bạn sẽ mất lợi ích của việc có một hệ điều hành máy chủ nhỏ, chặt chẽ, an toàn và có khả năng ảnh hưởng đến sự ổn định của toàn bộ máy chủ. Không đáng, IMO.

Trong trường hợp này, tôi vẫn sẽ ủng hộ Phương pháp 2.

Phản hồi cập nhật 2

Dường như cách thức cụ thể mà libvirt giả định lưu trữ được đặt ra là một điểm khác có lợi cho Phương pháp 2. Khuyến nghị của tôi là: đi với Phương pháp 2.

Miễn là chỉ có một hệ thống cố gắng sử dụng bất kỳ LV cụ thể nào ở chế độ đọc / ghi bất cứ lúc nào, việc sử dụng cùng một VG cho máy chủ và khách là điều khả thi. Nếu nhiều hệ thống cố gắng ghi vào cùng một LV thì sẽ xảy ra hỏng hóc hệ thống tập tin.

Bạn có thể muốn xem xét điều này, có thể tinker & xem dự án này thực hiện những gì bạn đang nói về.

ProxmoxVE là một máy chủ KVM kim loại trần, sử dụng hàm ý perl của libvirt thay vì đối tác nặng hơn của RHEL. Nó thực hiện cả hai kịch bản.

Các đĩa ảo là .raw và thưa thớt, tương tự như .qcow nhưng nhanh hơn.

Các định dạng hình ảnh đĩa qcow & vmdk cũng được hỗ trợ nhưng tôi nghĩ có thể có những hạn chế LVM liên quan. Tôi không sử dụng chúng vì vậy tôi không thể nói nhiều về điều đó.

Lưu trữ LVM được chia sẻ giữa các VM trên nút và có thể là thiết bị DRBD.

Đối với việc chia sẻ không gian VG của HĐH, giới hạn duy nhất cần quan tâm là kích thước ảnh chụp nhanh trong quá trình sao lưu. Ở đây giá trị này có thể được thay đổi trong một tệp cấu hình và đôi khi tôi thấy trong các diễn đàn nơi mọi người phải thay đổi nó, nhưng mặc định đã phục vụ tốt cho tôi trong một vài năm nay - ngay cả với các đĩa ảo lớn.

Chi tiết lưu trữ LVM của PVE:

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

Đây là cách các VG được đặt ra:

Nhóm khối lượng được tìm thấy "LDatastore1" sử dụng loại siêu dữ liệu lvm2

Nhóm khối lượng được tìm thấy "LDatastore0" sử dụng loại siêu dữ liệu lvm2

Tìm thấy nhóm khối lượng "pve" bằng cách sử dụng loại siêu dữ liệu lvm2

Đây là những LV của tôi:

HOẠT ĐỘNG '/ dev / LDatastore1 / vm-9098-đĩa-1' [4,00 GB] kế thừa

HOẠT ĐỘNG '/ dev / LDatastore1 / vm-7060-đĩa-1' [2,00 GB] kế thừa

HOẠT ĐỘNG '/ dev / LDatastore1 / vm-5555-đĩa-1' [8,00 GB] kế thừa

HOẠT ĐỘNG '/ dev / LDatastore0 / vm-4017-đĩa-1' [8,00 GB] kế thừa

HOẠT ĐỘNG '/ dev / LDatastore0 / vm-4017-đĩa-2' [512.00 GB] kế thừa

HOẠT ĐỘNG '/ dev / LDatastore0 / vm-7057-đĩa-1' [32,00 GB] kế thừa

HOẠT ĐỘNG '/ dev / LDatastore0 / vm-7055-đĩa-1' [32,00 GB] kế thừa

HOẠT ĐỘNG '/ dev / LDatastore0 / vm-6030-đĩa-1' [80,01 GB] kế thừa

HOẠT ĐỘNG '/ dev / pve / hoán đổi' [3,62 GB] kế thừa

HOẠT ĐỘNG '/ dev / pve / root' [7.25 GB] kế thừa

HOẠT ĐỘNG '/ dev / pve / data' [14,80 GB] kế thừa

Đây là LVM trên RAID10 được làm bằng 6 ổ đĩa Seagate Barracuda SATA 72 72 vòng / phút:

BOGOMIPS CPU: 53199.93

ĐĂNG KÝ / THỨ HAI: 824835

KÍCH THƯỚC HD: 19,69 GB (/ dev / mapper / LDatastore0-testlv)

ĐỌC BUFFERED: 315,17 MB / giây

AVERAGE XEM THỜI GIAN: 7,18 ms

FSYNCS / THỨ HAI: 2439.31

Và đây là LVM trên một ổ SSD Intel X25-E duy nhất, cùng VG với dữ liệu đã nói ở trên / dev / pve / nơi VM sống:

BOGOMIPS CPU: 53203.97

ĐĂNG KÝ / THỨ HAI: 825323

KÍCH THƯỚC HD: 7,14 GB (/ dev / mapper / pve-root)

ĐỌC BUFFERED: 198,52 MB / giây

AVERAGE XEM THỜI GIAN: 0,26 ms

FSYNCS / THỨ HAI: 1867,56