Xen Server Overview

Trước khi đọc blog post, mời các bạn đọc các bài post có liên quan trước đó:

• KVM & QEMU Connection by Thang Man
• Introduction of Virtualization by VietStack

Bài viết này sẽ giới thiệu tổng quan về Xen Server - một distro sử dụng Xen Hypervisor và các thành phần bên trong module Storage cùng một chút overview về Virtualization Driver của Xen. Các module khác như Network, Resource Compute & Monitor của Xen sẽ được nhắc đến trong các post sau.

Dưới đây là video demo nói về một trong những tính năng khá đặc biệt của Xen Server, thay đổi cấu hình máy ảo trong khi máy vẫn đang ở trạng thái running. Video chỉ mang tính chất gợi mở về các tính năng khá hay của Xen Server.

[embed]https://xen-orchestra.com/pictures/videos/adjust.mp4[/embed]

1. Giới thiệu:

Xen Server là distro sử dụng Xen hypervisor, trong đó Xen hypervisor là hypervisor kiểu I dạng microkernel (xem lại bài về virtualization), hỗ trợ hai chế độ ảo hoá full virtualization và para-virtualization. Toàn bộ thao tác điều khiển của Xen Server thông qua một máy ảo chính được gọi là Domain 0. Bản thân máy ảo Domain 0 có chứa toàn bộ driver tương tác với hạ tầng vật lý bên dưới và các service, thư viện hỗ trợ quản lý, tương tác với máy ảo (VM). Các máy ảo tạo ra trên nền tảng của Xen hypervisor có tên chung là domain U (dom U).

Kiến trúc của Xen Server như sau:

Hình 1. Kiến trúc Xen Server (nguồn: xenserver.org)

2. Chức năng chính:

Bảng dưới liệt kê các tính năng chính của Xen Server, bạn có thể so sánh với khả năng support của OpenStack trong link này.

3. Khái niệm

Dưới đây là một số khái niệm khi làm việc với Xen Server

• SR: storage repositories, IDE, SATA, SCSI, SAS, iSCSI, NFS, FC.
• VDI: virtual disk images của guest VM
• PBD: physical block devices, connector cho phép SR link tới một Xen host.
• VBD: virtual block devices, connector hỗ trợ link giữa VDIs và Vms. Lưu trong local/domain/device/vbd/id
• VHD: virtual hard disk, Connectix data virtual disk (File-based và LVM-based); có thể là một chuỗi các file VHD liên kết với nhau với độ dài tối đa là 30 disk (parent disk thường được sử dụng chủ yếu để clone ra các VM tương tự, các thay đổi thường được ghi lên child disk). Cơ chế tương tự như việc lưu và restore từ snapshot của Virtual Box và VMWare.
• PIF: physical network interface, thể hiện các tham số, cấu hình của network card vật lý trên server.
• VIF: virtual interface, thể hiện tham số và cấu hình của card ảo tạo ra cho các VM.
• Network: virtual ethernet switches, mỗi network được cấu hình bởi các pif và vif được sử dụng trong network ấy. Các network có pif gọi là external, không pif là internal. Ví dụ, có thể tạo ra 1 network đi qua 2 card pif (bonding), cũng có thể tạo ra 1 network chỉ giao tiếp nội bộ giữa các VM.
• Event Channel: kênh giao tiếp chính giữa các thành phần trong Xen Server.

4. Các thành phần bên trong Storage module Xen Server:

• BlkFront (domU, Xen BlkIf Protocol)

  Virtual device (driver) được quản lý bởi Xen blkfront, các thao tác đọc ghi trên dom U được blkfront ghi nhận và forward sang dom 0 qua Xen Bus (trong Event Channel) và giao thức blkif chuyên biệt. Blkfront nằm trong kernel space.

  Mỗi khi Dom U thực hiện thao tác đọc ghi sẽ được Dom 0 cấp quyền riêng biệt thông qua một bảng là bảng Grant Table.

  blkif được cấu tạo như một ring với 32 slot dùng chung cho request và response, giới hạn tối đa 11 segs, mỗi seg 4KiB trên một ring. Có thể cấu hình multi-page rings để support hiệu năng cao hơn.

• BlkBack (dom0)

Được cài đặt ở dom 0, nhận các thao tác đọc ghi từ dom U và chuyển xuống hạ tầng storage phần cứng bên dưới thông qua giao thức xen blkif. Sau đó, blkback sẽ thực hiện các thao tác đọc ghi trên các device driver.

Hình 2: Flow BlkBack (nguồn: Citrix Xen Project - Felipe Franciosi)

• BlkTap1/2 (tap, tapdisk1/2 - Xen Server 6.2.0)

  Từ phiên bản 6.2.0, Xen Server cài đặt 2 cách thức đảm bảo đọc ghi mới, thay vì blkback thao tác IO trực tiếp lên device driver sẽ thông qua một interface là blktap để chuyển các thao tác IO lên một device ảo là tap.

  Tại Dom 0, trên user space sẽ có một process là tapdisk handle toàn bộ các IO trong tap và chuyển tới device driver vật lý.

  Nguyên nhân sinh ra tapdisk là để chuyển một phần thao tác lên phía user space trong Linux kernel, tạo ra nhiều tùy chỉnh mềm dẻo hơn với nhà phát triển và tăng cường hiệu năng cho đọc ghi từ VM.

  Tham khảo: http://wiki.xenproject.org/wiki/Blktap

Hình 3: Flow với BlkTap Hình 2: Flow BlkBack (nguồn: Citrix Xen Project - Felipe Franciosi)

• BlkTap3 (tapdisk3/qemu-qdisk)

BlkTap3 là phiên bản nâng cấp từ blktap2, hiện chưa được implement trong Xen. BlkTap3 đưa tapdisk process lên hoàn toàn nằm trong user space và connect trực tiếp vào blkfront của DomU.

Tham khảo http://wiki.xenproject.org/wiki/Blktap3

Hình 4. Flow với BlkTap3 Hình 2: Flow BlkBack (nguồn: Citrix Xen Project - Felipe Franciosi)

3. Virtualization mode và performance - PV Driver trong Xen:

Hình 5: Các chế độ virtualization của Xen. (nguồn: xen.org)

• HVM (Full-Virtualization): toàn bộ phần cứng của guest được ảo hóa, guest không nhận biết được là mình đang chạy trên phần cứng ảo hóa, bởi vậy các thao tác đọc ghi ổ cứng, instruction của CPU, network read/write, memory page … đều phải thông qua hypervisor rồi mới đi xuống hạ tầng vật lý bên dưới. điều này gây đến hiệu suất rất chậm.

• PV: guest phải được customized để biết được mình đang được chạy trên phần cứng ảo hóa, do vậy, quá trình thao tác sẽ không phải để cho hypervisor chịu nhiều tải nữa. Đây là mode có hiệu năng cao nhất nhưng có yêu cầu khó vì phải customize guest nhiều.

• PVHVM: ảo hóa một phần, cho phép guest đọc ghi disk và network cùng các interrupts, timer của CPU thông qua interface của PV driver. Các thông số khác như emulated boot, privileges, page tables chạy trên FV mode.

• PVH: là PVHVM ảo hóa thêm motherboard và legacy boot, tăng cường hiệu năng cho guest.

• PV driver: driver của Xen do Citrix phát triển cài trên Dom U, cho phép Dom U hiểu rằng mình đang được ảo hóa (PV mode) và có thể communicate với Dom 0 cùng các thành phần khác của Xen.

• Xen Store: Lưu trữ toàn bộ các thông tin bao gồm thông tin về bộ nhớ, hiện trạng của event channel giữa Dom 0 và Dom U. Thường lưu ở local/domain/device/vif.

  Các máy ảo chạy ở chế độ HVM thường có hiệu suất rất chậm và khiến cho Dom 0 phải chịu tải rất lớn (trong trường hợp tồi nhất, máy ảo HVM có thể chiếm mất 50% CPU khiến hệ thống quá tải). Các storage và network card ảo (IDE và Realtek 8139) chạy trên HVM mode được cung cấp cũng có hiệu năng chậm. Ngoài ra, một số tính năng khác của Hypervisor sẽ không được tận dụng như live migration, live snapshot. Bởi vậy, Citrix khuyến khích các máy ảo DomU cài thêm một plugin bên trong máy ảo để chuyển đổi sang chế độ PV hoặc PVHVM giúp tăng hiệu năng hệ thống.

  Mô hình tổng quan của Xen PV driver trên Windows

Hình 6. Xen PV Driver trên Windows (nguồn: xen.org)

PV driver trên Xen 6.1

Hình 7. Kiến trúc PV Driver trên Xen Server 6.1 (nguồn: xen.org)

• Event channel giao tiếp giữa các Dom.

Hình 8. Event Channel trong Xen (nguồn: xen.org)

• Xend/XAPI

Hình 9. Xend trong Xen hypervisor (nguồn: xen.org)

Daemon (viết bằng python) nắm nhiệm vụ quản lý chung cho toàn hệ thống Xen, giao tiếp trực tiếp với Xen Hypervisor thông qua thư viện C libxenctrl. Toàn bộ các giao tiếp giữa Xend thông qua giao thức XML RPC và sử dụng các CLI như xm hoặc xe.

• libxenctrl

  Thư viện C giúp Xend có thể giao tiếp với hypervisor trong Dom 0 thông qua một driver đặc biệt là privcmd.

Hình 10. Thư viện libxenctrl (nguồn: xen.org)

• Xen virtual firmware

  Là một virtual bios được đính kèm với mỗi Dom U chạy ở chế độ HVM (Full-virtualization) để bảo đảm rằng OS cài trên guest có thể nhận được các chỉ dẫn start-up từ môi trường Xen xung quanh. Được OpenStack và CloudStack sử dụng để truyền các parameter cấu hình cho Linux VM như host name, IP...

Trên đây là các vấn đề cơ bản nhất về Xen Server cùng các thành phần bên trong module Storage của Xen. Thời gian tới, nhóm sẽ tiếp tục viết và cung cấp thêm các kiến thức về module Network và Resource Monitoring của Xen.

VietStack Team.