Changes between Version 27 and Version 28 of main_old

Timestamp:

05/12/11 09:23:46 (14 years ago)

Author:

bartek

Comment:

--

main_old

@@ -8 +8 @@
 In a nutshell, the !QosCosGrid middleware consists of two logical levels: grid domain and administrative domain. Grid-level services control, schedule and generally supervise the execution of end-users applications, which are spread between independent administrative domains. The administrative domain represents a single resource provider (e.g. HPC or datacenter) participating in a certain Grid or Cloud environment by sharing its computational resources, e.g. computing clusters, with both local and external end-users. The logical separation of administrative domains corresponds with the fact that they are possessed by different institutions or resource owners. Each institution contributes its resources for the benefit of the entire Grid or Cloud, while controlling its own administrative domain and own resource allocation/sharing policies. 
 
-The key component of every administrative domain in !QosCosGrid is the QCG BES/AR service, which gives the 
+The key component of every administrative domain in !QosCosGrid is the [[QCG_BES|QCG BES/AR service]], which gives the 
 remote access to queuing systems resources. QCG BES/AR supports advance reservations, parallel execution environments - OpenMPI, !ProActive and MUSCLE with coordinators responsible for synchronization of cross-cluster executions and Data Movement services for managing input and output data. The another relevant service at the administrative domain is in charge of notification mechanism and it is called QCG Notification. These services are tightly integrated and connected to the Grid-level services. The critical service on this level is QCG Broker, that is a meta-scheduling framework controlling executions of applicaitons on the top of queuing systems via Smoa Computing services. !QosCosGrid architecture is depicted in the figure presented below. For more information see /Link do sekcji/