Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Grid Economics
Central to the idea of a computing grid is the set of services that coordinates access and use of the grid by providing facilities such as lookup and discovery of available resources, security, and transaction management. The overall ecosystem of resource selection, allocation, control, and payment is referred to as grid economics.
Grids can be thought of as a sort of marketplace that brings users (service consumers) and service providers together for the purpose of providing transparent access to a collection of heterogeneous computing resources. This marketplace is supported by publicly defined contracts that describe the qualities of the services, as well as how to invoke the services.
Because of the dynamic nature and heterogeneity of a grid, traditional means for allocating and charging for resources are not sufficient. Local priority rules, policies, and budgeting will not fit or scale well in a grid environment. For example, in a locally administered organization, demand needs can be more easily forecasted and measured. In addition, these needs might remain relatively constant over time. Comparatively, in a grid environment, demand might be sporadic and uneven. Demand for resources might be influenced by nontraditional and difficult-to-predict factors due to the heterogeneous and dispersed user population. Furthermore, negotiating the use of a service or resource, and the QoS they provide can be real-time, which will require unambiguous public contracts that support and guarantee various levels of QoS. This is much different from static, document-centric negotiations that generally stop at promising best efforts in organizations today.
In several grid implementations, the binding of service consumers to service providers based on user-defined QoS thresholds occurs via a resource broker or scheduler (check out vGrADS or Nimrod/G). These systems rely on either centralized or distributed schedulers that coordinate the dispatching of jobs or service requests to service providers. Conversely, Jini's JavaSpaces can, for some types of problems, replace the scheduler component with a space or a sort of blackboard that allows for sharing of data and parceling of work without direct knowledge of or communication between nodes.