X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/gpc2011.git/blobdiff_plain/db3fd661ef153080f851664602a43ab45755cc34..386389681aed0efc9e9a396a4b09e2ab55a063f4:/xwch.tex diff --git a/xwch.tex b/xwch.tex index d38b719..f3230e3 100644 --- a/xwch.tex +++ b/xwch.tex @@ -1,53 +1,74 @@ -%----------------------------------------------------------------------------------------------------------------------------- +%------------------------------------ % The XtremWeb-CH environment -%----------------------------------------------------------------------------------------------------------------------------- -XtremWeb-CH (XWCH) is a volunteer computing inspired, large-scale computing platform for distributed applications. It consist of three -components: one coordinator, a set of workers and at least one warehouse. Client programs utilise these components. +%------------------------------------ +XtremWeb-CH (XWCH) is a volunteer computing inspired, large-scale +computing platform for distributed applications. It consists of three +components: one coordinator, a set of workers and at least one +warehouse. Client programs use these components. -The coordinator is the main component of the XWCH platform. It controls user access and schedules jobs to workers. It provides a web -interface for managing jobs and users, and a set of web services. These are user service and worker/warehouse services implemented using -WSDL \cite{WebServ2002}. +The coordinator is the main component of the XWCH platform. It +controls user access and schedules jobs to workers. It provides a web +interface for managing jobs and users, and a set of web +services. These are user service and worker/warehouse services +implemented using WSDL (Web Service Description Language) \cite{WebServ2002}, that simplifies +client development for languages that support it (and most popular programming languages do). -A worker is a Java daemon that runs on the user machine. Assumed to be volatile, the workers reports periodically -themselves to the coordinator, accept jobs, retrieve input, compute jobs, and store the results of the computation on warehouses. If the -coordinator does not receive a signal from a worker, it will simply remove it from the scheduling list, and if a job had been assigned to that -worker, it will be re-assigned to another one. A schema of the architecture is shown in Figure 4. +A worker is a Java daemon that runs on the user machine. Assumed to be +volatile, the workers report periodically themselves to the +coordinator, accept jobs, retrieve input, compute jobs, and store the +results of the computation on warehouses. If the coordinator does not +receive a signal from a worker, it will simply remove it from the +scheduling list, and if a job had been assigned to that worker, it +will be re-assigned to another one. A schema of the architecture is +shown in Figure \ref{xwch}. -\begin{figure}[hb] +\begin{figure}[htp] +\label{xwch} \begin{centering} \includegraphics [scale=0.2]{figures/xwcharchitecture.pdf} - \caption{The XWCH Architecture} - % \label{Figure 4: The XWCH Architecture} + \caption{The XtremWeb-CH architecture} \end{centering} \end{figure} -A warehouse is a file server that acts as a data storage system for workers and client programs. -Workers may not necessarily be able to communicate directly with each other, due to firewalls and NAT subnetworks. -For these reasons, warehouses are used as intermediaries to exchange, store and retrieve data. +A warehouse is a file server that acts as a data storage system for +workers and client programs. Workers may not necessarily be able to +communicate directly with each others, due to firewalls and NAT +sub-networks. For these reasons, warehouses are used as intermediaries +to exchange, store and retrieve data. -Job submission is done by a client program which is written using a flexible API, available for Java and C/C++ programs. The client program -runs on a “client node” and calls the user services to submit jobs (Figure 1, (1)). The main flexibility provided by the use of this -architecture is to control and generate dynamically jobs especially when their number can not be known in advance. Communications between -the coordinator and the workers are always initiated by the workers following a pull model (Figure 1, (2)): +Job submission is done by a client program which is written using a +flexible API, available for Java and C/C++ programs. The client +program runs on a “client node” and calls the user services to submit +jobs (Figure \ref{xwch}, (1)). The main flexibility provided by the use of this +architecture is to control and generate dynamically jobs especially +when their number cannot be known in advance. Communications between +the coordinator and the workers are always initiated by the workers +following a pull model (Figure \ref{xwch}, (2)): \begin{itemize} - \item Workers receive jobs (Figure 1, (3)) only if they send a “work request” signal. - \item When a worker finishes its job, it stores its output file on warehouse and sends a “work result” signal to the coordinator. - \item During its execution, a worker (respectively warehouse) periodically sends “work alive” to the worker service (respectively warehouse service) -to report itself to the coordinator. +\item Workers receive jobs (Figure \ref{xwch}, (3)) only if they send a “work + request” signal; +\item When a worker finishes its job, it stores its output file on + a warehouse and sends a “work result” signal to the coordinator; +\item During its execution, a worker (respectively warehouse) + periodically sends “work alive” to the worker service (respectively + warehouse service) to report itself to the coordinator. \end{itemize} -As a whole, XWCH is easy to install, maintain ans use. Its components are programmed mainly using Java, and their process memory sizes in a typical 32-bit Linux computer are shown below. + +As a whole, XWCH is easy to install, maintain and use. Its components +are programmed mainly using Java, and their process memory sizes in a +typical 32-bit GNU/Linux computer are: \begin{itemize} - \item Coordinator 190 MB including the Glassfish Java container - \item Worker 40 MB - \item Warehouse 80 MB + \item Coordinator 190 MB including the Glassfish Java container; + \item Worker 40 MB; + \item Warehouse 80 MB. \end{itemize} -Experiments, presented in \cite{ccgridpaper}, shows that the performance of XWCH is comparable with Condor \cite{Condor1988}, another -non-intrusive computing system that has similar functionality but is somewhat more difficult to install . - -The main characteristics of the new version of XWCH, compared to its previous versions, are: dynamic job generation, flexible data -sharing (data replication) and persistent jobs. These features are presented in \cite{VEZGrid} and will not be detailed in this paper. - - - +Experiments presented in \cite{ccgridpaper} show that the +performance of XWCH is comparable with Condor \cite{Condor1988}, +another non-intrusive computing system that has similar functionality +but is somewhat more difficult to install. +The main characteristics of the new version of XWCH, compared to +previous ones, are: dynamic job generation, flexible data sharing +(data replication) and persistent jobs. These features are presented +in \cite{VEZGrid} and will not be detailed in this paper.