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 tố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 q 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, tồ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. Ngồ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 ngun 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ỗ hồ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ự đố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ợ hồn tồn trong hệ thống dựa trên kế hoạch. Hơn nữa, mỗi khi có u cầu mới, tồ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 ngun 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.