Fórum Root.cz
Hlavní témata => Server => Téma založeno: Jarda Ucpaný 31. 07. 2017, 19:14:33
-
Zdar, potřebuju synchronizovat obraz disku virtuálu. Soubor má asi 40 GBa změn je relativně málo. Zkoušel jsem rsync, ale ten má raději sync na úrovni celých adresářů a tohle mu moc nevonělo. Bylo to strašně pomalé, pořád to počítalo nějaké heše a nefungovalo to dobře. Máte nějaký jiný tip?
-
jukni: https://github.com/poettering/casync
-
rsync je na tohle správný nástroj. Že rsync má raději změny na úrovni celých adresářů není pravda, takové změny snadno přenesete i jiným protokolem. Výhoda rsyncu se nejvíc projeví právě v případě, kdy máte ve velkém souboru jen několik změn. To, že počítal hashe, je v pořádku, tím právě zjistí, které části se změnily, a přes síť pak přenese jenom ty. Ale musíte samozřejmě k přenosu přes síť použít rsync protokol. Kdybyste si přes síť namapoval třeba NFS a teprve nad tím pustil rsync, bude to horší, než kdybyste ten soubor přes NFS rovnou zkopíroval.
Pokud se vám na použití rsync něco nezdálo, napište přesně, jak jste ho použil a co podle vás bylo špatně.
-
https://en.wikipedia.org/wiki/Syncthing
Na cilovej stroj nakopirujes to ISO/vdi z prenosnyho HDD, aby se to netahalo vsechno pres net.
Pak uz bude synchronizovat jen incrementalne.
Ja takhle synchronizuju cca 20GB ikdyz pravda je to vic mensich souboru, ale je to fuk, protoze co si pamatuju tak tenhle SW pouzivaj i FreeBSD vyvojari na preposilani si "ISO nightlies"
Eventuelne pokud chces delat ISO backup a nevadi ti CL tak zkus https://www.tarsnap.com/
Myslim ze i pres nej jako centralni uloziste by slo synchronizovat do ruznych stroju (ktery znaj heslo)- ale nezkousel sem.
-
Pokud se vám na použití rsync něco nezdálo, napište přesně, jak jste ho použil a co podle vás bylo špatně.
Napadá mě, že tazateli mohlo vadit, že se počítají hashe a že musí čekat. U 40GB souboru to asi chvíli zabere. Pokud by byl hash jednotlivých segmentů předpočítaný dopředu a uložený někde bokem třeba v souboru, bylo by to rychlejší. Nezdá se ale, že by toto rsync uměl.
-
Napadá mě, že tazateli mohlo vadit, že se počítají hashe a že musí čekat. U 40GB souboru to asi chvíli zabere. Pokud by byl hash jednotlivých segmentů předpočítaný dopředu a uložený někde bokem třeba v souboru, bylo by to rychlejší. Nezdá se ale, že by toto rsync uměl.
Pro rsync se používá plovoucí kontrolní součet, takže rsync pozná i to, když se blok dat posune třeba o jediný bajt a nepřenáší ho znovu. Pro uložení kontrolních součtů 40GB souboru by tedy bylo potřeba 160 GB (kontrolní součet je 4bajtový). Navíc ten kontrolní součet je schválně navržený tak, aby se počítal rychle a aby bylo možné rychle spočítat změnu „mám kontrolní součet bloku, posunu blok o 1 bajt doprava a chci spočítat nový kontrolní součet“.
-
Záleží taky na jakym FS ti to běží, ale tohle je hračka pro ZFS | BTRFS send-recieve
-
Napadá mě, že tazateli mohlo vadit, že se počítají hashe a že musí čekat. U 40GB souboru to asi chvíli zabere. Pokud by byl hash jednotlivých segmentů předpočítaný dopředu a uložený někde bokem třeba v souboru, bylo by to rychlejší. Nezdá se ale, že by toto rsync uměl.
Pro rsync se používá plovoucí kontrolní součet, takže rsync pozná i to, když se blok dat posune třeba o jediný bajt a nepřenáší ho znovu. Pro uložení kontrolních součtů 40GB souboru by tedy bylo potřeba 160 GB (kontrolní součet je 4bajtový). Navíc ten kontrolní součet je schválně navržený tak, aby se počítal rychle a aby bylo možné rychle spočítat změnu „mám kontrolní součet bloku, posunu blok o 1 bajt doprava a chci spočítat nový kontrolní součet“.
Aha. Tím pádem má ale tazatel pravdu v tom, že synchronizace adresáře s 40GB dat může být rychlejší než synchronizace 40GB binárního souboru. Při shodě mtime a velikosti souboru se kontrolní součet ani nepočítá a i pokud by se počítal, je rozdělením na soubory omezen prostor, ve kterém se shoda hledá. Pokud to dobře chápu, dělá to v 40GB binárním souboru podobné operace jako při deduplikaci, což bude asi dost drahá operace.
Snapshot na úrovni filesystému by si s tím poradil lépe? BTW pokud jde o obrazy VM nebylo by lepší udělat snapshoty a synchronizovat jen ty? Nebo použít live migraci nebo tak něco?
Další věc je, jak je na tom rsync s využitím více CPU jader a dále jak rychle disk naservíruje těch 40GB pro spočítání součtů (to může být limitující i pro ostatní nástroje).
-
vmware ma nastroj https://www.vmware.com/products/vsphere/data-protection.html na backupovanie diskov. nemam s nim skusenost ale tipujem ze bude rychlejsi ako rsync pretoze "rozumie" tomu co kopiruje (Changed Block Tracking)
-
Při shodě mtime a velikosti souboru se kontrolní součet ani nepočítá
Musíte ale přenést název souboru a mtime.
rozdělením na soubory omezen prostor, ve kterém se shoda hledá
Což je nevýhoda, protože to může vést k tomu, že budete zbytečně po síti přenášet data, která už na druhé straně máte – akorát v jiném souboru. Myslím, že se naopak uvažovalo o variantách rsyncu, které by uměly pracovat s více soubory.
Pokud to dobře chápu, dělá to v 40GB binárním souboru podobné operace jako při deduplikaci, což bude asi dost drahá operace.
Naopak je to navržené tak, aby to byla levná operace – kontrolní součty se nepočítají pro každý blok od začátku, ale když se blok posune o jeden bajt, použije se kontrolní součet předchozího bloku a jenom se aktualizuje o ten jeden smazaný a jeden přidaný bajt. Navíc se velikost bloku odvozuje od velikosti souboru, takže ani u velkých souborů není nutné držet v paměti velké množství kontrolních součtů. Naopak, pokud má cílový server dost paměti, možná by se vyplatilo naopak velikost bloku zmenšit, aby se zbytečně nepřenášely velké bloky dat, když dojde jen k malé změně.
Snapshot na úrovni filesystému by si s tím poradil lépe?
Obecně hůře, protože neumí zachytit posuny dat. Když budete mít nějaký soubor a na začátku přidáte nebo smažete jediný bajt, na běžném souborovém systému musíte zapsat celý nový soubor. rsync bude potřebovat přenést jenom ty kontrolní součty a v případě přidání bajtu pak jeden blok s tím přidaným bajtem, v případě jeho odebrání nebude potřeba přenášet už nic jiného. Samozřejmě je otázka, jak často k takovým operacím dochází – já tipuju, že obrazy disků virtuálních počítačů budou jedny z mála souborů, kde skutečně dochází k přesouvání dat z místa na místo.
Další věc je, jak je na tom rsync s využitím více CPU jader a dále jak rychle disk naservíruje těch 40GB pro spočítání součtů (to může být limitující i pro ostatní nástroje).
Když nemáte zaznamenané, k jakým změnám došlo, musíte ten soubor vždy přečíst celý. rsync optimalizuje to, aby nebylo nutné přenášet velký objem dat po síti. Využití více jader CPU asi nebude na pořadu dne, nejvíce omezujícím faktorem je rychlost sítě a pak rychlost čtení a zápisu na disk.
-
Onehdy jsem řešil asi patrně totéž, ale nakonec jsem se na to vykvák. Na obou stranách byla jakž takž linka, takže 25GB jsem přenesl za hodinku a pár minut. Do budoucna by se mi to ale určitě zase hodilo.
Zkoušel jsem rsync, konkrétně jsem se inspiroval následujícím:
https://blog.christophersmart.com/2014/01/15/force-rsync-to-use-delta-transfer-to-fix-corrupt-remote-file/
Nechal jsem to běžel asi 15 minut, ale pak jsem to vzdal a raději to prostě zkopíroval scp, protože jsem nevěděl, co to vlastně dělá a jak dlouho ještě bude.
Zdrojový počítač mi teď zkusmo md5 2,3GB ISO spočítal za 22s a cílový 600MB md5 zchroustal pod 5s. V oborou případech to tedy jeden přes 100MB/s u 25GB souboru by už měl zhruba za 4 a půl minuty vědět, na čem je, což se ale nestalo.
Dřív jsem zkoušel zsync, ale tady bych raději něco, co si vystačí s SSH bez nějaké instalace webserveru a podobně. BitTorrent je na opravy takových věci taky docela v pohodě, ale zase jeho použití zde mi zrovna 2x nevoní.
-
Onehdy jsem řešil asi patrně totéž, ale nakonec jsem se na to vykvák. Na obou stranách byla jakž takž linka, takže 25GB jsem přenesl za hodinku a pár minut. Do budoucna by se mi to ale určitě zase hodilo.
Zkoušel jsem rsync, konkrétně jsem se inspiroval následujícím:
https://blog.christophersmart.com/2014/01/15/force-rsync-to-use-delta-transfer-to-fix-corrupt-remote-file/
Nechal jsem to běžel asi 15 minut, ale pak jsem to vzdal a raději to prostě zkopíroval scp, protože jsem nevěděl, co to vlastně dělá a jak dlouho ještě bude.
Rsync má parametry --verbose a --progress
-
Další věc je, jak je na tom rsync s využitím více CPU jader a dále jak rychle disk naservíruje těch 40GB pro spočítání součtů (to může být limitující i pro ostatní nástroje).
Když nemáte zaznamenané, k jakým změnám došlo, musíte ten soubor vždy přečíst celý. rsync optimalizuje to, aby nebylo nutné přenášet velký objem dat po síti. Využití více jader CPU asi nebude na pořadu dne, nejvíce omezujícím faktorem je rychlost sítě a pak rychlost čtení a zápisu na disk.
Rsync optimalizuje na přenesená data, ale je otázka jak dlouho mu trvá, než zjistí, která data je třeba přenést. To by musel zjistit tazatel, na co vlastně čeká a co mu na rsync vlastně vadí. K ostatnmímu se nemohu vyjadřovat, možná se najde někdo povolanější.
-
Rsync optimalizuje na přenesená data, ale je otázka jak dlouho mu trvá, než zjistí, která data je třeba přenést.
Pokud to není nějaký ARM s rychlým NVMe diskem, je brzdou rozhodně disk. Pokud nemá předem zjištěné, které části se změnily (protože by tyhle informace ukládal virtuální stroj nebo souborový systém), bude muset vždy přečíst celý soubor, bez ohledu na způsob přenosu a zjišťování rozdílů.
To by musel zjistit tazatel, na co vlastně čeká a co mu na rsync vlastně vadí.
To jsem psal hned na začátku, že musí nejprve tazatel napsat, co a proč se mu nezdá.
-
Rsync má parametry --verbose a --progress
Má, ale v téhle fázi nefungují. Vypíše si to to své "receiving incremental file list" a já netuším, co to dělá a jak dlouho ještě bude.
-
"potřebuju synchronizovat obraz disku virtuálu. Soubor má asi 40 GBa změn je relativně málo. Zkoušel jsem rsync, ale ten má raději sync na úrovni celých adresářů a tohle mu moc nevonělo"
Jeste sem si vzpomel ze onehda se vyvojari FreeBSD bavili jak replikovat velky soubory pres internet, z USA do EU kde maj dalsi datacentrum = delaj to pres ZFS send s parametrem "rozdil v timestamps" kdy system porovnava bitove rozdily mezi 2ma snapshotama s rozdilnyma timestamps a tyto =pouze tyto rozdily pak posila pres net na cilovej stroj.
Presne si vzpominam ze Allan Jude tam mluvil o tom jak je pro tenhle ukol Rsync nepouzitelnej, protoze toho hashuje zbytecny quanta, bohuzel si nevzpomenu ve kterym konkretnim dile to bylo...... Kazdopadne v poslednich 5ti maximalne poslednich 10ti to bejt musi:
http://www.jupiterbroadcasting.com/show/bsdnow/
-
Rsync má parametry --verbose a --progress
Má, ale v téhle fázi nefungují. Vypíše si to to své "receiving incremental file list" a já netuším, co to dělá a jak dlouho ještě bude.
FYI progress jakéhokoli programu, který čte soubor, se dá zjistit tak, že si z /proc/pid/fd/ zjistíš deskriptor a pak se koukneš do /proc/pid/fdinfo/deskriptor. Dokonce existuje program "progress", který se to snaží nějak automatizovat a vykresluje progressbar.