% IEEE-Version
\documentclass[10pt,twocolumn]{article}          % LaTeX 2e
\usepackage{latex8}                              % LaTeX 2e
\usepackage{times}                               % LaTeX 2e
% Ende IEEE-Version

% 'Normale' Version
% \documentclass[10pt]{article}
% Ende 'Normale' Version

\usepackage[ngerman]{babel}
\usepackage[utf8]{inputenc}

% font definitions, try \usepackage{ae} instead of the following
% three lines if you don't like this look
\usepackage{mathptmx}
\usepackage{graphicx}

\usepackage[T1]{fontenc}

\title{Grid Computing}


\author{Luca Debiasi\\0720045\\ldebiasi@cosy.sbg.ac.at\\Universität Salzburg
\and
Siegmar Alber\\0720046\\salber@cosy.sbg.ac.at\\Universität Salzburg
}


\date{13.03.2009}


\begin{document}

\maketitle
\newpage

% Nur bei Normal-Version
% \tableofcontents
% \newpage
% ENDE

\begin{abstract}
In der heutigen Zeit gibt es Projekte, die sehr große und umfangreiche Datenmengen erzeugen, die natürlich auch ausgewertet und verarbeitet werden müssen. Dafür werden oft sogenannte "`Supercomputer"' verwendet, die sehr teuer sind und Unmengen von Kosten für die Installation und Wartung verschlingen. Außerdem sind solche "`Supercomputer"' oft nur auf eine Art von Berechnungen abgestimmt und ihre Rechenkapazität ist nur schlecht erweiterbar bzw. ausbaufähig.
Hier greift das Konzept der GRIDs: Ihr Konzept besteht darin heterogene Ressourcen miteinander zu verbinden und die Summe dieser gemeinsam verfügbar zu machen. Somit ist es z.B. auch leicht möglich die Rechenleistung eines GRIDs auszubauen. Doch ein GRID stellt nicht nur Rechenleistung zur Verfügung, sondern ist noch für weitaus mehr Zwecke nutzbar.
\end{abstract}







\section{Einleitung}

Es gibt keine einheitliche Definition, was ein GRID genau ist. Laut \cite{GridCafe} und \cite{WP-DE} kann ein GRID jedoch wie folgt beschreiben:

Ein GRID kann als eine Form des verteilten Rechnens beschrieben werden und setzt sich dabei aus lose gekoppelten, heterogenen Einheiten zusammen. Diese Einheiten bestehen aus transparenten Ressourcen, die vernetzt werden. Hierbei stellen offene, standardisierte Protokolle und Schnittstellen nicht-triviale Dienstgüten (QoS) bereit.



Ressourcen bezeichnen dabei:

  \begin{itemize}
    \item CPU: Liefert CPU-Zeit für jegliche Art von Berechnungen
    \item Speicher: Kann sowohl Arbeits- als auch Massenspeicher sein
    \item Datenbank: Speichert Daten in Tabellen samt ihren Zusammenhänge 
    \item Messgeräte: Können z.B. Sensoren sein
    \item Lizenzen: digitale Rechte eines Users
    \item Anwendungen: Programme jeglicher Art und Weise
    \item Web Services: Dienste im WWW
    \end{itemize}


  Ein Grid kann z.B. mit einem Stromnetz (eng. power grid) verglichen werden, da ihr Aufbau sehr ähnlich ist. Davon stammt auch der Name "`GRID"'.
 
Der Vergleich von GRIDs mit Cluster deckt einige Unterschiede auf:
GRIDs besitzen eine losere Kopplung und können aus heterogenen Einheiten (Komponenten) aufgebaut sein. Cluster bestehen hingegen aus homogenen Einheiten (Komponenten), die eng gekoppelt sind. Dies bedeutet, dass Cluster Einheiten verbinden, die sich auf engstmöglichem Raum befinden. GRIDs hingegen unterliegen meist einer weiträumigen geographischen Zerstreuung. Ein weiterer wesentlicher Unterschied zwischen GRIDs und Cluster besteht darin, dass GRIDs nicht nur CPU-Leistung bzw. -Zeit zur Verfügung stellen, sondern gegebenenfalls auch andere Ressourcen (z.B. einen Sensor oder Speicher). Außerdem besitzen sie eine standardisierte Middleware, um unterschiedliche Hardware zu Abstrahieren und für universelle Zwecke zur Verfügung stellen zu können. Cluster hingegen sind homogen aufgebaut und benötigen dadurch keine Middleware, sind dadurch jedoch nicht so flexibel.

Im Vergleich zu SETI@Home \& Co. weisen GRIDs im Wesentlichen den folgenden Unterschied auf:
GRIDs können verschiedene Anwendungsgebiete (Multi-Purposse) haben,  SETI@Home \& Co. sind auf  bestimmte Anwendungsgebiete ausgelegt und verwenden dadurch im Gegensatz zu GRIDs nur die CPU um Berechnungen durchzuführen.








\section{Aufbau}
Grids bestehen aus mehreren Komponenten. Nach \cite{GridCafe} gehören dazu:
\begin{description} 
  \item[Netzwerk]
  	Es bildet die Infrastruktur des GRIDs und verbindet die Einheiten. Es gewährleistet außerdem eine sichere Kommunikation zwischen diesen.
  \item[Ressourcen]
	Sie können unterschiedlichster Art sein und werden von (geographisch) unabhängigen Einheiten zur Verfügung gestellt.
  \item[Middleware]
  	Die Middleware abstrahiert die Heterogenität der Ressourcen und verwaltet diese. Dies wird oft durch Virtualisierung umgesetzt.
  \item[Applikation(en)]  
	Applikationen bilden die Schnittstelle des GRIDs zum Anwender.
  
\end{description}


\section{Geschichte}
Laut \cite{WP-DE} und \cite{WP-EN} gab es bereits in den 60er Jahren erste Konzepte für die Verteilung rechenintensiver Aufgaben.
Der Begriff „GRID“ existiert seit Mitte der 1990er Jahre. Die Projekte FAFNER (Factoring via Network-Enabled Recursion) und I-WAY (Information Wide Area Year) bilden den Anfang des GRID-Computings. 

Das FAFNER Projekt wurde 1995 ins Leben gerufen von einem Konsortium aus mehreren Firmen in den USA und behandelte Primfaktorenzerlegung mittels RSA-130. I-WAY entstand ebenso wie FAFNER 1995. Es wurde von der University of Illinois initiiert und hatte das Ziel verschiedene Supercomputer unter Verwendung existierender Netzwerke zu vernetzen um ihre Ressourcen gemeinsam nutzen zu können. Dafür wurde eine Gigabit-Testumgebung erstellt.


\section{Vorteile}
Durch ein GRID verbundene Ressourcen können wesentliche besser  ausgenutzt werden, da sie nicht nur für einen speziellen Zweck genutzt werden können, sondern universell einsetzbar sind und auch parallen von mehreren Anwendern genutzt werden können. Außerdem können GRIDs laufend ausgebaut werden und besitzen eine gute Skalierbarkeit. Sie verbinden geographisch unabhängige Ressourcen und dadurch können diese gegebenenfalls effizienter genutzt werden. GRIDs besitzen außerdem eine große Robustheit gegenüber "`single points of failure"'. Dies bedeutet dass einzelne Ressourcen ausfallen können und das GRID trotzdem noch lauffähig ist, da es  diesen Ausfall kompensieren kann. Durch die Kombination von vielen Ressourcen wird es außerdem erst möglich, sehr aufwändige und ressourcen-intensive Projekte durchzuführen.


\section{Nachteile}
Ein erster Aspekt, der hier beachtet werden muss, ist die (Daten-)Sicherheit. Im wesentlichen versteht man darunter, ob man dem GRID seine Daten anvertrauen kann.  Dadurch stellt sich auch die Frage, wer überhaupt garantieren kann, dass sensible Daten auch dementsprechend behandelt werden?
Ein weiteres Problem könnte die Abhängigkeit vom GRID werden. Da es für den Endbenutzer nur mehr Thin Clients geben soll, die selbst nur eine sehr begrenzte Rechenleistung besitzen, könnte es bei einem Ausfall des GRIDs dadurch zu schwerwiegenden Folgen kommen (z.B. könnte die Gesamte Börse lahmgelegt werden, wenn das GRID einen Totalausfall erleidet).



\section{Beispiele}
\subsection{Worldwide LHC Computing-Grid}


Das Worldwide LHC Computing-Grid wird von der CERN verwaltet und ist Teil des  EGEE (Enabling Grids for E-sciencE) Netzwerkes. Beim WLCG werden hunderte Cluster und große Anzahl von Sensoren vernetzt um Kollisionsberechnungen durchzuführen. Hierzu ist ein GRID notwendig, da ein dementsprechender Rechenaufwand von Nöten ist, um die sehr großen anfallenden Datenmengen auswerten zu können.
Die Informationen zu diesem Abschnitt stammen aus \cite{LHC}.

\begin{figure}[h]
\center{\includegraphics[height=7cm]{egee.jpg}}
\caption{Bildquelle \cite{LHC}. Wichtige Knoten des EGEE}
\end{figure}

\subsection[FhRG]{Frauenhofer Resource Grid}


Das Frauenhofer Resource Grid (FhRG) der Fraunhofer-Gesellschaft wird hauptsächlich für (interne) Forschung benutzt, steht jedoch auch für industrielle Nutzung zur Verfügung.
Die Informationen zu diesem Abschnitt stammen von \cite{FHG}.

\begin{figure}[h]
\center{\includegraphics[height=7cm]{fhrg.jpg}}
\caption{Bildquelle \cite{FHG}. Rechenzentren des FHRG}
\end{figure}


\section{Zukunft und Ziele}

Das grundlegende Ziel von GRIDs sollte es sein, "`Rechenleistung aus der Steckdose"' für jedermann bereitzustellen (angelehnt an das Stromnetz). Eine weitere Vision ist, dass Endbenutzergeräte auf dem Prinzip der Thin Clients basieren sollen: Hierbei gibt der Anwender eine Berechnung in Auftrag und die Thin Clients dienen nur der Visualisierung der Ergebnisse, die eigentliche Berechnung wird an das GRID abgegeben und von diesem durchgeführt. Dadurch soll es auch möglich werden komplexe Datenauswertungen überall verfügbar zu machen.
Ein weiteres Konzept befasst sich mit dem Thema "`Grid als Dienstleistung"'. Hierbei sollte es in Zukunft gegen Bezahlung möglich sein, auf sehr große Rechenkapazitäten zugreifen zu können und diese für die Industrie oder gegebenenfalls auch für Privatanwender verfügbar und nutzbar zu machen.
Durch all diese Konzepte soll ein weltweites Grid entstehen, das abertausende von Ressourcen vereint und gemeinsam nutzbar machen soll.

 


\section{Zusammenfassung}

Zusammenfassend kann man also sagen, dass ein Grid folgende 5 Grundideen vereint:
\begin{enumerate}
\item Ressourcen teilen (anderen zur Verfügung stellen)
\item Ressourcen gemeinsam nutzen (Ressourcen anderer für eigene Zwecke verwenden)
\item Sicherer Zugang und Datensicherheit
\item Räumliche Distanz verschwindet (durch die Vernetzung der Ressourcen)
\item Offene Standards (Austauschbare und laufend verbesserbare Schnittstellen)
\end{enumerate}

Da die GRID-Technologie noch in den Kinderschuhen steckt kann man noch nicht viel darüber sagen, wie sie sich in Zukunft genau entwickeln wird, jedoch stecken viel Potential und interessante Ideen dahinter. In Zukunft könnte es so weit kommen dass ein weltweit bestehendes GRID, auf das von überall zugegriffen werden kann, für uns so selbstverständlich sein wird wie heutzutage das Internet.

\section*{Weitere Referenztypen}
Artikel (in Journal)\cite{ArtikelJournal}, Artikel (in Collection)\cite{ArtikelCollection}, Buch\cite{Buch}, Proceeding\cite{Proceeding}, These\cite{These}

\bibliography{quellen}
\bibliographystyle{plain}

\end{document}
