rsyncrypto: šifrovaný rsync (diskuse)

[Jan Kundrát (jkt)]

Nevyhody SSH? Pokud distribuuji data urcena verejnosti, nebudu je kryptovat, pokud jsou data urcena jenom nekomu, smele mu zridim ucet omezeny na spusteni binarky rsyncu vedouci do vhodne oblasti..

[Creckx]

A nevyhody SSH stále zůstávají:) Tady jde o jinou věc.. zkoušel někdy přenášet něco přes rsync+ssh? Třeba nějakou zálohu? Já to dělám běžně, těch záloh tolik nemám, ale i tam je vidět, že ssh zbytečně zatěžuje procesor a dosahuje mnohem menších rychlostí, než přes například "čisté" ftp. Tam patří rsyncrypto a ne na určování kdo kam má přístup.

[Jan Kundrát (jkt)]

No nevim, prave jsem si overil, ze 30MB/s s tim mezi nejakymi dvema xeony po gigabitu protlacim se zatizenim CPU na 20%. Parametry linky neznam, takze nevim, jak moc je to SSHckem a jak moc ovladaci sitovky, ale pokud potrebuju zalohovat tolik dat, ze je pro me 30MB/s bottleneck, asi na to uz taky nepouzivam rsync, ze...

[Creckx]

Každej nemá 2xXeon na zálohovaných strojích. Na mém sempronu bylo zálohování po 100mbps síti cítit a jelo to tak 2-3MB/sec.

[Michal Kubeček]

Pak byl nejspíš problém někde jinde. Mně u SCP na nasycení 100Mb/s ethernetu stačil Athlon 1800XP+, rychlost byla oproti "čistým" protokolům (11.2 MB/s) nižší jen o mírnou režii (asi 10.5 Mb/s). Na 30 MB/s nepotřebujete dva Xeony, stačí v podstatě jakýkoli 64-bitový Athlon (vyzkoušeno na obyčejném AMD64 3000+).

[Jan Kundrát (jkt)]

Ve strojich-orezavatkach, ktere nemaji Xeon, ale jsou to nejake postarsi 2Ghz Pentia 4, mam pouze 100Mbps ethernet. Samozrejme ho sshd velice pohodlne saturuje s obdobnym ci mensim vytizenim CPU.

Pokud ti to na Sempronu nedela vic jak dejme tomu 80% realne propustnosti site, kterou mas odkzousenou nejakym "mene narocnym typem prenosu", treba NFS, Sambou, FTP,..., tak mas problem nekde v konfiguraci SSH.

[beko]

No zjavne to nevyhoda je, tvoja zostava by zvladla takychto prenosov 5 a procesor by isiel na maximum. Zober si, ze je mnoho masin kde tych prenosov potrebujes subezne este omnoho viac.. Nehovoriac o tom, ze su aj ine sluzby, ktore chcu vyuzivat procesor.

[hele]

a mate tam magickou sekvenci RSYNC_RSH="ssh -c arcfour,blowfish-cbc -oCompression=no"

ktera rapidne snizuje zatez cpu, a mam s tim dobre zkusenosti. Neni to sice jako rsync nesifrovany, ale je to lepsi. a slabsi sifrovani mi nevadi.

[Jan Kundrát (jkt)]

Ale ono na rsync-over-ssh snad nikdo nechce stavet produkcni sluzbu, ktera bezi paralelne v desitkach instanci a kazdemu klientovi tlaci desitky megabajtu za vterinu. Pokud jde o nejake pidizalohovani, synchronizaci konfigurace a nebo jednorazove prenosy dat (i kdyz treba opakovane jednou, dvakrat za den), zpravidla nezalohuji stroj peti thready najednou, a tak me "overhead ssh" ve forme "zbytecneho nastavovani uzivatelu a klicu" a vykonu CPU vzrostlech o 3% nezabije...

[Michal Ludvig]

tam je vidět, že ssh zbytečně zatěžuje procesor a dosahuje mnohem menších rychlostí

Jestli ono to nebude tím šífrováním, které je poměrně náročné na výkon CPU. Jestli bude šifrovat SSH nebo jestli to udělá přímo rsync není ve výsledku zas tak důležité, ten procesorový čas si to vezme tak jako tak.

[Pavel Obr]

Osobně si myslím, že jde o to, že data jsou zašifrována ještě před odesláním na cílový stroj. Z toho plyne, pokud chce někdo zálohovat na vzdálený stroj, tak má jistotu, že mu je nikdo nedokáže na něm přečíst.

[YYY]

Osobne si myslim, ze rsync+ssh moc nevyhod neprinasi. Na nasem serveru(nijak oslnivi vykonem) bez problemu bezi 10-11MB/s. Zajimal by mne maximalni strop naseho serveru pri pouziti gigabitoveho ethernetu. Jinak kdo potrebuje vetsi vykon, at zalohuje jinak nez pres rsync :)

[man]

a že jsem tak smělý, mohl bych vědět které další možnosti jsou?

[undz]

Třeba přes SMB diffovat :)

[superman]

bacula?

[YYY]

prenos po nfs? magneticke pasky?