Bericht in Abschnitte gesplittet
This commit is contained in:
parent
e430111ac1
commit
cc8cce6e99
2
bericht/abschnitte/bs-git.tex
Normal file
2
bericht/abschnitte/bs-git.tex
Normal file
@ -0,0 +1,2 @@
|
||||
\subsection{Git-Server}
|
||||
\label{sub:git_server}
|
||||
28
bericht/abschnitte/bs-pdsh.tex
Normal file
28
bericht/abschnitte/bs-pdsh.tex
Normal file
@ -0,0 +1,28 @@
|
||||
\subsection{Parallel Distributed Shell (PDSH)}
|
||||
\label{sub:parallel_shell}
|
||||
|
||||
Die {\tt pdsh} ist ein Tool, mit dem man parallel auf mehreren Rechnern gleichzeitig Befehle über SSH ausführen kann, um diese komplett synchron zu konfigurieren und zu administrieren.
|
||||
|
||||
Das entsprechende Paket war nicht im offiziellen Arch Linux Repository vorhanden, deshalb wurde über das AUR (Arch User Repositories) eine {\tt PKGBUILD}-Datei bezogen, die die »Anleitungen« zum Bau des Paketes enthielten. Mit {\tt makepkg} konnte dann das Paket gebaut und mit:
|
||||
\begin{center}
|
||||
\tt pacman -U pdsh-*.pkg.tar.gz
|
||||
\end{center}
|
||||
installiert werden.
|
||||
|
||||
\subsubsection{Gruppenverwaltung}
|
||||
Zur Verwaltung mehrerer Rechner in Gruppen (in unserem Fall Head-Node und Compute-Nodes) greift {\tt pdsh} auf Gruppen-Dateien von {\tt dsh} zurück. Diese können entweder pro Benutzer in { \tt $\tilde{}$/.dsh/group} oder systemweit in {\tt /etc/dsh/group} hinterlegt werden; da sowieso jeder Benutzer die gleichen Gruppen-Dateien verwendet, haben wir letzteres verwendet.
|
||||
|
||||
Dabei wurden folgende Gruppen-Dateien mit entsprechendem Inhalt angelegt:
|
||||
\begin{itemize}
|
||||
\item {\ttfamily \bfseries headnode}: \\
|
||||
{\tt zeus}
|
||||
|
||||
\item {\ttfamily \bfseries computenode}: \\
|
||||
{\tt ares} \\
|
||||
{\tt chronos} \\
|
||||
{\tt eris} \\
|
||||
{\tt hades}
|
||||
|
||||
\item {\ttfamily \bfseries all}: \\
|
||||
Kombination aus {\tt headnode} und {\tt computenode}
|
||||
\end{itemize}
|
||||
2
bericht/abschnitte/bs-ssh.tex
Normal file
2
bericht/abschnitte/bs-ssh.tex
Normal file
@ -0,0 +1,2 @@
|
||||
\subsection{SSH-Server}
|
||||
\label{sub:ssh_server}
|
||||
25
bericht/abschnitte/bs.tex
Normal file
25
bericht/abschnitte/bs.tex
Normal file
@ -0,0 +1,25 @@
|
||||
\section{Betriebsysteminstallation}
|
||||
|
||||
\subsection{Wahl des Betriebsystems}
|
||||
\label{sub:wahl_des_betriebsystems}
|
||||
|
||||
Vorteile:
|
||||
|
||||
\begin{itemize}
|
||||
\item Packetbau ist einfacher und es gibt sehr viele Packete im \href{http://aur.archlinux.org/}{AUR}
|
||||
\item Systemd als modernes und robustes Initsystem
|
||||
\item DWIM
|
||||
\end{itemize}
|
||||
|
||||
Nachteile:
|
||||
|
||||
\begin{itemize}
|
||||
\item Updates können die Konfiguration brechen
|
||||
\item keinen kommerziellen Support
|
||||
\end{itemize}
|
||||
|
||||
\input{abschnitte/bs-ssh}
|
||||
|
||||
\input{abschnitte/bs-git}
|
||||
|
||||
\input{abschnitte/bs-pdsh}
|
||||
54
bericht/abschnitte/cluster-layout.tex
Normal file
54
bericht/abschnitte/cluster-layout.tex
Normal file
@ -0,0 +1,54 @@
|
||||
\section{Cluster-Layout}
|
||||
|
||||
Wir haben uns folgendes Cluster-Layout überlegt: (Details auf nächster Seite)
|
||||
|
||||
\includegraphics{bilder/layout.pdf}
|
||||
|
||||
\pagebreak
|
||||
|
||||
{\bf Head-Nodes:} \\
|
||||
|
||||
\begin{tabularx}{\textwidth}{l|X}
|
||||
Hostnames & \tt zeus \\
|
||||
\hline
|
||||
Interne IP & \tt 10.20.0.1 \\
|
||||
Externe IP & \tt 142.76.90.104 \\
|
||||
\hline
|
||||
Partitionierung &
|
||||
\multicolumn{1}{l}{\begin{tabularx}{\textwidth}{l r l}
|
||||
\tt / & 50 GiB & Wurzelverzeichnis \\
|
||||
\tt /boot & 1 GiB & Boot-Dateien (Kernel, {\tt initrd}, grub, etc.) \\
|
||||
\tt /home & 40 GiB & Benutzer-Verzeichnisse \\
|
||||
\tt /cluster & 150 GiB & Cluster-Daten \\
|
||||
\tt swap & 2 GiB & Auslagerungsspeicher \\
|
||||
\end{tabularx}} \\
|
||||
\hline
|
||||
NFS-Freigaben &
|
||||
\multicolumn{1}{l}{\begin{tabularx}{\textwidth}{lr}
|
||||
\tt /home & \multirow{2}{*}{Freigabe für das {\tt 10.20.0.0/24}-Netz} \\
|
||||
\tt /cluster \\
|
||||
\end{tabularx}} \\
|
||||
\end{tabularx} \\\\\\
|
||||
|
||||
{\bf Compute-Nodes:} \\
|
||||
|
||||
\begin{tabularx}{45em}{l|X|X|X|X}
|
||||
Hostnames & \tt ares\footnote{330er Board und 1. Computenode} & \tt chronos & \tt eris & \tt hades \\
|
||||
\hline
|
||||
Interne IPs & \tt \small 10.20.0.101 & \tt \small 10.20.0.102 & \tt \small 10.20.0.103 & \tt \small 10.20.0.104 \\
|
||||
\hline
|
||||
Partitionierung & \multicolumn{4}{l}{
|
||||
\begin{tabularx}{\textwidth}{l r l}
|
||||
\tt / & 100 GiB & Wurzelverzeichnis \\
|
||||
\tt /boot & 1 GiB & Boot-Dateien (Kernel, {\tt initrd}, grub, etc.) \\
|
||||
\tt swap & 2 GiB & Auslagerungsspeicher \\
|
||||
\tt ? & 130 GiB & Reserviert
|
||||
\end{tabularx}
|
||||
}
|
||||
\end{tabularx} \\\\\\
|
||||
|
||||
Wir haben uns für ein Subnetz im Privat-Class A-Netz entschieden.
|
||||
Die internen IP-Adressen sollen hier aus dem {\tt 10.20.0.0/24}-Netz stammen.
|
||||
Der Vorteil ist die einfache Erweiterung um weitere Subnetze.
|
||||
|
||||
\pagebreak
|
||||
60
bericht/abschnitte/hardware.tex
Normal file
60
bericht/abschnitte/hardware.tex
Normal file
@ -0,0 +1,60 @@
|
||||
\section{Hardwareaufbau}
|
||||
|
||||
In die beiden zur Verfügung stehenden Gehäuse bauten wir jeweils zwei Mainboards ein.
|
||||
\begin{itemize}
|
||||
\item 1. Gehäuse: zwei \href{http://downloads.zotac.com/mediadrivers/mb/man/pa119.pdf}{»Zotac ION
|
||||
Synergy«}-Mainboards mit im Chipsatz integriertem nVidia-Graphikchip
|
||||
(siehe \ref{fig:Gehaeuse1})
|
||||
\item 2. Gehäuse: ein »Zotac«-Mainboard und ein \href{http://downloadmirror.intel.com/16960/eng/D945GCLF2_ProductGuide02_English.pdf}{»Intel Desktop Board D945GCLF2«}
|
||||
(siehe \ref{fig:Gehaeuse2})
|
||||
\end{itemize}
|
||||
|
||||
Da nur drei ZOTAC-Boards vorhanden waren, mussten wir als vierten Compute-Node
|
||||
ein normales Intel-Mainboard (ohne nVidia-Chip) verwenden. \\
|
||||
|
||||
Jedes Board war jeweils ausgestattet mit: %\footnote{330er Board und 1. Computenode}
|
||||
|
||||
\begin{itemize}
|
||||
\item einem (bereits fest verbautem) Intel Atom 330 Prozessor
|
||||
\item 2 GiB DDR2-RAM
|
||||
\item 250 GiB Festplatte
|
||||
\item einem im Gehäuse bereits vorhandenes Netzteil.
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.5cm}
|
||||
|
||||
COM-Ports konnten nicht angeschlossen werden, da keine entsprechenden Pins auf dem Intel-Board vorhanden waren und es ein inkompatibles Pin-Out (keine Pin-Aussparung beim 10. Pin) auf dem ZOTAC-Board gab. \\
|
||||
|
||||
Teile der Kabelstränge (unbenötigte Kabel, Schlaufe des ATX-Strangs, etc.) konnten unter der Festplattenhalterung verstaut werden. \\
|
||||
|
||||
Die Stromversorgung der vier Einschübe (von zwei Gruppen) erfolgt an zwei Stromverteilern (in Reihe), so dass nur ein Stromkabel nach außen geführt werden muss. Für die Vernetzung waren die kurzen Patch-Kabel ausreichend lang; es wurden alle 8 Boards im Rack an den Switch angeschlossen. \\
|
||||
|
||||
Als Switch wird ein \href{http://www.dlink.com/de/de/support/product/dgs-1216t-smart-copper-gigabit-switch}{D-Link DGS-1216T} verwendet.
|
||||
|
||||
\pagebreak
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\includegraphics[width=12cm]{bilder/hw-2zotac.jpg}
|
||||
\caption{ 1. Gehäuse: 2 ZOTAC-Boards} % (Beschriftung 7071bc5cc26d)
|
||||
\label{fig:Gehaeuse1}
|
||||
\end{figure}
|
||||
|
||||
\vspace{1cm}
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\includegraphics[width=12cm]{bilder/hw-1zotac.jpg}
|
||||
\caption{ 2. Gehäuse: 1 Intel-330er-Board, 1 ZOTAC-Board} % (Beschriftung 7071bc5cc410)
|
||||
\label{fig:Gehaeuse2}
|
||||
\end{figure}
|
||||
|
||||
\pagebreak
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\includegraphics[width=15cm]{bilder/hw-case.jpg}
|
||||
\caption{Anordnung im Rack; Stromversorung und Vernetzung}
|
||||
\end{figure}
|
||||
|
||||
\pagebreak
|
||||
@ -22,173 +22,10 @@
|
||||
|
||||
\begin{document}
|
||||
|
||||
\section{Hardwareaufbau}
|
||||
\input{abschnitte/hardware}
|
||||
|
||||
In die beiden zur Verfügung stehenden Gehäuse bauten wir jeweils zwei Mainboards ein.
|
||||
\begin{itemize}
|
||||
\item 1. Gehäuse: zwei \href{http://downloads.zotac.com/mediadrivers/mb/man/pa119.pdf}{»Zotac ION
|
||||
Synergy«}-Mainboards mit im Chipsatz integriertem nVidia-Graphikchip
|
||||
(siehe \ref{fig:Gehaeuse1})
|
||||
\item 2. Gehäuse: ein »Zotac«-Mainboard und ein \href{http://downloadmirror.intel.com/16960/eng/D945GCLF2_ProductGuide02_English.pdf}{»Intel Desktop Board D945GCLF2«}
|
||||
(siehe \ref{fig:Gehaeuse2})
|
||||
\end{itemize}
|
||||
\input{abschnitte/cluster-layout}
|
||||
|
||||
Da nur drei ZOTAC-Boards vorhanden waren, mussten wir als vierten Compute-Node
|
||||
ein normales Intel-Mainboard (ohne nVidia-Chip) verwenden. \\
|
||||
|
||||
Jedes Board war jeweils ausgestattet mit: %\footnote{330er Board und 1. Computenode}
|
||||
|
||||
\begin{itemize}
|
||||
\item einem (bereits fest verbautem) Intel Atom 330 Prozessor
|
||||
\item 2 GiB DDR2-RAM
|
||||
\item 250 GiB Festplatte
|
||||
\item einem im Gehäuse bereits vorhandenes Netzteil.
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.5cm}
|
||||
|
||||
COM-Ports konnten nicht angeschlossen werden, da keine entsprechenden Pins auf dem Intel-Board vorhanden waren und es ein inkompatibles Pin-Out (keine Pin-Aussparung beim 10. Pin) auf dem ZOTAC-Board gab. \\
|
||||
|
||||
Teile der Kabelstränge (unbenötigte Kabel, Schlaufe des ATX-Strangs, etc.) konnten unter der Festplattenhalterung verstaut werden. \\
|
||||
|
||||
Die Stromversorgung der vier Einschübe (von zwei Gruppen) erfolgt an zwei Stromverteilern (in Reihe), so dass nur ein Stromkabel nach außen geführt werden muss. Für die Vernetzung waren die kurzen Patch-Kabel ausreichend lang; es wurden alle 8 Boards im Rack an den Switch angeschlossen. \\
|
||||
|
||||
Als Switch wird ein \href{http://www.dlink.com/de/de/support/product/dgs-1216t-smart-copper-gigabit-switch}{D-Link DGS-1216T} verwendet.
|
||||
|
||||
\pagebreak
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\includegraphics[width=12cm]{bilder/hw-2zotac.jpg}
|
||||
\caption{ 1. Gehäuse: 2 ZOTAC-Boards} % (Beschriftung 7071bc5cc26d)
|
||||
\label{fig:Gehaeuse1}
|
||||
\end{figure}
|
||||
|
||||
\vspace{1cm}
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\includegraphics[width=12cm]{bilder/hw-1zotac.jpg}
|
||||
\caption{ 2. Gehäuse: 1 Intel-330er-Board, 1 ZOTAC-Board} % (Beschriftung 7071bc5cc410)
|
||||
\label{fig:Gehaeuse2}
|
||||
\end{figure}
|
||||
|
||||
\pagebreak
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\includegraphics[width=15cm]{bilder/hw-case.jpg}
|
||||
\caption{Anordnung im Rack; Stromversorung und Vernetzung}
|
||||
\end{figure}
|
||||
|
||||
\pagebreak
|
||||
|
||||
\section{Cluster-Layout}
|
||||
|
||||
Wir haben uns folgendes Cluster-Layout überlegt: (Details auf nächster Seite)
|
||||
|
||||
\includegraphics{bilder/layout.pdf}
|
||||
|
||||
\pagebreak
|
||||
|
||||
{\bf Head-Nodes:} \\
|
||||
|
||||
\begin{tabularx}{\textwidth}{l|X}
|
||||
Hostnames & \tt zeus \\
|
||||
\hline
|
||||
Interne IP & \tt 10.20.0.1 \\
|
||||
Externe IP & \tt 142.76.90.104 \\
|
||||
\hline
|
||||
Partitionierung &
|
||||
\multicolumn{1}{l}{\begin{tabularx}{\textwidth}{l r l}
|
||||
\tt / & 50 GiB & Wurzelverzeichnis \\
|
||||
\tt /boot & 1 GiB & Boot-Dateien (Kernel, {\tt initrd}, grub, etc.) \\
|
||||
\tt /home & 40 GiB & Benutzer-Verzeichnisse \\
|
||||
\tt /cluster & 150 GiB & Cluster-Daten \\
|
||||
\tt swap & 2 GiB & Auslagerungsspeicher \\
|
||||
\end{tabularx}} \\
|
||||
\hline
|
||||
NFS-Freigaben &
|
||||
\multicolumn{1}{l}{\begin{tabularx}{\textwidth}{lr}
|
||||
\tt /home & \multirow{2}{*}{Freigabe für das {\tt 10.20.0.0/24}-Netz} \\
|
||||
\tt /cluster \\
|
||||
\end{tabularx}} \\
|
||||
\end{tabularx} \\\\\\
|
||||
|
||||
{\bf Compute-Nodes:} \\
|
||||
|
||||
\begin{tabularx}{45em}{l|X|X|X|X}
|
||||
Hostnames & \tt ares\footnote{330er Board und 1. Computenode} & \tt chronos & \tt eris & \tt hades \\
|
||||
\hline
|
||||
Interne IPs & \tt \small 10.20.0.101 & \tt \small 10.20.0.102 & \tt \small 10.20.0.103 & \tt \small 10.20.0.104 \\
|
||||
\hline
|
||||
Partitionierung & \multicolumn{4}{l}{
|
||||
\begin{tabularx}{\textwidth}{l r l}
|
||||
\tt / & 100 GiB & Wurzelverzeichnis \\
|
||||
\tt /boot & 1 GiB & Boot-Dateien (Kernel, {\tt initrd}, grub, etc.) \\
|
||||
\tt swap & 2 GiB & Auslagerungsspeicher \\
|
||||
\tt ? & 130 GiB & Reserviert
|
||||
\end{tabularx}
|
||||
}
|
||||
\end{tabularx} \\\\\\
|
||||
|
||||
Wir haben uns für ein Subnetz im Privat-Class A-Netz entschieden.
|
||||
Die internen IP-Adressen sollen hier aus dem {\tt 10.20.0.0/24}-Netz stammen.
|
||||
Der Vorteil ist die einfache Erweiterung um weitere Subnetze.
|
||||
|
||||
\section{Betriebsysteminstallation}
|
||||
|
||||
\subsection{Wahl des Betriebsystems}
|
||||
\label{sub:wahl_des_betriebsystems}
|
||||
|
||||
Vorteile:
|
||||
|
||||
\begin{itemize}
|
||||
\item Packetbau ist einfacher und es gibt sehr viele Packete im \href{http://aur.archlinux.org/}{AUR}
|
||||
\item Systemd als modernes und robustes Initsystem
|
||||
\item DWIM
|
||||
\end{itemize}
|
||||
|
||||
Nachteile:
|
||||
|
||||
\begin{itemize}
|
||||
\item Updates können die Konfiguration brechen
|
||||
\item keinen kommerziellen Support
|
||||
\end{itemize}
|
||||
|
||||
\subsection{SSH-Server}
|
||||
\label{sub:ssh_server}
|
||||
|
||||
\subsection{Git-Server}
|
||||
\label{sub:git_server}
|
||||
|
||||
\subsection{Parallel Distributed Shell (PDSH)}
|
||||
\label{sub:parallel_shell}
|
||||
|
||||
Die {\tt pdsh} ist ein Tool, mit dem man parallel auf mehreren Rechnern gleichzeitig Befehle über SSH ausführen kann, um diese komplett synchron zu konfigurieren und zu administrieren.
|
||||
|
||||
Das entsprechende Paket war nicht im offiziellen Arch Linux Repository vorhanden, deshalb wurde über das AUR (Arch User Repositories) eine {\tt PKGBUILD}-Datei bezogen, die die »Anleitungen« zum Bau des Paketes enthielten. Mit {\tt makepkg} konnte dann das Paket gebaut und mit:
|
||||
\begin{center}
|
||||
\tt pacman -U pdsh-*.pkg.tar.gz
|
||||
\end{center}
|
||||
installiert werden.
|
||||
|
||||
\subsubsection{Gruppenverwaltung}
|
||||
Zur Verwaltung mehrerer Rechner in Gruppen (in unserem Fall Head-Node und Compute-Nodes) greift {\tt pdsh} auf Gruppen-Dateien von {\tt dsh} zurück. Diese können entweder pro Benutzer in {\tt ~/.dsh/group} oder systemweit in {\tt /etc/dsh/group} hinterlegt werden; da sowieso jeder Benutzer die gleichen Gruppen-Dateien verwendet, haben wir letzteres verwendet.
|
||||
|
||||
Dabei wurden folgende Gruppen-Dateien mit entsprechendem Inhalt angelegt:
|
||||
\begin{itemize}
|
||||
\item {\ttfamily \bfseries headnode}: \\
|
||||
{\tt zeus}
|
||||
|
||||
\item {\ttfamily \bfseries computenode}: \\
|
||||
{\tt ares} \\
|
||||
{\tt chronos} \\
|
||||
{\tt eris} \\
|
||||
{\tt hades}
|
||||
|
||||
\item {\ttfamily \bfseries all}: \\
|
||||
Kombination aus {\tt headnode} und {\tt computenode}
|
||||
\end{itemize}
|
||||
\input{abschnitte/bs}
|
||||
|
||||
\end{document}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user