What is Sapphire?
Sapphire is a general-purpose distributed programming
platform that greatly simplifies the design and implementation of applications
spanning mobiles and clouds. The key concept of it is the separation of
application logic and deployment logic. It is also a new architecture that
support pluggable extensible deployment managers.
Motivation
Modern applications implement difficult distributed
deployment tasks. Application programmers must coordinate data and computation
across different nodes and platforms. They must hide performance limitation and
failure. And they must manage different programming environments and hardware
resources.
Architecture:
The system is a three-layer architecture. It contains
Sapphire application layer, deployment manager layer and deployment kernel
layer. OTS is the objects tracking system. The main architecture is showed in
the following picture:
1.
Sapphire application is
partitioned into sapphire objects, which run in a single address space with
RPC. The sapphire object can be executed anywhere and can be moved
transparently. It also provides a unit of distribution for deployment managers.
2.
Deployment kernel provides
best-effort distribution services, including sapphire object tracking, mobility
and replication. Making and routing RPC to sapphire objects. Managing,
distributing and running deployment managers.
3.
Deployment management layer
consist of deployment managers, which extends the functions and guarantees of
deployment kernel. Interpose on sapphire object events.
Deployment manager is the key part for this system and it consists of three components, which are
created, deployed and invoked by sapphire kernel. The three components are:
1.
Instance manager: it is
co-located with the sapphire object. And it is responsible callee-side tasks
2.
Proxy: co-located with
remote references. It is responsible for caller-side tasks.
3.
Coordinator: co-located
with fault-tolerant object tracking service. It is responsible for centralized
tasks.
How are instance manager, proxy and coordinator created by
deployment kernel?
The DK will first create Sapphire object and instance
manager first. Then it will create stubs which can call instance manager
through proxy using RPC. Every reference of sapphire object will go through
proxy. Then DK creates the coordinator.
Advantages:
1.
From the previous papers,
we know some methods to deploy application in cloud or edge servers. For
example, MAUI, CloudClone. However, they don’t not focus on how to separate
application into different objects and dispatch this objects to cloud.
2.
This paper give a clear
logic on how to separate application logic and deployment logic. This is a
little like Mesos or Yarn.
3.
DM layer is the key part
for this paper. And they implement several libraries for this layer and these
libraries benefit lots of applications.
Disadvantages & discussion:
1.
MAUI consider energy
efficiency. But this paper doesn’t mention this.
2.
If the application
programmers do not know what functionalities they will use at the beginning of
the project, how should they choose DM layer for each Sapphire object?
3.
Scalability. For example,
Mesos and Yarn can handle many simultaneous jobs in the same cluster, can this
system do the same thing? It this system can do, what is the max number of jobs
can be run simultaneously?
4.
Can this system handle SO
transportation fluctuation? If Nowadays, many resource managers are using
machine learning algorithms, such as Microsoft Apollo.
For D#1, you would pick or implement an energy conscious DM. Note sure what you mean by D#2. They don't address the issue of competing tasks/jobs across applications. D#4: how does this relate specifically to Sapphire?
ReplyDelete