Stork Architecture
The Stork architecture, in essence, depends on three tiers. The
repository is Stork's central package warehouse. All packages available
for download through the Stork system need to be first uploaded to the repository.
The repository is located at
https://stork-repository.cs.arizona.edu.
From this site, you can upload packages, and you can also see a list of the packages
that others have uploaded. Note that this is also the repository that holds config
files, pacman files and keyfiles. The following diagrams demonstrate that Stork's repository system works similar to other
repositories.
Stork's architecture consists, on the basic level, of multiple nodes (each of which may have many
virtual machines) in contact with a central package repository.
When a virtual machine requests a package for installation, the request goes to the nest. If the nest has not already downloaded the file, it retrieves it from the repository. The TPFile is checked
to insure that the package is trusted.
Finally, the repository delivers the package to the nest, which unpacks the package and shares it securely with the virtual machine.
The nest is a virtual machine on each node that Stork uses to manage package downloads and installation.
Normally, to install packages on multiple virtual machines, each virtual machine would need to separately
download and install the packages even when these virtual machines are on the same physical node. For small, trivial packages, this may be adequate,
but for large, complex packages over a large number of virtual machines, this can be a nuisance.
The nest solves this problem by requesting and downloading the package a single time.
The nest then manages sharing between virtual machines, drastically decreasing the time for
installation of packages. The following shows an example of how Stork manages file sharing.
A Planet-Lab node, when using stork, is made up of multiple virtual machines (called slices) and a central nest, through which
all package requests go through. In this case, slice 1 makes a request for a package that has never been
installed on the node. The nest processes the query and makes a request to the Stork repository.
The package is delivered from the repository to the nest and the nest securely shares the package with the requesting slice.
Afterward, slice 2 requests the same package. The nest sees that the same package has already been downloaded and securely shares the same files with slice 2 as well.
The nodes can either be managed separately, or be organized into
groups by the use of Pacman. This allows you to
have greater power over which nodes recieve which packages. A simple example can be seen in the following:
In this figure, three separate nodes request a package installation, and the package is installed
on each node. Typically either the administrator would need to manually configure each node or
maintain a separate repository branch for each type of node that needs a separate configuration.
In this figure, we choose to group the first two nodes together using pacman. We can, as before, request the package
to be installed individually from each node. However, to streamline the process, we can request that the package
be installed on the group. Each node in the group will recieve the package just as before; however, installing
the package this way requires less manual work. It is easy to see that, if the package needs to be installed
on 100 different nodes, it is much more efficient to use pacman grouping.
Home Top
|
