Korrekturlesen: 1. Anlauf

This commit is contained in:
Jörg Thalheim 2014-04-03 11:37:41 +02:00
parent 9cd1f7e26b
commit 62ad17d07a
25 changed files with 322 additions and 186 deletions

View File

@ -34,8 +34,6 @@
:internal - [0:0] :internal - [0:0]
-A uni -j internal -A uni -j internal
-A internal -p tcp --dport 22 -j ACCEPT -A internal -p tcp --dport 22 -j ACCEPT
-A internal -p tcp --dport 80 -j ACCEPT
-A internal -p tcp --dport 443 -j ACCEPT
# --------------------------------------------------------------- # ---------------------------------------------------------------
# public traffic # public traffic

View File

@ -1,10 +1,10 @@
\subsection{Installation des Batchsystems} \subsection{Installation des Batchsystems}
Aus dem AUR (\ref{sec:aur}) installierten wir Aus dem AUR (\ref{sec:aur}) installierten wir
\href{http://www.schedmd.com/#index}{SLURM} in der Version 2.6.3. \href{http://www.schedmd.com/#index}{SLURM} in der Version 2.6.3. SLURM
SLURM benötigt für die Authentifizierung zwischen den Nodes einen externen Dienst. benötigt für die Authentifizierung zwischen den Nodes einen externen Dienst.
Dazu richteten wir den empfohlenen Dazu richteten wir den empfohlenen
\href{MUNGE}{http://code.google.com/p/munge/}-Daemon ein und verteilten den auf \href{http://code.google.com/p/munge/}{MUNGE}-Daemon ein und verteilten den auf
dem Head-Node erstellten Schlüssel auf die anderen Nodes dem Head-Node erstellten Schlüssel auf die anderen Nodes
(\emph{/etc/munge/munge.key}). (\emph{/etc/munge/munge.key}).

View File

@ -1,5 +1,10 @@
\subsection{Zusatzaufgabe: Maui} \subsection{Zusatzaufgabe: Maui}
Wir haben uns entschieden, Maui nicht einzurichten, da SLURM bereits einen eigenen Scheduler mitbringt und Maui äußerst schwierig einzurichten zu sein scheint, da selbst die SLURM-Entwickler hierzu nichts weiter sagen können: Wir haben uns entschieden, Maui nicht einzurichten, da SLURM bereits einen
eigenen Scheduler mitbringt und Maui äußerst schwierig einzurichten zu sein
scheint, so dass selbst die SLURM-Entwickler hierzu keine Dokumentation
anbieten:
\epigraph{Maui configuration is quite complicated and is really beyond the scope of any documents we could supply with SLURM.}{\href{https://computing.llnl.gov/linux/slurm/maui.html}{SLURM-Website}} \epigraph{Maui configuration is quite complicated and is really beyond the scope
of any documents we could supply with
SLURM.}{\href{https://computing.llnl.gov/linux/slurm/maui.html}{SLURM-Website}}

View File

@ -3,5 +3,3 @@
\input{batch/bat-installation} \input{batch/bat-installation}
\input{batch/bat-konfiguration} \input{batch/bat-konfiguration}
\input{batch/bat-maui} \input{batch/bat-maui}
\pagebreak

View File

@ -36,6 +36,8 @@ einen Wert von {\bf 4,076 GFlops}.
\subsubsection{Auswertung} \subsubsection{Auswertung}
Verglichen mit der theoretischen Floating Point Peak Performance von: \\ Verglichen mit der theoretischen Floating Point Peak Performance von: \\ $1,6$
$1,6$ GHz $\cdot 2$ CPU-Kerne pro Prozessor $\cdot 2$ Instruktion pro Takt $\cdot 4$ CPUs $ = 25,6$ GFlops \\ GHz $\cdot 2$ CPU-Kerne pro Prozessor $\cdot 2$ Instruktion pro Takt $\cdot 4$
erreichten wir damit also ca. 16 \% der maximal möglichen Leistung, was in Anbetracht des langsamen Verbindungsnetzwerkes ein akzeptabler Wert ist. CPUs $ = 25,6$ GFlops \\ erreichten wir also ca. 16 \% der maximal möglichen
Leistung, was in Anbetracht des langsamen Verbindungsnetzwerkes ein akzeptabler
Wert ist.

View File

@ -35,6 +35,14 @@ Die Lesegeschwindigkeit von NFS entspricht mit als Maximalwert gemessenen 109 Mi
\shellcmd{hdparm -t /dev/sda} \shellcmd{hdparm -t /dev/sda}
Die Schreibegeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa der Leistungsfähig der Festplatte entsprechen. Die Schreibegeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa
der Leistungsfähigskeit der Festplatte entsprechen.
GlusterFS liegt in der Lesegeschwindigkeit von maximal 104 MiB/s etwa mit NFS gleich auf. Die Schreibegeschwindigkeit hingegen erreicht lediglich 28 MiB/s und lieg damit weit hinter NFS. Dies lässt sich im Wesentlichen darauf zurückführen, dass GlusterFS ein FUSE-Dateisystem ist und es deshalb bei jeder Schreibeoperation etliche Kontextwechsel gibt, weil die einzelnen Nodes miteinander kommunizieren müssen, um die Daten verteilt schreiben zu können. Zusätzlich stellen hier also auch die Atom-Prozessoren durch ihre begrenze Leistungsfähigkeit einen limitierenden Faktor dar. GlusterFS liegt in der Lesegeschwindigkeit von maximal 104 MiB/s etwa mit NFS
gleich auf. Die Schreibegeschwindigkeit hingegen erreicht lediglich 28 MiB/s und
liegt damit weit hinter NFS. Dies lässt sich im Wesentlichen darauf
zurückführen, dass GlusterFS ein FUSE-Dateisystem ist und es deshalb bei jeder
Schreibeoperation es etliche Kontextwechsel und Kopiervorgänge gibt, weil die
einzelnen Nodes miteinander kommunizieren müssen, um die Daten verteilt
schreiben zu können. Zusätzlich stellen hier also auch die Atom-Prozessoren
durch ihre begrenze Leistungsfähigkeit einen limitierenden Faktor dar.

View File

@ -1,8 +1,11 @@
\subsection{Git-Server} \subsection{Git-Server}
\label{sub:git_server} \label{sub:git_server}
Zur Verwaltung von \emph{Git} haben wir uns für \href{https://github.com/sitaramc/gitolite}{gitolite} entschieden. Dies erlaubt eine Verwaltung von Zugriffsrechten auf Repositories. Zur Verwaltung von \emph{Git} haben wir uns für
Die Authentifizierung erfolgt dabei über SSH-Keys. Hier für wird ein \emph{git} Nutzer eingerichtet: \href{https://github.com/sitaramc/gitolite}{Gitolite} entschieden. Gitolite
erlaubt eine Verwaltung von Zugriffsrechten auf Repositories. Die
Authentifizierung erfolgt dabei über SSH-Keys. Hier für wird ein Nutzer mit dem
Namen \emph{git} eingerichtet:
\shellcmd{useradd -m -U -r -s /bin/bash -d /srv/git git} \shellcmd{useradd -m -U -r -s /bin/bash -d /srv/git git}
@ -23,46 +26,48 @@ Das lctp-Repository wiederum lässt sich mit folgendem Befehl clonen:
\shellcmd{cd lctp-gruppe4 \&\& git submodule init \&\& git submodule update} \shellcmd{cd lctp-gruppe4 \&\& git submodule init \&\& git submodule update}
\subsubsection{etckeeper} \subsubsection{Etckeeper}
Um die Konfiguration in \emph{/etc } versionierbar und damit nachvollziehbar zu machen installierten wir \emph{etckeeper}: Um die Konfiguration in \emph{/etc } versionierbar und damit nachvollziehbar zu
machen installierten wir \emph{Etckeeper}:
\shellcmd{yaourt -S etckeeper \&\& sudo etckeeper init} \shellcmd{yaourt -S etckeeper \&\& sudo etckeeper init}
\shellcmd{cd /etc/.git \&\& sudo git remote add git@zotac0:lctp.git} \shellcmd{cd /etc/.git \&\& sudo git remote add git@zotac0:lctp.git}
Dieses legt ein \emph{git}-Repository in \emph{/etc/.git} an und erstellt Commits bei Änderungen in \emph{/etc}. Etckeeper legt ein \emph{git}-Repository in \emph{/etc/.git} an und erstellt
Um die Konfiguration vom Bericht zu trennen, haben wir uns entschieden, \texttt{ Commits bei Änderungen in \emph{/etc}. Um die Konfiguration vom Bericht zu
etckeeper} in ein dediziertes Repository (\emph{logs}) pushen und als Submodule trennen, haben wir uns entschieden, \texttt{etckeeper} in ein dediziertes
im \emph{lctp}-Repository einzubinden: Repository (\emph{logs}) pushen und als Submodule im \emph{lctp}-Repository
einzubinden:
\shellcmd{sudo git remote add origin git@zotac0:etckeeper.git} \shellcmd{sudo git remote add origin git@zotac0:etckeeper.git}
Anders als bei anderen Paketmanagern wie \emph{apt} auf Debian, existieren in \emph{pacman} (\ref{sec:pacman}) Im Gegensatz zu anderen Paketmanagern wie \emph{apt} auf Debian, existieren in
keine Hooks. \emph{pacman} (\ref{sec:pacman}) keine Hooks. Um dennoch nach
Um dennoch nach Systemaktualisierungen oder Paketinstallationen automatisch die Systemaktualisierungen oder Paketinstallationen automatisch die neue
neue Konfiguration zu commiten haben wir jeweils einen Konfiguration zu commiten, haben wir jeweils ein
\href{https://gist.github.com/Mic92/7250403}{Wrapper-Script} für \emph{pacman} \href{https://gist.github.com/Mic92/7250403}{Wrapper-Script} für \emph{Pacman}
und \emph{yaourt} geschrieben und diese \emph{/usr/local/bin} abgelegt. Da in der und \emph{Yaourt} geschrieben und beide in den Pfad \emph{/usr/local/bin}
Shell \emph{/usr/local/bin} für gewöhnlich eine höhere Priorität hat als \texttt{ abgelegt. Da in der Shell \emph{/usr/local/bin} für gewöhnlich eine höhere
/usr/bin} werden Programme in diesem Verzeichnis vorrangig ausgeführt. (Die Priorität besitzt als \texttt{/usr/bin}, werden Programme in diesem Verzeichnis
Wrapper befinden sich in \emph{aufgabe2.4/yaourt} sowie in \emph{aufgabe2.4/pacman}). vorrangig ausgeführt. Die Wrapper befinden sich in \emph{aufgabe2.4/yaourt}
Darüber hinaus haben wir das Shell-Script für tägliche automatische Commits, sowie in \emph{aufgabe2.4/pacman}. Darüber hinaus haben wir das Shell-Script für
welches im tägliche automatische Commits, welches sich im
\href{https://github.com/joeyh/etckeeper/blob/master/debian/cron.daily}{Git-Repository} \href{https://github.com/joeyh/etckeeper/blob/master/debian/cron.daily}{Git-Repository}
(Stand 07.11.2013) (Stand 07.11.2013) von \emph{etckeeper} liegt, als Cronjob eingerichtet (siehe
von \emph{etckeeper} liegt, als cronjob installiert (siehe
\emph{aufgabe2.4/cron.daily/etckeeper}). \emph{aufgabe2.4/cron.daily/etckeeper}).
\subsubsection{Logs in git} \subsubsection{Logs in git}
Arch Linux setzt in der Standard-Installation \emph{journald} als Logging-Daemon ein. Dieses benutzt im Unterschied zu herkömmlichen Syslog-Varianten ein Binärformat zum Speichern. Archlinux setzt in der Standard-Installation \emph{Journald} als Logging-Daemon
Dieses Dateiformat eignet sich aus offensichtlichen Gründen nicht um mithilfe ein. Im Unterschied zu herkömmlichen Syslog-Varianten speichert Journald in
von git verwaltet zu werden. Deswegen haben wir zusätzlich \emph{syslog-ng} einem eigenen Binärformat ab. Dieses Dateiformat eignet sich aus
installiert und \emph{journald} so konfiguriert, das dieses ebenfalls in das offensichtlichen Gründen nicht um mithilfe von git verwaltet zu werden. Deswegen
syslog schreibt (siehe \emph{aufgabe2.4/journald.conf}). haben wir zusätzlich \emph{Syslog-ng} installiert und \emph{Journald} so
Für tägliche commits haben wir hierfür das Shell-Script \emph{git-commit-log} konfiguriert, das es ebenfalls in das syslog schreibt (siehe
nach \emph{/etc/cron.daily/} installiert (siehe \emph{aufgabe2.4/journald.conf}). Für tägliche commits haben wir hierfür das
\emph{aufgabe2.4/cron.daily/git-commit-log}). Dieses pusht die Log-Dateien in das Shell-Script \emph{git-commit-log} nach \emph{/etc/cron.daily/} installiert
logs-Repository. Es ist als Submodule im Verzeichnis \emph{logs} im (siehe \emph{aufgabe2.4/cron.daily/git-commit-log}). Dieses lädt die Log-Dateien
in das logs-Repository hoch. Es ist als Submodule im Verzeichnis \emph{logs} im
lctp-Repository eingebunden. lctp-Repository eingebunden.

View File

@ -1,17 +1,19 @@
\subsection{Parallel Distributed Shell (PDSH)} \subsection{Parallel Distributed Shell (PDSH)}
\label{sub:parallel_shell} \label{sub:parallel_shell}
Die \emph{pdsh} ist ein Tool, mit dem man parallel auf mehreren Rechnern gleichzeitig Befehle über SSH ausführen kann, um diese komplett synchron zu konfigurieren und zu administrieren. Die \emph{Pdsh} ist ein Tool, mit dem man parallel auf mehreren Rechnern
gleichzeitig Befehle über SSH ausführen kann, um diese komplett synchron zu
konfigurieren und zu administrieren.
Das entsprechende Paket war nicht im offiziellen Arch Linux Repository Das entsprechende Paket war nicht im offiziellen Arch Linux Repository
vorhanden, deshalb haben wir es über das AUR (siehe \ref{sec:aur}) installiert. vorhanden, deshalb haben wir es über das AUR (siehe \ref{sec:aur}) installiert.
\subsubsection{Gruppenverwaltung} \subsubsection{Gruppenverwaltung} Zur Verwaltung mehrerer Rechner in Gruppen (in
Zur Verwaltung mehrerer Rechner in Gruppen (in unserem Fall Headnode und unserem Fall Headnode und Computenodes) greift \emph{Pdsh} auf die
Computenodes) greift \emph{pdsh} auf die Gruppenbeschreibungsdatei \texttt{ Gruppenbeschreibungsdatei \texttt{ /etc/genders} (siehe
/etc/genders} (siehe \emph{aufgabe2.5/genders}) zurück. Dort können mehrere Hosts \emph{aufgabe2.5/genders}) zurück. Dort können mehrere Hosts in verschiedene
in verschiedene Gruppen eingeteilt werden. Gruppen eingeteilt werden. Um zu gewährleisten, dass Pdsh den richtigen Befehl
Um zu gewährleisten, dass pdsh den richtigen Befehl beim Verbinden benutzt, muss beim Verbinden benutzt, muss die Umgebungsvariable \emph{PDS\_RCMD\_TYPE} auf
die Umgebungsvariable \emph{PDS\_RCMD\_TYPE} auf den Wert \emph{ssh} gesetzt sein. Dies den Wert ``ssh'' gesetzt sein. Dies lösten wir durch ein Wrapper-Script in
lösten wir durch ein Wrapper-Script in \emph{/usr/local/bin}, das die \emph{/usr/local/bin}, das die genannte Umgebungsvariable setzt (siehe
genannte Umgebungsvariable setzt (siehe \emph{aufgabe2.5/pdsh}). \emph{aufgabe2.5/pdsh}).

View File

@ -16,14 +16,31 @@ ChallengeResponseAuthentication no
\subsubsection{iptables} \subsubsection{iptables}
Um den Zugriff auf das universitätsinterne Netz zu beschränken wurde ein Um den Zugriff auf das universitätsinterne Netz zu beschränken wurde ein
Filter-Chain \emph{uni} zur \emph{iptables.rules} unter \emph{/etc/iptables} (siehe Filter-Chain \emph{uni} zur \emph{iptables.rules} unter \emph{/etc/iptables}
\emph{aufgabe2.3/iptables.rules}) hinzugefügt, der nur IP-Adressen aus den Bereichen 141.30.0.0/16 und 141.76.0.0/16 akzeptiert und die Zugriffe auf Port 22, 80 und 443 beschränkt. (siehe \emph{aufgabe2.3/iptables.rules}) hinzugefügt, der nur IP-Adressen aus
den Bereichen 141.30.0.0/16 und 141.76.0.0/16 akzeptiert und die Zugriffe auf
den SSH-Port 22 beschränkt.
\subsubsection{Absicherung für externen Zugriff} \subsubsection{Absicherung für externen Zugriff}
Um den Zugriff aus einem externen Netz abzusichern, könnte man z.B. den externen SSH-Port auf einen anderen Port als 22 legen, so dass dieser nicht zu leicht erraten werden kann. Zusätzlich könnte man per \emph{fail2ban} IPs, die z.B. per Bruteforce zu häufig versuchen sich einzuloggen, aussperren. Außerdem könnte man den externen SSH-Port auch erst per Port-Knocking freischalten, bei dem der Client z.B. mit einem Script erst an mehrere Ports »klopfen« muss, bevor er sich verbinden kann. Desweiteren könnte man den Login von außen nur für bestimmte Benutzer erlauben. Um den Zugriff aus einem externen Netz abzusichern, gibt es verschiedene
Möglichkeiten
\begin{enumerate}
\item den externen SSH-Port auf einen anderen Port als 22 legen, so dass
dieser nicht zu leicht erraten werden kann
\item per \emph{Fail2ban} IPs, die z.B. per
Bruteforce zu häufig versuchen sich einzuloggen, aussperren
\item den externen SSH-Port erst per Port-Knocking freischalten, bei dem
der Client z.B. mit einem Script erst an mehrere Ports »klopfen« muss, bevor
er sich verbinden kann
\item den Login auf bestimmte Benutzer begrenzen
\end{enumerate}
\subsubsection{Automatisierung für neue Nutzer} \subsubsection{Automatisierung für neue Nutzer}
Das automatisierte Hinzufügen neuer Nutzer haben wir über ein Script \texttt{ Das automatisierte Hinzufügen neuer Nutzer haben wir über ein Script
newuser} (siehe \emph{aufgabe2.3/newuser}) gelöst. Dieses Script legt einen neuen Benutzer an, erstellt sein Home-Verzeichnis, generiert ein neues Public-Private-Key-Paar für SSH und trägt den eigenen Public-Key in die \emph{authorized\_keys} sowie für den Zugriff auf das git-Repository ein. \texttt{newuser} (siehe \emph{aufgabe2.3/newuser}) gelöst. Dieses Script legt
einen neuen Benutzer an, erstellt dessen Home-Verzeichnis, generiert ein neues
Public-Private-Key-Paar für SSH und trägt den eigenen Public-Key in die
\emph{authorized\_keys} ein und ermöglich den Zugriff auf das git-Repository.

View File

@ -5,14 +5,25 @@
Wir haben \href{http://www.archlinux.org/}{Arch Linux} als Betriebssystem gewählt. Wir haben \href{http://www.archlinux.org/}{Arch Linux} als Betriebssystem gewählt.
Es hat mit \emph{systemd} ein modernes und robustes init-System. Dieses verwaltet Abhängigkeiten zwischen den verschiedenen Systemdiensten. Gestartete Dienste werden überwacht und können im Fehlerfall neu gestartet werden. Es hat mit \emph{Systemd} ein modernes und robustes init-System. Systemd verwaltet Abhängigkeiten zwischen den verschiedenen Systemdiensten. Gestartete Dienste werden überwacht und können im Fehlerfall neu gestartet werden.
Das Logging delegiert \emph{systemd} an \emph{journald}. Dieses indexiert die Logs und speichert diese in komprimierter Form ab. Ersteres erlaubt das effiziente Filtern nach bestimmten Feldern, wie der Zeit. Das Logging delegiert \emph{Systemd} an \emph{Journald}. Journald indexiert die Logs und speichert diese in komprimierter Form ab. Ersteres erlaubt das effiziente Filtern nach bestimmten Feldern, wie der Zeit.
Archlinux ist eine Rolling-Release-Distribution. Das heißt, dass es keine festen Zeitpunkte gibt, zu denen eine neue Version veröffentlicht mit neuen Paketen veröffentlicht wird. Stattdessen werden diese von den Maintainern kontinuierlich eingepflegt. Deswegen befinden sich in den offiziellen Arch Linux Repository in den meisten Fällen die aktuellsten Versionen der benötigten Software. Archlinux ist eine Rolling-Release-Distribution. Das heißt, dass es keine festen
Zeitpunkte gibt, zu denen eine neue Version veröffentlicht mit neuen Paketen
veröffentlicht wird. Stattdessen werden Pakete von den Maintainern
kontinuierlich eingepflegt. Deswegen befinden sich in den offiziellen Arch Linux
Repository in den meisten Fällen die aktuellsten Versionen der benötigten
Software.
Ist diese nicht im offiziellen Repository vorhanden, so kann man viele weitere Pakete im AUR finden (siehe ~\ref{sec:aur}). Im Unterschied zum offiziellen Repository werden Pakete aus dem AUR aus den Quellen gebaut. Das einfach gehaltene Buildsystem, erlaubt es schnell in den Paketbau einzugreifen werden und eigene Varianten eines Paketes zu bauen. Neben dem offiziellen Repository gibt es viele weitere Pakete im AUR (siehe
~\ref{sec:aur}). Im Unterschied zum offiziellen Repository werden Pakete im AUR
aus den Quellen gebaut. Das einfach gehaltene Buildsystem erlaubt es, schnell in
den Paketbau einzugreifen zu können und eigene Varianten eines Paketes zu bauen.
Als Nachteile muss man hingegen aufführen, dass es leider keinen kommerziellen Support gibt. Dies wäre für größere Installationen notwendig. Außerdem muss bei den Systemupdates darauf achten werden, dass eine neue Version eines Paketes noch mit der aktuellen (möglicherweise geänderten) Konfiguration kompatibel ist. Als Nachteile muss man hingegen aufführen, dass es leider keinen kommerziellen
Support gibt, welcher für größere Installationen notwendig wäre. Außerdem muss
bei den Systemupdates darauf achten werden, das eine neue Version eines Paketes
noch mit der aktuellen (möglicherweise geänderten) Konfiguration kompatibel ist.
\subsection{Installation} \subsection{Installation}

View File

@ -4,43 +4,42 @@
\subsection{Munin} \subsection{Munin}
\label{sub:munin} \label{sub:munin}
Zur Überwachung und Aufzeichnung des Systems während des Burnin haben wir \texttt{ Zur Überwachung und Aufzeichnung des Systems während des Burnin haben wir
munin} eingerichtet. Dieses besteht aus einem Masterprozess, welches die gewünschten \texttt{Munin} eingerichtet. Munit besteht aus einem Masterprozess, welches
Daten aufzeichnet, und einem Nodeprozess, welches die Daten bereitstellt. Die die gewünschten Daten aufzeichnet und einem Nodeprozess, welches die Daten
Darstellung erfolgt über ein Webinterface, welches die Graphen aus einer bereitstellt. Die Darstellung erfolgt über ein Webinterface, welches die Graphen
\emph{rddtool}-Datenbank generiert. Auf dem Headnode haben wir den Masterprozess aus einer \emph{Rddtool}-Datenbank generiert. Auf dem Headnode haben wir den
installiert: Masterprozess installiert:
\shellcmd{pacman -S munin} \shellcmd{pacman -S munin}
Auf dem Computenode die Nodekomponente: Auf dem Computenode die Nodekomponente:
\shellcmd{pacman -S munin-node} \shellcmd{pacman -S munin-node}
Für das Webfrontend richteten wir darüber hinaus den Webserver \emph{nginx} ein: Für das Webfrontend richteten wir darüber hinaus den Webserver \emph{Nginx} ein:
\shellcmd{pacman -S nginx} \shellcmd{pacman -S nginx}
Dieser kommuniziert über fastcgi mit Munin um die Graphen Der Webserver kommuniziert über das FastCGI-Protokoll mit Munin um die Graphen
generieren zu lassen. Die nötige Konfiguration befindet sich in \texttt{ generieren zu lassen. Die nötige Konfiguration befindet sich in
aufgabe2.5/nginx}. Die fastcgi-Prozesse von Munin starteten wir mit folgenden \texttt{aufgabe2.5/nginx}. Den FastCGI-Prozess von Munin starteten wir mit dem
Befehl: Befehl:
\shellcmd{systemctl enable munin-graph.socket munin-html.socket} \shellcmd{systemctl enable munin-graph.socket munin-html.socket}
\shellcmd{systemctl start munin-graph.socket munin-html.socket} \shellcmd{systemctl start munin-graph.socket munin-html.socket}
Die ab zu fragenden Nodes werden in die \emph{munin.conf} eingetragen (\texttt{ Die abzufragenden Nodes werden in die \emph{munin.conf} eingetragen
aufgabe2.6/munin.conf}). (\texttt{aufgabe2.6/munin.conf}). Da die Anzahl unserer Nodes verhältnismäßig
Da die Anzahl unserer Nodes verhältnismäßig klein ist, haben wir uns für die klein ist, haben wir uns für die Aktualisierung der Leistungsdaten mithilfe
Aktualisierung der Leistungsdaten via \emph{munin-cron} entschieden: \emph{munin-cron} entschieden:
\shellcmd{crontab /etc/munin/munin-cron-entry -u munin} \shellcmd{crontab /etc/munin/munin-cron-entry -u munin}
Munin bringt bei der Installation schon eine Vielzahl von Plugins mit. Manche Munin bringt bei der Installation schon eine Vielzahl von Plugins mit. Manche
von diesen benötigen wiederum für die Datenerfassung andere Programme. Auf dem von dieser Plugins benötigen wiederum für die Datenerfassung andere Programme.
Computenode haben wir folgende Plugins aktiviert: Auf dem Computenode haben wir folgende Plugins aktiviert:
\begin{itemize} \begin{itemize}
\item cpu \item cpu
@ -51,7 +50,8 @@ Computenode haben wir folgende Plugins aktiviert:
\item sensors\_temp \item sensors\_temp
\end{itemize} \end{itemize}
Zum Belasten des Systems über 48h verwendeten wir \emph{stress} mit jeweils 4 Workern für jeweils CPU-, IO-, Speicher- und Festplatten-Auslastung. Zum Belasten des Systems über 48h verwendeten wir das Programm \emph{Stress} mit
4 Worker-Prozessen für jeweils CPU-, IO-, Speicher- und Festplatten-Auslastung.
\pagebreak \pagebreak
@ -90,7 +90,8 @@ Abschließend ist zu sagen, dass der Compute-Node den Burnin ohne nennenswerte A
\subsubsection{Shutdown} \subsubsection{Shutdown}
Nach dem Burnin sollte der Compute-Node automatisch heruntergefahren werden. Dazu nutzten wir folgenden Shell-Befehl: Nach dem Burnin sollte der Compute-Node automatisch heruntergefahren werden.
Dazu nutzten wir den Zeitparameter des \emph{Shutdown-Befehls}:
\shellcmd{shutdown -P 2880} \shellcmd{shutdown -P 2880}

View File

@ -458,7 +458,7 @@ werden können. Allerdings ist anzunehmen, dass die Zahl architekturbedingt unte
der von Chef liegt. der von Chef liegt.
Zu den von offiziell von Chef unterstützt Plattformen gehören Windows, MacOS X, Zu den von offiziell von Chef unterstützt Plattformen gehören Windows, MacOS X,
verschiedene Linuxderivate (Debian, Ubuntu, Redhat...) und Solaris. Puppet verschiedene Linuxderivate (Debian, Ubuntu, Redhat\ldots) und Solaris. Puppet
bietet breiteren Support und unterstützt zusätzlich Free- und OpenBSD sowie bietet breiteren Support und unterstützt zusätzlich Free- und OpenBSD sowie
HP-UX und AIX. HP-UX und AIX.

View File

@ -18,7 +18,7 @@ Jedes Board war jeweils ausgestattet mit: %\footnote{330er Board und 1. Computen
\item einem (bereits fest verbautem) Intel Atom 330 Prozessor \item einem (bereits fest verbautem) Intel Atom 330 Prozessor
\item 2 GiB DDR2-RAM \item 2 GiB DDR2-RAM
\item 250 GiB Festplatte \item 250 GiB Festplatte
\item einem im Gehäuse bereits vorhandenes Netzteil. \item ein im Gehäuse bereits vorhandenes Netzteil.
\end{itemize} \end{itemize}
\vspace{0.5cm} \vspace{0.5cm}

View File

@ -1,7 +1,7 @@
\subsection{Backup} \subsection{Backup}
\label{sub:backup} \label{sub:backup}
Wir haben uns für rsnapshot aus folgenden Gründen entschieden: Wir haben uns für \href{http://www.rsnapshot.org/}{Rsnapshot} aus folgenden Gründen entschieden:
\begin{itemize} \begin{itemize}
\item Die Backups liegen als Ordner mit den gleichen Rechten wie im zu backupenden System. \item Die Backups liegen als Ordner mit den gleichen Rechten wie im zu backupenden System.
@ -15,18 +15,18 @@ Wir haben uns für rsnapshot aus folgenden Gründen entschieden:
werden. Dies kann zeitaufwändig sein und ist fehleranfällig, sollte ein Delta werden. Dies kann zeitaufwändig sein und ist fehleranfällig, sollte ein Delta
beschädigt werden. Um dem entgegen zu wirken, werden deswegen in beschädigt werden. Um dem entgegen zu wirken, werden deswegen in
regelmäßigen Abständen volle Backups erstellt, was wiederum mehr regelmäßigen Abständen volle Backups erstellt, was wiederum mehr
Speicherplatz benötig. Speicherplatz benötigt.
\end{itemize} \end{itemize}
Die Konfigurationsdatei (/etc/rsnapshot.conf) für rsnaphot liegt in Die Konfigurationsdatei (/etc/rsnapshot.conf) für Rsnaphot liegt in
\emph{aufgabe4.3/rsnaphot.conf}. Es werden folgende Verzeichnisse gesichert: \emph{aufgabe4.3/rsnaphot.conf}. Es werden folgende Verzeichnisse gesichert:
/home/, /etc/, /usr/local/, /cluster/, /srv/, /fastfs/, /var/lib/ /home/, /etc/, /usr/local/, /cluster/, /srv/, /fastfs/, /var/lib/
Das dafür bereitgestellte NFS ist unter \emph{/backup} gemountet. Die Backups Das dafür bereitgestellte NFS ist unter dem Pfad \emph{/backup} gemountet. Die
werden im Unterverzeichnis \emph{rsnapshot} erstellt. Das Backup wird Backups werden im Unterverzeichnis \emph{rsnapshot} erstellt. Das Backup wird
als cron-job durch die Skripte \emph{/etc/cron.daily/rsnaphot} und als Cron-Job durch die Skripte \emph{/etc/cron.daily/rsnaphot} und
\emph{/etc/cron.weekly/rsnapshot} durchgeführt (vgl. \emph{/etc/cron.weekly/rsnapshot} durchgeführt (vgl.
\emph{aufgabe4.3/cron.\{daily,weekly\}/rsnapshot.conf}). Dabei werden die \emph{aufgabe4.3/cron.\{daily,weekly\}/rsnapshot.conf}). Dabei werden die
letzten die Stände der letzten 7 Tage sowie die der letzten 3 Wochen letzten die Stände der letzten 7 Tage sowie die der letzten 3 Wochen
vorgehalten. Darüber hinaus wurde je ein vollständiges Backup von zotac0 und zotac1 vorgehalten. Darüber hinaus wurde je ein vollständiges Backup von zotac0 und
in \emph{/backup} erstellt. zotac1 in Verzeichnis \emph{/backup} erstellt.

View File

@ -2,7 +2,7 @@
\label{sub:compiler} \label{sub:compiler}
Die benötigten Compiler/Bibliotheken für den Cluster-Betrieb wurden mit Hilfe der Die benötigten Compiler/Bibliotheken für den Cluster-Betrieb wurden mit Hilfe der
Software easybuild (\ref{sec:easybuild}) installiert. Software Easybuild (\ref{sec:easybuild}) installiert.
Die installierte Software ist im Verzeichnis \emph{/cluster/} zu finden. Die installierte Software ist im Verzeichnis \emph{/cluster/} zu finden.
\subsubsection{GNU Compiler Collection} \subsubsection{GNU Compiler Collection}
@ -15,7 +15,7 @@ Wir haben folgende GCC-Versionen installiert:
\item \href{4.8.2-RC-20131009}{ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.2-RC-20131009/} \item \href{4.8.2-RC-20131009}{ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.2-RC-20131009/}
\end{itemize} \end{itemize}
Die für easybuild (\ref{sec:easybuild}) benötigten Paket-Beschreibungen sind in \emph{aufgabe4.1/GCC} zu Die für Easybuild (\ref{sec:easybuild}) benötigten Paket-Beschreibungen sind in \emph{aufgabe4.1/GCC} zu
finden. Zwischen den Versionen kann mit folgendem Befehl gewechselt werden: finden. Zwischen den Versionen kann mit folgendem Befehl gewechselt werden:
\shellcmd{module swap GCC/4.8.2 GCC/4.8.1} \shellcmd{module swap GCC/4.8.2 GCC/4.8.1}
@ -24,7 +24,7 @@ finden. Zwischen den Versionen kann mit folgendem Befehl gewechselt werden:
\label{ssub:intel_compiler_suite} \label{ssub:intel_compiler_suite}
Wir installierten die Intel Compiler Suite in der Version 2013\_sp1.1.106 Wir installierten die Intel Compiler Suite in der Version 2013\_sp1.1.106
Die für easybuild (\ref{sec:easybuild}) benötigten Paket-Beschreibungen sind in \emph{aufgabe4.1/icc} zu Die für Easybuild (\ref{sec:easybuild}) benötigten Paket-Beschreibungen sind in \emph{aufgabe4.1/icc} zu
finden. finden.
Der C-Compiler wird mit folgenden Befehl geladen: Der C-Compiler wird mit folgenden Befehl geladen:

View File

@ -1,5 +1,6 @@
\subsection{CUDA} \subsection{CUDA}
\label{sub:cuda} \label{sub:cuda}
Die für easybuild (\ref{sec:easybuild}) benötigten Paket-Beschreibungen sind in \emph{aufgabe4.6} zu finden. Die für Easybuild (\ref{sec:easybuild}) benötigten Paket-Beschreibungen sind in
Zusätzlich wurden die Pakete \emph{nvidia mesa glu libxi libmxu freeglut} installiert. \emph{aufgabe4.6} zu finden. Zusätzlich wurden die Pakete \emph{nvidia, mesa,
glu, libxi, libmxu} und \emph{freeglut} installiert.

View File

@ -1,9 +1,12 @@
\subsection{Modules} \subsection{Modules}
\label{sub:modules} \label{sub:modules}
Zu Initialisierung von Modules, haben wir Shell-Skript in Zu Initialisierung von Modules, haben wir das Shell-Skript in
\emph{/etc/profile.d/module.sh} hinterlegt (auch zu finden in aufgabe4.2/module.sh). \emph{/etc/profile.d/module.sh} hinterlegt (auch zu finden in
Dieses Skript fügt den Pfad \emph{/cluster/modules/all} zum MODULESPATH hinzu, aufgabe4.2/module.sh). Dieses Skript fügt den Pfad \emph{/cluster/modules/all}
so dass Module in diesem Verzeichnis geladen werden können. Darüber hinaus wird die Datei \emph{/cluster/modules/rc} als MODULERCFILE konfiguriert. zum MODULESPATH hinzu, so dass Module in diesem Verzeichnis geladen werden
Diese Datei lädt Module wie den GCC-Compiler oder OpenMPI vor. Über eine können. Darüber hinaus wird die Datei \emph{/cluster/modules/rc} als
Versionsdatei in \emph{/cluster/modules/all/GCC/.version} wird der GCC-Version 4.8.2 als default markiert. Die gesamte Modules-Konfiguration befindet sich in \emph{aufgabe4.2/modules}. MODULERCFILE konfiguriert. Diese Datei lädt Module wie den GCC-Compiler oder
OpenMPI vor. Über eine Versionsdatei in \emph{/cluster/modules/all/GCC/.version}
wird der GCC-Version 4.8.2 als Standard markiert. Die gesamte
Modules-Konfiguration befindet sich in \emph{aufgabe4.2/modules}.

View File

@ -1,13 +1,18 @@
\subsection{Open MPI} \subsection{Open MPI}
\label{sub:open_mpi} \label{sub:open_mpi}
OpenMPI wurde in der Version 1.7.3 mithilfe von easybuild (\ref{sec:easybuild}) installiert. Die für easybuild benötigten Paket-Beschreibungen sind in \emph{aufgabe4.5} zu finden. Zum Testen haben wir das Programm \emph{hello.cpp} (siehe \emph{aufgabe4.5/hello.cpp}) geschrieben, welches für jeden Node dessen Rank und Hostname ausgibt. Dieses kann durch folgenden Befehl compiliert werden: OpenMPI wurde in der Version 1.7.3 mithilfe von Easybuild (\ref{sec:easybuild})
installiert. Die für Easybuild benötigten Paket-Beschreibungen sind in
\emph{aufgabe4.5} zu finden. Zum Testen haben wir das Programm \emph{hello.cpp}
(siehe \emph{aufgabe4.5/hello.cpp}) geschrieben, welches für jeden Node dessen
Rank und Hostname ausgibt. Dieses kann durch folgenden Befehl kompiliert werden:
\shellcmd{mpic++ hello.cpp} \shellcmd{mpic++ hello.cpp}
Mit Hilfe einer \emph{hosts}-Datei, in der die Namen aller verwendeten Nodes eingetragen wird, kann das Programm mit folgenden Befehl ausgeführt werden: Mit Hilfe einer \emph{hosts}-Datei, in der die Namen aller verwendeten Nodes
eingetragen wird, kann das Programm mit folgenden Befehl ausgeführt werden:
\shellcmd{mpirun $--$hostfile hosts a.out} \shellcmd{mpirun \-\-hostfile hosts a.out}
Beispiel-Ausgabe: Beispiel-Ausgabe:

View File

@ -5,9 +5,19 @@
\begin{sloppypar} \begin{sloppypar}
Wir verwenden Clonezilla um die Provisionierung durchzuführen. Wir haben uns für dieses Verfahren entschieden, weil bspw. ein Netzwerk-Boot, bei dem das gesamte Dateisystem per NFS eingebunden wird, in unserem Fall eher ineffektiv wäre, da auf den Festplatten der Compute-Nodes sowieso genügend Speicher für das Betriebssystem vorhanden ist und es dann bei jedem Zugriff auf das Dateisystem zu unnötigen Latenzen kommen würde. Für die Provisionierung wurde Clonezilla verwendet. Wir haben uns für dieses
Verfahren entschieden. Bei einem Netzwerk-Boot beispielsweise, bei dem das
gesamte Dateisystem per NFS eingebunden wird, wäre in unserem Fall ineffektiv,
da auf den Festplatten der Compute-Nodes genügend Speicher für das
Betriebssystem vorhanden ist und bei jedem Zugriff auf das Dateisystem unnötigen
Latenzen entstehen würden.
Um Clonezilla auf den Computenodes zu booten, haben wir den \emph{ in.tftpd}-Server installiert und das Service-File für \emph{ systemd} angepasst (siehe \emph{ aufgabe4.4/tftpd.service}). Außerdem haben wir die Konfiguration des DHCP-Servers so angepasst, dass nun jeder Compute-Node eine eigene Konfigurationsdatei in \emph{ /etc/dhcpd.d/} hat, die jeweils in von \emph{ /etc/dhcpd.d/all} inkludiert wird. Um Clonezilla auf den Computenodes zu booten, haben wir den
\emph{in.tftpd}-Server installiert und das Service-File für \emph{Systemd}
angepasst (siehe \emph{aufgabe4.4/tftpd.service}). Außerdem haben wir die
Konfiguration des DHCP-Servers so angepasst, dass nun jede Compute-Node eine
eigene Konfigurationsdatei in \emph{/etc/dhcpd.d/} hat, die jeweils von
\emph{/etc/dhcpd.d/all} inkludiert wird.
Außerdem haben wir ein Script \emph{ cluster} geschrieben, mit dem die Computenodes verwaltet werden können. Mit Außerdem haben wir ein Script \emph{ cluster} geschrieben, mit dem die Computenodes verwaltet werden können. Mit
\begin{lstlisting} \begin{lstlisting}
@ -17,9 +27,18 @@ wird ein neuer Node hinzugefügt (DHCP- und DNS-Eintrag). Mit
\begin{lstlisting} \begin{lstlisting}
cluster set-<MODE> <HOSTNAME> cluster set-<MODE> <HOSTNAME>
\end{lstlisting} \end{lstlisting}
kann der Modus für den nächsten Boot des Nodes festgelegt werden. Hier kann man zwischen \emph{ local} (Boot von lokaler Festplatte), \emph{ live} (Boot in das Clonezilla Image), \emph{ clone} (Clonen nach Boot) und \emph{ restore} (Image laden nach Boot) wählen. kann der Modus für den nächsten Boot des Nodes festgelegt werden. Hier kann
zwischen \emph{local} (Boot von lokaler Festplatte), \emph{live} (Boot in das
Clonezilla Image), \emph{clone} (Clonen nach Boot) und \emph{restore} (Image
laden nach Boot) gewechselt werden.
Um den Netzwerk-Boot zu ermöglichen, haben wir \emph{ pxelinux} unter \emph{ /srv/tftp/pxelinux} installiert und konfiguriert. In dieses Verzeichnis haben wir die Dateien \emph{ vmlinuz}, \emph{ initrd.img} und \emph{ filesystem.squashfs} aus der Clonezilla-Live-ISO kopiert, sowie außerdem noch \emph{ ldlinux.c32, libcom32.c32, libutil.c32, menu.c32, chain.c32} und \emph{ pxelinux.0} aus der \emph{ syslinux}-Installation. Die Konfigurationsdateien liegen in \emph{ /srv/tftp/pxelinux/pxelinux.cfg}. Um den Netzwerk-Boot zu ermöglichen, haben wir \emph{pxelinux} unter
\emph{/srv/tftp/pxelinux} installiert und konfiguriert. In dieses Verzeichnis
haben wir die Dateien \emph{vmlinuz}, \emph{initrd.img} und
\emph{filesystem.squashfs} aus der Clonezilla-Live-ISO kopiert, sowie außerdem
noch \emph{ldlinux.c32, libcom32.c32, libutil.c32, menu.c32, chain.c32} und
\emph{pxelinux.0} aus der \emph{syslinux}-Installation. Die
Konfigurationsdateien liegen in \emph{/srv/tftp/pxelinux/pxelinux.cfg}.
\end{sloppypar} \end{sloppypar}
@ -27,14 +46,38 @@ Um den Netzwerk-Boot zu ermöglichen, haben wir \emph{ pxelinux} unter \emph{ /s
\begin{sloppypar} \begin{sloppypar}
Um den Clone-Vorgang zu starten, wir nun mit \emph{ sudo cluster set-clone <HOSTNAME>} und anschließendem (Neu-)Starten des Nodes das Clonezilla Live Image gebootet. Dieses holt sich nun vom Headnode ein Script und führt dieses aus. In diesem Script haben wir alle nötigen Befehle eingetragen, um das Clonen vorzubereiten und zu starten (siehe \emph{ aufgabe4.4/clone.sh}). Dazu wird per NFS das \emph{ /cluster}-Verzeichnis des Headnodes eingebunden und dort im Unterverzeichnis \emph{ images} das Image der Festplatte abgelegt. Geclont werden nur die \emph{ /}- und die \emph{ /boot}-Partition. Um den Clone-Vorgang zu starten, führten wir nun mit dem Befehl \emph{sudo
cluster set-clone <HOSTNAME>} aus. Durch Neustart des Nodes wird das Clonezilla
Live Image gebootet. Dieses holt sich nun vom Headnode ein Script und führt es
aus. In diesem Script haben wir alle nötigen Befehle eingetragen, um das Clonen
vorzubereiten und zu starten (siehe \emph{aufgabe4.4/clone.sh}). Dazu wird per
NFS das \emph{/cluster}-Verzeichnis des Headnodes eingebunden und dort im
Unterverzeichnis \emph{images} das Image der Festplatte abgelegt. Geclont werden
nur die \emph{/}- und die \emph{/boot}-Partition.
Zum Wiederherstellen des Images wird mit \emph{ sudo cluster set-restore <HOSTNAME>} wieder der entsprechende Boot-Modus gesetzt und der Node neugestartet. Dort wird nun ein anderes Script vom Headnode geholt (siehe \emph{ aufgabe4.4/restore.sh}) und die beiden Partitionen wiederhergestellt. Anschließend werden noch die Swap-Partition und die Daten-Partition für das verteilte Dateisystem neu formatiert und die alten UUIDs gesetzt. Zum Wiederherstellen des Images wird mit \emph{sudo cluster set-restore
<HOSTNAME>} wieder der entsprechende Boot-Modus gesetzt und der Node
neugestartet. Dort wird nun ein anderes Script vom Headnode geholt (siehe \emph{
aufgabe4.4/restore.sh}) und die beiden Partitionen wiederhergestellt.
Anschließend werden noch die Swap-Partition und die Daten-Partition für das
verteilte Dateisystem neu formatiert und die alten UUIDs gesetzt.
Da Clonezilla bei uns \emph{ ext4} irgendwie nicht erkannt hat, hat es, um die Partitionen zu klonen, \emph{ partclone.dd} verwendet, was allerdings sehr langsam ist, weil es die komplette Partition klont und freie Blöcke nicht auslässt. Deswegen haben wir zwei kleine Wrapper-Scripts geschrieben, die stattdessen \emph{ partclone.ext4} aufrufen. (siehe \emph{ aufgabe4.4/partclone.dd-clone} und \emph{ partclone.dd-restore}) Da Clonezilla bei uns das Dateisystemformat \emph{ext4} nicht als solches
erkannt hat. Es fiel auf das generische Programm \emph{partclone.dd} zurück,
welches allerdings sehr langsam ist, weil es die komplette Partition klont und
freie Blöcke nicht überspringt. Deswegen haben wir zwei kleine Wrapper-Scripts
geschrieben.Diese Skripte verwenden stattdessen das schnellere
\emph{partclone.ext4} (siehe \emph{aufgabe4.4/partclone.dd-clone} und
\emph{partclone.dd-restore}).
Da wir in unserem Cluster gemischte Boards haben (Intel und Zotac), mussten wir anschließend außerdem noch das Ziel-Root-Verzeichnis mounten und dort mit \emph{ mkinitcpio -p linux} ein neues \emph{ initrd} erstellen lassen, damit die entsprechenden richtigen Treiber beim Bootvorgang geladen werden können. Da wir in unserem Cluster gemischte Boards haben (Intel und Zotac), mussten wir
anschließend außerdem noch das Ziel-Root-Verzeichnis mounten und dort mit Befehl
\emph{mkinitcpio -p linux} ein neue Init-Ramdisk erstellen lassen, welches die
entsprechenden Treiber für Bootvorgang enthält.
Um die automatische Umbenennung der Netzwerk-Interfaces vorzubeugen, mussten wir außerdem einen Symlink \emph{ /etc/udev/rules.d/80-net-name-slot.rules -> /dev/null} erstellen. Dieser verhindert, dass das Ethernet-Interface nicht enpXsY sondern fest eth0 benannt wird. Um die automatische Umbenennung der Netzwerk-Interfaces vorzubeugen, haben wir
außerdem einen Symlink \emph{/etc/udev/rules.d/80-net-name-slot.rules ->
/dev/null} erstellt. Dadurch wird verhindert, dass Ethernet-Interface nicht nach
dem neuen Schema enpXsY sondern fest den Namen eth0 erhalten.
\end{sloppypar} \end{sloppypar}

View File

@ -12,5 +12,3 @@ des Compute Nodes}
\input{prov/prov-mpi} \input{prov/prov-mpi}
\input{prov/prov-cuda} \input{prov/prov-cuda}
\pagebreak

View File

@ -3,7 +3,9 @@
\subsubsection{Server} \subsubsection{Server}
\begin{sloppypar} \begin{sloppypar}
Wir haben uns für \emph{dhcpd} als DHCP-Server entschieden. Zur Konfiguration haben wir in \emph{/etc/dhcpd.conf} (siehe \emph{aufgabe3.2}) den Domain-Namen \emph{zotac} eintragen und den Headnode als DNS-Server eingestellt. Wir haben uns für den \emph{ISC-Dhcpd} als DHCP-Server entschieden. Zur
Konfiguration haben wir in \emph{/etc/dhcpd.conf} (siehe \emph{aufgabe3.2}) die
interne Top-Level-Domain \emph{zotac} eintragen und den Headnode als DNS-Server eingestellt.
\end{sloppypar} \end{sloppypar}
Des Weiteren haben wir das Subnet \emph{10.20.0.0/24} deklariert und wiederum den Headnode als verantwortlichen Router eingetragen. Des Weiteren haben wir das Subnet \emph{10.20.0.0/24} deklariert und wiederum den Headnode als verantwortlichen Router eingetragen.
@ -18,23 +20,33 @@ host zotac<X> {
} }
\end{lstlisting} \end{lstlisting}
Damit ist sichergestellt, dass die Hosts die im Cluster-Layout spezifizierte IP-Adresse entsprechend ihrer MAC-Adresse zugewiesen bekommen und gleichzeitig ihren Hostnamen gesagt bekommen. (Die IP-Adresse holt sich der DHCP-Server vom lokalen DNS-Server.) Damit ist sichergestellt, dass die Hosts die im Cluster-Layout spezifizierte
IP-Adresse entsprechend ihrer MAC-Adresse zugewiesen bekommen und gleichzeitig
ihren Hostnamen mitgeteilt bekommen. Die IP-Adresse löst der DHCP-Server über
den lokalen DNS-Server auf.
Zusätzlich haben wir das bereits in der Installation enthaltene \emph{systemd}-Service-File entsprechend so angepasst, dass man beim Starten und Aktivieren des Dienstes spezifizieren kann, auf welchem Netzwerk-Interface der Dienst hören soll. (siehe \emph{aufgabe3.2/dhcpd4@.service}) Zusätzlich haben wir das bereits in der Installation enthaltene
\emph{Systemd}-Service-File entsprechend so angepasst, dass beim Starten und
Aktivieren des Dienstes spezifiziert werden kann, auf welchem Netzwerk-Interface
der Dienst hören soll. (siehe \emph{aufgabe3.2/dhcpd4@.service})
Starten kann man den Dienst nun mit: Gestartet wird der Dienst mit dem Befehl:
\shellcmd{systemctl start dhcpd4@eth1} \shellcmd{systemctl start dhcpd4@eth1}
wobei \emph{eth1} das Interface ist, das am internen LAN angeschlossen ist. Wobei \emph{eth1} der Name des Interface ist, das am internen LAN angeschlossen ist.
\subsubsection{Client} \subsubsection{Client}
\begin{sloppypar} \begin{sloppypar}
Als Client verwenden wir \emph{dhcpcd}. \\ Als Client verwenden wir \emph{Dhcpcd}.
Um den Hostnamen richtig vom DHCP-Server abholen zu können, mussten wir in \emph{/usr/lib/dhcpcd/dhcpcd-hooks/30-hostname} (siehe \emph{aufgabe3.2/30-hostname}) noch die Option \emph{hostname\_fqdn=false} setzen, damit der kurze Hostname (\emph{zotac<X>} statt \emph{zotac<X>.zotac}) verwendet wird. \\ Um den Hostnamen per DHCP zu setzen, mussten wir in
\emph{/usr/lib/dhcpcd/dhcpcd-hooks/30-hostname} (siehe
\emph{aufgabe3.2/30-hostname}) die Option \emph{hostname\_fqdn=false} setzen,
so dass der Hostname (\emph{zotac<X>} an Stelle der FQDN \emph{zotac<X>.zotac})
verwendet wird.
Außerdem haben wir noch die Zeile: Außerdem haben wir noch die Zeile:
\begin{center} \begin{center}
@ -51,10 +63,12 @@ ersetzt, damit der bezogene Hostname automatisch persistent (\emph{/etc/hostname
\subsection{DNS} \subsection{DNS}
\label{ssub:dns} \label{ssub:dns}
Als DNS-Server haben wir \emph{Bind} installiert und eingerichtet. Als DNS-Server haben wir \emph{Named} aus dem Programmpaket \emph{Bind} installiert und
Die Konfiguration ist in \emph{aufgabe3.2/named.conf} zu finden. eingerichtet. Die Konfiguration ist in \emph{aufgabe3.2/named.conf} zu finden.
Für das Auflösen der Hostnames haben wir die Domaine zotac \emph{aufgabe3.2/zotac.zone} angelegt und Für das Auflösen der Hostnames haben wir die Domaine zotac
ein Zonefile für die Reverse-DNS-Auflösung \emph{aufgabe3.2/0.20.10.in-appr.arpa}. \emph{aufgabe3.2/zotac.zone} angelegt und ein Zonefile für die
Schließlich musste noch die /etc/resolv.conf angepasst werden, so dass der eingerichtete Server Reverse-DNS-Auflösung \emph{aufgabe3.2/0.20.10.in-appr.arpa}. Schließlich
auch von der Head-Node zur Adress-Auflösung benutzt wird (\emph{aufgabe3.2/resolv.conf}). musste noch die /etc/resolv.conf angepasst werden, so dass der eingerichtete
Die Nodes bekommen die DNS-Einstellungen per dhcp. Server auch von der Head-Node zur Adress-Auflösung benutzt wird
(\emph{aufgabe3.2/resolv.conf}). Die Nodes bekommen die DNS-Einstellungen per
DHCP zugewiesen.

View File

@ -8,33 +8,35 @@ Wir haben uns für das NFS-Dateisystem entschieden. Dieses ermöglicht
ressourcensparend Verzeichnisse zwischen der Head-Node und den Compute-Nodes zu ressourcensparend Verzeichnisse zwischen der Head-Node und den Compute-Nodes zu
teilen. teilen.
Unter Archlinux ist der NFS-Server im Packet \emph{nfs-utils} zu finden. Unter Archlinux ist der NFS-Server im Paket \emph{nfs-utils} zu finden.
Um NFS zu exportieren starten wir auf dem Head-Node den rpc-mountd.service. Um NFS zu exportieren, starteten wir auf dem Head-Node den rpc-mountd.service.
Das ID-Mapping übernimmt in unserem Fall der ldap-Dienst (\ref{sub:ldap}). Das ID-Mapping der symbolischen Benutzer und Gruppen auf die User- und Group-IDs
Auf den Compute-Node wurde jeweils ein Eintrag für die Verzeichnisse \emph{home} übernimmt in unserem Fall der LDAP-Dienst (\ref{sub:ldap}). Auf den
und \emph{cluster} in der fstab angelegt. (siehe \emph{aufgabe3.1/fstab}). Compute-Node wurde jeweils ein Eintrag für die Verzeichnisse \emph{home} und
\emph{cluster} in der Datei \emph{/etc/fstab} angelegt. (siehe \emph{aufgabe3.1/fstab}).
\subsubsection{Verteiltes Dateisystem} \subsubsection{Verteiltes Dateisystem}
\label{ssub:verteiltes_dateisystem} \label{ssub:verteiltes_dateisystem}
Als Dateisystem haben wir uns für GlusterFS entschieden. Dieses hat im Vergleich Als Dateisystem haben wir uns für GlusterFS entschieden. Im Vergleich zu anderen
zu anderen verteilten Dateisystemen keine zentrale Metadaten-Server. Stattdessen verteilten Dateisystemen besitzt GlusterFS keine zentrale Metadaten-Server.
setzt es auf das Elastic-Hashing. Dieser verteilte Ansatz verbessert die Stattdessen verteilt es die Metadaten durch eine Netzwerktechnologie, die sich
Verfügbar- und Skalierbarkeit, da bei Dateisystemen wie Lustre, der Elastic-Hashing nennt. Dieser verteilte Ansatz verbessert die Verfügbar- und
Metadatenserver häufigt zum Flaschenhals wird. Das Dateisystem lässt sich im Skalierbarkeit, da bei Dateisystemen wie Lustre, der Metadatenserver häufig zum
laufenden Betrieb um weitere Nodes erweitern. GlusterFS kann auf beliebige Dateisysteme Flaschenhals wird. Das Dateisystem lässt sich im laufenden Betrieb um weitere
aufgesetzt werden, was die Wiederherstellung im Falle eines Absturzes Nodes erweitern. GlusterFS kann auf beliebige Dateisysteme aufgesetzt werden,
vereinfacht. Der einzigste Nachteil, der uns aufgefallen ist, was die Wiederherstellung im Falle eines Absturzes vereinfacht. Der einzigste
ist das GlusterFS auf Basis von Fuse im User-Space implementiert ist, was Nachteil, der uns aufgefallen ist, ist das GlusterFS auf Basis von Fuse im
potentiell langsamer als eine entsprechende Kernel-Implementierung ist. User-Space implementiert ist, was potentiell langsamer als eine entsprechende
Kernel-Implementierung ist.
Als Dateisystem für GlusterFS wird xfs empfohlen. Dafür haben wir mit fstab eine Als Dateisystem für GlusterFS wird XFS empfohlen. Dafür haben wir eine 50GB
50GB Partition angelegt, diese mit folgenden Befehl formatiert. Partition angelegt, diese mit Befehl:
\shellcmd{mkfs.xfs -i size=512 /dev/sda5} \shellcmd{mkfs.xfs -i size=512 /dev/sda5}
und nach \emph{/mnt/glusterfs} gemountet (siehe aufgabe3.3/fstab). Nach dem Starten des formatiert und nach \emph{/mnt/glusterfs} gemountet (siehe aufgabe3.3/fstab).
GlusterFS-Dienstes, sowohl auf Head- und Computenode: Nach dem Starten des GlusterFS-Dienstes, sowohl auf Head- und Computenode:
\shellcmd{systemctl enable glusterfs.service} \shellcmd{systemctl enable glusterfs.service}
@ -52,15 +54,14 @@ Letztendlich mounten wir das GlusterFS mit folgenden Eintrag in der \emph{aufgab
zotac0:/gv0 /fastfs glusterfs defaults 0 0 zotac0:/gv0 /fastfs glusterfs defaults 0 0
\end{center} \end{center}
Um die Schreibrate zu ermitteln, verwendeten wir den Befehl \emph{dd}: Um die Schreibdurchsatz zu ermitteln, verwendeten wir den Befehl \emph{dd}:
\shellcmd{dd bs=1M count=512 if=/dev/zero of=/path/to/file conv=fdatasync} \shellcmd{dd bs=1M count=512 if=/dev/zero of=/path/to/file conv=fdatasync}
um einen 512MB Block auf die Festplatte. Die Option \emph{conv=fdatasync} sorgt um einen 512MB Block auf die Festplatte. Die Option \emph{conv=fdatasync} sorgt
für einen Dateisystem-Sync nach dem Schreiben um die korrekte Schreibrate zu für einen Dateisystem-Sync nach dem Schreiben um die korrekte Schreibrate zu
ermitteln. ermitteln. Für die Leserate haben wir folgenden Befehl benutzt um dieselbige
Für Leserate haben wir folgenden Befehl benutzt um dieselbige erstellte Datei zu erstellte Datei zu lesen:
lesen:
\shellcmd{dd bs=1M count=512 if=/path/to/file of=/dev/null conv=fdatasync} \shellcmd{dd bs=1M count=512 if=/path/to/file of=/dev/null conv=fdatasync}
@ -70,8 +71,9 @@ diesem vor jedem Durchlauf geleert:
\shellcmd{sync; echo 3 | tee /proc/sys/vm/drop\_caches} \shellcmd{sync; echo 3 | tee /proc/sys/vm/drop\_caches}
Die Tests wurden auf dem Host zotac1 ausgeführt, wobei {\emph Lokal}, dem Die Tests wurden auf dem Host zotac1 ausgeführt, wobei {\emph Lokal}, dem
lokalen Ext4-Dateisystem entspricht, NFS dem gemounten NFS von zotac0 und GlusterFS, dem lokalen Ext4-Dateisystem entspricht, NFS dem gemounten NFS von zotac0 und
Dateisystem in /fastfs entspricht. Die Rohdaten befinden sich in \emph{aufgabe3.3/benchmark.txt} GlusterFS, dem Dateisystem im Pfad \emph{/fastfs} entspricht. Die Rohdaten
befinden sich in \emph{aufgabe3.3/benchmark.txt}
\pgfplotsset{ \pgfplotsset{
select row/.style={ select row/.style={
@ -133,8 +135,8 @@ Dateisystem in /fastfs entspricht. Die Rohdaten befinden sich in \emph{aufgabe3.
\end{tikzpicture} \end{tikzpicture}
Das lokale Dateisystem war wie zu erwarten sowohl beim Lesen als auch beim Das lokale Dateisystem war wie zu erwarten sowohl beim Lesen als auch beim
Schreiben das schnellste Dateisystem. Der offensichtliche Nachteil, dieser Schreiben das schnellste Dateisystem. Der offensichtliche Nachteil dieser
Methode, ist das nur die Node selber Zugriff auf diese Daten hat und die Daten Methode ist, dass nur die Node selber Zugriff auf diese Daten hat und die Daten
nicht größer als der lokale Speicher werden kann. nicht größer als der lokale Speicher werden kann.
Während beim Schreiben GlusterFS einen höheren Durchsatz verzeichnen konnte, Während beim Schreiben GlusterFS einen höheren Durchsatz verzeichnen konnte,

View File

@ -2,14 +2,24 @@
\subsubsection{Grundkonfiguration} \subsubsection{Grundkonfiguration}
\begin{sloppypar} Beim Systemstart wird der Dienst \emph{iptables.service} gestartet und die
Beim Systemstart wird der Dienst \emph{iptables.service} gestartet und die Filterregeln aus der \emph{/etc/iptables/iptables.rules} (siehe \emph{aufgabe3.1/iptables.rules}) übernommen. Diese wurde so konfiguriert, dass bestehende Verbindungen, sowie Verbindungen im internen LAN automatisch erlaubt werden. Der Zugriff von außerhalb ist auf den Port 22 beschränkt. Zusätzlich ist \emph{icmp} erlaubt. Zur Absicherung gegen BruteForce verwenden wird \emph{sshguard}, für das wir einen eigene Chain \emph{sshguard} in der \emph{iptables.rules} eingetragen haben. Alle Zugriffe auf Port 22 werden an diese Chain übergeben. Erfolgen in kurzer Zeit zu viele unautorisierte Zugriffe, trägt das Programm \emph{sshguard} automatisch temporär eine neue DROP-Regel in die \emph{sshguard}-Chain ein. Verbindungen nach außen werden alle durchgelassen, weil es nicht effektiv ist, einzelne Ports zu sperren, da ein Angreifer einfach auf anderen Ports Pakete versenden könnte. Filterregeln aus der Datei \emph{/etc/iptables/iptables.rules} (siehe
\end{sloppypar} \emph{aufgabe3.1/iptables.rules}) übernommen. Diese wurde so konfiguriert, dass
bestehende Verbindungen sowie Verbindungen im internen LAN automatisch erlaubt
werden. Der Zugriff von außerhalb ist auf den Port 22 beschränkt. Zusätzlich ist
\emph{Icmp} erlaubt. Zur Absicherung gegen Brute-Force-Angriffe wird der Dienst
\emph{SSH-Guard} verwendet. Für SSH-Guard haben wir eine eigene Chain
mit dem Namen \emph{sshguard} in der \emph{iptables.rules} eingetragen. Alle Zugriffe
auf Port 22 werden durch diese Chain gefiltert. Erfolgen in kurzer Zeit zu viele
unautorisierte Zugriffe, trägt das Programm \emph{SSH-Guard} automatisch temporär
eine neue DROP-Regel in die \emph{sshguard}-Chain ein. Verbindungen nach außen
werden ungefiltert durchgelassen, weil es nicht effektiv ist, einzelne Ports zu
sperren. Ein in das System bereits eingedrungener Angreifer könnte einfach
Pakete auf anderen offenen Ports versenden.
\subsubsection{Forwarding und Masquerading} \subsubsection{Forwarding und Masquerading}
Das Internet wird durch folgende Regel in der NAT-Tabelle: Der Zugriff auf das Internet wird durch folgende Regel in der NAT-Tabelle:
\begin{lstlisting} \begin{lstlisting}
-A POSTROUTING -o eth0 -j MASQUERADE -A POSTROUTING -o eth0 -j MASQUERADE
@ -32,5 +42,5 @@ Alle abgeblockten Verbindungen landen in der \emph{logging}-Chain, wo sie durch:
-A logging -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4 -A logging -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
\end{lstlisting} \end{lstlisting}
geloggt werden. Die Anzahl der Meldungen haben wir auf 2 pro Minute limitiert. Der Log kann unter \emph{/var/log/iptables.log} gefunden werden. geloggt werden. Die Anzahl der Meldungen wurde auf 2 Meldungen pro Minute
limitiert. Der Log wird in der Datei \emph{/var/log/iptables.log} gespeichert.

View File

@ -2,7 +2,8 @@
\label{sub:ldap} \label{sub:ldap}
\begin{sloppypar} \begin{sloppypar}
Wir haben uns für den OpenLDAP-Server entschieden. Dazu haben wir als Basis-\emph{dn}: Wir haben uns für den OpenLDAP-Server entschieden. Dazu haben wir als
Basis-\emph{DN} (Distinguished Name):
\begin{center} \begin{center}
\emph{dc=zotac,dc=lctp} \emph{dc=zotac,dc=lctp}
\end{center} festgelegt. \end{center} festgelegt.
@ -14,9 +15,9 @@ die Gruppen unter
\begin{center} \begin{center}
\emph{dn: ou=groups,dc=zotac,dc=lctp} \emph{dn: ou=groups,dc=zotac,dc=lctp}
\end{center} \end{center}
ab. Für den Import dieser \emph{dn}s haben wir eine Datei ab. Für den Import dieser \emph{DN}s haben wir eine Datei
\emph{/etc/openldap/base.ldif} (siehe \emph{aufgabe3.5/base.ldif}) erstellt. An \emph{/etc/openldap/base.ldif} (siehe \emph{aufgabe3.5/base.ldif}) erstellt. An
verfügbaren Schemen haben wir \emph{core, cosine, inetorgperson, nis} verfügbaren Schemata haben wir \emph{core, cosine, inetorgperson, nis}
eingestellt (siehe \emph{aufgabe3.5/slapd.conf}). eingestellt (siehe \emph{aufgabe3.5/slapd.conf}).
\end{sloppypar} \end{sloppypar}
@ -24,13 +25,14 @@ eingestellt (siehe \emph{aufgabe3.5/slapd.conf}).
\subsubsection{Absicherung und Zugriff} \subsubsection{Absicherung und Zugriff}
Wir haben die Zugriffsrechte so konfiguriert, dass jeder Benutzer sein eigenes Wir haben die Zugriffsrechte so konfiguriert, dass jeder Benutzer sein eigenes
Passwort ändern, aber niemand das Passwort auslesen darf (darf nur zur Passwort ändern, aber niemand das Passwort auslesen darf. Dieses wird nur für
Authentifizierung abgerufen werden). Alle anderen Attribute dürfen von allen zur Authentifizierung abgerufen werden. Alle anderen Attribute dürfen von allen
Users gelesen werden. (siehe \emph{aufgabe3.5/slapd.conf}) Users gelesen werden. (siehe \emph{aufgabe3.5/slapd.conf})
Damit auf den Verzeichnisdienst zugegriffen werden kann, haben wir eine Datei Um auf den Verzeichnisdienst zugreifen zu können, haben wir eine Datei
\emph{/etc/ldap.secret} mit dem Passwort für den Administrator-Account in LDAP \emph{/etc/ldap.secret} mit dem Passwort für den Administrator-Account in LDAP
angelegt, die nur durch \emph{root} zugreifbar ist (\emph{chmod 600}). angelegt, die nur durch \emph{root}-Benutzer zugreifbar ist
(Verzeichnisberechtigung $600_8$).
\subsubsection{Client-Konfiguration (Headnode und Computenode)} \subsubsection{Client-Konfiguration (Headnode und Computenode)}
@ -89,22 +91,33 @@ trägt den eigenen Public-Key in die \emph{authorized\_keys} ein, so dass der Be
\paragraph{Anlegen und Löschen von Benutzern} \paragraph{Anlegen und Löschen von Benutzern}
Zum Anlegen und Löschen von Benutzern aus einer Text-Datei (wie in der Aufgabe Zum Anlegen und Löschen von Benutzern aus einer Text-Datei (wie in der Aufgabe
gefordert) haben wir die Scripte \emph{ldap-users2ldif} (erstellt einen gefordert) haben wir die Scripte \emph{ldap-users2ldif} (gibt auf der
\emph{.ldif} Output anhand der Text-Datei), \emph{ldap-add-ldif} (fügt die im Standardausgabe die Daten im LDIF-Format aus anhand der Text-Datei),
\emph{.ldif} Format vorliegenden Benutzerbeschreibungen zur LDAP-Datenbank \emph{ldap-add-ldif} (fügt die im LDIF-Format vorliegenden
hinzu) und \emph{ldap-delete-users} (löscht die in einer Text-Datei Benutzerbeschreibungen zur LDAP-Datenbank hinzu) und \emph{ldap-delete-users}
aufgelisteten Benutzer aus der LDAP-Datenbank) geschrieben (siehe Dateien in (löscht die in einer Text-Datei aufgelisteten Benutzer aus der LDAP-Datenbank)
\emph{aufgabe3.5/ldap-tools}). geschrieben (siehe Dateien in \emph{aufgabe3.5/ldap-tools}).
Für eine Datei, z.B. \emph{user.txt}, die die hinzuzufügenden Benutzernamen zeilenweise enthält: Vorgehen um Systembenutzer zu erstellen, welche sich zeilenweise in einer Datei
befinden (in diesem Beispiel heißt die Datei \emph{user.txt}):
\begin{itemize} \begin{itemize}
\item \emph{sudo ldap-users2ldif user.txt > user.txt.ldif} \\ \item \emph{sudo ldap-users2ldif user.txt > user.txt.ldif} \\
erstellt eine \emph{.ldif}-Datei; erstellt außerdem \emph{user.txt.passwords}, die die Benutzernamen und Passwörter zeilenweise enthält; die Benutzernamen werden escaped (nur Kleinbuchstaben, Zahlen und »\_«, invalide Zeichen durch »\_« ersetzt, »\_« am Anfang und am Ende gestript); Passwörter zufällig erzeugt (mindestens jeweils ein Großbuchstabe, Kleinbuchstabe, Sonderzeichen und mindestens eine Zahl, zwischen 10 und 16 Zeichen lang); bereits existierende Benutzer oder doppelt vorkommende Nutzer werden mit einer Warnmeldung quittiert und ignoriert \begin{itemize}
\item erstellt eine \emph{.ldif}-Datei
\item erstellt außerdem \emph{user.txt.passwords}, die die Benutzernamen und Passwörter zeilenweise enthält
\item die Benutzernamen werden escaped (nur Kleinbuchstaben, Zahlen und »\_«, invalide Zeichen durch »\_« ersetzt, »\_« am Anfang und am Ende gestript)
\item Passwörter werden zufällig erzeugt (mindestens jeweils ein Großbuchstabe, Kleinbuchstabe, Sonderzeichen und mindestens eine Zahl, zwischen 10 und 16 Zeichen lang)
\item bereits existierende Benutzer oder doppelt vorkommende Nutzer werden mit einer Warnmeldung quittiert und ignoriert
\end{itemize}
\item \emph{sudo ldap-add-ldif user.txt.ldif} \\ \item \emph{sudo ldap-add-ldif user.txt.ldif} \\
fügt die \emph{.ldif}-Datei zu LDAP hinzu \begin{itemize}
\item fügt die \emph{.ldif}-Datei zu LDAP hinzu
\end{itemize}
\item \emph{sudo ldap-delete-users user.txt.passwords} \\ \item \emph{sudo ldap-delete-users user.txt.passwords} \\
löscht die in der erzeugten Datei \emph{user.txt.passwords} zeilenweise aufgelisteten Benutzer und entfernt ihr Home-Verzeichnis (diese Datei ist notwendig, weil die Benutzernamen unter Umständen escaped wurden) \begin{itemize}
\item löscht die in der erzeugten Datei \emph{user.txt.passwords} zeilenweise aufgelisteten Benutzer und entfernt ihr Home-Verzeichnis (diese Datei ist notwendig, weil die Benutzernamen unter Umständen escaped wurden)
\end{itemize}
\end{itemize} \end{itemize}

View File

@ -1,6 +1,6 @@
\subsection{NTP} \subsection{NTP}
Auf dem Head-Node wurde der Server \emph{time.zih.tu-dresden.de} als Zeitserver eingetragen und die folgende Zeile eingefügt: Auf dem Head-Node wurde der NTP-Server der TU-Dresden mit der Domain \emph{time.zih.tu-dresden.de} als Zeitserver eingetragen und die folgende Zeile eingefügt:
\begin{lstlisting} \begin{lstlisting}
restrict 10.20.0.0 mask 255.255.255.0 nomodify notrap nopeer restrict 10.20.0.0 mask 255.255.255.0 nomodify notrap nopeer