Korrekturlesen: Praxisteil

This commit is contained in:
Jörg Thalheim 2014-04-06 11:41:56 +02:00
parent 39c78d41fd
commit 65353f89eb
18 changed files with 97 additions and 91 deletions

View File

@ -8,7 +8,7 @@ Dazu richteten wir den empfohlenen
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}).
SLURM setzt für die Authentifizierung voraus, das der in der Konfiguration SLURM setzt für die Authentifizierung voraus, dass der in der Konfiguration
festgelegten Nutzer auf allen Systemen die gleiche UID besitzt: festgelegten Nutzer auf allen Systemen die gleiche UID besitzt:
\shellcmd{sudo usermod -u 992 slurm} \shellcmd{sudo usermod -u 992 slurm}

View File

@ -1,12 +1,13 @@
\subsection{Konfiguration} \subsection{Konfiguration}
Die Konfiguration der Queues (in SLURM \texttt{Partitions} genannt) erfolgt über die Die Konfiguration der Queues (in SLURM \texttt{Partitions} genannt) erfolgt über
Konfigurationsdateien im Ordner \emph{/etc/slurm/} (auch zu finden in \emph{aufgabe5.2/slurm}). die Konfigurationsdateien im Ordner \emph{/etc/slurm/} (auch zu finden in
Die Prioritäten wurden in folgender Reihenfolge absteigend vergeben: benchmark, express, small, long \emph{aufgabe5.2/slurm}). Die Prioritäten wurden in folgender Reihenfolge
Die \texttt{benchmark}-Partition bekam die größte Priorität, so das Jobs aus anderen absteigend vergeben: benchmark, express, small, long. Die
Queues angehalten werden. Die anderen Queues wurden umgekehrt proportional zur Zeitdauer \texttt{benchmark}-Partition bekam die größte Priorität, so das Jobs aus anderen
priorisiert. Dadurch werden Nutzer des Batchsystems dazu bewegt Jobs, die Queues angehalten werden. Die anderen Queues wurden umgekehrt proportional zur
weniger Zeit benötigen, den richtige Queue zu zu ordnen. Zeitdauer priorisiert. Dadurch werden Nutzer des Batchsystems dazu bewegt Jobs,
die weniger Zeit benötigen, der richtige Queue zu zuordnen.
Zusätzlich zur Verwaltung der Cores haben wir SLURM für die Verwaltung der GPUs Zusätzlich zur Verwaltung der Cores haben wir SLURM für die Verwaltung der GPUs
konfiguriert. Hierfür haben wir auf die Erweiterung \emph{GRES} zurück gegriffen. Die konfiguriert. Hierfür haben wir auf die Erweiterung \emph{GRES} zurück gegriffen. Die

View File

@ -1,9 +1,8 @@
\subsection{Zusatzaufgabe: Maui} \subsection{Zusatzaufgabe: Maui}
Wir haben uns entschieden, Maui nicht einzurichten, da SLURM bereits einen Wir haben uns entschieden, Maui nicht einzurichten, da SLURM bereits einen
eigenen Scheduler mitbringt und Maui äußerst schwierig einzurichten zu sein eigenen Scheduler mitbringt und Maui schwierig einzurichten zu sein scheint, so
scheint, so dass selbst die SLURM-Entwickler hierzu keine Dokumentation dass selbst die SLURM-Entwickler hierzu keine Dokumentation anbieten:
anbieten:
\epigraph{Maui configuration is quite complicated and is really beyond the scope \epigraph{Maui configuration is quite complicated and is really beyond the scope
of any documents we could supply with of any documents we could supply with

View File

@ -1,6 +1,6 @@
\subsection{Intel MPI Benchmark (IMB)} \subsection{Intel MPI Benchmark (IMB)}
Zur Messung der Kommunikationsleistung wurden die MPI-Test Ping-Pong, Barrier, Allreduce und Alltoall mit variierenden Nachrichtengrößen durchgeführt. Zur Messung der Kommunikationsleistung wurden die MPI-Tests Ping-Pong, Barrier, Allreduce und Alltoall mit variierenden Nachrichtengrößen durchgeführt.
\subsubsection{Ping-Pong} \subsubsection{Ping-Pong}

View File

@ -27,7 +27,8 @@ Testaufruf:
\shellcmd{./iozone -azcR -+q 1 -U /fastfs -f /fastfs/testfile -b excel-fastfs.xls} \shellcmd{./iozone -azcR -+q 1 -U /fastfs -f /fastfs/testfile -b excel-fastfs.xls}
Der Parameter \emph{-+q 1} sorgt für einen Verzögerung zwischen den einzelnen Tests, ohne den der Benchmark fehlerhaft läuft.\\ Der Parameter \emph{-+q 1} sorgt für eine Verzögerung zwischen den einzelnen
Tests. Ist dieser Parameter nicht gesetzt, läuft der Benchmark fehlerhaft durch.\\
\subsubsection{Auswertung} \subsubsection{Auswertung}
@ -36,13 +37,13 @@ Die Lesegeschwindigkeit von NFS entspricht mit als Maximalwert gemessenen 109 Mi
\shellcmd{hdparm -t /dev/sda} \shellcmd{hdparm -t /dev/sda}
Die Schreibgeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa Die Schreibgeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa
der Leistungsfähig der Festplatte entsprechen. der Leistungsfähigkeit der Festplatte entsprechen.
GlusterFS liegt in der Lesegeschwindigkeit von maximal 104 MiB/s etwa mit NFS GlusterFS liegt in der Lesegeschwindigkeit von maximal 104 MiB/s etwa mit NFS
gleich auf. Die Schreibgeschwindigkeit hingegen erreicht lediglich 28 MiB/s und gleich auf. Die Schreibgeschwindigkeit hingegen erreicht lediglich 28 MiB/s und
liegt damit weit hinter NFS. Dies lässt sich im Wesentlichen darauf 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 zurückführen, dass GlusterFS ein FUSE-Dateisystem ist und es deshalb bei jeder
Schreiboperation es etliche Kontextwechsel und Kopiervorgänge gibt, weil die Schreiboperation es etliche Kontextwechsel und Kopiervorgänge gibt, um die Daten
einzelnen Nodes miteinander kommunizieren müssen, um die Daten verteilt auf den anderen Nodes verteilt schreiben zu können. Zusätzlich stellen hier
schreiben zu können. Zusätzlich stellen hier also auch die Atom-Prozessoren also auch die Atom-Prozessoren durch ihre begrenze Leistungsfähigkeit einen
durch ihre begrenze Leistungsfähigkeit einen limitierenden Faktor dar. limitierenden Faktor dar.

View File

@ -28,7 +28,7 @@ Das lctp-Repository wiederum lässt sich mit folgendem Befehl klonen:
\subsubsection{Etckeeper} \subsubsection{Etckeeper}
Um die Konfiguration in \emph{/etc } versionierbar und damit nachvollziehbar zu Um die Konfiguration in \emph{/etc} versionierbar und damit nachvollziehbar zu
machen installierten wir \emph{Etckeeper}: machen installierten wir \emph{Etckeeper}:
\shellcmd{yaourt -S etckeeper \&\& sudo etckeeper init} \shellcmd{yaourt -S etckeeper \&\& sudo etckeeper init}
@ -65,8 +65,8 @@ ein. Im Unterschied zu herkömmlichen Syslog-Varianten speichert Journald in
einem eigenen Binärformat ab. Dieses Dateiformat eignet sich aus einem eigenen Binärformat ab. Dieses Dateiformat eignet sich aus
offensichtlichen Gründen nicht um mithilfe von git verwaltet zu werden. Deswegen offensichtlichen Gründen nicht um mithilfe von git verwaltet zu werden. Deswegen
haben wir zusätzlich \emph{Syslog-ng} installiert und \emph{Journald} so haben wir zusätzlich \emph{Syslog-ng} installiert und \emph{Journald} so
konfiguriert, das es ebenfalls in das syslog schreibt (siehe konfiguriert, das es ebenfalls in das Syslog schreibt (siehe
\emph{aufgabe2.4/journald.conf}). Für tägliche commits haben wir hierfür das \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 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 (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 in das logs-Repository hoch. Es ist als Submodule im Verzeichnis \emph{logs} im

View File

@ -13,7 +13,7 @@ unserem Fall Head-Node und Compute-Nodes) greift \emph{Pdsh} auf die
Gruppenbeschreibungsdatei \texttt{ /etc/genders} (siehe Gruppenbeschreibungsdatei \texttt{ /etc/genders} (siehe
\emph{aufgabe2.5/genders}) zurück. Dort können mehrere Hosts in verschiedene \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 Gruppen eingeteilt werden. Um zu gewährleisten, dass Pdsh den richtigen Befehl
beim Verbinden benutzt, muss die Umgebungsvariable \emph{PDS\_RCMD\_TYPE} auf beim Verbinden verwendet, muss die Umgebungsvariable \emph{PDS\_RCMD\_TYPE} auf
den Wert ``ssh'' gesetzt sein. Dies lösten wir durch ein Wrapper-Script in 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{/usr/local/bin}, das die genannte Umgebungsvariable setzt (siehe
\emph{aufgabe2.5/pdsh}). \emph{aufgabe2.5/pdsh}).

View File

@ -23,8 +23,8 @@ 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, gibt es verschiedene Um das Cluster gegen den Zugriff aus einem externen Netz abzusichern, gibt es verschiedene
Möglichkeiten Möglichkeiten:
\begin{enumerate} \begin{enumerate}
\item den externen SSH-Port auf einen anderen Port als 22 legen, so dass \item den externen SSH-Port auf einen anderen Port als 22 legen, so dass

View File

@ -29,10 +29,10 @@ Wir sind bei der Installation grundlegend nach der Anleitung im \href{https://wi
Die Partitionierung haben wir wie im Cluster-Layout angegeben mit \emph{fdisk} vorgenommen und die Daten-Partitionen jeweils mit \emph{mkfs.ext4} auf \emph{ext4} formatiert. Hier sollte man nicht vergessen, die Boot-Partition in \emph{fdisk} auch als \emph{bootable} zu markieren. Die Partitionierung haben wir wie im Cluster-Layout angegeben mit \emph{fdisk} vorgenommen und die Daten-Partitionen jeweils mit \emph{mkfs.ext4} auf \emph{ext4} formatiert. Hier sollte man nicht vergessen, die Boot-Partition in \emph{fdisk} auch als \emph{bootable} zu markieren.
Nach ursprünglichen Schwierigkeiten mit dem Internet-Zugang im TGI-Labor (keine IP-Adresse über DHCP erhalten), konnten wir dann das Basis-System mittels \emph{pacstrap} installieren und danach mittels \emph{arch-chroot} in dieses wechseln. Dort wurden nach der Anleitung die Sprache, das Konsolen-Tastaturlayout, die Zeitzone, Datum und Uhrzeit und die Hostnames festgelegt sowie den Bootloader \emph{GRUB} installiert und konfiguriert. Nach ursprünglichen Schwierigkeiten mit dem Internet-Zugang im TGI-Labor (keine IP-Adresse über DHCP erhalten), konnten wir dann das Basis-System mittels \emph{pacstrap} installieren und danach mittels \emph{arch-chroot} in dieses wechseln. Dort wurden nach der Anleitung die Sprache, das Konsolen-Tastaturlayout, die Zeitzone, Datum und Uhrzeit und die Hostnames festgelegt sowie der Bootloader \emph{GRUB} installiert und konfiguriert.
Nach dem erfolgreichen Reboot haben wir dann das Netzwerk auf eine statische Nach dem erfolgreichen Reboot haben wir das Netzwerk auf eine statische
IP-Adresse mittels \emph{netctl} konfiguriert. Damit waren sowohl die Head-Node IP-Adresse mittels \emph{netctl} konfiguriert. Damit waren sowohl der Head-Node
als auch der erste Compute-Node grundsätzlich einsatzfähig. als auch der erste Compute-Node grundsätzlich einsatzfähig.
\subsubsection{Netzwerk-Konfiguration} \subsubsection{Netzwerk-Konfiguration}
@ -43,11 +43,13 @@ statische IP-Adresse (wie im Cluster-Layout angegeben) konfiguriert (siehe
\emph{aufgabe2.2/headnode/network} und \emph{aufgabe2.2/headnode/internal} bzw. \emph{aufgabe2.2/headnode/network} und \emph{aufgabe2.2/headnode/internal} bzw.
\emph{aufgabe2.2/computenode/internal}). \emph{aufgabe2.2/computenode/internal}).
Auf dem Head-Node mussten wir noch mittels \emph{iptables} das \texttt{ Auf dem Head-Node mussten wir noch mittels \emph{iptables} das
MASQUERADE}-Target in der \emph{POSTROUTING}-Chain in der \emph{nat}-Tabelle auf \texttt{MASQUERADE}-Target in der \emph{POSTROUTING}-Chain in der
dem \emph{eth0}-Interface setzen (siehe \emph{aufgabe2.3/iptables.rules}) und mit \emph{nat}-Tabelle auf dem \emph{eth0}-Interface setzen (siehe
\emph{sysctl} (\emph{/etc/sysctl.d}) die Option \emph{net.ipv4.ip\_forward = 1} \emph{aufgabe2.3/iptables.rules}) und mit \emph{sysctl} (\emph{/etc/sysctl.d})
(siehe \emph{aufgabe2.2/10-ip-forward-conf}) freischalten, damit die Compute-Nodes auch auf das Internet zugreifen können (Paketinstallationen, Updates, etc.). die Option \emph{net.ipv4.ip\_forward = 1} (siehe
\emph{aufgabe2.2/10-ip-forward-conf}) freischalten, so dass die Compute-Nodes auch
auf das Internet zugreifen können (Paketinstallationen, Updates, etc.).
\input{bs/bs-ssh} \input{bs/bs-ssh}

View File

@ -5,7 +5,7 @@
\label{sub:munin} \label{sub:munin}
Zur Überwachung und Aufzeichnung des Systems während des Burnin haben wir Zur Überwachung und Aufzeichnung des Systems während des Burnin haben wir
\texttt{Munin} eingerichtet. Munit besteht aus einem Masterprozess, welches \texttt{Munin} eingerichtet. Munin besteht aus einem Masterprozess, welches
die gewünschten Daten aufzeichnet und einem Nodeprozess, welches die Daten die gewünschten Daten aufzeichnet und einem Nodeprozess, welches die Daten
bereitstellt. Die Darstellung erfolgt über ein Webinterface, welches die Graphen bereitstellt. Die Darstellung erfolgt über ein Webinterface, welches die Graphen
aus einer \emph{Rddtool}-Datenbank generiert. Auf dem Head-Node haben wir den aus einer \emph{Rddtool}-Datenbank generiert. Auf dem Head-Node haben wir den

View File

@ -5,10 +5,10 @@ Wir haben uns für \href{http://www.rsnapshot.org/}{Rsnapshot} aus folgenden Gr
\begin{itemize} \begin{itemize}
\item Die Backups liegen als Ordner mit den gleichen Rechten wie im zu sichernden System. \item Die Backups liegen als Ordner mit den gleichen Rechten wie im zu sichernden System.
Dies hat den Vorteil, dass andere Nutzer diese einsehen können und Dies hat den Vorteil, dass Nutzer ihre eigenen Daten einsehen können und
selbständig Dateien wiederherstellen können. selbständig Dateien wiederherstellen können.
\item Rsnapshot erstellt differentielle Backups. Dabei werden Dateien, die \item Rsnapshot erstellt differentielle Backups. Dabei werden Dateien, die
sich zum alten Backup sich nicht geändert haben durch Hardlinks in das neue sich zum alten Backup sich nicht geändert haben, durch Hardlinks in das neue
Backup verlinkt. Backup verlinkt.
\item Programme wie duplicity speichern die Differenz zum alten Stand als \item Programme wie duplicity speichern die Differenz zum alten Stand als
Delta ab. Diese Kette von Revisionen müssen beim Wiedereinspielen angewendet Delta ab. Diese Kette von Revisionen müssen beim Wiedereinspielen angewendet

View File

@ -23,7 +23,7 @@ finden. Zwischen den Versionen kann mit folgendem Befehl gewechselt werden:
\subsubsection{Intel Compiler Suite} \subsubsection{Intel Compiler Suite}
\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.

View File

@ -5,12 +5,11 @@
\begin{sloppypar} \begin{sloppypar}
Für die Provisionierung wurde Clonezilla verwendet. Wir haben uns für dieses Für die Provisionierung wurde Clonezilla verwendet. Bei einem Netzwerk-Boot
Verfahren entschieden. Bei einem Netzwerk-Boot beispielsweise, bei dem das beispielsweise, bei dem das gesamte Dateisystem per NFS eingebunden wird, wäre
gesamte Dateisystem per NFS eingebunden wird, wäre in unserem Fall ineffektiv, in unserem Fall ineffektiv, da auf den Festplatten der Compute-Nodes genügend
da auf den Festplatten der Compute-Nodes genügend Speicher für das Speicher für das Betriebssystem vorhanden ist und bei jedem Zugriff auf das
Betriebssystem vorhanden ist und bei jedem Zugriff auf das Dateisystem unnötigen Dateisystem unnötigen Latenzen entstehen würden.
Latenzen entstehen würden.
Um Clonezilla auf den Compute-Nodes zu booten, haben wir den Um Clonezilla auf den Compute-Nodes zu booten, haben wir den
\emph{in.tftpd}-Server installiert und das Service-File für \emph{Systemd} \emph{in.tftpd}-Server installiert und das Service-File für \emph{Systemd}
@ -19,7 +18,8 @@ Konfiguration des DHCP-Servers so angepasst, dass nun jede Compute-Node eine
eigene Konfigurationsdatei in \emph{/etc/dhcpd.d/} hat, die jeweils von eigene Konfigurationsdatei in \emph{/etc/dhcpd.d/} hat, die jeweils von
\emph{/etc/dhcpd.d/all} inkludiert wird. \emph{/etc/dhcpd.d/all} inkludiert wird.
Außerdem haben wir ein Script \emph{ cluster} geschrieben, mit dem die Compute-Nodes verwaltet werden können. Mit Um die Compute-Nodes zu verwalten, haben wir das Script \emph{cluster}
geschrieben. Mit dem Befehl
\begin{lstlisting} \begin{lstlisting}
cluster add <HOSTNAME> <IP> <MAC> cluster add <HOSTNAME> <IP> <MAC>
\end{lstlisting} \end{lstlisting}
@ -29,7 +29,7 @@ cluster set-<MODE> <HOSTNAME>
\end{lstlisting} \end{lstlisting}
kann der Modus für den nächsten Boot des Nodes festgelegt werden. Hier kann 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 zwischen \emph{local} (Boot von lokaler Festplatte), \emph{live} (Boot in das
Clonezilla Image), \emph{clone} (Clonen nach Boot) und \emph{restore} (Image Clonezilla Image), \emph{clone} (Klonen nach Boot) und \emph{restore} (Image
laden nach Boot) gewechselt werden. laden nach Boot) gewechselt werden.
Um den Netzwerk-Boot zu ermöglichen, haben wir \emph{pxelinux} unter Um den Netzwerk-Boot zu ermöglichen, haben wir \emph{pxelinux} unter
@ -46,38 +46,38 @@ Konfigurationsdateien liegen in \emph{/srv/tftp/pxelinux/pxelinux.cfg}.
\begin{sloppypar} \begin{sloppypar}
Um den Clone-Vorgang zu starten, führten wir nun mit dem Befehl \emph{sudo Um den Klonvorgang zu starten, führten wir den Befehl \texttt{sudo cluster
cluster set-clone <HOSTNAME>} aus. Durch Neustart des Nodes wird das Clonezilla set-clone <HOSTNAME>} aus. Durch Neustart des Nodes wird das Clonezilla Live
Live Image gebootet. Dieses holt sich nun vom Head-Node ein Script und führt es Image gebootet. Dieses holt sich nun vom Head-Node ein Script und führt es aus.
aus. In diesem Script haben wir alle nötigen Befehle eingetragen, um das Clonen In diesem Script haben wir alle nötigen Befehle eingetragen, um das Klonen
vorzubereiten und zu starten (siehe \emph{aufgabe4.4/clone.sh}). Dazu wird per vorzubereiten und zu starten (siehe \emph{aufgabe4.4/clone.sh}). Dazu wird per
NFS das \emph{/cluster}-Verzeichnis des Head-Nodes eingebunden und dort im NFS das \emph{/cluster}-Verzeichnis des Head-Nodes eingebunden und dort im
Unterverzeichnis \emph{images} das Image der Festplatte abgelegt. Geklont werden Unterverzeichnis \emph{images} das Image der Festplatte abgelegt. Geklont werden
nur die \emph{/}- und die \emph{/boot}-Partition. die \emph{Root}- und die \emph{Boot}-Partition.
Zum Wiederherstellen des Images wird mit \emph{sudo cluster set-restore Zum Wiederherstellen des Images wird mit \emph{sudo cluster set-restore
<HOSTNAME>} wieder der entsprechende Boot-Modus gesetzt und der Node <HOSTNAME>} wieder der entsprechende Boot-Modus gesetzt und der Node
neu gestartet Dort wird nun ein anderes Script vom Head-Node geholt (siehe \emph{ neu gestartet. Dort wird nun ein anderes Script vom Head-Node geholt (siehe \emph{
aufgabe4.4/restore.sh}) und die beiden Partitionen wiederhergestellt. aufgabe4.4/restore.sh}) und die beiden Partitionen wiederhergestellt.
Anschließend werden noch die Swap-Partition und die Daten-Partition für das Anschließend werden noch die Swap-Partition und die Daten-Partition für das
verteilte Dateisystem neu formatiert und die alten UUIDs gesetzt. verteilte Dateisystem neu formatiert und die alten UUIDs gesetzt.
Da Clonezilla bei uns das Dateisystemformat \emph{ext4} nicht als solches Da Clonezilla bei uns das Dateisystemformat \emph{ext4} nicht als solches
erkannt hat. Es fiel auf das generische Programm \emph{partclone.dd} zurück, erkannt hat, fiel auf das generische Programm \emph{partclone.dd} zurück,
welches allerdings sehr langsam ist, weil es die komplette Partition klont und welches allerdings sehr langsam ist, weil es die komplette Partition klont und
freie Blöcke nicht überspringt. Deswegen haben wir zwei kleine Wrapper-Scripts freie Blöcke nicht überspringt. Deswegen haben wir zwei kleine Wrapper-Scripts
geschrieben.Diese Skripte verwenden stattdessen das schnellere geschrieben.Diese Skripte verwenden stattdessen das schnellere
\emph{partclone.ext4} (siehe \emph{aufgabe4.4/partclone.dd-clone} und \emph{partclone.ext4} (siehe \emph{aufgabe4.4/partclone.dd-clone} und
\emph{partclone.dd-restore}). \emph{partclone.dd-restore}).
Da wir in unserem Cluster gemischte Boards haben (Intel und Zotac), mussten wir Da in unserem Cluster gemischte Boards (Intel und Zotac) sind, mussten wir
anschließend außerdem noch das Ziel-Root-Verzeichnis mounten und dort mit Befehl 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 \emph{mkinitcpio -p linux} ein neue Init-Ramdisk erstellen lassen, welches die
entsprechenden Treiber für Bootvorgang enthält. entsprechenden Treiber für den Bootvorgang enthält.
Um die automatische Umbenennung der Netzwerk-Interfaces vorzubeugen, haben wir Um die automatische Umbenennung der Netzwerk-Interfaces vorzubeugen, haben wir
außerdem einen Symlink \emph{/etc/udev/rules.d/80-net-name-slot.rules -> 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 /dev/null} erstellt. Dadurch wird verhindert, dass das Ethernet-Interface nicht nach
dem neuen Schema enpXsY sondern fest den Namen eth0 erhalten. dem neuen Schema enpXsY, sondern fest den Namen eth0 erhält.
\end{sloppypar} \end{sloppypar}

View File

@ -21,9 +21,9 @@ host zotac<X> {
\end{lstlisting} \end{lstlisting}
Damit ist sichergestellt, dass die Hosts die im Cluster-Layout spezifizierte Damit ist sichergestellt, dass die Hosts die im Cluster-Layout spezifizierte
IP-Adresse entsprechend ihrer MAC-Adresse zugewiesen bekommen und gleichzeitig IP-Adresse entsprechend ihrer MAC-Adresse zugewiesen und gleichzeitig ihren
ihren Hostnamen mitgeteilt bekommen. Die IP-Adresse löst der DHCP-Server über Hostnamen mitgeteilt bekommen. Die IP-Adresse löst der DHCP-Server über den
den lokalen DNS-Server auf. lokalen DNS-Server auf.
Zusätzlich haben wir das bereits in der Installation enthaltene Zusätzlich haben wir das bereits in der Installation enthaltene
\emph{Systemd}-Service-File entsprechend so angepasst, dass beim Starten und \emph{Systemd}-Service-File entsprechend so angepasst, dass beim Starten und
@ -40,7 +40,7 @@ Wobei \emph{eth1} der Name des Interface ist, das am internen LAN angeschlossen
\begin{sloppypar} \begin{sloppypar}
Als Client verwenden wir \emph{Dhcpcd}. Als Client verwenden wir den \emph{Dhcpcd}.
Um den Hostnamen per DHCP zu setzen, mussten wir in Um den Hostnamen per DHCP zu setzen, mussten wir in
\emph{/usr/lib/dhcpcd/dhcpcd-hooks/30-hostname} (siehe \emph{/usr/lib/dhcpcd/dhcpcd-hooks/30-hostname} (siehe
@ -63,12 +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{Named} aus dem Programmpaket \emph{Bind} installiert und Als DNS-Server haben wir \emph{Named} aus dem Programmpaket \emph{Bind}
eingerichtet. Die Konfiguration ist in \emph{aufgabe3.2/named.conf} zu finden. installiert und eingerichtet. Die Konfiguration ist in
Für das Auflösen der Hostnames haben wir die Domaine zotac \emph{aufgabe3.2/named.conf} zu finden. Für das Auflösen der Hostnames haben
\emph{aufgabe3.2/zotac.zone} angelegt und ein Zonefile für die wir die Domaine zotac (\emph{aufgabe3.2/zotac.zone}) angelegt und ein Zonefile
Reverse-DNS-Auflösung \emph{aufgabe3.2/0.20.10.in-appr.arpa}. Schließlich für die Reverse-DNS-Auflösung \emph{aufgabe3.2/0.20.10.in-appr.arpa}.
musste noch die /etc/resolv.conf angepasst werden, so dass der eingerichtete Schließlich musste noch die /etc/resolv.conf angepasst werden, so dass der
Server auch von der Head-Node zur Adress-Auflösung benutzt wird 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 (\emph{aufgabe3.2/resolv.conf}). Die Nodes bekommen die DNS-Einstellungen per
DHCP zugewiesen. DHCP zugewiesen.

View File

@ -5,30 +5,30 @@
\label{ssub:nfs} \label{ssub:nfs}
Wir haben uns für das NFS-Dateisystem entschieden. Dieses ermöglicht 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 dem Head-Node und den Compute-Nodes zu
teilen. teilen.
Unter Archlinux ist der NFS-Server im Paket \emph{nfs-utils} zu finden. 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. Um NFS zu exportieren, starteten wir auf dem Head-Node den \emph{RPC-Mountd}.
Das ID-Mapping der symbolischen Benutzer und Gruppen auf die User- und Group-IDs 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 übernimmt in unserem Fall der LDAP-Dienst (\ref{sub:ldap}). Auf dem
Compute-Node wurde jeweils ein Eintrag für die Verzeichnisse \emph{home} und 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}). \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. Im Vergleich zu anderen Wir haben uns für GlusterFS als verteiltes Dateisystem entschieden. Im Vergleich
verteilten Dateisystemen besitzt GlusterFS keine zentrale Metadaten-Server. zu anderen verteilten Dateisystemen besitzt GlusterFS keine zentrale
Stattdessen verteilt es die Metadaten durch eine Netzwerktechnologie, die sich Metadaten-Server. Stattdessen verteilt es die Metadaten durch eine
Elastic-Hashing nennt. Dieser verteilte Ansatz verbessert die Verfügbar- und Netzwerktechnologie, die sich Elastic-Hashing nennt. Dieser verteilte Ansatz
Skalierbarkeit, da bei Dateisystemen wie Lustre, der Metadatenserver häufig zum verbessert die Verfügbar- und Skalierbarkeit, da bei Dateisystemen wie Lustre,
Flaschenhals wird. Das Dateisystem lässt sich im laufenden Betrieb um weitere der Metadatenserver häufig zum Flaschenhals wird. Das Dateisystem lässt sich im
Nodes erweitern. GlusterFS kann auf beliebige Dateisysteme aufgesetzt werden, laufenden Betrieb um weitere Nodes erweitern. GlusterFS kann auf beliebige
was die Wiederherstellung im Falle eines Absturzes vereinfacht. Der einzige Dateisysteme aufgesetzt werden, was die Wiederherstellung im Falle eines
Nachteil, der uns aufgefallen ist, ist das GlusterFS auf Basis von FUSE im Absturzes vereinfacht. Der einzige Nachteil, der uns aufgefallen ist, ist das
User-Space implementiert ist, was potentiell langsamer als eine entsprechende GlusterFS auf Basis von FUSE im User-Space implementiert ist, was potentiell
Kernel-Implementierung ist. langsamer als eine entsprechende Kernel-Implementierung ist.
Als Dateisystem für GlusterFS wird XFS empfohlen. Dafür haben wir eine 50GB Als Dateisystem für GlusterFS wird XFS empfohlen. Dafür haben wir eine 50GB
Partition angelegt, diese mit Befehl: Partition angelegt, diese mit Befehl:
@ -54,7 +54,7 @@ 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 Schreibdurchsatz zu ermitteln, verwendeten wir den Befehl \emph{dd}: Um den 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}
@ -71,7 +71,7 @@ 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 lokalen Ext4-Dateisystem entspricht, NFS, dem gemounten NFS von zotac0 und
GlusterFS, dem Dateisystem im Pfad \emph{/fastfs} entspricht. Die Rohdaten GlusterFS, dem Dateisystem im Pfad \emph{/fastfs} entspricht. Die Rohdaten
befinden sich in \emph{aufgabe3.3/benchmark.txt} befinden sich in \emph{aufgabe3.3/benchmark.txt}

View File

@ -7,7 +7,7 @@ Filterregeln aus der Datei \emph{/etc/iptables/iptables.rules} (siehe
\emph{aufgabe3.1/iptables.rules}) übernommen. Diese wurde so konfiguriert, dass \emph{aufgabe3.1/iptables.rules}) übernommen. Diese wurde so konfiguriert, dass
bestehende Verbindungen sowie Verbindungen im internen LAN automatisch erlaubt 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 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{ICMP} erlaubt. Zur Absicherung gegen Brute-Force-Angriffe wird der Dienst
\emph{SSH-Guard} verwendet. Für SSH-Guard haben wir eine eigene Chain \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 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 auf Port 22 werden durch diese Chain gefiltert. Erfolgen in kurzer Zeit zu viele

View File

@ -25,9 +25,9 @@ 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. Dieses wird nur für Passwort ändern kann, aber niemand das Passwort auslesen darf. Dieses wird nur
zur Authentifizierung abgerufen werden. Alle anderen Attribute dürfen von allen für zur Authentifizierung abgerufen werden. Alle anderen Attribute dürfen von
Users gelesen werden. (siehe \emph{aufgabe3.5/slapd.conf}) allen Users gelesen werden. (siehe \emph{aufgabe3.5/slapd.conf})
Um auf den Verzeichnisdienst zugreifen zu können, 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
@ -80,12 +80,15 @@ Damit ist sichergestellt, dass sich die LDAP-Benutzter authentifizieren können,
sowie \emph{sudo} und \emph{su} benutzen und ihr Passwort mit \emph{passwd} ändern können. sowie \emph{sudo} und \emph{su} benutzen und ihr Passwort mit \emph{passwd} ändern können.
Durch die Zeile mit \emph{pam\_exec.so} wird bei jedem Login das Script Durch die Zeile mit \emph{pam\_exec.so} wird bei jedem Login das Script
\emph{first-login} (siehe \emph{aufgabe3.5/first-login}) ausgeführt; das ist faktisch das Script aus Aufgabe 2.3, nur angepasst für die Einbindung in PAM. Dieses wird generell nur ausgeführt, wenn das Home-Verzeichnis des Nutzers noch nicht existiert. \emph{first-login} (siehe \emph{aufgabe3.5/first-login}) ausgeführt; das Script
wurde aus Aufgabe 2.3 übernommen und für die Einbindung in PAM angepasst. Es
wird nur ausgeführt, wenn das Home-Verzeichnis des Nutzers noch nicht existiert.
Das Script erstellt das Home-Verzeichnis des Nutzers, ändert den Besitzer und Das Script erstellt das Home-Verzeichnis des Nutzers, ändert den Besitzer und
die Gruppe des Verzeichnisses entsprechend, erzeugt ein Public-Private-Key-Paar die Gruppe des Verzeichnisses entsprechend, erzeugt ein Public-Private-Key-Paar
für SSH, kopiert eine Beispiel-SSH-Konfiguration in sein Home-Verzeichnis und für SSH, kopiert eine Beispiel-SSH-Konfiguration in dessen Home-Verzeichnis und
trägt den eigenen Public-Key in die \emph{authorized\_keys} ein, so dass der Benutzer sich fortan auf allen Nodes einloggen kann. trägt den eigenen Public-Key in die \emph{authorized\_keys} ein, so dass der
Benutzer sich fortan auf allen Nodes einloggen kann.
\end{sloppypar} \end{sloppypar}
\paragraph{Anlegen und Löschen von Benutzern} \paragraph{Anlegen und Löschen von Benutzern}

View File

@ -6,4 +6,4 @@ Auf dem Head-Node wurde der NTP-Server der TU-Dresden mit der Domain \emph{time.
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
\end{lstlisting} \end{lstlisting}
Auf dem Compute-Node wurde \emph{zotac0} als Zeitserver eingetragen. Auf dem Compute-Node wurde \emph{zotac0} als Zeitserver eingestellt.