Warum Data Gravity auch für HPC eine Rolle spielt

Die Datenspeicherung im High-Performance-Computing-Bereich ist seit jeher eine der schlecht ausgeleuchteten Ecken der Computerbranche. Der enorme Bedarf an Geschwindigkeit und insgesamt die Größenordnung der Gesamtherausforderung verlangt nach sehr differenzierten technischen Lösungen. 

Eine der Schwierigkeiten, die sich aus der Komplexität der HPC-Datenspeicherung ergeben: auftretenden Probleme und die dafür erforderlichen Lösungen so zu erklären, dass auch diejenigen, die keine Experten auf diesem Gebiet sind, sie nachvollziehen können.

Welche Analogien oder mentalen Modelle können wir verwenden, um Managern und Führungskräften, die für die HPC-Installation in einem Unternehmen verantwortlich zeichnen, das Verständnis dafür zu erleichtern, was sie benötigen, damit ihre HPC-Ausrüstung mit höchster Effizienz arbeitet?

Eines der zur Verfügung stehenden mentalen Bilder: Daten haben „Masse“. Genauso wie ein Kubikmeter Gold viel schwerer aufzuheben und zu bewegen ist als ein Kubikzentimeter Gold, ist ein Petabyte an Daten viel schwerer vom Speicher zum Rechner (und wieder zurück) zu bewegen als ein Megabyte an Daten.

Dass Daten über eine Masse verfügen, ist sogar noch zutreffender, als es auf den ersten Blick erscheinen mag. Um einen Kubikmeter Gold nach oben in die Racks eines Rechenzentrums zu heben, ist eine erhebliche Menge an Infrastruktur erforderlich – etwa ein verstärkter Bodenbelag, aber auch einfach ein Vielfaches an Energie. Ein HPC-Speichersystem benötigt Energie, um Petabyte an Daten auf den Laufwerken abzurufen oder zu speichern, und die gesamte Netzwerkausrüstung, die erforderlich ist, um Petabyte an Daten mit hoher Bandbreite zu übertragen, erfordert noch wesentlich mehr Energie.

Eine weitere verwandte Analogie: Daten durchlaufen je nach ihrer Menge „Phasenwechsel“ – ähnlich wie der Aggregatzustandswechsel von Dampf in Wasser oder Eis. Dampf, Wasser und Eis sind ein und dasselbe, aber die Temperatur definiert den wesentlichen Unterschied bei der Bearbeitung.

„Datenmengen in der Größenordnung, die HPC typischerweise verarbeitet, erfordern eine physische Infrastruktur und ein Energieniveau, das bei Speicherlösungen für Unternehmen nicht gegeben ist.“

Curtis Anderson, Panasas

Ein Megabyte Daten ist wie Wasserdampf, der außer einer gewissen Isolierung nur ein paar leere Rohre benötigt, um von einem Ort zum anderen zu gelangen. Ein Gigabyte an Daten ist wie Wasser: Man braucht immer noch leere Rohre, aber man braucht auch einige elektrische Pumpen, um es von einem Ort zum anderen zu befördern. Ein Petabyte an Daten schließlich ist eher mit Eis zu vergleichen, das nicht durch Rohre fließt, egal wie sehr man es antreibt, man muss es in Blöcke schneiden oder zerkleinern und auf ein Förderband legen. Das ist nicht nur sehr viel energieintensiver, sondern erfordert auch eine ganz andere physische Infrastruktur als vergleichsweise Wasser oder Dampf. Es ist die Datenmenge (die Temperatur des Wassers), die den Unterschied ausmacht, und es ist die Art und Weise, wie man sie verarbeitet.

„Parallele Dateisysteme“ wurden als Ableger typischer Netzwerkdateisysteme wie NFS oder SMB/CIFS erfunden, und zwar genau deshalb, weil sie das „Förderband“ sein können und nicht das einfache „Rohr“, das HPC-Systeme benötigen.

Diese beiden Analogien liefern einfache mentale Modelle dafür, warum sich HPC-Speicherlösungen so sehr von Enterprise-Speicherlösungen unterscheiden. Datenmengen in der Größenordnung, die HPC typischerweise verarbeitet, erfordern eine physische Infrastruktur und ein Energieniveau, das bei Speicherlösungen für Unternehmen nicht gegeben ist.

Über den Autor:
Curtis Anderson ist ein Datenspeicher-Experte mit mehr als 34 Jahren Erfahrung. Seinen Schwerpunkt legt Anderson auf die Implementierung von Dateisystemen. Anderson war einer der fünf ursprünglichen Autoren des XFS-Dateisystems, das heute in Linux weit verbreitet ist, und arbeitete an dem Veritas VxFS-Dateisystem, bevor Veritas aus der Taufe gehoben wurde. Er war ferner 14 Jahre lang Mitglied der IEEE, unter anderem als Sponsor Chair für die IEEE 1244 Working Group, die einen formalen Standard für die gemeinsame Nutzung von Bandlaufwerken und Bandrobotern in einem SAN durch mehrere Hosts abstimmte und veröffentlichte. In seiner Funktion als Softwarearchitekt bei Panasas ist Anderson für die Koordinierung von Technologieteams verantwortlich, die an verschiedenen Elementen arbeiten, aus denen sich das parallele Speicherdateisystem von Panasas zusammensetzt. Vor seiner Tätigkeit bei Panasas war Anderson als Technical Director bei NetApp sowie als Architekt bei EMC/Data Domain tätig. Anderson hält 10 Patente, unter anderem in den Bereichen kontinuierliche Datensicherung und Replikation von deduplizierten Dateidaten über ein Netzwerk.

Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.