diff --git a/bericht/batch/bat-installation.tex b/bericht/batch/bat-installation.tex index 5ea9828..9484e12 100644 --- a/bericht/batch/bat-installation.tex +++ b/bericht/batch/bat-installation.tex @@ -9,7 +9,7 @@ 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 -festgelege Nutzer auf allen Systemen die gleiche UID besitzt: +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 f4c8976..b28d64d 100644 --- a/bericht/batch/bat-konfiguration.tex +++ b/bericht/batch/bat-konfiguration.tex @@ -1,11 +1,11 @@ \subsection{Konfiguration} -Die Konfiguration der Queues (in SLURM Partitions genannt) erfolgt über die +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 benchmark-Partition bekam die größte Priorität, so das Jobs aus anderen +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 Batchssystems dazu bewegt Jobs, die +priorisiert. Dadurch werden Nutzer des Batchsystems dazu bewegt Jobs, die weniger Zeit benötigen, den richtige Queue zu zu ordnen. Zusätzlich zur Verwaltung der Cores haben wir SLURM für die Verwaltung der GPUs diff --git a/bericht/bench/bench-hpl.tex b/bericht/bench/bench-hpl.tex index 061be06..4866a29 100644 --- a/bericht/bench/bench-hpl.tex +++ b/bericht/bench/bench-hpl.tex @@ -6,7 +6,7 @@ Der HPL-Benchmark wurde mit folgenden Befehlen durchgeführt: \shellcmd{mpirun -x LD\_LIBRARY\_PATH -np 8 -hostfile allnodes -npernode 2 \textbackslash} \\ \shellcmd{\hspace{1cm} /cluster/software/hpl/run\_hpl > hpl.out} -In der Datei \emph{allnodes} sind die Hostnames der Computenodes hinterlegt. +In der Datei \emph{allnodes} sind die Hostnames der Compute-Nodes hinterlegt. Beim Basislauf wurde ein maximaler Wert von $3,842 \cdot 10^{-4}$ GFlops mit folgender Konfiguration erreicht: \begin{lstlisting} @@ -15,7 +15,7 @@ Beim Basislauf wurde ein maximaler Wert von $3,842 \cdot 10^{-4}$ GFlops mit fol WR00L2L2 35 4 1 4 \end{lstlisting} -Der optimierte Lauf mit der Standard BLAS-Library des Systems mit der Konfiguration: +Der optimierte Lauf mit der Standard-BLAS-Bibliothek des Systems mit der Konfiguration: \begin{lstlisting} T/V N NB P Q @@ -36,7 +36,7 @@ einen Wert von {\bf 4,076 GFlops}. \subsubsection{Auswertung} -Verglichen mit der theoretischen Floating Point Peak Performance von: \\ $1,6$ +Verglichen mit der theoretischen Floating-Point-Peak-Performance von: \\ $1,6$ GHz $\cdot 2$ CPU-Kerne pro Prozessor $\cdot 2$ Instruktion pro Takt $\cdot 4$ CPUs $ = 25,6$ GFlops \\ erreichten wir also ca. 16 \% der maximal möglichen Leistung, was in Anbetracht des langsamen Verbindungsnetzwerkes ein akzeptabler diff --git a/bericht/bench/bench-iozone.tex b/bericht/bench/bench-iozone.tex index 35fc7f8..19b458c 100644 --- a/bericht/bench/bench-iozone.tex +++ b/bericht/bench/bench-iozone.tex @@ -27,7 +27,7 @@ Testaufruf: \shellcmd{./iozone -azcR -+q 1 -U /fastfs -f /fastfs/testfile -b excel-fastfs.xls} -Der Parameter \emph{-+q 1} sorgt für einen Delay zwischen den einzelnen Tests, ohne den der Benchmark fehlerhaft läuft.\\ +Der Parameter \emph{-+q 1} sorgt für einen Verzögerung zwischen den einzelnen Tests, ohne den der Benchmark fehlerhaft läuft.\\ \subsubsection{Auswertung} @@ -35,14 +35,14 @@ Die Lesegeschwindigkeit von NFS entspricht mit als Maximalwert gemessenen 109 Mi \shellcmd{hdparm -t /dev/sda} -Die Schreibegeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa -der Leistungsfähigskeit der Festplatte entsprechen. +Die Schreibgeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa +der Leistungsfähig der Festplatte entsprechen. GlusterFS liegt in der Lesegeschwindigkeit von maximal 104 MiB/s etwa mit NFS -gleich auf. Die Schreibegeschwindigkeit hingegen erreicht lediglich 28 MiB/s und +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 -Schreibeoperation es etliche Kontextwechsel und Kopiervorgänge gibt, weil die +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. diff --git a/bericht/bs/bs-git.tex b/bericht/bs/bs-git.tex index 452b547..854dba9 100644 --- a/bericht/bs/bs-git.tex +++ b/bericht/bs/bs-git.tex @@ -20,7 +20,7 @@ Nun kann die eigentliche Konfiguration per git heruntergeladen werden: Wir legten in dieser Konfiguration das Repository \emph{lctp} an und gaben allen Benutzern Zugriff darauf. Die gitolite-Konfiguration befindet sich als Git-Submodule im Verzeichnis \emph{aufgabe2.4/gitolite-admin}. -Das lctp-Repository wiederum lässt sich mit folgendem Befehl clonen: +Das lctp-Repository wiederum lässt sich mit folgendem Befehl klonen: \shellcmd{git clone git@141.76.90.104:lctp.git lctp-gruppe4} @@ -55,7 +55,7 @@ vorrangig ausgeführt. Die Wrapper befinden sich in \emph{aufgabe2.4/yaourt} sowie in \emph{aufgabe2.4/pacman}. Darüber hinaus haben wir das Shell-Script für tägliche automatische Commits, welches sich im \href{https://github.com/joeyh/etckeeper/blob/master/debian/cron.daily}{Git-Repository} -(Stand 07.11.2013) von \emph{etckeeper} liegt, als Cronjob eingerichtet (siehe +(Stand 07.11.2013) von \emph{etckeeper} liegt, als Cron-Job eingerichtet (siehe \emph{aufgabe2.4/cron.daily/etckeeper}). \subsubsection{Logs in git} diff --git a/bericht/bs/bs-pdsh.tex b/bericht/bs/bs-pdsh.tex index 716f8ad..37d5ef2 100644 --- a/bericht/bs/bs-pdsh.tex +++ b/bericht/bs/bs-pdsh.tex @@ -9,7 +9,7 @@ Das entsprechende Paket war nicht im offiziellen Arch Linux Repository vorhanden, deshalb haben wir es über das AUR (siehe \ref{sec:aur}) installiert. \subsubsection{Gruppenverwaltung} Zur Verwaltung mehrerer Rechner in Gruppen (in -unserem Fall Headnode und Computenodes) greift \emph{Pdsh} auf die +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 diff --git a/bericht/bs/bs-ssh.tex b/bericht/bs/bs-ssh.tex index 55b65c3..b391419 100644 --- a/bericht/bs/bs-ssh.tex +++ b/bericht/bs/bs-ssh.tex @@ -5,7 +5,7 @@ Wir haben uns für \emph{OpenSSH} als SSH-Server entschieden. Diesen haben wir m \shellcmd{pacman -S openssh} -Desweiteren wurden in \emph{/etc/ssh/sshd\_config} (siehe \emph{aufgabe2.3/sshd\_config}) folgende Zeilen verändert, um den ''root-Account'' zu deaktivieren und den passwortlosen Zugriff zu aktivieren: +Des weiteren wurden in \emph{/etc/ssh/sshd\_config} (siehe \emph{aufgabe2.3/sshd\_config}) folgende Zeilen verändert, um den ''root-Account'' zu deaktivieren und den passwortlosen Zugriff zu aktivieren: \begin{lstlisting} PermitRootLogin no @@ -43,4 +43,4 @@ Das automatisierte Hinzufügen neuer Nutzer haben wir über ein Script \texttt{newuser} (siehe \emph{aufgabe2.3/newuser}) gelöst. Dieses Script legt einen neuen Benutzer an, erstellt dessen Home-Verzeichnis, generiert ein neues Public-Private-Key-Paar für SSH und trägt den eigenen Public-Key in die -\emph{authorized\_keys} ein und ermöglich den Zugriff auf das git-Repository. +\emph{authorized\_keys} ein und ermöglicht den Zugriff auf das git-Repository. diff --git a/bericht/bs/bs.tex b/bericht/bs/bs.tex index 72c686c..8c45a3f 100644 --- a/bericht/bs/bs.tex +++ b/bericht/bs/bs.tex @@ -1,6 +1,6 @@ -\section{Betriebsysteminstallation} +\section{Betriebssysteminstallation} -\subsection{Wahl des Betriebsystems} +\subsection{Wahl des Betriebssystems} \label{sub:wahl_des_betriebsystems} Wir haben \href{http://www.archlinux.org/}{Arch Linux} als Betriebssystem gewählt. Es hat mit \emph{Systemd} ein modernes und robustes init-System. Systemd verwaltet Abhängigkeiten zwischen den verschiedenen Systemdiensten. Gestartete Dienste werden überwacht und können im Fehlerfall neu gestartet werden. @@ -31,21 +31,23 @@ Die Partitionierung haben wir wie im Cluster-Layout angegeben mit \emph{fdisk} v 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 dem erfolgreichen Reboot haben wir dann das Netzwerk auf eine statische IP-Adresse mittels \emph{netctl} konfiguriert. Damit waren sowohl die Headnode als auch der erste Computenode grundsätzlich einsatzfähig. +Nach dem erfolgreichen Reboot haben wir dann das Netzwerk auf eine statische +IP-Adresse mittels \emph{netctl} konfiguriert. Damit waren sowohl die Head-Node +als auch der erste Compute-Node grundsätzlich einsatzfähig. \subsubsection{Netzwerk-Konfiguration} -Auf dem Headnode bzw. Computenode haben wir mit \emph{netctl} die beiden +Auf dem Head-Node bzw. Compute-Node haben wir mit \emph{netctl} die beiden Netzwerk-Interfaces \emph{eth0} und \emph{eth1} bzw. \emph{enp1s0} auf eine 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 Headnode mussten wir noch mittels \emph{iptables} das \texttt{ +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 Computenodes auch auf das Internet zugreifen können (Paketinstallationen, Updates, etc.). +(siehe \emph{aufgabe2.2/10-ip-forward-conf}) freischalten, damit 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 2a89370..d62c03c 100644 --- a/bericht/burnin.tex +++ b/bericht/burnin.tex @@ -8,12 +8,12 @@ Zur Überwachung und Aufzeichnung des Systems während des Burnin haben wir \texttt{Munin} eingerichtet. Munit besteht aus einem Masterprozess, welches die gewünschten Daten aufzeichnet und einem Nodeprozess, welches die Daten bereitstellt. Die Darstellung erfolgt über ein Webinterface, welches die Graphen -aus einer \emph{Rddtool}-Datenbank generiert. Auf dem Headnode haben wir den +aus einer \emph{Rddtool}-Datenbank generiert. Auf dem Head-Node haben wir den Masterprozess installiert: \shellcmd{pacman -S munin} -Auf dem Computenode die Nodekomponente: +Auf dem Compute-Node die Nodekomponente: \shellcmd{pacman -S munin-node} @@ -39,7 +39,7 @@ klein ist, haben wir uns für die Aktualisierung der Leistungsdaten mithilfe Munin bringt bei der Installation schon eine Vielzahl von Plugins mit. Manche von dieser Plugins benötigen wiederum für die Datenerfassung andere Programme. -Auf dem Computenode haben wir folgende Plugins aktiviert: +Auf dem Compute-Node haben wir folgende Plugins aktiviert: \begin{itemize} \item cpu diff --git a/bericht/cluster-layout.tex b/bericht/cluster-layout.tex index ceabadf..92f8e19 100644 --- a/bericht/cluster-layout.tex +++ b/bericht/cluster-layout.tex @@ -33,7 +33,7 @@ Wir haben uns folgendes Cluster-Layout überlegt: (Details auf nächster Seite) {\bf Compute-Nodes:} \\ \begin{tabularx}{45em}{l|X|X|X|X} - Hostnames & \texttt{zotac1}\footnote{330er Board und 1. Computenode} & \texttt{zotac2} & \texttt{zotac3} & \texttt{zotac4} \\ + Hostnames & \texttt{zotac1}\footnote{330er Board und 1. Compute-Node} & \texttt{zotac2} & \texttt{zotac3} & \texttt{zotac4} \\ \hline Interne IPs & \texttt{\small 10.20.0.101} & \texttt{\small 10.20.0.102} & \texttt{\small 10.20.0.103} & \texttt{\small 10.20.0.104} \\ \hline diff --git a/bericht/hardware.tex b/bericht/hardware.tex index e91e4e7..0634568 100644 --- a/bericht/hardware.tex +++ b/bericht/hardware.tex @@ -12,7 +12,7 @@ In die beiden zur Verfügung stehenden Gehäuse bauten wir jeweils zwei Mainboar Da nur drei ZOTAC-Boards vorhanden waren, mussten wir als vierten Compute-Node ein normales Intel-Mainboard (ohne nVidia-Chip) verwenden. \\ -Beide Boards waren jeweils ausgestattet mit: %\footnote{330er Board und 1. Computenode} +Beide Boards waren jeweils ausgestattet mit: %\footnote{330er Board und 1. Compute-Node} \begin{itemize} \item einem (bereits fest verbautem) Intel Atom 330 Prozessor diff --git a/bericht/ori/ori-inst.tex b/bericht/ori/ori-inst.tex index 57b307f..b6c0b87 100644 --- a/bericht/ori/ori-inst.tex +++ b/bericht/ori/ori-inst.tex @@ -2,7 +2,14 @@ \subsubsection{Vorbereitungen} -Da Ori seine Configs und Repositorien unter \emph{.ori} im Home-Verzeichnis des jeweiligen Nutzers ablegt und dieses auf allen Nodes eingebunden wird, würden zwangsweise Fehler auftreten. Deshalb wurde auf allen Computenodes eine neue Partition erstellt und unter \emph{/ori} gemounted. Mit \emph{useradd ori} wurde ein neuer User ori angelegt, dem mit \emph{chown /ori/home ori:ori} und \emph{usermod --home /ori/home ori} das Home-Verzeichnis \emph{/ori/home} zugeteilt wurde. Mit \emph{ssh-keygen} wurden auf Computenode 1 die ssh-Schlüssel erstellt und anschließend auf Computenode 2 übertragen. Desweiteren wurde der Public-Key in die \emph{authorized\_keys} eingetragen. Mit diesen Arbeitsschritten war nun ein passwortloser Zugriff für den Nutzer ori auf die beiden Coputenodes gewährleistet. +Da Ori seine Configs und Repositorien unter \emph{.ori} im Home-Verzeichnis des +jeweiligen Nutzers ablegt und dieses auf allen Nodes eingebunden wird, würden +zwangsweise Fehler auftreten. Deshalb wurde auf allen Compute-Nodes eine neue +Partition erstellt und unter \emph{/ori} gemounted. Mit \emph{useradd ori} wurde +ein neuer User ori angelegt, dem mit \emph{chown /ori/home ori:ori} und +\emph{usermod --home /ori/home ori} das Home-Verzeichnis \emph{/ori/home} +zugeteilt wurde. Mit \emph{ssh-keygen} wurden auf Compute-Node 1 die +ssh-Schlüssel erstellt und anschließend auf Compute-Node 2 übertragen. Desweiteren wurde der Public-Key in die \emph{authorized\_keys} eingetragen. Mit diesen Arbeitsschritten war nun ein passwortloser Zugriff für den Nutzer ori auf die beiden Coputenodes gewährleistet. \subsubsection{Installation} diff --git a/bericht/prov/prov-backup.tex b/bericht/prov/prov-backup.tex index 88998a0..07e30b7 100644 --- a/bericht/prov/prov-backup.tex +++ b/bericht/prov/prov-backup.tex @@ -4,7 +4,7 @@ Wir haben uns für \href{http://www.rsnapshot.org/}{Rsnapshot} aus folgenden Gründen entschieden: \begin{itemize} - \item Die Backups liegen als Ordner mit den gleichen Rechten wie im zu backupenden System. + \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 selbständig Dateien wiederherstellen können. \item Rsnapshot erstellt differentielle Backups. Dabei werden Dateien, die diff --git a/bericht/prov/prov-provisioning.tex b/bericht/prov/prov-provisioning.tex index 46ae87e..88c4df2 100644 --- a/bericht/prov/prov-provisioning.tex +++ b/bericht/prov/prov-provisioning.tex @@ -12,14 +12,14 @@ da auf den Festplatten der Compute-Nodes genügend Speicher für das Betriebssystem vorhanden ist und bei jedem Zugriff auf das Dateisystem unnötigen Latenzen entstehen würden. -Um Clonezilla auf den Computenodes zu booten, haben wir den +Um Clonezilla auf den Compute-Nodes zu booten, haben wir den \emph{in.tftpd}-Server installiert und das Service-File für \emph{Systemd} angepasst (siehe \emph{aufgabe4.4/tftpd.service}). Außerdem haben wir die Konfiguration des DHCP-Servers so angepasst, dass nun jede Compute-Node eine eigene Konfigurationsdatei in \emph{/etc/dhcpd.d/} hat, die jeweils von \emph{/etc/dhcpd.d/all} inkludiert wird. -Außerdem haben wir ein Script \emph{ cluster} geschrieben, mit dem die Computenodes verwaltet werden können. Mit +Außerdem haben wir ein Script \emph{ cluster} geschrieben, mit dem die Compute-Nodes verwaltet werden können. Mit \begin{lstlisting} cluster add \end{lstlisting} @@ -42,22 +42,22 @@ Konfigurationsdateien liegen in \emph{/srv/tftp/pxelinux/pxelinux.cfg}. \end{sloppypar} -\subsubsection{Provisionierung der Computenodes} +\subsubsection{Provisionierung der Compute-Nodes} \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 Headnode ein Script und führt es +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 vorzubereiten und zu starten (siehe \emph{aufgabe4.4/clone.sh}). Dazu wird per -NFS das \emph{/cluster}-Verzeichnis des Headnodes eingebunden und dort im -Unterverzeichnis \emph{images} das Image der Festplatte abgelegt. Geclont werden +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. Zum Wiederherstellen des Images wird mit \emph{sudo cluster set-restore } wieder der entsprechende Boot-Modus gesetzt und der Node -neugestartet. Dort wird nun ein anderes Script vom Headnode 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. diff --git a/bericht/prov/prov.tex b/bericht/prov/prov.tex index de8c287..be02dd7 100644 --- a/bericht/prov/prov.tex +++ b/bericht/prov/prov.tex @@ -1,5 +1,4 @@ -\section{Compiler, Modules, Backup und Klonen -des Compute Nodes} +\section{Compiler, Modules, Backup und Klonen des Compute-Node} \input{prov/prov-compiler} diff --git a/bericht/sv/sv-dhcp_dns.tex b/bericht/sv/sv-dhcp_dns.tex index 0351db8..01500fc 100644 --- a/bericht/sv/sv-dhcp_dns.tex +++ b/bericht/sv/sv-dhcp_dns.tex @@ -5,10 +5,10 @@ \begin{sloppypar} Wir haben uns für den \emph{ISC-Dhcpd} als DHCP-Server entschieden. Zur Konfiguration haben wir in \emph{/etc/dhcpd.conf} (siehe \emph{aufgabe3.2}) die -interne Top-Level-Domain \emph{zotac} eintragen und den Headnode als DNS-Server eingestellt. +interne Top-Level-Domain \emph{zotac} eintragen und den Head-Node als DNS-Server eingestellt. \end{sloppypar} -Des Weiteren haben wir das Subnet \emph{10.20.0.0/24} deklariert und wiederum den Headnode als verantwortlichen Router eingetragen. +Des Weiteren haben wir das Subnet \emph{10.20.0.0/24} deklariert und wiederum den Head-Node als verantwortlichen Router eingetragen. Die Pro-Host-Konfiguration sieht bei uns wie folgt aus: diff --git a/bericht/sv/sv-filesystems.tex b/bericht/sv/sv-filesystems.tex index 35e317f..ea8f2b2 100644 --- a/bericht/sv/sv-filesystems.tex +++ b/bericht/sv/sv-filesystems.tex @@ -25,8 +25,8 @@ Elastic-Hashing nennt. Dieser verteilte Ansatz verbessert die Verfügbar- und Skalierbarkeit, da bei Dateisystemen wie Lustre, der Metadatenserver häufig zum Flaschenhals wird. Das Dateisystem lässt sich im laufenden Betrieb um weitere Nodes erweitern. GlusterFS kann auf beliebige Dateisysteme aufgesetzt werden, -was die Wiederherstellung im Falle eines Absturzes vereinfacht. Der einzigste -Nachteil, der uns aufgefallen ist, ist das GlusterFS auf Basis von Fuse im +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. @@ -36,7 +36,7 @@ Partition angelegt, diese mit Befehl: \shellcmd{mkfs.xfs -i size=512 /dev/sda5} formatiert und nach \emph{/mnt/glusterfs} gemountet (siehe aufgabe3.3/fstab). -Nach dem Starten des GlusterFS-Dienstes, sowohl auf Head- und Computenode: +Nach dem Starten des GlusterFS-Dienstes, sowohl auf Head- und Compute-Node: \shellcmd{systemctl enable glusterfs.service} @@ -60,8 +60,8 @@ Um die Schreibdurchsatz zu ermitteln, verwendeten wir den Befehl \emph{dd}: um einen 512MB Block auf die Festplatte. Die Option \emph{conv=fdatasync} sorgt für einen Dateisystem-Sync nach dem Schreiben um die korrekte Schreibrate zu -ermitteln. Für die Leserate haben wir folgenden Befehl benutzt um dieselbige -erstellte Datei zu lesen: +ermitteln. Für die Leserate haben wir folgenden Befehl benutzt um erstellte +Datei zu lesen: \shellcmd{dd bs=1M count=512 if=/path/to/file of=/dev/null conv=fdatasync} diff --git a/bericht/sv/sv-ldap.tex b/bericht/sv/sv-ldap.tex index 70d8c00..c24e9d0 100644 --- a/bericht/sv/sv-ldap.tex +++ b/bericht/sv/sv-ldap.tex @@ -34,7 +34,7 @@ Um auf den Verzeichnisdienst zugreifen zu können, haben wir eine Datei angelegt, die nur durch \emph{root}-Benutzer zugreifbar ist (Verzeichnisberechtigung $600_8$). -\subsubsection{Client-Konfiguration (Headnode und Computenode)} +\subsubsection{Client-Konfiguration (Head-Node und Compute-Node)} \begin{sloppypar} Hierfür haben wir die Variablen \emph{BASE, URI, TIMEOUT, NETWORK\_TIMEOUT} in