Korrekturlesen: Praxisteil
This commit is contained in:
parent
39c78d41fd
commit
65353f89eb
|
|
@ -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}
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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}
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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}).
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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}
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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}
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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}
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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}
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in New Issue