Lustre, Gluster oder MogileFS? für Videospeicherung, -kodierung und -streaming

Question

So viele Optionen und so wenig Zeit, sie alle zu testen... Ich frage mich, ob jemand Erfahrungen mit verteilten Dateisystemen für Videostreaming und Speicherung/Kodierung hat.

Ich habe viele große Videodateien (50 bis 250 GB), die ich irgendwo speichern, in mp4 kodieren und von mehreren Adobe FMS-Servern streamen muss. Die einzige Möglichkeit, dies zu bewerkstelligen, ist ein verteiltes Dateisystem, aber jetzt stellt sich die Frage, welches?

Meine bisherigen Nachforschungen haben mir gezeigt:

• Lustre Ausgereifte und bewährte Lösung, die von vielen großen Unternehmen verwendet wird und sich am besten für >10G-Dateien eignet, ist ein Kernel-Treiber.
• Gluster : neu, weniger ausgereift, FUSE-basiert, d.h. einfach zu installieren, aber möglicherweise langsamer aufgrund des FUSE-Overheads. Besser zu handhaben eine große Anzahl von kleineren Dateien ~1GB
• MogileFS FUSE: scheint nur für kleine Dateien (~MB) zu sein, verwendet HTTP für den Zugriff? mögliche FUSE-Anbindung in der Zukunft.

Bis jetzt scheint Lustre der Gewinner zu sein, aber ich würde gerne echte Erfahrungen für meine spezielle Anwendung hören.

Auch Hadoop, Redhat GFS, Coda und Windows DFS kommen in Frage, daher sind alle Erfahrungen willkommen. Wenn jemand Benchmarks hat, bitte teilen.

Nach einigen realen Erfahrungen habe ich Folgendes gelernt:

• Lüster:
  • Leistung: Erstaunlich schnell! Ich kann behaupten, dass Lustre eine Menge von Streams bedienen kann und dass die Verschlüsselungsgeschwindigkeit durch den Zugriff auf Dateien über Lustre nicht beeinträchtigt wird.
  • POXIS-Kompatibilität: Sehr gut!. Keine Notwendigkeit, Anwendungen zu ändern, um Luster zu verwenden.
  • Replikation, Lastausgleich und Fail Over: Sehr schlecht!. Für die Replikationslast Lastausgleich und Fail Over müssen wir uns auf andere Software wie virtuelle IPs und DRDB.
  • Einbau: Das Schlimmste!. Unmöglich von Normalsterblichen zu installieren. Erfordert eine sehr spezielle Kombination von Kernel, Lustre-Patches und Tweaks, damit es funktioniert. Und aktuelle Luster-Patches funktionieren normalerweise mit alten Kerneln, die mit neuer Hardware/Software nicht neuer Hardware/Software.
• MogileFS:
  • Leistung: Gut für kleine Dateien, aber unbrauchbar für mittlere bis große Dateien. Dies ist liegt hauptsächlich am HTTP-Overhead, da alle Dateien über HTTP-Anfragen gesendet/empfangen werden, die die alle Daten in base64 kodieren, was einen Overhead von 33% für jede Datei bedeutet.
  • Die POXIX-Kompatibilität ist nicht gegeben. Alle Anwendungen müssen modifiziert werden, um Mogilefs zu verwenden, was es für Streaming/Encoding unbrauchbar macht, da die meisten Streaming-Server und Kodierungstools das MogileFS-Protokoll nicht verstehen.
  • Replikation und Failover out of the box und Lastausgleich können in der Datenbank implementiert werden. Anwendung implementiert werden, indem auf mehr als einen Tracker zur gleichen Zeit zugegriffen wird.
  • Die Installation ist relativ einfach und in den meisten Distributionen gibt es bereits fertige Pakete. Die einzige Schwierigkeit, die ich gefunden habe, war die Einstellung der Datenbank als Master-Slave, um den einzigen Ausfallpunkt zu beseitigen.
    • Gluster:
  • Leistung: Sehr schlecht für Streaming. Ich erreiche nicht mehr als ein paar Mbps in einem 10Gbps Netzwerk. Clients und Server-CPU schießen bei schweren Schreibvorgängen in die Höhe. Für die Kodierung funktioniert, weil die CPU vor dem Netzwerk und der E/A gesättigt ist.
  • POXIS: Fast kompatibel. Die Tools, die ich verwende, können auf Gluster-Mounts wie normale Ordner auf Festplatte zugreifen, aber in einigen Randfällen fangen die Dinge an, Probleme zu verursachen. Schauen Sie in die Gluster Mailinglisten und Sie werden sehen, dass es eine Menge Probleme gibt.
  • Replikation, Ausfallsicherung und Lastausgleich: Das Beste! wenn sie tatsächlich funktionieren würden. Gluster ist sehr neu und hat eine Menge Bugs und Leistungsprobleme.
  • Die Installation ist zu einfach. Die Management-Befehlszeile ist erstaunlich und Einstellung repliziert, Striped und verteilte Volumes auf mehreren Servern kann nicht einfacher sein.

Abschließende Schlussfolgerung:

Leider lautet die Schlussfolgerung: "Es gibt kein Patentrezept".

Derzeit haben wir unsere Mediendateien in Gluster3.2 in einem replizierten Volume zur Speicherung und Transkodierung. Solange man nicht viele Server hat, Georeplikation und Stripe-Volumes vermeidet, funktioniert alles gut.

Wenn wir die Mediendateien streamen wollen, kopieren wir sie auf ein Lustre-Volume, das über DR:DB auf ein zweites Lustre-Volume repliziert wird. Der Wowza-Server liest dann die Mediendateien von den Lustre-Volumes.

Und schließlich verwenden wir MogileFS, um die Vorschaubilder auf unseren Webanwendungsservern bereitzustellen.

Answer 1

GlusterFS hat sich bis zu diesem Zeitpunkt stark verbessert. Sie bieten jetzt "granulares Sperren" für große Dateien an. Siehe hier: http://www.gluster.org/community/documentation/index.php/WhatsNew3.3 Es ist auch ziemlich abhängig von den Videobildraten, für die Sie ebenfalls arbeiten sollten. Wenn Sie nicht bis zu 4K-Raten gehen wollen, kann Gluster die Speicherprobleme lösen. Wenn es einen großen Bedarf an Geschwindigkeit gibt, kann Infiniband ins Spiel kommen.

Answer 2

Sehen Sie sich das Hadoop-Dateisystem (HDFS) an. Sein Schwerpunkt liegt auf sehr großen Dateien und parallelen Aufgaben (mit map/reduce), es hat eine hohe Latenz, aber einen sehr hohen Durchsatz. Es wird derzeit in so großen Installationen wie Facebook und amazon.com verwendet.

Answer 3

MogileFS eignet sich hervorragend für diese Art von Aufgaben. Die Qualität der Client-Bibliotheken variiert ein wenig, aber ich wäre überrascht, wenn es keine groß angelegten Produktionsseiten gäbe, die so ziemlich jede Sprache für den Zugriff verwenden.

HTTP ist eigentlich ein gutes Protokoll für diese Zwecke. Wer hat nicht einen funktionsreichen und effizienten HTTP-Client?

Answer 4

Von den genannten Systemen ist MoglieFS am besten geeignet.

Vielleicht kommen Sie aber auch ganz ohne ein spezielles System aus. Nehmen wir an, Sie haben 4 AdobeFMS-Server:

{video0.exmple.com,video1.exmple.com,video2.exmple.com,video3.exmple.com}.

Sie können alle Ihre Videos auf diese 4 Server verteilen, indem Sie ein einfaches Schema verwenden, wie

    /*
     *  pseudo code
     */

    $server_id = get_server_id(filename);
    ...
    ...
    int function get_server_id(filename) 
    { 
       return hash(filename) mod 4;
    }

Nach der Codierung der Videos würde Ihre Anwendung

$server_id = get_server_id(file_name)
copy file_name to /mnt/$server_id/

Clients greifen auf Videos zu, indem sie etwas wie http://videoN.example.com/filename.mp4 , wobei N aus dem Dateinamen berechnet wird mit get_server_id() .

Luster/Gluster ist wirklich nicht das, wonach Sie suchen sollten. Luster FS ist ausgereifter, aber die Entwickler bitten Sie, Dateien auf einem solchen FS als "Cache" zu behandeln, d.h. sie können jederzeit verloren gehen.

Luster/Gluster sind für den Einsatz im HPC gedacht, um einen schnellen Zugriff auf große Datenmengen zu ermöglichen, ohne dass ein einzelner Speicherserver einen Leistungsengpass darstellt. Ein weiterer Punkt für diese Systeme ist, dass sie POSIX-konform sind. In einer HPC-/Wissenschaftsforschungsumgebung haben Sie normalerweise keine Zeit, Ihre Anwendungen neu zu schreiben, weil Sie neue coole und schnelle FS installiert haben.

Answer 5

Map-reduce hilft nicht bei einem Schreib-/Leseverhältnis von 90/10! Die konstante Dateigröße ist eine gute Sache und die Dateien sind klein. MogileFS scheint also eine gute Alternative zu Luster/Gluster zu sein - die Cache-Situation ist nicht geeignet.