Sự khác biệt giữa Xen PV, Xen KVM và HVM?


53

Tôi biết rằng Xen thường tốt hơn OpenVZ vì nhà cung cấp không thể bán quá nhiều trong Xen. Tuy nhiên, sự khác biệt giữa là gì Xen PV, Xen KVMHVM(Tôi đã đi qua của nhà cung cấp này thông số kỹ thuật ? Cái nào là tốt hơn cho mục đích gì và tại sao?


Biên tập:

Đối với một người dùng cuối sẽ chỉ lưu trữ các trang web, cái nào tốt hơn? Từ hiệu quả hoặc quan điểm khác, có bất kỳ lợi thế của cái này hơn cái kia?

Câu trả lời:


47

Xen hỗ trợ các loại ảo hóa

Xen hỗ trợ chạy hai loại khách khác nhau. Khách Xen thường được gọi là domUs (tên miền không được ưu tiên). Cả hai loại khách (PV, HVM) có thể được sử dụng cùng một lúc trên một hệ thống Xen.

Xen Paravirtualization (PV)

Paravirtualization là một kỹ thuật ảo hóa hiệu quả và nhẹ được Xen giới thiệu, sau này cũng được áp dụng bởi các giải pháp ảo hóa khác. Paravirtualization không yêu cầu các phần mở rộng ảo hóa từ CPU chủ. Tuy nhiên, khách ảo hóa yêu cầu hạt nhân đặc biệt được chuyển để chạy tự nhiên trên Xen, vì vậy khách biết về trình ảo hóa và có thể chạy hiệu quả mà không cần giả lập hoặc phần cứng giả lập ảo. Hạt nhân khách Xen PV tồn tại cho các hệ điều hành Linux, NetBSD, FreeBSD, OpenSolaris và Novell Netware.

Khách PV không có bất kỳ loại phần cứng giả lập ảo nào, nhưng bảng điều khiển đồ họa vẫn có thể sử dụng pvfb của khách (bộ đệm khung paravirtual). Có thể xem bảng điều khiển đồ họa khách PV bằng ứng dụng khách VNC hoặc trình xem tài năng của Redhat. Có một máy chủ VNC riêng trong dom0 cho mỗi PVFB của khách.

Hạt nhân ngược dòng Linux Linux kể từ Linux 2.6.24 bao gồm hỗ trợ khách Xen PV (domU) dựa trên khung công tác Linux, do đó, mọi nhân Linux ngược dòng có thể được sử dụng tự động làm nhân khách Xen PV mà không cần thêm bất kỳ bản vá hay sửa đổi nào.

Xem trang wiki XenParavirtOps để biết thêm thông tin về hỗ trợ Xen pvops Linux.

Xen toàn bộ ảo hóa (HVM)

Khách ảo hóa hoàn toàn hay còn gọi là HVM (Máy ảo phần cứng) yêu cầu các phần mở rộng ảo hóa CPU từ CPU chủ (Intel VT, AMD-V). Xen sử dụng phiên bản sửa đổi của Qemu để mô phỏng toàn bộ phần cứng PC, bao gồm BIOS, bộ điều khiển đĩa IDE, bộ điều hợp đồ họa VGA, bộ điều khiển USB, bộ điều hợp mạng, vv cho khách HVM. Phần mở rộng ảo hóa CPU được sử dụng để tăng hiệu suất mô phỏng. Khách ảo hóa hoàn toàn không yêu cầu kernel đặc biệt, vì vậy, ví dụ hệ điều hành Windows có thể được sử dụng làm khách Xen HVM. Khách ảo hóa hoàn toàn thường chậm hơn so với khách ảo, vì yêu cầu thi đua.

Để tăng hiệu suất, các HVM được ảo hóa hoàn toàn, khách có thể sử dụng trình điều khiển thiết bị ảo đặc biệt để bỏ qua việc mô phỏng cho IO và mạng IO. Xen khách HVM có thể sử dụng trình điều khiển GPLPV mã nguồn mở. Xem trang wiki XenLinuxPVonHVMdrivers để biết thêm thông tin về trình điều khiển Xen PV-on-HVM cho khách HVM của Linux.

Đây là từ http://wiki.xenproject.org/wiki/XenOverview

KVM hoàn toàn không phải là Xen, nó là một công nghệ khác, trong đó KVM là mô-đun hạt nhân gốc Linux và không phải là một hạt nhân bổ sung, như Xen. Điều này làm cho KVM có thiết kế tốt hơn. Nhược điểm ở đây là KVM mới hơn Xen, do đó có thể thiếu một số tính năng.


9
+1 KVM hoàn toàn không phải là Xen. Hoàn toàn không đồng ý rằng KVM là một thiết kế tốt hơn. Xen cung cấp khả năng cách ly tốt hơn nhiều và không phụ thuộc vào nhân Linux và đó là các lỗ hổng tiềm năng.
Antoine Benkemoun

2
Cảm ơn bạn về thông tin! Tôi không thể hiểu tất cả. Từ quan điểm của người dùng cuối, ai sẽ chỉ là người lưu trữ trang web, cái nào tốt hơn? Có lợi thế đáng kể của cái này hơn cái kia không?

2
Xen có lỗ hổng riêng của nó. Nhưng chạy một hệ điều hành với hai nhân khởi động là một lỗ hổng thiết kế, bất kể bạn làm việc đó tốt như thế nào
dyasny

1
JP19: điều đó phụ thuộc vào các trang web. Nếu bạn có thể xác định tải trên VPS, bạn có thể hỏi tại đây hoặc google để có giải pháp tốt nhất.
dyasny

2
Xen là một siêu giám sát, và KVM cũng vậy. KVM có các thiết bị PV, và thêm nhiều thời gian hơn, nó cũng cho phép truyền qua PCI. Vì vậy, tôi không thấy điểm cho cuộc tranh luận của bạn, Nils
dyasny

32

Xen là một trình ảo hóa chạy trên kim loại (pc / server) và sau đó lưu trữ các máy ảo được gọi là tên miền.

Một Xen PVmiền là một miền bị ảo hóa , có nghĩa là hệ điều hành (thường là chúng ta đang nói linux ở đây) đã được sửa đổi để chạy dưới Xen và không cần phải thực sự mô phỏng phần cứng. Đây phải là cách hiệu quả nhất để đi, hiệu suất khôn ngoan.

Một Xen HVMmiền là miền mô phỏng phần cứng , có nghĩa là hệ điều hành (có thể là Linux, Windows, bất cứ điều gì) chưa được sửa đổi theo bất kỳ cách nào và phần cứng được mô phỏng. Điều này khá chậm, vì vậy, thông thường bạn cài đặt trình điều khiển PV trong hệ điều hành khách cho phần cứng quan trọng (thường là đĩa và mạng), do đó, toàn bộ khách sẽ chạy ảo hóa hoàn toàn nhưng các phần cứng quan trọng nhất về hiệu năng sẽ chạy ảo. Các hệ thống linux gần đây có trình điều khiển pv cho cả đĩa và mạng trong kernel và cũng có nhiều trình điều khiển PV khác nhau cho Windows. Với tất cả sự phát triển trên HVM trong những năm gần đây, thường có rất ít sự khác biệt về hiệu suất giữa HVM và PV cho khối lượng công việc tiêu chuẩn.

KVMkhông phải là Xen, nó là một nền tảng ảo hóa khác được xây dựng bên trong nhân Linux. Từ quan điểm của khách, nó giống với Xen HVM: khách chạy ảo hoàn toàn và có trình điều khiển cụ thể để chạy một số phần bị ảo hóa (một lần nữa, đĩa và mạng).

Cả Xen HVM và Linux KVM đều cần hỗ trợ ảo hóa hỗ trợ phần cứng (Intel VT-x, AMD AMD-V), trong khi Xen PV không nhưng không thể chạy hệ điều hành mà không có hỗ trợ PV (bạn không thể chạy Windows trên Xen PV).

Cả Xen HVM và Linux KVM sẽ sử dụng các phần của phần mềm ảo hóa qemu để mô phỏng phần cứng thực tế cho các thiết bị không sử dụng trình điều khiển PV trong hệ thống khách.

Xen (cả PV và HVM) có thể thực hiện di chuyển trực tiếp một khách đang chạy từ máy chủ vật lý này sang máy chủ vật lý khác, tôi không biết liệu KVM có thể không.

Cả Xen và KVM đều không thể vượt quá bộ nhớ, do đó bạn thường nhận được "RAM thực", trong khi các nền tảng khác như VMware có thể hoán đổi một phần ram khách sang đĩa.

Có sự khác biệt nhưng thường áp dụng cho các cài đặt cụ thể và không áp dụng cho máy chủ riêng ảo chung để bán cho người khác. Ví dụ, các trình ảo hóa Xen gần đây hỗ trợ bộ nhớ siêu việt có thể cải thiện việc sử dụng bộ nhớ và hiệu suất của khách nếu khách có hỗ trợ cho nó (hạt nhân linux> = 3. một cái gì đó).

Tất cả những công nghệ đó sẽ mang đến cho bạn trải nghiệm tuyệt vời nếu chúng được triển khai chính xác và sẽ không tạo ra sự khác biệt lớn theo quan điểm của bạn. Tất nhiên, có hàng ngàn cách mọi thứ có thể sai và điều đó không liên quan đến giải pháp ảo hóa cụ thể (nghĩa là khách của bạn có thể được lưu trữ trên các đĩa chậm và điều đó sẽ làm giảm hiệu suất của bạn).


3
KVM có thể vượt quá bộ nhớ và Xen cũng vậy.
dyasny

@dyasny Tôi không biết về KVM nhưng tôi khá chắc chắn Xen không thể vượt quá bộ nhớ theo nghĩa thực tế của từ này (cho phép kích thước tối đa khác nhau là một điều khác biệt). Vui lòng liên kết các nguồn của bạn nếu bạn tin rằng nó làm.
Luke404

Xen hỗ trợ balooning. Thêm trao đổi tiêu chuẩn cho điều này và bạn đã có ít nhất 2 cơ chế vượt mức. Cái này cũ như năm 2008: blog.xen.org/index.php/2008/08/27/ từ
dyasny

3
@dyasny bạn có thể nghĩ về overcommit như cho phép tối đa cao hơn. AFAIK, ý nghĩa được chấp nhận là thực sự phân bổ cho khách nhiều bộ nhớ hơn hiện diện vật lý trong máy chủ và điều này không được thực hiện trong Xen. Bạn không thể xì hơi bóng khách (ví dụ: cung cấp thêm bộ nhớ) nếu bạn không có bộ nhớ vật lý trong máy chủ và bạn không thể bắt đầu một khách mới nếu bạn đã phân bổ tất cả bộ nhớ máy chủ của mình (trừ khi bạn tăng cường chạy bóng bay cho khách, do đó thực sự giảm bộ nhớ được phân bổ để bạn không gặp phải bất cứ điều gì).
Luke404

1
Tôi nghĩ về overcommit vì không chỉ cho phép nhiều hơn vật chủ có, mà còn thực sự sử dụng nhiều hơn vật chủ có. Hoán đổi là khủng khiếp, nhưng đó là một cơ chế cho phép bạn phân bổ nhiều trang bộ nhớ hơn so với thực tế trên máy chủ, cho dù là cho các quy trình hay VM - không thành vấn đề. Điều này là xa như tôi sẽ đi vào ngữ nghĩa về điều này.
dyasny
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.