FREP was born out of a need I had to keep a cluster of server synchronized to a central location with instant file replication (one-way replication).
I realized that polling for file changes was going to be out of the question since the application would get progressively slower the more files were added.
I wanted something that wasn't going to be a ressource hog, and since I was looking at replicating over 200,000 files I wanted something that would scale too. When inotify was released in the vanilla linux kernel, I knew I had found the tool I needed to accomplish this job.
The next part of the puzzle that I needed to figure out what the communication mechanism that I was going to need to have in place to communicate changes to a large number of clients. With IP broadcast and multicast capabilities, the Spread cluster message toolkit was a natrual fit. Using Spread's multicasting capabilities, FREP should be able to scale to hundreds (if not thousands) of nodes.
The final piece of the puzzle was figuring out a bandwidth efficient mechanism for file transfers. I initially wanted to implement bits of the rsync protocol, but instead settled on a combination of Zlib compression on file chunks combined with using the generic diff format specification for partial data transfers. This combination should minimize the amount of bandwidth necessary to have file changes replicated to the cluster.
The system consists of several components:
· FREP_Server: The file monitor daemon
· FREP_Resync: The resynchronization daemon
· FREP_FileServer: A generic file server
· FREP_Client: The client installed on the nodes
· FREP_ResyncClient: A resynchronization client installed on the nodes as a failsafe mechanism
What's New in This Release:
· Bug fixes, configuration management
Product's homepage
Find us on Google+
