generated from DHBW/LaTex_Hausarbeit_Template
99 lines
9.3 KiB
TeX
99 lines
9.3 KiB
TeX
\chapter{Software}\label{ch:software}
|
|
Neben der bereits erwähnten Hardware muss es natürlich auch Software, wie das Betriebssystem oder die Anwendungen geben, damit die Leistung des \acrshort{hpc} genutzt werden kann.
|
|
Im folgenden soll zunächst auf das Betriebssystem beziehungsweise die Anforderungen an ein Betriebssystem eingegangen werden.
|
|
Des Weiteren ist auch eine Software für das Remote Management wichtig, da diese das Arbeiten mit dem Cluster signifikant verbessert.
|
|
Danach sollen noch zwei Tools vorgestellt werden, mit denen der gesamte Einrichtungs- und Administrierprozess eines Clusters vereinfacht werden soll.
|
|
Als letztes wird noch darauf eingegangen, für welche Art von Software ein \acrshort{hpc} genutzt werden kann und welche Anforderungen die Software erfüllen muss.
|
|
|
|
\section{Betriebssystem}\label{sec:betriebssystem}
|
|
Für High Performance Cluster wird in den meisten Fällen ein Linux Derivat verwendet.
|
|
Viele Betreiber der \acrshort{hpc} setzen auf \acrshort{rhel}, das von Redhat für den kommerziellen Markt entwickelt wird und dadurch zum Teil auch stabiler als andere Derivate läuft.
|
|
Eine weitere Möglichkeit ist das Betriebssystem CentOS.
|
|
Dieses Betriebssystem baut auf \acrshort{rhel} auf, wird aber nicht direkt von RedHat, sondern von freiwilligen Entwicklern weiterentwickelt.
|
|
Auf Web-Servern ist diese Distribution nach Debian und Ubuntu die am häufigsten genutzte\cite{os_usage_stats}.
|
|
Da in \acrshort{hpc} meistens keine \glqq normale\grqq Consumer-Hardware verwendet wird, sondern spezielle Hochleistungskomponenten, die vom Kernel unterstützt werden müssen, sind die Enterprise Distributionen \acrshort{rhel} oder CentOS oftmals besser geeignet als zum Beispiel Debian\cite{rhel}.
|
|
Die Linux-Derivate beziehungsweise deren Kernel haben gegenüber Windows oder anderen Betriebssystemen den Vorteil, dass sie beliebig angepasst, beziehungsweise auch neu kompliliert, werden können und in den Rechenzentren dann eine speziell modifizierte Version genutzt werden kann.
|
|
In der Liste Top500 werden die offiziell 500 schnellsten Supercomputer aufgelistet.
|
|
Anhand von Abbildung~\ref{fig:top500_os} wird deutlich, das Windows, Mac und BSD bis maximal 2016 in wenigen \acrshort{hpc} genutzt wurden, heutzutage wird aber ausschließlich Linux verwendet\cite{top500list}.
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=\textwidth]{images/Operating_systems_used_on_top_500_supercomputers.svg}
|
|
\caption{Verbreitung einiger Betriebssysteme unter den Top500 \acrshort{hpc}\cite{top500image}}
|
|
\label{fig:top500_os}
|
|
\end{figure}
|
|
|
|
In den \acrshort{hpc} werden oftmals Lightweight Kernel verwendet.
|
|
Lightweight Kernels sind dafür optimiert, mit verteiltem Speicher und tausenden von Prozessoren zusammen zu arbeiten.
|
|
Des weiteren sind die Kernel sehr effizient und versuchen einer Applikation möglichst viele Ressourcen (\acrshort{cpu}, \acrshort{ram}, Netzwerk-Bandbreite, \ldots) zuzuweisen, damit die Berechnungszeit der Anwendung minimiert wird\cite{lightweightKernel}\cite[S. 19f]{gerofi2019operating}.
|
|
|
|
\section{Remote Management}\label{sec:remote-management}
|
|
% https://www.engr.siu.edu/staff1/ahmed/mywebpage/Maxwell_SIUC_HPC_Description_Tutorial.pdf
|
|
% https://www2.latech.edu/~box/hapc/Chapter-1.pdf
|
|
Remote Management, also das Steuern und Überwachen von Geräten aus der Ferne, ist für Server und \acrshort{hpc} extrem wichtig.
|
|
Ein \acrshort{hpc}, dass oftmals aus mehreren Racks besteht, kann natürlich nicht mit dem privaten Desktop-PC oder Laptop verglichen werden, auf die man relativ einfach pyhsischen Zugriff erlangen kann.
|
|
Durch verschiedene Sicherheitsmechanismen wird in vielen Fällen der Zutritt zum Rechenzentrum und damit auch zur \acrshort{hpc}-Hardware erschwert und oftmals steht das Rechenzentrum auch gar nicht in der Nähe des Anwenders sondern zum Beispiel in der Nähe eines großen Internet-Knotenpunktes.
|
|
Um trotzdem (fast) alle Administrativen Aufgaben erledigen zu können, gibt es eine spezielle Schnittstelle, die oftmals auch direkt im Mainboard des Servers untergebracht ist.
|
|
Diese Schnittstelle nennt sich zum Beispiel \acrshort{ipmi}.
|
|
Über eine dedizierte Netzwerkschnittstelle und ein zusätzliches Management-Netzwerk kann Remote auf den Server zugegriffen werden, um zum Beispiel die \acrshort{cpu}-Auslastung, die Temperatur von RAM oder \acrshort{cpu} zu Überwachen.
|
|
Im Extremfall kann sogar über das Internet ein neues Betriebssystem installiert werden\cite{ipmi_specs}.
|
|
Zusätzlich zur Überwachung über \acrshort{ipmi} sind auch Healthchecks sinnvoll.
|
|
Wenn zum Beispiel Container genutzt werden (dazu später mehr), kann in jedem Container eine periodisch ausgeführte Aufgabe eingebaut wird, die dann zum Beispiel alle 5 Sekunden überprüft, ob alles in Ordnung ist.
|
|
|
|
Da ein \acrshort{hpc} in den seltensten Fällen von einem Nutzer alleine genutzt wird, müssen sich mehrere Nutzer Remote anmelden.
|
|
Um zu regulieren, wer sich anmelden darf, welche Rechte die jeweilige Person hat oder um später zu rekonsturieren, welcher Nutzer welche Prozesse ausgeführt hat, muss auch ein Authentifizierungssystem genutzt werden.
|
|
|
|
Als letztes ist auch noch die Automatisierung und das Resource-Management unerlässlich.
|
|
Da viele Jobs nicht die gesamte Leistung des \acrshort{hpc} brauchen, können mehrere parallel ausgeführt werden.
|
|
Diese Aufgabe wird zum Beispiel vom Resource-Manager erledigt.
|
|
|
|
\section{xCAT}\label{sec:xcat}
|
|
xCAT (Extreme Cloud Administration Toolkit) ist ein, von IBM entwickeltes, open-source Tool, dass zur Erstellung, Administration und zum Deployment von verteilten Systemen genutzt wird.
|
|
Vor allem das erstellen und managen von Clustern erfordert, wie in Kapitel~\ref{sec:remote-management} bereits erwähnt, viel administrativen Aufwand.
|
|
Die Software wird auf dem Management Node installiert und kann danach mit vergleichsweise wenig Aufwand die einzelnen Nodes im Netzwerk finden und einrichten
|
|
Um die Last des Management Nodes zu reduzieren, können auch Compute Nodes als Service Nodes verwendet werden, die dann ähnliche Aufgaben wie der Managament Node übernehmen, aber trotzdem noch vom Management Node gesteuert werden (siehe Abbildung~\ref{fig:xcat_architektur}).
|
|
Das ist vorallem wichtig, wenn die Speicher-Voraussetzungen von IBM beachtet werden: ein kleines Cluster, mit weniger als 16 Nodes, braucht schon ca. 5GB \acrshort{ram}.
|
|
Wenn das Cluster dann aber zum Beispiel 158.976 Nodes hat, so wie das aktuell schnellste \acrshort{hpc}, steigt der \acrshort{ram} Verbrauch und wird vermutlich die 32GB \acrshort{ram} pro Node deutlich übersteigen\cite{xCAT_docs, top500list}.
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=\textwidth]{images/Xcat-arch}
|
|
\caption{xCAT Architektur\cite{xcatimage}}
|
|
\label{fig:xcat_architektur}
|
|
\end{figure}
|
|
|
|
|
|
\section{OpenHPC}\label{sec:openhpc}
|
|
Ähnlich wie xCAT gibt es auch noch OpenHPC.
|
|
OpenHPC ist ebenfalls eine open-source Anwendung, die von der Linux Foundation entwickelt wird.
|
|
Die Software wird nur in CentOS getestet, aber durch die starken Ähnlichkeiten zu zum Beispiel \acrshort{rhel}, sollte sie auch dort funktionieren.
|
|
Auch OpenHPC hat es sich zur Aufgabe gemacht, die Einrichtung eines \acrshort{hpc} zu vereinfachen, was natürlich dann auch zu reduzierten Betriebskosten des \acrshort{hpc} führt.
|
|
Durch einen einzigen Software-Stack mit standardisierten, getesteten Komponenten, hat der Administrator die Möglichkeit ohne großen Konfigurationsaufwand das Cluster einzurichten und zu nutzenn.
|
|
Der Software-Stack besteht aus vielen verschiedenen einzelnen Tools, die in einzelne Kategorien eingeteilt werden können\cite{openhpc_docs}:
|
|
\begin{itemize}
|
|
\item Administration
|
|
\item Compiler
|
|
\item Entwicklung
|
|
\item \acrshort{io}
|
|
\item Parallelisierung
|
|
\item Performance Management
|
|
\item Resource Management
|
|
\item \ldots
|
|
\end{itemize}
|
|
|
|
Wie bei xCAT wird die Software zunächst nur auf dem Master-Node installiert, der dann später die Compute-Nodes mit der entsprechenden Software versorgt und auch die Aufgaben verteilt.
|
|
|
|
Auch wenn OpenHPC von der Linux Foundation entwickelt wird, sind viele große Unternehmen wie Dell, Fujitsu, Lenovo, Intel oder HP an der Entwicklung beteiligt.
|
|
Diese Unternehmen setzen die Software dann zum Teil auch in Clustern ein\cite{openhpc_presentation}.
|
|
|
|
\section{Anwendungssoftware}\label{sec:anwendungssoftware}
|
|
Für was kann die Leistung eines \acrshort{hpc} genutzt werden?
|
|
|
|
Oft werden die Cluster mithilfe von Containern genutzt.
|
|
Containerisierung ist eine Virtualisierungsmethode, bei der die Gäste (Instanzen eines Betriebssystems) isoliert voneinander den Kernel des Hostsystems nutzen.
|
|
Im Gegensatz zu anderen Virtualisierungsmethoden ist die Containerisierung ressourcenschonender.
|
|
Die Container haben in \acrshort{hpc} den Vorteil, dass sie vom Host-Betriebssystem und den System-Librarys getrennt sind.
|
|
Betriebssystem Aktualisierungen haben keinen Einfluss auf die Software, die in den Containern läuft\cite[S. 12]{gerofi2019operating}.
|
|
|
|
Die meisten \acrshort{hpc} werden vom Militär, von Regierungen, von der Industrie oder von Forschern genutzt.
|
|
Dabei werden oft mithilfe von \acrshort{ai}, \acrshort{ml} oder \acrshort{dl}, Berechnungen durchgeführt\cite[S. 12f]{gerofi2019operating}.
|
|
Die Rechenleistung wird unter anderem für Wettervorhersagen, die Öl- und Gasförderung, den Bereich der Physik und Quantenmechanik verwendet.
|
|
Mit einem einzelnen \acrshort{pc} oder Server wären solche Berechnungen nicht möglich oder würden extrem lange dauern\cite{intel_what_is_hpc}. |