HDFS als Filestorage für den Red Bull Content Pool
Das Hadoop Distributed File System (HDFS), die Storage-Einheit des Apache Hadoop Projektes, verwaltet spielend riesige Datenmengen, lässt sich im laufenden Betrieb bequem skalieren und ist komfortabel zu administrieren. Das HDFS-Konzept macht es einerseits robust gegen Ausfälle, andererseits ist es enorm schnell in der Auslieferung. HDFS wurde jedoch ausdrücklich nicht als Onlinestorage konzipiert.
Am Anfang war der Content
Und zwar jede Menge davon. So viel, dass sich die Red Bull Media House GmbH nach einer neuen Lösung für den Red Bull Content Pool umsah. Das rasant wachsende Datenvolumen und die steigenden Benutzerzahlen erforderten neue Strategien und Konzepte. Der angesichts dieser Datenmengen enorme Bedarf an Hardware ging gleichzeitig mit einem erhöhten Ausfallrisiko einer dieser Komponenten einher. Eine Problematik, der sich die Red Bull Media House GmbH bewusst war. Eine neue Onlinestorage-Lösung musste her. Aber welche? Bereits in den ersten Gesprächen legte Red Bull Media House ausführlich das Vorhaben von Red Bull dar: Dabei war die übergeordnete Zielsetzung das beachtliche und täglich wachsende Datenvolumen bestmöglich zu verwalten.
Die Anforderungen der Red Bull Media House GmbH
Der „Red Bull Content Pool“ dient dem Kunden als zentrales Repository, in dem sämtlicher Content von Red Bull abgelegt wird und in weiterer Folge schnell und einfach weltweit zur Verfügung gestellt werden soll.
Dazu zählen Videodateien von kurzen Clips bis zu längeren Produktionen, die im Rahmen vieler Events wie Red Bull Airrace, Formel 1 oder X-Fighters produziert wurden oder auch sämtliche Still Images und Audiodateien, die in verschiedenen Formaten und Qualitätsstufen vorgehalten werden bzw. jederzeit auf Abruf generiert werden können.
In den folgenden Abschnitten werden die Varianten mit ihren Möglichkeiten und Grenzen kurz skizziert; jeweils vor dem Hintergrund der konkreten Kundenanforderungen. Die Vorgabenliste enthielt neben dem Hosting der Infrastruktur folgende Punkte:
- Storage im Petabyte-Bereich
- Redundanz der Daten
- sehr hohe Lesegeschwindigkeit durch schnelle Datenauslieferung
- einfache Nutzbarkeit für Applikationen ohne Wartungsfenster
- skalierbar
- kurze Downtime im Fehlerfall, günstiger als Standardlösungen, beispielsweise mit EMC
Zunächst wurde seitens Red Bull über Standard-Storage-Lösungen von EMC oder NetApp nachgedacht. Wir schlugen jedoch vor, den Einsatz eines Distributed File Systems oder andere Lösungen in Erwägung zu ziehen. Beim DFS z. B. handelt es sich um ein verteiltes Dateisystem, das den Zugriff auf Dateien über ein Rechnernetz und die Speicherung der Daten auf mehreren Standardservern erlaubt. Verschiedene Open-Source-Ansätze wurden bei Adacor diskutiert und getestet, um alle Anforderungen des Kunden zu erfüllen. Darunter waren NFS, GlusterFS, Lustre, Openfiler, CloudStore und schließlich HDFS. Im Folgenden werden die Varianten mit ihren Möglichkeiten und Grenzen kurz skizziert; jeweils vor dem Hintergrund der konkreten Kundenanforderungen.
Eine perfekte, allen Anforderungen gleichermaßen gerecht werdende Lösung gibt es im Projektalltag selten. Dies wissen alle, die schon einmal gefragt haben, ob das Phänomen der eierlegenden Woll-Milch-Sau real jemals überlebensfähig wäre. Daher wiesen alle getesteten Dateisysteme viele Vorteile und einige Nachteile auf. Sie wurden detailliert mit der Red Bull Media House erörtert. Als Favorit kristallisierte sich vor dem Hintergrund der Systemanalysen und im Hinblick auf die Anforderungen von Red Bull HDFS heraus.
Im HDFS gibt es zwei Typen von Servern: NameNodes und DataNodes. Die Datenblöcke werden auf den DataNodes vorgehalten; sämtliche Meta-Informationen sind auf dem Name-Node gespeichert. Alle Daten auf den DataNodes werden mehrfach redundant gesichert, sofern ein Replikationsfaktor konfiguriert wurde. Allerdings stellt der NameNode einen Single Point of Failure dar. Er bildet die Kernfunktion des Systems, das für den schnelleren Lesezugriff große Dateien in kleinere Datenblöcke teilt. Für diese Blöcke vergibt der NameNode IDs, die er im Index verwaltet. Fällt der NameNode wegen eines Hardwarefehlers aus oder wird beschädigt, muss er manuell neu gestartet oder mithilfe eines Ersatz-Nodes wiederhergestellt werden. Auch Konfigurationsdateien sind anzupassen. Insgesamt kann dies einige Minuten dauern. Während dieser Zeit ist kein Zugriff auf das HDFS möglich. Aktuell laufende Schreib- und Leseprozesse auf das Filesystem werden mit einer Fehlermeldung abgebrochen. Die Problematik des NameNodes war sowohl Adacor als auch dem Kunden bekannt und wurde bewusst akzeptiert.
Nachdem die Entscheidung für HDFS gefallen war, wurde im Rahmen des konkreten Designprozesses ein großer Wert darauf gelegt, dem Schwachpunkt bestmöglich Rechnung zu tragen: Hierfür wird der Index zunächst lokal und im Netz gespeichert, zusätzlich wird regelmäßig eine Sicherungskopie angelegt. Um Downtimes auf ein Minimum zu reduzieren und Fehler frühzeitig zu erkennen, werden alle Server rund um die Uhr via Monitoring überwacht. Bei einem Alarm wird sofort ein Techniker informiert, der umgehend eingreifen kann. Für Red Bull Media House erwies sich HDFS als die beste Storage-Lösung, die nicht nur in der Theorie, sondern von 2008 bis in die 2020er Jahre in der Praxis sehr gut funktionierte.
Adacor und Red Bull Media House waren mit dem Ergebnis mehr als zufrieden. Zeitweise wurden netto rund 250 Terabyte Datenvolumen auf unseren Servern gehostet, dessen Wert aufgrund der redundanten Vorhaltung der Daten sogar doppelt so hoch war.
Der interne und externe Zugriff auf den Red Bull Content Pool wurde von einer eigens entwickelten Applikation verwaltet. Diese Applikation namens Media-Manager wurde von der Darmstädter Firma Signal7 entwickelt und ebenfalls auf den Adacor-Servern der gehostet.
