Big-Data-Storage in der Praxis: NAS-Cluster speichert Petabytes an digitalen Mond-Bildern

Forscher der Arizona State University (ASU) setzen auf geclustertes NAS-Storage. Mit dieser Technologie können selbst riesige Daten-Mengen von Mond-Bildern der NASA bewältigt werden.

Die School of Earth and Space Exploration (SESE) der Arizona State University (ASU) hat geclustertes NAS-Storage von EMC Isilon in der Größenordnung von mehr als einem Petabyte installiert. Untergebracht werden sollen darin Hunderte von Gigabyte an Daten und Bildern, die Tag für für Tag vom Lunar Reconnaissance Orbiter (LRO) der NASA zur Erde geschickt werden.

Laut Ernest Bowman-Cisneros, Manager im LROC Science Operations Center der SESE muss sein Team Petabytes von Daten in einem einzigen Volume speichern, um den kontinuierlichen Zustrom von Bildern vom Mond zu bewältigen. Diese Implementierung entspricht genau der Art von Big Data Storage, von der die EMC-Führung seit dem Abschluss der 2,25 Milliarden US-Dollar umfassenden Übernahme von Isilon im vergangenen Dezember spricht.

Die Umstellung auf Isilon fand bei der SESE im vergangenen Jahr statt. Zu diesem Zeitpunkt begann der LRO-Orbiter, Daten zur Erde zu senden. Das vorherige Storage-Setup war bereits bei der Digitalisierung von Bildern des Apollo-Weltraumprogramms an seine Grenzen gestoßen.

Die SESE betreibt jetzt zwei Storage-Cluster der Isilon NL-Series mit elf Knoten, von denen jeder Cluster knapp unter 700 TB Kapazität aufweist. Der primäre Cluster wird für aktive Daten verwendet, der zweite für die redundante Speicherung einer Kopie an einem separaten Standort. Für die Synchronisierung der Daten zwischen den beiden Clustern greift die SESE auf die Software Isilon SyncIQ zurück.

Laut Bowman-Cisneros hat die SESE im ersten Projektjahr fast 100 TB Daten von der Mondkamera veröffentlicht. Er geht davon aus, dass pro Jahr jetzt etwa 170 TB an Daten hinzukommen werden – 120 TB veröffentlichte Daten plus ungefähr 50 TB weitere Daten vom Raumfahrzeug. Der Orbiter LRO wird voraussichtlich vier bis fünf Jahre im Orbit bleiben.

„Wir brauchen keine hohe E/A-Leistung, aber sehr wohl eine Lösung mit viel Storage“, so Bowman-Cisneros. „Eine unserer anspruchsvollsten Anforderungen bestand darin, dass wir eine Wachstumsmöglichkeit auf Volumes mit mehreren Petabyte wollten. Für den Fall, dass ein Ausbau auf solch große Volumes nicht möglich sein sollte, hätten wir mit kleinen Pods arbeiten müssen. Die Lösung hätte dann für das Verschieben der Daten von einem Volume auf ein anderes  sehr schnell sein müssen. Mit unserem Budget war das aber nicht möglich.“

Die Gruppe um Bowman-Cisneros hatte schon vor dem LRO-Projekt mit der Speicherung von Daten im großen Umfang begonnen, wie er berichtet: Sie war am Apollo Scan Projekt zur Digitalisierung der Bilder aus den Apollo-Missionen beteiligt, das vom Johnson Space Center der NASA im Jahr 206 begonnen wurde.

Für das Apollo-Scanprojekt verwendete die SESE ursprünglich NetApp-Storage mit redundant ausgelegten Red Hat Global File System (GFS)-Knoten, eingerichtet von der High-Performance Computing (HPC)-Gruppe der Arizona State University. Das Projekt gab dem Team von Bowman-Cisneros die Zeit, eventuelle Storage-Probleme in den Griff zu bekommen, bevor die LRO-Kameras ab 2010 erstmals Daten zur Erde senden würden.

Nach sechs Monaten Projektdauer waren die Cluster zu groß für die GFS-Heads der SESE geworden und führten zu System-Crashs, erinnert sich Bowman-Cisneros. Einer dieser Crashs dauerte eine Woche lang.

„Laut Red Hat betrieben wir einen der größten Backend-Cluster auf GFS und sind an die Grenzen dieser Implementierung gestoßen“, sagt er. „Die Größe des Systems und die Art und Weise, in der auf das System zugegriffen wurde, haben dazu geführt, dass die GFS-Heads verrücktspielten. Eine Zeitlang hatten wir mehrere Heads, doch nach dem einwöchigen Ausfall mussten wir zu einem einzelnen Knoten zurückkehren, um den Betrieb fortzuführen und das Problem zu umgehen.“

Das LRO-Team habe zwar zu keiner Zeit Daten verloren, doch die Crashs hätten lästige Verzögerungen verursacht. „Immer wenn einiges los war, hatte dieser eine Knoten die Tendenz, sich aufzuhängen. Dann mussten wir ihn neu starten, was immer zu gewissen Verzögerungen bei der Datenverarbeitung führte“, erzählt Bowman-Cisneros. „Wenn die Belastung auf diesem Knoten sehr hoch war, hat er sogar das Dateisystem lahmgelegt und den Status der Backend-Filer verloren. Die Storage-Lösung war nicht dann mehr verfügbar und wir mussten auf den Neustart warten. Die Lösung hat zwar funktioniert, hatte aber diese Performance-Probleme. Außerdem brauchten wir für den nächsten Schritt in der Verarbeitung mehr Speicherkapazität.“

Nachdem das ursprüngliche Storage-System vier Jahre im Einsatz war, beschloss Bowman-Cisneros, dass es Zeit für ein Upgrade war. Er hatte mit etwas sechs NAS-Anbietern gesprochen, aber nur Isilon und IBM erklärten sich bereit für die Anforderungen von LRO. Isilon schlug seine NL-Series vor und IBM sein Storage-System SONAS (Scale Out Network Attached Storage) auf der Basis des eigenen General Parallel File System (GPFS).

Isilon stellte bereits Anfang Dezember ein Testsystem mit sechs Knoten zur Verfügung. „Das System hat mit Bravour bestanden“, berichtet Bowman-Cisneros darüber. Seit ungefähr einem Monat sei das komplette Isilon-System jetzt im Produktiv-Betrieb.

„Isilon hat sich sehr dafür eingesetzt, dass wir die Geräte schnell bekommen und sie korrekt aufgesetzt werden. Innerhalb kürzester Zeit hatten wir ein Setup, das einer vollständigen Implementierung der Hardware entsprach. Damit konnten wir alle unsere Anforderungen überprüfen und einige Problemfälle testen, die bei der alten Lösung aufgetreten waren“, so Bowman-Cisneros.

Das einzige Problem, das er mit Isilon bislang hatte, war ein Software-Patch, der Schwierigkeiten mit dem sekundären Knoten verursachte, was jedoch den Tagesbetrieb nicht beeinträchtigte. Der technische Support konnte das Problem schnell lösen und den Patch ohne Problem auf beide Systeme anwenden.

Bowman-Cisneros befand sich gerade mitten in der Testphase für das Isilon-System, als EMC   die Übernahme des Anbieters für geclusterte NAS-Lösungen verhandelte. „Erst als wir bereits unterschrieben hatten, haben wir von den EMC-Plänen erfahren“, sagt Bowman-Cisneros. „Ende Dezember hatten wir unsere Testphase abgeschlossen und wir uns für Isilon entschieden. Zu diesem Zeitpunkt hatte die Übernahme für uns keinerlei Bedeutung. Meine einzige Sorge ist, ob EMC das von uns eingesetzte Modell in Zukunft wirklich weiterentwickeln und unterstützen wird.“

Erfahren Sie mehr über Clustered-NAS

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close