Neben der bereits erwähnten Hardware muss es natürlich auch Software, wie das Betriebssystem oder die Anwendungen geben, damit die Leistung des \ac{HPC} genutzt werden kann.
Als letztes wird noch darauf eingegangen, für welche Art von Software ein \ac{HPC} genutzt werden kann und welche Anforderungen die Software erfüllen muss.
Viele Betreiber der \ac{HPC} setzen auf \ac{RHEL}, das von Redhat für den kommerziellen Markt entwickelt wird und dadurch zum Teil auch stabiler als andere Derivate läuft.
Da in \ac{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 \ac{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.
Anhand von Abbildung~\ref{fig:top500_os} wird deutlich, das Windows, Mac und BSD bis maximal 2016 in wenigen \ac{HPC} genutzt wurden, heutzutage wird aber ausschließlich Linux verwendet\cite{top500list}.
Des weiteren sind die Kernel sehr effizient und versuchen einer Applikation möglichst viele Ressourcen (\ac{CPU}, \ac{RAM}, Netzwerk-Bandbreite, \ldots) zuzuweisen, damit die Berechnungszeit der Anwendung minimiert wird\cite{lightweightKernel}\cite[S. 19f]{gerofi2019operating}.
Remote Management, also das Steuern und Überwachen von Geräten aus der Ferne, ist für Server und \ac{HPC} extrem wichtig.
Ein \ac{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 physischen Zugriff erlangen kann.
Durch verschiedene Sicherheitsmechanismen wird in vielen Fällen der Zutritt zum Rechenzentrum und damit auch zur \ac{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 \ac{IPMI}.
Über eine dedizierte Netzwerkschnittstelle und ein zusätzliches Management-Netzwerk kann Remote auf den Server zugegriffen werden, um zum Beispiel die \ac{CPU}-Auslastung, die Temperatur von RAM oder \ac{CPU} zu Überwachen.
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.
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.
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/Head 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 \ac{RAM}.
Wenn das Cluster dann aber zum Beispiel 158.976 Nodes hat, so wie das aktuell schnellste \ac{HPC}, steigt der \ac{RAM} Verbrauch und wird vermutlich die 32GB \ac{RAM} pro Node deutlich übersteigen\cite{xCAT_docs, top500list}.
Die Software wird nur in CentOS getestet, aber durch die starken Ähnlichkeiten zu zum Beispiel \ac{RHEL}, sollte sie auch dort funktionieren.
Auch OpenHPC hat es sich zur Aufgabe gemacht, die Einrichtung eines \ac{HPC} zu vereinfachen, was natürlich dann auch zu reduzierten Betriebskosten des \ac{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}:
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.
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.