Parent Directory
| 
Revision Log
Revision 1 - (view) (download) (as text)
| 1 : | mark | 1 | |
| 2 : | %%% Local Variables: | ||
| 3 : | %%% mode: latex | ||
| 4 : | %%% TeX-master: t | ||
| 5 : | %%% End: | ||
| 6 : | |||
| 7 : | % Introduction | ||
| 8 : | % Parallel archtectures | ||
| 9 : | % Network topologies | ||
| 10 : | % Linux Beowulf clusters | ||
| 11 : | % Parallel programming, the message passing interface | ||
| 12 : | % Performance metrics | ||
| 13 : | % Rocks installation | ||
| 14 : | % Rocks system administration | ||
| 15 : | % Job scheduling, SGE | ||
| 16 : | % Cluster benchmarking tools | ||
| 17 : | % Lab assignments | ||
| 18 : | |||
| 19 : | %% Author: T. M. Jonassen | ||
| 20 : | |||
| 21 : | \chapter{Beowulf Clusters} | ||
| 22 : | |||
| 23 : | \section{Introduction} | ||
| 24 : | |||
| 25 : | |||
| 26 : | This chapter will cover some aspects of what is known as \emph{high performance computing} (HPC). | ||
| 27 : | The main concern will be adminitrative, configuration and benchmarking tasks, but | ||
| 28 : | some basic background | ||
| 29 : | on parallel programming and parallel algorithm analysis is also covered. In earlier day | ||
| 30 : | on had to set up all clustering software from scratch, unless one bought a cluster solution | ||
| 31 : | from a company who had specialiced on clusters. With the succsesful development of Linux | ||
| 32 : | and open source solutions one now have ``Linux cluster distributions'' such as | ||
| 33 : | Rocks and Oscar, SuSE Linux also provide cluster solutions among others. | ||
| 34 : | |||
| 35 : | \section{Parallel archtectures} | ||
| 36 : | |||
| 37 : | In this section we will look into some types of parallel archtectures including different | ||
| 38 : | network topologies. The discussion here is quite general, but in the section on Linux | ||
| 39 : | Beowulf clusters we will be more specific on hardware setup. The section on Rocks | ||
| 40 : | installation is adapted to the lab setup at OUC. | ||
| 41 : | |||
| 42 : | \subsection{Flynn's taxonomy} | ||
| 43 : | |||
| 44 : | Flynn's taxonomy is a classification scheme for parallel computers based on whether the | ||
| 45 : | parallelism is exhibited in the instruction stream and/or in the data stream. This | ||
| 46 : | classification results in four main categories, SISD (single instruction single data), | ||
| 47 : | SIMD (single instruction multiple data), MISD (multiple instruction single data) and | ||
| 48 : | MIMD (multiple instruction multiple data). | ||
| 49 : | |||
| 50 : | |||
| 51 : | %%% FIG %%% | ||
| 52 : | |||
| 53 : | %% The figure should be centered!! How to do this by \epsfig? (I have brougt no documentation with me.) | ||
| 54 : | \begin{center} | ||
| 55 : | %%\begin{figure}[ht] | ||
| 56 : | \includegraphics[scale=0.5]{tmj-img/eps/flynn.eps} | ||
| 57 : | %%\caption{A schematic view of Flynn's taxonomy.} | ||
| 58 : | %%\end{figure} | ||
| 59 : | \end{center} | ||
| 60 : | |||
| 61 : | \subsection{Vector computers} | ||
| 62 : | |||
| 63 : | We will first clearify some standard terminology for parallel machines. A vector computer | ||
| 64 : | is a computer whose instruction set includes instructions for operations on vectors as well | ||
| 65 : | as scalars. There are basically two different ways to obtain this. One approach is to use a | ||
| 66 : | pipelined vector processor. This processor streams vectors from memory and piplined arithmetic | ||
| 67 : | units do the operations. Such architecture was used in the well known Cray-1 and in Cyber-205. | ||
| 68 : | |||
| 69 : | The other approach is to use a processor array. A processor array vector computer consists | ||
| 70 : | of a set of identical syncronized processing elements capable of simultaneous performing the | ||
| 71 : | same operation on different data. The processor array is controled by a front-end CPU. The | ||
| 72 : | processing elemnts are often simpler than regular CPUs, but each processing element often | ||
| 73 : | has it's own private memory. The motivation for such a construction was that the price of | ||
| 74 : | control units, as used in a standard CPU, was relatively high and that a large fraction | ||
| 75 : | of a scientific computations are data parallel. | ||
| 76 : | |||
| 77 : | %%% FIG %%% | ||
| 78 : | |||
| 79 : | However, there are several shortcommings of processor arrays: | ||
| 80 : | |||
| 81 : | \begin{itemize} | ||
| 82 : | \item Many problems are not strict data parallel, and do not run efficienly on a processor | ||
| 83 : | array architecture. | ||
| 84 : | |||
| 85 : | \item A processor array can only execute a single instruction at a time, so conditionally | ||
| 86 : | code causes a drop in efficiency, in particular, nested conditionally code is bad. | ||
| 87 : | |||
| 88 : | \item A processor array is a naturally single-user system, and is not easily modified | ||
| 89 : | into a multiuser system. | ||
| 90 : | |||
| 91 : | \item A processor array system does not scale well, that is, an array with a large number | ||
| 92 : | of processing elements needs very high bandwidth communication between the components in | ||
| 93 : | the system. | ||
| 94 : | |||
| 95 : | \item Processor arrays are buildt using custom VLSI and constructors of prosessor arrays | ||
| 96 : | can not use the improvements in performance and cost improvements of comodity CPU's done by | ||
| 97 : | big manufactures such as Intel. | ||
| 98 : | |||
| 99 : | \item One of the motivations for this type of architecture was the high cost of the control | ||
| 100 : | unit. This argument is no longer valid. | ||
| 101 : | \end{itemize} | ||
| 102 : | |||
| 103 : | For the reasons above, processor arrays are not considered an option for a general-purpose | ||
| 104 : | parallel computer, but only for special task parallel systems. | ||
| 105 : | |||
| 106 : | \subsection{Multiprocessors} | ||
| 107 : | |||
| 108 : | \section{Network topologies} | ||
| 109 : | |||
| 110 : | Processors in a parallel computer may communicate in two different ways, via a \emph{shared media} | ||
| 111 : | or via a \emph{switched media}. | ||
| 112 : | |||
| 113 : | |||
| 114 : | |||
| 115 : | \section{Linux Beowulf clusters} | ||
| 116 : | |||
| 117 : | %% From www.beowulf.org: | ||
| 118 : | |||
| 119 : | The website \texttt{www.beowulf.org} gives the following history of Linux Beowulf Clusters: | ||
| 120 : | |||
| 121 : | {\it | ||
| 122 : | In late 1993, Donald Becker and Thomas Sterling began sketching the outline of a commodity-based | ||
| 123 : | cluster system designed as a cost-effective alternative to large supercomputers. In early 1994, | ||
| 124 : | working at CESDIS under the sponsorship of the HPCC/ESS project, the Beowulf Project was started. | ||
| 125 : | |||
| 126 : | The initial prototype was a cluster computer consisting of 16 DX4 processors connected by channel | ||
| 127 : | bonded Ethernet. The machine was an instant success and their idea of providing COTS | ||
| 128 : | (Commodity Off The Shelf) based systems to satisfy specific computational requirements | ||
| 129 : | quickly spread through NASA and into the academic and research communities. | ||
| 130 : | |||
| 131 : | Some of the major accomplishments of the Beowulf Project will be chronicled below, but a | ||
| 132 : | non-technical measure of success is the observation that researchers within the High | ||
| 133 : | Performance Computer community now refer to such machines as "Beowulf Class Cluster | ||
| 134 : | Computers." Beowulf clusters are now recognized as genre within the HPC community. | ||
| 135 : | |||
| 136 : | The next few paragraphs will provide a brief history of the Beowulf Project and discussion | ||
| 137 : | of certain aspects or characteristics of the Project that appear to be key to its success. | ||
| 138 : | |||
| 139 : | The Center of Excellence in Space Data and Information Sciences (CESDIS) is a division | ||
| 140 : | of the non-profit University Space Research Association (USRA). CESDIS is located at the | ||
| 141 : | Goddard Space Flight Center in Greenbelt Maryland and supported in part by the NASA Earth | ||
| 142 : | and Space Sciences (ESS) project. | ||
| 143 : | |||
| 144 : | One of the goals of the ESS project is to determine the applicability of massively parallel | ||
| 145 : | computers to the problems faced by the Earth and space sciences community. The first Beowulf | ||
| 146 : | was built to address problems associated with the large data sets that are often involved | ||
| 147 : | in ESS applications. | ||
| 148 : | |||
| 149 : | Cluster is a widely-used term meaning independent computers combined into a unified system | ||
| 150 : | through software and networking. At the most fundamental level, when two or more computers | ||
| 151 : | are used together to solve a problem, it is considered a cluster. Clusters are typically | ||
| 152 : | used for High Availability (HA) for greater reliability or High Performance Computing (HPC) | ||
| 153 : | to provide greater computational power than a single computer can provide. | ||
| 154 : | |||
| 155 : | Beowulf Clusters are scalable performance clusters based on commodity hardware, on a | ||
| 156 : | private system network, with open source software (Linux) infrastructure. The designer | ||
| 157 : | can improve performance proportionally with added machines. The commodity hardware can | ||
| 158 : | be any of a number of mass-market, stand-alone compute nodes as simple as two networked | ||
| 159 : | computers each running Linux and sharing a file system or as complex as 1024 nodes | ||
| 160 : | with a high-speed, low-latency network. | ||
| 161 : | |||
| 162 : | Class I clusters are built entirely using commodity hardware and software using standard | ||
| 163 : | technology such as SCSI, Ethernet, and IDE. They are typically less expensive than | ||
| 164 : | Class II clusters which may use specialized hardware to achieve higher performance. | ||
| 165 : | |||
| 166 : | Common uses are traditional technical applications such as simulations, biotechnology, | ||
| 167 : | and petro-clusters; financial market modeling, data mining and stream processing; and | ||
| 168 : | Internet servers for audio and games. | ||
| 169 : | |||
| 170 : | Beowulf programs are usually written using languages such as C and FORTRAN. They | ||
| 171 : | use message passing to achieve parallel computations. | ||
| 172 : | } | ||
| 173 : | |||
| 174 : | \section{Parallel programming, the message passing interface} | ||
| 175 : | |||
| 176 : | We will briefly discuss a little on parallel programming, parallel algorithms and the message passing interface known as MPI. | ||
| 177 : | |||
| 178 : | \subsection{A simple example on medusa.vlab.iu.hio.no} | ||
| 179 : | |||
| 180 : | We will show how to compile and run a simple parallel program on \texttt{medusa.vlab.iu.hio.no}. | ||
| 181 : | |||
| 182 : | Create a file named \texttt{machines} in your home directory containing the names of | ||
| 183 : | the nodes, each repated twice, with only one name on each line. This file is used by the | ||
| 184 : | job launcher facility \texttt{mpirun} for some exercises later on. There is a systemwide | ||
| 185 : | \texttt{machines}-file on the system, used by default by \texttt{mpirun}. | ||
| 186 : | %% Machines file | ||
| 187 : | \begin{verbatim} | ||
| 188 : | compute-0-0 | ||
| 189 : | compute-0-0 | ||
| 190 : | compute-0-1 | ||
| 191 : | compute-0-1 | ||
| 192 : | .... | ||
| 193 : | .... Supressed to save paper. | ||
| 194 : | .... | ||
| 195 : | compute-0-14 | ||
| 196 : | compute-0-14 | ||
| 197 : | compute-0-15 | ||
| 198 : | compute-0-15 | ||
| 199 : | \end{verbatim} | ||
| 200 : | |||
| 201 : | Create a file named \texttt{hostfile} in your home directory containing the names of | ||
| 202 : | the nodes and the frontend. This file is used later on for a benchmarking program in some | ||
| 203 : | exercises. | ||
| 204 : | |||
| 205 : | %% Host file | ||
| 206 : | \begin{verbatim} | ||
| 207 : | medusa.local | ||
| 208 : | compute-0-0.local cpu=2 | ||
| 209 : | compute-0-1.local cpu=2 | ||
| 210 : | .... | ||
| 211 : | .... Supressed to save paper | ||
| 212 : | .... | ||
| 213 : | compute-0-14.local cpu=2 | ||
| 214 : | compute-0-15.local cpu=2 | ||
| 215 : | \end{verbatim} | ||
| 216 : | |||
| 217 : | %% Additions to .bashrc | ||
| 218 : | Add the following to your \texttt{.bashrc} file to be sure that you use the correct \texttt{mpirun}. | ||
| 219 : | There are several different \texttt{mpirun}'s on the system. | ||
| 220 : | \begin{verbatim} | ||
| 221 : | alias gnumpirun=/opt/mpich/gnu/bin/mpirun | ||
| 222 : | \end{verbatim} | ||
| 223 : | |||
| 224 : | %% Program file | ||
| 225 : | The following is a small \texttt{C} program, write a file containing the | ||
| 226 : | code and call the file \texttt{phello.c}: | ||
| 227 : | \begin{verbatim} | ||
| 228 : | #include <stdio.h> | ||
| 229 : | #include <stdlib.h> | ||
| 230 : | #include <unistd.h> | ||
| 231 : | #include "mpi.h" | ||
| 232 : | |||
| 233 : | int main(int argc, char **argv) | ||
| 234 : | { | ||
| 235 : | int rank, size; | ||
| 236 : | char *hostname; | ||
| 237 : | |||
| 238 : | hostname = (char *)malloc((size_t)80*sizeof(char)); | ||
| 239 : | MPI_Init(&argc,&argv); | ||
| 240 : | MPI_Comm_rank(MPI_COMM_WORLD,&rank); | ||
| 241 : | MPI_Comm_size(MPI_COMM_WORLD,&size); | ||
| 242 : | gethostname(hostname,79); | ||
| 243 : | printf("Hello world! I am prosess %d of %d | ||
| 244 : | on the machine %s.\n",rank,size,hostname); | ||
| 245 : | MPI_Finalize(); | ||
| 246 : | return(0); | ||
| 247 : | } | ||
| 248 : | \end{verbatim} | ||
| 249 : | |||
| 250 : | We will look further into some aspects of MPI later, but the above program | ||
| 251 : | is so simple, and contains only four MPI calls, so we will explain them here. | ||
| 252 : | |||
| 253 : | The call \texttt{MPI\_Init} initializes the MPI environment, and must be called | ||
| 254 : | before any other MPI call (with one exception). Each of the $n$ processors involved in a MPI | ||
| 255 : | program is assigned a unique integer in the range $0$ to $n-1$. This unique number | ||
| 256 : | is returned by the call \texttt{MPI\_Comm\_rank}. The call \texttt{MPI\_Comm\_size} | ||
| 257 : | gives the total number of processors involved, and the call \texttt{MPI\_Finalize} terminates | ||
| 258 : | the MPI environment. No MPI call can be used after this call, and every prosess must call | ||
| 259 : | this function before exiting. | ||
| 260 : | |||
| 261 : | %% Makefile | ||
| 262 : | It is always a good idea to use the \texttt{make} facility. The following | ||
| 263 : | file can be used as a template for a \texttt{Makefile} for small MPI programs on \texttt{medusa}: | ||
| 264 : | \begin{verbatim} | ||
| 265 : | CC = /usr/bin/gcc | ||
| 266 : | PROGRAMS = phello | ||
| 267 : | INCLUDES = -I/opt/mpich/gnu/include | ||
| 268 : | LIBS = -L/opt/mpich/gnu/lib -lmpich | ||
| 269 : | |||
| 270 : | all: $(PROGRAMS) | ||
| 271 : | |||
| 272 : | .c: ; $(CC) $(INCLUDES) $@.c $(LIBS) -o $@ | ||
| 273 : | |||
| 274 : | clean:: | ||
| 275 : | -rm -f $(PROGRAMS) *.o | ||
| 276 : | \end{verbatim} | ||
| 277 : | |||
| 278 : | It is of course possible to compile the program by hand on the commandline, | ||
| 279 : | but this is not recommended. | ||
| 280 : | |||
| 281 : | The program is run with \texttt{mpirun} and the argument to the flag \texttt{-np} | ||
| 282 : | determines how many processors that should be used (including the frontend). | ||
| 283 : | |||
| 284 : | Here is a sample output from a run on four processors with a minimum arguments to \texttt{mpirun}: | ||
| 285 : | |||
| 286 : | \begin{verbatim} | ||
| 287 : | [torejo@medusa hello]$ gnumpirun -np 4 phello | ||
| 288 : | Hello world! I am prosess 0 of 4 on the machine medusa.iu.hio.no. | ||
| 289 : | Hello world! I am prosess 3 of 4 on the machine compute-0-2.local. | ||
| 290 : | Hello world! I am prosess 2 of 4 on the machine compute-0-1.local. | ||
| 291 : | Hello world! I am prosess 1 of 4 on the machine compute-0-0.local. | ||
| 292 : | [torejo@medusa hello]$ | ||
| 293 : | \end{verbatim} | ||
| 294 : | |||
| 295 : | Here is another example with more flags: | ||
| 296 : | |||
| 297 : | \begin{verbatim} | ||
| 298 : | [torejo@medusa hello]$ gnumpirun -np 4 -nolocal phello | ||
| 299 : | Hello world! I am prosess 3 of 4 on the machine compute-0-3.local. | ||
| 300 : | Hello world! I am prosess 2 of 4 on the machine compute-0-2.local. | ||
| 301 : | Hello world! I am prosess 1 of 4 on the machine compute-0-1.local. | ||
| 302 : | Hello world! I am prosess 0 of 4 on the machine compute-0-0.local. | ||
| 303 : | \end{verbatim} | ||
| 304 : | |||
| 305 : | And yet another example with even more flags: | ||
| 306 : | |||
| 307 : | \begin{verbatim} | ||
| 308 : | [torejo@medusa hello]$ gnumpirun -v -machinefile ~/machines -np 4 -nolocal phello | ||
| 309 : | running /home/torejo/parallell-kurs/hello/phello2 on 4 LINUX ch_p4 processors | ||
| 310 : | Created /home/torejo/parallell-kurs/hello/PIyPDWK15665 | ||
| 311 : | Hello world! I am prosess 1 of 4 on the machine compute-0-0.local. | ||
| 312 : | Hello world! I am prosess 3 of 4 on the machine compute-0-1.local. | ||
| 313 : | Hello world! I am prosess 2 of 4 on the machine compute-0-1.local. | ||
| 314 : | Hello world! I am prosess 0 of 4 on the machine compute-0-0.local. | ||
| 315 : | \end{verbatim} | ||
| 316 : | |||
| 317 : | \begin{todo} | ||
| 318 : | Log into \texttt{medusa.vlab.iu.hio.no}, compile and run the above program with a varying number | ||
| 319 : | of processors. Use both the default \texttt{machines} file, and the machines file in your | ||
| 320 : | home directory. Make sure that you learn to use \texttt{mpirun} command, and read the manual page | ||
| 321 : | for the command. Determine how the file \texttt{machines} affects the processors chosen for the | ||
| 322 : | parallel execution of the program. | ||
| 323 : | \end{todo} | ||
| 324 : | |||
| 325 : | |||
| 326 : | \section{Performance metrics} | ||
| 327 : | |||
| 328 : | Programs running on parallel machines normally contains a lot of computations and run for a | ||
| 329 : | long time. Hence it is important to be able to predict the \textsl{speedup} or the gain of | ||
| 330 : | parallelizing a problem and how much we can gain by increase the number of processors. Such | ||
| 331 : | analysis is done by performance metrics, and we will briefly scratch the surface of this | ||
| 332 : | subject here. | ||
| 333 : | |||
| 334 : | Operations performed by a parallel program can be divided into three categories: | ||
| 335 : | \begin{itemize} | ||
| 336 : | \item Operations that must be performed sequentially | ||
| 337 : | \item Operations that can be done in parallel | ||
| 338 : | \item Parallel overhead consisting of communication operations and redundant computations | ||
| 339 : | \end{itemize} | ||
| 340 : | |||
| 341 : | We define speedup denoted by $\Psi$ as the ration between sequential execution time denoted by | ||
| 342 : | $S(n)$ and parallel execution time $P(n,p)$. Here $n$ denote the problem size (the amount of data | ||
| 343 : | involved) and $p$ the number of processors: | ||
| 344 : | $$\Psi(n,p)=\frac{S(n)}{P(n,p)}$$ | ||
| 345 : | The efficiency of a parallel program, denoted by $\epsilon(n,p)$ measures the processor utilization | ||
| 346 : | and is defined as the speedup divided by the number of processors used: | ||
| 347 : | $$\epsilon(n,p)=\frac{\Psi(n,p)}{p}=\frac{S(n)}{p\times P(n,p)}$$ | ||
| 348 : | There are some well-known performance prediction formulas, Amdahl's law that can be used to decide | ||
| 349 : | whether a program merits parallelization, the Karp-Flatt metric that can be used to decide if the | ||
| 350 : | barrier to speedup is the amount of inherrently sequentally code or parallel overhead. The | ||
| 351 : | Gustafson-Barsis's law is a metric to evaluate parallel performance. The isoefficiency metric | ||
| 352 : | evaluates the scalability of a parallel algorithm, that is how to achieve higher performance | ||
| 353 : | when the number of processors and the problem sizes are increased. | ||
| 354 : | |||
| 355 : | |||
| 356 : | \subsection{Amdahl's law} | ||
| 357 : | |||
| 358 : | Let $\Psi$ denote the maximal speedup achivable by a parallel computer and let $f$ denote | ||
| 359 : | the fraction of operations that must be performed seqentially, so $0\leq f\leq 1$, and let | ||
| 360 : | $p$ denote the number of processors. Then | ||
| 361 : | \beq | ||
| 362 : | \Psi\leq\frac{1}{f+\frac{1-f}{p}} | ||
| 363 : | \eeq | ||
| 364 : | |||
| 365 : | |||
| 366 : | \subsection{Karp-Flatt metric} | ||
| 367 : | |||
| 368 : | Suppose a parallel computation exhibits a speedup $\Psi$ using $p$ processors, where $p\geq 2$, | ||
| 369 : | then the exprementally determined serial fraction $e$ if defined by | ||
| 370 : | \beq | ||
| 371 : | e=\frac{\frac{1}{\Psi}-\frac{1}{p}}{1-\frac{1}{p}} | ||
| 372 : | \eeq | ||
| 373 : | |||
| 374 : | \subsection{Gustafson-Barsis's law} | ||
| 375 : | |||
| 376 : | Consoder a parallel program solving a problem of size $n$ on $p$ processors. Let $s$ denote the | ||
| 377 : | fraction of total execution time spent in serial code. Then the maximum speedup $\Psi$ is given | ||
| 378 : | by | ||
| 379 : | \beq | ||
| 380 : | \Psi\leq p+(1-p)s | ||
| 381 : | \eeq | ||
| 382 : | |||
| 383 : | |||
| 384 : | \subsection{The isoefficiency metric} | ||
| 385 : | |||
| 386 : | Consider a problem of size $n$ on $p$ processors with a efficiency $\epsilon(n,p)$. Let | ||
| 387 : | $C=\epsilon(n,p)/(1-\epsilon(n,p))$, let $T(n,1)$ denote the sequential execution time | ||
| 388 : | and let $T_0(n,p)$ denote the parallel overhead. Then, in order to maintain the same level | ||
| 389 : | of efficency when the number of processors is increased, the problem size must be increased | ||
| 390 : | such that | ||
| 391 : | \beq | ||
| 392 : | T(n,1)\geq C T_0(n,p) | ||
| 393 : | \eeq | ||
| 394 : | is satisfied. | ||
| 395 : | |||
| 396 : | \section{Rocks installation} | ||
| 397 : | |||
| 398 : | |||
| 399 : | The following section describes the installation of the Rocks Cluster distribution. | ||
| 400 : | The current version is 4.2, and this differs a little from the previous versions as | ||
| 401 : | this version is the first with a graphical install interface. The previous versions | ||
| 402 : | had a textbased installation interface. | ||
| 403 : | |||
| 404 : | The official homepage for Rocks can be found at: | ||
| 405 : | \begin{verbatim} | ||
| 406 : | http://www.rocksclusters.org/ | ||
| 407 : | \end{verbatim} | ||
| 408 : | |||
| 409 : | \subsection{Physical assembly of a cluster} | ||
| 410 : | |||
| 411 : | \textbf{\large Supported Hardware} | ||
| 412 : | |||
| 413 : | Since Rocks is built on top of RedHat Linux releases, actually uses the CentOS-distribution, Rocks supports | ||
| 414 : | all the hardware components that RedHat supports, but only supports the x86, x86\_64 and IA-64 architectures. | ||
| 415 : | |||
| 416 : | \textbf{Processors} | ||
| 417 : | \begin{itemize} | ||
| 418 : | \item x86 (ia32, AMD Athlon, etc.) | ||
| 419 : | \item x86\_64 (AMD Opteron and EM64T) | ||
| 420 : | \item IA-64 (Itanium) | ||
| 421 : | \end{itemize} | ||
| 422 : | |||
| 423 : | \textbf{Networks} | ||
| 424 : | \begin{itemize} | ||
| 425 : | \item Ethernet (All flavors that RedHat supports, including Intel Gigabit Ethernet) | ||
| 426 : | \item Myrinet (provided by Myricom) | ||
| 427 : | \item Infiniband (provided by Voltaire) | ||
| 428 : | \end{itemize} | ||
| 429 : | |||
| 430 : | |||
| 431 : | \noindent\textbf{\large Minimum Hardware Requirements} | ||
| 432 : | |||
| 433 : | \textbf{Frontend Node} | ||
| 434 : | \begin{itemize} | ||
| 435 : | \item Disk Capacity: 20 GB | ||
| 436 : | \item Memory Capacity: 640 MB | ||
| 437 : | \item Ethernet: 2 physical ports | ||
| 438 : | \end{itemize} | ||
| 439 : | |||
| 440 : | |||
| 441 : | \textbf{Compute Nodes} | ||
| 442 : | \begin{itemize} | ||
| 443 : | \item Disk Capacity: 20 GB | ||
| 444 : | \item Memory Capacity: 640 MB | ||
| 445 : | \item Ethernet: 1 physical port | ||
| 446 : | \end{itemize} | ||
| 447 : | |||
| 448 : | \begin{figure}[ht] | ||
| 449 : | \begin{center} | ||
| 450 : | \includegraphics[scale=0.5]{rocks-img/eps/cluster.eps} | ||
| 451 : | \caption{The schematic setup of a Rocks cluster. The additional application message passing network is not required.\label{rocks.eps}} | ||
| 452 : | \end{center} | ||
| 453 : | \end{figure} | ||
| 454 : | |||
| 455 : | %% \begin{center} | ||
| 456 : | %% \includegraphics[scale=1.0]{tmj-img/eps/img_1857.eps} | ||
| 457 : | %% \end{center} | ||
| 458 : | |||
| 459 : | \begin{figure}[ht] | ||
| 460 : | \begin{center} | ||
| 461 : | \epsfig{file=tmj-img/eps/img_1857.eps} | ||
| 462 : | \caption{Medusa in the first stage with frontend and eight compute nodes.\label{img_1857.eps}} | ||
| 463 : | \end{center} | ||
| 464 : | \end{figure} | ||
| 465 : | |||
| 466 : | |||
| 467 : | \begin{figure}[ht] | ||
| 468 : | \begin{center} | ||
| 469 : | \includegraphics[scale=1.0]{tmj-img/eps/img_1862.eps} | ||
| 470 : | \caption{Medusa in the first stage with frontend and eight compute nodes. The cabeling on | ||
| 471 : | the back of the cluster rack.\label{img_1862.eps}} | ||
| 472 : | \end{center} | ||
| 473 : | \end{figure} | ||
| 474 : | |||
| 475 : | \begin{figure}[ht] | ||
| 476 : | \begin{center} | ||
| 477 : | \includegraphics[scale=1.0]{tmj-img/eps/IMG_2093.eps} | ||
| 478 : | \caption{Medusa in the second stage with frontend and 14 compute nodes.\label{img_2093.eps}} | ||
| 479 : | \end{center} | ||
| 480 : | \end{figure} | ||
| 481 : | |||
| 482 : | \begin{figure}[ht] | ||
| 483 : | \begin{center} | ||
| 484 : | \includegraphics[scale=1.0]{tmj-img/eps/IMG_2097.eps} | ||
| 485 : | \caption{Medusa in the second stage with frontend and 14 compute nodes and a larger Gb switch. The cabeling on | ||
| 486 : | the back of the cluster rack.\label{IMG_2097.eps}} | ||
| 487 : | \end{center} | ||
| 488 : | \end{figure} | ||
| 489 : | |||
| 490 : | |||
| 491 : | \subsection{Frontend installation} | ||
| 492 : | |||
| 493 : | |||
| 494 : | \begin{center} | ||
| 495 : | \includegraphics[scale=0.5]{rocks-img/eps/splash.eps} | ||
| 496 : | \end{center} | ||
| 497 : | |||
| 498 : | \begin{center} | ||
| 499 : | \includegraphics[scale=0.5]{rocks-img/eps/20.eps} | ||
| 500 : | \end{center} | ||
| 501 : | |||
| 502 : | \begin{center} | ||
| 503 : | \includegraphics[scale=0.5]{rocks-img/eps/21.eps} | ||
| 504 : | \end{center} | ||
| 505 : | |||
| 506 : | \begin{center} | ||
| 507 : | \includegraphics[scale=0.5]{rocks-img/eps/22.eps} | ||
| 508 : | \end{center} | ||
| 509 : | |||
| 510 : | \begin{center} | ||
| 511 : | \includegraphics[scale=0.5]{rocks-img/eps/23.eps} | ||
| 512 : | \end{center} | ||
| 513 : | |||
| 514 : | \begin{center} | ||
| 515 : | \includegraphics[scale=0.5]{rocks-img/eps/24.eps} | ||
| 516 : | \end{center} | ||
| 517 : | |||
| 518 : | \begin{center} | ||
| 519 : | \includegraphics[scale=0.5]{rocks-img/eps/25.eps} | ||
| 520 : | \end{center} | ||
| 521 : | |||
| 522 : | \begin{center} | ||
| 523 : | \includegraphics[scale=0.5]{rocks-img/eps/26.eps} | ||
| 524 : | \end{center} | ||
| 525 : | |||
| 526 : | \begin{center} | ||
| 527 : | \includegraphics[scale=0.5]{rocks-img/eps/27.eps} | ||
| 528 : | \end{center} | ||
| 529 : | |||
| 530 : | \begin{center} | ||
| 531 : | \includegraphics[scale=0.5]{rocks-img/eps/28.eps} | ||
| 532 : | \end{center} | ||
| 533 : | |||
| 534 : | \begin{center} | ||
| 535 : | \includegraphics[scale=0.5]{rocks-img/eps/29.eps} | ||
| 536 : | \end{center} | ||
| 537 : | |||
| 538 : | \begin{center} | ||
| 539 : | \includegraphics[scale=0.5]{rocks-img/eps/30.eps} | ||
| 540 : | \end{center} | ||
| 541 : | |||
| 542 : | \begin{center} | ||
| 543 : | \includegraphics[scale=0.5]{rocks-img/eps/31.eps} | ||
| 544 : | \end{center} | ||
| 545 : | |||
| 546 : | \begin{center} | ||
| 547 : | \includegraphics[scale=0.5]{rocks-img/eps/32.eps} | ||
| 548 : | \end{center} | ||
| 549 : | |||
| 550 : | \begin{center} | ||
| 551 : | \includegraphics[scale=0.5]{rocks-img/eps/33.eps} | ||
| 552 : | \end{center} | ||
| 553 : | |||
| 554 : | \subsection{Node installation} | ||
| 555 : | |||
| 556 : | \section{Rocks system administration} | ||
| 557 : | |||
| 558 : | \subsection{Administration models and tools} | ||
| 559 : | |||
| 560 : | \section{Job scheduling, SGE} | ||
| 561 : | |||
| 562 : | \begin{verbatim} | ||
| 563 : | http://gridengine.sunsource.net/ | ||
| 564 : | \end{verbatim} | ||
| 565 : | |||
| 566 : | \section{Cluster benchmarking tools} | ||
| 567 : | |||
| 568 : | |||
| 569 : | \section{Lab assignments} | ||
| 570 : | |||
| 571 : | \subsection{Rock installation and configuration} | ||
| 572 : | |||
| 573 : | \subsection{Job scheduling with SGE} | ||
| 574 : | |||
| 575 : | \subsection{Benchmarking Linux Beowulf clusters} | ||
| 576 : | |||
| 577 : | \subsection{Performance measurements on MPI programs} |
| Administrator | ViewVC Help |
| Powered by ViewVC 1.0.3 |