6. http://gridengine.sunsource.net/
4.3.1.Cung cấp advancereservation trên trung tâm dữ liệu:
Mặc dù có thể lập lịch cho advance reservation cùng với best-effort nhưng những advance reservation này lại mắc phải một vài hạn chế. Trước tiên là phụ thuộc vào mô hình quản lý công việc - không đáp ứng được các mục tiêu đã nêu. Và đặc biệt, khi khách hàng yêu cầu loại advance reservation trên hệ thống job- based thì sẽ không có quyền truy cập trực tiếp vào tài nguyên mà thay vào đó chỉ được phép submit các công việc lên đó thôi. Ví dụ PBS Pro đã tạo ra một hàng đợi gồm các tài nguyên đã đặt chỗ để có thể đảm bảo rằng những công việc submit lên đó chắc chắn sẽ được thực hiện không sớm thì muộn (giả định rằng các quyền đã được phê duyệt). Mặc khác Maui và Moab lại cho phép người dùng chỉ định rõ những công việc sẽ sử dụng tài nguyên đã đặt chỗ (nếu người đó có quyền). Người dùng không thể trực tiếp login vào tài nguyên đã đặt chỗ ngoại trừ phải thông qua công việc tương tác, nhưng cũng không thể truy cập tài nguyên một cách tự do được (như không được truy cập root), hoặc cũng có thể sử dụng ad-hoc để yêu cầu quyền login từ người quản trị cluster trong thời gian đặt chỗ.
Hơn nữa, vấn đề tận dụng tài nguyên khi hỗ trợ advance reservation (27), (28), (8) cũng cần phải giải quyết do phải bỏ trống tài nguyên trước khi đặt chỗ bắt đầu. Không giống như đặt chỗ trước trong thuật toán backfilling, điểm bắt đầu được xác định dựa trên cơ sở best-effort, còn advance reservation lại giới thiệu kỹ thuật roadblock. Do đó, trình lập lịch truyền thống không thể kết hợp best-effort và advance reservation hiệu quả được (MT3).
Tuy nhiên, việc hỗ trợ advance reservation có thể đạt hiệu quả hơn khi dùng trình lập lịch có khả năng chiếm đóng các công việc chạy lúc bắt đầu đặt chỗ và phục hồi lại các công việc đó khi quá trình kết thúc. Ta cũng có thể sử dụng kỹ thuật chiếm đóng để chạy các công việc lớn song song trước trong trường hợp khẩn cấp, khi đó phải cấp phát tài nguyên theo một thông cáo ngắn và các công việc cho tài nguyên đó phải đảm bảo đã sẵn sàng. Kỹ thuật chiếm đóng có thể thay thế bằng cách hủy công việc đang chạy, toàn bộ trạng thái của công việc đó sẽ lưu vào đĩa và cho phép phục hồi tại điểm gần nhất. Ngoài ra, một vài trình lập lịch còn hỗ trợ di dời công việc, cho phép công việc đã được lưu vết khởi động trên một tài nguyên khác thích hợp thay vì phải đợi cho đến khi công việc đang chiếm đóng hay việc đặt chỗ hoàn tất.
Tuy nhiên, mặc dù các trình lập lịch hiện đại hiện nay ít nhất cũng có hỗ trợ chiếm đóng dựa trên dữ liệu lưu vết, nhưng vẫn đòi hỏi các công việc cũng phải có khả năng tự. Một ứng dụng có thể thêm chức năng lư vết vào một cách tường minh (lưu vết ở mức độ ứng dụng hoặc thư viện) hoặc dùng lưu vết ở cấp độ hệ điều hành (như hệ điều hành Cray, IRIX, hay các phiên bản của Linux có sử dụng BLCR (29)) sẽ lưu vết một xử lý nào đó mà không phải thay đổi ứng dụng hay kết nối lại với thư viện lưu vết. Tuy nhiên, hệ điều hành cũng cần phải có khả năng này.
Do đó, một trình lập lịch công việc có khả năng chiếm đóng hay di dời dựa trên kỹ thuật checkpoint thì có thể đáp ứng được MT3 bằng cách checkpoint các công việc trước khi bắt đầu một advance reservation giúp giảm tối thiểu va chạm khi lập lịch. Tuy nhiên, phương pháp checkpoint ở cấp độ ứng dụng hay thư viện lại gây rắc rối cho người dùng ở chỗ phải sửa đổi ứng dụng để tạo khả năng checkpoint. Mặc khác, kỹ thuật checkpoint cấp độ hệ điều hành là lựa chọn hấp
dẫn hơn nhưng vẫn còn lạm dụng sự hạn chế phần mềm nào đó đối với khách hàng sử dụng tài nguyên. Những hệ thống như Cray và IRIX vẫn còn yêu cầu phải biên dịch các ứng dụng theo kiến trúc tương ứng với hệ thống, cho phép lease hỗ trợ một phần nhỏ ứng dụng đó hoặc là yêu cầu các ứng dụng hiện tại phải theo hướng kiến trúc này. Do số lượng cluster và ứng dụng theo cấu trúc x86 rất lớn nên việc theo hướng này là một hạn chế rất lớn trong việc hỗ trợ cho thuê. Mặc dù dự án BLCR có cung cấp nhân Linux x86 có hỗ trợ lưu vết phần mềm nhưng vẫn còn mắc phải một vài hạn chế như không thể lưu vết đường truyền mạng hiệu quả, và cũng không lưu vết ứng dụng MPI được trừ khi ứng dụng đó được kết nối với thư viện MPI có hỗ trợ BLCR.
Ngoài ra, Nurmi (30) đã giới thiệu một phương pháp khác có thể hỗ trợ advance reservation gọi là “Hàng đợi dành cho advance reservation ảo” (VARQ - Virtual Advance Reservations for Queues). Đây là phương pháp che advance reservation với trình lập lịch công việc truyền thống bằng cách dự đoán trước thời gian một công việc sẽ đợi trong hàng đợi lập lịch, và submit một công việc (của advance reservation) tại thời điểm đó. Như vậy khả năng công việc đó có thể chạy ngay tại thời điểm bắt đầu đặt chỗ là rất cao. Khi không thể thực hiện đặt chỗ thực tế nào, các công việc VARQ có thể chạy trình lập lịch công việc truyền thống không phân biệt best-effort và VARQ. Mặc dù đặt chỗ ảo là phương pháp thích hợp để thực thi trong thực tế (vì không cần phải thay đổi trình lập lịch hiện thời) nhưng cuối cùng vẫn còn phụ thuộc vào mô hình quản lý công việc (MT1).
Hovestadt (31), (32) thì lại đề xuất phương pháp dựa trên kế hoạch (gần giống với xếp hàng đợi), có nghĩa là yêu cầu được đặt chỗ tức thì thay vì phải đợi trong hàng đợi. Do đó, advance reservation được hỗ trợ hoàn toàn trong hệ thống dựa trên kế hoạch. Hơn nữa, mỗi khi có yêu cầu mới, toàn bộ trình lập lịch sẽ kiểm tra lại để sử dụng tài nguyên tốt hơn. Ví dụ một advance reservation sẽ được chấp nhận mà không cần chiếm đóng, bởi vì các công việc đã được đưa trước vào tài nguyên này cũng có thể gán vào tài nguyên khác (giả sử công việc đó chưa chạy). Mặc dù phương pháp này có triển vọng, và có thể cho rằng chất
lượng tốt hơn phương pháp dựa trên hàng đợi, hệ thống này vẫn chưa đưa ra được những kết quả thuyết phục để đánh giá với hệ thống dựa trên hàng đợi hay là hệ thống có khả năng lưu vết phần mềm.