From 65353f89eb440e4270baa9a4e52a2531e6c4138e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Thalheim?= Date: Sun, 6 Apr 2014 11:41:56 +0200 Subject: [PATCH] Korrekturlesen: Praxisteil --- bericht/batch/bat-installation.tex | 2 +- bericht/batch/bat-konfiguration.tex | 15 ++++++------ bericht/batch/bat-maui.tex | 5 ++-- bericht/bench/bench-imb.tex | 2 +- bericht/bench/bench-iozone.tex | 13 +++++----- bericht/bs/bs-git.tex | 6 ++--- bericht/bs/bs-pdsh.tex | 2 +- bericht/bs/bs-ssh.tex | 4 +-- bericht/bs/bs.tex | 18 ++++++++------ bericht/burnin.tex | 2 +- bericht/prov/prov-backup.tex | 4 +-- bericht/prov/prov-compiler.tex | 2 +- bericht/prov/prov-provisioning.tex | 38 ++++++++++++++--------------- bericht/sv/sv-dhcp_dns.tex | 22 ++++++++--------- bericht/sv/sv-filesystems.tex | 32 ++++++++++++------------ bericht/sv/sv-iptables.tex | 2 +- bericht/sv/sv-ldap.tex | 17 +++++++------ bericht/sv/sv-ntp.tex | 2 +- 18 files changed, 97 insertions(+), 91 deletions(-) diff --git a/bericht/batch/bat-installation.tex b/bericht/batch/bat-installation.tex index 9484e12..24f50c7 100644 --- a/bericht/batch/bat-installation.tex +++ b/bericht/batch/bat-installation.tex @@ -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} diff --git a/bericht/batch/bat-konfiguration.tex b/bericht/batch/bat-konfiguration.tex index b28d64d..792181e 100644 --- a/bericht/batch/bat-konfiguration.tex +++ b/bericht/batch/bat-konfiguration.tex @@ -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 diff --git a/bericht/batch/bat-maui.tex b/bericht/batch/bat-maui.tex index f1a6110..e1e796a 100644 --- a/bericht/batch/bat-maui.tex +++ b/bericht/batch/bat-maui.tex @@ -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 diff --git a/bericht/bench/bench-imb.tex b/bericht/bench/bench-imb.tex index 29d95c5..380cdd7 100644 --- a/bericht/bench/bench-imb.tex +++ b/bericht/bench/bench-imb.tex @@ -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} diff --git a/bericht/bench/bench-iozone.tex b/bericht/bench/bench-iozone.tex index 19b458c..137b3ae 100644 --- a/bericht/bench/bench-iozone.tex +++ b/bericht/bench/bench-iozone.tex @@ -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. diff --git a/bericht/bs/bs-git.tex b/bericht/bs/bs-git.tex index 854dba9..82c9ff2 100644 --- a/bericht/bs/bs-git.tex +++ b/bericht/bs/bs-git.tex @@ -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 diff --git a/bericht/bs/bs-pdsh.tex b/bericht/bs/bs-pdsh.tex index 37d5ef2..8ce81bf 100644 --- a/bericht/bs/bs-pdsh.tex +++ b/bericht/bs/bs-pdsh.tex @@ -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}). diff --git a/bericht/bs/bs-ssh.tex b/bericht/bs/bs-ssh.tex index b391419..827ad54 100644 --- a/bericht/bs/bs-ssh.tex +++ b/bericht/bs/bs-ssh.tex @@ -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 diff --git a/bericht/bs/bs.tex b/bericht/bs/bs.tex index 8c45a3f..5392986 100644 --- a/bericht/bs/bs.tex +++ b/bericht/bs/bs.tex @@ -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} diff --git a/bericht/burnin.tex b/bericht/burnin.tex index d62c03c..443a9d6 100644 --- a/bericht/burnin.tex +++ b/bericht/burnin.tex @@ -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 diff --git a/bericht/prov/prov-backup.tex b/bericht/prov/prov-backup.tex index 07e30b7..a1fac8d 100644 --- a/bericht/prov/prov-backup.tex +++ b/bericht/prov/prov-backup.tex @@ -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 diff --git a/bericht/prov/prov-compiler.tex b/bericht/prov/prov-compiler.tex index ce127f3..4238679 100644 --- a/bericht/prov/prov-compiler.tex +++ b/bericht/prov/prov-compiler.tex @@ -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. diff --git a/bericht/prov/prov-provisioning.tex b/bericht/prov/prov-provisioning.tex index 88c4df2..0ff62af 100644 --- a/bericht/prov/prov-provisioning.tex +++ b/bericht/prov/prov-provisioning.tex @@ -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 \end{lstlisting} @@ -29,7 +29,7 @@ cluster set- \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 } 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 } 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 } 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} diff --git a/bericht/sv/sv-dhcp_dns.tex b/bericht/sv/sv-dhcp_dns.tex index 01500fc..60c1f30 100644 --- a/bericht/sv/sv-dhcp_dns.tex +++ b/bericht/sv/sv-dhcp_dns.tex @@ -21,9 +21,9 @@ host zotac { \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. diff --git a/bericht/sv/sv-filesystems.tex b/bericht/sv/sv-filesystems.tex index ea8f2b2..5018e60 100644 --- a/bericht/sv/sv-filesystems.tex +++ b/bericht/sv/sv-filesystems.tex @@ -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} diff --git a/bericht/sv/sv-iptables.tex b/bericht/sv/sv-iptables.tex index 4274ed6..f9e99f9 100644 --- a/bericht/sv/sv-iptables.tex +++ b/bericht/sv/sv-iptables.tex @@ -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 diff --git a/bericht/sv/sv-ldap.tex b/bericht/sv/sv-ldap.tex index c24e9d0..79ba159 100644 --- a/bericht/sv/sv-ldap.tex +++ b/bericht/sv/sv-ldap.tex @@ -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} diff --git a/bericht/sv/sv-ntp.tex b/bericht/sv/sv-ntp.tex index 3e8d17b..6191c08 100644 --- a/bericht/sv/sv-ntp.tex +++ b/bericht/sv/sv-ntp.tex @@ -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.