Adatok replikalsa tobb szerverre

Hálózatok általános

Udv,

Mint ahogy a cimben is irtam, az erdekelne, hogyan lehet adatokat replikalni kulonbozo szerverek kozott. Egesz pontosan arrol van szo, hogy adott egy video file, ami encodolasra kerul kulonbozo bitrate-re adaptiv streaminghez. Ezeket az encode-olt videokat kellene eljuttatni tobb kulonbozo szerverre. A helyzetet neheziti, hogy nem csak offline videokrol van szo, hanem stream-ekrol is, ahol folyamatosan keletkeznek az uj video szegmensek. Ezeket minel gyorsabban kellene replikalni kulonbozo szerverekre. A szerverek foldrajzilag kulonbozo helyeken vannak, es az is valtozo lehet idoben, hogy hany darab van beloluk. Vannak erre letezo kesz megoldasok? Milyen kifejezeskre erdemes rakeresnem Google-ben, hogy relevans talalatokat kapjak?

Remelem, jo kategoriaba soroltam. Ha megsem, szoljatok, hova illik inkabb, es atteszem.

Elore is koszonom,
kukukk

  • 877 megtekintés

( Sixday v | 2018. 03. 08., cs – 12:01 )

Szerintem valami user-space replikalo tool (pl. rsync) helyett erdemes lenne megprobalkoznod egy halozati filerendszerrel, mondjuk glusterfs-el.
Esetleg lehet olyan perverziot is csinalni hogy felhuzol valahova egy private cloudot (nextcloud vagy hasonlo)es minden gepen felveszed kliensnek ugyanarra a share-re, bar ha sok cuccrol van szo akkor az siman lehet hogy megoli a szerver savszeljet.

rsync felmerult bennem is, mint opcio. Az offline videok eseten akar meg jo is lenne, mert jo nehany perc keses belefer, viszont live stream eseten mar nem biztos, hogy jo. Mondjuk azokat lehetne kulon rscyn-elni. Tud rsync olyat, hogy egy konyvtarat folyamatosan szinkronban tartson? Mondjuk tobb szaz stream eseten mar problemas lehet ha minden storage server a forrastol probalja letolteni a file-okat, igy valoszinuleg kellene valami hierarchia a storage serverek kozott, hogy egymastol is toltsenek. Bar itt mar kell kis szamolas es teszt, hogy mi az a maximum melyseg, ami live stream eseten meg belefer, hogy idoben replikalodjanak a uj video szegmensek a kulonbozo storage szerverekre. Az a problema, hogy minden kliens direkt a forrastol probalja letolteni a file-okat a private cloud eseten is fenall, es kurvanagy output savszelet igenyelhet a forras oldalon. Valamint jo kerdes, hogy mennyire gyorsan reagalnak a valtozasokra. Nextcloud-ot hasznalok, az biztos nem lenne eleg gyors :}. De, mint lehetseges opcio, mindenkepp felkerul a listara.

Halozati filerendszerekrol nem sokat tudok. Utana nezek, hogy mit tudnak.

Sic Transit Gloria Mundi

A kettőt én lehet, hogy teljesen kölönválasztanám: on-demandre az akárhogy replikált fájl storage (pl. akár torrent, persze itt alkalmazás szinten meg kell oldanod, hogy a még nem elérhető fájlokat jó helyen keresse a kliens), élő streameknél pedig fába szervezve a szervereket akár egy ffmpeg-gel is meg tudod oldani (1 szerver fogadja a streamet előállító géptől a jelet, menti valami stream-kompatibilis formába későbbre, transcodeolja és kiküldi N másik szervernek, amikhez már a tényleges kliensek csatlakoznak, az adás végén pedig mehet a rögzített videó [akár újabb transcode után] a replikált fájl storage-ba).

https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs (Duplicate outputs rész)
https://trac.ffmpeg.org/wiki/StreamingGuide (Transcoding / repeating rész)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)