File szinkronizálás több szerver között

Üdv,

Feladatom része, hogy több szerveren lévő fileokat kell szinkronizálni 1 master gépről. Több megoldás is eszembe jutott és véleményt kérnék rá, esetleg ötletet, hogy ki mit javasol, illetve milyen más, általam nem ismert megoldások léteznek még/a leírtak közül mi az ami megvalósíthatatlan és miért.

1. adatbázisba az állományok
Egy master mysql adattáblába írom a binárisokat ezt replikálom a többi gépre, majd szinkron végén egy shell/sql script futtatással lekövetem a jelenlegi struktúrát, és a gépre visszaírom a fileokat.

Kérdés: Mit kezd a mysql pl egy 1 Gb-os állománnyal, le tudja kezelni? A duplikálás ugye 2x annyi helyet foglal. Járható ez az út?

2. rsync
Rsync-el történik a frissítés crontabból vezérelve.
Érdemes erre elindulni? a master gép filerendszeréhez képest jóval később jelenik meg az adat, illetve az rsync mennyire "pontos", visszaellenőrizhető. Mi történik ha az egyik gép kiesik, hogyan szinkronizálódik tovább?

3. sshfs + raid 1 (megvalósítható?)
felmountolni majd raid 1-be kötni és a frissítés a háttérben történik, titkosított csatornán. egyes gépek nem szerverteremben, localban vannak, így internet használata is kell.)

4. nfs + raid 1 (megvalósítható?)
ez előzőhöz hasonló módon.

5. SOAP protokollon keresztül történik az update, és a leellenőrzött majd visszaküldött struktúra alapján sql-be letárolom a változások listáját és crontabból 1 percenként frissítem.

Nos szerintetek melyik az amelyik legjobban megállja a helyét egy átlag 100-150 Gb-os tárhelyszükségletű napi átlag 1000 állományszintű updatehez (file: törlés/csere/rögzítés)

Előre is köszönöm építő jellegű hozzászólásaitokat.

Mizu

2283 megtekintés

A 2. ponthoz en ezt tudom hozzaszolni...

Ha nagyon nagy a kerdeses fajlrendszer struktura akkor az rsync nagyon lassu lehet vagy akar meg is allhat.

En azt tapasztaltam (64bites linuxon), hogy egy 6 millio kepet tartalmazo, 5 konyvtar melysegbe agyazott (minden konyvtarban 0-9 konyvtar), ~400GByte osszmeretu struktura eseten a legfelso konyvtarbol indulva az rsync nem tudott vele mit kezdeni. Timeout lett a vege meg mielott egy fajlt is atmasolt volna, kozben pedig megette a memoriat.

Ezt a nagy adatmennyiseget ugy lehet kezelni az rsync-el, hogy 2 szinttel lejebb levo alkonyvtarakbol kell inditani az rsync-et.

--
maszili

0 szavazat

A hozzászóláshoz be kell jelentkezni

Rendben, köszönöm, máris előrébb vagyok!

Mizu

0 szavazat

A hozzászóláshoz be kell jelentkezni

az én tapasztalatom 300GB-nyi cd/dvd boritó kép, szintén 0-9-ig mappákban, rsync vitte, dolgozott vele, de elvitte:)
1x usb-s vinyóról, 2x. pedig lokálból backupnak (azóta is vettem a backupból, kell a fenének 2x ennyi:))

0 szavazat

A hozzászóláshoz be kell jelentkezni

drdb vagy endb esetleg?
Nem tudom pontosan mit akarsz, de lehet hogy ez kell.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Igen ilyesmire gondoltam!

Köszönöm a javaslatot!

Mizu

0 szavazat

A hozzászóláshoz be kell jelentkezni

torrent

0 szavazat

A hozzászóláshoz be kell jelentkezni

kicsit bant, hogy senki sem javasolta a glusterfs-t.
igaz, user space, de legalabb nem lesz kernel panic:)
jah, es a patcheket is tedd fel!
en most most kepserveren hasznalom, tobb hete jol.

0 szavazat

A hozzászóláshoz be kell jelentkezni

En probaltam de piszok lassu...

Iras


dd if=/dev/zero of=/mnt/cluster/speedtest
BS     COUNT
1048576  8   8388608 bytes (8.4 MB) copied, 0.784547 s, 10.7 MB/s
524288  16   8388608 bytes (8.4 MB) copied, 0.782491 s, 10.7 MB/s
262144  32   8388608 bytes (8.4 MB) copied, 0.78087 s, 10.7 MB/s
131972  64   8446208 bytes (8.4 MB) copied, 0.816215 s, 10.3 MB/s
65536  128   8388608 bytes (8.4 MB) copied, 0.810806 s, 10.3 MB/s
32768  256   8388608 bytes (8.4 MB) copied, 0.874132 s, 9.6 MB/s
16384  512   8388608 bytes (8.4 MB) copied, 1.01051 s, 8.3 MB/s
8192  1024   8388608 bytes (8.4 MB) copied, 1.26686 s, 6.6 MB/s
4096  2048   8388608 bytes (8.4 MB) copied, 1.77408 s, 4.7 MB/s
2048  4096   8388608 bytes (8.4 MB) copied, 2.61803 s, 3.2 MB/s
1024  8192   8388608 bytes (8.4 MB) copied, 4.78317 s, 1.8 MB/s
512  16384   8388608 bytes (8.4 MB) copied, 7.84145 s, 1.1 MB/s
256  32768   8388608 bytes (8.4 MB) copied, 14.095 s, 595 kB/s
128  65536   8388608 bytes (8.4 MB) copied, 26.1655 s, 321 kB/s
64  131072   8388608 bytes (8.4 MB) copied, 50.3791 s, 167 kB/s
32  262144   8388608 bytes (8.4 MB) copied, 99.5162 s, 84.3 kB/s

Olvasas


dd if=/mnt/cluster/speedtest of=/dev/null
BS     COUNT
1048576  8   8388608 bytes (8.4 MB) copied, 0.71582 s, 11.7 MB/s
524288  16   8388608 bytes (8.4 MB) copied, 0.715714 s, 11.7 MB/s
262144  32   8388608 bytes (8.4 MB) copied, 0.715681 s, 11.7 MB/s
131972  64   8388608 bytes (8.4 MB) copied, 0.716234 s, 11.7 MB/s
65536  128   8388608 bytes (8.4 MB) copied, 0.7165 s, 11.7 MB/s
32768  256   8388608 bytes (8.4 MB) copied, 0.716207 s, 11.7 MB/s
16384  512   8388608 bytes (8.4 MB) copied, 0.716023 s, 11.7 MB/s
8192  1024   8388608 bytes (8.4 MB) copied, 0.716286 s, 11.7 MB/s
4096  2048   8388608 bytes (8.4 MB) copied, 0.716151 s, 11.7 MB/s
2048  4096   8388608 bytes (8.4 MB) copied, 0.716138 s, 11.7 MB/s
1024  8192   8388608 bytes (8.4 MB) copied, 0.716038 s, 11.7 MB/s
512  16384   8388608 bytes (8.4 MB) copied, 0.716193 s, 11.7 MB/s
256  32768   8388608 bytes (8.4 MB) copied, 0.716171 s, 11.7 MB/s
128  65536   8388608 bytes (8.4 MB) copied, 0.716108 s, 11.7 MB/s
64  131072   8388608 bytes (8.4 MB) copied, 0.716244 s, 11.7 MB/s
32  262144   8388608 bytes (8.4 MB) copied, 0.717781 s, 11.7 MB/s

Te milyen konfiguracioban/beallitasokkal hasznalod?

--
maszili

0 szavazat

A hozzászóláshoz be kell jelentkezni

100Mbiten pont ekkora lesz a max sebessége;)

En a szerver oldali replikalast hasznalom jelenleg. dual quad, 8 gb ram, raid 10, sles 10 sp1.
Debian alatt is ugyanebben a konfigban megfelelo volt a sebesege. Gigas cross link kabellel teszteltem, az olyan 28-30 MByte/sec volt. De az kliens oldali replikalas volt.

Gigabiten probaltad?

zolo

0 szavazat

A hozzászóláshoz be kell jelentkezni

Sajnos ezeket az ertekeket gigabites halozati kapcsolatot hasznalva kaptam es sehogyan nem sikerult nagyobb sebesseget kicsikarni belole.

Ha nem nagy keres (es publikus a dolog) akkor megtenned, hogy idekopizod az altalad hasznalt konfigot?

Koszi.

--
maszili

0 szavazat

A hozzászóláshoz be kell jelentkezni

srv:


   volume mailspool-ds
           type storage/posix
           option directory /srv/www/htdocs
   end-volume

   volume mailspool-ns
           type storage/posix
           option directory /srv/www/htdocs-ns
   end-volume

   volume mailspool-santa2-ds
           type protocol/client
           option transport-type tcp/client
           option remote-host masiksrvIP
           option remote-subvolume mailspool-ds
   end-volume

   volume mailspool-santa2-ns
           type protocol/client
           option transport-type tcp/client
           option remote-host masiksrvIP
           option remote-subvolume mailspool-ns
   end-volume

   volume mailspool-ns-afr
           type cluster/afr
           subvolumes mailspool-ns mailspool-santa2-ns
#           option replicate *:2
   end-volume

   volume mailspool-ds-afr
           type cluster/afr
           subvolumes mailspool-ds mailspool-santa2-ds
#           option replicate *:2
   end-volume

   volume mailspool-unify
           type cluster/unify
           subvolumes mailspool-ds-afr
           option namespace mailspool-ns-afr
           option scheduler rr
   end-volume

   volume mailspool
           type performance/io-threads
           option thread-count 8
           option cache-size 64MB
           subvolumes mailspool-unify
   end-volume

   volume server
     type protocol/server
     option transport-type tcp/server
     subvolumes mailspool
     option auth.ip.mailspool-ds.allow srvIP,127.0.0.1
     option auth.ip.mailspool-ns.allow srvIP,127.0.0.1
     option auth.ip.mailspool.allow *
   end-volume

client:


   volume santa
     type protocol/client
     option transport-type tcp/client     # for TCP/IP transport
     option remote-host 127.0.0.1       # DNS Round Robin pointing towards all 3 GlusterFS servers
     option remote-subvolume mailspool        # name of the remote volume
   end-volume

   volume writeback
     type performance/write-behind
     option aggregate-size 131072 # unit in bytes
     subvolumes santa
   end-volume

   volume readahead
     type performance/read-ahead
     option page-size 65536     # unit in bytes
     option page-count 16       # cache per file  = (page-count x page-size)
     subvolumes writeback
   end-volume

Ez most sima file replikalasra van, sqlite ala nem jo, ott mashogy kell megoldani lockolas miatt.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Koszi a segiteseget.

Nekem is csak file replikalasra kell... adatbazist az adatbazis sajat eszkozeivel replikalok.

--
maszili

0 szavazat

A hozzászóláshoz be kell jelentkezni

innen szedted le?


$ tla register-archive http://arch.sv.gnu.org/archives/gluster/
$ tla get -A gluster@sv.gnu.org glusterfs--mainline--BRANCH glusterfs

ez leszedi a patcheket is, ami eleg fontos!

Udv, Lanyi Zoltan

0 szavazat

A hozzászóláshoz be kell jelentkezni

ez csak redhaton megy, ugye? Különböző cluserFS megoldásokat pár hónapja én is kerestem, de 1 kész megoldást, leirást nem találtam, csak általános szövegek, hogy miért jó...de ez kevés:(

0 szavazat

A hozzászóláshoz be kell jelentkezni

Nem csak redhat-on megy... en debian alatt probaltam.

Leirasokat itt talalhatsz (google /glusterfs/ elso talalat):
http://www.gluster.org/docs/index.php/GlusterFS

Konkret peldakat az alkalmazasra pedig itt:
http://www.gluster.org/docs/index.php/GlusterFS#GlusterFS_Volume_Specif…

--
maszili

0 szavazat

A hozzászóláshoz be kell jelentkezni

Ahh köszi!

Nézem és döntünk majd melyik lesz a legjobb

Még1x köszönöm a segítségeteket!

Mizu

0 szavazat

A hozzászóláshoz be kell jelentkezni

udpcast
http://hup.hu/node/46385

3,4 nem , filerendszer felett nem lehet raid.
(talan, ha fs -eken van egy file amit raid1 -elsz, de szerintem az sem megy, meg ez mar bloat a kobon lenne)

see also
network block device
(Ezt talan lehet raidelni is)

0 szavazat

A hozzászóláshoz be kell jelentkezni

csync - pont erre találták ki, cluster sync. pl. 2 teljesen külön fizikai helyen levő filesys szinkronra. Nekem bejött.
Apropo ezt nem is írtad, fizikailag távol eső vagy egy helyen levő rendszerről van szó ? Local filesys esetén egy gfs próba ?
Saját filesys vagy SAN, NAS, etc filesystem ? Mert ebben az esetben a saját hw keret ezt is megoldja.

Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.

0 szavazat