Mic92/ltcp
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Korrekturlesen: Praxisteil

Browse Source
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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
bericht/batch/bat-installation.tex
View File

@ -8,7 +8,7 @@ Dazu richteten wir den empfohlenen
dem Head-Node erstellten Schlüssel auf die anderen Nodes
(\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:
\shellcmd{sudo usermod -u 992 slurm}

15
bericht/batch/bat-konfiguration.tex
View File

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

5
bericht/batch/bat-maui.tex
View File

@ -1,9 +1,8 @@
\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, so dass selbst die SLURM-Entwickler hierzu keine Dokumentation
anbieten:
eigenen Scheduler mitbringt und Maui 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

2
bericht/bench/bench-imb.tex
View File

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

13
bericht/bench/bench-iozone.tex
View File

@ -27,7 +27,8 @@ Testaufruf:
\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}
@ -36,13 +37,13 @@ Die Lesegeschwindigkeit von NFS entspricht mit als Maximalwert gemessenen 109 Mi
\shellcmd{hdparm -t /dev/sda}
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
gleich auf. Die Schreibgeschwindigkeit 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
Schreiboperation 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.
Schreiboperation es etliche Kontextwechsel und Kopiervorgänge gibt, um die Daten
auf den anderen Nodes verteilt schreiben zu können. Zusätzlich stellen hier
also auch die Atom-Prozessoren durch ihre begrenze Leistungsfähigkeit einen
limitierenden Faktor dar.

6
bericht/bs/bs-git.tex
View File

@ -28,7 +28,7 @@ Das lctp-Repository wiederum lässt sich mit folgendem Befehl klonen:
\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}:
\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
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
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

2
bericht/bs/bs-pdsh.tex
View File

@ -13,7 +13,7 @@ unserem Fall Head-Node und Compute-Nodes) 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
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
\emph{/usr/local/bin}, das die genannte Umgebungsvariable setzt (siehe
\emph{aufgabe2.5/pdsh}).

4
bericht/bs/bs-ssh.tex
View File

@ -23,8 +23,8 @@ den SSH-Port 22 beschränkt.
\subsubsection{Absicherung für externen Zugriff}
Um den Zugriff aus einem externen Netz abzusichern, gibt es verschiedene
Möglichkeiten
Um das Cluster gegen 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

18
bericht/bs/bs.tex
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.
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
IP-Adresse mittels \emph{netctl} konfiguriert. Damit waren sowohl die Head-Node
Nach dem erfolgreichen Reboot haben wir das Netzwerk auf eine statische
IP-Adresse mittels \emph{netctl} konfiguriert. Damit waren sowohl der Head-Node
als auch der erste Compute-Node grundsätzlich einsatzfähig.
\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/computenode/internal}).
Auf dem Head-Node mussten wir noch mittels \emph{iptables} das \texttt{
MASQUERADE}-Target in der \emph{POSTROUTING}-Chain in der \emph{nat}-Tabelle auf
dem \emph{eth0}-Interface setzen (siehe \emph{aufgabe2.3/iptables.rules}) und mit
\emph{sysctl} (\emph{/etc/sysctl.d}) die Option \emph{net.ipv4.ip\_forward = 1}
(siehe \emph{aufgabe2.2/10-ip-forward-conf}) freischalten, damit die Compute-Nodes auch auf das Internet zugreifen können (Paketinstallationen, Updates, etc.).
Auf dem Head-Node mussten wir noch mittels \emph{iptables} das
\texttt{MASQUERADE}-Target in der \emph{POSTROUTING}-Chain in der
\emph{nat}-Tabelle auf dem \emph{eth0}-Interface setzen (siehe
\emph{aufgabe2.3/iptables.rules}) und mit \emph{sysctl} (\emph{/etc/sysctl.d})
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}

2
bericht/burnin.tex
View File

@ -5,7 +5,7 @@
\label{sub:munin}
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
bereitstellt. Die Darstellung erfolgt über ein Webinterface, welches die Graphen
aus einer \emph{Rddtool}-Datenbank generiert. Auf dem Head-Node haben wir den

4
bericht/prov/prov-backup.tex
View File

@ -5,10 +5,10 @@ Wir haben uns für \href{http://www.rsnapshot.org/}{Rsnapshot} aus folgenden Gr
\begin{itemize}
\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.
\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.
\item Programme wie duplicity speichern die Differenz zum alten Stand als
Delta ab. Diese Kette von Revisionen müssen beim Wiedereinspielen angewendet

2
bericht/prov/prov-compiler.tex
View File

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

38
bericht/prov/prov-provisioning.tex
View File

@ -5,12 +5,11 @@
\begin{sloppypar}
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.
Für die Provisionierung wurde Clonezilla verwendet. 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 Compute-Nodes zu booten, haben wir den
\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
\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}
cluster add <HOSTNAME> <IP> <MAC>
\end{lstlisting}
@ -29,7 +29,7 @@ cluster set-<MODE> <HOSTNAME>
\end{lstlisting}
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
Clonezilla Image), \emph{clone} (Klonen nach Boot) und \emph{restore} (Image
laden nach Boot) gewechselt werden.
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}
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 Head-Node ein Script und führt es
aus. In diesem Script haben wir alle nötigen Befehle eingetragen, um das Clonen
Um den Klonvorgang zu starten, führten wir den Befehl \texttt{sudo cluster
set-clone <HOSTNAME>} aus. Durch Neustart des Nodes wird das Clonezilla Live
Image gebootet. Dieses holt sich nun vom Head-Node ein Script und führt es aus.
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
NFS das \emph{/cluster}-Verzeichnis des Head-Nodes eingebunden und dort im
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
<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.
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 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
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
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
\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
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.
/dev/null} erstellt. Dadurch wird verhindert, dass das Ethernet-Interface nicht nach
dem neuen Schema enpXsY, sondern fest den Namen eth0 erhält.
\end{sloppypar}

22
bericht/sv/sv-dhcp_dns.tex
View File

@ -21,9 +21,9 @@ 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 mitgeteilt bekommen. Die IP-Adresse löst der DHCP-Server über
den lokalen DNS-Server auf.
IP-Adresse entsprechend ihrer MAC-Adresse zugewiesen 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 beim Starten und
@ -40,7 +40,7 @@ Wobei \emph{eth1} der Name des Interface ist, das am internen LAN angeschlossen
\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
\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}
\label{ssub:dns}
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
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.

32
bericht/sv/sv-filesystems.tex
View File

@ -5,30 +5,30 @@
\label{ssub:nfs}
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.
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
ü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
\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. 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 einzige
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.
Wir haben uns für GlusterFS als verteiltes Dateisystem 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 einzige 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:
@ -54,7 +54,7 @@ Letztendlich mounten wir das GlusterFS mit folgenden Eintrag in der \emph{aufgab
zotac0:/gv0 /fastfs glusterfs defaults 0 0
\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}
@ -71,7 +71,7 @@ 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
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}

2
bericht/sv/sv-iptables.tex
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
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{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

17
bericht/sv/sv-ldap.tex
View File

@ -25,9 +25,9 @@ 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. 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})
Passwort ändern kann, 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})
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
@ -72,7 +72,7 @@ folgende Dateien geändert (siehe Dateien in \emph{aufgabe3.5/pam.d}):
\begin{lstlisting}
password sufficient pam_ldap.so
\end{lstlisting}
\end{itemize}
\begin{sloppypar}
@ -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.
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
die Gruppe des Verzeichnisses entsprechend, erzeugt ein Public-Private-Key-Paar
für SSH, kopiert eine Beispiel-SSH-Konfiguration in sein 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.
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.
\end{sloppypar}
\paragraph{Anlegen und Löschen von Benutzern}

2
bericht/sv/sv-ntp.tex
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
\end{lstlisting}
Auf dem Compute-Node wurde \emph{zotac0} als Zeitserver eingetragen.
Auf dem Compute-Node wurde \emph{zotac0} als Zeitserver eingestellt.