6. http://gridengine.sunsource.net/
4.3.1.Virtual cluster:
Một số nhóm đã áp dụng giải pháp dùng VM để tạo virtual cluster tại đỉnh cơ sở hạ tầng hiện hành. Như hệ thống của Nishimura (7)có thể triển khai một cluster gồm 190 node với thời gian rất thấp 40 giây bằng cách coi những môi trường phần mềm là những gói nhị phân khi cài đặt trên những ảnh đĩa cùng loại. Ngoài ra việc lưu trữ những gói nhị phân ngay trên các node giúp hệ thống có
thể giảm thiểu số lần vận chuyển ảnh đĩa từ nơi chứa gói khác. Phương pháp này chỉ giới hạn với những môi trường phần mềm có thể cài đặt thành các gói nhị phân nhưng vẫn có thể cung cấp khả năng khác triển khai ảnh đĩa VM nhanh hơn nếu thời gian cài đặt đủ ngắn. Yamasaki (8) đã cải tiến hệ thống này bằng cách phát triển một mô hình dự tính trước thời gian cài đặt môi trường phần mềm mới trên một node, cho phép trình lập lịch lựa chọn những node có thể giảm tối thiểu thời gian cài đặt một virtual cluster mới. Mô hình này có quan tâm đến tính không đồng nhất của các node, sử dụng các tham số cho mỗi node (tần suất CPU và tốc độ đọc/ghi đĩa) và hệ số kinh nghiệm để tính trước thời gian chuyển và cài đặt tất cả những gói được yêu cầu, rồi sau đó khởi động lại node đó. Tuy nhiên, mô hình này không tính đến chỉ tiêu hiệu lực khi cấp phát tài nguyên mà giả định rằng tất cả tài nguyên đều được yêu cầu tức thì.
Bộ công cụ Nimbus (9) có khả năng triển khai virtual cluster với tốc độ “one-click” với những cấu hình mạng và phần mềm khác nhau, ngoại trừ việc cần phải ráp ảnh đĩa VM vào một cách thủ công mỗi khi triển khai vào một site mới (ví dụ server NFS có thể có địa chỉ khác, hay những dịch vụ trên mạng có thể mong muốn một chứng chỉ host số của một tổ chức cấp chứng chỉ uy tín cục bộ). Cấu hình tự động này được thực hiện bằng cách sử dụng bối cảnh một nhà môi giới bối cảnh hóa ảnh đĩa để làm việc cho một site cụ thể.
Fallenbeck (10) đã mở rộng trình lập lịch Sun Grid Engine để sử dụng chức năng lưu/phục hồi VM của Xen, cho phép bắt đầu những công việc lớn song song sớm hơn bằng cách tạm treo những VM chạy theo kỳ và phục hồi lại chúng sau khi hoàn thành những công việc đó. Còn Emeneker (11) thì đã mở rộng trình lập lịch Moab để hỗ trợ chạy công việc trong VM, và khảo sát những chiến lược lưu trữ khác nhau để triển khai ảnh đĩa trong cluster nhanh hơn. Tuy nhiên, hai cách đó sử dụng VM chỉ để hỗ trợ thực thi các công việc best-effort, không lập lịch cho việc truyền ảnh đĩa một cách riêng biệt; hơn nữa, trình lập lịch Moab đã không tích hợp việc lưu trữ thông tin vào những quyết định lập lịch.
Walters (12) đã đề xuất một trình lập lịch coi VM là trung tâm gọi là UBIS. Trình lập lịch này có khả năng lập lịch cho cả hai loại công việc khối truyền thống và công việc tương tác có độ ưu tiên cao bằng cách tận dụng khả năng tạm
treo/phục hồi của VM để chiếm đóng những công việc khối đang chạy và cung cấp yêu cầu sắp đến cho những công việc tương tác. Trình lập lịch UBIS không chỉ hỗ trợ loại công việc tương tác dễ dàng mà còn cung cấp những cải thiện đáng kể (đến 500%) trong việc tận dụng tài nguyên và thời gian đáp ứng cho loại công việc khối. Tuy nhiên UBIS không hỗ trợ loại tài nguyên advance reservation, thay đó tập trung vào hỗ trợ loại công việc tương tác với những yêu cầu tài nguyên gần như là tức thì (loại yêu cầu hoàn toàn cho phép UBIS chiếm đóng khi có yêu cầu loại công việc tương tác). Việc hỗ trợ advance reservation theo cách đảm bảo thời gian bắt đầu phải mô hình chi phí sử dụng và lập lịch cho những thao tác chiếm lấp hoàn thành trước khi bắt đầu đặt chỗ.
Những nhóm khác cũng nghiên cứu nhiều thách thức mới về triển khai và chạy một virtual cluster, bao gồm cả mạng ảo và load cân bằng giữa nhiều cluster vật lý (VIOLIN/VioCluster (13) (14), cấu hình tự động và tạo ra VM (InVIGO (15)và VMPlants (16)), và sự liên lạc giữa trình lập lịch virtual cluster và trình lập lịch cục bộ chạy trong một virtual cluster (Maestro-trình lập lịch 2 cấp của virtual cluster (17)). Tuy nhiên, các nhóm đó không khảo sát được số công việc phối hợp yêu cầu best-effort và advance reservation, và cũng không lập lịch được tổng chi phí triển khai VM một cách riêng biệt.
Tóm lại, những giải pháp ở trên dùng máy ảo để đạt hiệu quả cao đã đáp ứng được mục tiêu 2 (MT2) hay cao hơn nữa là mục tiêu 4 (MT4). Tuy nhiên, tất cả đều hướng đến cấp phát tài nguyên cho loại công việc khối (không cấp cung cấp khả năng về cấp phát tổng quát ở MT1), và tập trung vào trường hợp có hiệu lực đơn lẻ (hầu hết là thực thi khối công việc trên một virtual cluster, ngăn cản khả năng đạt được MT3), ngoại trừ Walter đã có cân nhắc đến số công việc phối hợp cả công việc khối và công việc tương tác với những yêu cầu có hiệu lực gần như là tức thì. Với mức MT4 thì chỉ có Nishimura và Yamasaki có thể mô hình và lập lịch được tổng chi phí triển khai VM, trong khi các nhóm khác chỉ là giả định chi phí này không tồn tại (bằng cách giả định các ảnh đĩa VM đã được triển khai trước) hoặc có thể cho qua.