Korrekturlesen: 1. Anlauf

master
Jörg Thalheim 9 years ago
parent 9cd1f7e26b
commit 62ad17d07a

@ -34,8 +34,6 @@
:internal - [0:0]
-A uni -j internal
-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

@ -1,10 +1,10 @@
\subsection{Installation des Batchsystems}
Aus dem AUR (\ref{sec:aur}) installierten wir
\href{http://www.schedmd.com/#index}{SLURM} in der Version 2.6.3.
SLURM benötigt für die Authentifizierung zwischen den Nodes einen externen Dienst.
\href{http://www.schedmd.com/#index}{SLURM} in der Version 2.6.3. SLURM
benötigt für die Authentifizierung zwischen den Nodes einen externen Dienst.
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
(\emph{/etc/munge/munge.key}).

@ -1,5 +1,10 @@
\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}}

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

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

@ -35,6 +35,14 @@ Die Lesegeschwindigkeit von NFS entspricht mit als Maximalwert gemessenen 109 Mi
\shellcmd{hdparm -t /dev/sda}
Die Schreibegeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa der Leistungsfähig 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.
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
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.

@ -1,8 +1,11 @@
\subsection{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.
Die Authentifizierung erfolgt dabei über SSH-Keys. Hier für wird ein \emph{git} Nutzer eingerichtet:
Zur Verwaltung von \emph{Git} haben wir uns für
\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}
@ -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}
\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{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}.
Um die Konfiguration vom Bericht zu trennen, haben wir uns entschieden, \texttt{
etckeeper} in ein dediziertes Repository (\emph{logs}) pushen und als Submodule
im \emph{lctp}-Repository einzubinden:
Etckeeper legt ein \emph{git}-Repository in \emph{/etc/.git} an und erstellt
Commits bei Änderungen in \emph{/etc}. Um die Konfiguration vom Bericht zu
trennen, haben wir uns entschieden, \texttt{etckeeper} in ein dediziertes
Repository (\emph{logs}) pushen und als Submodule im \emph{lctp}-Repository
einzubinden:
\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})
keine Hooks.
Um dennoch nach Systemaktualisierungen oder Paketinstallationen automatisch die
neue Konfiguration zu commiten haben wir jeweils einen
\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
Shell \emph{/usr/local/bin} für gewöhnlich eine höhere Priorität hat als \texttt{
/usr/bin} werden Programme in diesem Verzeichnis vorrangig ausgeführt. (Die
Wrapper befinden sich in \emph{aufgabe2.4/yaourt} sowie in \emph{aufgabe2.4/pacman}).
Darüber hinaus haben wir das Shell-Script für tägliche automatische Commits,
welches im
Im Gegensatz zu anderen Paketmanagern wie \emph{apt} auf Debian, existieren in
\emph{pacman} (\ref{sec:pacman}) keine Hooks. Um dennoch nach
Systemaktualisierungen oder Paketinstallationen automatisch die neue
Konfiguration zu commiten, haben wir jeweils ein
\href{https://gist.github.com/Mic92/7250403}{Wrapper-Script} für \emph{Pacman}
und \emph{Yaourt} geschrieben und beide in den Pfad \emph{/usr/local/bin}
abgelegt. Da in der Shell \emph{/usr/local/bin} für gewöhnlich eine höhere
Priorität besitzt als \texttt{/usr/bin}, werden Programme in diesem Verzeichnis
vorrangig ausgeführt. Die Wrapper befinden sich in \emph{aufgabe2.4/yaourt}
sowie in \emph{aufgabe2.4/pacman}. Darüber hinaus haben wir das Shell-Script für
tägliche automatische Commits, welches sich im
\href{https://github.com/joeyh/etckeeper/blob/master/debian/cron.daily}{Git-Repository}
(Stand 07.11.2013)
von \emph{etckeeper} liegt, als cronjob installiert (siehe
(Stand 07.11.2013) von \emph{etckeeper} liegt, als Cronjob eingerichtet (siehe
\emph{aufgabe2.4/cron.daily/etckeeper}).
\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.
Dieses Dateiformat eignet sich aus offensichtlichen Gründen nicht um mithilfe
von git verwaltet zu werden. Deswegen haben wir zusätzlich \emph{syslog-ng}
installiert und \emph{journald} so konfiguriert, das dieses ebenfalls in das
syslog schreibt (siehe \emph{aufgabe2.4/journald.conf}).
Für tägliche commits haben wir hierfür das Shell-Script \emph{git-commit-log}
nach \emph{/etc/cron.daily/} installiert (siehe
\emph{aufgabe2.4/cron.daily/git-commit-log}). Dieses pusht die Log-Dateien in das
logs-Repository. Es ist als Submodule im Verzeichnis \emph{logs} im
Archlinux setzt in der Standard-Installation \emph{Journald} als Logging-Daemon
ein. Im Unterschied zu herkömmlichen Syslog-Varianten speichert Journald in
einem eigenen Binärformat ab. Dieses Dateiformat eignet sich aus
offensichtlichen Gründen nicht um mithilfe von git verwaltet zu werden. Deswegen
haben wir zusätzlich \emph{Syslog-ng} installiert und \emph{Journald} so
konfiguriert, das es ebenfalls in das syslog schreibt (siehe
\emph{aufgabe2.4/journald.conf}). Für tägliche commits haben wir hierfür das
Shell-Script \emph{git-commit-log} nach \emph{/etc/cron.daily/} installiert
(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.

@ -1,17 +1,19 @@
\subsection{Parallel Distributed Shell (PDSH)}
\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
vorhanden, deshalb haben wir es über das AUR (siehe \ref{sec:aur}) installiert.
\subsubsection{Gruppenverwaltung}
Zur Verwaltung mehrerer Rechner in Gruppen (in unserem Fall Headnode und
Computenodes) greift \emph{pdsh} auf die Gruppenbeschreibungsdatei \texttt{
/etc/genders} (siehe \emph{aufgabe2.5/genders}) zurück. Dort können mehrere Hosts
in verschiedene Gruppen eingeteilt werden.
Um zu gewährleisten, dass pdsh den richtigen Befehl beim Verbinden benutzt, muss
die Umgebungsvariable \emph{PDS\_RCMD\_TYPE} auf den Wert \emph{ssh} gesetzt sein. Dies
lösten wir durch ein Wrapper-Script in \emph{/usr/local/bin}, das die
genannte Umgebungsvariable setzt (siehe \emph{aufgabe2.5/pdsh}).
\subsubsection{Gruppenverwaltung} Zur Verwaltung mehrerer Rechner in Gruppen (in
unserem Fall Headnode und Computenodes) greift \emph{Pdsh} auf die
Gruppenbeschreibungsdatei \texttt{ /etc/genders} (siehe
\emph{aufgabe2.5/genders}) zurück. Dort können mehrere Hosts in verschiedene
Gruppen eingeteilt werden. Um zu gewährleisten, dass Pdsh den richtigen Befehl
beim Verbinden benutzt, muss die Umgebungsvariable \emph{PDS\_RCMD\_TYPE} auf
den Wert ``ssh'' gesetzt sein. Dies lösten wir durch ein Wrapper-Script in
\emph{/usr/local/bin}, das die genannte Umgebungsvariable setzt (siehe
\emph{aufgabe2.5/pdsh}).

@ -16,14 +16,31 @@ ChallengeResponseAuthentication no
\subsubsection{iptables}
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
\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.
Filter-Chain \emph{uni} zur \emph{iptables.rules} unter \emph{/etc/iptables}
(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}
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}
Das automatisierte Hinzufügen neuer Nutzer haben wir über ein Script \texttt{
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.
Das automatisierte Hinzufügen neuer Nutzer haben wir über ein Script
\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.

@ -5,14 +5,25 @@
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.
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.
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.
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.
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.
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}. 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 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.
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, 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}

@ -4,43 +4,42 @@
\subsection{Munin}
\label{sub:munin}
Zur Überwachung und Aufzeichnung des Systems während des Burnin haben wir \texttt{
munin} eingerichtet. Dieses besteht aus einem Masterprozess, welches die gewünschten
Daten aufzeichnet, und einem Nodeprozess, welches die Daten bereitstellt. Die
Darstellung erfolgt über ein Webinterface, welches die Graphen aus einer
\emph{rddtool}-Datenbank generiert. Auf dem Headnode haben wir den Masterprozess
installiert:
Zur Überwachung und Aufzeichnung des Systems während des Burnin haben wir
\texttt{Munin} eingerichtet. Munit besteht aus einem Masterprozess, welches
die gewünschten Daten aufzeichnet und einem Nodeprozess, welches die Daten
bereitstellt. Die Darstellung erfolgt über ein Webinterface, welches die Graphen
aus einer \emph{Rddtool}-Datenbank generiert. Auf dem Headnode haben wir den
Masterprozess installiert:
\shellcmd{pacman -S munin}
Auf dem Computenode die Nodekomponente:
\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}
Dieser kommuniziert über fastcgi mit Munin um die Graphen
generieren zu lassen. Die nötige Konfiguration befindet sich in \texttt{
aufgabe2.5/nginx}. Die fastcgi-Prozesse von Munin starteten wir mit folgenden
Der Webserver kommuniziert über das FastCGI-Protokoll mit Munin um die Graphen
generieren zu lassen. Die nötige Konfiguration befindet sich in
\texttt{aufgabe2.5/nginx}. Den FastCGI-Prozess von Munin starteten wir mit dem
Befehl:
\shellcmd{systemctl enable 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{
aufgabe2.6/munin.conf}).
Da die Anzahl unserer Nodes verhältnismäßig klein ist, haben wir uns für die
Aktualisierung der Leistungsdaten via \emph{munin-cron} entschieden:
Die abzufragenden Nodes werden in die \emph{munin.conf} eingetragen
(\texttt{aufgabe2.6/munin.conf}). Da die Anzahl unserer Nodes verhältnismäßig
klein ist, haben wir uns für die Aktualisierung der Leistungsdaten mithilfe
\emph{munin-cron} entschieden:
\shellcmd{crontab /etc/munin/munin-cron-entry -u munin}
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
Computenode haben wir folgende Plugins aktiviert:
von dieser Plugins benötigen wiederum für die Datenerfassung andere Programme.
Auf dem Computenode haben wir folgende Plugins aktiviert:
\begin{itemize}
\item cpu
@ -51,7 +50,8 @@ Computenode haben wir folgende Plugins aktiviert:
\item sensors\_temp
\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
@ -90,7 +90,8 @@ Abschließend ist zu sagen, dass der Compute-Node den Burnin ohne nennenswerte A
\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}

@ -458,7 +458,7 @@ werden können. Allerdings ist anzunehmen, dass die Zahl architekturbedingt unte
der von Chef liegt.
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
HP-UX und AIX.

@ -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 2 GiB DDR2-RAM
\item 250 GiB Festplatte
\item einem im Gehäuse bereits vorhandenes Netzteil.
\item ein im Gehäuse bereits vorhandenes Netzteil.
\end{itemize}
\vspace{0.5cm}

@ -1,7 +1,7 @@
\subsection{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}
\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
beschädigt werden. Um dem entgegen zu wirken, werden deswegen in
regelmäßigen Abständen volle Backups erstellt, was wiederum mehr
Speicherplatz benötig.
Speicherplatz benötigt.
\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:
/home/, /etc/, /usr/local/, /cluster/, /srv/, /fastfs/, /var/lib/
Das dafür bereitgestellte NFS ist unter \emph{/backup} gemountet. Die Backups
werden im Unterverzeichnis \emph{rsnapshot} erstellt. Das Backup wird
als cron-job durch die Skripte \emph{/etc/cron.daily/rsnaphot} und
Das dafür bereitgestellte NFS ist unter dem Pfad \emph{/backup} gemountet. Die
Backups werden im Unterverzeichnis \emph{rsnapshot} erstellt. Das Backup wird
als Cron-Job durch die Skripte \emph{/etc/cron.daily/rsnaphot} und
\emph{/etc/cron.weekly/rsnapshot} durchgeführt (vgl.
\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
vorgehalten. Darüber hinaus wurde je ein vollständiges Backup von zotac0 und zotac1
in \emph{/backup} erstellt.
vorgehalten. Darüber hinaus wurde je ein vollständiges Backup von zotac0 und
zotac1 in Verzeichnis \emph{/backup} erstellt.

@ -2,7 +2,7 @@
\label{sub:compiler}
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.
\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/}
\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:
\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}
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.
Der C-Compiler wird mit folgenden Befehl geladen:

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

@ -1,9 +1,12 @@
\subsection{Modules}
\label{sub:modules}
Zu Initialisierung von Modules, haben wir Shell-Skript in
\emph{/etc/profile.d/module.sh} hinterlegt (auch zu finden in aufgabe4.2/module.sh).
Dieses Skript fügt den Pfad \emph{/cluster/modules/all} zum MODULESPATH hinzu,
so dass Module in diesem Verzeichnis geladen werden können. Darüber hinaus wird die Datei \emph{/cluster/modules/rc} als 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 default markiert. Die gesamte Modules-Konfiguration befindet sich in \emph{aufgabe4.2/modules}.
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). Dieses Skript fügt den Pfad \emph{/cluster/modules/all}
zum MODULESPATH hinzu, so dass Module in diesem Verzeichnis geladen werden
können. Darüber hinaus wird die Datei \emph{/cluster/modules/rc} als
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}.

@ -1,13 +1,18 @@
\subsection{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:

@ -5,9 +5,19 @@
\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
\begin{lstlisting}
@ -17,9 +27,18 @@ wird ein neuer Node hinzugefügt (DHCP- und DNS-Eintrag). Mit
\begin{lstlisting}
cluster set-<MODE> <HOSTNAME>
\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}
@ -27,14 +46,38 @@ Um den Netzwerk-Boot zu ermöglichen, haben wir \emph{ pxelinux} unter \emph{ /s
\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}

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

@ -3,7 +3,9 @@
\subsubsection{Server}
\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}
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}
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}
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}
\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:
\begin{center}
@ -51,10 +63,12 @@ ersetzt, damit der bezogene Hostname automatisch persistent (\emph{/etc/hostname
\subsection{DNS}
\label{ssub:dns}
Als DNS-Server haben wir \emph{Bind} installiert und 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
ein Zonefile für die Reverse-DNS-Auflösung \emph{aufgabe3.2/0.20.10.in-appr.arpa}.
Schließlich musste noch die /etc/resolv.conf angepasst werden, so dass der eingerichtete 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.
Als DNS-Server haben wir \emph{Named} aus dem Programmpaket \emph{Bind} installiert und
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 ein Zonefile für die
Reverse-DNS-Auflösung \emph{aufgabe3.2/0.20.10.in-appr.arpa}. Schließlich
musste noch die /etc/resolv.conf angepasst werden, so dass der eingerichtete
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.

@ -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
teilen.
Unter Archlinux ist der NFS-Server im Packet \emph{nfs-utils} zu finden.
Um NFS zu exportieren starten wir auf dem Head-Node den rpc-mountd.service.
Das ID-Mapping übernimmt in unserem Fall der ldap-Dienst (\ref{sub:ldap}).
Auf den Compute-Node wurde jeweils ein Eintrag für die Verzeichnisse \emph{home}
und \emph{cluster} in der fstab angelegt. (siehe \emph{aufgabe3.1/fstab}).
Unter Archlinux ist der NFS-Server im Paket \emph{nfs-utils} zu finden.
Um NFS zu exportieren, starteten wir auf dem Head-Node den rpc-mountd.service.
Das ID-Mapping der symbolischen Benutzer und Gruppen auf die User- und Group-IDs
übernimmt in unserem Fall der LDAP-Dienst (\ref{sub:ldap}). Auf den
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}
\label{ssub:verteiltes_dateisystem}
Als Dateisystem haben wir uns für GlusterFS entschieden. Dieses hat im Vergleich
zu anderen verteilten Dateisystemen keine zentrale Metadaten-Server. Stattdessen
setzt es auf das Elastic-Hashing. Dieser verteilte Ansatz verbessert die
Verfügbar- und Skalierbarkeit, da bei Dateisystemen wie Lustre, der
Metadatenserver häufigt zum Flaschenhals wird. Das Dateisystem lässt sich im
laufenden Betrieb um weitere Nodes erweitern. GlusterFS kann auf beliebige Dateisysteme
aufgesetzt werden, was die Wiederherstellung im Falle eines Absturzes
vereinfacht. Der einzigste Nachteil, der uns aufgefallen ist,
ist das GlusterFS auf Basis von Fuse im 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
50GB Partition angelegt, diese mit folgenden Befehl formatiert.
Als Dateisystem haben wir uns für GlusterFS entschieden. Im Vergleich zu anderen
verteilten Dateisystemen besitzt GlusterFS keine zentrale Metadaten-Server.
Stattdessen verteilt es die Metadaten durch eine Netzwerktechnologie, die sich
Elastic-Hashing nennt. Dieser verteilte Ansatz verbessert die Verfügbar- und
Skalierbarkeit, da bei Dateisystemen wie Lustre, der Metadatenserver häufig zum
Flaschenhals wird. Das Dateisystem lässt sich im laufenden Betrieb um weitere
Nodes erweitern. GlusterFS kann auf beliebige Dateisysteme aufgesetzt werden,
was die Wiederherstellung im Falle eines Absturzes vereinfacht. Der einzigste
Nachteil, der uns aufgefallen ist, ist das GlusterFS auf Basis von Fuse im
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 eine 50GB
Partition angelegt, diese mit Befehl:
\shellcmd{mkfs.xfs -i size=512 /dev/sda5}
und nach \emph{/mnt/glusterfs} gemountet (siehe aufgabe3.3/fstab). Nach dem Starten des
GlusterFS-Dienstes, sowohl auf Head- und Computenode:
formatiert und nach \emph{/mnt/glusterfs} gemountet (siehe aufgabe3.3/fstab).
Nach dem Starten des GlusterFS-Dienstes, sowohl auf Head- und Computenode:
\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
\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}
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
ermitteln.
Für Leserate haben wir folgenden Befehl benutzt um dieselbige erstellte Datei zu
lesen:
ermitteln. Für die Leserate haben wir folgenden Befehl benutzt um dieselbige
erstellte Datei zu lesen:
\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}
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
Dateisystem in /fastfs entspricht. Die Rohdaten befinden sich in \emph{aufgabe3.3/benchmark.txt}
lokalen Ext4-Dateisystem entspricht, NFS dem gemounten NFS von zotac0 und
GlusterFS, dem Dateisystem im Pfad \emph{/fastfs} entspricht. Die Rohdaten
befinden sich in \emph{aufgabe3.3/benchmark.txt}
\pgfplotsset{
select row/.style={
@ -133,8 +135,8 @@ Dateisystem in /fastfs entspricht. Die Rohdaten befinden sich in \emph{aufgabe3.
\end{tikzpicture}
Das lokale Dateisystem war wie zu erwarten sowohl beim Lesen als auch beim
Schreiben das schnellste Dateisystem. Der offensichtliche Nachteil, dieser
Methode, ist das nur die Node selber Zugriff auf diese Daten hat und die Daten
Schreiben das schnellste Dateisystem. Der offensichtliche Nachteil dieser
Methode ist, dass nur die Node selber Zugriff auf diese Daten hat und die Daten
nicht größer als der lokale Speicher werden kann.
Während beim Schreiben GlusterFS einen höheren Durchsatz verzeichnen konnte,

@ -2,14 +2,24 @@
\subsubsection{Grundkonfiguration}
\begin{sloppypar}
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.
\end{sloppypar}
Beim Systemstart wird der Dienst \emph{iptables.service} gestartet und die
Filterregeln aus der Datei \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 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}
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}
-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
\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.

@ -2,7 +2,8 @@
\label{sub:ldap}
\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}
\emph{dc=zotac,dc=lctp}
\end{center} festgelegt.
@ -14,9 +15,9 @@ die Gruppen unter
\begin{center}
\emph{dn: ou=groups,dc=zotac,dc=lctp}
\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
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}).
\end{sloppypar}
@ -24,13 +25,14 @@ eingestellt (siehe \emph{aufgabe3.5/slapd.conf}).
\subsubsection{Absicherung und Zugriff}
Wir haben die Zugriffsrechte so konfiguriert, dass jeder Benutzer sein eigenes
Passwort ändern, aber niemand das Passwort auslesen darf (darf nur zur
Authentifizierung abgerufen werden). Alle anderen Attribute dürfen von allen
Passwort ändern, aber niemand das Passwort auslesen darf. Dieses wird nur für
zur Authentifizierung abgerufen werden. Alle anderen Attribute dürfen von allen
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
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)}
@ -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}
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
\emph{.ldif} Output anhand der Text-Datei), \emph{ldap-add-ldif} (fügt die im
\emph{.ldif} Format vorliegenden Benutzerbeschreibungen zur LDAP-Datenbank
hinzu) und \emph{ldap-delete-users} (löscht die in einer Text-Datei
aufgelisteten Benutzer aus der LDAP-Datenbank) geschrieben (siehe Dateien in
\emph{aufgabe3.5/ldap-tools}).
gefordert) haben wir die Scripte \emph{ldap-users2ldif} (gibt auf der
Standardausgabe die Daten im LDIF-Format aus anhand der Text-Datei),
\emph{ldap-add-ldif} (fügt die im LDIF-Format vorliegenden
Benutzerbeschreibungen zur LDAP-Datenbank hinzu) und \emph{ldap-delete-users}
(löscht die in einer Text-Datei aufgelisteten Benutzer aus der LDAP-Datenbank)
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}
\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} \\
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} \\
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}

@ -1,6 +1,6 @@
\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}
restrict 10.20.0.0 mask 255.255.255.0 nomodify notrap nopeer

Loading…
Cancel
Save