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

 ( wyx | 2014. március 11., kedd - 14:34 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

bittorrent +1
Mi is hasonló módon szórtunk szét több iso-t.

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

szervergépen van egy 700 Mb-os ISO, ezt kell szétszórni 15db gépre úgy, hogy ne képződjön 15x-ös sávszélességigény...

A 15 gép egy LANon van és a forrás WANon?

igen, de a forrás lehet ugyanazon a LAN-on is, ha így jobb a helyzet

LANon miért érdekes a sávszélesség-spórolás?

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)

+1

Vagyis, ha jól értem, időt akarsz spórolni, hogy a másolás gyorsabban végezzen: 1 másolásnyi idő alatt 15 másolásnyi helyett.
Miért kell itt az idővel spórolni? Milyen gyakran kell ezt a másolást elvégezni?

Üdv,
Marci

Most tenyleg azon ertetlenkedsz, hogy miert nem akarja szerencsetlen eldugitani a halozatat?

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

Hat mondjuk ha a halozatot 24/7 hasznaljak, akkor szerintem kurvara nem mellekes, hogy mennyi ideig lesz hasznalhatatlanul lassu masok szamara.

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

Idézet:
Sejtésem szerint nem túl sűrűn kell előadni ezt a mutatványt.

http://xkcd.com/1339/

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

Igen, azért kérdezek, mert egyelőre csak sejtek.
És persze e miatt: http://xkcd.com/1205/

Ü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

...amúgy a BITS-et lehet BITS Compact Serverrel is kiszolgálni: http://msdn.microsoft.com/en-us/library/dd904465(v=vs.85).aspx

Üdv,
Marci

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)

Ez tud file-t is küldeni egyik gépről a másikra? Van egy sender meg egy receiver - ha jól látom....

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)

közben én is kipróbáltam a windows-os verzión, sajna nem mindig találja meg a kapcsolatot mindegyik receiverrel..nem is beszélve arról, hogy egyszer elindult a másolás két gépre és 2 Mb után elhalálozott

Én linux alatt használom, a gépteremben (~20 gép) így szoktam teríteni pl. a telepített windows partíciót (sok gigás állományok). HW hibán kívül még nem találkoztam spontán kihalással.

Igen, egy fájlt is tud küldeni meg streamet is.

torrent :)
--
PtY - www.onlinedemo.hu

+1

igy van. tobb filehosting ceg hasznalja. pl. transmission-daemonrol olvastam, hogy az egyik ilyen host vallalat azzal szorja szet a feltoltott cuccot a szerverek kozt.

szerk: meg is van: https://forum.transmissionbt.com/viewtopic.php?t=4993

A baj az, hogy a 100Mbit az 100Mbit a LAN-on, nem a szerver a szűk keresztmetszet...
egymásról meg ugye nem nagyon töltik...

Tessék?
Mi az, hogy szerver? A szerver a tracker. azon nincs adat. Mindenki más kliens. Seeder és leecher. Ha már van 1 teljes blokkja a leechernek, azonnal tudja seedelni is. Innentől kezdve nem értem, mire célzol ...
--
PtY - www.onlinedemo.hu

A szerver szót nem a torrenthez használtam...hanem a jelenlegi rendszerhez....
de úgy látom félreérthető volt

Ja, ok. De egymástól is töltik ;)
--
PtY - www.onlinedemo.hu

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

Adsz valamilyen támpontot arra, hogy ez épp melyik netcat implementáció? (A *Hobbit*-féle originál, az OpenBSD-s, a .... ) Szóval lécci valami --version vagy hasonló kimenetet is rakj mellé, kérlek!

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

OK, az 1.10-es verziószám (és a -traditional) alapján ez az originál, Hobbit-féle. (Direkt telepítettem, abban nekem is van -b opció ezzel a funkcióval.) Kösz.

Számolj be kérlek majd, ha foglalkozol vele, hogy mit sikerült elérni vele!
Kösz,
vfero

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

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"?

ha 1 adatot küldesz több gépre, multicast módon, az 700MB forgalom.
Ha 1 adatot küldesz "A" és "B" gépre egyszerre, unicast módon, az 2x700MB forgalom.
így értem? :-)

Az attol fugg. Ha a gepek egy routerbe mennek be, akkor az biza' 700MB*gep adatforgalom, mert nem 1 kabelen ulnek sokan. (en pl itt a routerbe/melle tennem a szetkuldendo adatot) Kerdes a halozat topologiaja. Egy alhalon meg mukodhet is.

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/

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

Ez eddig a thread leghülyébb ötlete gz.

Bittorrent sync?

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

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!

Komoly ötlet!
A szkript elérhető itt, vagy privátban? Mi is alkalmaznánk....

Igazság az, hogy már rég nem ott dolgozom, és nem rémlik, hogy lemásoltam volna magamnak. De szerintem alapszinten nem egy nagy meló újraírni, inkább a robusztussá tétele nehéz.
---
Régóta vágyok én, az androidok mezonkincsére már!

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