This the Chiron Filesystem. It is a Fuse based filesystem. It's main purpose is to guarantee filesystem availability using replication. But it isn't a RAID implementation. RAID replicates DEVICES not FILESYSTEMS.

So, as shown in figure 1, most of the current networks fit that simple model. Servers, like Diamond and Sapphire, offer their services. Let's imagine that Diamond is a web server and Sapphire is a file server. Dog and Cat are the clients.

What happens if Diamond becomes unavailable? It means no web server. It means the phone will be ringing soon, your users and your boss want your head, blah, blah, blah... a bad day!

Yeah! You have made your backups. Good! You have even hardware backups. So you just have to restore everything and your day will be good again! But how much time do you spend restoring all that stuff?

You can make Saphire a hardware backup of Diamond (yeah Diamond can be a Saphire backup too). Then you can use Heartbeat to make each server monitor the other and act as a temporary replacement of the unavailable one.

Things are getting better! All the services are already installed and configured on all the servers: Diamond is prepared to act as a file server and Saphire can be the web server.

Everything automatically done! Except the data... Data written in one server is not available to the other until you do your backups.

Figure 1: Classical network model.

Figure 2: ChironFS storage network model.

Now, we will introduce more servers in the net. Mars, Venus and Mercury will be simple file servers. I said SIMPLE! They will have just a basic configuration. They will serve files only to Diamond and Sapphire. Dog and Cat are not allowed to talk to them. They will be servers' servers. They can serve their files with any protocol you want (NFS, SSH, etc.), the only requisite is that Diamond and Sapphire mount the filesystems served by Mars, Venus and Mercury.

So, this is the point where ChironFS starts its job. Diamond and Sapphire mounts the filesystems in Mars, Venus and Mercury. Let's say that they will be /mars, /venus and /mercury. Then, you mount the ChironFS as a combination of /mars, /venus and /mercury using the /chironfs mount-point. From now on, every write in the /chironfs subtree will be echoed to /mars, /venus and /mercury. Any read from /chironfs will be made from only one of the servers' servers (aiming toward load balance).

At this point you realize that you are free from single points of failure! If one of the servers' servers becomes unavailable, you can get the data from the others. ChironFS will detect that the data is unreachable in that server and try to retrieve from another. If Diamond or Sapphire becomes unavailable you can use Heartbeat to make the automatic temporary replacement server, but this time you will have access to all the data written by the dead server just before it died. No need to restore anything!

But why use ChironFS? Why not just use RAID over some network block device? Because it is a block device and if Diamond mounts that device in RW mode, no other server will be able to mount it in RW mode. And this was just a simple example, your real network may have many servers and offer a variety of services. Keeping everything running can become a real nightmare!