Tiểu luận về XEN Nghệ thuật ảo hóa

Tiểu luận về XEN Nghệ thuật ảo hóa. So sánh với các công nghệ ảo hóa khác

MỤC LỤC

2.1.1 Quản lý bộ nhớ 6

2.1.2 CPU 7

2.1.3 Thiết bị I/O 9

3.1 TRUYỀN ĐIỀU KHIỂN: HYPERCALL VÀ SỰ KIỆN 12

3.3.1 Điều phối CPU 14

3.3.2 Time và timers 14

3.3.3 Phiên dịch địa chỉ ảo 15

3.3.4 Bộ nhớ vật lý 16

3.3.5 Mạng 17

3.3.6 Đĩa 17

3.4 XÂY DỰNG 1 DOMAIN MỚI 18

4.1 HIỆU SUẤT TƯƠNG ĐỐI 20

4.2 ĐIỂM CHUẨN HỆ ĐIỀU HÀNH 22

4.2.1 Hiệu suất mạng 23

4.3 MÁY ẢO CHẠY ĐỒNG THỜI 23

4.4 KHẢ NĂNG MỞ RỘNG 25

5.1 TƯƠNG LAI 28

5.2 KẾT LUẬN 28

TÓM TẮT

Nhiều hệ thống được thiết kế sử dụng ảo hóa để chia 1 máy tính mạnh thành nhiều máy nhỏ Một số thì yêu cầu phần cứng chuyên dụng, hoặc không thể hỗ trợ hệ điều hành tiện nghi Một số khác thì chấp nhận hi sinh tính bảo mật hoặc tốc độ Một số ít bị cô lập tài nguyên Hầu hết chỉ đáp ứng tạm thời, có nguy cơ từ chối dịch vụ

Bài báo này trình bày Xen, một phần mềm cho phép nhiều hệ điều hành chia sẻ phần cứng và quản lý tài nguyên một cách an toàn, nhưng không bị giảm hiệu suất hoặc chức năng Điều này có thể thực hiện bằng cách cung cấp một máy ảo

lý tưởng mà các hệ điều hành như Linux, BSD và Windows XP, có thể được

“định cư” dễ dàng

Mục tiêu thiết kế của chúng tôi là lưu trữ lên đến 100 máy ảo chạy đồng thời trên một máy chủ hiện đại Cách ảo hóa của Xen là cực kỳ hiệu quả: cho phép các hệ điều hành như Linux và Windows được host đồng thời với tổng hiệu suất tăng không đáng kể - chỉ khoảng vài phần trăm so với trường hợp không ảo hóa Có thể cạnh tranh được với các sản phẩm thương mại

PHẦN 1: GIỚI THIỆU

Máy tính hiện đại đủ mạnh để chứa nhiều máy ảo nhỏ, mỗi máy ảo chạy 1 hệ điều hành riêng biệt Trong bài báo này chúng tôi trình bày Xen, một phần mềm quản lý máy ảo hiệu quả cao: quản lý nguồn tài nguyên, hosting đồng thời nhiều máy, phân tán dịch vụ web, bảo mật và tính di động ứng dụng (mobility)

Việc phân vùng một máy tính để hỗ trợ việc hosting đồng thời nhiều hệ điều hành đặt ra một số thách thức Thứ nhất, các máy ảo phải được cô lập với nhau: việc thực thi của máy này không ảnh hưởng xấu đến máy khác Thứ hai, hỗ trợ các hệ điều hành khác nhau thích ứng với các ứng dụng phổ biến Thứ ba, performance tăng không đáng kể

Xen có thể host các hệ điều hành khác nhau, mặc dù có một số phải sửa đổi mã nguồn Xen cho phép người dùng khởi tạo nhanh chóng một hệ điều hành để thực hiện bất cứ điều gì họ mong muốn

Có nhiều cách xây dựng một hệ thống để host nhiều ứng dụng và máy chủ trên một máy tính chia sẻ Có lẽ là đơn giản nhất là triển khai một hoặc nhiều máy chạy hệ điều hành chuẩn như Linux hoặc Windows, và cho phép người dùng cài đặt chương trình và xử lý các tập tin Kinh nghiệm cho thấy quản trị hệ thống có thể trở thành một công việc tốn nhiều thời gian do sự tương tác phức tạp giữa các ứng dụng phân chung

Quan trọng hơn, hệ thống như vậy này không hỗ trợ đầy đủ việc cô lập performance: độ ưu tiên thực thi, nhu cầu bộ nhớ, lưu lượng mạng và truy cập ổ cứng của một tiến trình sẽ tác động đến performance của máy khác Điều này có thể chấp nhận được khi có trích lập dự phòng đầy đủ và một nhóm sử dụng khép kín (như trong trường hợp của tính toán lưới), nhưng vẫn không được nếu tài nguyên đăng ký vượt mức hoặc người sử dụng không hợp tác

Một cách để giải quyết vấn đề này là trang bị thêm phần cứng để tăng performance của hệ điều hành Khó khăn của hướng này là đảm bảo rằng tất cả các tài nguyên được tính toán vừa đủ, ví dụ, các tương tác phức tạp giữa các ứng dụng là do bộ đệm hoặc thuật toán thay thế trang (page replacement algortithms) Chúng tôi sử dụng cách tiếp cận tương để xây dựng Xen, ghép nhiều nguồn tài nguyên vật lý thành một khối và có thể cô lập performance giữa chúng Có một giá phải trả cho sự linh hoạt này - chạy một hệ điều hành đầy đủ thì nặng hơn chạy một chương trình, kể cả về mặt khởi động hoặc tiêu thụ tài nguyên

Mục tiêu là host lên đến 100 hệ điều hành, điều này sẽ rất đáng giá Nó rất linh hoạt, người sử dụng có thể linh động tạo ra môi trường thực thi chính xác cho các phần mềm Tránh được sự tương tác cấu hình giữa các dịch vụ và ứng dụng khác nhau.

Phần còn lại của bài báo này được cấu trúc như sau: tại mục 2, chúng tôi giải thích cách tiếp cận của chúng tôi đối với ảo hóa và đề ra phương cách Xen hoạt động Phần 3 mô tả các khía cạnh quan trọng trong thiết kế và thực thi của chúng tôi Phần 4 sử dụng các tiêu chuẩn để đánh giá hiệu suất của XenoLinux chạy trên Xen so với Linux độc lập, VMware Workstation và User-mode Linux (UML) Phần 5 đánh giá công việc liên quan, và cuối cùng Phần 6 thảo luận về công việc tương lai và kết luận

PHẦN 2: XEN – TIẾP CẬN VÀ TỔNG QUAN

Trong một VMM truyền thống, phần cứng ảo có chức năng giống với máy tính bình thường Mặc dù ảo hóa toàn diện (full virtualization) rất hữu dụng khi cho phép hệ điều hành được host, nó cũng có một số nhược điểm Điều này đặc biệt

Một số phần mềm cần phải được xử lý bởi VMM để ảo hóa đúng, nhưng thực hiện những việc này với đủ đặc quyền có thể gây ra một số lỗi Hiệu quả ảo hóa các MMU x86 cũng là khó khăn Những vấn đề này có thể được giải quyết, nhưng lại tăng độ phức tạp và giảm hiệu suất ESX Server của VMware tự động ghi nhận mã máy host để can thiệp khi VMM yêu cầu Việc này được áp dụng cho toàn bộ OS kernel vì tất cả các lỗi cần phải và xử lý ESX Server thực thi các phiên bản của cấu trúc hệ thống như bảng trang (page table) và duy trì tính nhất quán với các trang ảo (virtual page) bằng cách giữ các bản cập nhật - phương pháp này có chi phí như tạo ra một chương trình ứng dụng mới

Do tính phức tạp của x86, nên có những tranh luận khác chống lại ảo hóa toàn diện Đặc biệt, có những tình huống mà người ta mong muốn thấy được tài nguyên thực và ảo của các hệ điều hành được host: cung cấp cả thời gian thực và

ảo cho phép một hệ điều hành hỗ trợ tốt hơn các nhiệm vụ về xử lý thời gian, để

xử lý một cách chính xác thời gian chờ TCP và ước lượng RTT, trong khi địa chỉ máy tính thực cho phép một hệ điều hành cải thiện hiệu suất bằng cách sử dụng superpages hoặc trang màu (page coloring)

Chúng tôi tránh những hạn chế của ảo hóa toàn diện bằng cách trình bày một máy

ảo tương tự nhưng không giống với máy thật - một cách tiếp cận, có tên gọi ảo hóa song song (paravirtualization) Điều này hứa hẹn sẽ cải thiện hiệu suất, mà không cần thay đổi hệ điều hành Điều quan trọng cần lưu ý, chúng tôi không yêu cầu thay đổi giao diện ứng dụng (ABI), và do đó không thay đổi được yêu cầu cho các ứng dụng khách

Chúng tôi chắt lọc các cuộc thảo luận cho đến nay vào một tập hợp các nguyên tắc thiết kế:

1 Hỗ trợ cho các ứng dụng nhị phân nguyên bản, hoặc người sử dụng sẽ không chuyển đổi sang Xen Do đó chúng ta phải ảo hóa tất cả các đặc trưng kiến trúc theo yêu cầu tiêu chuẩn hiện hành của ABI

2 Hỗ trợ đầy đủ hệ điều hành đa ứng dụng, vì điều này cho phép cấu hình máy chủ phức tạp để được ảo hóa trong một trường hợp duy nhất hệ điều hành khách.

3 Ảo hóa song song là cần thiết để có được hiệu suất cao và sự cô lập tài nguyên mạnh mẽ trên kiến trúc máy tính như x86

4 Ngay cả trên kiến trúc máy tính cộng tác, việc che dấu hoàn toàn sự ảnh hưởng của ảo hóa tài nguyên từ hệ điều hành khách sẽ làm giảm tính chính xác và hiệu suất

Lưu ý rằng ảo hóa song song x86 của chúng tôi là hoàn toàn khác với các dự án Denali gần đây đề xuất Denali được thiết kế để hỗ trợ hàng ngàn máy ảo đang chạy các dịch vụ mạng, phần lớn trong số đó là quy mô nhỏ và không phổ biến Ngược lại, Xen được thiết kế để mở rộng quy mô cho khoảng 100 máy ảo đang chạy các ứng dụng và dịch vụ tiêu chuẩn công nghiệp

Thứ nhất, Denali không nhắm đến mục tiêu ABI hiện có, và vì vậy có thể che đi đặc trưng kiến trúc từ giao diện máy ảo của họ Ví dụ, Denali không hỗ trợ đầy

đủ các phân khúc x86 mặc dù nó được sử dụng rộng rãi trong ABIs của NetBSD, Linux, và Windows XP

Thứ hai, việc thực thi của Denali không giải quyết được vấn đề hỗ trợ ghép kênh ứng dụng, cũng như nhiều không gian địa chỉ, trong một hệ điều hành khách duy nhất Thay vào đó, các ứng dụng được liên kết một cách rõ ràng đối với một thực thể của hệ điều hành khách Ilwaco Do đó, thực chất của mỗi máy ảo là single-user, single-application Trong Xen thì ngược lại, một máy ảo duy nhất host một

hệ điều hành thực mà có thể tự mình ghép hàng ngàn các chương trình một cách

an toàn

Thứ ba, trong kiến trúc Denali, VMM thực hiện tất cả các phân trang đến và đi từ

ổ đĩa Điều này có lẽ liên quan đến việc thiếu hỗ trợ quản lý bộ nhớ tại tầng ảo hóa Phân trang trong VMM là ngược lại với mục tiêu của chúng tôi trong việc cô lập thực thi Trong Xen chúng tôi hy vọng mỗi hệ điều hành khách thực hiện phân trang của riêng mình, đảm bảo phân bố bộ nhớ và đĩa

Cuối cùng, Denali ảo hóa “không gian tên” của tất cả tài nguyên máy Ngược lại, chúng tôi tin rằng kiểm soát an toàn truy cập trong các phần mềm máy ảo là đủ

để đảm bảo

Trong phần sau đây, chúng tôi mô tả các máy ảo tạo bởi Xen và thảo luận về cách một hệ điều hành khách được sửa đổi để phù hợp Lưu ý rằng trong bài báo này,

chúng tôi dành riêng thuật ngữ hệ điều hành khách (guest operating system) để nói đến một hệ điều hành mà Xen có thể host và chúng tôi sử dụng thuật ngữ domain để chỉ một máy ảo có hệ điều hành đang chạy, sự khác biệt tương tự như giữa 1 chương trình (program) và một tiến trình (process) trong một hệ thống thông thường Chúng tôi gọi Xen là hypervisor.

2.1 GIAO DIỆN MÁY ẢO:

Quản lý bộ nhớ

Ngắc phần cứng được thay thế bằng một hệ thống sự kiện bình thường

Mỗi hệ điều hành khách có một giao diện hẹn giờ và nhận biết cả thời gian “thực” và “ảo”

Thiết bị I/O

Mạng, đĩa, Thiết bị ảo truy nhập rất đơn giản Dữ liệu được chuyển thông qua vòng không đồng bộ I/O Một cơ chế sự kiện

thay thế ngắt phần cứng bằng các thông báo

Bảng 1: Giao diện ảo hóa song song x86.

Bảng 1 trình bày tổng quan về giao diện ảo hóa song song x86, một nhân tố trong

ba khía cạnh mở rộng của hệ thống: quản lý bộ nhớ, CPU, và thiết bị I/O Trong phần tiếp theo chúng tôi lần lượt đề cập đến máy tính phụ, và trình bày kiến trúc

ảo hóa song song Lưu ý rằng một số phần như quản lý bộ nhớ, CPU và các thiết

bị I/O (cụ thể đối với x86) có thể dễ dàng áp dụng cho kiến trúc máy tính khác Hơn nữa, x86 có thể đại diện cho một trường hợp xấu nhất

2.1.1 Quản lý bộ nhớ

Ảo hóa bộ nhớ chắc chắn là phần khó khăn nhất trong kiến trúc ảo hóa song song Nhiệm vụ này sẽ dễ dàng hơn nếu kiến trúc cung cấp một phần mềm quản

lý TLB TLB là một tính năng hữu ích được hỗ trợ bởi hầu hết các máy chủ có

kiến trúc RISC, bao gồm cả Alpha, MIPS và SPARC Kết hợp một thẻ nhận dạng không gian địa chỉ với mỗi TLB cho phép hypervisor và mỗi hệ điều hành khách cùng tồn tại một cách hiệu quả trong không gian địa chỉ riêng biệt mà không cần giải phóng TLB.

Translation lookaside buffer (TLB) là một cache mà phần cứng quản lý bộ nhớ sử dụng để tăng tốc độ phiên dịch địa chỉ ảo

Tuy nhiên, x86 lại không có phần mềm quản lý TLB; Thay vào đó là được phục

vụ tự động bởi bộ xử lý bằng cách duyệt cấu trúc trong bảng trang phần cứng Vì vậy, để đạt được hiệu quả tốt nhất có thể, tất cả các bản dịch trang trong không gian địa chỉ hiện tại đều hiện diện trong bảng trang phần cứng Hơn nữa, vì TLB không được gắn nhãn, không gian địa chỉ thường yêu cầu giải phóng TLB Với những hạn chế như trên, chúng tôi đưa ra hai quyết định: (i) hệ điều hành khách chịu trách nhiệm bố trí và quản lý các bảng trang phần cứng, với sự tham gia tối thiểu từ Xen để đảm bảo an toàn và cách ly, và (ii) Xen nằm trong 64MB tại đầu mỗi không gian địa chỉ, do đó tránh phải giải phóng TLB khi vào và ra hypervisor

Mỗi lần một hệ điều hành khách yêu cầu một bảng trang mới, một tiến trình mới được tạo ra, nên nó cấp phát và khởi tạo một trang từ bộ nhớ riêng của mình và đăng ký với Xen Tại thời điểm này hệ điều hành không được phép ghi trực tiếp vào bộ nhớ bảng trang: tất cả các bản cập nhật tiếp theo phải được xác nhận bởi Xen Điều này hạn chế cập nhật theo một số cách, bao gồm chỉ cho phép một hệ điều hành kết nối đến các trang mà nó sở hữu, và không cho phép ghi ánh xạ các bảng trang Hệ điều hành khách có thể cập nhật hàng loạt các yêu cầu để tiết kiệm tài nguyên cho hypervisor Khu vực đầu 64MB của mỗi không gian địa chỉ, phần dành cho Xen, hệ điều hành khách không truy cập hoặc ánh xạ lại được Vùng địa chỉ này không được sử dụng bởi bất kỳ Abis x86 nào, tuy vậy, hạn chế này không ảnh hưởng khả năng tương thích ứng dụng

Phân đoạn (segmentation) được ảo hóa theo cách tương tự, bằng cách xác nhận cập nhật đến bảng mô tả phân đoạn phần cứng Các hạn chế trên mô tả phân đoạn x86 là: (i) phải có đặc quyền thấp hơn Xen, và (ii) không cho phép bất kỳ truy cập đến phần dành riêng không gian địa chỉ của Xen

2.1.2 CPU

Ảo hóa CPU có một số tác động đối với hệ điều hành khách Về nguyên tắc, khi hypervisor được cài vào 1 hệ điều hành là vi phạm giả định thông thường: hệ

điều hành là thực thể có đặc quyền cao nhất trong hệ thống Để bảo vệ các hypervisor tránh tác động của hệ điều hành (và từ các domain khác tới), hệ điều hành khách phải được sửa đổi để chạy ở mức có đặc quyền thấp hơn.

Nhiều kiến trúc vi xử lý chỉ cung cấp hai mức độ đặc quyền Trong những trường hợp này, hệ điều hành khách sẽ chia sẻ với các ứng dụng ở mức đặc quyền thấp hơn Hệ điều hành khách sau đó sẽ tự bảo vệ mình bằng cách chạy trong một không gian địa chỉ riêng biệt từ các ứng dụng của nó Nếu TLB của bộ xử lý hỗ trợ nhãn không gian địa chỉ thì sẽ tránh được làm sạch TLB

Mức đặc quyền ảo hóa trên x86 khá linh hoạt vì phần cứng nó hỗ trợ bốn cấp Các cấp đặc quyền x86 thường được mô tả như chiếc vòng (rings), và được đánh

số từ 0 (đặc quyền cao nhất) đến 3 (đặc quyền thấp nhất) Hệ điều hành thường thực thi trong ring 0, trong khi ring 3 thường được sử dụng cho ứng dụng Theo chúng tôi biết, ring 1 và 2 đã không còn được sử dụng bởi bất kỳ hệ điều hành x86 nào kể từ khi OS / 2

Lệnh đặc quyền được ảo hóa song song bằng cách yêu cầu chúng phải được xác nhận và thực thi trong Xen Bất kỳ hệ điều hành khách nào cố gắng để trực tiếp thực thi một lệnh đặc quyền sẽ bị lỗi, vì chỉ có Xen mới được thực thi ở mức đầy

đủ đặc quyền

Trường hợp ngoại lệ, bao gồm cả lỗi bộ nhớ và phần mềm, được ảo hóa trên x86 trực tiếp Một bảng mô tả xử lý đối với từng loại ngoại lệ sẽ được đăng ký với Xen để xác nhận Việc xử lý theo quy định tại bảng này thường đồng nhất với những phần cứng x86 thực tế, vì các stack frame ngoại lệ chưa được sửa đổi trong kiến trúc ảo hóa song song Chỉ có 1 thay đổi là để xử lý lỗi trang, thông thường sẽ đọc địa chỉ lỗi từ thanh ghi xử lý xử lý đặc quyền(CR2), vì điều này là không thể, nên nó đươc ghi vào stack frame mở rộng Một ngoại lệ xảy ra trong khi thực hiện bên ngoài ring 0, Xen xử lý bằng cách tạo ra một bản sao của các stack frame ngoại lệ trên stack hệ điều hành khách và trả về điều khiển để xử lý đăng ký thích hợp

Thông thường chỉ có hai loại ngoại lệ xảy ra thường xuyên, đủ để ảnh hưởng đến hiệu suất hệ thống: cuộc gọi hệ thống (system call) và lỗi trang (page fault) Chúng tôi cải thiện hiệu suất của các cuộc gọi hệ thống bằng cách cho phép mỗi

hệ điều hành khách đăng ký một xử lý ngoại lệ 'nhanh' mà được truy cập trực tiếp bởi các vi xử lý mà không cần gián tiếp qua ring 0; xử lý này được xác nhận trước khi cài đặt nó trong bảng ngoại lệ Tiếc là không thể áp dụng kỹ thuật

tương tự để xử lý lỗi trang được bởi vì những mã thực thi trong ring 0 có thể đọc các địa chỉ lỗi từ thanh ghi CR2, do đó lỗi trang luôn luôn được gửi qua Xen để giá trị thanh ghi này có thể được lưu cho truy cập trong ring 1.

An toàn được đảm bảo bằng cách xác nhận xử lý ngoại lệ khi chúng được đưa tới Xen Yêu cầu kiểm tra đó là đoạn mã xử lý không có nằm trong ring 0 Không có

hệ điều hành khách nào có thể tạo ra một đoạn mã như vậy Xen phát hiện những

"lỗi kép" bằng cách kiểm tra các giá trị đếm lỗi chương trình: nếu địa chỉ nằm trong mã xử lý ngoại lệ thì sẽ ngắt tiến trình xâm phạm đến hệ điều hành khách.Quá trình kiểm tra an toàn ngay cả đối với các xử lý cuộc gọi hệ thống trực tiếp: lỗi truy cập sẽ xảy ra khi CPU cố gắng để “nhảy” trực tiếp đến xử lý hệ điều hành khách Trong trường hợp này, địa chỉ lỗi sẽ ở bên ngoài Xen (vì Xen sẽ không bao giờ thực thi một cuộc gọi hệ thống hệ điều hành khách) và như vậy lỗi được

ảo hóa theo cách thông thường Nếu gây ra thêm "lỗi kép", thì hệ điều hành khách bị ngắt như mô tả ở trên

Tương tự như ngắt phần cứng, Xen hỗ trợ một cơ chế cung cấp sự kiện đơn giản được sử dụng để gửi thông báo không đồng bộ vào domain Các thông báo được thực hiện bằng cách gọi một xử lý sự kiện theo quy định của hệ điều hành khách Những callback có thể được "giữ khoảng cách" theo quyết định của hệ điều hành khách - để tránh chi phí phát sinh thêm bằng cách thường xuyên thông báo đánh thức

2.2 CHI PHÍ THÍCH NGHI (PORTING) 1 HỆ ĐIỀU HÀNH VÀO XEN:

OS subsection # lines

Linux XP

Architecture-independent 78 1299

Virtual network driver 484 –

Virtual block-device driver 1070 –

Xen-specific (non-driver) 1363 3321

(Portion of total x86 code base 1.36%0.04%)

Bảng 2 cho thấy chi phí, (Chuẩn đo là số lines), hệ điều hành thích nghi với môi trường ảo hóa song song x86 của Xen Sự thích nghi của XP vẫn còn đang tiếp diễn, nó có thể thực thi ứng dụng nhờ sử dụng RAM, nhưng hiện đang thiếu một vài trình điều khiển I/O ảo Vì lý do này, số liệu về trình điều khiển thiết bị ảo cho XP không được trình bày Tuy nhiên, với Linux, chúng tôi mong đợi các trình điều khiển này sẽ nhỏ và đơn giản nhờ sự lý tưởng hóa phần cứng của Xen.Windows XP yêu cầu một số lượng lớn cần sửa đổi trong kiến trúc hệ điều hành độc lập bởi vì nó sử dụng các cấu trúc khác nhau để truy cập vào bảng trang (PTEs) Mỗi truy cập bảng trang phải được sửa đổi một cách riêng biệt, mặc dù một số tiến trình này được tự động với kịch bản Ngược lại, Linux cần rất ít sửa đổi vào hệ thống bộ nhớ chung của nó vì nó sử dụng các macro xử lý trước để truy cập các PTE

2.3 KIỂM SOÁT VÀ QUẢN LÝ:

Trong thiết kế và hoạt động của Xen, hypervisor phải gồm các datapath – datapath là tập hợp các đơn vị chức năng để xử lý dữ liệu (ví dụ, lịch làm việc CPU giữa các domain, lọc gói tin mạng trước khi truyền, hoặc thực thi kiểm soát truy cập khi đọc các khối dữ liệu), CPU sẽ được chia sẻ như thế nào hoặc các loại packet nào của domain có thể truyền

Hình1: K i ế n t r ú c c ủ a 1 m á y c h ạ y X e n hypervisor, hosting nhiều hệ điều hành khác nhau, gồm Domain0 chạy phần mềm kiểm soát trong môi trường XenoLinux.

Cấu trúc hệ thống tổng thể được minh họa trong Hình 1 Lưu ý rằng một domain được tạo ra vào lúc khởi động được phép sử dụng giao diện điều khiển Domain khởi tạo này, gọi là Domain0, chịu trách nhiệm hosting các phần mềm quản lý mức ứng dụng Giao diện điều khiển hỗ trợ tạo ra và ngắt các domain khác và kiểm soát các thông số điều phối, cấp phát bộ nhớ vật lý và truy cập chúng từ các

ổ đĩa vật lý của máy và thiết bị mạng

Ngoài tài nguyên bộ nhớ và bộ xử lý, giao diện điều khiển hỗ trợ việc tạo và xóa các giao diện mạng ảo (VIFs) và các thiết bị khối (VBDs) Các thiết bị I/O ảo này đã liên kết thông tin điều khiển truy cập để xác định domain nào có thể truy cập chúng, và cấm những gì (ví dụ, ngăn chặn nguồn giả mạo địa chỉ)

Giao diện điều khiển này, cùng với thống kê về hiện trạng của hệ thống, được hỗ trợ từ một bộ các ứng dụng công cụ quản trị cho phép quản lý thuận tiện toàn bộ máy chủ: các công cụ hiện tại có thể tạo ra và hủy các domain, thiết lập các bộ lọc mạng và quy tắc định tuyến, theo dõi hoạt động mạng tại domain và tạo và xóa các giao diện mạng ảo và các thiết bị khối ảo Chúng tôi đang tiếp tục phát triển các công cụ cao cấp để tiếp tục tự động hóa áp dụng các chính sách quản lý

PHẦN 3: THIẾT KẾ CHI TIẾT

Trong phần này, chúng tôi giới thiệu các thiết kế của các hệ thống con chính để tạo nên một máy chủ Xen Trong mỗi trường hợp, chúng tôi giới thiệu cả chức năng của Xen và hệ điều hành khách để rõ ràng hơn Các cuộc thảo luận hiện nay về hệ điều hành khách tập trung vào XenoLinux vì đây là OS phát triển nhất,

dù sao khả năng thích nghi của Windows XP và NetBSD vẫn tốt lên, tạo cho chúng ta sự tự tin rằng Xen là hệ điều hành khách bất khả tri

3.1 TRUYỀN ĐIỀU KHIỂN: HYPERCALL VÀ SỰ KIỆN

Hai cơ chế tồn tại trong tương tác điều khiển giữa Xen và domain nằm phía trên: các cuộc gọi đồng bộ từ một domain đến Xen có thể được thực hiện bằng cách sử dụng hypercall, trong khi thông báo được gửi đến domain từ Xen sử dụng một cơ chế sự kiện bất đồng bộ

Giao diện hypercall cho phép domain thi hành một lỗi phần mềm đồng bộ vào hypervisor để thực hiện một hoạt động đặc quyền, tương tự như việc sử dụng các cuộc gọi hệ thống trong hệ điều hành thông thường Một ví dụ về sử dụng một hypercall là yêu cầu một tập các cập nhật page table, trong đó Xen xác nhận và

áp dụng một danh sách các bản cập nhật, trả về điều khiển để gọi domain khi điều này được hoàn tất

Thông tin từ Xen vào một domain được cung cấp thông qua một cơ chế sự kiện bất đồng bộ, thay thế cơ chế thông thường để ngắt thiết bị và cho phép thông báo

sự kiện quan trọng như yêu cầu ngắt domain Tương tự như tín hiệu Unix, chỉ có một số ít các sự kiện, mỗi hành động để đánh dấu một loại đặc biệt xảy ra Ví dụ, các sự kiện được sử dụng để chỉ ra rằng dữ liệu mới đã được nhận được qua mạng, hoặc yêu cầu ổ đĩa ảo được hoàn thành

Các sự kiện pending được lưu trữ trong một bitmask của mỗi domain được cập nhật bởi Xen trước khi gọi một xử lý event callback theo quy định của hệ điều hành khách Xử lý callback chịu trách nhiệm cài đặt lại các thiết lập của các sự kiện pending và chịu trách nhiệm thông báo một cách thích hợp Một domain có thể trì hoãn việc xử lý sự kiện một cách rõ ràng bằng cách thiết lập một cờ ready: điều này tương tự để vô hiệu hóa ngắt trên một bộ xử lý thực tế

3.2 TRUYỀN DỮ LIỆU: RING I/O

Sự hiện diện của một hypervisor có nghĩa là thêm vào sự bảo vệ domain giữa hệ điều hành khách và thiết bị I/O, vì vậy điều quan trọng là cơ chế truyền dữ liệu cho phép dữ liệu di chuyển theo chiều dọc của hệ thống với ít chi phí nhất có thể.Hai yếu tố chính để thiết kế cơ chế truyền I/O: quản lý tài nguyên và thông báo

sự kiện Về quản lý tài nguyên, chúng tôi cố gắng để giảm thiểu công việc cần thiết để ghép, tách dữ liệu đến 1 domain cụ thể khi một tín hiệu ngắt được nhận

từ một thiết bị - sau quá trình tính toán sẽ được đưa đến domain thích hợp Tương

tự như vậy, bộ nhớ được ghi vào thiết bị I/O được quy định bởi các domain liên quan, để ngăn chặn sự nhiễu trong vùng đệm chia sẻ; bộ đệm I/O được bảo vệ trong quá trình truyền dữ liệu bằng cách chốt vào page frame trong Xen

Hình 2: Cấu trúc không đồng bộ vòng I/O, được sử dụng để truyền dữ liệu giữa Xen và hệ điều hành khách.

Hình 2 cho thấy cấu trúc của vòng I/O Mỗi vòng là một hàng đợi tròn được mô

tả bởi 1domain nhưng có thể truy cập từ bên trong Xen Truy cập vào mỗi vòng

là dựa trên hai cặp con trỏ Producer-Consumer: vị trí domain yêu cầu một vòng, kéo theo yêu cầu con trỏ Producer, và Xen loại bỏ những yêu cầu xử lý này, kéo theo yêu cầu con trỏ Consumer liên quan Câu trả lời (Responses) được đặt trở lại vòng theo cách tương tự, với Xen là Producer và hệ điều hành khách là

Consumer Không có ràng buộc là các yêu cầu phải được xử lý theo thứ tự: hệ điều hành khách liên kết một định danh duy nhất ứng với mỗi yêu cầu Điều này cho phép Xen sắp xếp lại một cách rõ ràng hoạt động I/O nhờ xem xét lịch trình hoặc độ ưu tiên.

Cấu trúc này hỗ trợ nhiều mô hình thiết bị khác nhau Ví dụ, một tập hợp các 'request' có thể cung cấp bộ đệm để tiếp nhận gói dữ liệu mạng, 'responses' sẽ báo hiệu sự xuất hiện của các gói tin vào các bộ đệm Sắp xếp lại rất hữu ích khi thực hiện yêu cầu sử dụng đĩa, nó cho phép các request này được sắp xếp trong Xen sao cho hiệu quả

Trong trường hợp có request , một domain có thể enqueue (sắp vào hàng) nhiều lần trước khi gọi một hypercall để cảnh báo Xen; trong trường hợp có responses, một domain có thể trì hoãn việc trả lời của một sự kiện bằng cách xác định số ngưỡng của responses Điều này cho phép mỗi domain đánh đổi yêu cầu độ trễ và băng thông

3.3 ẢO HÓA HỆ THỐNG CON

Các cơ chế truyền dữ liệu và điều khiển được sử dụng trong công nghệ ảo hóa các hệ thống con Trong phần tiếp theo, chúng tôi thảo luận về cách ảo hóa được thực hiện cho CPU, giờ, bộ nhớ, mạng và đĩa

3.3.1 Điều phối CPU

Xen hiện đang điều phối theo thuật toán Borrowed Virtual Time (BVT) Chúng tôi chọn thuật toán đặc biệt này vì nó là có thể duy trì công việc và có một cơ chế đặc biệt với độ trễ thấp khi nó nhận được một sự kiện BVT có độ trễ thấp do sử dụng virtual-time warping, một cơ chế tạm thời vi phạm "lý tưởng" chia sẻ công bằng có lợi cho lĩnh vực mới được đánh thức Các thông số điều phối cho mỗi domain có thể được điều chỉnh bằng phần mềm quản lý chạy trong Domain0

3.3.2 Time và timers

Xen cung cấp hệ điều hành khách với các khái niệm về thời gian thực, thời gian

ảo và thời gian wall-clock Thời gian thực được tính trong nano giây kể từ khi máy khởi động và duy trì tính chính xác của chu kỳ của bộ xử lý và có thể là tần

số update từ nguồn thời gian bên ngoài (ví dụ, thông qua NTP) Thời gian ảo của domain được sử dụng khi nó được thực thi: hệ điều hành điều phối để đảm bảo chính xác chia sẻ thời gian giữa các chương trình ứng dụng Wall-lock được xác định như phần bù đắp vào thời gian hiện hành Điều này cho phép thời gian wall-clock được điều chỉnh mà không ảnh hưởng đến tiến trình của thời gian thực