reklama

Přenos velkého množství dat po síti

Přenos velkého množství dat po síti
« kdy: 21. 01. 2020, 10:49:38 »
Ahoj, potřebuji po síti přenést velké množství dat mezi několika linuxovými servery. Někde to bude 100 GB a někde i 10 TB. Nemám s takto velkými přenosty zkušenosti. Měl bych na zkušenější kolegy pár otázek:

  • Jaký použít protokol? SCP nebo SFTP nebo nějakou formu připojení vzdáleného disku?
  • Budou se přenášet různě velké soubory. Někde to bude množství malých a někde to bude x GB dump databáze. Má to nějaké uskalí versus otázka číslo 1? Abych nezvolil protokol, který má třeba velikostní omezení na jeden soubor.
  • Jak je to s rychlostí? Je některý protokol nějak výrazně pomalejší?

Ideálně bych si představoval, že přenos bude zabezpečený, takže např. holé FTP bych nerad používal. Nějaké důležité know how co je třeba vědět?

Čas mě zatím nepálí, takže počítám s tím, že to bude trvat.

Díky

reklama


Re:Přenos velkého množství dat po síti
« Odpověď #1 kdy: 21. 01. 2020, 10:53:50 »
SCP nebo Rsync, lépe rsync.

Pokud je to v místní síti, tak rychlosti maličko pomůže nastavit v síti (na switchích a koncích) jumbo frames (MTU 9000 apod.).

Rychlost ovlivní zapnutí / vypnutí komprese. Záleží na rychlosti spojení a komprimovatelnosti dat. V některém případě komprese trvá déle, než samotný přenos. To je nutno vyzkoušet.

Zabezpečení, velikost souborů jsou bez problémů.

Re:Přenos velkého množství dat po síti
« Odpověď #2 kdy: 21. 01. 2020, 11:58:08 »
Disky na serverech mountovat s -o noatime, pokud jsou točivé a mohly by se stát úzkým hrdlem.

Pokud je to v LANce, asi má smysl také do /etc/sysctl.conf
Kód: [Vybrat]
net.ipv4.tcp_slow_start_after_idle=0alias
Kód: [Vybrat]
echo 0 > /proc/sys/net/ipv4/tcp_slow_start_after_idle(default je 1 = zapnuto = ohleduplný rozjezd TCP přenosů)

Pokud jde o nějakou WAN ve které lze očekávat cestou úzká hrdla, tak bych ji tímhle asi netrápil - tzn. nechal bych to v defaultu = 1 = ohleduplné chování TCP relací.

Re:Přenos velkého množství dat po síti
« Odpověď #3 kdy: 21. 01. 2020, 12:20:41 »
1] po jake siti to pujde. Interni, verejna, jake jsou rychlosti infrastruktury na trase.
2] jak jsou ulozena data. Lze realizovat prenos blokove nebo souborove?
3] je to jednorazove, nebo opakovatelne?
4] jaky je diskovy vykon zdroje a cile?
5] ohledne bezpecnosti, lze pripadne postavit oddelenou vlan, kde by bezpecnost nebylo nutne resit a propoji se jen konkretni servery? (souvisi s 1])

V pripade velkych objemu je vhodne i zvazit cestu zkopirovani na disk a prenest disk, misto tahani to po siti.

Re:Přenos velkého množství dat po síti
« Odpověď #4 kdy: 21. 01. 2020, 12:25:46 »
Pokud jsou ty lokace rozumně dostupné, tak bych v případě WAN doporučil výše zmíněný "kabelový přenos" (disky do kabely a převézt autem). U SSD s USB 3 to asi bude i rychlejší než síť. Dělají to tak i velké firmy jako třeba Amazon [1].

U LAN záleží na kapacitě místní sítě a lenosti admina.

[1] https://aws.amazon.com/blogs/aws/send-us-that-data/

reklama


Re:Přenos velkého množství dat po síti
« Odpověď #5 kdy: 21. 01. 2020, 14:16:43 »
Pokud nejde tolik o bezpečnost ale spíše o rychlost, tak se mi osvědčila tato metoda přes nc.
http://toast.djw.org.uk/tarpipe.html

Re:Přenos velkého množství dat po síti
« Odpověď #6 kdy: 21. 01. 2020, 22:31:11 »
(...) tarpipe (...)[/url]

Jak to tam je se spolehlivostí? Co stojí mezi mnou a jedním náhodně překlopeným bitem z 11 bilionů přenesených? U takových objemů bych si už netroufnul nepoužít nějakou kontrolu na aplikační úrovni...

Re:Přenos velkého množství dat po síti
« Odpověď #7 kdy: 21. 01. 2020, 23:15:00 »
(...) tarpipe (...)[/url]

Jak to tam je se spolehlivostí? Co stojí mezi mnou a jedním náhodně překlopeným bitem z 11 bilionů přenesených? U takových objemů bych si už netroufnul nepoužít nějakou kontrolu na aplikační úrovni...
Jelikož k přenosu je použit TCP/IP protokol který sám o sobě má checksumy tak bych se toho nebál. Samozřejmě pro 99.9999% jistotu nechat spočítat nejaky checksum na zdrojové a cílové straně po dokončení kopírování.

_Jenda

  • ***
  • 233
    • Zobrazit profil
    • https://jenda.hrach.eu/
    • E-mail
Re:Přenos velkého množství dat po síti
« Odpověď #8 kdy: 22. 01. 2020, 04:31:28 »
SCP
Mně přijde, že scp je při přenosu více souborů podivně pomalé - jako kdyby vždycky při začátku přenosu souboru čekalo na síťový roundtrip.

A pak teda protokoly co se tunelují po SSH (včetně rsyncu, pokud se používá po SSH) budou mít na rychlé síti bottleneck v šifrování. Na 1GE asi ještě ne pokud nemáš pomalý procesor (poznámka: neumí to běžet na víc jádrech, ale můžeš spustit těch přenosů víc…), ale na 10GE už asi jo.

A jinak rychlý přenos po síti kde je dlouhá latence a sem tam se něco ztratí (typicky mezikontinentální internet) prý řeší proprietární Aspera nebo https://github.com/fast-data-transfer/fdt, které řeší takové ty problémy se zahlcením a ztrátami líp než TCP, ale osobní zkušenosti s tím nemám.

Re:Přenos velkého množství dat po síti
« Odpověď #9 kdy: 22. 01. 2020, 08:37:09 »
Na lokální síti pro ruční jednorázový přenos velkého také používám tar + nc.

Re:Přenos velkého množství dat po síti
« Odpověď #10 kdy: 22. 01. 2020, 13:45:29 »
Při použití rsync se může hodit volba, aby zachoval částečně přenesená data - lze pak navázat i při výpadku připojení, což při velkých souborech ušetří čas. Jde o volby --partial případně --partial-dir=DIR Nebo, jak už tu někdo psal, ta data přenášet na úrovni souborového systému (některé souborové systémy umí synchronizovat po síti nebo po síti posílat snapshoty).

Re:Přenos velkého množství dat po síti
« Odpověď #11 kdy: 23. 01. 2020, 02:26:03 »
SCP NE a to proto, ze kdyz se prerusi prenos (pad site nebo vypadek proudu), tak musis cely proces od znova. FTP ani nahodou, SFTP je lepsi, nevim, jak se to tam s kontrolnimi soucty.

Kód: [Vybrat]
rsync -ahvc -e ssh --delete --progress --bwlimit=5000k ZDROJOVY_USER@ZDROJOVY_SERVER:Cesta_Lokalni/ CILOVY_USER@CILOVY_SERVER:Cesta_Lokalni/

 -e ssh pouzije ssh protokol. Vhodne pro prenos mezi servery, ne lokalne na jednom PC.

--progress zobrazi prubeh akce.

-ahvc tato moznost znamena, ze se pocitaji u souboru kontrolni soucty souboru, a zdali cilovou slozku aktualizovat (dany soubor), rozhoduje se podle kontrolnich souctu, ne podle casove znamky. Kdyz das jen -ahv, kontrolni soucty se predem nepocitaji, a tim padem to jde rychlejs (ale kontrolni soucty by mely byt v samotnem procesu prenosu po siti snad). Pokud jsou data dulezita na bezchybnost, dej -ahvc. Pri tomto mnozstvi dat (10 TiB) to bude kontrolni soucty pocitat cele dny, ale to je k obemu dat normalni.

--delete Smaze soubory-slozky, ktere jsou v cilovem adresari, ve zdrojovem adresari nikoliv. Hodi se to pri opakovanem pouziti rsync. NESPLET SI ZDROJ A CIL !!!!!

--bwlimit=5000k Kdyz pustim rsync bez omezeni, nekdy zahltim router a ostatnim zatvrdne net. Takze limituju prenos, aby to nevyzralo cele pasmo. Limit nastavis v kilobajtech XXXk nebo v megabajtech Xm. U gigabitove pripojky (to bude mozna tvuj pripad) je ale stejne rychlost 15-50 MB/s podle toho, jak zvlada CPU pocitat kontrolni soucty.

Re:Přenos velkého množství dat po síti
« Odpověď #12 kdy: 23. 01. 2020, 02:41:36 »
Ondrej Nemecek

Tak jak jsem ten prikaz napsal, tak jej pouzivam. Zalohuji prez to prubezne. Pokud je v cilovem miste slozka prenesena castecne, s timto prikazem se prenese, jen to co tam jeste neni (a ve zdroji a cili se overi kontrolni soucty). Takze pri vypadku pripojeni-zdroje-cile to nejde od znova cela slozka. Ale pokud je vypadek v prubehu jednoho velkeho souboru, tak ten soubor musi jet cely znova, jen konkretni soubor ale.

Ale z mych zkusenosti, prikaz tak jak jsem napsal ja, podle kontrolnich souctu - kdyz v cili a zdroji je nejaky velky soubor, co se lisi cil a zdroj jen v nekterych blocich, ktere jsou odlisne (ani nevim, jak jsou ty bloky velke). To uz je u souboru par GB velkych znat. Ale kdyz spadne sit v prubehu prenosu velkeho souboru, musi jet ten soubor cely znova, tak jak jsem ten prikaz napsal ja.

-partial-dir=DIR resp. -partial jsem nikdy nezkousel. To pomuze i na konkretni soubor v pripade vypadku site ?

Taky nevim, jestli je bezpecne aktualizovat v souboru cilovem (velkem) jen nektere bloky. rsync pustim po dokonceni prenosu znova, s -avhc mi to spocte kontrolni soucty, ktere jsou ve zdroji a cili stejne, takze po siti jdou jen ty kontrolni souctu, je li zdoj a cil stejny a vse je OK. Jake je riziko chyby pri prenosu i s -avhc na zdroji a cili, to nevim,s jakou pravdepodobnosti muze nastat bit-flip, tusim jednou za 100-1000 TB ? Neco podobneho se tu tusim resilo pred rokem nebo tak neco. Kdyz je chyba v archivu komprimovanem, muze to odrovnat cely archiv. Takze pak moznst zdroj a cil porovnat jinym programem a kontrolnim souctem.

_Jenda

  • ***
  • 233
    • Zobrazit profil
    • https://jenda.hrach.eu/
    • E-mail
Re:Přenos velkého množství dat po síti
« Odpověď #13 kdy: 23. 01. 2020, 14:57:24 »
U rsyncu se může hodit s --partial ještě --inplace. U rychlé sítě může být bottleneck kopírování do dočasného souboru u --partial.

Re:Přenos velkého množství dat po síti
« Odpověď #14 kdy: 24. 01. 2020, 01:57:40 »
Jenda

Ten bottleneck co mam zkusenost ja, se projevuje u rsync s ssh protokolem u 1 Gbit site. Samozrejme bottleneck je ten slabsi CPU z dvou stroju. U rsync tak jak jsem parametry zadal ja - Pri 2.2 GHz na I7 je rychlost okolo 35 MB/s max. Pri 10 Gbit uz je bottleneck rychlost disku, kdyz nemaji obe strany SSD. Pri externim HDD prez USB 2 take muze byt bottleneck to USB2, jen o neco vetsi nez 35 MB/s.

Pri prenosu hodne malych souboru z HDD a 1 Gbit nebo i 100 Mbit siti je bottleneck ten disk a ten radsi nepretezovat. A u procesoru Atom se kvuli pomalejsimu CPU nevyuzije ani 100 Mbit linka.

Kristan Surname, Ondrej Vanis

Preklopeni bitu nastava jedno za X-XXX TB podle ruznych veci, u samotnem prenosu po siti asi nejdrive. Na HDD jednou za 100-1000 TB tusim, nevim presne, neco podobneho se tu uz resilo na foru. U psanych programu nebo archivu muze zmena jednoho bitu nadelat paseku. Programy vysvetlovat nemusim, u archivu takova chyba mozna muze odpalit cely archiv.

Proto doporucuji aspon u dulezitych dat rsync pustit 2x po sobe, s -avhc (a to si u 10 TB tazatel pocka, vlastni zkusenost pri 2 TB), pokud se v datech vyskytuji archivy tak prez 7z zkontrolovat (umi rekurzivne) a spocitat jiny kontrolni soucet, nez pouziva rsync, jinym programem. U obycejneho prenosu, resp. tarovani predem pokud uvadis ten preklopeny bit je jednou za cca 1.5 TB. Radsi tedy naopak netarovat-nekomprimovat znova.

A jeste jednou. Pokud rsync ma parametr --delete, dobre kontroluj zdrojovou cilovou cestu a neprohod to.

 

reklama