MÔ HÌNH VÀ LẬP LỊCH THỜI GIAN TẠM TREO VÀ PHỤC HỒI MÁY ẢO
7.2.2.Thực nghiệm 1: Tạm treo và phục hồi hợp đồng
Trong thực nghiệm này, có hai hợp đồng được lập lịch trên một cụm máy: một hợp đồng chạy nền (BE_LEASE) được lập lịch trước và sử dụng tất cả tài nguyên rảnh, có thể bị chiếm đóng để giải phóng tài nguyên cho hợp đồng đặt chỗ (AR_LEASE), tức là tạm treo tất cả máy ảo của BE_LEASE và phục hồi lại khi AR_LEASE kết thúc. Mục đích thực nghiệm này là đo độ chính xác của thời gian tạm treo và phục hồi đã ước lượng, so sánh giá trị mô hình dự đoán với giá trị thực đo được. Mặc dù những kết quả này chỉ làm nổi bật việc các hợp đồng được lập lịch trong trường hợp cá biệt này như thế nào nhưng cũng một phần nào giúp ta hiểu được những nhân tố nào ảnh hưởng đến tính chính xác của mô hình.
sử dụng tài nguyên, cần thiết phải chiếm lấp tài nguyên chạy nền. Hợp đồng chạy nền được tạm treo trước đặt chỗ và sau đó được phục hồi lại khi kết thúc hợp đồng đặt chỗ.
Cả hai hợp đồng đều được yêu cầu tại thời điểm bắt đầu thực nghiệm và cần tất cả tài nguyên vật lý có được. AR_LEASE yêu cầu thời gian 5 phút và cần bắt đầu sau khi chạy thực nghiệm 15 phút. BE_LEASE yêu cầu thời gian 20 phút, khi không có hợp đồng nào tại thời điểm bắt đầu thực nghiệm, BE_LEASE có thể bắt đầu tức thì (nhưng sẽ bị AR_LEASE chiếm lấp khi chạy được 15 phút (hình 15)). Trong thực nghiệm này, ta sẽ khảo sát ba loại tham số:
• c {1, 2, 4, 8}: Số máy ảo trong một máy đơn. Vì mỗi hợp đồng đều dùng hết tất cả tài nguyên khả dụng nên tổng số máy ảo sẽ là N = c.4.
• f {local, global}: Tập tin trạng thái bộ nhớ sẽ được lưu ở hệ thống tập tin cục bộ (local) hay là toàn cục (global).
• m {512, 768, 1024}: Tổng số bộ nhớ trên một máy ảo.
Thực nghiệm này thi hành 22 cấu hình (mỗi cấu hình là một tổ hợp các tham số, ngoại trừ c = 8 và m = 1024; bởi vì miền Xen Dom0 sử dụng 512MB bộ nhớ nên
• ts: Thời gian tạm treo BE_LEASE theo dõi được. Ta đo thời gian này bằng cách ping đến máy ảo chạy hợp đồng 2 giây mỗi lần và lưu lại phản hồi. Ta phân tích chuỗi trả lời để xác định thời gian hợp đồng dành để tạm treo.
• as: Mức chính xác của thời gian tạm treo (độ chênh lệch giữa thời gian đo được so với thời gian dự đoán). Ta định nghĩa as bằng . Giá trị 1.0 được coi là mức chính xác hoàn hảo. Giá trị nhỏ hơn 1.0 chứng tỏ việc lượng giá quá cao: máy ảo trong hợp đồng hoàn thành sớm hơn thời gian được dự đoán trong mô hình; làm tài nguyên lãng phí trong khoảng thời gian kết thúc tạm treo để bắt đầu hợp đồng đặt chỗ. Nếu as lớn hơn 1.0 nghĩa là hợp đồng mất lâu hơn để tạm treo hơn thời gian ước lượng, làm trì hoãn thời gian bắt đầu hợp đồng đặt chỗ.
• vs: Thời gian tạm treo một máy ảo thuộc hợp đồng BE_LEASE. Ta đã phân tích các tập
tin log của Xen để xác định thời gian này.
• tr, ar, vr: Định nghĩa tương tự đối với quá trình phục hồi.
Hình 16 trình bày các giá trị trung bình của ts, tr, as, và ar trong mỗi cấu hình thực nghiệm. Mỗi giá trị được lấy sau 5 lần chạy một cấu hình. Độ lệch chuẩn không trình bày trong biểu đồ nhưng giá trị cao nhất là 13.9% (phần lớn giá trị đều nhỏ hơn 10%). Những biểu đồ này cho thấy thời gian tạm treo và phục hồi tăng lên tỉ lệ thuận với số bộ nhớ yêu cầu, tỉ lệ gia tăng càng thấy rõ hơn khi f = global. Thời gian đo được cho thấy mô hình có khuynh hướng ước lượng thời gian tạm cao thấp hơn so với thực tế, 6 cấu hình có độ chính xác lớn hơn 1.0 và giá trị lớn nhất là 1.39 (hợp đồng dành thời gian tạm treo lớn hơn 39% so với ước lượng). Mặt khác, tất cả thời gian phục hồi đều được lượng giá thấp, lớn hơn 1.0 và có một giá trị lớn nhất là 1.64.
giá trị được đo đạc) từ 45 giây đến 370 giây. Bằng cách kiểm tra tập tin log của Xen, ta nhận ra rằng các giá trị ngoại lai xuất hiện do quá trình tạm treo bị Xen chặn mà không có lý do rõ ràng. Nói cách khác, Xen đã nhận và xử lý chính xác lệnh tạm treo, bao gồm tạm dừng máy ảo nhưng không thật sự lưu trạng thái bộ nhớ vào đĩa sau một khoảng thời gian bất định (mặc dù không chặn những thao tác khác). Hiện nay chưa có nghiên cứu nào nhắc đến vấn đề này.
Nói cách khác, các giá trị vr có xu hướng phân tán khi c tăng. Nguyên nhân trực tiếp là do sự tranh chấp tài nguyên giữa các lần phục hồi gối đè lên nhau. Mặc dù trình lập lịch lập lịch cho các lần phục hồi theo kiểu không gối lên nhau (cả toàn cục hay cục bộ) nhưng đôi khi các quá trình phục hồi có thể lâu hơn dự đoán, ảnh hưởng đến thời gian của kế hoạch phục hồi tiếp theo và trì hoãn cả quá trình. Ta nhận ra rằng nguyên nhân cơ bản gây ra các trì hoãn này là:
1. Quá trình tắt các AR_LEASE có thể đè lên các lần phục hồi đầu tiên: Nếu
AR_LEASE vẫn đang trong quá trình tắt hẳn khi quá trình phục hồi bắt đầu thì sẽ có sự tranh chấp tài nguyên làm trì hoãn lần phục hồi đầu tiên. Trong thực nghiệm này, h (15) là giá trị cố định và không liên quan đến số máy đơn trong một hợp đồng và sẽ thiếu khi c = 8 (ngay cả khi giả sử một máy ảo có thể tắt hẳn trong 1 giây với chi phí ban hành là 1 giây thì kết quả vẫn tới 64 giây).
2. Trì hoãn trong quá trình ban hành các lệnh: Thỉnh thoảng, các lệnh ban
hành gởi từ OpenNebula (dùng SSH) bị trì hoãn do chính server SSH, và có thể lên đến 10 giây.
3. Giá trị c càng lớn, tác dụng càng cao: Ở hai trường hợp trên, giá trị c càng
lớn, lần phục hồi bị trì hoãn càng ảnh hưởng đến các quá trình phục hồi khác. Kết quả là toàn bộ các giá trị bị phân tán rõ hơn. Ảnh hưởng này càng rõ ràng hơn khi tắt những phần đè lên lần phục hồi đầu tiên làm trì hoãn 31
thuộc vào các hợp đồng phải bị chiếm đóng trước khi bắt đầu.