149 lines
5.2 KiB
TeX
149 lines
5.2 KiB
TeX
\subsection{Netzwerk-Dateisysteme}
|
|
\label{sub:netzwerk_dateisysteme}
|
|
|
|
\subsubsection{NFS}
|
|
\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
|
|
teilen.
|
|
|
|
Unter Archlinux ist der NFS-Server im Packet {\tt nfs-utils} zu finden.
|
|
Um NFS zu exportieren starten wir auf dem Head-Node den rpc-mountd.service.
|
|
Das ID-Mapping übernimmt in unserem Fall der ldap-Dienst (\ref{sub:ldap}).
|
|
Auf den Compute-Node wurde jeweils ein Eintrag für die Verzeichnisse {\tt home}
|
|
und {\tt cluster} in der fstab angelegt. (siehe {\tt aufgabe3.1/fstab}).
|
|
|
|
\subsubsection{Verteiltes Dateisystem}
|
|
\label{ssub:verteiltes_dateisystem}
|
|
|
|
Als Dateisystem haben wir uns für GlusterFS entschieden. Dieses hat im Vergleich
|
|
zu anderen verteilten Dateisystemen keine zentrale Metadaten-Server. Stattdessen
|
|
setzt es auf das Elastic-Hashing. Dieser verteilte Ansatz verbessert die
|
|
Verfügbar- und Skalierbarkeit, da bei Dateisystemen wie Lustre, der
|
|
Metadatenserver häufigt 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 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 mit fstab eine
|
|
50GB Partition angelegt, diese mit folgenden Befehl formatiert.
|
|
|
|
\shellcmd{mkfs.xfs -i size=512 /dev/sda5}
|
|
|
|
und nach {\tt /mnt/glusterfs} gemountet (siehe aufgabe3.3/fstab). Nach dem Starten des
|
|
GlusterFS-Dienstes, sowohl auf Head- und Computenode:
|
|
|
|
\shellcmd{systemctl enable glusterfs.service}
|
|
|
|
\shellcmd{systemctl start glusterfs.service}
|
|
|
|
legten wir das Dateisystem an:
|
|
|
|
\shellcmd{gluster volume create gv0 zotac1:/mnt/glusterfs}
|
|
|
|
\shellcmd{gluster volume start gv0}
|
|
|
|
Letztendlich mounten wir das GlusterFS mit folgenden Eintrag in der {\tt
|
|
aufgabe3.3/fstab}:
|
|
|
|
\begin{center}
|
|
{\tt zotac0:/gv0 /fastfs glusterfs defaults 0 0}
|
|
\end{center}
|
|
|
|
Um die Schreibrate zu ermitteln, verwendeten wir den Befehl {\tt dd}:
|
|
|
|
\shellcmd{dd bs=1M count=512 if=/dev/zero of=/path/to/file conv=fdatasync}
|
|
|
|
um einen 512MB Block auf die Festplatte. Die Option {\tt conv=fdatasync} sorgt
|
|
für einen Dateisystem-Sync nach dem Schreiben um die korrekte Schreibrate zu
|
|
ermitteln.
|
|
Für Leserate haben wir folgenden Befehl benutzt um dieselbige erstellte Datei zu
|
|
lesen:
|
|
|
|
\shellcmd{dd bs=1M count=512 if=/path/to/file of=/dev/null conv=fdatasync}
|
|
|
|
Um zu verhindern, dass das Betriebssystem hierfür den Cache benutzt, habe wir
|
|
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 GlusterFS, dem
|
|
Dateisystem in /fastfs entspricht. Die Rohdaten befinden sich in {\tt aufgabe3.3/benchmark.txt}
|
|
|
|
\pgfplotsset{
|
|
select row/.style={
|
|
x filter/.code={\ifnum\coordindex=#1\else\def\pgfmathresult{}\fi}
|
|
}
|
|
}
|
|
|
|
\pgfplotstableread[header=false]{
|
|
92.3 Lokal
|
|
38.4 NFS
|
|
56.9 GlusterFS
|
|
}\writetable
|
|
|
|
\pgfplotstableread[header=false]{
|
|
125 Lokal
|
|
104 NFS.
|
|
67.9 GlusterFS
|
|
}\readtable
|
|
|
|
\begin{tikzpicture}
|
|
\begin{axis}[
|
|
title=Lesen mit dd,
|
|
xbar, bar shift=0pt,
|
|
enlarge y limits=0.2,
|
|
xmin=0,
|
|
ytick={0,...,4},
|
|
yticklabels from table={\readtable}{1},
|
|
xmajorgrids = true,
|
|
bar width=6mm,
|
|
width=12cm, height=5.5cm,
|
|
xlabel={Leserate [MB/s]},
|
|
nodes near coords, nodes near coords align={horizontal},
|
|
]
|
|
\pgfplotsinvokeforeach{0,...,3}{
|
|
\addplot table [select row=#1, y expr=#1] {\readtable};
|
|
}
|
|
\end{axis}
|
|
\end{tikzpicture}
|
|
|
|
\begin{tikzpicture}
|
|
\begin{axis}[
|
|
title=Schreiben mit dd,
|
|
xbar, bar shift=0pt,
|
|
enlarge y limits=0.2,
|
|
xmin=0,
|
|
ytick={0,...,4},
|
|
yticklabels from table={\writetable}{1},
|
|
xmajorgrids = true,
|
|
bar width=6mm,
|
|
width=12cm, height=5.5cm,
|
|
xlabel={Schreibrate [MB/s]},
|
|
nodes near coords, nodes near coords align={horizontal},
|
|
]
|
|
|
|
\pgfplotsinvokeforeach{0,...,3}{
|
|
\addplot table [select row=#1, y expr=#1] {\writetable};
|
|
}
|
|
\end{axis}
|
|
\end{tikzpicture}
|
|
|
|
Das lokale Dateisystem war wie zu erwarten sowohl beim Lesen als auch beim
|
|
Schreiben das schnellste Dateisystem. Der offensichtliche Nachteil, dieser
|
|
Methode, ist das nur die Node selber Zugriff auf diese Daten hat und die Daten
|
|
nicht größer als der lokale Speicher werden kann.
|
|
|
|
Während beim Schreiben GlusterFS einen höheren Durchsatz verzeichnen konnte,
|
|
war es in diesem Test deutlicher langsamer als NFS beim Lesen.
|
|
Zu beachten hierbei sei, dass in diesem Test nur eine Node auf NFS
|
|
zugegriffen hat. Sobald von mehren Nodes auf das NFS geschrieben wird, kann dies
|
|
schnell zum Flaschenhals werden. GlusterFS hingegen kann die Datenmengen auf die
|
|
einzelnen Nodes verteilen und so höhere Performance erreichen. Ein Nachteil
|
|
von GlusterFS dabei ist das die Fuse-Implementierung die CPU stärker belastet,
|
|
als dies bei NFS der Fall wäre.
|