The Distributed Service Management Toolkit ("DSMT") provides the framework and tools to install, monitor and control a distributed application on PlanetLab. It uses the PsEPR eventing service to move status messages and commands between instances of an application and to monitor it's installation and operation.
DSMT does not solve all the problems of control of a distributed application. Deciding where to locate the application or how to recover from a sudden increase in application demand needs application specific knowledege. DSMT provides some simple solutions but also provides the structure for adding solutions for the specific application.
DSMT is focused on creating and managing distributed, long running services with particular focus on decentralized operation. Additionally, people who have built long running, fault resilient services have had to invest large amounts of their effort to build status, monitoring and repair of their services.
DSMT provides:
- tools that enable new users to quickly get their applications running on PlanetLab
- a framework and initial tools for deployment and management;
- libraries and command for connecting an application to PlanetLab slice management, resource allocation, management and control;
- Libraries and commands for monitoring and controlling the distributed application or service.
In particular, DSMT provides the following items:
- PsEPR: Event service for location independent, loosely-bound application command and control;
- DSMTC: a command line interface to slice creation and application installation.
- Container Manager: A resource manager who creates and monitors PlanetLab sliver application containers;
- Deployment agent: An application installation service and monitoring component;
- DSMTViewer: A visualization and reporting system for monitoring and controlling the application
This toolkit has to straddle several conflicting goals: to provide a complete startup kit for users while at the same time not proscribing a solution or building a non-extensible, monolithic deployment application. It does this by creating a simple solution for the overall problem built from smaller, reusable components.
There are some projects to develop execution environment provisioning and application deployment tools (these are discussed in the PlanetLab Deployment Comparison section. DSMT focuses more on the application needs and the lifetime management of the application rather than just the get-it-there-and-run-it problem that is addressed in part by these tools.
The toolkit is geared to loosely-coupled, long lasting, distributed applications. This means applications that consist of many instances of it that runs in different virtual machines on different computers scattered around the planet. In practical terms, this means that the application must choose PlanetLab nodes to run on, install itself on those nodes and then operate in the ever changing resource environment that is the Internet.
DSMT promotes a distributed application that is loosely-coupled. This means that the separate instances of the application do not tightly bind to each other with either tight state synchrony requirements or required stimulus/response handshakes.
Consider the organs in your body the pancreas does not make a call to the liver for something to happen and wait for an ACK. Instead, the pancreas puts out messages in the bloodstream staying things are this way. The liver is listening to the blood stream and it hears the pancreass report. The liver starts to do things differently and it eventually puts messages in the blood stream as a consequence if its actions. Any organ in the body can hear the liver but they dont necessarily know the message if from the liver but they do know if the message they see requires their action.
This is similar to chalk board or bus architectures but, as applied to application design, it means that instances of an application dont talk directly to each other. Instead, each instance evaluates the environment (which includes messages from the other instances) and decides on individual, necessary operations.
Another dimension of loosely-coupled operation is demonstrated in the design of most multi-tier'ed web server solutions. It is now general practice to not tightly couple the layers (by, for instance, using a call/return type link to move control through the tiers) but to loosely-couple the layers with message queues between them with "state-less" linkage.
DSMT provides tools for this type of application by providing a loosely-coupled command and control messaging system and tools for managing distributed state. In particular, a service named the Planetary Scale Event Propagation and Routing (PsEPR pronounced pepper) provides an event transport service moves small, XML event messages between different components of the application.
Using PsEPR, application components emit PsEPR events stating their intentions, wishes and status. Other components of the application receive these events and change their operation based on the distributed state of the other components.
Consider a service that is made up of 10 instances. Each of these instances can perform the operation of the whole service but, since there are 10, the application can quickly handle requests from different parts of the world, can survive the crash of one or more hosting computers and can adapt to changing resource availability.
more stuff about how to build applications
The client is built from several different layers of control. First a manager for the container -- the virtual machine or the 'sliver' in PlanetLab terminology. Within the container, a deployment agent is installed. This third component, the deployment agent, manages the installation and running of the application.
Each of these three components are installed on the client and there is, at least conceptually, a components that monitors the installation of the component. These installation monitors report the installation progress with status messages.
This organization is shown in the following diagram.
To be precise, this is merely a conceptual structure. The status reporting will look like it comes from a structure like this, but, for instance, the bottom most installation monitor cannot output the 'request' event because the client container has not been created yet. These details, though, should only be a concern to framework implementers.
Each of the install monitors in the
client, which are monitoring the installation of
the components above them, output status messages
that report the state of the installation of the
component above.
A components goes through the following states as it is installed:
- requested:
- instantiated:
- initialized:
- running:
- failed:
- terminated:
- undefined:
Referring to the client layer's diagram, it was described how the install monitors each monitor the installation of the component above them. Once that component is installed and running, the next component above is installed and the install monitor tracks the status of that installation.
Since each of the install monitors output
org.dsmt.component.slice-mgr)
then there will be messages about the installation of
the deployment agent
(messages from org.dsmt.component.slice-bootstrap)
then messages about the installation of the application
itself
(messages from
org.dsmt.component.deployment-agent)
.
Since the container manager is also outputing messages about what it thinks of the status of the container installation, a complex series of messages are available to display the state of the application installation.
The following table lists all the
| Event | Description |
|---|
There are several packages that assist in the deployment and operation of applications on PlanetLab. This table is a feature comparison of the major packages. This does not compare some of the command line toolsets like pssh, ...
| appmanger | stork | plush | emulab | pldeploy | DSMT | |
|---|---|---|---|---|---|---|
| allocates nodes [1] | . | . | . | . | . | . |
| selects nodes [2] | . | . | . | . | . | . |
| changes | . | . | . | . | . | . |
| centralized control | . | . | . | . | . | . |