Luster, Gluster o MogileFS ?? per archiviazione video, codifica e streaming

Question

Tante opzioni e così poco tempo per testarle tutte ... Mi chiedo se qualcuno abbia esperienze con i file system distribuiti per lo streaming video e la memorizzazione/codifica.

Ho un sacco di enormi file video (da 50 GB a 250 GB) che ho bisogno di memorizzare da qualche parte, essere in grado di codificarli in MP4 e trasmetterli in streaming da diversi server Adobe FMS. L'unico modo per gestire tutto questo è con un file system distribuito, ma ora la domanda è quale?

La mia ricerca finora mi dice:

• Luster: maturo soluzione collaudata, utilizzata da un sacco di grandi aziende, meglio con i file> 10G è un driver del kernel.
• Gluster: nuovo, meno maturo, basato su FUSE che significa facile da installare ma forse più lento a causa del sovraccarico di FUSE. Meglio gestire un numero elevato di file più piccoli ~ 1 GB
• MogileFS: sembra essere solo per file di piccole dimensioni ~ MB, utilizza HTTP per l'accesso ?? possibile associazione FUSE in futuro.

Finora Lustre sembra il vincitore ma mi piacerebbe sentire le esperienze reali per la particolare applicazione che ho.

Anche Hadoop, Redhat GFS, Coda e Windows DFS suonano come opzioni in modo che qualsiasi esperienza sia benvenuta. Se qualcuno ha dei parametri di riferimento, per favore condividi.

Dopo qualche esperienza reale questo è quello che ho imparato:

• Luster:
  • Performance: incredibilmente veloce! Posso affermare che Lustre può servire molti stream e che la velocità di codifica non è influenzata dall'accesso ai file via Lustre.
  • Compatibilità con POXIS: Molto buono !. Non c'è bisogno di modificare le applicazioni per usare lustro.
  • Replica, bilanciamento del carico e failover: molto male !. Per il carico di replica bilanciamento noi e failover abbiamo bisogno di fare affidamento su altri software come IP virtuali e DRDB.
  • Installazione: Il peggio !. Impossibile installare da semplici mortali. Richiede una combinazione molto specifica di kernel, patch di lustro e modifiche per ottenere il risultato corretto con lo . E le patch di lustro correnti di solito funzionano con vecchi kernel che sono incompatibili con il nuovo hardware/software .
• MogileFS:
  • Performance: Per file di piccole dimensioni, ma non utilizzabile per le medie e grandi file. Questo è principalmente a causa dell'overhead HTTP poiché tutti i file sono inviati/ricevuti tramite richieste HTTP che codificano tutti i dati in base64 aggiungendo un overhead del 33% a ciascun file.
  • La compatibilità con POXIX è inesistente. Tutte le applicazioni richiedono di essere modificate per utilizzare mogilefs che lo rende inutile per lo streaming/codifica poiché la maggior parte dei server di streaming e gli strumenti di codifica non comprendono il protocollo MogileFS.
  • La replica e il failover out of the box e il bilanciamento del carico possono essere implementati nell'applicazione accedendo a più di un tracker alla volta.
  • L'installazione è relativamente facile e i pacchetti pronti all'uso esistono nella maggior parte delle distribuzioni. L'unica difficoltà che ho riscontrato è stata l'impostazione del database master-slave per eliminare il singolo punto di errore .
    • Gluster:
  • Prestazioni: Molto male per lo streaming. Non riesco a raggiungere più di qualche Mbps su una rete a 10 Gbps. Client e Server CPU salgono alle scritture pesanti. Per la codifica funziona perché la CPU è satura prima della rete e I/O.
  • POXIS: quasi compatibile. Gli strumenti che uso possono accedere a gluster mount come normali cartelle nel disco ma in alcuni casi periferici le cose iniziano a causare problemi. Controlla le mailing list del gluster e vedrai che ci sono molti problemi.
  • Replica, failover e bilanciamento del carico: il migliore! se hanno effettivamente funzionato Gluster è molto nuovo e ha un sacco di bug e problemi di prestazioni.
  • L'installazione è troppo facile. La linea di comando di gestione è sorprendente e l'impostazione replicata, a strisce e volumi distribuiti tra diversi server non può essere più semplice.

Conclusione finale:

Purtroppo la conclusione è "Nessuna singola pallottola d'argento".

Attualmente abbiamo i file multimediali in Gluster3.2 in un volume replicato per l'archiviazione e la transcodifica. Finché non si hanno molti server, evitare la geo-replica e i volumi di stripe funzionano correttamente.

Quando si esegue lo streaming dei file multimediali, li copia in un volume di lustro che viene replicato in un secondo volume di lucentezza tramite DR: DB. Il server di wowza quindi legge i file multimediali dai volumi di lustro.

Infine, utilizziamo MogileFS per servire le anteprime nei nostri server di applicazioni Web.

Answer 1

Dai sistemi nominati il ​​più adatto è MoglieFS.

Ma forse è possibile ottenere senza alcun sistema speciale. Diciamo che avete 4 AdobeFMS server:

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

È possibile distribuire tutti i tuoi video tra quei 4 server tramite semplice schema, come

/* 
    * pseudo code 
    */ 

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

dopo aver codificare i video, la vostra applicazione sarebbe

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

I client

accedono ai video utilizzando qualcosa come http://videoN.example.com/filename.mp4, dove N viene calcolato dal nome file utilizzando get_server_id().

Luster/Gluster non è proprio quello che dovresti cercare.Luster FS è più maturo, ma gli sviluppatori ti chiedono di trattare i file su tali FS come "cache", cioè possono essere persi in qualsiasi momento.

Luster/Gluster sono destinati all'uso in HPC per consentire un accesso rapido a enormi quantità di dati senza il singolo server di archiviazione. Un altro punto per questi sistemi è che si tratta di un reclamo POSIX. Nell'ambiente di ricerca HPC/Scientifico di solito non hai tempo da perdere per riscrivere le tue app perché hai installato nuove versioni di file multimediali interessanti e veloci.

Answer 2

Controllare Hadoop Filesystem (HDFS). Il suo focus è su file molto grandi e task computing parallelo (con map/reduce), ha una latenza elevata ma un throughput molto alto. Attualmente è utilizzato su installazioni di grandi dimensioni come Facebook e amazon.com

Answer 3

MogileFS è ottimo per questo genere di cose. Le librerie client variano un po 'in termini di qualità, ma sarei sorpreso se non esistessero siti di produzione di grandi dimensioni che utilizzano praticamente qualsiasi linguaggio per accedervi.

HTTP è un buon protocollo per questa roba in realtà. Chi non ha un client HTTP ricco di funzionalità ed efficiente?

Answer 4

Riduzione mappa non aiuta nel rapporto scrittura/lettura di 90/10! La dimensione del file costante è una buona cosa e i file sono piccoli. Quindi, MogileFS sembra essere un'alternativa valida come Luster/Gluster - la situazione della cache non è appropriata.

Answer 5

GlusterFS si è migliorato molto fino a questa data. Ora stanno fornendo un "granular locking" per i file di grandi dimensioni. Vedi qui: http://www.gluster.org/community/documentation/index.php/WhatsNew3.3 Anche i frame rate del video sono molto dipendenti per cui dovresti lavorare anche tu. Se non si passa alle velocità 4K, Gluster può risolvere i problemi di archiviazione. Se c'è una grande richiesta di velocità, quindi Infiniband può entrare in gioco.