| | 222 | * Meta-scheduler最基本目的就是要能夠在分散式異質性且動態的環境中,透過跟底層local schedulers互動,做完善的資源選取與工作執行。GridWay屬於client side meta-scheduler,易於使得在廣大的Grid環境裡針對不同管理domain做大規模的資源共享,也提供了許多job 及resource方面的scheduling policies。而CSF4則是建立在GT4之上,運用了許多Grid services實作而成的,並且提供了plug-in scheduling protocol,讓使用者可以自訂scheduling policy,更支援藉由queueing service配置的economic scheduling。 |
| | 223 | * 對於GridWay和CSF4或許我也都還沒有玩的十分透徹,僅粗淺的玩一下,可能無法十分的精準分出究竟哪個好,這兩者都各有其優點特色在,不過也是有其仍需要在改進的部分,如在Job service 及Reservation service的部分他們就有些許的不同,GridWay 在針對特殊的平行程式可以做job migration,而CSF4則是僅能針對搭配特製的Resource Manager來做Suspend/Resume jobs,並且雖然CSF4堅稱它有特殊的Resource Reservation的功能,不過也是僅限於特製的Resource Manager,並不支援GRAM adapter。 |
| | 224 | * 而在丟工作方面,針對指定資源的部分,雖然GridWay沒有像CSF4可以直接指定要丟哪個cluster,在指令方面也不像CSF4來的這麼豐富,可以有一堆參數可以指定,但是卻也能使用原始的方法直接在job script裡指定local job manager的hostname,來丟到想丟的cluster。 |
| | 225 | * GridWay似乎要在Globus下的環境運作,因為它目前只支援GRAM,還未測試GridWay是否能在沒有Globus的環境下獨立運作,而我想或許直接運用已經包好了許多WS的CSF4,或許能有更好的應用發展,在未來要改寫其內容應該也會比較好結合,畢竟CSF4不僅支援了GRAM還有額外包裝的Resource manager的adapter(RM-LSF),也能再獨立製作其他RM adapter,不過也尚未測試其在沒有Globus的環境下要如何運作,可能都還需要改造,只是我在JAVA這方面真的不太有天份..XD |
