From Service Replica to Service Grid

1
From Service Replica to Service Grid

• Yuqi Bai, Liping Di, Aijun Chen, Yaxing Wei, Yang
  Liu
• Laboratory for Advanced Information Technology
  and Standards (LAITS)
• George Mason University
• 6301 Ivy Lane, Suite 620
• Greenbelt, MD 20770
• Yuqi Bai, Ph.D.
• ybai1_at_gmu.edu

2
Background

• Motivation
• While developing Geo-Science grid applications we
  observed advantages of moving data across
  multiple grid nodes and placing services near
  demand
• Especially useful for data-intensive applications
  
• Transforming high volume data always takes a long
  time, while placing a new service onsite will
  dramatically improve overall performance for a
  given task.
• If a deployed Grid Service can be dynamically
  re-deployed on different grid nodes, a new
  computing mechanism will appear.
• The Grid infrastructure will handle all of the
  copies of services and is responsible for their
  full life cycles.
• We name this type of grid as Service Grid and
  each copy of a service can be named a Service
  Replica.

3
A Vision for Service Grid

• Service Grid is
• a specialized grid computing environment where
  grid services can be automatically re-deployed
  (Service Replica) across multiple affiliated grid
  nodes to bring a high-availability computing
  infrastructure.
• Service Replica is
• a replica/instance of a grid service that is
  generated automatically by the grid computing
  facilities. All service replicas perform the
  same functions. The only difference among them is
  the access binding address.

4
Data VS. Service

• Differences between data and services
• Isolation
• Data is isolated. As long as it can be archived
  on a Grid node, it can be saved there as a
  replica.
• Service is not isolated. A service always needs
  a Runtime Context. It can not function well
  without the support from the platform (Software
  and Hardware). The same code may not work on a
  different environment.
• Transformation
• Data can be easily transformed, Most
  transformation can be made using underlying OS
  commands
• Services cannot easily be transformed. Some or
  most Services need to be configured. Most
  configuration can be done only with some kind of
  high level support, such as Container
• Conclusion Identifying the candidate Grid nodes
  appropriate to Grid Service Modules plays a key
  role in managing Service Replicas

5
Issues to Be Dealt With

• Service Level
• SLQ1 What kind of metainformation should a
  service maintain?
• SLQ2 How can this information be organized in
  and expressed by the service?
• SLQ3 How can this information be accessed after
  a service has been deployed?
• SLQ4 What is the CRUD of the information after a
  service has been deployed?
• Grid Environment Level
• GLQ1 How can the situation be evaluated and the
  need to generate Service Replicas recognized?
• GLQ2 What kind of strategies should be used to
  determine the grid node that provides a platform
  on which a particular Service can be run?
• GLQ3 How are the available Service Replicas for
  a particular Grid Service discovered?
• GLQ4 How is the decision on when and how to
  un-deploy Service Replicas managed?
• Important Indirect Issue(s)
• E.g. Security

6
Proposed Solutions

• SLQ1 What kind of metainformation should a
  service maintain?
• All the runtime context information should be
  identified. It can be grouped into two
  categories
• Software, e.g.
• Application Level
• Application Container
• Software packages
• OS Level
• Hardware, e.g.
• CPU
• RAM

7
Proposed Solutions (Cont.)

• SLQ2 How can this information be organized in
  and expressed by the service?
• All Service Runtime Context information can be
  analyzed and expressed in XML Schema Files
• Each service may maintain a xml file to describe
  its particular runtime environment needs.
  Hereafter, Runtime Context Description (RCD)
  identifies this type of file.

8
Proposed Solutions (Cont.)

• SLQ3 How can this information be accessed after
  a service has been deployed?
• A service always provides its RCD file along with
  the other needed information to Grid Container
  the first time it is deployed
• After the first deployment, this Service is
  known in the whole Grid Environment
• This RCD file is kept in Grid Container until the
  service provider requests un-deployment of the
  Service.

9
Proposed Solutions (Cont.)

• SLQ4 SLQ4 What is the CRUD of the information
  after a service has been deployed?
• Given a service, the Grid environment may permit
  the service provider only to Read/ Update the
  RCD file without updating the Service code
• Note This RCD file does not contain any service
  function interface definition
• The RCD file is created in the first deployment
• The RCD file is deleted when the Service is
  requested to un-deploy.

10
Proposed Solutions (Cont.)

• GLQ1 How can the situation be evaluated and the
  need to generate Service Replicas recognized?
• Depends on the underlying grid computing
  facilities.
• Possible reasons/scenarios to generate new
  Service Replicas
• The Grid Node where the Service is hosted does
  not work well
• More Service Replicas can bring higher
  availability for high- demand grid services
• Adding new Service Replicas to a particular grid
  node can improve the overall performance for a
  task which involves several logical steps
  (Service Chaining)

11
Proposed Solutions (Cont.)

• GLQ2 What kind of strategies should be used to
  determine the grid node that provides a platform
  on which a particular Service can be run?
• Two logical steps
• ST1 Defining candidate grid nodes
• ST2 Selecting target grid node (s)
• ST1
• RCD information of a grid service is matched with
  all the affiliated grid nodes, which can yield
  candidate grid nodes
• ST2
• Depends on reason to generate new service
  replicas
• Task-oriented or management-oriented.

12
Proposed Solutions (Cont.)

• GLQ3 How are the available Service Replicas for
  a particular Grid Service discovered?
• A current tree-like structure of all available
  Service Replicas should be maintained by Grid
  computing facilities
• Following predefined strategies, the Grid
  environment can select the appropriate Service
  Replica to fulfill service request in runtime

13
Proposed Solutions (Cont.)

• GLQ4 How is the decision on when and how to
  un-deploy Service Replicas managed?
• Depends on the underlying grid computing
  facilities.
• Possible reasons/scenarios to un-deploy Service
  Replicas
• Low demand for grid services
• For Grid Nodes with high demand, un-deployment of
  some of the Service Replicas can lower the loads
  and improve the system performance
• Receipt of a Master Service un-deployment
  request all Service Replicas are un-deployed.

14
Conclusion

• The goal of this presentation is to introduce and
  comment on a new type of Grid infrastructure,
  named Service Grid, where Grid Services can be
  dynamically deployed and un-deployed
• Future work
• Define the requirements that a Service Grid must
  satisfy
• Define the components and APIs that will be
  required in its implementation
• Identify the enabling technologies
• Construct a reference implementation for this
  architecture so as to enable large-scale
  experimentation
• The hope is that the definition of such an
  architecture will accelerate progress on
  data-intensive computing by providing a new
  computing mechanism that places the computational
  resources, rather than data resources, near to
  the demand.