Mirroring across 2 Linux systems

[JohnConnolly]

Does anyone know how to mirror data across two systems? I've seen it's possible across 2 disks on the same system and wondered if there's a way to extend that. I don't need guaranteed synchronization (we're not a bank...) or auto switching to the mirror if the main server fails.

 

[ecasadella]

By coding a few lines and using RSYNC you will find very easy to achieve this.

If you want to secure your transference RSYNC has an option to do it with SSH.

And you can use update options (-u) so that data already tranfered wont be overwritten.

this will look something like this:

Common transference
resync -uv <source> <user>@<server>:<destination>

rsync by default uses rsh.


Secure transference
resync -uve ssh2 <source> <user>@<server>:<destination>

to automate this with ssh2 you can generate a null passphrase.

EDC

 

[JohnConnolly]

Thanks for the suggesting &quot;resync&quot;. I've looked at the documentation and I'm worried about the load this will create on the primary server. It seems to me that &quot;resync&quot; will have to work its way right through the data on our primary server (54GB) each time to find out what's changed. What do you think?

I've also found a couple of other possibilities:

&quot;FAM & IMON&quot; - these will signal when a file has changed so an application can, for example, copy it to a mirror. This seems like a low overhead but the implementation looks fairly complex.

&quot;NBD / ENBD&quot; - Network Block Device and Enhanced Network Block Device allow the export of a physical disk. So the mirror system exports the disk, the primary server imports it and uses it a the second disk of a raid mirror. Sounds very simple with (I imagine), low overhead for the primary server and minimum LAN trafic.

Any thoughts on these ideas?

 

[ecasadella]

how often this sync must be done ? and what is the amount of data to be sync? will be always 54Gb?

EDC

 

[JohnConnolly]

There are two reasons why I want a mirror - if the server fails, to lose as little work as possible and to get everyone back to work quickly. So, &quot;how often&quot; is as often as possible. Regarding the amount of data to be mirrored, it varies a lot from maybe 20GB up to 50GB depending on when we last cleaned the server (archive to tape).

 

[ecasadella]

Well an option &quot;as often as possible&quot; would be a cluster solution, but I think this wont fit here.

My question about how often is because we have to know how much of your data changes in a determinate lapse of time.

for instance, in 10min period what is the average of data that vary.

A good solution and very cheap would be add a network card to both servers with a cross wire between them, so that every time you update your storage the transference will be full dedicated.

EDC
--------------------------------------
This is Unix-Land. In quiet nights, you can hear the Windows machines
reboot.

 

[JohnConnolly]

I estimate a minimum of 50MB per hour new/changed data but it can go a lot higher at times. The dedicated mini-LAN is a good idea but what about the load on the primary server? I've no idea how much CPU rsync would take finding the changed data and all the other stuff it needs to do. The server's not that fast P-450 with 128MB but it only serves data.

 

[ecasadella]

That time will depend only on how many files are going to be.

Rsync will check the filename, size and timestamp, so the more files you have, the more time will spend the cpu on this task.

By the way, the disk technology is IDE, isn't it ? EDC
--------------------------------------
This is Unix-Land. In quiet nights, you can hear the Windows machines
reboot.

 

[JohnConnolly]

We have a large number of files and a fairly complicated structure. We use specialized software to scan, colour and compose animation (hand-drawn). The structure for images looks like this:

/colourcamera/project_name/episode_number/unpainted/scene_number/level_name/image_data

The composition information (camera scenes) is held in an even more complex structure but the amount of data is very small.

The process involves a lot of changes to the data. First the drawings are scanned (new files) then they are processed to get them ready for colouring (changed files and new files). Then coloured (changed files and new files). Once all the drawings in a scene have been coloured, the scene folder is moved from /unpainted/ to /painted/ (path change). So there's a lot of activity over and above &quot;new data&quot;.

 

[JohnConnolly]

The primary server has 4 18GB SCSI drives configured as raid 5 on raid hardware (PERC).

 

[JohnConnolly]

I've just been checking our backup logs. The new/changed data is higher than I thought - around 90MB per hour...