What is
Istrice ? In a nutshell, it is
a system builds to allow a parallel and
remote compilation of projects of any size. The typical scenario is
that, whenever you have to compile a project, you run "make" and
then you get a long coffee! We have to say as well that the host where
the compilation is running are usually high loaded and hence not many
resources are free for other tasks.Istrice addresses this problem
allowing a host to demand the compilation to a set of remote hosts on
the base of the choices got by a server that represents those hosts.
The key concepts of ISTRICE
are: simple,dynamic, reconfigurable,powerful and parallelization.
Ok, many words but how does it works really. Let's see thus the
architecture of the Istrice project:
The logical
units represented in the above figure are:
| MS |
Master
Server
|
it
is the decisional unit of only ONE domain. It does not get any file to
be compiled by itself but it decides the registered Second Layer Server
(SLS, see below) to demand a compilation on the base of an algorithm
that distributes the load due to the Client requests |
| SLS |
Second
Layer Server |
it
plays the central role for compiling the source files on behalf of an
Istrice Client (IC, see the following description). It receives the
source from the Client and, after having compiled it, it returns the .o
just produced |
| IC |
Istrice
Client |
its
preferred sentence is: “why should I do anything, if someone else can
do it for me?” Actually the Istrice Client contacts the MS it is
registered to, in order to know which SLS can compile its code. After
that, the sole task it performs is to contact the indicated SLS and to
send it the source to compile |
Two other
important concepts must be pointed out. First of all, the Domain
concept: a domain is a group of units that are all registered to a MS
that defines the domain. Some units belong to a domain to get its
source
files compiled (that is the ICs). We can call this sub-domain as Client
Domain. The counterpart is the set of units that are registered to
the MS in order to offer their services to compile the IC source files.
We can call this complementary sub-domain as Server Domain.
This implies
that there is a correspondence one-2-one between a MS and its
controlled
Domain.
At a "physical"
point of view these logical units can live together within the same
station (e.g. a station can be the client of the jth domain and the
Master Server of the ith domain). The picture below figures out a
possible scenario:
Does it seem a
little mess? Maybe at a first sight but if each domain is considered
singularly the scenario is simple enough (as we previously said). For
shake of clearness, have a look to the Istrice configuration pages.
Seeing the
Istrice architecture, we can justify our assertion that Istrice is dynamic
and reconfigurable. In fact, any host can unregister itself to
the belonged domain or can register to one or more domain either as SLS
or as IC at any time, increasing the resources available to that
domain.
Furthermore it can build up a new domain launching a new MS instance.
Powerful
and parallelization: this is true because each IC has at its
disposal a whole domain of SLSs for distributing the compilation. To
optimise this procedure, the MS manages the available resources by
running an algorithm of Resource Allocation Control (RAC - see below).
Now have a
look behind the scene of Istrice. How can all the Istrice units
communicate among them? CORBA is the answer. By the way, Istrice uses
OmniORB as the preferred implementation of ORB. Check out the pros and
cons of using OnmiORB here (omniORB).
Furthermore,
for configure the main characteristics of MS, SLS and IC we have
employed configuration files formatted in XML. XML schemas grant the
correctness of those files. To accomplish to this jobs, Istrice uses
libxml2. Follow this link( libxml2) to have
more
information about.
Last but not
the least, a short overview on the algorithms that are at the base of
the RAC of the MS.
RAC is an
open-loop system as shown in the figure below:
This means the
RAC gets its decision scanning the SLS status list that contains the
most recent state of each SLS of its domain. This list is periodically
updated directly by SLSs that send their information to the MS which,
in
turn, inserts them into the list.
The algorithm
employed by the RAC is chosen by the user at the initialisation of the
MS. The possible algorithms are:
| Load
Balanced |
it
tries to distribute the IC requests in order to maintain the load
balanced among all the SLSs which belong to the domain |
| Max
Load |
it
assigns all the incoming requests to the same SLS till it becomes full |
| Task
Balanced |
same
as Load Balanced but it operates on the task not on the load |
| Max
Tasks |
same
as Max Load but it operates on the task not on the load |
| Tasks
Weigh |
|
