File küldése egyszerre több gépre?

Linux-haladó

Keresem azt a szoftvert, amely egy broadcast vagy multicast megoldással egy szerverről másol sok gépre egy file-t és kíméli a sávszélességet.
Lehet Linux és Windows alapokon nyugvó is.

  • 9304 megtekintés

( STP | 2014. 03. 11., k – 14:45 )

Broadcast esetén a(z adat) kiesés megengedett.
File esetén is?
Ha nem, akkor bittorrentsync lehet a barátod.

( mrceeka v | 2014. 03. 11., k – 14:50 )

Hello,

mivel az ilyen eszköz nem túl gyakori, érdekelne, mi a probléma, amit meg szeretnél oldani.
Nem teljesen kizárt, hogy a megoldást másfelé érdemes keresni (pl. lassú vonalak végén cache)

Üdv,
Marci

Mert a szerver adott idő felülről limitált sávszélességet tud kihasználni (1 Gbit/sec), így ha minden gép onnan szedi az amúgy egységes fájlt, akkor ezen korlát miatt lineárisan fog nőni az átvitel ideje, az UDP Cast vagy - gondolom mondanom sem kell - a WDS-es multicast viszont közel-konstans időt használ a kliensek számától függetlenül (az ACK-okkal és újraküldésekkel nem számolva)

Szerk.: Szal igazából nem a sávszélesség, hanem az átvitt adatmennyiség-spórolás az igazi kérdés :)

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

Tényleg. Azt szeretném megérteni, hogy 1 db 700MB-os file LAN-on való szétmásolásánál 15 helyre miért merül ez fel igényként? Mi az ok, ami miatt a szokványos megoldás nem működik?
1 perc vs 15 perc 100-as hálón. Sejtésem szerint nem túl sűrűn kell előadni ezt a mutatványt. Ráadásul alighanem valamilyen változtatáshoz kell az .iso, így a feladat tervezett tevékenység keretében lesz végrehajtva.
Ilyenkor szokott lenni idő az ilyesmire, akár BITS-el is (nincs hálózatdugítás...), akár PowerShellből: http://msdn.microsoft.com/en-us/library/ee663885(v=vs.85).aspx
Ráadásul - ha nem egyszeri a mutatvány - akkor gondoskodni kell a sikeresség ellenőrzéséről stb...
Szóval nézd el nekem, de érteni szeretném, miben különbözik ez a helyzet az általam eddig látottaktól.

Üdv,
Marci

Igen. Ha BITS-et használ, sose dugul be. Ha multicast file sendet, akkor amíg küldi, tuti bedugul. És, ha valahova nem ért oda és ismételni kell, akkor megint.
Másik oldalról a multicast a hálózati eszközökre komoly felelősséget ró. Pontosan tudni kell, hogy az adott eszközök hogyan kezelik azt - erről sem tudunk semmit.
Olcsóbb eszközök esetén simán előfordul, hogy broadcast-ként továbbítja vagy túlzott processzor-terhelést okoz a switchen.

Üdv,
Marci

Viszont ha csak sejtesz, akkor szerintem egy platform-függő és zárt megoldás (BITS) adoptálása előtt meg kéne gondolnunk annak a következményeit, hogy egy technológiának ilyen centrális szerepet adunk az életünkben. ;) (http://xkcd.com/1215/)

Amúgy komolyra fordítva a szót: szoftveresen ennek milyen feltételei vannak? IIS BITS extensionnel lehet csak a szerver oldal?

BlackY
ui.: Vajon mindenre van xkcd?
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Félreértés ne essék: a BITS említése csak arra volt való, hogy a problémát többféleképp is meg lehet közelíteni. Korántsem biztos, hogy megoldás itt, mert sajnos, továbbra sem tudunk eleget a dologról.
Hogy mindere van xkcd? Úgy tűnik, ennek be kellett következnie...! http://xkcd.com/1022/

Üdv,
Marci

( SzBlackY | 2014. 03. 11., k – 14:53 )

Helyi hálón az udpcast segíthet, Win-re és Linux-ra is van (külön még nem próbáltam, de AFAIK a Clonezilla is ezt használja szerver módban az image-k terjesztésére)

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

Kicsit elrejtik, de itt a command line doksi: https://www.udpcast.linux.lu/cmd.html

Ez alapján legalap esetben: klienseken elindítod az "udp-receiver -f fájlnév" command-ot (akár ssh-val/psexec-el), a szerveren pedig a "udp-send -f fájlnév --min-receivers "-et.

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

( vfero v | 2014. 03. 11., k – 20:22 )

Helló!

Sose próbáltam, de nem tartom kizártnak, hogy működjön, talán valaki megköpködi majd.
netcat -b
Üdv,
vfero

netcat-traditional

man netcat:
-b allow UDP broadcasts 


lsb_release -a
LSB Version:	core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID:	Debian
Description:	Debian GNU/Linux 7.4 (wheezy)
Release:	7.4
Codename:	wheezy

dpkg -l netcat-traditional
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                      Version           Architecture      Description
+++-=========================-=================-=================-========================================================
ii  netcat-traditional        1.10-40           amd64             TCP/IP swiss army knife

( gabrielakos v | 2014. 03. 11., k – 22:45 )

Másik irány: két másolás _között_ mennyit változik a forrás file tartalma?
Mert ha nem sokat akkor rsync megoldja (4k-s blokkonként van checksum).
--
Gábriel Ákos
http://i-logic.hu

( dorsy v | 2014. 03. 11., k – 23:33 )

Egyebkent nem nagyon ertem a "kimeli a savszelesseget" dolgot. Marmint hogyan is? Ha egy gepre el kell juttatni 700MB-ot, az 700MB forgalom a halozaton. Annal kevesebb aligha. (viszont sokkal tobb, mert ugye csomagok...)
Maga a "kimeli a savszelt" mire akarna vonatkozni?

Ne dugitsa el? -torrent, jol beallitott bandwith limitek. ha csillagpontos kicsit is a halozat, akkor jo eselyed van ra, hogy egy uton kevesebbszer vandorol at ugyanaz az adat (ket "kozelebbi" gep kuldi egymasnak).

Vagy odaviszed a gephez usbn. :)

Broadcastolni pl. videot/zenet okenak tunik, de file-t...es ha valamelyik gep epp "nem figyel"?

ezt most nem teljesen fogom.
létezik olyan dolog, h multicast routing
a kérdező is multicast/broadcast forgalmat mondott.
emlékeim szerint pl a norton ghost tud olyat, h hálózatra multicast-ol, így egyszerre több gépre tud klónozni.

amit még tudok esetleg (némi hack-el) ajánlani, az a Clock féle udp alapú brutalcopy.
ftp://atrey.karlin.mff.cuni.cz/pub/local/clock/bcp/

( neutrino v | 2014. 03. 12., sze – 14:25 )

Dropbox, ugyanazzal a fiókkal több gépre beléptetve...
-------------------------
neut @ présház

( willy v | 2014. 03. 13., cs – 08:38 )

Sajnos ekkora méretű file-okkal nem teszteltem, de talán: tftp multicast

( XMI | 2014. 03. 13., cs – 21:53 )

Egyetemen elég sokat próbáloztunk ilyenekkel a géptermekben a gyakorlatokra a virtuális gépek szétmásolásához. Azzal a különbséggel, hogy nem 700MB-ot, hanem tipikusan 20-30GB-ot kellett szétmásolni, ~30-40 gépre. Ezt jó lett volna ~15 percen belül csinálni, az egyes órák között, de mivel a géppark fele csak 100mbit-es volt, ezért ez esélytelen volt.

Nekem mi nem vált be:
1) Tetszőleges multicast-alapú protocol
Általában azon bukott el, hogy a hálózaton mindig akadt 1-2 olyan switch, ami ethernet flow control-lal ("PAUSE" frame-ekkel) lefojtja a multicast forgalmat. A kevésbé szemét darabok a leglassabb link sebességére lassítanak (ami könnyen lehet 10mbit/s, ha van egy-két standby állapotban levő gép a teremben). A szemetebb fajta switchek fixen 10mbit/s-re korlátoznak. Nem managelhető SOHO switcheknél, valamint olcsóbb managelhető switcheknél gyakori, hogy nem tudod kikapcsolni ezt a feature-t. Sajnos nekünk nem adatott meg, hogy minden switchünk valami minőségi típus legyen.

Másrészt a sebesség durva lefojtása ellenére is a session-ök többségében akadt egy-két notóriusan packet loss-os gép. Nem volt perzisztens oka, minden alkalommal másik gép játszotta, de 30 gépes gépteremnél már elég nagy mázli kellett hozzá, hogy ne forduljon elő. A különféle toolok ezt eltérő módon viselték, pl az adott gépen futó kliens 1-2 sikertelen block után feladta a küzdelmet, ilyenkor manuálisan kellett megkeresni a hibás fájlokat és kézzel utánamásolni. Rosszabb esetben az egész session szétesett.

2) Bittorrent
Nem szekvenciálisan másolódik a fájl, a sebesség közelében sincs a hálózat áteresztőképességének. Sajnos még bőven az SSD korszak előtt volt, és a gépekben a HDD-k értelemszerűen nem igazán szerették a random write terhelést. Ráadásul a fájl utána elég fragmentált volt, kb használhatatlan lassú volt az olvasás is belőle (mondjuk előre fix allokálással ezen lehetett volna segíteni).

Ami bevált:

Láncmásolás
Saját fejlesztésű toolt csináltam pár bash scriptből, ami SSH-val végigment a gépeken, mindegyiken indított két netcat-ot az egyik fogadta a kapcsolatot, a másik kapcsolódott a következő géphez. A pipe közepén egy tee pedig írta a diszkre a fájlt. Ha csak a gigabites hálókártyás gépek voltak a láncban, akkor ~50MB/s-et stabilan hozott, ez nagyjából a diszkek sebessége volt. Tesztben diszkre írás nélkül 80MB/s felett is ment. Fontos, hogy a gépek sorrendjét a switchek figyelembevételével kellett kialakítani, hogy az uplinkeken egynél többször ne menjen át az adat.

Aztán ez tovább lett okosítva, on the fly checksum ellenőrzéssel, ki-betömörítéssel (pl ha a szétmásolandó VM image eleve tömörítve volt a szerveren tárolva, illetve a 100mbit-es gépeknél az on the fly lzo betömörítés határozottan tudott gyorsítani), samba share kezeléssel, mindenféle hibaesetek (pl valamelyik gépen nincs elég hely) megfogásával. Teljesen stabilan működött, annak ellenére, hogy ugyanazokon a (vitatható minőségű) eszközökön futott, amin a multicast-os megoldások elvéreztek.
---
Régóta vágyok én, az androidok mezonkincsére már!

( Zahy v | 2014. 03. 13., cs – 22:54 )

Hát nekem a GhostCast eléggé bejött.