|
HI Jan
>
> What i would see as the prefect solution would be something like this:
>
> Place hooks in the filesystem, to run the cluster tool on write.
> The cluster tool propogates the changes to both neighbouring servers,
> and also sends an unique ID.
> The tool stores the ID, as handled for a while. (100.000 max to
> ensure dos attack is not possible?)
>
> The other servers cluster tools listen and receive the ID, check to see
> if they handled it previously, and since they didn't ask for the files.
> The servers write the files, without triggering their own update
> mechanism, but trigger a propgation tool with the received ID.
> This would update files around the entire cluster, would have
> configurable paths, and would not give any problems with servers
> updating in an endless loop.
>
> I know this doesn't handle file locks etc. But i think it handles most
> simple scenarios. (LAMP apps for example)
>
> Any toughts on this?
This sounds interesting.
Changedfiles (http://www.bangstate.com/changedfiles-1.0-rc1.tar.gz)
offers part of the solution. Although, you have to code a kernel
module to write the changes back. I was trying out something similar
sometime back for NxN replication where there will be no conflicts.
(the writes can be on any server occasionaly, that has to be
replicated). I was planning to use this to create another simple
module that will write the changes and a deamon in userland that reads
changes and writes to a log. Then the log is sent out to all the other
corresponding deamons which update thier log and sync the filesystem.
But due to other things I had dropped the project.
Ganhawk
http://p2pbridge.sourceforge.net/projects.php
|
